DevOps/AWS

AWS VPC Origin - Cloudfront with Internal ALB

가나무마 2025. 5. 19. 22:08

주의

아래 내용들은 오류나 잘못된 내용들을 포함할 수 있으므로 주의해주시기 바랍니다.

만약, 잘못된 부분이 있으면 댓글로 말씀해주시면 매우매우 감사하겠습니다.

 

2024년 11월 20일부터 AWS에선 VPC Origin 지원한다.

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/introducing-cloudfront-virtual-private-cloud-vpc-origins-shield-your-web-applications-from-public-internet/

 

VPC Origin은 Private Subnet에 속한 리소스와 CloudFront 간 연결을 가능하게 만든다.

 

기존엔 위처럼 CloudFront의 Origin으로 Internet-facing 로드밸런서를 사용했다. 이 방법은 한 가지 문제가 있다.

 

로드밸런서가 Internet-facing이므로 악의적인 사용자가 ALB를 통해 직접적인 접근이 가능하다.

현재 구조에선 사용자가 CloudFront를 통해 접근했을 때만 WAF가 동작하여 SQL Injection 차단과 같은 보안 기능을 제공한다.

허나, 위처럼 로드밸런서에 직접 접근한다면 WAF를 우회하여 접근이 가능하다.

물론, ALB엔 WAF를 따로 적용할 수 있다. 그러나, 이 방법은 WAF를 두 배로 사용하므로 WAF 사용 비용이 두 배가 된다.

단순 비용 뿐만이 아니라 운영 측면에서도 복잡함이 생긴다. 두 개 WAF에 동일한 규칙이 필요하다.

WAF를 사용하지 않고, 보안그룹을 사용하는 방법이다.

Cloudfront의 Prefix List(Cloudfront가 사용하는 IP 대역)를 보안 그룹의 인바운드 규칙에 적용하는 방법이다.

보안그룹은 CloudFront가 아닌 IP 대역에서 요청이 오면 해당 요청을 차단한다.

 

이 방법도 나쁘진 않다. 그러나, 내가 생각하기엔 여전히 두 가지 단점을 가진다.

첫 번째로, 여전히 로드밸런서의 주소가 외부에 노출된 상태다.

보안그룹이나 NACL을 통해 트래픽을 차단하더라도 외부에서 접근 가능한 주소를 노출한다는 건 공격 표면을 넓히는 일이다.

 

두 번째로, 보안그룹 규칙을 추가적으로 설정할 필요가 있다는 점이다. Prefix List로 처리가 매우 간단하지만, 이런 자잘한 규칙이 추가될수록 실수가 날 확률이 높아진다고 나는 개인적으로 생각한다.

 

따라서, 제일 좋은 방법은 네트워크 자체 분리라고 생각한다. 이를 위해 AWS에서 지원을 시작한 방법이 VPC Origin이다.

 

VPC Origin은 PrivateLink 방식으로 동작하며 해당 서브넷에 VPC Endpoint를 만들어 CloudFront와 Private 서브넷에 속한 로드밸런서 간에 연결을 가능하게 만든다.

VPC Origin을 사용하면 로드밸런서의 주소를 노출할 필요도 없고, 보안그룹 규칙 추가 등 추가적인 설정이 필요 없다는 큰 강점을 가진다.

 

 

https://aws.amazon.com/ko/blogs/networking-and-content-delivery/introducing-cloudfront-virtual-private-cloud-vpc-origins-shield-your-web-applications-from-public-internet/

https://docs.aws.amazon.com/ko_kr/AmazonCloudFront/latest/DeveloperGuide/private-content-vpc-origins.html#vpc-origins-supported-regions