DetourCut
← 프로젝트 패턴

AWS WIKI / PROJECT

기본 3-Tier 웹 시스템

공개 웹 서비스 · 관계형 데이터베이스

프로젝트 이해

전제조건과 공정별 산출물·완료 조건

DNS부터 애플리케이션 서버와 데이터베이스까지 이어지는 기본 웹 아키텍처입니다.

프로젝트 전체 공정

이 패턴의 중점 단계

설계

일반 인프라 개념과 AWS 구현의 선택

일반 인프라 관점

일반 개념AWS / 도구 대응
  1. 사용자
    사용자 / 웹 브라우저
  2. DNS
    Route 53
  3. Load Balancer
    ALB
  4. Application Server
    EC2
  5. Relational Database
    RDS

DNS는 주소 조회입니다. IAM은 AWS 작업 권한을 담당하며, 네트워크 접근 제어는 보안 그룹 등으로 별도 설계합니다.

AWS에서 구현하면

기준 그림: EC2 2대 / 2개 AZ · Single-AZ RDS
  1. 사용자 / 웹 브라우저웹사이트 접속

DNS는 주소 조회만 · 실제 요청: 사용자 → ALB → EC2 → RDS

전체 구성을 받쳐주는 기반

  • 정상 서버로 요청 분산
  • 앱·DB 접근 경계 분리
  • DB 관리 부담 감소

주의서버 이중화 ≠ DB 고가용성

상황별 구성 선택

학습 시나리오 선택

추천 구성

  • ALB + 서로 다른 AZ의 EC2 2대
  • DB 장애 요구에 맞춰 RDS Multi-AZ 검토

달라지는 점

  • Target Health와 알람으로 정상 대상 확인
  • 서버 증설 전 세션·데이터 공유 검토

주의

기준 설정값의 RDS는 Single-AZ입니다. 앱 서버 두 대만으로 DB 장애까지 대응하지는 않습니다.

왜 이 구성을 선택했을까?

요청 분산ALB + EC2 2대

하나의 진입점이 정상 서버로 요청을 분산합니다. 서버 한 대가 비정상일 때도 다른 정상 대상이 새 요청을 처리할 수 있습니다.

서버 장애 분리서로 다른 AZ

애플리케이션 서버를 두 가용 영역에 나눠 배치합니다. 이 선택만으로 DB 고가용성이나 무중단이 보장되지는 않습니다.

DB 관리 부담 ↓관리형 RDS

DB 서버의 유지 관리와 백업 기능을 활용합니다. 백업 보존·복구 테스트와 고가용성 선택은 여전히 운영자의 책임입니다.

이름으로 접속Route 53

서비스 진입점을 도메인 이름으로 연결합니다. Route 53은 웹 요청을 중계하지 않으며, 외부 DNS로 대체할 수도 있습니다.

상태를 관찰지표 + 알람

서버·로드 밸런서·DB 지표로 상태를 확인합니다. 알람 수신과 앱 로그 전송은 따로 설정해야 합니다.

구조 이해 자세히 보기역할 · 필요 이유 · 연결 · 대안

Route 53은 DNS 주소 조회를 담당합니다. 실제 HTTP 요청과 응답은 Route 53을 통과하지 않습니다.

이 프로젝트에 필요한 것

  • 웹 도메인
  • 애플리케이션 실행 환경
  • 관계형 데이터베이스
  • 기본 모니터링

Route 53

역할
도메인을 서비스 진입 주소로 연결합니다.
왜 필요한가
사용자가 변하기 쉬운 IP 대신 example.com 같은 이름으로 접속할 수 있습니다.
어떻게 연결되나
사용자 DNS 조회 → Route 53의 ALB 별칭 레코드 → ALB 주소 반환. 이후 브라우저가 ALB로 직접 요청합니다.
없으면 / 대안
사용자 지정 도메인이 필요 없다면 ALB DNS 이름으로 접근할 수 있습니다. HTTPS 인증서의 호스트 이름도 함께 고려해야 합니다.
공식 문서 ↗

ALB

역할
웹 요청을 받고 정상 애플리케이션 서버로 분산합니다.
왜 필요한가
서버 두 대에 공통 진입점을 제공하고, 상태 검사에 실패한 서버를 요청 대상에서 제외할 수 있습니다.
어떻게 연결되나
사용자 → ALB HTTPS 443 리스너 → 대상 그룹 → EC2의 애플리케이션 포트. 응답은 반대 방향으로 돌아옵니다.
없으면 / 대안
서버에 직접 접속하면 공통 진입점, 부하 분산, 상태 기반 대상 선택을 다른 방식으로 마련해야 합니다.
공식 문서 ↗

