10. 추가 AWS 서비스 및 리소스 정리

Part 1: 추가 AWS 서비스 소개

이번 챕터에서는 실무에서 자주 사용되지만 앞선 챕터에서 미처 다루지 못한 AWS 서비스 4가지를 소개한다. 이 서비스들은 각각 캐싱, DNS, 이메일, 메시지 큐라는 서로 다른 영역을 담당하며, 현대 클라우드 아키텍처에서 빠질 수 없는 핵심 구성 요소이다.

1. ElastiCache (엘라스티캐시)

개념

ElastiCache는 AWS가 제공하는 완전관리형 인메모리 데이터 스토어(In-Memory Data Store) 서비스이다. 인메모리란 말 그대로 RAM(Random Access Memory)에 데이터를 저장하는 방식을 의미한다.

일반적인 데이터베이스(RDS, DynamoDB 등)는 데이터를 **디스크(Disk)**에 저장한다. 디스크에서 데이터를 읽는 것은 RAM에서 읽는 것보다 수백 배에서 수천 배 느리다. ElastiCache는 자주 조회되는 데이터를 RAM에 미리 올려두어 응답 속도를 극적으로 개선한다.

비유로 이해하기

도서관에서 책을 찾는다고 생각해보자.
디스크 기반 DB = 서고(창고)에서 책을 찾아오는 것. 서고까지 걸어가서, 선반을 뒤져서, 책을 찾아 돌아와야 한다.
ElastiCache = 내 책상 위에 자주 보는 책을 미리 꺼내놓은 것. 손만 뻗으면 바로 볼 수 있다.
책상 공간(RAM)은 서고(디스크)보다 훨씬 작지만, 접근 속도는 비교할 수 없이 빠르다.

지원 엔진

ElastiCache는 두 가지 오픈소스 인메모리 엔진을 지원한다.

항목	Redis	Memcached
데이터 구조	문자열, 해시, 리스트, 셋, 정렬 셋 등 다양	단순 키-값(Key-Value)만 지원
데이터 영속성	스냅샷(Snapshot) 및 AOF로 디스크 백업 가능	순수 캐시 전용, 재시작 시 데이터 소실
복제(Replication)	읽기 복제본(Read Replica) 지원	미지원
클러스터링	Redis Cluster 모드 지원	여러 노드에 자동 분산
사용 사례	세션 관리, 리더보드, 실시간 분석, 메시지 브로커	단순 캐싱, HTML 조각 캐싱

주요 사용 사례

데이터베이스 캐싱: RDS나 DynamoDB 앞단에 캐시 레이어를 두어 DB 부하를 줄인다.
세션 스토어(Session Store): 웹 애플리케이션의 사용자 세션 정보를 저장한다. EC2 인스턴스가 여러 대일 때 세션 공유가 가능하다.
실시간 리더보드: 게임이나 랭킹 시스템에서 정렬된 데이터를 초고속으로 조회한다.
API 응답 캐싱: 외부 API 호출 결과를 캐싱하여 반복 호출을 줄인다.

아키텍처 예시

[사용자] → [ELB] → [EC2 애플리케이션]
                         │
                    ┌────┴────┐
                    │         │
              [ElastiCache]  [RDS]
              (캐시 히트 시  (캐시 미스 시
               즉시 응답)    DB 조회 후
                             캐시에 저장)

작동 흐름:

애플리케이션이 데이터 요청을 받는다.
먼저 ElastiCache에서 해당 데이터를 찾는다 (캐시 히트, Cache Hit).
캐시에 데이터가 있으면 즉시 반환한다 (수 밀리초).
캐시에 없으면(캐시 미스, Cache Miss) RDS에서 조회한다.
RDS에서 가져온 데이터를 ElastiCache에 저장(캐싱)한 뒤 반환한다.
다음 동일 요청은 캐시에서 바로 응답한다.

비용 고려사항

ElastiCache는 노드 유형과 개수에 따라 과금된다.
Free Tier에서 cache.t2.micro 또는 cache.t3.micro 노드를 월 750시간 무료로 사용할 수 있다 (12개월간).
실습 후 반드시 클러스터를 삭제해야 한다.

2. Route 53 (라우트 53)

개념

Route 53은 AWS의 완전관리형 DNS(Domain Name System) 서비스이다. "53"이라는 이름은 DNS가 사용하는 포트 번호 53에서 유래했다.

DNS란 사람이 읽을 수 있는 도메인 이름(예: www.example.com)을 컴퓨터가 이해하는 IP 주소(예: 192.0.2.1)로 변환하는 시스템이다.

비유로 이해하기

