AWS 용어 정리 스크립트

Kjjedd·2026년 4월 16일

aws

CS

목록 보기

3/3

AWS 용어 정리 스크립트

문서 구조

AWS 기초와 글로벌 인프라
네트워크 기초
네트워크 연결과 엣지
컴퓨팅
컨테이너와 서버리스
스토리지
데이터베이스
메시징, 이벤트, 통합
데이터 분석과 BI
보안과 IAM
운영, 배포, 비용 최적화
백업, 복구, 마이그레이션
커뮤니케이션/기타 서비스

AWS 기초와 글로벌 인프라

AWS를 처음 배울 때 가장 먼저 잡아야 하는 바닥 개념이다. 글로벌 인프라와 책임 경계를 이해해야 이후 서비스 설명이 자연스럽게 이어진다.

0. AWS란 무엇인가

AWS(Amazon Web Services) 는 AWS가 제공하는 클라우드 컴퓨팅 플랫폼이다. 서버, 네트워크, 스토리지, 데이터베이스, 메시징, 분석, 보안, AI 서비스까지 필요한 인프라를 필요한 만큼 빌려 쓸 수 있다.

왜 필요한가

서버를 미리 대량 구매하지 않아도 된다.
사용량에 따라 확장과 축소가 쉽다.
글로벌 인프라를 빠르게 활용할 수 있다.
관리형 서비스를 활용하면 운영 부담을 크게 줄일 수 있다.

클라우드의 핵심 가치

민첩성: 몇 분 안에 인프라를 만들고 실험할 수 있다.
탄력성: 트래픽이 늘면 확장하고 줄면 축소할 수 있다.
종량제 과금: 쓴 만큼 지불한다.
관리형 서비스: OS, 패치, HA, 백업 등을 AWS가 일부 또는 대부분 맡아준다.

1. Shared Responsibility Model

공유 책임 모델은 AWS와 고객이 보안을 나누어 책임진다는 모델이다.

AWS의 책임

데이터 센터, 전원, 냉각, 물리 보안
글로벌 네트워크
하이퍼바이저와 기본 클라우드 인프라
관리형 서비스의 기반 플랫폼

고객의 책임

IAM 권한 설계
데이터 암호화 여부
보안 그룹, NACL, 라우팅
OS 패치와 애플리케이션 보안(특히 EC2)
민감 정보 관리와 백업 정책

핵심 포인트

EC2를 많이 쓸수록 고객 책임이 커진다.
S3, RDS, DynamoDB 같은 관리형 서비스를 쓸수록 운영 부담이 줄어든다.

2. AWS 글로벌 인프라

AWS 글로벌 인프라는 전 세계 여러 지역에 분산된 리전, AZ, 엣지 로케이션으로 구성된다.

왜 먼저 알아야 하는가

대부분의 AWS 서비스는 리전 단위로 생성된다.
고가용성은 AZ 분산 개념 위에서 설계된다.
글로벌 서비스와 리전 서비스를 구분해야 Route 53, CloudFront, IAM 같은 서비스 성격이 선명해진다.

전체 그림

Region: 큰 지리적 분리 단위
Availability Zone: 리전 내부 장애 격리 단위
Data Center: 실제 물리 시설
Edge Location: 사용자 가까운 글로벌 응답 지점

3. Region

Region(리전) 은 AWS의 지리적으로 분리된 물리적 위치다.

왜 필요한가

사용자와 가까운 리전을 선택해 지연 시간을 줄일 수 있다.
국가/규정 요구사항에 맞게 데이터를 특정 지역에 보관할 수 있다.
리전 단위 장애 격리를 설계할 수 있다.

핵심 포인트

서울: ap-northeast-2
도쿄: ap-northeast-1
버지니아 북부: us-east-1
대부분의 서비스는 리전 단위로 배포/관리된다.

4. Availability Zone

Availability Zone(AZ) 은 하나의 리전 안에 있는, 물리적으로 분리된 데이터 센터 묶음이다.

왜 필요한가

단일 데이터 센터 장애가 전체 서비스 장애로 이어지지 않도록 하기 위해서다.
고가용성 아키텍처는 보통 Multi-AZ를 전제로 한다.

핵심 포인트

전원, 냉각, 네트워크가 분리된다.
AZ 간에는 매우 빠르고 지연이 낮은 전용 네트워크로 연결된다.
EC2, RDS, ELB, EFS 같은 서비스는 Multi-AZ 구조와 함께 자주 설계된다.

5. Data Center

Data Center 는 실제 서버와 네트워크 장비가 들어 있는 물리적 시설이다.

핵심 포인트

사용자는 데이터 센터를 직접 선택하지 않는다.
AWS는 데이터 센터의 정확한 위치와 개수를 공개하지 않는다.
하나의 AZ는 하나 이상의 데이터 센터로 구성된다.

6. Edge Location

Edge Location 은 CloudFront, Route 53, Global Accelerator 같은 글로벌 서비스가 사용자 가까운 위치에서 응답하기 위해 사용하는 지점이다.

왜 필요한가

정적 콘텐츠를 가까운 곳에서 캐싱해 빠르게 제공할 수 있다.
글로벌 트래픽을 최적 경로로 유도할 수 있다.
DNS 응답과 엣지 보안 처리를 빠르게 수행할 수 있다.

7. Well-Architected Framework

Well-Architected Framework 는 AWS가 제시하는 모범 아키텍처 원칙이다.

6가지 핵심 축

운영 우수성(Operational Excellence)
보안(Security)
안정성(Reliability)
성능 효율성(Performance Efficiency)
비용 최적화(Cost Optimization)
지속 가능성(Sustainability)

자주 나오는 원칙

용량을 추측하지 말고 자동 확장을 활용한다.
프로덕션 규모에서 실험하고 측정한다.
자동화로 반복 작업을 제거한다.
실패를 전제로 복구 가능한 아키텍처를 설계한다.
데이터로 의사결정한다.

네트워크 기초

AWS 네트워크는 결국 어디에 둘지, 어디로 보낼지, 누구를 허용할지를 설계하는 작업이다. 이 구간은 그 문법 자체를 다룬다.

8. CIDR

CIDR(Classless Inter-Domain Routing) 는 IP 주소 범위를 표현하는 표기법이다.

왜 필요한가

VPC와 서브넷의 IP 대역을 설계할 때 기준이 된다.
추후 피어링, TGW, 온프레미스 연결 시 CIDR 충돌 여부가 중요하다.

예시

10.0.0.0/16: 큰 네트워크 범위
10.0.1.0/24: 더 작은 서브넷 범위

주의사항

VPC 간 피어링이나 온프레미스 연동을 고려하면 CIDR 중복 없는 설계가 중요하다.

9. VPC

VPC(Virtual Private Cloud) 는 AWS 안에 만드는 논리적으로 격리된 가상 네트워크다.

왜 필요한가

AWS 리소스를 내 네트워크 정책 아래에서 배치할 수 있다.
서브넷, 라우팅, 보안 그룹, NAT, 인터넷 연결 등을 설계할 수 있다.
사실상 대부분의 AWS 컴퓨팅 아키텍처의 시작점이다.

핵심 구조

IP 대역: CIDR로 정의
서브넷: AZ별로 세분화
라우팅: Route Table로 결정
외부 연결: IGW, NAT, VPN, DX 등
보안 계층: SG, NACL

실무 포인트

VPC는 보통 리전 단위 자원이다.
하나의 VPC 안에서 여러 AZ에 서브넷을 나눠 고가용성을 설계한다.
네트워크를 처음 잘못 설계하면 이후 확장이 매우 불편해진다.

10. Subnet

Subnet(서브넷) 은 VPC 내부를 더 작은 네트워크 단위로 나눈 것이다.

왜 필요한가

역할별로 리소스를 분리할 수 있다.
AZ별로 나눠 고가용성 구성을 할 수 있다.
Public, Private, DB 전용처럼 네트워크 접근 정책을 분리할 수 있다.

핵심 포인트

서브넷은 하나의 AZ에만 속한다.
여러 AZ에 같은 역할의 서브넷을 만들어 Multi-AZ 구조를 구성한다.
서브넷의 Public/Private 여부는 이름이 아니라 라우팅으로 결정된다.

11. Public Subnet vs Private Subnet

Public Subnet

인터넷 게이트웨이로 가는 기본 경로가 있는 서브넷이다.

ALB, Bastion Host, NAT Gateway 같은 외부 노출 리소스를 둔다.
인스턴스가 퍼블릭 IP를 가지면 인터넷과 직접 통신할 수 있다.

Private Subnet

인터넷 게이트웨이로 직접 나가는 경로가 없는 서브넷이다.

애플리케이션 서버, 내부 서비스, DB를 배치한다.
외부 인터넷이 필요하면 NAT Gateway를 통해 아웃바운드만 허용한다.

핵심 포인트

퍼블릭/프라이빗은 서브넷 이름이 아니라 Route Table로 결정된다.
보안상 DB와 내부 애플리케이션은 보통 Private Subnet에 둔다.

12. Route Table

Route Table 은 서브넷에서 목적지 트래픽을 어디로 보낼지 결정하는 규칙 집합이다.

왜 필요한가

인터넷, NAT, VPN, TGW, VPC Endpoint 등 트래픽 경로를 제어할 수 있다.

대표 경로

0.0.0.0/0 -> IGW: 인터넷 직통
0.0.0.0/0 -> NAT Gateway: 프라이빗 서브넷 아웃바운드
10.1.0.0/16 -> VPC Peering: 다른 VPC 연결
온프레미스 CIDR -> VGW/TGW/DX: 하이브리드 연결

13. Internet Gateway

