Network Details
The AI Innovation Platform uses Shared VPC architecture to manage network resources efficiently while maintaining strong security boundaries.
What is a Shared VPC?
A Shared VPC (Virtual Private Cloud) allows multiple projects within an organization to share a common network infrastructure. This means that network resources like subnets, firewalls, and routes are centrally managed in a host project and made available to service projects.
This setup is particularly useful for organizations with multiple teams or departments, as it enables consistent security policies, centralized network control, and efficient resource sharing.
Key Components of Shared VPC:
- Host Project: The project that owns and manages the VPC network resources. Only admins of the host project can modify network configurations.
- Service Projects: Projects that use the network resources provided by the host project. While they can deploy resources like VMs within the shared subnets, they cannot alter network settings unless explicitly granted permissions.
- Subnets: Segments of the IP address space within the VPC. Subnets can span multiple regions, allowing for flexible deployment options.
- Firewall Rules: Policies that control the flow of traffic to and from network resources. These are centrally managed in the host project.
- IAM Roles: Permissions are managed through Identity and Access Management (IAM), ensuring that only authorized users have access to specific network configurations.
Benefits of Using Shared VPC:
- Centralized Network Management: Network configurations are managed in one place, reducing complexity and ensuring consistent policies across all projects.
- Improved Security: Shared VPC allows for organization-wide security policies, minimizing the risk of misconfigurations. Internal communication between resources is secure, without the need for public IPs.
- Efficient Resource Sharing: Teams can collaborate more effectively by accessing shared network resources while maintaining project-level isolation.
- Simplified Billing and Quotas: Resource usage can be tracked and managed across service projects, simplifying budgeting and quota management.
Network Tags for Firewall Rules (Common across all projects):
| Service | Tags | PORT | Purpose |
|---|---|---|---|
| Dataflow Jobs | dataflow | tcp:12345, 12346 | Firewall rules so that Dataflow VMs can send and receive network traffic on TCP port 12345 for streaming jobs and on TCP port 12346 for batch job |
| Virtual machines | allow-iap | tcp:22, 3389, 8002, 8003, 8004, 8005 | To allow SSH and RDP into Linux and Windows machines Additional ports 8002, 8003,8004, 8005 for custom purposes |
| HTTP/HTTPS servers | https-server, http-server | tcp:80, 81, 443, 8443, 10402 | apply to instances that are marked with the http-server network tag, allowing incoming traffic to reach those instances on ports 80, 81, 443, 8443, and 10402 |
| Health checks | allow-health-checks | tcp:80, 81, 443, 8443, 10402 | allows all TCP traffic from Google Cloud health check systems to your VM instances. VMs being load balanced to allow traffic from health check prober IP ranges ⧉. |
Shared Network
When creating an instance or other compute services, under the Network Interfaces, choose the "Network shared with me" option rather than "Network in this project", as illustrated in the screenshots below. After selecting this option, you can then choose the available subnets from the dropdown and select the most suitable one for your resource. Users will be able to use all the subnets shared with their projects for deployment.
