TPB : AWS·Terraform으로 WordPress HTTPS 인프라를 한 번에 배포하기

Sb_chi·2024년 9월 24일

목록 보기

1/2

📌 Intro

TPB 프로젝트는 개인 프로젝트로 진행했으며,
반복적으로 구축하던 인프라를 IaC(Terraform)로 표준화하고,
CloudFront를 통해 ACM 인증서를 발급받아 HTTPS·도메인 연동까지 자동화함으로써 배포 환경의 일관성·재현성을 확보한 프로젝트입니다.

동작 검증은 WordPress 설치 페이지에 정상적으로 접근하는 것을 목표로 했으며,
이를 위해 인프라 구성 후 HTTP→HTTPS 리디렉션, CloudFront 캐싱 동작, 데이터베이스 연결 상태 등을 순차적으로 점검해 안정성을 확인했습니다.

📝 프로젝트 개요

목표: WordPress 인프라를 IaC(Terraform)로 표준화하고, HTTPS·도메인 연동까지 자동화하여 일관성 있는 배포 환경 구축
주요 스택:
- IaC: Terraform
- 배포 환경: Amazon EC2(ASG), RDS(MySQL), ALB, CloudFront, Route 53
- AWS 서비스: VPC, ACM, S3, Bastion Host, Security Group
- 자동화: UserData 기반 WordPress 설치
- 보안: RDS Private Subnet, Public Access 차단, 최소 권한 SG 설정
- 캐시·전송 최적화: CloudFront 캐싱 + Invalidation 워크플로우

🔗 GitHub Link

TPB - Github

인프라 아키텍처

CloudFront(us-east-1 ACM) → ALB(ap-northeast-2 ACM) → EC2(ASG) → RDS(MySQL)
Route 53: root/www → CloudFront, origin → ALB (A-ALIAS)

아키텍처 다이어그램

트래픽 라우팅: Route 53과 CloudFront를 통해 요청을 글로벌로 분산
HTTPS 적용: CloudFront(us-east-1)와 ALB(ap-northeast-2)에서 이중 HTTPS 처리
배포 자동화: UserData로 WordPress 설치 및 초기 설정 자동화
인프라 코드화: Terraform으로 전체 인프라를 코드로 관리
보안 강화: RDS를 Private Subnet에 배치하고 Public Access 차단
캐시 최적화: CloudFront 캐싱 및 Invalidation으로 최신 콘텐츠 제공

TLS/ACM Architecture

TLS·ACM 아키텍처 다이어그램

HTTPS 처리: CloudFront(us-east-1)와 ALB(ap-northeast-2)에서 단계별 HTTPS 적용
인증서 관리: CloudFront와 ALB 각각 별도의 ACM 인증서 사용
전 구간 암호화: 브라우저부터 EC2까지 모든 구간 HTTPS 통신 유지
보안 이중화: 네트워크 경계마다 암호화를 적용해 보안 강화

구현

Terraform 모듈화를 통해 AWS 리소스들을 독립적으로 관리하고 재사용 가능하게 구성했습니다. EC2 인스턴스는 UserData로 Nginx, PHP-FPM, WordPress를 자동 설치하며 프록시 환경에서도 정상 동작하도록 설정했습니다. RDS는 애플리케이션 전용 네트워크에서만 접근 가능하도록 설계해, 불필요한 노출을 방지했습니다.

결과 스크린샷

HTTPS 동작 확인

CloudFront 응답 헤더

⚠️ 트러블슈팅 : HTTPS 리다이렉션 루프현상

증상

HTTP로 접속한 사용자를 HTTPS로 전환하도록 설정했지만, HTTPS 상태에서도 다시 HTTP로 되돌아가도록 잘못 구성해, HTTP와 HTTPS 간에 요청이 계속 왕복하며 무한히 리다이렉션이 발생했습니다.
오류 : ERR_TOO_MANY_REDIRECTS

원인

앱(WordPress/Nginx)이 프록시 뒤 HTTPS 요청을 HTTP로 오인(X-Forwarded-Proto 미반영) + 인프라 레벨 중복 리다이렉션.

해결

ALB: :80 → 301 Redirect(:443), :443 → TargetGroup Forward (추가 Redirect 금지)
CloudFront:
- Behavior: viewer_protocol_policy = redirect-to-https
- Origin: origin_protocol_policy = https-only

앱: 프록시 HTTPS 인지

fastcgi_param X-Forwarded-Proto $http_x_forwarded_proto;

// wp-config.php
if (($_SERVER['HTTP_X_FORWARDED_PROTO'] ?? '') === 'https') $_SERVER['HTTPS'] = 'on';
define('FORCE_SSL_ADMIN', true);

⚠️ 트러블슈팅 : CloudFront 캐시 지연

증상

콘텐츠 수정 후에도 오래된 페이지/정적 파일이 계속 노출. X-Cache: Hit, Age 값 큼.

원인

TTL 과다 또는 Invalidation 미실행.

해결

Behavior TTL 합리화(예: min_ttl=0, default_ttl=300, max_ttl=86400)

변경 후 무효화 실행:

aws cloudfront create-invalidation --distribution-id <ID> --paths "/*"

검증

curl -I https://<도메인> | grep -E "X-Cache|Age"  # Age 감소/리셋, 최신 반영

마무리

WordPress 인프라를 Terraform 기반으로 표준화하고, HTTPS로 보안을 강화하고 Route 53을 활용해 안정적인 도메인 환경을 구성하여 배포 일관성과 운영 안정성, 확장성을 확보했습니다. 첫 프로젝트이다 보니 Terraform 모듈 구성과 변수화에서 시행착오가 있었지만, 이를 통해 인프라 자동화의 흐름과 AWS 서비스 연동 방식에 대해 많은 것을 배웠습니다.
향후에는 WAF(Web Application Firewall) 적용과 변수화·모듈 재사용 범위 확장을 통해 다양한 서비스 환경에 신속히 적용 가능한 범용 인프라 템플릿으로 발전시킬 계획입니다.

Sb_chi

다음 포스트