인터넷을 통해 유입되는 트래픽을 보호하기 위한 AWS 기반 방화벽 배포방식 설계

인터넷을 통해 유입되는 트래픽을 보호하기 위한 AWS 기반 방화벽 배포방식 설계

인터넷을 통해서 서비스가 연결되는 애플리케이션들은, 외부로 부터의 여러 위협 및 원치 않은 접근을 제한하기 위한 보안 통제 조치들을 충분히 고려하여 구성하여야 합니다. 이러한 보안 통제 조치들은 애플리케이션의 유형이나, 크기, 요구되는 컴플라이언스 수준, 운영상의 조건 등 다양한 고려사항에 따라서 구현될 수 있습니다. 어떤 경우에는 Network Access Control List(NACL)나, Security Group(SG)만을 활용하여도 효과적으로 애플리케이션을 보호할 수 있을 것이며, 좀더 다양한 형태의 위협에 대한 대응이 필요할 경우에는 추가적인 방화벽 구성이 필요할 수도 있습니다.

추가적인 방화벽 구성의 경우, NACL이나 SG외에 AWS Web Application Firewall (AWS WAF) 혹은 3rd party security appliance 고려할 수 있을 것입니다. 또한 AWS Network Firewall이나, AWS Gateway Load Balancer 같은 새롭게 추가된 서비스들을 사용하여 더욱 유연한 방화벽 아키텍처를 AWS상에서 설계할 수 있습니다.

우리는 이러한 각 서비스들을 활용하는 다양한 구성방법들을 기존 블로그들에서 다룬 바 있습니다 : Network Firewall Deployments Models, Centralized Inspection Architectures with AWS Gateway Load Balancers, Defense-in-depth with AWS WAF. 더불어서 DDoS 대응 모범사례 백서 역시 발간 하였습니다.

이 블로그에서는 인터넷에 연결된 애플리케이션들에 대한 인바운드 트래픽을 보호하기 위한 다양한 방화벽 옵션에 대한 네트워크 구성방안들을 소개해 보고자 합니다. 즉, 인터넷으로 부터의 Ingress flow(예: Internet 에서 VPC로)에 집중하여 다룹니다. 이는 대다수의 애플리케이션들의 경우 Ingress flow에 대한 요구사항에서 고려할 부분이 더 많으며 이러한 요구사항에 따라서 네트워크 구성에 큰 차이점을 보일 수 있기 때문입니다. Egress flow(예: VPC에서 인터넷으로) 및 East/West(즉, VPC에서 VPC로 또는 VPC에서 온프레미스로)에 대한 검사 패턴은 위에 링크된 이전 블로그 게시물을 통해서 심층적으로 다루고 있습니다.

인터넷 유입 트래픽을 필터링 하기 위해서 NACL이나 Security Group외에 추가적인 고려사항이 필요한 이유

NACL이나 SG는 방화벽 처럼 동작합니다. NACL은 서브넷에 대한 Stateless(상태 비저장) 형태의 보호를 제공하며, SG는 상태저장(Stateful)으로 이미 허용된 트래픽에 대한 리턴 트래픽을 자동으로 허용합니다. SG는 서브넷과는 무관하게 ENI(Elastic Network Interface)에 할당됩니다.

많은 경우 이 2가지 보호만으로 충분할 수도 있습니다. 하지만 추가적인 보안조치를 필요로 하는 경우 역시 발생할 수 있습니다. 아래에서 추가적인 방화벽이 필요한 몇가지를 주요 이슈별로 나열하여 보았습니다.

• Scale(규모) – 하나의 NACL은 최대 40개의 규칙항목(Rule entry)를 지원합니다(기본값은 20개). 그리고 하나의 SG는 1,000개의 규칙항목(기본값은 60개)를 허용합니다. 만약 이러한 제약을 초과하는 요구가 있다면 추가적인 보안 제어지점을 추가해야 합니다. 예를 들어서 AWS Network firewall은 30,000개의 상태저장 규칙항목을 기본적으로 지원합니다.
• Inspection Depth(검사의 깊이) : NACL과 SG는 네트워크 계층 및 전송계층에서 동작합니다. 즉 제어에 있어서 IP주소, 프로토콜, 그리고 포트에 대해서 적용되며, 애플리케이션 파라메타에 대해서는 적용되지 않습니다. 따라서 어플리케이션 계층 기반의 보호를 제공하지 않습니다. 예를 들어서 만약HTTP/s 접속에 대한 페이로드 정보를 기반으로 하는 필터링 (특정 HTTP Header에 대한 차단 등)을 적용할 필요가 있다면 AWS WAF를 추가하여 구성할 수 있습니다.
• Centralized Management(중앙 집중식 관리) : 규모가 크고 분산된 환경에서는 중앙에서 다양한 어카운트 VPC에 걸쳐서 존재하는 SG와 NACL을 관리하기가 더 어려울 수 있습니다. 여기에 대한 하나의 해결책으로 AWS Firewall Manager 서비스에서 제공하는 SG에 대한 중앙관리 감사를 이용하는 방안이 있습니다. 또다른 대안으로는 중앙의 보안관리 팀에서 관리하는 방화벽 (AWS 또는 3rd Party에서 제공하는)을 추가하는 것입니다. 이때 충분한 자동화가 도입되지 않을 경우, 이러한 접근은 오히려 새 애플리케이션들이 배포될 때 병목현상을 초래할 수 있습니다.

유입트래픽에 대한 방화벽 적용시 고려해야 할 사항들

방화벽 솔루션을 도입할 때, 방화벽의 기본적인 기능이나 성능외에도 여러가지가 고려되어야 합니다. 아래는 일반적으로 네트워크 솔루션이 적용될 때 영향을 끼칠 수 있는 몇가지 영역들 입니다.

• 애플리케이션 타입 – 검토 중인 솔루션이 보호의 대상이 되는 애플리케이션 타입을 지원하도록 하여야 합니다. 예를 들어 Web Application firewall(웹방화벽)은 HTTP/s 기반의 애플리케이션 보호에는 적합하지만 다른 유형의 트래픽을 보호하는데는 적합하지 않습니다. 다양한 유형의 애플리케이션을 보호하여야 하는 경우라면 다양한 유형의 애플리케이션을 모두 보호할 수 있는 방화벽 제품을 도입하거나, 혹은 여러가지 방화벽 솔루션을 조합하여 구성할 필요가 있습니다.
• 운영 규모 – 유입 트래픽에 대하여 방화벽으로 보호할 VPC의 운영규모를 고려하여야 합니다. 단순히 하나의 VPC만을 보호 대상으로 할지, 멀티 VPC, 멀티 어카운트 환경이라면 방화벽을 분산시킬지(각 VPC 별로 독자적인 데이터 플레인 패스와 고유한 방화벽을 구성함) 또는 집중화할지(트래픽이 실제 어플리케이션이 속한 VPC로 전송되기 전에 중앙 집중화된 보안 전용 VPC를 거쳐서 제어 받도록 구성함)를 결정해야 합니다.
• 검사의 깊이/암호화– 방화벽에서 검사하는 패킷의 계층을 어디까지 적용할지 고려하여야 합니다. 예를 들어 네트워크 계층에 대한 규칙을 적용하는 것으로 충분한지, 아니면 애플리케이션에 계층에 대한 검사도 필요한지를 고려합니다. 또한 인터넷상의 트래픽의 대부분은 암호화되어 있으므로, 애플리케이션 계층에서 해당 트래픽을 검사하려면 암호화된 트래픽을 해독할 수 있는 방화벽 솔루션이 필요합니다.
• 운영/자동화 – AWS 네트워크에 추가적인 방화벽들이 구성되면 거기에 따라 운영 오버헤드가 발생합니다. 따라서 방화벽 솔루션들을 선택할 때, 적절하게 확장성에 따른 관리 및 자동화가 잘 이루어질 수 있는지를 고려야하여 합니다. 예를 들어 AWS Network Firewall 및 AWS WAF는 여러 VPC 및 AWS 계정에 배포된 경우에도 AWS Firewall Manager를 사용하여 중앙에서 관리할 수 있습니다. 적절하게 자동화를 구현할 수 없다면 방화벽 운영시 병목 현상이 발생하여 애플리케이션의 배포나 구현 속도가 느려질 수 있습니다.
• IPv6 지원– 아래에 나열된 모든 아키텍처가 IPv6를 지원하는 것은 아닙니다. IPv6 트래픽의 입력 필터링을 지원해야 하는 경우에는 최신으로 업데이트된 AWS 문서(IPv6 on AWS)를 참조하십시오.

