반응형
블로그 이미지
개발자로서 현장에서 일하면서 새로 접하는 기술들이나 알게된 정보 등을 정리하기 위한 블로그입니다. 운 좋게 미국에서 큰 회사들의 프로젝트에서 컬설턴트로 일하고 있어서 새로운 기술들을 접할 기회가 많이 있습니다. 미국의 IT 프로젝트에서 사용되는 툴들에 대해 많은 분들과 정보를 공유하고 싶습니다.
솔웅

최근에 올라온 글

최근에 달린 댓글

최근에 받은 트랙백

글 보관함

카테고리


반응형

AWS Cloud Practitioner Essentials (Digital) (Korean) - 02

 

AWS training and certification

 

www.aws.training

 

 

 

https://github.com/yoonhok524/aws-certifications/tree/master/0.%20Cloud%20Practitioner

 

yoonhok524/aws-certifications

AWS 자격증 취득을 위한 관련 내용 정리. Contribute to yoonhok524/aws-certifications development by creating an account on GitHub.

github.com

 

- AWS 보안 소개
안녕하세요. 
 저는 Amazon Web Services(AWS) 교육 및 자격증 팀의 Jody Soeiro de Faria입니다. 
 오늘은 AWS 보안에 대해 소개하려고 합니다. 
 AWS는 높은 가용성과 신뢰성을 위해 설계된 확장 가능한 클라우드 컴퓨팅 플랫폼을 제공하며, 이를 통해 고객이 다양한 애플리케이션을 실행할 수 있는 유연성을 제공합니다. 
 고객 시스템과 데이터의 기밀성, 무결성 및 가용성을 보호하도록 지원하는 것은 고객 신뢰와 자신감을 유지하는 것만큼이나 AWS에 최고로 중요한 사안입니다. 
 이 모듈은 AWS 환경의 제어 및 AWS가 보안 목표를 달성하기 위해 고객에게 제공하는 일부 제품 및 기능을 비롯한 AWS의 보안 접근 방식을 소개하기 위한 목적으로 마련되었습니다. 
 모든 AWS 고객은 보안에 가장 민감한 기업의 요구 사항도 충족시키도록 구축된 데이터 센터 및 네트워크 아키텍처를 활용할 수 있습니다. 
 즉, 기존 데이터 센터의 자본 지출 및 운영 비용 없이도 높은 보안성을 위해 설계된 탄력적인 인프라를 얻을 수 있습니다. 
 AWS 인프라는 강력한 보안 조치를 적용하여 고객의 개인 정보를 보호합니다. 
 AWS는 고객의 의견을 AWS 서비스에 지속적으로 반영하면서 대규모로 빠르게 혁신합니다. 
 Identity and Access Management(IAM), 로깅 및 모니터링, 암호화 및 키 관리, 네트워크 세분화, 비용이 거의 또는 전혀 들지 않는 표준 DDoS 차단과 같은 핵심 보안 서비스를 지속적으로 발전시켜 나가는 등 AWS 솔루션은 시간이 지날수록 더 좋아지기 때문에 이러한 지속적인 개선은 고객에게 이익이 됩니다. 
 이와 더불어 전 세계 보안 동향을 심층적으로 이해하고 있는 엔지니어들이 고안한 고급 보안 서비스도 제공하므로 새로 등장하는 위험을 선제적으로 실시간 처리할 수 있습니다. 
 게다가 이용한 서비스만큼의 가격만, 그것도 저렴하게 지불하면 됩니다. 
 다시 말해 선행 투자 없이 사업 성장에 발맞춰 필요한 보안 서비스를 선택할 수 있고, 자체 인프라를 관리하는 것보다 운영 비용이 훨씬 더 저렴합니다. 
 제대로 보안 조치를 취한 환경은 규정에 맞는 환경이 됩니다. 
 규제 대상 워크로드를 AWS 클라우드로 마이그레이션하면 AWS의 다양한 거버넌스 지원 기능을 이용하여 보안 수준을 한층 강화할 수 있습니다. 
 클라우드 기반의 거버넌스는 향상된 관리 기능, 보안 제어 및 중앙 자동화를 통해 낮은 초기 비용, 좀 더 용이한 운영, 향상된 민첩성 등의 이점을 제공합니다. 
 AWS를 선택하면 AWS가 이미 운영 중인 수많은 보안 제어 기능을 물려받을 수 있기 때문에 유지해야 할 보안 제어 기능의 수가 줄어듭니다. 
 자체적인 규정 준수 및 인증 프로그램은 강화되고, 그와 동시에 기업 고유의 보안 보증 요구 사항을 유지 관리하고 운영하는 데 드는 비용은 절감됩니다. 
 AWS와 파트너는 보안 목표를 달성하는 데 도움이 되는 광범위한 도구와 기능을 제공합니다. 
 이러한 도구는 자체 온프레미스 환경에 배포되는 제어 기능을 결합합니다. 
 AWS는 네트워크 보안, 구성 관리, 액세스 제어 및 데이터 보안 전반에 걸쳐 보안 전용 도구 및 기능을 제공합니다. 
 또한 AWS는 모니터링 및 로깅 도구를 통해 고객 환경에서 발생하는 상황에 대한 완전한 가시성을 제공합니다. 
 AWS는 개인 정보 보호 및 네트워크 액세스 제어를 개선하기 위한 여러 보안 기능과 서비스를 제공합니다. 
 여기에는 AWS 내에서 프라이빗 네트워크를 생성할 수 있는 내장 방화벽, 인스턴스 및 서브넷에 대한 네트워크 액세스 제어 기능, 모든 서비스에서 TLS(전송 계층 보안)로 전송되는 암호화, 사무실 또는 온프레미스 환경에서 프라이빗 또는 전용 연결을 활성화하는 연결 옵션, Auto Scaling 또는 콘텐츠 전송 전략의 일부인 DDoS 완화 기술이 포함됩니다. 
 AWS는 클라우드 리소스가 조직의 표준 및 모범 사례를 계속 준수하도록 보장하는 한편 빠르게 이동할 수 있게 지원하는 광범위한 도구를 제공합니다. 
 여기에는 조직 표준에 따라 AWS 리소스의 생성 및 폐기를 유지 관리하기 위한 배포 도구, AWS 리소스를 식별하고 시간 경과에 따라 해당 리소스의 변경 사항을 추적하고 관리하기 위한 인벤토리 및 구성 관리 도구, Amazon EC2 인스턴스에 대해 미리 구성된 강력한 표준 가상 머신(VM)을 생성하기 위한 템플릿 정의 및 관리 도구가 포함됩니다. 
 AWS는 클라우드에 보관된 데이터에 대한 보안 계층을 추가할 수 있는 기능을 통해 확장 가능하고 효율적인 암호화 기능을 제공합니다. 
 여기에는 Amazon EBS, Amazon S3, Amazon Glacier, Oracle RDS, SQL Server RDS 및 Amazon Redshift와 같은 AWS 스토리지 및 데이터베이스 서비스에서 사용 가능한 데이터 암호화 기능, AWS에서 암호화 키를 관리하도록 할지 아니면 직접 키를 완벽하게 제어할지를 선택할 수 있는 유연한 키 관리 옵션, 고객이 규정 준수 요구 사항을 충족하도록 지원하는 전용 하드웨어 기반 암호화 키 스토리지 옵션이 포함됩니다. 
 또한 AWS는 암호화 및 데이터 보호 기능을 AWS 환경에서 개발하거나 배포하는 서비스와 통합하기 위한 API를 제공합니다. 
 AWS는 AWS 서비스 전반에서 사용자 액세스 정책을 정의하고 적용하며 관리할 수 있는 기능을 제공합니다. 
 여기에는 AWS 리소스에 대해 권한을 가진 개별 사용자 계정을 정의할 수 있는 Identity and Access Management(IAM) 기능, 하드웨어 기반 인증자용 옵션을 포함하여 권한 있는 계정에 대한 멀티 팩터 인증(MFA), 관리 비용을 줄이고 사용자 경험을 개선하기 위한 기업 디렉터리와의 통합 및 연동이 포함됩니다. 
 AWS는 많은 서비스 전반에 걸쳐 기본 Identity and Access Management(IAM) 통합 및 API와 애플리케이션 또는 서비스의 통합을 제공합니다. 
 AWS는 AWS 환경에서 발생하는 상황을 확인할 수 있는 도구와 기능을 제공합니다. 
 여기에는 호출을 수행한 대상, 호출 항목, 호출 위치를 비롯하여 API 호출에 대한 깊은 가시성, 로그 집계 및 옵션, 조사 및 규정 준수 보고 간소화, 특정 이벤트가 발생하거나 임계값을 초과할 경우의 알림 전송이 포함됩니다. 
 이러한 도구 및 기능을 사용하면 비즈니스에 영향을 미치기 전에 문제를 파악하기 위한 가시성을 확보할 수 있으며, 보안 상태를 개선하고 환경의 위험 프로파일을 줄일 수 있습니다. 
 AWS Marketplace는 맬웨어 방지, 웹 애플리케이션 방화벽, 침입 방지 등 기존 제어 및 온프레미스 환경과 동등하거나 동일하거나 이와 통합되는 업계 최고 수준의 파트너 제품 수백 개를 제공합니다. 
 이 제품은 기존 AWS 클라우드 서비스를 보완하여 고객이 종합적인 보안 아키텍처를 배포하고 클라우드 및 온프레미스 환경에서 보다 매끄러운 환경을 구축할 수 있도록 합니다. 
 고객 시스템과 데이터를 안전하게 지키는 것은 고객 신뢰와 자신감을 유지하는 것만큼이나 AWS에 최고로 중요한 사안입니다. 
 이 동영상에서는 AWS 환경의 제어 및 AWS가 보안 목표를 달성하기 위해 고객에게 제공하는 일부 제품 및 기능을 비롯한 AWS의 보안 접근 방식을 소개했습니다. 
 저는 Amazon Web Services(AWS) 교육 및 자격증 팀의 Jody Soeiro de Faria였습니다. 

- AWS 공동 책임 모델
안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Jody Soeiro de Faria입니다. 
오늘은 공동 책임 모델의 개요에 대해 살펴보겠습니다. 
고객이 AWS를 사용하기 시작하면 Amazon은 AWS의 데이터 보안에 대한 책임을 고객과 공유합니다. 
 이 개념을 클라우드 보안의 공동 책임 모델이라고 합니다. 
AWS와 고객이 이 모델에서 어떤 보안에 대한 책임을 지는지 자세히 알아보겠습니다. 
AWS에게는 클라우드 자체의 보안이라는 책임이 있습니다. 
 이 말이 무슨 뜻입니까?공동 책임 모델에서 AWS는 호스트 운영 체제 및 가상화 계층부터 서비스 운영 시설의 물리적인 보안에 이르기까지 구성 요소를 운영, 관리 및 제어합니다. 
 즉, AWS는 리전, 가용 영역 및 엣지 로케이션을 비롯하여 AWS 클라우드에 제공된 모든 서비스를 실행하는 글로벌 인프라를 보호할 책임이 있습니다. 
이 인프라를 보호하는 것은 AWS의 최우선 과제이며 고객이 AWS 데이터 센터나 사옥에 방문하여 직접 확인할 수는 없지만, Amazon은 각종 컴퓨터 보안 표준과 규정에 대한 준수 사실을 확인한 타사 감사자의 보고서를 제공합니다 AWS는 이 글로벌 인프라를 보호할 뿐만 아니라, 컴퓨팅, 스토리지, 데이터베이스 및 네트워킹을 포함하여 기본적인 서비스로 간주되는 해당 제품의 보안 구성도 책임집니다. 
 이러한 유형의 서비스에는 Amazon DynamoDB, Amazon RDS, Amazon Redshift, Amazon Elastic MapReduce, Amazon WorkSpaces 및 여러 다른 서비스가 포함됩니다. 
 이러한 서비스의 경우, 게스트 운영 체제(OS), 데이터베이스 패치, 방화벽 구성, 재해 복구 등의 기본 보안 작업을 AWS가 처리합니다. 
 고객은 안티바이러스 패치 작업, 유지 관리 또는 설치 등에 대해 걱정할 필요가 없습니다. 
 Amazon이 대신 처리하므로 고객은 실제로 플랫폼에 포함되는 대상에 집중할 수 있습니다. 
대부분의 이러한 관리형 서비스의 경우 고객은 리소스에 대한 논리적 액세스 제어를 구성하고 계정 자격 증명을 보호해야 합니다. 
 일부 관리형 서비스의 경우 데이터베이스 사용자 계정 설정과 같은 추가 작업이 필요할 수 있지만 전반적인 보안 구성 작업은 서비스에 의해 수행됩니다. 
 클라우드 인프라는 AWS에 의해 보안이 유지되고 유지 관리되지만 고객은 클라우드 내부에 배치하는 모든 요소의 보안에 대한 책임을 갖습니다. 
AWS 서비스를 이용하는 고객은 콘텐츠를 완벽하게 제어할 수 있으며, 다음과 같은 중요 콘텐츠 보안 요구 사항을 관리해야 할 책임이 있습니다. 
 · AWS에 저장하기로 결정한 콘텐츠 · 콘텐츠와 함께 사용되는 AWS 서비스 · 콘텐츠가 저장되는 국가 · 콘텐츠의 형식과 구조 및 마스크, 익명화 또는 암호화 여부 · 콘텐츠에 액세스할 수 있는 사용자 · 그러한 액세스 권한을 부여, 관리 및 취소하는 방법 고객은 데이터, 플랫폼, 애플리케이션, 자격 증명 및 액세스 관리, 운영 체제를 보호하기 위해 구현하기로 선택한 보안 기능을 제어할 수 있습니다. 
 즉, 공동 책임 모델은 고객이 사용하는 AWS 서비스에 따라 본질적으로 달라집니다. 
또한 AWS Service Catalog를 사용하여 가상 머신 이미지, 서버, 소프트웨어, 데이터베이스 등 AWS에서 사용하도록 승인한 IT 서비스의 카탈로그를 만들고 관리하여 다층적 애플리케이션 아키텍처를 완성할 수 있습니다. 
 AWS Service Catalog는 고객이 공통적으로 배포되는 IT 서비스를 중앙에서 관리하도록 하며, 사용자가 자신에게 필요한 승인된 IT 서비스만 빠르게 배포하도록 하는 한편, 고객이 일관된 거버넌스를 달성하고 규정 준수 요구 사항을 충족하도록 도와줍니다. 
AWS 공동 책임 모델을 시각화하기 위해 예제를 살펴보겠습니다. 
고객이 스토리지에 Amazon S3를 사용하고 데스크톱 및 애플리케이션 스트리밍에 Amazon Workspaces를 사용한다고 가정해 보겠습니다. 
 또한 EC2 인스턴스와 Oracle DB 인스턴스로 구성된 Virtual Private Cloud(VPC)도 있습니다. 
AWS는 AWS 클라우드의 모든 서비스를 실행하는 글로벌 인프라를 보호할 책임이 있습니다. 
 AWS 글로벌 인프라는 보안 모범 사례를 비롯한 다양한 보안 규정 준수 표준에 따라 설계 및 관리됩니다. 
 Amazon EC2 및 Amazon VPC처럼 IaaS(서비스로서의 인프라) 범주에 해당하는 AWS 제품은 고객이 전적으로 제어할 수 있으며 필요한 모든 보안 구성과 관리 작업을 직접 수행해야 합니다. 
 예를 들어 EC2 인스턴스의 경우 고객은 게스트 OS(업데이트 및 보안 패치 포함)를 비롯하여 인스턴스에 설치한 모든 애플리케이션 소프트웨어나 유틸리티의 관리, 그리고 각 인스턴스에 대해 AWS에서 제공한 방화벽(보안 그룹이라고 부름)의 구성을 책임져야 합니다. 
 이는 서버 위치와 상관없이 기존에 수행했던 보안 작업과 기본적으로 동일합니다. 
 오늘 우리가 학습한 내용을 빠르게 복습해 보겠습니다. 
· 공동 책임 모델은 AWS 및 클라우드상의 데이터 보안을 위해 협력하는 고객으로 구성됩니다. 
 · AWS는 클라우드 자체의 보안에 대해 책임을 지는 반면 고객은 클라우드 내부의 보안에 대해 책임을 집니다. 
  · 고객은 사용하고 있는 AWS 서비스에 따라 구현하기로 선택한 보안에 대한 제어권을 갖습니다. 
· 고객은 AWS Service Catalog를 사용하여 AWS에서 사용하도록 승인한 IT 서비스의 카탈로그를 만들고 관리할 수 있습니다. 
· Amazon EC2 및 Amazon VPC처럼 IaaS 범주에 해당하는 AWS 제품은 고객이 전적으로 제어할 수 있으며 필요한 모든 보안 구성과 관리 작업을 직접 수행해야 합니다. 
저는 Amazon Web Services(AWS) 교육 및 자격증 팀의 Jody Soeiro de Faria였습니다. 

- AWS 엑세스 제어 및 관리
안녕하세요. 
 Amazon Web Services 교육 및 자격증 팀의 Jody Soeiro de Faria입니다. 
오늘은 액세스 제어 및 관리의 개요에 대해 살펴보겠습니다. 
AWS Identity and Access Management(IAM)는 AWS 리소스에 대한 고객 및 사용자의 액세스를 안전하게 제어하는 웹 서비스입니다. 
 고객은 IAM을 사용하여 AWS 리소스를 사용할 수 있는 사용자(인증이라고 함)와 리소스를 사용하는 방법(권한 부여라고 함)을 제어합니다. 
AWS Identity and Access Management(IAM)를 사용하면 AWS 클라우드에서 컴퓨팅, 스토리지, 데이터베이스 및 애플리케이션 서비스에 대한 액세스를 관리할 수 있습니다. 
사용자(최종 사용자), 그룹(작업 기능별 사용자 모음), 권한(사용자 또는 그룹에 적용 가능), 역할(신뢰할 수 있는 엔터티) 등 이미 익숙한 액세스 제어 개념에 대해 생각해 보십시오. 
 IAM은 바로 이러한 기능을 사용하여 아주 강력한 성능을 갖게 됩니다!또한, AWS 사용자 및 그룹을 만들고 관리하며 AWS 리소스에 대한 액세스를 허용 및 거부할 수 있습니다. 
 IAM의 기능을 자세히 살펴보겠습니다. 
AWS IAM으로 다음을 수행할 수 있습니다. 
· IAM 사용자 및 액세스 관리 - IAM에서 사용자를 생성하거나, 사용자에게 개별 보안 자격 증명(즉, 액세스 키, 암호, 멀티 팩터 인증 디바이스)을 할당하거나, AWS 서비스 및 리소스에 대한 액세스를 제공할 수 있도록 임시 보안 자격 증명을 요청할 수 있습니다. 
 사용자가 수행할 수 있는 작업을 제어하기 위해 권한을 관리할 수 있습니다. 
· IAM 역할 및 해당 권한 관리 - IAM에서 역할을 생성하고, 역할을 가정하는 엔터티 또는 AWS 서비스로 수행할 수 있는 작업을 제어하는 권한을 관리할 수 있습니다. 
 · 연합된 사용자 및 해당 권한 관리 - 자격 증명 연동을 사용하면 자격 증명별로 IAM 사용자를 생성하지 않고도, 기업 디렉터리에서 기존 자격 증명(사용자, 그룹 및 역할)으로 AWS Management Console에 액세스하고 AWS API를 호출하며 리소스에 액세스할 수 있습니다. 
 Amazon Web Services(AWS) 계정을 처음 생성하면 계정의 모든 AWS 서비스 및 리소스에 대한 완전한 액세스 권한을 가진 단일 로그인 자격 증명으로 시작하게 됩니다. 
 이 자격 증명은 AWS 계정 루트 사용자라고 하며, 계정을 생성할 때 사용한 이메일 주소와 암호로 로그인하여 액세스할 수 있습니다. 
루트 사용자 자격 증명에 대한 권한을 제한할 수 없으므로 루트 사용자 액세스 키를 삭제하는 것이 좋습니다. 
 관리자 수준의 권한이 필요한 경우, IAM 사용자를 생성하고, 이 사용자에게 전체 관리자 액세스 권한을 부여한 다음, 해당 자격 증명을 사용하여 AWS와 상호 작용할 수 있습니다. 
 권한을 취소하거나 수정해야 하는 경우, 해당 IAM 사용자에게 연결된 정책을 삭제하거나 수정할 수 있습니다. 
사용자를 추가할 때, 고객은 사용자가 AWS에 액세스하는 방법을 선택해야 합니다. 
 사용자에게 할당할 수 있는 액세스 유형에는 프로그래밍 방식 액세스 및 AWS Management Console 액세스라는 두 가지 액세스 방식이 있습니다. 
프로그래밍 방식 액세스는 AWS API, CLI, SDK 및 기타 개발 도구에 대한 액세스 키 ID 및 보안 액세스 키를 활성화합니다. 
 다른 옵션은 사용자가 AWS Management Console에 로그인할 수 있도록 허용하는 AWS Management Console 액세스 권한을 사용자에게 부여하는 것입니다. 
 AWS Management Console에서는 간편한 웹 인터페이스를 통해 Amazon Web Services를 사용할 수 있습니다. 
 AWS 계정 이름과 암호를 사용해 로그인할 수 있습니다. 
 AWS Multi-Factor Authentication이 활성화된 경우 디바이스의 인증 코드를 입력하라는 메시지가 표시됩니다. 
사용자는 인증을 받은 후 AWS 서비스에 액세스할 수 있는 권한을 부여받아야 합니다. 
사용자, 그룹 또는 역할에 권한을 할당하려면 권한을 명시적으로 나열하는 문서인 정책을 생성해야 합니다. 
 하나의 정책을 IAM 사용자, IAM 그룹 및 IAM 역할에 할당할 수 있습니다. 
IAM의 기본 개념에 대해 살펴보았으므로 이제 AWS Management Console에 로그인하여 사용자를 생성하고, 사용자를 그룹에 할당하고, 권한을 적용해 보겠습니다. 
로그인을 하면 홈페이지가 표시됩니다. 
 서비스를 위한 콘솔을 열려면 검색 상자에 서비스 이름을 입력한 다음 검색 결과 목록에서 원하는 서비스를 선택합니다. 
  예를 들어, EC2를 입력하면 EC2, EC2 Container Service 및 Elastic File System을 확인할 수 있습니다. 
 검색을 사용하지 않으려는 경우 서비스를 클릭하여 알파벳순으로 정렬된 전체 서비스 목록을 열 수 있습니다. 
 IAM을 찾아 클릭해 봅니다. 
