Professional Cloud Network Engineer
A standalone VPC network operates independently within a single Google Cloud project, giving a team full ownership of its network environment. A Shared VPC design allows multiple projects to share a common VPC network, with a central host project managing the core network infrastructure. The choice depends heavily on your organization's IT model: a centralized model benefits from Shared VPC for consistent governance, while a decentralized model often suits standalone VPCs for team autonomy. For managed services like Private IP Cloud Composer, each environment uses up to two VPC peering connections, but Google Kubernetes Engine (GKE) clusters can reuse existing peering to reduce the total count.
The number of VPC environments you need is driven by the need to isolate different teams, applications, or data classifications. Each Private IP environment requires two secondary IP ranges in its subnetwork—one for GKE pods and one for services. Since a single subnetwork supports a maximum of 30 secondary ranges, this limits how many environments can share that subnet. Projected growth patterns influence whether to create multiple VPC networks upfront or plan for expansion within a single network. More VPCs provide stronger isolation but increase management overhead for firewall rules and routing.
VPC peering charges apply to data transfer between the peered networks, so traffic volume impacts cost. When environments share a VPC through Shared VPC, cross-project traffic stays within Google's network without additional egress charges. Minimizing the number of peering connections while maintaining proper isolation helps control expenses. GKE's ability to reuse existing VPC peering connections reduces both the peering count and associated costs when deploying multiple environments in the same region.
Managing multiple VPC environments involves maintaining separate firewall rules, IAM policies, and routing configurations for each network. A Shared VPC model centralizes these tasks, reducing operational effort and enforcing consistent security policies across all attached service projects. For Private IP environments, the control plane offers a public endpoint and a private endpoint; you can disable the public endpoint to enhance security by preventing all internet access, though this may limit some remote management capabilities.
IP address planning must account for immutable allocations required by managed services, such as the minimum /24 block for Managed Service for Microsoft Active Directory. The maximum of 30 secondary ranges per subnetwork and VPC peering connection limits constrain how many managed service instances can reside in a single VPC network. Exceeding these limits requires distributing workloads across multiple VPCs. Traffic routing for high availability can use internal load balancers for active-active configurations or static routes with priority values for active-passive failover without a load balancer.
Network Connectivity Center (NCC) is a Google Cloud service for building centralized network topologies like hub-and-spoke. An NCC hub acts as a central point for managing routing information between attached spokes, such as VPC networks or hybrid connections. This hub enables transitive routing, meaning spokes can communicate with each other through the hub, unlike direct VPC Network Peering which is non-transitive. NCC simplifies connectivity management in complex, multi-cloud deployments by providing a single control point for route propagation.
A VPC spoke is a VPC network attached to an NCC hub. When attached, the hub automatically learns the subnet routes from that VPC and can propagate them to other spokes based on configured policies. You can use export filters on the hub to control exactly which routes are advertised, enabling traffic segmentation. NCC supports up to 250 active VPC spokes per hub and integrates hybrid connections like Cloud VPN tunnels, allowing on-premises networks to reach all VPC spokes connected to the same hub.
Private Service Connect (PSC) provides private, granular connectivity between a service consumer and a service producer without exposing traffic to the public internet. PSC creates a private IP address endpoint inside a consumer's VPC that maps directly to a specific service. Unlike VPC Network Peering, which connects entire networks, PSC connects at the service level, avoiding IP address overlap issues. Traffic remains within Google's private network, and producers control access via an authorization list, providing a strong security boundary.
VPC Network Peering establishes direct internal IP connectivity between two VPC networks across projects. A strict requirement is that the subnet IP address ranges of the two VPCs must not overlap. By default, peering only exchanges private IPv4 subnet routes (RFC 1918 addresses). To exchange custom routes (dynamic or static), both VPCs must enable specific import and export flags. Peering connections are bidirectional, but they do not support transitive routing—a VPC peered with two others cannot act as a transit path between them.
Choose Network Connectivity Center when you need transitive routing between many VPCs or hybrid connections through a central hub. Choose Private Service Connect when you need to avoid IP address conflicts, require service-level security controls, or want to reduce administrative overhead. Choose VPC Network Peering when you need to insert network virtual appliances (NVAs) for traffic inspection or when your application does not support PSC. For multi-VPC scenarios, NCC can propagate PSC endpoint reachability across spokes.
A Virtual Private Cloud (VPC) network can be created in either auto mode or custom mode. An auto mode VPC automatically creates one subnet in each region using predetermined IP ranges, which can cause overlap conflicts in hybrid environments. A custom mode VPC gives administrators full control to manually define subnets, their names, and their IP ranges only in chosen regions, preventing automatic overlaps. Choose custom mode for most enterprise designs to maintain explicit control over IP address management.
Subnets are regional resources containing a primary IP address range (CIDR block). Since Google Cloud's software-defined networking provides full mesh connectivity within a VPC, the number of subnets does not affect routing performance. A best practice is to group similar applications into fewer, larger subnets because features like Cloud NAT and Private Google Access are configured per subnet. For isolation, use service accounts or network tags on resources instead of relying solely on subnet separation.
Effective allocation requires planning CIDR ranges that do not overlap with on-premises networks, other clouds, or peered VPCs. Supported IPv4 ranges include RFC 1918 addresses, RFC 6598 (100.64.0.0/10), and Class E (240.0.0.0/4). Shared VPC centralizes IPAM in a host project, where subnets are created once and shared across service projects. Granting the network user role at the subnet level provides granular control over which teams can provision resources in specific address ranges.
Managed services consume IP addresses dynamically. Cloud Run reserves IP addresses in blocks of 16 and requires a subnet of at least /26 in size. Private Service Connect reduces IP consumption by allowing consumers to connect via private endpoints using IP addresses from their own VPC subnets, unlike private services access which uses VPC Network Peering and requires allocating large IP ranges.
IPv6 addressing supports dual-stack (IPV4_IPV6) and single-stack (IPV6_ONLY) configurations within custom mode VPCs. Subnets receive a fixed /64 CIDR block from Google Cloud. Bring Your Own IP (BYOIP) allows importing publicly routable IPv4 or IPv6 prefixes. Privately Used Public IP (PUPI) allows public IPv4 addresses to be used as internal subnet ranges, where traffic remains within Google's private network.
Automated IP Address Management uses internal range resources via the Network Connectivity API to manage and reserve non-overlapping CIDR blocks across VPCs. Allocation strategies include RANDOM, FIRST_AVAILABLE, and others to balance space preservation and reduce contention. Every primary IPv4 subnet reserves four addresses for internal infrastructure: the network address, default gateway, a future infrastructure address, and the broadcast address.
Planning a network environment involves deciding whether to design for global or regional connectivity based on workload requirements. A global design uses services and configurations that span multiple regions, such as global dynamic routing with Cloud Router, which advertises all VPC subnets to on-premises networks everywhere. A regional design confines resources and routing advertisements to a specific region, which can simplify management and control traffic paths. The choice impacts how applications are deployed, how users connect, and how data transfer costs are incurred across Google Cloud's network.
The Maximum Transmission Unit (MTU) is the largest packet size that can be transmitted over a network link without fragmentation. In Google Cloud VPCs, the default MTU for virtual machine network interfaces is 1460 bytes for Ethernet, accounting for overhead from protocols like TCP/IP. Choosing the correct MTU sizing is important for workload performance, especially for data-intensive applications. If the MTU is set too high, packets may be fragmented, adding latency; if set too low, it reduces efficiency by increasing header overhead. Workloads requiring jumbo frames, such as high-performance computing or storage replication, may need specific network configurations to support larger MTUs.
Network Virtual Appliances (NVAs) are third-party virtual devices, like firewalls or routers, inserted into a VPC network for traffic inspection, security, or advanced routing. To insert an NVA, you deploy it on a Compute Engine instance and configure custom static routes or policy-based routes to direct traffic through the appliance. The NVA typically sits between two subnetworks, and routes are updated so that traffic from one subnet to another uses the NVA's internal IP as the next hop.
Custom static routes define a specific path for traffic destined to particular IP ranges, overriding the VPC's default routing behavior. You can create these routes with different priority values; traffic flows to the route with the lowest priority that matches the destination. For active-passive NVA failover, you configure two routes to the same destination with different priorities and next hops, and the higher-priority (more preferred) route points to the primary NVA. Policy-based routes offer more granular control, allowing routing decisions based on source IP, destination IP, protocol, or port, not just destination.
Load balancers can be integrated with NVAs for scalable traffic distribution. An internal passthrough Network Load Balancer can distribute traffic across a pool of NVA instances in an unmanaged instance group. The load balancer's health checks monitor the NVAs, stopping traffic to any that fail. For advanced inspection scenarios, you can configure a proxy-based load balancer (like an Internal HTTP(S) Load Balancer) to terminate traffic, inspect it, and then forward it to backend services, potentially through an NVA.
Choose a Shared VPC when your organization uses a centralized IT model where a central networking team owns the core infrastructure. This allows for consistent governance and security policies across multiple projects that consume network resources from a single host project.
The main difference is transitive routing. NCC hubs enable VPC spokes attached to the same hub to route traffic to each other through the hub. VPC Network Peering is non-transitive; a VPC peered with two others cannot act as a transit path between them.
Cloud Run reserves IP addresses in blocks of 16 (/28) during traffic surges to enable rapid scaling and uses twice as many IP addresses as running instances at steady state. A /26 subnet provides enough addresses to accommodate this reservation pattern without exhaustion.
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts