테마
15. AWS 중상급 핵심 로드맵
원본 강의 전사는 AWS 서비스를 더 깊게 다루기 위해 IAM, Cognito, S3, DynamoDB, 서버리스, 컨테이너, CI/CD, 보안, IaC를 넓게 훑는다. 이 문서는 실습 순서를 그대로 옮기기보다, 개발자가 실제 설계와 운영 판단에 사용할 수 있도록 2026년 기준의 개념으로 다시 정리한다.
먼저 잡아야 할 큰 그림
중상급 AWS 학습의 핵심은 "서비스를 많이 아는 것"이 아니라, 서비스 사이의 책임 경계를 분명히 나누는 것이다.
서비스를 외울 때는 다음 질문으로 묶어 이해한다.
| 질문 | 핵심 서비스 |
|---|---|
| 사용자는 누구이며 어떤 권한을 가져야 할까? | IAM, Cognito, STS |
| 브라우저와 모바일 앱은 AWS 리소스에 어떻게 접근할까? | Cognito User Pool, Identity Pool |
| 파일과 대용량 객체는 어떻게 안전하게 저장할까? | S3, KMS, CloudFront |
| 예측이 어려운 트래픽의 상태 데이터는 어디에 둘까? | DynamoDB |
| 여러 작업을 순서대로, 실패 처리까지 포함해 어떻게 실행할까? | Lambda, Step Functions, SQS, SNS |
| 컨테이너 이미지는 어디에 저장하고 어떻게 실행할까? | ECR, ECS Fargate |
| 배포를 어떻게 반복 가능하게 만들까? | CodeBuild, CodeDeploy, CodePipeline, CloudFormation, SAM |
| 문제가 생겼는지 어떻게 추적할까? | CloudWatch, X-Ray, OpenTelemetry |
2026년 기준으로 고쳐 이해할 점
| 원문 흐름 | 지금은 이렇게 이해하기 |
|---|---|
| Cognito 호스팅 UI에서 바로 토큰을 받는다 | 현재 문서에서는 사용자 풀 도메인의 새 UI를 managed login으로 설명한다. 공개 웹/모바일 클라이언트는 client secret 없이 Authorization Code + PKCE 흐름을 우선한다. |
| User Pool과 Identity Pool을 모두 "로그인"으로 본다 | User Pool은 인증과 JWT 발급, Identity Pool은 토큰을 임시 AWS 자격 증명으로 교환하는 권한 위임 영역이다. |
| S3 암호화는 버킷 정책으로 강제해야 한다 | 2023년 1월 5일부터 새 S3 객체 업로드는 기본적으로 SSE-S3로 자동 암호화된다. 규제, 감사, 키 제어가 필요할 때 SSE-KMS 또는 DSSE-KMS를 명시한다. |
| S3 키 이름 앞에 랜덤 값을 붙이면 성능이 좋아진다 | 예전 파티션 분산 팁으로만 기억한다. 지금은 S3가 prefix별 최소 3,500 write, 5,500 read 요청/초까지 자동 확장한다. 의미 있는 prefix와 병렬화를 먼저 설계한다. |
| DynamoDB는 RCU/WCU부터 계산한다 | RCU/WCU는 시험과 고정 트래픽 설계에 중요하지만, 대부분의 가변 워크로드는 On-demand 모드가 기본 권장이다. |
| TTL이 만료되면 즉시 삭제된다 | DynamoDB TTL은 만료 시각 이후 보통 며칠 안에 비동기로 삭제된다. 만료된 항목이 잠시 조회될 수 있으므로 애플리케이션 조건도 함께 둔다. |
| Lambda가 VPC에 붙으면 ENI를 직접 관리한다고 본다 | Lambda는 Hyperplane ENI를 관리한다. 그래도 VPC 연결 함수가 인터넷이나 AWS API를 호출해야 하면 NAT Gateway 또는 VPC Endpoint 설계가 필요하다. |
| Lambda alias는 단순한 별칭이다 | alias는 특정 버전을 가리키는 포인터이며, 트래픽 분할로 카나리 배포에도 쓸 수 있다. |
| API Gateway는 REST API 하나로 이해하면 된다 | HTTP API와 REST API를 구분한다. 단순 Lambda 프록시와 OIDC/OAuth 인증은 HTTP API가 더 단순하고 저렴한 편이고, API key, usage plan, request validation, private API 같은 기능은 REST API가 필요하다. |
| Step Functions는 Lambda 순서 제어 도구다 | Standard와 Express 워크플로우를 구분해야 한다. 오래 걸리고 감사 추적이 중요한 업무는 Standard, 짧고 대량 실행되는 이벤트성 흐름은 Express가 맞다. |
| X-Ray SDK/Daemon을 기본 계측 방법으로 쓴다 | X-Ray SDK/Daemon은 2026년 2월 25일부터 유지보수 모드에 들어갔다. 새 계측은 OpenTelemetry와 AWS Distro for OpenTelemetry를 우선 검토한다. |
| KMS의 핵심은 CMK를 만드는 것이다 | 최신 용어는 KMS key다. 직접 관리하는 키는 customer managed key로 부르고, 기본 암호화에는 AWS owned key와 AWS managed key도 함께 이해한다. |
| CloudWatch Events로 파이프라인을 트리거한다 | 현재 이벤트 라우팅의 중심 용어는 Amazon EventBridge다. CodePipeline, Step Functions, Lambda, SaaS 이벤트를 연결할 때 EventBridge와 EventBridge Scheduler를 함께 본다. |
| CodeCommit에서 시작해 CodePipeline으로 배포한다 | AWS 네이티브 CI/CD 학습에는 여전히 좋다. CodeCommit은 2024년 7월 25일 신규 고객 제공이 중단됐다가 2025년 11월 25일 재개되었으므로, 그 기간 자료의 "신규 사용 불가" 설명은 문서 이력을 함께 확인한다. 실무에서는 GitHub/GitLab + OIDC + CodeBuild/CodePipeline 또는 GitHub Actions 조합도 함께 검토한다. |
| ECS는 EC2 클러스터를 만든 뒤 컨테이너를 올린다 | 새 학습은 Fargate를 기본 경로로 잡는다. EC2 launch type은 GPU, 특수 네트워크, 데몬, 비용 최적화가 필요한 경우에 선택한다. |
| Beanstalk 플랫폼은 예전 예제 그대로 따라가면 된다 | Amazon Linux 2 기반 Beanstalk 플랫폼은 2026년 중반 은퇴 일정이 많다. 새 실습은 Amazon Linux 2023 플랫폼과 현재 지원 런타임을 확인한다. |
1. IAM 정책은 재사용성과 경계로 이해한다
IAM 정책은 JSON으로 된 권한 규칙이다. 중상급부터는 "어떤 정책이 더 강한가"보다 "어디에 붙고, 누가 재사용하며, 어떻게 줄일 수 있는가"를 봐야 한다.
| 정책 유형 | 특징 | 사용 감각 |
|---|---|---|
| AWS 관리형 정책 | AWS가 만들고 업데이트한다 | 학습, 빠른 실습, 초기 탐색에 적합 |
| 고객 관리형 정책 | 계정 안에서 직접 만들고 버전 관리한다 | 운영에서 최소 권한을 담는 기본 형태 |
| 인라인 정책 | 특정 사용자, 그룹, 역할에 1:1로 붙어 재사용되지 않는다 | 해당 주체에만 유일하게 필요한 권한. 리뷰나 재사용이 필요하면 고객 관리형으로 승격 |
운영 설계에서는 다음 순서로 좁혀 간다.
- 학습과 탐색 단계에서는 AWS 관리형 정책으로 서비스 동작을 파악한다.
- 운영 전에는 CloudTrail, IAM Access Analyzer, 서비스별 액세스 로그를 보고 실제 필요한 동작으로 줄인다.
- 사람에게 장기 Access Key를 주는 방식은 줄이고, Role, IAM Identity Center, OIDC 기반 임시 자격 증명을 우선한다.
- 여러 팀이 쓰는 계정이라면 권한 경계, SCP, 태그 조건까지 함께 설계한다.
인라인 정책은 "이 역할 없이는 의미가 없는 특수한 예외"에 가깝다. 재사용할 가능성이 있거나 리뷰가 필요한 권한이라면 고객 관리형 정책이 더 낫다.
2. Cognito와 Web Identity Federation
Web Identity Federation은 외부 IdP의 로그인 결과를 AWS 권한으로 연결하는 방식이다. Cognito는 이 흐름을 앱 개발자가 쓰기 쉽게 묶어 준다.
| 구성 요소 | 역할 | 결과물 |
|---|---|---|
| User Pool | 사용자 가입, 로그인, MFA, 소셜/OIDC/SAML 연동 | ID token, access token, refresh token |
| Managed Login | Cognito가 제공하는 로그인 UI와 OIDC/OAuth 엔드포인트 | 브라우저 기반 인증 흐름 |
| Identity Pool | 외부 토큰을 AWS STS 임시 자격 증명으로 교환 | 제한된 IAM Role 자격 증명 |
User Pool과 Identity Pool을 함께 쓰는 흐름은 다음과 같다.
공개 클라이언트인 SPA나 모바일 앱에는 client secret을 넣으면 안 된다. 앱에 포함된 secret은 결국 사용자에게 노출될 수 있기 때문이다. 공개 클라이언트는 Authorization Code + PKCE 흐름을 쓰고, 토큰 저장 위치와 만료 시간을 보수적으로 잡는다.
Identity Pool을 사용할 때는 특히 guest access를 조심한다. 미인증 사용자에게도 임시 자격 증명을 줄 수 있으므로, S3 prefix, DynamoDB partition key, API 경로 조건으로 접근 범위를 아주 작게 제한해야 한다.
3. S3 심화: 암호화, CORS, 스토리지 클래스, 성능
S3는 단순한 파일 저장소가 아니라, 권한과 암호화와 전송 성능을 함께 설계해야 하는 객체 스토리지다.
암호화
모든 새 객체는 SSE-S3로 자동 암호화된다. 따라서 "암호화를 켜야 안전하다"보다 "어떤 키 통제와 감사 수준이 필요한가"가 더 중요한 질문이다.
| 방식 | 적합한 상황 |
|---|---|
| SSE-S3 | 기본 암호화, 별도 키 관리가 필요 없는 일반 객체 |
| SSE-KMS | 키 정책, CloudTrail 감사, 계정/팀별 키 통제가 필요한 데이터 |
| DSSE-KMS | 이중 계층 서버 측 암호화가 필요한 엄격한 규제 환경 |
버킷 정책의 s3:x-amz-server-side-encryption 조건 키로 aws:kms 값을 요구하고, 필요하면 s3:x-amz-server-side-encryption-aws-kms-key-id로 특정 KMS key까지 고정하는 실습은 여전히 유효하다. 다만 그 목적은 "암호화 자체를 켜기"가 아니라 "어떤 키로 암호화할지 고정하기"다.
CORS
CORS는 브라우저가 다른 origin의 리소스를 읽을 수 있는지 정하는 규칙이다. 인증이나 권한 부여 기능이 아니다.
| 좋은 설정 | 피해야 할 설정 |
|---|---|
| 실제 웹 앱 origin만 허용 | 운영 버킷에서 AllowedOrigins: ["*"] |
| 필요한 method와 header만 허용 | 모든 method와 header를 넓게 열기 |
| preflight 요청을 고려해 테스트 | S3 권한 문제와 CORS 문제를 혼동 |
브라우저 오류가 CORS처럼 보여도 실제 원인은 S3 버킷 정책, CloudFront OAC, 인증 토큰 누락일 수 있다. 네트워크 탭에서 preflight와 실제 요청을 따로 확인한다.
스토리지 클래스와 라이프사이클
스토리지 클래스는 "싸냐 비싸냐"가 아니라 "얼마나 자주 읽고, 얼마나 빨리 복원해야 하는가"로 고른다.
| 클래스 | 사용 감각 |
|---|---|
| S3 Standard | 자주 읽는 일반 데이터 |
| S3 Intelligent-Tiering | 접근 패턴이 예측되지 않는 데이터 |
| S3 Standard-IA / One Zone-IA | 드물게 읽지만 빠르게 접근해야 하는 데이터 |
| S3 Glacier Instant Retrieval | 거의 안 읽지만 즉시 접근이 필요한 아카이브 |
| S3 Glacier Flexible Retrieval / Deep Archive | 복원 지연을 감수할 수 있는 장기 보관 |
강의의 "Glacier는 복원에 몇 시간 걸린다"는 설명은 일부 클래스에는 맞지만 전체 Glacier 계열에는 부족하다. 이제는 Glacier 계열 안에서도 즉시 검색, 분 단위, 시간 단위, 장기 저비용 옵션을 나눠 봐야 한다.
성능
S3 성능 최적화에서 오래된 랜덤 prefix 규칙을 그대로 외우면 안 된다. 현재 S3는 높은 요청률로 자동 확장하며, prefix를 여러 개로 나눠 병렬 처리하면 더 큰 처리량을 얻을 수 있다.
실무 판단은 다음 순서가 좋다.
- 객체 key는 사람이 이해할 수 있는 도메인 구조로 설계한다.
- 매우 높은 요청률이 필요한 경우 prefix를 기준으로 병렬화를 설계한다.
- 원거리 업로드가 병목이면 Transfer Acceleration을 테스트한다.
- 읽기 지연이 문제면 CloudFront 캐시와 캐시 무효화 전략을 먼저 본다.
- SSE-KMS를 많이 쓰면 S3뿐 아니라 KMS 요청 한도와 비용도 확인한다.
4. DynamoDB 심화: 용량보다 접근 패턴이 먼저다
DynamoDB는 테이블을 먼저 만들고 쿼리를 나중에 고민하는 데이터베이스가 아니다. 먼저 화면, API, 배치 작업이 어떤 key로 데이터를 읽을지 정하고, 그 접근 패턴에 맞춰 파티션 키와 정렬 키를 설계한다.
| 개념 | 핵심 |
|---|---|
| On-demand | 가변 트래픽에 적합한 기본 권장 모드. 요청당 과금 |
| Provisioned | 예측 가능한 트래픽에서 RCU/WCU를 정해 비용을 통제 |
| RCU | 4KB 이하 항목 기준 초당 strongly consistent read 1회, eventually consistent read 2회, transactional read 0.5회 |
| WCU | 1KB write 기준 |
| Adaptive capacity | 특정 파티션에 트래픽이 몰릴 때 완화하지만, 나쁜 key 설계를 완전히 해결하지는 않음 |
| TTL | 만료 시각 이후 보통 며칠 안에 비동기 삭제. 즉시 삭제 보장 아님 |
Provisioned Throughput Exceeded가 보이면 단순히 RCU/WCU만 올리지 말고 원인을 나눠 본다.
| 증상 | 확인할 것 |
|---|---|
| 특정 사용자나 tenant에서만 실패 | hot partition 여부 |
| 전체 트래픽이 일시적으로 증가 | On-demand 전환, Auto Scaling, backoff |
| 배치 작업 중 실패 | batch 크기, 재시도, UnprocessedItems 처리 |
| 읽기 비용이 급증 | Scan 남용, GSI 설계, DAX 필요성 |
AWS SDK의 재시도와 exponential backoff는 기본적으로 도움이 된다. 그래도 멱등성 없는 쓰기 작업에서는 조건부 쓰기, idempotency key, 중복 처리 정책을 함께 설계해야 한다.
5. 서버리스 조율: Lambda, SQS, SNS, Step Functions
서버리스는 "서버가 없다"가 아니라 "서버 운영 책임을 줄이고 이벤트와 제한을 설계한다"에 가깝다.
| 서비스 | 역할 |
|---|---|
| Lambda | 이벤트에 반응해 짧은 코드를 실행 |
| API Gateway | 외부 HTTP 요청을 Lambda, VPC, AWS 서비스로 연결 |
| SQS | 작업을 큐에 쌓아 소비자가 처리하도록 분리 |
| SNS | 하나의 이벤트를 여러 구독자에게 fan-out |
| EventBridge | AWS 서비스, SaaS, 자체 앱 이벤트를 라우팅하고 스케줄링 |
| Step Functions | 분기, 재시도, 병렬 처리, 보상 작업을 워크플로우로 표현 |
API Gateway는 먼저 HTTP API와 REST API를 구분한다. 새 HTTP Lambda API를 빠르게 만들거나 JWT/OIDC 인증을 붙이는 정도라면 HTTP API가 단순하다. 반대로 API key, usage plan, 세밀한 request validation, private API endpoint가 필요하면 REST API가 맞다.
Lambda 버전과 alias는 운영 배포의 기본 단위다. $LATEST는 개발 중인 변경 가능 상태이고, publish한 version은 코드와 함수 구성이 고정된 불변 스냅샷이다. 트래픽 비중, 예약 동시성, 프로비저닝된 동시성 같은 운영 설정은 version이 아니라 alias 또는 함수 수준에서 다룬다. alias는 prod, staging처럼 안정적인 이름으로 특정 버전을 가리키며, 필요하면 두 버전에 트래픽을 나눠 카나리 배포를 할 수 있다.
Lambda를 VPC에 붙일 때는 "프라이빗 리소스에 접근해야 하는가"를 먼저 묻는다.
| 상황 | 권장 판단 |
|---|---|
| RDS, ElastiCache, private subnet의 EC2에 접근 | Lambda VPC 연결 필요 |
| 공개 AWS API나 외부 API만 호출 | VPC 연결 없이 시작하는 편이 단순 |
| VPC 연결 함수가 인터넷 호출 필요 | private subnet + NAT Gateway 또는 VPC Endpoint 검토 |
| S3, DynamoDB 같은 AWS 서비스 호출 | Gateway/Interface VPC Endpoint로 NAT 비용과 경로를 줄일 수 있음 |
Step Functions는 Lambda를 여러 개 붙이는 시각화 도구로만 보면 아깝다. 실패 재시도, timeout, compensation, 병렬 실행, 사람이 이해할 수 있는 상태 추적까지 포함한 워크플로우 경계로 본다.
| 유형 | 적합한 상황 |
|---|---|
| Standard | 오래 걸리는 업무, 정확한 실행 이력, 감사와 재시도가 중요한 플로우 |
| Express | 짧고 대량으로 실행되는 이벤트 처리, 높은 처리량과 낮은 비용이 중요한 플로우 |
6. 컨테이너와 CI/CD: 이미지 기준으로 배포한다
Docker, ECR, ECS를 배우는 이유는 "서버에 접속해서 설치한다"는 배포 방식을 "이미지를 빌드하고 선언된 서비스로 굴린다"로 바꾸기 위해서다.
| 구성 요소 | 역할 |
|---|---|
| Dockerfile | 실행 환경을 이미지로 정의 |
| ECR | 컨테이너 이미지 저장소 |
| ECS Task Definition | 컨테이너, CPU, 메모리, 포트, 로그, secret 정의 |
| ECS Service | 원하는 task 수를 유지하고 배포를 수행 |
| Fargate | EC2 서버 관리 없이 task 실행 |
ECS 권한에서 자주 헷갈리는 부분은 role 두 가지다.
| Role | 누가 사용하나 | 대표 권한 |
|---|---|---|
| Task execution role | ECS 에이전트와 Fargate 플랫폼 | ECR pull, CloudWatch Logs 전송, secret 가져오기 |
| Task role | 컨테이너 안의 애플리케이션 코드 | S3, DynamoDB, SQS 등 앱이 호출하는 AWS API |
강의처럼 CodeCommit -> CodeBuild -> ECR -> ECS로 이어지는 흐름은 AWS 네이티브 파이프라인을 이해하기 좋다. 다만 새 프로젝트라면 다음 흐름을 함께 비교한다.
| 흐름 | 장점 | 주의점 |
|---|---|---|
| CodeCommit + CodePipeline + CodeBuild | AWS 안에서 권한과 감사가 일관됨 | 팀 협업 도구가 GitHub/GitLab이면 중복될 수 있음. 2024~2025년 자료는 CodeCommit 제공 상태가 다르게 적혀 있을 수 있음 |
| GitHub/GitLab + OIDC + CodeBuild | 소스 플랫폼은 유지하고 AWS 빌드 환경 사용 | OIDC trust policy와 권한 범위를 좁혀야 함 |
| GitHub Actions + OIDC + ECS/Lambda 배포 | 개발자 경험이 좋고 생태계가 넓음 | 장기 Access Key 저장 금지, 배포 권한 최소화 필요 |
CodeBuild에서 Docker 이미지를 빌드할 때는 privileged 모드, ECR 로그인, 이미지 태그 전략, 캐시, SBOM/취약점 스캔을 같이 확인한다. latest 태그만 쓰면 롤백과 감사가 어려우므로 Git SHA, 버전, 빌드 번호를 함께 태깅하는 습관이 좋다.
7. Elastic Beanstalk은 빠른 PaaS, ECS는 운영 경계
Elastic Beanstalk은 코드 업로드만으로 EC2, Auto Scaling, Load Balancer, CloudWatch, S3 같은 리소스를 구성해 주는 PaaS다. 여전히 학습과 빠른 배포에는 유용하지만, 운영 자동화와 컨테이너 표준화가 중요해지면 ECS/Fargate나 App Runner, Lambda를 함께 비교해야 한다.
새 Beanstalk 실습을 한다면 Amazon Linux 2023 플랫폼과 현재 지원되는 런타임을 기준으로 시작한다. 오래된 강의의 Amazon Linux 2 또는 더 이전 AMI 기반 예제는 콘솔 UI, 런타임 버전, 은퇴 일정이 다를 수 있다.
| 배포 방식 | 특징 | 적합한 환경 |
|---|---|---|
| All at once | 모든 인스턴스를 한 번에 교체 | 개발, 짧은 다운타임 허용 |
| Rolling | 일부 인스턴스씩 교체 | 일반 운영, 일시적 용량 감소 감수 |
| Immutable | 새 인스턴스 그룹을 만들고 전환 | 안전한 프로덕션 배포 |
| Blue/Green | 별도 환경을 만들고 DNS/트래픽 전환 | 빠른 롤백과 배포 검증 |
.ebextensions는 Beanstalk 환경을 커스터마이징하는 방법이다. 다만 설정이 복잡해질수록 "PaaS로 단순하게 간다"는 장점이 줄어든다. 반복 가능한 인프라가 중요하다면 CloudFormation, CDK, Terraform 같은 IaC로 경계를 옮기는 편이 낫다.
8. 메시징: SQS, SNS, SES를 섞어 쓰지 않는다
세 서비스는 이름이 비슷하지만 목적이 다르다.
| 서비스 | 모델 | 사용 예 |
|---|---|---|
| SQS | Queue, pull | 주문 처리, 이미지 변환, 비동기 작업 버퍼 |
| SNS | Topic, push | 이벤트 fan-out, 이메일/SMS/HTTP/SQS 알림 |
| SES | Email service | 트랜잭션 메일, 대량 이메일 발송, 수신 처리 |
SNS와 SQS를 함께 쓰면 하나의 이벤트를 여러 큐로 나눠 독립적으로 처리할 수 있다. 이때 SQS 큐 정책이 SNS topic의 SendMessage를 허용해야 메시지가 들어온다.
SQS는 "메시지가 한 번만 처리된다"는 착각을 조심해야 한다. Standard 큐는 높은 처리량 대신 중복 가능성과 순서 미보장을 전제로 둔다. 정확한 순서와 중복 제거가 중요하면 FIFO 큐를 검토하지만, 처리량과 설계 제약을 함께 봐야 한다.
9. 관측과 보안: CloudWatch, X-Ray, OpenTelemetry, KMS
CloudWatch는 로그와 지표, 알람의 기본이다. X-Ray는 분산 추적을 시각화하는 데 유용하지만, 새 계측은 OpenTelemetry를 중심에 두고 X-Ray는 trace backend 중 하나로 연결하는 관점이 더 현대적이다.
| 관측 데이터 | 확인할 것 |
|---|---|
| Logs | 요청 ID, 사용자/tenant 단서, 오류 stack, structured logging |
| Metrics | latency, error rate, saturation, queue depth, throttling |
| Traces | 서비스 간 호출, 병목, downstream 오류 |
| Alarms | 사용자가 느끼는 증상에 가까운 지표 중심 |
KMS는 "직접 데이터를 모두 암호화하는 서비스"가 아니라, 키를 안전하게 관리하고 데이터 키를 보호하는 서비스다. 대용량 데이터는 보통 envelope encryption으로 처리한다.
KMS key를 만들 때는 관리자와 사용자를 분리한다. 키 관리자는 회전, 정책, 삭제 예약을 다루고, 키 사용자는 암호화와 복호화만 수행한다. 실습 후 customer managed key를 삭제 예약할 때는 최소 대기 기간이 있으므로 비용과 의존성을 확인한다.
10. IaC: CloudFormation과 SAM으로 반복 가능하게 만든다
콘솔 실습은 구조를 이해하기 좋지만, 같은 환경을 다시 만들 수 없다면 운영 지식으로 이어지기 어렵다. CloudFormation은 AWS 리소스를 YAML/JSON 템플릿으로 정의하고, SAM은 Lambda/API Gateway/DynamoDB 같은 서버리스 리소스를 더 간결하게 표현한다.
| 도구 | 역할 |
|---|---|
| CloudFormation | AWS 리소스 전체를 스택으로 생성, 변경, 삭제 |
| Nested Stack | 공통 리소스 또는 큰 템플릿을 모듈처럼 분리 |
| SAM | 서버리스 애플리케이션을 CloudFormation 위에서 간결하게 정의 |
| CDK | TypeScript, Python 같은 언어로 CloudFormation 템플릿을 생성 |
| Change Set | 실제 적용 전에 어떤 리소스가 바뀌는지 확인 |
중상급 실습에서는 콘솔로 한 번 만들고 끝내지 말고, 다음 기준으로 정리한다.
- 콘솔에서 만든 리소스를 템플릿으로 다시 표현할 수 있는가?
- 삭제 순서와 보존해야 할 데이터가 템플릿에 드러나는가?
- IAM Role, Log Group, Alarm, KMS key 같은 주변 리소스도 함께 정의했는가?
- 스택 삭제 후 S3 bucket, ECR image, CloudWatch log, KMS key 예약 삭제까지 확인했는가?
실습 체크리스트
- [ ] IAM 정책 3종을 비교하고, 실습용 AWS 관리형 정책을 고객 관리형 최소 권한 정책으로 줄여 본다.
- [ ] Cognito User Pool의 managed login으로 Authorization Code + PKCE 흐름을 테스트한다.
- [ ] User Pool 토큰을 Identity Pool로 교환해 S3 특정 prefix에만 접근하는 임시 자격 증명을 만든다.
- [ ] S3 버킷의 기본 SSE-S3 상태를 확인하고, SSE-KMS 강제 버킷 정책을 따로 실험한다.
- [ ] S3 CORS 오류와 IAM 권한 오류를 브라우저 네트워크 탭에서 구분해 본다.
- [ ] DynamoDB 테이블을 On-demand로 만들고, 같은 접근 패턴을 Provisioned RCU/WCU로 계산해 본다.
- [ ] TTL 항목을 만들고 삭제가 즉시 일어나지 않는다는 점을 쿼리 결과로 확인한다.
- [ ] Lambda version과 alias를 만들고
prodalias만 외부 트리거에 연결한다. - [ ] Lambda를 VPC에 연결한 뒤 NAT Gateway 또는 VPC Endpoint가 필요한 호출을 구분한다.
- [ ] API Gateway HTTP API와 REST API를 각각 만들어 기능과 비용 차이를 비교한다.
- [ ] Step Functions Standard와 Express 중 하나를 골라 재시도와 실패 분기를 모델링한다.
- [ ] SQS Standard 큐와 FIFO 큐의 중복, 순서, 처리량 차이를 작은 consumer로 확인한다.
- [ ] SNS topic이 SQS queue에 메시지를 보낼 수 있도록 queue policy를 직접 작성한다.
- [ ] Docker 이미지를 CodeBuild에서 빌드해 ECR에 Git SHA 태그로 푸시한다.
- [ ] ECS Fargate task execution role과 task role을 분리해 권한 오류를 의도적으로 재현해 본다.
- [ ] CodePipeline 또는 GitHub Actions OIDC로 장기 Access Key 없는 배포를 구성한다.
- [ ] Elastic Beanstalk 배포 전략을 비교하고, 실습 후 환경과 S3 애플리케이션 버킷을 정리한다.
- [ ] X-Ray SDK 대신 OpenTelemetry 계측을 검토하고 CloudWatch/X-Ray에서 trace를 확인한다.
- [ ] KMS customer managed key를 만들고, key administrator와 key user 권한을 분리한다.
- [ ] CloudFormation 또는 SAM으로 실습 리소스를 다시 만들고, Change Set을 확인한 뒤 삭제한다.
이 프로젝트에서 이어서 읽을 문서
| 더 알고 싶은 것 | 이어서 읽기 |
|---|---|
| AWS 기본 서비스 복습 | 14. AWS 입문 핵심 로드맵 |
| DynamoDB와 IAM 기본 | 05. DynamoDB와 IAM |
| S3와 CloudFront 기본 | 02. S3, 06. CloudFront와 CloudWatch |
| VPC, IAM, 시크릿 운영 | 12. AWS 네트워킹과 보안 |
| ECS Fargate 배포 | 13. Docker와 ECS Fargate 배포 |
| Elastic Beanstalk과 Lightsail | 09. Elastic Beanstalk과 Lightsail |
출처와 검증 기준
- 원문 자료:
ing-0021-aws-중상급.md - AWS 공식 문서: Cognito managed login과 identity pools, S3 default encryption과 performance guidelines, DynamoDB capacity mode와 TTL, Lambda VPC/version/alias, Step Functions workflow type, X-Ray SDK maintenance notice, KMS key concepts, CodeCommit 문서 이력