AWS SAA 기초 개념 핸드북

용어를 읽다가 모르는 AWS 서비스가 나오면 파란색 링크를 눌러 해당 용어로 이동할 수 있습니다. 핵심 배지가 붙은 용어는 활용 예시를 3개로 확장했고, 필터에서 핵심 용어만 따로 볼 수 있습니다.

내부 링크
설명/예시/시험 포인트 안의 관련 용어를 클릭하면 해당 섹션으로 이동합니다.
체크/필터
아는 용어, 모르는 용어, 핵심 용어만 필터링할 수 있습니다.
심화 질문
각 용어의 질문 프롬프트를 복사하거나 ChatGPT를 새 탭으로 열 수 있습니다.
모바일/PWA
모바일 우선 레이아웃이며, 정적 호스팅 시 홈 화면 앱처럼 사용할 수 있습니다.

1. 클라우드/아키텍처 기본

1.1

AWS Region

핵심

설명AWS 서비스가 운영되는 물리적 지역 단위. 서울, 도쿄, 버지니아 북부처럼 지리적으로 떨어진 큰 묶음이다.

활용 예시
  1. 국내 병원 사용자가 대부분이면 지연 시간과 데이터 위치를 고려해 ap-northeast-2(서울) 리전을 우선 선택한다.
  2. 재해 복구가 필요하면 서울 리전 장애에 대비해 도쿄나 싱가포르 리전으로 백업/복제를 구성한다.
  3. 특정 국가에 데이터를 보관해야 하는 규정이 있으면 해당 요구사항을 만족하는 리전을 선택한다.

시험 포인트지연 시간, 데이터 위치, 재해 복구 전략과 연결된다. AZ와 구분한다.

1.2

Availability Zone, AZ

핵심

설명하나의 리전 안에 있는 독립적인 데이터센터 영역. 서로 격리되어 장애 영향을 줄이도록 설계된다.

활용 예시
  1. 웹 서버를 서로 다른 두 AZ에 배치해 한 AZ 장애에도 다른 AZ가 요청을 처리하게 한다.
  2. RDS Multi-AZ는 Primary DB와 Standby DB를 서로 다른 AZ에 두어 DB 장애에 대비한다.
  3. Auto Scaling Group을 여러 AZ에 걸쳐 두면 서버 한 구역 장애에도 전체 서비스 중단 가능성을 낮출 수 있다.

시험 포인트High Availability 문제에서는 Multi-AZ 배치가 자주 정답 방향이 된다.

1.3

Edge Location

설명CloudFront 같은 엣지 서비스가 사용자 가까이에서 콘텐츠를 제공하는 지점.

활용 예시이미지, JS, CSS를 사용자 가까운 엣지에서 캐싱해 로딩 속도를 줄인다.

시험 포인트Region/AZ와 다르다. 애플리케이션 서버를 직접 배치하는 곳이 아니라 캐시/엣지 기능에 가깝다.

1.4

Shared Responsibility Model

핵심

설명AWS와 사용자가 보안을 나누어 책임지는 모델. AWS는 클라우드 자체를, 사용자는 클라우드 안의 설정과 데이터를 책임진다.

활용 예시
  1. AWS는 데이터센터, 물리 서버, 관리형 서비스의 기반 인프라를 책임진다.
  2. 사용자는 IAM 권한, 애플리케이션 코드, 데이터 암호화 설정, S3 공개 여부를 책임진다.
  3. EC2는 OS 패치 책임이 사용자에게 더 많고, Lambda는 런타임/인프라 관리 부담이 상대적으로 적다.

시험 포인트IAM, 암호화, 네트워크 설정, 패치 책임 범위를 묻는 문제에 자주 등장한다.

1.5

Well-Architected Framework

핵심

설명AWS 아키텍처를 평가하는 기준 묶음. 운영 우수성, 보안, 안정성, 성능 효율, 비용 최적화, 지속 가능성 관점으로 본다.

활용 예시
  1. 운영 중인 서비스가 보안, 안정성, 성능, 비용 측면에서 균형 있게 설계됐는지 점검한다.
  2. SAA 문제에서 '가장 적절한 아키텍처'는 보통 Well-Architected의 원칙을 반영한 선택지다.
  3. 비용만 낮추는 구성이 아니라 장애 대응, 보안, 운영 부담까지 같이 고려하는 판단 기준으로 사용한다.

시험 포인트SAA는 단순 서비스 암기보다 이 관점에 맞는 최적 선택을 고르는 시험이다.

1.6

High Availability

핵심

설명장애가 발생해도 서비스가 계속 사용 가능하도록 구성하는 성질.

활용 예시
  1. ALB 뒤에 여러 AZEC2를 배치해 서버 하나 또는 AZ 하나가 죽어도 서비스가 계속되게 한다.
  2. RDS Multi-AZ를 사용해 DB 장애 시 Standby로 자동 장애 조치가 가능하게 한다.
  3. 단일 EC2에 모든 기능을 올리는 구조는 High Availability 조건에서 부적절한 선택지가 되기 쉽다.

시험 포인트단일 AZ, 단일 인스턴스 구성은 High Availability 요구에 부족하다.

1.7

Fault Tolerance

핵심

설명구성 요소 일부가 실패해도 전체 시스템이 정상 동작하도록 만드는 성질.

활용 예시
  1. 장애가 발생해도 사용자가 거의 인지하지 못하도록 여러 구성요소가 자동으로 대체된다.
  2. SQS를 사용해 일시적으로 Worker가 죽어도 메시지가 사라지지 않고 나중에 재처리되게 한다.
  3. Multi-AZAuto Scaling으로 일부 서버/AZ 장애를 흡수하는 구조를 만든다.

시험 포인트High Availability보다 한 단계 더 강한 장애 대응 개념으로 이해하면 된다.

1.8

Scalability

핵심

설명사용량 증가에 맞춰 시스템 처리 능력을 키울 수 있는 성질.

활용 예시
  1. 트래픽 증가 시 EC2 Auto Scaling으로 서버 수를 늘려 요청 처리량을 확장한다.
  2. 읽기 요청이 많아지면 RDS Read ReplicaElastiCache로 읽기 부하를 분산한다.
  3. 정적 파일 요청이 많으면 CloudFront 캐싱으로 원본 서버 부하를 줄인다.

시험 포인트Horizontal ScalingVertical Scaling을 구분한다.

1.9

Elasticity

설명필요할 때 늘리고 필요 없을 때 줄이는 자동 조절 능력.

활용 예시밤에는 인스턴스를 줄이고 피크 시간에는 Auto Scaling으로 늘린다.

시험 포인트성능뿐 아니라 비용 최적화와 함께 나온다.

1.10

Horizontal Scaling

설명서버 한 대를 키우는 대신 서버 대수를 늘려 처리량을 높이는 방식.

활용 예시EC2 여러 대를 ALB 뒤에 붙인다.

시험 포인트클라우드 아키텍처에서는 Horizontal Scaling이 일반적으로 선호된다.

1.11

Vertical Scaling

설명서버 대수는 유지하고 인스턴스 사양을 키우는 방식.

활용 예시t3.small을 m7i.large로 바꿔 CPU/메모리를 늘린다.

시험 포인트한계가 있고 장애 지점이 남기 때문에 High Availability 요구에는 부족할 수 있다.

1.12

Recovery Time Objective, RTO

설명Recovery Time Objective. 장애 후 서비스를 복구하는 데 허용되는 최대 시간.

활용 예시RTO 10분이면 10분 안에 서비스를 다시 사용할 수 있어야 한다.

시험 포인트DR 전략 선택 문제에서 RPO와 같이 나온다.

1.13

Recovery Point Objective, RPO

설명Recovery Point Objective. 장애 시점 기준으로 잃어도 되는 데이터의 최대 시간 범위.

활용 예시RPO 5분이면 최근 5분 이내 데이터 손실까지만 허용한다는 뜻이다.

시험 포인트백업 주기, 복제 방식, Multi-AZ/리전 복제와 연결된다.

1.14

Disaster Recovery, DR

핵심

설명큰 장애나 재해 발생 시 서비스를 복구하는 전략.

활용 예시
  1. 중요 데이터를 다른 리전에 백업해 리전 장애 시 복구할 수 있게 한다.
  2. RTO/RPO 요구사항에 따라 백업 복원, Pilot Light, Warm Standby, Multi-Site 전략을 선택한다.
  3. S3 Cross-Region Replication이나 AWS Backup을 사용해 복구 지점을 확보한다.

시험 포인트RTO/RPO가 짧을수록 비용이 올라가는 경향이 있다.

1.15

Stateless Application

핵심

설명서버가 사용자 상태를 직접 들고 있지 않는 애플리케이션 구조.

활용 예시
  1. 사용자 세션을 EC2 로컬에 저장하지 않고 DynamoDB, ElastiCache, 쿠키 등에 분리한다.
  2. Stateless 웹 서버는 Auto Scaling으로 서버가 늘거나 줄어도 요청 처리가 안정적이다.
  3. 로드밸런서가 어떤 서버로 요청을 보내도 동일하게 처리되도록 설계한다.

시험 포인트Auto Scaling, Load Balancing에 유리하다.

1.16

Stateful Application

설명서버나 구성 요소가 상태를 가지고 동작하는 구조.

활용 예시특정 서버 메모리에 세션을 저장하면 그 서버 장애 시 세션이 사라질 수 있다.