아래에서는 트래픽의 접속 흐름에 따라서 분산 제어모델과 중앙 집중제어 방식의 아키텍처로 구분하여 설명하고 있습니다.

분산 제어 방식의 아키텍처

분산제어 방식의 아키택처에서는 각각의 VPC가 전용 인터넷 게이트웨이(IGW)를 통하는 자체적인 경로를 가지고 있습니다. 즉, 인터넷으로 부터의 유입경로가 1개 또는 여러개의 VPC들에 대해 동일하게 구성됩니다. 이 접근방식을 사용하면 관리가 용이해지고, 이슈 발생시 영향받는 범위가 한정되며, 트러블 슈팅이 간단해집니다.

인터넷 유입 트래픽을 분산한다고 해서 외부로 나가는 트패릭을 꼭 분산할 필요도 없습니다. 이러한 Ingress/Egress 트래픽의 흐름은 개별적으로 처리할 수 있습니다. Elastic Load Balancing(Network, Classic, Application 로드 밸런서)을 통해서 인턴넷에서 유입되는 트패픽은 항상 해당 로드 밸런서를 통해 돌아갑니다. 반면 내부 VPC에서 발생해서 인터넷으로 향하는 트래픽은 다른 경로를 가질 수 있습니다.

다음 섹션에서는 분산제어 방식의 아키텍처에 구성할 수 있는 다양한 방화벽 솔루션(AWS Native 및 3rd party)에 대해 설명하고 있습니다. 여기에는 각 고려사항별 주요 차이점에 대해서도 요약되어 있습니다. 즉 방화벽으로의 트래픽 흐름, VPC 확장성, 애플리케이션 유형 및 암/복호화, 클라이언트 IP 주소표시 방식에 대해서 다양한 방화벽 솔루션들이 어떻게 차이가 있는지를 보여주고 있습니다.

AWS WAF

방화벽으로의 트래픽 흐름:

AWS WAF는 Application Load Balancer(ALB), Amazon CloudFront, Amazon API Gateway, AWS AppSync와 직접 통합됩니다(마지막 두 개는 다이어그램에 표시되지 않음). 따라서 트래픽을 검사하기 위해서는 기존 ALB 또는 CloudFront 배포지점에 대해서 AWS WAF서비스를 활성화해야 합니다.

애플리케이션 유형 및 암/복호화:

AWS WAF는 HTTP/s 애플리케이션만 지원합니다. 이때, AWS WAF보호의 대상으로 등록되는 ALB와 CloudFront 모두 TLS 종료(TLS Termination)를 지원하고 있으므로, AWS WAF는 해당 자원에 대해서 복호화를 통해 암호화 되지 않은 트래픽을 검사할 수 있습니다.

여러 VPC로 확장 가능:

여러 VPC에 걸쳐서 서비스를 배포하는 경우 애플리케이션에 사용되는 각 애플리케이션 로드 밸런서 또는 CloudFront 배포지점에서 WAF를 사용하도록 설정하게 됩니다. 이때, AWS Firewall Manager를 사용하여 각각의 애플리케이션을 위한 WAF 정책들을 중앙에서 관리하고 강제화할 수 있습니다.

