빠른참조 · 2

헷갈리는 쌍 비교

후보가 둘로 좁혀졌을 때 어느 속성에서 갈리는지를 보는 페이지입니다. 각 표는 속성을 행에, 후보를 열에 놓았습니다. 요구사항에서 이름이 붙은 속성 하나만 찾으면 그 행에서 답이 결정됩니다.

같은 쌍을 시험이 노리는 지점의 관점으로 보려면 함정 사전으로 가십시오. 두 페이지의 역할은 아래에서 나눠 두었습니다.

이 페이지 쓰는 법

함정 사전과 이 페이지는 무엇이 다른가

같은 쌍을 다루지만 보는 방향이 반대입니다. 함정 사전은 시험지 쪽에서 출발해 "이 쌍에서 오답 선택지가 무엇을 뒤집는가"를 정리합니다. 이 페이지는 서비스 쪽에서 출발해 "두 서비스가 어느 속성에서 실제로 다른가"를 늘어놓습니다.

같은 쌍을 다루는 두 페이지의 역할 구분
구분 이 페이지 (헷갈리는 쌍 비교) 함정 사전
표의 구조 쌍 하나가 표 하나. 속성이 행, 후보가 열 쌍 하나가 행 하나. 결정적 차이 · 어느 쪽이 언제 · 노리는 지점이 열
담는 내용 확인된 속성값 — 복제 방식, 계층, 프로토콜, 개수 상한, 기본값 오답 선택지가 뒤집는 문장과 그 문장이 왜 틀리는지
쓰는 시점 개념을 정리할 때, 두 후보의 차이를 정확히 확인할 때 문제를 풀다 틀렸을 때, 시험 직전 오답 패턴을 복습할 때
다루는 범위 속성이 여러 개라 대조가 필요한 열두 묶음 혼동되는 쌍 전체를 넓게 훑습니다
헷갈리는 쌍 여섯 개와 각 쌍의 결정 질문 시험이 집요하게 노리는 혼동 쌍 여섯 개를 카드 여섯 장으로 배치하고, 각 카드에 그 쌍을 가르는 결정 질문 한 줄과 두 답을 적었습니다. 첫째 카드는 Multi-AZ 배포와 읽기 전용 복제본입니다. 가용성 문제인지 읽기 확장 문제인지를 물으면 갈립니다. 둘째는 보안 그룹과 네트워크 ACL 입니다. 인스턴스 경계인지 서브넷 경계인지, 거부 규칙이 필요한지가 기준입니다. 셋째는 ALB 와 NLB 입니다. HTTP 경로나 헤더로 라우팅해야 하면 ALB, TCP 나 UDP 를 다루거나 고정 IP 가 필요하면 NLB 입니다. 넷째는 LSI 와 GSI 입니다. 파티션 키를 테이블과 공유하면 LSI, 다른 파티션 키를 쓰면 GSI 입니다. 다섯째는 Secrets Manager 와 Parameter Store 입니다. 자격 증명을 자동으로 교체해야 하면 Secrets Manager 이고, 교체 요구 없는 설정값이면 Parameter Store 입니다. 여섯째는 게이트웨이 엔드포인트와 인터페이스 엔드포인트입니다. 대상이 Amazon S3 나 DynamoDB 면 게이트웨이 엔드포인트, 그 밖의 서비스면 인터페이스 엔드포인트, 즉 PrivateLink 입니다. 쌍을 외우는 것이 아니라 결정 질문을 외우는 것이 요령이라는 것이 이 한 장의 취지입니다. 쌍을 외우지 말고 각 쌍의 결정 질문을 외웁니다 Multi-AZ 배포 vs 읽기 전용 복제본 결정 질문 가용성 문제인가 읽기 확장 문제인가 가용성 → Multi-AZ 읽기 확장 → 복제본 보안 그룹 vs 네트워크 ACL 결정 질문 인스턴스 경계인가 서브넷 경계인가 인스턴스 → 보안 그룹 거부 규칙 → NACL ALB vs NLB 결정 질문 HTTP 경로 · 헤더로 라우팅해야 하는가 L7 라우팅 → ALB TCP · 고정 IP → NLB LSI vs GSI 결정 질문 파티션 키를 테이블과 공유하는가 키 공유 → LSI 다른 키 → GSI Secrets Manager vs Parameter Store 결정 질문 자격 증명을 자동으로 교체해야 하는가 교체 필요 → Secrets 설정값 → Parameter 게이트웨이 엔드포인트 vs 인터페이스 엔드포인트 결정 질문 대상이 S3 · DynamoDB 인가 그렇다 → 게이트웨이 그 외 → 인터페이스 문제문에서 결정 질문에 답할 단서를 먼저 찾으면 후보가 즉시 하나로 줄어듭니다
시험 직전 한 장 요약 — Multi-AZ 배포와 읽기 전용 복제본, 보안 그룹과 네트워크 ACL, ALB와 NLB, LSI와 GSI, Secrets Manager와 Parameter Store, 게이트웨이 엔드포인트와 인터페이스 엔드포인트를 각 쌍의 결정 질문 한 줄과 함께 배치합니다

