531
회사는 타사 데이터 피드와 통합 + 새 데이터가 소비될 준비가 되면 외부 서비스에 알리기 위해 웹훅을 보냄 + 개발자는 회사가 웹훅 콜백을 받을 때 데이터를 검색하는 Lambda 함수 작성 → 개발자는 타사가 호출할 수 있도록 Lambda 함수를 제공 + 가장 높은 운영 효율성
A. Lambda 함수에 대한 함수 URL을 만듭니다. 웹훅을 위해 제3자에게 Lambda 함수 URL을 제공합니다.
* 웹훅: 데이터가 변경되었을 때 실시간으로 알림을 받을 수 있는 기능
* Lambda 함수 URL 사용 ⇒ HTTPS 엔드포인트에서 Lambda 함수를 호출할 수 있고 이를 통해 HTTP 클라이언트를 사용하여 AWS 외부의 애플리케이션에 함수를 노출 → 제 3자가 접근 가능
532
고객은 API Gateway REST API를 사용하여 워크로드에 연결하고 액세스 + 회사는 DNS 공급자로 Route 53을 사용 → 모든 고객에게 개별적이고 안전한 URL을 제공 + 가장 높은 운영 효율성
A. 레지스트리에 필요한 도메인을 등록합니다. Route 53 호스팅 존에 와일드카드 사용자 지정 도메인 이름을 만들고 API Gateway 엔드포인트를 가리키는 존에 기록합니다.
D. 동일한 지역의 AWS Certificate Manager(ACM)에서 사용자 지정 도메인 이름과 일치하는 와일드카드 인증서를 요청합니다.
F. REST API를 위한 API Gateway에서 사용자 지정 도메인 이름을 만듭니다. AWS Certificate Manager(ACM)에서 인증서를 가져옵니다.
와일드카드 사용자 지정 도메인 이름: 도메인 이름의 하위 도메인을 포괄적으로 포함하는 도메인 이름 + *.example.com이라는 와일드카드 도메인은 a.example.com, b.example.com, subdomain.example.com 등 모든 하위 도메인을 포함
533
S3에 데이터 저장 + 데이터는 개인 식별 정보(PII)를 포함해서는 안된다 + 최근 S3 버킷에 PII가 포함된 일부 객체가 있다는 사실을 발견 → S3 버킷에서 PII를 자동으로 감지하고 회사의 보안팀에 알려야함
A. Amazon Macie를 사용합니다. Macie 결과에서 SensitiveData 이벤트 유형을 필터링하고 Amazon Simple Notification Service(Amazon SNS) 알림을 보안 팀에 보내는 Amazon EventBridge 규칙을 만듭니다.
* 개인 식별 번호(PII) ⇒ Amazon Macie 사용
534
여러 AWS 계정에 대한 로깅 솔루션 + 모든 계정의 로그를 중앙 계정에 저장 + 중앙 계정에 S3 버킷을 만들어 VPC 흐름 로그와 CloudTrail 로그를 저장 → 모든 로그는 빈번한 분석을 위해 30일 동안 고가용성 , 백업 목적으로 60일 동안 추가 보관 , 생성 후 90일 후에 삭제 해야함 + 가장 비용 효율적
C. 생성 후 30일 후에 S3 Glacier Flexible Retrieval 스토리지 클래스로 객체를 전환합니다. Amazon S3가 90일 후에 객체를 삭제하도록 지시하는 만료 작업을 작성합니다.
30일 이후에는 백업만 가능 + 자주 액세스하지 않음 + 가장 비용 효율적
→ 30일 이후에 S3 Glacier Flexible Retrieval 스토리지로 전환
* S3 Glacier Flexible Retrieval 스토리지 : 장기 보관 데이터. 접근 빈도가 낮은 데이터. 거의 액세스하지 않지만 오랫동안 보관.
535
회사가 워크로드를 위해 EKS 클러스터를 구축 + EKS에 저장된 비밀은 Kubernetes etcd 키-값 저장소에서 암호화되어야함
B. 새로운 AWS Key Management Service(AWS KMS) 키를 만듭니다. Amazon EKS 클러스터에서 Amazon EKS KMS 비밀 암호화를 활성화합니다.
etcd 저장소 암호화 ⇒ Secrets Manager(X) , KMS(ㅇ)
* KMS: 암호화 키 관리 서비스. 암호화 및 복호화
* Secrets Manager: 비밀 관리 및 순환을 지원
536
회사의 RDS for PostgreSQL 데이터베이스에 대한 거의 실시간 읽기 전용 액세스를 제공하고자함 현재 Single-AZ 데이터베이스로 구성 → 데이터베이스에 영향을 미치지 않는 복잡한 쿼리 사용 + 고가용성 솔루션 필요 + 가장 비용 효율적 충족
D. 단일 AZ에서 두 개의 읽기 가능한 대기 인스턴스가 있는 다중 AZ 클러스터 배포로 설정을 변경합니다. 데이터 과학자에게 읽기 엔드포인트를 제공합니다.
⇒ 고가용성 = 다중 AZ 클러스터 읽기 전용 + 거의 실시간 = 읽기 가능한 대기. 읽기
Multi-AZ 배포의 보조 인스턴스는 백업 및 복구 목적으로만 사용되어 비동기인 반면 읽기 가능한 대기는 동기적
Multi-AZ 배포의 보조 인스턴스는 읽기 전용 액세스 X
537
3계층 웹 애플리케이션 실행 + 애플리케이션 트래픽이 갑자기 증가할 것으로 예상 → 미래의 애플리케이션 용량 수요를 충족하고 3개의 가용성 영역 모두에서 높은 가용성을 보장하기 위해 확장할 수 있기를 원함
A. MySQL 데이터베이스를 Multi-AZ DB 클러스터 배포를 사용하여 Amazon RDS for MySQL로 마이그레이션합니다. 고가용성을 갖춘 Amazon ElastiCache for Redis를 사용하여 세션 데이터를 저장하고 읽기를 캐시합니다. 웹 서버를 세 개의 가용성 영역에 있는 자동 확장 그룹으로 마이그레이션합니다.
* Memcached는 데이터 캐싱에 가장 적합 + 고가용성 : Multi-AZ 클러스터
* Redis는 지속되어야 하는 데이터를 저장하는데 적합
* Memcached는 Redis보다 더 나은 성능과 단순성을 제공하지만 가용성은 낮음
538
글로벌 비디오 스트리밍 회사 + Amazon CloudFront + 국가 외부에 있는 시청자가 콘텐츠를 볼 수 없도록 설정
A. 허용 목록을 사용하여 CloudFront의 콘텐츠에 지리적 제한을 추가합니다. 사용자 지정 오류 메시지를 설정합니다.
CloudFront 지리적 제한 기능 ⇒ 지정된 웹 배포를 통해 배포하는 모든 파일에 대해 국가 수준에서 콘텐츠 배포를 제어 가능
539
온프레미스 재해 복구 구성 개선 + 애플리케이션은 30초 이하의 복구 지점 목표(RPO)와 60분의 복구 시간 목표(RTO) + 비용 최소화
B. AWS에서 SQL Server 데이터베이스용 웜 스탠바이 Amazon RDS를 구성합니다. AWS Database Migration Service(AWS DMS)를 구성하여 변경 데이터 캡처(CDC)를 사용합니다.
* 파일럿 라이트:환경 간에 데이터를 복제하고 핵심 워크 로드 인프라의 복사본을 프로비저닝 데이터 복제 및 백업을 지원하는데 필요한 리소스(ex: DB, 객체 스토리지)는 상시 작동하지만 애플리케이션 서버 등의 기타 요소는 꺼져 있고, 재해복구 장애 조치 호출 시나 테스트 중에만 사용
* 웜 스탠바이: 정상 작동하는 축소된 프로덕션 환경 사본을 복구 환경에 생성. AWS 상에 시스템을 모두 복제하고 상시 접속되도록 하여 복구 환경의 리소스가 시작될때까지 기다리지 않아도 되므로 복구 시간이 단축된다
* 백업 및 복원(RPO는 시간 단위, RTO는 24시간 이내)
* 파일럿 라이트(RPO는 분 단위, RTO는 시간 단위)
* 웜 스탠바이(RPO는 초 단위, RTO는 분 단위)
540
온프레미스 Oracle 데이터베이스를 사용하는 서버 + AWS 데이터베이스 서버를 사용하여 더 높은 가용성을 달성하고 성능을 개선 하고자함 + 기본 데이터베이스 시스템에서 보고를 오프로드하고자 함 + 가장 운영적으로 효율적인 방식
D. 멀티 AZ 인스턴스 배포에 배포된 Amazon RDS를 사용하여 Amazon Aurora 데이터베이스를 만듭니다. 보고 기능을 리더 인스턴스로 보냅니다.
⇒ Multi-AZ DB 클러스터는 MariaDB용 RDS, Oracle용 RDS, SQL Server용 RDS 에서 사용 불가
541
AWS에서 웹 애플리케이션 구축 + 웹 사이트에 대한 클라이언트 액세스 요청은 예측할 수 없고 오랜 시간 동안 유휴 상태가 될 수 있음 + 구독료를 지불한 고객만 로그인하여 웹 애플리케이션을 사용할 수 있음 + 가장 비용 효율적 충족
A. Amazon DynamoDB에서 사용자 정보를 검색하는 AWS Lambda 함수를 만듭니다. RESTful API를 허용하는 Amazon API Gateway 엔드포인트를 만듭니다. API 호출을 Lambda 함수로 보냅니다.
→ 람다는 유휴 시간 동안 비용 발생x DynamoDB는 사용자 정보를 저장하는 데 적합.
C. 사용자를 인증하기 위해 Amazon Cognito 사용자 풀을 생성합니다.
→ 사용자 풀: 사용자 로그인 처리
E. AWS Amplify를 사용하여 HTML, CSS, JS로 프런트엔드 웹 콘텐츠를 제공합니다. 통합 Amazon CloudFront 구성을 사용합니다.
* AWS Amplify: AWS에서 모바일 및 웹 애플리케이션 개발을 가속화하기 위한 도구 세트(오픈 소스 프레임워크, 비주얼 개발 환경, 콘솔) 및 서비스(웹 앱, 정적 웹사이트 호스팅)로 구성
* Cognito 사용자 풀: 사용자 인증 + 신원 확인 ↔ Cognito 자격 증명 풀: 권한 부여 + 액세스 제어
웹 애플리케이션 빌드 = AWS Amplify
S3는 PHP, JSP 또는 ASP.NET과 같은 서버 측 스크립팅을 지원 X
542
CloudFront 배포를 사용하여 인터넷을 통해 콘텐츠 제공 + 프리미엄 고객만 미디어 스트림과 파일 콘텐츠에 액세스할 수 있기를 원함 + 모든 콘텐츠를 S3 버킷에 저장 → 영화 대여 또는 음악 다운로드와 같은 특정 목적을 위해 고객에게 주문형 콘텐츠 제공
B. CloudFront 서명 URL을 생성하여 프리미엄 고객에게 제공합니다.
* 서명된 URL 및 서명된 쿠키: 컨텐츠에 액세스할 수 있는 대상을 제어하는 기능 + 쿠키: URL 제한X
543
Savings Plan → 다른 AWS 계정에서 Savings Plan 할인 사용 예정
A. 관리 계정의 AWS 계정 관리 콘솔에서 결제 기본 설정 섹션에서 할인 공유를 켭니다.
D. 새로운 지불자 계정에서 AWS Organizations에 조직을 만듭니다. 관리 계정에서 다른 AWS 계정을 초대하여 조직에 가입합니다.
새로운 Organizations에 조직 생성 후 관리 계정에서 다른 AWS 계정을 초대 할인은 신규 결제자에게만 적용되고, 고객 서비스 부서에 문의하지 않는 이상 기존 계정으로 이전 불가능
기존 EC2가 있는 계정을 관리 계정으로 사용 ⇒ 관리 계정에 대한 모범 사례에 어긋남
할인 공유 ⇒ Savings Plan의 할인 혜택이 조직 내 모든 계정에 적용 (비용 절감 효과)
544
퍼블릭 REST API에 지역 Amazon API Gateway API를 사용 + API Gateway 엔드포인트는 Route 53 별칭 레코드를 가리키는 사용자 지정 도메인 이름 → 새로운 버전의 API를 출시하기 위해 고객에게 미치는 영향과 데이터 손실을 최소화하는 솔루션
A. API Gateway에 대한 카나리아 릴리스 배포 단계를 만듭니다. 최신 API 버전을 배포합니다. 적절한 비율의 트래픽을 카나리아 단계로 지정합니다. API 검증 후 카나리아 단계를 프로덕션 단계로 승격합니다.
* Canary 릴리스 : API의 새 버전을 테스트 목적으로 배포하고 같은 단계에서의 정상 작동을 위해 기본 버전은 프로덕션 릴리스로 배포하는 소프트웨어 개발 전략 + 고객에게 미치는 영향 최소화 및 데이터 손실 최소화 + 중간에 멈출 수 없음 + 카나리아 릴리스 배포를 사용하면 새로운 API 버전을 점진적으로 릴리스 가능
545
웹 사이트를 사용할 수 없는 경우 사용자를 백업 정적 오류 페이지로 안내하려고 함 + 웹 사이트의 DNS 레코드는 Route 53에 호스팅 + 도메인은 ALB를 가리킴 → 변경 및 인프라 오버헤드를 최소화하는 솔루션
B. Route 53 액티브-패시브 페일오버 구성을 설정합니다. Route 53 상태 검사에서 ALB 엔드포인트가 비정상이라고 판단되면 Amazon S3 버킷에 호스팅된 정적 오류 페이지로 트래픽을 보냅니다.
⇒ 엔드포인트(Endpoint)는 웹 애플리케이션에서 클라이언트가 서버에 요청을 보내는 특정 URL 경로
⇒ 최소한의 구성 변경으로 자동 fail over 됨
* R oute 53 액티브-패시브 페일오버 구성: 트래픽을 주 리소스로 보내다가 실패할 시 대기 리소스로 트래픽 전환. 장애 복구
* 액티브 - 액티브 : 두 리소스가 동시에 활성 상태. 부하 분산
546
백업 비용을 줄여야 할 필요성 강조 + 온프레미스 백업을 간소화하고 물리적 백업 테이프 사용을 없애 비용을 절감하고자 함
D. iSCSI 가상 테이프 라이브러리(VTL) 인터페이스를 사용하여 백업 애플리케이션에 연결하도록 AWS Storage Gateway를 설정합니다.
* Tape Gateway(iSCSI 기반) ⇒ 온프레미스의 물리적 테이프를 AWS의 가상 테이프로 교체하면 테이프 기반 백업 워크플로를 변경하지 않고도 데이터 스토리지 비용을 절감 + 모든 주요 백업 애플리케이션을 지원하고 온프레미스의 가상 테이프를 캐시하여 대기
시간이 짧은 데이터 액세스를 제공
* VTL(Virtual Tape Library)은 가상 테이프 라이브러리로 데이터의 백업 및 복구를 위해 디스크를 가상의 테이프로 인식시켜 데이터를 저장하는 시스템
547
여러 위치에 데이터 센서 + 대량의 데이터를 스트리밍 + 대량 스트리밍 데이터를 수집하고 처리하는 플랫폼 설계 → 확장 가능해야하며 거의 실시간으로 데이터 수집을 지원 + 향후 보고를 위해 S3에 데이터를 저장해야함 + 가장 적은 운영 오버헤드
A. Amazon Kinesis Data Firehose를 사용하여 스트리밍 데이터를 Amazon S3로 전송합니다.
⇒ Kinesis Data Firehose 사용
548
각각의 부서를 위한 별도의 AWS 계정 → 비용과 보안 문제로 인해 각 계정에서 사용할 수 있는 서비스 제어
B. AWS Organizations에서 각 부서에 대한 조직 단위(OU)를 만듭니다. OU에 서비스 제어 정책(SCP)을 첨부합니다.
⇒ 부서 → 조직단위(OU) →Organizations + SCP 사용
549
프라이빗 서브넷에 있는 EC2 인스턴스에 호스팅된 MYSQL 클러스터 사용 + 타사 공급업체가 인터넷에 호스팅한 제품 카탈로그와 가격 정보를 검색 → 운영 오버헤드를 늘리지 않고도 보안을 극대화하는 전략
B. 퍼블릭 서브넷에 NAT 게이트웨이를 배포합니다. 모든 인터넷 바운드 트래픽을 NAT 게이트웨이로 전달하도록 프라이빗 서브넷 경로 테이블을 수정합니다.
* NAT Instance: 운영 오버헤드
* IGW: 보안상 X → 너무 많은 것을 Open + private subnet 에 igw ⇒ X
* 가상 사설 게이트웨이(VGW): VPN연결 혹은 Direct Connect를 통해 온프레미스와 vpc 연결.
550
회사에서 KMS 키를 사용하여 Lambda 환경 변수를 암호화 → 환경 변수를 해독하고 사용하기 위해 필요한 권한이 있는지 확인
B. Lambda 실행 역할에 AWS KMS 권한을 추가합니다.
D. AWS KMS 키 정책에서 Lambda 실행 역할을 허용합니다.
Lambda 리소스 정책 ⇒ Lambda 함수에 대한 접근을 제어하는 데 사용
AWS KMS 키 정책 ⇒ IAM 사용자 또는 역할을 대상으로 권한 부여
Lambda 실행 역할 ⇒ Lambda 함수가 실행될 때 사용하는 IAM 역할. KMS 키를 사용할 수 있는 권한을 부여 ⇒ kms:Decrypt 권한을 포함한 정책을 실행 역할에 추가
KMS 키 정책에서 Lambda 실행 역할 허용 ⇒ KMS 키 정책에 Lambda 실행 역할을 명시적으로 추가하여 kms:Decrypt 권한을 부여
551
보고서를 생성하는 재무 애플리케이션 운영 + 보고서의 평균 크기는 50KB이고 Amazon S3에 저장 + 보고서는 생산 후 첫 주에 자주 액세스되며 수년간 보관해야함 → 보고서는 6시간 이내에 검색할 수 있어야함
A. S3 Standard를 사용합니다. S3 Lifecycle 규칙을 사용하여 7일 후에 보고서를 S3 Glacier로 전환합니다.
S3 Glacier: 표준 3~5시간 내 데이터 검색
S3 Glacier Deep Archive: 표전 12시간 이내 검색
552
비용 최적화 + 인스턴스 유형과 패밀리 변경
B. 1년 기간 동안 선불 컴퓨팅 절감 플랜을 구매하세요.
* Compute Savings Plan 사용 ⇒ 필요에 따라 기간 내에 인스턴스 유형과 패밀리를 자유롭게 전환 가능
* EC2 Instance Savings Plan ⇒ 패밀리 변경 불가능
553
개인 식별 정보 (PII) 발견
A. 각 리전에서 Amazon Macie를 구성합니다. Amazon S3에 있는 데이터를 분석하는 작업을 만듭니다.
개인 식별 정보 (PII) 발견 ⇒ Amazon Macie 사용
554
데이터베이스 서버 마이그레이션 + 높은 요구사항을 충족하는 인스턴스 유형 필요 + 메모리 사용률이 높음
C. 애플리케이션과 데이터베이스 모두에 메모리 최적화된 인스턴스 패밀리를 사용합니다.
* 인스턴스 패밀리: 고객의 워크로드에대해 컴퓨팅타입을 분류한 것으로서 범용, 컴퓨팅 최적화, 메모리최적화, 가속화된 컴퓨팅, 스토리지 최적화 등 기능 존재
555
애플리케이션은 프라이빗 서브넷의 EC2 인스턴스에서 실행 + SQS 대기열 사용 → EC2 인스턴스와 SQS 대기열 간의 연결을 설정하는 보안 솔루션 설계
A. Amazon SQS에 대한 인터페이스 VPC 엔드포인트를 구현합니다. 엔드포인트가 프라이빗 서브넷을 사용하도록 구성합니다. 엔드포인트에 프라이빗 서브넷에 있는 EC2 인스턴스의 트래픽을 허용하는 인바운드 액세스 규칙이 있는 보안 그룹을 추가합니다.
* 인터페이스 VPC 엔드포인트: VPC를 퍼블릭 인터넷에 노출하지 않고도 AWS 서비스에 연결하는 비공개 방식 + 비공개 서브넷에서 Amazon SQS에 연결하는 가장 안전한 방법
SQS ↔ Gateway Endpoint : 유용한 옵션 X + 보안을 위해서라면 프라이빗 서브넷을 사용하도록 구성
556
3계층 웹 애플리케이션 배포 + 웹 계층과 DynamoDB 테이블에 사용자 데이터 저장하고 검색하는 애플리케이션 계층으로 구성 + 데이터베이스 계층은 공개적으로 액세스할 수 없음 → EC2 인스턴스는 템플릿에서 API 자격증명을 노출하지 않고도 DynamoDB
테이블에 액세스해야함
B. DynamoDB 테이블에서 읽고 쓸 수 있는 필수 권한이 있는 IAM 역할을 만듭니다. EC2 인스턴스 프로필에 역할을 추가하고 인스턴스 프로필을 애플리케이션 인스턴스와 연결합니다.
애플리케이션은 DynamoDB에 데이터를 "저장하고 검색" ⇒ 읽고 쓸 수 있는 권한이 있는 IAM 역할
CloudFormation 템플릿에서 매개변를 사용하는 것은 자격 증명이 쉽게 노출될 수 있음.
557
분석 애플리케이션 관리 + S3 버킷에 대량의 반구조화된 데이터 저장 + 병렬 데이터 처리를 사용하여 데이터를 더 빠르게 처리하려고함 → Redshift 데이터베이스에 저장된 정보를 사용하여 데이터를 풍부하게 하려고함
B. Amazon EMR을 사용하여 S3 데이터를 처리합니다. Amazon EMR을 Amazon Redshift 데이터와 함께 사용하여 S3 데이터를 풍부하게 합니다.
⇒ 병렬 데이터 처리 → AWS EMR
* Amazon EMR: 확장 가능한 Hadoop 및 Spark 클러스터를 제공하는 AWS의 완전 관리형 서비스
EMR에서 사용하는 Hadoop은 구조화되지 않았거나 반구조화된 페타바이트 규모의 데이터를 유용한 통찰력으로 전환하는 데 도움
558
동일한 지역의 2개의 VPC 연결 + 비용 효율적
C. VPC 간에 VPC 피어링 연결을 설정합니다. 각 VPC의 경로 테이블을 업데이트하여 VPC 간 통신에 VPC 피어링 연결을 사용합니다.
⇒ VPC Peering
피어링된 VPC 간에 전송되는 데이터는 동일한 지역에 있는 한 무료
559
애플리케이션은 여러 AWS 리전에 걸쳐 Organizations에서 동일한 조직에 속한 다른 AWS 계정에서 실행됨 + 각 제품군의 팀은 개별 계정에서 각 컴퓨팅 리소스에 태그를 지정 → Organizations의 통합 청구 기능에서 각 제품군의 비용에 대한 자세한 정보를 원함
B. AWS 결제 콘솔에서 특정 사용자 정의 태그를 선택합니다.
E. 조직 관리 계정에서 선택한 태그를 활성화합니다.
* Organizations ⇒ 조직 관리 계정(모든 계정에서 결제 통합)
AWS에서 생성한 태그 → AWS에서 미리 정의하며 제품 라인과 불일치
리소스 그룹 콘솔 → 리소스를 관리하는 데 도움이 되지만 결제에는 도움이 되지 않음.
560
Organizations를 사용하는 AWS 다중 계정 솔루션을 설계 + 회사의 계정을 조직 단위(OU)로 구성 → OU 계층 구조의 변경 사항을 식별하는 솔루션 + 회사의 운영팀에 변경 사항을 알려야함 + 가장 적은 운영 오버헤드
A. AWS Control Tower를 사용하여 AWS 계정을 프로비저닝합니다. 계정 드리프트 알림을 사용하여 OU 계층 구조의 변경 사항을 식별합니다.
* AWS Control Tower: AWS 계정 관리와 거버넌스를 자동화하는 데 유용. 계정 드리프트 감지를 통해 변경 사항을 알림
내장된 계정 드리프트 알림 → 예상 못한 구성 변경을 감지하고 알림 제공. 예상 구성과 실제 구성 간의 불일치 탐지. OU 변경 사항을 자동으로 감지
* AWS Service Catalog: 서비스, 리소스의 카탈로그를 생성하고 배포.
* AWS Config: 리소스 구성 변경을 모니터링하는 데 적합, OU 계층 구조 변경 추적에는 CloudTrail이 더 적합
* CloudTrail Organization Trail: 로그 기반 모니터링으로 실시간 변경 감지가 어려움
* CloudFormation 드리프트 감지: 리소스 수준의 드리프트 탐지 기능으로, OU 계층 구조의 변경 사항을 모니터링하기에는 적합하지 않음
561
매일 수백만 건의 요청 처리 + 요청 수는 계속 증가 + 웹 애플리케이션의 응답 시간 개선 → DynamoDB 테이블에서 제품 세부 정보를 검색할 때 대기 시간을 줄여야함 + 운영 오버헤드 최소화
A. DynamoDB Accelerator(DAX) 클러스터를 설정합니다. 모든 읽기 요청을 DAX를 통해 라우팅합니다.
⇒DynamoDB 대기 시간 감소 : DynamoDB Accelerator(DAX)
* DAX: DynamoDB에 특화된 캐시로, 복잡한 설정 없이 바로 DynamoDB 읽기 성능을 크게 향상
* Memcached는 널리 사용되지만, 직접 DynamoDB와 연동되지 않음.
562
VPC의 EC2 인스턴스에서 DynamoDB로의 API 호출이 인터넷을 통과하지 않도록 해야함
1. 엔드포인트에 대한 경로 테이블 생성
2. DynamoDB Gateway 엔드포인트 생성
* Gateway Endpoint: S3 및 DynamoDB 지원
563
회사가 EKS 클러스터와 온프레미스 Kubernetes 클러스터에서 모두 애플리케이션을 실행
→ 중앙 위치에서 모든 클러스터와 워크로드를 보고 싶어함 + 가장 적은 운영 오버헤드
B. Amazon EKS Connector를 사용하여 모든 Kubernetes 클러스터를 등록하고 연결합니다.
* Amazon EKS Connector: 모든 규정 준수 Kubernetes 클러스터를 AWS에 등록하고 연결. Amazon EKS 콘솔에서 시각화
+ 중앙 집중식 관리. 적은 운영오버헤드
* EKS Anywhere: 온프레미스 EKS 클러스터 배포 및 관리
* AWS Systems Manager: 인프라 및 애플리케이션 관리.
564
민감한 고객 정보 + 구매 거래를 완료할 수 잇는 기능 + 관리자로부터도 민감한 고객 데이터가 보호되어야함.
B. Amazon RDS for MySQL에 민감한 데이터를 저장합니다. AWS Key Management Service(AWS KMS) 클라이언트 측 암호화를 사용하여 데이터를 암호화합니다.
"데이터베이스 관리자조차도" → 클라이언트 측 암호화
* 클라이언트 측 암호화: 데이터가 전송되기 전에 애플리케이션에서 암호화. 데이터가 데이터베이스에 저장될 때 이미 암호화되어있음 → 데이터를 읽거나 쓰는 주체가 명확히 정의되어 있어 데이터베이스 관리자조차도 데이터에 접근 X
* AWS Key Management Service(AWS KMS) 서버 측 암호화 : 데이터가 AWS 서비스에 저장될 때, AWS가 서버에서 데이터를 암호화합니다. 즉, AWS가 데이터를 저장하는 서버에서 암호화
565
온프레미스 MYSQL DB → AWS 클라우드로 마이그레이션 + 회사의 애플리케이션과 호환성 유지 + 수요 증가 기간동안 자동 확장
C. AWS Database Migration Service(AWS DMS)를 사용하여 데이터베이스를 Amazon Aurora로 마이그레이션합니다. Aurora Auto Scaling을 켭니다.
⇒ 자동 확장 : AWS Aurora + Auto Scailing
* Aurora: MYSQL과 호환되는 관계형 DB 서비스 + RDS보다 자동 확장이 더 뛰어남
566
VPC에서 여러 EC2Linux 인스턴스 실행 + 계층적 디렉토리 구조를 사용하는 애플리케이션 호스팅 → 공유 스토리지를 빠르게 동시에 읽고 쓸 줄 알아야함
B. Amazon Elastic File System(Amazon EFS) 파일 시스템을 만듭니다. 각 EC2 인스턴스에서 EFS 파일 시스템을 마운트합니다.
⇒ EFS : 계층적 구조
Amazon EFS: NFSv4 프로토콜을 통해 기존 파일 공유 권한 모델과 계층적 디렉터리 구조를 사용하여 데이터에 대한 공유 액세스를 제공
567
세입자의 시간당 에너지 소비량을 저장하는 워크로드를 설계 + http 요청 + 관리형 서비스를 사용 + 독립적인 구성 요소를 추가함에 따라 워크로드는 향후 더 많은 기능을 받게 됨 + 가장 적은 운영 오버헤드
A. AWS Lambda 함수와 함께 Amazon API Gateway를 사용하여 센서에서 데이터를 수신하고, 데이터를 처리하고, 해당 데이터를 Amazon DynamoDB 테이블에 저장합니다.
* Lambda 함수 : 필요에 따라 데이터를 처리하기 위한 서버리스 컴퓨팅 계층 제공
* DynamoDB: 자동으로 확장되는 완전관리형 NoSQL 데이터베이스
* API Gateway: HTTP 요청을 수신하기 위해 서버를 관리할 필요성 제거
568
엔지니어링 도면을 저장하고 보는데 사용되는 새로운 웹 애플리케이션 스토리지 아키텍처를 설계 + 모두 AWS 인프라에 배포 → 엔지니어링 도면이 로드될때까지 기다리는 시간을 최소화하기 위해 캐싱 지원 + 페타바이트 규모의 데이터를 저장해야함
A. Amazon CloudFront를 갖춘 Amazon S3
* S3: 페타바이트 규모의 데이터를 비용 효율적으로 처리할 수 있는 객체 스토리지
* CloudFront: 캐싱을 통한 빠른 응답시간. 지연 감소
EBS → 페타바이트 데이터x
* Storage Gateway: 클라우드와 온프레미스 연결을 위한 것. 페타바이트 x
* Amazon ElastiCache: 완전 관리형 인메모리 캐싱 서비스. db성능 향상, 응답 시간 단축.
569
EventBridge 규칙은 타사 API를 대상으로 함 + 타사 API는 들어오는 트래픽을 수신하지 않음 → 규칙 조건이 충족되는지, 규칙의 대상이 호출되는지 확인하려고함
A. AWS/Events 네임스페이스의 Amazon CloudWatch에서 메트릭을 확인합니다.
⇒ EventBridge는 일치하는 이벤트 수부터 규칙에 의해 대상이 호출되는 횟수까지 모든 것에 대한 메트릭을 매분 Amazon CloudWatch로 전송 + EventBridge는 CloudWatch로 자세한 로그가 아닌 메트릭만 전송
* CloudTrail: AWS 리소스 모니터링
* AWS/EVENTS 네임스페이스: Amazon EventBridge 와 관련된 메트릭을 추적하도록 특별히 설계. 메트릭 모니터링. CloudWatch와 통합. 이벤트 기반 아키텍처를 모니터링.
570
매주 금요일 저녁에 대규모 워크로드 + 두 가용성 + 항상 두 개 이상의 인스턴스 실행 안됨
최대 6개의 인스턴스로 확장 → 적은 오버헤드
B. 예약된 작업이 있는 자동 크기 조정 그룹을 만듭니다.
'클라우드 > AWS' 카테고리의 다른 글
| [Associate SAA-C03] - dump 정리 601 ~ 630 (0) | 2024.10.12 |
|---|---|
| [Associate SAA-C03] - dump 정리 571 ~ 600 (0) | 2024.10.12 |
| [Associate SAA-C03] - dump 정리 501 ~ 530 (0) | 2024.10.08 |
| [Associate SAA-C03] - dump 정리 471~500 (0) | 2024.10.08 |
| [Associate SAA-C03] - dump 정리 441 ~ 470 (0) | 2024.10.07 |