Internet Gateway(IGW) 는 VPC를 인터넷과 연결하는 게이트웨이다.

왜 필요한가

퍼블릭 서브넷 리소스가 인터넷과 통신하려면 필요하다.

핵심 포인트

IGW 자체만 붙인다고 퍼블릭이 되지 않는다.
서브넷 Route Table에 인터넷 방향 경로가 있어야 한다.
인스턴스는 퍼블릭 IP 또는 EIP가 있어야 외부와 직접 통신할 수 있다.

14. Egress-only Internet Gateway

Egress-only IGW 는 IPv6 환경에서 아웃바운드 전용 인터넷 연결을 제공한다.

왜 필요한가

IPv6는 NAT Gateway를 쓰지 않기 때문에, 외부로 나가기만 하고 외부에서 먼저 들어오지 못하게 하려면 egress-only IGW가 필요하다.

15. NAT

NAT(Network Address Translation) 는 사설 네트워크의 주소를 공인 주소로 변환해 외부와 통신하게 하는 개념이다.

왜 필요한가

프라이빗 서브넷 인스턴스가 인터넷으로 나가 업데이트나 패키지 다운로드를 해야 할 수 있다.
하지만 외부에서 먼저 내부 인스턴스에 접근하지는 못하게 해야 한다.

핵심 포인트

내부 -> 외부 통신은 가능
외부 -> 내부 선제 접근은 불가
“나갈 수는 있지만, 직접 노출되지는 않는 구조”를 만들 때 핵심이다.

16. NAT Gateway

NAT Gateway 는 AWS가 제공하는 관리형 NAT 서비스다.

왜 필요한가

프라이빗 서브넷의 아웃바운드 인터넷 통신을 안정적으로 제공한다.

특징

관리형 서비스라 운영이 쉽다.
자동 확장된다.
IPv4용이다.
보통 Public Subnet에 만들고 EIP를 붙인다.

주의사항

NAT Gateway는 AZ 단위 장애 도메인이다.
고가용성을 원하면 각 AZ마다 NAT Gateway를 두고 해당 AZ 프라이빗 서브넷이 같은 AZ NAT를 바라보게 설계한다.
데이터 처리 비용과 NAT 시간당 비용이 발생한다.

17. NAT Instance

NAT Instance 는 NAT 역할을 하는 EC2 인스턴스다.

지금은 왜 잘 안 쓰는가

직접 패치, 확장, 장애 복구를 관리해야 한다.
성능과 가용성을 사용자가 설계해야 한다.
대부분의 경우 NAT Gateway가 더 단순하고 안전하다.

비교 포인트

NAT Gateway: 관리형, 자동 확장, 운영 간편
NAT Instance: 직접 관리, 커스터마이징 가능, 현재는 특수 케이스 외 비권장

18. Elastic IP

Elastic IP(EIP) 는 고정 퍼블릭 IPv4 주소다.

왜 필요한가

재시작이나 교체 후에도 동일한 공인 IP를 유지해야 할 때 사용한다.
NAT Gateway, Bastion Host, 특정 외부 화이트리스트 등록 시스템과 연동할 때 유용하다.

주의사항

사용하지 않는 EIP는 비용이 발생한다.
가능하면 직접 EC2에 장기 고정 IP를 붙이기보다 ALB, Route 53, Global Accelerator 같은 상위 추상화를 우선 고려한다.

19. Security Group

Security Group(SG) 은 ENI 또는 인스턴스 레벨에 붙는 가상 방화벽이다.

왜 필요한가

인스턴스, ALB, RDS 등 리소스에 대해 허용 기반 접근 제어를 한다.

핵심 포인트

Stateful 이다.
허용 규칙만 있다. 명시적 차단 규칙은 없다.
응답 트래픽은 별도 규칙 없이 허용된다.
다른 SG를 소스로 지정할 수 있어 애플리케이션 계층 간 보안 설계에 편리하다.

예시

ALB SG는 443 허용
EC2 SG는 ALB SG만 소스로 허용
RDS SG는 EC2 SG만 소스로 허용

20. NACL

NACL(Network ACL) 은 서브넷 레벨의 네트워크 필터다.

왜 필요한가

서브넷 단위에서 더 거친 허용/차단 정책을 둘 수 있다.
특정 IP 차단 같은 네트워크 레벨 제어가 필요할 때 활용할 수 있다.

핵심 포인트

Stateless 이다.
인바운드와 아웃바운드를 각각 명시해야 한다.
허용과 거부 규칙을 모두 가질 수 있다.
규칙 번호 순서대로 평가된다.

Security Group과 비교

SG: 인스턴스/ENI 레벨, Stateful, 허용만 가능
NACL: 서브넷 레벨, Stateless, 허용/거부 모두 가능

21. ENI

ENI(Elastic Network Interface) 는 EC2 인스턴스에 붙는 가상 네트워크 인터페이스다.

핵심 포인트

프라이빗 IP, 퍼블릭 IP, MAC 주소, SG 등이 ENI에 연결된다.
보안 그룹은 인스턴스가 아니라 실제로는 ENI에 적용된다.
일부 네트워크 고급 기능은 ENI 단위로 동작한다.

22. Bastion Host

Bastion Host 는 퍼블릭 서브넷에 두고 내부 프라이빗 인스턴스로 접속하기 위한 점프 서버다.

왜 필요한가

외부에서 프라이빗 서브넷 인스턴스에 직접 접근할 수 없을 때 중간 진입 지점 역할을 한다.

현재 실무 흐름

전통적으로는 Bastion Host를 많이 썼다.
하지만 최근에는 SSM Session Manager 로 대체하는 경우가 많다.
Bastion은 관리 포인트가 늘고 SSH 키 관리 부담이 있다.

23. VPC Flow Logs

VPC Flow Logs 는 네트워크 인터페이스 수준의 트래픽 메타데이터를 기록하는 기능이다.

왜 필요한가

연결이 안 되는 이유를 추적할 때 유용하다.
ACCEPT/REJECT 기록을 통해 보안 정책이나 라우팅 문제를 확인할 수 있다.

주의사항

패킷 본문이 아니라 메타데이터 중심이다.
더 깊은 패킷 분석이 필요하면 Traffic Mirroring 같은 기능을 고려한다.

24. Reachability Analyzer

Reachability Analyzer 는 두 AWS 네트워크 리소스 간 연결 가능 여부를 분석하는 도구다.

왜 필요한가

라우팅, SG, NACL, TGW, 게이트웨이 설정이 복잡할 때 “왜 안 붙는지”를 빠르게 파악할 수 있다.

25. Traffic Mirroring

Traffic Mirroring 은 ENI 트래픽을 복제해 IDS/IPS, 보안 분석 장비로 보내는 기능이다.

왜 필요한가

심층 패킷 분석이 필요할 때 사용한다.
보안 관제, 네트워크 포렌식, 침입 탐지에 유용하다.

네트워크 연결과 엣지

여기서는 하나의 VPC를 넘어서 여러 네트워크를 연결하고, 사용자 가까운 곳에서 빠르고 안전하게 응답하는 구조를 다룬다.

26. VPC Peering

VPC Peering 은 두 VPC를 프라이빗하게 직접 연결하는 기능이다.

왜 필요한가

별도 인터넷 경유 없이 VPC 간 통신을 하게 한다.

핵심 포인트

CIDR이 겹치면 안 된다.
Transitive Routing 을 지원하지 않는다.
소규모 연결에는 단순하지만, 연결 수가 많아지면 관리가 복잡해진다.

언제 쓰는가

연결할 VPC가 몇 개 안 되고 구조가 단순할 때 적합하다.

27. Site-to-Site VPN

Site-to-Site VPN 은 온프레미스 네트워크와 AWS VPC를 인터넷 기반 IPSec 터널로 연결하는 방식이다.

왜 필요한가

빠르게 하이브리드 연결을 만들 수 있다.
DX보다 구축이 쉽고 초기 진입 비용이 낮다.

구성 요소

Customer Gateway(CGW): 고객 측 VPN 장비 또는 소프트웨어
Virtual Private Gateway(VGW) 또는 Transit Gateway: AWS 측 종단

특징

인터넷을 사용하므로 DX보다 예측 가능성과 대역폭 면에서 제한이 있다.
암호화된 터널을 제공한다.
빠른 구축이 장점이다.

라우팅

정적 라우팅 또는 BGP 기반 동적 라우팅 사용 가능
BGP를 쓰면 경로 전파와 장애 대응이 더 유연하다.

28. VGW와 CGW

CGW

온프레미스 측 라우터/방화벽/VPN 어플라이언스다.

VGW

AWS VPC에 연결되는 VPN 종단 게이트웨이다.

비교 포인트

CGW는 고객 측
VGW는 AWS VPC 측

29. Direct Connect

Direct Connect(DX) 는 온프레미스와 AWS를 전용 회선으로 연결하는 서비스다.

왜 필요한가

대용량, 안정적, 예측 가능한 네트워크 연결이 필요할 때 사용한다.
공용 인터넷보다 일관된 대역폭과 낮은 지연을 기대할 수 있다.

특징

초기 구축 시간이 필요하다.
VPN보다 안정적이지만 암호화 자체가 기본 내장된 것은 아니다.
필요하면 DX 위에 VPN을 얹어 암호화를 추가한다.

30. Direct Connect Gateway

DXGW 는 하나의 DX 연결을 여러 VPC나 리전에 연결할 때 쓰는 중간 게이트웨이다.

왜 필요한가

Direct Connect를 단일 VPC에만 연결하면 확장성이 낮다.
여러 리전, 여러 VPC, 멀티 계정 구조에서는 연결 허브가 필요하다.

핵심 포인트