클라이언트 IP 주소 표시:

AWS WAF는 CloudFront 또는 ALB에 연결되는 클라이언트의 실제 IP 주소에 액세스할 수 있습니다. 다만, 이 IP 주소는 최종 백엔드에 전달되는 IP 패킷자체에는 보존되지 않는 다는 점은 유의하여야 합니다. ALB 및 CloudFront는 트래픽을 백엔드로 전송할 때 실제 클라이언트 IP를 X-Forwarded-For HTTP 헤더에 포함하는 방식으로 클라이언트의 실제 IP에 대한 추적성을 확보합니다.

AWS Network Firewall

방화벽으로의 트래픽 흐름:

AWS 네트워크 방화벽은 ‘Bump-in-the-Wire’ 형태로 네트워크 트래픽 흐름에 transparent하게 추가 될 수 있습니다. 즉 Client로 부터 목적 Service에 이르는 동안 직접 접속의 대상이 되지 않습니다. 구성을 위해서는 각 가용 영역(Availability Zone)별로 AWS Network Firewall Endpoint들을 위한 서브넷을 구성하여야 합니다. 트래픽을 검사하기 위해서는 VPC 서브넷 route table을 변경하여 트래픽을 네트워크 방화벽 엔드포인트(Network Firewall Endpoint)로 라우팅 해야 합니다.

인터넷에서 유입되는 트래픽을 네트워크 방화벽 엔드포인트로 보내기 위해서는 IGW의 라우팅을 변경하여야 합니다. 이렇게 함으로써 ELB 서브넷을 향하는 트래픽을 적합한 가용영역에 속한 방화벽 엔드포인트로 보낼수 있습니다. 유입트래픽 라우팅에 대한 보다 자세한 내용을 배우기 위해서는 해당 블로그를 참조합니다.

애플리케이션 유형 및 암/복호화:

AWS 네트워크 방화벽은 모든 유형의 트래픽을 처리할 수 있지만 TLS복호화(TLS decryption)는 지원하지 않습니다. 따라서 애플리케이션 계층에서 암호화된 트래픽에 대한 검사는 수행할 수 없습니다.
물론, 트래픽이 암호화되어 있는 경우에도 AWS 네트워크 방화벽은 네트워크 및 전송 계층뿐만 아니라 상위계층에 대한 일부 제어를 적용할 수 있습니다. TLS 프로토콜의 서버 이름 표시(Server Name Indication : SNI) 확장을 볼 수 있으며, 허용할 TLS 버전을 강제화 하거나 TLS fingerprinting을 특정할 수 있습니다.

여러 VPC로 확장 가능:

분산 제어 방식으로 AWS 네트워크 방화벽을 구현하기 위해서는 에서는 각각의 VPC에 대해 별도의 AWS 네트워크 방화벽들을 배포해야 합니다. 따라서 방화벽 도입에 필요한 비용을 충분히 고려하여야 합니다. AWS 네트워크 방화벽에 대한 가격정보는 여기에서 확인할 수 있습니다.
AWS Firewall Manager Service를 사용하면 여러 계정 및 VPC에 걸쳐 분산된 설치된 네트워크 방화벽을 한 곳에서 관리할 수 있습니다.

클라이언트 IP 주소 표시:

ELB와 IGW 사이에 AWS 네트워크 방화벽을 배치하면(그림2 참조), 실제 클라이언트 IP 주소를 인식할 수 있습니다.
2021년 여름에 소개된 Amazon VPC 라우팅 개선에 따라 ALB(네트워크 로드 밸런서에 인스턴스를 대상으로 적용할 경우에는 해당사항 없음)와 백엔드 서버 사이에 AWS 네트워크 방화벽을 도입할 수도 있습니다. 단, 이렇게 구성될 경우 AWS 네트워크 방화벽은 실제 클라이언트 IP를 인식할 수 없습니다.