데이터베이스

RDS Multi-AZ 배포 대 읽기 전용 복제본

복제 방식이 동기인가 비동기인가 하나에서 나머지가 모두 갈립니다. 동기 복제는 지연을 감수하고 데이터 손실을 없애므로 가용성 장치가 되고, 비동기 복제는 지연을 허용하는 대신 복제본을 여러 개 두고 읽기를 나눌 수 있게 합니다.

Amazon RDS Multi-AZ 배포와 읽기 전용 복제본의 속성 대조
속성 Multi-AZ 배포 읽기 전용 복제본
복제 방식 동기(synchronous) 비동기(asynchronous)
해결하는 문제 가용 영역 장애를 견디는 것 — 고가용성 읽기 부하를 나누는 것 — 성능 확장
대기·복제 인스턴스의 읽기 처리 받지 않음 — 대기 인스턴스는 트래픽을 처리하지 않습니다 받음 — 읽기 전용 질의를 처리합니다
엔드포인트 같은 엔드포인트를 유지하고 장애 조치 시 DNS가 대기 인스턴스를 가리킵니다 별도의 읽기 엔드포인트가 생기며 애플리케이션이 나눠 보내야 합니다
장애 조치 자동 자동 승격 없음 — 필요하면 수동으로 독립 인스턴스로 승격합니다
배치 범위 같은 리전의 다른 가용 영역 같은 리전 또는 다른 리전도 가능
가용 영역 지정 Multi-AZ 배포에서는 AvailabilityZone을 지정할 수 없습니다 배치 위치를 지정할 수 있습니다
개수 대기 인스턴스 하나 여러 개를 둘 수 있습니다
백업 설정 동기 복제된 대기 인스턴스가 있어 백업 중 지연 급증이 줄어듭니다 생성 시 백업이 비활성 상태로 만들어집니다. 원본은 백업 보존이 켜져 있어야 합니다
Amazon Aurora에서 클러스터가 여러 가용 영역에 걸친 스토리지를 씁니다 CreateDBInstanceReadReplica를 지원하지 않습니다 — 클러스터에 인스턴스를 추가합니다
고르는 신호 "가용 영역 장애에도 계속", "자동 장애 조치", "다운타임 최소화" "읽기 질의가 많아 느리다", "보고서 조회를 분리", "다른 리전에서도 읽어야"

DynamoDB LSI 대 GSI

파티션 키를 테이블과 공유하는가가 갈림길이고, 거기서 개수 상한 · 용량 · 생성 시점 제약이 전부 따라옵니다.

