10CHAPTER 10 · 실전·심화

종합 실습

지금까지 배운 서비스를 하나의 운영 가능한 웹 아키텍처로 연결하기

실전·심화실습 리소스 과금 주의삭제 계획 먼저

VPC · ALB · EC2 · RDS · S3 · CloudFront · Route 53 · ACM · CloudWatch · CI/CD · Secrets Manager

CHAPTER INFO
🏗3-Tier + CDN 통합 구성
🔒Private EC2 · Private RDS
💰생성 전 Cost 확인
🔗이전: CH09 CI/CD 자동화
🔗다음: CH11 비용 관리

실습 목표 — “서비스를 만들었다”보다 “운영 가능한가”까지 확인

이번 실습의 목표는 리소스를 많이 만드는 것이 아닙니다. 사용자 요청이 DNS와 CDN을 지나 애플리케이션과 데이터베이스까지 도달하고, 문제가 생겼을 때 모니터링으로 원인을 찾고, 변경사항을 반복 가능한 방식으로 배포할 수 있는 구조를 만드는 것입니다.

👤
User
→
🌐
Route 53
→
⚡
CloudFront
→
⚖️
ALB
→
🖥
Private EC2
→
🗄
Private RDS
🧭
실습 성공 기준을 먼저 정합니다.
HTTPS 접속, 정적 콘텐츠 응답, API Health, DB 연결, CloudWatch 지표·로그 확인, 배포 후 Health 확인, 마지막 전체 정리까지 완료돼야 종합 실습을 끝낸 것으로 봅니다.

목표 아키텍처 — Public은 최소화하고 Application·DB는 Private에 둔다

계층리소스위치접근 원칙
EdgeRoute 53 · CloudFront · ACMAWS ManagedHTTPS 사용자 요청 수신
StaticS3Private BucketCloudFront OAC만 Read 허용
WebALBPublic Subnet 2개 이상HTTPS Listener, EC2 Target
AppEC2Private SubnetALB Security Group에서 App Port 허용
DBRDSPrivate DB SubnetEC2 Security Group에서 DB Port 허용
OpsCloudWatch · SSMManaged Service모니터링·운영 접속
⚠️
NAT Gateway는 “필수”가 아닙니다.
Private EC2가 인터넷으로 나가야 하는 요구가 있으면 NAT Gateway를 사용할 수 있지만 시간·데이터 처리 비용이 발생합니다. 실습 목적과 필요한 AWS Service 접근을 검토해 VPC Endpoint 또는 다른 구조로 대체 가능한지 먼저 확인합니다.

생성 전에 비용 경계선부터 정한다

AWS 가격은 Region, Instance Type, 사용량, 시간, 데이터 전송량에 따라 바뀝니다. 그래서 실습 문서에 고정 달러 금액을 박아두기보다 어떤 리소스가 시간당 또는 사용량 기준으로 계속 비용을 만드는지를 이해하는 것이 중요합니다.

리소스비용이 생기는 대표 이유실습 전 결정
ALB가동 시간·처리 용량실습 종료 후 삭제 여부
EC2 · EBSCompute 시간·Volume종료와 Volume 잔존 확인
RDSDB Instance·Storage·Backup실습 종료 후 Snapshot 필요 여부
NAT Gateway가동 시간·처리 데이터정말 필요한지 먼저 결정
CloudFront · S3요청·저장·전송량 등불필요 객체와 Distribution 정리
CloudWatchLog 수집·보관·조회, Custom Metric 등Retention과 수집 범위 결정
💰
실습 시작 전에 Cost Explorer와 AWS Pricing Calculator를 확인합니다.
무료 사용 가능 여부나 실제 예상 금액은 계정·시점·Region마다 다를 수 있습니다. “몇 달러 정도겠지”라는 고정 숫자보다 현재 가격과 계정 혜택을 기준으로 판단합니다.

실습 1 — VPC와 Security Group

순서작업검증
1VPC CIDR 계획향후 다른 VPC와 겹치지 않는 범위인지 확인
22개 AZ에 Public Subnet 구성ALB가 두 AZ에 배치 가능
32개 AZ에 App/DB용 Private Subnet 구성Public IP 자동 할당 비활성 확인
4IGW와 Public Route 설정Public Route의 기본 경로가 IGW
5ALB·App·DB Security Group 분리DB가 인터넷 전체에 열리지 않음
ALB SG
사용자에게 필요한 HTTPS를 허용합니다.
App SG
Application Port는 ALB SG를 Source로 제한합니다.
DB SG
DB Port는 App SG를 Source로 제한합니다.
관리 접속
가능하면 SSH 22를 인터넷에 열지 않고 Session Manager를 사용합니다.

실습 2 — RDS · EC2 · ALB 백엔드

학습용 환경도 운영 기본 원칙은 유지합니다. Credential을 Repository에 넣지 않고, Database는 Public Access를 비활성화하고, Application은 ALB를 통해서만 접근되게 구성합니다.