DXGW는 DX 연결을 더 넓은 AWS 네트워크 집합에 연결할 수 있게 해준다.
단순 회선 연결이 아니라 하이브리드 네트워크의 확장 전략과 함께 이해해야 한다.

31. Transit Gateway

Transit Gateway(TGW) 는 여러 VPC와 온프레미스 네트워크를 허브 앤 스포크 방식으로 연결하는 중앙 허브다.

왜 필요한가

VPC 수가 많아지면 피어링은 조합 수가 급격히 늘어난다.
TGW를 사용하면 중앙 집중형 연결과 라우팅 관리가 가능하다.

핵심 포인트

Transitive Routing 을 지원한다.
TGW Route Table로 연결 범위를 제어한다.
멀티 계정, 멀티 VPC, VPN, DX를 큰 규모로 묶을 때 강력하다.

32. Route 53

Route 53 은 AWS의 DNS 서비스다.

왜 필요한가

도메인을 IP나 AWS 리소스로 매핑한다.
고가용성, 트래픽 분산, 헬스 체크 기반 장애 조치에 활용할 수 있다.

Hosted Zone

Public Hosted Zone: 인터넷 공개 도메인용
Private Hosted Zone: 특정 VPC 내부 전용 DNS용

주요 레코드 타입

A: IPv4 주소
AAAA: IPv6 주소
CNAME: 다른 도메인 이름 별칭
Alias: AWS 리소스를 가리키는 AWS 전용 별칭
MX, TXT, NS 등 기타 DNS 레코드

Alias Record가 중요한 이유

AWS 리소스(ALB, CloudFront, S3 website, API Gateway 등)를 루트 도메인에서도 연결할 수 있다.
Route 53은 Alias 대상의 IP 변경을 AWS 내부적으로 추적한다.

TTL

길면 DNS 질의 수가 줄고 캐시 효율이 좋다.
짧으면 변경 반영이 빠르다.
장애 조치나 잦은 전환이 필요한 레코드는 짧은 TTL이 유리하다.

Routing Policy

Simple: 단순 매핑
Weighted: 가중치 기반 분산
Latency-based: 가장 지연이 낮은 리전으로 유도
Failover: 헬스 체크 기반 Active-Passive
Geolocation: 사용자 위치 기반 정책
Geoproximity: 위치와 트래픽 편향 기반
Multi-Value: 여러 정상 응답 반환

33. CloudFront

CloudFront 는 AWS의 CDN 서비스다.

왜 필요한가

정적/동적 콘텐츠를 사용자 가까운 엣지 로케이션에서 제공한다.
응답 속도를 높이고 원본 서버 부하를 줄인다.
WAF, TLS, Geo Restriction과 결합해 웹 보안 계층을 강화할 수 있다.

핵심 구성

Edge Location: 캐시 지점
Origin: S3, ALB, EC2, API Gateway 등 원본
Distribution: CloudFront 배포 설정 단위

주요 특징

캐싱
HTTPS 종단 처리
서명 URL/쿠키
Geo Restriction
WAF 연계
Lambda@Edge / CloudFront Functions 연계

CloudFront vs S3 CRR

CloudFront: 전 세계 캐시 배포, 원본은 그대로
S3 CRR: 객체 자체를 다른 리전에 복제

34. Global Accelerator

Global Accelerator 는 AWS 글로벌 네트워크를 통해 사용자를 가장 가까운 엣지로 받아 AWS 백엔드(ALB, NLB, EC2)까지 최적 경로로 전달하는 서비스다.

왜 필요한가

TCP/UDP 기반 글로벌 애플리케이션에서 지연과 가용성을 개선한다.
고정 Anycast IP 두 개를 제공한다.

CloudFront와 비교

CloudFront: 캐싱 중심, HTTP/HTTPS 콘텐츠 최적화
Global Accelerator: 네트워크 경로 최적화, 비캐시 트래픽에도 유용

35. AWS 캐싱 전략

캐싱은 한 계층만의 기능이 아니라 여러 계층에서 설계할 수 있다.

레이어별 예시

CloudFront: 전 세계 엣지 캐시
API Gateway Cache: API 응답 캐시
ElastiCache Redis/Memcached: 애플리케이션 캐시
DAX: DynamoDB 전용 캐시
애플리케이션 내부 캐시: 코드 레벨 캐시

핵심 원칙

사용자와 가까운 계층일수록 응답 속도 개선 폭이 크다.
뒤쪽 계층일수록 더 일반적인 캐시가 가능하지만 지연과 비용이 커질 수 있다.
무엇을 얼마나 오래 캐싱할지 TTL과 무효화 정책이 중요하다.

36. AWS에서 IP 차단하는 방법

IP 차단은 어느 계층에서 할지 먼저 결정해야 한다.

선택지

NACL: 서브넷 레벨 IP 차단 가능
Security Group: 허용 규칙만 가능, 직접 차단은 불가
WAF: HTTP/HTTPS 레벨에서 IP, 국가, 패턴 기반 차단
EC2 내부 방화벽: OS 레벨 제어 가능하나 운영 부담 증가
Geo Restriction(CloudFront): 국가 단위 제한

실무 포인트

글로벌 웹 서비스라면 WAF와 CloudFront가 보통 더 적절하다.
CloudFront 앞단에 들어오면 원본 입장에서 클라이언트 IP 처리 구조를 이해해야 한다.
L7 정책은 WAF, 서브넷 거부는 NACL, 인스턴스 허용은 SG로 역할을 나눠 생각하면 정리가 쉽다.

컴퓨팅

이 구간은 서버를 어떤 형태로 실행할지에 대한 선택지를 정리한다. EC2 같은 전통적 방식부터 확장성과 성능 중심 설계까지 연결해서 읽으면 좋다.

37. EC2

EC2(Elastic Compute Cloud) 는 AWS에서 가장 대표적인 가상 서버 서비스다.

왜 필요한가

OS 수준 제어가 필요한 워크로드를 실행할 수 있다.
레거시 애플리케이션, 커스텀 미들웨어, 특수 패키지 설치가 가능하다.
컨테이너나 서버리스보다 자유도가 높다.

핵심 구성 요소

AMI
Instance Type
EBS / Instance Store
ENI
Security Group
Key Pair
IAM Role

라이프사이클

pending
running
stopping
stopped
terminated

주의사항

terminate 되면 기본적으로 인스턴스 자체는 사라진다.
인스턴스 스토어 데이터는 인스턴스 중지/종료 시 사라질 수 있다.
운영 부담은 서버리스보다 훨씬 크다.

38. AMI

AMI(Amazon Machine Image) 는 EC2 인스턴스를 띄우기 위한 이미지 템플릿이다.

왜 필요한가

동일한 OS와 소프트웨어 구성을 반복 배포할 수 있다.
표준화된 서버 이미지를 운영할 수 있다.

사용 예시

골든 이미지 운영
사전 패치된 베이스 이미지
보안 에이전트 포함 이미지 배포

39. Instance Type

Instance Type 은 CPU, 메모리, 네트워크, 스토리지 성능 조합을 의미한다.

대표 계열

General Purpose: 범용 워크로드
Compute Optimized: CPU 집약적 작업
Memory Optimized: 메모리 집약적 DB/캐시
Storage Optimized: 높은 로컬 IOPS
GPU 계열: ML, 그래픽, 병렬 연산

선택 기준

CPU 바운드인지
메모리 바운드인지
네트워크 성능이 중요한지
GPU가 필요한지
비용 대비 효율이 어떤지

40. Key Pair

Key Pair 는 EC2 SSH 접속에 사용하는 공개키/개인키 쌍이다.

실무 포인트

최근에는 Session Manager 사용으로 SSH 의존도를 줄이는 경우가 많다.
키 유출은 심각한 보안 사고로 이어질 수 있다.

41. EC2 고가용성

EC2는 기본적으로 한 AZ에서 실행되므로, 고가용성을 원하면 사용자가 구조를 설계해야 한다.

대표 패턴

여러 AZ에 인스턴스를 배치한다.
ALB/NLB 앞단으로 분산한다.
Auto Scaling Group으로 장애 시 대체 인스턴스를 자동 생성한다.
데이터 계층도 Multi-AZ를 고려한다.

42. Auto Scaling

Auto Scaling Group(ASG) 은 지정한 조건에 따라 EC2 인스턴스 수를 자동으로 조절하는 기능이다.

왜 필요한가

트래픽 증가 시 자동 확장
사용량 감소 시 자동 축소
인스턴스 장애 시 자동 교체

주요 구성

최소/최대/희망 용량
Launch Template 또는 Launch Configuration
헬스 체크
Scaling Policy

Scaling Policy

Target Tracking: 목표 메트릭 유지
Step Scaling: 임계값 구간별 조정
Scheduled Scaling: 시간 기반 조정
Predictive Scaling: 예측 기반 확장

ASG와 ELB 관계

ELB는 트래픽을 분산한다.
ASG는 인스턴스 수를 조절한다.
ALB가 비정상 인스턴스를 감지하고, ASG가 교체하는 구조가 자주 쓰인다.

43. ELB

ELB(Elastic Load Balancing) 는 들어오는 트래픽을 여러 대상에게 분산하는 서비스다.

종류

ALB(Application Load Balancer): L7, HTTP/HTTPS
NLB(Network Load Balancer): L4, TCP/UDP, 고성능
GWLB(Gateway Load Balancer): 네트워크 보안 장비 삽입
CLB: 구세대 로드밸런서

ALB가 적합한 경우

경로 기반 라우팅
호스트 기반 라우팅
웹 애플리케이션
WAF 연동

NLB가 적합한 경우