시험 포인트Scalability와 장애 대응이 어려워질 수 있어 외부 저장소로 상태를 분리하는 패턴이 자주 나온다.

2. 보안/IAM

2.1

Identity and Access Management, IAM

핵심

설명AWS의 사용자, 역할, 권한을 관리하는 서비스.

활용 예시
  1. 개발자에게 필요한 S3 읽기 권한만 주고, 전체 관리자 권한은 부여하지 않는다.
  2. EC2LambdaS3에 접근할 때 액세스 키 대신 IAM Role을 사용한다.
  3. 운영 계정에는 MFA를 적용하고, 권한은 Least Privilege 원칙으로 제한한다.

시험 포인트Least Privilege 원칙이 핵심이다.

2.2

IAM User

설명특정 사람이나 애플리케이션에 연결되는 장기 자격 증명 주체.

활용 예시관리자 계정이나 레거시 배포 계정에 사용될 수 있다.

시험 포인트가능하면 장기 Access Key보다 Role 기반 임시 자격 증명을 선호한다.

2.3

IAM Group

설명여러 IAM User에게 같은 권한을 묶어 부여하는 단위.

활용 예시개발자 그룹에 읽기 권한, 운영자 그룹에 제한된 관리 권한을 부여한다.

시험 포인트Role이 아니라 User 권한 관리용 묶음이다.

2.4

IAM Role

핵심

설명특정 사용자나 서비스가 임시로 맡는 권한 묶음.

활용 예시
  1. Lambda 함수가 DynamoDB를 읽어야 할 때 Lambda 실행 Role에 DynamoDB Read 권한을 부여한다.
  2. EC2S3 파일을 읽어야 할 때 EC2 인스턴스 프로파일로 Role을 연결한다.
  3. 다른 AWS 계정의 리소스에 임시로 접근할 때 Cross-account Role을 사용한다.

시험 포인트서비스 간 권한 위임 문제에서 자주 정답이 된다.

2.5

IAM Policy

핵심

설명무엇을 허용하거나 거부할지 JSON 형태로 정의한 권한 문서.

활용 예시
  1. 특정 S3 버킷에 대해서만 GetObject를 허용하는 정책을 작성한다.
  2. Deny 정책이 있으면 Allow가 있어도 최종적으로 거부된다.
  3. Action, Resource, Effect, Condition을 조합해 권한 범위를 세밀하게 제한한다.

시험 포인트Action, Resource, Effect, Condition 구조를 이해한다.

2.6

Identity-based Policy

설명User, Group, Role 같은 IAM 자격 증명에 붙는 정책.

활용 예시개발자 Role에 DynamoDB 읽기 권한을 부여한다.

시험 포인트누가 무엇을 할 수 있는지 정의하는 관점이다.

2.7

Resource-based Policy

설명S3 버킷, KMS Key 같은 리소스 자체에 붙는 정책.

활용 예시특정 CloudFront 배포만 S3 버킷에 접근하도록 버킷 정책을 설정한다.

시험 포인트누가 이 리소스에 접근할 수 있는지 리소스 입장에서 정의한다.

2.8

Explicit Deny

설명명시적으로 거부된 권한. 허용 정책보다 우선 적용된다.

활용 예시모든 사용자에게 특정 S3 삭제 작업을 Deny로 막는다.

시험 포인트Allow가 있어도 Explicit Deny가 있으면 거부된다.

2.9

Least Privilege

핵심

설명업무 수행에 필요한 최소 권한만 부여하는 원칙.

활용 예시
  1. 운영자가 로그 조회만 필요하면 CloudWatch Read 권한만 주고 삭제 권한은 주지 않는다.
  2. Lambda가 특정 테이블 하나만 읽으면 전체 DynamoDB 권한이 아니라 해당 테이블 권한만 부여한다.
  3. SAA에서는 보안을 강화하고 권한 범위를 줄이는 선택지가 정답 방향인 경우가 많다.

시험 포인트보안 설계 문제의 기본 방향이다.

2.10

Multi-Factor Authentication, MFA

설명비밀번호 외에 추가 인증 수단을 요구하는 보안 장치.

활용 예시Root User와 관리자 계정에 MFA를 활성화한다.

시험 포인트민감한 계정 보호의 기본 조치로 자주 나온다.

2.11

Security Token Service, STS

설명Security Token Service. 임시 보안 자격 증명을 발급하는 서비스.

활용 예시외부 사용자가 특정 Role을 AssumeRole하여 임시로 S3에 접근한다.

시험 포인트장기 Access Key 대신 임시 권한을 줄 때 사용한다.

2.12

Key Management Service, KMS

핵심

설명암호화 키를 생성하고 관리하는 서비스.

활용 예시
  1. S3 객체를 SSE-KMS로 암호화해 키 사용 권한까지 제어한다.
  2. RDS 스토리지 암호화에 KMS 키를 사용해 DB 데이터 보호를 강화한다.
  3. 민감한 로그나 백업을 암호화할 때 고객 관리형 KMS 키로 감사와 권한 관리를 세밀하게 한다.

시험 포인트SSE-KMS, 키 정책, 권한 분리가 자주 나온다.

2.13

Secrets Manager

핵심

설명DB 비밀번호, API 키 같은 민감 정보를 안전하게 저장하고 관리하는 서비스.

활용 예시
  1. DB 비밀번호를 코드나 환경변수에 직접 넣지 않고 Secrets Manager에 저장한다.
  2. RDS 비밀번호를 주기적으로 자동 Rotation하도록 설정한다.
  3. Lambda가 실행될 때 필요한 API 키를 Secrets Manager에서 읽어 사용한다.

시험 포인트자동 교체(rotation)가 필요한 비밀값에 적합하다.

2.14

Systems Manager Parameter Store

설명설정값과 비밀값을 저장할 수 있는 Systems Manager 기능.

활용 예시환경별 API 엔드포인트나 간단한 설정값을 저장한다.

시험 포인트Secrets Manager보다 단순한 설정 관리에 자주 쓰인다.

2.15

Cognito

핵심

설명웹/모바일 앱의 사용자 가입, 로그인, 인증을 지원하는 서비스.

활용 예시
  1. 외부 사용자 로그인/회원가입을 구현할 때 Cognito User Pool을 사용한다.
  2. 소셜 로그인 또는 MFA를 붙여 사용자 인증을 관리형 서비스로 처리한다.
  3. 인증된 사용자에게만 S3 업로드 권한을 주기 위해 Cognito Identity Pool과 IAM Role을 연결할 수 있다.

시험 포인트User Pool과 Identity Pool의 목적을 구분한다.

2.16

AWS Certificate Manager, ACM

핵심

설명SSL/TLS 인증서를 발급하고 관리하는 서비스.

활용 예시
  1. CloudFront 배포에 HTTPS를 적용하기 위해 인증서를 발급한다.
  2. ALB에 TLS 인증서를 연결해 API 서버를 HTTPS로 제공한다.
  3. CloudFront용 ACM 인증서는 us-east-1 리전에 발급해야 하는 점을 주의한다.

시험 포인트CloudFront용 인증서는 us-east-1 리전 요구가 자주 언급된다.

2.17

AWS WAF (Web Application Firewall)

핵심

설명웹 요청을 필터링하는 웹 애플리케이션 방화벽.

활용 예시
  1. CloudFront 앞단에서 SQL Injection이나 XSS 패턴 요청을 차단한다.
  2. 특정 IP 대역이나 국가에서 오는 요청을 제한한다.
  3. API GatewayALB 앞에 붙여 과도하거나 악성인 웹 요청을 필터링한다.

시험 포인트Security Group과 달리 HTTP 레벨 규칙을 다룬다.

2.19

GuardDuty

설명AWS 계정과 워크로드의 위협을 탐지하는 관리형 서비스.

활용 예시의심스러운 API 호출, 악성 IP와의 통신을 탐지한다.

시험 포인트탐지 서비스이지 방화벽처럼 직접 차단하는 서비스는 아니다.

2.20

Inspector

설명EC2, 컨테이너 이미지, Lambda 등의 취약점을 스캔하는 서비스.

활용 예시배포된 워크로드의 CVE 취약점을 확인한다.

시험 포인트취약점 평가와 패키지 보안 점검 관점이다.

2.21

Macie

설명S3 안의 민감 데이터를 탐지하는 서비스.

활용 예시S3에 주민등록번호나 개인정보가 들어 있는지 탐지한다.

시험 포인트S3 데이터 보안/개인정보 탐지 문제에 연결된다.

2.22

Security Hub

설명여러 보안 서비스의 결과를 모아 보안 상태를 통합 관리하는 서비스.

활용 예시GuardDuty, Inspector, Config 결과를 한 곳에서 본다.

시험 포인트통합 대시보드/보안 기준 점검 관점이다.

3. 네트워크/CDN/DNS

3.1

Virtual Private Cloud, VPC

핵심

설명AWS 안에 만드는 논리적 사설 네트워크.

활용 예시
  1. EC2, RDS, ALB 같은 리소스를 격리된 네트워크 안에 배치한다.
  2. Public Subnet에는 ALB나 Bastion을, Private Subnet에는 애플리케이션 서버와 DB를 배치한다.
  3. CIDR, Subnet, Route Table, Internet Gateway, NAT Gateway가 함께 나오는 네트워크 기본 단위다.