Amazon DynamoDB 로컬 보조 인덱스와 글로벌 보조 인덱스의 속성 대조
속성 LSI (로컬 보조 인덱스) GSI (글로벌 보조 인덱스)
파티션 키 테이블과 같아야 합니다 테이블과 달라도 됩니다
정렬 키 테이블과 다른 속성을 씁니다 임의로 지정합니다
테이블당 최대 개수 5개 20개
크기 제약 파티션 키 값당 10 GB 제약 없음
처리 용량 테이블의 용량을 함께 씁니다 자체 읽기·쓰기 용량을 따로 가집니다
생성 시점 테이블을 만들 때만 — 이후 추가·삭제할 API가 없습니다 운영 중 언제든 추가·삭제할 수 있습니다
읽기 일관성 강력한 일관된 읽기를 요청할 수 있습니다 최종적 일관성만 지원합니다
프로젝션 타입 KEYS_ONLY · INCLUDE · ALL — 두 인덱스 유형이 동일합니다. INCLUDE의 비키 속성은 모든 보조 인덱스를 통틀어 100개를 넘을 수 없습니다
고르는 신호 "같은 파티션 안에서 다른 순서로 조회", "강력한 일관성이 필요" "운영 중인 테이블에 인덱스를 추가", "다른 속성으로 조회"

네트워크와 접근 경로

보안 그룹 대 네트워크 ACL

적용 계층과 상태 저장 여부 두 가지가 축입니다. 나머지 차이는 이 둘에서 파생됩니다.

보안 그룹과 네트워크 ACL의 속성 대조
속성 보안 그룹 네트워크 ACL
적용 계층 인스턴스(ENI) 수준 서브넷 수준
적용 대상 연결된 인스턴스에만 연결된 서브넷의 모든 인스턴스에
규칙 종류 허용만 — 거부 규칙이 없습니다 허용과 거부 모두
평가 방식 모든 규칙을 평가합니다 가장 낮은 번호부터 순서대로 평가하고 먼저 일치한 규칙을 적용합니다
상태 상태 저장(stateful) — 반환 트래픽이 자동 허용됩니다 상태 비저장(stateless) — 반환 트래픽을 규칙으로 명시해야 합니다
임시 포트 고려 불필요 필요 — 응답이 돌아오는 임시 포트 범위를 아웃바운드에 열어야 합니다
출발지 지정 CIDR과 다른 보안 그룹 ID를 쓸 수 있습니다 CIDR만 쓸 수 있습니다
기본 동작 기본 보안 그룹은 서로에게 제한 없는 접근을 허용하는 규칙을 갖습니다 기본 네트워크 ACL은 모든 인바운드·아웃바운드를 허용합니다
고르는 신호 "특정 애플리케이션 계층만 접근", "웹 계층에서 앱 계층으로" "특정 IP 주소를 차단", "서브넷 전체에 공통 규칙"

게이트웨이 엔드포인트 대 인터페이스 엔드포인트

어디에 만들어지는가가 갈림길입니다. 게이트웨이 엔드포인트는 라우팅 테이블의 항목이고, 인터페이스 엔드포인트는 서브넷 안의 네트워크 인터페이스입니다. 그래서 지원 서비스 범위, 보안 그룹 적용 여부, 온프레미스에서의 도달 가능성이 모두 갈립니다.

VPC 게이트웨이 엔드포인트와 인터페이스 엔드포인트의 속성 대조
속성 게이트웨이 엔드포인트 인터페이스 엔드포인트 (AWS PrivateLink)
지원 서비스 Amazon S3와 Amazon DynamoDB 두 가지만 대부분의 AWS 서비스, 다른 계정이 제공하는 서비스 포함
구현 위치 라우팅 테이블의 경로 항목 서브넷 안의 네트워크 인터페이스(ENI)
생성 시 지정하는 것 라우팅 테이블 ID 서브넷 ID와 보안 그룹
보안 그룹 붙일 수 없음 붙일 수 있음
DNS 동작 접두사 목록으로 라우팅합니다 — DNS 이름은 그대로입니다 프라이빗 DNS로 서비스의 기본 이름을 엔드포인트의 사설 IP로 해석시킵니다
온프레미스에서 접근 불가 — VPC 라우팅 테이블에만 붙습니다 가능 — VPN이나 AWS Direct Connect를 통해 사설 IP로 도달합니다
피어링된 VPC에서 사용 불가 가능 — 엔드포인트의 사설 IP로 도달합니다
과금 축 추가 요금이 없습니다 엔드포인트 시간과 처리 데이터로 과금됩니다
엔드포인트 정책 두 유형 모두 붙일 수 있습니다. 리소스 기반 정책이며 권한을 부여하지 않고 통과 범위를 좁힙니다
고르는 신호 "S3 접근을 NAT 게이트웨이 밖으로", "추가 비용 없이 비공개 경로" "온프레미스에서도 사설 경로로", "S3와 DynamoDB가 아닌 서비스", "보안 그룹으로 통제"

