AWS 인프라 통합 관리

Overview

IT지원위원회에서 운영하는 Homepage, SSUPPORT 등 여러 서비스를 하나의 클라우드 환경에서 효율적으로 관리하기 위한 인프라 통합 프로젝트입니다.

기존에는 공용 네트워크 자원이 특정 서비스의 Terraform 코드에 포함되어 있어, 신규 서비스가 NAT나 네트워크를 사용하려면 기존 프로젝트에 의존해야 했습니다. 이를 공용 자원을 담당하는 Global 계층과 개별 비즈니스 서비스를 담당하는 Service 계층으로 분리하고, 각 서비스가 원격 상태를 통해 필요한 값만 참조하는 Hub & Spoke 구조로 재설계했습니다.

Architecture

IT지원위원회 AWS 통합 인프라 아키텍처

사용자 요청은 Route53과 CloudFront를 거쳐 서비스별 오리진으로 전달됩니다. 정적 웹은 OAC로 보호된 S3에서 제공하고, 백엔드 트래픽은 공용 ALB의 리스너 규칙에 따라 각 서비스의 Target Group으로 분배됩니다. 애플리케이션 EC2는 프라이빗 서브넷에 배치해 외부 직접 접근을 제한했습니다.

운영 VPC와 개발 VPC를 분리하고, IAM, ECR, Systems Manager, CloudWatch 같은 공통 기능은 Shared 영역에서 관리합니다. CloudFront용 인증서는 us-east-1, ALB용 인증서는 서비스 리전인 ap-northeast-2에서 관리해 AWS의 리전 요구사항을 반영했습니다.

Tech Stack

영역	기술	선택 이유
Infrastructure as Code	Terraform	공용·서비스별 인프라 의존성 분리와 상태 기반 변경 관리
Edge & Routing	Route53, CloudFront, ALB	엣지 보안, 도메인 라우팅, 다중 서비스 트래픽 중앙 제어
Compute & Storage	EC2, S3	프라이빗 애플리케이션 실행 환경과 OAC 기반 정적 호스팅
Operations	IAM, ECR, SSM, CloudWatch	권한, 이미지, 접속과 모니터링 기능의 공통 관리
Delivery	GitHub Actions	코드 변경부터 배포까지의 자동화

My Role

• Global 계층과 서비스별 Terraform 구성을 분리하고 공용 인프라를 코드화
• Shared ALB 리스너 규칙을 활용한 다중 서비스 트래픽 라우팅 설계
• 운영 중인 AWS 리소스를 유지한 채 Terraform State를 마이그레이션
• 서비스 계층에서 terraform_remote_state로 공용 출력값을 참조하는 구조 설계

Problem

초기 인프라는 단일 서비스인 Homepage를 중심으로 구성되어 있었습니다. NAT와 네트워크 같은 공용 자원까지 Homepage의 Terraform State에 포함되어 있었기 때문에, 신규 서비스가 공용 자원을 사용하려면 Homepage 코드와 상태에 직접 의존해야 했습니다.

서비스가 늘어날수록 변경 영향 범위와 관리 포인트가 커졌고, 서비스마다 ALB 같은 고정비 자원을 별도로 만들 경우 운영 비용도 불필요하게 증가하는 구조였습니다.

Troubleshooting

Global · Service 계층 분리

VPC, Subnet, Route53, ACM, Shared ALB, 공통 IAM처럼 여러 서비스가 함께 사용하는 자원을 Global 계층으로 옮겼습니다. 각 서비스는 terraform_remote_state로 VPC ID, Subnet ID, 인증서 ARN 등 필요한 출력값만 참조하고, 자신의 EC2, S3, Target Group 같은 리소스만 관리하도록 경계를 나눴습니다.

Shared ALB 기반 라우팅

서비스마다 ALB를 생성하지 않고 하나의 운영 ALB를 공유했습니다. Host Header와 경로에 따른 리스너 규칙으로 요청을 서비스별 Target Group에 전달해 고정 비용과 관리 지점을 줄였습니다.

무중단 Terraform State 마이그레이션

이미 운영 중인 물리적 AWS 리소스를 다시 생성하면 다운타임이나 충돌이 발생할 수 있었습니다. 따라서 리소스는 그대로 유지하고 terraform state rm으로 기존 State의 논리적 연결을 해제한 뒤, Global 계층에서 terraform import로 다시 연결했습니다.

마이그레이션 전에는 State를 백업하고 대상 리소스 주소를 확인했으며, 단계별 terraform plan 결과에 불필요한 생성·삭제가 없는지 검증하는 방식으로 변경 범위를 통제했습니다.

Result

공용 인프라를 Global 계층으로 분리해 서비스 간 Terraform 코드와 State의 직접 의존성을 제거했습니다. 운영 리소스의 다운타임 없이 마이그레이션을 완료했으며, 이후 신규 서비스는 네트워크와 Shared ALB를 재사용하면서 자신의 리소스만 추가할 수 있게 되었습니다.

이를 통해 서비스마다 중복 인프라를 구성할 때 발생하는 고정 비용을 피하고, 공용 보안·라우팅 정책의 관리 지점을 하나로 모았습니다.

Retrospective

클라우드 인프라는 리소스를 생성하는 것만큼 소유 경계와 State를 설계하는 일이 중요하다는 것을 배웠습니다. 특히 운영 중인 리소스의 State를 직접 이전하면서, 실제 인프라와 Terraform State의 관계를 이해하고 변경 전에 실행 계획을 검증하는 습관을 익혔습니다.

향후에는 State 잠금과 복구 절차를 문서화하고, 서비스 수와 비용 변화 같은 운영 지표를 지속적으로 기록해 통합 구조의 효과를 정량적으로 검증할 계획입니다.