AWS 헷갈리는 개념 및 서비스들

#개발자의도구들 #AWS비슷한서비스 #aws헷갈리는

​

참고: Exam Topic Disscussion

문제 찾는법 : 여기 최하단

비슷한 서비스 모아서 정리

DVA-C02에 자주 등장하는 헷갈리는 서비스를 모아서 정리하자.

​

🥊 Cloud watch vs X-ray

API Gateway 로그를 확인하는 방법

API Gateway의 단일 오류를 찾아보려면 Cloud watch의 Access Logs, Execution Logs를 수동적으로 켜줘야 한다.

X-ray는 단일 로그를 찾는 것보다는 전체 시스템의 요청 흐름 파악에 유리

​

​

📌 CloudTrail

• AWS 계정 내 API 호출 기록 (감사 & 보안 추적)
• API 호출 이벤트(누가, 언제, 어떤 서비스 호출 했는지)
• AWS 서비스 전반

​

👉 "누가 IAM 정책을 변경했는지?", "어느 계정에서 S3버킷 삭제 요청을 했는지?"

​

• S3 버킷에 로그를 저장할 수 있다.

🥊 environment parameter vs entryPoint parameter

컨테이너 실행 환경을 다룰 때 등장하는 개념

​

📌 environment parameter

정의: 실행되는 컨테이너 안에 전달되는 환경 변수

용도: 애플리케이션 실행 시 동작에 필요한 설정값 전달

                                    environment:
  - name: DB_HOST
    value: mydb.example.com
  - name: DB_USER
    value: admin

→ 컨테이너 내부 애플리케이션이 process.env.DB\_HOST, System.getenv("DB\_HOST") 같은 방식으로 접근

​

특징

• 애플리케이션 동작을 외부 설정값으로 제어

​

📌 entryPoint parameter

정의: 컨테이너가 시작될 때 실행되는 최초 명령어

용도: 컨테이너가 어떤 프로세스를 실행할지 지정

                                    ENTRYPOINT ["python", "app.py"]

→ 컨테이너가 뜨면 무조건 python app.py를 실행한다.

​

특징

• 실행 파일/스크립트 지정
• Dockerfile의 ENTRYPOINT 또는 ECS/k8s에서 entryPoint로 override 가능하다

​

🥊 Service Definition vs Task Definition

AWS ECS, Fargate에서 혼동 개념으로 등장

​

📌 Task Definition

역할: ECS에서 실행할 컨테이너 블루프린트(템플릿)

포함:

1. 어떤 Docker 이미지 사용?
2. 실행할 커맨드
3. 환경 변수
4. CPI/메모리 리소스 할당량
5. 포트 매핑
6. IAM Role, 로그 설정 등

​

👉 즉, "한 개 또는 여러 컨테이너를 어떻게 실행할지 정의한 설계도"

​

📌 Service Definition

역할: Task를 어떻게 배포하고 유지할지 제어하는 실행 관리자

포함:

1. 어떤 Task Definition 버전을 사용할지
2. 몇 개의 Task를 유지할지 (desiredCount)
3. 배포 전략 (rolling update, blue/green)
4. 로드 밸런서 연결 (ALB/NLB)
5. 서비스 디스커버리

​

👉 즉, "Task 몇 개 띄우고, 어떤 방식으로 계속 살아있게 유지할지"

​

​

​

🥊 CloudFormation DeletionPolicy Attribute vs Cloud Formation Stack Policy

📌 CloudFormation DeletionPolicy Attribute

대상: 리소스 단위 (개별 S3 Bucket, RDS, DynamoDB Table 등)

목적: 스택 삭제(Stack delete) 시, 해당 리소스를 어떻게 처리할지 결정

옵션:

-

• Delete(기본값): 스택 삭제시 리
• 소스도 같이 삭제
• Retain: 리소스는 그대로 유지(스택만 삭제)
• SnapShot: 삭제전 스냅 샷 생성

                                    Resources:
  MyDB:
    Type: AWS::RDS::DBInstance
    Properties:
      DBInstanceClass: db.t3.micro
      Engine: mysql
    DeletionPolicy: Snapshot