AWS Gateway Load Balancer

방화벽으로의 트래픽 흐름:

AWS 네트워크 방화벽과 마찬가지로 게이트웨이 로드밸런서 엔드포인트 (Gateway Load Balancer Endpoint)역시 ‘Bump-in-the-Wire’ 형태로 구성되기에, VPC 서브넷 라우팅과 IGW ingress 라우팅 변경을 통해 네트워크 트래픽에 transparent 하게 도입됩니다. 이때도 역시 각 가용영역별로 게이트웨이 로드밸런서 엔드포인트를 위한 서브넷을 구성하여야 합니다. 이렇게 도입된 엔드포인트는 게이트웨이 로드밸런서(Gateway Load Balancer:GWLB)를 통해서 3rd party 방화벽이 설치된 별도의 VPC에 대한 트래픽 경로를 제공합니다.

트래픽을 검사하려면 우선 트래픽을 적절한 GWLB 엔드포인트로 라우팅합니다. 해당 엔드포인트로 전송된 트래픽은 GWLB를 거쳐서 연결된 3rd party 방화벽으로 전송됩니다. 트래픽에 대한 검사가 완료되면 다시 GLWB Endpoint로 전송되어 실제 서비스를 호스팅하는 Elastic Load Balancer로 전달 됩니다. 이렇게 트래픽이 흐르는동안에 트래픽이 프록시 되지 않으며 5-TUPLE 세부 정보(소스 IP, 목적지 IP, 소스 포트, 목적지 포트, 프로토콜)역시 변경되지 않습니다.

애플리케이션 유형 및 암/복호화:

처리되는 트래픽의 종류 및 복호화 지원은 GWLB를 통해 연결된 3rd party 벤더 방화벽에 따라서 달라질 수 있습니다. 복호화를 사용할 경우 개별 방화벽의 성능의 저하를 가져올 수 있습니다. 각 방화벽 벤더의 제품 기능에 대한 자세한 내용은 각 방화벽 벤더에 문의하십시오.

방화벽이 복호화를 수행하는 경우 방화벽에 관련 인증서를 배포해야 합니다. 참조로, AWS Certificate Manager(ACM)에서 생성된 인증서는 방화벽에 직접 배포할 수 없습니다. 3rd party 방화벽에 직접 인증서를 Import하기 위해서는 ACM이 아닌 외부에서 인증서를 생성하여야 합니다. 이후에 ACM에 해당 인증서를 추가하여 별도서비스를 위해서 사용할 수 있습니다. ACM을 통해서 인증서를 지원받을 수 있는 서비스에 대해서는 여기를 참조하십시오.

여러 VPC로 확장 가능:

하나의 GWLB에 서로 다른 VPC에 속한 여러개의 GWLB 엔드포인트를 연결할 수 있습니다. 만약 새로운 VPC가 추가되면, 추가된 새 VPC에 GWLB 엔드포인트만을 추가하면 됩니다. 이때, 실제 트래픽을 처리할 3rd party 방화벽에 대한 용량을 모니터링하고 필요에 따라 확장해야 합니다. GWLB 도입에 대한 모범 사례에 대한 추가적인 설명은 이 블로그 게시글을 참조합니다.

클라이언트 IP 주소 표시:

AWS 네트워크 방화벽과 동일한 규칙이 적용됩니다. ELB와 IGW 사이에 GWLB 엔드포인트를 배치하면(그림3 참조), 실제 클라이언트 IP 주소를 확인할 수 있습니다. 마찬가지로 2021년 여름에 소개된 Amazon VPC 라우팅 개선에 따라 ALB(네트워크 로드 밸런서에 인스턴스를 대상으로 적용할 경우에는 해당사항 없음)와 백엔드 서버 사이에 GWLB 엔드포인트를 도입할 수도 있습니다. 단, 이렇게 구성될 경우 GWLB를 통해 연결된 3rd party 방화벽은 실제 클라이언트 IP를 인식할 수 없습니다.

