AWS DVA-C02 Final 오답노트

#개발자의도구들 #AWS시험 #AWSDVA-C02 #DVA-C02

​

참고: ExamPotic Disscussion

문제 찾는법 : 여기 최하단

​

암호화 관련

CSE vs CMK vs AWS Managed Key

📌 CSE(Client-Side-Encryption)

• 클라이언트 측에서 암호(S3 업로드 전에 이미 암호화)
• 사용자가 직접 암호화/복호화 키를 관리한다.
• 👉overhead 및 보안 이슈가 크기 때문에 AWS 시험에서는 대부분 이걸 사용안한다.

​

​

📌 CMK(Customer Managed Key with KMS)

• 서버 측에서 암호화 하는 방식(SSE)
• 암호화 자체는 CMK가 한다.(암호화, 복호화 모두 AWS에서)
• AWS KMS를 통해서 키를 관리한다.
• 🔑키는 KMS의 Customer Managed CMK로 저장됨
• CMK는 on-demand로 rotation이 된다.

​

🚀 imported key material

• 고객이 직접 키 재료(key material) 를 KMS로 가져와 사용하는 구조.
• 키 자체는 KMS에서 관리되지만, 키 재료를 언제든 삭제 가능.
• 삭제 시 즉시 비활성화, 키로 암호화된 모든 데이터 복호화 불가능.
• KMS는 고가용성 서비스이므로 인프라 관리 필요 없음.
• ➡️ ✅ 즉시 삭제 가능 + 고가용성 + 관리형 인프라 불필요
• ✅ 정답

​

⚠️기본적으로 KMS에서 생성된 키는 즉시 삭제 불가!

• 하지만 위 방법으로 가능!

​

🚀 vs AWS Managed Key

• 관리 주체에 대해서 물어보는 것
• CMK의 경우 암호화는 서버에서 진행하지만, 관리 자체는 사용자가 진행한다.
• 고객이 생성, 이름, 정책, rotation 시점 등을 정의
• 반면, AWS Managed Key는 생성, 관리 자체를 AWS에 모두 자동화 시켜버림
• aws s3

​

• 고객이 관리 주체이면 CMK를 사용하거나 CSE인데 CSE는 보통 AWS에서 권장되지 않는다.
• SSE-KMS를 사용하면 유저가 직접 관리하는 CMK나 AWS Managed Key로 자동 관리 \\

​

S3 Policy vs Permission Boundary

S3 Policy: 실제 허용/거부 권한 정의

Permission Boundary: IAM 사용자가 가질 수 있는 최대 권한의 상한성을 설정

​

🧠 개념 차이 상세 설명

long-term credentials

📌 장기 자격 증명?

• 고정된 DB 비밀번호
• IAM access key & secret key
• 환경 변수나 config 파일에 저장된 고정 인증번호

​

👉 AWS는 자격 증명 유출 위험을 줄이기 위해 임시 인증 방식을 권장한다.

​

​

IAM Databse Authentication vs Secrets Manager rotaton

📌 IAM Databse Authentication

• RDS MySQL/PostgreSQL에서 IAM token으로 로그인

• 단기 토큰 사용 = not long-term credential을 의미

​

반면에 📌 Secret manager는?

• 여전히 pw 기반 = 장기 보관을 의미

​

4️⃣ IAM Database Authentication 상세

• 지원 엔진: Amazon RDS for MySQL / PostgreSQL
• 동작 방식
• 개발자/앱은 IAM Role 또는 IAM User 자격으로 rds-db:connect 권한을 가짐
• AWS SDK 또는 CLI를 통해 임시 인증 토큰 발급
• (예: generate-db-auth-token API 호출)
• 이 토큰은 15분간 유효하며, RDS MySQL 로그인 시 password 대신 사용됨
• RDS가 IAM을 통해 토큰을 검증하여 접속 허용

​

Lambda Authorizer

API GW에서 요청이 실제 벡엔드로 전달되기 전에, Lambda 함수를 호출해 요청을 허용할지 거부할지 결정하는 로직

                                    [Client] → [API Gateway] → [Lambda Authorizer]
→ [API Gateway Policy 적용] → [Backend / Lambda / HTTP API]

Authorizer는 IAM Policy를 반환한다.

• 반환된 결과는 API GW의 Authorizer Caching 기능에 사용됨
• 결과를 TTL 동안 캐싱
• 동일 토큰에 대해서는 Lambda를 호출하지 않는다.

​

Trust Policy

Trust Policy는 누가 이 Role을 사용할 수 있는지를 정의하는 정책이다.

​

IAM Role(역할)은 두 가지 정책으로 구성된다.

🧠 6️⃣ Trust Policy vs Permissions Policy 차이

Trust Policy vs Resource Policy

Cross-account 접근 제어

🔑 cross account 접근 제어 정책에서 ...

