개념정리
AWS CloudFormation
- 개념 :
- AWS 클라우드 환경에서 리소스를 코드로 관리할 수 있게 해주는 Infra Structure 관리 도구이다
- AWS의 다양한 리소스[예 : EC2, S3, RDS 등)를 프로그래밍 방식으로 정의하고 배포할 수 있음
- 템플릿 기반 인프라
- CloudFormation 템플릿은 JSON 또는 YAML 파일 형식으로 작성됨. 이 파일에는 배포하려는 AWS 리소스의 세부사항[예 : 리소스의 종류, 속성, 종속성 등]이 정의됨
- 예를 들어, EC2 인스턴스를 설정하거나, S3 버킷을 생성하고, 로드 밸런서를 설정하는 등의 작업을 템플릿 파일에 작성한 후, 이를 기반으로 자동으로 인프라를 구축할 수 있음
- 스택
- AWS CloudFormation에서 생성된 리소스들의 집합을 "스택"이라고 부른다. 즉, 템플릿을 기반으로 인프라가 배포되면, 그 결과로 만들어진 리소스 그룹을 스택이라고 한다. 예를 들어, EC2 인스턴스와 로드 밸런서, 그리고 DB를 하나의 스택으로 묶어 관리할 수 있음
- 스택은 필요할 떄 업데이트하거나 삭제할 수 있으며, CloudFormation을 통해 리소스 간의 종속성 및 순서도 자동으로 관리됨
- 자동화 및 일관성
- 인프라의 배포와 관리를 자동화하기 때문에, 동일한 템플릿을 여러 환경에서 반복해서 사용할 수 있음
- 예를 들어, 개발 환경, 테스트 환경, 프로덕션 환경에서 동일한 인프라 구성을 손쉽게 배포할 수 있어 환경 간의 일관성을 유지할 수 있음
- IaC[Infrastructure as Code]로 배포가 가능하므로, 코드 리뷰와 버전 관리가 가능하며 수동으로 인프라를 설정하는 과정에서 발생할 수 있는 실수를 줄여준다.
- 변경 관리 및 업데이트
- 이미 배포된 스택의 변경 사항이 있을 경우, CloudFormation은 이를 템플릿 업데이트를 통해 관리한다.
- 변경 사항이 적용되면 기존 리소스가 필요에 따라 업데이트되거나 교체된다.
- 이 과정에서 다운타임을 최소화할 수 있으며, 롤백 기능도 제공되어 문제가 발생할 경우 이전 상태로 복구할 수 있다.
- 종속성 관리
- CloudFormation은 리소스 간의 종속성을 자동으로 관리한다.
- 예를 들어, S3 버킷을 먼저 생성한 후 EC2 인스턴스에 연결해야 하는 상황이라면, CloudFormation은 이러한 순서를 자동으로 처리한다.
- 비용 관리
- CloudFormation을 사용하면 불필요한 리소스를 쉽게 추적하고, 스택 단위로 삭제할 수 있어 비용 관리에도 용이하다.
- 스택을 삭제하면 스택에 속한 모든 리소스도 함께 삭제되기 때문에, 남아있는 잉여 리소스로 인해 발생하는 비용을 줄일 수 있다.
- 외부 서비스 통합
- CloudFormation은 Lambda, SQS, SNS와 같은 AWS 서비스뿐만 아니라 서드파티 서비스와도 통합할 수 있다.
- 또한, 사용자가 직접 정의한 리소스를 배포할 수 있는 Custom Resources 기능도 제공해 유연한 인프라 구성이 가능하다.
VPC 엔드포인트
일반적으로 VPC 안에 있는 리소스가 AWS 서비스에 접근할 때는 인터넷 게이트웨이를 통해 퍼블릭 인터넷을 경유해야 한다. 이 경우 NAT 게이트웨이나 NAT 인스턴스를 사용하여 퍼블릭 인터넷을 통과해야 하므로 추가적인 데이터 전송 비용이 발생한다.
VPC 엔드포인트는 이러한 인터넷 경유를 없애기 위해 제공되며, AWS 네트워크 내에서 직접 연결을 제공함으로써 보안과 비용 효율성을 동시에 달성할 수 있ㄷ다. VPC 엔드포인트를 사용하면 EC2 인스턴스가 퍼블릭 인터넷에 노출되지 않고 AWS 서비스와 통신할 수 있다.
VPC 엔드포인트의 종류
1. 게이트웨이 엔드포인트 (Gateway Endpoint):
- 지원 서비스: S3, DynamoDB
- 설명: 게이트웨이 엔드포인트는 라우팅 테이블을 통해 설정됩니다. 이는 VPC 내에서 AWS의 S3 또는 DynamoDB와 통신할 때, 트래픽이 인터넷을 거치지 않고 AWS 네트워크 내에서 직접 경로를 설정하는 방식입니다.
- 사용 예: 프라이빗 서브넷 내의 EC2 인스턴스가 퍼블릭 인터넷 없이 S3 버킷과 데이터를 주고받을 수 있습니다.
2. 인터페이스 엔드포인트 (Interface Endpoint):
- 지원 서비스: 다양한 AWS 서비스 (Lambda, SNS, CloudWatch 등)
- 설명: 인터페이스 엔드포인트는 AWS PrivateLink를 기반으로 작동하며, 특정 서비스에 대한 엔드포인트 네트워크 인터페이스를 생성하여 AWS 서비스와의 프라이빗 연결을 제공합니다. 이는 보안 그룹을 통해 제어할 수 있으며, 서비스에 대한 세부적인 접근 권한을 설정할 수 있습니다.
- 사용 예: EC2 인스턴스에서 퍼블릭 인터넷 없이 Lambda 함수 또는 SNS 주제와 통신할 수 있습니다.
VPC 엔드포인트의 주요 장점
1. 비용 절감:
- 퍼블릭 인터넷을 경유하지 않으므로 NAT 게이트웨이나 인터넷 데이터 전송 비용을 절감할 수 있습니다. 특히, S3와 같은 서비스는 VPC 엔드포인트를 사용할 때 트래픽 비용이 매우 낮아집니다.
2. 보안 강화:
- 퍼블릭 인터넷을 사용하지 않고 AWS의 내부 네트워크에서 트래픽을 처리하므로, 데이터 보안이 강화됩니다. 또한, EC2 인스턴스가 퍼블릭 IP 없이도 AWS 서비스와 안전하게 통신할 수 있어 공격 표면을 줄일 수 있습니다.
3. 네트워크 성능 최적화:
- 트래픽이 퍼블릭 인터넷을 통하지 않고 AWS 내부 네트워크를 통해 처리되므로 네트워크 대기 시간이 줄어들고 성능이 향상됩니다.
4. 프라이빗 서브넷에서 직접 접근 가능:
- 퍼블릭 인터넷을 거치지 않고도 프라이빗 서브넷 내 리소스에서 AWS 서비스에 직접 접근할 수 있어 네트워크 구성이 간단해집니다.
VPC 엔드포인트 사용 사례
1. S3와의 통신: EC2 인스턴스가 S3 버킷에 자주 접근할 경우, VPC 엔드포인트를 사용하여 퍼블릭 인터넷을 우회하고 데이터를 전송함으로써 데이터 전송 비용을 절감할 수 있습니다.
2. 보안이 중요한 서비스 통신: 퍼블릭 인터넷에 노출되지 않고 안전하게 DynamoDB, SNS, Lambda 등 다양한 AWS 서비스와 통신할 수 있습니다.
3. 프라이빗 서브넷의 애플리케이션: 퍼블릭 인터넷 연결 없이 내부 리소스가 AWS 서비스에 접근할 수 있어, 보안성을 강화할 수 있습니다.
VPC 엔드포인트 구성 방법
- 게이트웨이 엔드포인트: VPC의 라우팅 테이블에서 특정 서비스(S3, DynamoDB)에 대한 트래픽을 엔드포인트로 전달하도록 설정합니다.
- 인터페이스 엔드포인트: AWS 콘솔이나 CLI를 통해 특정 서비스에 대한 프라이빗 IP 주소를 할당받아 VPC에 엔드포인트를 설정하고, EC2 인스턴스에서 해당 서비스에 접근할 때 이 엔드포인트를 사용하도록 합니다.
S3 스토리지 클래스 요약
• S3 Standard: 자주 액세스되는 데이터를 위한 스토리지, 빠른 접근, 높은 비용.
• S3 Intelligent-Tiering: 액세스 빈도에 따라 데이터를 자동으로 적절한 클래스로 이동시켜 비용 절감.
• S3 Standard-IA: 자주 접근하지 않지만 필요 시 빠른 액세스가 중요한 데이터에 적합.
• S3 One Zone-IA: 단일 가용 영역에 저장되며, 매우 저렴하지만 가용성 위험이 있음.
• S3 Glacier: 장기 보관용, 복구 시간이 오래 걸리지만 매우 저렴.
• S3 Glacier Deep Archive: 가장 저렴한 장기 보관 스토리지, 복구 시간이 가장 오래 걸림.
taskRoleArn
개념 : Amazon ECS에서 사용되는 작업에 대한 IAM 역할을 지정하는 속성입니다. 이 IAM 역할은 ECS 작업이 실행될 때 해당 작업에 부여할 권한을 정의합니다.
예시 :
- 만약 ECS 작업이 S3 버킷에 저장된 파일을 읽거나 쓰려면, 해당 작업에 대한 권한이 필요합니다.
- IAM 역할을 생성하여 S3에 대한 읽기/쓰기 권한을 부여합니다.
- 생성한 IAM 역할의 ARN을 ECS 작업 정의의 taskRoleArn에 추가합니다.
클러스터 배치 그룹
개념 : 클러스터 배치 그룹은 네트워크 지연 시간을 최소화하고 높은 네트워크 처리량이 필요한 애플리케이션에 적합한 배치 전략입니다. 같은 물리적 하드웨어에 인스턴스를 밀집 배치하여 인스턴스 간 통신을 빠르게 할 수 있도록 설계되었습니다.
특징 :
- 인스턴스들이 서로 매우 가깝게 배치됩니다.
- 저지연 네트워크 통신과 높은 네트워크 처리량을 필요로 하는 애플리케이션에 적합합니다.
- 주로 고성능 컴퓨팅, 빅데이터 처리, 분산 애플리케이션 등에서 사용됩니다.
- 단점은 여러 인스턴스가 한 물리적 하드웨어에 가까이 배치되므로 단일 장애 지점 위험이 증가할 수 있습니다. 즉, 하드웨어 고장이 발생하면 배치된 모든 인스턴스가 영향을 받을 수 있습니다.
파티션 배치 그룹
개념 : 파티션 배치 그룹은 데이터를 분산시키고 장애 내성을 강화하는 데 중점을 둔 배치 전략입니다. 각 파티션은 서로 다른 물리적 하드웨어에 배치되며, 하나의 파티션에 장애가 발생하더라도 다른 파티션은 영향을 받지 않도록 설계되었습니다.
특징 :
- 여러 파티션으로 인스턴스를 분리하여 배치합니다.
- 각 파티션은 다른 물리적 하드웨어를 사용하므로 고가용성이 요구되는 시스템에 적합합니다.
- 대규모 배포에서 장애 내성을 강화하기 위해 사용됩니다.
- 수백 대의 인스턴스를 사용할 때, 각 파티션 간에 격리된 배치를 보장합니다.
용어정리
다운타임 : 시스템, 서버, 네트워크, 애플리케이션 등의 IT 서비스가 일시적으로 중단되는 시간을 의미한다. 즉, 사용자가 해당 서비스를 정상적으로 이용할 수 없는 상태를 말한다.
문제풀이
문제 1: 회사는 AWS 클라우드에서 애플리케이션을 호스팅합니다. 애플리케이션은 Auto Scaling 그룹의 Elastic Load Balancer 뒤에서 Amazon DynamoDB 테이블과 함께 Amazon EC2 인스턴스에서 실행됩니다. 회사는 다운타임을 최소화하면서 다른 AWS 리전에서 애플리케이션을 사용할 수 있도록 하려고 합니다. 최소한의 다운타임으로 이러한 요구 사항을 충족하려면 솔루션 설계자가 무엇을 해야 합니까? A
A. 재해 복구 지역에 Auto Scaling 그룹과 로드 밸런서를 생성합니다. DynamoDB 테이블을 전역 테이블로 구성합니다. 새 재해 복구 지역의 로드 밸런서를 가리키도록 DNS 장애 조치를 구성합니다.
- 이 선택지는 자동 확장 및 로드 밸런서 설정을 통해 애플리케이션의 가용성을 확보하는 방법입니다. 또한 DynamoDB 전역 테이블을 사용해 여러 리전에 걸쳐 데이터베이스를 복제해 가용성을 높입니다. DNS 장애 조치를 통해 서비스가 원활히 다른 리전으로 전환될 수 있도록 하는 방식입니다. 전반적으로 적절한 재해 복구 전략을 제시하고 있습니다.
B. AWS CloudFormation 템플릿을 생성하여 필요할 때 시작할 EC2 인스턴스, 로드 밸런서 및 DynamoDB 테이블을 생성합니다. 새 재해 복구 지역의 로드 밸런서를 가리키도록 DNS 장애 조치를 구성합니다.
- AWS CloudFormation을 사용해 리소스를 자동으로 생성할 수 있지만, 이 선택지는 사전 구성된 리소스 없이 필요할 때만 시작되는 구조입니다. 즉, 필요할 때 리소스를 생성하는 방식은 시간이 걸릴 수 있기 때문에 다운타임 최소화 목표와는 맞지 않습니다.
C. AWS CloudFormation 템플릿을 생성하여 EC2 인스턴스를 생성하고 필요할 때 시작할 로드 밸런서를 생성합니다. DynamoDB 테이블을 전역 테이블로 구성합니다. 새 재해 복구 지역의 로드 밸런서를 가리키도록 DNS 장애 조치를 구성합니다.
- 이 선택지 역시 EC2 인스턴스와 로드 밸런서가 필요할 때만 시작되므로 다운타임 최소화와는 거리가 있습니다. 다만 DynamoDB 전역 테이블을 사용하는 점은 적절합니다.
D. 재해 복구 지역에 Auto Scaling 그룹 및 로드 밸런서를 생성합니다. DynamoDB 테이블을 전역 테이블로 구성합니다. 재해 복구 로드 밸런서를 가리키는 Amazon Route 53을 업데이트하는 AWS Lambda 함수를 트리거하는 Amazon CloudWatch 경보를 생성합니다.
- 이 선택지는 Lambda와 CloudWatch 경보를 사용해 장애 상황에서 자동으로 DNS를 업데이트하는 방식을 제안합니다. 이 방식은 완전 자동화된 프로세스를 제공하지만, 실시간 장애 감지와 즉각적인 대응보다는 약간의 지연이 있을 수 있습니다.
문제 2 : 회사는 Amazon S3를 사용하여 사용자가 업로드한 이미지를 저장할 계획입니다. 이미지는 Amazon S3에서 암호화되어야 합니다. 회사는 키를 관리하고 교체하는 데 시간을 소비하고 싶지 않지만 해당 키에 액세스할 수 있는 사람을 제어하기를 원합니다.
솔루션 설계자는 이를 달성하기 위해 무엇을 사용해야 합니까? D
A. S3 버킷에 저장된 키를 사용한 서버 측 암호화
- 이 방법은 회사가 키를 직접 관리하게 되는 방식입니다. 회사는 키를 관리하고 싶지 않다고 했으므로 이 선택지는 적합하지 않습니다.
B. 고객 제공 키를 사용한 서버 측 암호화 (SSE-C)
- 이 방식은 고객이 직접 제공한 키를 사용하는 방법입니다. 고객이 키를 제공하고 관리해야 하기 때문에 역시 회사의 요구사항에 맞지 않습니다.
C. Amazon S3 관리형 키를 사용한 서버 측 암호화 (SSE-S3)
- 이 방법은 AWS S3에서 자체적으로 키를 관리하고, 암호화를 수행하는 방식입니다. 회사가 키를 관리할 필요가 없으므로, 회사가 원하는 요구사항에 부합할 수 있습니다. 다만, 접근 제어를 위해 더 나은 방법이 있을 수 있습니다. [AWS에서 관리]
D. AWS KMS 관리형 키를 사용한 서버 측 암호화 (SSE-KMS)
- 이 방식은 AWS Key Management Service(KMS)를 사용하여 암호화 키를 관리하는 방식입니다. AWS가 키를 관리하지만, 회사는 KMS를 통해 키에 대한 접근을 제어할 수 있습니다. 즉, 회사는 키 관리에 시간을 쓰지 않으면서도 키에 접근할 수 있는 사람을 제어할 수 있으므로, 이 방법이 가장 적합합니다.
문제 3 :고객이 VPC의 프라이빗 서브넷에서 호스팅되는 Amazon EC2 인스턴스에서 애플리케이션을 실행하고 있습니다. EC2 인스턴스는 Elastic Load Balancer(ELB) 뒤의 Auto Scaling 그룹에서 구성됩니다. EC2 인스턴스는 NAT 게이트웨이 아웃바운드 인터넷 액세스를 사용하지만 EC2 인스턴스는 공용 인터넷에 연결하여 소프트웨어 업데이트를 다운로드할 수 없습니다. B,E
A. ELB가 적절한 상태 확인으로 구성되지 않았습니다.
- 이 선택지는 EC2 인스턴스가 애플리케이션 로드 밸런서를 통한 트래픽 분배 문제를 의미합니다. 그러나 지금 문제는 EC2 인스턴스가 소프트웨어 업데이트를 다운로드하지 못하는 것이므로 적절한 원인이라고 보기 어렵습니다.
B. VPC의 라우팅 테이블이 잘못 구성되었습니다.
- EC2 인스턴스가 인터넷에 접근하기 위해서는 올바른 라우팅 테이블이 필요합니다. 라우팅 테이블이 잘못 구성되면 인터넷에 연결할 수 없으므로 이 선택지는 타당한 원인입니다.
- 프라이빗 서브넷의 라우팅 테이블에 NAT 게이트웨이 라우팅을 구성해야 합니다.
C. EC2 인스턴스가 탄력적 IP 주소와 연결되어 있지 않습니다.
- 탄력적 IP는 인스턴스가 퍼블릭 서브넷에 있을 때 필요합니다. 이 문제는 프라이빗 서브넷에 있는 EC2 인스턴스와 관련이 있으므로 이 선택지는 적절하지 않습니다.
D. NAT 게이트웨이에 연결된 보안 그룹이 잘못 구성되었습니다.
- 보안그룹을 NAT 게이트웨이에 적용할 수 없습니다.
E. EC2 인스턴스에 대한 보안 그룹 연결에 대한 아웃바운드 규칙이 잘못 구성되었습니다.
- EC2 인스턴스에서 NAT 게이트웨이를 통해 인터넷에 연결하기 위해서는 보안 그룹이 아웃바운드 트래픽을 허용해야 합니다. 이 설정이 잘못되면 인스턴스가 인터넷에 접근하지 못할 수 있으므로 이 선택지도 가능성이 있습니다.
문제 4 :회사는 Amazon ECS를 사용하여 애플리케이션을 실행합니다. 애플리케이션이 크기가 조정된 원본 이미지 버전을 생성한 다음 Amazon S3 API를 호출하여 크기 조정된 이미지를 Amazon S3에 저장합니다. 솔루션 설계자는 애플리케이션에 Amazon S3에 대한 액세스 권한이 있는지 어떻게 확인할 수 있습니까? B
A. Amazon ECS에서 읽기/쓰기가 가능하도록 AWS IAM에서 S3 역할을 업데이트한 다음 컨테이너를 다시 시작합니다.
- 이 방법은 IAM 역할을 업데이트하는 것으로, S3에 접근할 수 있도록 권한을 부여하는 과정입니다. 하지만 S3 액세스 권한을 부여하고 컨테이너를 다시 시작해야 한다고 언급했기 때문에 권한 확인보다는 설정 방법에 가깝습니다.
B. S3 권한이 있는 IAM 역할을 생성한 다음 해당 역할을 작업 정의에서 taskRoleArn으로 지정합니다.
- 이 선택지는 ECS 작업에서 S3에 접근할 수 있도록 IAM 역할을 지정하는 방법을 설명합니다. 적절한 권한을 부여하고 나면 S3 API를 통해 이미지에 접근할 수 있습니다. 이를 통해 액세스 권한이 있는지 확인할 수 있습니다. 따라서 이 선택지는 적합한 방법입니다.
C. Amazon ECS에서 Amazon S3로의 액세스를 허용하는 보안 그룹을 생성하고 ECS 클러스터에서 사용하는 시작 구성을 업데이트합니다.
- 보안 그룹은 네트워크 트래픽을 제어하는 역할을 하므로 S3에 대한 액세스 권한과는 관련이 없습니다. 따라서 적절한 방법이 아닙니다.
D. S3 권한이 있는 IAM 사용자를 생성한 다음 이 계정으로 로그인한 상태에서 ECS 클러스터에 대한 Amazon EC2 인스턴스를 다시 시작합니다.
- IAM 사용자를 생성하는 것은 ECS 클러스터에서의 액세스 권한 설정과 관련이 없습니다. 이 방법은 적절하지 않습니다.
문제 5 : 회사는 Amazon EC2 인스턴스에서 컴퓨팅 집약적인 애플리케이션을 호스팅할 계획입니다. 대부분의 네트워크 트래픽은 이러한 애플리케이션 간에 발생합니다. 회사에는 지연 시간을 최소화하고 네트워크 처리량을 최대화하는 솔루션이 필요합니다. EC2 인스턴스의 기본 하드웨어를 다른 회사와 공유해서는 안 됩니다.
다음 중 이러한 요구 사항을 충족하는 솔루션은 무엇입니까?
A. 클러스터 배치 그룹에서 EC2 인스턴스를 전용 호스트로 시작
- 클러스터 배치 그룹은 인스턴스들을 동일한 물리적 하드웨어에 가깝게 배치하여 네트워크 지연 시간을 최소화하는 방법입니다. “전용 호스트”는 EC2 인스턴스가 다른 회사와 하드웨어를 공유하지 않도록 하여, 요구 사항에 적합합니다. 따라서 이 선택지는 적절한 해결책이 될 수 있습니다.
B. EC2 인스턴스를 파티션 배치 그룹의 전용 호스트로 시작
- 파티션 배치 그룹은 큰 규모의 배포에서 데이터를 분산하여 장애 발생 시 영향 범위를 최소화하기 위한 것입니다. 하지만 문제에서 요구하는 것은 네트워크 지연 시간 최소화와 전용 하드웨어 사용입니다. 따라서 이 선택지는 부적합할 수 있습니다.
C. 클러스터 배치 그룹에서 EC2 인스턴스를 전용 인스턴스로 시작
- "전용 인스턴스”는 물리적 하드웨어에서 다른 사용자의 인스턴스와 공유하지 않도록 보장하지만, “전용 호스트”만큼의 하드웨어 관리 권한을 제공하지는 않습니다. 또한 클러스터 배치 그룹은 네트워크 지연 시간 최소화에 도움이 되므로, 이 선택지도 적절한 해결책이 될 수 있습니다.
D. EC2 인스턴스를 파티션 배치 그룹의 전용 인스턴스로 시작
- 이 선택지는 파티션 배치 그룹과 전용 인스턴스를 사용합니다. 하지만 이 설정은 문제에서 요구하는 네트워크 지연 시간 최소화와는 관련이 적으며, 전용 호스트가 아닌 전용 인스턴스를 사용합니다. 따라서 이 선택지는 적절하지 않을 수 있습니다.
'개발 > AWS' 카테고리의 다른 글
[AWS - SAA] 개념정리 및 문제풀이 7일차 (0) | 2024.09.27 |
---|---|
[AWS - SAA] 개념정리 및 문제풀이 6일차 (2) | 2024.09.26 |
[AWS - SAA] 개념정리 및 문제풀이 3일차 (8) | 2024.09.04 |
[AWS - SAA] 개념 정리 및 문제 풀이 - 2일차 (0) | 2024.08.29 |
[AWS] [Step - 1] VPC 부터 서브넷 구축 해보기 (0) | 2024.07.14 |