ELB Sandwich

방화벽으로의 트래픽 흐름:

AWS 네트워크 방화벽 및 게이트웨이 로드 밸런서 배포와 달리 ELB 샌드위치 모델은 Transparent 하지 않습니다. 즉 접속 경로상에 3rd party 방화벽이 직접 목적지로 추가됩니다(인터넷에 연결된 ELB의 Target으로 등록됨)

일반적으로, 인터넷에 연결된 ELB 는, 개별 애플리케이션별로 구분된 특정 포트를 통해서 방화벽에 트래픽을 전달합니다. 예를 들어, ALB 를 사용하고 있는 경우는, 각각의 애플리케이션 방화벽의 다른 포트로 연결되도록 경로기반 라우팅을 설정할 수 있습니다.( app1.example.com 의 경우는 8081 포트로, app2.example.com 의 경우는 8082포트로 구분하여 포워딩 하는 경우 등.)

방화벽은 이렇게 전달받은 트래픽을 검사한 후 해당 내부 ELB로 전송합니다.

애플리케이션 유형 및 암/복호화:

트래픽 복호화 기능은 3rd party 방화벽의 기능에 따라 달라집니다. 세부적인 내용에 대해서는 해당하는 3rd party 벤더와 확인하여야 합니다. 또는, 인터넷에 연결된 ELB에서 TLS를 종료한 후 암호화되지 않은 트래픽을 방화벽으로 전송할 수 있습니다.

여러 VPC로 확장 가능:

분산 모델에서는 각 VPC에 고유한 방화벽 세트를 구성할 필요가 있으며, 이는 비용에 영향을 미칠 수 있습니다. 따라서 3rd party 방화벽 벤더와 확인하여 비용정책을 수립합니다.

방화벽의 운영관리 관점에서, 선택한 방화벽 벤더가 여러대의 방화벽을 분산 배포하고 관리하기 위한 관리도구를 제공하는지 확인할 필요가 있습니다. 대규모 환경에서는 개별 애플리케이션들 마다필요한 정책들을 다수의 방화벽에 배포하여 통제하고 관리하는 것이 큰 과제가 될 수 있습니다. .

클라이언트 IP 주소 표시:

클라이언트 IP 에 대한 주소 보존은, 사용하는 인터넷 연결 ELB 의 종류에 따라서 다릅니다. NLB에서는 클라이언트 IP를 유지할 수 있습니다. 이 문서에서는 이를 실현하기 위해 무엇이 필요한지 자세히 설명합니다. ALB의 경우 패킷 내의 클라이언트 IP는 유지되지 않습니다. 대신 ALB는 클라이언트 IP를 X-Forwarded-For HTTP 헤더에 추가합니다.

중앙 집중 제어 아키텍처

분산제어 아키텍처를 사용할 수 없는 상황(예를 들어 애플리케이션 VPC에서 IGW를 허용하지 않는 정책을 가지고 있을 경우 등)에서는 일원화된 아키텍처를 검토할 수 있습니다. 다만 중앙 집중식으로 트래픽의 흐름을 구성하면 네트워크 아키텍처가 더욱 복잡해지고 특정 이슈가 발생할 경우 영향받는 범위가 넓어지게 됩니다(예를 들어 중앙집중 ELB의 구성이 잘못될 경우, 여러 백엔드 애플리케이션에 영향을 미칠 수 있습니다).

중앙 집중 제어 아키텍처에서 AWS 네트워크에 대한 모든 트래픽은 보안솔루션들이 모여있는 전초 VPC (edge VPC)를 통해서 전송됩니다. 거기에서 처리된 트래픽들은 이후 Transit Gateway 또는 PrivateLink를 통해 다른 VPC의 대상 애플리케이션으로 전송됩니다.