시험 포인트Subnet, Route Table, Gateway, Security Group의 상위 개념이다.

3.2

CIDR Block (Classless Inter-Domain Routing)

설명네트워크 주소 범위를 표현하는 방식.

활용 예시10.0.0.0/16 VPC 안에 10.0.1.0/24 서브넷을 만든다.

시험 포인트IP 범위가 겹치면 VPC Peering이나 네트워크 연결에 문제가 생긴다.

3.3

Subnet

핵심

설명VPC 안을 더 작게 나눈 네트워크 구역.

활용 예시
  1. VPC 내부를 AZ별, 역할별로 나누기 위해 Subnet을 만든다.
  2. Public Subnet에는 인터넷에 노출되는 ALB를 두고, Private Subnet에는 EC2RDS를 둔다.
  3. High Availability를 위해 같은 역할의 Subnet을 여러 AZ에 만든다.

시험 포인트서브넷은 하나의 AZ에 속한다.

3.4

Public Subnet

핵심

설명인터넷으로 나가는 경로가 있는 서브넷.

활용 예시
  1. 인터넷 사용자가 접근해야 하는 ALB를 Public Subnet에 배치한다.
  2. Route TableInternet Gateway로 향하는 기본 경로가 있으면 Public Subnet이 된다.
  3. EC2가 Public IP를 갖고 인터넷에서 직접 접근 가능하면 Security Group 설정을 특히 주의해야 한다.

시험 포인트Internet Gateway로 향하는 라우트가 있어야 한다.

3.5

Private Subnet

핵심

설명인터넷에서 직접 접근할 수 없도록 구성한 서브넷.

활용 예시
  1. RDS나 내부 애플리케이션 서버처럼 외부에서 직접 접근하면 안 되는 리소스를 둔다.
  2. Private Subnet의 서버가 패키지 업데이트를 받으려면 NAT Gateway를 통해 외부로 나간다.
  3. 인터넷에서 직접 들어오는 경로는 막고, ALB나 내부 네트워크를 통해서만 접근하게 한다.

시험 포인트외부에서 직접 들어오는 접근을 막고 NAT Gateway로 나가는 통신만 허용할 수 있다.

3.6

Route Table

핵심

설명네트워크 트래픽이 어디로 가야 하는지 정하는 라우팅 규칙.

활용 예시
  1. Public Subnet의 Route Table에는 0.0.0.0/0 → Internet Gateway 경로를 둔다.
  2. Private Subnet의 Route Table에는 0.0.0.0/0 → NAT Gateway 경로를 둘 수 있다.
  3. VPC Peering이나 Transit Gateway 연결 시 목적지 CIDR로 가는 경로를 추가해야 통신된다.

시험 포인트서브넷이 public/private인지 판단하는 핵심 요소다.

3.7

Internet Gateway

핵심

설명VPC가 인터넷과 통신할 수 있게 하는 게이트웨이.

활용 예시
  1. Public SubnetEC2ALB가 인터넷과 통신하려면 VPC에 Internet Gateway를 연결한다.
  2. 인터넷 접근 경로가 Route Table에 있어야 실제로 외부 통신이 가능하다.
  3. Private Subnet 리소스가 외부로 나가는 용도는 Internet Gateway가 아니라 NAT Gateway가 맡는다.

시험 포인트VPC에 붙인 뒤 Route Table에도 경로가 있어야 한다.

3.8

NAT Gateway (Network Address Translation)

핵심

설명Private Subnet 리소스가 인터넷으로 나갈 수 있게 하는 서비스.

활용 예시
  1. Private SubnetEC2가 소프트웨어 업데이트를 받으려고 인터넷으로 나갈 때 사용한다.
  2. 외부에서 Private Subnet으로 직접 들어오는 연결은 허용하지 않는다.
  3. 가용성을 높이려면 AZ별 NAT Gateway를 두지만 비용이 늘어난다.

시험 포인트들어오는 공개 접근용이 아니라 나가는 통신용이다. 비용도 자주 고려된다.

3.9

Security Group

핵심

설명EC2, ALB, RDS 등에 붙는 Stateful 방화벽.

활용 예시
  1. ALB는 443 포트를 인터넷에 열고, EC2ALB Security Group에서 오는 트래픽만 허용한다.
  2. RDS는 애플리케이션 서버 Security Group에서 오는 DB 포트만 허용한다.
  3. Stateful 방화벽이라 인바운드 허용에 대한 응답 트래픽은 아웃바운드 규칙 없이도 돌아갈 수 있다.

시험 포인트Stateful이다. 허용 규칙만 있고 명시적 Deny는 없다.

3.10

Network Access Control List, NACL

핵심

설명서브넷 단위의 Stateless 방화벽.

활용 예시
  1. 서브넷 단위로 들어오고 나가는 트래픽을 stateless 방식으로 제어한다.
  2. 특정 IP 대역을 서브넷 수준에서 차단하는 보조 방화벽으로 사용할 수 있다.
  3. 인바운드와 아웃바운드 규칙을 모두 고려해야 하며 Security Group보다 낮은 네트워크 계층에서 동작한다.

시험 포인트Stateless라서 인바운드/아웃바운드 규칙을 모두 고려해야 한다.

3.11

VPC Endpoint

핵심

설명인터넷을 거치지 않고 VPC 내부에서 AWS 서비스에 접근하는 경로.

활용 예시
  1. Private SubnetEC2가 인터넷을 거치지 않고 S3DynamoDB에 접근하게 한다.
  2. 보안상 NAT Gateway를 통한 외부 인터넷 경로를 줄이고 AWS 내부망 경로를 사용한다.
  3. S3/DynamoDBGateway Endpoint, 대부분의 기타 서비스는 Interface Endpoint를 사용한다.

시험 포인트보안과 비용 최적화 문제에 자주 나온다.

3.12

Gateway Endpoint

설명S3, DynamoDB 같은 서비스에 VPC 내부 경로로 접근하게 해주는 Endpoint 유형.

활용 예시Private Subnet에서 S3 파일을 읽되 인터넷으로 나가지 않게 한다.

시험 포인트S3/DynamoDB 전용이라고 기억하면 된다.

3.14

PrivateLink

설명VPC 간 또는 VPC와 AWS 서비스 간 private 연결을 제공하는 기술.

활용 예시외부 SaaS나 다른 VPC의 서비스를 공인 인터넷 없이 연결한다.

시험 포인트VPC Peering과 달리 서비스 단위 접근에 가깝다.

3.15

VPC Peering

설명VPC를 private하게 연결하는 기능.

활용 예시개발 VPC와 공통 서비스 VPC를 연결한다.

시험 포인트전이 라우팅을 지원하지 않는다. 여러 VPC 연결에는 Transit Gateway가 더 적합할 수 있다.

3.16

Transit Gateway

설명여러 VPC와 온프레미스 네트워크를 중앙에서 연결하는 허브.

활용 예시여러 팀의 VPC를 하나의 중앙 네트워크 허브로 연결한다.

시험 포인트VPC Peering이 많아져 복잡할 때 사용하는 대규모 연결 방식이다.

3.17

Route 53

핵심

설명AWS의 DNS 서비스.

활용 예시
  1. example.com 도메인을 CloudFront 배포나 ALB로 연결한다.
  2. Health Check와 Failover Routing으로 장애 시 다른 엔드포인트로 전환한다.
  3. Latency-based Routing으로 사용자에게 가까운 리전의 서비스로 연결할 수 있다.

시험 포인트라우팅 정책, 헬스 체크, DNS 레코드 문제가 자주 나온다.

3.18

A Record

설명도메인을 IPv4 주소나 Alias 대상에 연결하는 DNS 레코드.

활용 예시api.example.com을 ALB로 연결한다.

시험 포인트AWS 리소스에는 Alias Record가 자주 쓰인다.

3.19

CNAME Record (Canonical Name)

설명도메인을 다른 도메인 이름으로 연결하는 DNS 레코드.

활용 예시www.example.com을 dxxxx.cloudfront.net으로 연결한다.

시험 포인트루트 도메인에는 일반 CNAME을 쓰기 어렵고 Alias를 고려한다.

3.20

Route 53 Routing Policy

핵심

설명DNS 응답을 어떤 기준으로 줄지 정하는 정책.

활용 예시
  1. Weighted Routing으로 신규 버전 트래픽을 10%만 보내 카나리 배포처럼 운영한다.
  2. Failover Routing으로 Primary 장애 시 Secondary로 자동 전환한다.
  3. Latency Routing으로 사용자 위치에 따라 지연 시간이 낮은 리전으로 연결한다.

시험 포인트Simple, Weighted, Latency, Failover, Geolocation 등을 구분한다.

3.21

CloudFront

핵심

설명정적/동적 콘텐츠를 전 세계 엣지에서 빠르게 제공하는 CDN.

활용 예시
  1. S3에 있는 이미지, PDF, JS, CSS를 전 세계 사용자에게 빠르게 제공한다.
  2. S3 버킷을 public으로 열지 않고 OAC를 통해 CloudFront에서만 접근하게 한다.
  3. 로그인한 사용자만 볼 수 있는 콘텐츠는 CloudFront Signed URL/Cookie로 제한할 수 있다.

시험 포인트Origin, Cache Policy, OAC, Signed URL과 함께 나온다.

3.23

Cache Policy

핵심

설명CloudFront가 어떤 요청 요소를 기준으로 캐시 키를 만들지 정하는 정책.