순서작업완료 조건
1RDS Subnet Group과 Private RDS 생성Publicly Accessible 비활성
2DB Credential을 Secrets Manager에 저장Source Code에 Secret 없음
3Private EC2와 IAM Role 구성필요 최소 AWS 권한만 부여
4Session Manager로 EC2 운영 접속 확인SSH Inbound 없이 접속 가능
5Spring Boot 기동과 DB 연결 확인Health Endpoint 정상
6ALB Target Group 등록Target Health = Healthy
7ACM + HTTPS Listener 구성TLS 접속 정상
🗄
백업을 0으로 만드는 것을 실습 기본값으로 고정하지 않습니다.
학습 환경이라도 데이터가 필요하면 Automated Backup과 Final Snapshot 정책을 목적에 맞게 결정합니다. 삭제 시 Snapshot을 남길지 여부도 삭제 직전에 다시 확인합니다.

실습 3 — Private S3 + CloudFront + Route 53

순서작업완료 조건
1S3 Bucket 생성, Block Public Access 유지인터넷 직접 공개 안 됨
2Frontend Build Artifact 업로드필요 파일만 배포
3CloudFront Distribution 생성S3 Bucket Origin + OAC 사용
4CloudFront Viewer용 ACM 인증서 연결인증서가 us-east-1에 존재
5Route 53 Alias 연결사용자 Domain → CloudFront
6Frontend에서 API 호출 확인CORS·HTTPS·API 응답 정상
💡
한 Domain 아래에서 /api/*를 ALB Origin으로 보내는 설계도 가능합니다.
CloudFront Behavior를 이용하면 정적 콘텐츠와 API Origin을 하나의 사용자 Domain 아래에 둘 수 있습니다. 다만 Cache Policy와 허용 Method를 API 특성에 맞게 분리해야 합니다.

실습 4 — CloudWatch 운영 관측

임계값은 예시 숫자를 그대로 복사하지 말고 실습 중 정상 상태의 Baseline을 먼저 확인한 뒤 정합니다.

계층먼저 볼 지표이상 시 다음 확인
CloudFrontError Rate · RequestOrigin·Cache·Certificate
ALBTarget 5XX · Response TimeTarget Health·App Log
EC2CPU · Status CheckAgent Memory·Disk·App Log
RDSConnections · CPU · FreeStorageQuery·Connection Pool·Storage
📊
장애 연습도 실습에 포함합니다.
Application Process를 의도적으로 중지하는 등 비파괴적 시나리오에서 ALB Target Health와 Alarm, Logs가 어떻게 변하는지 관찰하면 서비스 간 관계를 더 잘 이해할 수 있습니다.

실습 5 — CI/CD 연결과 Release Gate

📦
GitHub Source
→
🧪
CodeBuild Test
→
🚦
Release Gate
→
🚀
CodeDeploy
→
❤️
Health Verify
검증PASS 기준
Unit TestTest 실패 0건
Build배포 Artifact 생성
DeployLifecycle Hook 성공
Target Health새 Revision Target Healthy
Smoke TestHealth와 핵심 API 정상
CloudWatch오류율·지연의 비정상 증가 없음

정리 — 삭제 순서를 외우기보다 “의존성”을 끊는다

리소스 삭제는 환경에 따라 의존성이 달라질 수 있으므로 하나의 고정 순서를 절대 규칙처럼 사용하지 않습니다. 먼저 사용 중인 연결을 해제하고, 삭제가 막히면 어떤 리소스가 참조 중인지 확인합니다.

범주정리 대상확인 포인트
배포Pipeline · Build · Deploy 관련 리소스Artifact Bucket·Role 잔존 여부
EdgeCloudFront · Route 53 RecordDistribution Disable/Delete 완료 여부
ComputeALB · Target Group · EC2Target·ENI·EBS 잔존 여부
DatabaseRDSFinal Snapshot·Automated Backup 결정
NetworkNAT Gateway · EIP · Endpoint · VPCENI와 참조 Security Group 확인
StorageS3 · Snapshot · Log필요 데이터 보존 후 삭제
ObservabilityAlarm · Dashboard · Log GroupRetention·장기 보존 필요 여부
🗑
삭제 전에 데이터와 Snapshot 필요성을 다시 확인합니다.
RDS·S3·Snapshot처럼 복구에 필요한 데이터를 지우는 작업은 비용 정리와 데이터 보존을 함께 판단해야 합니다. 학습 문서의 예시보다 실제 계정의 목적을 우선합니다.
📌 CH10 종합 실습 완료 기준
NetworkPublic ALB · Private App · Private DB 경계가 명확함
FrontendPrivate S3 + CloudFront OAC + HTTPS Domain
BackendALB Health, EC2 App, Private RDS 연결 정상
OperationsCloudWatch Metrics·Logs·Alarm으로 상태 확인 가능
ReleaseTest→Deploy→Health Verify가 반복 가능
Cleanup불필요 리소스와 잔존 비용을 확인하고 정리