​

📌 CloudFormation Stack Policy

대상: 스택 전체

목적: 스택 업데이트(Update Stack) 시, 특정 리소스가 잘못 수정/삭제되는 것을 보호

구조: IAM 정책과 유사한 JSON

동작:

-

• Deny/Allow로 특정 리소스에 대한 Update/Delete 방지
• 실수로 중요한 리소스를 업데이트하는 것을 막는다.

                                    {
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "Update:*",
      "Principal": "*",
      "Resource": "LogicalResourceId/MyDB"
    }
  ]
}

​

🥊 Lambda 에러 디버깅

기본적으로 Lambda 호출시에 오류가 발생하면 cloud watch에 자동으로 로그가 기록된다. 하지만 비동기 호출시 오류가 발생하면 다음 솔루션을 사용한다.

​

📌 Dead Letter Queue (DLQ)

• 비동기 호출시 지원 (S3, SNS, EventBridge 등이 Lambda를 비동기 호출 했을 때)
• 지원 서비스 : SQS, SNS
• 실패한 이벤트를 payload 원본만 보관

​

장점: 단순하고 안정적이다. 실패한 이벤트를 나중에 수동으로 재처리 가능하다.

단점: 실패 사유, Lambda 실행 경로 등은 기록되지 않는다. 👉 CloudWatch Logs 같이 봐야 한다.

​

📌 Lambda Destinations

DLQ와 대부분 비슷하다.

두드러진 차이점: 성공/실패 + 디테일한 내용 저장가능

1. 성공시 결과 payload전달
2. 실패시 원인, 에러 메시지, 이벤트까지 함께 전달 가능
3. SQS, SNS 뿐 아니라 EventBridge, Lambda까지 호출 가능하다.

​

풍부한 메타데이터 제공으로 디버깅에 유리. 단 설정이 좀 복잡해진다.

​

​

​

🥊 RDS Read Replica vs Multi-AZ Deployment vs RDS Proxy

📌 Read Replicas

• 목적: 읽기 성능 개선을 위해서
• 동작:
• 기본(Primary) DB의 데이터를 비동기 복제
• SELECT 쿼리(읽기 전용 트래픽)를 Replica로 분산 → 읽기 처리량 증가
• 특징:
• 최대 15개
• 약간의 Latency
• Replicas를 Promote하여 독립된 DB로 승격 가능하다.

​

👉 "읽기 많은 애플리케이션을 위해 읽기전용 DB 생성"

​

📌 Multi-AZ Deployment

• 목적: 고가용성
• 동작:
• 기본(Primary) DB와 Standby DB를 동기식 복제(Synchronous Replication)
• Primary 장애 시 자동으로 Standby로 failover
• 특징:
• 성능 향상은 크게 없다.
• 쓰기/읽기 모두 Primary에서만 처리한다.

​

👉 "장애 대응이 주 목적"

​

📌 RDS Proxy

• 목적: DB연결 관리 + 보안/성능 최적화
• 동작:
• 애플리케이션과 RDS 사이에 프록시 계층을 두어 DB 커넥션 풀링
• Lambda, Fargate 같은 짧은-lived 커넥션 많은 환경에서 유용
• 특징:
• DB 자원 효율적 사용 → 연결 폭증으로 인한 DB 과부화 방지
• IAM 인증 통합, Secrets Manager 연동 지원
• 장애시 빠른 failover: 기존 커넥션 사용

​

👉 "DB에 연결된 Lambda가 너무 많아 지연이 일어남"

​

🥊 SAM CLI 주요 명령어

문제: 로컬에서 API Gateway 환경을 흉내내어 테스트가 필요하다. 단순 Lambda 실행이 아닌 REST API 호출 흐름을 시뮬레이션 하고 싶다.

​

📌 SAM 주요 명령어 모음

sam local invoke:

• ​개별 Lambda 함수를 직접 실행
• JSON 이벤트 파일을 넣고 함수 결과 확인 가능