IAM에 들어가면 IAM 사용자 로그인 링크가 표시됩니다. 
  웹 주소에 임의의 숫자가 있다는 점을 알 수 있습니다. 
 이 링크를 쉽게 사용자 지정할 수 있습니다. 
페이지 아래로 이동하면 Security Status 섹션이 표시됩니다. 
계속 진행하여 2명의 사용자를 생성해 봅니다. 
 첫 번째 사용자는 John Doe이고, 두 번째 사용자는 Bob Fields입니다. 
그 다음, 프로그래밍 방식과 AWS Management Console 액세스를 모두 제공할 수 있습니다. 
 또한 두 사용자의 콘솔 암호를 자동으로 생성하거나 할당하려는 경우 선택할 수도 있습니다. 
 password1이라는 암호를 할당해 보겠습니다. 
 또한 사용자가 로그인할 때 암호 재설정을 요구할 수도 있습니다. 
[Next: Permissions]를 클릭합니다. 
 이제 사용자를 그룹에 배치하거나 기존 사용자의 권한을 복사하거나 기존 정책을 직접 연결할 수 있는 옵션을 갖습니다. 
 앞서 언급했듯이 그룹을 생성하고 그룹에 연결할 정책을 선택할 수 있습니다. 
 그룹을 사용하는 것은 작업 기능별로 사용자의 권한을 관리할 수 있는 모범 사례입니다. 
 예를 들어 시스템 관리자, 재무 부서, 개발자 등을 위한 그룹을 생성할 수 있습니다. 
계속 진행하여 시스템 관리 그룹을 생성해 봅니다. 
 [Create Group]을 클릭합니다. 
[Group Name]에 system-admins를 입력합니다. 
그 다음, 이 그룹에 정책을 적용할 수 있습니다. 
 정책은 단순히 사용자 또는 그룹에 연결할 수 있는 권한의 문서라는 점을 기억해야 합니다. 
 그러면 시스템 관리자에게 부여하려는 권한은 무엇입니까? 시스템 관리자가 애플리케이션을 관리할 수 있게 해 보겠습니다. 
 Policy Type: admin을 검색해 봅니다. 
다양한 관리자 정책에 대한 수많은 결과를 확인할 수 있습니다. 
AdministratorAccess라는 상자를 확인해 봅니다. 
 그런 다음 [Create Group]을 클릭합니다. 
 [Next: Review]를 클릭합니다. 
 이제 방금 생성한 사용자 세부 정보 및 권한 요약을 검토할 수 있습니다. 
 좋습니다. 
 이제 [Create Users]를 클릭합니다. 
앞서 생성한 John과 Bob이 표시됩니다. 
 또한 이 사용자와 관련하여 생성된 다른 항목도 있습니다. 
  액세스 키 ID와 보안 액세스 키입니다. 
사용자가 명령줄 인터페이스 또는 SDK 및 API를 사용하여 프로그래밍 방식으로 AWS와 상호 작용하게 하려면 액세스 키 ID와 보안 액세스 키가 모두 필요합니다. 
 하지만 AWS Management Console에 로그인하려면 여기에 나열된 사용자 이름과 암호를 사용하게 됩니다. 
마지막 단계는 . 
CSV 파일을 다운로드하여 생성한 사용자의 기록과 로그인 정보를 얻는 것입니다. 
 이제 [Close]를 클릭합니다. 
이제 사용자인 John과 Bob이 한 그룹에 속해 있다는 점을 확인할 수 있습니다. 
 마지막으로 로그인한 시간도 확인할 수 있습니다. 
 또한 왼쪽의 탐색 항목을 사용하여 사용자를 분석하고, 정책을 추가하고, 정책을 분리하고, 그룹을 변경하고, 기타 사용자 관리 기능을 사용할 수 있습니다. 
계속 진행하여 대시보드로 돌아갑니다. 
 Security Status 확인 목록에 다음 몇 가지 항목이 확인된 상태에 있는 것을 볼 수 있습니다. 
· 개별 IAM 사용자를 생성했음. 
· 그룹을 사용하여 권한을 할당했음· 이제 마지막으로 해야 할 일은 IAM 암호 정책을 적용하는 것입니다. 
 계속 진행하여 [Apply an IAM password policy]를 클릭한 다음 [Manage Password Policy]를 클릭합니다. 
 이 화면에서 IAM 사용자가 설정할 수 있는 암호 유형을 정의하는 기본 규칙을 설정합니다. 
 비즈니스에 가장 적합한 특정 암호 정책을 설정했으면 계속 진행하여 [Apply password policy]를 클릭합니다. 
마지막으로, AWS Management Console에서 역할에 대한 작업을 수행해야 합니다. 
 계속 진행하여 왼쪽 탐색 창에서 [Roles]를 클릭합니다. 
 역할은 신뢰하는 엔터티에 권한을 부여하는 안전한 방식이라는 점을 기억하세요. 
 계속 진행하여 [Create Role]을 클릭합니다. 
AWS 서비스, 다른 AWS 계정, 웹 자격 증명 또는 SAML 2.0 연동과 같은 역할 유형을 클릭하여 선택할 수 있습니다. 
계속 진행하여 [AWS Service]를 클릭합니다. 
 S3에 파일을 저장하기 위해 EC2에 액세스해야 하는 역할을 생성하고 있다고 가정해 보겠습니다. 
  이제 사용 사례를 선택합니다. 
 첫 번째 옵션 “Allows EC2 instances to call AWS services on your behalf”를 선택합니다. 
 [Next: Permissions]를 클릭합니다. 
 이전에 그룹에서 확인했던 것처럼 권한을 할당하는 정책을 적용할 수 있습니다. 
EC2 인스턴스에 액세스하여 S3에 파일을 저장할 수 있으므로 이제 계속 진행하여 S3 정책을 검색해 보겠습니다. 
 [AmazonS3Full Access]를 클릭합니다. 
 [Next]를 클릭합니다. 
[Role Name]에 S3-Access를 추가합니다. 
  설명을 추가할 수도 있지만 필수는 아닙니다. 
 [Create Role]을 클릭합니다. 
  좋습니다. 
 새로운 역할이 생성되었습니다!  이 역할을 EC2 인스턴스에 적용할 수 있으며, 연결된 정책에 따라 S3 권한이 부여됩니다. 
축하합니다! 사용자를 생성했고, 그룹에 할당했으며, 작업 기능을 기반으로 권한을 적용했습니다. 
  또한 IAM 암호 정책을 적용하여 Security Status 확인 목록 항목을 완료했습니다. 
 그런 다음 역할을 생성했습니다. 
 이것이 신뢰할 수 있는 엔터티에 권한을 부여하는 멋진 방법이라는 점도 확인했습니다. 
 훌륭하네요!IAM의 작동 방식을 살펴보았으므로 이제 IAM의 모범 사례에 대해 알아보겠습니다. 
· AWS 루트 계정 액세스 키는 AWS 리소스에 대한 무제한 액세스를 제공하므로 삭제. 
 대신, IAM 사용자 액세스 키 또는 임시 보안 자격 증명 사용. 
· AWS 루트 계정에 대해 멀티 팩터 인증(MFA)을 활성화하여 계정을 안전하게 유지할 수 있는 또 다른 보호 계층 추가. 
 · IAM 사용자를 생성하고 필요한 권한만 부여. 
 AWS 루트 계정은 AWS 리소스에 대한 무제한 액세스를 제공하므로 AWS와의 일상적인 상호 작용에 해당 루트 계정을 사용하지 않음. 
 · IAM 그룹을 사용하여 IAM 사용자에게 권한을 할당해서 계정의 권한을 간편하게 관리하고 감사할 수 있음. 
· IAM 암호 정책을 적용하여 IAM 사용자가 강력한 암호를 만들고 암호를 정기적으로 교체하도록 요구. 
· Amazon EC2 인스턴스에서 실행되는 애플리케이션에 역할 사용· 자격 증명을 공유하기보다는 역할을 사용하여 위임· 자격 증명을 주기적으로 교체· 불필요한 사용자와 자격 증명을 제거· 보안 강화를 위해 정책 조건 사용· AWS 계정 내 활동을 모니터링요약하자면, AWS Identity and Access Management는 고객과 사용자가 AWS 리소스에 대한 액세스를 안전하게 제어할 수 있도록 도와줍니다. 
  이를 통해 액세스, 역할 및 권한과 더불어 사용자 및 그룹을 관리할 수 있습니다. 
저는 Amazon Web Services(AWS) 교육 및 자격증 팀의 Jody Soeiro de Faria였습니다.

- AWS 보안 규정 준수 프로그램
안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Jody Soeiro de Faria입니다. 
 오늘은 보안 규정 준수 프로그램의 개요에 대해 살펴보겠습니다. 
Amazon의 모든 것과 마찬가지로, AWS 보안 및 규정 준수 프로그램의 성공 여부를 가늠하는 단 한 가지 기본 조건은 바로 고객의 성공입니다. 
 AWS 고객들은 안전하고 규정에 맞는 클라우드 환경을 운영할 수 있도록 마련된 AWS의 규정 준수 보고서, 증명, 인증 포트폴리오를 믿고 따릅니다. 
 이러한 노력을 발판 삼아 AWS가 제공하는 확장성과 비용 절감 효과를 달성하는 동시에 강력한 보안 및 규정 준수의 혜택을 얻을 수 있습니다. 
 이 모듈에서는 다음 주제에 대해 살펴보겠습니다. 
· 보증 프로그램을 비롯한 AWS의 규정 준수 접근 방식. 
· 위험 관리, 제어 환경 및 정보 보안과 같은 AWS 위험 및 규정 준수 프로그램. 
· 마지막으로, AWS 고객 규정 준수 책임. 
공동 보안 책임 모델에서 AWS와 고객은 IT 환경의 보안을 함께 제어합니다. 
 이 공동 책임 모델에서 AWS가 책임져야 할 부분에는 매우 안전하게 관리되는 플랫폼에서 서비스를 제공하고 고객이 사용할 수 있는 다양한 보안 기능을 지원하는 일이 포함됩니다. 
 고객사의 책임에는 목적에 맞춰 안전하고 통제된 방식으로 IT 환경을 조성하는 것이 포함됩니다. 
 고객이 IT 환경의 용도와 구성을 AWS에 알리지 않더라도 AWS는 고객과 관련된 보안 및 제어 환경을 알려야 합니다. 
 AWS는 다음과 같은 방법으로 이를 수행합니다. 
 · 산업 인증 및 독립적인 타사 인증 획득· 백서와 웹 사이트 콘텐츠를 통한 AWS 보안 및 규제 관행에 대한 정보 공개
 · NDA 체결 후, AWS 고객사에 인증서, 보고서 및 기타 문서 직접 제공(필요한 경우). 
AWS는 외부 인증 기관 및 독립 감사자와 협력하여 고객에게 AWS에서 확립 및 운영하는 정책, 프로세스 및 컨트롤에 대한 다양한 정보를 제공합니다. 
 규정 준수 인증 및 검증은 독립적인 외부 감사 기관이 평가하여 인증, 감사 보고 또는 규정 준수 검증의 형태로 결과가 나타납니다. 
 AWS 고객은 관련 규정 준수 법률 및 규정을 준수할 책임이 있습니다. 
 경우에 따라 AWS는 고객 규정 준수를 지원하기 위한 기능(보안 기능 등), 인에이블러 및 법률 계약(AWS 데이터 처리 계약 및 비즈니스 제유 계약 등)을 제공합니다. 
 규정 준수 편성 및 프레임워크에는 특정 업계나 기능과 같은 특정 목적으로 게시된 보안 또는 규정 준수 요건이 포함됩니다. 
 AWS는 이러한 유형의 프로그램에 맞는 기능(보안 기능 등)과 인에이블러(규정 준수 플레이북, 매핑 문서 및 백서 포함)를 제공합니다. 
AWS는 고객이 거버넌스 프레임워크에 AWS 컨트롤을 통합할 수 있는 위험 및 규정 준수 프로그램에 대한 정보를 제공합니다. 
 이 정보는 고객이 프레임워크의 중요한 부분으로 포함된 AWS를 통해 전체 제어 및 거버넌스 프레임워크를 문서화할 수 있도록 지원합니다. 
 AWS 위험 및 규정 준수 프로그램은 다음 세 가지 요소로 구성됩니다. 
· 위험 관리
· 제어 환경
· 정보 보안

각 AWS 위험 및 규정 준수 프로그램을 자세히 살펴보겠습니다. 
 AWS 관리 팀은 위험 식별과 위험을 완화 또는 관리할 수 있는 컨트롤 구현을 포함하는 전략적 비즈니스 계획을 개발했습니다. 
 AWS 관리 팀은 최소한 1년에 두 번 이상 전략적 비즈니스 계획을 재평가합니다. 
 이 프로세스에서는 관리 팀이 책임 영역 내의 위험을 식별하고 그러한 위험을 해결할 수 있도록 고안된 적절한 대책을 구현해야 합니다. 
또한 AWS 제어 환경은 다양한 내부 및 외부 위험 평가를 거칩니다. 
 AWS 규정 준수 및 보안 팀은 다음 관리 기관을 기반으로 정보 보안 프레임워크 및 정책을 구축했습니다. 
· COBIT(Control Objectives for Information and related Technology)
· AICPA(미국 공인회계사 협회)
· NIST(National Institute of Standards and Technology)

AWS는 보안 정책을 유지하고, 직원에게 보안 교육을 제공하며, 애플리케이션 보안 검토를 수행합니다. 
 이러한 검토는 정보 보안(IS) 정책에 대한 일치성뿐 아니라 데이터의 기밀성, 무결성 및 가용성도 평가합니다. 
AWS 보안 팀은 정기적으로 모든 인터넷 연결 서비스 엔드포인트 IP 주소를 검사하여 취약성이 있는지 확인합니다(검사는 고객 Amazon EC2 인스턴스 인터페이스에서 수행되지 않음). 
 AWS 보안 팀은 확인된 취약성을 해결하기 위해 해당 당사자에게 취약성을 알립니다. 
 또한 독립적인 보안 회사에서 정기적으로 외부 취약성 위협 평가를 수행합니다. 
 이러한 평가 결과 확인된 내용과 권장사항이 범주화되어 AWS 책임자에게 전달됩니다. 
 이러한 검사는 기본 AWS 인프라의 상태와 실현가능성을 확인하는 방식으로 수행되며, 특정 규정 준수 요건을 충족하는 데 필요한 고객의 자체 취약성 검사를 대체하기 위한 의도로 제공되지 않습니다. 
 고객은 검사가 고객의 인스턴스에 국한되고 AWS Acceptable Use Policy를 위반하지 않는 범위에서 클라우드 인프라 검사를 수행할 수 있는 권한을 요청할 수 있습니다. 
AWS는 Amazon의 전체 통제 환경의 다양한 측면을 활용하는 정책, 프로세스 및 통제 활동을 포함하는 포괄적인 통제 환경을 관리합니다. 
 이 통제 환경은 AWS 서비스 제품군을 안전하게 제공하기 위해 마련되었습니다. 
 이 집합적인 제어 환경은 AWS 제어 프레임워크의 운영 효과를 지원하는 환경을 구성 및 관리하는 데 필요한 인력, 프로세스 및 기술을 포괄합니다. 
 AWS는 선도적인 클라우드 컴퓨팅 산업 기관에서 확인한 적용 가능한 클라우드 관련 컨트롤을 AWS 제어 프레임워크에 통합했습니다. 
 AWS는 고객이 제어 환경을 관리할 수 있도록 더 효과적으로 지원하는 주요 사례를 구현하기 위해 이러한 산업 그룹을 지속적으로 모니터링합니다. 
AWS는 고객 시스템 및 데이터의 기밀성, 무결성, 가용성을 보호할 수 있도록 고안된 공식적인 정보 보안 프로그램을 구현했습니다. 
 AWS는 공개 웹 사이트에 AWS에서 고객이 데이터를 안전하게 보호하도록 도울 수 있는 방법을 설명한 보안 백서를 게시합니다. 
온라인에서 사용 가능한 리소스를 살펴보겠습니다. 

 먼저 http://aws.amazon.com/compliance로 이동합니다. 
  지금까지 다루고 있는 주제에 대한 리소스를 찾을 수 있는 곳입니다. 
 예를 들어, 보증 프로그램을 클릭하면 사용 가능한 프로그램 목록이 표시됩니다. 
 미국을 클릭한 다음 아래로 스크롤하여 HIPAA를 클릭해 봅니다. 
  페이지를 스크롤하면서 많은 정보를 발견할 수 있습니다. 
  페이지 상단에는 HIPAA에 초점을 맞춘 백서가 있습니다. 
  해당 백서를 클릭하면 자세한 pdf 파일이 표시됩니다. 
  이 문서의 제목은 “Architecting for HIPAA Security and Compliance on Amazon Web Services”입니다. 
  목차로 스크롤하면 여기에 나열된 모든 서비스에 대한 HIPAA 규정 준수 정보를 확인할 수 있습니다. 
 이 사이트에 나열된 다른 보증 프로그램에 대해서도 유사한 정보를 찾을 수 있습니다. 
늘 그렇듯이 AWS 고객은 IT 배포 방식에 관계 없이 전체 IT 제어 환경에 대한 적절한 거버넌스를 지속적으로 유지해야 합니다. 
 주요 모범 사례: 
 · 필요한 규정 준수 목표 및 요건 이해(관련 소스에서)
 · 그러한 목표와 요건을 충족하는 제어 환경 구성
 · 조직의 위험 허용 범위에 따라 필요한 확인 이해
 · 제어 환경의 운영 효과 검증 
 
 AWS 클라우드 기반 배포를 통해 대기업에게 다양한 유형의 컨트롤과 다양한 검증 방법을 적용할 수 있는 여러 옵션을 제공할 수 있습니다. 
 강력한 고객 규정 준수와 거버넌스에는 다음과 같은 기본 접근법이 포함될 수 있습니다. 
 · AWS에서 제공하는 정보와 기타 정보를 함께 검토하여 전체 IT 환경을 최대한 이해한 다음 모든 규정 준수 요건을 문서화합니다. 
· 대기업의 규정 준수 요건을 충족하는 제어 목표를 수립하고 구현합니다. 
· 외부 당사자가 소유한 제어 기능을 식별하고 문서화합니다. 
· 모든 제어 목표가 달성되었으며 모든 주요 제어 환경이 효과적으로 설계 및 운영되고 있는지 확인합니다. 
고객은 AWS를 통해 규정 준수 및 거버넌스 프로세스에 참여하여 규정 준수 요건을 충족할 수 있습니다. 
Amazon Web Services 클라우드 규정 준수를 통해 고객은 클라우드에서 보안 및 데이터 보호를 유지하기 위한 AWS의 강력한 통제 환경을 이해할 수 있습니다. 
 시스템이 AWS 클라우드 인프라를 기반으로 구축되기 때문에 규정 준수와 관련된 책임이 공유됩니다. 
 AWS 규정 준수 프로그램은 기존 프로그램을 기반으로 하며, 고객이 AWS 보안 제어 환경을 구성하고 운영할 수 있도록 지원합니다. 
 저는 Amazon Web Services(AWS) 교육 및 자격증 팀의 Jody Soeiro de Faria였습니다. 
 
 
 - AWS 보안 리소스
 안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Jody Soeiro de Faria입니다. 
 오늘은 보안 리소스의 개요에 대해 살펴보겠습니다. 
 앞서 언급했듯이 AWS는 다음을 수행하여 고객에게 보안 및 제어 환경을 전달합니다. 
· 산업 인증 및 독립적인 타사 증명
· 백서와 웹 콘텐츠를 통한 AWS 보안 및 규제 관행에 대한 정보
· NDA에 따라 AWS 고객에게 인증서, 보고서 및 기타 문서 직접 제공

AWS가 온라인 도구, 리소스, 지원 및 전문 서비스를 통해 클라우드에서 데이터를 보호할 수 있도록 고객에게 지침 및 전문 지식을 제공하는 방법에 대해 자세히 살펴보겠습니다. 
AWS Trusted Advisor는 맞춤형 클라우드 전문가와 같은 역할을 하는 온라인 도구로서, 모범 사례를 따르도록 리소스를 구성할 수 있도록 도와줍니다. 
 Trusted Advisor는 AWS 환경을 검사하여 보안 격차를 줄이고, 비용 절감과 시스템 성능 개선, 안정성 향상에 대한 기회를 찾을 수 있도록 도와줍니다. 
AWS 계정 팀은 첫 번째 연락 지점을 제공하여 배포 및 구현 과정을 안내하고, 직면할 수 있는 보안 문제를 해결하기 위한 최적의 리소스를 알려 줍니다. 
AWS Enterprise Support는 15분의 응답 시간을 제공하며 전담 기술 계정 관리자와 함께 전화, 채팅 또는 이메일을 통해 24시간 연중 무휴로 이용할 수 있습니다. 
 이 컨시어지 서비스는 고객의 문제가 최대한 신속하게 처리되도록 보장합니다. 
AWS Professional Services 및 AWS 파트너 네트워크는 충분히 검증된 설계를 기반으로 보안 정책과 절차를 개발하고 고객의 보안 설계가 내부 및 외부 규정 준수 요건을 충족하도록 지원합니다. 
 AWS 파트너 네트워크는 고객의 보안 및 규정 준수 요구 사항을 지원하는 전 세계 수백 개의 인증된 AWS 컨설팅 파트너를 보유하고 있습니다. 
AWS 자문 및 게시판을 통해 AWS는 현재의 취약성 및 위협에 대한 자문을 제공하고 고객이 AWS 보안 전문가와 협력하여 침해 사례, 취약성 및 침투 테스트와 같은 문제를 해결할 수 있게 합니다. 
감사, 규정 준수 또는 법적 역할을 수행하는 경우 AWS 감사자 학습 과정을 확인하면 내부 작업이 AWS 플랫폼을 사용하여 규정 준수를 증명할 수 있는 방법을 더 깊이 이해할 수 있습니다. 
 규정 준수 웹 사이트의 추천 교육, 자습형 실습 및 리소스 감사에 액세스할 수 있습니다. 