DNS는 인터넷의 전화번호부이다.
친구에게 전화할 때 전화번호(IP 주소)를 외우지 않고 연락처 이름(도메인 이름)으로 검색하는 것과 같다.
www.example.com이라고 입력하면, DNS가 이 이름에 해당하는 IP 주소 192.0.2.1을 찾아 브라우저에 알려준다.
Route 53은 이 전화번호부를 AWS가 관리해주는 서비스이다.

DNS 동작 원리 상세

[사용자가 www.example.com 입력]
         │
         ▼
[브라우저 DNS 캐시 확인] ─── 캐시 히트 → 바로 접속
         │ 캐시 미스
         ▼
[OS DNS 캐시 확인] ─── 캐시 히트 → 바로 접속
         │ 캐시 미스
         ▼
[ISP의 DNS 리졸버(Recursive Resolver)]
         │
         ▼
[루트 네임서버(.)] → [TLD 네임서버(.com)] → [Route 53 네임서버]
                                                    │
                                                    ▼
                                          [IP 주소 192.0.2.1 반환]
                                                    │
                                                    ▼
                                          [브라우저가 해당 서버에 접속]

Route 53의 세 가지 핵심 기능

1) 도메인 등록(Domain Registration)

example.com 같은 도메인을 직접 구매하고 등록할 수 있다.
.com, .net, .org, .io 등 다양한 TLD(Top-Level Domain)를 지원한다.
연간 갱신 비용이 발생한다 (예: .com은 연간 약 $12).

2) DNS 라우팅(DNS Routing)

도메인 이름을 실제 리소스(EC2, ELB, S3, CloudFront 등)에 연결한다. Route 53은 다양한 라우팅 정책을 지원한다.

라우팅 정책	설명	사용 사례
단순 라우팅(Simple)	하나의 리소스로 트래픽을 보냄	단일 서버
가중치 기반(Weighted)	비율에 따라 트래픽을 분배	A/B 테스트, 점진적 배포
지연 시간 기반(Latency)	가장 응답이 빠른 리전으로 라우팅	글로벌 서비스
장애 조치(Failover)	주 서버 장애 시 백업 서버로 전환	고가용성(HA) 구성
지리적 위치(Geolocation)	사용자 위치 기반 라우팅	지역별 콘텐츠 제공
다중 값 응답(Multivalue)	여러 IP를 반환, 헬스체크와 결합	간단한 부하 분산

3) 헬스 체크(Health Check)

연결된 리소스의 상태를 주기적으로 확인한다.
서버가 응답하지 않으면 해당 리소스로 트래픽을 보내지 않는다.
HTTP, HTTPS, TCP 프로토콜로 헬스 체크를 설정할 수 있다.
CloudWatch 경보와 연동하여 장애 알림을 보낼 수 있다.

DNS 레코드 타입

레코드 타입	설명	예시
A	도메인 → IPv4 주소	`example.com → 192.0.2.1`
AAAA	도메인 → IPv6 주소	`example.com → 2001:db8::1`
CNAME	도메인 → 다른 도메인	`www.example.com → example.com`
MX	메일 서버 지정	`example.com → mail.example.com`
NS	네임서버 지정	`example.com → ns-1.awsdns.com`
Alias	AWS 리소스 직접 연결 (Route 53 전용)	`example.com → d123.cloudfront.net`

참고: Alias 레코드는 Route 53 고유의 기능으로, AWS 리소스(ELB, CloudFront, S3 등)를 도메인의 루트(Zone Apex)에 직접 연결할 수 있다. CNAME은 루트 도메인에 사용할 수 없지만 Alias는 가능하다.

비용 고려사항

호스팅 영역(Hosted Zone) 1개당 월 $0.50.
DNS 쿼리 100만 건당 $0.40 (표준 쿼리 기준).
도메인 등록비는 TLD에 따라 다르다.
Free Tier에 포함되지 않으므로 실습 후 삭제를 권장한다.

3. SES (Simple Email Service, 심플 이메일 서비스)

개념

SES는 AWS의 대규모 이메일 발송 서비스이다. 개발자가 애플리케이션에서 프로그래밍 방식으로 이메일을 보낼 수 있도록 설계되었다.

일반 이메일 서비스(Gmail, Outlook 등)와 달리, SES는 수만에서 수백만 통의 이메일을 안정적으로 발송하는 데 최적화되어 있다.

비유로 이해하기

일반 이메일 = 개인이 편지를 한 통씩 보내는 것. SES = 기업이 운영하는 대형 우편 발송 센터. 수십만 통의 편지를 자동으로 분류하고, 주소를 인쇄하고, 한 번에 발송한다.
개인 편지와 달리, 대량 발송 센터는 배달 성공률 추적, 반송 처리, 수신 거부 관리까지 체계적으로 처리한다.

주요 사용 사례