활용 예시
  1. 정적 이미지나 JS 파일은 긴 TTL로 캐싱해 원본 요청을 줄인다.
  2. 사용자별 응답은 쿠키/헤더/쿼리스트링 캐싱 조건을 신중하게 설정한다.
  3. 잘못된 캐시 정책은 최신 데이터가 늦게 반영되거나 캐시 효율이 낮아지는 원인이 된다.

시험 포인트너무 많은 값을 캐시 키에 넣으면 캐시 효율이 떨어진다.

3.24

Invalidation

설명CloudFront 캐시를 강제로 무효화하는 작업.

활용 예시새 JS 번들을 배포했는데 기존 캐시가 남아 있으면 무효화한다.

시험 포인트자주 무효화하기보다 파일명 해시 전략이 비용/성능에 유리할 수 있다.

3.25

OAC/OAI (Origin Access Control / Origin Access Identity)

핵심

설명CloudFrontS3 Origin에 접근하도록 제한하는 방식. OAC가 더 최신 방식이다.

활용 예시
  1. S3 버킷을 public으로 열지 않고 CloudFront를 통해서만 읽을 수 있게 한다.
  2. OAI보다 최신 방식인 OAC를 사용해 S3 오리진 접근을 제어한다.
  3. Bucket Policy에서 CloudFront 배포만 객체를 읽도록 허용한다.

시험 포인트S3를 public으로 열지 않는 안전한 정적 콘텐츠 제공 구조다.

3.26

CloudFront Signed URL/Cookie

핵심

설명CloudFront 배포 콘텐츠에 시간 제한이나 조건부 접근을 적용하는 기능.

활용 예시
  1. 유료 사용자에게만 특정 동영상이나 PDF를 제한된 시간 동안 제공한다.
  2. 단일 파일 접근은 Signed URL, 여러 파일 묶음 접근은 Signed Cookie가 적합하다.
  3. S3 Presigned URL과 달리 CloudFront 캐시/CDN 경로를 통해 비공개 콘텐츠를 제공한다.

시험 포인트S3 Presigned URL과 다르다. CDN 앞단 접근 제어다.

3.27

Global Accelerator

핵심

설명고정 Anycast IP와 AWS 글로벌 네트워크로 애플리케이션 접근 성능/가용성을 개선하는 서비스.

활용 예시
  1. 전 세계 사용자의 TCP/UDP 트래픽을 AWS 글로벌 네트워크를 통해 가까운 엔드포인트로 라우팅한다.
  2. 고정 Anycast IP를 제공해 ALBNLB 뒤의 리전 장애 전환을 쉽게 한다.
  3. HTTP 캐싱 목적이면 Global Accelerator가 아니라 CloudFront를 우선 고려한다.

시험 포인트HTTP 캐싱이 필요한 경우 CloudFront, TCP/UDP 글로벌 라우팅은 Global Accelerator를 고려한다.

3.28

Direct Connect

설명온프레미스와 AWS를 전용 회선으로 연결하는 서비스.

활용 예시병원 내부망과 AWS VPC를 안정적인 전용 회선으로 연결한다.

시험 포인트인터넷 VPN보다 일관된 대역폭과 낮은 지연 시간이 필요할 때 적합하다.

3.29

Site-to-Site VPN

설명온프레미스 네트워크와 AWS VPC를 인터넷 기반 암호화 터널로 연결하는 서비스.

활용 예시사내 네트워크에서 Private Subnet의 시스템에 접근한다.

시험 포인트빠른 구축은 VPN, 안정적인 전용선은 Direct Connect로 구분한다.

4. 컴퓨팅/컨테이너

4.1

Elastic Compute Cloud, EC2

핵심

설명AWS에서 빌려 쓰는 가상 서버.

활용 예시
  1. 직접 서버를 띄워 웹 애플리케이션, 백엔드 API, Worker를 실행한다.
  2. OS 패치, 런타임 설치, 보안 설정 등 관리 책임이 서버리스보다 크다.
  3. Auto Scaling, ELB, Security Group, EBS와 함께 사용되는 기본 컴퓨팅 서비스다.

시험 포인트인스턴스 타입, AMI, Security Group, Auto Scaling과 함께 나온다.

4.2

Amazon Machine Image, AMI

설명EC2 인스턴스를 만들기 위한 서버 이미지.

활용 예시기본 패키지와 설정을 포함한 AMI로 동일한 서버를 반복 생성한다.

시험 포인트백업/복제/Auto Scaling 시작 템플릿과 연결된다.

4.3

Instance Type

설명EC2의 CPU, 메모리, 네트워크 성능 조합.

활용 예시CPU 집약 작업은 C 계열, 메모리 집약 작업은 R 계열을 고려한다.

시험 포인트성능 요구와 비용 최적화 문제에 나온다.

4.4

User Data

설명EC2 시작 시 실행되는 초기화 스크립트.

활용 예시인스턴스 부팅 시 패키지 설치와 앱 실행 명령을 자동으로 수행한다.

시험 포인트Auto Scaling으로 새 서버가 생성될 때 초기 설정 자동화에 유용하다.

4.5

EC2 Auto Scaling

핵심

설명조건에 따라 EC2 인스턴스 수를 자동으로 조절하는 기능.

활용 예시
  1. CPU 사용률이 높아지면 EC2 인스턴스 수를 자동으로 늘린다.
  2. 여러 AZ에 인스턴스를 분산해 High Availability와 Scalability를 동시에 확보한다.
  3. 트래픽이 줄면 인스턴스 수를 줄여 비용을 절감한다.

시험 포인트High Availability와 비용 최적화를 동시에 다룬다.

4.6

Launch Template

설명EC2 생성에 필요한 AMI, 인스턴스 타입, Security Group 등을 정의한 템플릿.

활용 예시Auto Scaling Group이 이 템플릿으로 새 EC2를 만든다.

시험 포인트Launch Configuration보다 Launch Template이 더 최신 방식이다.

4.7

Elastic Load Balancing, ELB

핵심

설명트래픽을 여러 대상에 분산하는 로드 밸런서 서비스 묶음.

활용 예시
  1. 여러 EC2 인스턴스에 사용자 요청을 분산한다.
  2. 비정상 인스턴스는 Health Check로 제외하고 정상 인스턴스에만 트래픽을 보낸다.
  3. ALB는 HTTP/HTTPS, NLB는 TCP/UDP 고성능 트래픽에 적합하다.

시험 포인트ALB, NLB, GWLB의 차이를 구분한다.

4.8

Application Load Balancer, ALB

핵심

설명HTTP/HTTPS 레벨에서 동작하는 로드 밸런서.

활용 예시
  1. /api 요청은 백엔드 Target Group으로, /admin 요청은 다른 Target Group으로 라우팅한다.
  2. HTTPS 인증서를 연결해 웹/API 트래픽을 TLS로 처리한다.
  3. HTTP 헤더, 경로, 호스트 기반 라우팅이 필요하면 ALB가 적합하다.

시험 포인트웹 애플리케이션, TLS 종료, 경로/호스트 기반 라우팅에 적합하다.

4.9

Network Load Balancer, NLB

핵심

설명TCP/UDP 레벨에서 고성능으로 동작하는 로드 밸런서.

활용 예시
  1. TCP/UDP 기반의 초고성능, 낮은 지연 시간 트래픽을 처리한다.
  2. 고정 IP가 필요한 로드밸런서 구성에서 사용될 수 있다.
  3. HTTP 경로 기반 라우팅이 필요하면 NLB가 아니라 ALB를 선택한다.

시험 포인트HTTP 기능보다 네트워크 성능과 낮은 지연 시간이 중요할 때 선택한다.

4.10

Elastic Beanstalk

설명애플리케이션 코드를 올리면 인프라 구성을 자동으로 관리해주는 PaaS형 서비스.

활용 예시Node.js 앱을 배포하면 EC2, ALB, Auto Scaling 구성을 대신 만들어준다.

시험 포인트세부 인프라 제어보다 빠른 배포와 운영 간소화가 중요할 때 나온다.

4.11

Lambda

핵심

설명서버를 직접 관리하지 않고 함수 단위 코드를 실행하는 서버리스 컴퓨팅 서비스.

활용 예시
  1. 이미지 업로드 후 썸네일 생성 같은 이벤트 기반 작업을 함수로 처리한다.
  2. API Gateway와 조합해 서버를 직접 관리하지 않는 API를 만든다.
  3. 짧고 이벤트 기반인 작업에 적합하며 실행 시간, 메모리, 동시성 제한을 고려해야 한다.

시험 포인트실행 시간 제한, 이벤트 트리거, 콜드 스타트, IAM Role을 이해한다.

4.12

Lambda Concurrency

설명동시에 실행 가능한 Lambda 함수 실행 수.

활용 예시트래픽이 급증하면 동시 실행 수 제한에 걸릴 수 있다.

시험 포인트Reserved Concurrency와 Throttling 개념이 함께 나온다.

4.13

Elastic Container Service, ECS

설명AWS의 컨테이너 오케스트레이션 서비스.

활용 예시Docker 컨테이너로 만든 API 서버를 ECS Service로 운영한다.

시험 포인트EKS보다 AWS 관리형 컨테이너 운영에 단순한 편이다.

4.14

Elastic Kubernetes Service, EKS

설명AWS에서 Kubernetes를 운영하는 관리형 서비스.