ALB 대 NLB 대 GWLB

어느 계층에서 무슨 프로토콜을 다루는가가 전부입니다. HTTP 내용을 보고 판단해야 하면 ALB, 전송 계층에서 그대로 흘려보내야 하면 NLB, 보안 어플라이언스를 트래픽 경로에 끼워 넣어야 하면 GWLB입니다.

Application · Network · Gateway Load Balancer의 속성 대조
속성 Application Load Balancer Network Load Balancer Gateway Load Balancer
API 타입 값 application network gateway
동작 계층 L7 애플리케이션 L4 전송 L3 · L4 게이트웨이
지원 프로토콜 HTTP · HTTPS TCP · TLS · UDP · TCP_UDP · QUIC · TCP_QUIC GENEVE (포트 6081)
라우팅 판단 근거 경로 · 호스트 헤더 · HTTP 헤더 · 쿼리 문자열 · 출발지 IP 흐름 해시 — 내용을 보지 않습니다 어플라이언스로의 투명한 전달
고정 IP 제공하지 않습니다 — DNS 이름으로 접근합니다 가용 영역마다 정적 IP를 가지며 탄력적 IP를 붙일 수 있습니다 엔드포인트를 통해 트래픽을 받습니다
교차 영역 로드 밸런싱 기본값 켜짐 — 끌 수 없습니다 꺼짐 (변경 가능) 꺼짐 (변경 가능)
대표 용도 웹 애플리케이션, 마이크로서비스 경로 라우팅, 컨테이너 대상 극단적 처리량, 비 HTTP 프로토콜, 고정 IP 요구 서드파티 방화벽 · 침입 탐지 어플라이언스 삽입
고르는 신호 "URL 경로에 따라", "호스트 이름별로", "HTTP 헤더 기반" "수백만 요청", "게임 서버의 UDP", "정적 IP를 방화벽에 등록" "가상 어플라이언스를 통과시켜야"

CloudFront 대 Global Accelerator

둘 다 엣지 네트워크를 쓰지만 엣지에서 하는 일이 다릅니다. CloudFront는 콘텐츠를 캐시해서 돌려주고, Global Accelerator는 캐시하지 않고 백본으로 태워 보냅니다.

Amazon CloudFront와 AWS Global Accelerator의 속성 대조
속성 Amazon CloudFront AWS Global Accelerator
엣지에서 하는 일 콘텐츠를 캐시해 직접 응답합니다 캐시하지 않고 AWS 백본으로 전달합니다
대상 트래픽 HTTP · HTTPS TCP · UDP 전반
클라이언트가 보는 주소 배포의 도메인 이름 고정 애니캐스트 IP
엔드포인트 유형 S3 버킷, 로드 밸런서, 임의의 HTTP 오리진 Application Load Balancer, Network Load Balancer, EC2 인스턴스, 탄력적 IP
장애 대응 오리진 그룹으로 오리진 장애 시 전환합니다 엔드포인트 상태를 보고 다른 리전으로 즉시 전환합니다
비용 관점의 효과 캐시 적중이 오리진 송신량을 줄입니다 전송량을 줄이지는 않습니다 — 경로 품질을 개선합니다
보안 서비스 연동 AWS WAF를 배포에 직접 연결합니다 표준 디도스 보호가 적용되며, 웹 규칙은 뒤의 로드 밸런서 쪽에 붙입니다
고르는 신호 "정적 콘텐츠", "동영상 전송", "오리진 부하와 송신을 줄인다" "게임·음성 같은 UDP", "고정 IP를 허용 목록에", "리전 간 빠른 장애 조치"