Ec2(계정 A) → Kinesis Data(계정 B) 접근 시 필요한 권한 설정

​

EC2는 permission policy적용

• kinesis: GetRecords
• kinesis: GetShardItereator

​

Kinsesis Stream Policy

• 누가 접근할지 적용
• trust policy?

​

🧩 1️⃣ 공통점

​

​

⚙️ 2️⃣ 차이점 요약표

• trust는 Role을 사용할 주체를 결정
• Resource는 해당 resourcce 자체에 대한 주체 결정

​

Data Rotation vs Key Rotation

• DataRotation: 데이터 값을 로테이션
• KeyRotation: 키 값을 로테이션

​

SecretManager = API key value, DB credential와 같이 데이터 자체를 rotate

KMS AWS managed key = 데이터 암호화에 사용되는 Key 값 자체를 Rotation

SQS

​

SQS FIFO vs SQS Standard

공통점

차이점

6️⃣ 언제 어떤 걸 쓰나?

• 👉 FIFO가 좀 더 무거운 동작!!

​

​

CloudFormation 관련

UPDATE\_ROLLBACK\_FAILED

CloudFormation은 리소스를 선언형(Declarative)으로 관리한다.

-

• 템플릿 변경 = 기존 리소스 수정(Update)를 의미

​

• Stack update 중 리소스 교체 또는 수정이 수행됨
• 중간에 실패하는 경우 기존 리소스로 롤백된다.
• 하지만, 기존 리소스가 수동으로 변경, 삭제되어 있으면 롤백에 실패한다.

​

UPDATE\_FAILED

기존 인스턴스 타입을 변경할 때 만날 수 있는 오류.

👉 새 인스턴스 타입이 template에 명시되어 있지 않으면 오류

​

IAM 권한 부족으로 생기는 경우

👉 해당 리소스를 생성,수정할 권한이 없어

SSM Dynamic Reference

CloudFormation이 배포 시점에 외부 서비스에서값을 자동으로 가져오는 기능이다.

• SSM: System Manager

API GW & Lambda pattern

Lambda dependecy

의존성 파일 크기가 500MB

• 어떤 배포 방법이 적합한가?

​

lambda도 container로 배포가 가능하다!

• .zip배포는 최대 250MB 크기만 가능
• 컨테이너 배포시에는 ECR 사용!

​

API GW Integration

원래는 API GW → Lambda가 익숙한 패턴이다.

​

하지만 integration의 종류가 여러가지라서 아래를 참고하자.

                                    [Client]
   │  (HTTP/REST/WebSocket)
   ▼
[API Gateway]
   ├── Method Request   ← (요청 수신 및 인증/인가)
   ├── Integration Request  ← (백엔드로 전달)
   ├── Integration Response ← (백엔드 응답 수신)
   └── Method Response  ← (클라이언트로 반환)
   ▼
[Backend (Integration Target)]

​

• 어떤 백엔드로 어떤 방식으로 전달할지를 정의하는 것!

Cold Start

🤔 cold start?

서버리스 환경, AWS Lambda나 Fargate, Cloud functions 등에서 자주 언급되는 핵심 개념이다.

• Lambda가 새로 생성된 실행 환경을 처음 시작할 때 발생하는 지연

• 아직 아무 인스턴스도 준비되어 있지 않은 상태에서 요청을 받으면 AWS가 새 컨테이너(실행환경)을 "처음부터 생성하고 초기화 하는 과정" 때문에 시간이 더 걸린다.

​

🔹 Cold Start가 발생할 때

1. 요청 도착
2. Lambda 서비스가 새 실행 환경(container)을 생성
3. 런타임 로딩 (Node.js, Python, Java 등)
4. 함수 코드 + 의존성(라이브러리) 로딩
5. Handler 초기화 (init 단계)
6. 드디어 요청 처리 시작 (Invoke)

​

🔹 Warm Start (웜 스타트)

한 번 생성된 Lambda 환경은 잠시 동안 재사용(keep-alive) 됩니다.

이후 동일 함수에 새로운 요청이 오면 이미 워밍된 컨테이너에서 바로 실행 → 거의 지연 없음.

즉:

​

💡 5️⃣ Cold Start 줄이는 방법

​

Provisioned Concurrency vs Reserved Concurrency

​

Execution Role vs Resource Policy

• Execution Role은 Lambda가 다른 AWS 리소스에 접근할 때 사용하는 권한이다.
• Resource Policy는 누가 Lamgda를 호출 할 수 있는지 제어

S3

Versioning & LifeCycle Rule

📌 Versioning 구조

• 각 오브젝트 키(file.txt)는 여러 버전을 가질 수 있다.

                                    file.txt (version 3) ← current
file.txt (version 2)
file.txt (version 1)

• 오브젝트를 삭제하면 실제로 삭제되는 것이 아닌 Delete-marker가 생성된다.

