CloudFront VPC Origin - 퍼블릭 노출 피하기

2024년 11월 20일부터 AWS는 CloudFront의 VPC Origin 기능을 정식으로 지원하기 시작했습니다.
이 기능은 Private Subnet에 위치한 리소스를 CloudFront의 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/

---

기존 구조의 문제점

전형적인 CloudFront를 사용한 ALB 활용 구조

기존에는 CloudFront의 Origin으로 Internet-facing 로드밸런서(ALB/NLB) 를 사용하는 방식이 일반적이었습니다.

---

ALB의 엔드포인트를 통한 직접적인 접근이 가능하다.

하지만 이 방식에는 다음과 같은 보안상의 취약점이 존재합니다.

• 퍼블릭 노출: ALB가 Internet-facing이므로, 악의적인 사용자가 로드밸런서에 직접 접근할 수 있습니다.
• WAF 우회 가능성: WAF는 CloudFront에만 적용되어 있는 경우가 많습니다. 이 경우 로드밸런서에 직접 접근하면 WAF를 피해서 서비스에 접근하는 것이 가능해집니다.

---

CloudFront와 ALB에 WAF를 적용할 수 있따. 대신 비용이 두 배

물론, ALB에 별도로 WAF를 추가해 보호할 수 있지만 다음과 같은 한계가 있습니다:

• 비용 증가: CloudFront와 ALB 양쪽에 WAF를 적용하면, WAF 비용이 두 배가 됩니다.
• 운영 복잡도: 동일한 보안 룰을 두 개의 WAF에 중복으로 적용해야 합니다.

---

대안: 보안 그룹 + Prefix List

한 가지 대안은 CloudFront의 Prefix List(IP 대역) 를 이용하여 보안 그룹에서 인바운드 요청을 제한하는 것입니다.

이 방식도 나름의 보안 효과는 있지만, 다음과 같은 단점이 존재합니다:

1. 공개 주소 노출: ALB 주소는 여전히 퍼블릭하게 노출되어 있어, 공격 표면이 열려 있는 상태입니다.
2. 운영 실수 가능성: Prefix List 기반 보안 그룹 설정은 간단하긴 하지만, 추가적인 규칙 관리가 필요하고, 이로 인한 설정 누락 가능성도 존재합니다.

---

가장 이상적인 방식: CloudFront VPC Origin

CloudFront와 ALB를 VPC Origin으로 연결

이 문제를 근본적으로 해결할 수 있는 방식이 바로 VPC Origin입니다.

• VPC Origin은 AWS PrivateLink를 기반으로 동작합니다.
• CloudFront에서 VPC Endpoint를 통해 Private Subnet 내의 로드밸런서(또는 리소스)에 직접 연결합니다.
• 로드밸런서 주소 노출이 없으며, 보안 그룹이나 NACL 설정도 불필요합니다.

즉, 인터넷을 통한 접근 경로 자체를 차단하고, CloudFront만이 유일한 진입점이 되므로 보안성과 운영 효율성 모두를 극대화할 수 있습니다.

---

참고자료

• 공식 블로그 – Introducing CloudFront VPC Origins
• 공식 문서 – VPC Origins (지원 리전 포함)