스토리지

S3 스토리지 클래스 전체

선택 기준은 얼마나 자주 읽는가와 읽어야 할 때 얼마나 빨리 필요한가 둘뿐입니다. 여기에 최소 저장 기간과 최소 청구 크기라는 제약이 붙어, 짧게 두는 데이터를 차가운 클래스에 넣으면 오히려 손해가 나는 구간이 생깁니다.

SAA 출제 범위 S3 스토리지 클래스 — 가용 영역 수, 접근 시간, 최소 저장 기간, 최소 청구 크기
클래스 가용 영역 수 접근 시간 최소 저장 기간 최소 청구 크기 고르는 신호
S3 Standard 3개 이상 밀리초 없음 없음 자주 읽는 데이터. 지정하지 않으면 이 클래스입니다
S3 Intelligent-Tiering 3개 이상 밀리초 (아카이브 티어 제외) 없음 없음 접근 패턴을 모를 때. 자동으로 계층을 옮겨 줍니다
S3 Standard-IA 3개 이상 밀리초 30일 128 KB 드물게 읽지만 필요할 때 즉시 읽어야 하는 데이터
S3 One Zone-IA 1개 밀리초 30일 128 KB 다시 만들 수 있거나 원본이 따로 있는 데이터. 가용 영역 손실 시 데이터도 손실됩니다
S3 Glacier Instant Retrieval 3개 이상 밀리초 90일 128 KB 분기에 한 번 정도 읽지만 즉시 접근이 필요한 아카이브
S3 Glacier Flexible Retrieval 3개 이상 복원 필요 — 신속 1~5분, 대량 5~12시간 90일 40 KB 거의 읽지 않고 복원에 시간을 쓸 수 있는 아카이브
S3 Glacier Deep Archive 3개 이상 복원 필요 — 기본 12시간 180일 40 KB 규정 때문에 몇 년간 보존하지만 거의 읽지 않는 데이터
수명 주기 전환에 걸리는 제약 — 클래스 선택과 함께 봐야 하는 조건
제약 내용
30일 전환 제약 S3 Standard-IA 또는 S3 One Zone-IA로 전환하려면 객체가 최소 30일 저장되어 있어야 합니다. 버전 관리 버킷의 비현재 버전도 최소 30일 비현재 상태여야 합니다
128 KB 미만 객체 작은 객체는 전환되지 않습니다. 대량의 작은 객체를 차가운 클래스로 옮기려는 설계는 의도대로 동작하지 않습니다
최소 저장 요금 Standard-IA와 One Zone-IA는 30일 최소 저장 기간에 해당하는 요금이 부과됩니다. 자주 지우는 데이터에는 손해입니다

EFS 대 FSx 네 종류

EFS와 FSx는 성능 등급의 위아래가 아니라 서로 다른 파일 시스템입니다. 판단은 언제나 워크로드가 어떤 프로토콜과 어떤 생태계를 요구하는지에서 나옵니다.

