S(*). Architect

Lambda와 API Gateway

학습 목표handler·runtime·event/response 형식으로 Lambda 함수를 작성할 수 있다.execution role·resource policy로 Lambda·API Gateway 권한을 최소로 연결할 수 있다.REST API와 HTTP API 차이를 보고 신규 API에 적합한 타입을 고를 수 있다.Lambda proxy integration으로 API Gateway와 함수를 IaC(CDK) 로 배포할 수 있다.앞 편 Serverless 아키텍처 선택 기준을 구체 구현으로 이어갈 수 있다.문제 상황10편에서 sync API는 Lambda가 맞다고 했는데 — handler가 event 구조를 몰라 500만 반환API Gateway REST로 만들었더니 비용·설정이 과함 — HTTP AP..

Serverless 아키텍처

학습 목표Serverless가 서버 관리 위임·사용량 과금·이벤트 구동을 핵심으로 함을 설명할 수 있다.FaaS·event-driven 패턴으로 요청·비동기 워크로드를 설계할 수 있다.cold start·concurrency가 latency·비용에 미치는 영향을 설명할 수 있다.serverless vs container를 트래픽·팀·운영 축에서 비교할 수 있다.Part 2 CDK로 serverless 스택을 코드화할 준비를 할 수 있다.문제 상황트래픽 10배 차이 — EC2 24/7 과금, 야간 idle 80%“서버리스로 가자” — VPC Lambda ENI·cold start 3초 — API SLA 깨짐SQS 100만 메시지 — Lambda 동시성 한도·throttle — 설계 미스K8s Deploym..

학습 목표cdk synth·diff·deploy를 로컬·CI에서 안전한 순서로 실행할 수 있다.Template assertions·snapshot test로 synth 결과를 자동 검증할 수 있다.PR CI에서 synth·diff·test를, main에서 승인 후 deploy를 구성할 수 있다.bootstrap·asset·stack approval이 배포 파이프라인에 미치는 영향을 설명할 수 있다.Terraform plan file 승인 패턴과 CDK template diff 패턴을 대응시킬 수 있다.문제 상황cdk deploy를 로컬에서만 — PR에 template 변경이 안 보이고 리뷰 불가construct id 바꿨더니 S3 bucket replace — 테스트 없이 프로덕션 적용Jest는 있는데 ..

학습 목표Terraform과 CDK가 같은 IaC 철학(선언·멱등)을 공유하지만 엔진·상태가 다름을 설명할 수 있다.state file vs CloudFormation stack이 plan·drift·협업에 미치는 차이를 설명할 수 있다.plan/apply와 synth/diff/deploy 워크플로를 1:1로 대응시킬 수 있다.멀티 클라우드·팀 언어·추상화 관점에서 어느 쪽을 고를지 근거를 들 수 있다.두 도구를 공존시키는 패턴(terraform-cdk, 스택 분리)을 개괄할 수 있다.문제 상황Part 1 Terraform으로 S3·VPC·remote state를 잡았는데 — AWS만 쓰면 CDK가 낫다는 말만 듣고 기준이 없음CDK cdk diff는 익숙한데 terraform plan과 뭐가 다른지 —..

학습 목표L1·L2·L3 construct 계층과 언제 어떤 레벨을 쓰는지 설명할 수 있다.ec2.Vpc·lambda.Function 등 L2로 VPC·서브넷·NAT를 정의할 수 있다.IAM Role·PolicyStatement·grantRead 등으로 권한을 선언적으로 연결할 수 있다.L1 Cfn* 로 CloudFormation 속성에 직접 접근하는 이유를 설명할 수 있다.TypeScript·Python CDK 코드의 구조 차이를 읽고 작성할 수 있다.문제 상황6편에서 s3.Bucket 한 줄은 썼는데 — VPC 3 AZ·NAT는 L2 옵션이 뭔지 모름CloudFormation 문서의 속성 이름이 L2에 없어서 막힘 — L1로 내려가야 하나IAM 인라인 policy JSON을 CDK에 하드코딩 — gr..

학습 목표AWS CDK(Cloud Development Kit) 가 일반 purpose 언어로 인프라를 정의하는 방식임을 설명할 수 있다.App·Stack·Construct 계층과 부모-자식 관계를 설명할 수 있다.synthesis가 CDK 코드를 CloudFormation template으로 바꾸는 과정임을 설명할 수 있다.cdk synth·cdk deploy·cdk diff가 Terraform plan/apply와 어떻게 대응되는지 비교할 수 있다.Terraform과 CDK의 상태·배포 엔진 차이를 개괄적으로 설명할 수 있다.문제 상황CloudFormation YAML 3,000줄 — !Ref·!GetAtt 추적이 지옥VPC·RDS·Lambda를 복사 붙여넣기 — 파라미터 하나 바꿀 때 전 스택 di..

학습 목표dev·staging·prod 환경을 Terraform으로 분리하는 대표 패턴을 비교할 수 있다.workspace와 directory per environment의 trade-off를 설명할 수 있다.terraform.tfvars·-var-file·TF_VAR_*로 환경별 변수를 주입할 수 있다.backend key·state 분리와 환경 전략을 함께 설계할 수 있다.실무에서 같은 module·다른 env 구조를 잡을 수 있다.문제 상황main.tf에 bucket = "myapp-prod" 하드코딩 — staging apply 시 prod 이름 충돌terraform workspace select prod 했는데 VPC가 dev와 공유 — workspace만 바꾸고 backend key는 그대로e..

학습 목표Terraform state가 멱등·plan·팀 협업에 왜 필요한지 설명할 수 있다.local state와 remote state(S3 등) ·state locking 차이를 설명할 수 있다.module로 인프라를 재사용하고 root module에서 variable·output으로 연결할 수 있다.terraform init 시 module source·backend 마이그레이션 흐름을 설명할 수 있다.state 민감 정보·충돌 위험과 실무 운영 습관을 짚을 수 있다.문제 상황동료와 같은 VPC를 각자 terraform apply — 리소스 이중 생성·state 덮어쓰기terraform.tfstate를 Git에 커밋 — RDS password가 평문 노출laptop state만 있어 CI appl..

학습 목표Terraform Core, provider, resource의 역할을 구분할 수 있다.HCL 파일 구조(terraform / provider / resource 블록)를 읽고 작성할 수 있다.terraform init, plan, apply, destroy가 각각 무엇을 하는지 설명할 수 있다.resource address(aws_s3_bucket.artifacts)와 속성 참조(aws_vpc.main.id)를 사용할 수 있다.로컬 state로 최소 스택을 올리고 plan diff를 해석할 수 있다.문제 상황.tf를 작성했는데 terraform apply → "Please run terraform init" — provider·plugin이 없다provider "aws"만 쓰고 region을 ..

학습 목표IaC(Infrastructure as Code) 로 desired state를 버전·리뷰할 수 있음을 설명할 수 있다.Terraform plan·apply·state·drift 개념을 설명할 수 있다.GitOps — Git이 진실의 원천 — 와 push 배포의 차이를 설명할 수 있다.Argo CD Application·sync·reconcile 루프를 설명할 수 있다.PR 기반 manifest 변경·승인·자동 sync 흐름을 설계할 수 있다.문제 상황prod VPC·RDS를 콘솔로 만든 뒤 누가 무엇을 바꿨는지 감사 불가IaC·PR 없음staging kubectl apply와 prod 수동 apply — manifest가 다름drift·환경 불일치terraform apply state 없이 로..