​

sam local invoke

• 개별 Lambda 함수를 직접 실행한다.
• Json 이벤트 파일을 넣고 함수 결과 확인 가능

👉 Lambda 함수만 테스트 하고 싶다.

​

sam local generate-event

• 샘플 이벤트(Json)를 생성 (S3 Put, API Gateway Proxy event 등)
• 단독으로 실행하는 명령어는 아니다.

👉 테스트 이벤트 JSON 생성기

​

sam local start-lambda

• 로컬에서 Lambda 앤드포인트를 띄운다.
• 다른 SDK/클라이언트가 이 엔드 포인트를 호출해서 Lambda 테스트 가능하다.

👉 Lambda 전용 엔드포인트

​

sam local start-api

• 로컬에서 API Gateway를 시뮬레이션
• curl http://127.0.0.1:3000/myapi 로 REST API 호출 테스트 가능

👉 API Gateway 전체 호출 테스트(REST API)

🥊배포전략 용어들

📌 In-house 배포

방법

• 개발팀이 직점 Lambda 버전을 Publish
• alias를 새 버전에 매핑하거나, weighted alias를 수동으로 조정한다.

​

특징

• 완전 수동 또는 자체 스크립트/CI 파이프라인으로 동작
• Weighted Alias를 이용하면 간단한 트래픽 분배는 가능하다.
• 점진적 증가/ 자동 롤백 등 직접 구현 필요

​

📌 CodeDeploy 배포 전략

방법​

• AWS CodeDeploy와 Lambda를 통합한다.
• 배포 시 alias를 대상으로 트래픽 전환 전략(Deployment Config) 지정

​

🚀 지원전략

• Canary: 일정 비율만 먼저 새 버전에 전송 후, 시간이 지나면 전체 전환
• 10% → 10분 후 100%
• Linear: 일정 시간 간격마다 일정 비율씩 점진적 전환
• All-at-once: 한번에 100% 트래픽 전환
• in-place: 기존 실핼 중인 서버에 새 애플리케이션 버전을 덮어씌우는 방식
• 동작 순서(기출)

1. ApplicationStop
2. BeforeInstall: 새 앱을 설치하기 전에 필요한 준비 작업 수행
3. AfterInstall: 새 앱을 설치 후 구성 변경 후 추가 작업 실행
4. ApplicationStart

​

추가기능

• CloudWatch Alarms와 연동 → 에러 발생시 자동 롤백
• 배포 상태 추적 및 관리 로그 자동화

​

🤔 Canary vs Linear

두 서비스는 서로 비슷해 보인다. 확실한 차이는 무엇인가?

​

Linear의 경우 일정 시간마다 고정된 비율씩 트래픽을 점진적으로 전환한다.

​

Canary = 빠른 실험, 소규모 검증 후 전체 전환 (속도 ↑, 위험 ↑)

Linear = 점진적 전환, 안정성 확보에 좀 더 유리 (속도 ↓, 안정성 ↑)

​

🥊Elastic Cache 비교

AWS 관리형 인메모리 캐시 서비스이다.

지원엔진: Redis, Memcached

​

📌 Redis

데이터 구조

• String, Hash, List, Set, Sorted Set 등 복잡한 자료구조 지원
• 정렬, 랭킹 같은거 가능
• 세션 스토어 가능

​

영속성

• 스냅샷, AOF 등 지원 → 재시작시 데이터 유지 가능

​

Multi-AZ & 복제

• 지원, 리플리케이션, Multi-AZ, failover

​

Clusting

• 샤딩/클러스터링 지원 → 수평 확장 가능

​

보안: IAM 통합, AUTH 명령어로 인증

​

​

⚙️ "단일 스레드" 기반

​

🚀 어디에 사용되는가?

세션 저장소, 실시간 분석, 큐, 리더 보드, pub/sub, 캐시

​

📌 Memcached

데이터 구조

• 단순 Key-Value (문자열 기반)

​

• 영속성, Multi-Az & 복제: ❌ 지원 안함
• 샤딩은 지원

