이 가이드에서는 Google Cloud의 Virtual Private Cloud(VPC) 설계에 대한 권장사항과 일반적인 엔터프라이즈 아키텍처를 소개합니다. 이 가이드는 Google Cloud 네트워킹 개념에 익숙한 클라우드 네트워크 설계자 및 시스템 설계자를 대상으로 합니다.
일반 원칙 및 첫 번째 단계
의사 결정권자, 타임라인, 사전 작업 파악
VPC 설계의 첫 번째 단계는 이해관계자의 요구사항을 해결하기 위해 필요한 의사 결정권자, 타임라인, 사전 작업을 파악하는 것입니다.
이해관계자로는 애플리케이션 소유자, 보안 설계자, 솔루션 설계자, 오퍼레이션 관리자가 있습니다. 이해관계자는 VPC 네트워크 설계 목적(프로젝트, 비즈니스 계열 또는 전체 조직)에 따라 변경될 수 있습니다.
사전 작업을 통해 팀은 VPC 네트워크 설계의 개념과 용어에 익숙해질 수 있습니다. 다음과 같은 유용한 문서를 활용하세요.
초기에 VPC 네트워크 설계 고려
Google Cloud에서 조직 설정 설계 시 초기 단계에 VPC 네트워크 설계를 고려하세요. 나중에 네트워크 세분화 방법 또는 워크로드 위치와 같은 기본 요소를 변경해야 하는 경우 조직에 방해가 될 수 있습니다.
다양한 VPC 네트워크 구성은 라우팅, 확장, 보안에 상당한 영향을 미칠 수 있습니다. 특정 고려사항을 신중히 계획하고 자세히 이해하면 점진적으로 증가하는 워크로드에 대한 견고한 아키텍처 기반을 구축하는 데 도움이 됩니다.
단순함 유지
관리가 용이하고 안정적이며 이해하기 쉬운 아키텍처를 구축하는 가장 좋은 방법은 VPC 네트워크 토폴로지 설계를 단순하게 유지하는 것입니다.
명확한 이름 지정 규칙 사용
이름 지정 규칙을 단순하고 직관적이며 일관성 있게 유지하세요. 그래야 관리자와 최종 사용자가 각 리소스의 용도, 배치 조건, 다른 리소스와의 차별점을 이해할 수 있습니다
긴 단어의 경우 일반적으로 인정되는 줄임말 또는 축약어를 사용할 수 있습니다. 최적의 가독성을 위해 가능하다면 친숙한 용어를 사용하세요.
이름 지정 규칙을 설정할 때 다음 예시에 설명된 요소를 고려해 보세요.
- 회사 이름: Acme Company:
acmeco - 비즈니스 단위: 인사 관리:
hr - 애플리케이션 코드: 보상 시스템:
comp - 리전 코드: northamerica-northeast1:
na-ne1, europe-west1:eu-we1 - 환경 코드:
dev,test,uat,stage,prod
예를 들어 인사 관리 부서의 보상 시스템을 위한 개발 환경 이름은 acmeco-hr-comp-eu-we1-dev로 지정할 수 있습니다.
다른 일반적인 네트워킹 리소스는 다음과 같은 패턴을 사용해 보세요.
VPC 네트워크
구문:{company name}-{description(App or BU)-label}-{environment-label}-{seq#}
예시:acmeco-hr-dev-vpc-1서브넷
문법:{company-name}-{description(App or BU)-label}-{region-label}-{environment-label}-{subnet-label}
예:acmeco-hr-na-ne1-dev-vpc-1-subnet-1
참고: 서브넷에 한 영역의 리소스만 포함된 경우 'region-label' 대신 'zone-label'을 사용할 수 있습니다.방화벽 규칙
구문:{company-name}-{description(App or BU)-label}{source-label}-{dest-label}-{protocol}-{port}-{action}
예시:acmeco-hr-internet-internal-tcp-80-allow-ruleIP 경로
구문:{priority}-{VPC-label}-{tag}-{next hop}
예시:1000-acmeco-hr-dev-vpc-1-int-gw
주소 및 서브넷
커스텀 모드 VPC 네트워크 사용
첫 프로젝트를 시작할 때는 기본 네트워크로 default라는 자동 모드 VPC 네트워크를 사용합니다. 자동 모드 네트워크는 RFC 1918 주소 범위의 예측 가능한 집합을 사용하여 기본 IP 범위가 각 Google Cloud 리전의 /20 CIDR인 서브넷 및 해당 서브넷 경로를 자동으로 만듭니다. 또한 default 네트워크에는 미리 입력된 방화벽 규칙이 자동으로 포함됩니다.
초기 탐색에는 자동 모드 네트워크가 유용하지만 대부분의 프로덕션 환경에는 커스텀 모드 VPC 네트워크가 더 적합합니다.
다음과 같은 이유로 기업은 VPC 네트워크를 처음부터 커스텀 모드로 사용하는 것이 좋습니다.
- 커스텀 모드 VPC 네트워크가 기존 IP 주소 관리 체계와 더 잘 통합됩니다. 모든 자동 모드 네트워크가 내부 IP 범위의 동일한 집합을 사용하므로 온프레미스 기업 네트워크에 연결될 때 자동 모드 IP 범위가 겹칠 수 있습니다.
- VPC 네트워크 피어링을 사용하여 두 개의 자동 모드 VPC 네트워크를 함께 연결할 수 없습니다. 해당 서브넷이 동일한 기본 IP 범위를 사용하기 때문입니다.
- 자동 모드 서브넷은 모두 네트워크와 동일한 이름을 갖습니다. 커스텀 모드 서브넷을 설명하는 고유한 이름을 사용하면 VPC 네트워크를 더 이해하기 쉽고 유지 가능하게 구성할 수 있습니다.
- 새로운 Google Cloud 리전이 도입되면 자동 모드 VPC 네트워크가 해당 리전에서 새 서브넷을 자동으로 가져옵니다. 커스텀 모드 VPC 네트워크는 지정된 경우에만 새 서브넷을 가져옵니다. 이는 주권 및 IP 주소 관리 측면에서 모두 중요합니다.
리소스가 없는 경우 default 네트워크를 삭제할 수 있습니다. VPC 네트워크를 삭제하려면 먼저 이 네트워크에 종속된 모든 리소스(가상 머신(VM) 인스턴스 포함)를 삭제해야 합니다.
자동 모드 VPC 네트워크와 커스텀 모드 VPC 네트워크 간의 차이점에 대한 자세한 내용은 VPC 네트워크 개요를 참조하세요.
애플리케이션을 주소 범위가 더 큰 몇 개의 서브넷으로 그룹화
다양한 이유로 일부 기업 네트워크는 많은 작은 주소 범위로 분리됩니다. 예를 들어 이는 애플리케이션을 식별 또는 격리하거나, 더 작은 브로드캐스트 도메인을 유지하기 위한 조치일 수 있습니다.
그러나 애플리케이션의 유형이 같은 경우 운영하려는 리전에서 더 큰 주소 범위를 사용하여 더 적은 수의 관리가 용이한 서브넷으로 그룹화하는 것이 좋습니다.
서브넷 마스크가 사용되는 다른 네트워킹 환경과 달리 Google Cloud는 소프트웨어 정의 네트워킹(SDN) 방식을 통해 전역 VPC 네트워크의 모든 VM을 완전 메시형으로 연결합니다. 서브넷의 수는 라우팅 동작에 영향을 미치지 않습니다.
특정 라우팅 정책이나 방화벽 규칙을 적용하기 위해 서비스 계정이나 네트워크 태그를 사용해도 됩니다. Google Cloud에서 ID는 서브넷 IP 주소만을 기준으로 하지 않습니다.
Cloud NAT, 비공개 Google 액세스, VPC 흐름 로그, 별칭 IP 범위를 비롯한 일부 VPC 기능은 서브넷별로 구성됩니다. 이러한 기능에 대한 세부적인 제어가 필요한 경우에는 서브넷을 추가하세요.
단일 VPC 네트워크 및 공유 VPC
공통적인 요구사항이 있는 리소스에 대해 단일 VPC로 시작
여러 작업 그룹의 관리에 공유 VPC 사용
서브넷 수준에서 네트워크 사용자 역할 부여
리소스에 여러 네트워크 인터페이스가 필요한 경우 하나의 호스트 프로젝트 사용
리소스에 단일 프로젝트 할당량을 초과하는 요구사항이 있을 경우 여러 호스트 프로젝트 사용
각 VPC별로 개별적인 관리 정책이 필요한 경우 여러 호스트 프로젝트 사용
공통적인 요구사항이 있는 리소스에 대해 단일 VPC로 시작
여러 간단한 사용 사례의 경우에는 필요한 기능을 대부분 제공하는 단일 VPC 네트워크를 사용하면 다른 복잡한 방식과 비교할 때 생성, 유지보수, 이해가 더 쉽습니다. 공통적인 요구사항과 특성이 있는 리소스를 단일 VPC 네트워크로 그룹화하여 잠재적인 문제를 격리하는 VPC 네트워크 경계를 설정할 수 있습니다.
이 구성의 예시는 단일 프로젝트, 단일 VPC 네트워크 참조 아키텍처를 참조하세요.
VPC 네트워크를 추가해야 하는 요인으로는 확장, 네트워크 보안, 재무적 고려사항, 운영 요구사항, ID 및 액세스 관리(IAM) 등이 있습니다.
여러 작업 그룹의 관리에 공유 VPC 사용
여러 팀으로 구성된 조직의 경우 공유 VPC를 사용하면 아키텍처 측면에서 단순한 단일 VPC 네트워크를 여러 작업 그룹으로 확장할 수 있습니다. 이와 같이 단순한 방식으로 단일 공유 VPC 네트워크를 사용하는 단일 공유 VPC 호스트 프로젝트를 배포한 후 팀 서비스 프로젝트를 호스트 프로젝트 네트워크에 연결할 수 있습니다.
이 구성에서 모든 네트워킹 리소스에 대한 네트워크 정책 및 제어는 중앙 집중화되므로 관리가 더 용이합니다. 서비스 프로젝트 부서는 비네트워크 리소스를 구성하고 관리하므로 조직 내 여러 팀의 책임을 명확하게 구분할 수 있습니다.
이러한 프로젝트의 리소스는 내부 IP 주소를 사용하여 프로젝트 경계를 넘어 보다 안전하고 효율적으로 서로 통신할 수 있습니다. 중앙 호스트 프로젝트에서 공유 네트워크 리소스(예: 서브넷, 경로, 방화벽 등)를 관리하기 때문에 여러 프로젝트에 전반에 걸쳐 일관된 네트워크 정책을 적용할 수 있습니다.
이 구성의 예시는 단일 호스트 프로젝트, 여러 서비스 프로젝트, 단일 공유 VPC 참조 아키텍처를 참조하세요.
서브넷 수준에서 네트워크 사용자 역할 부여
중앙 집중식 공유 VPC 관리자는 서브넷 수준에서 보다 세분화된 서비스 프로젝트 승인을 위해 또는 호스트 프로젝트 수준에서 모든 서브넷에 대해 IAM 구성원에게 네트워크 사용자(networkUser) 역할을 부여할 수 있습니다.
최소 권한의 원칙에 따라 서브넷 수준의 네트워크 사용자 역할은 연결된 사용자, 서비스 계정 또는 그룹에 부여하는 것이 좋습니다.
서브넷은 리전별로 구분되므로 이러한 세부적인 제어를 통해 각 서비스 프로젝트에서 리소스 배포를 위해 사용할 수 있는 리전을 지정할 수 있습니다.
공유 VPC 아키텍처를 사용하면 여러 공유 VPC 호스트 프로젝트를 조직 내에 유연하게 배포할 수도 있습니다. 그런 다음 각 공유 VPC 호스트 프로젝트를 단일 또는 여러 공유 VPC 네트워크에 맞게 조정할 수 있습니다. 이 구성에서는 환경별로 서로 다른 정책을 쉽게 적용할 수 있습니다.
자세한 내용은 네트워킹의 IAM 역할을 참조하세요.
리소스에 여러 네트워크 인터페이스가 필요한 경우 하나의 호스트 프로젝트 사용
예를 들어 여러 네트워크 인터페이스가 있는 VM 인스턴스와 같이 격리된 여러 VPC에 리소스를 배포해야 하는 서비스 프로젝트가 있다면 호스트 프로젝트에는 서비스를 제공하는 모든 VPC 네트워크가 포함되어 있어야 합니다. 이는 하나의 서비스 프로젝트를 하나의 호스트 프로젝트에만 연결할 수 있기 때문입니다.
리소스에 단일 프로젝트 할당량을 초과하는 요구사항이 있으면 여러 호스트 프로젝트 사용
프로젝트 할당량 범위 내에서 모든 VPC 네트워크의 총 리소스 요구사항을 충족할 수 없는 경우, 여러 공유 VPC 네트워크가 포함된 단일 호스트 프로젝트 대신 호스트 프로젝트당 단일 공유 VPC 네트워크가 있는 아키텍처를 사용합니다. 단일 호스트 프로젝트를 사용하려면 호스트 프로젝트에 여러 VPC 네트워크가 필요하고 프로젝트 수준에서 할당량이 적용되므로 확장 요구사항을 평가하는 것이 중요합니다.
이러한 구성의 예시는 여러 호스트 프로젝트, 여러 서비스 프로젝트, 단일 공유 VPC 참조 아키텍처를 참조하세요.
각 VPC 네트워크별로 개별적인 관리 정책이 필요한 경우 여러 호스트 프로젝트 사용
각 프로젝트에는 자체 할당량이 있으므로 총 리소스를 확장하기 위해서는 VPC 네트워크마다 별도의 공유 VPC 호스트 프로젝트를 사용해야 합니다. 이렇게 하면 IAM 권한도 프로젝트 수준에서 구현되므로 각 VPC 네트워크가 네트워킹 및 보안 관리를 위한 개별적인 IAM 권한을 갖게 됩니다. 예를 들어 두 개의 VPC 네트워크(VPC 네트워크 A와 VPC 네트워크 B)를 동일한 호스트 프로젝트에 배포하면 네트워크 관리자(networkAdmin) 역할이 두 VPC 네트워크에 모두 적용됩니다.
여러 VPC 네트워크 생성 여부 결정
VPC 네트워크 할당량을 프로젝트에 매핑하기 위해 프로젝트별로 하나의 VPC 네트워크 만들기
공통 VPC 네트워크에서 공유 서비스를 사용하여 각 자율 팀별로 하나의 VPC 네트워크 만들기
독립적인 IAM 제어를 위해 여러 프로젝트에 여러 VPC 네트워크 만들기
자체 VPC 네트워크에서 민감한 정보 격리
프로젝트당 하나의 VPC 네트워크를 만들어 VPC 리소스 할당량을 프로젝트에 매핑
할당량은 프로젝트 또는 네트워크 수준에서 적용되는 제약조건입니다. 모든 리소스에는 예기치 않은 리소스 사용을 방지하기 위한 초기 기본 할당량이 있습니다. 그러나 다양한 요인으로 인해 할당량 상향 조정이 필요할 수 있습니다. 대부분의 리소스에서 추가 할당량을 요청할 수 있습니다.
기본 VPC 리소스 할당량 이상으로 확장해야 하는 경우 프로젝트별로 하나의 VPC 네트워크를 만드는 것이 좋습니다. 이렇게 하면 동일한 프로젝트에서 VPC 네트워크를 조합하는 대신 각 VPC 네트워크별로 프로젝트 수준 할당량 상향 조정을 쉽게 매핑할 수 있습니다.
한도는 총 시스템 리소스를 보호하도록 설계되었습니다. 한도는 보통 쉽게 늘릴 수 없지만, Google Cloud 지원팀과 영업팀이 고객과 협업하여 한도를 일부 늘릴 수 있습니다.
현재 값은 VPC 리소스 할당량 및 한도를 참조하세요.
Google 지원은 확장 한도를 늘릴 수 있지만 확장 요구사항을 충족하기 위해 여러 VPC 네트워크를 빌드해야 하는 경우가 있을 수 있습니다. VPC 네트워크를 한도 이상으로 확장해야 하는 경우 이러한 요구사항을 충족하는 가장 좋은 방법에 대해 Google Cloud 영업팀 및 지원팀에 문의하세요.
공통 VPC 네트워크에서 공유 서비스를 사용하여 각 팀별로 하나의 VPC 네트워크 만들기
일부 대기업 배포에서는 각 VPC 네트워크에 대한 완전한 제어를 필요로 하는 자율적인 팀들이 포함되기도 합니다. 공통 VPC 네트워크에서 공유 서비스(예: 애널리틱스 도구, CI/CD 파이프라인, 빌드 머신, DNS/디렉터리 서비스)를 사용하여 각 비즈니스 단위별로 VPC 네트워크를 만들어 이러한 요구사항을 충족할 수 있습니다. 공유 서비스의 공통 VPC 네트워크를 만드는 방법에 대한 자세한 내용은 공유 서비스 섹션을 참조하세요.
독립적인 IAM 제어를 위해 여러 프로젝트에 VPC 네트워크 만들기
VPC 네트워크는 다음 역할을 포함하여 세분화된 프로젝트 수준 ID 및 액세스 관리(IAM) 제어 권한을 가진 프로젝트 수준 리소스입니다.
networkAdminsecurityAdminnetworkUsernetworkViewer
기본적으로 IAM 제어는 프로젝트 수준에서 배포되고 각 IAM 역할은 프로젝트의 모든 VPC 네트워크에 적용됩니다.
VPC 네트워크별로 독립적인 IAM 제어가 필요한 경우 다양한 프로젝트에 여러 VPC 네트워크를 만드세요.
VM 인스턴스, 디스크, 이미지와 같은 특정 Compute Engine 리소스로 IAM 역할 범위를 지정해야 할 경우, Compute Engine 리소스에 대한 IAM 정책을 사용합니다.
자체 VPC에서 민감한 정보 격리
규정 준수 이니셔티브, 민감한 정보, HIPAA 또는 PCI-DSS와 같은 규정 준수 표준이 적용되는 규제가 심한 데이터를 처리하는 기업의 경우 추가 보안 조치를 취해야 할 수 있습니다. 보안을 강화하고 더 쉽게 규정 준수를 입증하는 한 가지 방법은 이러한 환경을 각각 자체 VPC 네트워크로 격리하는 것입니다
여러 VPC 네트워크 연결
비용, 성능 및 보안 니즈를 충족하는 VPC 연결 방법 선택
리소스 한도를 초과하지 않을 경우 VPC 네트워크 피어링 사용
비공개 IP 주소 통신이 필요 없는 경우 외부 라우팅 사용
Cloud VPN을 사용하여 전체 피어링 그룹 한도를 초과하는 VPC 네트워크 연결
Cloud Interconnect를 사용하여 온프레미스 기기를 통한 VPC 네트워크 간 트래픽 제어
다중 NIC 가상 어플라이언스를 사용하여 클라우드 기기를 통한 VPC 네트워크 간 트래픽 제어
여러 VPC 네트워크가 서로가 아닌 공통 리소스에 액세스해야 하는 경우 공유 서비스 만들기
비용, 성능, 보안 요구사항을 충족하는 VPC 연결 방법 선택
여러 VPC 네트워크 구현을 결정했다면 다음 단계는 해당 VPC 네트워크를 연결하는 것입니다. VPC 네트워크는 Google의 Andromeda SDN 내에서 격리된 테넌트 공간이지만 몇 가지 방법으로 서로 통신할 수 있습니다. 이후 섹션에서는 VPC 연결 방법을 선택하는 권장사항을 설명합니다.
다음 표에는 각각의 장점과 단점이 요약되어 있으며, VPC 연결 방법을 선택하는 권장사항은 다음 섹션에서 설명합니다.
| 장점 | 단점 | |
|---|---|---|
| VPC 네트워크 피어링 |
|
|
| 외부 라우팅(공개 IP 또는 NAT 게이트웨이) |
|
|
| Cloud VPN |
|
|
| Cloud Interconnect - 전용 또는 파트너 |
|
|
| 여러 개의 네트워크 인터페이스(다중 NIC) |
|
|
리소스 한도를 초과하지 않을 경우 VPC 네트워크 피어링 사용
VPC 네트워크를 연결해야 하고 단일 공유 VPC를 사용할 수 없는 경우 직접 연결된 모든 피어에 필요한 리소스의 합계가 VM 인스턴스, 피어링 연결 수, 내부 전달 규칙의 한도를 초과하지 않는 한 VPC 네트워크 피어링을 사용하는 것이 좋습니다
VPC 네트워크 피어링을 사용하면 동일한 프로젝트 또는 동일한 조직에 속해 있는지 여부와 무관하게 Google SDN을 통해 두 개의 VPC 네트워크를 내부에서 서로 연결할 수 있습니다. VPC 네트워크 피어링은 각 피어 간의 제어 영역과 흐름 전파를 병합하여 모든 VM이 동일한 VPC 네트워크에 있는 것처럼 동일한 전달 특성을 허용합니다. VPC 네트워크를 피어링하면 모든 서브넷, 별칭 IP 범위, 내부 전달 규칙에 액세스할 수 있으며 각 VPC 네트워크는 자체의 분산형 방화벽을 유지합니다. VPC 네트워크 피어링은 비전환성입니다.
다음과 같은 이유로 VPC 네트워크를 연결할 때는 VPC 네트워크 피어링을 사용하는 것이 좋습니다.
- 게이트웨이 병목 현상이 없음—VM이 동일한 VPC 네트워크에 있는 것처럼 피어 전체에 트래픽이 전달됩니다.
- 결제—추가 요금이 없습니다. VM이 동일한 VPC 네트워크에 있는 것처럼 요금이 청구됩니다.
비공개 IP 주소 통신이 필요 없는 경우 외부 라우팅 사용
비공개 IP 주소 통신이 필요 없는 경우 외부 IP 주소를 사용한 외부 라우팅 또는 NAT 게이트웨이를 사용합니다
VPC가 배포되면 Google의 기본 인터넷 게이트웨이 경로가 우선 순위 1000으로 프로비저닝됩니다. 이 경로가 있고 VM에 외부 IP 주소가 제공되면 VM은 Google의 인터넷 게이트웨이를 통해 아웃바운드(이그레스) 트래픽을 전송할 수 있습니다. 또한 Google의 많은 공용 로드 밸런싱 제품 중 하나의 백그라운드에서 서비스를 배포할 수 있으며, 이를 통해 외부에서 서비스에 연결할 수 있습니다.
외부에서 주소가 지정된 VM은 리전 및 네트워크 서비스 등급에 관계없이 Google의 백본을 통해 비공개로 서로 통신합니다. Google Cloud 방화벽 규칙을 사용하여 VM로 들어오는 외부 인바운드(인그레스) 트래픽을 제어합니다.
외부 라우팅은 확장에는 도움이 되는 선택이지만 공개 라우팅이 비용에 영향을 미치는 방법을 이해하는 것이 중요합니다. 자세한 내용은 네트워크 가격 책정 문서를 참조하세요.
Cloud VPN을 사용하여 총 피어링 그룹 한도를 초과하는 VPC 네트워크 연결
HA VPN은 엔드포인트 집합 사이에 IPsec 터널을 만들어 VPC 네트워크를 연결하는 관리형 서비스를 제공합니다. 커스텀 공지 모드로 Cloud Router를 구성하면 이 문서의 뒷부분에서 설명하는 VPC 네트워크와 허브 및 스포크 토폴로지에서 전환 라우팅을 사용 설정할 수 있습니다. Network Connectivity Center를 사용하면 HA VPN 터널을 Cloud VPN 문서에 설명된 대로 온프레미스 네트워크 간의 전송 네트워크로 사용할 수 있습니다.
Cloud VPN은 대규모 MTU를 지원하지 않습니다. 자세한 내용은 MTU 고려사항을 참조하세요.
Cloud Interconnect를 사용하여 온프레미스 기기를 통한 VPC 네트워크 간 트래픽 제어
Cloud Interconnect를 활용하면 가용성이 높고 지연 시간이 짧은 연결을 통해 온프레미스 네트워크를 Google 네트워크로 확장할 수 있습니다. Dedicated Interconnect를 사용하여 Google에 직접 연결하거나 Partner Interconnect를 사용하여 지원되는 서비스 제공업체를 통해 Google에 연결할 수 있습니다.
Dedicated Interconnect는 Google과 코로케이션 제공업체 또는 온프레미스 위치 사이에 고속 L2 서비스를 제공합니다. 이렇게 하면 온프레미스 라우팅 장비를 사용하여 VPC 네트워크 간에 라우팅하고 기존 온프레미스 보안 및 검사 서비스를 사용하여 VPC 네트워크 간의 모든 트래픽을 필터링할 수 있습니다. 온프레미스 시스템을 통한 왕복이 추가되므로 두 VPC 네트워크 간의 모든 트래픽에 대한 지연 시간이 길어집니다.
Partner Interconnect도 유사한 기능을 제공하며, 이 외에 L3에서 제공업체와 직접 피어링하고 VPC 네트워크 간 제공업체 경로를 지정할 수 있습니다. 이렇게 하면 NAT 기기나 VPN 터널 없이도 온프레미스 네트워크 및 Google Cloud VPC 네트워크에서 내부 IP 주소에 액세스할 수 있습니다.
많은 기업 보안 어플라이언스를 여러 네트워크 인터페이스가 있는 VM을 사용해 Google Cloud에서 사용할 수 있으므로, 기업 정책 때문에 모든 트래픽이 온프레미스 어플라이언스를 통과해야 하는 극히 일부의 경우를 제외하고는 Cloud Interconnect를 통한 VPC 네트워크 간의 트래픽을 라우팅할 필요가 없습니다.
가상 어플라이언스를 사용하여 클라우드 기기를 통한 VPC 네트워크 간 트래픽 제어
다중 네트워크 인터페이스 VM을 사용하면 VM 인스턴스가 VPC 네트워크 간의 통신을 브리지할 수 있기 때문에 다중 네트워크 인터페이스 VM은 추가 보안 또는 서비스가 필요한 VPC 네트워크에 일반적으로 사용됩니다.
VM은 연결된 각 VPC 네트워크의 인터페이스 하나만 가질 수 있습니다. VM을 여러 VPC 네트워크에 배포하려면 VM이 연결되는 각 VPC 네트워크에 적절한 IAM 권한이 있어야 합니다.
다중 NIC VM을 배포할 때는 다음 특성에 유의하세요.
- 다중 NIC VM은 최대 8개의 인터페이스를 가질 수 있습니다.
- 인터페이스의 서브넷 IP 범위는 겹치지 않아야 합니다.
여러 VPC 네트워크가 서로가 아닌 공통 리소스에 액세스해야 하는 경우 공유 서비스 생성
VPC 네트워크는 전역 연결 범위의 전체 메시를 제공합니다. 이런 이유로 동일한 VPC 네트워크에 상주하는 공유 서비스 및 지속적 통합 파이프라인에는 연결성과 관련하여 특별한 요구사항이 없습니다. 즉, 기본적으로 연결 가능합니다. 공유 VPC는 이 개념을 확장하여 공유 서비스가 격리된 프로젝트에 상주하도록 허용하는 동시에 다른 서비스나 소비자에 대한 연결성을 제공합니다.
공유 서비스에 대한 접근 방법에는 Private Service Connect, VPC 네트워크 피어링, Cloud VPN이 포함됩니다. 어떤 이유로든 사용할 수 없는 경우 Private Service Connect를 사용합니다. 총 리소스 한도를 초과하지 않고 모든 서비스에 엔드포인트를 설정하지 않는 경우 VPC 네트워크 피어링을 사용하여 공유 서비스 VPC 네트워크에 연결할 수 있습니다. Cloud VPN을 사용하여 총 피어링 그룹 한도를 초과하는 공유 서비스 VPC 네트워크에 연결할 수도 있습니다.
Private Service Connect를 사용하면 소비자 네트워크에서 특별한 엔드포인트를 만들어 한 네트워크에서 호스팅되는 서비스를 다른 네트워크의 VM에서 사용할 수 있습니다. 그러면 Private Service Connect 구성이 두 네트워크 간에 해당 서비스에 대한 트래픽을 채널화합니다.
소비자는 VPC 네트워크를 벗어나거나 외부 IP 주소를 사용하지 않고 자체 내부 IP 주소를 사용하여 서비스에 액세스할 수 있습니다. 트래픽은 전적으로 Google Cloud 내에 유지됩니다. Private Service Connect는 소비자 및 프로듀서 사이의 서비스 중심 액세스를 제공하여 서비스 액세스 방법을 세밀하게 제어합니다.
VPC 네트워크 피어링 모델에서 각 VPC 네트워크는 공통 공유 서비스 VPC 네트워크와 피어링 관계를 만들어 연결성을 제공합니다. VPC 네트워크 피어링을 사용하려면 확장을 고려해야 하는데, 이는 확장 한도가 모든 피어의 총 리소스 사용량에 적용되기 때문입니다.
VPC 네트워크 피어링을 비공개 서비스 액세스 및 Service Networking API와 함께 사용할 수 있습니다. Service Networking API를 사용하면 같은 조직이나 다른 조직의 고객이 제공된 서비스를 사용할 수 있게 하거나 VPC 네트워크 피어링을 사용하여 연결할 IP 주소 범위를 선택할 수 있게 할 수 있습니다.
Cloud VPN은 또 다른 대안입니다. Cloud VPN은 관리형 IPsec 터널을 통해 연결 가능성을 설정하므로 VPC 네트워크 피어링의 총 한도가 없습니다. Cloud VPN은 연결에 VPN 게이트웨이를 사용하며 IPsec 피어의 총 리소스 사용량을 고려하지 않습니다. Cloud VPN의 단점으로는 증가된 비용(VPN 터널 및 트래픽 이그레스), 터널 유지관리에 필요한 관리 오버헤드, IPsec의 성능 오버헤드가 있습니다.
하이브리드 설계: 온프레미스 환경 연결
하이브리드 연결 니즈가 확인되어 대역폭, 성능, 보안 요구사항을 충족하는 솔루션을 선택했으면 이 솔루션을 VPC 설계에 통합하는 방법을 고려해 보세요.
공유 VPC를 사용하면 개별 프로젝트를 사용할 필요성이 줄어들어 같은 솔루션을 복제할 수 있습니다. 예를 들어 리전이나 서비스 프로젝트에 관계없이 Cloud Interconnect 솔루션을 공유 VPC로 통합하면 모든 VM에서 Cloud Interconnect 연결에 액세스할 수 있습니다.
동적 라우팅
동적 라우팅은 HA VPN, 기본 VPN, Dedicated Interconnect, Partner Interconnect를 포함한 모든 하이브리드 솔루션에서 사용할 수 있습니다. 동적 라우팅은 Google의 Cloud Router를 Border Gateway Protocol(BGP) 스피커로 사용하여 동적 외부 BGP(eBGP) 라우팅을 제공합니다.
Cloud Router는 데이터 영역에 있지 않으며 SDN에서 경로를 만들기만 합니다.
동적 라우팅은 태그를 사용하지 않고 Cloud Router는 학습된 프리픽스를 절대 재공지하지 않습니다.
각 VPC 네트워크에서 Cloud Router의 두 가지 모드(리전 또는 전역) 중 하나를 사용하도록 설정할 수 있습니다. 리전 라우팅을 선택한 경우 Cloud Router는 Cloud Router가 배포된 리전에 함께 상주하는 서브넷만 공지합니다. 반면에 전역 라우팅은 리전에 관계없이 지정된 VPC 네트워크의 모든 서브넷을 공지하지만 리전 밖에서 공지되고 학습된 경로에 페널티를 적용합니다. 이렇게 하면 항상 로컬 상호 연결을 우선 사용하여 리전 내에 균형이 유지되고, 페널티는 200밀리초와 리전 간의 TTL 값의 합과 같은 페널티 측정항목(MED)을 추가하여 계산됩니다.
정적 라우팅
정적 라우팅은 기본 VPN에서만 제공되며, Cloud VPN 터널을 가리키는 다음 홉 경로를 설정하는 기능을 제공합니다.
기본적으로 정적 경로는 리전에 관계없이 네트워크의 모든 VM에 적용됩니다. 정적 라우팅을 사용하면 네트워크 관리자가 인스턴스 태그를 사용하여 어떤 VM에 경로를 적용할지 선택적으로 설정할 수 있습니다. 이때 태그는 경로를 만들 때 지정할 수 있습니다.
정적 경로는 VPC 네트워크 내에서 동일한 경로 우선순위로 전역적으로 적용됩니다. 따라서 여러 리전에 같은 우선순위의 동일한 프리픽스가 적용된 여러 터널이 있는 경우 VM은 모든 터널에서 5-튜플 해시 기반의 ECMP를 사용하게 됩니다. 이 설정을 최적화하려면 각 리전에 대한 인스턴스 태그를 참조하고 그에 따라 여러 선호 경로를 생성하여 리전 내 기본 경로를 만들 수 있습니다.
Google의 기본 인터넷 게이트웨이를 통과하는 아웃바운드(이그레스) 트래픽을 원하지 않으면 선호하는 기본 정적 경로를 설정하여 모든 트래픽을 터널을 통해 온프레미스로 다시 전송할 수 있습니다.
연결 VPC 네트워크를 사용하여 여러 VPC 네트워크로 허브 및 스포크 아키텍처 확장
여러 VPC 네트워크에서 허브 및 스포크 아키텍처를 확장해야 하는 경우 전용 VPC 네트워크에서 중앙 집중식 하이브리드 연결을 구성하고 커스텀 공지 경로를 사용하여 다른 프로젝트로 피어링합니다. 이를 통해 정적 또는 동적으로 학습된 경로를 피어 VPC 네트워크로 내보내면 중앙 집중식 구성을 제공하여 VPC 네트워크 설계로 확장할 수 있습니다.
이는 각 개별 VPC 네트워크에서 VPN 터널 또는 VLAN 연결을 사용하는 기존 하이브리드 연결 배포와는 대조적입니다.
다음 다이어그램은 VPC 네트워크 피어링 커스텀 경로를 사용한 중앙 집중식 하이브리드 연결을 보여줍니다.
네트워크 보안
명확한 보안 목표 확인
외부 액세스 제한
민감한 정보의 서비스 경계 정의
가능한 경우 Google Cloud 기반 방화벽 규칙으로 트래픽 관리
가능한 경우 더 적은 수의 광범위한 방화벽 규칙 집합 사용
가능한 경우 서비스 계정을 사용하여 VM 격리
태그 사용 시 자동화를 사용하여 보안 정책 모니터링
추가 도구를 사용하여 앱을 안전하게 보호
Google Cloud는 인프라와 서비스 전반에서 데이터 센터의 물리적 보안과 커스텀 보안 하드웨어부터 전담 연구팀에 이르기까지 강력한 보안 기능을 제공합니다. 그러나 Google Cloud 리소스 보호는 Google과 사용자 공동의 책임입니다. 사용자는 앱과 데이터를 보호하기 위한 적절한 조치를 취해야 합니다.
명확한 보안 목표 확인
클라우드 기반 또는 클라우드 지원 보안 제어를 평가하기 전에 모든 이해관계자들이 기본적으로 동의하는 제품의 명확한 보안 목표부터 파악해야 합니다. 이러한 목표는 달성 가능성, 문서화, 반복에 초점을 맞춰 개발 과정 전반에 걸쳐 참조하고 개선할 수 있어야 합니다.
외부 액세스 제한
VPC 네트워크를 사용하는 Google Cloud 리소스를 만들 때 리소스가 있는 네트워크와 서브넷을 선택합니다. 리소스에는 서브넷과 연결된 IP 범위 중 하나에서 내부 IP 주소가 할당됩니다. 방화벽 규칙이 허용하면 VPC 네트워크의 리소스는 내부 IP 주소를 통해 상호 통신할 수 있습니다.
인터넷 액세스는 인터넷 액세스가 필요한 리소스로만 제한합니다. 비공개 내부 IP 주소만 있는 리소스도 Private Service Connect 또는 비공개 Google 액세스를 통해 많은 Google API 및 서비스에 액세스할 수 있습니다. 비공개 액세스는 리소스가 공개 인터넷으로부터 격리된 상태를 유지하면서 주요 Google 및 Google Cloud 서비스와 상호작용할 수 있게 해줍니다.
또한 조직 정책을 사용하면 외부 IP 주소를 사용할 수 있는 리소스를 추가로 제한할 수 있습니다.
그러나 인터넷 액세스를 차단하기 전에 VM 인스턴스에 미치는 영향을 신중히 고려하세요. 인터넷 액세스를 차단하면 데이터 무단 반출 위험을 줄일 수 있지만 소프트웨어 업데이트, 타사 API, 서비스를 위한 필수 트래픽을 포함한 정상적인 트래픽도 차단될 수 있습니다. 인터넷 액세스가 차단되면 Cloud VPN 터널, Cloud Interconnect 연결 또는 IAP(Identity-Aware Proxy)를 통해 연결된 온프레미스 네트워크를 통해서만 VM 인스턴스에 액세스할 수 있습니다. Cloud NAT를 사용하면 공개 인그레스 연결을 노출하지 않고도 가상 머신에서 특정 필수 트래픽용 인터넷에 대한 이그레스 연결을 시작할 수 있습니다.
민감한 정보의 서비스 경계 정의
민감한 정보가 포함된 워크로드의 경우 VPC 서비스 제어를 사용하면 VPC 리소스와 Google 관리 서비스 주위에 서비스 경계를 구성하고 경계 범위 간의 데이터 이동을 제어할 수 있습니다. VPC 서비스 제어를 사용하면 프로젝트와 온프레미스 네트워크를 단일 경계로 그룹화하여 Google 관리형 서비스를 통한 데이터 액세스를 차단할 수 있습니다. 서비스 경계에는 서로 다른 조직의 프로젝트가 포함되지 않지만, 경계 브리지를 사용하면 서로 다른 서비스 경계에 있는 프로젝트와 서비스가 통신하도록 할 수 있습니다.
가능한 경우 Google Cloud 기반 방화벽 규칙으로 트래픽 관리
Google Cloud VPC에는 수평 확장이 가능하며 각 VM에 분산 방식으로 적용되는 L3/L4 스테이트풀(Stateful) 방화벽이 포함되어 있습니다. 이 방화벽은 계층식 방화벽 정책, 전역 및 리전 네트워크 방화벽 정책, VPC 방화벽 규칙을 사용하여 구성됩니다. 자세한 내용은 Cloud 방화벽 개요를 참조하세요.
Google Cloud Marketplace는 정보 유출 방지, 애플리케이션 악용 방지, 권한 에스컬레이션 방지와 같은 고급 보안 기능을 제공하고, 알려진 위협과 알 수 없는 위협을 감지하며, URL 필터링을 적용하는 VM을 비롯한 다양한 타사 솔루션 생태계를 갖추고 있습니다. 또한 단일 서비스 제공업체가 클라우드 서비스 제공업체 및 온프레미스 환경에서 정책을 구현할 수 있도록 하는 운영상의 이점이 있습니다.
다음 다이어그램의 여러 개발-서브넷 경로에 표시된 대로, 트래픽은 일반적으로 우선순위가 동일하거나(5 튜플 해시를 사용하여 트래픽 배포) 우선순위가 다른(중복 경로 생성) 경로를 지정하여 이러한 VM으로 라우팅됩니다.
대부분의 솔루션에는 여러 네트워크 인터페이스 VM이 필요합니다. VM에는 VPC 네트워크당 둘 이상의 인터페이스가 포함될 수 없으므로 여러 네트워크 인터페이스 VM 생성 시 각 인터페이스는 별도의 VPC 네트워크에 연결되어야 합니다.
다음과 같은 이유로 타사 솔루션을 VPC 네트워크에 배포할 때 확장도 중요하게 고려해야 합니다.
- 한도: 대부분의 VM 기반 어플라이언스는 데이터 경로에 삽입되어야 합니다. 이를 위해서는 동일한 프로젝트에 있는 여러 VPC 네트워크를 연결하는 다중 네트워크 인터페이스 VM이 필요합니다. VPC 리소스 할당량은 프로젝트 수준에서 설정되므로 모든 VPC 네트워크의 총 리소스 니즈가 제한될 수 있습니다.
- 성능: VPC 네트워크의 완전 수평적 확장성 속성에 단일 VM 기반 정체 현상을 도입하는 방법은 클라우드 설계 방법과 어긋납니다. 이 문제를 완화하기 위해 내부 패스 스루 네트워크 부하 분산기 뒤에 있는 관리형 인스턴스 그룹에 여러 네트워크 가상 어플라이언스(NVA)를 배치할 수 있습니다.
대규모 요구사항 아키텍처에서 이러한 요인을 고려하기 위해서는 보안 제어를 엔드포인트로 푸시해야 합니다. 먼저 VM을 강화하고 Google Cloud 방화벽 규칙을 사용합니다. 이 전략에는 다중 네트워크 인터페이스 VM을 통해 VPC 네트워크의 전달 아키텍처를 변경하지 않는 호스트 기반 엔드포인트 검사 에이전트 도입도 포함될 수 있습니다.
이러한 구성의 추가 예시는 VPC 네트워크 간 스테이트풀(Stateful) L7 방화벽 참조 아키텍처를 참조하세요.
가능한 경우 더 적은 수의 광범위한 방화벽 규칙 집합 사용
VM에는 특정 수의 규칙만 프로그래밍할 수 있습니다. 그러나 여러 규칙을 하나의 복잡한 규칙 정의로 결합할 수 있습니다. 예를 들어 VPC 네트워크의 모든 VM에서 10개의 인그레스 TCP 포트를 명시적으로 허용해야 하는 경우 각각 하나의 포트를 정의하는 10개의 개별 규칙을 작성하거나 10개의 포트가 모두 포함된 단일 규칙을 정의하는 두 가지 옵션이 있습니다. 10개의 포트를 모두 포함하는 단일 규칙을 정의하는 옵션이 더 효율적입니다.
전체 VPC 네트워크에 적용되는 일반 규칙 집합을 생성한 다음 타겟을 사용하여 그룹화한 여러 소규모 VM 그룹에 더 구체적인 규칙 집합을 사용합니다. 즉, 우선 광범위한 규칙을 정의한 다음 필요에 따라 해당 규칙을 더 세부적으로 정의합니다.
- VPC 네트워크에서 모든 VM에 공통적으로 적용되는 방화벽 규칙을 적용합니다.
- 서비스 인스턴스 그룹 또는 서브넷과 같이 여러 VM에 걸쳐 그룹화할 수 있는 방화벽 규칙을 적용합니다.
- NAT 게이트웨이 또는 배스천 호스트와 같은 개별 VM에 방화벽 규칙을 적용합니다.
가능한 경우 서비스 계정을 사용하여 VM 격리
많은 조직이 VPC 네트워크에서 VM의 하위 집합에 대해 특정 규칙이 필요한 환경을 운영하고 있습니다. 이러한 경우 서브넷 격리 및 타겟 필터링이라는 두 가지 일반적인 방법을 사용할 수 있습니다.
서브넷 격리
서브넷 격리를 사용하면 서브넷에서 Google Cloud 방화벽 규칙이 적용되는 보안 경계를 형성합니다. 이 방법은 온프레미스 네트워킹 구조 및 IP 주소와 네트워크 배치가 VM ID의 일부인 경우에 공통적으로 적용할 수 있습니다.
고유한 태그, 네트워크 태그 또는 서비스 계정을 해당 인스턴스에 적용하여 특정 서브넷의 VM을 식별할 수 있습니다. 이렇게 하면 연결된 태그, 네트워크 태그, 서비스 계정과 함께 서브넷의 VM에만 적용되는 방화벽 규칙을 생성할 수 있습니다. 예를 들어 동일한 서브넷의 VM 간 모든 통신을 허용하는 방화벽 규칙을 만들려면 방화벽 규칙 페이지에서 다음 규칙 구성을 사용할 수 있습니다.
- 타겟: 지정된 타겟 태그
- 타겟 태그: subnet-1
- 소스 필터: Subnets
- 서브넷: 이름을 기준으로 서브넷을 선택합니다(예: subnet-1).
타겟 필터링
타겟 필터링의 경우 모든 VM은 동일한 서브넷에 있거나 임의 서브넷 집합의 일부입니다. 이 접근 방식에서 서브넷 멤버는 방화벽 규칙에 대한 인스턴스 ID의 일부로 간주되지 않습니다. 대신 태그, 네트워크 태그 또는 서비스 계정을 사용하여 동일한 서브넷의 VM 간 액세스를 제한할 수 있습니다. 동일한 방화벽 규칙을 사용하는 각 VM 그룹에는 동일한 네트워크 태그가 적용됩니다.
이를 설명하기 위해 모든 인스턴스가 동일한 서브넷에 배포되는 3계층(웹, 앱, 데이터베이스) 애플리케이션을 고려해 보세요. 웹 계층은 최종 사용자 및 앱 계층과 통신할 수 있고, 앱 계층은 데이터베이스 계층과 통신할 수 있지만 계층 간 다른 통신은 허용되지 않습니다. 웹 계층을 실행하는 인스턴스에는 web 네트워크 태그가 있고, 앱 계층을 실행하는 인스턴스에는 app 네트워크 태그가 있으며, 데이터베이스 계층을 실행하는 인스턴스에는 db 네트워크 태그가 있습니다.
다음 방화벽 규칙은 이 방법을 구현합니다.
| 규칙 1: 최종 사용자 → 웹 계층 허용 | 타겟: 지정된 타겟 태그 타겟 태그: web 소스 필터: IP 범위 소스 IP 범위: 0.0.0.0/0 |
| 규칙 2: 웹 계층 → 앱 계층 허용 | 타겟: 지정된 타겟 태그 타겟 태그: app 소스 필터: 소스 태그 소스 태그: web |
| 규칙 3: 앱 계층 → 데이터베이스 계층 허용 | 타겟: 지정된 타겟 태그 타겟 태그: db 소스 필터: 소스 태그 소스 태그: app |
그러나 이 경우 타겟 필터링에 네트워크 태그를 사용할 수는 있지만 가능하면 태그 또는 서비스 계정을 사용하는 것이 좋습니다. 타겟 태그에 대한 액세스는 제어되지 않으며 VM이 사용 중인 경우 instanceAdmin 역할을 가진 사용자가 이를 변경할 수 있습니다. 태그 및 서비스 계정에 대한 액세스는 제어되므로 특정 사용자에게 서비스 계정을 사용하도록 명시적으로 권한을 부여해야 합니다.
인스턴스당 서비스 계정은 하나만 있을 수 있지만 태그는 여러 개 있을 수 있습니다. 또한 VM에 할당된 서비스 계정은 VM이 정지된 경우에만 변경할 수 있습니다.
태그를 사용할 때 자동화를 사용하여 보안 정책 모니터링
네트워크 태그를 사용하는 경우 인스턴스 관리자가 이러한 태그를 변경할 수 있습니다. 이 경우 보안 정책을 우회할 수 있습니다. 따라서 프로덕션 환경에서 네트워크 태그를 사용하는 경우 자동화 프레임워크를 사용하면 네트워크 태그에 대한 IAM 거버넌스의 부족을 해결할 수 있습니다.
추가 도구를 사용하여 앱을 안전하게 보호
방화벽 규칙 외에 다음과 같은 추가 도구를 사용하여 앱을 안전하게 보호하세요.
- Google Cloud 전역 HTTP(S) 부하 분산기를 사용하여 고가용성과 프로토콜 정규화를 지원합니다.
- Google Cloud Armor를 HTTP(S) 부하 분산기와 통합하면 DDoS 보호 및 네트워크 에지에서 IP 주소를 차단 또는 허용하는 기능이 제공됩니다.
- IAP를 통해 사용자 ID와 요청 컨텍스트를 확인하고 사용자에게 액세스 권한이 부여됐는지 여부를 판단하여 앱에 대한 액세스를 제어합니다.
- Security Command Center에서는 보안 통계, 이상 감지, 취약점 감지를 위한 단일 인터페이스를 제공합니다.
네트워크 서비스: NAT 및 DNS
Cloud NAT에서 고정 외부 IP 주소 사용
다양한 VM의 고정 외부 IP 주소가 필요한 경우 Cloud NAT를 사용하세요. 고정 아웃바운드 IP 주소가 필요한 이유에 대한 예시로 타사에서 특정 외부 IP 주소의 요청을 허용하는 경우를 들 수 있습니다. Cloud NAT를 사용하면 각 리전별로 아웃바운드 통신에 사용되는 소수의 NAT IP 주소를 할당할 수 있습니다.
Cloud NAT를 사용하면 VM 인스턴스가 자체 외부 IP 주소가 없어도 인터넷을 통해 통신할 수 있습니다. Google Cloud 방화벽 규칙은 스테이트풀(Stateful)입니다. 소스와 타겟 또는 타겟과 타겟 간에 연결이 허용되는 경우 두 방향 모두에서 이후의 모든 트래픽이 허용됩니다. 즉, 방화벽 규칙은 세션이 설정되면 양방향 통신을 허용합니다.
이름 확인에 비공개 DNS 영역 사용
Cloud DNS의 비공개 영역을 사용하면 이 매핑을 외부에 노출하지 않고도 내부 IP 주소를 사용하여 VPC 네트워크 내의 DNS로 서비스를 확인할 수 있습니다.
분할된 범위의 DNS를 사용하면 서비스를 외부가 아닌 VPC 네트워크 내에서 서로 다른 IP 주소에 매핑할 수 있습니다. 예를 들어 공용 인터넷의 네트워크 부하 분산을 통해 서비스를 노출시킬 수 있지만 내부 부하 분산이 VPC 네트워크 내에서 동일한 DNS 이름을 사용하여 동일한 서비스를 제공하도록 할 수 있습니다.
Google 관리 서비스에 대한 API 액세스
가능한 경우 기본 인터넷 게이트웨이 사용
기본 경로를 수정해야 할 경우 Google API에 대한 명시적 경로 추가
동일한 서브넷에 Google API를 사용하는 인스턴스 배포
가능한 경우 기본 인터넷 게이트웨이 사용
VPC 네트워크 내의 리소스에서 Google API로의 액세스는 기본 인터넷 게이트웨이 다음 홉을 따릅니다. 다음 홉 게이트웨이의 이름에 관계없이 인스턴스와 Google API 간의 경로는 Google 네트워크 내에 유지됩니다.
기본적으로 외부 IP 주소가 있는 VM 인스턴스만 Google API 및 서비스와 통신할 수 있습니다. 외부 IP 주소 없이 인스턴스에서 액세스해야 하는 경우 Private Service Connect 엔드포인트를 설정하거나 각 서브넷에 비공개 Google 액세스 기능을 사용합니다. 이렇게 해도 Google API에 대한 통신 속도가 저하되지 않습니다.
Google Kubernetes Engine(GKE)은 노드가 배포된 서브넷에서 비공개 Google 액세스를 자동으로 사용 설정합니다. 외부 IP 주소가 없는 이러한 서브넷의 모든 노드는 Google 관리형 서비스에 액세스할 수 있습니다.
기본 경로를 수정해야 할 경우 Google API에 대한 명시적 경로 추가
기본 경로를 수정해야 하는 경우 Google API 대상 IP 범위에 대한 명시적 경로를 추가합니다.
기본 경로(0.0.0.0/0)에서 인터넷 게이트웨이 다음 홉을 사용하지 않는 환경에서는 Google API에서 사용하는 대상 IP 주소 범위에 명시적 경로를 구성합니다. 명시적 경로의 다음 홉을 기본 인터넷 게이트웨이로 설정합니다. 이러한 시나리오의 예시로 온프레미스 기기를 통해 모든 트래픽을 검사해야 하는 경우를 들 수 있습니다.
동일한 서브넷에 Google API를 사용하는 인스턴스 배포
동일한 서브넷에서 Google API 및 서비스에 액세스해야 하는 인스턴스를 배포하고 외부 IP 주소가 없는 인스턴스에 대해 비공개 Google 액세스를 사용하도록 설정합니다. 또는 Private Service Connect 엔드포인트를 설정합니다.
온프레미스 환경에서 비공개 Google 액세스를 사용하여 Google API에 액세스하려면 온프레미스 호스트의 비공개 Google 액세스 구성을 참조하여 비공개 IP 주소 범위에서 일부 Google 서비스에 액세스합니다. 이러한 기능을 활성화하기 전에 지원되는 서비스를 확인합니다. 이 서비스에서 제공하는 IP 주소를 통해 다른 Google API에 액세스할 수 없기 때문입니다. 이 기능을 활성화하려면 DNS 뷰 구성과 같은 DNS 구성이 추가로 필요합니다.
Private Service Connect 엔드포인트를 사용하여 온프레미스 환경에서 Google API에 액세스하려면 온프레미스 호스트에서 엔드포인트 액세스를 참조하세요.
로깅, 모니터링, 공개 상태
특정 사용 사례 및 주요 대상을 위해 로깅 조정
긴 연결이 있는 VPC 네트워크의 로그 집계 간격 늘리기
VPC 흐름 로그 샘플링을 사용하여 볼륨 줄이기
IP 및 포트 데이터만 필요한 경우 추가 메타데이터 삭제
특정 사용 사례 및 주요 대상을 위해 로깅 조정
VPC 흐름 로그를 사용하면 네트워크 모니터링, 포렌식, 실시간 보안 분석, 비용 최적화를 할 수 있습니다. 서브넷 수준에서 VPC 흐름 로그를 사용 설정하거나 사용 중지할 수 있습니다. 서브넷에 대해 사용 설정된 경우 VPC 흐름 로그는 해당 서브넷의 모든 VM 인스턴스에서 데이터를 수집합니다.
이러한 로그는 VM 인스턴스에서 전송되거나 수신되는 네트워크 흐름의 샘플을 기록합니다. 사용 사례를 로깅하면 로깅이 필요한 서브넷과 로깅 기간을 결정하는 데 도움이 됩니다.
흐름 로그는 Compute Engine VM에서 5초마다 연결별로 집계된 후 실시간으로 내보내집니다. 흐름 로그는 Cloud Logging에서 볼 수 있으며 Cloud Logging 내보내기가 지원되는 모든 대상으로 로그를 내보낼 수 있습니다.
Logging의 로그 수집 페이지에서는 프로젝트의 로그 볼륨을 추적하고 모든 로그 수집을 사용 중지하거나 불필요한 로그 항목을 제외(삭제)할 수 있습니다. 그러면 월 할당량 가운데 로그에 청구되는 요금을 최소화할 수 있습니다.
로그는 운영 및 보안 측면의 성공에 매우 중요한 부분이지만 검토에 따른 조치를 취하지 않으면 도움이 되지 않습니다. VPC 네트워크에 대한 운영 및 보안 측면의 성공을 보장하기 위해서는 주요 대상에 대한 로그를 조정해야 합니다.
자세한 내용은 VPC 흐름 로그를 참조하세요.
긴 연결이 있는 VPC 네트워크의 로그 집계 간격 늘리기
주로 연결이 오랫동안 유지되는 VPC 네트워크의 경우 로그 집계 간격을 15분으로 설정하면 생성되는 로그 수를 크게 줄이고 보다 빠르고 간단하게 분석을 사용할 수 있습니다.
로그 집계 간격 늘리기가 필요한 워크플로 예시는 네트워크 모니터링이며 다음과 같은 태스크가 포함됩니다.
- 네트워크 진단 수행
- VM 및 애플리케이션별로 흐름 로그를 필터링하여 트래픽 변화 파악
- 용량 예측을 위한 트래픽 증가 분석
VPC 흐름 로그 샘플링을 사용하여 볼륨 줄이기
VPC 흐름 로그 샘플링을 사용하면 VPC 흐름 로그의 볼륨을 줄일 수 있지만 여전히 낮은 수준의 샘플과 집계된 뷰를 볼 수 있습니다.
샘플링을 통한 볼륨 줄이기가 필요한 워크플로 예시는 네트워크 사용량 파악 및 네트워크 트래픽 비용 최적화입니다. 이 워크플로에는 다음과 같은 태스크가 포함됩니다.
- 리전과 영역 간 트래픽 예측하기
- 인터넷에서 특정 국가로 가는 트래픽 예측하기
- 최상위 네트워크 소비자 파악하기
IP 및 포트 데이터만 필요한 경우 추가 메타데이터 삭제
IP 주소 및 포트만 필요한 보안 사용 사례에서는 추가 메타데이터를 삭제하여 Cloud Logging에서 사용되는 데이터 볼륨을 줄입니다.
메타데이터 제거가 필요한 워크플로 예시는 네트워크 포렌식이며 다음과 같은 태스크가 포함됩니다.
- 어떤 IP로 누구와 언제 통신했는지 확인
- 네트워크 흐름 분석 결과 확인된 손상된 IP 주소 식별
참조 아키텍처
이 섹션에서는 이 문서에 설명된 권장사항 중 일부를 보여주는 몇 가지 아키텍처에 대해 중점적으로 설명합니다.
단일 프로젝트, 단일 VPC 네트워크
이 초기 참조 아키텍처에는 여러 리전에 걸쳐 고가용성 아키텍처를 배포하는 데 필요한 모든 구성 요소가 포함되어 있습니다. 이때 서브넷 수준 격리 및 99.99% SLA가 온프레미스 데이터 센터에 연결됩니다.
단일 호스트 프로젝트, 여러 서비스 프로젝트, 단일 공유 VPC
초기 참조 아키텍처를 기반으로 빌드된 공유 VPC 호스트 프로젝트 및 여러 서비스 프로젝트를 사용하면 관리자가 서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙에서 제어하면서 서비스 프로젝트 관리자에게 인스턴스 생성 및 관리와 같은 관리 책임을 위임할 수 있습니다.
여러 호스트 프로젝트, 여러 서비스 프로젝트, 여러 공유 VPC
다음 다이어그램은 VPC 격리의 아키텍처를 보여줍니다. 이 아키텍처는 고가용성 설계를 기반으로 하고 프로덕션을 다른 프로젝트에서 분리합니다. 감사 요구사항(예: PCI), 환경 간 할당량 고려사항 또는 다른 논리적 격리 계층을 포함하여 VPC 격리를 고려해야 하는 이유는 다양합니다. 중복화를 위해 위치당 두 개의 상호 연결만 필요하지만 여러 개의 Interconnect 연결을 여러 VPC 네트워크 또는 리전에 추가할 수 있습니다.
또한 프록시, 인증, 디렉터리 서비스와 같은 핵심 서비스를 배치할 위치를 결정할 때 격리를 사용하면 복제가 필요할 수도 있습니다. 공유 서비스 VPC 네트워크를 사용하면 VPC 네트워크 피어링을 통해 이러한 서비스를 다른 VPC 네트워크와 공유하는 동시에 관리 및 배포를 중앙 집중식으로 처리할 수 있습니다.
VPC 네트워크 간 스테이트풀(Stateful) L7 방화벽
이 아키텍처에는 VPC 네트워크 간의 다중 NIC 브리지로 작동하는 L7 차세대 방화벽(NGFW) 어플라이언스로 연결된 여러 VPC 네트워크가 있습니다.
신뢰할 수 없는 외부 VPC 네트워크를 사용하여 검사를 위해 L7 NGFW의 외부 구간에서 종료되는 하이브리드 상호 연결 및 인터넷 기반 연결을 종료할 수 있습니다. 이 설계는 다양하게 변형할 수 있지만 핵심 원칙은 트래픽이 신뢰할 수 있는 VPC 네트워크에 도달하기 전에 방화벽을 통해 트래픽을 필터링하는 것입니다.
이 설계를 사용하려면 각 VPC 네트워크가 VM 기반 NGFW를 삽입할 프로젝트에 상주해야 합니다. 할당량은 프로젝트 수준에서 적용되므로 모든 VPC 리소스의 합계를 고려해야 합니다.
다음 단계
- VPC 심층 탐구 및 권장사항(Cloud NEXT'18 동영상)
- 하이브리드 및 멀티 클라우드 네트워크 토폴로지
- Google Cloud 시작 영역의 리소스 계층 구조 결정
- Compute Engine 리전 선택 권장사항
- 데이터 센터 전문가를 위한 Google Cloud: 네트워킹
- VPC 문서
- GKE 네트워킹 개요
- Google Cloud에 대한 참조 아키텍처, 다이어그램, 권장사항을 살펴봅니다. Cloud 아키텍처 센터를 살펴보세요.