1. 다음 중 AWS에 도커 이미지를 저장할 수 있게 해주는 AWS 서비스는 무엇인가요 ?

• A. Elastic Container Service (ECS)
• B. Elastic Container Registry (ECR)
• C. Amazon S3
• D. AWS CodeCommit

✅ Amazon Elastic Container Registry(ECR)는 완전 관리형 도커 컨테이너 레지스트리로 도커 컨테이너 이미지를 쉽게 저장, 관리, 공유 및 배포할 수 있게 해줍니다.

2. AWS에 모든 인프라를 호스팅하고 있는 한 기업이 있습니다. 이 기업에서는 코드를 전적으로 AWS 내에서 버전 관리하기 위해 GitLab에 대한 대안이 될 수 있는 AWS 서비스를 모색하고 있습니다. 이 경우, 다음 중 어떤 AWS 서비스를 사용하는게 권장될까요 ?

• A. AWS CodeBuild
• B. AWS CodeCommit
• C. Amazon S3
• D. AWS CodePipeline

✅ AWS CodePipeline은 완전 관리형 지속 전송(CD) 서비스로 빠르고 안전한 애플리케이션과 인프라 업데이트를 위한 릴리스 파이프라인의 자동화에 도움이 됩니다. 이는 코드가 변경될 때마다 릴리스 프로세스의 구축, 테스트, 배포 단계를 자동화합니다. AWS CodeCommit은 프라이빗 Git 리포지토리를 호스팅하며 안전하고 스케일링이 용이한 관리형 소스 제어 서비스입니다. CodeCommit은 GitLab과 GitHub의 대안입니다.

3. 재해 복구 전략의 일환으로, 전체 인프라를 코드(IaC)로 만들어 어떤 AWS 리전에서든 손쉽게 다시 배포할 수 있게 하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 사용하는 게 권장될까요 ?

• A. AWS CodePipeline
• B. AWS Elastic Beanstalk
• C. AWS CodeDeploy
• D. AWS CloudFormation

✅ AWS CloudFormation은 코드로서의 인프라(IaC)를 위한 AWS의 실질적인 서비스입니다. 이를 사용하면 예상 가능하고 반복적인 AWS 인프라 배포를 생성하여 프로비저닝할 수 있습니다.

4. 여러분은 AWS Organization으로 다수의 AWS 계정을 관리하고 있는 한 기업에서 근무를 하고 있습니다. 다수의 AWS 리전 내에 있는 여러의 AWS 계정에 CloudFormation 스택을 생성하려 합니다. 이 작업을 위한 가장 효율적인 방법은 무엇일까요 ?

• A. AWS CodeDeploy
• B. AWS Organizations
• C. AWS CLI
• D. CloudFormation StackSets

✅ CloudFormation StackSets을 사용하면 한 번의 작업으로 다수의 AWS 계정 및 AWS 리전 전반에 걸쳐 CloudFormation 스택을 생성, 업데이트 및 삭제할 수 있습니다.

5. 다음 중 AWS Cloud와 온프레미스에서 도커 컨테이너 플릿을 관리하기 위해서는 어떤 AWS 서비스를 사용해야 할까요 ?

• A. Amazon EC2
• B. Amazon ECR
• C. Amazon ECS
• D. AWS CloudFormation

✅ Amazon ECS는 완전 관리형 컨테이너 오케스트레이션 서비스로 컨테이너화된 애플리케이션을 쉽게 배포, 관리 및 스케일링할 수 있게 해줍니다.

6. CICD 파이프라인이 Elastic Beanstalk까지 전달되도록 오케스트레이션하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 사용하는 게 권장될까요 ?

• A. AWS CodeBuild
• B. AWS CodePipeline
• C. AWS CloudFormation
• D. AWS SWF

✅ AWS CodePipeline은 완전 관리형 지속 전송(CD) 서비스로 빠르고 안전한 애플리케이션과 인프라 업데이트를 위한 릴리스 파이프라인의 자동화에 도움이 됩니다. 이는 코드가 변경될 때마다 릴리스 프로세스의 구축, 테스트, 배포 단계를 자동화합니다. 이는 Elastic Beanstalk과 직접 통합되어 있습니다.

7. 다음 중 특정한 전략을 사용하여 EC2 인스턴스 플릿으로 코드를 배포하는 데에 도움을 주는 AWS 서비스는 무엇인가요 ? (예: 블루/그린 배포)

• A. AWS CodeDeploy
• B. AWS CodeBuild
• C. AWS CodePipeline
• D. AWS CodeCommit

✅ AWS CodeDeploy는 완전 관리형 배포 서비스로, EC2, Fargate, Lambda 및 온프레미스 서버와 같은 다양한 컴퓨팅 서비스에 대한 소프트웨어 배포를 자동화해 줍니다. 가동 중(in-place) 배포 혹은 블루/그린 배포와 같은 실행 전략을 정의할 수 있습니다.

8. Jenkins 지속 통합(CI) 빌드 서버가 온프레미스로 호스팅되어 있는데, 이를 중단한 뒤 AWS 관리형 서비스로 교체하려 합니다. 이 경우, 어떤 AWS를 선택해야 할까요 ?

• A. AWS Jenkins
• B. AWS CodeBuild
• C. AWS CloudFormation
• D. Amazon ECS

✅ AWS CodeBuild는 완전 관리형 지속 통합(CI) 서비스로, 소스 코드를 컴파일링하고 테스트를 실행하며 배포 준비가 완료된 소프트웨어 패키지를 생성하는 서비스입니다. 이는 Jenkins의 대안입니다.

9. 일련의 AWS Lambda 함수를 워크플로우 오케스트레이션하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. AWS SWF
• B. AWS CodePipeline
• C. AWS Step Function
• D. AWS OpsWorks

✅ AWS Step Function은 로우 코드 비주얼 워크플로우 서비스로 AWS 서비스와 오케스트레이션, 비즈니스 프로세스 최적화 및 서버리스 애플리케이션의 구축에 사용됩니다. 이는 실패, 재시도, 병렬화, 서비스 통합 등을 관리합니다.

10. 다음 중 대규모 데이터 분석 수행을 위해 Hadoop 클러스터를 생성할 수 있게 해주는 AWS 서비스는 무엇인가요 ?

• A. Amazon Redshift
• B. Amazon Athena
• C. AWS Glue
• D. Amazon EMR

✅ Amazon EMR은 관리형 서비스로 Apache Hadoop과 Spark를 빠르고 쉽고 비용 효율적으로 실행하여 많은 양의 데이터를 처리할 수 있게 해줍니다.

11. 메타데이터 카탈로그 기능을 가진 관리형 ETL 서비스로 AWS 데이터베이스 전반에 있는 데이터를 옮기려 합니다. 이런 경우, 다음 중 어떤 AWS를 사용하는 게 권장될까요 ?

• A. Amazon EMR
• B. Amazon Redshift
• C. AWS Glue
• D. Amazon Athena

✅ AWS Glue는 추출, 변환 및 로드(ETL) 연산을 위한 서버리스 데이터 준비 서비스입니다.

12. 여러분이 근무 중인 기업은 이미 Chef 레시피를 사용해 인프라를 관리하고 있습니다. 여러분은 Cloud로 옮기되, Chef는 계속 이용하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 추천할 수 있을까요 ?

• A. AWS OpsWorks
• B. AWS SSM
• C. AWS CloudFormation
• D. Amazon EC2

✅ AWS OpsWorks는 Chef and Puppet 관리형 인스턴스를 제공하는 구성 관리 서비스입니다.

13. 솔루션 아키텍트로써 여러분은 온프레미스 가상 데스크톱 인프라(VDI)를 AWS로 이전하려 합니다. 이 작업을 통해 유지 및 관리 비용을 줄일 수 있게 됩니다. 이 경우, 다음 중 어떤 AWS 서비스를 사용하는 게 권장될까요 ?

• A. AWS AppSync
• B. AWS Organizations
• C. Amazon Workspaces
• D. Amazon ECR

✅ Amazon WorkSpaces는 완전 관리형의 지속적인 가상화 서비스로, 사용자들이 언제, 어디서든, 어떤 기기로든 자신들에게 필요한 데이터, 애플리케이션 및 리소스에 액세스할 수 있도록 해줍니다. 이는 Windows 혹은 Linux 데스크톱을 프로비저닝하는 데에 사용될 수 있습니다.

14. 개발자들이 모바일 애플리케이션을 생성하는 중인데, 이 애플리케이션에 관리형 GraphQL 백엔드를 두려고 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 사용하는 게 권장될까요 ?

• A. Amazon API Gateway
• B. AWS Lambda
• C. Amazon ECS
• D. AWS AppSync

✅ AWS AppSync는 완전 관리형 서비스로, DynamoDB, Lambda 등의 데이터 소스에 대한 안전한 연결이라는 복잡한 작업을 처리해주어 GraphQL API를 쉽게 개발할 수 있게 해줍니다.

15. AWS Cost Explorer는 비용 및 사용량을 보고 분석할 수 있게 해줍니다. 최대 지난 12개월까지의 데이터를 볼 수 있으며, 향후 12개월 간의 예측 사용량 및 구매 추천 EC2 예약 인스턴스를 볼 수 있습니다.

• A. 결제 경보를 설정
• B. AWS Cost Explorer를 사용
• C. AWS Lambda
• D. AWS AppSync

✅ AWS Cost Explorer는 비용 및 사용량을 보고 분석할 수 있게 해줍니다. 최대 지난 12개월까지의 데이터를 볼 수 있으며, 향후 12개월 간의 예측 사용량 및 구매 추천 EC2 예약 인스턴스를 볼 수 있습니다.

1. S3 버킷을 업로드되는 객체를 처리하는 서버리스 애플리케이션으로 작업하고 있습니다. S3 버킷에 S3 이벤트를 구성해 객체가 업로드될 때마다 Lambda 함수가 호출되도록 만들었습니다. 프로세싱되지 않은 이벤트는 추후 처리를 위해 데드 레터 대기열(DLQ)로 전송시키려 합니다. 이런 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. S3 Events
• B. SNS Topic
• C. Lambda Function

✅ Lambda 함수의 호출은 '비동기적'이기 때문에 DLQ를 Lambda 함수 측에 설정해야 합니다.

2. 솔루션 아키텍트인 여러분은 기업을 위해 다음과 같은 AWS 서비스를 포함하는 아키텍처를 구축했습니다. CloudFront, 웹 애플리케이션 방화벽(AWS WAF), AWS Shield, Application Load Balancer 및 오토 스케일링 그룹이 관리하는 EC2 인스턴스, 이 기업에서는 가끔 악성 요청을 수신하고 있으며 이 IP 주소를 차단하고자 합니다. 이 아키텍처에 따르면 다음 중 어느 서비스에서 이 작업을 수행해야 할까요 ?

• A. CloudFront
• B. AWS WAF (Web Application Firewall)
• C. AWS Shield
• D. ALB Security Group
• E. EC2 Security Group
• F. NACL (Network Access Control List)

3. 고성능 컴퓨팅(HPC)을 수행하기 위해 EC2 인스턴스를 클러스터 배치 그룹으로 배포했습니다. EC2 인스턴스들 간의 네트워크 성능을 최대화하려 합니다. 무엇을 사용해야 할까요 ?

• A. Elastic Fabric Adapter (EFA)
• B. Elastic Network Interface (ENI)
• C. Elastic Network Adapter (ENA)
• D. FSx for Lustre

4. 프라이빗 서브넷의 EC2 인스턴스에 액세스하기 위해 us-east-1a AZ에서 EC2 인스턴스(Bastion Host)를 시작했습니다. us-east-1a AZ에 재해가 발생할 경우에 대비하여 배스천 호스트의 가용성을 높이려고 합니다. 당신은 무엇을 해야 합니까 ?

• A. 2군데의 AZ에 2개의 Bastion Host를 실행하고 2군데의 AZ에 배포된 Application Load Balancer를 사용해 트래픽을 라우팅
• B. 2군데의 AZ에 2개의 Bastion Host를 실행하고 2군데의 AZ에 배포된 Network Load Balancer를 사용해 트래픽을 라우팅

✅ Application Load Balancer는 7계층(HTTP 프로토콜)에서 운용되기 때문에 사용할 수 없습니다. NLB는 4계층(TCP)에서 운용되기 때문에 NLB를 사용해야 하며, Bastion Host EC2 인스턴스로 SSH를 해야 합니다.

1. 재해 복구 계획의 일부로 AWS에서 중요한 인프라만을 가동해 실행하려 합니다. 복구 시간 목표(RTO)는 길어져도 상관이 없습니다. 이런 경우, 다음 중 어떤 DR 전략을 추천할 수 있을까요 ?

• A. 백업 및 복구
• B. 파일럿 라이트
• C. Warm Standby
• D. 멀티 사이트

2. 여러분은 비용에 관계없이 가장 낮은 RTO(복구 시간 목표) 및 RPO(복구 시점 목표)로 재해 복구 전략을 얻고자 합니다. 어떤 DR을 선택해야 할까요 ?

• A. 백업 및 복원 계획
• B. 파일럿 라이트
• C. Warm Standby
• D. Multi-Site

3. 다음 중 잠재적으로 높은 복구 시점 목표(Rpo)와 복구 시간 목표(RTO)를 갖는 재해 복구 전략은 무엇인가요 ?

• A. 백업 및 복구
• B. 파일럿 라이트
• C. Warm Standby
• D. 멀티 사이트

4. 스케일 다운된 버전의 시스템을 가동해 실행하고, 재해가 발생하면 빠르게 스케일 업하는 재해 복구 계획을 수립하려 합니다. 이 경우, 어떤 DR 전략을 선택해야 할까요 ?

• A. 백업 및 복구
• B. 파일럿 라이트
• C. Warm Standby
• D. 멀티 사이트

5. AWS로 특히 Amazon Aurora로 이전시키려는 온프레미스 Oracle 데이터베이스가 있습니다. 어떻게 이전해야 할까요 ?

• A. 데이터베이스 스키마를 변환하기 위해 AWS 스키마 변환 도구(AWS SCT)을 사용한 후, AWS 데이터베이스 이전 서비스(AWS DMS)를 사용해 데이터를 이전
• B. 데이터베이스 스키마를 변환하기 위해 AWS 데이터베이스 이전 서비스(AWS DMS)를 사용한 후, AWS 스키마 변환 도구(AWS SCT)를 사용해 데이터를 이전

✅ AWS DataSync는 온라인 데이터 전송 서비스로 온프레미스 스토리지 시스템과 AWS 스토리지 시스템 간의 데이터 이전 그리고 AWS 스토리지 서비스들 간의 데이터 이전 과정을 단순화, 자동화 및 가속화해주는 서비스입니다.

6. AWS DataSync가 지원하지 않는 서비스를 고르세요.

• A. Amazon S3
• B. Amazon EBS
• C. Amazon EFS
• D. Windows 파일 서버 용 Amazon FSx

7. AWS 내에서 EC2 인스턴스, EBS 볼륨, DynamoDB 테이블 등의 여러 리소스를 실행하고 있습니다. 한 곳에서 이러한 AWS 서비스들의 백업을 관리할 수 있는 간편한 방법이 필요한 상황입니다. 이 처리과정을 간단히 하기 위해서는 다음 중 어떤 AWS를 사용해야 할까요 ?

• A. Amazon S3
• B. AWS Storage Gateway
• C. AWS Backup
• D. EC2 Snapshot

✅ AWS 백업을 사용하면 AWS 서비스 전반에 걸친 데이터 보호를 중앙 집중화하고 자동화할 수 있습니다. 이는 데이터 보호를 위한 규정 준수, 혹은 기업의 정책을 지원하는 데에 도움이 됩니다.

1. 보안 그룹은 ( ) 레벨에서 운용되는 반면, NACL은 ( ) 레벨에서 운용됩니다.

• A. EC2 인스턴스, 서브넷
• B. 서브넷, EC2 인스턴스

2. 인터넷 게이트웨이를 VPC에 연결했으나, 여전히 인터넷을 통한 EC2 인스턴스 액세스가 불가능한 상태입니다. 이런 경우, 가능성이 있는 원인이 아닌 것을 고르세요.

• A. 라우팅 테이블에 항목이 누락됨
• B. EC2 인스턴스에 공용 IP가 없음
• C. 보안 그룹이 들어오는 트래픽을 허용하지 않음
• D. NACL이 나가는 네트워크 트래픽을 허용하지 않음

✅ 보안 그룹은 상태를 유지하기 때문에 트래픽이 나갈 수 있다면 다시 들어갈 수도 있습니다.

3. IPv4를 가진 사설 서브넷에 있는 EC2 인스턴스에 인터넷 액세스를 제공하려 합니다. 이 솔루션을 사용하면 필요한 관리의 양은 최소가 되어야 하며, 원활하게 스케일링이 되어야 합니다. 무엇을 사용해야 할까요 ?

• A. 소스/목적지 확인 플래그 오프를 가진 NAT 인스턴스
• B. 송신 전용 인터넷 게이트웨이
• C. NAT Gateway

4. VPC A와 VPC B 사이에 VPC 피어링이 활성화되어 있으며, VPC A에 대해 라우팅 테이블이 업데이트되어 있는 상황입니다. 그러나 EC2 인스턴스 간의 통신이 불가능한 상태입니다. 이런 경우, 가능성이 있는 문제는 무엇인가요 ?

• A. NACL 확인하기
• B. VPC B의 라우팅 테이블 확인하기
• C. 보안 그룹에 연결된 EC2 인스턴스 확인하기
• D. DNS Resolution 활성화 여부 확인하기

✅ 라우팅 테이블은 피어링이 된 두 VPC 모두에 업데이트되어야 합니다.

5. 기업 데이터 센터와 AWS 계정 내 VPC A 사이에 Direct Connect 연결을 설정했습니다. 기업의 데이터센터가 다른 AWS 리전에 있는 VPC B로도 액세스할 수 있어야 합니다. 어떻게 해야 할까요 ?

• A. VPC 피어링 활성화하기
• B. 고객 게이트웨이 사용하기
• C. Direct Connect Gateway 사용하기
• D. NAT Gateway 설정하기

6. CIDR 10.0.4.0/28은 무엇에 해당할까요 ?

• A. 10.0.4.0 to 10.0.4.15
• B. 10.0.4.0 to 10.0.32.0
• C. 10.0.4.0 to 10.0.4.28
• D. 10.0.0.0 to 10.0.16.0

7. 기업 네트워크의 크기는 10.0.0.0/8이고, 위성 사무실의 크기가 192.168.0.0/16입니다. 추후 두 네트워크를 연결할 계획이라면, AWS VPC에 적합한 CIDR은 다음 중 무엇인가요 ?

• A. 172.16.0.0/12
• B. 172.16.0.0/16
• C. 10.0.16.0/16
• D. 192.168.4.0/18

✅ CIDR이 겹쳐서는 안 되며, AWS 내 최대 CIDR의 크기는 /16입니다.

8. 최소 28개의 EC2 인스턴스를 위한 용량을 갖는 서브넷을 생성하려 합니다. 이 경우, 서브넷에 필요한 최소 크기는 무엇인가요 ?

• A. /28
• B. /27
• C. /26
• D. /25

9. VPC 엔드 포인트를 사용할 경우, 인터페이스 엔드포인트가 아닌 게이트웨이 엔드 포인트를 갖는 두 개의 AWS 서비스는 무엇인가요 ?

• A. Amazon S3 및 Amazon SQS
• B. Amazon SQS 및 DynamoDB
• C. Amazon S3 및 DynamoDB

✅ 이 두 개의 서비스는 VPC 게이트웨이 엔드 포인트를 가지며, 이들을 제외한 나머지 모두 인터페이스 엔드포인트를 가집니다.

10. VPC에 새로운 서브넷을 생성할 때마다, AWS는 5개의 IP 주소를 예약합니다. CIDR 10.0.0.0/24로 서브넷을 생성할 경우, 다음 중 ( )를 제외한 IP 주소들이 예약됩니다.

• A. 10.0.0.1
• B. 10.0.0.2
• C. 10.0.0.3
• D. 10.0.0.4

11. 4개의 서브넷을 갖는 새로운 VPC를 생성했습니다. 이 서브넷들의 내부에 한 세트의 EC2 인스턴스를 실행했으나, 이 EC2 인스턴스들에 공용 호스트 이름이 할당되어 있지 않고, DNS resolution이 작동되고 있지 않다는 사실을 발견했습니다. 이 문제를 해결하기 위해서는 어떻게 해야 할까요 ?

• A. VPC에 DNS Resolution과 DNS Hostnames를 활성화
• B. 서브넷에 연결된 라우팅 테이블을 확인
• C. 인터넷 게이트웨이의 정상 작동 여부를 확인

12. 여러분은 3개의 VPC A, B, C가 있습니다. 3개의 모든 VPC 간에 VPC 피어링 연결을 설정하려고 합니다. 어떻게 해야 할까요 ?

• A. VPC 피어링은 전이적 피어링을 지원하므로 2개의 VPC 피어링 연결(AB, BC)을 설정해야 합니다.
• B. 3개의 VPC 피어링 연결 설정(AB, AC, BC)

13. VPC의 IP 트래픽에 대한 정보는 어떻게 포착할 수 있을까요 ?

• A. VPC Flow 로그 활성화
• B. VPC 트래픽 미러링 활성화
• C. CloudWatch 트래픽 로그 활성화

✅ VPC Flow Logs는 VPC 기능으로, VPC에서 네트워크 인터페이스로 드나드는 IP 트래픽에 대한 정보를 포착할 수 있게 해줍니다.

14. 기업의 데이터 센터와 AWS 간의 500Mbps Direct Connect 연결을 위해서는 ( ) 연결을 선택해야 합니다.

• A. 전용 Dedicated
• B. Hosted Direct Connect

✅ Hosted Direct Connect 연결은 50Mbps와 500Mbps를 지원하며, 최대 10Gbps까지 지원합니다.

15. VPC 내의 사설 서브넷에 호스팅된 내부 웹 애플리케이션이 있으며, 이 애플리케이션을 다른 고객들이 사용할 수 있게 하려 합니다. 애플리케이션이 인터넷으로 노출되거나, 전체 VPC가 다른 고객들에게 공개되어서는 안 됩니다. 어떻게 해야 할까요 ?

• A. NAT Gateway 사용
• B. VPC 엔드포인트 서비스(AWS PrivateLink) 사용
• C. VPC Peering 사용

✅ VPC 엔드포인트 서비스를 사용하면 애플리케이션을 인터넷에 공개하지 않고 VPC 피어링 연결을 사용할 필요 없이 사설 애플리케이션을 다른 AWS 고객들에게 노출할 수 있습니다.

16. 기업의 온프레미스 데이터 센터와 AWS Cloud 내 VPC 사이에서 AWS 사이트 대 사이트 VPN 연결을 설정할 경우, 이 연결을 구성하는 데에 있어서 가장 중요한 두 구성 요소가 되는 것은 무엇인가요 ?

• A. 고객 게이트웨이와 NAT Gateway
• B. 인터넷 게이트웨이와 고객 게이트웨이
• C. 가상 프라이빗 게이트웨이와 인터넷 게이트웨이
• D. 가상 프라이빗 게이트웨이와 고객 게이트웨이

17. 여러분의 기업이 수백 명의 고객에게 SaaS로 판매할 REST API를 생성했습니다. 기업의 고객들은 AWS 상에 있으며 자체 VPC를 사용하고 있습니다. 인프라가 네트워크 공격에 노출되지 않으면서도 고객들이 공용 인터넷을 거치지 않고도 SaaS로 액세스할 수 있게 하려 합니다. 어떤 방법을 추천할 수 있을까요 ?

• A. VPC 엔드 포인트 생성하기
• B. VPC 피어링 연결 생성하기
• C. PrivateLink(VPC 엔드 포인트 서비스) 생성
• D. ClassicLink 생성

18. 여러분의 기업은 미국 전역에 몇 개의 온프레미스 사이트를 갖고 있습니다. 이 사이트들은 현재 프라이빗 연결을 사용해 연결되어 있으나, 최근에는 프라이빗 연결 제공자가 상당히 불안해져 IT 아키텍처의 일부가 오프라인 상태가 되었습니다. 여러분은 온프레미스 사이트들을 연결하기 위해 공용 인터넷을 사용하는 백업 연결을 생성하여, 제공 업체에 문제가 발생한 경우 장애 조치로 사용을 하려 합니다. 어떤 방법을 추천할 수 있을까요 ?

• A. VPC 피어링
• B. AWS VPN 클라우드 허브
• C. Direct Connect
• D. AWS PrivateLink

✅ AWS VPN CloudHub는 AWS VPN을 통한 다수 사이트 간의 안전한 통신을 가능하게 해줍니다. 이는 VPC와 함께 또는 VPC 없이 사용할 수 있는 단순한 허브 및 스포크 모델로 운용됩니다.

19. 온프레미스 기업의 데이터 센터와 AWS Cloud 간의 전용 연결을 설정해야 합니다. 이 연결은 프라이빗이어야 하고, 지속적이어야 하며 트래픽이 인터넷을 통해 이동해서는 안됩니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. Site to Site VPN
• B. AWS PrivateLink
• C. AWS Direct Connect
• D. Amazon EventBridge

20. Direct Connect 연결을 사용해 공용 및 프라이빗 AWS 리소스 모두에 액세스할 수 있습니다.

• A. 참
• B. 거짓

21. 온프레미스 데이터와 AWS Cloud 간에 구축된 AWS 사이트 대 사이트 VPC 연결 처리량을 단일 IP초 터널의 최대 제한인 1.25Gbps 이상으로 스케일 업하려 합니다. 어떻게 해야 할까요 ?

• A. 2개의 가상 프라이빗 게이트웨이를 사용
• B. Direct Connect Gateway 사용
• C. Transit Gateway 사용

22. AWS 계정에 듀얼 스택 모드에서 실행되는 VPC가 있습니다. EC2 인스턴스를 실행하려 계속 시도하고 있으나 실패하고 있는 상황입니다. 더 조사를 해본 결과, IPv4 주소를 사용할 수 없다는 점을 알아냈습니다. 어떻게 해야 할까요 ?

• A. VPC을 수정해 IPv4 모드만을 실행하게 만들기
• B. VPC로 IPv4 CIDR 추가하기

1. 전송 중 암호화(이행 중 암호화)를 암호화하기 위해서는 ( )가 필요합니다.

• A. SSL 인증서를 가진 HTTP 엔드 포인트
• B. SSL 인증서를 가진 HTTPS 엔드 포인트
• C. TCP 엔드포인트

✅ 전송 중 암호화 = HTTPS이며, HTTPS는 SSL 인증서 없이 활성화될 수 없습니다.

2. 서버 측 암호화는 데이터가 암호화된 상태로 서버로 보내진다는 의미입니다.

• A. 맞습니다.
• B. 아닙니다.

✅ 서버 측 암호화는 서버가 데이터를 암호화해 준다는 의미입니다.

3. 서버 측 암호화에서 암호호와 복호화는 어디에서 이루어지나요 ?

• A. 암호화와 복호화 모두 서버에서 이루어짐
• B. 암호화와 복호화 모두 클라이언트 측에서 이루어짐
• C. 암호화는 서버에서 이루어지며, 복호화는 클라이언트 측에서 이루어짐
• D. 암호화는 클라이언트 측에서 이루어지며, 복호화는 서버에서 이루어짐

4. 클라이언트 측 암호화의 경우, 데이터를 업로드하기 전에 서버가 암호화 체계를 알고 있어야 합니다.

• A. 아닙니다.

• B. 맞습니다.

  ✅ 클라이언트 측 암호화를 사용할 경우, 서버에서 암호화 또는 복호화 작업을 수행하지 않기 때문에 사용된 암호화 체계에 대한 어떤 정보도 알 필요가 없습니다.

5. EBS, S3, RDS에 대한 암호화 기능을 사용하려면 AWS KMS 내에서 KMS 키를 먼저 생성해야 합니다.

• A. 맞습니다.
• B. 아닙니다.

✅ KMS에서 AWS 관리 서비스 키를 사용할 수 있으므로, 자체적인 KMS 키를 생성할 필요가 없습니다.

6. AWS KMS Key는 대칭 및 비대칭 KMS 키 모두를 지원합니다.

• A. 맞습니다.
• B. 아닙니다.

✅ KMS 키는 대칭일 수도, 비대칭일 수도 있습니다. 대칭 KMS 키는 암호화와 복호화에 사용되는 256비트 키를 나타냅니다. 비대칭 KMS 키는 암호화 및 복호화, 혹은 서명과 검증에 사용되는 RSA 키 쌍을 나타내지만, 둘 다에 사용되지는 않습니다. 혹은 서명 및 검증에 사용되는 타원 곡선 (ECC) 키 쌍을 나타냅니다.

7. KMS 키는 자동 교체를 활성화하면 백업 키가 매 ( )마다 교체됩니다.

• A. 90일
• B. 1년
• C. 2년
• D. 3년

8. KMS CMK를 사용해 암호화된 EBS 스냅샷이 있는 AMI가 있습니다. 이 AMI를 다른 AWS 계정과 공유하려 합니다. AMI를 원하는 AWS 계정과 공유했으나 다른 AWS 계정에서는 여전히 이를 사용할 수 없는 상태입니다. 이 경우 어떻게 문제를 해결해야 할까요 ?

• A. 다른 AWS 계정이 로그아웃 후 다시 로그인해 자격 증명을 새로고침해야 함
• B. AMI를 암호화하는 데에 사용된 KMS CMK를 다른 AWS 계정과 공유해야 함
• C. 암호화된 EBS 스냅샷을 가진 AMI는 공유할 수 없음

9. S3 버킷과 EBS 스냅샷 모두를 암호화하는 데에 사용한 고객 관리형 CMK를 KMS에서 생성했습니다. 기업 정책에 따라 암호화 키를 매 3개월마다 교체해야 합니다. 어떻게 해야 할까요 ?

• A. KMS CMK를 다시 구성해 자동 교체를 활성화하고, "Period(기간)"를 3개월로 선택
• B. AWS에 의해 3개월마다 자동으로 교체되는 AWS 관리 키를 사용
• C. KMS CMK를 수동으로 교체, KMS CMK를 생성하고 키 별칭을 사용해 새로운 KMS CMK를 참조, 오래된 데이터의 복호화를 위해 기존의 KMS CMK는 유지

10. KMS CMK에 대한 액세스를 제어하기 위해서는 다음 중 어떤 방법을 사용해야 할까요 ?

• A. KMS 키 정책
• B. KMS IAM 정책
• C. AWS GuardDuty
• D. KMS Access Control List (KMS ACL)

11. 데이터베이스 내에서 데이터를 차리하던 Lambda 함수가 있습니다. Lambda 함수에 데이터베이스 비밀번호에 대한 액세스를 부여하려 합니다. 이를 위해서는 다음 중 어떤 옵션을 사용하는 게 가장 안전할까요 ?

• A. 코드에 임베딩
• B. 평문 환경 변수로 만들기
• C. 암호화된 환경 변수로 만들고 런타임에서 복호화

