AWS 인프라 기초 설계

AWS 인프라 기초 설계 · VPC · RDS · ElastiCache · EC2로 배포하기

Spring Boot 애플리케이션을 실제 서비스 환경에 배포하려면 단순히 EC2 서버에 JAR 파일을 올리는 것만으로는 부족하다.
네트워크(VPC), 데이터베이스(RDS), 캐시(ElastiCache), 애플리케이션 실행 환경(EC2)을

어떻게 설계하고 연결했는지에 따라 서비스의 안정성과 확장성이 결정된다.
이 글에서는 AWS에서 VPC + RDS(MySQL) + ElastiCache + EC2를 구성하고 연결한 과정을 정리한다.

---

＃전체 아키텍처 개요

이번에 구성한 인프라의 핵심 요소는 다음과 같다.

• VPC - 독립된 가상 네트워크
• 퍼블릭 서브넷 - 인터넷과 통신되는 영역
• 프라이빗 서브넷 - 외부에서 직접 접근할 수 없는 내부 전용 영역
• RDS(MySQL) - 서비스 데이터 저장소
• ElastiCache - 세션 및 캐시 담당 Redis 호환 인메모리 캐시
• EC2 - Spring Boot 애플리케이션 실행 서버
• 보안 그룹 - 인바운드/아웃바운드 트래픽 제어

애플리케이션 요청은 다음 흐름으로 동작한다.

• User → Internet → EC2 → RDS / ElastiCache
• 모든 내부 통신은 VPC 내부 IP로 이루어지고, 외부에 노출되는 것은 EC2의 퍼블릭 엔드포인트뿐이다.

---

＃VPC

VPC(Virtual Private Cloud)는 AWS 안에서 사용하는 나만의 가상 사설 네트워크다.
쉽게 말해, 내 서비스의 모든 리소스가 들어가는 전용 네트워크 구역이라고 보면 된다.

VPC를 쓰는 이유

• 내 서비스 리소스를 다른 계정/다른 서비스와 논리적으로 완전히 분리
• 퍼블릭/프라이빗 서브넷을 나눠 외부에 공개할 것과 숨길 것을 분리
• 보안 그룹, NACL, 라우팅 테이블로 트래픽 흐름을 세밀하게 제어

---

＃RDS

RDS는 AWS에서 제공하는 관리형 관계형 데이터베이스 서비스다.
직접 EC2에 MySQL을 설치하는 대신, 백업, 패치, 장애 조치까지 AWS가 관리해주는 것이 특징이다.

왜 EC2에 직접 MySQL을 설치하지 않았는가?

• 백업/복구/스냅샷을 직접 관리해야 한다.
• 장애 발생 시 수동으로 재부팅/장애조치가 필요하다.
• 애플리케이션과 DB가 같은 서버에 있으면 리소스 경합이 생긴다.

반면 RDS를 사용하면,

• 자동 백업, 스냅샷, 멀티 AZ, 모니터링 등 운영 기능을 대부분 AWS가 제공
• 애플리케이션 서버(EC2)와 역할 분리가 명확해진다.

Spring Boot에서 RDS 연결 설정 예시

spring:
 datasource:
  url: jdbc:mysql://oddventure-db.xxxxxx.ap-northeast-2.rds.amazonaws.com:3306/oddventure
  username: oddventure_user
  password: <RDS_PASSWORD>
  driver-class-name: com.mysql.cj.jdbc.Driver

 

---

＃ElastiCache

ElastiCache는 AWS에서 제공하는 관리형 인메모리 캐시 서비스로, 고속 읽기·쓰기가 필요한 데이터를 안정적으로 처리할 수 있도록 설계된 서비스다.

RDS가 디스크 기반의 영속 저장소라면, ElastiCache는 속도를 위해 메모리에 데이터를 저장하는 캐시 계층 역할을 한다.
이 구조를 통해 자주 조회되는 데이터는 캐시에서 빠르게 응답하고, 필요한 경우에만 RDS에 접근하도록 구성했다.

 

이번 프로젝트에서 ElastiCache의 내부 엔진으로는 Valkey를 사용했다.
Valkey는 Redis와 명령어, 프로토콜, 클라이언트까지 모두 호환되는 Redis 계열 인메모리 데이터베이스로,
기능적인 사용 방식은 사실상 Redis와 거의 동일하다.