ELB가 다른 VPC에 속한 대상에게 트래픽을 전송할 때는, target type으로 반드시 IP 를 지정해야 합니다. NLB 엔드포인트와 PrivateLink 엔드포인트 모두 고정 IP를 가지고 있으므로 이 경우에 는 해당 IP가 ELB의 대상으로 지정될 수 있습니다.

대상이 ALB에 등록되어 있는 경우라면, ALB가 고정 IP를 가지고 있지 않기 때문에 ALB 상에서 고정 IP 주소를 취득하기 위해서 NLB 뒤에 배치할 필요가 있습니다. 이 블로그 게시글에서 해당 설정을 위한 세부적인 내용을 확인 할 수 있습니다.

아래에서 소개하는 방화벽 솔루션들은 분산제어 아키텍처에서 이미 살펴본 고려사항들이 동일하게 적용됩니다. 따라서 이미 기존에 설명한 고려사항들외에 중앙 집중식 관리가 될 경우에 추가적으로 고려되어야 할 사항들에 대해서 설명합니다.

참조하실 사항으로, Transit Gateway 또는 Private Link 모델을 사용하는 경우 성능 및 확장성에 차이가 있습니다. 따라서 검토 중인 각 서비스별로 성능 및 확장성을 확인하시려면 각 서비스별 문서를 확인 하십시오.

AWS WAF

이 모델에서는 트래픽이 AWS WAF에 등록된 ALB를 통해서 들어옵니다. 또는 ALB 앞에 CloudFront를 구축하고 CloudFront 배포지점을 WAF에 등록하여 보호할 수 도 있습니다.

ALB는 App VPC의 NLB 또는 Edge VPC의 PrivateLink VPC Endpoints 의 고정 IP 주소를 대상으로 해야 합니다.

AWS Network Firewall

분산 제어 모델의 경우와 마찬가지로 인터넷 연결 ELB(ALB, NLB 또는 클래식 로드 밸런서)에 도달하기 전에 IGW에서 라우팅을 조절하여 AWS 네트워크 방화벽 엔드포인트로 트래픽을 전달합니다.

AWS Gateway Load Balancer

트래픽 흐름은 네트워크 방화벽의 경우와 동일합니다.

다이어그램을 단순화 하기 위해서 GWLB를 호스팅하는 VPC와 3rd party 방화벽은 표시하지 않았습니다.

ELB Sandwich

중앙 집중 제어방식의 ELB Sandwich 아키텍처는 다른 아키텍처와 다릅니다. 일부 3rd party 방화벽 벤더는 IP 주소뿐만 아니라 호스트네임을 대상으로 트래픽을 전송할 수 있습니다. 이 경우에는 방화벽에서 Transit Gateway를 통해서 원격 VPC들에 속한 ALB와 NLB 모두에게 트래픽을 전달할 수 있습니다.

결론

위에서 설명한 아키텍처 구성들은, 인바운드 트래픽을 효과적으로 필터링 하기 위하여 보안 솔루션들의 네트워크 통합에 초점을 맞추고 있습니다. 솔루션을 결정할 때는 방화벽의 기능과 함께 방화벽이 요구되는 보안 고려사항들을 충족하는지 여부도 고려해야 합니다. 심층적인 방어를 구축하기 위해서는 Security Groups, NACLS, Amazon GuardDuty, Route 53 Resolver Firewall 등과 같은 다른 AWS 보안 서비스 및 제어와 결합하여 구성하여야 합니다.

– Tom Adamski, AWS Principal Solutions Architect

이 글은 AWS Networking & Content Delivery 블로그의 Design your firewall deployment for Internet ingress traffic flows을 황재훈 AWS 보안 분야 Technical Account Manager가 한국어로 번역한 글입니다.

Source: 인터넷을 통해 유입되는 트래픽을 보호하기 위한 AWS 기반 방화벽 배포방식 설계