EC2

역할
웹 애플리케이션 코드와 업무 로직을 실행합니다.
왜 필요한가
요청을 해석하고 데이터 조회·저장 결과를 화면이나 API 응답으로 만듭니다.
어떻게 연결되나
ALB → EC2 애플리케이션 → RDS. EC2 보안 그룹은 ALB 보안 그룹에서 오는 애플리케이션 포트만 허용합니다.
없으면 / 대안
애플리케이션 실행 계층은 여전히 필요합니다. EC2 대신 컨테이너나 서버리스 실행 환경을 선택할 수 있습니다.

RDS

역할
애플리케이션의 관계형 데이터를 저장합니다.
왜 필요한가
서버를 교체해도 데이터가 남고, 관리형 데이터베이스의 백업·유지 관리 기능을 활용할 수 있습니다.
어떻게 연결되나
EC2 → RDS 엔드포인트의 MySQL 3306. DB 보안 그룹은 EC2 보안 그룹에서 오는 연결만 허용합니다.
없으면 / 대안
영속 데이터가 없다면 생략할 수 있습니다. 다른 DB를 쓰거나 직접 운영하면 백업과 장애 대응도 별도로 설계해야 합니다.
공식 문서 ↗

VPC

역할
리소스의 네트워크 배치와 통신 경계를 만듭니다.
왜 필요한가
인터넷 진입점과 애플리케이션·DB를 분리하고, 필요한 통신만 허용하기 위해 사용합니다.
어떻게 연결되나
Public Subnet의 ALB → Private App Subnet의 EC2 → Private DB Subnet의 RDS. 라우팅과 보안 그룹이 각 연결을 제어합니다.
없으면 / 대안
EC2·ALB·이 RDS 구성에는 VPC가 필요합니다. 직접 만든 VPC 대신 기본 VPC를 쓸 수 있지만 공개 범위를 다시 확인해야 합니다.

IAM

역할
누가 어떤 AWS 작업을 할 수 있는지 정합니다.
왜 필요한가
운영자와 애플리케이션에 필요한 최소 권한만 부여하고, 장기 접근 키를 서버에 넣는 일을 줄입니다.
어떻게 연결되나
운영자는 IAM 권한으로 리소스를 관리하고, EC2 역할은 로그 전송 등 AWS API 호출에 사용합니다. 네트워크 통신 허용은 보안 그룹의 역할입니다.
없으면 / 대안
AWS 리소스를 관리하려면 권한 체계가 필요합니다. EC2 역할을 생략하면 해당 AWS API 접근을 별도로 해결해야 합니다.

기술 구성

핵심·검토·추가·대체 요소의 역할

구성 요소의 성격

핵심 구성

이 패턴을 설명하는 중심 요소

  • ALBHTTPS / 요청 분산
  • EC2앱 실행 · 2대
  • RDS데이터 저장

일반적으로 함께 검토

Production 설계에서 함께 고려

  • Route 53도메인 이름으로 공개 서비스를 연결할 때
  • VPC리소스 배치와 통신 경계를 설계
  • IAM운영자와 서비스의 AWS 작업 권한 검토
  • CloudWatch상태 확인·로그 수집·알람 수신 검토

요구사항에 따라 추가

상황에 맞춰 선택할 요소

  • Auto Scaling트래픽 변화에 맞춰 서버 수를 조정할 때
  • AWS WAF웹 요청에 대한 공격 방어 규칙이 필요할 때

대체 가능다른 선택과 주의점

가능EC2 두 대로 앱 분산정상 대상이 새 요청을 처리

조건서로 다른 AZ, 정상 Health Check, 충분한 잔여 용량

추가 책임 / 확인

  • 애플리케이션 세션과 파일을 서버 간 공유할지 검토
  • 진행 중 요청 실패와 탐지 지연은 별도 대응
EC2
대체 가능EC2 → 온프레미스 서버기존 앱 서버를 유지할 수 있음

조건VPN / Direct Connect 연결, 허용 사설 IP, ALB IP 대상 구성

추가 책임 / 확인

  • OS 패치와 서버 장애 대응
  • 백업과 물리 / 가상 인프라 관리
  • 회선·라우팅·암호화와 상태 검사
EC2
대체 가능Route 53 → 외부 DNS다른 DNS도 도메인 연결 가능