Amazon EFS와 Amazon FSx 네 종류의 속성 대조
속성 Amazon EFS FSx for Windows File Server FSx for Lustre FSx for NetApp ONTAP FSx for OpenZFS
프로토콜 NFS SMB Lustre NFS · SMB · iSCSI NFS
주 클라이언트 리눅스 Windows 리눅스 HPC 노드 리눅스와 Windows 혼재 리눅스
디렉터리 통합 해당 없음 Active Directory 해당 없음 Active Directory 연동 가능 해당 없음
용량 쓰는 만큼 자동으로 늘고 줄어듭니다 생성 시 지정합니다 생성 시 지정합니다 생성 시 지정합니다 생성 시 지정합니다
배포 유형 리전 또는 단일 가용 영역 SINGLE_AZ_1 · SINGLE_AZ_2 · MULTI_AZ_1 SCRATCH_1 · SCRATCH_2 · PERSISTENT_1 · PERSISTENT_2 SINGLE_AZ_1 · SINGLE_AZ_2 · MULTI_AZ_1 · MULTI_AZ_2 SINGLE_AZ_1 · SINGLE_AZ_2 · SINGLE_AZ_HA_1 · SINGLE_AZ_HA_2 · MULTI_AZ_1
Amazon S3 연동 해당 없음 해당 없음 데이터 리포지토리로 연결해 객체를 파일처럼 읽고 결과를 내보냅니다 계층화 대상으로 쓸 수 있습니다 해당 없음
고르는 신호 "리눅스 여러 대가 같은 디렉터리" "Windows", "SMB", "Active Directory" "HPC", "기계 학습 학습", "S3 데이터셋으로 대규모 병렬 처리" "NFS와 SMB를 동시에", "기존 NetApp 운영 유지" "리눅스 NFS를 ZFS 스냅샷 기능과 함께"

볼륨 게이트웨이 캐시형 대 저장형

이름이 가리키는 것은 온프레미스 디스크의 역할입니다. 캐시형에서는 온프레미스 디스크가 캐시이고, 저장형에서는 원본 저장소입니다. 뒤집어 외우는 실수가 매우 흔하므로 이 한 문장만 붙잡으면 됩니다.

AWS Storage Gateway 볼륨 게이트웨이 두 유형의 속성 대조
속성 캐시형 볼륨(cached) 저장형 볼륨(stored)
주 데이터의 위치 AWS 온프레미스
온프레미스 디스크의 역할 자주 쓰는 데이터의 캐시 전체 데이터셋의 원본 저장소
AWS로 넘어가는 것 데이터 본체 비동기로 올라가는 스냅샷
온프레미스에 필요한 용량 전체 데이터보다 작아도 됩니다 전체 데이터를 담을 수 있어야 합니다
읽기 지연 캐시에 없는 데이터는 AWS에서 가져옵니다 전체 데이터에 로컬 속도로 접근합니다
해결하는 문제 온프레미스 스토리지를 늘리지 않고 용량을 키우기 로컬 접근 속도를 유지하면서 클라우드 백업 확보하기
공통 사항 둘 다 iSCSI 블록 볼륨으로 보이며, 스냅샷은 Amazon EBS 스냅샷으로 저장되어 EBS 볼륨으로 복원할 수 있습니다
고르는 신호 "온프레미스 스토리지 용량이 부족한데 장비를 늘리고 싶지 않다" "전체 데이터에 낮은 지연으로 접근해야 하고 백업만 클라우드로"

컴퓨팅 실행 모델

ECS 대 EKS 대 Fargate 대 Lambda

넷을 같은 줄에 놓으면 안 됩니다. Amazon ECS와 Amazon EKS는 오케스트레이터이고, AWS Fargate는 그 위에서 고르는 용량 제공 방식이며, AWS Lambda는 컨테이너 오케스트레이션과 무관한 별개의 실행 모델입니다. "ECS 대 Fargate" 라는 대립 자체가 성립하지 않습니다.