규정 준수를 어디부터 시작해야 할지 잘 모르거나 자주 사용하는 리소스 및 프로세스에 액세스해야 하는 경우 AWS 규정 준수 솔루션 안내서를 확인합니다. 
 공동 책임 모델 이해, 규정 준수 보고서 요청 또는 보안 질문서 작성과 같은 사용 가능한 규정 준수 솔루션에 대해 알아보십시오. 
기타 유용한 규정 준수 리소스에는 다음 항목이 포함됩니다. 
· 범위 내 서비스. 
 이 페이지는 현재 범위 내에 있는 서비스와 진행 중인 서비스에 대한 세부 정보를 보여 줍니다. 
· AWS 보안 블로그는 AWS 보안 프로그램의 최신 업데이트를 모두 추적할 수 있는 좋은 방법입니다. 
· 사례 연구는 보안과 관련된 AWS의 현재 고객 경험에 대한 통찰력 있는 정보를 제공합니다. 
· PCI, HIPAA, SOC, FedRAMP와 같은 특정 규정 준수 유형에 대한 자주 묻는 질문의 답변을 얻을 수도 있습니다. 
AWS 보안에 대한 자세한 내용을 확인하려면 <http://AWS.amazon.com/security>에 방문하십시오. 
 리소스 탭에서는 개발자 문서, 백서, 도움말 및 자습서로 연결되는 링크 및 AWS 보안 환경을 사용자 지정하는 제품을 검색할 수 있는 AWS Marketplace의 링크를 찾을 수 있습니다. 
 또한 http://AWS.amazon.com/compliance를 방문하고 리소스 탭을 클릭하여 규정 준수 리소스에 대한 자세한 내용을 확인할 수도 있습니다. 
 이 페이지의 리소스는 필수, 워크북, 개인 정보 보호 정책, 정부, 가이드 및 모범 사례 범주로 구성되어 있습니다. 
  추가 정보가 필요한 경우 프로덕션 환경을 구성하기 전에 지식을 적용하는 데 도움이 되는 라이브 또는 가상 강좌의 자습형 실습, 강의식 교육 학습 방식의 AWS 교육을 언제든지 수강할 수 있습니다. 
복습하자면, AWS는 AWS 클라우드에서 데이터의 보안을 보장하기 위해 여러 가지 서비스, 도구, 제품 및 리소스를 제공합니다. 
 http://aws.amazon.com/security 또는 http://aws.amazon.com/compliance를 방문하여 더 많은 리소스를 확인할 수 있습니다. 
 저는 Amazon Web Services(AWS) 교육 및 자격증 팀의 Jody Soeiro de Faria였습니다. 
 

 

 


- Well Architected 프레임워크 소개
안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox입니다. 
 오늘 동영상에서는 Well-Architected 프레임워크에 대해 간략히 소개하겠습니다. 
 AWS Well-Architected 프레임워크는 고객을 돕기 위한 목적입니다. 
 고객이 고유의 아키텍처를 평가 및 개선하고 설계에 대한 의사결정이 비즈니스에 미치는 영향을 더 확실히 파악할 수 있도록 돕기 위한 목적입니다. 
 AWS 전문가는 고객이 아키텍처를 분석하고 비평적으로 생각하는 데 도움이 되는 여러 가지 질문을 개발했습니다. 
 인프라가 모범 사례를 따르는지 확인하는 데 도움을 줍니다. 
 이를 통해 AWS는 다섯 가지 관점 또는 핵심 요소로부터 아키텍처를 설계하는 데 도움이 되는 안내서를 개발했습니다. 
 이러한 핵심 요소는 보안, 안정성, 성능 효율성, 비용 최적화 및 운영 우수성입니다. 
 이 동영상 전체에 걸쳐 각 핵심 요소를 자세히 살펴볼 것입니다. 
 또한 각 핵심 요소의 설계 원칙에 대해서도 논의해 보겠습니다. 
 이제 보안 핵심 요소를 알아보겠습니다. 
 보안 핵심 요소에는 위험 평가 및 완화 전략을 통해 정보, 시스템 및 자산을 보호하는 동시에 비즈니스 가치를 제공하는 능력이 포함됩니다. 
 여기에서 좀 더 자세히 살펴보자면, 클라우드 보안은 다섯 가지 영역으로 구성되어 있습니다. 
 각 영역에 대해 간략히 알아보겠습니다. 
 · 먼저 AWS Identity and Access Management(IAM)가 있습니다. 
 이는 고객이 의도한 방식에 따라 권한이 부여되고 인증된 사용자만 리소스에 액세스할 수 있도록 보장하는 데 매우 중요한 역할을 합니다. 
 · 그리고 탐지 제어도 있습니다. 
 탐지 제어는 로그를 캡처하거나 분석하고 감사 제어를 통합하는 것과 같은 접근 방식을 고려하여 잠재적인 보안 사고를 식별하는 데 사용할 수 있습니다. 
 · 그 다음, 인프라 보호도 있습니다. 
 이를 통해 아키텍처 내의 시스템과 서비스가 의도치 않은 무단 액세스로부터 보호됩니다. 
 예를 들어 사용자는 네트워크 경계, 강화 및 패치 작업, 사용자/키/액세스 수준, 애플리케이션 방화벽 또는 게이트웨이를 생성할 수 있습니다. 
 · 그리고 데이터 보호가 있습니다. 
 데이터 보호의 경우 고려해야 할 많은 접근 방식과 방법이 있습니다. 
 여기에는 데이터 분류, 암호화, 보관된 데이터 및 전송 중인 데이터 보호, 데이터 백업, 그리고 필요할 때의 복제 및 복구가 포함됩니다. 
 · 마지막으로, 사고 대응이 있습니다. 
 모든 예방 및 탐지 방법을 사용하더라도 조직은 잠재적 보안 사고에 대응하고 그 영향을 완화하기 위한 사고 대응 프로세스를 마련해야 합니다. 
 사고 대응은 적절한 시기에 복구 작업을 수행할 수 있도록 아키텍처가 업데이트되도록 보장합니다. 
 설계할 때에는 보안을 강화하는 데 도움이 되는 이러한 설계 원칙을 고려하는 것이 중요합니다. 
 AWS의 첫 번째 설계 원칙은 모든 계층에 보안을 적용하는 것입니다. 
 고객은 모든 장소와 모든 계층의 인프라를 보호하고자 합니다. 
 물리적 데이터 센터에서 보안은 일반적으로 주변에 대해서만 고려됩니다. 
 AWS를 사용하면 주변뿐만 아니라 리소스 내와 리소스 간에 보안을 구현할 수 있습니다. 
 이를 통해 개별 환경과 구성 요소가 서로 안전하게 보호됩니다. 
 그런 다음 AWS는 추적 기능을 활성화하고자 합니다. 
 고객은 환경에 대한 모든 작업 또는 변경 사항을 기록하고 감사하여 이를 수행할 수 있습니다. 
 또 다른 유용한 설계 원칙은 최소 권한의 원칙을 구현하는 것입니다. 
 기본적으로 고객은 환경의 권한 부여가 적절한지, AWS 리소스에 대한 강력한 논리적 액세스 제어를 구현하고 있는지 확인하고자 합니다. 
 다음으로, AWS는 고객이 시스템 보안에 집중하도록 보장하고 싶습니다. 
 AWS 공동 책임 모델을 사용하면 AWS에서 보안 인프라 및 서비스를 제공하므로 고객은 애플리케이션, 데이터 및 운영 체제 보안에 집중할 수 있습니다. 
 마지막으로, 기억해야 할 마지막 설계 원칙은 보안 모범 사례를 자동화하는 것입니다. 
 소프트웨어 기반 보안 메커니즘은 더욱 빠르고 비용 효율적으로 안전하게 확장하는 기능을 개선합니다. 
 예를 들어 가상 서버의 패치 적용 및 강화된 이미지를 만들어 저장한 다음, 해당 이미지가 필요할 때 이미 강화되고 패치 적용된 동일한 이미지를 사용하여 자동으로 새 인스턴스를 만드는 것이 권장됩니다. 
 또 다른 모범 사례는 정기적인 보안 이벤트와 비정상적인 보안 이벤트에 대한 응답을 자동화하는 것입니다. 
 다음은 안정성 핵심 요소에 대해 살펴보겠습니다. 
 안정성 핵심 요소에는 인프라 또는 서비스 장애로부터 복구할 수 있는 시스템의 기능이 포함됩니다. 
 또한 수요를 충족하고 중단 사태를 완화하기 위해 컴퓨팅 리소스를 동적으로 확보하는 기능에 중점을 둡니다. 
 그 결과, 장애로부터 복구하고 수요를 충족하는 기능을 지원하는 안정성을 얻을 수 있습니다. 
 클라우드의 안정성은 기반, 변경 관리 및 장애 관리라는 세 가지 영역으로 구성됩니다 안정성을 확보하려면 아키텍처 및 시스템이 수요 또는 요구 변화를 처리하며 장애를 탐지하고 자동으로 해결할 수 있는 잘 계획된 기반을 갖춰야 합니다. 
 모든 유형의 구조를 설계하기 전에는 건설 전에 미리 기반을 잘 살펴보는 것이 매우 중요합니다. 
 클라우드에서도 마찬가지로 모든 시스템을 설계하기 전에 안정성에 영향을 미치는 기본 요구 사항이 준비되어 있어야 합니다. 
 변경 관리의 경우 변경 사항이 시스템에 미치는 영향을 완전히 이해하고 인식하는 것이 중요합니다. 
 사전 계획을 세우고 시스템을 모니터링하면 빠르고 안정적으로 변경 사항을 수용하고 조정할 수 있습니다. 
 아키텍처가 안정적인지 확인하기 위해서는 장애를 예측하고 인식하며 대응하고 장애 발생을 방지하는 것이 중요합니다. 
 클라우드 환경에서는 자동화된 모니터링 기능을 활용하고 환경의 시스템을 교체하며 이후 장애가 발생한 시스템의 문제를 해결할 수 있습니다. 
 이 모든 작업이 안정적인 상태에서 낮은 비용으로 수행됩니다. 
 이제 안정성 설계 원칙을 알아보겠습니다. 
 안정성을 향상시킬 수 있는 설계 원칙에는 복구 절차 테스트가 포함됩니다. 
 클라우드에서 사용자는 시스템에 어떻게 장애가 발생하는지 테스트할 수 있으며 복구 절차를 확인할 수 있습니다. 
 사용자는 실제 장애가 발생하기 전에 다른 장애를 시뮬레이션하고 공개한 다음 대응할 수 있습니다. 
 다음으로, AWS는 장애로부터 자동으로 복구합니다. 
 AWS에서는 임계값이 초과될 때 자동 대응을 트리거할 수 있습니다. 
 이를 통해 장애가 발생하기 전에 미리 예측하여 해결할 수 있습니다. 
 다음 원칙은 수평적으로 확장하여 전체 시스템 가용성을 높이는 것입니다. 
 하나의 큰 리소스가 있을 때 이 리소스를 여러 개의 작은 리소스로 대체하여 단일 장애 지점이 전체 시스템에 미치는 영향을 줄이는 것이 유용합니다. 
 따라서 여기에서의 목표는 수평적으로 확장하고 여러 작은 리소스 간에 요구 사항을 분산하는 것입니다. 
 다음 설계 원칙은 용량에 대한 추측을 중단하는 것입니다. 
 클라우드 환경에서 고객은 수요와 시스템 사용률을 모니터링하고, 리소스 추가 또는 제거를 자동화할 수 있는 기능을 갖게 됩니다. 
 이를 통해 프로비저닝 과다 또는 부족 현상 없이 최적의 수준으로 수요를 충족할 수 있습니다. 
 마지막으로, AWS는 변경 사항과 자동화를 관리합니다. 
 아키텍처 및 인프라에 대한 변경은 자동화된 방식으로 수행되어야 합니다. 
 이렇게 하면 모든 단일 시스템 또는 리소스가 아닌 자동화 변경만 관리하면 됩니다. 
 이제 성능 효율성 핵심 요소를 알아보겠습니다. 
 클라우드에서 성능 효율성 핵심 요소는 선택, 검토, 모니터링 및 트레이드오프라는 네 가지 요소로 구성됩니다. 
 각 영역을 자세히 살펴보겠습니다. 
 선택의 경우 아키텍처를 최적화할 가장 적합한 솔루션을 선택하는 것이 중요합니다. 
 하지만 이러한 솔루션은 보유한 워크로드의 종류에 따라 달라집니다. 
 AWS에서는 리소스를 가상화할 수 있으며 다양한 유형 및 구성으로 솔루션을 사용자 지정할 수 있습니다. 
 검토를 통해 솔루션을 지속적으로 혁신하고 새롭게 사용 가능한 기술 및 접근 방식을 활용할 수 있습니다. 
 이렇게 새롭게 출시된 제품은 아키텍처의 성능 효율성을 향상시킬 수 있습니다. 
 모니터링의 경우, 아키텍처를 구현한 후 성능을 모니터링하여 고객이 문제의 영향을 받고 인식하기 전에 해당 문제를 해결할 수 있어야 합니다. 
 AWS를 사용하면 Amazon CloudWatch, Amazon Kinesis, Amazon Simple Queue Service(Amazon SQS) 및 AWS Lambda와 같은 도구를 사용하여 자동화를 사용하고 아키텍처를 모니터링할 수 있습니다. 
 마지막으로, 트레이드오프가 있습니다. 
 최적의 접근 방식을 보장하는 트레이드오프의 예는 일관성, 내구성 및 공간을 위해 시간 또는 지연 시간을 절충하여 높은 성능을 제공하는 것입니다. 
 이제 성능 효율성을 달성하는 데 도움이 되는 설계 원칙을 살펴보겠습니다. 
 먼저, 고급 기술의 대중화입니다. 
 기술에 대한 지식과 복잡성을 클라우드 업체가 제공하는 서비스로 극복하면서, 구현하기 어려운 기술도 간편하게 사용할 수 있습니다. 
 IT 팀은 새로운 기술을 호스팅하고 실행하는 방법을 배우는 대신, 이를 서비스로 사용하기만 하면 됩니다. 
 그 다음, AWS는 몇 분 만에 전 세계로 확장할 수 있습니다. 
 AWS를 사용하면 전 세계 여러 리전에 시스템을 쉽게 배포할 수 있으면서 최소의 비용으로 고객에게 더 낮은 지연 시간과 더 나은 경험을 제공할 수 있습니다. 
 성능 효율성을 달성하는 데 도움이 되는 다음 설계 원칙은 서버리스 아키텍처를 사용하는 것입니다. 
 클라우드 환경에서는 컴퓨팅 활동을 위해 기존 서버를 실행하고 유지 관리할 필요가 없습니다. 
 또한 운영 부담을 없애고 트랜잭션 비용을 낮출 수도 있습니다. 
 또 다른 설계 원칙은 더 자주 실험하는 것입니다. 
 가상화를 통해 테스트를 빠르게 수행하여 효율성을 높일 수 있습니다. 
 마지막으로, 기계적 동조라는 원칙이 있습니다. 
 이 원칙은 달성하려는 목표에 가장 부합하는 기술 접근 방식을 사용할 것을 제안합니다. 
 다음 핵심 요소는 전체 수명 주기에 걸쳐 지속적으로 시스템을 개선 및 개량하는 프로세스가 포함된 비용 최적화 요소입니다. 
 이 핵심 요소는 비용 효율적인 시스템을 구축 및 운영하고 투자수익률을 극대화할 수 있다는 아이디어를 포함합니다. 
 비용 최적화 핵심 요소는 비용 효율적인 리소스, 수요와 공급의 균형, 지출 인식 및 시간에 따른 최적화라는 네 가지 영역으로 구성됩니다. 
 완전하게 비용 최적화된 시스템은 기능 요구 사항을 충족하는 한편, 가장 낮은 가격대에서 최상의 성과를 달성하기 위해 모든 리소스를 사용합니다. 
 시스템이 적절한 서비스, 리소스 및 구성을 사용하고 있는지 확인하는 것이 비용 절감의 주요 요소 중 하나입니다. 
 사용자는 프로비저닝, 크기 조정, 구매 옵션 및 기타 특성과 같은 세부 정보에 집중하여 필요에 맞는 최적의 아키텍처를 보유하고 있는지 확인하고자 합니다. 
 비용 최적화의 또 다른 요소는 수요와 공급의 균형입니다. 
 AWS 클라우드를 사용하면 클라우드 아키텍처의 탄력성을 활용하여 변화하는 수요를 충족할 수 있습니다. 
 자동 조정을 하고 다른 서비스에서 알림을 받아 수요 변화로 인한 공급을 조정할 수 있습니다. 
 그 다음으로, 지출 인식이 있습니다. 
 비즈니스에서 발생하는 지출 및 비용 요인을 완전히 인식하고 인지하는 것이 매우 중요합니다. 
 따라서 현재 비용을 확인하고, 이해하고, 분석하고, 미래 비용을 예측하고, 그에 따른 계획을 세워야만 클라우드에서 아키텍처의 비용 최적화가 실현됩니다. 
 마지막으로, AWS에서는 시간에 따라 최적화할 수 있습니다. 
 모든 도구와 서로 다른 접근 방식을 사용하면 AWS 플랫폼에서 수집한 데이터를 바탕으로 아키텍처를 측정, 모니터링 및 개선할 수 있습니다. 
 비용 최적화 설계 원칙에 대해 살펴보겠습니다. 
 우리의 첫 번째 원칙은 소비 모델을 도입하는 것입니다. 
 소비 모델을 통해 사용하는 컴퓨팅 리소스에 대해서만 비용을 지불하고 비즈니스 요구 사항에 따라 증감할 수 있습니다. 
 다음 원칙은 전반적인 효율성을 측정하는 것입니다. 
 시스템의 비즈니스 생산량과 이를 제공하는 것과 관련된 비용을 측정한 다음 이 측정 결과를 통해 생산량 증가와 비용 절감으로 발생하는 이익을 이해하는 것이 중요합니다. 
 다음 설계 원칙은 데이터 센터 운영에 필요한 비용 지출을 중단하는 것을 의미합니다. 
 AWS를 사용하면 서버를 랙에 설치하고, 쌓아 올리고, 서버에 전원을 공급하는 등의 과중한 업무를 수행할 필요가 없습니다. 
 AWS가 대신 그러한 작업을 수행하므로, IT 인프라 대신 고객과 비즈니스 프로젝트에 완전히 집중할 수 있습니다. 
 다음 설계 원칙은 지출을 분석하고 부과하는 것입니다. 
 클라우드는 보다 손쉽게 시스템의 사용 및 비용을 정확하게 파악할 수 있게 해 줍니다. 
 고객은 투자수익률을 측정할 수 있으며, 이는 리소스를 최적화하고 비용을 절감할 수 있는 기회를 제공합니다. 
 마지막으로, 고객은 관리형 서비스를 사용하여 소유 비용을 줄이는 것이 좋습니다. 
 클라우드는 많은 관리형 서비스를 제공하여 이메일 전송 또는 데이터베이스 관리와 같은 작업을 위해 서버를 유지 관리하는 데 따른 운영 부담을 없애 줍니다. 
 모두 클라우드 규모로 운영되므로, 트랜잭션별 또는 서비스별 비용을 더 저렴하게 제공할 수 있습니다. 
 다음 핵심 요소는 운영 우수성입니다. 
 운영 우수성은 지속적으로 프로세스와 절차를 개선하여 비즈니스 가치를 제공하기 위해 시스템을 실행하고 모니터링하는 데 중점을 둡니다. 
 운영 우수성의 핵심 아이디어 중 일부는 변경 관리 및 자동화, 이벤트 응답, 일일 작업을 성공적으로 관리하기 위한 표준 정의를 포함합니다. 
 곧 공개될 백서에 운영 우수성 핵심 요소에 관한 추가 정보가 포함될 예정입니다. 
 이제 오늘 논의한 사항에 대해 살펴보겠습니다. 
 AWS Well Architected 프레임워크는 고객이 고유의 아키텍처를 평가 및 개선하고 설계에 대한 의사결정이 비즈니스에 미치는 영향을 더 확실히 파악할 수 있도록 돕기 위해 개발되었습니다. 
 지금까지 보안, 안정성, 성능 효율성, 비용 최적화 및 운영 우수성과 같은 AWS Well Architected 프레임워크를 구성하는 핵심 요소에 대해 알아보았습니다. 
 이 프레임워크에 대한 자세한 정보와 전략은 aws.amazon.com에서 확인할 수 있습니다. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox였습니다. 
 
 - 내결함성 및 고가용성
 안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox입니다. 
 이 동영상에서는 내결함성과 고가용성 아키텍처에 대해 살펴보겠습니다. 
 먼저, 내결함성과 고가용성의 의미에 대해 이야기해 보겠습니다. 
 내결함성이란 시스템의 일부 구성 요소에 장애가 발생해도 시스템이 계속 작동할 수 있는 기능을 의미합니다. 
 애플리케이션 구성 요소의 내장된 중복성이라고 할 수 있습니다. 
 그리고 전체 시스템에 대한 개념인 고가용성이 있습니다. 
 이 시스템의 목표는 시스템이 항상 작동하고 액세스 가능한 상태를 유지하며, 사용자의 개입 없이 중단 시간을 가능한 최소화하는 것입니다. 
 사이트를 단 1분 동안 사용할 수 없는 경우에도 비즈니스가 중대한 손상을 입을 수 있습니다. 
 하지만 Amazon Web Services는 이렇게 필요한 시간을 지원하는 도구를 제공합니다. 
 AWS 플랫폼은 사용자가 내결함성이 있고 가용성이 뛰어난 시스템 및 아키텍처를 이상적으로 구축할 수 있도록 해 줍니다. 
 AWS는 사용자가 최소한의 개입 및 선행 비용 투자로 이 시스템을 구축할 수 있다는 점에서 특별합니다. 
 또한 필요에 따라 사용자 지정할 수도 있습니다. 
  그러면 온프레미스 환경과 AWS의 가용성을 비교해 보겠습니다. 
 전통적으로 로컬 데이터 센터에서 고가용성을 보장하는 것은 비용이 많이 들며, 일반적으로 미션 크리티컬 애플리케이션에서만 보장됩니다. 
 하지만 AWS에서는 선택하는 서버 간에 가용성과 복구 가능성을 확장할 수 있는 옵션을 갖습니다. 
 여러 서버, 각 리전 내의 여러 가용 영역, 여러 리전에서 고가용성을 보장할 수 있으며, 원하는 경우 내결함성 서비스에 액세스할 수 있습니다. 
 AWS가 제공하는 본질적으로 가용성이 높은 서비스 및 적절한 아키텍처와 함께 사용 가능한 서비스를 확인할 수 있습니다. 
 그렇다면 일부 특정 서비스가 고가용성을 보장하는 데 도움을 줄 수 있는 방법을 자세히 알아보겠습니다. 
 다음 항목을 살펴봅니다. 
