Intrigued by the art of cloud architecture? Discover how to design, develop, and manage robust, secure, scalable, and dynamic solutions on Google Cloud as you prepare for the Professional Cloud Architect exam!
Gauge your current knowledge
Gauge your current knowledge
When designing networks, choosing between global and regional routing determines how user requests travel across the world. Global Load Balancing utilizes a single Anycast IP to automatically send users to the closest healthy application backend. Conversely, Regional Load Balancing forces traffic to stay inside a designated area, which helps you comply with strict data residency laws and reduce network transit costs. You can select the External Application Load Balancer for global needs, while using the Internal Application Load Balancer or the External Passthrough Network Load Balancer for regional needs.
Traffic management depends heavily on whether your load balancer inspects application data or just transport data. Layer 7 Proxies run at the application layer to process HTTP and HTTPS traffic, allowing them to use URL maps for routing requests based on web paths and handle TLS termination to offload security decryption. In contrast, Layer 4 Proxies act as passthrough systems that handle TCP and UDP traffic at the transport level without inspecting the underlying web data. You should choose Layer 7 proxies for complex web applications that need smart routing, whereas Layer 4 proxies are best for high-performance, non-HTTP workloads.
For internal communications, Cloud Service Mesh coordinates traffic directly between private services using sidecar proxies. This platform supports sophisticated routing policies, such as weight-based traffic splitting for gradual updates and request mirroring to test live traffic against new software versions. Deploying a second-level gateway at the edge of this mesh establishes a clean separation of duties between platform administrators and application developers. This architecture also lets you implement header-based routing, deploy custom logic with Service Extensions, and block threats using Cloud Armor.
For containerized environments, the GKE Gateway Controller uses the Kubernetes Gateway API to manage incoming traffic for clusters. This controller can perform multi-cluster load balancing, which automatically redirects user requests to a backup cluster if a primary regional cluster fails. This system relies on Network Endpoint Groups (NEGs) to route traffic directly to individual pod IP addresses instead of routing through cluster nodes. By bypassing intermediate virtual machine hops, container-native routing decreases overall network latency and improves health check accuracy.
To protect internal workloads, you must manage how private virtual machines communicate with the outside world. Cloud NAT acts as a managed gateway that lets private instances fetch system updates or reach external APIs without exposing those instances to direct public internet access. For accessing Google APIs specifically, you can configure Private Google Access to let VMs with internal IPs communicate with services like cloud storage. Together, these tools establish a strict security boundary by blocking arbitrary inbound connections from the internet while allowing safe, outbound-only egress.
A Shared VPC helps large organizations maintain centralized network control while letting individual teams deploy their applications. In this model, a Host Project owns and manages the physical subnets, firewalls, and routing tables, while multiple Service Projects attach their workloads to these shared resources. This architecture enables clear separation between environments, allowing you to isolate production networks from testing networks under unified security policies. This setup ensures that your network security team handles infrastructure compliance while application teams focus on writing code.
Private Service Connect allows you to access external services or Google APIs privately inside your VPC, avoiding the need for complex network peering. This technology uses distinct patterns to secure your connections:
For hybrid setups, traffic coming from on-premises networks crosses over Cloud Interconnect or Cloud VPN. This traffic is managed dynamically by a Cloud Router using the Border Gateway Protocol to automatically update network paths.
To prevent malicious actors or compromised systems from leaking information, VPC Service Controls establish a virtual security boundary. This service perimeter isolates your most sensitive data by blocking unauthorized interactions with Google-managed services, even if those requests have valid credentials. This defense-in-depth tool mitigates the risk of data exfiltration, ensuring that data cannot be copied to unapproved storage buckets outside the perimeter. By separating identity permissions from network boundaries, you protect critical resources from internal and external threats.
When creating a VPC Network, you can build it in one of two distinct structural modes. Auto Mode automatically builds a subnet in every Google Cloud region using pre-allocated IP ranges, which is ideal for quick testing. Custom Mode requires you to define subnets and IP ranges manually, making it the preferred choice for production networks where overlapping IPs must be avoided. A Custom Mode network can also be designated as a Shared VPC, allowing a Host Project to control the network architecture while Service Projects consume the subnets safely.
Connecting physical data centers to the cloud requires evaluating different speeds, costs, and reliability guarantees. Cloud Interconnect provides a dedicated, high-speed physical cable link directly to Google's edge networks for heavy traffic demands. For a more cost-effective setup over the public internet, Cloud VPN secures traffic using encrypted tunnels, with HA VPN guaranteeing high availability through redundant active-active connections. These hybrid options use Cloud Router to dynamically exchange routing paths, ensuring that network failures automatically trigger traffic redirection.
Certain deployment architectures require specialized subnets and name resolution structures to function correctly. When using regional Envoy-based load balancers, you must configure a Proxy-only Subnet to allocate unique IP addresses for the load balancer's internal proxies to use. For naming, Cloud DNS translates server names to IP addresses inside your virtual networks, and you can implement DNS Peering to resolve names across different VPC networks. If you require maximum local reliability within a single zone, Zonal Cloud DNS isolates DNS data and failures to that specific zone.
A robust security posture relies on defining strict rules at the boundaries of your VPC. You can establish a "final drop" strategy using Firewall Rules to ensure that any traffic not explicitly allowed is blocked and logged for auditing purposes. This baseline defense works alongside VPC Service Controls and Private Google Access to prevent unauthorized lateral movement of data within your network. By combining these edge controls with internal firewalls, you protect your system from both external attacks and accidental internal misconfigurations.
StudyCerts
StudyCerts