12. 암호화 목적으로 사용하는 암호 값이 있고, 시간 경과에 따라 암호의 값을 저장하고 추적하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. AWS KMS 버전 관리 기능
• B. SSM 파라미터 스토어
• C. Amazon S3

✅ SSM 파라미터 스토어는 암호를 저장하는 데에 사용될 수 있으며, 추적 기능이 내장되어 있습니다. 파라미터의 값을 감사할 때마다 SSM 파라미터 스토어가 파라미터의 새 버전을 생성하고 기존의 버전을 보관합니다. 값을 포함한 모든 파라미터 버전의 내역을 상세히 볼 수 있습니다.

13. AWS 공동 책임 모델에 따르면, 다음 중 여러분이 RDS에서 맡고 있는 책임은 무엇인가요 ?

• A. 보안 그룹 규칙
• B. OS 패치
• C. 데이터베이스 엔진 패치
• D. 내부 하드웨어 보안

✅ 보안 그룹 규칙의 경우 여러분이 직접 구성해야 합니다.

14. 사용자 대면 웹사이트는 디도스 공격에 취약하며, 여러분은 이러한 공격에 대비해 지원을 받고자 합니다. AWS는 공격 중 발생한 비용에 대한 배상을 제공하고 있습니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. AWS WAF
• B. AWS Shield Advanced
• C. AWS Shield
• D. AWS DDoS OpsTeam

15. 애플리케이션이 주요 데이터베이스의 구성 값을 외부적으로 유지하여 그 값을 런타임 시 선택할 수 있도록 하려 합니다. 제어와 버전 내역을 유지하기 위해서는 다음 중 어떤 장소에 구성 값을 저장해야 할까요 ?

• A. Amazon DynamoDB
• B. Amazon S3
• C. Amazon EBS
• D. SSM Parameter Store'

16. 암호화 키를 관리하고, 이들을 완전히 제어하기 위해 전용 하드웨어 모듈을 사용하려 합니다. 어떤 방법을 추천할 수 있을까요 ?

• A. AWS CloudHSM
• B. AWS KMS
• C. AWS Parameter Store

17. AWS GuardDuty는 다음 중 ( )를 제외한 데이터 소스를 스캔합니다.

• A. CloudTrail 로그
• B. VPC Flow 로그
• C. DNS 로그
• D. CloudWatch 로그

18. Application Load Balancer가 관리하는 한 세트의 EC2 인스턴스에 웹사이트가 호스팅되어 있습니다. 일반적인 웹 애플리케이션 공격(예: SQL 주입)으로부터 웹사이트를 보호하기 위해서는 다음 중 어떤 방법을 사용해야 할까요 ?

• A. AWS Shield
• B. AWS WAF
• C. AWS Security Hub
• D. AWS GuardDuty

19. EC2 인스턴스의 OS 취약점을 분석하려 합니다. 분석은 매주 수행되어야 하며, 취약점 발견 시 구체적인 권장 사항을 제공해야 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. AWS Shield
• B. Amazon GuardDuty
• C. Amazon Inspector
• D. AWS Config

20. 다음 중 자동 순환을 지원하며, RDS DB 비밀번호를 저장하는 데에 가장 적합한 AWS 서비스는 무엇인가요 ?

• A. AWS Secrets Manager
• B. AWS KMS
• C. AWS SSM Parameter Store

21. AWS 조직 내 AWS 계정 전체의 EC2 보안 그룹과 AWS Shield Advanced를 중앙에서 관리하기 위해서는 다음 AWS 서비스 중 무엇을 사용해야 할까요 ?

• A. AWS Shield
• B. AWS GuardDuty
• C. AWS Config
• D. AWS Firewall Manager

✅ AWS Firewall Manager는 보안 관리 서비스로 AWS Organizations에 있는 계정과 애플리케이션 간에서 방화벽 규칙을 구성하고 중앙 관리할 수 있게 해줍니다. AWS Organizations에 통합되어 있기 때문에, AWS WAF 규칙, AWS Shield Advanced 보호, 보안 그룹, AWS Network Firewall 규칙, Amazon Route 53 Resolver와 DNS 방화벽 규칙을 활성화할 수 있습니다.

22. 다음 중 S3 버킷에 저장된 민감한 데이터를 보호하기 위해서는 어떤 AWS 서비스를 사용해야 할까요 ?

• A. Amazon GuardDuty
• B. Amazon Shield
• C. Amazon Macie
• D. AWS KMS

✅ Amazon Macie는 완전 관리형 데이터 보안 서비스로, 머신 러닝을 사용해 S3 버킷 내에 저장된 민감한 데이터를 발견하고 보호합니다. 이는 암호화되지 않은 버킷의 목록, 공용으로 액세스 가능한 버킷 및 다른 AWS 계정과 공유된 버킷을 포함한 S3 버킷의 인벤토리를 자동으로 제공합니다. 이를 사용하면, 개인 식별 정보(PII)와 같이 민감한 데이터를 식별해 경고해 줍니다.

Terraform 명령어로 EC2 생성

생성된 EC2 정보

• 퍼블릭 IPv4 주소: 52.79.236.180
• 프라이빗 IPv4 주소: 172.31.47.65

SSH EC2 접속

ssh -v -i ~/.ssh/linux.pem -o IdentitiesOnly=yes ec2-user@52.79.236.180

EC2 Connect 로그 분석

서버에 원격 접속하기 위해 연결 프로세스 시작