매우 높은 처리량
TCP/UDP
고정 IP 필요
낮은 지연 시간 중요

주요 개념

Health Check
Cross-Zone Load Balancing
Sticky Session
SSL/TLS Termination
Deregistration Delay(Connection Draining)

44. HPC(High Performance Computing)

HPC 는 대규모 연산과 초고속 네트워크/스토리지가 필요한 워크로드를 의미한다.

왜 필요한가

기상 예측
유전체 분석
대규모 시뮬레이션
머신 러닝/딥러닝 학습
자율주행/과학 계산

AWS가 유리한 이유

필요한 순간에 대량 리소스를 빠르게 확보 가능
사용한 만큼 비용 지불
네트워크/스토리지/배치 서비스 조합이 가능

45. Placement Group

Placement Group 은 EC2 인스턴스의 물리 배치 전략이다.

유형

Cluster: 같은 랙 가까이 배치, 초저지연/고대역폭
Partition: 장애 도메인 분리
Spread: 서로 다른 하드웨어에 분산

HPC에서 중요한 이유

Cluster Placement Group은 노드 간 통신이 중요한 HPC에 적합하다.

46. Enhanced Networking, ENA, EFA

Enhanced Networking

SR-IOV 기반으로 더 높은 대역폭과 더 낮은 지연을 제공한다.

ENA

ENA(Elastic Network Adapter) 는 고성능 네트워크 어댑터로 높은 처리량과 PPS를 제공한다.

EFA

EFA(Elastic Fabric Adapter) 는 HPC용 고성능 네트워크 인터페이스다.

Linux 기반 워크로드에서 주로 사용
MPI(Message Passing Interface) 기반 분산 연산에 적합
노드 간 통신이 매우 빈번한 작업에서 강력하다.

비교 포인트

ENI: 일반 네트워크 인터페이스 개념
ENA: 고성능 네트워크 성능 향상 기능
EFA: HPC 특화 네트워크 인터페이스

컨테이너와 서버리스

이 구간은 애플리케이션 실행 단위를 비교하는 파트다. VM, 컨테이너, 함수형 실행이 각각 무엇을 해결하는지 중심으로 보면 선택 기준이 잡힌다.

47. 컨테이너란 무엇인가

컨테이너는 애플리케이션과 실행에 필요한 라이브러리를 함께 묶어 어디서든 동일하게 실행되게 하는 패키징 방식이다.

왜 필요한가

개발/운영 환경 차이를 줄인다.
배포가 빨라진다.
마이크로서비스 아키텍처에 잘 맞는다.

48. Docker

Docker 는 컨테이너 이미지를 만들고 실행하는 가장 대표적인 도구다.

핵심 개념

Image: 읽기 전용 템플릿
Container: 실행 중인 인스턴스
Dockerfile: 이미지 생성 정의 파일
Registry: 이미지 저장소

49. Amazon ECR

ECR(Elastic Container Registry) 는 AWS의 컨테이너 이미지 저장소다.

왜 필요한가

Docker 이미지를 안전하게 저장하고 ECS/EKS와 연계할 수 있다.

50. ECS

ECS(Elastic Container Service) 는 AWS의 관리형 컨테이너 오케스트레이션 서비스다.

왜 필요한가

AWS 환경에서 컨테이너 운영을 비교적 단순하게 할 수 있다.
Kubernetes보다 러닝커브가 낮다.

핵심 구성요소

Task Definition: 컨테이너 실행 정의
Task: 실제 실행 단위
Service: 원하는 수의 Task 유지
Cluster: ECS 리소스 집합

실행 방식

EC2 Launch Type: EC2 위에서 컨테이너 실행
Fargate Launch Type: 서버 관리 없이 실행

IAM 역할

EC2 Instance Profile: EC2 Launch Type용
Task Role: 애플리케이션이 다른 AWS 서비스에 접근할 권한
Task Execution Role: 이미지 pull, 로그 전송 등 실행 보조 권한

51. Fargate

Fargate 는 ECS/EKS에서 서버를 직접 관리하지 않고 컨테이너를 실행하는 서버리스 실행 엔진이다.

왜 필요한가

EC2 인스턴스 패치, AMI 관리, 오토스케일링 노드 운영을 줄일 수 있다.

적합한 경우

운영 단순성이 중요할 때
중소 규모 서비스
잡/마이크로서비스

Lambda와 비교

Lambda: 함수 단위, 짧은 이벤트성 작업
Fargate: 컨테이너 단위, 더 긴 실행과 자유도

52. Kubernetes

Kubernetes 는 컨테이너 오케스트레이션 표준 플랫폼이다.

왜 필요한가

대규모 컨테이너 스케줄링
서비스 디스커버리
롤링 업데이트
선언적 운영

핵심 구조

Control Plane: API 서버, 스케줄러 등
Worker Node: 실제 Pod 실행 노드
Pod: 최소 배포 단위
Deployment: 원하는 Pod 수와 롤링 업데이트 관리
Service: Pod 네트워크 접근 추상화

53. EKS

EKS(Elastic Kubernetes Service) 는 AWS의 관리형 Kubernetes 서비스다.

왜 필요한가

Control Plane을 AWS가 관리한다.
표준 Kubernetes 생태계를 활용할 수 있다.

노드 방식

Managed Node Group
Self-Managed Node
Fargate for EKS

ECS와 비교

ECS: AWS 친화적, 단순, 러닝커브 낮음
EKS: Kubernetes 표준 필요 시 유리, 복잡도 높음

54. App Runner

App Runner 는 소스 코드나 컨테이너 이미지를 기반으로 웹 애플리케이션을 매우 간단히 배포하는 서비스다.

적합한 경우

빠른 웹 앱 배포
인프라 세부 제어보다 단순 배포가 중요할 때

왜 따로 존재하는가

ECS/EKS는 강력하지만 개념이 많고 운영 포인트도 많다.
Lambda는 이벤트 기반 함수 실행에는 매우 강하지만, 일반 웹 애플리케이션 전체를 그대로 옮기기에는 제약이 있다.
App Runner는 이 둘 사이에서 “웹 앱을 빠르게 올리고 싶다”는 요구를 해결해 주는 단순 배포 서비스다.

비교 포인트

Lambda: 함수 단위 실행
App Runner: 웹 애플리케이션 단위 배포
ECS/Fargate: 더 많은 제어권과 더 큰 운영 복잡도

55. Lambda

AWS Lambda 는 서버를 직접 관리하지 않고 코드를 이벤트 기반으로 실행하는 함수형 컴퓨팅 서비스다.

왜 필요한가

요청이 있을 때만 실행되어 유휴 비용이 적다.
짧고 독립적인 이벤트 처리에 강하다.
다양한 AWS 서비스와 쉽게 연동된다.

핵심 특징

함수 단위 실행
이벤트 기반
자동 확장
서버 관리 불필요
최대 실행 시간 제한 존재

대표 트리거

API Gateway
S3
SQS
SNS
EventBridge
DynamoDB Streams

주의사항

콜드 스타트 가능성
실행 시간/메모리 제한
VPC 안에 넣으면 네트워크 구성이 중요해진다.

56. Lambda in VPC

Lambda를 VPC 내부 리소스(RDS, ElastiCache 등)와 연결하려면 VPC에 붙여야 한다.

주의사항

인터넷 접근이 필요하면 NAT 등 아웃바운드 설계를 고려해야 한다.
모든 Lambda를 무조건 VPC에 넣는 것은 아니다.

57. Lambda + SQS

SQS는 Lambda가 매우 자주 함께 쓰는 이벤트 소스다.

동작 방식

SQS 큐에 메시지가 들어간다.
Lambda 서비스가 큐를 폴링한다.
메시지를 배치 단위로 함수에 전달한다.
처리 실패 시 재시도되며, 반복 실패하면 DLQ로 보낼 수 있다.

장점

백프레셔를 흡수한다.
일시적인 장애에도 메시지를 보존할 수 있다.
비동기 처리에 강하다.

58. Lambda + SQS FIFO

FIFO 큐는 순서 보장이 필요한 경우 사용한다.

주의사항

앞 메시지 처리가 막히면 뒤 메시지도 지연될 수 있다.
순서 보장이 필요한 경우에만 선택한다.
장애 메시지는 DLQ 분리 전략이 중요하다.

59. Lambda + SNS

SNS는 Pub/Sub 구조에서 Lambda에 비동기 이벤트를 전달할 수 있다.

특징

SNS가 Lambda를 직접 비동기 호출한다.
실패 시 SNS 쪽 재시도 정책과 DLQ 구성이 중요하다.
여러 구독자에게 동시에 이벤트를 배포할 수 있다.

60. Fan-out Pattern

Fan-out Pattern 은 하나의 이벤트를 여러 소비자에게 동시에 전달하는 패턴이다.

대표 구조

Producer -> SNS Topic -> 여러 SQS Queue / Lambda / HTTPS Endpoint

왜 직접 여러 SQS에 쓰지 않는가

애플리케이션이 모든 큐 전송 책임을 가지면 실패 지점이 늘어난다.
SNS를 중앙 분배 계층으로 두면 확장성과 신뢰성이 좋아진다.

61. API Gateway

API Gateway 는 HTTP API를 생성, 배포, 인증, 스로틀링, 로깅하는 관리형 API 서비스다.

왜 필요한가

Lambda, ECS, EC2 뒤에서 API 엔드포인트를 표준화한다.
인증, 제한, 스테이지 관리, 캐시, 로깅을 제공한다.

Endpoint Type

Edge-Optimized
Regional
Private

통합 대상

Lambda
HTTP 백엔드
AWS 서비스 통합(Kinesis 등)

62. API Gateway와 Kinesis Data Streams 통합

API Gateway는 요청을 받아 Kinesis Data Streams로 직접 넣는 패턴을 만들 수 있다.

적합한 경우

대량의 이벤트 수집 API
스트림 기반 비동기 수집 파이프라인

63. Step Functions

Step Functions 는 여러 서비스 작업을 상태 머신으로 오케스트레이션하는 서비스다.

왜 필요한가

Lambda 여러 개를 코드에서 직접 엮으면 복잡해진다.
재시도, 분기, 병렬 처리, 타임아웃을 선언적으로 관리할 수 있다.

적합한 경우

승인/검증 같은 다단계 업무 흐름
ETL 또는 백엔드 배치 파이프라인
실패 재시도와 분기 로직이 중요한 프로세스

핵심 포인트

작업 순서를 코드 안에서 억지로 이어 붙이기보다 상태 전이로 모델링한다.
장기 실행, 병렬 처리, 오류 복구가 중요한 흐름에서 특히 가치가 크다.

64. Lambda@Edge와 CloudFront Functions

CloudFront Functions

매우 가볍고 빠른 엣지 코드
헤더 조작, URL 재작성 등에 적합

Lambda@Edge

더 복잡한 로직 가능
CloudFront 요청/응답 흐름에 개입 가능

비교 포인트

가벼운 로직이면 CloudFront Functions
더 풍부한 로직/외부 연계가 필요하면 Lambda@Edge

스토리지

스토리지 파트는 블록, 파일, 객체 저장 방식을 구분하는 데서 시작한다. 저장 방식 차이를 이해하면 서비스 선택이 훨씬 쉬워진다.

65. EBS

EBS(Elastic Block Store) 는 EC2에 붙여 쓰는 블록 스토리지다.

왜 필요한가

OS 디스크, 데이터 디스크처럼 서버 디스크 역할을 한다.
영구 저장이 가능하다.

핵심 포인트

보통 한 AZ에 종속된다.
EC2와 네트워크로 연결되는 블록 스토리지다.
스냅샷을 통해 백업/복원이 가능하다.

볼륨 타입

gp3/gp2: 범용 SSD
io1/io2: 높은 IOPS 필요한 워크로드
st1/sc1: 처리량 위주 HDD 계열

스냅샷

S3 기반 관리형 스냅샷으로 저장된다.
다른 리전/계정으로 복사 가능하다.
DR과 백업 전략에서 핵심 역할을 한다.

66. Instance Store

Instance Store 는 EC2 물리 호스트에 직접 연결된 임시 스토리지다.

왜 쓰는가

매우 높은 IOPS와 낮은 지연 시간
캐시, 임시 파일, scratch 데이터에 적합

주의사항

인스턴스가 중지/종료되면 데이터 유실 가능
영구 보관 데이터에는 적합하지 않다.

67. EFS

EFS(Elastic File System) 는 여러 인스턴스에서 동시에 마운트할 수 있는 관리형 NFS 파일 시스템이다.

왜 필요한가

여러 EC2/ECS/Lambda가 같은 파일 시스템을 공유해야 할 때 사용한다.

특징

여러 AZ에 걸쳐 접근 가능
자동 확장
Linux 기반 파일 공유에 적합

성능/처리량 개념

Bursting Throughput
Provisioned Throughput
General Purpose / Max I/O 성능 모드

68. S3

S3(Simple Storage Service) 는 객체 스토리지 서비스다.

왜 필요한가

정적 파일 저장
백업
로그 저장
데이터 레이크
정적 웹 호스팅
애플리케이션 업로드 파일 저장

핵심 구조

Bucket: 컨테이너
Object: 실제 데이터
Key: 객체 경로 역할 문자열

보안 모델

IAM Policy
Bucket Policy
ACL(가능하면 최소화)
Block Public Access

주요 기능

Versioning
Lifecycle Policy
CRR/SRR
정적 웹사이트 호스팅
다양한 스토리지 클래스

스토리지 클래스

Standard
Intelligent-Tiering
Standard-IA
One Zone-IA
Glacier Instant Retrieval
Glacier Flexible Retrieval
Glacier Deep Archive

69. FSx

Amazon FSx 는 특정 워크로드용 관리형 파일 시스템 제품군이다.

대표 종류

FSx for Windows File Server: SMB 기반 Windows 공유 파일 시스템
FSx for Lustre: HPC/고성능 병렬 파일 시스템
FSx for NetApp ONTAP
FSx for OpenZFS

FSx for Lustre가 중요한 이유

HPC, 대규모 병렬 연산, 고속 파일 접근에 유리하다.
S3와 함께 연동하는 패턴이 자주 사용된다.

70. Storage Gateway

Storage Gateway 는 온프레미스와 AWS 스토리지를 연결하는 하이브리드 스토리지 서비스다.

왜 필요한가

온프레미스 워크로드를 유지하면서 백엔드 저장소를 AWS로 확장할 수 있다.

대표 유형

File Gateway
Volume Gateway
Tape Gateway

71. DataSync

DataSync 는 온프레미스와 AWS 스토리지 간 데이터를 고속 전송/동기화하는 서비스다.

왜 필요한가

대량 데이터 이전을 자동화할 수 있다.
NFS, SMB, S3, EFS, FSx 등과 연계된다.

72. Snow Family

Snowball / Snowmobile 은 네트워크로 옮기기 어려운 대용량 데이터를 물리 장비로 옮길 때 사용한다.

언제 쓰는가

수십~수백 TB 이상 대용량 이전
네트워크가 느리거나 불안정한 환경
일회성 대규모 마이그레이션

데이터베이스

데이터베이스는 “어떤 데이터 모델을 다루는가”와 “운영을 어디까지 직접 맡을 것인가”의 조합으로 선택하면 정리가 쉽다.

73. RDS

RDS(Relational Database Service) 는 AWS의 관리형 관계형 데이터베이스 서비스다.

왜 필요한가

백업, 패치, 모니터링, Multi-AZ 같은 운영 부담을 줄일 수 있다.
MySQL, PostgreSQL, MariaDB, Oracle, SQL Server 등 여러 엔진을 지원한다.

대표 기능

자동 백업
스냅샷
Read Replica
Multi-AZ
모니터링 및 관리 자동화

74. RDS Multi-AZ

Multi-AZ 는 가용성을 높이기 위한 동기식 스탠바이 복제 구성이다.

왜 필요한가

AZ 장애 시 빠른 장애 조치를 위해서다.

핵심 포인트

읽기 확장용이 아니라 가용성용이다.
보통 자동 장애 조치 대상은 스탠바이 인스턴스다.

75. Read Replica

Read Replica 는 읽기 부하 분산을 위한 비동기 복제본이다.

왜 필요한가

읽기 요청이 많은 워크로드에서 메인 DB 부하를 줄일 수 있다.

Multi-AZ와 비교

Multi-AZ: HA 목적
Read Replica: 읽기 성능 확장 목적

76. Aurora

Aurora 는 AWS가 만든 클라우드 최적화 관계형 데이터베이스 엔진이다.

왜 필요한가

MySQL/PostgreSQL 호환성
높은 성능과 가용성
스토리지 자동 확장

핵심 구조

DB Cluster
Writer Instance
Reader Instance
분산 스토리지 계층

Aurora Global Database

여러 리전에 걸친 글로벌 읽기/DR 구성이 가능하다.
전 세계 서비스와 재해 복구 전략에서 자주 언급된다.

77. RDS Proxy

RDS Proxy 는 데이터베이스 연결 풀링을 제공하는 프록시 서비스다.

왜 필요한가

Lambda처럼 짧은 함수가 대량 동시 접속을 만들면 DB 연결 수가 폭증할 수 있다.
프록시가 연결을 재사용해 DB 부담을 줄인다.

78. ElastiCache

ElastiCache 는 AWS의 관리형 인메모리 캐시 서비스다.

왜 필요한가

DB 부담을 줄이고 응답 속도를 높인다.
세션 저장소, 랭킹, 실시간 캐시 등에 적합하다.

엔진

Redis
Memcached

Redis vs Memcached

Redis: 데이터 구조 풍부, 영속성/복제/고급 기능 가능
Memcached: 단순 캐시, 멀티스레드, 구조 단순

대표 패턴

Cache-Aside
Write-Through
Write-Behind
Session Store

79. DynamoDB

DynamoDB 는 AWS의 완전관리형 NoSQL Key-Value/Document 데이터베이스다.

왜 필요한가

서버 관리 없이 대규모 트래픽 처리
매우 높은 확장성
짧고 예측 가능한 지연 시간

핵심 개념

Table
Partition Key
Sort Key
Item
Attribute

용량 모드

Provisioned
On-Demand

고급 기능

DAX
Streams
TTL
Global Tables
Point-in-time Recovery
백업/복원

80. DAX

DAX(DynamoDB Accelerator) 는 DynamoDB 전용 인메모리 캐시다.

왜 필요한가

읽기 지연을 더 낮추고 핫 키에 대한 부담을 줄인다.

ElastiCache와 비교

DAX: DynamoDB 전용 캐시
ElastiCache: 범용 캐시

81. DocumentDB

DocumentDB 는 MongoDB 호환 문서형 데이터베이스 서비스다.

적합한 경우

문서 지향 애플리케이션
MongoDB API 친화성이 필요한 경우

82. Neptune

Neptune 는 그래프 데이터베이스 서비스다.

적합한 경우

추천 시스템
사기 탐지
관계 탐색
네트워크/그래프 분석

83. Keyspaces

Amazon Keyspaces 는 Cassandra 호환 관리형 데이터베이스다.

84. QLDB

