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
By default, resources in a Virtual Private Cloud (VPC) network cannot reach Google APIs or external services without a public IP address. To solve this, Private Google Access allows private resources to connect securely to Google APIs over internal IP addresses. Alternatively, Private Service Connect creates a service abstraction that allows a consumer to access Google APIs or services hosted in another VPC using internal endpoints. This keeps sensitive traffic off the public internet, reducing exposure to external threats.
To connect serverless environments like Cloud Run or Cloud Functions to private VPC resources, you must configure a Serverless VPC Access connector. The serverless service routes its outbound traffic through this connector, which assigns it an internal IP address capable of reaching databases or virtual machines within the private network. This setup is crucial for applications that must interact with private backends without exposing either end to the public internet.
Administrators can manage Private Service Connect components through three main features. First, endpoints use internal IP addresses to route requests to Google services. Second, backends use integration with load balancers to manage traffic destined for published services. Finally, service attachments act as producer-side resources that expose the private service to consumers.
To further secure these connections, a Shared VPC can centralize network policy by letting a single host project manage subnets for multiple service projects. Additionally, VPC Service Controls create a security perimeter around cloud resources to prevent data exfiltration. Using these tools together ensures that serverless workloads can only communicate with authorized services in a highly secure environment.
A VPC network serves as the basic private boundary for all cloud resources. Using a custom-mode VPC is a best practice because it gives network admins complete control over subnet IP ranges and regional setups. In larger setups, a Shared VPC allows a central team to manage these subnets, while developers deploy Compute Engine virtual machines and GKE clusters in their own projects.
For modern container networking, VPC-native clusters are the recommended standard because they assign each Pod a unique, routable address from alias IP ranges. This structure allows GKE Pod traffic to be managed directly by VPC firewall rules, eliminating the need for complex routing tables. Effective IP address management is critical during cluster design to prevent running out of addresses as GKE automatically scales nodes and Pods. Choose this VPC-native model for:
To secure VM and container workloads, administrators should limit external IP addresses and use Private Google Access for internal service calls. When private Compute Engine VMs or GKE nodes need to retrieve software updates from the internet, Cloud NAT provides secure network address translation. Cloud NAT allows outbound connections to pass through but blocks unsolicited inbound traffic, and using fixed external IPs helps satisfy third-party IP whitelisting requirements.
Securing containerized workloads requires a multi-layered approach using VPC firewall rules at the VM level and Kubernetes network policies at the Pod level. While VPC firewall rules control traffic entering GKE nodes, network policies restrict lateral movement between containers inside the cluster. You can improve this setup by using namespaces to logically segment resources and using Identity-Aware Proxy (IAP) to control user access based on identity rather than network location.
Cloud Load Balancing acts as the front door for user traffic, distributing workloads across regions to ensure high availability. For GKE clusters, container-native load balancing uses Network Endpoint Groups (NEGs) to route traffic directly to individual Pod IPs, reducing latency by avoiding extra network hops through GKE nodes. This load-balancing setup integrates seamlessly with Horizontal Pod Autoscaling to automatically adjust compute capacity based on user demand.
Google Cloud VMware Engine (GCVE) is a fully managed service that lets organizations run VMware environments directly on Google Cloud bare metal infrastructure. To establish hybrid connectivity between an on-premises data center and GCVE, administrators can deploy Cloud VPN for encrypted internet tunnels or Cloud Interconnect for high-speed, physical links. This hybrid integration allows organizations to migrate workloads to the cloud while keeping their existing VMware tools and operations.
Connecting GCVE to a native VPC requires VPC Network Peering to enable private routing between the VMware environment and Google Cloud resources. Within the GCVE private cloud, NSX-T operates as the software-defined networking layer that manages virtual machine segments and micro-segmentation. Network administrators must carefully configure these NSX-T segments to ensure seamless communication between VMware workloads and other native cloud services.
To protect public-facing VMware workloads, administrators can deploy third-party network appliances from the Google Cloud Marketplace to act as firewalls. These appliances sit directly in the network path to perform deep packet inspection and intrusion prevention, supporting a defense-in-depth strategy. Key security features for these designs include:
Moving existing workloads into GCVE is simplified by VMware HCX, which manages the migration paths between on-premises sites and the cloud. Once the workloads are running in GCVE, Cloud Load Balancing can distribute incoming traffic to ensure high availability. Adding Cloud Armor security policies to the load balancer provides additional edge protection against common web attacks, keeping the migrated applications secure and scalable.
StudyCerts
StudyCerts