· 탄력적 로드 밸런서(ELB)
· 탄력적 IP 주소
· Amazon Route 53
· Auto Scaling
· Amazon CloudWatch

먼저 탄력적 로드 밸런서(ELB)가 있습니다. 
 ELB는 수신하는 트래픽, 즉 로드를 인스턴스에 분산하는 서비스입니다. 
 또한 ELB는 관리형 모니터링 서비스인 Amazon CloudWatch에 측정치를 전송할 수 있습니다. 
 이 내용은 이 모듈의 후반부에서 더 자세히 설명하겠습니다. 
 따라서 ELB는 트리거 역할을 할 수 있으며 높은 지연 시간 또는 서버가 과도하게 사용되는 경우에 사용자에게 알릴 수 있습니다. 
 ELB를 사용자 지정할 수도 있습니다. 
 예를 들어, 인스턴스에서 비정상적인 측정치 또는 특정 측정치를 인식하도록 구성할 수 있습니다. 
 퍼블릭 또는 내부 솔루션이 될 수 있습니다. 
 마지막으로, 여러 개의 서로 다른 프로토콜을 사용할 수 있습니다. 
그 다음, 탄력적 IP 주소가 있습니다. 
 탄력적 IP 주소는 애플리케이션에 대해 높은 내결함성을 제공하는 데 유용합니다. 
 탄력적 IP는 동적 클라우드 컴퓨팅에 적합하게 설계된 고정 IP 주소입니다. 
 이 도구를 통해 사용자가 같은 IP 주소를 가진 대체 리소스를 사용할 수 있게 함으로써 인스턴스 또는 소프트웨어의 장애를 숨길 수 있습니다. 
 탄력적 IP 주소를 사용하면 인스턴스에 장애가 발생해도 클라이언트가 여전히 애플리케이션에 액세스할 수 있으므로 고가용성이 보장됩니다. 
  또 다른 서비스는 Amazon Route 53입니다. 
 Amazon Route 53은 AWS에서 제공하는 신뢰할 수 있는 DNS 서비스입니다. 
 이 서비스는 도메인 이름을 IP 주소로 변환하는 데 사용됩니다. 
 Amazon Route 53은 최고 수준의 가용성을 염두에 두고 설계 및 유지 관리됩니다. 
 간단한 출력, 지연 시간 기반 라우팅, 상태 확인 및 DNS 장애 조치 및 지리 위치 라우팅을 지원하기 위해 개발되었습니다. 
 이러한 모든 특성은 고객용 애플리케이션의 가용성을 높입니다. 
Auto Scaling은 지정된 조건에 따라 인스턴스를 시작 또는 종료합니다. 
 이 서비스는 고객 수요의 변화에 따라 조정 및 수정할 수 있는 유연한 시스템을 구축하는 데 도움을 주기 위해 설계되었습니다. 
 Auto Scaling을 사용하면 새 리소스를 생성하는 데 대한 제한을 방지할 수 있습니다. 
 대신, 새로운 온디맨드 리소스를 만들거나 예약된 프로비저닝을 사용할 수 있습니다. 
 이를 통해 로드와 관계없이 언제든 애플리케이션과 시스템을 사용할 수 있습니다. 
 또한 정책에 따라 프로비저닝을 확장 또는 축소할 수 있다는 점을 염두에 두어야 합니다. 
 마지막으로, Amazon CloudWatch가 있습니다. 
 Amazon CloudWatch는 분산된 통계 수집 시스템입니다. 
 애플리케이션의 지표를 수집하고 추적합니다. 
 또 다른 특징은 자체 사용자 지정 지표를 생성하고 사용할 수 있다는 것입니다. 
 지연 시간이 높거나 설정한 임계값을 초과한 지표가 있으면 CloudWatch가 자동으로 조정하여 아키텍처의 고가용성을 보장할 수 있습니다. 
 이제 몇 가지 내결함성 도구를 살펴보겠습니다. 
 먼저 내결함성 애플리케이션의 핵심 요소로 사용될 수 있는 Amazon Simple Queue Service(Amazon SQS)가 있습니다. 
 이는 매우 안정적인 분산 메시징 시스템입니다. 
 Amazon SQS는 대기열을 항상 사용할 수 있도록 도와줍니다. 
 그리고 높은 내구성과 내결함성 데이터 스토리지를 제공하는 Amazon Simple Storage Service(Amazon S3)가 있습니다. 
 간편하게 사용할 수 있고 실제 사용하는 스토리지에 대해서만 비용을 지불하는 웹 서비스입니다. 
 Amazon S3는 한 리전의 여러 시설에 걸쳐 서로 다른 여러 디바이스에 모든 데이터를 중복 저장하므로 장애가 발생하는 경우에도 모든 정보에 계속 액세스할 수 있습니다. 
 Amazon SimpleDB는 내결함성과 내구성을 갖춘 체계적인 데이터 스토리지 솔루션입니다. 
 SimpleDB를 사용하면 확장 가능한 서비스를 최대한 활용할 수 있으며 고가용성과 내결함성을 위한 자연스러운 설계를 통해 단일 장애 지점을 방지할 수 있습니다. 
 그런 다음 관계형 데이터베이스와 관련하여 사용할 수 있는 또 다른 웹 서비스 도구인 Amazon Relational Database Service(Amazon RDS)가 있습니다. 
 중요한 데이터베이스의 안정성을 향상시키는 몇 가지 기능을 제공함으로써 고가용성 및 내결함성을 제공합니다. 
 이러한 기능 중 일부에는 자동 백업, 스냅샷 및 다중 가용 영역 배포를 포함됩니다. 
 이러한 모든 서비스는 고가용성 및 내결함성 시스템을 보장할 수 있는 높은 안정성과 내구성을 갖춘 내결함성 도구입니다. 
 내결함성 및 고가용성을 갖춘 아키텍처를 구축하는 것은 그렇게 어렵지 않습니다. 
 AWS 플랫폼을 사용하면 제공되는 서비스 및 도구를 활용하여 애플리케이션 및 시스템의 고가용성과 내결함성을 높일 수 있습니다. 
 고가용성 및 내결함성을 갖춘 서비스 및 아키텍처에 대한 자세한 내용은 <http://aws.amazon.com/ko>에서 확인할 수 있습니다. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox였습니다.
 
 - 웹 호스팅
 안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox입니다. 
 오늘은 웹 호스팅에 대해 간략히 알아보겠습니다. 
 기존 방식의 확장 가능한 웹 호스팅은 비용이 높고 시간이 많이 소요되며 어려운 프로세스일 수 있습니다. 
 하지만 반드시 그런 방식을 사용할 필요는 없습니다. 
 AWS 클라우드의 웹 호스팅은 빠르고 간단하며 쉽고 비용이 적게 듭니다. 
 컴퓨팅, 스토리지, 데이터베이스 및 애플리케이션 서비스 같은 종합적인 AWS 도구 및 서비스 세트를 사용하여 쉽게 배포하고 유지 관리할 수 있습니다. 
 소셜 미디어 앱을 개발하는 경우 호스팅할 수 있는 웹 애플리케이션에는 회사 웹 사이트, 콘텐츠 관리 시스템 또는 내부 SharePoint 사이트가 포함됩니다. 
웹 호스팅 시 발생할 수 있는 몇 가지 공통된 문제와 난관이 있습니다. 
 그중 일부는 인프라, 아키텍처 문제 및 최종 비용과 관련이 있을 수 있습니다. 
 하지만 AWS는 이러한 공통된 문제에 대한 솔루션을 제공할 수 있습니다. 
 피크 및 비용 효율적인 방식으로 이러한 피크를 처리하는 방법에 대한 공통의 딜레마가 나타나곤 합니다. 
 피크 및 대규모 고객 수요라는 큰 문제를 가질 수 있는데, 이는 여전히 중대한 문제가 될 수 있습니다. 
 기존의 방식으로 이러한 피크 용량을 처리하기 위해서는 여러 서버를 프로비저닝해야 할 것입니다. 
 이렇게 되면 일부 피크 시간 동안 리소스에 많은 시간과 돈을 소비하게 될 수 있습니다. 
 하지만 AWS는 추가 서버의 온디맨드 프로비저닝을 활용할 수 있으므로 고객은 용량과 비용을 실제 트래픽 패턴에 맞게 조정할 수 있습니다. 
 예를 들어, 웹 애플리케이션이 오전에는 느리지만 오후 5시 전후에 피크에 도달하면 트래픽 추이를 기반으로 해당 시간에 필요한 리소스를 프로비저닝할 수 있습니다. 
 이로 인해 용량의 낭비가 제한되며 비용이 50% 이상 줄어들 수 있습니다. 
이제 웹 호스팅 아키텍처는 비용 효율적일 뿐 아니라 확장 가능한 솔루션이 될 수 있습니다. 
 트래픽이 급증할 때에는 실행이 필요한 인스턴스가 있는지 확인하는 것이 매우 중요합니다. 
 이렇게 트래픽이 예기치 않게 급증하는 경우 적절한 시간에 대응할 수 없는 기존의 아키텍처를 피할 수 있습니다. 
 AWS를 사용하면 새로운 호스트를 시작하고 몇 분 안에 활용하도록 준비하며 불필요한 경우 축소할 수 있습니다. 
 리소스 테스트와 관련된 또 다른 공통된 문제도 방지할 수 있습니다. 
 사전 프로덕션, 베타 또는 테스트 환경을 개발할 때에는 많은 비용과 시간이 소요될 수 있습니다. 
 또한 리소스를 사용하지 않을 경우 많은 대금을 낭비하게 될 수 있습니다. 
 대신 AWS 클라우드를 사용하면 필요할 때 테스팅 집합을 프로비저닝할 수 있습니다. 
 서비스 중단이 거의 없거나 전혀 없는 준비 환경을 빠르게 개발할 수 있습니다. 
 AWS 클라우드의 또 다른 장점은 로드 테스트 중에 사용자 트래픽을 시뮬레이션할 수 있다는 것입니다. 
따라서 이와 같습니다. 
 기존 웹 호스팅 아키텍처를 AWS 클라우드로 전송하기로 결정했다고 가정해 봅니다. 
 전송 시 유용할 수 있는 일부 AWS 제품을 살펴보겠습니다. 
 웹 호스팅에 대해 고려할 수 있는 서비스는 다음과 같습니다. 
· Amazon Virtual Private Cloud(Amazon VPC)
· Amazon Route 53
· Amazon CloudFront
· Elastic Load Balancing(ELB)
· 방화벽/AWS Shield
· Auto Scaling
· 앱 서버/Elastic Compute Cloud(Amazon EC2) 인스턴스 
· Amazon ElastiCache
· Amazon Relational Database Services(Amazon RDS)
· Amazon Dynamo DB

각 서비스의 특성에 대한 자세한 내용은 제품 아래의 AWS 홈 페이지에서 확인할 수 있습니다. 
현재 AWS 클라우드를 사용할 때 염두에 둘 주요 고려 사항이 많이 있습니다. 
 이제 클라우드에서 호스팅할 때 이러한 주요 아키텍처 변화에 대해 살펴보겠습니다. 
· 먼저, 물리적 네트워크 어플라이언스가 제거됩니다. 
 이에 더해 물리적 디바이스에 AWS 애플리케이션용 방화벽, 라우터 및 로드 밸런서를 더 이상 가질 수 없으며, 대신 소프트웨어 솔루션으로 교체해야 합니다. 
· 그 다음, 어디에나 방화벽이 있어야 합니다. 
 AWS는 더 안전한 모델을 적용하므로 모든 호스트가 차단되어 있는지 확인합니다. 
 특정 트래픽을 허용하거나 거부하는 보안 그룹을 만들 수 있지만, 해당 정책을 적용해야 합니다. 
 · 그런 다음 여러 데이터 센터의 가용성을 고려해 보는 것이 좋습니다. 
 가용 영역 및 AWS 리전을 통해 이러한 위치에 애플리케이션을 쉽게 배포하여 높은 가용성과 안정성을 보장할 수 있습니다. 
 · 고려해야 할 다음 아이디어는 가장 중요한 것일 수 있는데, 바로 호스트와 관련된 것입니다. 
 AWS를 사용하면 호스트는 임시적이고 동적인 것으로 간주됩니다. 
 오늘 모듈에서는 웹 호스팅 및 AWS 클라우드가 비용 효율적이고 확장 가능한 온디맨드 솔루션을 지원할 수 있는 방법에 대해 간략히 알아보았습니다. 
 또한 웹 호스팅 아키텍처를 지원할 수 있는 AWS 서비스에 대해 알아보았습니다. 
 마지막으로, AWS 웹 호스팅과 관련한 주요 고려 사항에 대해서도 알아보았습니다. 
 웹 호스팅에 대한 자세한 내용은 <http://aws.amazon.com/ko>에서 확인할 수 있습니다. 
 또한 다음의 URL에서 AWS 클라우드의 웹 애플리케이션 호스팅과 관련된 백서 같은 추가 리소스도 검토할 수 있습니다: <https://aws.amazon.com/whitepapers/web-application-hosting-best-practices/>. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox였습니다. 

 

 


 
 - 요금 기본 정보·
 안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Jody Soeiro de Faria입니다. 
 오늘은 AWS 요금 기본 정보에 대해 알아보겠습니다. 
 AWS는 다양한 클라우드 컴퓨팅 서비스를 제공합니다. 
 각 서비스에서 고객은 정확히 실제로 사용한 리소스 양에 대해 비용을 지불합니다. 
 이러한 유틸리티 스타일 가격 결정에 포함되는 항목은 다음과 같습니다. 
· 종량 과금제
· 예약하는 경우 지불 비용 감소
· 더 많이 사용할수록 단위당 더 적은 비용 지불
· AWS 규모가 커짐에 따라 더 적은 비용 지불

이러한 요금의 핵심 개념에 대해 좀 더 자세히 살펴보겠습니다. 
 데이터 센터 구축 사업을 하는 경우를 제외하고는 아마 지금까지 데이터 센터 구축에 너무 많은 시간과 비용을 소비했을 것입니다. 
 AWS에서는 서버나 인프라 구매 또는 시설 임대를 비롯하여 고가의 인프라 구축에 소중한 리소스를 쏟아부을 필요가 없습니다. 
 AWS에서는 대규모 초기 비용을 저렴한 가변 비용으로 대체할 수 있고 필요한 기간 동안 사용한 만큼만 비용을 지불하면 됩니다. 
 모든 AWS 서비스는 온디맨드로 제공되며, 장기 계약을 맺지 않아도 되고, 복잡한 라이선스에 의존할 필요가 없습니다. 
사용한 만큼 지불하는 종량 과금제를 통해 예산을 과도하게 할당하지 않고도 변화하는 비즈니스 요구에 손쉽게 대응하고. 
변화에 대한 응답성을 개선할 수 있습니다. 
 종량 과금제 모델에서는 예측치가 아닌 정확한 수요에 따라 비즈니스에 대응할 수 있으므로 위험이나 초과 프로비저닝 또는 누락되는 용량을 줄일 수 있습니다. 
필요한 만큼만 서비스 요금을 지불함으로써 혁신 및 발명에 집중할 수 있으므로 조달 복잡성을 줄이고 비즈니스에 완전한 탄력성을 부여할 수 있습니다. 
Amazon EC2 및 Amazon RDS와 같은 특정 서비스의 경우, 예약 용량에 투자할 수 있습니다. 
 예약 인스턴스의 경우 동일한 온디맨드 용량과 비교하여 최대 75%까지 절감할 수 있습니다. 
 예약 인스턴스는 3가지 옵션인, 전체 선결제 금액(AURI), 부분 선결제 금액(PURI), 선결제 금액 없음(NURI)으로 제공됩니다. 
예약 인스턴스를 구입할 때 선결제 금액이 클수록 할인도 커집니다. 
 절감액을 최대화하려면 전체를 선결제 금액으로 지불하고 가장 큰 폭의 할인을 받으면 됩니다. 
 부분 선결제 금액 RI는 할인폭은 낮지만 미리 지불하는 금액이 적습니다. 
 마지막으로, 선결제 금액을 내지 않고 작은 폭의 할인을 받지만, 자금을 확보하여 다른 프로젝트에 사용하도록 선택할 수 있습니다. 
 예약 용량을 사용함으로써 조직은 위험을 최소화하고, 예산을 좀 더 예측 가능하게 관리하며, 장기 약정을 요구하는 정책을 준수할 수 있습니다. 
AWS에서는 규모에 따른 할인을 받을 수 있으며 사용량이 늘수록 의미 있는 비용 절감이 실현됩니다. 
 Amazon S3 및 EC2에서 데이터 송신과 같은 서비스의 경우 요금이 계층화되어 있습니다. 
 즉, 사용량이 많을수록 기가바이트당 비용이 저렴해집니다. 
 또한, 데이터 수신 요금은 언제나 무료입니다. 
 따라서 AWS 사용 요구가 증가함에 따라 도입을 확장하면서 비용은 통제할 수 있는 규모의 경제 이점을 활용할 수 있습니다. 
조직이 성장함에 따라 AWS에서는 고객이 비즈니스 요구를 처리하는 데 도움이 되는 서비스를 확보할 수 있도록 옵션을 제공합니다. 
 예를 들어 AWS의 스토리지 서비스 포트폴리오는 데이터 액세스 빈도와 데이터 검색에 필요한 성능에 따라 비용을 줄일 수 있는 옵션을 제공합니다. 
 비용 절감을 최적화하기 위해서는 성능, 보안 및 안정성을 유지하면서 비용을 절감할 수 있는 적절한 스토리지 솔루션의 조합을 선택해야 합니다. 
AWS는 지속적으로 데이터 센터 하드웨어 비용을 줄이고, 운영 효율성을 향상하며, 전력 소비를 줄이고, 비즈니스 운영 비용을 낮추는 데 중점을 두고 있습니다. 
 이러한 최적화 및 내실 있게 성장하는 AWS의 규모의 경제로 인해 얻은 절약 효과를 요금 인하의 형태로 고객에게 돌려드립니다. 
 2006년 이래 AWS는 44번 요금을 인하했습니다. 
AWS는 모든 고객에게 서로 다른 요구 사항이 있다는 점을 알고 있습니다. 
 프로젝트에 대해 적합한 AWS의 요금 모델이 없는 경우 고유한 요구 사항이 있는 대용량 프로젝트에 대해 요금을 사용자 지정할 수 있습니다. 
 신규 AWS 고객이 클라우드 사용을 시작하는 데 도움이 될 수 있도록 AWS에서 프리 티어를 제공하고 있습니다. 
 신규 AWS 고객은 프리 티어를 사용하여 Amazon EC2 마이크로 인스턴스를 1년 동안 무료로 실행할 수 있을 뿐 아니라 Amazon S3, Amazon Elastic Block Store(Amazon EBS), Elastic Load Balancing(ELB), AWS 데이터 전송 및 기타 AWS 서비스에서 프리 티어를 활용할 수 있습니다. 
AWS에서는 추가 비용 없이 다양한 서비스를 제공합니다. 
· Amazon VPC: Amazon Virtual Private Cloud는 고객이 정의하는 가상 네트워크에서 AWS 리소스를 시작할 수 있도록 AWS 클라우드에서 로컬로 격리된 공간을 프로비저닝합니다. 
· AWS Elastic Beanstalk는 AWS 클라우드에서 애플리케이션을 간편하고 신속하게 배포하고 관리할 수 있는 방법입니다. 
· AWS CloudFormation은 개발자 및 시스템 관리자가 관련 AWS 리소스 모음을 쉽게 생성하고 순서에 따라 예측 가능한 방식으로 프로비저닝하도록 지원합니다. 
· AWS Identity and Access Management(IAM)는 AWS 서비스와 리소스에 대한 사용자 액세스를 제어합니다. 
· Auto Scaling은 정의한 조건에 따라 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스를 자동으로 추가하거나 제거합니다. 
 Auto Scaling을 사용하면 요청이 급증하는 동안에는 매끄럽게 Amazon EC2 인스턴스의 개수가 늘어 성능을 유지하고, 요청이 감소할 때는 자동으로 인스턴스의 개수가 줄어 비용을 최소화할 수 있습니다. 
