Video coming soon
Please continue with the lesson material below.
시간이 없다면 — 압축본 먼저
Log in to save your progressLesson Material
시간이 없다면 — 압축본 먼저
전체 카드는 212장입니다. 시험이 이틀 안쪽으로 남았다면 이 압축본(81장)만 보고 바로 다음 파트로 넘어가세요. 여유가 있으면 이어지는 분류별 회차에서 전체를 봅니다.
여기 실린 항목이 곧 다음 회차들의 ★ 입니다. 같은 내용을 두 번 보는 게 아니라, 압축본은 목록이고 다음 회차들이 설명입니다.
꼭 알아야 할 서비스
각 행의 '신호'는 문제에서 그 서비스를 가리키는 키워드입니다. 설명보다 신호를 외우세요.
스토리지
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Amazon S3 | 무제한 객체 스토리지. 버킷에 파일을 담고 HTTPS로 접근하며 11 9s 내구성으로 리전 내 여러 AZ에 자동 복제된다. | 정적 파일·백업·로그·데이터레이크의 기본값. 단 OS가 마운트하는 파일시스템(EFS/FSx)이나 블록 디바이스(EBS)가 필요하면 오답. |
| S3 Standard | 기본 클래스. 최소 보관 기간과 최소 객체 크기 제약이 없고 밀리초 단위로 읽는다. | 접근이 빈번하고 패턴이 예측 가능할 때. 패턴을 모르면 Intelligent-Tiering이 정답. |
| S3 Intelligent-Tiering | 접근 패턴을 S3가 모니터링해 계층을 자동 이동. 객체당 소액 모니터링 수수료만 붙는다. | "접근 패턴을 알 수 없다", "수동 관리 없이 비용 절감". 검색 수수료와 성능 저하가 없어 Lifecycle 규칙을 직접 짜는 선택지보다 우선. |
| S3 Standard-IA | 드물게 접근하지만 즉시 읽어야 하는 데이터용. 최소 보관 30일, 최소 과금 128KB, GB당 검색 요금. | 월 1~2회 읽는 백업. 3개 이상 AZ에 저장되어 내구성은 Standard와 동일. |
| S3 One Zone-IA | Standard-IA와 같지만 단일 AZ 저장으로 약 20% 저렴. 최소 보관 30일. | 재생성 가능한 사본(썸네일, 2차 백업)에만. AZ 소실 시 데이터도 소실되므로 중요 데이터에는 오답. |
| S3 Glacier Instant Retrieval | 아카이브 클래스 중 유일하게 밀리초 즉시 조회. 최소 보관 90일. | "아카이브인데 즉시 접근"이면 이것. 분기 1회 읽는 의료 영상·미디어 자산. |
| S3 Glacier Flexible Retrieval | 저비용 아카이브. 복원은 Expedited 1 | 연 1 |
| S3 Glacier Deep Archive | S3에서 가장 싼 장기 아카이브. 복원 Standard 12시간, Bulk 48시간. 최소 보관 180일. | "7년 규정 보관"처럼 거의 읽지 않고 "가장 저렴하게"가 조건일 때. 분 단위 복원 요구면 오답. |
| S3 Lifecycle | 기간 기준으로 더 싼 클래스로 전환하거나 삭제하는 버킷 규칙. | "30일 후 IA, 90일 후 Glacier, 1년 후 삭제" 문장이 나오면 바로 이것. 전환은 더 차가운 방향으로만 가능. |
| S3 Versioning | 같은 키에 덮어써도 이전 버전을 모두 보관하고, 삭제는 삭제 마커만 추가한다. | 실수로 인한 덮어쓰기·삭제 복구 요구. 한 번 켜면 일시 중단만 가능하며 복제와 Object Lock의 전제 조건. |
| S3 Object Lock | 객체를 일정 기간 삭제·변경 불가하게 잠그는 WORM. Governance는 특별 권한으로 해제 가능, Compliance는 루트도 불가. | "규제 준수로 누구도 삭제할 수 없게"면 정답. 버전 관리 필수. 백업 대상의 같은 개념은 AWS Backup Vault Lock. |
| S3 Replication (CRR/SRR) | 객체를 다른 버킷으로 자동 복제. 다른 리전이면 CRR, 같은 리전이면 SRR. | DR과 사용자 근처 지연 감소는 CRR, 로그 집계·계정 간 분리는 SRR. 양쪽 버전 관리가 켜져야 하고 기존 객체는 배치 복제가 필요. |
| S3 이벤트 알림 | 객체 생성·삭제 이벤트를 SNS, SQS, Lambda, EventBridge로 발송. | "업로드되면 자동으로 처리(썸네일·메타데이터)"형 서버리스 파이프라인의 시작점. 폴링이나 스케줄 선택지보다 우선. |
| Amazon EBS | EC2에 붙이는 네트워크 블록 스토리지. 특정 AZ에 묶인 가상 하드디스크. | OS 디스크, DB 데이터 파일처럼 블록 접근이 필요할 때. 여러 인스턴스나 여러 AZ가 동시 공유해야 하면 EFS/FSx가 정답. |
| EBS gp3 / io2 | gp3는 용량과 IOPS를 분리 설정하는 범용 SSD, io2 Block Express는 최대 256000 IOPS의 프로비저닝 IOPS SSD. | "성능 유지하며 비용 절감"은 gp2에서 gp3 전환, "일관된 초고 IOPS와 서브밀리초 지연"은 io2. Multi-Attach는 io1/io2만 지원. |
| EBS 스냅샷 | EBS 볼륨을 S3에 증분 백업하는 기능. | EBS가 단일 AZ라는 제약을 넘는 표준 수단. 다른 리전으로 복사하면 DR, AMI로 만들면 인스턴스 복제. |
| Amazon EFS | 여러 Linux 인스턴스가 NFS로 동시에 마운트하는 관리형 공유 파일시스템. 용량이 자동 확장되고 여러 AZ에서 접근 가능. | "여러 EC2 또는 여러 AZ가 같은 파일을 동시에 읽고 쓴다"면 정답. Linux/NFS 전용이라 Windows SMB는 FSx for Windows, 단일 블록 디스크는 EBS. |
| FSx for Windows File Server | SMB, NTFS, Active Directory 통합을 지원하는 관리형 Windows 파일 서버. | "Windows 앱이 SMB 공유 드라이브 필요", "AD 권한 유지"면 정답. Linux NFS 공유면 EFS가 정답. |
| FSx for Lustre | HPC용 병렬 파일시스템. S3 버킷과 연동해 객체를 파일처럼 읽고 결과를 S3에 쓴다. | "S3 데이터에 고성능 파일 접근", ML 학습·유체 해석·렌더링이면 거의 확정. Scratch는 임시 고속, Persistent는 장기용. |
| AWS Storage Gateway | 온프레미스가 기존 프로토콜(NFS, SMB, iSCSI, VTL)로 쓰면서 실제 데이터는 AWS에 저장되는 하이브리드 게이트웨이. | "앱을 수정하지 않고 클라우드 스토리지 사용"이면 정답. 일회성 대량 이전은 DataSync나 Snowball이고 이쪽은 지속적 하이브리드 연결용. |
| S3 File Gateway | 온프레미스에서 NFS/SMB로 마운트하면 파일이 S3 객체로 저장되는 유형. | 파일 서버를 S3로 확장하고 Lifecycle로 Glacier까지 보낼 때. 저장 대상이 FSx면 FSx File Gateway. |
| Volume Gateway | 온프레미스에 iSCSI 블록 볼륨을 제공하고 EBS 스냅샷으로 AWS에 백업하는 유형. | Stored는 주 데이터를 로컬에 두어 저지연 접근이 필수일 때, Cached는 주 데이터를 AWS에 두어 온프레미스 용량을 줄일 때. |
| AWS Backup | EBS, EFS, FSx, RDS, DynamoDB, S3, EC2 등을 정책으로 일괄 백업·복원하는 중앙 관리 서비스. | "중앙에서 일관된 백업 정책과 보관 기간 적용", 계정 간·리전 간 복사. EBS 스냅샷만이면 Data Lifecycle Manager로도 충분. |
전송·마이그레이션
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| AWS DataSync | 온프레미스(NFS, SMB, HDFS)와 AWS 스토리지(S3, EFS, FSx) 사이를 에이전트로 자동 전송·동기화하는 온라인 전송 서비스. | 회선이 충분할 때의 대량 전송 기본값. 1Gbps면 하루 약 10TB가 기준선이고, 이보다 느리면 Snow 계열, 지속적 하이브리드 접근이면 Storage Gateway. |
| AWS Snowball Edge | AWS가 보내준 물리 장비에 데이터를 담아 우편으로 반송해 S3에 적재하는 오프라인 전송 장비. 수십 TB급(Storage Optimized 약 80TB). | "인터넷 대역폭이 제한적", "1Gbps 미만 회선에 100TB"처럼 온라인 전송이 몇 주 이상 걸릴 때. 수 TB면 Snowcone이 적정. |
| AWS Snowcone | 약 8TB(HDD) 또는 14TB(SSD)의 가장 작고 휴대 가능한 Snow 장비. DataSync 에이전트를 내장 실행할 수 있다. | 공간·전력이 제한된 현장이나 드론·차량의 소량 수집. 수십 TB 이상이면 Snowball Edge. |
| AWS DMS | 소스를 계속 가동한 상태로 복제해 DB를 최소 다운타임으로 AWS로 옮기는 관리형 마이그레이션 서비스. | RDS, Aurora, Redshift, DynamoDB, S3로 DB 이전. 엔진이 같으면 DMS 단독, 다르면 SCT와 조합. CDC로 초기 로드 후 변경을 따라가 커트오버만 짧게 전환. |
| AWS Transfer Family | SFTP, FTPS, FTP로 들어오는 파일 전송을 S3나 EFS에 직접 연결하는 관리형 서비스. | 파트너가 기존 SFTP 클라이언트와 스크립트를 그대로 쓰면서 저장소만 S3로 바꿀 때. EC2에 SFTP 서버를 직접 운영하는 선택지보다 우선. |
| S3 Transfer Acceleration | CloudFront 엣지를 입구로 삼아 AWS 백본으로 S3까지 보내 장거리 업로드를 가속하는 버킷 단위 기능. | 멀리 떨어진 여러 지역 사용자가 한 버킷에 대용량 파일을 올려 느릴 때. 멀티파트 업로드와 조합. 다운로드 가속·캐싱이면 CloudFront. |
컴퓨트·컨테이너
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Amazon EC2 | OS와 패치까지 직접 관리하는 가상 서버. | 기존 앱 리프트 앤 시프트, OS 수준 제어 필요. 반대로 "운영 오버헤드 최소화"가 있으면 오답 쪽. |
| Amazon EC2 Auto Scaling | 수요에 맞춰 EC2 대수를 자동 조절하고 비정상 인스턴스를 교체. | 고가용성 + 탄력성 동시 요구. 답은 항상 여러 AZ에 걸친 ASG + 로드 밸런서 조합. 앱 장애 인스턴스까지 교체하려면 ELB 상태 확인을 켜야 한다. |
| 스케일링 정책 4종 | 대상 추적(목표 지표 유지, 가장 단순) / 단계·단순 조정(경보 구간별 증감) / 예약(시각 지정) / 예측(ML로 미리 증설). | "지표 하나를 일정하게"는 대상 추적, "매주 월요일 9시처럼 시점을 이미 안다"는 예약, "주기적이나 시각 특정 어렵고 워밍업 필요"는 예측, 구간별 다른 대응은 단계 조정. |
| Launch template | AMI, 인스턴스 타입, 보안 그룹 등 기동 설정을 담은 버전 관리 틀. | ASG가 인스턴스를 찍어내는 원본. 온디맨드와 스팟 혼합 인스턴스 정책, 버전 관리는 시작 구성(launch configuration)으로는 불가. |
| EC2 Spot Instance | 남는 용량을 최대 90퍼센트 싸게 쓰는 대신 2분 중단 알림 후 회수될 수 있는 인스턴스. | 상태 비저장 배치, 빅데이터, CI 빌드 + 비용 절감. "중단되면 안 된다", "상태 유지 필요"가 있으면 무조건 탈락. |
| AWS Lambda | 함수 코드만 올리면 이벤트마다 실행되고 실행 시간만 과금되는 서버리스 컴퓨트. | "이벤트 기반", "운영 오버헤드 최소", "유휴 비용 0". 한도는 최대 실행 15분(900초), 메모리 128MB |
| Amazon ECS | AWS 자체 컨테이너 오케스트레이터. 작업 정의를 올리면 배치와 관리를 대신한다. | Kubernetes 호환이 필요 없고 IAM·ALB·CloudWatch 통합이 중요할 때. 작업 IAM 역할(앱 권한)과 작업 실행 역할(이미지 풀·로그) 구분 출제. |
| Amazon EKS | 관리형 Kubernetes 컨트롤 플레인. | 지문에 Kubernetes, 헬름, 멀티 클라우드 이식성, 기존 온프레미스 K8s가 있으면 EKS. 단순히 컨테이너만 돌리면 되는 문제에서는 운영 복잡도 때문에 오답. |
| AWS Fargate | 서버 없이 컨테이너를 돌려주는 실행 환경. ECS·EKS의 시작 유형 중 하나. | 컨테이너 + 운영 부담 최소. EC2 launch type은 호스트 OS 패치가 사용자 책임으로 남아 오답. 반대로 GPU, 특정 인스턴스 타입, 호스트 커스터마이징, 기존 예약 인스턴스 활용이면 EC2 유형. 태스크당 최대 16 vCPU. |
| AWS Batch | 배치 작업을 큐에 넣으면 필요한 컴퓨트(EC2 또는 Fargate)를 띄워 실행하고 정리한다. | 대량 일괄 처리 + "클러스터 관리 없이", 작업 큐와 우선순위, 스팟으로 비용 절감. Lambda 15분 제한을 넘기는 작업의 대체안. |
| AWS Elastic Beanstalk | 코드를 올리면 EC2, 로드 밸런서, Auto Scaling까지 자동 구성해 주는 플랫폼 서비스. | "코드만 신경 쓰고 인프라 구성은 맡긴다" + 기존 웹앱. 블루/그린, 롤링, 불변 배포 옵션 선택이 출제된다. |
데이터베이스
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Amazon RDS | 백업·패치·복구를 AWS가 맡는 관리형 관계형 DB(MySQL, PostgreSQL, MariaDB, Oracle, SQL Server). | 기존 SQL 앱을 코드 수정 없이 이전. 스토리지는 늘릴 수만 있고 줄일 수 없다. OS 접근이 필요하면 RDS는 불가. |
| RDS Multi-AZ | 다른 AZ에 동기 복제되는 대기 인스턴스를 두고 자동 페일오버. | "고가용성", "자동 페일오버", "유지보수 중 중단 최소화". 대기 인스턴스는 읽기 트래픽을 받지 않으므로 성능 향상 목적에 고르면 오답. 엔드포인트는 그대로 유지된다. |
| RDS 읽기 전용 복제본 | 비동기 복제로 읽기 쿼리만 처리하는 복사본. 최대 15개, 크로스 리전 가능. | "읽기 부하 분산", "리포팅 쿼리가 운영 DB를 느리게 한다", "읽기 성능 확장". Multi-AZ(가용성·동기·읽기 불가)와 최다 혼동 지점이며 이쪽은 읽기 확장·비동기·복제 지연 존재. |
| RDS 자동 백업·PITR | 일일 스냅샷과 트랜잭션 로그로 보존 기간 내 임의 시점으로 복구. | "몇 분 전 상태로 되돌리기", RPO 5분 수준. 자동 백업 보존 최대 35일이고 더 오래 두려면 수동 스냅샷. 복구는 덮어쓰기가 아니라 새 인스턴스 생성. |
| RDS Proxy | RDS·Aurora 앞단의 완전관리형 DB 커넥션 풀. | Lambda 폭증으로 DB 커넥션이 고갈되는 시나리오. 페일오버 시간 단축, Secrets Manager·IAM 인증 연동. |
| Amazon Aurora | MySQL·PostgreSQL 호환 AWS 자체 엔진. 3개 AZ 6중 복제, 최대 128TiB 자동 확장. | "같은 SQL인데 더 높은 성능과 가용성". 복제본 최대 15개, 페일오버가 RDS Multi-AZ보다 빠름(보통 30초 내). 쓰기는 클러스터 엔드포인트, 읽기는 리더 엔드포인트. 자동 백업 보존 최대 35일. |
| Aurora Serverless | 사용량에 따라 용량(ACU)을 자동 증감하는 Aurora 구성. | 간헐적·예측 불가 워크로드, 개발/테스트, 유휴 시간 비용 절감. 일정한 고부하면 프로비저닝 Aurora. |
| Aurora Global Database | 주 리전 쓰기 + 최대 5개 보조 리전 읽기 전용 복제. 복제 지연 보통 1초 미만. | "여러 리전 읽기 지연 감소 + 리전 단위 DR". 보조 리전은 읽기 전용(승격 RTO 약 1분)이므로 다중 리전 쓰기가 필요하면 DynamoDB 글로벌 테이블. |
| Amazon DynamoDB | 서버리스 NoSQL 키-값·문서 DB. 한 자릿수 밀리초 응답, 기본 3개 AZ 복제. | "서버리스", "스키마 유연", "초당 수백만 요청", "키로 조회". 항목 최대 크기 400KB. 조인이나 임의 조건 집계가 필요하면 RDS/Aurora. 핫 파티션은 파티션 키 카디널리티 부족이 원인. |
| DynamoDB 용량 모드 | 온디맨드는 쓴 만큼 과금, 프로비저닝은 RCU/WCU를 미리 지정. | 예측 불가·스파이크성·신규 서비스면 온디맨드. 꾸준하고 예측 가능한 부하에서 비용 절감이면 프로비저닝 + Auto Scaling. 한도 초과 시 ProvisionedThroughputExceededException 스로틀링. |
| DynamoDB Accelerator(DAX) | DynamoDB 전용 인메모리 캐시 클러스터. API 호환으로 읽기를 마이크로초급으로 줄인다. | "DynamoDB 읽기를 더 빠르게" + "코드 변경 최소화", 같은 항목 반복 조회. 쓰기 위주에는 효과 없고 ElastiCache는 캐시 로직을 직접 구현해야 해서 밀린다. |
| DynamoDB 글로벌 테이블 | 여러 리전에 양방향 자동 복제되는 액티브-액티브 테이블. | "전 세계 낮은 지연" + "리전 장애에도 쓰기 유지". 최종 일관성이며 충돌은 마지막 쓰기 우선. 활성화에 DynamoDB Streams 필요. |
| Amazon ElastiCache | Redis 또는 Memcached를 관리형으로 제공하는 인메모리 캐시. | "DB 읽기 부하 과도", "밀리초 미만", "세션 상태 저장". Redis는 복제·자동 페일오버·스냅샷 영속·정렬 세트가 있어 고가용성·영속성·세션 공유·리더보드면 정답이고 Memcached는 단순 키-값 멀티스레드 캐시로 복제·영속성이 없어 그런 요구가 보이면 오답. |
네트워킹
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Amazon VPC | 계정 안에 만드는 전용 가상 네트워크. 하나의 리전에 속하고 여러 AZ에 걸친다. | 거의 모든 리소스가 그 안에 들어간다. 고가용성 요구가 나오면 최소 2개 AZ에 서브넷을 두는 구성이 정답. |
| 퍼블릭/프라이빗 서브넷 | VPC의 IP 범위를 자른 구역으로 서브넷 하나는 AZ 하나에만 속한다. | 구분 기준은 이름이 아니라 라우팅 테이블이 0.0.0.0/0을 인터넷 게이트웨이로 보내는지 여부다. DB는 프라이빗, 로드 밸런서는 퍼블릭이 기본 패턴. |
| NAT Gateway | 프라이빗 서브넷 인스턴스의 아웃바운드 인터넷 접근만 허용하는 관리형 서비스. | 나가는 통신만 필요할 때. IPv4 전용이라 IPv6는 egress-only internet gateway. 퍼블릭 서브넷에 두고 AZ마다 하나씩, NAT 인스턴스보다 NAT Gateway가 정답. |
| 보안 그룹 | 인스턴스(ENI) 단위 가상 방화벽. | 상태 저장이라 인바운드 허용의 응답은 자동으로 나간다. allow 규칙만 가능해 특정 IP 차단은 불가. 다른 보안 그룹 ID를 소스로 지정하는 계층 간 제어가 특징. |
| 네트워크 ACL | 서브넷 단위 방화벽. | 상태 비저장이라 인바운드와 아웃바운드, 임시 포트를 각각 열어야 한다. deny 규칙이 가능하므로 특정 IP 차단 요구는 NACL이 정답. |
| VPC gateway endpoint | VPC에서 S3와 DynamoDB로 가는 사설 경로. 라우팅 테이블에 경로가 추가된다. | 인터넷이나 NAT 없이 S3 접근 + 추가 비용 없음. 대상이 S3나 DynamoDB가 아니면 interface endpoint. 온프레미스에서는 사용 불가. |
| VPC interface endpoint / PrivateLink | 서브넷에 ENI를 만들어 S3·DynamoDB 외의 서비스나 타 계정·SaaS 서비스를 사설로 호출한다. | S3·DynamoDB 외 모든 서비스, 시간당 과금, 보안 그룹으로 제어, Direct Connect나 VPN 경유 온프레미스 접근 가능. 수많은 VPC가 한 서비스에 접근하면 피어링이 아니라 PrivateLink이고 제공자 쪽에는 NLB가 필요하다. |
| VPC 피어링 | 두 VPC를 1대1로 연결해 프라이빗 IP로 통신시킨다. | 전이적 라우팅 불가라 A-B, B-C가 있어도 A는 C와 통신 못 한다. CIDR이 겹치면 불가. 연결 수가 많아지면 Transit Gateway. |
| Transit Gateway | 여러 VPC와 온프레미스 연결을 중앙 허브에 모아 라우팅한다. | 피어링이 그물망처럼 복잡해질 때가 정답 신호. 전이적 라우팅 지원, Direct Connect와 VPN도 연결, 멀티캐스트 지원. |
| Direct Connect | 온프레미스와 AWS를 잇는 전용 물리 회선으로 인터넷을 거치지 않는다. | 일관된 저지연, 안정적 대역폭, 대용량 상시 전송이면 정답. 구축에 수주~수개월이 걸리므로 즉시 필요하면 VPN 먼저. 이중화는 DX 2회선 또는 DX + VPN 백업. |
| Site-to-Site VPN | 온프레미스와 AWS 사이에 인터넷 경유 IPsec 터널을 만든다. | 빠르고 저렴한 구축이 요구되거나 Direct Connect의 백업 경로로 출제된다. 대역폭과 지연이 인터넷 상황에 좌우되는 것이 단점. |
로드밸런싱·엣지
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Application Load Balancer | HTTP/HTTPS를 내용에 따라 분배하는 L7 로드 밸런서. | 경로·호스트·헤더 기반 라우팅, 마이크로서비스, ECS 동적 포트 매핑, Lambda 대상, Cognito/OIDC 인증이면 ALB. 클라이언트 IP는 X-Forwarded-For로 전달된다. |
| Network Load Balancer | TCP·UDP·TLS를 초저지연으로 처리하는 L4 로드 밸런서. | 수백만 RPS, UDP, AZ별 고정 IP(Elastic IP)면 NLB. PrivateLink 제공자 쪽에 필수. HTTP 경로 기반 라우팅이 필요하면 ALB. |
| Gateway Load Balancer | 서드파티 가상 어플라이언스로 트래픽을 투명하게 보내고 되돌려 받는 로드 밸런서. | 방화벽·IDS/IPS·심층 패킷 검사를 모든 트래픽에 거치게 하되 앱 설정은 그대로 두고 싶을 때. GENEVE 6081과 GWLB 엔드포인트가 키워드. |
| Amazon CloudFront | 전 세계 엣지에 콘텐츠를 캐싱하는 CDN. | 정적 콘텐츠 지연과 오리진 부하 감소면 정답. S3 보호는 OAC, 유료 콘텐츠 제한은 서명된 URL/쿠키, 국가 차단은 지리적 제한, 공격 방어는 WAF 결합. CloudFront용 ACM 인증서는 반드시 us-east-1에서 발급. 업로드 가속은 S3 Transfer Acceleration. |
| AWS Global Accelerator | AWS 백본과 고정 anycast IP로 트래픽을 최적 리전 엔드포인트로 보낸다. | 캐싱이 없다는 점이 CloudFront와의 핵심 차이. 비HTTP(TCP/UDP), 고정 IP 2개, DNS TTL에 의존하지 않는 빠른 리전 페일오버면 정답. 정적 콘텐츠 캐싱이면 CloudFront. |
| Amazon Route 53 | 관리형 DNS. 도메인 등록, 레코드, 상태 확인, 라우팅 정책을 제공한다. | Alias 레코드는 AWS 리소스를 가리키며 무료이고 루트 도메인에도 쓸 수 있다. CNAME은 루트 도메인 불가. 상태 확인과 묶인 DR 구성이 단골. |
| Route 53 - 지연 시간 / 지리 위치 | latency는 측정된 지연이 가장 낮은 리전으로, geolocation은 사용자의 국가·대륙 기준으로 보낸다. | 성능과 가장 빠른 응답이면 latency, 데이터 주권·라이선스·언어처럼 특정 국가를 특정 리전에 고정해야 하면 geolocation. geolocation은 기본 레코드를 반드시 둔다. |
| Route 53 - 장애 조치(failover) | 기본 엔드포인트의 상태 확인이 실패하면 보조로 넘긴다. | 액티브-패시브 DR의 표준 답이며 상태 확인이 필수다. 보조를 S3 정적 웹사이트 안내 페이지로 두는 구성도 나온다. |
| Route 53 - 나머지 정책 | simple은 단순 응답이고 상태 확인 불가, weighted는 비율 분배, geoproximity는 거리와 bias, multivalue는 정상 레코드 최대 8개 반환. | 카나리와 블루/그린, A/B 테스트면 weighted. DNS 수준의 간단한 분산과 가용성이면 multivalue. |
보안·자격증명
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| AWS IAM | 누가 어떤 리소스에 무엇을 할 수 있는지 정하는 글로벌 권한 관리 서비스. | 평가 순서는 명시적 Deny 우선, 그다음 Allow, 아무것도 없으면 암묵적 Deny. 교차 계정 접근은 대상 계정에 role을 만들고 assume role로 푼다. |
| IAM role (instance profile) | EC2·Lambda가 AWS 서비스를 호출할 때 쓰는 임시 자격 증명. | EC2가 S3에 접근. 액세스 키를 인스턴스나 코드에 심는 선택지는 항상 오답. |
| AWS KMS | 암호화 키를 만들고 보관하며 사용 권한을 통제하는 관리형 키 서비스. | 고객 관리 키(CMK)는 키 정책 직접 작성과 자동 교체·삭제 예약·교차 계정 공유가 되고 AWS 관리 키는 안 된다. 키는 리전 종속이라 암호화된 스냅샷을 다른 리전에 복사하면 대상 리전 키로 재암호화된다. |
| S3 암호화 방식 (SSE-S3 / SSE-KMS / SSE-C) | S3 객체 암호화 방식으로 키를 누가 관리하느냐가 차이. | SSE-S3는 S3가 키를 전부 관리하는 기본값이고 SSE-KMS 고객 관리 키는 키 교체와 CloudTrail 감사 추적이 필요할 때, SSE-C는 고객이 요청마다 키를 보내고 AWS는 키를 저장하지 않을 때다. KMS 요청 한도가 걸리면 S3 Bucket Key를 켠다. |
| AWS Certificate Manager (ACM) | SSL/TLS 인증서를 무료로 발급하고 만료 전 자동 갱신해 주는 서비스. | CloudFront·ALB·API Gateway의 HTTPS 종료. CloudFront용 인증서는 반드시 us-east-1에서 발급하고 EC2에 직접 설치하는 용도로는 못 쓴다. |
| AWS WAF | SQL 인젝션·XSS·국가/IP 차단·요청률 제한 같은 L7 웹 공격을 막는 웹 방화벽. | CloudFront·ALB·API Gateway에만 붙고 NLB에는 못 붙으므로 NLB 구성은 앞에 CloudFront를 둔다. 특정 IP의 과도한 요청 차단은 요율 기반 규칙. |
| AWS Shield | DDoS 방어 서비스로 Standard와 Advanced 두 등급이 있다. | Standard는 모든 계정에 자동 적용되는 무료 L3/L4 방어, Advanced는 유료 구독으로 SRT 전문가 지원과 DDoS 급증 요금 비용 보전을 제공한다. 비용 보전이나 전문가 대응이 나오면 Advanced. |
| Amazon Macie | 머신러닝으로 S3를 스캔해 주민번호·카드번호 같은 민감정보(PII)를 찾아내는 서비스. | S3에 민감정보가 있는지 찾아라는 문구. 위협 탐지는 GuardDuty, 취약점 스캔은 Inspector로 구분한다. |
| Amazon GuardDuty | CloudTrail·VPC Flow Logs·DNS 로그를 분석해 비정상 API 호출과 악성 통신을 찾는 위협 탐지 서비스. | 에이전트 설치 없이 켜기만 하면 되는 계정 내 위협 탐지. 탐지만 하고 차단은 안 하며 발견 사항을 EventBridge로 받아 Lambda나 SNS로 자동 대응하는 패턴이 단골. |
| Amazon Inspector | EC2·ECR 이미지·Lambda를 스캔해 알려진 소프트웨어 취약점(CVE)을 찾는 서비스. | 취약점 스캔이라는 단어. EC2 스캔에는 SSM Agent가 필요하고 실제 패치 적용은 Systems Manager Patch Manager다. |
| AWS Secrets Manager | DB 비밀번호와 API 키를 암호화 보관하고 API로 꺼내 쓰게 하는 서비스. | 자동 교체(rotation)가 요구사항이면 무조건 이것. RDS·Aurora·Redshift는 AWS 제공 Lambda로 자동 교체되며 비밀 1건당 월 요금이 붙는다. |
| Systems Manager Parameter Store | 설정값과 비밀 값을 계층형 경로로 저장하는 구성 저장소. SecureString은 KMS로 암호화된다. | 단순 저장이고 비용을 아껴야 하면 이것. 표준 파라미터는 무료지만 자동 교체 기능이 없으므로 교체가 필요하면 Secrets Manager로 간다. |
| Amazon Cognito | 웹·모바일 앱의 회원가입, 로그인, 소셜 및 SAML 로그인을 대신 처리하는 인증 서비스. | 앱 최종 사용자 수백만 명 인증. 사용자 풀은 인증 담당, 자격 증명 풀은 인증된 사용자에게 임시 AWS 자격 증명 발급. 직원의 AWS 콘솔 로그인은 IAM Identity Center다. |
| CloudFront signed URL / signed cookie / OAC | CloudFront 콘텐츠 접근을 제한하는 세 가지 수단. | 개별 파일 하나만 제한하면 signed URL, 여러 파일이나 전체 라이브러리를 제한하면 signed cookie, S3 버킷 직접 접근을 막고 CloudFront 경유만 허용하면 OAC(구 OAI)다. |
거버넌스·멀티 계정
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| AWS Organizations | 여러 AWS 계정을 하나의 조직으로 묶어 통합 결제와 중앙 정책 관리를 하는 서비스. | 통합 결제로 볼륨 할인과 RI·Savings Plans 공유. 리소스 정책에서 조직 전체에 접근을 허용하려면 aws:PrincipalOrgID 조건 키를 쓴다. |
| 서비스 제어 정책 (SCP) | OU나 계정이 쓸 수 있는 권한의 최대 범위를 정하는 가드레일 정책. | 권한을 주지 않고 한계만 정하므로 IAM Allow가 별도로 있어야 동작한다. 관리 계정에는 적용되지 않고 멤버 계정 루트에는 적용된다. 조직 전체 특정 리전·서비스 금지 문제의 정답. |
| AWS Config | 리소스 설정 변경 이력을 기록하고 규칙 위반을 자동 평가하는 설정 감사 서비스. | 설정이 언제 어떻게 바뀌었고 규정을 지키는지. API 호출자 기록은 CloudTrail, 지표·알람은 CloudWatch. 위반 시 SSM Automation으로 자동 수정하고 Aggregator로 다계정·다리전 준수 상태를 모은다. |
| AWS RAM (Resource Access Manager) | 내 계정의 리소스를 복제 없이 다른 계정이나 조직 전체가 그대로 쓰게 공유하는 서비스. | 여러 계정이 중앙 VPC 서브넷이나 Transit Gateway를 함께 쓰는 구성. 추가 비용이 없고 Organizations 연동 시 초대 수락 없이 공유된다. |
| AWS Control Tower | 멀티 계정 랜딩 존을 모범 사례대로 자동 구성해 주는 서비스. | 새 다계정 환경을 표준대로 빠르게 세우라는 요구사항. Organizations·IAM Identity Center·Config·CloudTrail·로그 계정을 한 번에 세팅하고 Account Factory로 새 계정을 발급한다. |
통합·메시징
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Amazon SQS | 메시지를 쌓아두는 대기열. 소비자가 당겨서(pull) 처리한다. | 트래픽 급증 흡수(버퍼링), 작업 유실 방지, 컴포넌트 분리. 한 메시지는 한 소비자만 처리(1:1). 처리 오래 걸리면 가시성 제한 시간 늘리고, 반복 실패는 DLQ. |
| SQS FIFO 큐 | 순서를 지키고 중복을 제거하는 큐. | 지문에 순서 보장, 정확히 한 번 처리, 중복 제거가 나오면 무조건 FIFO. 그 외에는 표준 큐. |
| Amazon SNS | 주제에 한 번 발행하면 구독자 전체에 밀어주는(push) 알림. | 하나의 이벤트를 여러 대상에 동시 전파(팬아웃, 1:N), 이메일/SMS 알림. SNS는 보관하지 않으므로 유실 방지가 필요하면 뒤에 SQS를 붙인다. |
| SNS to SQS 팬아웃 | SNS 주제에 여러 SQS 큐를 구독시켜 같은 메시지를 복사해 넣는 패턴. | 한 메시지를 여러 시스템이 각자 독립적으로 처리해야 하면 이 조합. 소비자별 버퍼링과 재처리가 가능해진다. |
| Amazon EventBridge | 이벤트를 규칙에 따라 원하는 대상으로 라우팅하는 이벤트 버스. 일정 실행도 된다. | 이벤트 내용(패턴) 기반 분기, cron/rate 주기 실행, AWS 서비스 상태 변화 자동 대응, SaaS 파트너 이벤트. 단순 알림 전파면 SNS. |
| Amazon API Gateway | HTTP 요청을 받아 Lambda나 백엔드로 넘겨주는 API 현관문. | 서버 없이 REST/HTTP/WebSocket API 공개. 스로틀링과 사용량 계획으로 호출 제한, 캐싱으로 백엔드 부하 감소, 인증은 IAM/Cognito/Lambda 권한 부여자. 통합 제한 29초라 긴 작업은 비동기로. |
| AWS Step Functions | 여러 단계 작업을 상태 기계 워크플로로 묶어 실행하는 오케스트레이션. | 순차/분기/병렬/재시도 흐름을 코드 밖에서 관리, Lambda 15분 제한을 넘는 긴 처리, 사람 승인 대기. 대량 항목 병렬 반복은 Map 상태. |
분석
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Kinesis Data Streams | 실시간 스트림을 샤드에 보관해 여러 소비자가 순서대로 읽게 하는 서비스. | 실시간 대량 이벤트, 순서 보장, 같은 데이터를 여러 앱이 각자 처리, 재처리 필요. 기본 보존 24시간(최대 365일)이라 SQS와 달리 재생 가능. 처리량은 샤드로 확장. |
| Kinesis Data Firehose | 스트림을 버퍼링해 S3, Redshift, OpenSearch 등으로 자동 적재하는 완전관리형 전송. | 코드 없이 스트림 저장, 운영 부담 최소, 서버리스 적재. 소비자 앱을 직접 만들 수 없고 버퍼 때문에 근실시간(수십 초 지연). |
| AWS Glue | 서버리스 ETL과 중앙 메타데이터 카탈로그. 크롤러가 스키마를 자동 탐지한다. | 서버 관리 없는 ETL, S3 데이터 정제, 스키마 자동 탐지. 데이터 레이크 기본 조합은 S3 + Glue 카탈로그 + Athena이며 카탈로그는 Athena/Redshift Spectrum/EMR이 공유한다. |
| Amazon Athena | S3 데이터를 옮기지 않고 표준 SQL로 바로 조회하는 서버리스 쿼리 서비스. | 애드혹 쿼리, 간헐적 S3 로그 분석, 인프라 구축 없이 즉시. 비용 절감 답은 Parquet/ORC 컬럼형 + 압축 + 파티셔닝으로 스캔량 감소. |
| Amazon Redshift | 대용량 분석 전용 컬럼형 데이터 웨어하우스. | 지속적인 대용량 BI 대시보드, 복잡한 조인과 집계 반복, 여러 원본 통합 분석. OLTP에 쓰면 오답(그쪽은 RDS/Aurora). 간헐적 조회면 Athena. |
| Amazon EMR | Hadoop, Spark, Hive, Presto를 EC2 클러스터로 띄워주는 관리형 빅데이터 서비스. | 지문에 Spark/Hadoop/Hive가 직접 등장하거나 기존 빅데이터 클러스터 마이그레이션. 비용 최적화는 태스크 노드를 스팟으로, 데이터는 S3(EMRFS)에. |
| Amazon QuickSight | 브라우저에서 쓰는 서버리스 BI 시각화 서비스. | 경영진용 대시보드, 서버 없이 시각화. SPICE 인메모리 엔진, 행 수준 보안으로 사용자별 데이터 제한. |
| Amazon OpenSearch Service | 로그와 문서를 색인해 전문 검색과 대시보드를 제공하는 관리형 검색·분석 엔진. | 로그 검색과 시각화, 전문 검색, 거의 실시간 운영 분석. 전형적 파이프라인은 Kinesis나 Firehose로 받아 OpenSearch에 적재. |
모니터링·운영
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Amazon CloudWatch | AWS 리소스의 성능 지표, 로그, 알람, 대시보드를 모아 보는 모니터링 서비스. | CPU 사용률, 지연 시간 같은 성능 지표와 로그 수집, 임계값 초과 시 SNS 알림이나 Auto Scaling 실행. 누가 API를 호출했는지는 CloudTrail. |
| CloudWatch agent | EC2와 온프레미스 서버에 설치해 추가 지표와 로그를 보내는 에이전트. | EC2 메모리 사용률과 디스크 사용률은 기본 지표가 아니므로 agent 설치가 정답. 애플리케이션 로그를 CloudWatch Logs로 보낼 때도 필요. |
| AWS CloudTrail | 계정에서 누가 언제 어떤 API를 호출했는지 기록하는 감사 로그. | 보안 감사, 변경 주체 추적, 규정 준수 증적. 장기 보관은 S3 추적, S3 객체 수준 접근은 데이터 이벤트를 따로 켜야 한다. |
| AWS Systems Manager | EC2와 온프레미스 서버를 한 곳에서 운영하는 관리 도구 묶음. | Session Manager는 22번 포트와 키 페어, 배스천 없이 셸 접속. Patch Manager는 대규모 서버 패치 자동 적용과 준수 보고, Run Command는 여러 인스턴스에 명령 일괄 실행. |
| AWS CloudFormation | 인프라를 템플릿 코드로 정의해 스택 단위로 배포하는 서비스. | 동일 환경 반복 재현, 여러 리전·계정 배포(StackSets), 변경 집합으로 사전 영향 확인, 실패 시 자동 롤백. |
비용
| 서비스 | 한 줄 설명 | 이게 정답이 되는 신호 |
|---|---|---|
| Savings Plans | 1년 또는 3년간 시간당 일정 금액을 약정하고 할인받는 방식. | 상시 가동이면서 인스턴스 유형이나 리전을 바꿀 유연성이 필요할 때. Compute Savings Plans는 EC2, Fargate, Lambda까지 적용되어 가장 유연하다. |
| 예약 인스턴스(RI) | 인스턴스 유형과 리전을 1~3년 약정하고 최대 약 72% 할인받는 방식. | 장기간 계속 켜 두는 안정적 워크로드. 구성을 고정해도 되면 RI, 유연성이 필요하면 Savings Plans. RDS, ElastiCache, Redshift에도 있다. |
| 스팟 인스턴스 | 남는 용량을 최대 약 90% 싸게 쓰지만 2분 통보 후 회수될 수 있는 방식. | 중단을 견디는 배치 처리, 빅데이터 분석, CI 빌드. 상태 저장 워크로드나 DB에는 오답. 기준 부하는 RI/Savings Plans, 변동분은 온디맨드, 내결함성 초과분은 스팟이 정석 조합. |
| AWS Cost Explorer | 지난 비용과 사용량을 그래프로 분석하고 예측하는 도구. | 어느 서비스나 태그에서 비용이 늘었는지 사후 분석, 구매 권고와 우량 사이즈 권고 확인. |
| AWS Budgets | 비용이나 사용량 한도를 정하고 초과나 초과 예상 시 알리는 서비스. | 예산 한도 초과 사전 경고, SNS 알림, Budgets Actions로 자동 조치. 과거 분석은 Cost Explorer, 한도 알림은 Budgets. |
Q&A0
Only students taking this course can post questions.
No questions yet. Be the first to ask!