이메일 유형	설명	예시
트랜잭션 이메일	사용자 행동에 의해 자동 발송	회원가입 인증, 비밀번호 재설정, 주문 확인
마케팅 이메일	프로모션/홍보 목적 발송	할인 쿠폰, 신제품 안내, 뉴스레터
알림 이메일	시스템 상태/이벤트 알림	결제 완료, 배송 출발, 서버 장애 알림
대량 이메일	고객 세그먼트별 타겟 발송	지역별 프로모션, 관심사별 콘텐츠

핵심 기능 상세

1) 발신자 인증(Sender Verification)

이메일 스팸 방지를 위해 SES는 발신 도메인 또는 이메일 주소를 인증해야 한다.

이메일 주소 인증: 개별 이메일 주소를 인증 (개발/테스트용).
도메인 인증: 도메인 전체를 인증 (운영 환경용). DNS에 DKIM, SPF 레코드를 추가한다.

2) 발송 평판 관리(Sending Reputation)

SES는 바운스율(Bounce Rate), 컴플레인율(Complaint Rate)을 모니터링한다.
바운스율이 5%를 초과하거나 컴플레인율이 0.1%를 초과하면 발송이 제한될 수 있다.
전용 IP(Dedicated IP)를 사용하면 다른 사용자의 평판 영향을 받지 않는다.

3) 샌드박스 모드(Sandbox Mode)

새 SES 계정은 기본적으로 샌드박스 모드로 시작한다.
샌드박스에서는 인증된 이메일 주소로만 발송 가능하다.
운영 환경으로 사용하려면 AWS에 프로덕션 액세스 요청을 해야 한다.

비용 고려사항

EC2에서 발송 시: 처음 62,000통/월 무료 (이후 1,000통당 $0.10).
EC2 외부에서 발송 시: 1,000통당 $0.10.
첨부 파일은 GB당 $0.12 추가.

4. SQS (Simple Queue Service, 심플 큐 서비스)

개념

SQS는 AWS의 완전관리형 메시지 큐(Message Queue) 서비스이다. 분산 시스템의 구성 요소 간에 메시지를 비동기적으로 전달하는 중간 매개체 역할을 한다.

SQS는 AWS에서 가장 오래된 서비스 중 하나로, 2006년에 출시되었다. 현대 **마이크로서비스 아키텍처(Microservice Architecture)**에서 서비스 간 결합도를 낮추는 데 필수적인 컴포넌트이다.

비유로 이해하기

놀이공원 줄서기를 생각해보자.
놀이기구(처리 서버)는 한 번에 정해진 인원만 태울 수 있다.
손님(요청)이 몰려도 줄(Queue)에서 기다린다.
먼저 줄 선 사람이 먼저 탑승한다 (FIFO: First In, First Out).
줄이 아무리 길어져도 놀이기구가 고장 나지 않는다 (과부하 방지).
놀이기구가 일시적으로 멈춰도 줄에 있는 사람들은 사라지지 않는다 (메시지 보존).
SQS가 바로 이 "줄" 역할을 한다. 보내는 쪽(Producer)과 받는 쪽(Consumer)을 분리하여 시스템 안정성을 확보한다.

큐의 두 가지 유형

항목	표준 큐(Standard Queue)	FIFO 큐(FIFO Queue)
순서 보장	최선 노력(Best-Effort) 순서	엄격한 FIFO 순서 보장
중복 가능성	간혹 중복 메시지 발생 가능	정확히 한 번만 전달(Exactly-Once)
처리량	거의 무제한	초당 최대 300건 (배치 시 3,000건)
사용 사례	로그 처리, 알림, 일반 작업 큐	금융 거래, 주문 처리 등 순서가 중요한 경우

핵심 동작 방식

[생산자(Producer)]          [SQS 큐]              [소비자(Consumer)]
      │                       │                         │
      │──── 메시지 전송 ────▶│                         │
      │                       │──── 메시지 수신 ────▶  │
      │                       │   (Visibility Timeout)  │
      │                       │                         │── 처리 완료
      │                       │◀── 메시지 삭제 ─────── │

**생산자(Producer)**가 메시지를 큐에 전송한다.
메시지는 큐에 저장되며 최대 14일간 보존된다 (기본 4일).
**소비자(Consumer)**가 큐에서 메시지를 가져간다(Poll).
메시지를 가져가면 가시성 제한 시간(Visibility Timeout) 동안 다른 소비자에게 보이지 않는다.
소비자가 처리를 완료하면 큐에서 메시지를 삭제한다.
가시성 제한 시간 내에 삭제하지 않으면 메시지가 다시 큐에 나타나 다른 소비자가 처리한다.

Apache Kafka와의 비교

SQS는 종종 Apache Kafka와 비교된다. 둘 다 메시지를 중개하는 역할을 하지만 설계 철학이 다르다.