· AWS OpsWorks는 모든 형태와 규모의 애플리케이션을 간편하게 배포하고 운영할 수 있도록 해 주는 애플리케이션 관리 서비스입니다. 
또한 통합 결제를 사용하여 모든 계정을 통합하고 계층화 이점을 얻을 수 있습니다. 
AWS가 제공하는 서비스의 수와 유형은 크게 증가했지만 요금에 대한 철학은 변하지 않았습니다. 
 매월 말에, 사용한 만큼만 비용을 지불하고 언제든지 제품 사용을 시작하거나 중단할 수 있습니다. 
 장기 계약은 필요 없습니다. 
 AWS 웹 사이트에 각 서비스에 대한 요금 정보가 제공됩니다(<http://aws.amazon.com/pricing/>). 
 각 서비스별로 독립적인 AWS의 요금 전략은 각 프로젝트에 필요한 서비스를 선택하고 사용한 만큼만 비용을 지불할 수 있는 엄청난 유연성을 제공합니다. 
 저는 Amazon Web Services(AWS) 교육 및 자격증 팀의 Jody Soeiro de Faria였습니다.
 
 - 요금내역
 안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Jody Soeiro de Faria입니다. 
 오늘은 AWS 요금의 세부 정보에 대해 알아보겠습니다. 
 AWS 사용 시 지불해야 하는 세 가지 기본 특성은 컴퓨팅, 스토리지 및 데이터 송신입니다. 
 이러한 특성은 사용하는 AWS 제품에 따라 다릅니다. 
 하지만 기본적으로 비용에 가장 큰 영향을 미치는 핵심 특성이기도 합니다. 
데이터 송신에 대해 요금이 청구되지만 인바운드 데이터 전송 또는 동일 리전 내에서 서비스 간의 데이터 전송에 대해서는 청구되지 않습니다. 
 아웃바운드 데이터 전송은 Amazon EC2, Amazon S3, Amazon RDS, Amazon SimpleDB, Amazon SQS, Amazon SNS 및 Amazon VPC 전체에서 집계된 후 아웃바운드 데이터 전송 요금으로 청구됩니다. 
 이 요금은 월별 명세서에 AWS 데이터 송신으로 표시됩니다. 
Amazon Elastic Compute Cloud(Amazon EC2), Amazon Simple Storage Service(Amazon S3), Amazon Elastic Block Store(Amazon EBS), Amazon Relational Database Service(Amazon RDS) 및 Amazon CloudFront 같은 일반적으로 사용되는 AWS 제품의 요금 특징에 대해 자세히 살펴보겠습니다. 
Amazon EC2는 클라우드에서 크기 조정이 가능한 컴퓨팅 파워를 제공하는 웹 서비스입니다. 
 Amazon EC2의 간단한 웹 서비스 인터페이스를 통해 간편하게 필요한 컴퓨팅 파워를 확보하고 구성할 수 있습니다. 
 Amazon의 입증된 컴퓨팅 환경에서 컴퓨팅 리소스에 대한 완전한 제어를 제공합니다. 
 Amazon EC2는 실제 사용한 용량에 대해서만 고객에게 요금을 부과하므로 컴퓨팅 비용이 절약됩니다. 
 Amazon EC2 비용을 추정할 때는 다음을 고려해야 합니다. 
· 시계로 표시되는 서버 시간. 
 리소스는 실행 중일 때 요금이 부과됩니다. 
 예를 들어, Amazon EC2 인스턴스가 시작되는 시간부터 인스턴스가 종료될 때까지 또는 탄력적 IP가 할당된 시간부터 해제될 때까지 시간입니다. 
· 머신 구성. 
 선택하는 Amazon EC2 인스턴스의 물리적 용량을 고려합니다. 
 인스턴스 요금은 AWS 리전, OS, 코어 수 및 메모리에 따라 달라집니다. 
· 머신 구입 유형. 
 온디맨드 인스턴스를 사용하면 필수적인 최소 약정 없이 시간 단위로 컴퓨팅 파워를 구입할 수 있습니다. 
 예약 인스턴스는 예약하고자 하는 모든 인스턴스에 대해 일시불로 결제하거나 선결제 금액이 없는 옵션을 제공하므로 해당 인스턴스의 시간별 사용 요금이 상당히 할인되는 효과를 얻을 수 있습니다. 
 스팟 인스턴스의 경우 미사용 Amazon EC2 용량에 대해 입찰할 수 있습니다. 
 · 인스턴스 수. 
 피크 로드를 처리하기 위해 Amazon EC2 및 Amazon EBS 리소스의 여러 인스턴스를 프로비저닝할 수 있습니다. 
· 로드 밸런싱. 
 탄력적 로드 밸런서는 Amazon EC2 인스턴스 간에 트래픽을 분산할 때 사용할 수 있습니다. 
 탄력적 로드 밸런서가 실행되는 시간과 처리하는 데이터의 양은 월별 비용에 영향을 미칩니다. 
· 세부 모니터링. 
 Amazon CloudWatch를 사용하여 Amazon EC2를 모니터링할 수 있습니다. 
 기본적으로, 기본 모니터링은 추가 비용 없이 활성화되어 있으며, 사용 가능합니다. 
 하지만 고정 월별 요금의 경우 1분에 1회 기록되는 사전 선택된 지표 7개를 포함하는 세부 모니터링을 선택할 수 있습니다. 
 한 달을 채우지 못한 경우 인스턴스당 시간별 요금을 비율로 해서 청구합니다. 
· Auto Scaling. 
 Auto Scaling은 사용자가 정의한 조건에 따라 배포에서 Amazon EC2 인스턴스 수를 자동으로 조정합니다. 
 이 서비스는 Amazon CloudWatch 요금 외의 추가 비용 없이 사용 가능합니다. 
· 탄력적 IP 주소. 
 실행 중인 인스턴스에 연결된 탄력적 IP 주소 한 개는 무료로 사용할 수 있습니다. 
· 운영 체제 및 소프트웨어 패키지. 
 운영 체제 요금은 인스턴스 요금에 포함됩니다. 
 AWS를 사용하면 Microsoft, IBM 및 기타 여러 공급업체와 파트너 관계를 맺고 Amazon EC2 인스턴스에서 실행되는 특정 상용 소프트웨어 패키지(예: Windows의 Microsoft SQL Server)를 쉽게 실행할 수 있습니다. 
 비표준 운영 체제, Oracle 애플리케이션, Microsoft SharePoint 및 Microsoft Exchange와 같은 Windows Server 애플리케이션 등 AWS에서 제공하지 않는 상용 소프트웨어 패키지의 경우 공급업체로부터 라이선스를 획득해야 합니다. 
 또한 Microsoft License Mobility through Software Assurance Program과 같은 특정 공급업체 프로그램을 통해 기존 라이선스를 클라우드로 가져올 수도 있습니다. 
Amazon S3는 인터넷용 스토리지입니다. 
 언제든지 웹상 어디서나 용량과 관계없이 데이터를 저장하고 검색하는 데 사용할 수 있는 단순한 웹 서비스 인터페이스를 제공합니다. 
 Amazon S3 비용을 추정할 때는 다음을 고려해야 합니다. 
· 스토리지 클래스. 
 표준 스토리지는 99.999999999%의 내구성과 99.99%의 가용성을 제공하도록 설계되었습니다. 
 Standard - Infrequent Access(SIA)는 액세스 빈도가 낮은 데이터를 Amazon S3 표준 스토리지보다 약간 낮은 수준의 중복성으로 저장함으로써 비용을 절감할 수 있는 Amazon S3의 스토리지 옵션입니다. 
 Standard - Infrequent Access는 지정된 한 해 동안 Amazon S3와 동일한 99.999999999%의 내구성과 99.99%의 가용성을 제공하도록 설계되었습니다. 
 각 클래스마다 비율이 다르다는 점에 유의해야 합니다. 
· 스토리지. 
 Amazon S3 버킷에 저장되는 객체의 수와 크기 및 스토리지 유형입니다. 
· 요청. 
 요청의 수 및 유형입니다. 
 GET 요청은 PUT 및 COPY 요청과 같은 다른 요청과 다른 비율로 요금이 발생합니다. 
· 데이터 전송. 
 Amazon S3 리전에서 송신된 데이터의 양입니다. 
Amazon EBS는 Amazon EC2 인스턴스에 사용할 수 있는 블록 수준의 스토리지 볼륨을 제공합니다. 
 Amazon EBS 볼륨은 인스턴스 수명과 관계없는 지속되는 오프 인스턴스 스토리지입니다. 
 클라우드의 가상 디스크와 유사합니다. 
 Amazon EBS는 범용(SSD), 프로비저닝된 IOPS(SSD), 마그네틱이라는 세 가지 볼륨 유형을 제공합니다. 
 세 개의 볼륨 유형은 성능 특성과 비용이 각각 다르므로 애플리케이션 요구 사항에 맞는 올바른 스토리지 성능과 요금을 선택할 수 있습니다. 
 Amazon EBS 비용을 추정할 때는 다음을 고려해야 합니다. 
· 볼륨. 
  모든 Amazon EBS 볼륨의 볼륨 스토리지에 대해서는 스토리지 해제 시점까지 매월 프로비저닝하는 용량(GB)을 기준으로 요금이 청구됩니다. 
 · 초당 입출력 작업(IOPS). 
 I/O는 범용 볼륨의 요금에 포함되는 한편 EBS 마그네틱 볼륨의 경우 I/O는 볼륨에 대해 요청을 수행한 수에 따라 청구됩니다. 
 프로비저닝된 IOPS 볼륨의 경우, IOPS에서 프로비저닝한 양에 해당 달에 프로비저닝한 날의 비율을 곱한 만큼의 요금도 청구됩니다. 
 · 스냅샷. 
 Amazon EBS를 통해 데이터의 스냅샷을 Amazon S3로 백업하여 데이터를 안정적으로 복구할 수 있습니다. 
 EBS 스냅샷을 선택하는 경우 추가 비용은 저장된 데이터의 월별 기가바이트당 비용입니다. 
 · 데이터 전송. 
 애플리케이션의 송신된 데이터의 양을 고려합니다. 
 인바운드 데이터 전송은 무료이며 아웃바운드 데이터 전송은 계층화됩니다. 
 Amazon RDS는 클라우드에서 관계형 데이터베이스를 손쉽게 설치, 운영 및 확장할 수 있게 해 주는 웹 서비스입니다. 
 시간 소모적인 데이터베이스 관리 작업을 관리하는 한편, 효율적인 비용으로 크기 조정이 가능한 용량을 제공하므로 애플리케이션과 비즈니스에 좀 더 집중할 수 있습니다. 
 Amazon RDS 비용을 추정할 때는 다음을 고려해야 합니다. 
 · 시계로 표시되는 서버 시간. 
 리소스는 실행 중일 때 요금이 부과됩니다. 
 예를 들어, DB 인스턴스가 시작되는 시간부터 DB 인스턴스가 종료될 때까지 시간입니다. 
 · 데이터베이스 특성. 
 선택한 데이터베이스의 실제 용량은 청구되는 비용에 영향을 줍니다. 
 데이터베이스 특성은 데이터베이스 엔진, 크기 및 메모리 클래스에 따라 달라집니다. 
 · 데이터베이스 구입 유형. 
 온디맨드 DB 인스턴스를 구입할 때 필수적인 최소 약정 없이 데이터베이스 인스턴스에서 실행되는 각 시간당 컴퓨팅 파워에 대해서만 요금을 지불합니다. 
 예약 DB 인스턴스는 1년 또는 3년 약정으로 예약하려는 각 DB 인스턴스에 대해 저렴한 사전 확약금을 일시불로 결제할 수 있습니다. 
 · 데이터베이스 인스턴스 수. 
 Amazon RDS를 사용하면 피크 로드를 처리하기 위해 여러 데이터베이스 인스턴스를 프로비저닝할 수 있습니다. 
 · 프로비저닝된 스토리지. 
 활성 DB 인스턴스에 대해 프로비저닝된 데이터베이스 스토리지의 최대 100%까지는 백업 스토리지에 대한 추가 비용이 없습니다. 
 DB 인스턴스가 종료된 후 백업 스토리지에는 월별 기가바이트당 요금이 청구됩니다. 
 · 추가 스토리지. 
 프로비저닝된 스토리지 용량 외에 백업 스토리지의 양은 월별로 기가바이트당 청구됩니다. 
 · 요청. 
 데이터베이스에 대한 입력 및 출력의 요청 수입니다. 
 · 배포 유형. 
 데이터베이스 인스턴스를 단일 가용 영역(독립 실행형 데이터 센터와 유사) 또는 다중 가용 영역(향상된 데이터 내구성 및 가용성에 대해 보조 데이터 센터와 유사)에 배포할 수 있습니다. 
 스토리지 및 I/O 요금은 배포 대상인 가용 영역 수에 따라 달라집니다. 
 · 데이터 전송. 
 인바운드 데이터 전송은 무료이며 아웃바운드 데이터 전송 비용은 계층화됩니다. 
 애플리케이션의 요구 사항에 따라 예약 Amazon RDS 데이터베이스 인스턴스를 구입하여 Amazon RDS 데이터베이스 인스턴스 비용을 최적화할 수 있습니다. 
 예약 인스턴스를 구입하기 위해 예약하려는 각 인스턴스에 대해 저렴한 금액을 일시불로 결제하여, 해당 인스턴스의 시간당 사용 요금이 상당히 할인되는 효과를 얻을 수 있습니다. 
Amazon CloudFront는 콘텐츠 전송을 위한 웹 서비스입니다. 
 다른 Amazon Web Services와 통합되므로, 낮은 지연 시간과 빠른 데이터 전송 속도로 최종 사용자에게 콘텐츠를 편리하게 배포할 수 있으며, 최소 약정이 필요 없습니다. 
 Amazon CloudFront 비용을 추정할 때는 다음을 고려해야 합니다. 
 · 트래픽 배포. 
 데이터 전송 및 요청 요금은 지리적 리전에 따라 다르며, 요금은 콘텐츠가 제공되는 엣지 로케이션을 기반으로 합니다. 
 · 요청. 
 요청한 수 및 유형과 요청이 발생한 지리적 리전입니다. 
 · 데이터 송신. 
 Amazon CloudFront 엣지 로케이션에서 송신된 데이터의 양입니다. 
 비용을 추정하는 가장 좋은 방법은 각 AWS 서비스의 기본 특성을 살펴보고, 각 특성에 대한 사용량을 추정한 다음, 해당 사용량을 웹 사이트에 게시된 요금에 매핑하는 것입니다. 
 저는 Amazon Web Services(AWS) 교육 및 자격증 팀의 Jody Soeiro de Faria였습니다.
 
 - TCO 계산기
 안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox입니다. 
 이 동영상에서는 AWS 총 소유 비용(TCO) 계산기에 대해 알아보겠습니다. 
 TCO 계산기는 다음과 같은 작업에 도움이 되는 도구입니다. 
· AWS를 사용할 때의 비용 절감을 추정
· 임원 프레젠테이션에 사용할 수 있는 상세 보고서 세트를 제공
· 요구 사항에 가장 잘 맞게 가정 수정
더 자세히 알아보겠습니다. 
 TCO 계산기는 <https://awstcocalculator.com>에 방문해서 시작할 수 있습니다. 
 TCO 계산기에서 사용할 수 있는 옵션을 간단히 살펴보겠습니다. 
 이 탭을 클릭하고 Basic과 Advanced 사이에 전환하면 아래에 VM Usage, Optimize By 및 Host와 관련된 Advanced의 추가 옵션이 표시됩니다. 
 그럼 Basic부터 시작해 보겠습니다. 
 여기서 Currency를 선택한 다음 비교하려는 환경 유형을  On-Premises 또는 Colocation 중에서 선택합니다. 
 그런 다음 비즈니스 요구 사항에 가장 적합한 Region을 선택합니다. 
 Workload Type: General 또는 SharePoint Site를 선택할 수 있습니다. 
 그 다음, 물리적 서버 또는 가상 머신의 비교 중에서 선택합니다. 
 Virtual Machines를 선택해 보겠습니다. 
 이제 Servers 필드로 이동하고 몇 가지 값을 입력해 봅니다. 
 Server Type은 Non DB로 둡니다. 
 그런 다음 Application Name에 입력합니다. 
 이것은 선택 사항이지만 나중에 보고서 사용을 분명하게 하는 데 도움이 될 수 있습니다. 
 이제 VMs가 있습니다. 
 100개가 있고, CPU 코어 2개와 8GB RAM을 갖추고 있다고 가정합니다. 
 그러면 하이퍼바이저 중에 선택하는 옵션이 있지만 Xen을 사용할 것입니다. 
 그리고 Caluclate TCO를 클릭합니다. 
 그러면 계산기는 3년의 시간 프레임에 대해 입력한 값을 볼 때, AWS로 이동하면 42%를 절감할 수 있다고 알려 줍니다. 
 또한 달러 금액의 절감 효과도 제공합니다. 
 아래로 스크롤하면 환경 세부 정보가 표시됩니다. 
 계산기가 입력한 값에 따라 인스턴스 유형을 선택하는 것에 주목합니다. 
 필요한 인스턴스 유형을 파악하는 것은 어려운 작업일 수 있지만, TCO 계산기를 사용하면 입력한 값과 설정을 기반으로 제안을 해 줍니다. 
 이제 상단으로 돌아가서 Change Input을 선택하면 초기 페이지로 이동합니다. 
 Advanced로 변경하여 어떤 옵션이 있는지 살펴보겠습니다. 
 이제 VM 사용과 최적화 방법을 추가하고 마지막으로 호스트를 추가할 수 있습니다. 
 최적화 방법에 대한 명확한 정보가 필요한 경우 매핑 기준을 설명하는 차트가 표시됩니다. 
 여기에는 해당 옵션이 일치하는 방식에 대한 설명이 나와 있습니다. 
 아래로 스크롤합니다. 
 계산기가 비용을 구분하는 차트를 생성한 것을 확인할 수 있습니다. 
 이는 비용 구분 내역을 그래픽으로 표시하는 데 유용한 도구가 될 수 있습니다. 
 마지막으로, 비용 구분 내역, 방법론, 가정 및 FAQ를 포함하는 전체 보고서를 다운로드할 수 있습니다. 
 또 다른 장점은 보고서를 Amazon S3에 저장하고 원하는 경우 다른 사람들과 공유할 수 있다는 것입니다. 
 TCO 계산기는 AWS 클라우드에 애플리케이션을 배포함으로써 실현할 수 있는 잠재적 절감 효과에 대한 지침을 제공하는 도구입니다. 
 이 도구는 대략적인 용도로만 사용되지만 실제로 달성할 수 있는 가치에 대해 공정한 평가를 제공할 수 있다는 점을 기억하세요. 
 좋습니다. 
 오늘 AWS 총 소유 비용(TCO) 계산기에 대해 간단하게 알아보았습니다. 
 앞서 언급했듯이, TCO 계산기는 다음과 같은 작업에 도움이 되는 도구입니다. 
· AWS를 사용할 때의 비용 절감을 추정
· 상세 보고서 세트를 제공 
 · 비즈니스 요구 사항에 가장 잘 맞게 가정 수정
 
 TCO 계산기에 대한 세부 정보 및 추가 리소스를 확인하려면 <http://aws.amazon.com/ko>에 방문하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox였습니다. 
 
 
 - AWS Support Plan 
 안녕하세요. 
 저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox입니다. 
 오늘은 AWS Support와 사용 가능한 Support 플랜에 대해 알아보겠습니다. 
 AWS는 고객의 성공을 지원하는 데 필요한 리소스를 제공하고자 합니다. 
 따라서 새로운 고객이든, 비즈니스 솔루션으로 AWS 서비스와 애플리케이션을 계속 채택하는 고객이든 상관없이 AWS를 통해 놀라운 작업을 수행할 수 있도록 돕고자 합니다. 
 AWS Support는 현재 또는 미래의 계획된 사례를 기반으로 도구 및 전문 지식의 고유한 조합을 제공합니다. 
 이 동영상에서는 AWS Support 및 AWS Support 플랜을 살펴봅니다. 
AWS Support는 고객의 성공을 돕기 위한 완전한 지원과 올바른 리소스를 제공하기 위해 개발되었습니다. 
 AWS를 실험하고 있는 사람들, 프로덕션에서 AWS를 사용하려는 사람들, 그리고 AWS를 비즈니스 크리티컬 리소스로 사용하는 고객을 포함하는 모든 고객을 지원하고자 합니다. 
 AWS Support는 고객의 요구 사항과 목표에 따라 제공되는 지원 유형을 변경할 수 있습니다. 
 고객은 AWS를 통해 확신을 가지고 계획, 배포 및 최적화할 수 있습니다. 
 AWS는 고객에게 지원이 필요한 경우 안내할 수 있는 도구와 리소스를 갖추고 있습니다. 
 사전 지침을 원하는 사용자가 있는 경우 해당 사용자의 1차 연락 담당자로 지정된 기술 계정 관리자가 있습니다. 
 기술 계정 지원 담당자(TAM)는 사용자가 솔루션을 계획, 배포 및 최적화할 때 계속 정보를 얻고 대비할 수 있도록 지침, 아키텍처 검토 및 지속적인 커뮤니케이션을 제공할 수 있습니다. 
 TAM은 고객의 대변자이자 AWS 내 전담 지원 창구입니다. 
 AWS 환경에서 성능과 내결함성을 개선하는 모범 사례를 따르고자 하는 사용자에게는 AWS Trusted Advisor가 있습니다. 
 AWS Trusted Advisor는 사용자 지정 클라우드 전문가와 비슷하지만, 실제로는 월별 지출을 줄이고 생산성을 개선할 수 있는 기회를 확인하는 온라인 리소스입니다. 
 다음으로 계정 지원이 필요한 경우, Support 컨시어지는 결제 및 계정 전문가로서 문제에 대한 빠르고 효율적인 분석과 지원을 제공하여 사용자가 비즈니스에 더 많은 시간을 쏟을 수 있도록 지원합니다. 
 컨시어지는 기술적이지 않은 결제 및 계정 수준의 모든 문의를 처리합니다. 
 이제 Support 플랜 옵션을 알아보겠습니다. 
 AWS는 고객이 확신을 가지고 계획, 배포 및 최적화할 수 있기를 바랍니다. 
 이에 따라 고객을 지원하기 위해 AWS는 도움을 줄 특정 플랜을 개발했습니다. 
 Basic Support 플랜, Developer Support 플랜, Business Support 플랜 및 Enterprise Support 플랜이 있습니다. 
 AWS 홈페이지로 이동하면 Support를 클릭해 봅니다. 
 그러면 AWS Support 페이지로 이동하게 됩니다. 
 여기서 각 플랜을 살펴보고 비교할 수 있습니다. 
 각 플랜을 더 자세히 보고 싶으면 탐색 창에서 해당 플랜을 클릭합니다. 
 그러면 Developer Support 플랜을 살펴보겠습니다. 
 여기에서는 이 플랜이 제공해야 할 사항과 추가 세부 정보 및 리소스에 대한 간략한 소개를 제공합니다. 
 각 플랜에 대해 이러한 모든 정보를 볼 수 있습니다. 
 플랜을 비교하려면 AWS Support 플랜 비교를 클릭합니다. 
 이는 플랜 간의 차이점을 평가하고 고유한 요구 사항에 가장 적합한 리소스를 확인하는 데 유용한 차트입니다. 
 여기에서 확인할 수 있듯이 플랜의 지원 항목과 추가 리소스가 달라집니다. 
 이 차트는 고객이 요구 사항에 가장 적합한 플랜과 필요한 리소스 수준을 결정하고 이해하는 것을 돕기 위해 마련되었습니다. 
좋습니다. 
 이제 마무리 단계에 접어들었습니다. 
 이 동영상에서는 AWS Support 및 고객의 요구 사항에 적합하도록 마련된 다양한 플랜 옵션에 대해 살펴보았습니다. 
 오늘 알아본 플랜은 다음과 같습니다. 
· Basic Support 플랜
· Developer Support 플랜
· Business Support 플랜
· Enterprise Support 플랜  

AWS Support 및 AWS Support 플랜에 대한 세부 정보 및 추가 리소스를 확인하려면 <http://aws.amazon.com/ko>에 방문하세요. 
  저는 Amazon Web Services 교육 및 자격증 팀의 Anna Fox였습니다. 
  

 

 

 


  - 보안그룹 및 NACL
  이제 AWS에서 애플리케이션을 위한 네트워킹을 보호하는 방법에 대해 설명해 보겠습니다. 
 이 경우에는 3티어 애플리케이션으로 단순화합니다. 
 이미 주요 네트워킹 요소들을 모두 추가했습니다. 
 그리고 인터넷 게이트웨이, 가상 프라이빗 게이트웨이 등의 게이트웨이도 갖추었습니다. 
 여러 가용 영역(AZ)에 걸쳐 분산된 서브넷(퍼블릭 및 프라이빗)도 갖추었습니다. 
 올바른 자산에 대해 올바른 서브넷 액세스 권한을 부여하도록 라우팅 테이블을 추가했습니다. 
 또한 보안 그룹에 대해 살펴보았으며 포트, 프로토콜 및 IP 범위에 따라 수신 트래픽을 정의하는 보안 그룹이 모든 인스턴스에 있다는 사실도 알아보았습니다. 
 보안 그룹의 기본 동작은 모든 인바운드 트래픽을 거부하는 것이므로 보안 그룹 간에 수신되는 모든 트래픽을 허용하도록 명시적 규칙을 추가해야 합니다. 
이것이 VPC 내부의 유일한 트래픽 조절 장치는 아닙니다. 
 서브넷은 IP 범위, 포트 및 프로토콜을 기반으로 필터링할 수도 있는 개별 서브넷에 적용되는 선택적 네트워크 액세스 통제 목록(NACL)을 가질 수 있습니다. 
 이 목록(NACL)은 불필요한 것으로 느껴지며 실제로도 네트워킹 요구가 많기 때문에 불필요합니다. 
 다만 NACL의 운영 방식은 보안 그룹의 운영 방식과는 다릅니다. 
 NACL은 상태비저장(stateless) 방식으로 운영되는 반면, 보안 그룹은 상태저장(stateful)방식으로 운영됩니다. 
다시 말해, 하나의 인스턴스에서 수신되며 보안 그룹 밖에서 허용되는 모든 패킷은 항상 반송 트래픽이 허용되며 심지어는 반송된 소스 인스턴스에서 통신을 허용하는 인바운드 트래픽에 대한 규칙이 없더라도 그러합니다. 
 반송 트래픽을 기억할 수 있다는 이러한 개념은 NACL에서 트래픽을 분리하는 것이 무엇인지를 나타내는 반면, NACL은 인바운드 역할 집합과 아웃바운드 역할 집합을 하나씩 갖습니다. 
 그리고 각 역할 집합은 왕복 프로세스의 일환으로 평가해야 합니다. 
 이제 한 가지 예를 들어 이것(NACL)이 어떤 방식으로 운영되는지 알아 보겠습니다. 
 이 특정 인스턴스에서 시작하는 하나의 패킷을 갖고 있으며 해당 패킷은 이 특정 인스턴스와 통신하려는 상황을 가정해 봅시다. 
 그렇다면 이 패킷은 인스턴스 1의 보안 그룹, 퍼블릭 서브넷 1의 NACL, 프라이빗 서브넷 1의 NACL 및 인스턴스 2 주변의 보안 그룹을 각각 통과하게 됩니다. 
 평가 규칙은 다음과 같습니다. 
 먼저 첫 번째 인스턴스 주변의 해당 보안 그룹을 종료하려는 패킷으로 시작합니다. 
 기본 규칙 집합은 모든 종료 트래픽을 허용하는 것입니다. 
 다만 이 규칙 집합은 변경되었을 수도 있기 때문에 해당 패킷이 올바르게 승인된 포트 프로토콜과 IP 범위를 표적으로 하는지 확인할 목적으로 패킷 검사가 실시됩니다. 
 본 시나리오에서는 패킷이 허용되기 때문에 해당 패킷은 홈 인스턴스를 종료할 수 있으며, 이 지점에서 퍼블릭 서브넷 1에 대한 서브넷 경계에 도달합니다. 
 여기는 여권 검사대(passport control)입니다. 
 패킷이 이 인스턴스를 종료할 수 있도록 허용됩니까? 지금 안전한 위치로 이동 중인가요? 그 표적을 검사합니다. 
 이것이 승인, 포트, 프로토콜, IP인지 확인합니다. 
 그렇습니다. 
 승인된 것입니다. 
 출국 수속 절차를 모두 통과하면 출국하여 서브넷을 떠날 수 있으며 다음 지역을 여행할 수 있게 되는데 여기서도 여권 검사대를 통과하게 됩니다. 
 이제 프라이빗 서브넷 1로 들어가는 중입니다. 
 명시적으로는 포트, 프로토콜, IP 주소를 나타내는 라인이 있어야 하는데 이것은 승인된 것인가요? 기본 동작들은 모두 허용하지만 또 다시 블록이 존재할 수 있습니다. 
 이 시나리오에서는 블록이 없고 패킷은 여권 검사대를 통과하여 해당 인스턴스에 도달합니다. 
 한 번 더 포트, 프로토콜 및 IP 주소가 필요합니다. 
 이는 상태 저장 검사에 속합니다. 
 다만 이 패킷이 실제로 요청을 받은 것인지 한 번 알아보겠습니다. 
 입장이 허용되었습니까? 명시적 규칙은 ‘모든 트래픽을 거부’하는 것입니다. 
 이것은 패킷이 수신되지 않을 경우, 사용자가 차단되는 여러 원인들 중 가장 가능성이 큰 원인에 해당됩니다. 
 이 규칙은 화이트리스트에 추가해야 합니다. 
 이 시나리오에서 해당 규칙은 화이트리스트에 추가되었습니다. 
 패킷은 인스턴스로 들어가 인스턴스 내에서 필요한 모든 작업을 수행합니다. 
 작업은 완료되고 파티는 끝나며 이제 복귀할 시간입니다. 
 응답 트래픽을 발신할 시간입니다. 
 이 경우, 파티를 떠나고 집 밖으로 나가면 도어맨이 나를 인지합니다. 
 상태 저장 방화벽이군요. 
 이 방화벽은 내가 홈(home)으로 복귀해도 되는지 여부를 확인하는 검사를 수행하지 않습니다. 
 다만 방화벽은 나를 건물 밖으로 내보내면서 “즐거운 하루 보내세요”라고 작별 인사를 건넵니다. 
 건물을 벗어나 서브넷 경계에 도착하면 여권 검사대가 나타납니다. 
 서브넷 경계에서는 사용자가 들어가도 되는지 여부를 신경 쓰지 않으며 반송 트래픽이 허용되는지 여부를 다시 확인하게 됩니다. 
 서브넷 경계는 반송 트래픽이 무엇인지를 인지하지 못합니다. 
 다만 포트, 프로토콜 및 IP만 인지할 뿐입니다. 
 이 경우에는 블록이 없습니다. 
 기본 동작들은 모두 허용합니다. 
 트래픽은 홈 서브넷의 여권 검사대를 떠납니다. 
 다시 한 번 포트, 프로토콜 및 IP 주소가 필요합니다. 
 허용됩니까? 예, 허용됩니다. 
 이것은 상태 비저장에 해당됩니다. 
 메모리는 없습니다. 
 그런 다음, 발신 인스턴스의 보안 그룹에 도착하며 내 홈 도어맨은 내가 맨 처음 문 밖으로 나갈 수 있도록 허용된 사실을 인식했습니다. 
 도어맨은 홈으로 들어오면서 변경된 부분은 없는지 확인하는 검사를 수행하지 않습니다. 
 홈 복귀가 허용되며 해당 패킷은 프로세스를 완료합니다. 
 이 지점에서 그러한 차이들을 관리했습니다. 
 이 때쯤 되면 본 동영상을 시청 중인 수강생들 중 상당수는 이렇게 말할 것 같습니다. 
 “오 이런. . . 
 여권 검사대에서 나의 출입 및 출국 수속 검사가 완료되었기 때문에 내 서브넷 네트워크 액세스 통제 목록(NACL)의 보안 기능들은 더 강력한 기능인 것 같습니다. 
 그러한 보안 기능들만 사용해야겠네요. 
” 이를 머리로 이해하기에 앞서 인스턴스 1에서 인스턴스 3까지 상호 통신이 이루어질 때 이에 포함되는 서브넷 경계는 몇 개인지를 질문해볼 필요가 있습니다. 
 답은 0입니다. 
 동일한 서브넷에 있다면 처리된 NACL은 없는 것입니다. 
 NACL은 오로지 서브넷 경계를 통과하는 중 처리되며 그것(NACL)이 가용 영역(AZ)에 걸쳐 존재하는지 여부는 문제가 되지 않습니다. 
 나는 서브넷 내에 있을 때에는 NACL을 처리하지 않습니다. 
 다만 나는 보안 그룹들을 항상 처리하며 모든 인스턴스는 보안 그룹들을 갖습니다. 
 그래서 규칙 작성 시 기본 동작은 모든 규칙들을 하나의 보안 그룹에 입력하고 NACL을 사용해 지원을 2배로 늘리거나 해당 보안 그룹 수준에서 선언된 동작을 무시하도록 설정해야 합니다. 
 이렇게 하면 Amazon VPC 내부의 자산을 보호하는 데 필요한 여러 가지 컨트롤 중 한 가지를 얻게 됩니다. 
 
 - 보안 그룹
 AWS 내에서 애플리케이션을 보호하는 방법에 대해 계속 설명해 보겠습니다. 
 앞서 우리는 퍼블릭 서브넷과 프라이빗 서브넷을 이용해 VPC를 설정하는 방법을 살펴보았으며, 라우팅 테이블을 사용해 게이트웨이에 대한 액세스를 제어하는 작업에 대해서도 알아보았습니다. 
 이제는 애플리케이션 내에서 개별 인스턴스에 대한 액세스로 이동해보려고 합니다. 
 애플리케이션 인스턴스에 대해서만 통화하고 해당 애플리케이션은 데이터베이스에 대해 통화할 수 있도록 전면 웹 애플리케이션을 포함한 권한을 제어할 방법은 무엇입니까? 이러한 제어는 보안 그룹(security groups)이라 불리는 AWS 엔진을 통해 이루어집니다. 
 VPC 내부의 모든 인스턴스는 이미 그 주위에 보안 그룹을 하나씩 갖고 있습니다. 
 이것은 Amazon EC2 기술의 핵심에 속합니다. 
 보안 그룹은 기본적으로 모든 수신 트래픽을 차단하는 개별 인스턴스 주변의 방화벽으로 간주할 수 있습니다. 
 이는 매우 지루한 인스턴스를 야기합니다. 
 개발자들은 방화벽을 사용하고 트래픽의 특정 소스를 승인하는 명시적 규칙들을 방화벽과 보안 그룹 내부에 작성합니다. 
 소스는 IP 주소, 프로토콜 및 포트로 정의됩니다(IP 범위는 실제로 의미하는 대상에 해당됩니다). 
 내 애플리케이션 서버가 프런트엔드 웹 서버의 트래픽만 허용하고 싶다면 해당 범위, 포트 및 웹 서버 자체의 프로토콜에서 발신되는 트래픽을 허용할 보안 그룹의 구멍을 열기만 하면 됩니다. 
 데이터베이스는 그 주위에 자체 보안 그룹을 갖게 되며 애플리케이션 서버에서 발신된 트래픽만 허용합니다. 
 사용자의 프런트엔드 웹 서버도 하나의 보안 그룹을 가지며, 웹 서버와 통신하기 위해 외부 웹 랜드에서 수신되는 000의 트래픽을 승인할 유일한 서버에 해당됩니다. 
 이를 일컬어 스택 보안 그룹(stacked security groups)이라 합니다. 
 외부에서 발신되는 모든 트래픽은 라우팅 테이블로 인해 그리고 보안 그룹들이 000의 트래픽을 허용하지 않는 이유로 애플리케이션 서버 또는 데이터베이스와 통신할 수 없습니다. 
 이 보안 그룹은 웹 서버의 트래픽 정보만 허용합니다. 
 외부의 어떤 자가 연결할 수 있는 유일한 것은 프런트엔드 웹 서버이며 이는 보안 그룹이 허용하는 유일한 서버이기 때문에 거기서만 애플리케이션에 연결할 수 있으며 애플리케이션에서 데이터베이스로 연결할 수 있습니다. 
 이는 알 수 없는 결함이 발생할 때 하나 또는 둘 이상의 보호 계층을 형성합니다. 
 예를 들어, 어떤 이유로 인해 사용 중인 애플리케이션 개발자 중 한 명이 웹 랜드에서 상황을 지켜보고 있던 악의적 해커가 악용할 수 있는 어떤 결함 내지는 열린 요소를 방치하는 것과 같은 취약성이 프런트엔드 웹 서버에 존재한다면 무슨 일이 벌어질까요? 여기에서 보안 그룹은 포트 443 또는 포트 80을 통해서만 000에서 열리기 때문에 문제의 해커는 바로 이 인스턴스에 연결하여 가상의 결함을 악용하고 해당 인스턴스에 대한 루트 액세스 권한을 확보할 수 있었습니다. 
 실현 가능성이 희박한 이 시나리오에서 문제의 해커는 데이터베이스와 통신하여 데이터베이스에 침입하려는 시도를 하기 위한 액세스 권한을 갖고 있나요? 이 질문에 대한 답은 ‘아니요’입니다. 
 라우팅 테이블이 어떤 패킷의 경로가 존재할 수 있도록 허용하더라도 데이터베이스 주위의 해당 보안 그룹은 웹 서버에서 해당 데이터베이스와 직접 통신하려는 시도를 거부하게 됩니다. 
 이는 간단하게 허용되지는 않습니다. 
 그 대신 해커가 할 수 있는 유일한 일은 애플리케이션 포트를 통해서만 애플리케이션 서버와 통신하는 것입니다. 
 이러한 작업은 웹 애플리케이션 자체와 통신하는 것만으로 매년 완료했을 수도 있습니다. 
 한편 이 해커는 지금 웹 서버에 있기 때문에 해당 운영 체제에 존재하는 Amazon Inspector 또는 그 외 어떤 프로세스에서 누군가 루트에 있음을 인식하고 있으며 예상되는 숫자는 0이고 실제 숫자는 0보다 크며 이 지점에서 인스턴스는 위반 상태에 있음을 자체 보고하든 상관없이 일정한 수준의 작업 보호 기능을 설치했을 가능성이 매우 높습니다. 
 인스턴스는 손상됩니다. 
 인스턴스가 할 수 있는 것은 무엇입니까? 인스턴스는 Amazon S3로 로그를 덤프할 수 있으며, 시스템 관리자들에게 알림을 전송한 후 마지막으로 자체 종료됩니다. 
 인스턴스는 더 이상 존재하지 않으며 악의적 해커는 불과 수초 이내에 이러한 가상의 취약성을 역이용합니다. 
 이것이 바로 계층 내 보안입니다. 
 이러한 보안에서는 모든 개별 요소가 손상될 것을 예상하기 때문에 계층들이 겹겹이 위치하며 각 계층은 공격을 차단할 수 있습니다. 
 지금 어떤 계층을 사용하고 있습니까? 모든 계층을 사용하고 있습니다. 
 보안 그룹들은 모든 인스턴스 주위에 존재하는데 이는 개발자들이 하게 될 첫 번째 작업이 모든 포트, 모든 프로토콜 및 모든 IP 주소에 대하여 보안 그룹을 여는 것임을 의미합니다. 
 저는 이러한 작업이 이루어지는 것을 목격했습니다. 
 그것은 보안 그룹의 모든 목적을 무효화합니다. 
 이는 집 한 채를 장만하는 것과 같은 셈이 되는데, 여러분이 완료한 첫 번째 작업은 경첩에 달린 문을 뜯어낸 후 “수많은 쿠키들아! 들어와”라는 메시지가 적힌 큰 간판 1개를 부착하는 것이었습니다. 
 모든 쿠키가 해당 지점에서 도난당하는 것은 그 누구의 잘못도 아닙니다. 
 충분한 보안 점검의 일환에서 보안 관리자들은 보안 그룹을 정기적으로 검사하여 퍼블릭 인스턴스만 보안 그룹에서 000, 열린 포트를 갖고 있으며 내부 프라이빗 보안 그룹이 단지 예상되는 인스턴스로부터 트래픽을 허용하도록 적절하게 계층화되어 있는지 확인하기 위해 보안 그룹들을 수시로 점검해야 합니다. 
 보안 그룹들은 애플리케이션 내 가장 소중한 자산들을 보호하는 데 도움을 주기 위해 사용되는 또 다른 키 도구가 됩니다. 

 

 


 
 - 공동 책임 모델
 여러분이 사용하는 애플리케이션이 AWS에서 실행되고 있을 때, 어떤 지점에서 누군가는 애플리케이션을 보호할 궁극적 책임을 담당해야 합니다. 
 그 책임은 ‘A) 고객’ 여러분에게 있을까요? 아니면 ‘B) AWS’에 있을까요? 정답은 ‘C) 고객과 AWS 모두 해당’입니다. 
 고객 여러분과 AWS는 모두 전체 애플리케이션을 보호하기 위해 함께 협력해야 합니다. 
 좋은 보안 관리자라면 여러분이 동일한 개체를 보호하는 2개의 다른 업체를 보유할 수 없으며, 실제로 보안(security)을 갖추고 있지는 않고 다만 제안(suggestions)이 있다는 사실을 여러분에게 알려줄 것입니다. 
 이에 동의하면 AWS에서 우리는 공동 책임 모델(Shared Responsibility Model)이라 불리는 모델을 갖습니다. 
 우리는 애플리케이션 스택을 전체적으로 관찰하며 이를 여러 개의 부분으로 분할합니다. 
 그러한 부분들 중 일부에 대해서는 AWS가 100% 책임을 집니다. 
 나머지 부분들에 대해서는 고객 여러분이 100% 책임을 집니다. 
 그러한 분할의 위치를 파악하는 것은 고객 여러분과 AWS의 상호 작용 중 일부에 속합니다. 
 이제 스택이 어떻게 작동하는지를 단순한 관점으로 살펴보겠습니다. 
 먼저 물리적 계층에서 스택의 맨 아랫쪽부터 시작합니다. 
 이것은 철과 콘크리트입니다. 
 이것은 철조망 울타리입니다. 
 어떤 이는 주차장을 관리해야 합니다. 
 어떤 이는 물리적 디바이스를 관리해야 합니다. 
 이것이 AWS입니다. 
 저희 AWS는 데이터 센터 둘러보기를 제공하지 않습니다. 
 또한 물리적 측면을 보호하는 방법의 일환에서 어떠한 유형의 액세스 권한도 부여하지 않습니다. 
 물리적 계층의 맨 위에서 우리는 AWS 시스템의 보안을 허용하도록 설계된 독점 네트워킹 프로토콜인 AWS 네트워크를 실행하기 때문에 가상 프라이빗 클라우드(Amazon VPC) 같은 요소들은 규모와 속도에 따라 작동할 수 있으며 모든 요소들은 트래픽을 보호하도록 설계되어 있습니다. 
 AWS는 트래픽을 어떻게 보호할까요? 이것은 AWS 보안의 일부로서 알려줄 수 없습니다. 
 만약 이 점에 대해 언급한다면 많은 부분을 알려주지 않는 셈이 됩니다. 
 저는 이러한 점을 이해하고 있습니다. 
 AWS에서 하는 일을 여러분에게 정확히 알려줄 수는 없지만 감사 기관에 대해서는 이를 매우 구체적으로 설명했습니다. 
 AWS.amazon.com/compliance를 방문하면 네트워크 스택 또는 물리적 요소를 이미 검토했거나 이들을 정기적으로 검토하는 수많은 타사 감사 활동을 볼 수 있습니다. 
 이 모든 감사에서는 네트워크가 안전하다고 할 때 Amazon이 아닌 누군가 - 감사가 어떻게 완료되었는지를 설명하는 신뢰할만한 자 - 가 검토한 매우 엄밀한 정보를 제공합니다. 
 네트워크의 맨 위에는 하이퍼바이저(hypervisor)가 있습니다. 
 지금은 AWS 하이퍼바이저가 Xen 기반의 하이퍼바이저를 사용한다는 사실을 밝히고 있습니다. 
 그렇지만 보안을 구현하고 확장성을 제공하며 어떤 데이터의 유출에 대해서도 걱정하지 않고 수백만 명의 동시 고객들을 실행할 수 있도록 하이퍼바이저를 특별히 많이 변경했습니다. 
 하이퍼바이저의 맨 위에서 EC2를 실행할 경우, Amazon Elastic Compute Cloud(Amazon EC2)의 하이퍼바이저로부터 게스트 운영 체제를 분리하는 마법의 구분선이 존재하며 이 경우에는 해당 운영 체제를 선택합니다. 
 사용자는 각자의 기호에 따라 Linux 또는 Windows를 선택하며 어떤 애플리케이션이 실행되는지를 선택합니다. 
 이 구분선 위에서 AWS는 0의 가시성(zero visibility)을 갖습니다. 
 운영 체제에서 어떤 일이 발생하는지를 확인하기 위해 할 수 있는 일은 없습니다. 
 AWS는 여러분이 사용하는 애플리케이션에 대해서는 아는 바가 없기 때문에 사용자 데이터에 대해서도 알지 못합니다. 
 이러한 데이터는 액세스 키 비밀 키 조합과 암호화 방법을 통해 전적으로 보호되는 콘텐츠에 해당됩니다. 
 원한다면 그 내용을 읽을 수도 없습니다. 
 사실, 클라우드에 대한 근거없는 통념 중 한 가지는 AWS가 예전에 과도한 마케팅 활동을 벌였던 수많은 이메일 서비스 업체들처럼 사용자의 정보를 물색하고 있다는 것입니다. 
 물론 Amazon.com에서는 그러한 정보를 좋아할만한 일부 마케팅 관리자가 있겠지만 그러한 정보에 접근할 권한이 있는 관리자라도 실제로는 AWS의 아키텍처 설계 방식 때문에 해당 정보에 접근할 수 없습니다. 
 해당 정보는 읽는 것 자체가 불가능합니다. 
 따라서 AWS는 구분선 아래에 있는 모든 것에 대해 100% 책임이 있으며, 구분선 위에 있는 모든 것에 대해서는 고객 여러분이 100% 책임을 지게 됩니다. 
 여러분이 각자의 역할을 담당하면 AWS는 자사의 역할을 수행합니다. 
 보안 애플리케이션 환경은 바로 이러한 과정을 통해 구현됩니다. 
 
 - IAM 사용자/그룹/역할
 AWS에서 권한이 작동하는 방식을 이해한다면 곧 IAM(Identity and Access Management)이 내부에서 어떻게 작동하는지를 이해하는 셈이 됩니다. 
 IAM에서는 영어가 문제가 됩니다. 
 명백한 것들을 의미하는 단어들이 있긴 하지만 그러한 단어들에 숨겨진 의미를 살펴보면 그러한 단어들을 사용하는 사람과 문맥에 따라 실제로는 완전히 다른 것을 의미할 수 있습니다. 
 사용자(user), 그룹(group) 및 역할(role)과 같은 단어들 즉, 매우 친숙한 느낌을 주면서 각 단어가 의미하는 것이라고 생각되는 것을 어느 정도 의미하는 단어들, 다만 IAM의 관점에서 볼 때 매우 특정한 의미를 담을 수 있는 단어들부터 차근차근 살펴보겠습니다. 
 먼저 사용자(user)의 개념부터 알아보겠습니다. 
 사용자란 무엇입니까? AWS IAM의 경우, 여기서 우리가 논하는 것(사용자)은 이름이 지정된 영구적 운영자를 가리킵니다. 
 그것은 인간일 수도 있고 기계(컴퓨터)일 수도 있습니다. 
 사용자가 무엇인지는 중요하지 않습니다. 
 사용자란 그 개념상 내 자격 증명이 영구적이며 이름과 암호, 액세스 키, 비밀 키 조합 등 무엇이든 간에 강제 순환이 있을 때까지 내 자격 증명이 이름이 지정된 사용자를 포함한 상태로 유지된다는 것을 의미합니다. 
 이것은 시스템 내에서 이름이 지정된 사용자들에 대한 내 인증 방법(authentication method)입니다. 
 그렇다면 그룹(group)이란 무엇입니까? 이 시점에서 이 그룹이란 용어는 분명한 의미를 담고 있어야 합니다. 
 그룹(group)이란 사용자의 모음을 의미합니다. 
 그룹은 Blaine을 포함한 많은 사용자들을 포함할 수 있으며 사용자들은 많은 그룹에 속할 수 있습니다. 
 이 개념이 이해하기가 어렵다고 말할 분도 계시겠군요. 
 역할(role)이란 무엇입니까? AWS IAM에서 역할은 사용자의 권한이 아니기 때문에 여기서는 (역할을) IAM으로 이해하는 것이 중요합니다. 
 역할(role)이란 인증 방법을 의미합니다. 
 사용자(user)란 운영자를 의미하며 인간이거나 기계(컴퓨터)일 수 있습니다. 
 여기서 중요한 점은 이것이 자격 증명의 영구적(permanent) 집합이라는 것입니다. 
 역할(role)은 운영자를 의미합니다. 
 그것은 인간일 수도 있고 기계(컴퓨터)일 수도 있습니다. 
 여기서 중요한 점은 역할을 포함한 자격 증명이 일시적(temporary)이란 것입니다. 
 어떤 경우든 간에 여기서 우리는 사용자 및 운영자를 위한 인증 방법(authentication method)을 확인하고 있습니다. 
 AWS에서는 모든 것이 API입니다. 
 이것이 중요합니다. 
 이는 또한 API를 실행하기 위해 무엇보다도 먼저 인증(authenticate)을 한 후에 권한을 부여(authorize)해야 한다는 것을 의미합니다. 
 역할은 권한(permissions)을 의미하지 않습니다. 
 다만 이것은 인증(authentication)을 의미할 뿐입니다. 
 권한은 어떤 경우든 간에 정책 문서(policy document)로 알려진 별도의 개체에서 발생합니다. 
 정책 문서는 JSON 문서입니다. 
 이 문서는 영구적 이름이 지정된 사용자 또는 사용자 그룹과 직접 연결되며, 혹은 역할과 직접 연결할 수 있습니다. 
 정책 문서는 지금 제가 화이트리스트에 추가하고 있거나 허용하는 특정 API를 나열하거나 혹은 API들의 와일드카드 그룹을 나열하는데, 그렇다면 어떤 리소스에 대해 나열하는 것일까요? 그것(정책 문서)은 계정 내 리소스에 대한 것일까요? 아니면 특정 부분 집합에 대한 것일까요? 몇몇 조건들이 있습니까? 홈 네트워크에 있다면 개인적으로만 정책 문서를 허용할 필요가 있을까요? VPN에 전화를 건다면? 혹은 어떤 위치에서든 정책 문서를 허용할까요? 하루 중 특정 시기에(정책 문서를 허용할까요)? 어쩌면 오로지 제반 함수를 수행할 수 있는 운영자들이 있을지도 모릅니다. 
 이 모든 운영자들은 정책 문서의 일부 요소가 됩니다. 
 이제 운영자들이 연결된 상태에서 하나의 API가 어떤 프로세스를 거치는 과정을 설명해 보겠습니다. 
 예를 들면, 어떤 운영자가 S3 버킷에 하나의 개체를 입력하려는 상황을 생각해 봅시다. 
 이것은 API 호출을 의미하며, 이러한 호출을 하기 위해 운영자들은 API를 실행하고 버킷 등의 개체를 S3에 입력합니다. 
 그리고 운영자들은 콘솔에 로그인하기 위해 사용하는 액세스 키, 비밀 키 또는 사용자 이름 및 암호 등 일련의 자격 증명 집합을 제공합니다. 
 이 모든 것들은 API 실행문을 나타냅니다. 
 이 실행문은 AWS API 엔진에 전달됩니다. 
 IAM 엔진이 수행하는 첫 번째 작업은 그러한 자격 증명, 사용자 이름 및 암호, 액세스 키, 비밀 키 등을 확인하고 이들 항목이 능동적 권한 부여 자격 증명인지를 검증하며, 이것이 영구 운영자(여기서는 Blaine)인지 혹은 어쩌면 프로젝트 17의 개발자 역할에 해당되는지 아니면 전체 사용자들의 모음을 포함할 수 있는 관리자 그룹에 해당되는지를 검증하는 것입니다. 
 어떤 경우든 간에 그러한 자격 증명들은 승인되며, 우리는 사용자 본인이 스스로 주장하는 운영자에 해당된다는 사실에 동의합니다. 
 그런 다음, 해당 운영자(예: 사용자, 사용자 그룹 또는 역할)와 관련된 정책 문서를 가져와 모든 정책 문서들을 한 눈에 평가합니다. 
 이제 여러분이 수행하는 작업 - 이 경우에는 S3에 개체를 입력 - 에 대한 권한이 해당 정책 문서를 통해 부여되는지를 알아보겠습니다. 
 권한이 부여된다면 API를 실행할 수 있게 됩니다. 
 이제 정책 문서는 명시적 거부(explicit deny)를 포함할 수도 있습니다. 
 이는 허용 실행문(allows statement)을 무시합니다. 
 허용 실행문이 없다면 암묵적 거부(implicit deny)가 있는 것입니다. 
 적어도 이러한 일이 발생하려면 하나의 함수를 화이트리스트에 추가해야 합니다. 
 다만 블랙리스트나 명시적 거부가 있을 경우에는 허용 실행문이 있는지 여부가 문제가 되지 않습니다. 
 그것은 몇몇 작업들이 발생하는 것을 영구적으로 방지해야 할 경우에 사용할 수 있습니다. 
 예를 들면, 어떤 생산 환경에서 자산을 중단하거나 종료할 수 있는 누군가가 필요하지 않은 상황을 생각해볼 수 있습니다. 
 EC2 중단을 거부하는 하나의 정책 문서를 작성할 수 있으며, EC2는 리소스 생산에 대비하여 종료되며 하나의 인스턴스를 사용하지 않도록 허용된 유일한 자에 해당하는 권한이 있는 시스템 관리자를 제외하면 모든 그룹, 모든 사용자 및 모든 역할에 그것(정책 문서)을 연결합니다. 
 따라서 생산 환경에서 우연히 자신을 발견해 인스턴스를 종료하기 시작한 개발자가 있다면 거부 정책은 삭제 실행문(delete statement)을 거부하고 종료 실행문(terminate statement)의 실행을 거부할 것이기 때문에 아무 것도 종료되지 않습니다. 
 이 사람이 스스로 개발자라고 주장하는 자에 해당된다는 사실에 동의하더라도 말입니다. 
 인증, 권한 부여. 
 이것은 추가적인 문제를 해결하며 일련의 자격 증명 집합에 해당됩니다. 
 예를 들면, 저의 개인 계정에서 어떤 이유 때문에 내 암호 관리를 소홀히 했다고 가정해 봅시다. 
 어쩌면 제 아이가 내 노트북을 사용하도록 방치했는데 그 녀석이 노트북에 어떤 바이러스를 다운로드했고 누군가 키 자동 기록기(key logger)를 획득해 내 사용자 이름과 암호를 가로챌 수도 있겠죠 - 설상가상으로 저는 멀티 팩터 인증을 사용하지 않습니다. 
 (제 시스템에서는 이 2가지 경우가 발생한 적이 없지만 실제로 발생한다고 가정해 보겠습니다.) 이러한 경우, 어디선가 어떤 악의적 해커가 내 관리 사용자 이름과 암호를 가로채 영구적 사용자와 연결된 모든 정책 문서에 접근할 권한을 확보합니다. 
 왕국의 열쇠(권한을 획득하기 위해 필요한 개인 정보)를 손에 넣었다는 사실을 확인한 이 해커는 “가지고 있는 비트코인을 다 내놓는 게 신상에 좋을 걸... 
 아니면 자산을 곧 삭제해 버릴 거야”라는 악의적인 내용의 인질 협박 메시지를 회사에 전달합니다. 
 그리고 실제로 비트코인이 위치한 지점을 검증하기 위해 회사의 일부 자산을 삭제합니다. 
 이에 회사 측은 당황합니다. 
 이제 무엇을 해야 할까요? 여러분이 지금 사용자와 연결된 정책 문서를 사용 중이며 루트 수준의 자격 증명을 사용하고 있지 않다면 이 시점에서 - 어떤 계정이 손상되었는지를 알지 못하는 - 보안 관리자는 단일한 작업의 모든 사용자, 그룹 및 역할에서 모든 정책 문서를 제거하는 단일 API 실행문을 실행할 수 있습니다. 
 회사의 비트코인을 가로채지 못한 범인(해커)은 이제 비트코인이 필요한 이유로 더 많은 자산을 삭제하기 위해 비트코인이 위치한 지점을 검증하려고 합니다. 
 API 작업이 해결되는 과정은 다음과 같습니다. 
 범인은 Blaine의 자격 증명을 이용해 API를 제출하면서 S3에서 개체를 삭제한다고 말합니다. 
 해당 API는 IAM 엔진을 통해 평가됩니다. 
 IAM 엔진은 이 API가 Blaine이라는 사실에 동의합니다. 
 이것은 올바른 사용자 이름이자 암호입니다. 
 그런 다음, IAM 엔진은 해당 계정에서 삭제된 해당 정책 문서들(연결된 상태)을 검사합니다. 
 이들 문서는 Blaine에 더 이상 연결되어 있지 않은데, 이는 Blaine이 어떤 문서든 삭제할 수 없으며 그나마 애쓴 게 가상하다는 것을 의미합니다. 
 그건 그렇고 AWS CloudTrail에서는 모든 API 작업이 CloudTrail에 ‘성공(successful)’ 또는 ‘거부됨(declined)’으로 기록되기 때문에 여러분이 시도한 작업을 기록할 것입니다. 
 인증 및 권한 부여. 
 이러한 차이를 이해한다면 AWS에서 여러분의 작업에 일부 중요한 권한과 보안을 추가할 수 있습니다. 
 
 - 데이터 암호화
 암호화를 논할 경우, 암호화와 AWS에 관해 알아야 할 사항들이 많이 있습니다. 
 이제 고민할 필요가 없는 것들 중 한 가지는 바로 암호화 프로세스에서 사용되는 알고리즘입니다. 
 그렇다고 이것이 중요하지 않다는 것은 아닙니다. 
 AWS는 사실 자사의 알고리즘에 대해 큰 자부심을 갖고 있습니다. 
 AWS는 AAS 256 알고리즘을 사용하며 다만 이 알고리즘이 작동하는 방식을 이해하려면 암호학 박사 쯤은 되어야 할 겁니다. 
 이는 지금 당장 알 수 있는 것보다 더 많은 시간이 걸립니다. 
 해당 엔진이 내부에서 작동하는 방식 그리고 암호화 키를 관리하는 방법을 각각 이해할 필요가 있습니다. 
 이제 몇 가지 기본 원리를 살펴보겠습니다. 
 데이터 키인 개인 암호 키를 생성하는 엔진이 하나 있다고 생각해 봅시다. 
 이 키는 데이터 객체에 적용되는 모든 암호 정보를 포함합니다. 
 해당 데이터 객체는 사진이나 동영상 혹은 사용자가 보호하려는 개별 문서일 수도 있습니다. 
 개별 개체에 대하여 암호 데이터를 적용하면 결국 암호화된 데이터를 얻게 됩니다. 
 이렇게 암호화된 데이터는 스토리지에 보관됩니다. 
 Amazon S3 또는 Amazon EBS든 어떤 것이든 간에 이는 문제가 되지 않습니다. 
 원래의 암호화 키가 없다면 해당 데이터를 읽을 방법도 없는 셈이 됩니다. 
 여기서 진짜 문제가 되는 것은 그 키를 관리하는 것입니다. 
 저희는 그 키를 잃고 싶지 않으며 키를 보호하고 싶어 합니다. 
 또 다른 고려 사항이 여기에 있습니다. 
 어떤 이유로든 간에 데이터 키가 손상될 경우 해당 키를 가진 사람이 모든 것을 읽을 수 있기 때문에 내 환경에 저장하는 모든 개체에 대해 똑같은 데이터 키를 사용하고 싶지는 않습니다. 
 그 대신, 내 엔진은 내 시스템으로 들어가는 모든 개체에 대해 고유한 하나의 키를 만들 것입니다. 
 50개 또는 100개의 문서가 있다면 큰 문제가 있는 것으로 생각되지는 않겠지만 여러분이 현재 보관 중인 수백만 개 또는 수십억 개의 개별 개체가 존재할 수 있는 소셜 미디어 사이트를 운영하고 있다고 상상해 보십시오. 
 이러한 경우, 그러한 모든 키를 관리해야 한다는 것은 주어진 시나리오에서 까다로운 부분에 해당됩니다. 
 AWS는 이러한 관리를 어떻게 수행할까요? AWS는 실제로 부동산에서 교훈을 얻고 있습니다. 
 여러분은 부동산 중개인이며 직업상 여러분이 사는 동네에서 수만 채 혹은 수십만 채의 주택에 접근할 권한을 확보할 수 있다고 상상해 보십시오. 
 그러한 모든 키를 포함한 키 체인을 보관하는 대신, 키를 주택의 현관문에 테이프로 붙일 것을 모든 집 주인에게 부탁하면 됩니다. 
 이것은 AWS가 수행하는 작업이라는 점만 제외하면 언뜻 보기에 그다지 안전한 것 같지는 않을 것입니다. 
 비유하자면 AWS는 해당 키를 받아 키를 집 현관문의 사서함에 테이프로 부착하며, 부동산 중개인이 갖고 있는 것은 사서함에 부착된 이 키 밖에 없는 셈이죠. 
 부동산 중개인들은 마스터 키를 갖고 있으며 중개인은 이 키를 사서함에 부착하는 한, 이 키를 획득해 집 현관문을 열 수 있습니다. 
 AWS는 바로 이와 같은 일을 하고 있는 것입니다. 
 여러분은 이 데이터 객체에서만 사용되는 개인 데이터 키를 갖고 있습니다. 
 AWS는 데이터 키를 확보하고 마스터 키를 갖고 있으며 원래의 데이터 키와 대조하여 마스터 키를 적용함으로써 암호화된 버전의 데이터 키를 얻을 수 있습니다. 
 그런 다음, 새로 암호화된 버전의 해당 개체는 암호화된 개체에 가상으로 부착되며 그 개체는 결국 스토리지에 보관됩니다. 
 이제 원래의 데이터 키를 보관하는 것에 대해서는 고민할 필요가 없습니다. 
 사실 개인적으로 이 키를 잊어버릴 수 있습니다. 
 암호화된 버전의 키를 획득했기 때문에 원래의 키는 사라진 것입니다. 
 마스터 키를 분실하지 않는 한, 마스터 키를 사용하면 암호화된 버전의 키를 해독하여 평문 버전의 키를 얻을 수 있으며, 이 키를 사용하면 무엇보다도 평문 데이터 객체로 복원할 수 있게 됩니다. 
 마스터 키를 사용해 수행하는 작업을 제외하면 문제가 해결됩니까? 이제 문제가 되는 것은 바로 마스터 키 관리입니다. 
 똑같은 솔루션을 사용해 보겠습니다. 
 또 다른 마스터 키를 받아 이 키를 암호화한 후 스토리지에 따로 보관합니다. 
 이제 마스터 키를 암호화해야겠군요. 
 마스터 키를 암호화는 게 좋겠습니다! 암호 기법에 대해 논할 때 여러분이 결국 얻게 되는 것은 문제의 원인입니다. 
 고민해야 할 것은 마스터 키 관리입니다. 
 사람들은 이 문제에 대한 솔루션을 수십 년 동안 궁리해 왔습니다. 
 AWS는 암호 기법 적용 시 도움을 주기 위해 활용할 수 있는 솔루션들을 출시하고 있습니다. 
 저희는 클라우드 HSM(Hardware Security Module) 같은 하드웨어 솔루션 또는 서비스(예: KMS) 및 키 관리 시스템 등에 필요한 솔루션들을 제공합니다. 
 이러한 솔루션들은 AWS에서 기본적인 마스터 키 관리 문제를 해결할 방법들을 제공할 수 있습니다. 
 
 - EBS 볼륨 암호화 
 Amazon EBS(Elastic Block Store) 볼륨 암호화는 중요 데이터를 보호하는 데 도움을 주기 위해 AWS가 제공하는 기본 암호화 서비스 중 하나에 속하며, AWS KMS(Key Management Service)와 연동합니다. 
 EBS 볼륨 암호화를 사용할 경우, 모든 암호화 알고리즘이 서버 측에서 발생하여 암호화 프로세스에서 운영 체제에 필요한 여유 공간을 확보한다는 점이 돋보입니다. 
 EBS 볼륨 암호화의 운영 방식은 다음과 같습니다. 
 EBS 볼륨이 서버측 암호화를 요청할 경우, KMS는 각 EBS 볼륨에 대한 고유 데이터 키를 프로비저닝합니다. 
 AWS에서는 그러한 고유 데이터 키를 재사용하지 않습니다. 
 즉, 암호화가 필요한 EBS 볼륨의 수가 몇 개이든 간에 해당 시스템 밖에서 1개의 키가 손상될 경우에는 데이터가 손실될 가능성이 없습니다. 
 이 EBS 볼륨이 분리되어 별개의 EC2 인스턴스에 다시 연결될 경우에도 문제가 되지 않습니다. 
 이 볼륨을 몇 번 연결하든 이 볼륨을 제어하는 모든 EC2 인스턴스가 암호 정보에 대한 액세스 권한을 항상 갖는지 확인할 필요가 있습니다. 
 이 볼륨은 EC2 인스턴스에 연결될 때 암호화된 버전의 암호화 키를 EC2 인스턴스로 전달합니다. 
 그런 다음, 이 인스턴스는 해당 키를 해독해야 합니다. 
 EC2 인스턴스는 KMS 서비스에 이 키를 복호화할 것을 요청하며 암호화된 버전의 키를 KMS로 전달합니다. 
 KMS는 키를 복호화하는 데 사용된 마스터 키를 보관합니다. 
 이 마스터 키는 KMS 시스템을 떠나지 않습니다. 
 KMS는 권한을 사용해 마스터에 붙어 다니면서 개별 데이터 키를 복호화하며 이 키를 EC2 인스턴스로 다시 보냅니다. 
 이제 EC2 인스턴스는 복호화된 버전의 키에 대한 액세스 권한을 갖게 되며 EC2 인스턴스 및 EBS 볼륨을 드나드는 모든 데이터는 이러한 식으로 암호화 및 보관됩니다. 
 어떤 지점에서든 EC2 인스턴스는 암호화된 키 및 평문 버전의 암호화 키를 시스템 내 어느 곳에서든지 작성합니다. 
 암호화 키를 메모리에 보관하는 것은 이 인스턴스 밖에 없습니다. 
 이런 식으로 사용자의 데이터는 안전하게 보관 및 보호됩니다.
 
 - 서브넷 게이트웨이 및 라우팅
 표준 3티어 아키텍처를 살펴보면 이해해야 할 점이 많습니다. 
 애플리케이션 서버로 이동한 후 마스터 대기 구성에서 실행 중인 데이터베이스와 통신하는 프런트엔드 웹 서버로 시작하는 애플리케이션을 구축하는 것을 고려하면서 네트워크 구성 요소들을 먼저 살펴보기로 하겠습니다. 
 먼저 물리적 인프라부터 살펴보겠습니다. 
 3티어 애플리케이션을 갖고 있음에도 불구하고 처음부터 항상 높은 가용성에 대해 생각한다는 개념입니다. 
 이는 여러 가용 영역(AZ)이 있는 AWS 리전에서 실행됨을 의미합니다. 
 모든 AWS 리전은 적어도 2개 이상의 가용 영역(AZ)을 갖고 있습니다. 
 물론 2개 이상의 가용 영역을 사용할 수 있는데 다만 여기서는 편의상 필요에 따라 더 많이 분산할 수 있는 가용 영역 AZ-1 및 AZ-2에 위치해 보겠습니다. 
 모든 것은 VPC 내부에 있습니다. 
 이번 시간에는 10.10/16의 CIDR(Classless Inter-Domain Routing) 블록을 VPC를 위한 네트워킹 구성 요소로 선택한 다음, 갖고 있는 자산을 여러 서브넷으로 분할했습니다. 
 VPC 내부에 있는 모든 것은 하나의 서브넷 내에 있으며, 해당 서브넷들은 모두 충돌할 수 없는 자체 CIDR 블록을 갖고 있습니다. 
 서브넷들은 고유한 것이어야 하며, 이들은 모두 코어 VPC 사이트 또는 블록 그 자체의 부분 집합에 속합니다. 
 여기서 할 일은 항상 자산을 보호한다는 목적으로 해당 부분 집합 내에서 통신을 처리하는 것입니다. 
 아키텍처를 어떤 방법으로 사용하고 싶습니까? 과연 AWS는 데이터베이스와 직접 통신하는 인터넷에서 사용자들을 밖에 위치시키고 싶어 하겠습니까? 아니요. 
 그렇지 않습니다. 
 AWS는 사용자들이 프런트 애플리케이션 웹 서버를 통과하기를 늘 원하고 있으며 거기서부터 애플리케이션 서버는 서로 통신합니다. 
 애플리케이션 서버는 데이터베이스와 통신합니다. 
 다만 외부 통신으로부터 데이터베이스를 보호함으로써 해킹, 침입 또는 남용으로부터 보호를 받게 됩니다. 
 애플리케이션의 GUI를 중심으로 배치할 방어선들은 많습니다. 
 먼저 네트워킹 구성 요소부터 살펴보겠습니다. 
 단일한 서브넷 내부에 모든 것을 배치하는 대신, 가용 영역(AZ)들을 퍼블릭 서브넷과 프라이빗 서브넷으로 분할합니다. 
 온프레미스 네트워킹을 수행했다면 서브넷에 대해 생각할 때 먼저 스위치와 라우터에 대해 생각해보고 모든 자산이 서로 통신하거나 혹은 동일한 스위치 및 동일한 라우터에서 통신을 한 후 다른 자산들이 개별 라우터에 위치하는지 확인합니다. 
 AWS에서 이것은 서브넷의 목적에 해당되지 않습니다. 
 AWS 네트워크가 내부에서 작동하는 방식을 전반적으로 다룬 논의는 있습니다. 
 다만 이것은 이번 시간에 논의할 주제에 속하지는 않습니다. 
 이에 관한 내용을 알고 싶다면 “A Day In the Life of a Billion Packets(수십억 개의 패킷이 가진 수명 중 하루)”라는 제목의 동영상을 시청해 보시기 바랍니다. 
