AWS 배포 정리

게시 2026/02/09

By Haram Jeong

21 분읽는 시간

AWS 배포 정리

이 글의 목적 — AWS 기반 백엔드 시스템을 배포할 때 자주 헷갈리는 용어, 컴포넌트 간 연관 관계, 그리고 배포 순서를 한 페이지 요약본으로 정리한다.
설계 결정을 내리기 전 빠르게 훑고 싶을 때, 또는 특정 개념이 흐릿해질 때마다 돌아오는 레퍼런스로 활용하자.

1. 시스템 품질 목표 — 무엇을 위해 설계하는가

AWS 컴포넌트를 선택하기 전에, “이 시스템이 무엇을 잘해야 하는가” 를 먼저 정의해야 한다.
목표가 달라지면 선택해야 하는 인프라 구성도 달라진다.

품질 속성	핵심 질문	주요 지표	달성 수단
신뢰성 (Reliability)	결과가 항상 정확한가?	MTBF, MTTR, 에러율	트랜잭션, 무결성 제약, 멱등성
가용성 (Availability)	요청을 항상 받을 수 있는가?	업타임 % (99.9 등)	이중화, Failover, 헬스 체크
성능 (Performance)	요청을 빠르게, 많이 처리하는가?	Latency, Throughput	캐싱, 비동기 처리, DB 최적화
확장성 (Scalability)	부하가 늘어도 성능이 유지되는가?	처리량 선형성	Stateless 설계, Auto Scaling

트레이드오프 주의: 가용성을 높이기 위한 Multi-AZ는 비용을 올리고, Sticky Session은 가용성을 방어하지만 확장성을 해친다. 목표를 명확히 정한 뒤 설계해야 한다.

2. AWS 배포 핵심 용어 사전

2-1. 네트워크 계층

VPC (Virtual Private Cloud)

AWS 클라우드 내에서 논리적으로 격리된 사용자 전용 가상 네트워크다.
모든 인프라 자원이 VPC 위에서 동작하며, 보안 설계의 첫 단계다.
하나의 AWS 계정에 여러 VPC를 만들 수 있고, VPC 안에서 IP 대역(CIDR)을 직접 정의한다.

Subnet (서브넷)

VPC를 더 세분화한 네트워크 구역으로, 역할에 따라 두 종류로 나뉜다.

종류	인터넷 접근	주 용도
Public Subnet	직접 가능 (Internet Gateway 연결)	ALB, NAT Gateway, Bastion Host
Private Subnet	불가 (NAT Gateway 경유로 outbound만 허용)	EC2 WAS, RDS, Redis

Internet Gateway (IGW)

VPC와 인터넷 사이의 양방향 게이트웨이다. Public Subnet의 리소스가 외부와 통신하려면 필수다.

NAT Gateway

Private Subnet 내 서버들이 외부로 나가는 요청(outbound)만 처리할 수 있게 하는 단방향 게이트웨이다.
외부에서 Private Subnet으로의 직접 접근은 여전히 차단된다.
주 사용처: EC2가 패키지·라이브러리를 다운로드할 때.

Security Group (보안 그룹)

EC2, RDS 등 각 리소스 앞단에 붙는 가상 방화벽이다.
Inbound/Outbound 규칙으로 허용할 포트와 IP 대역을 지정한다.
Stateful 방식: 허용된 inbound 요청의 응답은 자동으로 허용된다.

# 예시: EC2 보안 그룹 설정 원칙
Inbound: ALB의 보안 그룹에서 오는 8080 포트만 허용
Outbound: RDS 보안 그룹으로 나가는 5432 포트 허용

2-2. 컴퓨팅 계층

EC2 (Elastic Compute Cloud)

AWS가 제공하는 가상 서버 인스턴스다. 애플리케이션 서버(WAS)가 실제로 실행되는 곳이다.
인스턴스 타입(t3.medium, c5.large 등)으로 CPU·메모리 스펙을 선택한다.
AMI (Amazon Machine Image): 인스턴스를 시작할 때 사용하는 OS + 소프트웨어 스냅샷. Auto Scaling 시 새 인스턴스가 이 이미지를 기반으로 생성된다.

Auto Scaling Group (ASG)

부하 변동에 따라 EC2 인스턴스 수를 자동으로 조절하는 서비스다.
Scale-out: 인스턴스 추가 (부하 증가 시)
Scale-in: 인스턴스 제거 (부하 감소 시)
정책 예시: “평균 CPU 사용률이 60%를 넘으면 인스턴스 1개 추가”
ASG가 제대로 동작하려면 애플리케이션이 Stateless(무상태) 구조여야 한다.

