[Associate SAA-C03] - dump 정리 441 ~ 470
441
다중 계층 웹 애플리케이션 호스팅 + ASG + 최종 사용자가 대량의 정적 웹 콘텐츠에 액세스 할 때 ASG가 더 많은 주문형 인스턴스를 시작한다는 것 관찰 → 비용을 최적화
C. Amazon S3 버킷의 정적 웹 콘텐츠를 호스팅하기 위해 Amazon CloudFront 배포를 생성합니다.
⇒ 정적 컨텐츠 → S3 저장 → CloudFront의 CDN 사용 → EC2 인스턴스 부하 감소(성능 향상, 비용 감소)
442
여러 AWS 계정에 걸쳐 수 페타바이트의 데이터 저장 + Lake Formation을 사용하여 데이터 레이크 관리 → 분석 목적으로 해당 계정의 선택적 데이터를 회사의 엔지니어링 팀과 안전하게 공유 + 최소한의 운영 오버헤드
D. Lake Formation 태그 기반 액세스 제어를 사용하여 엔지니어링 팀 계정에 필요한 데이터에 대한 교차 계정 권한을 승인하고 부여합니다.
* Lake Formation: 분석 및 기계 학습을 위한 데이터를 중앙에서 관리하고 보호, 전 세계적으로 공유
* Lake Formation 태그 기반 액세스 제어: 태그와 태그 기반 정책을 정의하여 계정에 필요한 데이터에 대한 선택적 액세스 부여 가능 → 전체 액세스 권한X, 세부적인 액세스 권한 가능
443
전 세계 여러 지역의 사용자가 액세스 + 기가바이트 크기의 데이터 업로드 및 다운로드 지연 시간 최소화
A. Amazon S3를 Transfer Acceleration과 함께 사용하여 애플리케이션을 호스팅합니다.
* S3 Transfer Acceleration: 대규모 파일을 글로벌하게 전송 할 때 전송 속도를 향상 시키기 위한 기능. 먼 거리에서 업로드 및 다운로드에 유용. 최적화 경로를 사용해 더 빠르게 전송.
→ 업로드 및 다운로드 지연을 최소화하고 성능을 극대화하기 위한 비용 효율적인 솔루션
444
RDS DB 인스턴스 하나와 웹 서버를 실행하는 수동으로 프로비저닝된 EC2 인스턴스 2개로 구성 + 단일 AZ → 최근에 DB 인스턴스 삭제 → 24시간 동안 사용 불가 → 전반적인 안정성에 대해 우려 → 안정성을 극대화
B. DB 인스턴스를 Multi-AZ로 업데이트하고 삭제 보호를 활성화합니다. EC2 인스턴스를 Application Load Balancer 뒤에 배치하고 여러 가용성 영역에 걸쳐 EC2 자동 확장 그룹에서 실행합니다.
⇒ RDS Multi-AZ + 삭제 보호 기능: 데이터베이스에 높은 가용성 제공
⇒ AZ 간의 로드 밸런서와 Auto Scailing Group: EC2에 높은 가용성 제공
445
데이터 센터의 대규모 네트워크 연결 스토리지 시스템에 700테라바이트의 데이터 저장 + 10Gbps AWS Direct Connect 연결이 있는 하이브리드 환경 → 회사의 90일 내에 데이터를 클라우드로 이전 → 데이터를 효율적이고 중단 없이 이전 → 이전 기간 동안 데이터에 액세스하고 업데이트 할 수 있어야함
A. 기업 데이터 센터에서 AWS DataSync 에이전트를 만듭니다. 데이터 전송 작업을 만듭니다. Amazon S3 버킷으로 전송을 시작합니다.
* AWS DataSync: 대규모 데이터 전송 서비스. 네트워크 연결 스토리지에서 S3로 데이터 전송에 최적화. 하이브리드 환경에서 실시간 동기화 지원.
* rsync: 데이터를 복사하는 데 사용할 수 있는 도구
* 테이프: 저비용 대량 데이터 저장소이지만 속도가 느리고 실시간 사용에는 부적합.
⇒ AWS DataSync: Direct Connect를 통해 온프레미스에서 AWS 환경으로 대용량 데이터 세트 효율적으로 전송 가능 + 전송 프로세스 중에 데이터에 지속적으로 액세스하고 업데이트 가능
446
S3 버킷에 PDF 형식으로 데이터 저장 → 모든 새 데이터와 기존 데이터를 7년 동안 S3에 보관해야하는 법적 요구 사항 + 최소한의 운영 오버헤드
D. S3 버킷에 대한 규정 준수 보관 모드로 S3 객체 잠금을 켭니다. 보관 기간을 7년 후 만료되도록 설정합니다. S3 일괄 작업을 사용하여 기존 데이터를 규정 준수 상태로 만듭니다.
* 규정 준수 모드: 보존 기간 동안 관리자를 포함 누구도 수정, 삭제 불가능.
* 거버넌스 모드: 관리자는 수정, 삭제 가능.
* S3 Batch Operations(일괄 작업): 대규모 객체에 대해 일괄 작업 수행. 단일 작업 요청으로 반복 작업 자동화.
법적 요구 사항 → 규정 준수 모드 사용 , 거버넌스(예외 존재하므로 X)
S3 배치(일괄) 작업 수행 → 기존 객체의 보존 기간 설정
447
API Gateway에서 호출하는 Lambda 함수에서 실행되는 상태 없는 웹 애플리케이션 → 여러 AWS 지역에 애플리케이션을 배포하여 지역 장애 조치 기능을 제공 → 여러 지역으로 트래픽을 라우팅
* 상태 없는 웹 애플리케이션: 서버가 클라이언트의 요청에 대한 상태를 저장하지 않는 애플리케이션.
A. 각 지역에 대한 Amazon Route 53 상태 검사를 만듭니다. 액티브-액티브 장애 조치 구성을 사용합니다.
* CloudFront: 라우팅 트래픽에 대한 상태 검사 지원 x , CDN 서비스 및 캐싱을 위해 설계
* Route 53: AWS의 DNS 웹 서비스로, 다양한 지역으로 트래픽을 분산하거나 장애 발생 시 자동으로 장애 조치를 수행
* 상태 검사(Health Check): 각 지역의 API Gateway에 대한 상태 검사를 설정하면, 특정 지역의 문제가 발생할 경우 Route 53이 자동으로 다른 지역으로 트래픽을 라우팅
* 액티브-액티브 장애 조치: 다중 가용성 구성. 서비스 중단이 없음. Amazon Route 53 를 사용해 상태 검사(Health Check)를 설정하여 모니터링 가능. 트래픽을 여러 AWS 지역으로 분산
448
Management VPC는 고객 게이트웨이(CGW)를 통해 VPN을 사용하여 데이터 센터의 단일 장치에 연결
Production VPC는 두 개의 Direct Connect 연결이 연결된 가상사설 게이트웨이를 사용
→ Management 와 Production 는 모두 단일 VPC 피어링 연결을 사용하여 통신 허용 → 단일 장애 지점 완화 솔루션
* 단일 장애 지점: 한 곳에 의존하고 있어서 고장나면 전부다 영향을 미치는 상황.
ex. vpc 통신이 오직 하나의 vpn에 의존하면 vpn 연결이 중단 시 vpc 통신이 끊어져버림. 그 장치(연결)이 단일 장애지점.
C. 두 번째 고객 게이트웨이 장치에서 관리 VPC에 두 번째 VPN 세트를 추가합니다.
하나의 고객 게이트웨이 장치를 통한 단일 VPN 연결 ⇒ 단일 장애점 ⇒ VPN 연결을 이중화하여 해결.
2개의 CGW 사용 → 단일 장애 지점 완화하려면 나머지 1개의 CGW 이용해서 VPN 연결하여 중복성 제공.
449
Oracle 데이터베이스 + 권한 있는 액세스가 필요한 타사 데이터베이스 기능 사용. 가장 비용 효율적으로 마이그레이션 하는 방법.
B. 데이터베이스를 Amazon RDS Custom for Oracle로 마이그레이션합니다. 타사 기능을 지원하도록 데이터베이스 설정을 사용자 지정합니다.
* Amazon RDS Custom for Oracle: 특별한 패치를 적용하고 DB SW 설정을 변경함으로써 액세스에 권한이 필요한 타사 애플리케이션 지원 하는 등 DB 서버 호스트 및 OS에 액세스하고 사용자 지정 가능
450
단일 서버에 있는 3계층 웹 애플리케이션 + AWS로 마이그레이션 + Well-Architected Framework와 일치하고 , 보안, 확장성 및 복원성을 위한 권장 모범사례와 일관되기를 원함
C. 두 개의 가용성 영역에 걸쳐 VPC를 만듭니다. 웹 계층, 애플리케이션 계층 및 데이터베이스 계층을 호스팅하도록 애플리케이션을 리팩토링합니다. 웹 계층 및 애플리케이션 계층에 대한 자동 확장 그룹이 있는 자체 프라이빗 서브넷에서 각 계층을 호스팅합니다.
E. 웹 계층 앞에 Elastic Load Balancer를 사용합니다. 각 계층의 보안 그룹에 대한 참조를 포함하는 보안 그룹을 사용하여 액세스를 제어합니다.
F. 프라이빗 서브넷에서 Amazon RDS 데이터베이스 Multi-AZ 클러스터 배포를 사용합니다. 애플리케이션 계층 보안 그룹에서만 데이터베이스 액세스를 허용합니다.
451
온프레미스 애플리케이션과 데이터베이스를 AWS클라우드로 이전. ECS, RDS 사용하고자 함.
회사의 운영팀에서 관리되는 부분 3가지
- 고객 책임
⇒ 고객의 책임을 묻는 문제
B. Amazon RDS DB 인스턴스 생성 및 예약된 유지 관리 창 구성
C. 모니터링, 패치 관리, 로그 관리 및 호스트 침입 탐지를 위한 Amazon ECS의 추가 소프트웨어 구성 요소 구성
F. Direct Connect를 통해 전송되는 데이터의 암호화
- 고객 책임: 클라우드에서 실행되는 애플리케이션, 데이터의 보안과 관리.
암호화, 사용자 접근 관리, 설정 및 구성, 운영체제 및 데이터베이스 관리, 모니터링.
⇒ 액세스 관련, OS 선택, 구성 및 패치 적용하는 단계, 보안 그룹 구성하는 단계, 사용자 계정 관리 단계
- AWS 책임
- AWS 책임: 클라우드 인프라의 보안과 안정성 관리. 물리적 보안
A. RDS 인프라 계층, 운영 체제 및 플랫폼 관리
D. RDS의 모든 마이너 및 메이저 데이터베이스 버전에 대한 패치 설치
E. 데이터 센터의 RDS 인프라의 물리적 보안
452
EC2 인스턴스에서 JAVA 기반 작업 실행 → 매 시간 실행, 실행 시간 10초 + 예약된 간격으로 실행 + 인스턴스의 CPU 사용률은 작업이 사용 가능한 최대 CPU를 사용하는 짧은 서지를 제외하고는 낮음 → 작업을 실행하는데 드는 비용 최적화
B. 메모리가 1GB인 AWS Lambda 함수에 코드를 복사합니다. 매 시간 코드를 실행하기 위한 Amazon EventBridge 예약 규칙을 만듭니다.
10초 실행, 비용 최적화, 1GB 메모리 소모 ⇒ AWS Lambda
* AWS App2Container(A2C): JAVA 및 .NET 웹 애플리케이션을 컨테이너 형식으로 마이그레이션하고 현대화하는 명령줄 도구
453
보존 기간 동안 파일을 변경해서는 안됨
D. AWS Backup을 사용하여 규정 준수 모드에서 볼트 잠금이 있는 백업 볼트를 만듭니다. 필요한 백업 계획을 만듭니다.
* 볼트 잠금: 지정 기간 동안 버킷의 객체를 삭제, 수정 x. 법적 규제 준수.
규정 준수 모드
거버넌스는 예외 존재하므로 x
454
회사는 여러 AWS 지역과 계정에 리소스를 보유 + 이전 직원이 리소스 인벤토리에 대한 세부 정보를 제공하지 않았다는 것을 발견 → 모든 계정에서 다양한 워크로드의 관계 세부 정보를 구축하고 매핑해야함 + 가장 운영적으로 효율적인 방식
C. AWS에서 Workload Discovery를 사용하여 워크로드의 아키텍처 다이어그램을 생성합니다.
* AWS Workload Discovery: AWS 클라우드 워크로드를 시각화하는 도구(워크로드의 세부 아키텍처 다이어그램 자동 구축)
* AWS Systems Manager: 인스턴스 수와 인스턴스에 설치된 sw에 대한 정보 수집
* AWS X-Ray: 애플리케이션으로 보낸 요청에 대한 엔드 투 엔드 교차 서비스 뷰 제공, 애플리케이션을 통과하는 요청에 대한 애플리케이션 중심의 뷰 제공
* AWS Step Functions: 워크플로를 시각적으로 구성하고 조정. 수동으로 작성.
455
회사 Organizations 사용 + 다른 예산으로 일부 AWS 계정을 운영하고자 함 → 특정 기간 동안 할당된 예산 임계값에 도달하면 알림을 받고 AWS 계정에서 추가 리소스의 프로비저닝을 자동으로 방지하고자함
B. AWS Budgets를 사용하여 예산을 만듭니다. 필요한 AWS 계정의 Billing 대시보드에서 예산 금액을 설정합니다.
D. AWS Budgets에서 필요한 권한으로 예산 작업을 실행할 수 있는 IAM 역할을 생성합니다.
F. 각 계정이 예산 임계값에 도달하면 회사에 알리는 알림을 추가합니다. 적절한 서비스 제어 정책(SCP)으로 생성된 IAM ID를 선택하여 추가 리소스의 프로비저닝을 방지하는 예산 작업을 추가합니다.
→ Organization이므로 SCP 사용
* Billing 대시보드: 예산 생성 + 예산 설정
* Budgets에 대한 IAM 사용자: 특정 사람이나 서비스 계정에만 직접 권한 부여
* Budgets에 대한 IAM 역할: 다양한 서비스나 사용자가 해당 역할을 가정하여 필요한 작업 수행 가능
456
한 AWS 리전의 EC2 인스턴스에서 애플리케이션 실행 + EC2 인스턴스를 두 번째 리전에 백업하려고함 → 두 번째 리전에서 EC2 리소스를 프로비저닝하고 한 AWS계정에서 EC2 인스턴스를 중앙에서 관리하려고 함 + 가장 비용 효율적
C. AWS Backup을 사용하여 백업 계획을 만듭니다. EC2 인스턴스에 대해 두 번째 Region에 대한 크로스 리전 백업을 구성합니다.
* AWS Backup 사용: EC2 인스턴스의 백업 프로세스 자동화하는 백업 계획 생성 가능 , 지역 간 백업 구성 시 백업이 두 번째 지역에 복제되어 재해 복구 기능 제공 + aws 서비스 및 하이브리드 워크로드 전반의 데이터 보호를 중앙 집중화하고 자동화하는 완전관리형 서비스
457
회사가 제품 제조업체로 데이터를 전송하는 애플리케이션 구축 + 자체 ID 공급자(IdP) 존재 → 사용자가 애플리케이션을 사용하여 데이터를 전송하는 동안 IdP가 애플리케이션 사용자를 인증하기를 원함 + Applicability Statement 2(AS2) 프로토콜을 사용해야함
C. AWS Transfer Family를 사용하여 데이터를 전송합니다. IdP 인증을 위한 AWS Lambda 함수를 만듭니다.
* AWS Transfer Family: SFTP, AS2, FTPS, FTP를 통해 S3 또는 EFS에서 직접 파일을 주고 받을 수 있는 서비스
458
현금 환급 서비스를 위해 API Gateway에서 RESTAPI 설계 → 계산 리소스에 1GB의 메모리와 2GB의 스토리지 필요 + 데이터는 관계형 형식 + 최소한의 관리 노력
B. AWS 람다
C. 아마존 RDS
관계형 DB → RDS 선택 ↔ DynamoDB는 NoSQL
1GB의 메모리 → Lambda 사용 (최소한의 관리 노력)
459
회사가 Organizations를 사용하여 여러 AWS 계정 내에서 워크로드 실행 + 회사에서 태그를 만들 때 부서 태그를 AWS 리소스에 추가 + 회계 팀은 EC2 소비에 대한 지출을 결정 + AWS 계정과 상관없이 비용을 책임지는 부서를 결정해야함 → 회계팀은 조직 내 모든 AWS 계정에 대한 AWS Cost Explorer에 액세스할 수 있으며 Cost Explorer의 모든 보고서에 액세스해야함 + 가장 운영 효율적인 방식
A. 조직 관리 계정 청구 콘솔에서 department라는 사용자 정의 비용 할당 태그를 활성화합니다. Cost Explorer에서 태그 이름으로 그룹화하여 비용 보고서 하나를 만들고 EC2로 필터링합니다.
* AWS 정의 비용 할당 태그 예시: aws:createdBy (리소스를 생성한 IAM 사용자), aws:cloudformation:stack-name (CloudFormation 스택 이름)
* 사용자 정의 비용 할당 태그 예시: Department (부서 이름), Project (프로젝트 이름), Environment (개발/테스트/프로덕션 환경)
460
회사가 소프트웨어 서비스(SaaS)애플리케이션 Salesforce 계정과 S3 간에 데이터를 안전하게 교환하려고 함 + KMS 고객관리 키를 사용하여 저장 데이터를 암호화 해야함 + 전송 중인 데이터를 암호화 + Salesforce 계정에 대한 API 액세스를 활성화
C. Salesforce에서 Amazon S3로 데이터를 안전하게 전송하기 위해 Amazon AppFlow 흐름을 생성합니다.
* Amazon AppFlow:SaaS(Software-as-a-Service) 애플리케이션과 Amazon S3 및 Amazon Redshift와 같은 AWS 서비스 간에 데이터를 안전하게 전송할 수 있게 해 주는 완전관리형 통합 서비스 + 내장된 암호화 옵션, SSL/TLS 프로토콜을 사용하여 전송 중 암호화 지원
* Salesforce: 기업이 고객과의 관계를 관리하고 분석할 수 있도록 도와주는 플랫폼
461
모바일 게임 앱 개발 + 앱 데이터는 DynamoDB에 저장 + 앱은 TCP/UDP 트래픽 사용하여 통신 + 전 세계적으로 사용 + 모든 사용자에게 가능한 가장 낮은 지연 시간 보장
B. AWS Global Accelerator를 사용하여 가속기를 만듭니다. Global Accelerator 통합을 사용하고 TCP 및 UDP 포트에서 수신 대기하는 가속기 엔드포인트 뒤에 Network Load Balancer(NLB)를 만듭니다. Auto Scaling 그룹을 업데이트하여 NLB에 인스턴스를 등록합니다.
TCP/UDP ⇒ Global Accelerator + Network Load Balancer
NLB는 Cloudfront와 함께 사용할 수 없음.
462
고객 주문을 처리하는 애플리케이션 + EC2 인스턴스에서 애플리케이션을 호스팅하여 Aurora 데이터베이스에 주문 저장 → 트래픽이 많을 때 워크로드가 주문을 충분히 빨리 처리하지 못함 → 데이터베이스에 주문을 안정적으로 작성
B. Amazon Simple Queue Service(Amazon SQS) 대기열에 주문을 씁니다. Application Load Balancer 뒤의 Auto Scaling 그룹에서 EC2 인스턴스를 사용하여 SQS 대기열에서 읽고 주문을 데이터베이스로 처리합니다.
⇒ SQS 사용하여 쓰기 작업을 처리 작업에서 분리하면 EC2 인스턴스의 처리 용량에 관계없이 주문이 큐에 안정적으로 저장 + 대기열의 작업 부하에 따라 Auto Scailing Group 사용
463
사용자의 수면에 대한 데이터를 수집하는 센서가 있는 메트리스 출시 + 센서는 S3 버킷으로 데이터 전송 + 매일 밤 2MB의 데이터 수집 → 각 메트리스에 대한 데이터를 처리하고 요약 + 결과는 가능한 한 빨리 제공 + 데이터 처리에는 1GB의 메모리가 필요하며 30초 이내에 완료 + 가장 비용 효율적
C. Python 스크립트와 함께 AWS Lambda 사용
* AWS Lambda: 서버리스 컴퓨팅 서비스, 사용량만큼 비용, 약 2MB의 데이터를 처리하는 작업, 최대 10GB의 메모리를 사용할 수 있으며, 1GB의 메모리만 필요하므로 충분히 적합
* Apache Spark: 대규모 데이터 처리 분산 컴퓨팅 프레임워크. EMR, Glue의 클러스터에서 실행
464
모든 주문을 PostgreSQL Single-AZ DB 인스턴스용 RDS에 저장하는 온라인 쇼핑 애플리케이션 호스팅 + 단일 장애 지점을 제거하고자 하며 코드를 변경하지 않고도 데이터베이스 다운타임 최소화 솔루션
A. 데이터베이스 인스턴스를 수정하고 Multi-AZ 옵션을 지정하여 기존 데이터베이스 인스턴스를 Multi-AZ 배포로 변환합니다.
→ 단일 장애 지점 제거 ⇒ Multi-AZ 배포 사용(다른 AZ에 복제본을 유지함으로 가용성을 높이고 단일 장애 지점 제거)
Multi-AZ는 Standby 인스턴스로 자동 장애 조치를 제공
B. 새 RDS Multi-AZ 배포를 만듭니다. 현재 RDS 인스턴스의 스냅샷을 찍고 스냅샷으로 새 Multi-AZ 배포를 복원합니다.
→ RDS 인스턴스를 스냅샷으로 복원하면 데이터베이스를 새로 만드는 과정에서 연결이 끊길 수 있으며, 다운타임이 발생
465
고객 수요를 지원하기 위한 애플리케이션 + EC2 Nitro 기반 인스턴스의 여러 블록 스토리지 볼륨에 동시에 쓸 수 있는 기능을 제공하여 더 높은 애플리케이션 가용성 달성
C. Amazon Elastic Block Store(Amazon EBS) 다중 연결과 함께 프로비저닝된 IOPS SSD(io2) EBS 볼륨 사용
* SSD io2: 다중 연결 지원, 동일한 AZ 내에서 최대 16개의 Nitro 기반 EC2 인스턴스 간에 EBS 데이터 볼륨에 대한 액세스 공유 가능
HDD<gp2<gp3<io2
다중 연결은 Provisioned IOPS SSD(io1 및 io2) 볼륨에서만 지원
466
단일 가용성 영역에서 EC2 + RDS Multi-AZ DB 인스턴스를 사용하는 무상태 2계층 애플리케이션 설계 → 고가용성 보장
A. Multi-AZ EC2 자동 확장을 사용하도록 애플리케이션을 구성하고 애플리케이션 부하 분산 장치를 생성합니다.
높은 가용성 ⇒ Multi-AZ EC2 + ALB
467
Organizations 사용 + Compute Savings Plan 구매 → 멤버 계정 내 워크로드가 변경되어 더 이상 Compute Savings Plan 약정의 전체 혜택을 받지 못함 + 회사는 구매한 컴퓨팅 파워의 50%미만 사용
B. 회사 조직 관리 계정의 계정 콘솔에 있는 청구 기본 설정 섹션에서 할인 공유를 켭니다.
⇒ Compute Savings Plan 할인은 AWS Organizations 내에서 공유 가능 ⇒ 조직의 다른 계정들이 해당 할인을 사용할 수 있게 되어, 전체 조직 차원에서 구매한 Savings Plan의 혜택 활용 ⇒ Savings Plan의 혜택이 조직 내 다른 계정으로 자동으로 전파되어, 멤버 계정의 미사용 용량을 다른 계정에서 사용 가능
468
고객에게 검색 카탈로그를 제공하는 마이크로서비스 애플리케이션 개발 + REST API 사용하여 애플리케이션의 프런트엔드를 사용자에게 제공 → REST API는 회사가 프라이빗 VPC 서브넷의 컨테이너에서 호스팅하는 백엔드 서비스에 액세스 해야함
B. Amazon API Gateway를 사용하여 REST API를 설계합니다. 프라이빗 서브넷의 Amazon Elastic Container Service(Amazon ECS)에서 애플리케이션을 호스팅합니다. API Gateway가 Amazon ECS에 액세스할 수 있도록 프라이빗 VPC 링크를 만듭니다.
* WebSocket API: 양방향 통신을 필요로 하는 실시간 애플리케이션에 적합
⇒ 검색 카탈로그 제공과 같은 일반적인 요청-응답 패턴에는 REST API가 더 적합
* REST API용 VPC 링크: VPC 내부 리소스에 대한 액세스 제공→ 프라이빗한 연결 가능 + 보안 그룹을 만드는 것만으로는 API Gateway가 프라이빗 서브넷의 EC2 컨테이너에 접근 불가능
469
S3 저장 데이터. 예측하거나 제어할 수 없는 액세스 패턴. S3 비용을 줄이는 솔루션
C. S3 Lifecycle 규칙을 사용하여 S3 Standard에서 S3 Intelligent-Tiering으로 객체를 전환합니다.
* 예측 할 수 없는 패턴 ⇒ S3 Intelligent-Tiering
* S3 inventory ⇒ 파일을 다른 클래스로 이동할 수 없음
470
IPv6 주소가 있는 Amazon EC2 인스턴스에 호스팅된 애플리케이션 + 인터넷을 사용하여 다른 외부 애플리케이션과 통신 + 회사의 보안 정책에 따르면 외부 서비스는 EC2 인스턴스에 연결 x
→ 외부로 나가는 트래픽은 허용하고, 들어오는 연결은 차단하는 옵션 선택.
D. 이그레스 전용 인터넷 게이트웨이를 생성하고 이를 서브넷 경로 테이블의 목적지로 만듭니다.
* Egress-Only Internet Gateway 이그레스 전용 인터넷 게이트웨이: IPv6 주소를 가진 인스턴스가 인터넷에 연결. 인바운드 트래픽은 차단하고 아웃트래픽만 허용함.
인터넷 게이트웨이: IPv4, IPv6 인스턴스가 인터넷과 양방향 통신. 인바운드 트래픽도 허용. 외부 차단이 불가능.
NAT 게이트웨이: IPv4 전용. 프라이빗 서브넷 인스턴스가 인터넷에 접근 가능.
가상 사설 게이트웨이: 온프레미스 네트워크와 VPC를 연결.