조건루트 도메인 연결 방식과 ALB DNS 이름 처리 확인

추가 책임 / 확인

  • DNS 레코드와 인증서 이름 일치 확인
  • ALB IP를 고정값처럼 직접 등록하지 않기
Route 53
대체 가능RDS → 직접 운영 DBEC2 또는 온프레 DB 사용 가능

조건네트워크 연결·DB 접근 제어·복구 계획 필요

추가 책임 / 확인

  • DB 패치·백업과 복구 검증
  • 고가용성·장애 조치 직접 설계
  • DB 서버와 스토리지 운영
RDS
비추천앱·DB 포트 전체 공개0.0.0.0/0로 무분별하게 열지 않기

조건공개 진입은 ALB, 앱·DB는 필요한 보안 그룹만 허용

VPC
주의Single-AZ RDS서버 두 대여도 DB 장애는 별개

조건DB 장애 요구가 높다면 Multi-AZ와 복구 정책 검토

RDS

공정 × 기술영역

확인 → 설계 → 검증 → 운영
  • 핵심
  • 일반적 검토
  • 조건부
  • 해당 없음
프로젝트 공정별 기술영역 검토 수준
기술영역01요구사항 정리02기본설계03상세설계04구축05테스트06이행 / 전환07운영08인수인계 / 개선

구축 · 테스트 · 이행

구축 설정과 검증·전환·복구 결과

실제 설정과 동작

실제 설정값 보기기준 구성 · 네트워크 · 접근 제어

시나리오별 참고안과 별개인 학습용 기준 설정입니다. 정답 구성이나 실제 배포 절차를 뜻하지 않습니다.

가정한 상황

  • 공개 도메인을 사용하는 소규모 웹 애플리케이션
  • 관계형 DB가 필요하고 애플리케이션 서버는 2대
  • 서로 다른 가용 영역에 서버를 배치하고, 한 대의 장애에도 요청 처리 유지
  • DB는 Single-AZ 학습 구성으로 시작: DB 장애 자동 복구까지 보장하는 예시는 아님

VPC

CIDR
10.0.0.0/16
인터넷 진입
Internet Gateway 연결; Public Subnet 기본 경로 0.0.0.0/0 → IGW

서브넷 / 가용 영역

Public (AZ A / B)
10.0.1.0/24 / 10.0.2.0/24 — ALB
Private App (AZ A / B)
10.0.11.0/24 / 10.0.12.0/24 — EC2
Private DB (AZ A / B)
10.0.21.0/24 / 10.0.22.0/24 — RDS DB subnet group
외부 통신
Private Subnet에 IGW 직접 경로 없음. 패키지 설치·운영 API 접근이 필요하면 NAT 또는 VPC Endpoint를 별도 설계

ALB

배치
Internet-facing; 두 Public Subnet
Listener
HTTPS 443; example.com에 유효한 ACM 인증서 필요
Target / Health Check
EC2 2대, HTTP 8080; GET /health → 200
보안 그룹
인터넷 → 443 허용; EC2 앱 포트로 전달

EC2

서버
2대; 서로 다른 Private App Subnet; 공인 IP 없음
앱 / 권한
HTTP 8080; /health 구현; 필요한 AWS API만 허용하는 IAM 역할
보안 그룹
ALB 보안 그룹 → 8080만 허용; DB 3306으로 연결

RDS

엔진 / 배치
MySQL; Single-AZ; Private DB subnet group; Public access 꺼짐
보안 그룹
EC2 보안 그룹 → MySQL 3306만 허용
장애 대응 범위
두 AZ의 subnet group만으로 Multi-AZ가 되지는 않음. DB 자동 장애 조치는 Multi-AZ 구성을 별도 검토

Route 53

DNS 레코드
example.com A (Alias) → ALB; example.com은 설명용 도메인
정상 / 장애 동작 보기조건 → AWS 동작 → 결과

정상 웹 요청

조건 / 입력사용자가 https://example.com에 접속하고 서버와 DB가 정상 상태

AWS 동작

  1. 브라우저의 DNS 조회에 Route 53이 ALB 주소를 반환
  2. 브라우저가 ALB의 HTTPS 443으로 요청; ALB가 인증서를 사용해 TLS 종료
  3. ALB가 정상 EC2 중 하나의 HTTP 8080으로 요청 전달
  4. EC2 애플리케이션이 RDS MySQL에서 필요한 데이터 조회
  5. EC2가 응답을 만들고 ALB를 거쳐 브라우저로 반환