항목	SQS	Apache Kafka
관리	AWS 완전관리형	직접 설치/운영 또는 MSK(Managed Streaming for Kafka) 사용
메시지 소비	소비 후 삭제	보존 기간 동안 여러 번 읽기 가능
스케일링	자동	파티션(Partition) 수동 설정
순서 보장	FIFO 큐에서만	파티션 내 보장
사용 사례	작업 큐, 비동기 처리	이벤트 스트리밍, 로그 집계, 실시간 파이프라인

AWS에서 Kafka가 필요하다면 Amazon MSK(Managed Streaming for Apache Kafka) 서비스를 사용할 수 있다.

실무 활용 예시

주문 처리 시스템:

[웹 주문 접수] → [SQS 주문 큐] → [주문 처리 서버]
                      │                  │
                      │             ┌────┴────┐
                      │             │         │
                      │        [재고 확인]  [결제 처리]
                      │             │         │
                      │             └────┬────┘
                      │                  │
                      │            [SQS 알림 큐] → [이메일 발송 서버]

이 구조의 장점:

주문이 폭주해도 큐가 완충 역할을 하여 서버가 과부하되지 않는다.
주문 처리 서버가 일시적으로 다운되어도 메시지가 큐에 보존된다.
각 단계를 독립적으로 확장(Scale)할 수 있다.

비용 고려사항

매월 첫 100만 요청 무료 (Free Tier 기간과 무관, 영구 무료).
이후 100만 요청당 $0.40 (표준 큐) / $0.50 (FIFO 큐).

Part 2: AWS 서비스 전체 요약 맵

지금까지 학습한 모든 AWS 서비스를 카테고리별로 정리한다. 각 서비스가 어떤 역할을 하고, 서로 어떤 관계에 있는지 전체 그림을 파악하는 것이 중요하다.

Mermaid 다이어그램 1: AWS 서비스 전체 맵

카테고리별 서비스 요약표

카테고리	서비스	한 줄 설명
컴퓨팅	EC2	가상 서버 인스턴스
	Elastic Beanstalk	코드만 올리면 인프라 자동 구성 (PaaS)
	Lightsail	소규모 프로젝트용 간편 서버
	Auto Scaling	트래픽에 따라 EC2 인스턴스 자동 증감
스토리지	S3	무제한 객체 스토리지 (파일, 이미지, 백업)
	EBS	EC2에 연결하는 가상 하드디스크
데이터베이스	RDS (MySQL)	완전관리형 관계형 데이터베이스
	DynamoDB	완전관리형 키-값/문서 NoSQL 데이터베이스
네트워킹	ELB	들어오는 트래픽을 여러 서버에 분산
	CloudFront	전 세계 엣지 로케이션에서 콘텐츠 전송 (CDN)
	Route 53	DNS 서비스 (도메인 이름 해석)
	Elastic IP	인스턴스에 연결하는 고정 공인 IP
보안	IAM	사용자/그룹/역할 기반 접근 제어
	Security Group	인스턴스 레벨 방화벽 (인바운드/아웃바운드 규칙)
모니터링	CloudWatch	지표 수집, 경보 설정, 대시보드, 로그 관리
메시징	SES	대량 이메일 발송
	SQS	서비스 간 비동기 메시지 큐
캐싱	ElastiCache	Redis/Memcached 기반 인메모리 캐시

Mermaid 다이어그램 2: 추가 서비스의 아키텍처 위치

다이어그램 해설:

Route 53 (DNS 계층): 사용자의 첫 관문. 도메인 이름을 IP 주소로 변환하여 어디로 가야 하는지 알려준다.
ElastiCache (캐시 계층): 애플리케이션과 데이터베이스 사이에 위치. DB 부하를 줄이고 응답 속도를 높인다.
SQS (비동기 처리 계층): 즉시 처리할 필요 없는 작업을 큐에 넣어 워커 서버가 순차적으로 처리한다.
SES (알림 계층): 처리 결과나 알림을 이메일로 사용자에게 전달한다.

Part 3: 리소스 일괄 정리 체크리스트

왜 리소스 정리가 중요한가?

AWS는 사용한 만큼 과금되는 구조이다. 실습용으로 생성한 리소스를 삭제하지 않으면 예상치 못한 비용이 발생할 수 있다.

실제 사례: EC2 인스턴스를 중지(Stop)만 하고 종료(Terminate)하지 않아 EBS 볼륨 요금이 계속 청구된 경우, 사용하지 않는 Elastic IP에서 시간당 $0.005가 과금되어 한 달에 $3.60이 청구된 경우 등이 있다.

삭제 순서의 원칙

리소스 간에는 **의존 관계(Dependency)**가 있다. 예를 들어, EC2 인스턴스를 삭제하기 전에 해당 인스턴스에 연결된 Elastic IP를 먼저 릴리즈해야 한다. 아래 순서는 의존 관계를 고려하여 정리한 권장 삭제 순서이다.

Mermaid 다이어그램 3: 리소스 정리 체크리스트 흐름도

상세 삭제 가이드

1단계: 컴퓨팅 리소스 정리

1) EC2: 모든 인스턴스 종료 (Terminate)

EC2 콘솔 → 인스턴스 → 모든 리전 확인 → 실행 중/중지됨 인스턴스 선택
→ 인스턴스 상태 → 인스턴스 종료 (Terminate)

중요: "중지(Stop)"가 아니라 "종료(Terminate)"를 선택해야 한다.
중지는 인스턴스를 일시 정지하는 것이고, 종료는 영구 삭제이다.
중지 상태에서도 EBS 볼륨 요금은 계속 청구된다.
모든 리전을 확인해야 한다. 서울(ap-northeast-2) 리전만 확인하고 다른 리전에 남아있는 인스턴스를 놓치는 경우가 많다.

인스턴스 종료 후 상태가 "terminated"로 바뀌면 잠시 후 목록에서 자동으로 사라진다.

2) EBS: 스냅샷 삭제

EC2 콘솔 → 탄력적 블록 스토어 → 스냅샷 → 선택 → 삭제

EC2 인스턴스를 종료하면 기본 EBS 볼륨은 함께 삭제된다 (DeleteOnTermination 기본값이 true인 경우).
하지만 수동으로 생성한 스냅샷은 자동 삭제되지 않는다.
스냅샷은 S3에 저장되며 GB당 월 $0.05가 과금된다.

3) AMI: 등록 취소 + 연관 스냅샷 삭제

EC2 콘솔 → AMI → 선택 → 작업 → AMI 등록 취소
→ 이후 연관된 스냅샷도 별도로 삭제

AMI를 등록 취소(Deregister)해도 연관 스냅샷은 자동 삭제되지 않는다.
반드시 AMI 등록 취소 후 연관 스냅샷을 추가로 삭제해야 한다.

2단계: 스토리지 및 데이터베이스 정리

4) S3: 객체 비우기 -> 버킷 삭제

S3 콘솔 → 버킷 선택 → "비우기(Empty)" → 확인
→ 비워진 버킷 선택 → "삭제(Delete)" → 버킷 이름 입력하여 확인

S3 버킷은 비어있어야만 삭제할 수 있다.
먼저 "비우기"로 모든 객체를 삭제한 뒤 버킷을 삭제한다.
**버전 관리(Versioning)**가 활성화된 버킷은 이전 버전 객체도 모두 삭제해야 한다.

5) RDS: 인스턴스 삭제 + 스냅샷 삭제

RDS 콘솔 → 데이터베이스 → 선택 → 작업 → 삭제
→ "최종 스냅샷 생성 여부" 체크 해제 → 확인
→ 이후 수동 스냅샷도 별도로 삭제

삭제 시 "최종 스냅샷 생성" 옵션이 기본으로 체크되어 있다. 실습용이라면 체크를 해제한다.
자동 백업은 인스턴스 삭제 시 함께 삭제되지만, 수동 스냅샷은 남아있다.
삭제 보호(Deletion Protection)가 활성화되어 있으면 먼저 비활성화해야 한다.

6) DynamoDB: 테이블 삭제

DynamoDB 콘솔 → 테이블 → 선택 → 삭제
→ "CloudWatch 경보 삭제" 체크 → 확인 텍스트 입력 → 삭제

DynamoDB는 테이블 단위로 삭제한다.
온디맨드 모드 테이블도 삭제하지 않으면 최소 요금이 발생할 수 있다.

3단계: 네트워크 및 배포 정리

7) CloudFront: 비활성화 -> 삭제

CloudFront 콘솔 → 배포 선택 → "비활성화(Disable)" → 상태가 "Deployed"로 바뀔 때까지 대기
→ 다시 선택 → "삭제(Delete)"

CloudFront는 즉시 삭제가 불가능하다. 먼저 비활성화하고 배포가 완료될 때까지 기다려야 한다.
비활성화 후 배포 완료까지 15~20분 소요될 수 있다.

8) CloudWatch: 경보 삭제

CloudWatch 콘솔 → 경보 → 모든 경보 → 선택 → 삭제

경보 자체는 비용이 거의 없지만, 깔끔한 정리를 위해 삭제한다.
경보에 연결된 SNS 주제가 있다면 함께 삭제를 고려한다.

9) ELB: 로드 밸런서 삭제

EC2 콘솔 → 로드 밸런서 → 선택 → 작업 → 삭제
→ 대상 그룹도 확인하여 삭제

로드 밸런서 삭제 후 **대상 그룹(Target Group)**도 별도로 삭제해야 한다.
리스너(Listener) 규칙은 로드 밸런서와 함께 자동 삭제된다.

10) Auto Scaling: 그룹 삭제

EC2 콘솔 → Auto Scaling 그룹 → 선택 → 삭제
→ 시작 템플릿(Launch Template)도 확인하여 삭제

Auto Scaling 그룹을 삭제하면 관리 중인 EC2 인스턴스도 자동으로 종료된다.
연관된 시작 템플릿(Launch Template)이나 시작 구성(Launch Configuration)도 삭제한다.

4단계: 관리형 서비스 정리

11) Elastic Beanstalk: 애플리케이션 삭제 + S3 수동 삭제

Elastic Beanstalk 콘솔 → 환경 → 종료(Terminate)
→ 애플리케이션 → 삭제
→ S3 콘솔에서 elasticbeanstalk 관련 버킷 수동 삭제

Elastic Beanstalk 환경을 종료하면 EC2, ELB, Auto Scaling 등 관련 리소스가 자동 삭제된다.
하지만 S3 버킷(애플리케이션 소스 코드 저장용)은 자동 삭제되지 않는다.
S3 콘솔에서 elasticbeanstalk- 접두사가 붙은 버킷을 찾아 수동으로 삭제해야 한다.

12) Lightsail: 인스턴스 삭제

Lightsail 콘솔 → 인스턴스 → 삭제 아이콘(쓰레기통) → 확인
→ 고정 IP가 있다면 별도로 분리 및 삭제
→ 스냅샷이 있다면 별도로 삭제

Lightsail은 EC2 콘솔이 아닌 별도의 Lightsail 콘솔에서 관리한다.
고정 IP(Static IP)가 연결되어 있으면 인스턴스 삭제 후 자동 해제되지 않으므로 직접 삭제한다.

5단계: IP 및 보안 정리

13) Elastic IP: 릴리즈

EC2 콘솔 → 탄력적 IP → 선택 → 작업 → 탄력적 IP 주소 릴리즈

핵심: Elastic IP는 인스턴스에 연결되어 있을 때는 무료이지만, 연결되지 않은 상태에서는 시간당 과금된다.
EC2 인스턴스를 종료한 후 Elastic IP를 릴리즈하지 않으면 비용이 계속 발생한다.
시간당 약 $0.005로 적은 금액이지만, 여러 개가 쌓이면 무시할 수 없다.

14) IAM: 사용자/그룹 삭제 (필요시)

IAM 콘솔 → 사용자 → 선택 → 삭제
→ 그룹 → 선택 → 삭제
→ 역할 → 불필요한 역할 삭제
→ 정책 → 커스텀 정책 삭제

IAM 자체는 무료 서비스이므로 비용 발생은 없다.
하지만 보안 측면에서 불필요한 사용자와 액세스 키는 삭제하는 것이 좋다.
루트 계정의 액세스 키가 있다면 반드시 비활성화 또는 삭제한다.

삭제 시 주의사항 요약

주의사항	설명
운영 데이터 백업	삭제 전 반드시 필요한 데이터는 백업한다. S3에서 다운로드하거나 RDS 스냅샷을 생성해둔다.
모든 리전 확인	AWS 콘솔은 리전별로 리소스를 표시한다. 서울(ap-northeast-2)만 확인하지 말고 사용한 모든 리전을 점검한다.
의존 관계 확인	삭제 순서를 지키지 않으면 "리소스가 사용 중"이라는 오류가 발생할 수 있다.
삭제 보호 비활성화	RDS, EC2 등에 삭제 보호(Deletion Protection)가 설정되어 있으면 먼저 해제해야 한다.
CloudFront 비활성화 대기	CloudFront는 비활성화 후 즉시 삭제할 수 없다. 15~20분 대기가 필요하다.

Part 4: 비용 관리 실전 가이드

Free Tier 한도 관리

AWS Free Tier는 크게 세 가지 유형이 있다.

유형	설명	예시
12개월 무료	계정 생성 후 12개월간 제공	EC2 t2.micro 750시간/월, S3 5GB, RDS db.t2.micro 750시간/월
항상 무료	기간 제한 없이 영구 제공	DynamoDB 25GB, Lambda 100만 요청/월, SQS 100만 요청/월
단기 체험	특정 서비스 최초 사용 시	Lightsail 첫 3개월, Redshift 2개월 등

Free Tier 12개월 기한 관리 팁:

계정 생성일을 기록해두고 11개월차에 미사용 리소스를 정리한다.
12개월이 지나면 t2.micro EC2도 시간당 요금이 부과된다.
결제 대시보드에서 Free Tier 사용량을 수시로 확인한다.

결제 대시보드 활용

AWS 콘솔 우측 상단 → 계정 이름 클릭 → "결제 대시보드(Billing Dashboard)"

결제 대시보드에서 확인해야 할 핵심 항목:

메뉴	용도
청구서(Bills)	이번 달 서비스별 상세 비용 확인
Free Tier 사용량	각 서비스별 Free Tier 한도 대비 현재 사용량
비용 탐색기(Cost Explorer)	기간별, 서비스별 비용 추이 그래프
예산(Budgets)	월별 예산 설정 및 초과 시 알림

청구 알림 설정 (강력 권장)

실습 시 예상치 못한 요금 발생을 방지하기 위해 청구 알림을 반드시 설정하자.

방법 1: 예산 알림 (AWS Budgets)

결제 대시보드 → 예산(Budgets) → 예산 생성
→ 비용 예산 → 월별 예산 금액 설정 (예: $5)
→ 알림 임계값 설정 (예: 예산의 80% 도달 시)
→ 이메일 수신자 입력 → 생성

방법 2: CloudWatch 결제 알림

CloudWatch → 경보 → 경보 생성
→ 지표: Billing → EstimatedCharges
→ 임계값: 예상 비용 > $1 (원하는 금액)
→ SNS 주제 생성 → 이메일 구독 확인
→ 경보 생성

두 방법 중 AWS Budgets가 더 직관적이고 설정이 간편하므로 초보자에게 권장한다.

Part 5: 전체 강의 학습 로드맵

Mermaid 다이어그램 4: 학습 로드맵

학습 단계별 요약

단계	챕터	핵심 학습 내용
기초	00~01	클라우드 컴퓨팅 개념, AWS 계정 생성, IAM으로 보안 체계 수립
컴퓨팅	02~04	EC2로 서버 생성/관리, AMI와 스냅샷으로 백업, ELB와 Auto Scaling으로 확장성 확보
스토리지/CDN	05~06	S3로 파일 저장, CloudFront로 전 세계에 빠르게 배포
데이터	07	RDS로 관계형 DB 운영, DynamoDB로 NoSQL 활용
배포/운영	08~09	Elastic Beanstalk로 간편 배포, CloudWatch로 모니터링
마무리	10	ElastiCache, Route 53, SES, SQS 추가 서비스 학습, 리소스 정리

핵심 정리

추가 서비스 한눈에 보기

서비스	핵심 역할	비유	실무 사용 사례
ElastiCache	인메모리 캐싱	책상 위에 꺼내놓은 자주 보는 책	DB 캐싱, 세션 스토어, 리더보드
Route 53	DNS 관리	인터넷 전화번호부	도메인 등록, DNS 라우팅, 헬스 체크
SES	대량 이메일 발송	대형 우편 발송 센터	마케팅 메일, 트랜잭션 메일
SQS	메시지 큐	놀이공원 줄서기	비동기 작업 처리, 마이크로서비스 간 통신

비용 관리 3대 원칙

실습 후 리소스 정리는 습관화한다. 매 실습 종료 시 생성한 리소스를 즉시 삭제한다.
AWS Billing Dashboard를 주기적으로 확인한다. 최소 주 1회 결제 대시보드에서 비용을 점검한다.
Free Tier 한도 초과 감지를 위한 청구 알림을 설정한다. AWS Budgets에서 월 $1~$5 예산 알림을 설정해두면 예상 외 과금을 즉시 감지할 수 있다.

리소스 정리 핵심 체크리스트

[ ] EC2 인스턴스 모두 종료(Terminate) 확인
[ ] EBS 스냅샷 삭제 확인
[ ] AMI 등록 취소 + 연관 스냅샷 삭제 확인
[ ] S3 버킷 비우기 + 삭제 확인
[ ] RDS 인스턴스 삭제 + 스냅샷 삭제 확인
[ ] DynamoDB 테이블 삭제 확인
[ ] CloudFront 비활성화 + 삭제 확인
[ ] CloudWatch 경보 삭제 확인
[ ] ELB 로드 밸런서 삭제 확인
[ ] Auto Scaling 그룹 삭제 확인
[ ] Elastic Beanstalk 환경 종료 + S3 수동 삭제 확인
[ ] Lightsail 인스턴스 삭제 확인
[ ] Elastic IP 릴리즈 확인
[ ] IAM 불필요한 사용자/그룹 삭제 확인
[ ] 모든 리전 리소스 확인 완료
[ ] 결제 대시보드에서 잔여 과금 항목 없음 확인

이것으로 AWS 클라우드 컴퓨팅 기초 학습을 마무리한다. 클라우드 서비스는 빠르게 발전하고 있으므로, 이 기초를 바탕으로 공식 문서와 실습을 통해 지속적으로 학습하는 것이 중요하다. 특히 AWS Well-Architected Framework의 5대 원칙(운영 우수성, 보안, 안정성, 성능 효율성, 비용 최적화)을 항상 염두에 두고 아키텍처를 설계하길 권장한다.

10. 추가 AWS 서비스 및 리소스 정리 ​

Part 1: 추가 AWS 서비스 소개 ​

1. ElastiCache (엘라스티캐시) ​

개념 ​

비유로 이해하기 ​

지원 엔진 ​

주요 사용 사례 ​

아키텍처 예시 ​

비용 고려사항 ​

2. Route 53 (라우트 53) ​

개념 ​

비유로 이해하기 ​

DNS 동작 원리 상세 ​

Route 53의 세 가지 핵심 기능 ​

DNS 레코드 타입 ​

비용 고려사항 ​

3. SES (Simple Email Service, 심플 이메일 서비스) ​

개념 ​

비유로 이해하기 ​

주요 사용 사례 ​

핵심 기능 상세 ​

비용 고려사항 ​

4. SQS (Simple Queue Service, 심플 큐 서비스) ​

개념 ​

비유로 이해하기 ​

큐의 두 가지 유형 ​

핵심 동작 방식 ​

Apache Kafka와의 비교 ​

실무 활용 예시 ​

비용 고려사항 ​

Part 2: AWS 서비스 전체 요약 맵 ​

Mermaid 다이어그램 1: AWS 서비스 전체 맵 ​

카테고리별 서비스 요약표 ​

Mermaid 다이어그램 2: 추가 서비스의 아키텍처 위치 ​

Part 3: 리소스 일괄 정리 체크리스트 ​

왜 리소스 정리가 중요한가? ​

삭제 순서의 원칙 ​

Mermaid 다이어그램 3: 리소스 정리 체크리스트 흐름도 ​

상세 삭제 가이드 ​

1단계: 컴퓨팅 리소스 정리 ​

2단계: 스토리지 및 데이터베이스 정리 ​

3단계: 네트워크 및 배포 정리 ​

4단계: 관리형 서비스 정리 ​

5단계: IP 및 보안 정리 ​

삭제 시 주의사항 요약 ​

Part 4: 비용 관리 실전 가이드 ​

Free Tier 한도 관리 ​

결제 대시보드 활용 ​

청구 알림 설정 (강력 권장) ​

Part 5: 전체 강의 학습 로드맵 ​

Mermaid 다이어그램 4: 학습 로드맵 ​

학습 단계별 요약 ​

핵심 정리 ​

추가 서비스 한눈에 보기 ​

비용 관리 3대 원칙 ​

리소스 정리 핵심 체크리스트 ​

10. 추가 AWS 서비스 및 리소스 정리

Part 1: 추가 AWS 서비스 소개

1. ElastiCache (엘라스티캐시)

개념

비유로 이해하기

지원 엔진

주요 사용 사례

아키텍처 예시

비용 고려사항

2. Route 53 (라우트 53)

개념

비유로 이해하기

DNS 동작 원리 상세

Route 53의 세 가지 핵심 기능

DNS 레코드 타입

비용 고려사항

3. SES (Simple Email Service, 심플 이메일 서비스)

개념

비유로 이해하기

주요 사용 사례

핵심 기능 상세

비용 고려사항

4. SQS (Simple Queue Service, 심플 큐 서비스)

개념

비유로 이해하기

큐의 두 가지 유형

핵심 동작 방식

Apache Kafka와의 비교

실무 활용 예시

비용 고려사항

Part 2: AWS 서비스 전체 요약 맵

Mermaid 다이어그램 1: AWS 서비스 전체 맵

카테고리별 서비스 요약표

Mermaid 다이어그램 2: 추가 서비스의 아키텍처 위치

Part 3: 리소스 일괄 정리 체크리스트

왜 리소스 정리가 중요한가?

삭제 순서의 원칙

Mermaid 다이어그램 3: 리소스 정리 체크리스트 흐름도

상세 삭제 가이드

1단계: 컴퓨팅 리소스 정리

2단계: 스토리지 및 데이터베이스 정리

3단계: 네트워크 및 배포 정리

4단계: 관리형 서비스 정리

5단계: IP 및 보안 정리

삭제 시 주의사항 요약

Part 4: 비용 관리 실전 가이드

Free Tier 한도 관리

결제 대시보드 활용

청구 알림 설정 (강력 권장)

Part 5: 전체 강의 학습 로드맵

Mermaid 다이어그램 4: 학습 로드맵

학습 단계별 요약

핵심 정리

추가 서비스 한눈에 보기

비용 관리 3대 원칙

리소스 정리 핵심 체크리스트