퍼블릭 및 프라이빗 서브넷 설계

Virtual Private Cloud(VPC)는 AWS에서 논리적으로 격리된 네트워크입니다. 그 안에 단일 가용 영역에 연결된 IP 주소 범위인 서브넷을 나누어 구성합니다. VPC를 서브넷으로 어떻게 나누는지는 무엇이 무엇에 도달할 수 있는지를 결정하므로, 가장 중요하면서도 첫 번째로 내려야 할 보안 결정입니다.

퍼블릭 서브넷에는 인터넷 게이트웨이로 연결되는 경로가 있으므로 그 안의 리소스는 인터넷에서 접근할 수 있고 인터넷에 연결할 수도 있습니다. 프라이빗 서브넷에는 인터넷으로 직접 연결되는 경로가 없습니다. 이 구분은 서브넷 자체의 속성이 아니라 전적으로 라우팅 테이블에 의해 결정됩니다.

인터넷을 직접 상대해야 하는 리소스만 퍼블릭 서브넷에 배치해야 합니다. 예를 들면 로드 밸런서, NAT 게이트웨이, 배스천 대안이 있습니다. 이 계층을 최소화하면 공격 표면이 줄어듭니다. 애플리케이션 서버와 데이터베이스는 인터넷에서 직접 접근할 수 있는 퍼블릭 서브넷에 배치해서는 안 됩니다.

애플리케이션 서버, 데이터베이스, 내부 서비스는 프라이빗 서브넷에 배치하십시오. 퍼블릭 서브넷의 로드 밸런서를 통해 트래픽을 제공하고 NAT를 통해 업데이트를 위해 인터넷에 연결할 수 있지만, 외부에서 직접 주소를 지정할 수는 없으므로 노출이 크게 줄어듭니다.

일반적인 보안 레이아웃은 세 계층으로 구성됩니다. 로드 밸런서용 퍼블릭 서브넷, 컴퓨팅 리소스용 프라이빗 애플리케이션 서브넷, 데이터베이스용 프라이빗 데이터 서브넷입니다. 트래픽은 계층별로 안쪽으로 흐르며 각 계층은 바로 앞 계층에서 오는 연결만 허용합니다.

복원력을 위해 여러 가용 영역(AZ)에 서브넷을 복제하십시오. 각 AZ에 퍼블릭 서브넷과 프라이빗 서브넷을 한 쌍씩 두면 한 영역이 손실되어도 로드 밸런서와 워크로드가 계속 작동할 수 있습니다. 이는 안전하고 중복성 있는 설계를 지원하는 고가용성 방식입니다.

서브넷이 겹치지 않고 확장할 여유가 있도록 CIDR 블록을 계획하십시오. 신중하게 구성한 겹치지 않는 범위는 라우팅, 피어링, 보안 규칙 참조를 더 명확하게 만듭니다. 나중에 VPC 간 CIDR이 겹치면 피어링이 차단되고 연결이 복잡해지므로, 처음부터 주소 공간을 의도적으로 계획해야 합니다.

서브넷 설계는 민감한 워크로드를 격리할 수 있게 해 주므로 보안 제어로 작동합니다. 인터넷 경로가 없고 애플리케이션 계층에서 오는 인바운드 경로만 있는 데이터 서브넷은 보안 그룹을 추가하기 전부터 구조적으로 보호됩니다. 이 경계는 규칙만이 아니라 아키텍처가 적용합니다.

서브넷은 네트워크 ACL이 적용되는 위치를 정의합니다. NACL은 서브넷 경계에 연결되기 때문입니다. 잘 설계된 서브넷을 서브넷 수준의 NACL 및 리소스 수준의 보안 그룹과 함께 사용하면 SCS-C02 시험에서 요구하는 계층화된 심층 방어 네트워크 모델을 구성할 수 있습니다.

대표적인 실수는 데이터베이스를 퍼블릭 서브넷에 배치하거나 편의를 위해 프라이빗 인스턴스에 퍼블릭 IP를 부여하는 것입니다. 두 경우 모두 내부에 있어야 할 리소스가 노출됩니다. 기본적으로 프라이빗 배치를 선택하고, 퍼블릭 서브넷에 배치하는 모든 리소스에는 명확한 근거를 제시하십시오.

올바른 서브넷 설계는 안전한 VPC의 근간입니다. 인터넷을 상대하는 리소스와 내부 리소스를 분리하고 AZ 전체에 걸쳐 구성하면 네트워크 자체에 격리와 복원력을 구축할 수 있습니다. 게이트웨이, 라우팅 테이블, 방화벽은 그 기반 위에 구성됩니다.

서브넷 설계 원칙을 적용해 보십시오.

VPC는 가용 영역에 연결된 서브넷으로 나뉩니다. 서브넷은 라우팅 테이블이 인터넷 게이트웨이에 연결될 때만 퍼블릭이고, 그렇지 않으면 프라이빗입니다. 퍼블릭 서브넷에는 로드 밸런서와 NAT만 두고, 애플리케이션 및 데이터 계층은 프라이빗하게 배치하십시오. 여러 AZ에 걸쳐 다중 계층 패턴을 사용하고 겹치지 않는 CIDR을 계획하면 아키텍처 자체에 격리가 구축됩니다.