결과사용자는 도메인 하나로 웹 서비스를 이용하고, EC2·RDS에 직접 접속하지 않습니다.

EC2 한 대의 상태 검사 실패

조건 / 입력한 EC2가 연속 상태 검사 실패 기준에 도달하고 다른 EC2는 정상

AWS 동작

  1. ALB가 실패한 대상을 unhealthy로 판정
  2. 실패한 대상을 새 요청의 전달 대상에서 제외
  3. 다른 정상 EC2가 새 요청을 계속 처리

결과서버 한 대의 장애에도 새 요청 처리를 이어갈 수 있습니다. 탐지 전 요청이나 진행 중 요청은 실패할 수 있고, 남은 서버의 처리 용량도 확인해야 합니다. 모든 대상이 비정상이면 ALB는 fail-open으로 비정상 대상에도 요청을 보낼 수 있습니다.

이 구성으로 이해할 수 있는 것

  • 공개 진입은 ALB에 집중하고 애플리케이션과 DB는 private 영역에 분리
  • 서버 한 대 장애 시 정상 대상이 요청을 이어받는 구조 이해
  • IAM은 AWS 권한, 보안 그룹은 네트워크 접근, CloudWatch는 관찰을 담당
  • 실제 운영 전에는 비용, 인증서, DB 고가용성, 백업과 복구, 외부 통신 경로를 추가 검토

운영

서버 관리·관찰·백업과 운영 책임

운영 공정 · 절차와 산출물 →인수인계 · 개선 →운영 비용 확인 →
운영 시 주의상태 / 백업 / 복구
  • ALB Target Health와 앱의 /health 응답 확인
  • CloudWatch Alarm과 알림 수신 경로 점검
  • RDS 백업 보존 정책과 실제 복구 테스트 확인
운영 역할 자세히 보기역할 · 필요 이유 · 연결 · 대안

CloudWatch

역할
리소스 상태와 오류 징후를 지표·로그·알람으로 확인합니다.
왜 필요한가
사용자가 문제를 알려주기 전에 CPU 상승, 대상 오류, DB 연결 증가 등을 발견하기 위해 사용합니다.
어떻게 연결되나
EC2·ALB·RDS 기본 지표 → CloudWatch 알람. EC2 앱 로그는 에이전트나 별도 로그 전송 설정이 필요합니다.
없으면 / 대안
요청 처리는 계속되지만 장애 원인을 파악하기 어려워집니다. 다른 모니터링 도구로 관찰 기능을 대신 마련할 수 있습니다.
운영 설정값 보기관리 · 지표 · 로그 · 알람

시나리오별 참고안과 별개인 학습용 기준 설정입니다. 정답 구성이나 실제 배포 절차를 뜻하지 않습니다.

CloudWatch

기본 관찰
EC2 CPUUtilization; ALB HealthyHostCount / HTTPCode_Target_5XX_Count; RDS CPUUtilization / DatabaseConnections
알람 / 로그
HealthyHostCount < 2 등 서비스 목표에 맞춘 알람; 앱 로그 수집은 별도 설정

실무 판단

요금·변경·중단·데이터·보안 위험

실무 판단

기준 프로젝트 · 요구사항에 따라 달라짐
예상 비용$96.67 / 월학습 예시 · NAT·전송·로그 등 합계 밖

Asia Pacific (Tokyo) / ap-northeast-1 · 단가 확인 2026-10-05 · USD

시간 약
$0.13
하루 약
$3.18
월 약
$96.67
연 약
$1,160.05

고정 조건의 학습용 비교값입니다. 실제 요금과 다를 수 있으며 모든 비용을 포함하지 않습니다.

계산에 포함한 항목의 월 비용 비중
단가 출처 / 재확인

합계 밖의 추가 예시

AZ별 NAT 2개 + NAT용 IPv4 2개: 월 약 $97.82 추가. 처리·전송 요금은 또 별도입니다. 외부 통신 경로의 한 가지 예시이며 필수 구성이 아닙니다.

계산 / 판단 가정

  • Linux t3.small EC2 2대, MySQL db.t3.micro Single-AZ 1대; 상시 실행, On-Demand USD
  • EC2 EBS gp3 총 40 GB, RDS gp3 20 GB; 기본 IOPS/처리량만 사용
  • 인터넷 공개 ALB 1개 + 평균 1 LCU, ALB 공인 IPv4 2개를 고정 가정; 실제 LCU·주소 수는 달라짐
  • Route 53 Public Hosted Zone 1개. ALB Alias 대상 조회 외 유료 질의는 미포함
  • 월 730시간, 연 12개월(8,760시간). 시간/일 값은 월 비용을 나눈 비교값이며 Hosted Zone은 실제 시간 과금이 아님