​

📌 LifeCycle Rule은 다음 두 가지를 개별적으로 관리한다.

1. Current version
2. Previous versions

​

🤔 자동 삭제기능 구현?

1년뒤 오브젝트를 자동 삭제하고 싶다.

• Delete marker를 보고 자동으로 삭제됨

​

​

DynamoDB

DAX (Accelerator) vs Dynamo DB Streams

📌 DAX

목적: ⚡ 읽기 성능 향상 (in-memory cache)

주요기능: 자주 조회되는 항목을 메모리에 캐싱

사용시점: 읽기 부하가 많고, 같은 데이터를 자주 읽을 때

성능: micro sec 수준

👉 Redis In-memory cache 같은 느낌

​

클라이언트 → DAX → DynamoDB (읽기 요청 가속)

​

​

📌 DynamoDB Streams

목적: 🔄 데이터 변경 이벤트 추적 (change data capture)

주요기능: 테이블의 insert, update, delete 이벤트를 시간 순서대로 스트림으로 전달.

성능: 준실시간, 초단위 지연 발생 가능

​

DynamoDB → Streams → 소비자(Lambda, Kinesis 등)

​

​

​

조회

X-Ray

Sampling Rule

• X-Ray는 기본적으로 모든 요청을 추적하지 않는다.
• Sampling rule을 통해 어떤 요청을 기록할지 결정한다.
• 기본 샘플링(Defult rule)
• 1초당 첫 요청 1개
• 이후 5% 정도의 추가 요청만 샘플링

​

📌 Custom Sampling rules

• 서비스별, 요청 속성별로 다르게 추적하고 싶어.
• Fixed Rate:
• 추적 비율에 대해
• 중요도 높은건 높게
• 낮은건 낮게 설정

​

😵‍💫 혼동 개념

• sampling을 제거
• 요청 추적을 안한다?
• ❌
• 👉 모든 요청에 대해 추적한다!

​

• volume
• X-ray의 추적 요청량
• 중요도가 높은걸 높게
• 낮은걸 낮게 해야함

기타 서비스들

AWS AppConfig

상황: 여러 Lambda 함수에서 동적 구성 데이터를 읽어야 한다.

• 구성 데이터의 크기는 6KB Json 문서
• AWS AppConfig에 저장되어잇다.
• Lambda 재배포 없이 구성을 업데이트하려면?

​

📌 App Config : AWS Systems Manager안의 구성 관리 서비스이다.

• App 서비스를 버전별로 관리하고, 애플리케이션에서 동적으로 읽기 가능
• 애플리케이션 설정값을 안전하게 배포,관리,롤백할 수 있는 구성 관리 서비스이다!

​

​

Lambda에서 AWS AppConfig를 사용하는 가장 쉬운 방법

• 사용이유: Lambda내에 한경설정을 배포하면 환경설정 변경시 Lambda 자체를 재배포 해야한다.
• Lambda Extension을 사용해서 Lambda 실행환경에서 AppConfig 데이터를 로컬로 제공받을 수 있다.

​

"운영 환경에서 실시간으로 변경 가능한 구성 관리"를 목표로 한다.

​

​

Amazon Macie vs Amazon Inspector

📌 Mecies

• 데이터 보안 서비스
• 자동으로 민감한 데이터 탐지 (PII, 신용카드, 개인정보 등)
• 암호화 상태 확인(암호화되지 않은 객체 탐지)
• S3 버킷 보안 평가(공개 엑세스, 정책 문제 등)
• 자동 알림 (Event Brdige와 통합)
• 기계학습 기반 민감 데이터 분휴

​

📌 Amazon Inspector

• 인프라 보안 서비스
• 워크로드(컴퓨터 리소스)의 취약점 스캔
• 소프트웨어 취약점(CVE)
• 운영체제 패치 누락
• 라이브러리 취약점
• 네트워크 접근성
• 애플리케이션 보안 설정

​

Cloud Watch EMF vs Insigts

Embedded metric format

• Lmabde가 로그 실시간으로 뽑아내 메트릭 생성
• AWS 제공 lib사용

​

Kinesis shard

• Peak 타임에 kinesis 데이터 ingest가 느려지는 경우 해야할 조치?

​

📌 Kinesis Data Stream 기본 개념

• Shard 용량
• 각 샤드당
• 쓰기: 1MB/초 또는 1,000 레코드/초
• 읽기: 2MB/초

​

📜 용량 모드

1. Provisioned Mode

• 샤드 수를 수동으로 관리한다.
• 샤드당 시간당 과금
• 예측 가능한 비용
• 스케일링
• 수동 샤드 분할/병합
• Application Auto Scaling 사용

​

1. On-Demand Mode

• 자동으로 용량 조정
• 실제 사용량만큼 과금
• 샤드 관리 불필요

​

​