​

⚙️ "멀티 스레드" 기반

• CPU 활용을 잘한다.
• 빠르고 확장성이 좋다.
• 다중 노드 사용이 가능하다는 의미
• memcached는 분산 캐시 구조
• 트래픽이나 데이터가 늘어날 때 노드를 수평 확장 해서 처리량을 늘린다.

​

🚀 어디에 사용되는가?

단순 캐시(읽기 중심), 단순 쿼리 결과 캐시

세션 데이터를 저장해서 웹 서버 인스턴스가 공유 할 수 잇다.

→ Redis를 더 자주 쓰긴한다.

​

📌 Redis 모드 종류

​

⚙️ Cluster Mode Disabled (비클러스터 모드)

• 하나의 Primary(Writer) 노드
• 선택정으로 여러개의 Replica(Reader) 노드

​

모든 쓰기 연산은 Primary에서만 처리한다. 즉, 쓰기 확장은 불가능 하다.

읽기는 Replica로 분산이 가능하다. = 읽기 확장 가능하다는 의미

Multi-AZ 지원 (Primary 장애 시 Replica가 승격)

데이터 샤딩 없음 : 데이터는 모두 Primary에 저장

​

🚀 사용예시

세션 저장소, 캐시 (읽기 부하가 크고 쓰기 부하는 적음), 단일 노드 내에서 자료구조 기능(Hash, Set, Sorted Set)활용

​

⚙️ Cluster Mode Enabled (클러스터 모드)

• 데이터를 여러 샤드(Shard)로 분산 저장
• 각 샤드는 Primary + Replicas 구조

​

쓰기/읽기 모두 수평 확장이 가능하다, 샤드 단위로 분산처리를 하기 때문

대규모 데이터 저장가능

데이터는 자동 샤딩

단, 복잡성이 증가한다.

​

🚀 사용예시

초당 요청 수가 매우 많은 대규모 애플리케이션, 랭킹 서비스 같은 대규모 데이터 집계, 고가용성과 확장성을 동시에 요구하는 경우

🥊S3 스토리지 클래스(Tier)

📌 S3 Standard

용도: 자주 접근하는 데이터 (핫 데이터)