활용 예시Kubernetes 기반으로 여러 마이크로서비스를 운영한다.

시험 포인트Kubernetes 생태계가 필요할 때 적합하지만 운영 복잡도가 있다.

4.15

Fargate

핵심

설명서버 인스턴스를 직접 관리하지 않고 컨테이너를 실행하는 서버리스 컨테이너 실행 방식.

활용 예시
  1. 컨테이너를 실행하지만 EC2 서버 관리는 AWS에 맡긴다.
  2. ECS 작업을 서버리스 컨테이너처럼 운영해 인프라 관리 부담을 줄인다.
  3. 항상 실행되는 컨테이너 워크로드에는 Lambda보다 Fargate가 더 적합할 수 있다.

시험 포인트컨테이너는 필요하지만 EC2 관리 부담을 줄이고 싶을 때 선택한다.

4.16

Elastic Container Registry, ECR

설명Docker 컨테이너 이미지를 저장하는 AWS 레지스트리.

활용 예시GitHub Actions에서 빌드한 이미지를 ECR에 push하고 ECS에서 사용한다.

시험 포인트ECS/EKS 배포 흐름과 함께 나온다.

4.17

Spot Instance

핵심

설명남는 EC2 용량을 저렴하게 쓰는 인스턴스 구매 옵션.

활용 예시
  1. 중단되어도 괜찮은 배치 작업이나 이미지 처리 Worker에 저렴하게 사용한다.
  2. 중요한 운영 서버나 DB처럼 중단되면 안 되는 워크로드에는 부적절하다.
  3. On-Demand와 Spot을 섞어 비용 절감과 안정성을 균형 있게 구성할 수 있다.

시험 포인트언제든 회수될 수 있어 Stateful 핵심 서비스에는 부적합하다.

4.18

Reserved Instance

핵심

설명장기 사용을 약정해 EC2/RDS 비용을 절감하는 구매 옵션.

활용 예시
  1. 1년 이상 계속 켜둘 DB나 EC2가 있다면 예약으로 비용을 줄인다.
  2. 사용량이 예측 가능한 워크로드에 적합하다.
  3. 갑작스럽게 바뀌는 트래픽이나 짧은 실험 환경에는 On-Demand가 더 유연하다.

시험 포인트지속적인 사용량이 예측될 때 비용 최적화 선택지다.

4.19

Savings Plans

핵심

설명일정 사용량을 약정하고 컴퓨팅 비용을 할인받는 모델.

활용 예시
  1. 컴퓨팅 사용량을 일정 금액 이상 쓰기로 약정해 EC2/Lambda/Fargate 비용을 낮춘다.
  2. 인스턴스 타입이 바뀔 가능성이 있으면 RI보다 유연한 선택지가 될 수 있다.
  3. 장기적으로 일정한 사용량이 있는 서비스 비용 최적화 문제에서 자주 나온다.

시험 포인트Reserved Instance보다 유연한 비용 절감 선택지로 나온다.

5. 스토리지/파일 제공

5.1

Simple Storage Service, S3

핵심

설명객체 스토리지 서비스. 파일을 객체 단위로 저장한다.

활용 예시
  1. 이미지, PDF, 정적 파일, 로그, 백업 파일을 객체 형태로 저장한다.
  2. 프론트엔드 정적 자산은 S3에 저장하고 CloudFront로 빠르게 제공할 수 있다.
  3. 수명주기 정책으로 오래된 파일을 저렴한 스토리지 클래스로 이동한다.

시험 포인트거의 모든 SAA 영역에서 등장하는 핵심 서비스다.

5.2

S3 Bucket

설명S3 객체를 담는 최상위 컨테이너.

활용 예시서비스별로 embryo-report-prod 같은 버킷을 만든다.

시험 포인트버킷 이름은 전역 고유하며 public access 설정을 주의한다.

5.3

S3 Object

설명S3에 저장되는 개별 파일과 메타데이터.

활용 예시patient/123/report.pdf 같은 Key로 PDF를 저장한다.

시험 포인트S3는 파일 시스템이 아니라 Key 기반 객체 저장소다.

5.4

S3 Storage Class

핵심

설명접근 빈도와 비용 구조에 따라 선택하는 S3 저장 등급.

활용 예시
  1. 자주 접근하는 파일은 S3 Standard에 저장한다.
  2. 가끔 접근하지만 바로 꺼내야 하는 파일은 Standard-IA를 고려한다.
  3. 장기 보관용 백업은 Glacier 계열로 이동해 비용을 줄인다.

시험 포인트접근 빈도, 복구 시간, 최소 저장 기간을 함께 고려한다.

5.5

S3 Standard

설명자주 접근하는 데이터를 위한 기본 S3 저장 등급.

활용 예시웹에서 자주 로딩되는 이미지나 정적 리소스를 저장한다.

시험 포인트가용성과 내구성이 높지만 저빈도 데이터에는 비용이 더 들 수 있다.

5.6

S3 Standard-IA (Infrequent Access)

설명자주 접근하지 않지만 필요할 때 빠르게 접근해야 하는 데이터용 저장 등급.

활용 예시월 1회 이하로 보는 과거 리포트를 저장한다.

시험 포인트저장 비용은 낮지만 조회 비용이 발생한다.

5.7

S3 One Zone-IA (Infrequent Access)

설명하나의 AZ에만 저장하는 저빈도 접근용 저장 등급.

활용 예시재생성 가능한 임시 데이터나 중요도가 낮은 파일에 사용한다.

시험 포인트AZ 장애에 취약하므로 중요한 원본 데이터에는 부적합하다.

5.8

S3 Glacier

설명장기 보관용 저비용 스토리지 계열.

활용 예시법적 보관이 필요한 오래된 백업 데이터를 저장한다.

시험 포인트복구 시간이 필요하므로 즉시 조회 데이터에는 맞지 않는다.

5.9

S3 Lifecycle Policy

핵심

설명객체를 시간 흐름에 따라 다른 저장 등급으로 이동하거나 삭제하는 규칙.

활용 예시
  1. 30일 지난 로그 파일을 Standard-IA로 옮기고 1년 후 Glacier로 이동한다.
  2. 오래된 객체 버전을 자동 삭제해 저장 비용을 줄인다.
  3. 접근 빈도와 보관 기간이 명확한 데이터 비용 최적화 문제에서 자주 등장한다.

시험 포인트비용 최적화 문제에서 자주 나온다.

5.10

S3 Versioning

핵심

설명객체의 이전 버전을 보관하는 기능.

활용 예시
  1. 실수로 덮어쓴 파일을 이전 버전으로 복구한다.
  2. 삭제 마커를 사용해 삭제된 객체도 복구할 수 있는 여지를 남긴다.
  3. Replication, Object Lock, 백업 전략과 함께 데이터 보호 문제에서 자주 나온다.

시험 포인트삭제 마커와 MFA Delete 개념이 함께 나올 수 있다.

5.11

S3 Replication

핵심

설명객체를 같은 리전 또는 다른 리전의 버킷으로 복제하는 기능.

활용 예시
  1. 서울 리전의 버킷 데이터를 도쿄 리전 버킷으로 자동 복제한다.
  2. 동일 리전의 다른 버킷으로 복제해 계정/환경 분리 백업을 만든다.
  3. Versioning이 활성화되어 있어야 하며 복제 지연과 비용을 고려해야 한다.

시험 포인트CRR은 리전 간 복제, SRR은 같은 리전 복제다.

5.12

S3 Encryption

핵심

설명S3 객체를 암호화해 저장하는 기능.

활용 예시
  1. 기본 암호화로 S3에 저장되는 객체를 자동 암호화한다.
  2. SSE-KMS를 사용하면 KMS 키 권한과 사용 감사까지 관리할 수 있다.
  3. 민감 데이터 저장 문제에서는 암호화와 접근 제어를 함께 고려한다.

시험 포인트SSE-S3, SSE-KMS, SSE-C 차이를 구분한다.

5.13

S3 Bucket Policy

핵심

설명버킷 리소스에 직접 붙는 접근 정책.

활용 예시
  1. 특정 CloudFront 배포에서 오는 요청만 S3 객체 읽기를 허용한다.
  2. 특정 IAM Role이나 계정에만 업로드 권한을 부여한다.
  3. Resource-based Policy이므로 버킷 리소스 자체에 접근 규칙을 붙이는 방식이다.

시험 포인트IAM PolicyResource-based Policy 차이를 이해한다.

5.14

S3 Public Access Block

핵심

설명S3 버킷과 객체의 공개 접근을 차단하는 안전장치.

활용 예시
  1. 실수로 버킷 정책을 잘못 작성해도 public 공개를 막는 안전장치로 사용한다.
  2. 민감 이미지나 리포트가 있는 버킷은 Public Access Block을 켜는 것이 기본 방향이다.
  3. 정적 웹사이트 호스팅처럼 public 접근이 필요한 경우와 CloudFront 비공개 접근 구성을 구분해야 한다.

시험 포인트보안 문제에서는 기본적으로 활성화하는 방향이 안전하다.

5.15

S3 Presigned URL

핵심

설명제한된 시간 동안 S3 객체에 접근할 수 있는 서명된 URL.

활용 예시
  1. 브라우저가 서버를 거치지 않고 S3에 직접 파일을 업로드하도록 임시 URL을 발급한다.
  2. 비공개 리포트 PDF를 10분 동안만 다운로드 가능하게 한다.
  3. CloudFront를 통한 캐싱/전송 최적화가 필요하면 CloudFront Signed URL과 비교한다.