Multi-AZ (다중 가용 구역)

물리적으로 독립된 데이터 센터(AZ) 여러 곳에 인프라를 분산 배치하는 전략이다.
한 AZ에 화재·정전·지진이 발생해도 다른 AZ의 서비스는 유지된다.
적용 대상: EC2(ASG에서 AZ 분산 설정), RDS(Primary-Standby 복제), ALB(기본 내장).

2-3. 트래픽 분산 계층

ALB (Application Load Balancer)

HTTP/HTTPS 트래픽을 지능적으로 라우팅하는 L7 로드 밸런서다.
Public Subnet에 위치하여 외부 요청을 받아, Private Subnet의 EC2 그룹(Target Group)으로 분산한다.
헬스 체크를 통해 비정상 인스턴스를 자동으로 트래픽 대상에서 제외한다.
HTTPS를 위해 ACM(AWS Certificate Manager) 인증서를 ALB에 직접 붙인다.

로드 밸런싱 알고리즘

알고리즘	설명	적합한 상황
Round Robin	순서대로 균등하게 분배	서버 성능이 균일할 때
Weighted Round Robin	가중치 비율로 분배	서버 스펙이 혼재할 때
Least Connections	현재 연결이 가장 적은 서버로	요청 처리 시간이 가변적일 때
Least Response Time	응답이 가장 빠른 서버로	실시간 성능 최적화가 필요할 때
IP Hash (Sticky Session)	동일 클라이언트 → 동일 서버 고정	Stateful 레거시 환경 (⚠️ 확장성 불리)

2-4. 데이터 계층

RDS (Relational Database Service)

관리형 관계형 데이터베이스 서비스로, 시스템의 최종 진실 원천(Source of Truth)이다.
신뢰성이 최우선이므로 가장 깊숙한 Private Subnet에 격리한다.
Multi-AZ 동기식 복제: Primary에 쓰기가 발생하면 Standby에도 동시에 복제. Primary 장애 시 자동 Failover.
Read Replica: 비동기 복제. 읽기 부하를 분산하여 성능 개선에 사용.

ElastiCache (Redis)

DB 앞단에서 반복 조회를 가로채 응답 속도를 끌어올리는 캐시 계층이다.
역할 1 — 성능: DB 쿼리 결과를 메모리에 캐싱하여 Latency 단축.
역할 2 — 확장성: EC2가 로컬 메모리 대신 Redis에 세션을 저장함으로써 Stateless 구조 유지.

SQS / Kafka (메시지 큐)

무조건 동기식으로 처리할 필요가 없는 무거운 로직을 비동기로 분리한다.
트래픽 급증 시 메시지를 큐에 쌓아두는 완충 장치(Buffer) 역할을 한다.
효과: 애플리케이션 서버와 DB가 동시에 과부하되는 상황을 방어 (가용성 + 신뢰성).

2-5. 보안·인증서

ACM (AWS Certificate Manager)

SSL/TLS 인증서를 무료로 발급·갱신해주는 서비스다. ALB에 붙여 HTTPS를 강제한다.

IAM (Identity and Access Management)

AWS 리소스에 대한 접근 권한을 정의하는 서비스다. EC2가 S3에 접근하거나, 배포 파이프라인이 ECR에 이미지를 올리는 권한 등을 제어한다.

3. 컴포넌트 연관 관계 — 용어들이 어떻게 연결되는가

3-1. 전체 아키텍처 흐름

[사용자 요청]
     │  HTTPS (443)
     ▼
[ALB] ← Public Subnet (AZ-a, AZ-b)
  │   └─ ACM 인증서 부착
  │   └─ 헬스 체크 수행
  │  HTTP (8080)
  ▼
[EC2 WAS - Target Group] ← Private Subnet (AZ-a, AZ-b)
  │   └─ Auto Scaling Group이 인스턴스 수 자동 조절
  │   └─ AMI / User Data로 부팅 시 소스코드 자동 실행
  ├─── [Redis (ElastiCache)]  ← 세션 저장 / 캐시
  ├─── [SQS / Kafka]          ← 비동기 작업 큐
  │
  ▼
[RDS (Primary)] ← Private Subnet 최심부
  └─ Multi-AZ 동기 복제 ──▶ [RDS (Standby)]

3-2. 품질 목표 ↔ 컴포넌트 매핑