이번 시간에는 퍼블릭 서브넷 내부의 모든 자산이 외부 인터넷과 직접 통신하게 될 자산이라는 사실에 대해 논의해보려고 합니다. 
 물론 여기서 직접 다루지는 않을 모든 자산은 프라이빗 서브넷 내에 위치할 것입니다. 
 여러 개의 프라이빗 서브넷을 가질 수 있을까요? 물론 가질 수 있습니다. 
 지침 목적상 도표는 단순화하고 있습니다. 
 퍼블릭(public) 즉, 공개적인 속성을 결정하는 것은 무엇입니까? 프라이빗(private) 즉, 비공개적인 속성을 결정하는 것은 무엇입니까? 그것은 바로 외부에 대한 접근(액세스)입니다. 
 VPC는 승인된 통신을 제외하면 트래픽의 입력 또는 출력을 허용하지 않는 가상 프라이빗 클라우드(virtual private cloud)로 정의됩니다. 
 트래픽 입력 또는 출력은 게이트웨이를 통해 이루어집니다. 
 여기서 살펴볼 첫 번째 게이트웨이는 IGW(internet gateway, 인터넷 게이트웨이)입니다. 
 이 게이트웨이를 활용하면 외부 인터넷의 통신을 VPC와 승인된 모든 서브넷에 전달할 수 있습니다. 
 이것은 라우팅(routing)에 대해 설명할 때 첫 번째 단계에 해당합니다. 
 VPC는 AWS 내 그 밖의 모든 VPC에 걸쳐 트래픽을 격리하도록 설계되어 있습니다. 
 VPC 내부의 자산은 VPC 그 자체와 그 외 모든 사용자 혹은 VPC의 나머지 구성 요소 간에 패킷을 전송하는 방법을 이미 알고 있습니다. 
 이는 라우팅 테이블을 통해 이루어집니다. 
 VPC를 콘솔 내에서 생성했는지 혹은 API를 통해 생성했는지 여부에 관계없이 기본 라우팅 테이블(RT) 개체는 자동으로 생성되었습니다. 
 이 개체는 1개의 라인만 갖습니다. 
 이 경우, 이 개체는 VPC 그 자체(10.10/16)의 CIDR 블록에 해당합니다. 
 그렇다면 그 대상은 어디에 있을까요? 대상은 로컬에 있습니다. 
 그 밖에 해야 할 일은 없지만 이는 서브넷과는 별도로 프라이빗 IP 주소와 관계없이 VPC 내부의 모든 자산은 패킷을 전송할 하나의 경로가 있음을 의미합니다. 
 이것은 패킷이 승인되었음을 의미하지는 않습니다. 
 본 강의의 뒷부분에서는 보안 그룹과 액세스 통제 목록(ACL)에 대해 살펴볼 것입니다. 
 다만 이것은 패킷이 최소한 다른 인스턴스에 도달하는 방법을 알고 있음을 의미합니다. 
 그러나 딱 거기까지만 알고 있는 것이죠. 
 퍼블릭 서브넷의 인스턴스에서 어떤 패킷이 IGW 밖으로 빠져나가 인터넷(interwebs)으로 들어가거나 혹은 그 반대로 이동할 수 있기를 원한다면 말입니다. 
 인터넷을 프라이빗 엔터티 또는 퍼블릭 인스턴스에 연결하고 싶다면 IGW를 통해 빠져나가는 경로를 제공하는 라우팅 라인(route line)을 추가해야 합니다. 
 해당 액세스 권한은 기본 라우팅 테이블에 바로 입력할 수 있습니다. 
 문제는 이것이 모든 인스턴스에 적용된다는 점이며, 수행 중인 작업의 전체 지점은 바로 여기서 GUI 중심을 보호하는 데 그 목적이 있습니다. 
 그 대신, AWS는 새로운 개체 즉, 퍼블릭 라우팅 테이블을 만듭니다. 
 사용자가 새 라우팅 테이블을 만들면 이 테이블은 기본 라우팅 테이블에 수록된 모든 내용을 자동으로 복사합니다. 
 그래서 새 라우팅 테이블은 10.10.0.0/16으로 시작합니다. 
 이 테이블은 항상 로컬로 유지됩니다. 
 여기서 우리가 하려는 작업은 퍼블릭 라우팅 테이블을 승인하는 것입니다. 
 이 테이블과 관련된 모든 자는 IGW에 대한 액세스 권한을 갖습니다. 
 우리가 대상으로 삼고 있는 IP는 무엇입니까? 우리는 전체 IPV 4 스펙트럼을 대상으로 삼고 있습니다. 
 그렇다면 표기법은 어떻게 인용하고 있을까요?  0.0.0.0/0은 IGW 밖으로 나갑니다. 
 IGW는 물리적 서버가 아니며 네트워크 구성체(network construct)에 속합니다. 
 IGW는 10.10/16에 해당되지 않는 것으로서 대상이 된 모든 콘텐츠가 해당 리전 외부로 나가 DNS 검색 시 콘텐츠 전송의 대상 위치로 들어갈 수 있도록 자동으로 허용된다는 것을 시사하는 고가용성의 네트워크 구성체에 속합니다. 
 마지막으로 해야 할 일은 퍼블릭 라우팅 테이블을 퍼블릭 서브넷과 연결하는 것입니다. 
 웹 인스턴스에서 발신되거나 웹 인스턴스를 대상으로 하는 모든 패킷은 10.10/16 밖으로 나간다면 이제 IGW 밖으로 이동하는 경로를 갖게 되며 필요한 것이 무엇인지를 확인한 후 반환하게 됩니다. 
 0.0.0.0/0을 프라이빗 서브넷에 추가하지는 않았기 때문에 누군가 이 인스턴스의 IP 주소를 알고 있더라도 패킷이 이 인스턴스를 통과하려는 모든 시도는 즉시 중단됩니다. 
 패킷이 이 인스턴스를 건드리지 못하는 이유는 IGW가 이 서브넷과 연결될 수 있도록 허용하는 라우팅 라인이 없는데다 건드릴 수 없는 것들을 해킹할 수는 없기 때문입니다. 
 이만하면 훌륭하군요. 
 다만 또 다른 문제가 있습니다. 
 즉, 어떤 지점에서는 이 자산이 인터넷으로 빠져나가 하나의 패치를 선택할 수 있게끔 하고 싶을 때가 있는 것이죠. 
 예를 들면, 이것이 Oracle 데이터베이스라고 할 때 나는 oracle.com 사이트로 이동해 Oracle의 최신 버전을 다운로드하여 내 시스템을 업데이트해야 합니다. 
 시스템 업데이트는 바로 이런 식으로 이루어집니다. 
 인스턴스는 IGW로 이동을 시도하라는 요청을 할 것입니다. 
 DNS 검색 요청을 할 경우, oracle.com 사이트로 이동하면 DNS는 54.<주소>에 있다고 알려줄 것입니다. 
 주소를 구성하고 있습니다. 
 어떤 지점에서 인스턴스는 ‘좋습니다. 이제 패킷을 54.<주소>로 전송하십시오’라고 알리게 됩니다. 
 내 라우팅 테이블은 무엇입니까? 그것은 기본 라우팅 테이블 54.<주소>와 계속 관련됩니다. 
 내 라우팅 테이블은 10.10/16의 일부인가요? 아니요. 
 그렇지 않습니다. 
 다른 선택의 여지가 없다면 패킷은 제거됩니다. 
 패킷은 외부로 통신할 수 없습니다. 
 이러한 일이 발생하려면 이 아키텍처에 몇 가지 다른 요소들을 추가해야 합니다. 
 퍼블릭 라운드 테이블을 연결할 수 있습니다. 
 이 때 문제가 되는 것은 자산이 노출되었다는 점이며 또한 이 서브넷을 퍼블릭 상태로 공개함으로써 시간을 들여 마련한 모든 보안 프로토콜을 위반했다는 점입니다. 
 서브넷의 이름은 여전히 프라이빗(private)으로 불리겠지만 000, IGW 액세스 권한을 갖고 있기 때문에 사실상 퍼블릭 서브넷이나 다름이 없습니다. 
 이름은 관련이 없습니다. 
 이것의 이름은 사람, 곰, 돼지 등으로 부를 수 있습니다. 
 여러분이 그 이름을 어떻게 부르든 상관은 없습니다. 
 이 서브넷이 000 IGW 액세스 권한을 갖고 있다면 퍼블릭 서브넷에 해당됩니다. 
 AWS는 이 서브넷을 어떻게 보호할까요? 먼저 이 시나리오에서 해결하려는 2가지 통신 경로를 살펴보겠습니다. 