OpenSSH_8.6p1, LibreSSL 3.3.6 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 21: include /etc/ssh/ssh_config.d/* matched no files debug1: /etc/ssh/ssh_config line 54: Applying options for * debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug1: Connecting to 52.79.236.180 [52.79.236.180] port 22. debug1: Connection established.

SSH 프로토콜 버전 교환

debug1: identity file /Users/jinhyeokhong/.ssh/linux.pem type -1 debug1: identity file /Users/jinhyeokhong/.ssh/linux.pem-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_8.6 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4 debug1: compat_banner: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002

• SSH는 양측이 서로에게 버전 문자열을 보내는 것으로 시작됩니다. 핸드셰이크의 한 부분으로서 SSH 설계의 몇 가지 결함으로 인해 대부분의 최신 클라이언트와 서버는 SSH 2.0만 지원한다는 점에 유의해야 합니다.

  키교환 과정(Elliptic Curve Diffie-Hellman 방식)

  Elliptic Curve Diffie-Hellman Initialization

  debug1: Authenticating to 52.79.236.180:22 as 'ec2-user' debug1: load_hostkeys: fopen /Users/jinhyeokhong/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ssh-ed25519
• SSH 키 교환(KEX)은 양쪽에서 SSH_MSG_KEX_INIT 메시지를 서로에게 보내면서 시작됩니다. 이 메시지는 선호도를 반영하는 순서로 지원하는 암호화 기본 형식의 목록입니다.
• 암호화 기본 요소는 키 교환을 수행한 다음 대량 데이터 암호화를 수행하는 데 사용할 빌딩 블록을 설정하는 것입니다.
• 양측은 동일한 알고리즘을 사용하여 지원 목록에서 암호화 프리미티브를 선택하기 때문에 키 교환 초기화 후 키 교환을 즉시 시작할 수 있습니다. ECDH(Elliptic Curve Diffie-Hellman)으로 클라이언트가 임시 키 쌍(개인 및 관련 공개 키)을 생성하고 SSH2_MSG_KEXINIT 메시지로 서버에 공개 키를 보내는 것으로 키 교환이 시작됩니다.

  Key Exchange(KEX)	Symmetric Cipher	Message Authentication Code(Mac)	Server Host Key Algorithm
  curve25519-sha256@libssh.org	chacha20-poly1305@openssh.com	hmac-sha2-256-etm@openssh.com	ssh-rsa-cert-y01@openssh.com
  ecdh-sha2-nistp256	aes128-gcm@openssh.com	hmac-sha2-256	ssh-rsa
  ecdh-sha2-nistp384	aes256-ctr
  ecdh-sha2-nistp521	aes192-ctr
  	aes128-ctr

  임시 키쌍 공유

  debug1: kex: server->client cipher: chacha20-poly1305@openssh.comMAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none

• 하지만 이 키 쌍은 임시적이며 키 교환 중에만 사용되며 나중에 폐기됩니다. 이러한 방식은 공격자가 미래의 언젠가 개인 키를 훔칠 기회를 엿보고 암호화된 트래픽을 수동적으로 기록하는 공격 클래스를 극도로 어렵게 만듭니다. 따라서 교환 중에 탈취당했다고 해도 키 교환 중에만 사용하고 폐기되는 키 쌍이기 때문에 무용지물이 됩니다. 이러한 속성을 순방향 비밀성이라고 합니다.

  Elliptic Curve Diffie-Hellman Reply

  debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug1: SSH2_MSG_KEX_ECDH_REPLY received
  debug1: Server host key: ssh-ed25519 SHA256:FZWagooddK7helloNQgMI1y3FLJF6q+lvz/PNj1Ads debug1: load_hostkeys: fopen /Users/jinhyeokhong/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory debug1: hostkeys_find_by_key_hostfile: hostkeys file /Users/jinhyeokhong/.ssh/known_hosts2 does not exist debug1: hostkeys_find_by_key_hostfile: hostkeys file /etc/ssh/ssh_known_hosts does not exist debug1: hostkeys_find_by_key_hostfile: hostkeys file /etc/ssh/ssh_known_hosts2 does not exist The authenticity of host '52.79.236.180 (52.79.236.180)' can't be established. ED25519 key fingerprint is SHA256:FZWaItntdK7wCjNJHELLOI1y3FLJF6q+lvz/Pgoods. This key is not known by any other names

  로컬 데이터베이스에 호스트 키 추가

• Are you sure you want to continue connecting (yes/no/[fingerprint])? *yes Warning: Permanently added '52.79.236.180' (ED25519) to the list of known hosts.
• 로컬 데이터베이스에 호스트 키를 추가하도록 요청하는 SSH 클라이언트. OpenSSH의 경우 일반적으로 ~/.ssh/known_hosts입니다.

  New keys

  debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey in after 134217728 blocks debug1: Will attempt key: /Users/jinhyeokhong/.ssh/linux.pem explicit debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> debug1: SSH2_MSG_SERVICE_ACCEPT received

• 교환 해시는 다음 필드의 해시(키 교환 알고리즘에 따라 SHA256, SHA384 또는 SHA512)를 사용하여 생성됩니다.

  최종 연결

  debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Next authentication method: publickey debug1: Trying private key: /Users/jinhyeokhong/.ssh/linux.pem debug1: Authentication succeeded (publickey). Authenticated to 52.79.236.180 ([52.79.236.180]:22). debug1: channel 0: new [client-session] debug1: Requesting no-more-sessions@openssh.com debug1: Entering interactive session. debug1: pledge: filesystem full debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0 debug1: client_input_hostkeys: searching /Users/jinhyeokhong/.ssh/known_hosts for 52.79.236.180 / (none) debug1: client_input_hostkeys: searching /Users/jinhyeokhong/.ssh/known_hosts2 for 52.79.236.180 / (none) debug1: client_input_hostkeys: hostkeys file /Users/jinhyeokhong/.ssh/known_hosts2 does not exist debug1: Sending environment. debug1: channel 0: setting env LC_TERMINAL_VERSION = "3.4.15" debug1: channel 0: setting env LANG = "ko_KR.UTF-8" debug1: channel 0: setting env LC_TERMINAL = "iTerm2" Learned new hostkey: RSA SHA256:gtc6vF/Uit3fyV9LzqZshelloiUDQnM+Vz+pUorgood Learned new hostkey: ECDSA SHA256:XCIsShelloEscqDlKZfveryqgaakNRKZHPgoodM7Cc Adding new key for 52.79.236.180 to /Users/jinhyeokhong/.ssh/known_hosts: ssh-rsa SHA256:gtc6vF/Uit3fyV9LzqZshelloiUDQnM+Vz+pUorgood Adding new key for 52.79.236.180 to /Users/jinhyeokhong/.ssh/known_hosts: ecdsa-sha2-nistp256 SHA256:XCIsShelloEscqDlKZfveryqgaakNRKZHPgoodM7Cc debug1: update_known_hosts: known hosts file /Users/jinhyeokhong/.ssh/known_hosts2 does not exist

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

  https://aws.amazon.com/amazon-linux-2/ 16 package(s) needed for security, out of 26 available Run "sudo yum update" to apply all updates.

~/.ssh/known_hosts에 추가된 new key

• 서버의 공개키가 로컬에 저장되있는 것을 확인할 수 있다.

SSH Key란 ?

서버에 접속할 때 비밀번호 대신 key를 제출하는 방식이다. SSH Key는 언제 사용하는가 ?

• 비밀번호보다 높은 수준의 보안을 필요로 할 때
• 로그인 없이 자동으로 서버에 접속할 때

SSH Key가 동작하는 방식

SSH Key는 공개키(public key)와 비공개 키(private key)로 이루어지는데 이 두개의 관계를 이해나는 것이 SSH Key를 이해하는데 핵심이다. 키를 생성하면 공개키와 비공개키가 만들어진다. 이 중에 비공개키는 로컬 머신(SSH Client)에 위치해야 하고, 공개키는 리모트 머신(SSH Server)에 위치해야 한다.

AWS STS (Security Token Service)

• Allows to grant limited and temporary access to AWS resources.
• Token is valid for up to one hour (must be refreshed)
• AssumeRole Within your own account: for enhanced security Cross Account Access: assume role in target account to perform actions there

• AssumeRoleWithSAML: return credentials for users logged with SAML
• AssumeRoleWithWebIdentity:
• returen creds for users logged with an IdP (Facebook, Google, OIDC...)
• AWS recommends against using this, and using Cognito instead
• GetSessionToken: for MFA, from a user or AWS account root user

Using STS to Assume a Role

• Define an IAM Role within your account or cross-account
• Define which principals can access this IAM Role
• Use AWS STS to retrive credentials and impersonate the IAM Role you have access to (AssumeRole API)
• Temporary credentials can be valid between 15 minutes to 1 hour

Identity Federation in AWS

• Federation lets users outside of AWS to assume temporary role for accessing AWS resources.
• These users assume identity provided access role.

  Federations can have many flavors:

• SAML 2.0
• Custom Identity Broker
• Web Identity Federation with Amazon Cognito
• Web Identity Federation without Amazon Cognito
• Single Sign On
• Non-SAML with AWS Microsoft AD

✅ Using federation, you don't need to create IAM users (user management is outside of AWS)

AWS Security Token Service (AWS STS)를 사용하면 AWS 리소스에 대한 액세스를 제어할 수 있는 임시 보안 자격 증명을 생성하여 신뢰받는 사용자에게 제공할 수 있습니다. 임시 보안 자격 증명은 다음과 같은 차이점을 제외하고는 IAM 사용자가 사용할 수 있는 장기 액세스 키 자격 증명과 거의 동일한 효력을 지닙니다.

• 임시 보안 자격 증명은 그 이름이 암시하듯 단기적입니다. 이 자격 증명은 몇 분에서 몇 시간까지 지속되도록 구성할 수 있습니다. 자격 증명이 만료된 후 AWS는 더는 그 자격 증명을 인식하지 못하거나 그 자격 증명을 사용한 API 요청으로부터 이루어지는 어떤 종류의 액세스도 허용하지 않습니다.

• 임시 보안 자격 증명은 사용자와 함께 저장되지 않지만 동적으로 생성되어 요청시 사용자에게 제공됩니다. 임시 보안 자격 증명이 만료되었을 때(심지어는 만료 전이라도) 사용자는 새 자격 증명을 요청할 수 있습니다. 단, 자격 증명을 요청하는 해당 사용자에게 그렇게 할 수 있는 권한이 있어야 합니다.

이러한 차이점은 다음과 같은 임시 자격 증명 사용의 이점을 발생시킬 수 있습니다.

• 애플리케이션으로 장기 AWS 보안 자격 증명을 배포 또는 포함할 필요가 없습니다.

• 사용자에 대한 AWS 자격 증명을 정의하지 않고도 AWS 리소스에 대한 액세스 권한을 사용자에게 제공할 수 있습니다. 임시 자격 증명은 역할 및 ID 페더레이션을 위한 기초입니다.
• 임시 보안 자격 증명은 수명이 제한되어 있어서, 더 이상 필요하지 않을 때 교체하거나 명시적으로 취소할 필요가 없습니다. 임시 보안 자격 증명이 만료된 후에는 다시 사용할 수 없습니다. 그 자격 증명에 대해 유효 기간을 최대 한계까지 지정할 수 있습니다.

AWS STS 및 AWS 리전

임시 보안 자격 증명은 AWS STS에 의해 생성됩니다. 기본적으로 AWS STS는 https://sts.amazonaws.com에 단일 엔드포인트가 있는 전역적 서비스입니다. 그러나 지원되는 기타 다른 리전에서 엔드포인트에 대한 AWS STS API 호출을 할 수도 있습니다. 이렇게 지리적으로 더 가까운 리전에 있는 서버로 요청을 전송함으로써 지연 시간(서버 랙)을 단축할 수 있습니다. 자격 증명은 어떤 리전에서 오는지 상관없이 전역적으로 유효합니다.

임시 자격 증명과 관련된 일반적인 시나리오

임시 자격 증명은 ID 페더레이션, 위임, 교차 계정 액세스, IAM 역할 등의 시나리오에서 유용합니다.

ID 페더레이션

AWS 밖의 외부 시스템에서 사용자 자격 증명을 관리할 수 있고 해당 시스템을 통해 로그인하는 사용자에게 액세스 권한을 부여하여 AWS 작업을 수행하고 AWS 리소스에 액세스할 수 있습니다. IAM은 두 가지 ID 페더레이션 유형을 지원합니다. 두 경우 모두 자격 증명은 AWS 외부에 저장됩니다. 외부 시스템이 상주하는 위치, 즉 데이터 센터 또는 웹의 외부 서드 파티에 따라 구분됩니다.

• 엔터프라이즈 ID 페더레이션: 조직의 네트워크에서 사용자를 인증한 다음, 해당 사용자에 대한 새로운 AWS 자격 증명을 생성하지 않고 또한, 사용자에게 별도의 사용자 이름 및 암호로 로그인하도록 요구하지 않고도 AWS에 대한 액세스 권한을 사용자에게 제공할 수 있습니다. 이는 임시 액세스 권한에 대한 SSO(Single Sign-On) 접근 방식으로 알려져 있습니다. AWS STS는 SAML 2.0(Security Assertion Markup Language 2.0)과 같은 개방형 표준을 지원합니다. 이를 통해 Microsoft AD FS를 사용해 Microsoft Active Directory를 최대한 활용할 수 있습니다. 또한, SAML 2.0을 사용해 사용자 자격 증명 연동을 위한 자신만의 솔루션을 관리할 수 있습니다.

  • 사용자 지정 페더레이션 브로커: 조직의 인증 시스템을 사용해 AWS 리소스에 대한 액세스 권한을 부여할 수 있습니다.
  • SAML 2.0을 사용한 페더레이션: 조직의 인증 시스템과 SAML을 사용해 AWS 리소스에 대한 액세스 권한을 부여할 수 있습니다.

• 웹 ID 페더레이션 - Login with Amazon, Facebook, Google 또는 OpenID Connect(OIDC) 2.0 호환 공급자와 같은 유명한 서드 파티 자격 공급자를 사용해 사용자가 로그인할 수 있습니다. 그 공급자로부터 얻은 자격 증명을 AWS 계정 리소스 사용 권한과 교환할 수 있습니다. 이는 임시 액세스 권한에 대한 웹 ID 페더레이션을 사용하면 사용자 지정 로그인 코드를 생성하거나 자신의 사용자 자격 증명을 관리할 필요가 없습니다. 웹 ID 페더레이션을 사용하면 AWS 계정을 안전하게 보호할 수 있는 이점이 있습니다. 애플리케이션으로 IAM 사용자 액세스 키 같은 장기 보안 자격 증명을 배포할 필요가 없기 때문입니다.

모바일 애플리케이션의 경우 Amazon Cognito를 사용하는 것이 좋습니다. 이 서비스와 함께 AWS Mobile SDK for IOS 및 AWS Mobile SDK for Android and Fire OS를 사용하면 사용자의 고유 자격 증명을 생성하고 사용자를 인증하여 AWS 리소스에 안전하게 액세스하도록 할 수 있습니다. Amazon Cognito는 AWS STS와 동일한 자격 증명 공급자를 지원하고 인증되지 않은 액세스도 지원하며 사용자가 로그인할 때 사용자 데이터를 마이그레이션 할 수 있습니다. 또한, Amazon Cognito는 사용자가 디바이스간에 이동할 때 데이터가 보존되도록 사용자 데이터를 동기화하기 위한 API 작업도 제공합니다.

SAML 2.0

AWS는 많은 자격 증명 공급자(IdP: Identity Provider)가 사용하는 개방형 표준인 SAML 2.0(Security Assertion Markup Language 2.0)이라는 ID 페더레이션을 지원합니다. 이 기능은 페더레이션 통합 인증(SSO)을 활성화하므로 조직의 모든 구성원에 대해 IAM 사용자를 생성하지 않아도 사용자가 AWS Management Console에 로그인하거나 AWS API 작업을 호출할 수 있습니다. SAML을 사용함으로써 AWS로 연동을 구성하는 과정을 단순화할 수 있는데, 이는 사용자 지정 자격 증명 프록시 코드를 작성하는 대신 IdP의 서비스를 사용할 수 있기 때문입니다.

IAM 페더레이션은 다음과 같은 사용 사례를 지원합니다.

AWS에 대한 API 액세스를 위해 SAML 기반 페더레이션 사용

직원들에게 자신의 컴퓨터에서 백업 폴더로 데이터를 복사하는 방법을 제공하려 한다고 가정해 봅시다. 사용자가 컴퓨터에서 실행하는 애플리케이션을 구축합니다. 그 애플리케이션은 백엔드에서 S3 버킷에 있는 객체를 읽고 씁니다. 사용자는 AWS에 직접 액세스할 수 없습니다. 그 대신 다음 프로세스를 사용합니다.

1. 조직 내 사용자가 클라이언트 앱을 사용해 조직의 IdP로부터 인증을 요청
2. IdP가 조직의 자격 증명 스토어를 이용하여 사용자를 인증
3. IdP가 사용자에 대한 정보로 SAML 어설션을 만들어 클라이언트 앱으로 전송
4. 클라이언트 앱이 AWS STS AssumeRoleWithSAML API를 호출하면서 SAML 공급자의 ARN, 수임할 역할의 ARN, IdP로부터 받은 SAML 어설션을 전달
5. 클라이언트 앱에 대한 API 응답에는 임시 보안 자격 증명이 포함
6. 클라이언트 앱이 임시 보안 자격 증명을 사용하여 Amazon S3 API 작업을 호출

사용자 지정 자격 증명 브로커가 AWS 콘솔에 액세스할 수 있도록 하기

코드를 작성하고 실행해 조직 네트워크에 로그인하는 사용자가 AWS Management Console에 안전하게 액세스할 수 있게 하는 URL을 생성할 수 있습니다. URL에는 AWS에서 얻고 AWS에 사용자를 인증하는 로그인 토큰이 포함되어 있습니다. 조직의 사용자가 AWS Management Console에 액세스할 수 있도록 하는 경우 다음 단계를 수행하여 사용자 지정 자격 증명 브로커를 생성할 수 있습니다.

1. 사용자가 로컬 자격 증명 시스템에 의해 인증되는지 확인
2. AWS Security Token Service AssumeRole(권장) 또는 GetFederationToken API 작업을 호출하여 사용자를 위한 임시 보안 자격 증명을 얻을 수 있습니다.
3. AWS 연동 엔드포인트를 호출하고 임시 보안 자격 증명을 제공하여 로그인 토큰을 요청
4. 토큰을 포함하는 콘솔에 대한 URL 생성
5. 사용자에게 URL을 부여하거나 사용자 대신 URL 호출

Microsoft Active Directory (AD)

Microsoft AD란 AD 도메인 서비스와 함께 모든 Windows 서버에서 찾을 수 있는 소프트웨어입니다. 객체 데이터베이스이고 여기서 객체는 사용자 계정과 컴퓨터, 프린터, 파일 공유 보안 그룹이 될 수 있습니다. 전체 Microsoft 생태계에서 온프레미스로 관리되는 모든 사용자는 Microsoft AD에서 관리됩니다. 중앙 보안 관리로서 계정을 만들고 허가를 발급하는 등의 작업을 할 수 있으며 모든 객체들은 트리(tree)로 조직화되며 트리의 그룹은 포리스트(forest)라는 용어로 부릅니다.

예를 들어 도메인 제어기가 있다고 가정했을 때 여기에 계정을 만들건데 사용자 이름은 John 암호는 password입니다. 네트워크 내에 있는 모든 Windows 머신들이 이 도메인 제어기에 연결될 것이고 첫 번째 머신에 방금 만든 계정을 입력하면 제어기 내에서 계정 정보를 찾아 계정 정보가 일치할 경우 그 머신에서 로그인하게 해줍니다. 머신들이 전부 도메인 제어기에 연결되기 때문에 어떤 머신에서도 사용자가 액세스 가능하도록 할 수 있습니다. 그게 Active Directory의 대략적인 개념입니다.

AWS Directory Services

AWS Managed Microsoft AD

• 로컬에서 사용자 관리, 멀티팩터 인증 지원
• 사용자가 있는 다른 온프레미스 AD와 신뢰 관계 생성

  AD Connector

• 온프레미스 AD로 리디렉트, 온프레미스 AD에서만 사용자를 관리하는 Directory Gateway
• 사용자가 AD Connector로 로그인하면 그 요청을 온프레미스 AD로 프록시하여 탐색

  Simple AD

  Simple AD는 다음에서 완벽하게 관뢰되는 Samba 기반 디렉터리를 생성합니다. AWS 클라우드 Simple AD를 사용하여 디렉터리를 만들 때 AWS Directory Service가 사용자를 대신하여 자동으로 두 개의 도메인 컨트롤러와 DNS 서버를 생성합니다. 도메인 컨트롤러는 VPC 내의 서로 다른 서브넷에 생성됩니다. 이 중복으로 인해 장애가 발생하더라도 디렉터리에 액세스할 수 있습니다.

온프레미스로 사용자를 프록시한다면 AD Connector 또는 AWS 내 클라우드에서 사용자를 관리하고 MFA를 받겠다면 AWS Managed AD, 온프레미스 디렉터리가 없는 경우 필요한 걸 물어본다면 Simple AD

AWS Organizations

AWS Organizations는 여러 AWS 계정을 사용자가 생성하고 중앙에서 관리하는 단일 조직으로 통합할 수 있는 계정 관리 서비스입니다. 조직을 사용하면 멤버 계정을 생성하고, 조직에 가입하도록 기존 계정을 초대할 수 있습니다. 이러한 계정을 그룹으로 구성하고 정책 기반 제어 항목을 연결할 수 있습니다.

Organizations AWS Control Tower에서 결제를 관리하고, 액세스, 규정 준수 및 보안을 제어하고, 멤버 AWS 계정 전체에서 리소스를 공유하는 일을 모두 중앙에서 처리할 수 있습니다. 계정은 조직 단위(OU)라고 하는 논리 그룹으로 그룹화됩니다.

SCP (Service Control Policies)

SCP(서비스 제어 정책)는 조직의 권한을 관리하는 데 사용할 수 있는 조직 정책 유형입니다. SCP는 조직의 모든 계정에 사용 가능한 최대 권한을 중앙에서 제어합니다. SCP를 사용하면 조직의 액세스 제어 지침에 따라 계정을 유지할 수 있습니다. SCP는 활성화된 모든 기능을 가진 조직에서만 사용할 수 있습니다. 조직이 통합 결제 기능만 지원한다면 SCP를 이용할 수 없습니다.

SCP만으로는 조직 내 계정에 권한을 부여하기에 충분하지 않습니다. SCP는 어떠한 권한도 부여하지 않습니다. SCP는 계정 관리자가 영향을 받는 계정의 IAM 사용자 및 역할에 위임할 수 있는 작업에 대해 권한 범위를 정의하거나 제한을 설정합니다.

1. 어떤 모바일 애플리케이션에서 사용자들이 S3 버킷 내의 개인 공간으로 액세스할 수 있게 만들려 합니다. 이를 위해서는 어떻게 해야 할까요 ?

• A. 애플리케이션의 각 사용자마다 IAM 사용자 자격 증명을 생성
• B. Amazon Cognito 신원 연결을 생성
• C. SAML 신원 연결을 사용
• D. 버킷 정책을 사용해 버킷을 공용으로 만들기

✅ SAML 자격 증명 연동은 Microsoft Active Directory와 같은 자격 증명 공급자 서비스를 AWS와 통합하는 데 사용됩니다. 모바일 애플리케이션에서는 작동하지 않습니다. 반면 Amazon Cognito는 모바일 사용자 계정을 연결하고 이들에게 IAM 권한을 제공하는 방식으로 S3 버킷 내의 개인 공간에 액세스할 수 있게 해줍니다.

2. SAML 2.0을 지원하지 않는 온프레미스 자격 증명 제공자가 있으며, 온프레미스 사용자들에게 여러분이 관리 중인 AWS 계정 내 리소스에 대한 액세스 권한을 부여하려 합니다. 어떻게 해야 할까요 ?

• A. 사용자 지정 자격 증명 브로커를 사용해 사용자들을 인증하고, AssumeRole 또는 GetFederationToken STS 호출을 사용해 AWS STS에서 임시 자격 증명 받기
• B. Microsoft AD 각 사용자의 모든 AWS 계정에 대해 상응하는 IAM 사용자를 생성하는 Lambda 함수를 생성
• C. SAML 신원 연결을 사용

3. 내부 감사가 완료된 AWS 서비스만을 프로덕션에 허용해야 한다는 강력한 규제 요구 사항이 있습니다. 여러분은 서비스 감사가 이루어지는 동안 팀이 개발 환경에서 실험해볼 수 있었으면 합니다. 이를 설정하기 위한 최적의 방법은 무엇일까요 ?

• A. 개발 팀에 완전히 독자적인 AWS 계정을 제공
• B. 글로벌 IAM 정책을 프로덕션 계정에 적용
• C. AWS 조직을 생성해 두 개의 프로덕션 및 Dev OU를 생성한 후, Prod OU에 SCP를 적용
• D. AWS Config 규칙을 생성

4. 온프레미스 Microsoft Active Directory 설정이 있고, 온프레미스 AD 사용자들에게 여러분이 가진 다수의 AWS 계정에 대한 액세스 권한을 부여하고자 합니다. 솔루션은 향후 있을 계정 추가를 위해 스케일링이 가능해야 합니다. 어떤 방법을 추천할 수 있을까요 ?

• A. 각 AWS 계정과 온프레미스 Microsoft AD 사이에서의 SAML 2.0 통합을 설정
• B. Microsoft AD 각 사용자의 모든 AWS 계정에 대해 상응하는 IAM 사용자를 생성하는 Lambda 함수를 생성
• C. Amazon Cognito를 통해 웹 ID 연결을 설정
• D. AWS Single Sign-On 설정

5. 기업용 AWS 계정을 관리하고 있으며, 개발자 중 한 명에게 S3 버킷 내의 파일을 읽을 수 있는 액세스 권한을 부여하려 합니다. 여러분은 버킷 정책을 업데이트 했으나, 해당 개발자는 여전히 버킷 내의 파일에 액세스할 수 없는 상태입니다. 무엇이 문제일까요 ?

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam:123456789012:user/Dave"
      },
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::static-files-bucket-xxx"
    }    
  ]
}

• A. 아무 문제가 없으며, 다시 로그인해야 함
• B. 아직 버킷에 파일이 없음
• C. 객체 레벨의 권한이므로, 리소스를 arn:aws:s3:::static-files-bucket-xxx/*로 변경해야 함

6. 온프레미스 Microsoft Active Directory로 요청을 프록시하려면 다음 중 어떤 AWS 디렉토리 서비스를 사용해야 할까요 ?

• A. EC2 상의 Microsoft AD
• B. AWS가 관리하는 Microsoft AD
• C. AD Connector
• D. Simple AD

7. AWS 계정에 있는 AWS 리소스를 다른 AWS 계정들과 공유하기 위해서는 다음 AWS 서비스 중 어떤 것을 사용해야 할까요 ?

• A. AWS Resource Access Manager
• B. AWS Single Sign-On (SSO)
• C. AWS Organizations
• D. AWS 공동 책임 모델

✅ AWS Resource Access Manager (AWS RAM)를 사용하면 AWS 리소스를 AWS Organizations에 있는 조직, 또는 조직 단위(OU) 내에 있는 AWS 계정들과 안전하게 공유할 수 있습니다. IAM 역할 및 IAM 사용자들과도 리소스를 공유할 수 있습니다.

8. AWS Organizations을 사용해 관리하고 있는 5개의 AWS 계정이 있습니다. 여러분은 각 계정이 특정 AWS 서비스로 액세스하는 것을 제한하려 합니다. 이런 경우 어떻게 해야 할까요 ?

• A. IAM 역할 사용
• B. AWS Organizations SCP 사용
• C. AWS Config 사용

네임스페이스

네임스페이스는 CloudWatch 지표의 컨테이너입니다. 다른 네임스페이스의 지표는 서로 격리되어 있으므로 다른 애플리케이션의 지표가 실수로 동일한 통계로 집계되는 일은 없습니다. 기본 네임스페이스는 없습니다. CloudWatch에 게시하는 각 데이터 포인트의 네임스페이스를 지정해야 합니다. 사용자는 지표를 생성할 때 네임스페이스 이름을 지정할 수 있습니다. 이 이름은 유효한 XML 문자를 포함하고 있어야 하고 길이가 256자 미만이어야 합니다. 가능한 문자로는 영숫자 문자(0-9A-Za-z), 마침표(.), 하이픈(-), 밑줄(_), 슬래시(/), 해시(#), 콜론(:)이 있습니다.

지표

지표는 CloudWatch의 기본 개념입니다. 지표는 CloudWatch에 게시된 시간 순서별 데이터 요소 집합을 나타냅니다. 지표는 모니터링할 변수로, 데이터 요소는 시간에 따른 변수의 값을 나타내는 것으로 간주합니다. 예를 들어 특정 EC2 인스턴스의 CPU 사용량은 Amazon EC2가 제공하는 하나의 지표입니다. 데이터 요소 그 자체는 데이터를 수집하는 애플리케이션이나 비즈니스 활동에서 나올 수 있습니다.

기본적으로 많은 AWS 서비스에서 리소스(Amazon EC2 인스턴스, Amazon EBS 볼륨, Amazon RDS DB 인스턴스)에 대한 무료 지표를 제공합니다. 또한 유료로 Amazon EC2 인스턴스와 같은 일부 리소스에 대한 세부 모니터링을 사용하거나 자체 애플리케이션 지표를 게시할 수도 있습니다. 사용자 지정 지표의 경우 원하는 순서와 속도로 데이터 요소를 추가할 수 있습니다. 이러한 데이터 요소에 대한 통계를 정렬된 시계열 집합으로 검색할 수 있습니다.

지표는 생성된 리전에만 존재합니다. 지표는 삭제가 불가능하지만, 지표에 새 데이터가 게시되지 않을 경우 15개월 후에 자동으로 만료됩니다. 15개월이 지난 데이터 요소는 순서대로 만료됩니다. 새로운 데이터 요소가 들어오면 15개월이 지난 데이터가 삭제됩니다.

타임스탬프

각 지표 데이터 요소에는 타임스탬프가 연결되어 있어야 하며 타임스탬프는 최대 2주 전이고 최대 2시간 빠를 수 있습니다. 타임스탬프를 제공하지 않으면 CloudWatch는 데이터 요소를 수신한 시간에 따라 자동으로 타임스탬프를 생성합니다.

CloudWatch 경보는 UTC의 현재 시간을 기반으로 지표를 확인합니다. 현재 UTC 시간이 아닌 타임스탬프와 함께 사용자 지정 지표를 CloudWatch에 전송하면 경보에 데이터 부족(insufficient Data) 상태가 표시되거나 경보가 지연될 수 있습니다.

지표 보존 기간

CloudWatch는 지표 데이터를 다음과 같이 유지합니다.

• 기간이 60초 미만으로 설정된 데이터 요소들은 3시간 동안 사용이 가능합니다. 이러한 데이터 요소는 고분해능 사용자 지정 지표입니다.
• 기간이 60초로 설정된 데이터 요소들은 15일 동안 사용이 가능
• 기간이 300초(5분)로 설정된 데이터 요소들은 63일 동안 사용이 가능
• 기간이 3600초(1시간)로 설정된 데이터 요소들은 455일(15개월) 동안 사용이 가능

• 표준 분해능 - 1분 세분화 데이터
• 고분해능 - 1초 세분화 데이터

  고분해능 지표는 애플리케이션의 단기(1분 미만)활동을 보다 즉각적으로 관찰할 수 있게 해줍니다. 사용자 지정 지표에 대해 PutMetricData를 호출할 때마다 요금이 부과되며, 따라서 고분해능 지표에 대해 PutMetricData를 자주 호출할수록 요금이 증가합니다. 고분해능 지표에 대해 경보를 설정할 경우 고분해능 경보를 10초 또는 30초 기간으로 지정하거나 60초의 배수 기간으로 정기 경보를 설정할 수 있습니다. 10초 또는 30초 기간의 고분해능 경보는 요금이 더 비쌉니다.

AWS CloudWatch 기본 모니터링 및 세부 모니터링

CloudWatch는 기본 모니터링과 세부 모니터링이라는 두 가지 모니터링 범주를 제공합니다. 다수의 AWS 서비스는 고객에게 무료로 CloudWatch에 기본 지표 세트를 게시하여 기본 모니터링을 제공합니다. 기본적으로 AWS 서비스 중 하나를 사용하기 시작할 때 기본 모니터링이 자동으로 활성화됩니다.

세부 모니터링은 일부 서비스에서만 제공됩니다. 또한 요금이 부과됩니다. AWS 서비스에 사용하려면 활성화하기를 선택해야 합니다. 자세한 모니터링 옵션은 서비스마다 다른데 예를 들어, *Amazon EC2 세부 모니터링은 Amazon EC2 기본 모니터링에 사용되는 5분 간격 대신 1분 간격으로 게시되는 더 빈번한 지표를 제공합니다. * Apache Kafka에 대한 Amazon S3 및 Amazon 관리형 스트리밍에 대한 세부 모니터링은 더 세밀한 지표를 의미합니다.

다른 AWS 서비스, 상세한 모니터링도 각기 다른 이름을 가지고 있는데 예를 들어, Amazon EC2에서는 세부 모니터링이라고 하며 AWS Elastic Beanstalk에서는 이를 향상된 모니터링이라고 하며, Amazon S3에서는 이를 요청 지표라고 합니다.

Amazon EC2에 대한 세부 모니터링을 사용하면 Amazon EC2 리소스를 보다 효율적으로 관리할 수 있으므로 추세를 파악하고 조치를 더 빠르게 수행할 수 있습니다. 운영 문제를 신속하게 확인하기 위해 Amazon S3 요청 지표를 1분 간격으로 사용할 수 있습니다.

AWS Config 규칙

규칙 페이지에 표시되는 초기 AWS 관리형 규칙을 계정에 추가할 수 있습니다. 설정을 마치면 AWS Config는 사용자가 선택한 규칙에 따라 AWS 리소스를 평가합니다. 설정 후 규칙을 업데이트하거나 관리형 규칙을 추가로 만들 수 있습니다.

AWS Config 규칙을 사용하여 비준수 리소스 자동 개선

AWS Config에는 AWS Config 규칙을 사용한 자동 개선 기능이 포함됩니다. 자동 개선 기능을 활용하면 개선 조치를 AWS Config 규칙과 연결하고 이를 자동으로 실행하도록 선택하여 수동으로 개입하지 않고도 비준수 리소스를 해결할 수 있으며, 이를 통해 이러한 리소스를 개선하는 데 소요 되는 시간을 절감할 수 있습니다.

개선 조치는 AWS Config 콘솔 또는 API를 통해 손쉽게 설정할 수 있습니다. 미리 채워진 목록에서 연결할 개선 조치를 선택하거나 AWS Systems Manager Automation 문서를 사용하여 자체적으로 사용자 지정 개선 조치를 생성할 수 있습니다. 수동 또는 자동 개선을 선택할 수 있으며 개선조치와 관련된 파라미터를 추가로 설정할 수도 있습니다.

AWS Config는 AWS 리소스 구성을 측정, 감사 및 평가할 수 있는 서비스입니다. Config는 AWS 리소스 구성을 지속적으로 모니터링 및 기록하고, 원하는 구성을 기준으로 기록된 구성을 자동으로 평가해 줍니다. Config를 사용하면 AWS 리소스 간 구성 및 관계 변화를 검토하고, 자세한 리소스 구성 기록을 분석하고, 내부 지침에 지정되어 있는 구성을 기준으로 전반적인 규정 준수 여부를 확인할 수 있습니다. 이에 따라 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결 작업을 간소화할 수 있습니다.

AWS Config 규칙을 사용한 자동 개선은 미국 동부(오하이오), 미국 동부(버지니아 북부), 미국 서부(캘리포니아 북부), 미국 서부(오레곤), 아시아 태평양(뭄바이), 아시아 태평양(서울), 아시아 태평양(싱가포르), 아시아 태평양(시드니), 아시아 태평양(도쿄), 캐나다(중부), EU(프랑크푸르트), EU(아일랜드), EU(런던), EU(파리), EU(스톡홀름), 남아메리카(상파울루) 및 AWS GovCloud(US) 지역의 고객이 사용할 수 있습니다.

CloudWatch vs CloudTrail vs Config

CloudWatch

• 지표, CPU, 네트워크 등의 성능 모니터링과 대시보드를 만드는 데 사용
• 이벤트와 알림을 수신
• 로그 집계 및 분석 도구 사용

CloudTrail

• 누구에 의한 호출이든 계정 내에서 만든 API에 대한 모든 호출을 기록
• 특정 리소스에 대한 추적 정의
• 글로벌 서비스

Config

• 구성 변경을 기록
• 규정 준수 규칙에 따라 리소스 평가
• 변경과 규정 준수에 대한 타임라인

For an Elastic Load Balancer

CloudWatch

• CloudWatch로 들어오는 연결 수 모니터링
• 오류 코드 수를 시간 흐름에 따라 비율로 시각화
• 로드 밸런서의 성능을 볼 수 있는 대시보드 생성

Config

• 로드 밸런서에 대한 보안 그룹 추적
• 로드 밸런서에 대한 구성 변경 추적
• SSL 인증서가 로드 밸런서에 항상 할당되어 있어야 한다는 규칙을 만들어 암호화되지 않은 트래픽이 로드 밸런서에 접근하는 것을 거부

CloudTrail

• 누가 API를 호출하여 로드 밸런서를 변경했는지 추적

1. 한 쌍의 EC2 인스턴스가 있으며, 이들의 표준 CloudWatch 지표가 매 1분마다 수거되도록 하려 합니다. 어떻게 해야 할까요 ?

• A. CloudWatch 사용자 지정 지표 활성화하기
• B. 고분해능 활성화
• C. 기본 모니터링 활성화
• D. 세부 모니터링 활성화

✅ 이는 유료 기능으로, 기본적으로 비활성화되어 있습니다. 활성화된 경우, EC2 인스턴스 지표는 1분마다 사용이 가능합니다.

2. 고분해능 사용자 지정 지표는 최소 해상도로 ( )를 가질 수 있습니다.

• A. 1초
• B. 10초
• C. 30초
• D. 1분

3. 데이터베이스 로그를 CloudWatch로 푸시하도록 구성 되어 있는 RDS DB 인스턴스가 있습니다. 로그에서 오류가 발견될 경우에는 CloudWatch 경보를 생성하게 만드려고 합니다. 어떻게 해야 할까요 ?

• A. 1시간 마다 AWS Lambda를 트리거하도록 예약된 CloudWatch 이벤트를 생성하고, 로그를 스캔해 SNS 주제를 통해 알리기
• B. 키워드 Error에 대한 로그를 필터링하는 CloudWatch 로그 지표 필터를 생성한 후, 지표 필터를 기반으로 CloudWatch 경보 생성
• C. 데이터베이스 로그의 오류를 모니터링하는 AWS 구성 규칙을 생성하고 SNS 주제를 통해 알리기

4. 최소 용량을 2로 구성한 오토 스케일링 그룹이 관리하고 있고, 한 세트의 EC2 인스턴스에서 호스팅하고 있는 애플리케이션이 있습니다. 또한 CPU 사용률이 60%에 이르면 ASG를 스케일인 하도록 구성된 CloudWatch 경보도 생성해 둔 상태입니다. 현재 이 애플리케이션은 2개의 EC2 인스턴스 상에 실행되고 있으며, 트래픽의 수준은 낮고, CloudWatch 경보는 ALARM 상태에 있습니다. 이런 경우, 무슨 일이 일어나게 될까요 ?

• A. 하나의 EC2 인스턴스가 종료되고 ASG의 원하는 용량 및 최소 용량이 1로 설정됨
• B. CloudWatch 경보는 계속 ALARM 상태로 유지되지만, ASG의 EC2 인스턴스 수는 절대 감소하지 않음
• C. CloudWatch 경보가 ASG로부터 분리될 것
• D. CloudWatch 경보가 OK 상태로 변화함

✅ ASG의 EC2 인스턴스 수는 이론상 CloudWatch 경보가 EC2 인스턴스 중단을 트리거한다고 해도, 최소 용량 이하로 감소할 수 없습니다.

5. CloudWatch의 EC2 인스턴스 메모리 사용은 어떻게 모니터링할 수 있나요 ?

• A. EC2 세부 모니터링 활성화
• B. EC2 인스턴스는 기본적으로 메모리 사용량을 CloudWatch로 푸시함
• C. 통합 CloudWatch 에이전트를 사용해 메모리 사용량을 사용자 지정 지표로 CloudWatch에 푸시

6. 고분해능 사용자 지정 지표에 설정된 CloudWatch 경보는 ( )마다 트리거될 수 있습니다.

• A. 1초
• B. 10초
• C. 30초
• D. 1분

  ✅ 고분해능 지표를 설정했다면 1초, 5초, 10초, 30초 또는 60초의 배수 기간으로 지표를 읽고 검색할 수 있습니다.

• 표준 분해능: 1분 세분화 데이터
• 고분해능: 1초 세분화 데이터

7. 구성을 변경했고, 이 변경 사항이 애플리케이션의 성능에 어떤 영향을 미쳤는지 평가하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. Amazon CloudWatch
• B. AWS CloudTrail

✅ Amazon CloudWatch는 모니터링 서비스로 애플리케이션을 모니터링할 수 있게 해줍니다. 이는 시스템의 성능 변경에 따라 반응하며, 리소스 활용을 최적화하며 운영 상태를 통합적으로 볼 수 있도록 해줍니다. CloudWatch는 애플리케이션의 성능과 지표를 모니터링하는 데에 사용됩니다.

8. 지난 주, 누군가가 AWS 계정 내에서 민감한 데이터를 포함한 중요 데이터베이스를 호스팅하고 있던 EC2 인스턴스를 중단했습니다. 이런 경우, 누가 언제 이런 작업을 했는지 알아내려면 다음 중 어떤 AWS 서비스를 사용해야 할까요 ?

• A. CloudWatch 지표
• B. CloudWatch 경보
• C. CloudWatch 이벤트
• D. AWS CloudTrail

✅ AWS CloudTrail은 AWS 인프라 간의 작업과 관련된 계정 활동을 로그하고 지속적인 모니터링 및 유지를 가능하게 해줍니다. CloudTrail은 AWS 계정 활동 내역을 제공해 주며, AWS 관리 콘솔, AWS SDK, AWS CLI에서 생성한 API 호출을 감사합니다. 따라서 여기에 EC2 인스턴스 중단 API 호출이 나타납니다. CloudTrail은 AWS 계정 내의 비정상적인 활동을 감지하는 데에 사용할 수 있습니다.

9. CloudTrail이 전체 AWS 리전의 AWS 계정에 활성화되어 있습니다. AWS 계정 내의 비정상적인 활동을 감지하려면 다음 중 어떤 기능을 사용해야 할까요 ?

• A. CloudTrail Data Events
• B. CloudTrail Insights
• C. CloudTrail Management Events

10. 팀원들 중 하나가 중요한 데이터를 포함하고 있는 EC2 인스턴스를 4개월 전에 중단했습니다. 누가 이런 작업을 했는지를 알지 못하는 관계로 CloudTrail을 사용해 이 기간 동안의 모든 API 호출을 검토하려 합니다. CloudTrail은 이미 설정되어 있으며, S3 버킷으로 로그를 보내도록 구성되어 있습니다. 누가 이런 작업을 했는지 알아내기 위해서는 어떻게 해야 할까요 ?

• A. CloudTrail 콘솔의 CloudTrail 이벤트 내역을 활용
• B. Amazon Athena로 S3 버킷 내의 CloudTrail 로그를 분석

✅ CloudTrail 콘솔은 지난 90일 간 보고된 API 활동을 확인하려는 경우 활용할 수 있습니다. 90일보다 오래된 이벤트의 경우에는 Athena를 사용해 S3 버킷 내에 저장된 CloudTrail 로그를 분석합니다.

11. 84번 포트가 취약한 것으로 알려진 OS를 지닌 EC2 인스턴스 플릿에서 웹사이트를 실행하고 있습니다. 84번 포트가 노출된 경우에는 EC2 인스턴스를 지속적으로 모니터링하려 합니다. 이 경우, 어떻게 해야 할까요 ?

• A. CloudWatch 지표 설정
• B. CloudTrail 추적 설정
• C. 구성 규칙 설정
• D. CloudWatch 이벤트가 Lambda 함수를 트리거해 EC2 인스턴스를 스캔하도록 만들기

12. 리소스 구성의 규정 준수를 시간의 경과에 따라 평가하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. AWS Config
• B. Amazon CloudWatch
• C. AWS CloudTrail

13. 누군가가 리소스의 구성을 변경하여, 규정을 위반하게 만들었습니다. 누가 이런 변경 사항을 만들었는지 알아내기 위해서는 다음 중 어떤 AWS 서비스를 사용해야 할까요 ?

• A. Amazon CloudWatch
• B. AWS CloudTrail
• C. AWS Config

14. EC2 인스턴스에 대한 무제한 SSH 액세스가 있는 경우에는 보안 그룹을 모니터링할 수 있도록 AWS Config를 활성화했습니다. 보안 그룹을 올바른 상태로 자동으로 재구성하기 위해서는 다음 AWS Config 기능 중 어떤 것을 사용해야 할까요 ?

• A. AWS Config 수정
• B. AWS Config 규칙
• C. AWS Config

✅ AWS Config 규칙은 수정 작업을 지원하지 않습니다.

15. 제한된 SSH 액세스를 갖고 있으며, 강화된 보안 그룹을 포함하고 있는 한 세트의 EC2 인스턴스에 중요한 웹사이트를 실행하고 있습니다. 여러분은 AWS 리전 내에 AWS Config를 활성화했고, 누군가가 EC2 인스턴스의 보안 그룹에 변경을 가한 경우 이메일을 통해 알림을 받으려 합니다. 이 경우, 다음 중 어떤 AWS Config 기능을 사용해야 할까요 ?

• A. AWS Config 수정
• B. AWS Config 규칙
• C. AWS Config

아키텍처에 기반하여 올바른 데이터베이스를 고르기 위한 질문들

• 읽기를 많이 하는지 쓰기를 많이 하는지 혹은 균형 잡힌 상태인지
• 확장성을 고려하여 처리량은 얼마나 필요한지
• 얼마만큼의 데이터를 얼마나 오래 보관할지, 평균 객체 크기는 얼마이며 작은지 또는 큰지 아니면 평균에 가까운지 파악
• 데이터 액세스하는 방법과 보안이 갖춰졌는지 파악
• 데이터 내구성, 즉 얼마나 오래 보존할지
• 데이터 쿼리에서 기본 키를 사용하는지 또한 조인할지 여부
• 정형인지 반정형인지, 검색할 필요가 있는지
• RDBMS와 NoSQL 중 뭘 원하는지
• 라이선스 비용이 있는지, 클라우드 네이티브 데이터베이스로 전활할 수 있는지

Database Types

• RDBMS (= SQL / OLTP): RDS, Aurora - great for joins
• NoSQL database: DynamoDB (~JSON), ElastiCache (key / value pairs), Neptune (graphs) - no joins, no SQL
• Object Store: S3 (for big objects) / Glacier (for backups / archives)
• Data Warehouse (= SQL Analytics / BI): Redshift (OLAP), Athena
• Search: ElasticSearch (JSON) - free text, unstructured searches
• Graphs: Neptune - displays relationships between data

RDS

• Managed PostgreSQL / MySQL / Oracle / SQL Server
• Must provision an EC2 instance & EBS Volume type and size
• Support for Read Replicas and Multi AZ
• Security through IAM, Security Groups, KMS, SSL in transit
• Backup / Snapshot / Point in time restore feature
• Managed and Scheduled maintenance
• Monitoring through CloudWatch
• Use case: Store relational datasets (RDBMS / OLTP), perform SQL queries, transactional inserts / update / delete is available

  RDS for Solutions Architect

• Operations: small downtime when failover happens, when maintenance happens, scalinng in read replicas / ec2 instance / restore EBS implies manual intervention, application changes.
• Security: AWS responsible for OS security, we are responsible for settign up KMS, security groups, IAM policies, authorizing users in DB, using SSL
• Reliability: Multi AZ feature, failover in case of failures
• Performance: depends on EC2 instance type, EBS volume type, ability to add Read Replicas. Storage auto-scaling & manual scaling of instances
• Cost: Pay per hour based on provisioned EC2 and EBS

Aurora

• Compitable API for PostgreSQL / MySQL
• Data is held in 6 replicas, across 3 AZ
• Auto healing capability
• Multi AZ, Auto Scaling Read Replicas
• Read Replicas can be Global
• Aurora database can be Global for DR or latency purposes
• Auto scaling of storage from 10GB to 128TB
• Define EC2 instance type for aurora instances
• Same security / monitoring / maintenance features as RDS
• Aurora Serverless - for unpredictable / intermittent workloads
• Aurora Multi-Master - for continous writes failover
• Use case: same as RDS, but with less maintenance / more flexibility / more performance

  Aurora for Solutions Architect

• Operations: less operations, auto scaling storege
• Security: AWS responsible for OS security, we are responsible for setting up KMS, security groups, IAM policies, authorizing users in DB, using SSL
• Reliability: Multi AZ, highly available, possibly more than RDS, Aurora Serverless option, Aurora Multi-Master option
• Performance: 5x performance (according to AWS) due to architectural optimizations. Up to 15 Read Replicas (only 5 for RDS)
• Cost: Pay per hour based on EC2 and storage usage. Possibly lower costs compared to Enterprise grade databases such as Oracle

ElastiCache

• Managed Redis / Memcached (similar offering as RDS, but for caches)
• In-memory data store, sub-millisecond latency
• Must provision an EC2 instance type
• Support for Clustering (Redis) and Multi AZ, Read Replicas (sharding)
• Security through IAM, Security Groups, KMS, Redis Auth
• Backup / Snapshot / Point in time restore feature
• Managed and Scheduled maintenance
• Monitoring through CloudWatch

  ElastiCache for Solutions Architect

• Operations: same as RDS
• Security: AWS responsible for OS security, we are responsible for setting up KMS, security groups, IAM policies, users (Redis Auth), using SSL
• Reliability: Clustirng, Multi AZ
• Performance: Sub-millisecond performance, in memory, read replicas for sharding, very popular cache option
• Cost: Pay per hour based on EC2 and storage usage

DynamoDB

• AWS proprietary technology, managed NoSQL database
• Serverless, provisioned capacity, auto scaling, on demand capacity
• Can replace ElastiCache as key/value store (storing session data for example)
• Highly Available, Multi AZ by default, Read and Writes are decoupled, DAX for read cache
• Reads can be eventually consistent or strongly consistent
• Security: authentication and authorization is done through IAM
• DynamoDB Streams to integrate with AWS Lambda
• Backup / Restore feature, Global Table feature
• Monitoring through CloudWatch
• Can only query on primary key, sort key, or indexes
• Use Case: Serverless applications development (small documents 100s KB), distributed serverless cache, doesn't have SQL query language available, has transactions capability from Nov 2018

  DynamoDB for Solutions Architect

• Operations: no operations needed, auto scaling capability, serverless
• Security: full security through IAM policies, KMS encryption, SSL in flight
• Reliability: Multi AZ, Backups
• Performance: single digit millisecond performance, DAX for caching reads, performance doesn't degrade if your application scales
• Cost: Pay per provisioned capacity and storage usage (no need to guess in advance any capacity - can use auto scaling)

S3

• S3 is a key/value storer for objects
• Great for big objects, not so great for small objects
• Serverless, scales infinitely, max object size is 5TB
• Strong consistency
• Tiers: S3 Standard, S3 IA, S3 One Zone IA, Glacier for backups
• Features: Versioning, Encryption, Cross Region Replication, etc...
• Security: IAM, Bucket Policies, ACL
• Encryption: SSE-S3, SSE-KMS, SSE-C, client side encryption, SSL in transit
• Use Case: static files, key value store for big files, website hosting

  S3 for Solutions Architect

• Operations: no operations needed
• Security: IAM, Bucket Policies, ACL, Encryption (Server/Client), SSL
• Reliability: 99.999999999% durability / 99.99% availability, Multi AZ, CRR
• Performance: scale to thousands of read / writes per second, transfer acceleration / multi-part for big files
• Cost: pay per storage usage, network cost, requests number

Athena

• Fully Serverless database with SQL capabilities
• Used to query data in S3
• Pay per query
• Output results back to S3
• Secured through IAM
• Use Case: one time SQL queries, serverless queries on S3, log analytics

  Athena for Solutions Architect

• Operations: no operations needed, serverless
• Security: IAM + S3 security
• Reliability: managed service, uses Presto engine, highly available
• Performance: queries scale based on data size
• Cost: pay per query / per TB of data scanned, serverless

Redshift

• Redshift is based on PostgreSQL, but it's not used for OLTP
• It's OLAP - online anlytical processing (analytics and data warehousing)
• 10x better performance than other data warehouses, scale to PBs of data
• Columnar storage of data (instead of row based)
• Massively Parallel Query Execution (MPP)
• Pay as you go based on the instances provisioned
• Has a SQL interface for performing the queries
• BI tools such as AWS Quicksight or Tableau integrate with it
• Data is loaded form S3, DynamoDB, DMS, other DBs...
• From I node to 128 nodes, up to 128 TB of space per node
• Leader node: for query planning, results aggregation
• Compute node: for performing the queries, send results to leader
• Redshfit Spectrum: perform queries directly against S3 (no need to load)
• Backup & Restore, Security VPC / IAM / KMS, Monitoring
• Redshift Enhanced VPC Routing: COPY / UNLOAD goes through VPC

  Redshift - Snapshots & DR

• Redshift has no "Multi-AZ" mode
• Snapshots are point-in-time backups of a cluster, stored internally in S3
• Snapshots are incremental (only what has changed is saved)
• You can restore a snapshot into a new cluster
• Automated: every 8 hours, every 5 GB, or on a schedule. Set retention
• Manual: snapshot is retained until you delete it
• You can configure Amazon Redshift to automatically copy snapshots (automated or manual) of a cluster to another AWS Region

  Loading data into Redshift

1. Amazon Kinesis Data Firehose
2. S3 using COPY command
3. EC2 Instance

   Redshift Spectrum

   

• Query data that is already in S3 without loading it.
• Must have a Redshift cluster available to start the query
• The query is then submitted to thousands of Redshift Spectrum nodes

  Redshift for Solutions Architect

• Operations: like RDS
• Security: IAM, VPC, KMS, SSL (like RDS)
• Reliability: auto healing features, cross-region snapshots copy
• Performance: 10x performance vs other data warehousing, compression
• Cost: pay per node provisioned, 1/10th of the cost vs other warehouses
• vs Athena: faster queries / joins / aggregations thanks to indexed
• Remember: Redshift = Analytics / BI / Data Warehouse

AWS Glue

• Managed extract, transform, and load (ETL) service
• Useful to prepare and transform data for analytics
• Fully serverless service

Neptune

• Fully managed graph database
• When do we use Graphs ?

  • High relationship data
  • Social Networking: Users friends with Users, replied to comment on post of user and likes other comments
  • Knowledge graphs (Wikipedia)

• Highly available across 3 AZ, with up to 15 read replicas
• Point-in-time recovery, continuous backup to Amazon S3
• Support for KMS encryption at rest + HTTPS

  Neptune for Solutions Architecture

• Operations: similar to RDS
• Security: IAM, VPC, KMS, SSL (similar to RDS) + IAM Authentication
• Reliability: Multi-AZ, clustering
• Performance: best suited for graphs, clustering to improve performance
• Cost: pay per node provisioned (similar to RDS)
• Remember: Neptune = Graphs

Amazon OpenSearch Service

• Amazon OpenSearch is successor to Amazon ElasticSearch
• Example: In DynamoDB, you can only find by primary key or indexes
• With OpenSearch, you can search any field, even partially matches
• It's common to use OpenSearch as a complement to another database
• OpenSearch also has some usage for Big Data applications
• You can provision a cluster of instances
• Built-in integrations: Amazon Kinesis Data Firehose, AWS IoT, and Amazon CloudWatch Logs for data ingestion
• Security through Cognito & IAM, KMS encryption, SSL & VPC
• Comes with OpenSearch Dashboards (visualization)

  OpenSearch for Solutions Architect

• Operations: similar to RDS
• Security: Cognito, IAM, VPC, KMS, SSL
• Reliability: Multi-AZ, clustering
• Performance: based on ElasticSearch project (open source), petabyte scale
• Cost: pay per node privisioned (similar to RDS)
• Remember: OpenSearch = Search / Indexing

1. 다음 중 SQL 언어 호환성 및 삽입, 업데이트, 삭제와 같은 변환 프로세싱 기능을 통해 관계형 데이터셋의 저장을 보조해주는 데이터베이스는 무엇인가요 ?

• A. Amazon Redshift
• B. Amazon RDS
• C. Amazon DynamoDB
• D. Amazon ElasticCache

✅ Amazon Redshift는 온라인 트랜잭션 프로세싱(OLTP)에 사용될 수 없습니다. Redshift는 데이터 웨어하우징과 같은 온라인 분석 프로세싱(OLAP)을 위한 것입니다.

2. 다음 중 Redis API와 호환이 가능한 캐싱 기능을 제공하는 AWS 서비스는 무엇인가요 ?

• A. Amazon RDS
• B. Amazon DynamoDB
• C. Amazon ElasticSearch
• D. Amazon ElastiCache

✅ Amazon RDS에는 캐싱 기능이 없으며, JDBC 기반으로 Redis API와 호환되지 않으며 Amazon DynamoDB는 Redis 대용으로 사용할 수 있지만 Redis API를 지원하지 않습니다. Amazon ElastiCache는 완전 관리형 인메모리 데이터 스토어로, Redis 혹은 Memcached와 호환이 가능합니다.

3. 온프레미스 MongoDB NoSQL 데이터베이스를 AWS로 이전하려 합니다. 데이터베이스 서버를 관리하고 싶지 않기 때문에 고가용성 및 높은 내구성과 신뢰성을 제공하며, 가급적이면 서버리스인 관리형 NoSQL 데이터베이스를 사용하려 합니다. 이런 경우, 어떤 데이터베이스를 선택해야 할까요 ?

• A. Amazon RDS
• B. Amazon DynamoDB
• C. Amazon Redshift
• D. Amazon Aurora

✅ Amazon DynamoDB는 키-값 문서, NoSQL 데이터베이스입니다.

4. 여러분은 온라인 트랜잭션 프로세싱(OLTP)을 수행하려 합니다. 이 작업에는 오토 스케일링 기능이 내장되어 있고, 기반 스토리지에 대해 최대 복제본 수를 제공하는 데이터베이스를 사용하고자 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 추천할 수 있을까요 ?

• A. Amazon ElastiCache
• B. Amazon Redshift
• C. Amazon Aurora
• D. Amazon RDS

✅ Amazon Aurora는 MySQL 및 PostgreSQL과 호환이 가능한 관계형 데이터베이스입니다. Aurora는 데이터베이스 인스턴스 당 최대 128TB까지 자동 스케일업하는 분산형, 내결함성 자가 복구 스토리지 시스템이라는 것이 특징입니다. 최대 15개의 지연 시간이 낮은 읽기 전용 복제본, 지정 시간 복구, Amazon S3로의 지속적인 백업 그리고 3개의 AZ에 대한 복제를 통해 높은 성능과 고가용성을 제공합니다.

5. 한 스타트업 회사가 솔루션 아키텍트인 여러분에게 사용자들이 서로 친구가 될 수 있고, 서로의 포스트에 좋아요를 남길 수 있는 소셜 미디어 웹사이트 아키텍처의 구축을 도와달라고 한 상황입니다. 이 회사는 'Mike의 친구들이 남긴 포스트에는 몇 개의 좋아요가 있는가?'와 같은 복잡한 쿼리를 수행하려 합니다. 이 경우, 어떤 데이터베이스의 사용을 추천할 수 있을까요 ?

• A. Amazon RDS
• B. Amazon Redshift
• C. Amazon Neptune
• D. Amazon ElasticSearch

✅ Amazon Neptune은 빠르고 신뢰도가 높은 완전 관리형 그래프 데이터베이스 서비스로 고도로 연결된 데이터셋을 처리하는 애플리케이션을 구축하고 실행하는 데에 도움을 줍니다.

6. 각각의 크기가 100MB인 한 세트의 파일들이 있는데, 이 파일을 안전하고 내구성이 높은 키-값 스토어에 저장하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 사용하는 게 권장될까요 ?

• A. Amazon Athena
• B. Amazon S3
• C. Amazon DynamoDB
• D. Amazon ElastiCache

✅ Amazon S3는 키-값 스토어가 맞습니다. (키는 버킷 내 객체의 전체 경로입니다.)

7. 큰 규모의 열 기반 데이터 세트에 대한 분석 쿼리 수행을 위해 효율적인 데이터베이스가 필요합니다. 이 데이터 웨어하우스에 대한 연결에는 Amazon QuickSight와 같은 보고 및 대시보드 도구를 사용하려 합니다. 이 경우, 어떤 AWS 기술을 사용하는 것을 추천할 수 있을까요 ?

• A. Amazon RDS
• B. Amazon S3
• C. Amazon Redshift
• D. Amazon Neptune

8. S3 버킷 내에 많은 로그 파일이 저장되어 있는데. 로그를 필터링하고 인증되지 않은 작업을 시도한 사용자를 판별하기 위해 빠른 분석을, 가능하다면 서버리스로 수행하고자 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 사용해야 할까요 ?

• A. Amazon DynamoDB
• B. Amazon Redshift
• C. Amazon S3 Glacier
• D. Amazon Athena

✅ Amazon Athena는 대화식 서버리스 쿼리 서비스로, 표준 SQL을 사용해 S3 버킷 내의 데이터를 분석하는 데에 유용합니다.

9. 여러분은 솔루션 아키텍트로서 Redshift 클러스터를 위한 재해 복구 계획을 준비해달라는 요청을 받았습니다. 어떻게 해야 할까요 ?

• A. 다중 AZ 활성화
• B. 자동 스냅샷을 활성화한 후, Redshift 클러스터가 다른 AWS 리전으로 스냅샷을 자동으로 복사하게끔 구성
• C. 스냅샷을 찍은 후, 새로운 Redshift 글로벌 클로스터로 복원

10. 다음 중 클러스터와 데이터 리포지토리 간을 오가는 COPY 및 UNLOAD 트래픽이 VPC를 통해 이동하도록 강제하는 Redshift 기능은 무엇인가요 ?

• A. 향상된(Enhanced) VPC 라우팅
• B. 개선된(Improved) VPC 라우팅
• C. Redshift 스펙트럼

11. DynamoDB 데이터 스토어로 사용하는 게임 웹사이트를 실행 중입니다. 사용자들은 이름 검색, 가능하다면 부분 일치 검색을 통해 다른 게이머들을 찾을 수 있는 기능을 요청해왔습니다. 이런 기능을 구현하려면 다음 중 어떤 AWS 기술이 권장될까요 ?

• A. Amazon DynamoDB
• B. Amazon ElasticSearch
• C. Amazon Neptune
• D. Amazon Redshift

✅ 검색(search)이라는 말이 나오면, 무조건 ElasticSearch를 떠올리면 됩니다.

12. 이 AWS 서비스를 사용하면 몇 번의 클릭 만으로 ETL(추출, 변환, 로드)을 생성, 실행 및 모니터링할 수 있습니다.

• A. AWS Glue
• B. Amazon DynamoDB
• C. Amazon RDS
• D. Amazon Redshift

✅ AWS Glue는 추출, 변환 및 로드(ETL) 연산을 위한 서버리스 데이터 준비 서비스입니다.

OLTP (Online Transaction Processing)

복수의 사용자 PC에서 발생되는 트랜잭션(Transaction)을 DB 서버가 처리하고, 그 결과를 요청한 사용자 PC에 결과값을 되돌려주는 과정을 뜻합니다. 쉽게 이야기해서 1개의 요청작업을 처리하는 과정을 OLTP라고 생각할 수 있습니다.

예를 들어, 은행에 돈을 입금하는 과정을 생각해보면 약 3단계의 처리과정을 거쳐야 한다고 가정해보겠습니다. 1단계는 돈과 카드를 은행원에게 전달합니다. 2단계는 은행원이 돈과 카드를 확인한 후 입금을 진행합니다. 3단계는 입금이 확인된 내역을 확인합니다. 이 3단계는 중간에 그만두면 안되는 과정이며 모든 단계가 완벽하게 종료되어야 합니다. 3단계를 1개의 요청 작업, 즉 트랜잭션(Transaction)으로 본다면, OLTP는 이 과정을 완벽하게 처리함을 의미합니다.

즉, 중간에 예상치 못한 변수로 2단계까지만 작업이 진행되고 멈추게 된다면 지금까지 진행된 1, 2 단계를 무효화시켜야 합니다. (이 과정을 롤백(Rollback)이라 합니다.) 또한 1, 2, 3단계의 작업이 정상적으로 진행되면 작업을 확정해야 합니다. (이 과정을 커밋(Commit)이라 합니다.)

이처럼 OLTP의 의미는 무수히 많이 발생되는 각각의 작업요청을 오류없이 처리하고, 그 결과값을 실시간으로 확인시켜줘야 함을 의미합니다. 조금 복잡하게 말하면 1개의 트랜잭션에서 발생되는 INSERT, UPDATE, DELETE의 과정을 무결성을 보장하여 처리하고 그 결과를 SELECT하는 과정을 OLTP라고 합니다.

OALP (Online Analytical Processing)

OLTP가 데이터 자체의 처리에 중점이 된 용어라면 OLAP는 이미 저장된 데이터를 기반으로 분석하는데 중점이 된 용어입니다.

OLAP는 데이터웨어하우스(DW), 쉽게 말해 DB에 저장되어 있는 데이터를 분석하고 데이터 분석을 통해 사용자에게 유의미한 정보를 제공해주는 처리방법을 의미합니다. 나아가 이런 유의미한 정보를 바탕으로 보다 복잡한 모델링을 가능하게 합니다.

예를 들어, 만약 여러분이 회사의 대표라고 가정한다면 1년 동안 뒤도 돌아보지 않고 열심히 일을 했고 1년이 끝나는 시기에 돈은 얼마나 벌었는지 어디에 얼마만큼의 돈을 썼는지를 표로 정리하고 싶습니다. 해당 자료를 얻기 위해서 우선 필요한 것은 1년동안 사용한 내역서가 필요합니다. 먼저 1년 동안 무수히 많이 거래된 통장거래내역을 확보합니다. 그리고 이 통장거래내역을 바탕으로 수입과 지출금액을 나누고 다시 지출금액은 항목별로 나눠서 계산을 합니다. 이후 일별로 1년 동안의 벌어들인 금액과 지출항목별 금액을 정리했습니다. 다만 일일이 수작업으로 확인하다보니 정확한지에 대한 확신이 없습니다. OLAP는 사람이 원하는 이 작업을 컴퓨터로 자료를 추출 및 분석하여 제공하는 과정을 의미합니다.

즉, OLAP는 기존에 저장되어 있는 데이터를 사용자의 요구와 목적에 맞게 분석하여 정보를 제공하는 개념을 의미합니다.

OLTP vs OLAP

1. 한 스타트업 회사가 AWS 상에서 자신들의 애플리케이션을 실행하려 합니다. 이 기업에서는 여러분을 솔루션 아키텍트로 고용해, 완전한 서버리스 REST API의 설계 및 구현을 맡겼습니다. 어떤 기술 스택을 사용하는 것을 추천할 수 있을까요 ?

• A. API Gateway + AWS Lambda
• B. Application Load Balancer (ALB)
• C. Elastic Container Service (ECS) + Elastic Block Store (EBS)
• D. Amazon CloudFront + S3

2. 다음 AWS 서비스 중 즉시 사용 가능한 캐싱 기능이 없는 것을 고르세요.

• A. API Gateway
• B. Lambda
• C. DynamoDB

✅ Lambda는 즉시 사용 가능한 캐싱 기능을 가지고 있지 않습니다.

3. 한 모바일 애플리케이션을 실행하고 있는데 등록된 각 사용자들이 S3 버킷에 있는 자신들의 폴더에서 /로 이미지를 업로드 다운로드 할 수 있게끔 하려 합니다. 또한, 사용자들이 소셜 미디어 계정(예: Facebook)을 사용해 가입하고 로그인할 수 있게 하려 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. AWS Identity and Access Management (IAM)
• B. AWS Single Sign On (SSO)
• C. Amazon Cognito
• D. Amazon CloudFront

✅ Amazon Cognito는 사용자들이 웹 및 모바일 앱에 빠르고 쉽게 가입, 로그인 및 액세스할 수 있게 해줍니다. Amazon Cognito는 수백만개의 사용자들을 스케일링하며, Apple, Facebook, Google, Amazon 및 SAML 2.0과 OpenID Connect를 통한 기업 자격 증명 제공자 등의 소셜 자격 증명 제공자를 사용해 로그인할 수 있도록 해줍니다.

4. 사용자들에게 전역적으로 배포하고자 하는 대량의 정적 파일이 S3 버킷 내에 저장되어 있습니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. S3 리전 간 복제
• B. Amazon CloudFront
• C. Amazon Route 53
• D. API Gateway

✅ Amazon CloudFront는 낮은 지연 시간과 빠른 전송 속도로 전역의 고객들에게 데이터, 영상, 애플리케이션 및 API를 전송해 주는 고속 콘텐츠 전송 네트워크(CDN)입니다. Amazon CloudFront에 딱 맞는 사용 사례입니다.

5. ap-northeast-1에 DynamoDB 테이블을 생성했으며, 이 테이블을 eu-west-1에서도 사용할 수 있도록 하기 위해 DynamoDB 글로벌 테이블을 생성하기로 했습니다. DynamoDB 글로벌 테이블을 생성하기 전에는 어떤 기능을 먼저 활성화해야 할까요 ?

• A. DynamoDB 스트림
• B. DynamoDB DAX
• C. DynamoDB 버전 관리
• D. DynamoDB 백업

✅ DynamoDB Accelarator (DAX)는 완전 관리형에 고가용성을 갖춘 DynamoDB용 인메모리 캐시이며, 초당 수백만개의 요청이 있어도 최대 10배(밀리초에서 마이크로초까지)의 성능 향상을 제공해 줍니다. DAX는 개발자들이 캐시 무효화, 데이터 수집 혹은 클러스터 관리를 할 필요없이 DynamoDB 테이블로 인메모리 가속을 추가하기 위한 모든 복잡한 작업을 수행할 수 있게 해줍니다. DynamoDB Streams는 DynamoDB가 변경 로그를 가져오고, 이를 사용해 다른 AWS 리전에 있는 복제 테이블이 서로의 데이터를 복제할 수 있는 기능을 활성화해 줍니다.

6. DynamoDB Streams를 이용해 DynamoDB 테이블로 항목이 추가될 때마다 Lambda 함수가 각 아이템을 실행하도록 구성한 상황입니다. 이 함수는 추후 장기적인 처리 업무를 위해 메시지를 SQS 대기열로 삽입하게 되어 있습니다. Lambda 함수를 매번 호출해보면 DynamoDB Stream를 읽을 수는 있으나 SQS 대기열로 메시지를 삽입하지는 못하는 것으로 보입니다. 이 경우, 무엇이 문제일까요 ?

• A. SQS 대기열로 메시지를 삽입할 때는 Lambda를 사용할 수 없으므로, EC2 인스턴스를 대신 사용해야 함
• B. Lambda 실행 IAM 역할에 권한이 없음
• C. Lambda 보안 그룹이 SQS에 대한 아웃바운드 액세스를 허용해야만 함
• D. SQS 보안 그룹이 AWS Lambda를 허용하도록 수정되어야 함

7. S3 버킷에 저장된 영상을 인코딩하고 인코딩된 영상을 다시 S3 버킷으로 저장할 목적으로만 사용될 마이크로 서비스 애플리케이션의 아키텍처를 생성하려 합니다. 이 마이크로 서비스 애플리케이션의 신뢰도를 높이고, 실패 시 재시도할 수 있는 기능을 부여하고자 합니다. 각 영상 처리에는 최대 25분이 걸릴 수 있습니다. 아키텍처에 사용되는 서비스는 비동기적이어야 하며 하루 동안 중지되었다가 그 다음 날 인코딩되지 않은 영상부터 다시 작업을 시작할 수 있는 기능을 포함해야 합니다. 이런 경우, 다음 중 어떤 AWS 서비스를 사용하는 게 권장될까요 ?

• A. Amazon S3 + AWS Lambda
• B. Amazon SNS + Amazon EC2
• C. Amazon SQS + Amazon EC2
• D. Amazon SQS + AWS Lambda

✅ AWS Lambda의 최대 실행 시간은 15분이므로 EC2를 사용해야 하고 Amazon SQS를 사용하면 메시지를 며칠 간 보관하고 향후에 처리할 수 있으며, EC2 인스턴스를 중단할 수도 있습니다.

8. 콘텐츠를 구매한 고객들을 위해, 유료 소프트웨어 설치 파일을 전역적으로 배포하려 합니다. 다른 사용자들이 소프트웨어를 구매할 수도 있기 때문에 IP 제한을 포함한 보안 조치를 통해 다운로드 URL을 보호하고자 합니다. 이 경우, 어떤 솔루션을 추천할 수 있을까요 ?

• A. CloudFront Presigned URL
• B. S3 Presigned URL
• C. EFS
• D. Public S3 Bucket

✅ CloudFront Presigned URL은 IP 주소 제한을 포함한 보안 기능을 가지게 됩니다.

9. 여러분은 전 세계에서 이미지를 다운로드하는 사진 공유 웹사이트를 실행하고 있습니다. 여러분은 15GB가 넘는 크기의 아름다운 산 이미지의 마스터 팩을 매달 웹사이트에 게시합니다. 이 콘텐츠는 Elastic File System (EFS)에 호스팅되어 있으며 Application Load Balancer와 한 세트의 EC2 인스턴스를 통해 배포되었습니다. 여러분은 매달 높은 양의 트래픽을 경험하고 있으며, 이로 인해 EC2 인스턴스의 작업량과 네트워크 비용이 증가하고 있는 상황입니다. 웹사이트를 리팩터링하지 않고 EC2 부하와 네트워크 비용을 줄이기 위해서는 어떤 방법이 권장될까요 ?

• A. 마스터팩을 S3으로 호스팅
• B. Application Load Balancer 캐싱 활성화
• C. EC2 인스턴스 스케일 업
• D. Amazon CloudFront 배포 생성

✅ Amazon CloudFront는 낮은 지연 시간과 빠른 전송 속도로 전역의 고객들에게 데이터, 영상, 애플리케이션 및 API를 전송해 주는 고속 콘텐츠 전송 네트워크(CDN)입니다. Amazon CloudFront는 Application Load Balancer 앞에서 사용될 수 있습니다.

10. 이 AWS 서비스를 사용하면 실시간으로 초당 기가바이트의 데이터를 포착할 수 있고, 리플레이 기능을 통해 이러한 데이터를 여러 개의 소비 애플리케이션으로 전송할 수 있습니다.

• A. Kinesis 데이터 스트림
• B. Amazon S3
• C. Amazon MQ

✅ Amazon Kinesis Data Streams (KDS)은 확장성과 내구성이 뛰어난 실시간 데이터 스트리밍 서비스입니다. 이는 웹사이트, 클릭스트림, 데이터베이스 이벤트 스트림, 금융 거래, 소셜 미디어 피드, IT 로그 및 위치 추적 이벤트 등의 수백 개 소스로부터 초당 GB에 달하는 데이터를 지속적으로 포착할 수 있습니다.

1. 데이터를 프로세싱하는 데에 대략 1시간 정도가 걸리는 Lambda 함수를 생성했습니다. 코드를 머신에서 로컬로 실행했을 때에는 문제가 없었으나 Lambda 함수를 호출할 때는 3초가 지난 후 '시간초과' 오류가 발생하여 실패합니다. 어떻게 해야 할까요 ?

• A. Lambda의 시간 초과를 25분으로 구성
• B. Lambda의 메모리를 10GB으로 구성
• C. 코드를 다른 곳(예: EC2 인스턴스)에서 실행

✅ Lambda의 최대 실행 시간은 15분입니다. 코드를 EC2 인스턴스처럼 다른 곳에서 실행할 수도 있고, Amazon ECS를 사용할 수도 있습니다.

2. 다음 중 동적 DB_URL 변수를 Lambda 함수의 코드로 주입하기 위한 최적의 방법은 무엇일까요 ?

• A. Lambda의 환경 변수 사용
• B. 코드 내에 넣고 zip 파일 생성하기
• C. 코드 자체에 넣기

✅ Lambda의 환경 변수를 사용하면 코드를 업데이트하지 않고 함수의 행위 특성을 조정할 수 있습니다.

3. DynamoDB 표를 생성하기 전에는 DynamoDB 테이블이 실행될 EC2 인스턴스를 프로비저닝해야 합니다.

• A. 맞습니다.
• B. 아닙니다.

✅ DynamoDB는 프로비저닝, 패치 혹은 관리할 서버가 없고 설치, 유지 및 운용해야 할 소프트웨어가 없는 서버리스 서비스입니다. DynamoDB는 용량 조정 및 성능 유지를 위한 테이블의 확장 및 축소를 자동으로 스케일링합니다. 이는 프로비저닝(RCU & WCU 지정) 및 온디맨드 (사용한 만큼의 비용 책정) 용량 모드 모두를 제공합니다

4. DynamoDB 테이블을 10 RCU와 10 WCU로 프로비저닝했습니다. 한 달 후, 더 많은 읽기 트래픽을 처리하기 위해 RCU를 증가시키려 합니다. 어떻게 해야 할까요 ?

• A. RCU는 증가, WCU는 동일하게 유지
• B. RCU와 WCU 모두를 증가시켜야 함
• C. RCU 증가 및 WCU 감소

✅ RCU와 WCU는 분리되어 있으므로, 각 값을 개별적으로 증가/감소시킬 수 있습니다.

5. DynamoDB를 데이터베이스로 사용하는 전자 상거래 웹사이트가 있습니다. 곧 크리스마스 세일 기간에 들어갈 예정이며, 굉장히 인기가 높은 몇몇 항목들이 높은 조회수를 기록할 것으로 에상하고 있습니다. 안타깝게도 작년에는 높은 트래픽의 양으로 인해 ProvisionedThroughputExceededException 예외 처리 오류가 발생했습니다. 이 오류의 재발을 방지하려면 어떻게 해야 할까요 ?

• A. RCU를 아주 높은 값으로 설정
• B. DAX 클러스터 생성하기
• C. 세일 기간 중 데이터베이스를 DynamoDB 밖으로 이전시키기

✅ DynamoDB Accelerator(DAX)는 완전 관리형에 고가용성을 갖춘 DynamoDB 용 인메모리 캐시이며 최대 10배까지 성능을 향상시켜 줍니다. 이는 가장 자주 사용되는 데이터를 캐시해 DynamoDB 테이블의 핫 키에서 과도한 양의 읽기를 오프로딩 해주어 ProvisionedThroughputExceededException 예외 처리 오류를 방지합니다.

6. DynamoDB를 데이터 저장소로 사용하는 모바일 애플리케이션을 개발했습니다. 신규 사용자가 가입한 후 환영 이메일을 자동으로 보내려고 합니다. 이를 달성하는 가장 효율적인 방법은 무엇일까요 ?

• A. CloudWatct Event를 사용해 Lambda 함수를 매 분 실행하여 테이블에 등록된 새로운 사용자를 스캔하게 만들기
• B. SNS와 DynamoDB 통합을 활성화
• C. DynamoDB와 Streams을 활성화하고 이메일을 보내기 위해 Lambda 함수를 호출하도록 구성

7. 서버리스 API를 생성하기 위해서는 Amazon API Gateway를 ( ) 와 통합해야 합니다.

• A. EC2 인스턴스
• B. Elastic Loda Balancing
• C. AWS Lambda

8. 엣지 최적화 API 게이트웨이를 사용할 경우, API Gateway가 모든 AWS 리전의 CloudFront 엣지 로케이션에 존재하게 됩니다.

• A. 아닙니다.
• B. 맞습니다.

✅ 엣지 최적화 API Gateway는 지리적으로 분산된 클라이언트에 가장 적합합니다. API 요청은 가장 가까운 CloudFront 엣지 로케이션으로 라우팅되며, 이는 지연 시간을 향상시킵니다. API Gateway는 여전히 하나의 AWS 리전에 존재합니다.

9. 사용자들이 여러분의 API Gateway가 호스팅하는 API로 요청을 보내기 전에 Facebook을 이용해 인증을 하도록 만들려 합니다. 매끄러운 인증 통합을 위해서는 어떤 방법을 사용해야 할까요 ?

• A. Amazon Cognito Sync
• B. Lambda 권한 부여자가 있는 DynamoDB 사용자 테이블
• C. Amazon Cognito 사용자 풀

✅ Amazon Cognito 사용자 풀은 Facebook과 통합되어 애플리케이션의 사용자들에게 인증된 로그인을 제공합니다.

10. 프로덕션에서 실행하고 있는 애플리케이션은 DynamoDB를 데이터베이스로 활용하고 있으며 원활하고 지속적인 사용량을 경험하고 있습니다. 애플리케이션을 개발 모드에서도 실행해야 하는데, 이 모드에서는 예쌍 불가능한 요청 볼륨을 경험하게 될 겁니다. 이런 경우, 어떤 방법을 가장 비용 효율적인 솔루션으로 추천해야 할까요 ?

• A. 개발 및 프로덕션 모두에 오토 스케일링이 활성화되어 있는 프로비저닝된 용량 모드 사용하기
• B. 프로덕션에는 오토 스케일링이 활성화된 프로비저닝된 용량모드를 사용하고 개발에는 온디맨드 용량 모드 사용하기
• C. 개발에는 오토 스케일링이 활성화된 프로비저닝된 용량 모드를 사용하고 프로덕션에는 온디맨드 용량 모드 사용하기
• D. 개발 및 프로덕션 모두에 온디맨드 용량 모드 사용하기

11. CloudFront 배포를 통해 전역적으로 제공되는 애플리케이션이 있습니다. 인증 요청이 오리진까지 전달되게 하는 대신, CloudFront 엣지 로케이션에서 사용자를 인증하려 합니다. 이 요구 사항을 만족시키기 위해서는 어떤 방법을 사용해야 할까요 ?

• A. Lambda@Edge
• B. API Gateway
• C. DynamoDB
• D. AWS 글로벌 액셀러레이터

✅ Lambda@Edge는 CloudFront의 기능으로 사용자에 가깝게 코드를 실행하도록 해주어 성능을 향상시키고 지연 시간을 줄여 줍니다.

12. DynamoDB 테이블 내 항목의 최대 크기는 ( )입니다.

• A. 1MB
• B. 500KB
• C. 400KB
• D. 400MB

EC2와 EC2 & Docker 가상화 방식

도커 구동 방식

도커 컨테이너와 도커 이미지는 어떻게 생성될까요 ?

먼저 도커 파일을 생성해야 합니다. 기본 이미지 등을 작성하고 데이터를 도커 이미지에 복사하는 겁니다. 그러면 애플리케이션을 구동할 수 있고 애플리케이션을 실행해 주는 명령을 내릴 수 있게 됩니다. 도커 파일을 정의하면 그 파일이 도커 이미지를 만듭니다. 도커 이미지가 생기면 도커를 실행할 수 있고 이것이 도커 컨테이너를 만들어줍니다.

도커 이미지는 저장도 되는데 도커 푸시를 통해 도커 리포지토리에 푸시할 수 있습니다. 도커 허브나 Amazon ECR이 될 수 있습니다. 이미지를 풀하면 도커 풀도 가능한데 그러면 구동이 가능해집니다. 이것이 도커의 작동원리입니다.

AWS Container Management Platform

AWS에서 도커의 컨테이너를 어떻게 가동할까요 ?

컨테이너 관리 플랫폼이 필요합니다. 세 가지 선택지가 있는데 먼저 ECS는 Amazon 자체의 컨테이너 플랫폼이며 Fargate는 ECS와 비슷하지만 Amazon 자체의 서버리스 컨테이너 플랫폼입니다. 마지막으로 EKS는 Amazon의 관리형 Kubernetes 플랫폼으로 오픈소스 컨테이너 관리 플랫폼입니다.

ECS

ECS는 Elastic Container Service의 약자이며 AWS에서 도커 컨테이너를 실행하게 해주는 서비스입니다. 그러기 위해 인프라를 유지하고 프로비저닝해야 합니다. EC2 인스턴스가 ECS 클러스터를 지원합니다. Fargate와 함께 EC2 인스턴스를 유지하지 않아도 되는 솔루션도 있습니다. ECS는 한 번 컨테이너를 갖추고 나면 애플리케이션 로드 밸런서와 통합해서 여러분의 서비스와 태스크를 세상에 노출시킵니다.

ECS 서비스는 각각 다른 유형의 컨테이너를 작동시키고 있습니다. ECS 서비스는 새 도커 컨테이너를 시작하고 싶을 때 도커 컨테이너를 어디에 위치시킬지 찾습니다. EC2 인스턴스에서 말이죠. 이 경우 EC2 인스턴스들은 리소스와 CPU와 RAM입니다. 도커 컨테이너는 요구 사항이 있는데 필요한 CPU와 RAM의 용량이 정해져 있습니다. 그 도커 컨테이너는 특정 EC2 인스턴스에 위치하게 됩니다.

ECS 실행 유형

EC2 실행 유형

먼저 살펴볼 것은 Amazon EC2 실행 유형입니다. 리전과 VPC 두 개의 가용 영역과 함께 Amazon ECS 클러스터가 있다고 해봅시다. 보시다시피 VPC는 하나인데 다중 AZ에 걸쳐 정의돼있습니다. 오토 스케일링 그룹을 생성해서 EC2 인스턴스와 컨테이너 인스턴스들을 생성합니다. 컨테이너 인스턴스들도 서로 유형이 다릅니다. m5.xlarge나 t2.mall이 있고 다른 가용 영역에도 마찬가지로 m5.xlarge와 t2.small이 있습니다. 이 컨테이너들은 모두 하나 또는 그 이상의 오토 스케일링 그룹에 속해 있습니다. 그리고 이것들을 Amazon ECS 클러스터에 등록하길 원합니다. 그러려면 ECS 에이전트를 인스턴스들에서 운영해야 하는데 수동으로 하지 않아도 됩니다. ECS를 위해 만들어진 AMI를 사용한다면 ECS 에이전트는 사전 구성이 됩니다. 그래서 ECS 에이전트가 이 모든 컨테이너 인스턴스들에서 구동됩니다.

ECS 에이전트로 인해 이 컨테이너 인스턴스들은 Amazon ECS 클러스터에 등록될 것이고 ECS 태스크들을 실행하는 데 사용될 수 있을 겁니다. 따라서 컨테이너 인스턴스가 크다면 ECS 태스크를 많이 실행할 수 있습니다.

Fargate 실행 유형

또 다른 서비스로는 Fargate가 있습니다.Fargate는 AWS에서 도커 컨테이너 실행을 하게 합니다. 인프라를 프로비저닝할 필요가 없는 겁니다. 관리하거나 실행할 EC2가 없어서 아주 간단합니다. 그래서 서버리스 오퍼링이라고 불립니다. 서버를 관리하지 않기 때문에요. 그래서 도커 컨테이너를 실행하기가 더 간단하고 쉽습니다.

AWS는 CPU와 RAM이 얼마나 필요한지에 따라 컨테이너를 실행해 줍니다. 그리고 백엔드의 어디에서 실행되는지는 상관 없습니다. AWS가 알아서 처리하고 숨기기 때문입니다. Fargate 서비스를 살펴보면 아주 간단하게 새 도커 컨테이너가 필요하고 Fargate 클러스터에서 새 ECS 태스크가 실행돼야 한다고 하면 Fargate는 우리가 원하는 걸 실행해 줍니다. EC2 인스턴스도 필요 없습니다. 컨테이너가 그냥 실행됩니다. ECS의 Fargate 실행 유형에서는 Fargate가 ECS의 일부입니다.

ECS를 위한 Fargate 실행 유형에서는 똑같이 두 개의 가용 영역과 VPC, 리전, 클러스터가 있다고 가정해봅니다. 이번에는 Fargate 서비스가 태스크를 실행할 것이고 EC2 인스턴스를 미리 생성해 줄 필요가 없어서 훨씬 간단해집니다. Fargate 태스크에 액세스하려면 ENI, 즉 일래스틱 네트워크 인터페이스가 필요한데 VPC에서 실행되는 것으로 태스크를 네트워크 IP에 바인딩해줍니다. 이렇게 태스크에 액세스할 수 있게 됩니다. 태스크가 늘어나면 ENI도 더 생성되며 태스크마다 전부 다른 ENI가 생성됩니다. 위 사진에서는 4개의 Fargate 태스크가 실행 중이며 따라서 VPC에서는 네 개의 ENI가 실행 중입니다. ENI가 별개의 IP이기 때문에 충분한 IP 주소들을 가지고 있는지 확인해야 합니다. VPC에 사설 IP가 충분한 지 살펴봐야합니다. 즉 Fargate 클러스터를 가동할 만큼 충분히 큰 VPC가 있어야 합니다. 태스크가 많을 경우를 대비해서요.

ECS 태스크들은 AWS 서비스에서 연산을 실행할 수도 있습니다. 예를 들면 DynamoDB나 Amazon S3와 통신하는 겁니다. 그래서 IAM 역할이 있어야 합니다. EC2 인스턴스에 IAM 역할이 있는 건 알지만 ECS 태스크에도 IAM 역할이 있습니다. EC2 인스턴스가 Amazon ECS 클러스터를 가동하는 예시를 살펴봅니다.

ECS IAM Role

도커 컨테이너가 애플리케이션을 가동하면 이 태스크 역할은 태스크에 연결되므로 태스크를 생성하면 태스크 역할을 연결하게 됩니다. 그래서 각 태스크가 특정 역할을 가지게 됩니다. EC2 인스턴스를 가동한 두 번째 태스크가 있다면 그 태스크를 위한 새 ECS 태스크 역할을 생성하는 게 좋습니다. ECS 서비스가 여러 개고 태스크를 구동할 거라면 서비스마다 다른 ECS 태스크 역할을 주는 것이 좋습니다. 그리고 태스크 정의에서 정의합니다. 한 번 태스크 역할이 ECS 태스크에 연결되면 예를 들어 Amazon S3 버킷에 액세스할 수 있고 Amazon EC2 인스턴스에서 가동 중인 태스크일 경우 S3 버킷에 액세스하는 것이 허용됩니다. 마찬가지로 두 번째 태스크 역할이 DynamoDB와 통신한다면 역할은 그 태스크만 DynamoDB에 액세스하는 것을 허용합니다. 그래서 보안이 세분화됩니다. 태스크의 유형이 다양한 만큼 많은 태스크 역할도 있게 됩니다. 특정 AWS 서비스에 액세스해야 하는 태스크가 있는 ECS 서비스가 있다면 ECS 태스크 역할을 새로 만드는 겁니다.

ECS 태스크의 데이터 공유

ECS는 EFS 파일 시스템과 통합됩니다. EC2 인스턴스가 존재하고 태스크가 여러 개라면 EFS 파일 시스템을 생성해서 파일 시스템에 ECS 태스크를 직접 마운트하는 것도 가능하며 EC2 인스턴스에도 작동합니다. Fargate 태스크도 가능합니다. 태스크에 EFS 볼륨을 마운트하면 데이터를 공유할 수 있습니다. EFS는 다중 가용 영역에 걸쳐 사용할 수 있기 때문에 태스크 역시 어느 가용 영역에서든 실행할 수 있습니다. EFS 볼륨에서도 동일한 데이터를 공유할 수 있습니다. Fargate와 EFS를 함께 사용한다면 서버리스 태스크 관리와 데이터 저장소 EFS를 쓸 수 있는데 그러면 서버를 관리하지 않고 완전한 서버리스 형태로 데이터를 저장하고 컴퓨팅을 실행할 수 있습니다. ECS와 EFS를 함께 쓰는 사용 사례는 컨테이너를 위한 지속형 다중 AZ 공유 스토리지를 사용하는 것입니다.

ECS 서비스, 로드 밸런싱

Amazon ECS 클러스터에 EC2 실행 타입으로 두 개의 컨테이너 인스턴스가 있다고 가정할 때 Amazon ECS 클러스터에 여러 서비스를 가동할 수 있습니다. 여러 태스크를 여러 EC2 인스턴스에 걸쳐 가동하는 서비스 A가 있습니다. 이 태스크를 사용자들에게 노출시키고 싶다면 애플리케이션 로드 밸런서를 생성해서 태스크에 직접 통합시킬 수도 있습니다. 사용자들에게 애플리케이션 로드 밸런서의 DNS나 URL만을 주는 방법도 있습니다. 로드 밸런서의 뒤에서는 ECS 태스크에 오는 모든 요청을 포워딩합니다. ECS 서비스의 일부로서 가동되고 있는 요청들입니다. Amazon ECS 클러스터 하나에서 다중 서비스를 가동할 수 있습니다. 만약 서비스 B라는 또 다른 서비스를 생성하면 태스크를 두 개만 가동합니다. 마찬가지로 애플리케이션을 노출시키려면 같거나 새로운 애플리케이션 로드 밸런서를 연결합니다. 가장 좋은 방법은 예를 들자면 컨테이너를 지정된 포트 없이 실행하는 겁니다. 컨테이너를 실행할 때 예를 들어 NodeJS 애플리케이션이라면 EC2 인스턴스에 배정된 무작위 포트를 얻는 겁니다. 이런 경우에는 컨테이너에 무작위 포트가 지정되는데 서로 다른 네 개의 태스크에 서로 다른 두 개의 ECS 컨테이너 인스턴스가 배정된 것입니다.

로드 밸런서는 어떤 포트와 통신해야 할지 어떻게 알까요 ?

애플리케이션 로드 밸런서는 특정 포트와 통신이 가능한데 ECS로는 ALB 밖으로 포트 80, 443을 노출할 수 있습니다. ALB의 동적 포트 포워딩 기능 덕분에 ALB가 ECS 태스크에 대한 올바른 포트를 EC2 인스턴스에서 찾을 수 있게 됩니다. ALB가 ECS에서 특정 서비스에 한 번 등록되면 태스크를 찾아서 자동으로 올바른 포트를 통해 통신하게 됩니다. 같은 컨테이너에서 원하는 만큼 많은 인스턴스를 하나의 EC2 인스턴스에서 가동하고 하나의 애플리케이션 로드 밸런서를 통해 노출시킬 수 있다는 것입니다. 그러기 위해서는 네트워크 보안을 짚고 넘어가야 합니다.

EC2 인스턴스와 ALB의 보안그룹

EC2 인스턴스의 보안 그룹에서 ALB 보안그룹으로부터 오는 포트를 허용해야 합니다. ALB가 인스턴스 상의 다양한 포트 그룹과 통신할 테고 네트워킹을 위해 보안 규칙을 설정해야 하는 것입니다. 하지만 Fargate의 경우 조금 다릅니다.

Fargate 태스크와 ALB의 보안 그룹

Fargate는 가동되고 있는 모든 태스크에 대해 ENI를 생성하는데 그래서 ENI는 고유의 IP가 있지만 포트는 그대로입니다. 예를 들어 태스크가 세 개 있고 각 태스크의 IP는 다르지만 모두 80번 포트를 가지고 있다고 가정했을 때 로드 밸런서를 생성하면 서로 다른 IP들과 통신하겠지만 전부 같은 포트, 80번과 통신합니다. 네트워크 보안 측면에서 이를 가능하게 하려면 보안 그룹으로서의 ENI가 태스크 보드에서 애플리케이션 로드 밸런서를 반드시 허용해야 합니다.

ECS 클러스터 스케일링 (서비스 스케일링)

다양한 지표에서 ECS 서비스를 스케일링할 수 있습니다. 예를 들어 서비스 CPU 사용량입니다. 서비스에 태스크가 두 개 실행되고 액세스하는 사용자는 하나일 때 CPU 사용량은 매우 낮습니다. 갑자기 오토 스케일링을 설정해서 여러 사용자가 서비스에 액세스할 수 있게 되면 CPU 사용령도 높아지게 됩니다. CloudWatch 지표를 ECS 서비스 전체 평균 CPU 사용량으로 설정해서 특정 임계값을 넘길 때 CloudWatch 경보를 작동하도록 만들 수 있습니다. 그러면 ECS 서비스가 자동 스케일링되어 새로운 태스크를 시작합니다. Fargate와 EC2 실행 유형 모두에서 이렇게 작동합니다. 오토 스케일링 그룹과 굉장히 비슷한 과정입니다. 그러나 EC2 인스턴스에 이런 태스크를 실행할 때가 있습니다. EC2 실행 유형을 사용하는 경우인데 그래서 때때로 EC2 인스턴스를 스케일링할 필요가 있습니다. 그렇지 않으면 새로운 태스크를 실행할 공간이 남지 않을 겁니다.

ECS 클러스터 스케일링 (EC2 인스턴스 스케일링)

따라서 EC2 인스턴스의 ECS 클러스터를 스케일링하려면 Amazon ECS의 Capacity Provider를 쓰는데 EC2 인스턴스 실행 유형에서만 선택할 수 있는 옵션입니다. 즉 ECS 스케일링은 태스크를 실행할 충분한 용량이 없는 경우 해당 서비스를 지원하는 EC2 인스턴스의 오토 스케일링 그룹을 실행하고 ECS 클러스터에 EC2 인스턴스를 추가합니다. EC2 서비스에는 두 가지 수준의 스케일링이 있습니다. 바로 서비스 스케일링 및 백엔드 EC2 인스턴스 스케일링입니다. Fargate 실행 유형을 사용하지 않고 다른 방법으로 ECS 서비스를 스케일링하려면 Amazon SQS 대기열 길이를 사용합니다. SQS 대기열에서 메시지를 읽는 서비스가 있어서 메시지를 폴링한다고 가정할 때 ECS 서비스에 오토 스케일링을 설정해서 CloudWatch 지표의 대기열 길이를 보면 특정 임계값을 초과할 경우가 있습니다. 대기열에 메시지가 너무 많을 때입니다. 이제 CloudWatch 경보를 작동하고 Amazon ECS 서비스의 오토 스케일링 서비스가 스케일링되고 나면 새로운 태스크가 생성됩니다. 즉 사용 중인 EC2 인스턴스를 스케일링하고 싶다면 ECS Capacity Provider를 설정해 주면 됩니다.

ECS Rolling Update

• Minumum healthy percent: 100
• Maximum percent: 200

  이번에는 ECS 서비스를 업데이트하는 방법입니다. 바로 롤링 업데이트를 사용하는데 즉 ECS 서비스를 v1에서 v2로 업데이트할 때 태스크가 한 번에 얼마나 어떤 순서로 시작되고 중지되는지 제어할 수 있습니다. 그래서 ECS 업데이트를 보면 새로운 태스크 정의의 개수를 선택하고 ECS 서비스를 업데이트할 때 두 가지 설정이 있습니다. 최소 정상 백분율 및 최대 백분율입니다. 예를 들어 ECS 서비스에 실행 중인 태스크가 9개이고 실제 실행 가능 용량의 100%를 차지합니다. 이때 최소 정상 백분율을 100이하로 설정해 봅시다. 이 경우 남아있는 태스크가 최소 정상 백분율만큼 충분하다면 오른쪽에 있는 작업은 모두 종료할 수 있게 됩니다. 그리고 최대 백분율은 버전 2에서 얼마나 많은 태스크를 생성할지 나타내는데 기본적으로 서비스를 롤링 업데이트합니다. 이렇게 두 가지 설정이 업데이트에 영향을 줍니다. 계속해서 새로운 태스크를 생성하고 태스크를 전부 종료하는 등 이 모든 과정이 태스크를 전부 종료해서 새로운 버전으로 업데이트하기 위해서입니다.

ECS Rolling Update Senario

• Minumum healthy percent: 50%

• Maximum percent: 100%
• 시작 태스크: 4
  

  • Minumum healthy percent: 50%

• Maximum percent: 150%
• 시작 태스크: 4

ECR (Elastic Container Registry)

• 관리 배포하기 위해 사용, 스토리지 사용에 따라 비용 청구
• Amazon ECS로 완전히 통합
• IAM 사용, ECR로 업로드된 이미지는 모두 Amazon S3에 저장
• 이미지 취약성 스캔, 버전 관리, 태깅, 이미지 수명 주기 지원

EKS (Elastic Kubernetes Service)

• AWS에 관리형 쿠버네티스 클러스터를 실행
• 오픈 소스 시스템으로 컨테이너화된 애플리케이션(도커)등을 자동으로 배포, 스케일링, 관리
• 일종의 규격화를 제공하는 다양한 클라우드 공급자 사용 (Cloud-Agnostic)
• Azure나 Google 클라우드 등 어떤 클라우드에서도 사용 가능
• EC2 실행모드, Fargate 모드

1. 온프레미스로 호스팅된 다중 도커 기반의 애플리케이션이 있으며, 이를 AWS로 이전시키려 합니다. 여러분은 인프라를 프로비저닝하거나 관리할 의향이 없으며 그냥 컨테이너를 AWS 상에서 실행하려고 합니다. 이 경우, 다음 중 어떤 AWS 서비스를 선택해야 할까요 ?

• A. Elastic Container Service (ECS)
• B. Elastic Container Registry (ECR)
• C. AWS Fargate
• D. Elastic Kubernetes Service (EKS)

✅ AWS Fargate를 사용하면 서버를 관리할 필요 없이 AWS 상에서 컨테이너를 실행할 수 있습니다.

2. Amazon Elastic Container Service (ECS)에는 두 가지의 실행 유형이 있습니다. ( )와 ( )입니다.

• A. Amazon EC2 실행 유형과 Fargate 실행 유형
• B. Amazon EC2 실행 유형과 EKS 실행 유형
• C. Fargate 실행 유형과 EKS 실행 유형

3. ECS 클러스터(EC2 실행 유형)상에 호스팅된 애플리케이션이 있습니다. 여러분은 ECS 태스크가 S3 버킷으로 파일을 업로드하게 하려 합니다. 이를 위해서는 다음 중 어떤 ECS 태스크용 IAM 역할을 수정해야 할까요 ?

• A. EC2 인스턴스 프로필
• B. ECS 태스크 역할

✅ ECS 태스크 역할은 ECS 태스크 자체가 사용하는 IAM 역할입니다. 컨테이너가 S3, SQS 등이 다른 AWS 서비스를 호출하려 할 때 사용합니다.

4. 도커 컨테이너 상에서 실행 중인 WordPress 웹사이트를 온프레미스에서 AWS로 이전하려 합니다. ECS 클러스터에서 애플리케이션을 실행하기로 했으나, 도커 컨테이너가 웹사이트 파일, 이미지, 영상을 비롯한 동일한 WordPress 웹사이트 콘텐츠에 액세스할 수 있게끔 하려 합니다. 이를 위해서는 어떤 방법이 권장될까요 ?

• A. EFS 볼륨 마운트
• B. EBS 볼륨 마운트
• C. EC2 인스턴스 스토어 사용

✅ EFS 볼륨은 서로 다른 EC2 인스턴스와 서로 다른 ECS 태스크 간의 공유가 가능합니다. 컨테이너의 영구적인 다중 AZ 공유 스토리지로 사용될 수 있습니다.

5. EC2 인스턴스로 구성된 ECS 클러스터 상에 애플리케이션을 배포하려 합니다. 현재, 클러스터는 DynamoDB에 대한 API 호출을 성공적으로 발행한 애플리케이션 하나를 호스팅하고 있습니다. S3로의 API 호출을 발행하는 두 번째 애플리케이션을 추가하려는데 권한 부여 관련 문제가 발생했습니다. 이 문제를 해결하고 적절한 보안을 유지하기 위해서는 어떤 방법을 사용해야 할까요 ?

• A. EC2 인스턴스 역할을 수정해 S3에 대한 권한 추가
• B. 새 애플리케이션을 위한 IAM 역할 생성
• C. Fargate 모드 활성화
• D. ECS 태스크를 허용하도록 S3 버킷 정책 수정

6. Application Load Balancer가 동일한 ECS 컨테이너 인스턴스에서 실행 중인 다수의 ECS 태스크로 트래픽을 리다이렉트하게 만들기 위해서는 다음 중 어떤 기능을 사용해야 할까요 ?

• A. 동적 포트 매핑
• B. 자동 포트 매핑
• C. ECS 태스크 정의
• D. ECS 서비스

7. 온프레미스 도커 기반 애플리케이션을 Amazon ECS로 이전하려 합니다. 여러분은 도커 허브 컨테이너 이미지 라이브러리를 컨테이너 이미지 리포지토리로 사용하고 있었습니다. 다음의 대체 AWS 서비스들 중 Amazon ECS와 완전히 통합되어 있는 서비스는 무엇인가요 ?

• A. AWS Fargate
• B. Elastic Container Registry (ECR)
• C. Elastic Kubernetes Service (EKS)
• D. Amazon EC2

✅ Amazon ECR은 컨테이너 이미지를 손쉽게 저장, 관리, 공유 및 배포할 수 있도록 해주는 완전 관리형 컨테이너 레지스트리입니다. 이는 도커 기반 애플리케이션의 실행에는 도움이 되지 않을 겁니다.

SQS

• 소비자가 SQS 대기열에서부터 요청 메시지를 보내고 데이터를 끌어옵니다.
• 데이터가 처리된 이후에 소비자는 대기열에서 해당 데이터를 삭제하여 다른 소비자가 다시는 읽을 수 없게 해야 합니다.
• 원하는 만큼의 작업자 즉 소비자를 가질 수 있고 대기열에서 모든 메시지를 소비하고 삭제하도록 모든 작업자가 함께 작업합니다.
• 관리형 서비스이므로 미리 처리량을 프로비저닝할 필요 없고 방대한 수의 메시지를 빠르게 스케일링할 수 있습니다.
• 메시지 순서를 보장하려면 FIFO 대기열이라고 하는 선입 선출 방식을 사용해야 합니다.
• 또한 개별 메시지 지연 능력이 있어서 특정 시간 후에 메시지를 확인하도록 할 수 있습니다. 예를 들어 30초 후에 대기열의 소비자가 메시지를 확인하도록 할 수도 있습니다.

  SQS Request-Response Systems

  Requesters는 여러 생산자가 될 수도 있으며 이들이 모든 요청을 요청 대기열로 보냅니다. 이렇게 해서 Requesters와 Responders를 분리합니다. 그리고 중간에서 SQS를 이용하는 방식으로 요청 및 응답의 양을 스케일링할 수 있습니다. Responders가 있는 곳은 Auto Scaling Group으로 SQS 대기열에서 실행 중인 애플리케이션이 됩니다. 그리고 Requesters에 응답하는데 요청 받은 대기열을 사용하는 것이 아니라 또 다른 대기열에 응답을 넣는 방법을 사용합니다. 여기서 핵심은 Requesters가 메시지를 SQS 대기열에 보낼 때 상호 관련 ID를 함께 보내는데 그 ID는 요청 번호와 요청의 내용 및 응답할 대기열을 나타냅니다. 즉 이 메시지를 받으면 "응답 대기열 1로 응답하세요"와 같은 뜻이 됩니다. 그럼 이제 Responders는 요청 대기열을 읽고 해당 요청을 처리해서 응답을 생성합니다. 응답을 생성하려는데 대기열이 존재하지 않으면 응답 대기열1이라는 대기열을 만듭니다. 그리고 그 대기열로 응답을 보내면서 이전의 상호 관련 ID를 함께 전송합니다. 이렇게 하면 Requesters는 각각 어떤 응답이 어떤 요청에 대응하는지 알 수 있고 응답 페이로드도 이해할 수 있게 됩니다.
  이 아키텍처에서 중요한 것은 중간에 확장 가능한 백엔드(응답 대기열, Queue)가 있어서 수많은 다양한 요청과 수많은 다양한 응답을 전송할 수 있게 해주면서도 대상 시스템에 과부하를 주지 않는다는 점입니다.
  시험에서 요청 응답 시스템을 어떻게 시행하는지 묻는다면 SQS Temporary Queue Client 즉, SQS 임시 대기열 클라이언트가 답이 됩니다. 이는 AWS에서 직접 생성한 사용 가능한 클라이언트이고 동시에 Java 클라이언트입니다. 이 클라이언트를 사용함으로써 이 패턴의 시행 세부 사항을 걱정할 필요가 없게 됩니다.

SNS

• Pub/SUb 모델이라고 하며 여러 구독자에 데이터를 푸시하면 보내는 메시지 사본을 모두가 수신할 수 있습니다.
• SNS 토픽 당 최대 구독자는 12,500,000명이고 데이터가 SNS로 보내진 후에는 더 이상 지속되지 않습니다. 다시 말해, 데이터가 전달되지 않는 경우 손실될 가능성이 있습니다. 토픽은 100,000개로 제한됩니다. 처리량을 프로비저닝할 필요 없고 SQS와 결합하는 것도 가능하며 팬 아웃 아키텍처 패턴을 사용해 SNS를 SQS와 결합할 수 있습니다.
• SNS FIFO 토픽을 SQS FIFO 대기열이 있는 SNS와 결합할 수 있습니다.

SNS + SQS: Fan out

예를 들어, 구매 서비스가 두 개의 SQS 대기열로 메시지를 보내고 싶은데 직접 보내느 대신에 하나의 메시지를 SNS 주제로 전송하고 대기열들은 SNS 주제의 구독자가 됩니다. 그렇게 함으로써, 사기 탐지 서비스와 선적 서비스가 각각의 SQS 대기열로부터 모든 메시지를 읽을 수 있는 것입니다. 팬아웃 패턴은 완전히 분리된 모델이고 데이터 손실이 전혀 없으며 장시간에 걸쳐 더 많은 SQS 대기열을 SNS 주제의 구독자로 추가할 수 있습니다.

Kinesis

Kinesis Data Streams

• 데이터 스트림으로 스트리밍 데이터를 수집합니다.

  Kinesis Data Firehose

• 데이터 전송 스트림으로 스트리밍 데이터를 처리 및 전송합니다.
• Source: Kinesis Data Streams, Direct PUT
• Destination: Amazon OpenSearch Service, Redshift, S3, HTTP Endpoint
• 3rd party Destination: Coralogix, Datadog, Dynatrace, Honeycomb, LogicMonitor, MongoDB Cloud, New Relice, Splunk, Sumo Logic

  Kinesis Data Analytics

• 데이터 분석 애플리케이션을 사용하여 스트리밍 데이터를 분석합니다.

  • 소비 매커니즘의 향상된 팬아웃의 경우 Kinesis가 소비자에 데이터를 푸시할 수 있으므로 각 소비자 샤드당 1초에 2MB를 얻습니다. 다시 말해 처리량이 후러씬 늘어나고 Kinesis 스트림에서 읽을 수 있는 애플리케이션의 양도 늘어납니다.

• Kinesis 데이터 스트림 안에 데이터가 지속되니 다시 재생할 수도 있습니다. 따라서 Kinesis는 실시간 빅데이터, 분석, ETL에 사용됩니다.

• 샤드 레벨에서 순서가 지정되므로 미리 Kinesis 데이터 스트림당 필요한 샤드를 지정해야 합니다. 그러므로 직접 샤드를 스케일링해야 합니다.

• 데이터는 X일 후에 만료되는데 기록 시점에서 데이터 보존 중 1일과 365일 사이에 해당합니다. 또한 처리량을 프로비저닝해야 하며 Kinesis는 샤드로 구성되어 있어 처리량이 많아질수록 더 많은 샤드를 필요로 합니다. 즉 처리량을 늘리려면 샤드를 추가해야 하며 여기서는 오토 스케일링을 사용할 수 없습니다.

Amazon MQ

온프레미스에서 클라우드로 SQS나 SNS를 사용하는 애플리케이션을 마이그레이션할 때 전부 재설계를 하는 대신 메시지 대기열을 클라우드로 그냥 옮기고 싶을 수 있습니다. 그러기 위해 Amazon MQ를 사용합니다. Amazon MQ는 클라우드에서 Apache ActiveMQ를 관리합니다. 온프레미스에서 클라우드로 애플리케이션을 마이그레이션할 때 그 애플리케이션이 MQTT나 MQP 같은 표준 프로토콜을 사용한다면 Amazon MQ를 사용해야 합니다.

1. 일년 중 최대 세일 기간인 블랙 프라이데이를 준비하고 있는 전자 상거래 웹사이트가 있습니다. 트래픽은 100배가 증가할 것으로 예상됩니다. 이 웹사이트는 이미 SQS 표준 대기열을 사용하고 있습니다. SQS 대기열은 어떻게 준비해야 할까요 ?

• A. AWS 지원 센터에 연락해 SQS 표준 대기열을 준비해줄 것을 요청
• B. SQS 대기열에 오토 스케일링 활성화
• C. SQS 대기열 용량 늘리기
• D. SQS이 자동으로 스케일링해줄 것이므로 아무 조치도 취하지 않음

2. SQS 메시지가 SQS 대기열에 게시된 지 5분이 지난 후에만 소비자들에 의해 처리되도록 하기 위해서는 어떻게 해야 할까요 ?

• A. DelaySeconds 파라미터 늘리기
• B. 가시성 시간초과 변경
• C. 롱 폴링 활성화
• D. Amazon SQS Extended Client 사용

✅ SQS 가시성 시간초과는 Amazon SQS가 다른 소비자들의 메시지 재수신 및 재처리를 막는 기간이며 가시성 시간초과는 대기열에서 소모된 메시지만을 감춤 처리합니다. (기본: 30초, 최소: 0초, 최대: 12시간) ✅ SQS 대기열 지연은 Amazon SQS가 소비자들에게 새로운 SQS 메시지가 보이지 않도록 유지하는 기간입니다. SQS 대기열 지연은 대기열로 처음 추가된 메시지를 감춤 처리합니다. (기본: 0분, 최대 15분)

3. 소비자들이 한 번에 10개의 메시지를 폴링하고 1분 내로 이에 대한 처리를 완료하는 SQS 대기열이 있습니다. 잠시 후, 여러분은 동일한 SQS 메시지를 다른 소비자들도 수신하여 메시지가 한 번 이상 처리되었음을 알게 되었습니다. 이 문제를 해결하기 위해서는 어떻게 해야 할까요 ?

• A. 롱 폴링 활성화
• B. 메시지 생성 시 메시지에 DelaySeconds 파라미터 추가
• C. 가시성 시간 초과 늘리기
• D. 가시성 시간 초과 줄이기

✅ SQS 가시성 시간 초과는 Amazon SQS가 다른 소비자들의 메시지 재수신 및 재처리를 막는 기간입니다. 가시성 시간초과는 대기열에서 소모된 메시지만을 감춤 처리합니다. 가시성 시간초과를 증가시키면 소비자들이 더 오랜 시간 동안 메시지를 처리할 수 있게 해주며, 메시지의 중복 읽기를 방지합니다. (기본: 30초, 최소: 0초, 최대: 12시간)

4. SQS 표준 대기열에서 메시지를 처리하던, 오토 스케일링 그룹의 관리 하에 있는 EC2 인스턴스 플릿(소비자)이 있습니다. 최근 많은 메시지들이 두 번 처리되었다는 점을 발견해 조사를 해본 결과, 이 메시지들을 성공적으로 처리할 수 없음을 알게 되었습니다. 이러한 메시지 실패의 원인은 어떻게 해결(디버깅)해야 할까요 ?

• A. SQS 표준 대기열
• B. SQS 데드 레터 대기열
• C. SQS 대기열 지연
• D. SQS FIFO 대기열

✅ SQS 데드 레터 대기열은 다른 SQS 대기열(소스 대기열)들이 처리(소비)될 수 없는 메시지를 보낼 수 있는 곳입니다. 이를 통해 문제가 되는 메시지들을 분리하여 처리가 실패한 이유를 디버깅할 수 있으므로, 디버깅에 유용합니다.

5. 다음 중 어떤 SQS 대기열 유형을 사용해야 메시지가 순차적으로, 단 한 번만 처리될까요 ?

• A. SQS 표준 대기열
• B. SQS 데드 레터 대기열
• C. SQS 대기열 지연
• D. SQS FIFO 대기열

✅ SQS FIFO(First-In-First-Out) 대기열은 SQS 표준 대기열의 모든 기능을 가지고 있으며, 다음과 같은 두 기능이 추가됩니다. 첫 번째, 어떤 메시지를 보내고 수신했는지에 대한 오더가 엄격하게 보존됩니다. 메시지는 한 번만 전송되며, 소비자가 해당 메시지를 처리하고 삭제할 때까지 사용할 수 있습니다. 두 번째, 복제된 메시지는 대기열에 들어오지 않습니다.

6. 3개의 서로 다른 애플리케이션으로 동일한 메시지를 보내려 합니다. 3개의 애플리케이션 모두 SQS를 사용하고 있습니다. 이를 위해 어떤 접근법을 선택하는 것이 가장 적절할까요 ?

• A. SQS 복제 기능을 사용
• B. SNS + SQS 팬아웃 패턴을 사용
• C. 3개의 SQS 대기열에 개별적으로 메시지 전송하기

✅ 흔히 사용되는 패턴으로, 단 하나의 메시지를 SNS 주제로 전송한 뒤, 다수의 SQS 대기열로 팬 아웃합니다. 이 방식에는 다음의 기능이 포함되어 있습니다. 1. 데이터 손실이 없으며, 향후 더 많은 SQS 대기열(더 많은 애플리케이션)을 추가할 수 있습니다.

7. 한 Kinesis Data Streams에 6개의 샤드가 프로비저닝되어 있습니다. 이 데이터 스트림은 보통 5MB/초의 속도로 데이터를 수신하며, 8MB/초의 속도로 데이터를 전송합니다. 이따금 트래픽이 2배까지 증가하여 ProvisionedThroughputExceedException 예외 처리가 발생합니다. 이 문제를 해결하려면 어떻게 해야 할까요 ?

• A. 더 많은 샤드 추가
• B. Kinesis 복제 활성화
• C. SQS를 Kinesis의 버퍼로 사용

✅ Kinesis Data Streams의 용량 제한은 데이터 스트림 내에 있는 샤드의 수에 의해 결정됩니다. 이러한 제한은 데이터 처리량, 혹은 읽기 데이터 호출에 의해 초과될 수 있습니다. 각 샤드는 1MB/초 만큼의 들어오는 데이터와 2MB/초 만큼의 나가는 데이터를 허용합니다. 충분한 용량을 제공하려면 데이터 스트림의 샤드 수를 증가시켜야 합니다.

8. 한 웹사이트 내에서 사용자들이 클릭하는 순서, 사용자들이 보내는 시간 및 탐색이 어디에서 시작되고 어떻게 종료되는지 등의 클릭스트림 데이터를 분석하고자 합니다. Amazon Kinesis를 사용하기로 했고, 웹사이트가 이러한 클릭스트림 데이터를 Kinesis Data Stream로 전송하도록 구성한 상태입니다. Kinesis Data Stream으로 전송된 데이터를 확인하던 중, 데이터가 순서대로 정렬되어 있지 않으며 한 개별 사용자로부터 온 데이터가 여러 샤드에 분산되어 있다는 것을 알게 되었습니다. 이 경우, 어떻게 문제를 해결해야 할까요 ?

• A. 샤드가 너무 많으므로 오직 1개의 샤드만 사용해야 함.
• B. 다수의 소비자를 사용해서는 안되므로, 오직 하나만을 사용하면 데이터가 재정렬될 것
• C. Kinesis로 보내지는 각 레코드에 사용자의 신원을 나타내는 파티션 키를 추가해야 함

✅ Kinesis Data Streams는 각 데이터 레코드에 연결된 파티션 키를 사용해 주어진 데이터 레코드가 어느 샤드에 속하는지 판단합니다. 각 사용자의 신원을 파티션 키로 사용할 경우, 각 유저에 대한 데이터가 정렬되어 동일한 샤드로 보낼 수 있습니다.

9. 데이터 스트림에 대한 실시간 분석을 수행하려는 경우, 다음 AWS 서비스 중 어느 것이 가장 적절할까요 ?

• A. Amazon SQS
• B. Amazon SNS
• C. Amazon Kinesis Data Analytics
• D. Amazon Kinesis Data Firehose

✅ Kinesis Data Analytics를 사용하려면 Kinesis Data Streams를 기반 데이터 소스로 사용해야 합니다.

10. 대량의 실시간 데이터를 생성하는 애플리케이션을 실행 중이며, 이 데이터를 S3와 Redshift로 로딩하려 합니다. 또한 이 데이터들은 목적지에 도달하기 전에 변환되어야 합니다. 이를 위해, 선택할 수 있는 가장 적절한 아키텍처는 무엇인가요 ?

• A. SQS + AWS Lambda
• B. SNS + HTTP Endpoint
• C. Kinesis Data Streams + Kinesis Data Firehose

✅ Kinesis Data Streams와 Kinesis Data Firehose 조합은 실시간 데이터를 S3와 Redshift로 로딩하기 위한 완벽한 기법 조합입니다. Kinesis Data Firehose는 AWS Lambda를 사용하는 커스텀 데이터 변환을 지원하기도 합니다.

11. 다음 중 AWS SNS를 지원하지 않는 구독자를 고르세요.

• A. Amazon Kinesis
• B. Amazon SQS
• C. HTTP(S) Endpoint
• D. AWS Lambda

✅ Amazon SNS가 메시지를 게시할 수 있는 엔드 포인트는 다음과 같습니다. (HTTP(S), SQS, Lambda, 모바일 푸시, 이메일, SMS)

12. 다음 중 사용자들에게 이메일 알림을 보내려 할 때 도움이 되는 AWS 서비스는 무엇인가요 ?

• A. AWS Lambda를 갖는 Amazon SQS
• B. Amazon SNS
• C. Amazon Kinesis

13. 여러 마이크로 서비스 애플리케이션을 온프레미스로 실행 중이며, 이들은 MQTT 프로토콜을 지원하는 메시지 브로커를 사용해 통신하고 있습니다. 애플리케이션을 새로 엔지니어링하거나 코드를 수정하는 작업 없이, 이 애플리케이션들을 AWS로 이전시키려 합니다. MQTT 프로토콜을 지원하는 관리 메시지 브로커를 활용하기 위해서는 다음 중 어떤 AWS 서비스를 사용해야 할까요 ?

• A. Amazon SQS
• B. Amazon SNS
• C. Amazon Kinesis
• D. Amazon MQ

✅ Amazon MQ는 JMS, NMS와 같은 업계 표준 API를 지원하며 AMQP, STOMP, MQTT 및 WebSocket 등을 비롯한 메시징 프로토콜을 지원합니다.

EBS (Elastic Block Store)

EBS는 인스턴스가 실행 중인 동안 연결 가능한 네트워크 드라이브입니다. EBS 볼륨을 사용하면 인스턴스가 종료된 후에도 데이터를 지속할 수 있습니다. 우리가 인스턴스를 재생성하고 이전 EBS 볼륨을 마운트하면 데이터를 다시 복구할 수 있습니다. 그리고 CCP 레벨의 EBS 볼륨은 (CCP 레벨: 하나의 EBS는 하나의 EC2 인스턴스에만 마운트 가능 / Associate 레벨: 일부 EBS 다중 연결) 한 번에 하나의 인스턴스에만 마운트 할 수 있습니다. 또한 EBS 볼륨을 생성할 때는 특정 가용 영역에서만 가능합니다. 예를 들어 EBS 볼륨이 us-east-1a에서 생성된 경우 us-east-1b에는 연결이 불가능합니다. 즉 EBS 볼륨이란 네트워크 USB 스틱처럼 한 컴퓨터에서 꺼내 다른 컴퓨터에 꽂는 그런 장치는 맞지만 실제 물리적 연결은 없으며 네트워크를 통해 연결되는 것입니다. 무료 등급으로는 매달 30GB의 EBS 스토리지를 범용 SSD 혹은 마그네틱 유형으로 제공됩니다. 인스턴스와 EBS 볼륨이 서로 통신을 하기 위해서는 네트워크를 필요로 합니다. 그리고 네트워크가 사용되기 때문에 컴퓨터가 다른 서버에 도달할 때 지연이 생길 수 있습니다. EBS 볼륨은 네트워크 드라이브이므로 EC2 인스턴스에서 분리될 수 있고 매우 빠르게 다른 인스턴스로 연결될 수 있습니다. 이 때문에 대체 작동 등의 경우에 매우 유용합니다. EBS 볼륨은 특정 가용 영역에 고정되어 있으므로 us-east-1a에 생성된 볼륨은 us-east-1b로 연결이 불가능합니다. 마지막으로 EBS 볼륨을 생성한 후 연결하지 않고 그대로 둘 수도 있습니다. 꼭 EC2 인스턴스에 연결될 필요는 없습니다. 필요한 경우에만 연결이 가능한 아주 강력한 기능입니다.

하지만 스냅샷을 이용하면 다른 가용 영역으로도 볼륨을 옮길 수 있습니다. 또한 볼륨이기 때문에 용량을 미리 결정해야 합니다. 따라서 원하는 양의 GB 및 IOPS, 즉 단위 초당 전송 수를 미리 지정해야 합니다. 기본적으로 여러분이 원하는 EBS 볼륨의 성능을 미리 정의하는 겁니다. 그러면 해당 프로비전 용량에 따라 요금이 청구되고 더 좋은 성능이나 큰 사이즈가 필요하면 이후에 용량을 늘릴 수도 있습니다. us-east-1a에는 EC2 인스턴스 하나가 있고 EBS 볼륨 하나를 EC2 인스턴스를 하나 더 생성한다면 앞서 말했듯이 CCP 레벨의 EBS 볼륨은 한 번에 두 개의 인스턴스와 연결될 수 없습니다. 따라서 이 경우 두 번째 EC2 인스턴스는 고유한 EBS 볼륨이 따로 연결되어야 합니다. 하지만 인스턴스 하나에 두 개의 EBS 볼륨이 연결되는 건 문제없이 가능합니다. 네트워크 USB 스틱 두 개가 머신 하나에 연결되는 상황을 생각하면 됩니다. 이제 EBS 볼륨이 가용 영역에 연결되었습니다. 마지막으로 EC2 인스턴스를 통해 EBS 볼륨을 생성하는 경우 종료 시 삭제라고 하는 속성이 있습니다. 기본 설정으로는 루트 볼륨에 체크되어 있고 새로운 EBS 볼륨에는 체크가 되어 있지 않습니다. 이 옵션을 통해 EC2 인스턴스 종료 시 EBS 행동을 제어할 수 있습니다. 기본적으로 루트 EBS 볼륨은 인스턴스 종료와 함께 삭제되도록 설정이 되어 있습니다. 실제 사용 예시로는 인스턴스가 종료될 때 루트 볼륨을 유지하고자 하는 경우 데이터를 저장하고자 하는 등의 경우에는 루트 볼륨의 종료 시 삭제 속성을 비활성화하면 됩니다.

EBS 스냅샷

언제든 원하는 시점에 EBS 볼륨을 가지고 와서 백업이라고 불리기도 하는 스냅샷(Snapshot)을 생성할 수 있습니다. 즉 추후에 EBS 볼륨을 삭제하더라도 해당 시점에 대한 백업으로 복원할 수 있습니다. 스냅샷을 생성하는 이유는 복원 목적도 있으나 가용 영역(AZ) 또는 리전(Region)에 걸친 스냅샷을 복사할 수 있기 때문입니다. 더불어서 AWS의 다른 리전에 데이터를 전송하여 글로벌 인프라를 활용하는 것입니다.

AMI (Amazon Machine Image)

AMI란 각자의 소프트웨어 구성에 대해 운영 체제를 정의 및 설정하며 모니터링 도구를 설정할 수도 있는데 이때 자체적으로 AMI를 생성하면 부팅과 구성에 시간이 단축됩니다. 이는 여러분의 EC2 인스턴스에 설치하고자 하는 모든 소프트웨어가 AMI를 통해서 사전에 패키징되기 때문입니다. 따라서 AMI를 자체적으로 구성하고 특정 리전에 맞도록 구축함으로써 이들을 원하는 리전에 복사해 놓거나 AWS 글로벌 인프라를 활용할 수 있는 겁니다. 따라서 여러 종류의 AMI에 EC2 인스턴스를 실행할 수 있습니다. AWS 마켓 플레이스 AMI에서도 EC2 인스턴스의 실행이 가능합니다. 이는 다른 사용자가 만들어서 판매하는 AMI로 자주 찾아볼 수 있습니다. AWS의 공급 업체가 자체적으로 AMI나 구성이 훌륭한 소프트웨어를 생성하고 여러분은 시간 절약을 위해 마켓 플레이스 AMI에서 이들을 구매할 수 있습니다. 또한 사용자인 여러분도 AWS 마켓 플레이스에서 AMI를 직접 판매할 수 있습니다.

EC2 인스턴스 스토어

지금까지 EC2 인스턴스에 네트워크 드라이브를 연결하는 방법까지 알아봤으나 그 성능은 제한됩니다. 제한된다는 뜻은 성능 자체는 뛰어나지만 이보다 더 높은 성능을 요구할 때가 있고 이때는 EC2 인스턴스에 연결된 하드웨어 디스크 성능이 향상되어야 합니다. EC2 인스턴스는 가상 머신이지만 실제로는 하드웨어 서버에 물리적으로 연결된 디스크 공간을 갖습니다. 따라서 특정 유형의 EC2 인스턴스는 EC2 인스턴스 스토어라고 불리며 이는 해당하는 물리적 서버에 연결된 하드웨어 드라이브를 가리킵니다. 이 EC2 인스턴스 스토어는 I/O 성능 향상을 위해 활용할 수 있습니다. 이들이 훌륭한 처리량을 갖추고 있어서 매우 향상된 디스크 성능을 요할 때에 활용할 수 있도록 확보할 필요가 있습니다. *이때 주의할 점은 여러분이 EC2 인스턴스, 즉 인스턴스 스토어를 중지 또는 종료하면 해당 스토리지 또한 손실된다는 것입니다. * 이 같은 이유로 이를 임시 스토리지라고 부르며 EC2 인스턴스 스토어가 장기적으로 데이터를 보관할 만한 장소가 될 수 없음을 보여줍니다.

그러면 언제 사용하는 것이 좋을까요 ?

버퍼나 캐시 스크래치 데이터 또는 임시 콘텐츠를 사용하려는 경우 이들을 보관할 좋은 장소가 되지만 장기적인 스토리지는 될 수 없습니다. 장기 스토리지의 경우에는 EBS가 적합합니다. 마지막으로 EC2 인스턴스의 기본 서버에 장애가 발생할 시에는 해당 EC2 인스턴스가 연결된 하드웨어에도 장애가 발생하므로 데이터 손실에 대한 위험이 존재합니다. ** 따라서 EC2 인스턴스 스토어를 사용할 때에는 여러분의 필요에 따라 데이터를 백업해 두거나 복제해 둬야 합니다.**

EBS 볼륨 유형

EBS 볼륨에 대해서는 총 6개의 유형이 있고 이들을 여러 범주로 나눌 수 있습니다.

• 첫째로는 gp2/gp3가 있는데 이는 범용 SSD 볼륨으로 다양한 워크로드에 대해 가격과 성능의 절충안이 되어 줍니다.
• 다음으로는 io1과 io2가 있습니다. 최고 성능을 자랑하는 SSD 볼륨으로 미션 크리티컬이자 지연 시간이 낮고 대용량의 워크로드에 쓰입니다.
• 그리고 st1 볼륨이 있는데 이는 저비용의 HDD 볼륨으로 잦은 접근과 처리량이 많은 워크로드에 쓰입니다.
• sc1 볼륨은 가장 비용이 적게 드는 HDD 볼륨으로 접근 빈도가 낮은 워크로드를 위해 설계되었습니다.
  EBS 볼륨을 정의하는 데에는 크기, 처리량, IOPS가 있습니다. IOPS는 초당 I/O 작업 수를 뜻합니다. EC2 인스턴스에는 gp2/gp3와 io1/io2만이 부팅 볼륨으로 사용될 수 있습니다. 루트 OS가 실행될 위치에 해당합니다. gp2는 짧은 지연 시간을 자랑하며 효율적인 비용의 스토리지입니다. 시스템 부팅 볼륨에서 가상 데스크톱, 개발, 테스트 환경에서 사용할 수 있습니다. 크기는 1GB에서 16TB까지 다양합니다. gp2와 gp3에는 차이가 있는데 gp3는 최신 세대의 볼륨으로 기본 성능으로 3,000 IOPS와 초당 125MB의 처리량을 제공합니다. 각각 IOPS는 최대 16,000 IOPS, 처리량은 1,000MB/S까지 증가시킬 수 있습니다. 이는 연결되어 있지 않다는 뜻입니다. gp2는 좀 더 오래된 버전으로 볼륨이 더 작습니다. 최대 3,000 IOPS, 볼륨과 IOPS가 연결되어 있어서 IOPS가 증가할 때면 즉 볼륨의 GB 수를 늘릴 때에 세 배 더 증가한 16,000 IOPS가 된다는 의미입니다.
  가령 5,334GB라고 한다면 최대 용량인 16,000 IOPS를 초과하는 상황이 발생합니다. gp2/gp3가 비용 효과적인 스토리지이며 gp3에서는 IOPS와 처리량을 독자적으로 설정할 수 있는 반면 gp2에서는 그 둘이 연결되어 있다는 점입니다. 중요한 내용은 프로비저닝을 마친 IOPS로 이는 IOPS 성능을 유지할 필요가 있는 주요 비즈니스 애플리케이션이나 16,000 IOPS 이상을 요하는 애플리케이션에 적합합니다. 일반적으로 데이터베이스 워크로드에 알맞습니다.
  스토리지를 이용하는 경우에는 스토리지 성능과 일관성에 아주 민감하여 gp2 또는 gp3 볼륨에서 io1 또는 io2 볼륨으로 바꾸는 것이 해답입니다. io1/io2 중에서는 최신 세대를 고르는 것이 좋습니다. 4 ~ 16TB에 달하며 Nitro EC2 인스턴스에서는 최대 64,000 IOPS까지 가능합니다. Nitro EC2 인스턴스의 경우 이를 통해 더 높은 IOPS까지 이용할 수 있습니다. Nitro EC2 인스턴스가 아닌 경우에는 최대 32,000 IOPS까지 지원됩니다. 또한 io1/io2를 이용하면 gp3 볼륨처럼 프로비저닝된 IOPS 스토리지 크기와 독자적으로 증가시킬 수 있습니다. io2는 io1과 동일한 비용으로 내구성과 기가 당 IOPS의 수가 더 높습니다. 현재까지는 io2를 사용하는 것이 더 합리적입니다.
  다음은 st1과 sc1에 대해 이야기해보겠습니다. 이 둘은 부팅 볼륨일 수 없습니다. 이전 유형의 볼륨에 해당합니다. 최대 16TB까지 확장되며 두 가지 종류의 볼륨을 제공합니다. 하나는 st1인 처리량 최적화 HDD로 빅 데이터나 데이터 웨어하우징 로그 처리에 적합합니다. 최대 처리량은 초당 500MB 그리고 최대 IOPS는 500 IOPS에 달합니다. 다음으로는 sc1인 콜드 HDD가 있는데 이는 아카이브 데이터용으로 접근 빈도가 낮은 데이터에 적합합니다. 최저 비용으로 데이터를 저장할 때에 사용합니다. 최대 처리량은 초당 250MB 그리고 최대 IOPS도 250 IOPS입니다.

EBS 다중 연결

io1/io2 제품군에 대한 내용입니다. 앞서 EBS 볼륨은 단일한 EC2 인스턴스에만 연결할 수 있다고 했습니다. EBS 다중 연결을 제외한 경우에 말입니다. 다중 연결로 동일한 EBS 볼륨을 동일한 가용 영역 내의 여러 EC2 인스턴스에 연결하여 사용할 수 있습니다. 예들 들어, 세 개의 EC2 인스턴스가 있고 다중 연결이 각능한 io2 볼륨이 있다고 가정해 봅시다. 이 볼륨은 한 번에 총 세 개의 EC2 인스턴스에 연결할 수 있습니다. 이때 각 EC2 인스턴스는 볼륨에 대한 전체 읽기 및 쓰기 권한을 갖습니다. 모든 애플리케이션에서 가능하지는 않으나 해당 애플리케이션 내에서는 동일한 볼륨에서의 동시 쓰기 작업을 관리할 수 있어야 합니다. 따라서 이는 특정 워크 로드에만 해당되며 특정 유형의 EBS 볼륨에 대해서만 가능합니다. 이를 위해서는 반드시 클러스터 인식 파일 시스템을 사용해야 합니다. XFS나 EX4 등은 사용할 수 없습니다. 또한 EBS는 io1이나 io2 제품군일 때만 여러 EC2 인스턴스에 연결이 가능합니다.

EBS 볼륨 암호화

암호화된 EBS 볼륨을 생성하는 즉시 볼륨 내에서 암호화된 저장 데이터를 가져오고 인스턴스와 볼륨 간에 전송되는 모든 데이터는 암호화됩니다. 모든 스냅샷이 암호화되고 스냅샷에서 생성된 모든 볼륨은 암호화 됩니다. 즉 모든 곳이 암호화 되는 셈입니다. 그리고 기존 암호화와 해독 매커니즘이 투명하게 처리되므로 사용자는 할 작업이 없습니다. 모든 작업은 뒷단에서 EC2와 EBS에서 처리됩니다. 전반적으로 암호화는 지연 시간에 미치는 영향도 거의 없고 KMS 즉 AES-256의 키를 활용합니다. 그래서 암호화되지 않은 스냅샷을 복사할 때 암호화를 활성화합니다. 암호화되지 않은 EBS 볼륨을 어떻게 암호화하는지에 대해 얘기해보겠습니다. 이는 아주 중요한 사항입니다. 암호화되지 않은 EBS 볼륨을 암호화하려면 먼저 볼륨의 EBS 스냅샷을 생성하고 복사로 EBS 스냅샷을 암호화합니다. 그런 다음 스냅샷에서 새 EBS 볼륨을 생성하면 해당 볼륨도 암호화되게 됩니다. 이제 암호화된 볼륨을 원본 인스턴스에 연결할 수 있습니다.

EFS (Elastic File System)

다양한 가용 영역에 걸쳐 다수의 EC2 인스턴스에 마운트할 수 있는 관리형 NFS 혹은 네트워크 파일 시스템입니다. 즉 다중 AZ에서 동작하며 이 점이 EFS와 EBS의 가장 큰 차이를 보여줍니다. EBS는 단일 가용 영역에 묶여 있는 반면 EFS는 다중 가용 영역에 걸쳐서 마운트가 가능합니다. 따라서 가용성이 매우 높습니다. 확장성도 높으며 비용도 많이 듭니다. gp2 드라이브 비용의 약 세 배에 달하지만 쓴 만큼만 내면 됩니다. 따라서 너무 많은 데이터를 저장하지 않는 경우 EBS보다 EFS가 저렴할 수 있습니다. EBS는 한 번에 하나의 EC2 인스턴스에만 연결되어 있어서 데이터가 다중의 EC2 인스턴스 간 공유되지 않지만 이 경우 EFS에서는 네트워크 파일 시스템으로 EFS 드라이브의 모든 EC2 인스턴스가 동일한 파일에 대한 접근 권한을 갖습니다. EFS는 콘텐츠 관리, 웹 서비스, 데이터 공유 또는 WordPress 웹사이트에서 쓰입니다. 표준 NFSv4.1 프로토콜이 사용되며 이는 네트워크 드라이브 마운트 시 기본적인 방법입니다. 또한 EFS 파일 시스템에 접근하려면 네트워크 보안인 보안 그룹을 이용해야 합니다. EFS는 Windows가 아닌 Linux 기반 AMI에서만 작동합니다. Windows 인스턴스는 파일 시스템에 EFS를 마운트할 수 없습니다. KMS 키를 사용하여 EFS 유휴 시 암호화를 설정할 수 있습니다. EFS는 POSIX 파일 시스템, 즉 Linux에서만 사용 가능하며 표준 파일 API를 갖습니다. 파일 시스템은 자동으로 확장되며 쓰는 만큼 비용을 내는 방식으로 용량에 구애받지 않고 사용이 가능합니다.

EFS 성능 모드

범용 성능 모드

성능 모드에는 두 가지가 존재합니다. 웹 서버 운영이나 지연 시간에 민감한 파일이 있는 경우 범용 성능 모드를 사용합니다. 예시로 WordPress를 운영할 때에 범용 EFS 파일 시스템을 사용하는 것처럼 말입니다. 이 경우에는 여러 작은 파일에 신속히 접근해야 하는데 EFS가 바로 해당 경우를 위해 제작되었습니다.

Max I/O 성능 모드

EFS에서 대규모 데이터 워크로드를 처리하는 경우 Max I/O 성능 모드가 적합합니다. 지연 시간은 더 길겠지만 처리량은 더 향상됩니다. 이는 훨씬 더 병렬적이므로 빅데이터나 미디어 처리에도 훌륭한 성능을 보입니다.

처리량 모드

처리량 모드는 기본적으로 버스팅(Bursting) 처리량 모드로 설정되어 있습니다. 1TB 스토리지에 대해 초당 50MB를 저장할 수 있으며 여기에 초당 100MB까지 확장이 가능하다는 것입니다. 일반적으로는 파일 시스템의 크기에 따라 처리량이 증가하므로 EFS 파일 시스템의 크기는 줄이면서 처리량을 높이기 위해서는 프로비저닝된 처리량 모드로 설정을 바꿀 수 있습니다. 이 모드에서는 스토리지 크기와 상관없이 처리량을 설정할 수 있습니다. 1TB의 스토리지에 불과하더라도 초당 1GB의 처리량을 요청할 수 있습니다. 파일 시스템 자체는 작으나 높은 처리량을 요구할 때에는 EFS의 프로비저닝 된 처리량 모드로 변경할 필요가 있는 것입니다.

스토리지 계층

마지막으로 시험에 출제될 내용으로는 스토리지 계층을 꼽을 수 있습니다. 이는 파일에 대한 수명 주기 관리 기능으로 30일이 지난 후 새로운 계층으로 파일을 이동시키는 기능입니다. 접근 빈도가 높은 파일에 대해 표준으로 설정되어 있으며 EFS-IA라고 부르며 저비용의 빈도가 낮은 접근에 대한 티어가 있습니다. 이와 같은 파일을 저장할 저비용의 장소인 것입니다. 하지만 해당 파일을 가져올 때마다 관련된 비용이 발생합니다.

EBS vs EFS

EBS 볼륨은 한 번에 하나의 인스턴스에만 연결이 가능하고 특정 가용 영역에 한정됩니다. 예를 들면, EC2 인스턴스가 첫 번째 AZ에 연결됐고 EBS 볼륨은 실제로 해당 AZ 안에 있을 때 EBS는 한 번에 EC2 인스턴스 하나에만 연결이 가능합니다. EBS의 gp2 볼륨에서는 디스크 크기가 늘어나면 IO도 함께 증가합니다. io1은 IO를 볼륨 크기와 관계 없이 독립적으로 증가시킬 수 있습니다. 중요한 데이터베이스를 실행할 때 좋은 방법입니다. EBS를 다른 가용 영역으로 옮기고자 할 때는 가장 먼저 스냅샷을 찍어야 합니다. 스냅샷을 찍었다면 다른 AZ에서 그 스냅샷을 복원시키면 됩니다. 그러면 해당 AZ에 EBS 볼륨이 생성됩니다. EBS의 스냅샷이나 백업을 만들 때에는 EBS 볼륨 내의 IO를 전부 사용하게 되니 인스턴스가 EBS를 사용 중이 아닐 때에만 실행해야 합니다. 그렇지 않으면 성능에 문제가 발생할 수 있습니다. EC2 인스턴스가 종료되면 인스턴스 내의 루트 EBS 볼륨도 기본적으로 종료됩니다. 원할 경우 이 동작은 비활성화할 수 있습니다. 하지만 EFS는 이와 완전히 다릅니다. EFS는 일래스틱 파일 시스템으로 여러 개의 가용 영역에 걸쳐 무수히 많은 인스턴스들에 연결될 수 있습니다. EFS Mount Target을 사용해 특정 AZ에서 EC2 인스턴스들과 EFS 드라이브를 연결해 줄 수도 있습니다. WordPress 같은 웹 사이트 파일을 공유할 때도 EFS를 씁니다. 이는 Linux 인스턴스에서만 가능한데 POSIX 파일 시스템이라 Windows에서는 구동되지 않기 때문입니다. 또한 EFS는 EBS보다 훨씬 비쌉니다. 거의 세 배 정도 더 비싸죠. 하지만 비용을 절약하고 싶은 경우에는 스토리지 티어로 EFS-IA를 사용하고 제품 수명 정책을 사용하면 비용을 절감할 수 있습니다. EFS 사용 시에 또 기억해야 할 점은 EFS는 사용한 만큼만 비용이 청구된다는 점입니다. EBS의 경우에는 실제 사용한 양이 아니라 EBS 드라이브의 크기에 따라 실제 사용량이 아니라 정해진 사용량을 지불한는 식이었습니다. EFS는 다수의 인스턴스에 걸쳐 연결해야 하는 네트워크 파일 시스템에 적합하다는 것을 알아두면 됩니다. 반면 EBS는 네트워크 볼륨을 한 번에 하나의 인스턴스에 연결할 수 있고 특정 AZ 내로 한정됩니다. 인스턴스 스토어는 EC2 인스턴스에 IO를 최대로 사용하게끔 해주지만 인스턴스가 망가지면 함께 망가지는 임시 드라이브가 됩니다.

1. 루트 볼륨 유형과 데이터 저장을 위한 기타 EBS 볼륨 유형, 두 개의 EBS 볼륨으로 EC2 인스턴스를 실행했습니다. EC2 인스턴스는 한 달 후에 종료할 예정입니다. 각 EBS 볼륨에 기본적으로 나타날 행위 특성은 무엇일까요 ?

• A. 루트 볼륨 유형과 EBS 볼륨 유형이 모두 삭제됨
• B. 루트 볼륨 유형은 삭제되지만, EBS 볼륨 유형은 삭제되지 않음
• C. 루트 볼륨 유형은 삭제되지 않고, EBS 볼륨 유형은 삭제됨
• D. 루트 볼륨 유형과 EBS 볼륨 유형 모두 삭제되지 않음

✅ 루트 볼륨의 경우 '종료시 삭제' 속성이 기본으로 활성화되어 있기 때문에 기본적으로 삭제되게 됩니다. 기타 EBS 볼륨 유형의 경우 '종료시 삭제' 속성이 기본적으로 비활성화되어 있으므로 삭제되지 않습니다.

2. 노스버지니아 리전 us-east-1에서 AMI를 사용하면 어떤 AWS 리전에 있는 EC2 인스턴스라도 실행할 수 있습니다.

• A. 맞습니다.
• B. 아닙니다.

✅ AMI는 특정 AWS 리전에 국한되며, 각 AWS 리전에는 고유한 AMI가 있습니다. 다른 AWS 리전에서 AMI를 사용해 EC2 인스턴스를 실행하는 것은 불가능하지만 대상 AWS 리전으로 AMI를 복사해 EC2 인스턴스를 생성하는 것은 가능합니다.

3. 다음 중 EC2 인스턴스를 생성할 때 부팅 볼륨으로 사용할 수 있는 EBS 볼륨 유형은 무엇인가요 ?

• A. gp2, gp3, st1, sc1
• B. gp2, gp3, io1, io2
• C. io1, io2, st1, sc1

✅ EC2 인스턴스를 생성할 때, 부팅 볼륨으로는 다음의 EBS 볼륨 유형만을 사용할 수 있습니다. gp2, gp3, io1, io2 Magnetic(표준)

4. us-east-1a에서의 EC2 인스턴스를 종료하여, 이 인스턴스에 연결된 EBS 볼륨을 사용할 수 있게 되었습니다. 팀원이 us-east-1b의 EC2 인스턴스에 이 볼륨을 연결하려 했으나, 연결이 불가능한 상태입니다. 이 경우, 가능성이 있는 원인은 무엇일까요 ?

• A. IAM 권한이 없음
• B. EBS 볼륨은 AWS 리전으로 제한되어 있음
• C. EBS 볼륨은 가용 영역으로 제한되어 있음

✅ EBS 볼륨은 특정 AZ에 맞춰 생성됩니다. EBS 스냅샷을 활용하면 다른 AZ 간의 이전이 가능합니다.

5. EBS 다중 연결이란 무엇일까요 ?

• A. 동일한 EBS 볼륨을 다수의 AZ에 있는 다수의 EC2 인스턴스에 연결
• B. 다수의 EBS 볼륨을 동일한 AZ에 있는 동일한 EC2 인스턴스에 연결
• C. 동일한 EBS 볼륨을 동일한 AZ에 있는 다수의 EC2 인스턴스에 연결
• D. 다수의 EBS 볼륨을 다수의 AZ에 있는 동일한 EC2 인스턴스에 연결

✅ EBS 다중 연결을 사용하면 동일한 EBS 볼륨을 동일 AZ 상에 있는 다수의 EC2 인스턴스에 연결할 수 있습니다. 각 EC2 인스턴스는 완전한 읽기/쓰기 권한을 갖게 됩니다.

6. EC2 인스턴스에 연결되어 있는 암호화되지 않은 EBS 볼륨을 암호화하려 합니다. 어떻게 해야 할까요 ? - A. EBS 볼륨의 EBS 스냅샷을 생성하고 스냅샷을 복사한 뒤 복사된 스냅샷을 암호화하는 옵션을 체크합니다. 그 후, 암호화된 스냅샷을 사용해 새로운 EBS 볼륨을 생성합니다.

• B. EBS 볼륨을 선택하고, Edit 속성을 선택한 후, KMS 옵션을 사용해 암호화 옵션을 체크합니다.
• C. 암호화된 EBS 볼륨을 새로 생성한 후, 암호화되지 않은 EBS 볼륨의 데이터를 새로운 EBS 볼륨으로 복사합니다.
• D. AWS 지원센터에 EBS 볼륨 암호화를 요청합니다.

7. 대량의 데이터 세트를 처리하는, 다수의 AZ에 걸친 EC2 인스턴스 플릿이 있습니다. 동일한 데이터가 NFS 드라이브로서 모든 EC2 인스턴스에서 액세할 수 있게 만들기 위해서는 어떤 방법을 추천할 수 있을까요 ?

• A. EBS 사용
• B. EFS 사용
• C. 인스턴스 스토어 사용

8. EC2 인스턴스에 호스팅된 애플리케이션에 고성능 로컬 캐시를 포함시키려 합니다. EC2 인스턴스 종료 시, 캐시가 소실되어도 문제가 없는 상황입니다. 이런 경우, 솔루션 아키텍트로서 어떤 스토리지 매커니즘을 추천할 수 있을까요 ?

• A. EBS
• B. EFS
• C. 인스턴스 스토어

✅ EC2 인스턴스 스토어는 최적의 디스크 I/O 성능을 제공합니다.

9. 기반 스토리지에 310,000의 IOPS가 필요한 고성능 데이터베이스를 실행하고 있습니다. 어떤 방법을 추천할 수 있을까요 ?

• A. EBS gp2 드라이브 사용
• B. EBS io1 드라이브 사용
• C. EC2 인스턴스 스토어 사용
• D. EBS io2 Block Express 드라이브 사용

✅ EC2 인스턴스에서 데이터베이스를 인스턴스 스토어를 사용하여 실행 가능하지만, EC2 인스턴스가 중지 시 데이터가 손실된다는 문제가 있습니다. 한 가지 솔루션은 인스턴스 스토어가 있는 다른 EC2 인스턴스에서 복제 매커니즘을 설정하여 대기 복사본을 가질 수 있다는 것입니다. 또 다른 솔루션은 데이터에 대한 백업 매커니즘을 설정하는 것입니다. 요구 사항을 검증하기 위해 아키텍처를 설정하는 방법은 모두 사용자에게 달려 있습니다. 이 사용 사례에서는 IOPS 기준이므로 EC2 인스턴스 스토어를 선택해야 합니다.

Private IP vs Public IP vs Elastic IP

공용 웹 서버가 하나 있다고 가정해보겠습니다. 이 서버들은 공용 IP를 사용해서 서로 통신할 수 있습니다. 회사엔 사설 네트워크가 있고 사설 네트워크에는 기본적으로 사설 IP 범위가 있는데 사설 IP는 매우 구체적으로 정의되지만 기본적으로 사설 네트워크 내의 모든 컴퓨터가 사설 IP를 이용하여 서로 통신할 수 있음을 의미합니다.

반면 공용 게이트웨이인 인터넷 게이트웨이를 이용하게 되면 이 인스턴스들도 다른 서버들에 액세스 할 수 있게 됩니다. 만일 여러분이 사설 네트워크가 있는 다른 회살을 갖고 있다면 사설 네트워크 안에서 모든 컴퓨터들은 다른 컴퓨터들과 통신할 수 있고 IP가 있는 인터넷 게이트와도 연결되어 있어 인터넷을 통해 어디든 연결하며 다른 서버들과 통신할 수 있게 됩니다.

공용 IP가 있으면 인터넷 전역에 액세스할 수 있고 사설 IP로는 사설 네트워크 내에서만 액세스할 수 있다는 점입니다. 공용 IP는 곧 기기가 인터넷상에서 식별될 수 있음을 의미합니다. 그리고 각 공용 IP는 전체 웹에서 유일한 것이어야 하는데 즉 두 개 이상의 기기가 같은 공용 IP를 가질 수는 없다는 것입니다. 그리고 IP가 있으면 Google 검색으로 그 IP의 지리적 위치를 쉽게 찾을 수 있습니다. 반면 사설 IP는 기기가 오직 사설 네트워크 안에서만 식별될 수 있으며 따라서 IP가 사설 네트워크 안에서만 유일한 것이면 됩니다.

기기가 사설 네트워크에 있을 때 NAT 장치와 프록시 역할을 할 인터넷 게이트웨이를 통해 인터넷에 연결됩니다. 마지막으로 지정된 범위의 IP만 사설 IP로 사용될 수 있습니다.

마지막으로 탄력적 IP의 경우 EC2 인스턴스를 시작하고 중지할 때 공용 IP를 바꿀 수 있습니다. 어떤 이유에서든 인스턴스에 고정된 공용 IP를 사용하려면 탄력적 IP가 필요하게 됩니다. 탄력적 IP는 공용 IPv4인데 삭제하지 않는 한 계속 가지고 있게 됩니다. 당연하게도 한 번에 한 인스턴스에만 첨부할 수 있습니다. IP 주소가 탄력적이면 한 인스턴스에서 다른 인스턴스로 빠르게 이동함으로써 인스턴스 또는 소프트웨어의 오류를 마스킹할 때 사용할 수 있지만 이런 일은 사실 드뭅니다. 왜냐하면 계정당 탄력적 IP를 5개만 쓸 수 있기 때문입니다. 결론적으로 탄력적 IP는 사용하지 않는 것이 좋습니다.

대신 임의의 공용 IP를 써서 DNS 이름을 할당하는 것이 좋습니다. DNS는 Route 53에서 살펴볼 텐데 훨씬 더 많은 제어가 가능하고 확장 가능성도 더 큽니다. 또한 로드 밸런서를 사용해서 공용 IP를 전혀 사용하지 않을 수도 있습니다.

EC2 분산 배치 그룹 (Spread)

분산 배치 그룹은 인스턴스가 다른 하드웨어에 분산된다는 의미입니다. 여기에는 가용 영역별로 분산된 배치 그룹당 7개의 EC2 인스턴스만 가질 수 있다는 제한 사항이 있습니다. 따라서 크리티컬 애플리케이션이 있는 경우 분산 배치 그룹을 사용합니다.

EC2 분할 배치 그룹 (Partition)

분산 배치 그룹과 비슷하게 인스턴스를 분산하지만 분산 배치 그룹과는 다르게 여러 파티션에 인스턴스가 분할되어 있고 이 파티션은 가용 영역 내의 다양한 하드웨어 랙 세트에 의존합니다. 즉 인스턴스가 여전히 분산되어 있지만 다른 실패로부터 격리되지 않았다는 것입니다. 하지만 파티션은 다른 오류 파티션과 격리되어야 합니다. 즉 그룹당 수백 개의 EC2 인스턴스를 통해 확장할 수 있고 이를 통해 Hadoop, Cassandra, Kafka 같은 애플리케이션을 실행할 수 있다는 겁니다.

EC2 클러스터 배치 그룹

클러스터 배치 그룹의 경우 이는 모든 EC2 인스턴스가 동일한 랙에 있다는 겁니다. 즉 동일한 하드웨어와 동일한 가용 영역에 있다는 겁니다. 클러스터 배치 그룹을 만들려고 하고 지연 시간이 매우 짧은 10GB 속도 정도의 네트워크를 원하기 때문에 우린 이들을 동일한 랙에 배치합니다. 즉 우리는 빠른 속도의 네트워크를 갖게 됩니다. 그러나 이 네트워크가 가지는 단점은 랙에 실패가 발생하면 즉 하드웨어에 실패가 발생하면 모든 EC2 인스턴스가 동시에 실패한다는 겁니다. 그래서 전체 스택에 걸쳐 실패가 전파될 위험이 있습니다. 매우 높은 대역폭과 짧은 지연 시간이 필요한 경우 클러스터 배치 그룹이 이를 수행하는 좋은 방법입니다.

EC2의 절전모드

인스턴스를 시작할 경우 먼저 운영체제가 부팅되고 EC2 사용자 데이터에서 스크립트를 실행합니다. EC2 인스턴스에 내부 캐시가 있는 경우 캐시가 워밍업됩니다. 애플리케이션이 시작되는 속도가 느리거나 캐시가 워밍업되는 속도가 느린 경우 이 모든 작업에 시간이 걸릴 수 있습니다. 이 경우 EC2 절전모드라는 옵션을 사용할 수 있습니다. EC2 절전모드를 사용하면 모든 메모리 내 상태가 보존되므로 RAM의 모든 데이터가 보존됩니다. 즉 메모리가 보존된다는 겁니다. 절전 모드 후 인스턴스를 재시작하면 운영체제가 중지되거나 재시작되지 않았기 때문에 인스턴스 부팅이 훨씬 빨라집니다.

EC2 절전모드 작동방식

실행 중인 EC2 인스턴스가 있다고 가정할 때 RAM에 암호화된 Amazon EBS 루트 볼륨이 있으면 중지 후 절전모드로 전환하면 RAM이 암호화된 Amazon EBS 루트 볼륨에 덤프됩니다. 그러면 인스턴스가 중지되어 인스턴스가 종료되지만 OS는 종료되지 않습니다. 그런 다음 다시 시작하면 RAM이 EBS 볼륨에서 인스턴스의 RAM으로 이동하고 인스턴스가 실행됩니다.

EC2 절전모드 사용 사례

장기 실행 프로세스를 계속 실행하려는 경우나 RAM 상태를 저장하려는 경우나 초기화하는 데 시간이 많이 걸리는 서비스가 있는 경우 시작할 때 실제로 초기화하고 싶지 않다면 인스턴스를 절전모드로 전환하고 재시작하면 인스턴스 상태가 유지됩니다. 하지만 절전모드 옵션은 모든 인스턴스를 지원하지는 않습니다.

탄력적 네트워크 인터페이스 (ENI)

VPC의 논리적 구성 요소이며 가상 네트워크 카드를 나타냅니다. ENI는 EC2 인스턴스가 네트워크에 액세스할 수 있게 해줍니다. 또한 ENI는 EC2 인스턴스 외부에서도 사용됩니다. 예를 들어 가용 영역이 있고 하나의 EC2 인스턴스가 있다고 하면 기본 ENI인 Eth0에 연결되어 EC2 인스턴스 네트워크 연결을 제공합니다. 각 ENI는 다음과 같은 속성을 가질 수 있습니다. 첫 번째로 주요 사설 IPv4와 하나 이상의 보조 IPv4를 가질 수 있습니다. 따라서 이 예시에서는 Eth0 하나만 있지만 EC2에 보조 ENI를 얼마든지 추가해도 됩니다. 각 ENI는 사설 IPv4당 탄력적 IPv4를 갖거나 혹은 하나의 공용 IPv4를 가질 수 있으므로 사설 및 공용 IP가 한 개씩 제공됩니다. 참고로 ENI는 특정 가용 영역 즉 AZ에 바인딩됩니다. 즉 특정 AZ에서 ENI를 생성하면 해당 AZ에만 바인딩할 수 있습니다. 만약 이 인스턴스에 다른 문제가 생겼는데 또 다른 ENI가 연결되어 있다고 가정하면 첫 번째 EC2 인스턴스에서 두 번째 EC2 인스턴스로 Eth1을 옮겨서 사설 IP를 이동시킬 수 있습니다. 그러면 사설 IP가 첫 번째 문제 인스턴스에서 두 번째 EC2 인스턴스로 연결되게 됩니다.

탄력적 네트워크 인터페이스는 VPC에서 가상 네트워크 카드를 나타내는 논리적 네트워킹 구성 요소입니다. 여기에는 다음 속성이 포함될 수 있습니다.

• VPC의 IPv4 주소 범위 중 기본 프라이빗 IPv4 주소
• VPC의 IPv4 주소 범위 중 하나 이상의 보조 프라이빗 IPv4 주소
• 프라이빗 IPv4 주소당 한 개의 탄력적 IP 주소(IPv4)
• 한 개의 퍼블릭 IPv4 주소
• 한 개 이상의 IPv6 주소
• 하나 이상의 보안 그룹
• MAC 주소
• 원본/대상 확인 플래그
• 설명
  네트워크 인터페이스를 생성 및 구성하고 동일한 가용 영역의 인스턴스에 연결할 수 있습니다. 계정에는 사용자가 다른 리소스 및 서비스를 사용할 수 있도록 AWS 서비스가 생성하고 관리하는 요청자 관리 네트워크 인터페이스가 있을 수도 있습니다. 이러한 네트워크 인터페이스는 사용자가 직접 관리할 수 없습니다. 또한 이 AWS 리소스를 AWS Management Console 및 Amazon EC2 API에서는 네트워크 인터페이스라고 합니다

  요청자 관리 네트워크 인터페이스

  요청자 관리형 네트워크 인터페이스는 AWS 서비스가 사용자를 대신하여 VPC에서 생성하는 네트워크 인터페이스입니다. 네트워크 인터페이스는 Amazon RDS의 DB 인스턴스, NAT 게이트웨이, AWS PrivateLink의 인터페이스 VPC 엔드포인트 등의 다른 서비스에 대한 리소스와 연결됩니다.

  네트워크 인터페이스 기본 사항

  네트워크 인터페이스를 만들고, 인스턴스에 연결하고, 인스턴스에서 분리한 후 다른 인스턴스에 연결할 수 있습니다. 인스턴스에 연결하거나 분리한 후 다른 인스턴스에 다시 연결하면 네트워크 인터페이스의 속성이 해당 네트워크 인터페이스를 따릅니다. 네트워크 인터페이스를 인스턴스 간에 이동하면 네트워크 트래픽이 새 인스턴스로 리디렉션됩니다.

  기본 네트워크 인터페이스

  각 인스턴스는 기본 네트워크 인터페이스라는 기본 네트워크 인터페이스를 갖습니다. 주 네트워크 인터페이스는 인스턴스에서 분리할 수 없습니다. 추가 네트워크 인터페이스를 만들고 연결할 수 있습니다. 사용 가능한 최대 네트워크 인터페이스 수는 인스턴스 유형에 따라 다릅니다.

  네트워크 인터페이스용 퍼블릭 IPv4 주소

  VPC에서 모든 서브넷은 해당 서브넷에서 생성된(따라서 인스턴스가 그 서브넷으로 시작된) 네트워크 인터페이스가 퍼블릭 IPv4 주소에 할당될 것인지 결정하는 수정 가능한 속성을 갖습니다. 퍼블릭 IPv4 주소는 Amazon의 퍼블릭 IPv4 주소 풀에서 할당됩니다. 인스턴스를 시작하면 생성된 기본 네트워크 인터페이스에 IP 주소가 할당됩니다.
  네트워크 인터페이스를 생성할 때 네트워크 인터페이스는 서브넷에서 퍼블릭 IPv4 주소 지정 속성을 상속합니다. 이후에 서브넷의 퍼블릭 IPv4 주소 지정 속성을 수정하면 네트워크 인터페이스는 처음 생성될 때 적용된 설정을 그대로 유지합니다. 인스턴스를 시작하고 기존 네트워크 인터페이스를 기본 네트워크 인터페이스로 지정하는 경우 퍼블릭 IPv4 주소 속성은 이 네트워크 인터페이스에 의해 결정됩니다.

  퍼블릭 IPv4 주소

  퍼블릭 IP 주소는 인터넷을 통해 연결할 수 있는 IPv4 주소입니다. 퍼블릭 주소는 인스턴스와 인터넷의 상호 통신을 위해 사용될 수 있습니다.

  기본 VPC에서 인스턴스를 시작할 때 기본적으로 퍼블릭 IP 주소가 할당됩니다. 기본 VPC가 아닌 VPC로 인스턴스를 시작하는 경우 서브넷은 이 서브넷으로 시작되는 인스턴스가 퍼블릭 IPv4 주소 풀로부터 퍼블릭 IP 주소를 부여받는지 여부를 결정하는 속성을 갖습니다. 기본적으로 기본 서브넷이 아닌 서브넷에서 시작된 인스턴스에 퍼블릭 IP 주소가 할당되지 않습니다.

  퍼블릭 IP 주소는 Amazon의 퍼블릭 IPv4 주소 풀에서 사용자 인스턴스로 지정되고 AWS 계정과는 관련이 없습니다. 인스턴스와 퍼블릭 IP 주소의 연결이 해제되면 해당 퍼블릭 IP 주소는 퍼블릭 IPv4 주소 풀로 해제되지만 사용자가 해당 주소를 다시 사용할 수 없습니다.

  인스턴스에서 퍼블릭 IP 주소(IPv4)를 수동으로 연결하거나 연결 해제할 수 없습니다. 어떤 경우에는 Amazon에서 귀하의 인스턴스로부터 퍼블릭 IP 주소를 해제하거나 새 인스턴스에 할당합니다.

• 인스턴스가 중지되거나 최대 절전 모드로 전환되거나 종료되면 인스턴스의 퍼블릭 IP 주소는 릴리스됩니다. 중지되거나 최대 절전 모드로 전환된 인스턴스가 시작되면 새 퍼블릭 IP 주소가 할당됩니다.

• 탄력적 IP 주소를 인스턴스와 연결하는 경우 인스턴스의 퍼블릭 IP 주소가 릴리스됩니다. 사용자가 인스턴스에서 탄력적 IP 주소의 연결을 해제하면 새 퍼블릭 IP 주소가 할당됩니다.

• VPC 인스턴스의 퍼블릭 IP 주소가 해제되고 인스턴스에 1개 이상의 네트워크 인터페이스가 연결된 경우 새 퍼블릭 IP 주소가 할당되지 않습니다.

• 인스턴스의 퍼블릭 IP 주소가 릴리스된 가운데 탄력적 IP 주소와 연결된 보조 프라이빗 IP 주소를 보유한 경우 인스턴스는 새 퍼블릭 IP 주소를 수신하지 않습니다.
  필요에 따라 인스턴스 간에 연결할 수 있는 영구 퍼블릭 IP 주소가 필요한 경우 탄력적 IP 주소를 대신하여 사용합니다.
  동적 DNS를 사용하여 새 인스턴스의 퍼블릭 IP 주소에 기존 DNS 이름을 연결하는 경우 IP 주소가 인터넷을 통해 전해지는 데 24시간까지 걸릴 수 있습니다. 따라서 종료된 요청을 계속 받는 동안 새 인스턴스가 트래픽을 받지 못할 수 있습니다.

1. NodeJS 애플리케이션을 호스트하게 될 EC2 인스턴스를 실행합니다. 모든 필수 소프트웨어를 설치하고 애플리케이션을 구성한 후, 액세스를 위해 EC2 인스턴스 공용 IPv4를 기록해 두었습니다. 그 다음, 실행을 중단하고 애플리케이션 구성을 완료하기 위해 EC2 인스턴스를 다시 시작했습니다. 그러나 재시작 후, EC2 인스턴스에 액세스할 수 없었으며 EC2 인스턴스 공용 IPv4가 변경된 것을 알게 되었습니다. 이 경우, EC2 인스턴스에 고정적인 공용 IPv4를 할당하려면 어떻게 해야 할까요 ?

• A. EC2 인스턴스에 탄력적 IP 할당
• B. EC2 인스턴스 OS에서 네트워크 구성을 DHCP에서 정적으로 변경한 뒤 공용 IPv4에 할당
• C. AWS 지원 센터에 연락해 EC2 인스턴스를 위한 정적 공용 IPv4 요청
• D. 불가능, EC2 인스턴스에는 고정 사설 IPv4만 할당 가능

✅ 탄력적 IP는 여러분이 원하는 기간만큼 소유할 수 있는 공용 IPv4로 한 번에 하나의 인스턴스에만 연결할 수 있습니다.

2. 한 세트의 EC2 인스턴스가 필요한 배치 작업을 수행하려 합니다. 배치 작업은 4시간 동안 수행되며 중단되어서는 안 됩니다. 이러한 배치 작업을 가장 저렴한 비용으로 수행하기 위해서는 다음 중 어떤 EC2 구매 옵션을 선택해야 할까요 ?

• A. 온디맨드 인스턴스
• B. 예약 인스턴스
• C. 스팟 인스턴스
• D. 스팟 블록 인스턴스

✅ 스팟 블록 인스턴스를 사용하면 한 세트의 EC2 인스턴스를 지정된 기간(1~6시간)동안 중단 없이 예약할 수 있습니다.

3. 스팟 플릿은 한 세트의 스팟 인스턴스로 선택적 ()입니다.

• A. 예약 인스턴스
• B. 온디맨드 인스턴스
• C. 전용 호스트
• D. 전용 인스턴스

✅ 스팟 플릿은 한 세트의 스팟 인스턴스로 선택적 온디맨드 인스턴스입니다. 이를 사용하면 가장 낮은 가격의 스팟 인스턴스를 자동으로 요청할 수 있습니다.

4. EC2 인스턴스 플릿에서 대규모의 데이터 분석을 수행하는 애플리케이션이 있습니다. 여러분은 EC2 인스턴스들이 서로 소통하면서도 가장 높은 수준의 네트워킹 성능을 유지했으면 합니다. 이런 경우, 다음 중 어떤 EC2 배치 그룹을 선택해야 할까요 ?

• A. 분산 배치 그룹
• B. 클러스터 배치 그룹
• C. 분할 배치 그룹

✅ 클러스터 배치 그룹을 사용하면 EC2 인스턴스들이 나란히 위치하게 되어 고성능의 컴퓨팅 및 네트워킹 성능을 제공하게 됩니다.

5. EC2 인스턴스 플릿에 호스팅된 중요 애플리케이션이 있습니다. 이 애플리케이션에서 AZ 실패가 일어난 경우, 최대 가용성을 달성했으면 합니다. 이런 경우, 다음 중 어떤 EC2 배치 그룹을 선택해야 할까요 ?

• A. 클러스터 배치 그룹
• B. 분할 배치 그룹
• C. 분산 배치 그룹

✅ EC2 분산 배치 그룹은 EC2 인스턴스들이 서로 다른 AZ에 위치하게 됩니다.

6. 탄력적 네트워크 인터페이스(ENI)는 다른 AZ에 있는 EC2 인스턴스와 연결될 수 있습니다.

• A. 맞습니다.
• B. 아닙니다.

✅ 탄력적 네트워크 인터페이스(ENI)는 특정 AZ로 국한됩니다. 다른 AZ에 있는 EC2 인스턴스에 ENI를 연결할 수는 없습니다.

7. EC2 절전 모드와 관련된 내용 중, 옳지 않은 설명을 고르세요.

• A. EC2 인스턴스 루트 볼륨은 반드시 인스턴스 스토어 볼륨이어야 함
• B. 온디맨드 및 예약 인스턴스를 지원함
• C. EC2 인스턴스 RAM은 150GB 미만이어야 함
• D. EC2 인스턴스 루트 볼륨 유형은 EBS 볼륨이어야 함

✅ EC2 절전 모드를 활성화하기 위해서는 EC2 인스턴스 루트 볼륨 유형이 EBS 볼륨이어야만 하며, 민감한 내용을 보호할 수 있도록 암호화되어야 합니다.

범용

먼저 범용의 인스턴스는 웹 서버나 코드 저장소와 같은 다양한 작업에 적합합니다. 컴퓨팅, 메모리, 네트워킹 간의 균형도 잘 맞습니다.

컴퓨팅 최적화

컴퓨팅 최적화 인스턴스는 컴퓨터 집약적인 작업에 최적화된 인스턴스입니다. 일부 데이터의 일괄 처리에 사용하거나 미디어 트랜스 코딩 작업 시 혹은 고성능 웹 서버가 필요하거나 고성능 컴퓨팅이라는 HPC 작업을 할 때 또는 머신 러닝이나 전용 게임 서버가 있을 때 사용합니다. 컴퓨터 최적화의 모든 인스턴스는 C로 시작하는 이름을 가지고 있습니다.

메모리 최적화

메모리 최적화의 인스턴스를 살펴보겠습니다. 이 유형의 인스턴스는 메모리에서 대규모 데이터셋을 처리하는 유형의 작업에 빠른 성능을 제공합니다. 메모리는 RAM을 뜻하고 사용 사례를 살펴보면 대부분 인 메모리 데이터베이스가 되는 고성능의 관계형 또는 비관계형의 데이터베이스에 사용하고 일래스틱 캐시를 예로 들 수 있는 분산 웹스케일 캐시 저장소에도 사용합니다. 또 비즈니스 인텔리전스 즉, BI에 최적화된 인 메모리 데이터베이스와 대규모 비정형 데이터의 실시간 처리를 실행하는 애플리케이션에도 사용합니다. 메모리 최적화 인스턴스의 이름을 살펴보면 RAM을 나타내는 R로 시작합니다. 하지만 X1이나 대용량 메모리 Z1도 있습니다.

스토리지 최적화

스토리지 최적화 인스턴스는 로컬 스토리지에서 대규모의 데이터셋에 액세스할 때 적합한 인스턴스입니다. 스토리지 최적화 인스턴스의 사용 사례로는 고주파 온라인 트랜잭션 처리인 OLTP 시스템에 사용되며 관계형과 비관계형인 NoSQL 데이터베이스에 사용합니다. 예를 들어 레디스(Redis)같은 메모리 데이터베이스의 캐시나 데이터 웨어하우징 애플리케이션과 분산 파일 시스템에 사용됩니다. AWS의 스토리지 최적화 인스턴스는 이름이 I, G 또는 H1으로 시작합니다.

AWS 스팟 인스턴스

스팟 인스턴스를 사용하면 온디맨드와 비교해 최대 90%까지 할인을 받을 수 있습니다. 비용이 크게 절감됩니다. 어떤 스팟 인스턴스에 대해 지불할 의향이 있는 스팟 최고가를 정의한 후에 인스턴스의 비용이 지불 의향 있는 최고가보다 낮은 한 해당 인스턴스를 계속해서 사용하게 되는 겁니다. 시간당 스팟 비용은 오퍼 및 용량에 따라 다양하고 올라갈 수도 있고 내려갈 수도 있습니다. 그리고 만약 현재 스팟 가격이 정의된 최고 가격보다 높아지는 경우에는 두 가지의 옵션이 있습니다. 그리고 이러한 옵션들에는 2분의 유예 시간이 있습니다. 이런 유예 시간을 통해 약간의 시간을 벌 수 있습니다.

AWS 스팟 인스턴스 옵션1

옵션들 중 하나는 인스턴스를 중단하는 것으로 하고 있던 모든 작업을 멈추고 인스턴스를 중단한 뒤 언젠가 스팟 가격이 여러분이 정한 최고가보다 낮아지는 때에 인스턴스를 재시작해 중단했던 부분부터 계속 이어서 작업을 하는 것입니다.

AWS 스팟 인스턴스 옵션2

혹은 그 EC2 인스턴스를 중단 상태로 둘 필요가 없는 경우에는 인스턴스를 완전히 종료해 끝낼 수도 있습니다. 이 말인즉슨 업무를 재시작할 때마다 완전히 새로운 EC2 인스턴스로 시작을 할 수 있게 된다는 의미입니다.

AWS 스팟 블록

AWS 스팟 블록은 AWS에게 스팟 인스턴스를 회수당할 일이 없게 하기 위한 전략입니다. 스팟 블록이란 특정 기간 동안 인스턴스를 차단하는 기능입니다. 기간은 1시간에서 6시간 사이가 될 수 있습니다. 그리고 아무 방해 없이 차단이 가능합니다. (🔥2021년 7월 1일부터 신규 사용자는 스팟 블록을 사용할 수 없으며 2022년 12월 31일자로 서비스가 종료됩니다. )

스팟 요청

스팟 요청에는 원하는 인스턴스의 개수, 지불 의사가 있는 인스턴스 최고 가격, AMI등 요구되는 사양 그리고 요청의 유효 기간이 있습니다. 유효 기간은 무기한으로 할 수도 있습니다. 그리고 요청의 유형이 포함됩니다. 요청에는 두 가지 유형이 있습니다. 스팟 인스턴스를 위한 일회성 요청이 있고 사후 인스턴스를 위한 지속적인 요청이 있습니다.

일회성 요청

일회성 요청의 경우에는 스팟 요청이 이행되는 즉시 인스턴스가 시작되게 됩니다. 그리고 이는 일회성 요청이었으니 스팟 요청은 사라지게 됩니다. 즉 스팟 요청이 사라져도 괜찮은 경우에 사용하는 유형이 되겠습니다.

지속적인 요청

지속적인 요청의 경우에는 스팟 요청의 Valid from부터 Valid until까지의 유효 기간 동안 여러분이 요청한 개수의 인스턴스들이 계속 유효하게 되는 겁니다. 즉 어떤 이유로 인스턴스가 중단되거나 스팟 가격 상승을 이유로 방해를 받은 경우에는 스팟 요청이 다시 전달되어 요청이 검증되고 나면 스팟 인스턴스가 재시작됩니다. 따라서 지속적 요청 모드에는 스팟 인스턴스가 중단되어도 스팟 요청이 여전히 활성화되어 있기 때문에 스팟 요청이 자동적으로 인스턴스를 재시작해 주는 겁니다.

스팟 요청 취소

스팟 요청이 취소되기 위해서는 open 상태, active 상태 혹은 disabled 상태여야 합니다. 즉, failed나 cancelled 혹은 closed가 아니어야 한다는 겁니다. 스팟 요청을 취소하려는 경우 기존에 실행했던 인스턴스는 종료가 되지 않습니다. 즉 기존에 실행했던 인스턴스를 종료하는 것은 AWS의 책무가 아니라 사용자의 책무인 것입니다. 그러므로 스팟 인스턴스를 영구히 종료하고 재실행되는 일이 없도록 하기 위해서는 먼저 스팟 요청부터 취소한 뒤 해당 요청과 연결된 스팟 인스턴스를 종료해야 합니다. 왜냐하면 스팟 인스턴스를 먼저 종료하게 되면 스팟 요청이 다시 작동을 해서 다시 스팟 인스턴스를 생성하게 됩니다. 따라서 스팟 인스턴스를 종료하기 위한 올바른 순서는 제일 먼저 스팟 요청을 취소해 AWS가 더 이상 새로운 인스턴스를 실행하지 않게끔 한 뒤에 연결된 스팟 인스턴스를 종료하는 겁니다.

스팟 인스턴스 영구 종료

스팟 요청 취소 ➡️ 해당 스팟 요청과 연결된 스팟 인스턴스 종료

스팟 플릿

스팟 플릿은 극강의 비용 절감을 위한 방법입니다. 스팟 플릿이란 한 세트의 스팟 인스턴스에다가 선택적으로 온디맨드 인스턴스를 조합해 사용하는 방식입니다. 그래서 집합이라는 뜻의 플릿(Fleet)이라는 이름이 붙은 겁니다. 그리고 스팟 플릿은 정의된 비용 제한 내에서 대상 용량을 맞추려 노력할 것입니다. 또한 사용 가능한 런치풀(Launch Pool)을 통해서 실행이 됩니다. 또한 다양한 인스턴스 유형, 다양한 OS 그리고 다양한 가용 영역을 가질 수 있습니다. 여러 개의 런치 풀과 여러 개의 인스턴스 크기 등 여러 가지의 모든 것들을 정의하게 됩니다. 그러고 나면 플릿이 가장 적합하고 좋은 런치풀을 선택해주는 것입니다. 그리고 스팟 플릿이 정해진 예산 혹은 원하는 용량에 달한 경우에는 인스턴스 실행을 멈출 겁니다. 그리고 스팟 플릿 내에 스팟 인스턴스를 할당해 줄 전략을 정의하게 됩니다.

스팟 플릿 비용 전략

lowestPrice

첫 번째 전략은 lowestPrice입니다. 시험에 가장 자주 출제되는 전략입니다. 이 전략을 사용하면 스팟 플릿이 가장 적은 비용을 가진 풀에서부터 인스턴스를 실행해 줍니다. 이런 식으로 비용 최적화가 가능하며 아주 짧은 워크로드가 있을 때 적합한 옵션입니다.

diversified

그리고 스팟 인스턴스를 실행하기 위해 diversified 옵션을 사용할 수도 있습니다. 이 경우 스팟 인스턴스는 여러분이 기존에 정의한 모든 풀에 걸쳐 분산이 됩니다. 긴 워크로드에 적합하고 가용성이 뛰어난 옵션입니다. 왜냐하면 한 풀이 중단되더라도 다른 풀이 활성화되기 때문입니다.

capacityOptimized

그리고 마지막 옵션은 capacityOptimized입니다. 인스턴스의 개수에 따라서 최적 용량으로 실행이 되고 적절한 풀을 찾아 주는 옵션입니다.

EC2 Dedicated Instance vs Dedicated Host

Dedicated Instance (호텔)

"전용 인스턴스는 단일 고객 전용 하드웨어의 VPC에서 실행되는 Amazon EC2 인스턴스입니다. 전용 인스턴스는 호스트 하드웨어 수준에서 다른 AWS 계정에 속하는 인스턴스로부터 물리적으로 격리됩니다."

• 물리적으로 인스턴스 단위로 격리된 서버에서 EC2를 실행
• 한 계정에서 전용 호스트를 잠시 빌려서 사용

  • 호텔처럼 쓰는 동안에만 내 꺼 -> 체크아웃 하면 다른 방에서 묵어야 할 수도 있음
  • 인스턴스 재부팅 시 다른 전용 호스트에서 인스턴스가 동작할 가능성 존재
  • 내 계정의 전용 인스턴스가 아닌 인스턴스도 섞여 들어갈 수 있음
  • 인스턴스 배치 컨트롤 불가능

• 인스턴스 단위 빌링

  • 전용 요금의 숫자와 관계 없이 단 하나라도 사용시 부과: 시간당 $2
  • 시간당 인스턴스 사용료: 약 10% 더 비싼 요금

• 내 라이선스를 직접 활용 불가능 (Bring Your Own License 불가능)

Dedicated Host (전세)

"Amazon EC2 전용 호스트를 사용하면 Amazon EC2에서 Microsoft 및 Oracle 같은 공급업체의 적격 소프트웨어 라이선스를 사용할 수 있으므로 고객이 자사의 보유 라이선스를 활용하는 유연성과 비용 효율성을 보장받으면서 AWS의 복원력, 간편성 및 탄력성을 활용할 수 있습니다. Amazon EC2 전용 호스트는 고객에게 전용으로 제공되는 물리적 서버로 회사 규정 준수 요건을 해결하는 데 유용합니다."

• 물리적으로 호스트 단위로 격리된 서버에서 EC2를 실행
• 전용 호스트(서버)를 전세 내서 빌려 쓰는 개념

  • 전세집
  • 인스턴스 재부팅 시 확보한 호스트에서 다시 동작
  • 인스턴스 배치 컨트롤 가능

• 호스트 단위 빌링

  • 패밀리 선택 후, 호스트당으로 요금 지불
  • 하나의 호스트안에 인스턴스 숫자와 관계 없이 요금 지불

• 내 라이선스를 직접 활용 가능 (Bring Your Own License 가능)

  • AWS License Manager

1. 다음 중 할인 폭이 가장 크나 데이터베이스 혹은 중요 업무에는 적합하지 않은 EC2 구매 옵션은 무엇인가요 ?

• A. 전환 가능 예약 인스턴스
• B. 전용 호스트
• C. 스팟 인스턴스

✅ 스팟 인스턴스는 단기적인 워크로드에 적합하여 가장 저렴한 EC2 구매 옵션입니다. 하지만 EC2 인스턴스를 손실할 우려가 있기 때문에 신뢰도가 떨어집니다.

2. EC2 인스턴스 내/외의 트래픽을 제어하기 위해서는 무엇을 사용해야 하나요 ?

• A. 네트워크 액세스 제어 리스트(NACL)
• B. 보안 그룹
• C. IAM 정책

✅ 보안 그룹은 EC2 인스턴스 레벨에서 운용되며, 트래픽을 제어할 수 있습니다.

3. EC2 예약 인스턴스를 예약할 수 있는 기간은 얼마인가요 ?

• A. 1년 혹은 3년
• B. 2년 혹은 4년
• C. 6개월 혹은 1년
• D. 1년에서 3년 사이의 기간

✅ EC2 예약 인스턴스는 1년 혹은 3년의 기간으로만 예약이 가능합니다.

4. EC2 인스턴스에 고성능 컴퓨팅(HPC) 애플리케이션을 배포하려 합니다. 다음 중 어떤 EC2 인스턴스 유형을 선택해야 할까요 ?

• A. 스토리지 최적화
• B. 컴퓨팅 최적화
• C. 메모리 최적화
• D. 범용

✅ 메모리 최적화 EC2 인스턴스는 메모리에 대규모 데이터 세트가 필요한 워크로드에 적합하며 컴퓨팅 최적화 EC2 인스턴스는 고성능 프로세서(예: 배치 처리, 미디어 트랜스코딩, 고성능 컴퓨팅, 과학적 모델링 및 머신 러닝, 전용 게이밍 서버 등)가 필요한 집중 컴퓨팅 워크로드에 적합합니다.

5. 1년 간 지속적으로 서버를 운영할 계획인 애플리케이션의 경우에는 다음 중 어떤 EC2 구매 옵션을 사용해야 할까요 ?

• A. 예약 인스턴스
• B. 스팟 인스턴스
• C. 온디맨드 인스턴스

✅ 예약 인스턴스는 장기적인 워크로드에 적합합니다. EC2 인스턴스는 1년 혹은 3년의 기간으로 예약할 수 있습니다.

6. 일련의 EC2 인스턴스에 호스팅 될 애플리케이션을 실행하려 합니다. 이 애플리케이션에는 소프트웨어 설치가 필요하며, 최초 실행 중에 일부 OS 패키지를 업데이트해야 합니다. EC2 인스턴스를 실행하려는 경우, 이를 위한 최적의 방식은 무엇일까요 ?

• A. SSH를 통해 각 EC2 인스턴스에 연결한 후, 필수 소프트웨어를 설치하고 OS 패키지를 수동으로 업데이트하기
• B. 필수 소프트웨어의 설치 및 OS 업데이트를 수행하는 bash 스크립트를 작성한 후, AWS 지원 센터에 연락해 스크립트 제공하고 이 스크립트를 EC2 인스터스 실행시 인스턴스에서 실행
• C. 필수 소프트웨어의 설치 및 OS 업데이트를 수행하는 bash 스크립트를 작성한 후, 이 스크립트를 EC2 인스턴스 실행 시에 EC2 사용자 데이터에서 사용하기

7. 인메모리 데이터베이스를 사용하는 중요 애플리케이션을 위해서는 다음 중 어떤 EC2 인스턴스 유형을 선택해야 할까요 ?

• A. 컴퓨팅 최적화
• B. 스토리지 최적화
• C. 메모리 최적화
• D. 범용

✅ 메모리 최적화 EC2 인스턴스는 메모리에 대규모 데이터 세트가 필요한 워크로드에 적합합니다.

8. 온프레미스에 호스팅된 OLTP 데이터베이스를 갖춘 전자 상거래 애플리케이션이 있습니다. 이 애플리케이션은 인기가 좋아 데이터베이스가 초당 수천개의 요청을 지니게 됩니다. 여러분은 데이터베이스를 EC2 인스턴스로 이전하려 합니다. 이렇게 높은 빈도를 보이는 OLTP 데이터베이스를 처리하기 위해서는 어떤 EC2 인스턴스 유형을 선택해야 할까요 ?

• A. 컴퓨팅 최적화
• B. 스토리지 최적화
• C. 메모리 최적화
• D. 범용

✅ 스토리지 최적화 EC2 인스턴스는 로컬 스토리지의 대규모 데이터 세트에 대해 높은 수준의 그리고 순차적인 읽기/쓰기 액세스 권한이 필요한 워크로드에 적합합니다.

9. 보안 그룹은 오직 하나의 EC2 인스턴스에만 연결될 수 있습니다.

• A. 아닙니다.
• B. 맞습니다.

✅ 보안 그룹은 동일한 리전/VPC 내에 있는 다수의 EC2 인스턴스에 연결될 수 있습니다.

10. 온프레미스 애플리케이션을 AWS로 이전하려 합니다. 여러분의 기업에는 애플리케이션을 전용 서버에서 실행해야 한다는 엄격한 규정이 있습니다. 또한 비용 절감을 위해 전용 서버 바운드 소프트웨어 라이선스를 사용해야 합니다. 이 경우, 다음 중 어떤 EC2 구매 옵션이 적합할까요 ?

• A. 전환 가능 예약 인스턴스
• B. 컨버터블 예약 인스턴스
• C. 전용 호스트
• D. 스팟 인스턴스

✅ 전용 호스트는 높은 수준의 규정 준수가 필요한 기업 혹은 복잡한 라이선스 모델을 가진 소프트웨어에 적합합니다. 이는 가장 비싼 EC2 구매 옵션입니다.

11. 데이터베이스 기술을 EC2 인스턴스에 배포하려 합니다. 공급 업체 라이선스는 물리적 코어 및 기반 네트워크 소켓 가시성을 기반으로 비용을 책정합니다. 이 경우, 어떤 EC2 구매 옵션을 사용해야 가시성을 확보할 수 있을까요 ?

• A. 스팟 인스턴스
• B. 온디맨드 인스턴스
• C. 전용 호스트
• D. 예약 인스턴스

IAM

회사 내 실제 사용자와 IAM 사용자가 매핑됩니다. 사용자는 AWS 콘솔에 대한 비밀번호를 가질 것이고 모범 사례는 사용자를 그룹에 두는 것입니다. 그룹은 사용자만을 포함할 수 있습니다. 다른 그룹은 포함할 수 없습니다. 그리고 사용자나 그룹에 권한을 부여합니다. IAM 정책을 만드는 것에 있어서는 JSON 문서가 있습니다. 이 문서는 사용자나 그룹이 할 수 있는 권한을 알려주는 문서입니다. 또한 AWS에서 역할을 사용할 수 있습니다. AWS 서비스가 다른 AWS 서비스에 무언가를 하게 하는 어떤 권한을 주려고 할 때 IAM 역할을 만들어야 합니다. 보안 관련해서 사용자를 안전하게 하기 위해서는 MFA 인증을 활성화하여 로그인할 때 두 번째 장치를 이용하도록 하게 하고 강한 비밀번호 정책을 가져야 합니다.

• 코딩을 하기 위해 CLI 또는 명령줄 인터페이스를 이용하거나 SDK를 이용하여 AWS에 액세스한다면 반드시 액세스 키를 만들어야 합니다. 이를 통해 AWS를 프로그래밍 방식으로 접근할 수 있습니다.

• IAM 대시보드를 감사하고 싶다면 자격 증명 보고서를 만들어 사용자 관련 정보를 볼 수 있습니다.

• IAM의 특정 사용자를 감사하고 싶다면 IAM 액세스 관리자를 사용하여 사용자의 최근 권한의 사용 내역을 확인할 수 있습니다.

1. 다음 중 IAM 역할의 올바른 정의는 무엇일까요 ?

• A. 다중 사용자 그룹에 속한 IAM 사용자
• B. IAM 사용자들을 위한 비밀번호 정책을 정의하는 IAM 개체
• C. AWS 서비스에 요청을 생성하기 위한 일련의 권한을 정의하고, AWS 서비스에 의해 사용될 IAM 개체
• D. 특정 행동 수행을 위해 IAM 사용자에게 할당된 권한

✅ 일부 AWS 서비스는 여러분을 위해 특정 행동을 수행해야 합니다. IAM 역할은 이러한 권한을 할당하기 위해 사용됩니다.

2. 다음 중 IAM 보안 도구에 해당되는 것은 무엇인가요 ?

• A. IAM 자격 증명 보고서
• B. IAM 루트 계정 관리자
• C. IAM 서비스 보고서
• D. IAM 보안 관리자

✅ IAM 자격 증명 보고서에는 AWS 계정의 모든 IAM 사용자와 이들의 다양한 자격 증명 상태가 포함되어 있습니다.

3. IAM 사용자에 대해 잘못 서술된 내용을 고르세요.

• A. IAM 사용자들은 다중 사용자 그룹에 속할 수 있습니다.
• B. IAM 사용자들이 사용자 그룹에 속할 필요는 없습니다.
• C. IAM 정책은 IAM 사용자에게 직접 연결될 수 있습니다.
• D. IAM 사용자들은 루트 계정 자격 증명을 통해 AWS 서비스에 액세스합니다.

4. 다음 중 IAM 모범 사례에 해당하는 것은 무엇인가요 ?

• A. 한 사람에게 다수의 IAM 사용자 생성하기
• B. 루트 계정 사용하지 않기
• C. 동료들이 업무를 대신 수행할 수 있도록 AWS 계정 자격 증명을 공유하기
• D. 보다 쉬운 액세스를 위해 MFA를 활성화하지 않기

✅ 루트 계정은 최초 IAM 사용자 생성과 일부 계정 서비스 관리 업무에만 사용됩니다. 일상적인 업무에는 IAM 사용자를 사용해야 합니다.

5. IAM 정책은 무엇인가요 ?

• A. AWS 계정들이 상호작용하는 방법을 정의하는 일련의 정책
• B. AWS 서비스에 요청을 생서아힉 의한 일련의 권한을 정의하며 IAM 사용자, 사용자 그룹 및 IAM 역할에서 사용하게 될 JSON 문서
• C. IAM 사용자들의 비밀번호를 정의하는 일련의 정책
• D. 고객들이 AWS와 상호작용하는 방법을 보여주는 AWS에서 정의한 일련의 정책

6. IAM 권한에는 다음 중 어떤 원칙이 적용되어야 할까요 ?

• A. 최대 권한 부여하기
• B. 직원의 요청이 있을 경우, 더 많은 권한 부여하기
• C. 최소 권한 부여하기
• D. 루트 계정 권한 제한하기

7. 루트 계정 보안을 향상시키기 위해서는 어떤 작업을 수행해야 할까요 ?

• A. 루트 계정에서 권한 제거하기
• B. AWS 명령줄 인터페이스(CLI)를 통해서만 AWS 서비스에 액세스하기
• C. IAM 사용자를 생성하지 않고, 루트 계정으로만 AWS 계정에 액세스하기
• D. 다중 인증(MFA) 활성화하기

✅ MFA를 활성화할 경우, 보안에 하나의 층을 더 추가하게 됩니다. 비밀번호가 유출되었거나 도용을 당한 경우에도, 여러분의 계정은 안전합니다.

8. IAM 사용자 그룹은 IAM 사용자 및 기타 사용자 그룹을 포함할 수 있습니다.

• A. 맞습니다.
• B. 아닙니다.

✅ IAM 사용자 그룹은 다른 사용자 그룹에 속할 수 없습니다.

9. IAM 정책은 하나 이상의 문장으로 구성됩니다. IAM 정책 내 문장의 구성 요소가 아닌 것을 고르세요.

• A. 효과 (Effect)
• B. 원칙 (Principal)
• C. 버전 (Version)
• D. 조치 (Action)
• E. 리소스 (Resource)

IAM 정책의 문장은 시드(Sid), 효과(Effect), 원칙(Principal), 조치(Action), 리소스(Resource) 그리고 조건(Condition Block)으로 구성됩니다. 버전은 IAM 정책 자체의 일부이지, 문장의 일부가 아닙니다.

• Sid(선택 사항): 선택 설명문 ID를 포함하여 설명문들을 구분합니다.

• Effect: Allow 또는 Deny를 사용하여 정책에서 액세스를 허용하는지 또는 거부하는지 여부를 설명합니다.
• Principal(일부 상황에서만 필요): 리소스 기반 정책을 생성하는 경우 액세스를 허용하거나 거부할 계정, 사용자, 역할 또는 페더레이션 사용자를 표시해야 합니다. 사용자 또는 역할에 연결할 IAM 권한 정책을 생성하면 이 요소를 포함할 수 없습니다. 보안 주체는 사용자 또는 역할을 의미합니다.
• Action: 정책이 허용하거나 거부하는 작업 목록을 포함합니다.
• Resource(일부 상황에서만 필요): IAM 권한 정책을 생성하는 경우 작업이 적용되는 리소스 목록을 지정해야 합니다. 리소스 기반 정책을 생성하는 경우 이 요소는 선택사항입니다. 이 요소를 포함하지 않으면 작업이 적용되는 리소스는 정책이 연결된 리소스입니다.
• Condition(선택 사항): 정책에서 권한을 부여하는 상황을 지정합니다.

10. AWS 공동 책임 모델을 따를 경우, 다음 중 AWS 책임에 해당하는 것은 무엇인가요 ?

• A. IAM 사용자, 사용자 그룹 및 IAM 정책
• B. AWS 인프라
• C. 루트 계정 및 모든 IAM 사용자에 대한 MFA 활성화
• D. IAM 사용자의 액세스 키 교체

Block 스토리지

• Amazon EBS
• EC2 Instance Store

File 스토리지

• Amazon EFS
• Amazon FSx

Object 스토리지

• Amazon S3
• Amazon Glacier

Storage Comparison

S3: 객체 스토리지이며 또한 서버리스입니다. 용량을 미리 프로비저닝할 필요가 없고 데이터베이스 서비스와 긴밀하게 통합됩니다.

Glacier: 객체 아카이브를 위한 곳으로 객체를 오랫동안 저장하고 싶고 회수할 일은 드물 경우 사용하며 객체가 아카이브 되었기 때문에 객체를 다시 회수하기 까지 오랜 시간이 걸립니다.

EFS: 일래스틱 파일 시스템으로 Linux 인스턴스용의 네트워크 파일 시스템이며 동시에 POSIX 파일 시스템입니다. 모든 EC2 인스턴스에서 동시에 액세스 가능하며 AZ 전반에 걸쳐 공유됩니다.

EBS: EBS 볼륨은 네트워크 스토리지로 한 번에 EC2 인스턴스 하나만 액세스 되며 또 생성된 특정 가용 영역 내부에 바인딩되어 AZ를 변경하고 싶다면 스냅샷을 생성해서 해당 스냅샷을 원하는 AZ로 이동시키고 볼륨을 생성해야 합니다.

인스턴스 스토리지: EC2 인스턴스의 물리적 스토리지이며 하드웨어에 연결되어 있기 때문에 EBS보다 훨씬 높은 IOPS를 가지게 됩니다. EBS 볼륨은 최대 16,000 IOPS, io1에선 최대 64,000 IOPS인데 인스턴스 스토리지는 EC2 인스턴스와 물리적으로 연결되기 때문에 수백만 IOPS도 가능하며 매우 높습니다. 하지만 EC2 인스턴스가 중단되면 해당 스토리지가 영구적으로 손실될 위험이 있습니다.

FSx for Windows: Windows용 FSx는 EFS와 같지만 Windows를 위한 것이며 즉 Windows 서버를 위한 네트워크 파일 시스템입니다.

FSx for Lustre: Lustre용 FSx는 Linux와 클러스터로 고성능 컴퓨팅이 가능한 Linux 파일 시스템입니다. 여기에서 HPC가 실행됩되며 IOPS가 높고 용량도 크며 백엔드에서 S3와 통합됩니다.

Storage Gateway: 온프레미스 서버에서 AWS로 파일을 전송하는데 여기에는 File Gateway, 캐시 및 저장을 위한 Volume Gateway, Tape Gateway가 있으며 각각의 사용 사례가 다릅니다.

Database: RDBMS, NoSQL 등이 있으며 보다 특정한 워크로드에 사용되는데 일반적으로 인덱싱 및 쿼리와 함께 사용됩니다.

Snowball, Snowmobile: 마지막으로 Snowball과 Snowmobile은 대용량 데이터를 S3의 클라우드로 물리적으로 옮깁니다.

Storage Gateway 종류

Storage Gateway

온프레미스 데이터와 클라우드 사이에 브리지가 필요할 경우

File Gateway

네트워크 파일 시스템과 함께 Active Directory을 사용하는 선택적 사용자 인증이 필요할 경우

Volume Gateway

볼륨, 블록 스토리지 그리고 iSCSI 백업이 필요한 경우 볼륨 게이트웨이를 사용하여 EBS 스냅샷을 생성하여 Amazon S3로 백업

Tape Gateway

백업에 테이프 솔루션이 필요할 경우

온프레미스 가상화 시스템이 없는 경우

소스 게이트웨이에서 하드웨어 어플라이언스를 주문하고 데이터 센터에 설치

1. S3에 대규모의 데이터셋이 저장되어 있습니다. 여러분은 NFS, 혹은 SMB 프로토콜을 사용해 온프레미스 서버를 통해 이 데이터셋에 액세스하려 합니다. 또한, 온프레미스 Microsoft AD를 통해 이러한 파일에 대한 액세스를 인증하고자 합니다. 무엇을 사용해야 할까요 ?

• A. AWS Storage Gateway - 볼륨 게이트웨이
• B. AWS Storage Gateway - 파일 게이트웨이
• C. AWS Storage Gateway - 테이프 게이트웨이
• D. AWS Data Migration Service

2. 수백 TB의 데이터를 Amazon S3로 이전한 후, EC2 인스턴스 플릿을 사용해 처리해야 합니다. 광대역은 1Gbit/초 입니다. 여러분은 데이터를 더 빠르게 이전하고, 가능하면 전송 중에 데이터를 처리했으면 합니다. 어떤 방법을 추천할 수 있을까요 ?

• A. 자체 네트워크 사용하기
• B. Snowcone 사용하기
• C. AWS 데이터 이전 사용하기
• D. Snowball Edge 사용하기

✅ Snowball Edge는 컴퓨팅 능력을 갖추고 있으며, 데이터가 Snowball로 이동하는 동안 데이터를 사전에 처리할 수 있도록 해주므로 정답입니다.

3. 테이프 백업에 가상 인피니트 스토리지를 노출하려고 합니다. 여러분은 사용 중인 것과 동일한 소프트웨어를 유지하고, iSCSI와 호환 가능한 인터페이스를 사용하려 합니다. 어떤 방법을 사용해야 할까요 ?

• A. AWS Snowball
• B. AWS Storage Gateway - 테이프 게이트웨이
• C. AWS Storage Gateway - 볼륨 게이트웨이
• D. AWS Storage Gateway - 파일 게이트웨이

4. 여러분의 EC2 Windows 서버는 Windows의 보안 매커니즘을 준수하며, Microsoft Active Directory와 통합된 네트워크 파일 시스템을 마운트하여 일부 데이터를 공유해야 합니다. 어떤 방법을 추천할 수 있을까요 ?

• A. Windows용 Amazon FSx(파일 서버)
• B. Amazon EFS
• C. Lustre용 Amazon FSx
• D. 파일 게이트웨이를 지닌 Amazon S3

5. 여러분은 수백 TB의 데이터를 AWS S3로 최대한 빨리 이전시켜야 합니다. 여러분의 네트워크 대역폭을 사용해보려 했으나 업로드 프로세스가 완료되기까지 약 3주가 소요됩니다. 이런 경우 어떤 접근법이 권장될까요 ?

• A. AWS Storage Gateway - 볼륨 Gateway
• B. S3 멀티파트 업로드
• C. AWS Snowball 엣지
• D. AWS 데이터 이전 서비스

6. 기업의 인프라를 온프레미스에서 AWS Cloud로 이전시킬 계획을 가지고 있습니다. 여러분은 이전시키려는 온프레미스 Microsoft Windows 파일 서버를 갖고 있습니다. 어떤 AWS 서비스를 사용하는 것이 가장 적절할까요 ?

• A. Windows용 Amazon FSx(파일 서버)
• B. AWS Storage Gateway - 파일 게이트웨이
• C. AWS가 관리하는 Microsoft AD

7. 고성능 컴퓨팅(HPC)과 전산 유전학 연구를 수행하기 위해 IOPS를 최대화해 줄 분산 POSIX 준수 파일 시스템이 필요한 상황입니다. 이 파일 시스템은 수백만 개의 IOPS로 손쉽게 스케일링할 수 있어야 합니다. 어떤 방법을 추천할 수 있을까요 ?

• A. Max를 가진 EFS IO 활성화
• B. Lustre용 Amazon FSxLustre 용 Amazon FSx
• C. EC2 인스턴스에 탑재된 Amazon S3
• D. EC2 인스턴스 스토어

8. FSx 파일 시스템에 있는 다음 배포 옵션 중에서 AZ 내에 복사된 장기 스토리지를 제공하는 것은 무엇인가요 ?

• A. Scratch File System
• B. Persistent File System

9. 다음 중 AWS 전송 제품군(AWS Transfer Family)이 지원하지 않는 프로토콜은 무엇인가요 ?

• A. 파일 전송 프로토콜(FTP)
• B. SSL을 통한 파일 전송 프로토콜(FTP)
• C. 전송층 보안(TLS)
• D. 보안 파일 전송 프로토콜(FTP)

✅ AWS 전송 제품군(AWS Transfer Family)는 FTP 프로토콜을 사용해 S3 혹은 EFS 내부/외부로 파일을 전송하는 관리 서비스입니다. 따라서 TLS를 지원하지 않습니다.

1. S3 버킷에 유료 콘텐츠가 저장되어 있습니다. 이 콘텐츠를 전역적으로 분배하기 위해 CloudFront 배포를 설정하고 S3 버킷이 CloudFront 배포에서만 데이터를 교환하도록 구성했습니다. 다음 CloudFront 기능 중 유료 콘텐츠를 안전하게 분배하기 위해서는 무엇을 사용해야 할까요 ?

• A. 원본 액세스 ID
• B. S3 Presigned URL
• C. CloudFront Presigned Url
• D. CloudFront 무효화

✅ CloudFront Presigned URL은 일반적으로 동적으로 생성된 Presigned URL을 통해 유료 콘텐츠를 배포하는 데 사용됩니다.

2. Application Load Balancer가 관리하는 EC2 인스턴스 플릿에 호스팅된 웹사이트를 제공하는 CloudFront 배포가 있습니다. 모든 클라이언트가 미국에 있는데도 불구하고, 타 국가로부터 일부 악성 요청이 들어오고 있다는 점을 발견했습니다. 오직 미국으로부터의 사용자들만을 허가하고, 다른 국가는 차단하려면 어떻게 해야 할까요 ?

• A. CloudFront 지리적 제한 사용하기
• B. 원본 액세스 ID 사용하기
• C. 보안그룹을 설정한 뒤 이를 CloudFront 배포에 연결하기
• D. Route 53 지연 시간을 사용해 이를 CloudFront 분배로 연결하기

3. S3 버킷 상에 호스팅된 정적 웹사이트가 있습니다. 요청을 더 잘 처리하고 성능을 향상시키기 위해 S3 버킷을 가리키는 CloudFront 배포를 생성했습니다. 얼마 후, 여러분은 아직도 사용자들이 S3 버킷에서 웹사이트로 직접 액세스할 수 있다는 것을 알게 되었습니다. 여러분은 사용자들이 CloudFront만을 통해서 웹사이트로 액세스하게끔 하려 합니다. 이를 위해서는 어떻게 해야 할까요?

• A. 클라이언트들에게 이메일을 보내 S3 엔드 포인트를 사용하지 말 것을 요청
• B. CloudFront 배포를 구성해 원본 액세스 ID를 생성한 후, S3 버킷이 오직 CloudFront 배포 OAI 사용자들이 보내는 요청만을 수락하도록 업데이트
• C. 클라이언트가 CloudFront로 리다이렉팅되도록 S3 액세스 포인트 사용

4. Application Load Balancer가 관리하는 한 세트의 EC2 인스턴스에 웹사이트가 호스팅되어 있습니다. 여러분은 CloudFront 배포를 생성해 그 오리진이 ALB를 가리키도록 설정했습니다. CloudFront 배포를 통해 제공되는 수백 개의 사설 파일에 대한 액세스를 제공하려면 무엇을 사용해야 할까요?

• A. CloudFront Presigned URL
• B. CloudFront 원본 액세스 ID
• C. CloudFront 서명된 쿠키
• D. CloudFront HTTPS 암호화

✅ 서명된 URL은 개별 파일에 액세스하는 데에 유용하고 서명된 쿠키는 다수의 파일에 액세스하는 데에 유용합니다.

5. HTTP REST API를 노출시킬 애플리케이션을 생성하고 있습니다. 요청 라우팅 규칙을 HTTP 레벨에서 제공해야 할 필요가 있습니다. 보안 요구 사항 때문에 애플리케이션은 두 개의 정적 IP 주소를 통해서만 노출될 수 있습니다. 이러한 요구사항을 충족시키기 위한 솔루션을 생성하려면 어떻게 해야 할까요?

• A. Network Load Balance를 사용하고 탄력적 IP를 여기에 연결
• B. AWS Global Accelarator와 Application Load Balancer 사용
• C. Application Load Balancer를 사용하고 탄력적 IP를 여기에 연결
• D. CloudFront를 탄력적 IP와 Application Load Balancer와 함께 사용

6. AWS Global Accelerator는 두 개의 정적 IP 주소를 제공하며 ALB는 HTTP 라우팅 규칙을 제공합니다.

{
    "Version": "2012-10-17",
    "Id": "Mystery policy",
    "Statement": [{
         "Sid": "What could it be?",
         "Effect": "Allow",
         "Principal": {
             "CanonicalUser": "CloudFront Origin Identity Canonical User ID"
         },
         "Action": "s3:GetObject",
         "Resource": "arn:aws:s3:::examplebucket/*"
    }]
}

• A. CloudFront에서 GetObjcet 요청의 경우, 이를 암호화하도록 강제
• B. CloudFront 배포 Access ID에서 오는 S3 버킷 콘텐츠만이 평가될 수 있도록 허가
• C. S3 버킷에 대한 GetObject 유형의 요청만을 허가