품질 목표	책임 컴포넌트	핵심 원리
가용성	ALB, Multi-AZ, ASG, RDS Failover	이중화 + 헬스 체크 + 자동 교체
신뢰성	RDS (Multi-AZ 동기 복제), Security Group, SQS	데이터 정합성 + 외부 침입 차단 + 재처리 보장
성능	Redis, ALB 로드 밸런싱, Read Replica	캐싱 + 부하 분산 + 읽기 분리
확장성	ASG, Stateless EC2, Redis (세션 외부화)	수평 확장 가능 구조

3-3. Stateless가 핵심인 이유

# ❌ Stateful 구조 — 확장 불가
사용자 A의 세션 → EC2-1의 메모리에 저장
  └─ EC2-2가 A의 요청을 받으면 세션 없음 → 오류

# ✅ Stateless 구조 — 자유롭게 확장
사용자 A의 세션 → Redis에 저장
  └─ EC2-1이든 EC2-2든 Redis에서 꺼내면 됨
  └─ ASG가 새 인스턴스를 찍어내도 아무 문제 없음

4. 배포 단계별 체크리스트

아래 5단계를 순서대로 진행한다. 앞 단계의 기반이 없으면 다음 단계가 제대로 동작하지 않는다.

[1단계] 네트워크 구축
    └──▶ [2단계] 데이터 저장소 격리
              └──▶ [3단계] 서버 환경 구성 & ASG
                        └──▶ [4단계] ALB & HTTPS 설정
                                  └──▶ [5단계] 무중단 배포 & 헬스 체크

1단계 — 네트워크 인프라 구축 (VPC & Subnet)

목표: 모든 자원이 살아갈 격리된 네트워크를 선언한다.

VPC 생성 시 AZ를 최소 2개 이상 선택했는가?
Public Subnet / Private Subnet을 AZ별로 분리하여 생성했는가?
Public Subnet에 Internet Gateway 를 연결했는가?
Private Subnet에서 외부 라이브러리 다운로드를 위한 NAT Gateway 를 올바르게 구성했는가?
NAT Gateway는 Public Subnet에 위치하고, Private Subnet의 라우팅 테이블이 NAT를 가리키는가?

2단계 — 데이터 및 상태 저장소 격리 (RDS & Redis)

목표: 서버가 늘고 줄 때 데이터가 유실되거나 꼬이지 않도록 기반을 먼저 다진다.

RDS Multi-AZ 를 활성화했는가? (Primary - Standby 동기 복제)
RDS는 가장 깊은 Private Subnet 에 배치했는가?
RDS 보안 그룹은 EC2 보안 그룹에서 오는 트래픽만 허용하는가?
세션 기반 인증을 사용한다면, 서버 로컬 메모리가 아닌 Redis(ElastiCache) 에 세션을 저장하도록 구성했는가?
Redis 역시 Private Subnet에 격리되었는가?

3단계 — 애플리케이션 서버 환경 구성 (EC2 & ASG)

목표: 트래픽 변동에 유연하게 대응할 수 있는 컴퓨팅 자원을 준비한다.

EC2 인스턴스를 Private Subnet 에 배치했는가?
새 인스턴스 생성 시 소스코드가 자동 실행되도록 AMI 또는 User Data 스크립트를 구성했는가?
ASG에 Auto Scaling 정책 을 명확히 정의했는가?
- 예: 평균 CPU 60% 초과 시 Scale-out, 30% 미만 시 Scale-in
ASG의 최소(Min) / 희망(Desired) / 최대(Max) 인스턴스 수 를 설정했는가?
ASG가 여러 AZ에 걸쳐 인스턴스를 분산 배치하도록 설정했는가?

4단계 — 통합 관문 연결 및 보안 프로토콜 적용 (ALB & ACM)

목표: 사용자 요청이 안전하게 들어오고, 공평하게 분산되도록 관문을 세운다.

ALB를 Public Subnet 에, 2개 이상의 AZ 에 걸쳐 생성했는가?
ACM 에서 SSL/TLS 인증서를 발급받고 ALB HTTPS 리스너(443)에 적용했는가?
HTTP(80) 요청을 HTTPS(443)로 강제 리다이렉트 하는 리스너 규칙을 추가했는가?
ALB의 Target Group 에 EC2 ASG가 연결되어 있는가?
EC2의 보안 그룹 이 ALB 보안 그룹에서 오는 트래픽만 허용하도록 설정했는가? (직접 접근 차단)
ALB의 헬스 체크 경로 를 단순 200 OK가 아닌 DB·캐시 연결을 검증하는 엔드포인트로 설정했는가?

5단계 — 배포 전략 선택 및 안정성 장치 마련