Amazon QLDB 는 변경 이력을 신뢰성 있게 추적하는 원장형 데이터베이스다.

적합한 경우

감사 추적
변경 이력 검증이 중요한 시스템

85. Timestream

Amazon Timestream 은 시계열 데이터베이스다.

적합한 경우

IoT 센서 데이터
애플리케이션 메트릭
로그 기반 시계열 분석

86. DB 선택 기준

정형 관계 데이터 + SQL: RDS / Aurora
대규모 Key-Value + 초고속 확장: DynamoDB
문서 모델: DocumentDB
그래프 질의: Neptune
시계열: Timestream
감사 가능한 원장: QLDB
캐시: ElastiCache

메시징, 이벤트, 통합

이 구간은 서비스들을 느슨하게 연결하는 방법을 다룬다. 큐, Pub/Sub, 이벤트 버스, 스트림을 명확히 구분해 읽는 것이 핵심이다.

87. SQS

SQS(Simple Queue Service) 는 메시지를 저장했다가 소비자가 나중에 처리하도록 만드는 관리형 큐 서비스다.

왜 필요한가

서비스 간 결합도를 낮춘다.
트래픽 급증을 완충한다.
비동기 처리와 재시도 구조를 만든다.

종류

Standard Queue: 높은 처리량, 최소 1회 전달, 순서 보장 없음
FIFO Queue: 순서 보장, 중복 제거 지원, 처리량 제약 있음

핵심 개념

Visibility Timeout
Long Polling
DLQ(Dead Letter Queue)

88. SNS

SNS(Simple Notification Service) 는 Pub/Sub 방식의 메시지 팬아웃 서비스다.

왜 필요한가

하나의 이벤트를 여러 소비자에게 동시에 전달할 수 있다.

구독 대상 예시

SQS
Lambda
HTTPS Endpoint
Email / SMS 등

89. SQS vs SNS

SQS: 메시지 보관과 소비자 비동기 처리
SNS: 메시지 배포와 팬아웃
둘은 경쟁 관계가 아니라 함께 자주 사용된다.

90. EventBridge

EventBridge 는 이벤트 버스 서비스다.

왜 필요한가

AWS 서비스, SaaS, 사용자 정의 애플리케이션 이벤트를 규칙 기반으로 라우팅한다.
느슨한 이벤트 기반 아키텍처를 만들 수 있다.

핵심 특징

JSON 규칙 기반 필터링
다양한 대상 서비스로 전달
아카이빙과 리플레이 가능
스케줄 기반 이벤트 생성 가능

91. S3 Event Notification

S3는 객체 생성, 삭제, 복원 등의 이벤트를 발생시킬 수 있다.

전송 대상

Lambda
SNS
SQS

사용 예시

이미지 업로드 후 썸네일 생성
업로드 후 메타데이터 추출
파일 도착 알림

92. S3 Event Notification with EventBridge

S3 이벤트를 EventBridge로 보내면 더 풍부한 필터링과 다양한 대상 연계가 가능하다.

장점

객체 이름, 크기 등 더 세밀한 조건 처리
더 많은 AWS 서비스 대상 연결
이벤트 아카이브/리플레이 활용 가능

93. EventBridge와 CloudTrail API 이벤트

CloudTrail은 AWS API 호출을 기록하고, EventBridge는 그 이벤트를 받아 규칙 기반 자동화를 실행할 수 있다.

사용 예시

특정 IAM 변경 발생 시 경고
보안 그룹 변경 감지
루트 계정 사용 감지

94. Kinesis Data Streams

Kinesis Data Streams 는 실시간 스트리밍 데이터 수집 서비스다.

왜 필요한가

로그, 클릭스트림, IoT 이벤트처럼 연속적으로 들어오는 데이터를 실시간 처리할 수 있다.

핵심 개념

Shard
Producer
Consumer
순서 보장은 샤드 내부에서 유지

95. Kinesis Data Firehose

Firehose 는 스트리밍 데이터를 S3, Redshift, OpenSearch 등으로 적재하는 관리형 전송 서비스다.

왜 필요한가

직접 Consumer 애플리케이션을 만들지 않고도 적재 파이프라인을 쉽게 만들 수 있다.

96. Amazon MQ

Amazon MQ 는 ActiveMQ / RabbitMQ 기반 관리형 메시지 브로커 서비스다.

왜 필요한가

레거시 애플리케이션이 JMS, AMQP, MQTT, STOMP 등 전통적 메시지 브로커 프로토콜을 필요로 할 수 있다.

SQS와 비교

SQS: 클라우드 네이티브 큐, AWS 방식
Amazon MQ: 전통 브로커 호환성 필요 시

97. MSK

Amazon MSK 는 관리형 Kafka 서비스다.

왜 필요한가

Kafka 생태계를 유지하면서 운영 부담을 줄일 수 있다.

적합한 경우

Kafka API/생태계가 필요한 조직
스트리밍 파이프라인 표준이 Kafka일 때

98. AppFlow

Amazon AppFlow 는 SaaS와 AWS 서비스 간 데이터를 연결하는 관리형 통합 서비스다.

왜 필요한가

Salesforce, SAP, ServiceNow, Slack 등과 S3/Redshift 같은 AWS 저장소를 연결할 수 있다.
스케줄 기반 또는 이벤트 기반 통합이 가능하다.

99. Big Data Ingestion Pipeline 예시

대표적인 수집 파이프라인 예시는 다음과 같다.

IoT Core 또는 API Gateway에서 데이터 수집
Kinesis / Firehose로 스트림 처리
S3에 데이터 레이크 저장
SQS + Lambda로 후처리
Athena/Redshift/QuickSight로 분석

데이터 분석과 BI

이 구간은 저장된 데이터를 어떻게 적재하고, 가공하고, 조회하고, 시각화하는지 전체 흐름으로 본다.

100. Athena

Athena 는 S3에 저장된 데이터를 SQL로 바로 조회하는 서버리스 쿼리 서비스다.

왜 필요한가

인프라 없이 데이터 레이크를 탐색할 수 있다.
로그 분석, ad-hoc 분석에 매우 유용하다.

성능 포인트

컬럼형 포맷(Parquet, ORC)
파티셔닝
작은 파일 너무 많이 만들지 않기

101. Redshift

Redshift 는 대규모 분석용 데이터 웨어하우스 서비스다.

왜 필요한가

BI, 대규모 집계, OLAP 분석에 적합하다.

Athena와 비교

Athena: S3 위 서버리스 쿼리
Redshift: 데이터 웨어하우스 중심, 반복 분석과 BI에 강함

102. OpenSearch

OpenSearch 는 검색과 로그 분석에 강한 엔진 기반 서비스다.

적합한 경우

전문 검색
로그 인덱싱
대시보드 기반 분석

103. EMR

EMR 는 Hadoop, Spark 등 빅데이터 프레임워크를 실행하는 서비스다.

왜 필요한가

대규모 분산 처리 작업을 할 수 있다.
Spark 기반 데이터 처리/ML 전처리에 자주 쓰인다.

104. Glue

AWS Glue 는 관리형 데이터 통합/ETL 서비스다.

왜 필요한가

데이터 카탈로그를 만들고 ETL 작업을 자동화할 수 있다.

핵심 개념

Data Catalog
Crawler
ETL Job
Job Bookmark

105. Lake Formation

Lake Formation 은 데이터 레이크 구축과 권한 관리를 도와주는 서비스다.

왜 필요한가

S3 기반 데이터 레이크 권한을 중앙에서 통제할 수 있다.

106. Kinesis Data Analytics

Kinesis Data Analytics는 스트리밍 데이터 실시간 분석 서비스다.

유형

SQL 기반 스트림 분석
Apache Flink 기반 실시간 처리

107. QuickSight

QuickSight 는 AWS의 BI 시각화 서비스다.

왜 필요한가

Athena, Redshift, RDS 등과 연결해 대시보드와 리포트를 만들 수 있다.

보안과 IAM

보안은 단일 서비스가 아니라 계층 구조다. 권한, 네트워크, 암호화, 감사, 탐지가 함께 가야 실제 보안 체계가 완성된다.

108. IAM

IAM(Identity and Access Management) 은 AWS 접근 권한을 제어하는 핵심 서비스다.

왜 필요한가

누가 무엇을 할 수 있는지 정의한다.
최소 권한 원칙을 실현한다.

109. IAM User, Group, Policy, Role

IAM User

사람 또는 애플리케이션의 장기 자격 증명 주체

IAM Group

여러 사용자에게 동일 정책 적용

IAM Policy

권한을 JSON 문서로 표현

IAM Role

임시 권한을 부여하는 주체
EC2, Lambda, ECS Task 등에 매우 중요

110. Policy 기본 개념

주요 구성 요소

Effect
Action
Resource
Condition
Principal(리소스 기반 정책에서 중요)

핵심 규칙

명시적 Deny가 항상 우선
그 다음 Allow 평가
아무 것도 허용되지 않으면 기본적으로 거부

111. Principal

Principal 은 “누가 이 리소스에 접근하는가”를 의미한다.

언제 중요해지는가

S3 Bucket Policy
SNS Topic Policy
SQS Queue Policy
KMS Key Policy

112. Policy Evaluation Logic

권한 평가는 여러 정책이 합쳐져 결정된다.

함께 고려되는 요소

IAM Identity Policy
Resource-based Policy
SCP
Permission Boundary
Session Policy

113. SCP

SCP(Service Control Policy) 는 AWS Organizations에서 계정/OU 수준의 최대 권한 범위를 제어한다.

핵심 포인트

권한을 부여하는 정책이 아니라 허용 한도를 제한한다.
루트 계정 포함 조직 전체 가드레일로 사용될 수 있다.

