0. VPC capabilites
다른 physical network들 처럼, VPC(Virtual Private Cloud)도 routing tables을 가지고 있다. 이러한 routing tables은 같은 네트워크 안의 하나의 인스턴스에서 다른 인스턴스로 트래픽을 전송하는데 사용된다. 외부 IP주소를 요구하지 않고 서브네트워크 전체에 걸쳐서도, GCP 영역 사이에서도 동일하다. VPC routing tables과 firewall instance는 built-in 되어있기 때문에 따로 규정하거나 manage할 필요는 없다. VPC는 사용자에게 글로벌하게 distribute된 firewall을 제공한다. 사용자는 인스턴스에 들어오고 나가는 접근을 제한할 수 있다. 또한, 사용자는 metadata tags을 사용하여 firewall 룰을 정의할 수 있다. 예를 들어, 모든 웹서버에 "web"이라고 태그를 달 수 있으며, port 80과 443의 트래픽은 web이라는 태그를 가진 모든 vm에 접근을 허용한다는 firewall rule을 작성할 수 있다.
1. VPC Peering
VPC 네트워크 피어링을 사용하면, 여러 VPC 네트워크의 워크로드가 내부적으로 통신할 수 있도록 VPC 네트워크를 연결할 수 있다. Google Cloud VPC 네트워크 피어링은 동일한 프로젝트에 속하는지 또는 동일한 조직에 속하는지에 관계없이 두 개의 VPC 네트워크에서 내부 IP 주소 연결을 허용한다. 트래픽은 Google 네트워크에 그대로 머무르며 공개 인터넷을 거치지 않는다.
1-1. VPC network Peering이 유용한 경우
❶ 구글 클라우드의 SaaS ecosystem, 서비스가 조직 내, 조직 전체의 여러 vpc네트워크를 걸쳐 프라이빗하게 가능하게 할 수 있다.
❷ 네트워크 관리 도메인의 조직들은 서로 피어링할 수 있다.
만약에 조직내에 네트워크 관리 도메인이 여러 개 있다면, VPC Network Peering은 내부 IP주소를 사용하여 VPC 네트워크 전체에 걸쳐서 서비스를 사용 가능하게 만들어준다.
1-2. VPC network Peering의 장점
❶ 네트워크 지연 시간: 내부 주소만 사용하는 연결은 외부 주소를 사용하는 연결보다 지연 시간이 짧다.
❷ 네트워크 보안: 서비스 소유자는 공개 인터넷에 서비스를 노출할 필요가 없어, 그와 관련된 위험을 감수할 필요가 없다.
❸ 네트워크 비용: Google Cloud는 트래픽이 같은 영역 내에 있더라도 외부 IP를 사용하여 통신하는 네트워크에 egress 대역폭 가격을 청구한다. 그러나 피어링된 네트워크의 경우 내부 IP를 사용하여 통신하면 이러한 이그레스 비용을 절약할 수 있다. 일반 네트워크 가격은 여전히 모든 트래픽에 적용된다.
1-3. VPC network Peering 사용하기
시작하기 전에 피어링 할 VPC 네트워크의 이름이 있어야하고, 해당 네트워크가 다른 프로젝트에있는 경우 해당 프로젝트의 프로젝트 ID도 있어야한다.
피어링 구성은 다른 VPC 네트워크에 연결 하려는 의도 로 설정하며, 네트워크와 다른 네트워크는 서로에 대한 피어링 구성을 가질 때까지 연결되지 않는다. 다른 네트워크가 네트워크와 피어링 할 해당 구성을 가지면 피어링 상태가 active로 변경되고 연결된다. 앞서 말했듯이, 조직간 피어링도 가능하다.
1-3-1. Peering from network-a to network-b
1-3-2. Peering from network-b to network-a
1-3-3. Peering ACTIVE
1-4. 제한 사항
1-4-1. 피어링 된 VPC 네트워크에서 서브넷 IP 범위는 다른 서브넷 IP 범위와 겹칠 수 없다. 겹치는 서브넷 IP 범위는 라우팅 문제를 야기할 수 있기 때문이다.
1-4-2. 레거시 네트워크는 VPC 네트워크 피어링에서 지원되지 않는다. 레거시 네트워크는 서브넷이없는 네트워크이기 때문에, 기존 네트워크는 다른 네트워크와 피어링 할 수 없으며 VPC 네트워크 피어링에서 지원되지 않는다.
1-4-3. 피어링 된 네트워크에서 태그 및 서비스 계정을 사용할 수 없다.
1-4-3. GKE를 사용한 VPC 네트워크 피어링 은 IP Aliases 및 Custom routes 와 함께 사용할 때 지원된다.
2. Shared VPC
공유 VPC를 사용하면 조직에서 여러 프로젝트의 리소스를 공통 VPC 네트워크에 연결할 수 있으므로 해당 네트워크의 내부 IP를 사용하여 서로 안전하고 효율적으로 통신 할 수 있다. 공유 VPC를 사용하는 경우 프로젝트를 호스트 프로젝트로 지정하고 하나 이상의 다른 서비스 프로젝트 를 여기에 연결한다. 호스트 프로젝트의 VPC 네트워크를 공유 VPC 네트워크라고 하며, 서비스 프로젝트의 적격리소스는 공유 VPC 네트워크의 서브넷을 사용할 수 있다. 공유 VPC를 사용하면 조직 관리자가 서브넷, 경로, 방화벽과 같은 네트워크 리소스를 중앙 집중식으로 제어하면서 인스턴스 생성 및 관리와 같은 관리 책임을 서비스 프로젝트 관리자에게 위임 할 수 있다.
공유 VPC는 동일한 조직 내의 프로젝트를 연결하며, 참여하는 호스트 및 서비스 프로젝트는 다른 조직에 속할 수 없다. 연결된 프로젝트는 동일하거나 다른 폴더 에있을 수 있지만 다른 폴더에 있는 경우 관리자는 두 폴더에 대한 공유 VPC 관리자 권한이 있어야한다.
2-1. 액세스 제어
조직 정책과 IAM 권한이 함께 작동 하여 다양한 수준의 액세스 제어를 제공한다.
2-1-1. 필수 관리 역할
• 조직관리자
• 공유 VPC 관리자
• 서비스 프로젝트 관리자
2-2. 공유 VPC에 사용될 수 있는 리소스
• Compute Engine Instances
• Compute Engine Instance Templates
• Compute Engine Instance Groups
• Google Kubernetes Engine clusters
• Cloud Functions
• App Engine standard environment services
• App Engine flexible environment instances
• Internal IP Addresses
• Internal DNS
• Cloud DNS Private Zones
• Load Balancing
• Memorystore for Redis
2-3. 간단한 공유 VPC 시나리오
조직의 공유 VPC관리자는 호스트 프로젝트를 만들고, 여기에 두개의 서비스 프로젝트를 연결하였다.
서비스 프로젝트 A의 서비스 프로젝트 관리자는 공유 VPC 네트워크의 서브넷 전체 또는 일부에 액세스하도록 구성 할 수 있다. 10.0.1.0/24서브넷의 서브넷 수준 이상의 권한이 있는 서비스 프로젝트 관리자는 us-west1 리젼의 구역에 인스턴스 A를 만들었다. 이 인스턴스는 10.0.1.0/24 CIDR block으로부터 10.0.1.3의 내부 IP주소를 받는다.
독립 프로젝트는 공유 VPC에 참여하지 않는다. 호스트도 서비스 프로젝트도 아니며, 독립형 인스턴스는 최소한 compute.InstanceAdmin프로젝트에 대한 역할이있는 IAM 구성원이 만든다.