시험 포인트CloudFront Signed URL과 구분한다. S3에 직접 접근하는 방식이다.

5.16

S3 Event Notification

핵심

설명S3 이벤트 발생 시 Lambda, SQS, SNS 등으로 알림을 보내는 기능.

활용 예시
  1. 이미지가 S3에 업로드되면 Lambda를 호출해 썸네일을 생성한다.
  2. CSV 파일이 업로드되면 SQS로 메시지를 보내 Worker가 비동기로 처리한다.
  3. 객체 생성/삭제 이벤트를 기반으로 후처리 파이프라인을 구성할 때 사용한다.

시험 포인트비동기 처리 패턴과 연결된다.

5.17

Elastic Block Store, EBS

핵심

설명EC2에 붙이는 블록 스토리지.

활용 예시
  1. EC2 인스턴스에 OS 디스크나 애플리케이션 데이터 디스크로 연결한다.
  2. 스냅샷으로 볼륨 백업을 만들고 다른 AZ/리전에 복원할 수 있다.
  3. S3처럼 객체 저장소가 아니라 EC2에 붙는 블록 스토리지다.

시험 포인트EC2와 같은 AZ에 있어야 하며 Snapshot으로 백업한다.

5.18

EBS Snapshot

설명EBS 볼륨의 백업 이미지.

활용 예시디스크 백업을 만들고 다른 AZ나 리전에서 복원한다.

시험 포인트증분 백업 개념과 DR/백업 문제에 나온다.

5.19

Elastic File System, EFS

핵심

설명여러 EC2에서 동시에 마운트할 수 있는 관리형 파일 시스템.

활용 예시
  1. 여러 EC2 인스턴스가 같은 파일 시스템을 동시에 마운트해야 할 때 사용한다.
  2. 컨테이너 여러 개가 공유 파일을 읽고 써야 하는 Linux 워크로드에 적합하다.
  3. S3는 객체 저장소, EFS는 POSIX 파일 시스템이라는 차이를 구분한다.

시험 포인트Linux 기반 공유 파일 시스템이며 다중 AZ 구성이 가능하다.

5.20

FSx

설명Windows File Server, Lustre 등 특정 파일 시스템을 제공하는 관리형 서비스.

활용 예시Windows 애플리케이션이 SMB 파일 공유를 필요로 할 때 사용한다.

시험 포인트EFS와 달리 워크로드별 파일 시스템 선택지로 이해한다.

5.21

AWS Backup

핵심

설명AWS 리소스 백업을 중앙에서 관리하는 서비스.

활용 예시
  1. RDS, EBS, EFS 등 여러 리소스의 백업 정책을 중앙에서 관리한다.
  2. 보관 기간과 백업 주기를 정책으로 지정해 운영 실수를 줄인다.
  3. 규정 준수나 감사 대응이 필요한 서비스에서 백업 증적을 관리한다.

시험 포인트여러 서비스의 백업 정책을 통합 관리할 때 선택한다.

5.22

Storage Gateway

설명온프레미스 환경과 AWS 스토리지를 연결하는 하이브리드 스토리지 서비스.

활용 예시병원 내부 시스템의 백업을 AWS S3로 연동한다.

시험 포인트File Gateway, Volume Gateway, Tape Gateway 개념이 있다.

6. 데이터베이스/캐시

6.1

Relational Database Service, RDS

핵심

설명MySQL, PostgreSQL 같은 관계형 DB를 관리형으로 제공하는 서비스.

활용 예시
  1. MySQL/PostgreSQL 같은 관계형 DB를 관리형 서비스로 운영한다.
  2. 백업, 패치, 장애 조치 등 DB 운영 부담을 직접 설치형 DB보다 줄인다.
  3. Multi-AZ, Read Replica, 암호화, 자동 백업 옵션이 시험에 자주 나온다.

시험 포인트Multi-AZ, Read Replica, 백업, 스토리지 확장과 함께 나온다.

6.2

Aurora

핵심

설명AWS가 만든 MySQL/PostgreSQL 호환 고성능 관계형 DB.

활용 예시
  1. MySQL/PostgreSQL 호환 DB가 필요하지만 더 높은 성능과 가용성이 필요할 때 사용한다.
  2. 읽기 Replica를 여러 개 두어 읽기 성능을 확장한다.
  3. 일반 RDS보다 AWS 최적화된 분산 스토리지 구조를 갖는 관리형 DB다.

시험 포인트RDS 계열이지만 스토리지 구조와 복제 방식이 다르다.

6.3

Aurora Serverless

핵심

설명수요에 따라 자동으로 용량이 조절되는 Aurora 옵션.

활용 예시
  1. 트래픽이 불규칙한 개발/테스트 또는 간헐적 서비스에서 DB 용량을 자동 조정한다.
  2. 항상 최대 성능이 필요한 고정 트래픽 워크로드에는 Provisioned Aurora가 더 적합할 수 있다.
  3. 운영 부담과 유휴 비용을 줄이는 DB 선택지로 나온다.

시험 포인트항상 일정한 고성능이 필요한 워크로드와 비교해 선택한다.

6.4

RDS Multi-AZ

핵심

설명DB 장애 대응을 위해 다른 AZ에 대기 복제본을 두는 구성.

활용 예시
  1. Primary DB 장애 시 다른 AZ의 Standby DB로 자동 Failover한다.
  2. DB 읽기 성능 향상 목적이 아니라 가용성과 장애 대응 목적이다.
  3. 운영 DB가 단일 AZ에만 있으면 AZ 장애 시 서비스가 중단될 수 있다.

시험 포인트High Availability 목적이지 읽기 성능 확장 목적이 아니다.

6.5

Read Replica

핵심

설명읽기 트래픽 분산을 위한 DB 복제본.

활용 예시
  1. 조회 요청이 많은 서비스에서 읽기 전용 복제본으로 부하를 분산한다.
  2. 리포트/분석 쿼리를 Replica로 보내 Primary DB 부하를 줄인다.
  3. 장애 대비는 Multi-AZ, 읽기 성능 확장은 Read Replica로 구분한다.

시험 포인트읽기 성능 확장 목적이다. 자동 장애 조치 목적의 Multi-AZ와 구분한다.

6.6

RDS Automated Backup

설명RDS가 자동으로 수행하는 백업 기능.

활용 예시특정 시점으로 DB를 복구한다.

시험 포인트Point-in-time recovery와 백업 보존 기간이 자주 나온다.

6.7

DynamoDB

핵심

설명완전 관리형 NoSQL Key-Value/Document DB.

활용 예시
  1. 세션, 장바구니, 이벤트 로그처럼 key-value/문서 기반 데이터를 빠르게 저장한다.
  2. 서버리스 API에서 Lambda와 함께 사용해 운영 부담을 줄인다.
  3. 파티션 키 설계가 성능과 Scalability에 큰 영향을 준다.

시험 포인트파티션 키 설계가 중요하며 조인 중심 관계형 모델과 다르다.

6.8

DynamoDB Partition Key

핵심

설명DynamoDB 데이터를 분산 저장하고 조회하는 기본 키 요소.

활용 예시
  1. 사용자 ID를 Partition Key로 사용해 사용자별 데이터를 빠르게 조회한다.
  2. 특정 키에 요청이 몰리면 Hot Partition이 생겨 성능 문제가 발생할 수 있다.
  3. 테이블의 데이터 분산과 기본 조회 패턴을 결정하는 가장 중요한 키다.

시험 포인트키 설계가 잘못되면 hot partition 문제가 생긴다.

6.9

DynamoDB Sort Key

설명같은 파티션 안에서 데이터를 정렬/범위 조회할 수 있게 하는 키.

활용 예시userId + createdAt 구조로 사용자별 이력을 시간순 조회한다.

시험 포인트복합 키 설계와 쿼리 패턴이 함께 나온다.

6.10

DynamoDB GSI (Global Secondary Index)

설명기본 키와 다른 방식으로 조회하기 위한 Global Secondary Index.

활용 예시email로 사용자를 찾고 싶을 때 GSI를 만든다.

시험 포인트추가 비용과 eventual consistency를 고려한다.

6.11

DynamoDB TTL (Time to Live)

설명지정한 시간이 지난 항목을 자동으로 삭제하는 기능.

활용 예시만료된 세션이나 임시 토큰 데이터를 자동 삭제한다.

시험 포인트수명 제한 데이터에 적합하다.

6.12

DynamoDB Accelerator, DAX

핵심

설명DynamoDB 전용 인메모리 캐시.

활용 예시
  1. DynamoDB 읽기 지연 시간을 마이크로초 수준으로 낮추기 위해 캐시를 붙인다.
  2. 읽기 요청이 매우 많고 같은 데이터를 반복 조회하는 경우에 적합하다.
  3. 일반적인 RDS 캐시는 ElastiCache, DynamoDB 전용 캐시는 DAX로 구분한다.

시험 포인트DynamoDB 앞단 캐시가 필요할 때 고려한다.

6.13

ElastiCache

핵심

설명Redis 또는 Memcached를 관리형으로 제공하는 인메모리 캐시 서비스.