별도 확인할 범위

  • NAT / VPC Endpoint는 합계 밖: private 앱 외부 통신 경로를 별도 설계
  • 데이터 전송·AZ 간 통신·로그/알람·추가 백업·CPU 크레딧·도메인 등록·RDS Extended Support
  • 세금·환율·지원 플랜과 Free Tier/크레딧·예약 할인 미반영; 현재 가격과 실제 사용량으로 재산정 필요

NAT 처리 / 전송 별도 과금

위 NAT 추가 예시에도 처리량 $0.062/GB와 전송 비용은 빠져 있습니다. Endpoint 방식은 별도 비교합니다. VPC / IPv4 요금 ↗

CloudWatch 사용량에 따라

기본 지표 외 사용자 지정 지표·로그·알람 등을 확인합니다. 무료 범위는 계정/사용량 조건에 따라 달라집니다. CloudWatch 요금 ↗

IAM 기본 권한 관리 추가 요금 없음

연결 리소스 비용은 별도입니다. Access Analyzer의 일부 분석/검사 기능은 유료이므로 구분합니다. IAM / 분석 기능 요금 ↗

언제 과금되는가?

EC2 · RunningCompute 과금접속하지 않아도 실행 시간 과금
  • On-Demand Linux 실행 시간과 EBS·공인 IPv4 등 부속 리소스는 별도
  • 재시작과 재부팅은 과금 종료 수단이 아님
EC2 상태와 과금 ↗
EC2 · Stopped유지 비용 확인일반 Compute 중단 ≠ 전체 비용 0
  • EBS·스냅샷·남아 있는 공인 IP 비용을 따로 확인
  • 예약 약정·hibernate stopping 등의 예외는 요금 정책 확인
EC2 상태와 과금 ↗
EC2 · Terminated잔여 리소스삭제되지 않은 볼륨·스냅샷·IP 확인
  • 인스턴스 Compute는 종료되지만 DeleteOnTermination 설정에 따라 EBS가 남음
  • 예약 약정은 인스턴스 삭제만으로 취소되지 않음
EC2 상태와 과금 ↗
RDS · 실행 / 정지실행 + 저장Instance·Storage·Backup·전송 확인
  • 정지 중에도 스토리지·백업 비용은 남음
  • 지원되는 인스턴스는 최대 7일 정지 후 자동 재시작: 방치하면 실행 과금 재개
RDS 정지와 비용 ↗
변경 난이도일부 재시작SG는 온라인 · 서버 크기는 Stop/Start

EC2 Instance Type

Stop / Restart 필요

호환되는 EBS-backed On-Demand: Stop → Type 변경 → Start

EC2 타입 변경 ↗영향 상세 →

Security Group Rule

온라인 변경

규칙 변경은 연결 리소스에 자동 적용; 재시작 불필요

보안 그룹 규칙 ↗영향 상세 →

RDS DB Class

변경 가능 · 영향 있음

클래스 변경은 중단 가능; 즉시 적용/유지보수 창 선택 확인

RDS 설정별 변경 영향 ↗영향 상세 →

RDS Storage 증가

조건에 따라 다름

보통 온라인 확장; 성능 영향 가능, 원래 크기로 축소 불가

