회사는 최근 온프레미스 데이터 센터를 AWS 클라우드에 통합하는 하이브리드 아키텍처를 채택했습니다. VPC를 구성하고 필요한 IAM 사용자, IAM 역할, IAM 그룹 및 IAM 정책을 구현하도록 지정되었습니다.
이 시나리오에서 IAM 정책을 생성할 때 모범 사례는 무엇입니까?
작업을 수행하는 데 필요한 권한만 부여하는 최소 권한 원칙을 사용합니다.
AWS 리소스를 보호하려면 AWS Identity and Access Management(IAM)에 대한 다음 모범 사례를 따르세요.
- 임시 보안 인증을 사용하여 AWS에 액세스하려면 인간 사용자가 ID 공급자와의 페더레이션을 사용하도록 요구합니다.
- AWS에 액세스하려면 워크로드에 IAM 역할이 있는 임시 자격 증명을 사용하도록 요구합니다.
- 다중 인증(MFA) 필요
- 장기 보안 인증이 필요한 사용 사례의 경우 정기적으로 액세스 키 교체
- 루트 사용자 보안 인증을 보호하고 일상적인 작업에 사용하지 마세요.
- 최소 권한 적용
- AWS 관리형 정책으로 시작하고 최소 권한을 향해 나아갑니다.
- IAM 액세스 분석기를 사용하여 액세스 활동을 기반으로 최소 권한 정책 생성
- 사용하지 않는 사용자, 역할, 권한, 정책 및 보안 인증은 정기적으로 검토하고 제거합니다.
- IAM 정책의 조건을 사용하여 액세스 추가 제한
- IAM Access Analyzer를 사용하여 리소스에 대한 퍼블릭 및 크로스 계정 액세스 확인
- IAM Access Analyzer를 사용하여 IAM 정책을 검증하여 안전하고 기능적인 권한을 보장합니다.
- 여러 계정에 권한 가드레일 설정
- 권한 경계를 사용하여 계정 내에서 권한 관리 위임
IAM 정책을 사용하여 권한을 설정하는 경우 작업을 수행하는 데 필요한 권한만 부여합니다. 이렇게 하려면 최소 권한으로 알려진 특정 조건에서 특정 리소스에 대해 수행할 수 있는 작업을 정의합니다. 워크로드 또는 사용 사례에 필요한 권한을 탐색하는 동안 광범위한 권한으로 시작할 수 있습니다. 사용 사례가 발전함에 따라 최소 권한을 향해 나아가도록 부여하는 권한을 줄이기 위해 노력할 수 있습니다.
Solutions Architect는 기존 Amazon VPC가 있는 대규모 회사에 합류했습니다. Auto Scaling 이벤트를 검토할 때 Architect는 웹 애플리케이션이 한 시간 내에 여러 번 확장 및 축소되는 것을 확인했습니다.
Architect는 탄력성을 유지하면서 비용을 최적화하기 위해 어떤 설계 변경을 할 수 있습니까?
Auto Scaling 그룹의 휴지 기간을 변경하고 CloudWatch 지표를 더 높은 임계값으로 설정합니다.
애플리케이션이 한 시간 내에 여러 번 확장 및 축소되기 때문에 문제는 Auto Scaling 그룹의 휴지 기간에 있습니다.
휴지 기간은 이전 조정 활동이 적용되기 전에 추가 인스턴스를 시작하거나 종료하지 않도록 하는 Auto Scaling 그룹에 대해 구성 가능한 설정입니다. Auto Scaling 그룹은 간단한 조정 정책을 사용하여 동적으로 조정한 후 조정 활동을 재개하기 전에 휴지 기간이 완료될 때까지 기다립니다.
Auto Scaling 그룹을 수동으로 확장할 때 기본값은 휴지 기간을 기다리지 않는 것이지만 기본값을 무시하고 휴지 기간을 조정할 수 있습니다. 인스턴스가 비정상이 되면 Auto Scaling 그룹은 비정상 인스턴스를 교체하기 전에 휴지 기간이 완료될 때까지 기다리지 않습니다.
회사의 Solutions Architect는 현재 인터넷 게이트웨이가 연결된 VPC에 있는 서브넷에서 EC2 인스턴스 집합을 구성하고 있습니다. 이러한 모든 EC2 인스턴스는 인터넷에서 액세스할 수 있습니다. Architect는 다른 서브넷을 시작하고 그 안에 EC2 인스턴스를 배포하지만 Architect는 인터넷에서 이 EC2 인스턴스에 액세스할 수 없습니다.
이 문제의 가능한 이유는 무엇입니까? (2개 선택)
Amazon EC2 인스턴스에는 연결된 퍼블릭 IP 주소가 없습니다.
인터넷 게이트웨이를 통해 EC2 인스턴스에서 인터넷으로 트래픽을 보내도록 라우팅 테이블이 제대로 구성되지 않았습니다.
VPC에는 암시적 라우터가 있으며 라우팅 테이블을 사용하여 네트워크 트래픽이 전달되는 위치를 제어합니다. VPC의 각 서브넷은 서브넷의 라우팅을 제어하는 라우팅 테이블(서브넷 라우팅 테이블)과 연결되어야 합니다. 서브넷을 특정 라우팅 테이블과 명시적으로 연결할 수 있습니다. 그렇지 않으면 서브넷이 기본 라우팅 테이블과 암시적으로 연결됩니다.
서브넷은 한 번에 하나의 라우팅 테이블에만 연결할 수 있지만 여러 서브넷을 동일한 서브넷 라우팅 테이블에 연결할 수 있습니다. 선택적으로 라우팅 테이블을 인터넷 게이트웨이 또는 가상 프라이빗 게이트웨이(게이트웨이 라우팅 테이블)와 연결할 수 있습니다. 이를 통해 게이트웨이를 통해 VPC로 들어오는 인바운드 트래픽에 대한 라우팅 규칙을 지정할 수 있습니다.
서브넷 라우팅 테이블에도 인터넷 게이트웨이에 대한 경로 항목이 있는지 확인합니다. 이 항목이 없으면 인스턴스가 프라이빗 서브넷에 있고 인터넷에서 액세스할 수 없습니다.
인터넷에서 EC2 인스턴스에 액세스할 수 없는 경우(또는 그 반대의 경우) 일반적으로 다음 두 가지를 확인해야 합니다.
- EIP 또는 퍼블릭 IP 주소 유무
- 라우팅 테이블 구성
정기적으로 파일을 업로드할 외부 사용자와 공유합니다. Solutions Architect는 S3 버킷에 업로드된 모든 객체에 대한 전체 액세스 권한을 버킷 소유자에게 부여하는 솔루션을 구현해야 합니다.
이 작업을 수행하려면 어떤 조치를 취해야 합니까?
사용자가 객체의 ACL을 bucket-owner-full-control로 설정하도록 요구하는 버킷 정책을 생성합니다.
Amazon S3는 데이터를 버킷 내의 객체로 저장합니다. 객체는 파일 및 파일을 설명하는 선택적 메타데이터입니다. Amazon S3에 파일을 저장하려면 버킷에 업로드합니다. 파일을 객체로 업로드할 때 객체 및 모든 메타데이터에 대한 권한을 설정할 수 있습니다. 버킷은 객체의 컨테이너입니다. 하나 이상의 버킷을 가질 수 있습니다. 각 버킷에 대한 액세스를 제어하여 버킷에서 객체를 생성, 삭제 및 나열할 수 있는 사람을 결정할 수 있습니다. 또한 Amazon S3가 버킷과 해당 콘텐츠를 저장할 지리적 리전을 선택하고 버킷 및 해당 객체에 대한 액세스 로그를 볼 수 있습니다.
기본적으로 S3 객체는 버킷을 다른 계정이 소유하고 있더라도 이를 업로드한 AWS 계정이 소유합니다. 객체에 대한 전체 액세스 권한을 얻으려면 객체 소유자가 버킷 소유자 액세스 권한을 명시적으로 부여해야 합니다. 버킷 소유자가 객체에 대한 전체 액세스 권한을 가질 수 있도록 객체를 업로드할 때 외부 사용자에게 버킷 소유자 전체 제어 권한을 부여하도록 버킷 정책을 생성할 수 있습니다.
사용자가 버킷에 객체를 업로드할 때 bucket-owner-full-control 액세스 제어 목록(ACL)을 포함하도록 요구하는 버킷 정책을 추가합니다.
AWS에서 안전한 애플리케이션 환경을 갖추어야 하는 회사의 기술 요구 사항이 있습니다. KMS를 사용할지 CloudHSM을 사용할지 결정하려고 합니다.
다음 중 CloudHSM 및 KMS에 대한 설명으로 옳은 것은?
독점적인 관리 아래에서 타사의 검증된 전용 하드웨어 보안 모듈에 키를 저장해야 하는 경우 AWS KMS를 통한 AWS CloudHSM 사용을 고려해야 합니다.
AWS Key Management Service(AWS KMS)는 데이터를 암호화하는 데 사용되는 암호화 키를 쉽게 생성하고 제어할 수 있는 관리형 서비스입니다. AWS KMS에서 생성하는 마스터 키는 FIPS 140-2 검증 암호화 모듈로 보호됩니다. AWS KMS는 사용자가 관리하는 암호화 키로 데이터를 암호화하는 대부분의 다른 AWS 서비스와 통합됩니다. 또한 AWS KMS는 AWS CloudTrail과 통합되어 감사, 규제 및 규정 준수 요구 사항을 충족하는 데 도움이 되는 암호화 키 사용 로그를 제공합니다.
AWS KMS를 사용하면 암호화한 데이터에 대한 액세스를 더 잘 제어할 수 있습니다. 애플리케이션에서 직접 또는 AWS KMS와 통합된 AWS 서비스를 통해 키 관리 및 암호화 기능을 사용할 수 있습니다. AWS용 애플리케이션을 작성하든 AWS 서비스를 사용하든 AWS KMS를 사용하면 누가 고객 마스터 키를 사용하고 암호화된 데이터에 액세스할 수 있는지 제어할 수 있습니다. AWS KMS는 사용자가 지정한 Amazon S3 버킷으로 로그 파일을 전달하는 서비스인 AWS CloudTrail과 통합됩니다. CloudTrail을 사용하면 마스터 키가 누가 언제 어떻게 사용되었는지 모니터링하고 조사할 수 있습니다.
암호화 키 생성 및 제어를 위한 관리형 서비스를 원하지만 자체 HSM을 운영하고 싶지 않거나 운영할 필요가 없다면 AWS Key Management Service 사용을 고려합니다.
새로운 회사 정책에 따라 IAM 사용자는 암호의 최소 길이를 12자로 변경해야 합니다. 무작위 검사 후 정책을 따르지 않는 직원이 여전히 있음을 발견했습니다.
계정에 대한 현재 암호 정책이 회사 암호 정책을 준수하는지 여부를 자동으로 어떻게 확인하고 평가할 수 있습니까?
사용자 암호의 규정 준수를 주기적으로 확인하는 평가를 트리거하도록 AWS Config를 구성합니다.
AWS Config는 AWS 리소스 구성을 측정, 감사 및 평가할 수 있는 서비스입니다. Config는 AWS 리소스 구성을 지속적으로 모니터링 및 기록하고, 원하는 구성을 기준으로 기록된 구성을 자동으로 평가해 줍니다. Config를 사용하면 AWS 리소스 간 구성 및 관계 변화를 검토하고, 자세한 리소스 구성 기록을 분석하고, 내부 지침에 지정되어 있는 구성을 기준으로 전반적인 규정 준수 여부를 확인할 수 있습니다. 이에 따라 규정 준수 감사, 보안 분석, 변경 관리 및 운영 문제 해결 작업을 간소화할 수 있습니다.
주어진 시나리오에서 AWS Config를 활용하여 계정의 IAM_PASSWORD_POLICY를 확인하도록 Config 규칙을 구성하여 암호 정책의 규정 준수를 확인할 수 있습니다. 또한 Config가 AWS Organizations와 통합되기 때문에 계정 간의 규정 준수 정보를 중앙 대시보드로 집계하도록 설정을 개선할 수 있습니다.
회사에는 AWS에 저장해야 하는 10TB의 자주 액세스하지 않는 재무 데이터 파일이 있습니다. 이러한 데이터는 감사 목적으로 검색되는 특정 주 동안 드물게 액세스됩니다. 검색 시간은 24시간을 넘지 않는 한 엄격하지 않습니다.
다음 중 이 시나리오에 대한 안전하고 내구성 있고 비용 효율적인 솔루션은 무엇입니까?
데이터를 S3에 업로드하고 수명 주기 정책을 설정하여 0일 후에 데이터를 Glacie로 전환합니다.
S3 Glacier Flexible Retrieval (이전의 S3 Glacier)스토리지 클래스는 연간 1~2회 액세스하고 비동기식으로 검색되는 아카이브 데이터에 대해 S3 Glacier Instant Retrieval보다 최대 10% 더 저렴한 비용으로 스토리지를 제공하며, 무료 대량 검색을 지원합니다. S3 Glacier Flexible Retrieval(이전 S3 Glacier)은 즉각적인 액세스가 필요하지 않지만 백업 또는 재해 복구 사용 사례와 같이 대규모 데이터 집합을 무료로 검색할 수 있는 유연성이 필요한 아카이브 데이터에 이상적인 스토리지 클래스입니다. S3 Glacier Flexible Retrieval은 몇 분 정도에서 몇 시간까지 다양한 액세스 시간에서 비용의 균형을 조정하는 가장 유연한 검색 옵션과 무료 대량 검색 기능을 제공합니다. 이는 가끔 몇 분 안에 일부 데이터를 검색해야 하고 비용에 대해 걱정하고 싶지 않은 경우, 그리고 백업, 재해 복구, 오프사이트 데이터 스토리지 요구 사항에 대해 적합한 솔루션입니다. S3 Glacier Flexible Retrieval은 특정 연도에 물리적으로 분리된 여러 AWS 가용 영역에서 데이터를 중복 저장하여 99.999999999%의 데이터 내구성과 99.99%의 가용성을 지원하도록 설계되었습니다.
S3 Glacier Flexible Retrieval(이전 S3 Glacier)은 즉각적인 액세스가 필요하지 않지만 백업 또는 재해 복구 사용 사례와 같이 대규모 데이터 집합을 무료로 검색할 수 있는 유연성이 필요한 아카이브 데이터에 이상적인 스토리지 클래스입니다. S3 Glacier Flexible Retrieval은 몇 분 정도에서 몇 시간까지 다양한 액세스 시간에서 비용의 균형을 조정하는 가장 유연한 검색 옵션과 무료 대량 검색 기능을 제공합니다. 이는 가끔 몇 분 안에 일부 데이터를 검색해야 하고 데이터 검색 비용에 대해 걱정하고 싶지 않은 경우, 그리고 백업, 재해 복구, 오프사이트 데이터 스토리지 요구 사항에 대해 적합한 솔루션입니다.
검색 작업을 처리할 때 Amazon S3는 요청된 데이터를 S3 Glacier Flexible Retrieval에서 먼저 검색한 다음, 요청된 데이터의 임시 사본을 Amazon S3에 생성합니다. 이 과정은 일반적으로 몇 분이 소요됩니다. 요청에 걸리는 액세스 시간은 선택한 검색 옵션(긴급, 표준 또는 대량 검색)에 따라 다릅니다. 긴급 검색을 사용하면 가장 큰 객체(250MB 이상)를 제외하고 모든 아카이브에서 보통 1~ 5분 이내에 데이터에 액세스할 수 있습니다. 표준 검색을 사용해 객체를 검색하면 보통 완료하는 데 3~5시간이 걸립니다. 대량 검색은 보통 5~12시간 이내에 완료되며, 무료입니다.
S3 Glacier 에 데이터를 저장하는 가장 쉬운 방법은 데이터를 직접 업로드하기 위하여 S3 API를 사용하는 것입니다. 스토리지 클래스로 “S3 Glacier”를 지정하기만 하면 됩니다. 이렇게 하려면 AWS Management Console, S3 REST API, AWS SDK 또는 AWS 명령줄 인터페이스(CLI)를 사용하면 됩니다.
또한 객체의 수명 주기를 정의하고 스토리지 비용을 줄일 수 있는 S3 수명 주기를 사용하여 데이터를 마이그레이션하는 정책을 생성함으로써 S3 Glacier 를 시작할 수도 있습니다. 이러한 정책은 객체의 사용 기간에 따라 객체를 S3 Glacier 로 마이그레이션하도록 설정할 수 있습니다. S3 버킷이나 특정 접두사에 대한 정책을 설정할 수 있습니다.
지정된 Amazon S3 객체가 Amazon Glacier로 전환되어야 하는 절대 또는 상대 기간(0일 포함)을 지정할 수 있습니다.
개발자는 AWS 계정 B의 Amazon S3 버킷에 액세스하는 AWS 계정 A의 Lambda 함수를 구현해야 합니다.
이 요구 사항을 충족하기 위해 다음 중 어느 것을 추천하시겠습니까?
S3 버킷에 대한 액세스 권한을 부여하는 Lambda 함수에 대한 IAM 역할을 생성합니다. IAM 역할을 Lambda 함수의 실행 역할로 설정합니다. 버킷 정책이 Lambda 함수의 실행 역할에 대한 액세스 권한도 부여하는지 확인합니다.
Lambda 함수에 대해 생성한 IAM 역할이 버킷과 동일한 AWS 계정에 있는 경우 IAM 역할과 버킷 정책 모두에 대해 Amazon S3 권한을 부여할 필요가 없습니다. 대신 IAM 역할에 대한 권한을 부여한 다음 버킷 정책이 Lambda 함수 역할에 대한 액세스를 명시적으로 거부하지 않는지 확인할 수 있습니다. IAM 역할과 버킷이 다른 계정에 있는 경우 IAM 역할과 버킷 정책 모두에 대해 Amazon S3 권한을 부여해야 합니다.
회사에서 애플리케이션을 AWS로 마이그레이션하는 중입니다. 그들의 시스템 중 하나에는 전역으로 확장할 수 있고 빈번한 스키마 변경을 처리할 수 있는 데이터베이스가 필요합니다. 그리고 데이터베이스에 스키마 변경이 있을 때마다 애플리케이션에 다운타임이나 성능 문제가 없어야 합니다. 또한 트래픽이 많은 쿼리에 대해 짧은 대기 시간 응답을 제공해야 합니다.
이 요구 사항을 달성하는 데 사용할 가장 적합한 데이터베이스 솔루션은 무엇입니까?
Amazon DynamoDB
스키마를 데이터베이스에 있는 데이터의 "구조" 또는 "모델"로 생각할 수 있습니다. 시나리오에서는 스키마 또는 데이터 구조가 자주 변경되어야 하므로 새로운 유형의 데이터를 추가하거나 제거하는 비경직적이고 유연한 방법을 제공하는 데이터베이스를 선택해야 합니다. 이것은 관계형 데이터베이스와 비관계형(NoSQL) 데이터베이스 사이에서 선택하는 전형적인 예입니다.
NoSQL 데이터베이스는 특정 데이터 모델에 대해 특정 목적에 맞추어 구축되는 데이터베이스로서 현대적인 애플리케이션 구축을 위한 유연한 스키마를 갖추고 있습니다. NoSQL 데이터베이스는 개발의 용이성, 기능성 및 확장성을 널리 인정받고 있습니다.
NoSQL 데이터베이스에서는 데이터의 액세스 및 관리를 위해 다양한 데이터 모델을 사용합니다. 이러한 데이터베이스 유형은 큰 테이터 볼륨, 짧은 지연 시간과 유연한 데이터 모델이 필요한 애플리케이션에 최적화되었으며, 이는 다른 데이터베이스의 데이터 일관성 제약 일부를 완화함으로써 이루어집니다.
NoSQL의 경우 테이블/컬렉션 항목에서 행이나 요소를 쉽게 추가하거나 제거할 수 있기 때문에 관계형 데이터베이스만큼 엄격하지 않습니다. 또한 관계형 데이터베이스와 달리 여러 관련 테이블을 변경할 필요가 없는 단일 항목 내에 복잡한 계층적 데이터를 저장할 수 있기 때문에 보다 유연한 스키마를 갖습니다. 따라서 여기에서 사용하는 가장 좋은 대답은 DynamoDB와 같은 NoSQL 데이터베이스입니다. 비즈니스에서 트래픽이 많은 쿼리에 대한 짧은 대기 시간 응답이 필요한 경우 일반적으로 NoSQL 시스템을 활용하는 것이 기술적, 경제적 의미가 있습니다.
Amazon DynamoDB는 모든 규모에서 고성능 애플리케이션을 실행하도록 설계된 완전관리형의 서버리스 키-값 NoSQL 데이터베이스입니다. DynamoDB는 기본 제공 보안, 지속적인 백업, 자동화된 다중 리전 복제, 인 메모리 캐시 및 데이터 가져오기/내보내기 도구를 제공합니다.
온라인 거래 시스템은 AWS에서 호스팅되며 EC2 인스턴스의 Auto Scaling 그룹, RDS 데이터베이스 및 Redis용 Amazon ElastiCache를 사용합니다. Redis 명령을 실행할 수 있는 권한이 부여되기 전에 사용자에게 암호를 입력하도록 요구하여 메모리 내 데이터 저장소의 데이터 보안을 개선해야 합니다.
위의 요구 사항을 충족하려면 다음 중 무엇을 해야 합니까?
--transit-encryption-enabled 및 --auth-token 매개변수가 모두 활성화된 새 Redis 클러스터를 생성하여 Redis AUTH를 사용하여 사용자를 인증합니다.
Redis AUTH 명령을 사용하면 암호로 보호된 Redis 서버에서 Redis 명령을 실행할 수 있는 권한이 부여되기 전에 사용자에게 암호를 입력하도록 요구하여 데이터 보안을 향상시킬 수 있습니다.
사용자가 암호로 보호된 Redis 서버에 암호를 입력하도록 요구하려면 복제 그룹 또는 클러스터를 생성할 때와 복제 그룹 또는 클러스터에 대한 모든 후속 명령에 올바른 암호와 함께 --auth-token 매개변수를 포함합니다.
회사는 매일 수십만 명의 클라이언트가 액세스하는 온라인 웹 포털의 웹 서비스에 API Gateway와 Lambda의 조합을 사용하고 있습니다. 회사는 신제품을 발표할 것이며 웹 포털은 전 세계적으로 엄청난 수의 방문자를 받을 것으로 예상됩니다.
트래픽 급증으로부터 백엔드 시스템과 애플리케이션을 어떻게 보호할 수 있습니까?
API Gateway에서 조절 제한 사용
amazon API Gateway는 어떤 규모에서든 개발자가 API를 손쉽게 게시, 유지 관리, 모니터링 및 보호할 수 있도록 지원하는 완전관리형 서비스입니다. AWS Management Console에서 몇 번의 클릭으로 애플리케이션이 백엔드 서비스(Amazon Elastic Compute Cloud(Amazon EC2), Amazon Elastic Container Service(Amazon ECS) 또는 AWS Elastic Beanstalk에서 실행되는 애플리케이션, AWS Lambda에서 실행되는 코드, 기타 웹 애플리케이션 등)의 데이터, 비즈니스 로직 또는 기능에 액세스할 수 있도록 "현관문" 역할을 하는 API를 생성할 수 있습니다. Amazon API Gateway는 트래픽 관리, 권한 부여 및 액세스 제어, 모니터링, API 버전 관리를 비롯해 최대 수십만 건의 동시 API 호출을 수락 및 처리하는 데 관련된 모든 작업을 처리합니다. Amazon API Gateway에는 최소 요금이나 시작 비용이 없습니다. HTTP API와 REST API의 경우 수신한 API 호출과 전송한 데이터 양에 대해서만 요금을 지불하면 됩니다. WebSocket API의 경우 전송하고 수신한 메시지와 사용자/디바이스가 WebSocket API에 연결한 시간에 대해서만 요금을 지불하면 됩니다.
Amazon API Gateway에서는 글로벌 또는 서비스 호출별을 비롯해 여러 수준에서 제한을 설정할 수 있으며, 표준 속도 및 버스트 속도에 대해 제한을 설정할 수 있습니다. 예를 들어, API 소유자가 REST API의 특정 메서드에 대해 초당 요청 1,000건으로 속도 제한을 설정하고 Amazon API Gateway에서 몇 초 동안 초당 요청 2,000건의 버스트를 처리하도록 구성할 수도 있습니다. Amazon API Gateway는 초당 요청 수를 추적합니다. 설정된 제한을 초과하는 요청은 429 HTTP 응답을 수신하게 됩니다. 이러한 응답이 수신되면 Amazon API Gateway에서 생성한 클라이언트 SDK(Javascript 제외)가 자동으로 호출을 재시도합니다.
제한은 백엔드 서비스가 성능 및 가용성을 유지할 수 있도록 API 트래픽을 제어하게 해줍니다.
회사에 여러 온디맨드 EC2 인스턴스에서 실행되는 Linux 서버 세트가 있습니다. 감사팀은 보고서를 위해 이러한 서버에서 생성된 애플리케이션 로그 파일을 수집하고 처리하려고 합니다.
이 경우 다음 중 어떤 서비스를 사용하는 것이 가장 좋을까요?
애플리케이션 로그 파일을 저장하기 위한 Amazon S3 및 로그 파일을 처리하기 위한 Amazon Elastic MapReduce
Amazon EMR은 AWS에서 Apache Hadoop 및 Apache Spark와 같은 빅 데이터 프레임워크 실행을 간소화하여 방대한 양의 데이터를 처리하고 분석하는 관리형 클러스터 플랫폼입니다. 이러한 프레임워크와 Apache Hive 및 Apache Pig와 같은 관련 오픈 소스 프로젝트를 사용하여 분석 목적 및 비즈니스 인텔리전스 워크로드를 위한 데이터를 처리할 수 있습니다. 또한 Amazon EMR을 사용하여 Amazon Simple Storage Service(Amazon S3) 및 Amazon DynamoDB와 같은 다른 AWS 데이터 스토어 및 데이터베이스 안팎으로 대량의 데이터를 변환하고 이동할 수 있습니다.
게임 회사는 확장 가능하고 가용성이 높아야 하는 서버를 보유하고 있습니다. 따라서 3개의 가용 영역(AZ)에 Auto Scaling 그룹(ASG)이 있는 Elastic Load Balancer(ELB)를 배포했습니다. 게임 토너먼트가 실행될 때 서버는 빠르게 확장되어야 합니다. 그리고 토너먼트가 끝나면 서버는 유휴 상태가 될 수 있습니다. 일반적으로 고가용성을 원하고 비용을 확장하고 최적화할 수 있는 능력을 갖기를 원합니다.
Auto Scaling의 추천 기능은 무엇인가요? (2개 선택)
최소 용량으로 예약 인스턴스 사용
최소 용량을 2로 설정
Auto Scaling 그룹에는 자동 조정 및 관리를 위한 논리적 그룹으로 취급되는 Amazon EC2 인스턴스 모음이 포함됩니다. Auto Scaling 그룹을 통해 상태 확인 교체 및 조정 정책과 같은 Amazon EC2 Auto Scaling 기능을 사용할 수도 있습니다. Auto Scaling 그룹의 인스턴스 수 유지와 자동 조정은 모두 Amazon EC2 Auto Scaling 서비스의 핵심 기능입니다.
최소, 최대, 원하는 용량을 설정하여 Auto Scaling 그룹의 크기를 구성합니다. Auto Scaling 그룹을 생성하려면 최소 및 최대 용량이 필요하며 원하는 용량은 선택 사항입니다. 원하는 용량을 미리 정의하지 않으면 기본적으로 최소 용량이 설정됩니다.
Auto Scaling 그룹은 최소 및 최대 용량 값이 다른 한 탄력적입니다. Auto Scaling 그룹의 원하는 용량 변경에 대한 모든 요청(수동 조정 또는 자동 조정)은 이러한 제한 내에 있어야 합니다.
여기서 ASG가 3개의 AZ에 배포되더라도 고가용성 최소 용량은 2입니다. 2를 최소 용량으로 지정하면 ASG는 별도의 AZ에 이 2개의 인스턴스를 생성합니다. 수요가 증가하면 ASG는 세 번째 AZ에서 새 인스턴스를 가동합니다. 나중에 수요가 줄어들면 ASG가 축소되고 인스턴스 수는 다시 2로 돌아갑니다.
예약 인스턴스를 사용하면 온디맨드 인스턴스 요금에 비해 Amazon EC2 비용을 크게 절감할 수 있습니다. 예약 인스턴스는 물리적 인스턴스가 아니라 계정에서 온디맨드 인스턴스 사용에 적용되는 결제 할인입니다. 이러한 온디맨드 인스턴스는 결제 할인 혜택을 받으려면 인스턴스 유형 및 리전과 같은 특정 속성과 일치해야 합니다. 최소 용량은 항상 유지되므로 다른 옵션보다 예약 인스턴스를 선택하는 것이 비용 효율적입니다.
AZ 중단의 경우 해당 AZ의 인스턴스가 중단되지만 다른 인스턴스는 계속 사용할 수 있습니다. ASG는 최소 개수를 2로 유지하기 위해 세 번째 AZ에서 교체 인스턴스를 프로비저닝합니다.
회사의 사진 공유 웹 사이트는 Amazon S3를 사용하여 웹 사이트 방문자에게 고품질 사진을 제공합니다. 며칠 후, 회사는 회사의 웹 사이트 사진을 연결하여 사용하는 다른 사진 공유 웹사이트가 있다는 것을 알게 되었습니다. 이로 인해 회사의 비즈니스에 재정적 손실이 발생했습니다.
이 문제를 완화하는 가장 효과적인 방법은 무엇입니까?
퍼블릭 읽기 액세스를 제거하고 만료 날짜가 있는 미리 서명된 URL을 사용하도록 S3 버킷을 구성합니다.
기본적으로 모든 S3 객체는 비공개입니다. 객체 소유자만 액세스할 수 있습니다. 그러나 객체 소유자는 필요할 경우 자신의 보안 자격 증명을 사용하여 일정 기간 동안 객체 다운로드를 허가하는 미리 서명된 URL을 만들어 다른 사용자와 객체를 공유할 수 있습니다.
객체에 대해 미리 서명된 URL을 만들 때 보안 자격 증명을 제공하고 버킷 이름, 객체 키, HTTP 메서드(GET으로 객체 다운로드) 및 만료 날짜와 시간을 지정해야 합니다. 사전 서명된 URL은 지정된 기간 동안만 유효합니다. 임시 토큰을 사용하여 미리 서명된 URL을 생성하면 이 URL이 토큰 만료보다 이후의 만료 시간으로 생성된 경우에도 토큰이 만료되면 이 URL도 만료됩니다.
미리 서명된 URL을 받은 사용자는 누구나 객체에 액세스할 수 있습니다. 예를 들어, 버킷에 동영상이 있고 버킷과 객체 모두 비공개인 경우 미리 서명된 URL을 만들어 다른 사용자와 동영상을 공유할 수 있습니다. 미리 서명된 URL은 URL을 아는 모든 사람에게 Amazon S3 버킷에 대한 액세스 권한을 부여하므로 적절하게 보호하는 것이 좋습니다.
운영팀에는 두 개의 사용자 지정 VPC 내 EC2 인스턴스에서 실행되는 애플리케이션이 있습니다. VPC는 각각 Seoul 및 Tokyo 리전에 있습니다. 팀은 퍼블릭 인터넷을 통과하지 않고 인스턴스 간에 데이터를 전송하려고 합니다.
어떤 단계의 조합으로 이를 달성할 수 있습니까? (2개 선택)
VPC 간에 VPC 피어링 연결을 설정합니다.
라우팅 테이블의 대상과 인스턴스 서브넷의 대상을 재구성합니다.
Virtual Private Cloud(VPC)는 사용자의 AWS 계정 전용 가상 네트워크입니다. VPC는 AWS 클라우드에서 다른 가상 네트워크와 논리적으로 분리되어 있습니다. AWS 리소스(예: Amazon EC2 인스턴스)를 VPC에서 시작할 수 있습니다.
VPC 피어링 연결은 프라이빗 IPv4 주소 또는 IPv6 주소를 사용하여 두 VPC 간에 트래픽을 라우팅할 수 있도록 하기 위한 두 VPC 사이의 네트워킹 연결입니다. 동일한 네트워크에 속하는 경우와 같이 VPC의 인스턴스가 서로 통신할 수 있습니다. 사용자의 자체 VPC 또는 다른 AWS 계정의 VPC와 VPC 피어링 연결을 만들 수 있습니다. VPC는 상이한 리전에 있을 수 있습니다(리전 간 VPC 피어링 연결이라고도 함).
리전 간 VPC 피어링은 리전 간에 리소스를 공유하거나 지리적 중복성을 위해 데이터를 복제할 수 있는 간단하고 비용 효율적인 방법을 제공합니다. 현재 VPC를 구동하는 기술과 동일한, 수평 확장되고 중복된 고가용성 기술을 기반으로 하는 리전 간 VPC 피어링은 단일 장애 지점이나 대역폭 병목 없이 리전 간 트래픽을 암호화합니다. 리전 간 VPC 피어링을 사용하는 트래픽은 전 세계 AWS 백본에 항상 머무르며 퍼블릭 인터넷을 통과하지 않으므로 일반적인 도용 및 DDoS 공격 같은 위협 벡터를 줄입니다.
회사는 객체가 Amazon S3 버킷에 업로드될 때마다 AWS Fargate를 사용하여 배치 작업을 실행하고 있습니다. 최소 ECS 작업 수는 비용을 절약하기 위해 처음에 1로 설정되며 S3 버킷에 업로드된 새 객체를 기반으로만 증가해야 합니다.
최소한의 노력으로 구현하기에 가장 적합한 옵션은 무엇입니까?
Amazon EventBridge 규칙을 설정하여 S3 객체 PUT 작업을 감지하고 대상을 ECS 클러스터로 설정하여 새 ECS 작업을 실행합니다.
Amazon EventBridge(이전의 CloudWatch Events) 는 이벤트를 관리하는 데 선호되는 방법입니다. CloudWatch Events와 EventBridge는 기본 서비스 및 API가 동일하지만 EventBridge가 더 많은 기능을 제공합니다. CloudWatch 또는 EventBridge에서 변경한 내용은 각 콘솔에 나타납니다.
Amazon EventBridge(이전의 CloudWatch Events)는 애플리케이션을 쉽게 연결할 수 있게 해주는 서버리스 이벤트 버스입니다. 자체 애플리케이션, 통합 SaaS(Software as a Service) 애플리케이션 및 AWS 서비스의 데이터를 사용합니다. 이는 이벤트 생산자와 이벤트 소비자를 분리하여 이벤트 기반 아키텍처를 구축하는 프로세스를 단순화합니다. 이를 통해 생산자와 소비자를 독립적으로 확장, 업데이트 및 배포할 수 있습니다. 느슨한 결합은 애플리케이션 탄력성 외에도 개발자의 민첩성을 향상시킵니다.
특정 AWS 이벤트가 발생할 때 Amazon EventBridge를 사용하여 Amazon ECS 작업을 실행할 수 있습니다. Amazon S3 PUT 작업을 사용하여 특정 Amazon S3 버킷에 파일을 업로드할 때마다 Amazon ECS 작업을 실행하는 EventBridge 규칙을 설정할 수 있습니다.
회사에서 Amazon EC2 인스턴스에 애플리케이션을 배포할 계획입니다. 애플리케이션은 다음 작업을 수행합니다.
- Amazon S3 버킷에서 대용량 데이터 세트를 읽습니다.
- 데이터 세트에 대한 다단계 분석을 실행합니다.
- 결과를 Amazon RDS에 저장합니다.
다단계 분석 중에 애플리케이션은 인스턴스 스토리지에 많은 수의 임시 파일을 저장합니다. Solutions Architect는 임시 파일에 대해 높은 I/O 성능과 함께 가장 빠른 스토리지 옵션을 권장해야 합니다.
다음 중 이 요구 사항을 충족하는 옵션은 무엇입니까?
여러 인스턴스 스토어 볼륨에서 RAID 0을 구성합니다.
인스턴스 스토어는 인스턴스에 블록 수준의 임시 스토리지를 제공합니다. 스토리지는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치합니다. 인스턴스 스토어는 버퍼, 캐시, scratch 데이터 및 기타 임시 콘텐츠와 같이 자주 변경되는 정보의 임시 스토리지나 로드가 분산된 웹 서버 풀과 같은 여러 인스턴스상에서 복제되는 데이터에 가장 적합합니다.
하나 이상의 인스턴스 스토어 볼륨으로 구성된 인스턴스 스토어는 블록 디바이스로 표시됩니다. 인스턴스 스토어의 크기는 물론 사용 가능한 디바이스의 수는 인스턴스 유형에 따라 다릅니다.
RAID 0 어레이를 생성하면 단일 Amazon EBS 볼륨에서 프로비저닝할 때보다 파일 시스템의 성능이 더 향상됩니다. I/O 성능이 무엇보다 중요할 경우 RAID 0를 사용하십시오. RAID 0를 사용할 경우 I/O가 스트라이프의 볼륨에 분산됩니다. 볼륨을 추가하면 처리량 및 IOPS도 그에 따라 바로 추가됩니다. 그러나 스트라이프의 성능은 세트에서 성능이 가장 낮은 볼륨의 성능으로 제한되며 세트에서 단일 볼륨이 손실되면 어레이의 데이터가 완전히 손실됩니다.
RAID 5 및 RAID 6는 이 RAID 모드의 패리티 쓰기 작업에서 볼륨에 사용 가능한 IOPS의 일부를 사용하기 때문에 Amazon EBS에 권장되지 않습니다. RAID 어레이의 구성에 따라 이러한 RAID 모드에서는 RAID 0 구성보다 20-30% 더 적은 가용 IOPS를 제공합니다. 이러한 RAID 모드는 비용 증가의 한 요인이기도 합니다. 볼륨 크기와 속도가 동일할 경우 2 볼륨 RAID 0 어레이가 두 배 더 비싼 4 볼륨 RAID 6 어레이보다 더 우수한 성능을 제공합니다.
또한 RAID 1은 Amazon EBS와 함께 사용하지 않는 것이 좋습니다. RAID 1의 경우 데이터를 동시에 여러 볼륨에 쓰기 때문에 비 RAID 구성에 비해 Amazon EC2와 Amazon EBS 사이에 더 큰 대역폭이 필요합니다. 또한 RAID 1은 쓰기 성능 향상 효과를 제공하지 않습니다.
회사에서 자주 액세스하지 않는 데이터에 사용할 데이터 웨어하우스가 필요한 애플리케이션을 출시할 계획입니다. 대규모의 순차적 I/O 작업을 처리할 수 있는 EBS 볼륨을 사용해야 합니다.
다음 중 요구 사항을 충족하기 위해 사용해야 하는 가장 비용 효율적인 스토리지 유형은 무엇입니까?
콜드 HDD(sc1)
Amazon EBS를 사용하면 스토리지 볼륨을 만들어 Amazon EC2 인스턴스에 연결할 수 있습니다. 볼륨을 연결한 후에는 해당 볼륨 위에 파일 시스템을 생성하거나, 데이터베이스를 실행하거나, 블록 스토리지를 사용하는 것과 같은 방식으로 사용할 수 있습니다. Amazon EBS 볼륨은 특정 가용 영역에 위치하며 여기에서 자동으로 복제되므로, 단일 구성 요소에 장애가 발생하더라도 안전하게 보호됩니다. 모든 EBS 볼륨 유형은 안정적인 스냅샷 기능을 제공하며 99.999%의 가용성을 제공하도록 설계되었습니다.
Amazon EBS는 워크로드에 대한 스토리지 성능과 비용을 최적화할 수 있는 다양한 옵션을 제공합니다. 이러한 옵션은 2개의 큰 카테고리로 나뉩니다. 데이터베이스 및 부트 볼륨과 같은 트랜잭션 워크로드를 위한 SSD 지원 스토리지(주로 IOPS가 성능을 좌우)와 MapReduce 및 로그 처리와 같은 처리량 집약적 워크로드를 위한 HDD 지원 스토리지(주로 초당 MB가 성능을 좌우)가 이에 해당합니다.
가장 뛰어난 성능을 자랑하는 io2 Block Express 볼륨은 클라우드에서 최초의 SAN을 지원합니다. Block Express는 고가의 온프레미스 SAN을 조달, 확장 및 유지 관리하는 수고와 비용을 들이지 않고도 가장 뛰어난 성능의 블록 스토리지를 제공하는 차세대 스토리지 서버 아키텍처입니다. Block Express에서 io2 볼륨을 실행하면 밀리초 이하의 대기 시간을 달성하고 최대 256,000 IOPS, 초당 4,000MB의 처리량 및 64TB의 용량을 지원하는 단일 io2 볼륨을 프로비저닝할 수 있습니다. 이 수치는 기존 io2 볼륨에 비해 성능, 처리량 및 용량 면에서 4배 더 높습니다. io2 Block Express 볼륨은 Oracle 데이터베이스, SAP HANA, Microsoft SQL Server, InterSystems 데이터베이스 및 SAS Analytics의 가장 크고 가장 I/O 집약적인 미션 크리티컬 배포에 적합합니다.
SSD 지원 볼륨은 대기 시간에 민감한 트랜잭션 워크로드를 위한 고성능의 프로비저닝된 IOPS SSD(io2와 io1)와 다양한 트랜잭션 데이터를 위해 가격과 성능의 균형을 맞춘 범용 SSD(gp3 및 gp2)를 포함합니다. HDD 지원 볼륨은 자주 액세스하고 처리량 집약적인 워크로드를 위한 처리량 최적화 HDD(st1)와 액세스 빈도가 낮은 데이터를 위한 최저비용 콜드 HDD(sc1)를 포함합니다.
Amazon EBS는 다음의 볼륨 유형을 제공하고 이러한 볼륨 유형은 성능 특성과 가격이 다르므로 애플리케이션의 필요에 맞게 스토리지 성능과 비용을 조정할 수 있습니다.
SSD(Solid-State Drive) — 주요 성능 특성이 IOPS인 작은 I/O 크기의 읽기/쓰기 작업을 자주 처리하는 트랜잭션 워크로드에 최적화되어 있습니다. SSD 지원 볼륨 유형에는 다음이 포함됩니다.
- 범용 SSD 볼륨
- Provisioned IOPS SSD 볼륨
HDD(Hard Disk Drive) — 주요 성능 특성이 처리량인 대규모 스트리밍 워크로드에 최적화되어 있습니다. HDD 지원 볼륨 유형에는 처리량 최적화 HDD 및 콜드 HDD 볼륨이 포함됩니다.
회사는 배송 트럭의 GPS 좌표를 추적하는 애플리케이션을 출시할 계획입니다. 좌표는 5초마다 각 배송 트럭에서 전송됩니다. 여러 소비자로부터 이러한 좌표를 실시간으로 처리할 수 있는 아키텍처를 설계해야 합니다. 집계된 데이터는 별도의 보고 애플리케이션에서 분석됩니다.
이 시나리오에서는 어떤 AWS 서비스를 사용해야 합니까?
Amazon Kinesis
Amazon Kinesis를 사용하면 실시간 스트리밍 데이터를 손쉽게 수집, 처리 및 분석할 수 있으므로 적시에 통찰력을 확보하고 새로운 정보에 신속하게 대응할 수 있습니다. Amazon Kinesis는 모든 규모의 스트리밍 데이터를 비용 효율적으로 처리할 수 있는 핵심 기능과 더불어 애플리케이션 요구 사항에 가장 적합한 도구를 선택할 수 있는 유연성을 제공합니다. Amazon Kinesis에서는 기계 학습, 분석 및 기타 애플리케이션을 위해 비디오, 오디오, 애플리케이션 로그, 웹 사이트 클릭스트림 및 IoT 텔레메트리 데이터와 같은 실시간 데이터를 수집할 수 있습니다. Amazon Kinesis를 사용하면 모든 데이터가 수집된 후에야 처리를 시작할 수 있는 것이 아니라 데이터가 수신되는 대로 처리 및 분석하여 즉시 대응할 수 있습니다.
이점
- 실시간
Amazon Kinesis를 사용하면 실시간으로 스트리밍 데이터를 수집, 버퍼링 및 처리할 수 있으므로 몇 시간 또는 며칠이 아니라 몇 초 또는 몇 분 만에 통찰력을 얻을 수 있습니다.
- 완전관리형
Amazon Kinesis는 완전관리형으로 스트리밍 애플리케이션을 운영하므로 사용자는 인프라를 관리할 필요가 없습니다.
- 확장성
Amazon Kinesis는 모든 규모의 스트리밍 데이터를 처리하고 매우 짧은 지연 시간으로 수많은 소스의 데이터를 처리할 수 있습니다.
회사는 현재 고객에게 SEO 분석을 자동으로 제공하는 개념 증명 프로젝트를 진행하고 있습니다. 회사에는 IPv4 및 IPv6 통신이 허용되는 이중 스택 모드에서 작동하는 AWS의 VPC가 있습니다. 수신 트래픽을 고르게 분산하는 Application Load Balancer가 앞에 있는 Auto Scaling EC2 인스턴스 그룹에 애플리케이션을 배포했습니다. 사용할 준비가 되었지만 도메인 이름(buildupworks.com)이 Application Load Balancer를 가리키도록 해야 합니다.
Route 53에서 Application Load Balancer의 DNS 이름을 가리키는 데 사용할 레코드 유형은 무엇입니까? (2개 선택)
유형 "AAAA" 레코드 집합의 별칭
유형 "A" 레코드 세트의 별칭
여러 Amazon EC2 인스턴스에서 하나의 웹 사이트를 호스팅하는 경우 Elastic Load Balancing(ELB) 로드 밸런서를 사용하여 웹 사이트에 대한 트래픽을 인스턴스 간에 분산할 수 있습니다. 웹 사이트에 대한 트래픽이 시간에 따라 변화하므로 ELB 서비스가 로드 밸런서를 자동으로 확장합니다. 또한 로드 밸런서를 통해 등록된 인스턴스의 상태를 모니터링하고 상태가 양호한 인스턴스로만 도메인 트래픽을 라우팅할 수 있습니다.
도메인 트래픽을 ELB 로드 밸런서로 라우팅하려면 Amazon Route 53을 사용하여 로드 밸런서를 지정하는 별칭 레코드(alias record)를 생성합니다. 별칭 레코드는 DNS에 대한 Route 53 확장입니다. 이는 루트 도메인(예: example.com)과 하위 도메인(예: www.example.com)에 대해 모두 별칭 레코드를 만들 수 있다는 점을 제외하고, CNAME 레코드와 유사합니다. (CNAME 레코드는 하위 도메인에 대해서만 생성할 수 있습니다.)
Elastic Load Balancer는 IPv6를 지원합니다.
웹 브라우저와 같은 클라이언트가 도메인 이름(example.com) 또는 하위 도메인 이름(www.example.com)에 대한 IP 주소를 요청할 때 클라이언트는 IPv4 주소(A 레코드), IPv6 주소(AAAA 레코드), 또는 IPv4 및 IPv6 주소(별도 요청의 경우 IPv4 먼저) 둘 다를 요청할 수 있습니다.
회사의 콘텐츠 부서에는 Amazon S3에서 각각 약 10MB 크기의 많은 수의 파일을 생성하는 애플리케이션이 있습니다. 회사는 파일을 삭제하기 전에 5년 동안 보관할 것을 요구합니다. 파일은 객체 생성 후 처음 30일 동안 자주 액세스되지만 처음 30일 후에는 거의 액세스되지 않습니다. 파일에는 재생산이 쉽지 않은 중요한 비즈니스 데이터가 포함되어 있으므로 즉각적인 액세스가 항상 필요합니다.
주어진 사례에 가장 비용 효율적인 솔루션은 무엇입니까?
객체 생성 후 30일이 지나면 S3 Standard에서 S3 Standard-IA로 파일을 이동하도록 S3 버킷 수명 주기 정책을 설정합니다. 개체 생성 후 5년이 지나면 파일을 삭제합니다.
S3 Standard-IA 클래스는 액세스 빈도가 낮지만 필요할 때 빠른 액세스가 필요한 데이터를 위한 것입니다. S3 Standard-IA는 S3 Standard의 높은 내구성, 높은 처리량 및 짧은 대기 시간을 제공하며 GB당 스토리지 가격과 GB당 검색 요금이 낮습니다.
주어진 사례에 대해 S3 수명 주기 구성을 설정하고 객체 생성 후 30일 후에 객체를 S3 Standard에서 S3 Standard-IA로 이동하는 전환 작업을 생성할 수 있습니다. 객체 생성 후 5년이 지나면 객체를 삭제하도록 만료 작업을 설정할 수 있습니다.
회사는 Application Load Balancer 뒤의 EC2 인스턴스에서 실행되는 다중 계층 애플리케이션을 관리합니다. 인스턴스는 여러 가용 영역에 걸쳐 EC2 Auto Scaling 그룹에서 실행되며 Amazon Aurora 데이터베이스를 사용합니다. Solutions Architect는 요청 속도의 주기적인 급증에 대해 애플리케이션을 보다 탄력적으로 만들라는 임무를 받았습니다.
다음 중 주어진 사용 사례에 권장하는 솔루션은 무엇입니까? (2개 선택)
Application Load Balancer 앞에서 CloudFront 배포 사용
Aurora 복제본 사용
Aurora 복제본과 CloudFront 배포를 사용하여 요청 속도 급증에 대한 애플리케이션의 복원력을 높일 수 있습니다.
Aurora 복제본에는 두 가지 주요 목적이 있습니다. 쿼리를 실행하여 애플리케이션에 대한 읽기 작업을 확장할 수 있습니다. 일반적으로 클러스터의 리더 엔드포인트에 연결하여 이를 수행합니다. 그런 식으로 Aurora는 클러스터에 있는 만큼의 Aurora 복제본에 읽기 전용 연결에 대한 로드를 분산할 수 있습니다. Aurora 복제본은 가용성을 높이는 데도 도움이 됩니다. 클러스터의 라이터 인스턴스를 사용할 수 없게 되면 Aurora는 리더 인스턴스 중 하나를 자동으로 승격하여 새 라이터 역할을 대신합니다. 최대 15개의 Aurora 복제본을 AWS 리전 내에서 DB 클러스터가 걸쳐 있는 가용 영역에 배포할 수 있습니다.
Amazon CloudFront는 개발자 친화적인 환경 내에서 짧은 지연 시간, 높은 전송 속도로 전 세계 고객에게 데이터, 비디오, 애플리케이션 및 API를 안전하게 제공하는 빠른 CDN(콘텐츠 전송 네트워크) 서비스입니다. CloudFront 접속 지점(POP)(에지 로케이션)은 인기 있는 콘텐츠가 시청자에게 빠르게 제공될 수 있도록 합니다. 또한 CloudFront에는 콘텐츠가 POP에 머물 만큼 인기가 없는 경우에도 시청자에게 더 많은 콘텐츠를 제공하여 해당 콘텐츠의 성능을 개선하는 데 도움이 되는 리전 엣지 캐시가 있습니다.
CloudFront는 데이터 복원력 요구 사항을 지원하는 데 도움이 되는 오리진 장애 조치 기능을 제공합니다. CloudFront는 엣지 로케이션 또는 접속 지점(POP)이라고 하는 전 세계 데이터 센터 네트워크를 통해 콘텐츠를 제공하는 글로벌 서비스입니다. 콘텐츠가 엣지 로케이션에 아직 캐시되지 않은 경우 CloudFront는 콘텐츠의 최종 버전에 대한 소스로 식별한 오리진에서 콘텐츠를 검색합니다.