활용 예시
  1. 자주 조회되는 API 결과를 캐싱해 DB 부하와 응답 시간을 줄인다.
  2. 사용자 세션을 저장해 Stateless 애플리케이션 구조를 만들 수 있다.
  3. 읽기 성능 향상 문제에서 Read Replica와 함께 비교된다.

시험 포인트DB 부하 감소와 지연 시간 감소가 목적이다.

6.14

ElastiCache for Redis

설명고급 자료구조와 복제, 영속성 옵션을 제공하는 Redis 기반 캐시.

활용 예시세션 저장소나 Pub/Sub, rate limit 카운터에 사용한다.

시험 포인트Memcached보다 기능이 많고 복잡한 캐시 패턴에 적합하다.

6.15

Redshift

설명대규모 분석용 데이터 웨어하우스 서비스.

활용 예시서비스 로그와 비즈니스 데이터를 모아 분석 쿼리를 수행한다.

시험 포인트운영 트랜잭션 DB가 아니라 분석용 OLAP 성격이다.

6.16

DocumentDB

설명MongoDB 호환 문서형 DB 서비스.

활용 예시문서 기반 데이터를 MongoDB API와 유사하게 다룬다.

시험 포인트DynamoDB와 같은 일반 NoSQL이라기보다 MongoDB 호환 워크로드로 이해한다.

6.17

Neptune

설명그래프 DB 서비스.

활용 예시추천, 관계 탐색, 연결성 분석에 사용한다.

시험 포인트관계형 조인보다 그래프 탐색이 핵심인 워크로드에 적합하다.

7. 서버리스/비동기/통합

7.1

API Gateway

핵심

설명클라이언트 요청을 Lambda나 백엔드 서비스로 연결하는 API 관문.

활용 예시
  1. 브라우저 요청을 Lambda로 연결해 서버리스 API를 만든다.
  2. 인증, Throttling, CORS, Stage 배포 같은 API 앞단 기능을 제공한다.
  3. 단순 HTTP API는 비용/성능 면에서 REST API보다 적합할 수 있다.

시험 포인트REST API, HTTP API, 인증, CORS, Throttling을 구분한다.

7.2

REST API vs HTTP API

설명API Gateway의 API 유형. REST API는 기능이 많고, HTTP API는 더 단순하고 비용/성능에 유리한 경우가 많다.

활용 예시단순 Lambda 프록시 API는 HTTP API로 충분할 수 있다.

시험 포인트필요 기능과 비용 조건에 따라 선택한다.

7.3

API Gateway Throttling

설명API 요청 속도를 제한하는 기능.

활용 예시과도한 요청으로 백엔드가 터지지 않게 초당 요청 수를 제한한다.

시험 포인트보호, 비용 통제, 안정성 문제와 연결된다.

7.4

Simple Queue Service, SQS

핵심

설명메시지를 줄 세워 비동기로 처리하는 큐 서비스.

활용 예시
  1. 이미지 분석 요청을 큐에 넣고 Worker가 순서대로 가져가 처리한다.
  2. 트래픽이 갑자기 몰려도 요청을 버리지 않고 뒤에서 천천히 처리한다.
  3. 서비스 간 직접 의존을 줄이는 Decoupling 문제에서 자주 정답이 된다.

시험 포인트생산자와 소비자를 분리해 장애와 트래픽 급증을 흡수한다.

7.5

SQS Standard Queue

설명높은 처리량을 제공하지만 메시지 순서와 정확히 한 번 처리를 보장하지 않는 큐.

활용 예시순서가 크게 중요하지 않은 이미지 처리 작업에 사용한다.

시험 포인트최소 한 번 전달(at-least-once)을 전제로 중복 처리에 대비한다.

7.6

SQS FIFO Queue

설명메시지 순서와 중복 제거를 지원하는 큐.

활용 예시주문 처리처럼 순서가 중요한 작업에 사용한다.

시험 포인트Standard Queue보다 처리량 제약이 있을 수 있다.

7.7

Dead Letter Queue, DLQ

핵심

설명처리에 반복 실패한 메시지를 따로 보내는 큐.

활용 예시
  1. 여러 번 처리 실패한 메시지를 별도 큐로 보내 원인 분석을 쉽게 한다.
  2. 무한 재시도로 시스템이 막히는 것을 방지한다.
  3. SQSLambda 비동기 처리의 실패 관리 패턴으로 등장한다.

시험 포인트재시도 실패 처리와 운영 안정성 문제에 자주 나온다.

7.8

Simple Notification Service, SNS

핵심

설명하나의 메시지를 여러 구독자에게 발행하는 Pub/Sub 서비스.

활용 예시
  1. 하나의 이벤트를 Email, Lambda, SQS 등 여러 구독자에게 동시에 보낸다.
  2. 주문 완료 이벤트를 여러 시스템에 팬아웃해야 할 때 사용한다.
  3. 작업을 줄 세워 처리하는 SQS와 달리 메시지를 발행/구독 방식으로 전파한다.

시험 포인트SQS는 큐, SNS는 팬아웃 알림으로 구분한다.

7.9

EventBridge

핵심

설명애플리케이션 이벤트를 규칙에 따라 라우팅하는 이벤트 버스 서비스.

활용 예시
  1. SaaS나 AWS 서비스 이벤트를 받아 규칙에 맞게 LambdaSQS로 라우팅한다.
  2. 매일 오전 특정 시간에 배치 Lambda를 실행하는 스케줄러처럼 사용할 수 있다.
  3. 이벤트 기반 아키텍처에서 서비스 간 결합도를 낮추는 데 사용한다.

시험 포인트스케줄링, 이벤트 기반 아키텍처, 서비스 간 느슨한 결합에 적합하다.

7.10

Step Functions

핵심

설명여러 AWS 서비스와 Lambda 실행 흐름을 상태 머신으로 조율하는 서비스.

활용 예시
  1. 여러 Lambda 작업을 순서, 조건, 재시도, 병렬 처리로 묶어 워크플로우를 만든다.
  2. 이미지 업로드 → 분석 → 리포트 생성 → 알림 발송 같은 긴 프로세스를 상태 머신으로 관리한다.
  3. 단일 함수로 복잡한 로직을 처리하기보다 단계별 오케스트레이션이 필요할 때 사용한다.

시험 포인트복잡한 순서, 재시도, 분기, 에러 처리가 필요할 때 사용한다.

7.11

AppSync

설명GraphQL API를 관리형으로 제공하는 서비스.

활용 예시프론트엔드가 GraphQL로 여러 데이터 소스를 조회한다.

시험 포인트GraphQL, 실시간 구독, DynamoDB/Lambda 연동과 연결된다.

7.12

Kinesis

핵심

설명실시간 스트리밍 데이터를 수집/처리하는 서비스 계열.

활용 예시
  1. 실시간 클릭 로그나 IoT 이벤트처럼 스트리밍 데이터를 수집한다.
  2. 순서가 중요한 연속 데이터 처리를 위해 샤드 기반으로 스트림을 확장한다.
  3. 단순 비동기 작업 큐는 SQS, 실시간 스트리밍 분석은 Kinesis로 구분한다.

시험 포인트SQS는 메시지 큐, Kinesis는 스트리밍 데이터 처리로 구분한다.

7.13

Amazon MQ

설명RabbitMQ/ActiveMQ 호환 관리형 메시지 브로커.

활용 예시기존 온프레미스 메시지 브로커 기반 시스템을 AWS로 이전한다.

시험 포인트클라우드 네이티브 신규 설계는 SQS/SNS, 기존 브로커 호환은 Amazon MQ가 자주 맞다.

8. 운영/모니터링/IaC/비용

8.1

CloudWatch

핵심

설명AWS 리소스와 애플리케이션의 메트릭, 로그, 알람을 관리하는 서비스.

활용 예시
  1. EC2 CPU 사용률, Lambda 오류 수, API Gateway 지연 시간을 모니터링한다.
  2. 메트릭 기반 알람을 만들어 장애나 비용 급증을 빠르게 인지한다.
  3. CloudWatch Logs, Metrics, Alarms가 함께 운영 관찰성의 기본이 된다.

시험 포인트로그와 메트릭 모니터링은 CloudWatch, API 호출 감사는 CloudTrail로 구분한다.

8.2

CloudWatch Logs

핵심

설명애플리케이션과 AWS 서비스 로그를 저장하고 검색하는 기능.

활용 예시
  1. Lambda 실행 로그를 확인해 에러 원인을 추적한다.
  2. 애플리케이션 로그를 중앙으로 모아 검색하고 필터링한다.
  3. 로그 보관 기간을 설정해 비용과 감사 요구사항을 조절한다.

시험 포인트운영 디버깅의 기본 도구다.

8.3

CloudWatch Alarm

핵심

설명메트릭 조건이 임계치를 넘으면 알림이나 조치를 실행하는 기능.

활용 예시
  1. EC2 CPU가 80%를 넘으면 알림을 보내거나 Auto Scaling 정책을 실행한다.
  2. Lambda 오류율이 일정 기준을 넘으면 운영자에게 SNS 알림을 보낸다.
  3. 메트릭 임계값을 기반으로 자동 대응이나 알림을 구성한다.

시험 포인트Auto Scaling 정책과도 연결된다.

8.4

CloudTrail

핵심

설명AWS 계정에서 발생한 API 호출과 활동을 기록하는 감사 로그 서비스.