RDS 설정별 변경 영향 ↗영향 상세 →
서비스 영향조건에 따라 중단DB·접근 규칙 변경 전 복구 확인
EC2 Instance TypeStop / Restart 필요
기존 환경 중간
ALB 대상 제외·남은 서버 용량·앱 기동 확인
중단 가능성 조건부
대상 서버는 중단; 서비스 전체 영향은 다른 정상 서버/세션에 따라 다름
데이터 영향 조건부
EBS는 유지되지만 instance store·메모리는 보존되지 않음
복구 난이도 중간
호환성과 용량을 확인하고 다시 Stop/Start하여 이전 타입 복원
비용 영향 조건부
새 타입의 단가와 CPU 크레딧 정책 확인
보안 영향 낮음
Role·보안 그룹과 기동 후 접근 경로 재확인
EC2 타입 변경 ↗
Security Group Rule온라인 변경
기존 환경 높음
같은 SG를 쓰는 모든 리소스에 영향을 줄 수 있음
중단 가능성 조건부
잘못된 허용 규칙은 새 연결을 즉시 막을 수 있음; 기존 연결 추적은 별도
데이터 영향 낮음
저장 데이터를 바꾸지는 않지만 통신 실패로 업무 처리 영향 가능
복구 난이도 중간
기록한 기존 Rule 복구 후 새 연결로 재검증
비용 영향 낮음
규칙 자체 추가 요금보다 장애 대응 비용 확인
보안 영향 높음
0.0.0.0/0와 관리/DB 포트 과도한 개방 금지
보안 그룹 규칙 ↗
RDS DB Class변경 가능 · 영향 있음
기존 환경 높음
앱의 DB 재연결·타임아웃·유지보수 창 조율
중단 가능성 높음
이 샘플 Single-AZ DB 클래스 변경은 중단 발생
데이터 영향 조건부
백업과 복구 가능성 확인; 설정 변경이 백업을 대신하지 않음
복구 난이도 중간
지원되는 이전 클래스로 재변경 가능하나 다시 중단·용량 확인
비용 영향 조건부
새 DB 클래스 단가와 라이선스/CPU 크레딧 확인
보안 영향 낮음
DB 접근·암호화 정책 유지 확인
RDS 설정별 변경 영향 ↗
RDS Storage 증가조건에 따라 다름
기존 환경 중간
스토리지 최적화 중 성능과 변경 제한 확인
중단 가능성 낮음
할당 용량 증가 자체는 중단 없음; 다른 설정과 동시에 바꾸면 별도 영향
데이터 영향 조건부
백업/복구 검증 후 용량·성능 모니터링
복구 난이도 높음
제자리 축소 불가; 더 작은 DB로 데이터 이행 등 별도 계획 필요
비용 영향 높음
늘어난 스토리지 비용이 계속 발생
보안 영향 낮음
이행 대안 선택 시 암호화·접근 정책 재확인
RDS 설정별 변경 영향 ↗
주요 주의사항네트워크 · DB · IAM기존 연결과 데이터·권한 범위 확인
구축 시 주의배치 / 접근 범위
  • EC2에 공인 IP가 꼭 필요한 것은 아님: 이 예시는 Private Subnet
  • 앱·DB 포트를 0.0.0.0/0로 과도하게 개방하지 않기
  • HTTPS 인증서·IGW·보안 그룹·DB subnet group 확인
비용 주의NAT / 유휴 리소스
  • NAT Gateway는 시간·데이터 처리 비용이 발생: 통신 경로별 비용 비교
  • 쓰지 않는 EC2·EBS·ALB·스냅샷 정리 여부 확인
  • Multi-AZ와 로그 보존도 비용에 포함해 검토
확장 시 주의고가용성 / 용량
  • Single-AZ에서 시작했다면 장애 요구 증가 시 RDS Multi-AZ 검토
  • 트래픽 증가 시 Auto Scaling과 남은 서버 용량 검토
  • EC2 증설만으로 DB 병목이 해결되지는 않음
이행 / 변경 시 주의DNS / 연결 / 복구
  • DNS TTL·캐시와 Routing 변경 후 접속 전환 시간 확인
  • 앱의 DB 재연결·타임아웃과 변경 창을 조율
  • 변경 전 기존 설정·백업·Rollback 경로 확보
보안 주의최소 권한 / 관리 경로
  • IAM 최소 권한과 공개/Private Subnet 역할 확인
  • DB 직접 공개와 SG 관리 포트 과도한 개방 금지
  • SSM 등 관리 접속 경로와 감사 로그·암호화 검토
운영 주의사항 →

일반적으로 많이 검토하는 선택

절대적인 정답은 아니며 요구사항에 따라 달라집니다.

Production EC2복수 AZ와 잔여 용량 검토

장애 목표에 맞춰 AZ를 나누고 한 서버가 빠져도 처리할 용량을 확인합니다. 앱 상태 공유와 비용도 비교합니다.

EC2 권장 사항 ↗
DB 접근앱과 경계 분리 · 외부 공개 최소화

이 예시에서는 private DB와 앱 SG만 허용합니다. Multi-AZ 여부와 백업/복구 목표는 별도 요구사항으로 검토합니다.

RDS 보안 ↗
학습 메모
  • 학습을 위한 하나의 구성 예시이며, 모든 서비스에 적용되는 정답이나 실제 배포 안내가 아닙니다.
  • Route 53·ALB·RDS는 아직 Wiki 서비스 상세 데이터가 없어 공식 문서로 연결합니다.