AWS 배포시 CloudFront에서 ALB로 포워딩 하는 구조가 좋지 않은 이유가 무엇인가요?

Question

토이 프로젝트 배포하려고 하는데요, CloudFront와 ALB를 사용하려고 합니다.아래의 첨부 이미지와 같은 구조로 배포하려고 생각하고 다른 곳에 인프라 구조 관련 질문을 드렸는데요,CloudFront에서 ALB로 포워딩 하는 구조가 좋지 않다는 피드백이 있었습니다.정적 파일 요청과 API 요청 도메인을 각각 서브도메인으로 나눠서 처리하는게 좋다는 의견이셨습니다.https://static.example.com/https://service.example.com/이때 CloudFront에서 ALB로 요청을 포워딩 하는 구조가 좋지 않은 이유가 궁금합니다.ALB 앞단에 CloudFront가 없이 ALB이 직접 요청을 수신해서 처리하도록 하면 다음과 같은 단점(?) 있을 수도 있는것 같아서요WAS 응답 캐싱 불가 (CloudFront에서 받으면 WAS 응답도 캐싱하여 바로 제공 가능?)정적 리소스만 캐싱하게됨SSL/TLS 인증서를 ALB에도 등록 해야함 (CloudFront 뿐만 아니라)CloudFront의 보안 기능들을 WAS에는 적용 불가DDoS 보호, WAF 방화벽 등 제가 생각했던 구조는 아래의 첨부 이미지와 같이 CloudFront에서 요청을 받아서 정적인 요청은 캐싱된 정적 파일로 처리 하고 동적 처리가 필요한 요청은 WAS로 넘겨서 처리하는 구조였습니다. 제가 생각한 구조는 아래 프로젝트의 인프라 구조랑 비슷한거 같네요..클라우드 프론트가 가장 앞단에서 모든 요청을 처리 or 포워딩 한다는 점에서..?

쿠거 · Answer

글쎄요.. 딱히 추가적인 제약사항이 생길 것 같지는 않는데 저도 궁금하네요. 피드백 받았을 당시 좋지 않다고 한 이유에 대해 들으신 내용이 있을까요??만약 서버를 프라이빗으로 구성해야 할 경우에 한해서는 alb를 internal로 구성해야 하니 cloudfront를 사용하지 못하겠지만 그런 조건이 없다면 개인적으로는 문제는 없을 것 같다에 한 표 입니다.

Lamanus · Answer

장점이 더 많을텐데요. 누가 왜 그런 피드백을 제공했는지 좀 의문이네요.어차피 ttl은 0으로 설정해서 alb 호출하는거랑 동일하게 제공하고 나중에 선별적으로 캐싱 제공도 가능하고, 트래픽 요금도 alb로 직접 들어올 경우에는 DataTransfer로 분류되지만, cf 통해서 들어오면 cf 별도 요금제를 타기 때문에 cfrc 같은 할인 제도를 통해서 비용적인 면에서도 이득입니다. 게다가 cf 엣지에서 alb로 aws 망을 통해 들어오기 때문에 고객이 alb로 직접 접근하기 위해서 isp들을 타고 오는 것보다 퍼포먼스도 아주 조금이지만 개선될 수 있고요.

AWS 배포시 CloudFront에서 ALB로 포워딩 하는 구조가 좋지 않은 이유가 무엇인가요?

2개의 답변

#cloudfront 목록