114. Permission Boundaries

Permission Boundary 는 IAM 주체가 가질 수 있는 최대 권한 한계를 제한한다.

적합한 경우

팀/셀프서비스 환경에서 권한 위임을 하되 상한선을 두고 싶을 때

115. Cognito

Cognito 는 외부 사용자 인증/인가를 위한 서비스다.

구성 요소

User Pool: 사용자 인증
Identity Pool: AWS 자격 증명 연동

적합한 경우

모바일/웹 앱 사용자 로그인
소셜 로그인 연계
외부 사용자 대상 인증 시스템

116. IAM Identity Center

IAM Identity Center 는 AWS 계정과 애플리케이션에 대한 SSO를 제공한다.

적합한 경우

여러 AWS 계정을 중앙에서 접근 관리
조직 단위 SSO

117. Directory Service

Directory Service 는 Microsoft AD 연동 또는 디렉터리 서비스를 제공한다.

왜 필요한가

기업 환경은 기존 AD 기반 인증 체계를 많이 사용한다.
AWS로 워크로드를 옮겨도 사용자/그룹/정책 체계를 완전히 버리기 어려운 경우가 많다.

적합한 경우

Windows 서버 운영
AD 기반 인증 통합
기업 내부 인증 체계를 AWS 리소스와 연결해야 할 때

118. KMS

KMS(Key Management Service) 는 암호화 키를 관리하는 서비스다.

왜 필요한가

저장 시 암호화에 필요한 키를 중앙에서 관리한다.
키 정책, 감사 로그, 키 회전을 통제할 수 있다.

키 유형

대칭 키
비대칭 키
AWS Managed Key
Customer Managed Key
Multi-Region Key

핵심 포인트

대부분의 AWS 서비스 암호화와 연동된다.
CMK가 더 세밀한 제어를 제공한다.

119. Parameter Store vs Secrets Manager

SSM Parameter Store

설정값, 구성값 저장
KMS 암호화 가능
운영 파라미터 관리에 적합

Secrets Manager

DB 비밀번호, API 키 같은 비밀 저장
회전 기능이 더 강력함

120. ACM

ACM(AWS Certificate Manager) 는 TLS 인증서를 발급/관리하는 서비스다.

적합한 경우

ALB, CloudFront, API Gateway 등의 HTTPS 구성

121. AWS WAF

WAF(Web Application Firewall) 는 HTTP/HTTPS 요청을 필터링하는 L7 보안 서비스다.

왜 필요한가

IP 차단
SQL Injection/XSS 방어
봇/비정상 요청 패턴 차단
Rate limiting

122. AWS Shield

Shield 는 DDoS 방어 서비스다.

Shield Standard: 기본 제공
Shield Advanced: 더 강한 보호와 지원

123. Firewall Manager

Firewall Manager 는 여러 계정/리소스에 대한 보안 정책을 중앙에서 관리하는 서비스다.

왜 필요한가

계정 수가 많아질수록 WAF, Shield, 보안 정책을 일일이 맞추기 어려워진다.
중앙 보안팀이 조직 전체 정책을 강제해야 하는 멀티 계정 환경에서 특히 유용하다.

124. GuardDuty

GuardDuty 는 위협 탐지 서비스다.

데이터 소스 예시

CloudTrail 이벤트
VPC Flow Logs
DNS 로그

125. Inspector

Inspector 는 취약점 스캔 및 보안 점검 서비스다.

왜 필요한가

운영 중인 EC2나 컨테이너 이미지의 취약 패키지와 노출 위험을 자동으로 찾을 수 있다.
단순 권한 통제만으로는 보이지 않는 보안 위생 상태를 점검할 수 있다.

126. Macie

Macie 는 S3의 민감 정보 탐지와 데이터 보안 분석 서비스다.

왜 필요한가

S3는 너무 자주 쓰이기 때문에 민감 정보가 의도치 않게 저장되기 쉽다.
데이터의 존재 자체를 모르면 접근 제어만 잘해도 위험을 놓칠 수 있다.

적합한 경우

개인정보 탐지
규제 대응
민감 데이터 위치 파악

127. CloudTrail

CloudTrail 은 AWS API 호출 이력을 기록하는 감사 서비스다.

왜 필요한가

누가 무엇을 했는지 추적
보안 감사와 포렌식
EventBridge 자동화 연동

128. AWS Config

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

왜 필요한가

설정 드리프트 탐지
규정 위반 여부 검사
보안/컴플라이언스 자동화

운영, 배포, 비용 최적화

운영 파트는 “문제가 생겼을 때 어떻게 보고, 어떻게 대응하고, 어떻게 반복 작업을 자동화할 것인가”를 중심으로 이해하면 된다.

129. CloudWatch

CloudWatch 는 메트릭, 로그, 알람을 중심으로 AWS 리소스와 애플리케이션을 모니터링하는 서비스다.

왜 필요한가

성능 저하나 장애를 빠르게 감지할 수 있다.
로그와 메트릭을 기반으로 운영 자동화를 구성할 수 있다.

핵심 구성

Metrics
Logs
Alarms
Dashboards
Events/EventBridge 연계

130. CloudWatch Logs

애플리케이션 로그, 시스템 로그, Lambda 로그 등을 수집한다.

131. CloudWatch Alarm

임계값 조건을 만족하면 알림 또는 자동 조치를 발생시킨다.

사용 예시

CPU 과다 사용 경고
EC2 Recovery
Auto Scaling 트리거
SNS 알림

132. EventBridge 운영 관점

EventBridge는 단순 이벤트 버스가 아니라 운영 자동화의 핵심이 될 수 있다.

사용 예시

일정 기반 배치 작업 실행
특정 리소스 변경 시 자동 대응
Config 규정 위반 시 자동 보정
SSM Automation 트리거

133. CloudFormation

CloudFormation 은 AWS 인프라를 코드로 선언하는 IaC(Infrastructure as Code) 서비스다.

왜 필요한가

수동 클릭 대신 템플릿으로 인프라를 일관되게 배포할 수 있다.
환경 간 반복 배포가 쉬워진다.
변경 이력을 코드 리뷰로 관리할 수 있다.

장점

선언형 방식
재현성
태그 일관성
비용 추적 보조
스택 단위 관리

실무 포인트

실험용/운영용 환경을 같은 템플릿으로 재사용 가능
지원되지 않는 리소스는 커스텀 리소스 고려 가능

134. SSM Session Manager

Session Manager 는 SSH 키나 Bastion 없이 EC2/온프레미스 서버에 안전하게 접속하는 기능이다.

왜 중요한가

포트 22를 열지 않아도 된다.
SSH 키 관리 부담을 줄인다.
접속 로그를 S3/CloudWatch로 남길 수 있다.

Bastion과 비교

Bastion: 별도 점프 서버 운영 필요
Session Manager: 관리형에 가깝고 더 안전한 운영 가능

135. Run Command

Run Command 는 여러 인스턴스에 명령을 원격으로 실행하는 기능이다.

사용 예시

패키지 설치
에이전트 배포
진단 명령 실행
긴급 운영 명령 배포

136. Patch Manager

Patch Manager 는 OS와 소프트웨어 패치 작업을 자동화하는 기능이다.

왜 필요한가

보안 패치를 표준화하고 정기적으로 적용할 수 있다.
패치 준수 여부를 관리할 수 있다.

137. Maintenance Windows

유지보수 작업이 실행될 일정 창을 정의한다.

사용 예시

OS 패치
재부팅
소프트웨어 업데이트
스크립트 실행

138. Automation

SSM Automation 은 운영 Runbook을 자동화하는 기능이다.

사용 예시

인스턴스 재시작
AMI 생성
EBS 스냅샷
장애 복구 절차 실행

139. Trusted Advisor

Trusted Advisor 는 AWS 계정에 대한 권고를 제공하는 서비스다.

주요 범주

비용 최적화
성능
보안
내결함성
서비스 할당량

예시

사용률 낮은 EC2
미사용 EBS/EIP
루트 MFA 미설정
과도하게 열린 보안 그룹
Multi-AZ 미구성

140. Cost Explorer

Cost Explorer 는 비용과 사용량을 시각적으로 분석하는 서비스다.

왜 필요한가

어떤 서비스가 비용을 많이 쓰는지 파악할 수 있다.
태그 기준 비용 분석이 가능하다.
미래 비용을 예측하는 데 도움을 준다.

141. 비용 최적화 핵심 포인트

사용하지 않는 리소스 정리
적절한 인스턴스 타입 선택
Savings Plans / RI 고려
S3 Lifecycle과 스토리지 클래스 최적화
서버리스/관리형 서비스 활용으로 운영비 절감

백업, 복구, 마이그레이션

이 구간은 장애가 났을 때의 복구 전략과, 기존 시스템을 AWS로 옮길 때 필요한 도구를 함께 다룬다. 운영 후반부가 아니라 설계 초기에 같이 고려해야 하는 파트다.

142. Disaster Recovery 개요

재해 복구(DR) 는 재해 발생 시 비즈니스와 서비스를 복구하기 위한 전략이다.

재해 예시

리전 장애
데이터 손상
랜섬웨어/악의적 삭제
네트워크 분리
대규모 인프라 장애

143. RPO와 RTO

RPO(Recovery Point Objective)

얼마만큼의 데이터 손실까지 허용할지에 대한 목표
백업 주기, 복제 주기와 직접 관련된다.

RTO(Recovery Time Objective)

장애 후 얼마 안에 서비스를 복구할지에 대한 목표
복구 절차 자동화와 예비 인프라 규모에 큰 영향을 준다.

144. DR 전략 1. Backup and Restore

가장 단순한 복구 전략이다.