Valkey를 선택한 배경에는 Redis 라이선스 변경 이슈가 있다.
2024년 이후 Redis는 기존의 자유로운 BSD 라이선스에서 상업적 사용에 제약이 있는 형태로 라이선스 정책이 변경되었고,
이로 인해 AWS, Google, Azure 같은 주요 클라우드 벤더들이 Redis를 기존 방식 그대로 서비스하기 어려워졌다.
그 대안으로 Redis 7.2 기반의 오픈소스 포크 프로젝트인 Valkey가 공식적으로 채택되었고,
AWS 역시 ElastiCache의 Redis 대안으로 Valkey 계열을 적극적으로 지원하고 있다.

다만 개인적으로는 지금까지의 프로젝트에서는 Redis만 사용해왔고,

이번 프로젝트에서는 AWS 환경에서의 공식 대응 방향을 따라가 보기 위해 ElastiCache + Valkey 조합을 선택했다.
실제 사용 경험 측면에서는 Redis와 체감 차이는 거의 없었고, 기존 Redis 클라이언트 설정과 코드도 거의 그대로 사용할 수 있었다.

결론적으로 기능만 보면 Redis와 큰 차이는 없지만, 운영 관점과 장기적인 라이선스 리스크까지 고려했을 때
ElastiCache + Valkey 조합이 더 안전한 선택이라고 판단해 이번 프로젝트에서는 해당 구성을 캐시 계층으로 채택했다.

캐시 계층이 필요한 이유는 다음과 같다.

• 로그인 세션을 DB에만 저장하면 요청마다 DB I/O가 발생한다.
• 자주 조회되지만 자주 바뀌지 않는 데이터는 DB 대신 캐시에서 조회하는 것이 훨씬 효율적이다.
• 실시간 트래픽이 몰릴 때 DB 부하를 완충해주는 역할을 한다.

Spring Boot Redis 설정 예시

spring:
 data:
  redis:
   host: oddventure-cache.xxxxxx.ap-northeast-2.cache.amazonaws.com
   port: 6379

 

---

＃EC2 - Spring Boot 애플리케이션 실행 서버

EC2는 흔히 말하는 클라우드 상의 리눅스 서버다.
이번 구성에서는 Spring Boot 애플리케이션을 실행하는 애플리케이션 서버 역할을 담당한다.

EC2에서 수행하는 역할

• 빌드된 `oddventure` 애플리케이션 JAR/Docker 컨테이너 실행
• 외부로부터 HTTP 요청 수신 (예: 80/8080 포트)
• 내부 네트워크를 통해 RDS/ElastiCache에 접근

보안 그룹 설정 개요

• EC2 보안 그룹
  • 인바운드: HTTP(80), 혹은 테스트용 8080, SSH(22) 제한된 IP만 허용
  • 아웃바운드: RDS/ElastiCache 포트로의 통신 허용
• RDS 보안 그룹
  • 인바운드: MySQL(3306), EC2 보안 그룹에서만 접근 허용
• ElastiCache 보안 그룹
  • 인바운드: 6379, EC2 보안 그룹에서만 접근 허용

---

마치며

이번 글에서는 VPC · RDS(MySQL) · ElastiCache · EC2를 사용해
Spring Boot 프로젝트를 AWS에 배포하면서 경험한 아키텍처 설계를 정리했다.

단순히 EC2에 서비스 하나 띄우는 수준을 넘어서, 네트워크(VPC) · 데이터베이스(RDS) · 캐시(ElastiCache) · 애플리케이션 서버(EC2)가 서로 어떤 역할을 맡고, 실제 트래픽이 들어왔을 때 어떻게 상호작용하는지까지 눈에 그려보는 것이 목표였다.

다만 현재 구조는 EC2 단일 인스턴스 기반이기 때문에, 무중단 배포, 자동 확장, 롤백 측면에서는 한계가 있다.

다음 단계에서는 이 구조를 기반으로
ECS(Fargate) 기반 컨테이너 배포, ALB를 이용한 무중단 배포, Prometheus/Grafana를 이용한 모니터링까지 확장해 볼 계획이다.