활용 예시
  1. 누가 S3 버킷 정책을 변경했는지 감사 로그로 확인한다.
  2. IAM 권한 변경이나 리소스 삭제 같은 AWS API 호출 기록을 남긴다.
  3. 애플리케이션 로그가 아니라 AWS 계정 활동 로그라는 점을 CloudWatch Logs와 구분한다.

시험 포인트애플리케이션 로그가 아니라 AWS API 활동 기록이다.

8.5

AWS Config

핵심

설명AWS 리소스 구성 변경 이력과 규정 준수 상태를 추적하는 서비스.

활용 예시
  1. S3 버킷이 public으로 열렸는지 규칙으로 지속 점검한다.
  2. 리소스 설정 변경 이력을 추적해 언제 어떤 설정이 바뀌었는지 확인한다.
  3. 규정 준수와 구성 감사 문제에서 CloudTrail과 함께 등장한다.

시험 포인트현재 상태와 변경 이력을 관리하는 컴플라이언스 도구다.

8.6

Systems Manager

설명EC2와 AWS 리소스를 운영/관리하는 기능 묶음.

활용 예시Session Manager로 SSH 포트 없이 EC2에 접속한다.

시험 포인트패치, 명령 실행, 파라미터 관리, 인벤토리와 연결된다.

8.7

Session Manager

설명브라우저/CLI로 EC2에 안전하게 접속하는 Systems Manager 기능.

활용 예시Bastion Host 없이 Private EC2에 접속한다.

시험 포인트SSH 키와 22번 포트 노출을 줄이는 선택지다.

8.8

CloudFormation

핵심

설명AWS 인프라를 코드로 정의하고 배포하는 IaC 서비스.

활용 예시
  1. VPC, Subnet, ALB, EC2 구성을 템플릿으로 정의해 반복 생성한다.
  2. 수동 콘솔 작업 대신 코드로 인프라 변경 이력을 관리한다.
  3. Stack 단위로 리소스를 생성/수정/삭제하며 롤백도 지원한다.

시험 포인트수동 콘솔 작업보다 재현성과 변경 관리에 유리하다.

8.9

Stack

설명CloudFormation 템플릿으로 생성된 리소스 묶음.

활용 예시개발 환경 전체 인프라를 하나의 Stack으로 관리한다.

시험 포인트업데이트/롤백 단위로 이해한다.

8.10

Cloud Development Kit, CDK

핵심

설명프로그래밍 언어로 CloudFormation 인프라를 정의하는 도구.

활용 예시
  1. TypeScript나 Python 코드로 CloudFormation 템플릿을 생성한다.
  2. 개발자가 익숙한 언어로 재사용 가능한 인프라 구성을 만든다.
  3. 최종적으로는 CloudFormation Stack을 배포한다는 점을 이해해야 한다.

시험 포인트시험에서는 깊게 코딩하지 않지만 IaC 선택지로 볼 수 있다.

8.11

X-Ray

설명분산 애플리케이션의 요청 흐름과 병목을 추적하는 서비스.

활용 예시API Gateway -> Lambda -> DynamoDB 요청 지연 원인을 추적한다.

시험 포인트CloudWatch가 로그/메트릭 중심이면 X-Ray는 트레이싱 중심이다.

8.12

Trusted Advisor

설명비용, 보안, 성능, 내결함성, 서비스 한도 관점으로 AWS 환경을 점검하는 서비스.

활용 예시사용하지 않는 리소스나 보안 위험 구성을 찾아낸다.

시험 포인트환경 점검과 권장 사항 제공 서비스로 이해한다.

8.13

Cost Explorer

설명AWS 비용과 사용량을 분석하는 서비스.

활용 예시서비스별 월별 비용 증가 원인을 확인한다.

시험 포인트이미 발생한 비용 분석에 적합하다.

8.14

AWS Budgets

설명예산 기준을 정하고 초과 예상 또는 초과 시 알림을 받는 서비스.

활용 예시월 AWS 비용이 50달러를 넘을 것으로 예상되면 알림을 받는다.

시험 포인트비용 알림/통제 요구에 자주 나온다.

8.15

Cost and Usage Report, CUR

설명상세한 비용/사용량 원천 데이터를 제공하는 리포트.

활용 예시Athena로 비용 데이터를 세부 분석한다.

시험 포인트가장 상세한 비용 데이터가 필요할 때 사용한다.

8.16

Compute Optimizer

설명EC2, Auto Scaling, EBS, Lambda 등의 리소스 크기 최적화를 추천하는 서비스.

활용 예시과도하게 큰 EC2 인스턴스를 줄이는 권장안을 받는다.

시험 포인트성능 데이터 기반 right-sizing 추천 서비스다.

8.17

AWS Organizations

핵심

설명여러 AWS 계정을 조직 단위로 묶어 관리하는 서비스.

활용 예시
  1. 개발/운영/보안 계정을 분리하고 중앙에서 관리한다.
  2. 통합 결제로 여러 계정 비용을 한 곳에서 확인한다.
  3. SCP를 사용해 조직 단위로 사용할 수 있는 AWS 작업을 제한한다.

시험 포인트SCP와 멀티 계정 전략이 함께 나온다.

8.18

Service Control Policy, SCP

핵심

설명AWS Organizations에서 계정 단위 최대 권한 경계를 제한하는 정책.

활용 예시
  1. 조직 전체에서 특정 리전 사용을 금지한다.
  2. 개발 계정에서는 고비용 인스턴스 타입 생성을 막는다.
  3. IAM 권한이 있어도 SCP에서 금지하면 해당 작업은 수행할 수 없다.

시험 포인트SCP는 권한을 부여하지 않고, 사용할 수 있는 최대 범위를 제한한다.

8.19

AWS RAM (Resource Access Manager)

설명Resource Access Manager. AWS 리소스를 다른 계정과 공유하는 서비스.

활용 예시여러 계정이 같은 Transit Gateway나 서브넷을 공유한다.

시험 포인트멀티 계정 리소스 공유 문제에 나온다.

9. 마이그레이션/분석/기타 자주 보는 서비스

9.1

Database Migration Service, DMS

설명Database Migration Service. DB를 AWS로 이전하거나 DB 간 복제를 지원하는 서비스.

활용 예시온프레미스 MySQL을 RDS로 마이그레이션한다.

시험 포인트동종/이종 DB 이전, CDC가 자주 나온다.

9.2

Schema Conversion Tool, SCT

설명서로 다른 DB 엔진 간 스키마 변환을 돕는 도구.

활용 예시Oracle 스키마를 PostgreSQL 호환 형태로 변환한다.

시험 포인트DMS와 함께 이종 DB 마이그레이션에 나온다.

9.3

DataSync

설명온프레미스와 AWS 스토리지 간 대량 파일 전송을 자동화하는 서비스.

활용 예시병원 파일 서버의 이미지 데이터를 S3로 주기적으로 동기화한다.

시험 포인트파일 전송 자동화, 증분 동기화에 적합하다.

9.4

Snow Family

설명대용량 데이터를 물리 장비로 옮기는 AWS 서비스 계열.

활용 예시네트워크로 전송하기 어려운 수십 TB 이상의 데이터를 AWS로 반입한다.

시험 포인트네트워크 전송이 비현실적일 때 선택한다.

9.5

Transfer Family

설명SFTP, FTPS, FTP로 S3/EFS에 파일을 주고받게 해주는 서비스.

활용 예시외부 병원이 SFTP로 파일을 올리면 S3에 저장한다.

시험 포인트기존 파일 전송 프로토콜을 유지해야 할 때 적합하다.

9.6

Athena

핵심

설명S3 데이터를 SQL로 바로 조회하는 서버리스 쿼리 서비스.

활용 예시
  1. S3에 쌓인 로그 파일을 서버 없이 SQL로 조회한다.
  2. CloudTrail 로그나 ALB 로그를 분석할 때 사용한다.
  3. 데이터를 별도 DB에 적재하지 않고 S3 데이터 레이크를 쿼리하는 방식이다.

시험 포인트서버를 만들 필요 없이 S3 기반 분석을 할 때 사용한다.

9.7

Glue

설명데이터 카탈로그와 ETL 작업을 지원하는 서비스.

활용 예시S3 로그 데이터를 정제해 분석 테이블로 만든다.

시험 포인트Athena와 함께 데이터 카탈로그/ETL 맥락에서 나온다.

9.8

OpenSearch Service

설명검색과 로그 분석에 사용하는 관리형 OpenSearch 서비스.

활용 예시서비스 로그를 색인해 검색하거나 대시보드를 만든다.

시험 포인트전문 검색/로그 분석 요구에 적합하다.

9.9

QuickSight

설명AWS의 BI 대시보드 서비스.

활용 예시비즈니스 지표를 대시보드로 시각화한다.

시험 포인트분석 결과 시각화 도구로 이해하면 충분하다.

9.10

Amplify

핵심

설명웹/모바일 앱 개발과 호스팅을 돕는 서비스 묶음.

활용 예시
  1. 프론트엔드 앱 배포, 인증, API 연동을 빠르게 구성한다.
  2. React/Next.js 프로젝트를 빠르게 호스팅하고 백엔드 기능을 붙일 때 사용한다.
  3. SAA에서는 깊게 나오지는 않지만 프론트엔드 개발자에게 친숙한 AWS 개발 플랫폼이다.

시험 포인트프론트엔드 친화 서비스지만 SAA에서는 깊은 구현보다 용도 중심으로 본다.

10. 참고

↑ 맨 위