특징

평소 비용이 가장 낮다.
스냅샷/백업을 저장해 두고 재해 시 복구한다.
RPO, RTO가 상대적으로 길다.

145. DR 전략 2. Pilot Light

핵심 데이터와 최소 구성만 항상 유지하는 전략이다.

특징

복구 시 코어 시스템을 빠르게 키운다.
비용과 복구 속도의 균형형 전략이다.

146. DR 전략 3. Warm Standby

전체 시스템을 작은 규모로 계속 돌리는 전략이다.

특징

장애 시 빠르게 확장 가능
Backup/Pilot Light보다 복구가 빠름
비용은 더 큼

147. DR 전략 4. Multi Site / Hot Site

여러 사이트가 모두 실제 운영 가능한 수준으로 동작하는 전략이다.

특징

가장 낮은 RTO/RPO 가능
비용과 운영 복잡도가 가장 높음
Active-Active 아키텍처와 연결된다.

148. AWS Backup

AWS Backup 은 여러 AWS 서비스의 백업을 중앙에서 관리하는 서비스다.

왜 필요한가

백업 정책을 서비스별로 따로 만들 필요를 줄인다.
계정 간/리전 간 백업 전략을 일관되게 만들 수 있다.

특징

백업 플랜
스케줄/보관 기간 설정
태그 기반 백업 정책
리전 간 복사
계정 간 백업
PITR 지원 서비스 존재

149. AWS Backup Vault Lock

Vault Lock 은 백업을 WORM(Write Once Read Many) 방식으로 보호한다.

왜 중요한가

악의적 삭제나 백업 변조를 방지할 수 있다.
보존 기간 변경까지 막을 수 있다.
랜섬웨어 대응 관점에서 중요하다.

150. DMS

DMS(Database Migration Service) 는 데이터베이스 마이그레이션과 지속적 복제를 지원하는 서비스다.

왜 필요한가

마이그레이션 중에도 소스 DB를 계속 사용할 수 있다.
CDC(변경 데이터 캡처)를 통한 지속 복제를 지원한다.

사용 예시

온프레미스 -> RDS
RDS -> Aurora
DB -> S3 / Redshift / DynamoDB / Kinesis

151. SCT

SCT(Schema Conversion Tool) 는 소스와 타깃 DB 엔진이 다를 때 스키마 변환을 도와준다.

핵심 포인트

동종 엔진이면 보통 필요 없다.
이기종 마이그레이션에서 중요하다.

152. Aurora 마이그레이션 전략

RDS MySQL -> Aurora MySQL

스냅샷 기반 마이그레이션
Aurora Read Replica 기반 점진적 마이그레이션

외부 MySQL -> Aurora

백업/Import
DMS 기반 지속 복제

153. Application Discovery Service

Application Discovery Service 는 온프레미스 서버의 구성, 사용량, 종속성을 파악해 마이그레이션 계획을 돕는다.

왜 필요한가

무엇을 먼저 옮겨야 하는지
어떤 서버끼리 연결되어 있는지
리소스 사용량이 어떤지 파악할 수 있다.

154. AWS Application Migration Service(MGN)

MGN 은 서버를 AWS로 리호스팅(lift-and-shift)하는 데 특화된 서비스다.

특징

지속 복제 기반
다운타임 최소화
물리/가상/다른 클라우드 서버 이전 지원

155. VM Import/Export

가상 머신 이미지를 EC2와 온프레미스 환경 간에 가져오거나 내보내는 기능이다.

왜 필요한가

기존 가상화 환경의 이미지를 AWS로 이전할 수 있다.
반대로 특정 이미지를 외부 환경으로 반출해야 할 수도 있다.

적합한 경우

레거시 VM 이전
점진적 클라우드 전환
테스트용 이미지 이동

156. 대규모 데이터 전송 전략

데이터 양과 시간 제약에 따라 전략이 달라진다.

선택 기준

작은 데이터: 인터넷 업로드
지속적 연결: VPN / DX / DataSync
대규모 일회성 이전: Snowball
DB 지속 복제: DMS

커뮤니케이션/기타 서비스

이 구간은 핵심 인프라 외에도 실무에서 자주 만나는 목적형 서비스를 모아 정리한다. 메일, 마케팅 메시징, 배치 처리, 미디어 변환이 대표적이다.

157. SES

SES(Simple Email Service) 는 대규모 이메일 송수신을 위한 관리형 서비스다.

왜 필요한가

트랜잭션 이메일, 알림 메일, 대량 발송 등에 적합하다.
SMTP 또는 API 방식으로 연동 가능하다.
DKIM, SPF, 피드백 처리 등 이메일 운영 기능을 제공한다.

158. Pinpoint

Pinpoint 는 이메일, SMS, 푸시, 인앱 메시지 같은 마케팅/커뮤니케이션 채널을 관리하는 서비스다.

SES/SNS와 차이

SES/SNS: 메시지 자체를 전달하는 기능 중심
Pinpoint: 캠페인, 세그먼트, 개인화, 다채널 커뮤니케이션에 강함

159. AWS Batch

AWS Batch 는 대규모 배치 작업 실행을 자동화하는 서비스다.

왜 필요한가

작업 큐에 잡을 넣으면 적절한 컴퓨팅 리소스를 자동으로 프로비저닝한다.
EC2/Spot을 활용해 비용 효율적인 배치 처리가 가능하다.

Lambda와 비교

Batch: 긴 실행, 대규모 배치, 컨테이너 기반 작업
Lambda: 짧은 이벤트 처리, 빠른 함수 실행

160. Elastic Transcoder

Elastic Transcoder 는 미디어 파일을 다른 포맷으로 변환하는 관리형 서비스다.

적합한 경우

동영상/오디오 포맷 변환
디바이스별 미디어 최적화

왜 필요한가

모든 단말이 같은 미디어 포맷을 잘 재생하는 것은 아니다.
업로드 원본을 여러 해상도와 포맷으로 변환해야 하는 경우가 많다.
직접 EC2에 인코딩 파이프라인을 구축하지 않고도 미디어 변환을 처리할 수 있다.

마무리 정리

161. 서비스 선택을 단순화하는 질문

네트워크

외부 노출이 필요한가: ALB / NLB / CloudFront / API Gateway
내부만 써야 하는가: Private Subnet / Endpoint / Internal LB
여러 VPC/온프레미스를 묶어야 하는가: TGW / VPN / DX

컴퓨팅

OS 제어가 필요한가: EC2
컨테이너만 관리하고 싶은가: ECS / EKS
서버도 관리하기 싫은가: Fargate / Lambda / App Runner

스토리지

서버 디스크가 필요한가: EBS
공유 파일시스템이 필요한가: EFS / FSx
대용량 객체 저장인가: S3

데이터베이스

관계형 SQL인가: RDS / Aurora
NoSQL 초고확장인가: DynamoDB
캐시인가: ElastiCache
그래프/문서/시계열 같은 특수 모델인가: Neptune / DocumentDB / Timestream

메시징

큐잉이 필요한가: SQS
팬아웃이 필요한가: SNS
이벤트 버스가 필요한가: EventBridge
스트리밍이 필요한가: Kinesis / MSK

보안과 운영

권한 관리: IAM / SCP / Permission Boundary
비밀 관리: Secrets Manager / Parameter Store
감사: CloudTrail / Config
운영 자동화: CloudWatch / EventBridge / SSM / CloudFormation

162. 최종 핵심 원칙

AWS는 개별 서비스 암기보다 역할 분리로 이해해야 한다.
고가용성은 보통 Multi-AZ, 자동 복구, 분산 구조가 핵심이다.
보안은 IAM, 네트워크, 암호화, 감사, 운영 자동화가 함께 가야 한다.
관리형 서비스를 적극적으로 활용할수록 운영 복잡도는 줄어든다.
재해 복구와 마이그레이션은 마지막에 붙이는 기능이 아니라 초기 설계부터 고려해야 한다.

Kjjedd

Gongbuhaja

이전 포스트

AWS 용어 정리 스크립트

CS

AWS 용어 정리 스크립트

문서 구조

AWS 기초와 글로벌 인프라

0. AWS란 무엇인가

왜 필요한가

클라우드의 핵심 가치

1. Shared Responsibility Model

AWS의 책임

고객의 책임

핵심 포인트

2. AWS 글로벌 인프라

왜 먼저 알아야 하는가

전체 그림

3. Region

왜 필요한가

핵심 포인트

4. Availability Zone

왜 필요한가

핵심 포인트

5. Data Center

핵심 포인트

6. Edge Location

왜 필요한가

7. Well-Architected Framework

6가지 핵심 축

자주 나오는 원칙

관련 도구

네트워크 기초

8. CIDR

왜 필요한가

예시

주의사항

9. VPC

왜 필요한가

핵심 구조

실무 포인트

10. Subnet

왜 필요한가

핵심 포인트

11. Public Subnet vs Private Subnet

Public Subnet

Private Subnet

핵심 포인트

12. Route Table

왜 필요한가

대표 경로

13. Internet Gateway

왜 필요한가

핵심 포인트

14. Egress-only Internet Gateway

왜 필요한가

15. NAT

왜 필요한가

핵심 포인트

16. NAT Gateway

왜 필요한가

특징

주의사항

17. NAT Instance

지금은 왜 잘 안 쓰는가

비교 포인트

18. Elastic IP

왜 필요한가

주의사항

19. Security Group

왜 필요한가

핵심 포인트

예시

20. NACL

왜 필요한가

핵심 포인트

Security Group과 비교

21. ENI

핵심 포인트

22. Bastion Host

왜 필요한가

현재 실무 흐름

23. VPC Flow Logs