실전 웹서비스를 AWS에 처음부터 끝까지 구축합니다. Multi-AZ VPC 네트워크, ALB 로드밸런싱과 HTTPS 종료, ACM·Route 53 도메인 연결, ECS Fargate 오토스케일링, RDS, S3+CloudFront, IAM·Secrets 보안, CloudWatch 모니터링, CI/CD, Terraform 프로젝트 구조화까지 — 프로덕션 수준 아키텍처를 순서대로 정리했습니다. 이 가이드는 개념을 나열하기보다, 실제 프로젝트에서 판단해야 하는 순서대로 내용을 따라갈 수 있게 구성했습니다.
핵심 관점
인프라 / 운영
설치 명령을 외우기보다 트래픽, 런타임, 관측, 장애 대응이 어떤 순서로 이어지는지 파악합니다.
ALB 로드밸런싱 & HTTPS 종료ECS Fargate 오토스케일링RDS·Secrets 보안 설계Terraform 통합 IaC
구조 다이어그램
글로 읽은 내용을 머릿속에 오래 남기려면 먼저 흐름을 그림으로 잡는 편이 좋습니다. 아래 두 그림은 AWS를 학습할 때 계속 되돌아볼 수 있는 기준 지도입니다.
학습 흐름
다이어그램 렌더링 중…
아키텍처 관점
다이어그램 렌더링 중…
전체 아키텍처 한눈에 보기
AWS를 처음 펼칠 때는 세부 명령보다 큰 그림이 먼저입니다. 이 섹션에서는 앞으로 배울 개념들이 어떤 문제를 풀기 위해 등장했는지부터 잡아봅니다.
실전 웹서비스는 컨테이너 하나만 띄운다고 끝나지 않습니다. 도메인을 연결하고, HTTPS를 종료하고, 트래픽을 여러 인스턴스로 분산하고, DB를 안전하게 격리하고, 장애를 감지할 수 있어야 비로소 "프로덕션"이라 부를 수 있습니다. 이 가이드는 아래 아키텍처를 구성 요소 하나씩, 실제로 만들어가는 순서로 이어집니다.
다이어그램 렌더링 중…
구성 요소
역할
배치 위치
Route 53
DNS — 도메인을 ALB에 Alias로 연결
-
ACM
TLS 인증서 무료 발급 및 자동 갱신
-
ALB
L7 로드밸런싱, HTTPS 종료, 경로/호스트 기반 라우팅
Public Subnet (Multi-AZ)
ECS Fargate
서버리스 컨테이너 실행
Private Subnet (Multi-AZ)
RDS
관리형 관계형 DB, Multi-AZ 자동 페일오버
Private Subnet
S3 + CloudFront
정적 자산 저장 + 글로벌 CDN 배포
-
Secrets Manager
DB 비밀번호·API 키 보안 관리 및 런타임 주입
-
CloudWatch
로그 수집, 메트릭, 알람
-
VPC 네트워크 설계 (Multi-AZ)
여기서는 VPC 네트워크 설계 (Multi-AZ)을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
프로덕션 서비스는 반드시 최소 2개의 가용 영역(AZ)에 걸쳐 배치해야 합니다. 하나의 AZ에 장애가 발생해도 나머지 AZ가 트래픽을 계속 받을 수 있어야 하기 때문입니다. ALB와 NAT Gateway는 퍼블릭 서브넷에, ECS Task와 RDS는 인터넷에서 직접 접근할 수 없는 프라이빗 서브넷에 배치합니다.
여기서는 ACM 인증서 & Route 53 도메인을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
ACM(AWS Certificate Manager)으로 무료 TLS 인증서를 발급받아 위에서 만든 HTTPS 리스너에 연결하고, Route 53 Alias 레코드로 도메인을 ALB에 직접 연결합니다. Alias 레코드는 CNAME과 달리 루트 도메인(example.com)에도 사용할 수 있고 조회 비용이 없습니다.
acm-route53.tfHCL
resource "aws_acm_certificate" "cert" { domain_name = "example.com" subject_alternative_names = ["*.example.com"] validation_method = "DNS" lifecycle { create_before_destroy = true }}resource "aws_route53_record" "cert_validation" { for_each = { for dvo in aws_acm_certificate.cert.domain_validation_options : dvo.domain_name => { name = dvo.resource_record_name type = dvo.resource_record_type value = dvo.resource_record_value } } zone_id = aws_route53_zone.main.zone_id name = each.value.name type = each.value.type records = [each.value.value] ttl = 60}resource "aws_acm_certificate_validation" "cert" { certificate_arn = aws_acm_certificate.cert.arn validation_record_fqdns = [for r in aws_route53_record.cert_validation : r.fqdn]}resource "aws_route53_record" "alb_alias" { zone_id = aws_route53_zone.main.zone_id name = "example.com" type = "A" alias { name = aws_lb.main.dns_name zone_id = aws_lb.main.zone_id evaluate_target_health = true }}
ECS Fargate 배포 & ALB 연동
여기서는 ECS Fargate 배포 & ALB 연동을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
Task Definition에 컨테이너 이미지·CPU/메모리·로그 설정을 지정하고, ECS Service의 load_balancer 블록으로 앞서 만든 Target Group에 연결합니다. 컨테이너가 쓰는 역할이 두 가지(Execution Role, Task Role)로 나뉘는데, 자세한 차이는 뒤의 IAM 섹션에서 다룹니다.
여기서는 IAM 역할 & 보안 정책을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
ECS에서는 Execution Role과 Task Role을 혼동하기 쉽습니다. Execution Role은 ECS 에이전트가 ECR에서 이미지를 받아오고 로그를 CloudWatch로 보내기 위한 역할이고, Task Role은 컨테이너 안에서 실행 중인 애플리케이션 코드가 S3·Secrets Manager 같은 다른 AWS 서비스를 호출할 때 쓰는 역할입니다.
iam-execution-role.tfHCL
resource "aws_iam_role" "ecs_execution" { name = "ecsTaskExecutionRole" assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{ Effect = "Allow" Principal = { Service = "ecs-tasks.amazonaws.com" } Action = "sts:AssumeRole" }] })}resource "aws_iam_role_policy_attachment" "ecs_execution" { role = aws_iam_role.ecs_execution.name policy_arn = "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"}
s3:GetObject, secretsmanager:GetSecretValue(코드에서 직접 호출) 등
Secrets Manager & 환경변수 관리
여기서는 Secrets Manager & 환경변수 관리을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
DB 비밀번호, 외부 API 키 같은 민감 정보는 이미지나 환경변수 파일에 하드코딩하지 말고 Secrets Manager(또는 로테이션이 필요 없다면 Parameter Store SecureString)에 저장한 뒤, Task Definition의 secrets 필드로 런타임에 주입합니다.
여기서는 CI/CD (ECR + GitHub Actions)을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
컨테이너 이미지를 ECR에 푸시하고 ECS 서비스를 새 이미지로 갱신하는 흐름을 GitHub Actions로 자동화합니다. 이미지 태그를 커밋 SHA로 고정해두면 ECS가 정확히 어떤 빌드를 실행 중인지 항상 추적할 수 있고, 서비스 갱신 후 배포 상태가 안정될 때까지 기다리는 단계를 넣어야 실패한 배포를 자동으로 감지할 수 있습니다.
여기서는 Terraform 프로젝트 구조화을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
앞서 다룬 리소스(VPC, ALB, ECS, RDS, ...)를 실제 팀에서 운영할 때는 파일 하나에 다 몰아넣지 않고 모듈 단위로 쪼개고, 원격 상태(remote state)를 S3 + DynamoDB 락으로 관리해 여러 사람이 동시에 안전하게 작업할 수 있도록 합니다.
여기서는 프로덕션 체크리스트을 실제 코드와 함께 확인합니다. 예제를 그대로 따라 하기보다, 입력과 출력, 그리고 바뀌기 쉬운 부분이 어디인지 보면서 읽어보세요.
✅
배포 전 최종 점검
• 보안 그룹: ALB만 0.0.0.0/0에 노출하고, ECS·RDS는 내부 보안그룹 참조로만 접근 허용 • WAF: ALB에 AWS WAF를 연결해 SQL Injection·XSS·Rate Limiting 기본 규칙 적용 • ALB 액세스 로그: S3 저장을 활성화해 장애·공격 발생 시 사후 분석이 가능하도록 준비 • Multi-AZ: ALB·ECS·RDS 모두 최소 2개 AZ에 분산 배치 • 백업 & 삭제 방지: RDS 자동 백업 활성화, deletion_protection = true • 비용 알람: AWS Budgets로 예상치 못한 과금을 조기에 감지 • 태그 전략: Environment/Service/Owner 태그를 전 리소스에 일관 적용 (비용 분석·자동화 스크립트에 필수)