목표: 새 버전 배포 시 다운타임을 0으로 만들고, 문제 발생 시 즉각 격리한다.

무중단 배포 전략 비교

전략	방법	장점	단점	선택 기준
롤링 (Rolling)	인스턴스를 한 대씩 순차 교체	추가 인프라 비용 없음	배포 중 구/신 버전 공존 (하위 호환 필수)	비용 민감, 하위 호환 가능할 때
블루-그린 (Blue-Green)	신버전 그룹 전체를 별도로 올린 뒤 ALB 스위칭	즉각 롤백 가능, 검증 후 전환	순간 2배 리소스 비용	안정성 최우선, 롤백 속도 중요할 때
카나리 (Canary)	일부 트래픽(5~10%)만 신버전으로 우선 분배	실 트래픽 검증 후 점진적 확대	모니터링 및 관리 복잡	실 환경에서의 안전한 검증이 필요할 때

헬스 체크 설계

  
// Spring Boot Actuator 활용 예시
// application.yml
management:
  endpoint:
    health:
      show-details: always  // DB, Redis 연결 상태 포함
  health:
    db:
      enabled: true
    redis:
      enabled: true

// 커스텀 헬스 체크 엔드포인트
@Component
public class CustomHealthIndicator implements HealthIndicator {
    @Override
    public Health health() {
        // DB 커넥션 확인
        // Redis 커넥션 확인
        return Health.up()
            .withDetail("db", "connected")
            .withDetail("redis", "connected")
            .build();
    }
}

헬스 체크 엔드포인트가 DB + Redis 연결 상태를 실제로 검증하는가?
ASG의 헬스 체크 유예 기간 (Grace Period) 을 설정하여 Warm-up 전 트래픽 유입을 막았는가?
- 예: Spring Boot 앱의 경우 60~120초 권장
배포 후 구버전 → 신버전 전환 중 데이터 스키마 호환성 을 확인했는가? (롤링 배포 시 특히 중요)
문제 발생 시 롤백 절차와 소요 시간을 사전에 확인했는가?

한눈에 보는 최종 요약

VPC (전체 울타리)
 ├── Public Subnet     : ALB, NAT Gateway
 └── Private Subnet    : EC2(WAS), RDS, Redis

요청 흐름
 사용자 → ALB(HTTPS) → EC2 WAS → Redis(캐시 hit?) → RDS

확장 장치
 ASG: CPU 60% 초과 → EC2 Scale-out
 Multi-AZ: AZ 장애 → 자동 Failover

배포 순서
 1. VPC + Subnet + IGW + NAT
 2. RDS Multi-AZ + Redis 격리
 3. EC2 AMI + ASG 정책
 4. ALB + ACM(HTTPS) + 보안 그룹 타이트닝
 5. 무중단 배포 전략 + 헬스 체크 엔드포인트

References

Backend, Infrastructure

AWS 배포 정리

목차

1. 시스템 품질 목표 — 무엇을 위해 설계하는가

2. AWS 배포 핵심 용어 사전

2-1. 네트워크 계층

VPC (Virtual Private Cloud)

Subnet (서브넷)

Internet Gateway (IGW)

NAT Gateway

Security Group (보안 그룹)

2-2. 컴퓨팅 계층

EC2 (Elastic Compute Cloud)

Auto Scaling Group (ASG)

Multi-AZ (다중 가용 구역)

2-3. 트래픽 분산 계층

ALB (Application Load Balancer)

로드 밸런싱 알고리즘

2-4. 데이터 계층

RDS (Relational Database Service)

ElastiCache (Redis)

SQS / Kafka (메시지 큐)

2-5. 보안·인증서

ACM (AWS Certificate Manager)

IAM (Identity and Access Management)

3. 컴포넌트 연관 관계 — 용어들이 어떻게 연결되는가

3-1. 전체 아키텍처 흐름

3-2. 품질 목표 ↔ 컴포넌트 매핑

3-3. Stateless가 핵심인 이유

4. 배포 단계별 체크리스트

1단계 — 네트워크 인프라 구축 (VPC & Subnet)

2단계 — 데이터 및 상태 저장소 격리 (RDS & Redis)

3단계 — 애플리케이션 서버 환경 구성 (EC2 & ASG)

4단계 — 통합 관문 연결 및 보안 프로토콜 적용 (ALB & ACM)

5단계 — 배포 전략 선택 및 안정성 장치 마련

무중단 배포 전략 비교

헬스 체크 설계

한눈에 보는 최종 요약

인기 태그