컨테이너 오케스트레이터 · 용량 제공 방식 · 함수 실행 모델의 속성 대조
속성 Amazon ECS Amazon EKS AWS Fargate AWS Lambda
범주 컨테이너 오케스트레이터 컨테이너 오케스트레이터 용량 제공 방식 — 단독으로 쓰지 않습니다 함수 실행 모델
배포 단위 태스크와 서비스 파드와 디플로이먼트 ECS 태스크 또는 EKS 파드 함수
API 표준 AWS 고유 Kubernetes 해당 없음 AWS 고유
인스턴스 관리 책임 EC2 시작 유형이면 우리 몫 관리형 노드 그룹을 써도 노드는 우리 몫 없음 — 인스턴스가 보이지 않습니다 없음
실행 시간 제한 없이 상주할 수 있습니다 제한 없이 상주할 수 있습니다 제한 없이 상주할 수 있습니다 호출당 최대 900초
과금 축 EC2 시작 유형이면 인스턴스 가동 시간 클러스터 시간과 노드 가동 시간 태스크·파드가 요청한 자원과 실행 시간 호출 수와 실행 시간, 할당 메모리
고르는 신호 "컨테이너를 굴려야 하는데 Kubernetes 요구는 없다" "Kubernetes", "기존 클러스터를 그대로" "인스턴스를 관리하고 싶지 않다" "이벤트에 반응", "간헐적 실행", "운영 부담 최소"

데이터 수집

Kinesis Data Streams 대 Data Firehose

데이터를 붙잡아 두는가, 흘려보내는가가 갈림길입니다. Data Streams는 레코드를 보존해 여러 소비자가 각자의 속도로 읽게 하고, Data Firehose는 버퍼에 모아 목적지에 적재하고 잊습니다.

Amazon Kinesis Data Streams와 Amazon Data Firehose의 속성 대조
속성 Amazon Kinesis Data Streams Amazon Data Firehose
기본 성격 보존되는 스트림 목적지로 흘려보내는 전송 스트림
데이터 보존 보존 기간 동안 남으며 다시 읽을 수 있습니다 적재 후 남지 않습니다 — 다시 읽으려면 목적지에서 읽습니다
전달 방식 소비자가 가져갑니다 서비스가 목적지에 넣어 줍니다
소비자 수 여러 애플리케이션이 같은 데이터를 각자 읽습니다 전송 스트림마다 목적지 하나
지연 특성 거의 즉시 읽을 수 있습니다 버퍼링 후 적재하므로 지연이 생깁니다
용량 관리 샤드를 관리하거나 온디맨드 모드를 씁니다 자동으로 조정됩니다
사용자 코드 소비 애플리케이션을 우리가 만듭니다 코드 없이 구성만으로 동작하며, 필요하면 변환 함수를 붙입니다
고르는 신호 "실시간으로 처리", "여러 팀이 같은 스트림을", "재처리가 필요" "S3에 적재만 하면 된다", "코드를 만들지 않고", "관리 부담 최소"

보안과 설정 관리

Secrets Manager 대 Parameter Store

둘 다 값을 암호화해 저장하고 IAM으로 접근을 통제하며 런타임에 값을 내려 줍니다. 겹치지 않는 지점은 하나, 자동 교체를 내장하는가입니다.

AWS Secrets Manager와 AWS Systems Manager Parameter Store의 속성 대조
속성 AWS Secrets Manager Parameter Store
주 용도 데이터베이스 자격 증명, API 키 같은 비밀 설정값과 파라미터
값 유형 비밀 문자열 또는 이진 값 String · StringList · SecureString
자동 교체 내장 — 교체 함수를 붙여 자동화합니다 없음 — 새 값을 넣는 것은 우리 몫입니다
교체 동작 AWSCURRENT와 AWSPENDING 준비 라벨로 새 버전을 만들며, 실패해도 현재 값이 살아 있습니다 해당 없음
계층 구조 비밀 단위로 관리합니다 이름을 /app/prod/db/처럼 경로로 계층화합니다
계층 등급 해당 없음 Standard · Advanced · Intelligent-Tiering
암호화 AWS KMS로 암호화합니다 SecureString일 때 AWS KMS로 암호화합니다
과금 성격 비밀 개수와 API 호출로 과금됩니다 표준 계층은 추가 비용 없이 쓸 수 있습니다
고르는 신호 "주기적으로 자동 교체", "비밀번호를 회전" "설정값을 계층 구조로", "추가 비용 없이", "교체 요구가 없다"

이어서 볼 곳

공식 문서 출처