내구성: 99.99999999999% (11 9's)

가용성: 99.99%

특징: 멀티 AZ에 자동 복제

비용: 가장 비쌈

🚀 예시

웹 앱의 정적 콘텐츠, 자주 조회되는 데이터

​

​

📌 S3 Standard-IA (Infrequent Access)

용도: 자주 쓰지 않지만 필요할 때는 빠르게 접근해야 하는 데이터

내구성: 99.99999999999% (11 9's)

가용성: 99.9%

특징: S3보다 저렴, 단 조회 시 추가 요금 발생

🚀 예시

백업, DB 데이터

​

📌 S3 One Zone-IA

용도: 자주 접근하지 않고, 재생성 가능한 데이터

내구성: 99.99999999999% (11 9's)

가용성: 99.5%

특징: 단일 AZ에만 저장 : 저렴하나 데이터 유실 위험

🚀 예시

로그, 캐시성 데이터

​

📌 S3 Intelligent-Tiering

용도: 접근 패턴이 불규칙하여 특정할 수 없는 경우

특징:

-

• 자주 접근하면 Standard 요금
• 일정 기간 안 쓰이면 자동으로 IA 티어로 이동
• ML 기반으로 자동 최적화
• 자주 접근: S3 Standard
• 30일간 접근 안됨: S3 Standard IA
• 거의 접근이 안됨: Glacier Instant Retrieval
• 수개월 이상 접근 안됨: Glacier Flexible Retrieval
• 장기간(수년) 접근 안됨: Glacier Deep Archive

🚀 예시

데이터 사용 패턴을 예측하기 어려운 워크로드

​

📌 S3 Glacier Instant Retreval

용도: 거의 접근하지 않지만, 필요할 땐 즉시 조회해야 하는 데이터

특징:

-

• 조회시간: 밀리초

​

🚀 예시

의료기록, 미디어 콘텐츠 아카이브

​

​

📌 S3 Glacier Flexible Retrieval

용도: 장기 보관, 저렴한 비용

특징:

-

• 조회 시간: 몇 분 ~ 몇 시간 (Expedited / Standard / Bulk 옵션)

🚀 예시

콜드 데이터, 감사 로그

​

📌 S3 Glacier Deep Archive

용도: 최저 비용, 장기 아카이브 (7~10년 이상 보관 데이터)

특징:

-

• 조회 시간: 몇 시간 (12~48시간)
• Standard retrieval : 약 12시간
• Bulk retrieval: 최대 48시간

🚀 예시

법적 규제 보관 데이터, 기록 보관소

​

🥊SAM 관련 모르는 거

질문: 새로운 테스트 환경(prod, dev, staging ... 등)이 발생할 때마다 새로운 환경에 템플릿을 직접 복사, CLI의 파라미터를 직접 입력하지 않도록 하는 솔루션?

​

📌 TOML

• SAM은 samconfig.toml 파일을 지원해서, 환경별 설정을 그룹화할 수 있다.

                                    [default.deploy.parameters]
stack_name = "myapp-dev"
region = "us-east-1"

[test.deploy.parameters]
stack_name = "myapp-test"
region = "us-east-1"

[staging.deploy.parameters]
stack_name = "myapp-staging"
region = "us-east-1"

개발자는 아래 명령어를 입력하여 환경별로 실행 가능

                                    sam deploy --config-env test
sam deploy --config-env staging

​

Secret store 판단

📌 Secret Manager

• 비밀 관리 전용 서비스
• 자동 암호화/복호화(KMS), 암호 회전(rotation)
• at rest/ in transit 암호화 제공
• resource-based policy로 cross-account access 지원
• EC2 IAM Role로 바로 접근 가능
• 관리 오버헤드 최소

​

🚀 비밀 관리 전용 (DB 암호, API 토큰, 키 등), 문자열 및 JSON

​

📌 System Manager Parameter Store

• at rest/ in transit 암호화 제공
• 비용이 매우 저렴하다
• ❌ rotation 지원 안함
• ❌ resource-based policy로 cross-account access 지원안함
• SecureString시 KMS (AWS managed / CMK) 사용이 가능하다.

​

🚀 설정값(Configuration) 및 일반적인 파라미터 저장할 때 사용한다.

​

​

Back off 솔루션

등장하는 곳

: Lambda 비동기 호출, DynamoDB Batch 쿼리 시, SNS, SQS 전송 재시도, Step Function Retry 정책 등

​

솔루션: exponential back-off를 사용하여 요청 retry를 지연

: 2초 대기 → 4초 대기 → 8초 대기 → 16초 대기 ...

​

read capacity를 늘리는 방법도 고려

• Lambda는 직접 업그레이드 ​불가능
• 할당 메모리에 비례해서 CPU/네트워크 리소스가 자동 할당된다.
• DynamoDB
• Provisioned read capacity 증설
• 경우에 따라 DAX를 사용하기도

​

​

Cognito

사용자 인증 + 권한 관리 서비스

• 웹/모바일 애플리케이션에 로그인 기능, 세션 관리, 소셜 로그인, SAML 연동 등을 쉽게 추가 가능

​

📌 User Pools

• 사용자 인증(Authentication) 담당
• Conito 자체가 ID 제공자(IdP) 역할
• 기능:
• 회원가입/로그인 관리
• 비밀번호 정책, 이메일/휴대폰 검증
• MFA 지원
• OAuth 2.0 / OpenID Connect / SAML 연동
• 소셜 로그인 지원: Google, Facebook, Apple 등
• 결과: 사용자 인증 후 JWT 토큰(ID, Access, Refresh Token) 발급

​

📌 Identity Pools (Federated Identities)

• 권한 부여(Authorization) 담당
• 기능:
• 인증된 사용자에게 IAM Role 매핑
• Cognito User Pool, SAML, IdP, 소셜 IdP 등 다양한 IdP에서 온 사용자 통합
• 인증된 사용자 → AWS 리소스 접근
• *비인증 사용자**(Guest Access)*도 지원
• 결과: STS를 통해 임시 AWS 자격 증명 발급

​

Lambda 연결

Lambda 연결되는 서비스는 너무 많으니 불가능한 서비스 위주로 정리해보자.

​

📌 Lambda 트리거 불가능한 주요 서비스들

• Amazon RDS (MySQL, PostgreSQL 등 표준 RDS 인스턴스)
• RDS는 Lambda를 직접 호출할 수 없음
• 단, RDS Proxy, Aurora 는 호출이 가능하다.
• Amazon Redshift

​

• Amazon EBS/EFS
• Amazon NLB
• ALM는 호출이 가능
• HTTP기반 요청을 Lambda 전달 가능함.
• EC2 인스턴스
• EC2 자체가 Lambda를 호출하지 못한다.
• EventBrdige(CloudWatch Events)가 EC2 상태 변경 이벤트를 받아 Lambda 트리거 가능

​

🚀 직접 트리거 불가 : EventBridge를 경유해야한다. : 이벤트를 받아서

​

⚠️ DynamoDB

• 직접 연결은 불가
• DynamoDB Streams를 사용해야한다.
• 테이블에서 발생하는 모든 변경 사항(INSERT, UPDATE, DELETE)을 캡처하는 로그 스트림
• Lambda는 이 Streams를 이벤트 소스로 연결할 수 있다.
• 테이블에서 레코드 변경시 Streams → Lambda 트리거

​

​

Lambda 버전관리

Lambda 함수는 코드를 수정하거나 환경 구성을 변경할 때 마다 새로 Publish 해서 버전을 만들 수 있다.

​

• 각 버전은 불변이다.
• $Latest 버전읜 제외: 항상 가장 최근 수정된 코드
• 정식 프로덕션 배포시에는 버전을 정확하게 명시할 것!

​

📌 Alias

• Alias = 특정 버전을 가리키는 포인터
• 개발자/운영자가 직접 이름을 붙일 수 있음 (예: dev, test, prod)

​

함수 호출 시 직접 버전 번호 대신 Alias 이름을 사용한다 : 코드 변경 없이 배포 버전 교체가 가능하다.

​

Weighted alias (가중치 분배)

• 하나의 alias가 여러 버전을 동시에 가리킬 수 있다.
• 예:
• prod alias → v2(90%) + v3(10%)
• 이를 이용해 Canary 또는 Linear 배포 시나리오 구현 가능.

​

​

Lambda Layer

목적: 코드/라이브러리 중복을 최소화를 최소화 하자

​

📌 Lambda Layer

Lambda Layer는 여러 Lambda 함수에서 공통으로 사용하는 코드나 라이브러리르 모아두는 별도의 배포 단위이다.

​

장점

• 한 번 패키징한 라이브러리를 여러 함수에서 재사용 가능
• 함수 배포 시 라이브러리를 중복 포함하지 않아도 된다.

​

                                    👉 request, numpy 같은 라이브러리를 Layer로 만들고 모든 함수가 참조

arn:aws:lambda:region:account:layer:my-shared-lib:1

​

KMS (SSE, CSE/)

KMS는 중앙에서 키를 생성/관리/회전하는 서비스이다. 대부분의 AWS 서비스(S3, RDS, DynamoDB, Lambda)와 연동 가능하다.

​

📌 SSE

• AWS 서비스(서버 측)에서 암호화 처리
• 데이터가 AWS 서비스에 저장될 때 자동 암호화

​

🚀 기출 문제 (S3를 기준으로)

🔑 SSE-S3 (AES-256)

• AWS가 자체적으로 관리하는 키 사용
• 설정
• x-amz-server-side-encryption: AES256
• 운영 부담 최소

​

👉 "AES-256", "S3 manages keys", "least overhead"

​

🔑 SSE-KMS

• AWS KMS의 CMK를 사용한다.
• 장점: KeyRotation, Audit, Access Control (IAM + KMS Policy)
• 단점: KMS API 호출 비용 발생

​

👉 "KMS integration", "Granular access control", "CloudTrai lAudit logs"

​

🔑 SSE-C (Customer-Provided Keys)

• 고객이 직접 키를 제공 → S3는 해당 키로 암호화 후 즉시 폐기
• 키는 S3에 저장되지 않는다 : ​항상 고객이 키를 관리해야함
• 운영 부담 커서 잘 안쓴다

​

👉 "Customer provides keys with each request"

​

​

📌 CSE

• 클라이언트 측에서 데이터 암호화 후 업로드
• AWS는 암호화된 상태 그대로 저장 → 서버는 평문에 접근 불가
• 키는 사용자가 직접 관리하거나, KMS를 통해 Data Key를 가져와서 사용 가능

​

👉 "데이터가 AWS에 도달하기 전에 반드시 암호화 되어야 한다"

​

📌 CMK (KMS key)

Customer Master Key

헷갈리는 용어라서 따로 정리하고자 한다.

​

• KMS 내부에서 동작
• 데이터 키를 생성/암호화하는 키 관리 단위이다.
• 데이터키: 데이터를 암호화 할 때 사용한 키
• 이걸 또 암호화 할 때 사용하는 키가 바로 CMK

​

⚠️ 실제 데이터를 암호화 할 때 사용하지 않는다.

​

리소스 프로비저닝

CloudFromation vs BeanStalk vs SAM

📌 CloudFormation

• IaC(Infrastructure as Code)
• 리소스 단위
• (EC2, S3, IAM 등 모든 AWS 자원 템플릿 화 가능)
• 사용방식:
• YAML/JSON 템플릿 작성
• stack 배포
• 매우 세밀하게 속성까지 모두 제어 가능
• 자동화 범위:
• 네트워크, 보안, 데이터, 앱 리소스 전부)
• 무제한 확장성
• 운영 부담이 매우 높다.

​

👉 "IaC", "모든 AWS 리소스 템플릿 화"

​

​

📌 Elastic Beanstalk

• PaaS
• 애플리케이션 환경 전체
• 코드 배포 + 인프라 자동 생성
• 사용방식
• 애플리케이션 코드 업로드
• ALB/EC2/ASG 등 프로비저닝
• 추상화 높다.
• 내부 리소스는 자동으로 생성
• 자동화 범위
• 배포, 모니터링, 스케일링까지 앱 환경만
• 제한적 확장 (주로 웹/백엔드 앱 중심)
• 낮은 운영 부담

​

👉 "운영부담 최소", "코드 업로드만"

​

​

📌 SAM

• Serverless 특화 IaC
• 서버리스 애플리케이션
• Lambda, API Gateway, DynamoDB, Step Functions 등
• 사용방식
• SAM Template(YAML)
• sam build, sam deploy : CLI배포
• 중간 수준의 제어
• 자동화 범위​
• 서버리스 앱 배포 + 로컬 테스트
• 서버리스 워크로드 전용
• 낮은 : 서버리스에 최적화

​

👉 "서버리스", "서버리스 배포, 로컬 테스트"

​

​

API Gateway 모음

상황: API Gateway에서 직접 Backend를 호출하지 않고 다양한 응답 테스트를 받고 싶다.

​

📌 Mock Integration

API Gateway에서 백엔드 서비스를 호출하지 않고, API Gateway자체에서 미리 정의된 응답을 반환하는 통합 유형

목적: 개발, 테스트, 시뮬레이션 단계에서 빠른 프로토타이핑 및 백엔드 의존성을 제거

​

간단한 hands-on 시뮬레이션

• API Gateway 콘솔 → API 선택
• 리소스/메서드 선택 (예: GET /items)
• Integration type → Mock 선택
• Method Response에서 원하는 상태 코드 추가 (200, 400 등)
• Integration Response에서 Mapping Template 작성 (예: JSON Body 정의)
• 배포 후 호출 시, 백엔드 없이 Mock 응답 반환

​

​