우리가 해결하려는 첫 번째 경로는 외부에서의 통신입니다. 
 그 이유는 여러분이 갖고 있는 것이 패치를 필요로 하는지 여부를 확인하기 위해 우선적으로 데이터베이스에 대한 액세스 권한을 획득하려는 데이터베이스 관리자(DBA)이기 때문입니다. 
 저는 외부의 Starbucks 또는 그 외 다른 곳에서 있는 DBA와 일하고 있습니다. 
 DBA는 로그인을 시도해 데이터베이스에 연결하려고 합니다. 
 지금 당장에는 데이터베이스가 DBA의 패킷을 허용할 방법은 없기 때문에 이렇게 하려면 아키텍처에 또 다른 개체를 추가해야 합니다. 
 지금까지 실행된 모든 보안 메커니즘을 위반하는 퍼블릭 라우팅 테이블을 다시 한 번 할당할 수도 있습니다. 
 이것은 접속 호스트(bastion host)라 불리는 새 인스턴스에 해당되며, 접속 호스트 또는 점프 박스(jump box)의 전체 개념은 DBA 또는 시스템 관리자가 퍼블릭 인스턴스에 로그인하기 위한 장소(landing place)를 제공하는 것입니다. 
 DBA 또는 시스템 관리자는 퍼블릭 인스턴스에 로그인한 상태에서 로그인 권한이 있는 그 밖의 모든 인스턴스에 대해서도 로그인을 실행할 수 있는데 그 이유는 (그들이) 이미 VPC 내에 있기 때문입니다. 
 이제 접속 호스트는 승인되지 않은 액세스를 방지하기 위해 그 주위에 모든 종류의 보안 그룹과 액세스 통제 목록(ACL) 보호 기능을 갖게 됩니다. 
 다만 그러한 보안 그룹과 ACL 보호 기능이 열려 있다고 가정한다면 DBA는 접속 호스트에 로그인할 수 있으며 접속 호스트에 대한 루트 액세스 권한을 획득하게 되는데, 이 지점에서 DBA는 접속 호스트로부터 데이터베이스 또는 원하는 그 밖의 위치로 직접 연결할 수 있습니다. 
 그 이유는 퍼블릭 서브넷이 로컬 라인을 갖고 있기 때문이며 이는 패킷이 로컬 라인에서 내부의 다른 위치까지 그 경로를 인지하고 있음을 의미합니다. 
 이것은 승인된 것일까요? 아니면 승인되지 않은 것일까요? 그것은 다른 대화에 속합니다. 
 그럼 승인된 것으로 가정해 보겠습니다. 
 이제 DBA는 데이터베이스상의 한 루트(root)로서 로그인을 할 수 있으며 예를 들면 oracle.com 사이트로 이동하기 위해 필요한 모든 검사를 수행할 수 있을 뿐만 아니라 저장소가 있는 모든 위치에서 최신 패치를 다운로드할 수 있습니다. 
 접속 서버(bastion server)를 통한 연결이 되더라도 인스턴스에서 패킷을 시작해 IGW 밖으로 복귀할 수 있도록 액세스 권한이 DBA에 부여되지는 않습니다. 
 이는 이동했던 경로를 단순히 추적하지는 않습니다. 
 따라서 프라이빗 서브넷에서 시작된 트래픽을 IGW 밖으로 다시 내보낼 수 있도록 허용하려면 또 다른 개체가 필요합니다. 
 다시 한 번 뭔가를 추가해야 합니다. 
 그래서 한 가지 구식 수법을 활용합니다. 
 그것은 바로 네트워크 주소 변환 서버(network address translation server)를 의미하는 NAT 서버입니다. 
 이 서버는 AWS가 새로 고안한 것이 아니며 작동 원리는 매우 간단합니다. 
 NAT 서버는 단순히 전체 인터넷인 것처럼 작동합니다. 
 로그아웃을 시도 중인 데이터베이스는 NAT 서버를 대상으로 하면서 이 서버가 전체 인터넷인 것으로 판단합니다. 
 NAT 서버는 기본적으로 ‘예, 허용합니다. 
 저는(NAT 서버는) 귀하가 찾고 계신 모든 주소에 해당됩니다’라는 메시지를 전달한 후, 패킷을 리디렉션합니다. 이러한 동작이 이루어지려면 새 라우팅 테이블(즉, 프라이빗 라우팅 테이블)이 필요합니다. 
 늘 그렇듯이 AWS는 기본 라우팅 테이블의 사본부터 먼저 만드는데, 이는 기본 테이블에서 모든 것을 복사한다는 것을 의미하며 그래서 내 로컬 라인인 10.10.0.0/16은 일반 로컬 라인에 해당됩니다. 
 새 라인은 000으로 처리하는 작업에 해당됩니다. 
 IGW 밖으로 이동하지는 않습니다. 
 그 대신, 이 경우에는 내 0.0.0.0/0이 NAT-ID 밖으로 이동합니다. 
 우리는 단지 이 특정 인스턴스를 향해 외부로 이동하도록 되어 있는 모든 트래픽을 대상으로 한 후, 프라이빗 라우팅 테이블을 2개의 프라이빗 서브넷에 모두 연결합니다. 
 패킷 트래픽은 다음과 같은 방식으로 이동합니다. 
 즉, DBA는 데이터베이스에서 시작해 루트에서 로그인됩니다. 
 이제 DBA는 패킷 송신을 시작하려 합니다. 
 따라서 DNS 검색에서는 54.<주소>로 이동 중으로 나타납니다. 
 이제 패킷은 중단되며 10.10 부분이 아닌, 라우팅 테이블 54.<주소>를 검사합니다. 
 또 다른 옵션이 있습니까? 000이 있군요. 
 우리는 그것과 정확히 일치하므로 당신은 전체 인터넷(entire internet)임에 틀림이 없습니다. 
 그렇다면 NAT는 ‘예, 저는 54.<주소>입니다’라는 메시지를 알립니다. 
 그런데 이 기능이 작동하려면 원본/대상 확인 기능을 꺼야 합니다. 
 이 기능은 기본적으로 ‘켜짐(on)’으로 설정되어 있으며 여러분의 자산을 “중간자(man in the middle)”형 공격으로부터 보호하는 기능이기 때문에 매우 중요합니다. 
 이 경우에는 해당 기능이 꺼져 있기 때문에 NAT는 이 기능이 켜진 것처럼 가장하여 ‘저는 당신의 요구에 따라 54.<주소>에 있어야 할 아무개입니다’라는 메시지를 알립니다. 
 NAT는 실제로 그렇지 않으면서도 그런 척 하는 것입니다. 
 그런 다음, 패킷을 수신하여 다시 로드합니다. 
 NAT는 IGW에 액세스했는데 그 이유는 퍼블릭 테이블에 액세스할 권한이 있기 때문입니다. 
 NAT는 패킷을 밖으로 전송하고 필요한 패킷을 모아서 후퇴시키며 다시 패키지로 만들어 되돌려 보냅니다. 
 그러면 해당 프로세스가 완료된 것입니다. 
 프라이빗 라우팅 테이블이 NAT를 대상으로 하도록 허용하면 밖으로 나갈 수 있으며 혹은 내 퍼블릭 라우팅 테이블은 NAT 액세스 권한을 사용할 필요 없이 직접 나갈 수 있습니다. 
 어떤 경우든 간에 시작해야 할 일은 거기에 있습니다. 
 그것을 허용할까요? 하지 말까요? 이는 권한 문제에 속합니다. 
 그것은 또 다른 대화에 속하며 다만 지금은 적어도 패킷을 밖으로 내보냅니다. 
 제가 언급하고 싶은 퍼즐 조각이 하나 더 있습니다. 
 그것은 하이브리드 옵션들을 다루고 있습니다. 
 내 DBA가 Starbucks에서 연결할 수 있도록 허용하고 싶지 않다면 어떨까요? DBA가 프라이빗 데이터 센터에 로그인했거나 혹은 VPN 터널을 통해 로그인한 경우에만 연결할 수 있도록 요구하고 싶다면 어떨까요? 이러한 경우에는 내 프라이빗 데이터 센터가 있습니다. 
 이 경우, 내 프라이빗 데이터 센터가 해당되는데, 저는 프라이빗 데이터 센터에서 로그인할 것을 내 DBA에 요구할 것이며 이제 VPC에 VPN 연결을 구성할 것입니다. 
 IGW를 경유하지는 않겠습니다. 
 그 대신, VGW라 불리는 새 게이트웨이 또는 가상 프라이빗 게이트웨이를 사용할 것입니다. 
 이제 직접 통신이 필요한 서브넷에 라우팅 테이블 라인을 추가하면 액세스 권한을 설정할 수 있습니다. 
 아마도 내 DBA가 프라이빗 데이터 센터에서 들어오면 데이터베이스에 직접 연결하도록 허용할 필요가 있을 것 같습니다. 
 그래서 내 프라이빗 데이터 센터가 172.68.0.0/16의 IP 체계를 사용하면 해당 라인을 추가하기만 하면 됩니다. 
 이제 어디로 가고 있는 걸까요? VGW 액세스입니다. 
 여기서는 DBA가 프라이빗 데이터 센터에서 직접 통신을 시작한 경우에만 접속 서버를 경유할 필요 없이 해당 인스턴스와 직접 통신할 수 있게 됩니다. 
 그것은 모범 사례 요소에 해당되나요? 모든 구현은 고유한 것이 됩니다. 
 여러분은 각자의 선택을 하게 될 것이며 다만 이러한 선택은 AWS VPC(Virtual Private Cloud)에서 네트워킹 옵션을 구축하기 시작할 때 고려할 필요가 있는 일련의 기본 도구가 됩니다. 
 

 

 


 - 강의 요약 
 안녕하세요. 
 저는 AWS(Amazon Web Services) 교육 및 자격증 팀 담당자 Jody Soeiro de Faria입니다. 
 여러분은 AWS 클라우드 실무자 에센셜 과정을 완료했습니다. 
 이제 지금까지 학습한 내용을 간략히 정리하면 다음과 같습니다. 
 · 섹션 1에서는 클라우드의 가치와 AWS 클라우드 채택에 따른 이점들을 이해하였습니다. 
 · 섹션 2에서는 몇몇 AWS 범주와 서비스, 서비스의 기능 및 서비스 사용 시기와 방법에 대해 배웠습니다. 
 · 섹션 3에서는 AWS가 클라우드 보안에 접근하는 방법에 대해 알아보았으며 AWS 공동 책임 모델, AWS 액세스 제어 및 관리, AWS 보안 및 규정 준수 프로그램은 물론, AWS 클라우드 보안 옵션을 보다 잘 이해할 수 있도록 도움을 주기 위해 제공되는 리소스에 대해서도 살펴보았습니다. 
 · 섹션 4에서는 Well Architected Framework를 포함하는 AWS 아키텍처 설계와 웹 호스팅의 내결함성 및 고가용성을 위한 참조 아키텍처에 대해 살펴보았습니다. 
 · 섹션 5에서는 요금 및 지원에 대해 알아보았습니다. 
 TCO 계산기 및 AWS 지원 계획뿐만 아니라 몇몇 주요 서비스에 대한 요금 및 요금 요소의 기본적인 사항들도 살펴보았습니다. 
 · 보너스 자료에서는 본 과정의 핵심 요소에 관한 추가적인 세부 정보를 제공하는 몇몇 동영상들을 시청했습니다. 
 이번 과정에서 즐거운 학습 경험을 얻었기를 바랍니다. 
 본 과정에 관한 의견은 언제든지 환영합니다. 
 사후 교육 평가를 꼭 완료하시기 바랍니다. 
 또한 의견이 있으시면 이메일 AWS-course- feedback@Amazon.com으로 보내시면 됩니다. 
 저는 AWS(Amazon Web Services) 교육 및 자격증 팀 담당자 Jody Soeiro de Faria였습니다.

반응형