- Cloud Router is a fully distributed and managed Google Cloud service that helps you define custom dynamic routes and scales with your network traffic.
Features
- It works with both legacy networks and Virtual Private Cloud (VPC) networks.
- Cloud Router utilizes Border Gateway Protocol (BGP) to exchange routes between your Virtual Private Cloud (VPC) network and your on-premises network.
- Using Cloud Router is required or recommended in the following cases:
- Required for Cloud NAT
- Required for Cloud Interconnect and HA VPN
- A recommended configuration option for Classic VPN
- When you extend your on-premises network to Google Cloud, use Cloud Router to dynamically exchange routes between your Google Cloud networks and your on-premises network.
- Cloud Router peers with your on-premises VPN gateway or router. The routers exchange topology information through BGP.
Route advertisements
- Through BGP, Cloud Router advertises the IP addresses of Google resources that clients in your on-premises network can reach. Your on-premises network then sends packets to your VPC network that have a destination IP address matching an advertised IP range. After reaching Google Cloud, your VPC network’s firewall rules and routes determine how Google Cloud route the packets.
- Default Route Advertisement – Cloud Router advertises subnets in its region for regional dynamic routing or all subnets in a VPC network for global dynamic routing.
- Custom Route Advertisement – You explicitly specify the routes that a Cloud Router advertises to your on-premises network.
- There are several ways to extend your on-premises environment to the Google Cloud Platform.
- You can connect your infrastructure to Google Cloud Platform (GCP) on your terms, from anywhere based on your requirements.
Cloud Interconnect
- Provides low latency, highly available connections that enable you to reliably transfer data between your on-premises and Google Cloud VPCs.
- Cloud Interconnect connections provide internal IP address communication, which means internal IP addresses are directly accessible from both networks.
- Cloud Interconnect offers two options to extend your on-premises network to the Google Cloud Platform:
- Dedicated Interconnect
- Direct physical Connection to Google’s network.
- Partner Interconnect
- Provides connectivity through a supported service provider.
- You can use Cloud Interconnect in combination with Private Google Access for on-premises resources so that your on-premises resources can use internal IP addresses rather than external IP addresses to reach Google APIs and services.
Direct Peering
- Direct Peering connects your on-premises network to Google services, including Google Cloud products that can be exposed via one or more public IP addresses.
- Traffic from Google’s network to your on-premises network also takes that same connection, including traffic from VPC networks in your projects.
- Direct Peering exists outside of Google Cloud Platform. So, unless you need to access Google Workspace applications, the recommended methods of access to Google Cloud Platform are via Dedicated Interconnect or Partner Interconnect.
Carrier Peering
- Carrier Peering enables you to access Google applications, such as Google Workspace, by using a service provider to obtain enterprise-grade network services that connect your infrastructure to Google.
- When connecting to Google through a service provider, you can get connections with higher availability and lower latency, using one or more links.
Cloud VPN
- Cloud VPN securely extends your peer network to Google’s network through an IPsec VPN tunnel.
- Ipsec VPN tunnels encrypt data by using industry-standard Ipsec protocols as traffic traverses the public Internet.
- It only requires a VPN device in your on-premises network, unlike Cloud Interconnect that comes with overhead and costs to set up a direct private connection.
- Cloud VPN pricing is based on the location of the Cloud VPN gateway and the number of tunnels per hour.
- You can create and manage your own virtual topology network where you can launch your Google Cloud resources using Google Virtual Private Cloud (VPC).
- Google VPC is the networking layer of Google Cloud resources.
- A VPC spans all the zones in the region. After creating a VPC, you can add one or more subnets in each zone.
Key Concepts
- A virtual private cloud (VPC) allows you to specify an IP address range for the VPC, add and expand subnets, and configure firewall rules.
- You can expand CIDR ranges without downtime.
- To protect Google Cloud resources, segment your networks by setting up firewall rules.
- Projects can contain multiple VPC networks unless you create an organizational policy that does not allow it.
- New projects start with a default network that has one subnetwork.
- VPC networks including their firewall rules and associated routes are global resources.
- Subnets are regional resources.
- Resources inside the same VPC network can communicate with each other by using an internal IPv4 address but is still subject to applicable network firewall rules.
- Instances with IPv4 addresses can communicate with Google APIs and services.
- Network administration can be secured by using Identity and Access Management (IAM) roles.
Network and Subnets
- Each VPC network consists of one or more useful IP range partitions called subnets.
- Each subnet is associated with a region.
- A network must have at least one subnet before you can use it.
- Auto mode VPC networks create subnets in each region automatically. These automatically created subnets use a set of predefined IP ranges that fit within the 10.128.0.0/9 CIDR block.
- Custom mode VPC networks start with no subnets giving you full control.
- You can create more than one subnet per region.
- You can switch a VPC network from auto mode to custom mode. This is a one-way conversion which means custom mode VPC networks cannot be changed to auto mode VPC networks.
Configuring IP Addresses
- External IP Address
- You should assign an external IP address to instances if you need them to communicate with the Internet.
- Instances support static and ephemeral external IP addresses.
- Internal IP Address
- You should assign a specific internal IP address when you create a VM instance.
- You can reserve a static internal IP address for your project and assign that address to your resources.
- Static external IP addresses can be either a regional or a global resource. A regional static IP address allows resources of that region or resources of zones within that region to use the IP address.
Firewall Rules
- Firewall rules are defined at the network level.
- They only apply to the network where they are created but the name defined for each of them must be unique to the project.
- Firewall rule components
- The direction of connection:
- Ingress rules apply to incoming connections from specified sources to Google Cloud targets
- Egress rules apply to connections going to specified destinations from targets.
- A numerical priority, which determines whether the rule is applied.
- Only the highest priority (lowest priority number) rule whose other components match traffic is applied;
- Conflicting rules with lower priorities are ignored.
- An action upon match, either allow or deny, decides whether the rule permits or blocks connections.
- The enforcement status of the firewall rule.
- A target, which defines the instances to which the rules apply.
- A source for ingress rules or a destination for egress rules.
- The protocol (such as TCP, UDP, or ICMP) and destination port.
Routes
- System-generated default route
- When you create a VPC network, it includes a system-generated default route which serves as a path out of the VPC network, including the path to the Internet, and provides the standard path for Private Google Access.
- Subnet routes – define paths to resources like VMs and internal load balancers in a VPC network.
- Static routes – are defined using static route parameters and support static route next hops.
- Dynamic routes – are routes managed by Cloud Routers inside the VPC network. Their destinations are IP address ranges outside your VPC network, from a BGP peer. Dynamic routes are utilized by:
- Dedicated Interconnect
- Partner Interconnect
- HA VPN tunnels
- Classic VPN tunnels that use dynamic routing
Communications and access for App Engine
- VPC firewall rules apply to resources running in the VPC network. For App Engine instances, firewall rules work as follows:
- App Engine standard environment
- Only App Engine firewall rules apply to ingress traffic. App Engine standard environment instances do not run inside your VPC network which means VPC firewall rules do not apply to them.
- App Engine flexible environment
- Both App Engine and VPC firewall rules apply to ingress traffic. Inbound traffic is only permitted if it is allowed by both types of firewall rules. For outbound traffic, VPC firewall rules shall apply.
Connecting VPC Networks
- An organization can use a Shared VPC to keep a VPC network in a common host project. Authorized IAM members from other projects in the same organization can create resources that use the Shared VPC network’s subnet.
- You can use VPC Network Peering to connect VPCs to other VPC networks located in different projects or organizations.
- VPC networks can be securely connected in hybrid environments by utilizing Cloud VPN or Cloud Interconnect.
Pricing
- No charge for egress through network IP addresses. There are charges though for egress traffic through external IP addresses, even if traffic is in the same zone.
- You are also charged for active and unused static and ephemeral IP addresses inside your VPC.
- The Google Cloud CDN (content delivery network) service accelerates your web content delivery by using Google’s global edge network to bring content as close to the user as possible.
- It helps you reduce latency, cost, and load for your backend services.
Features
- Activates with a single click for Cloud Load Balancing users.
- Cloud CDN supports modern protocols originally developed at Google, like HTTP/2 and QUIC.
- Integrates with Cloud Monitoring and Cloud Logging by providing latency metrics and raw HTTP request logs for deeper and better visibility.
- Logs can be exported to Cloud Storage or BigQuery for analysis.
- Cloud CDN content can be sourced from several types of backends including:
- Instance groups
- Zonal network endpoint groups (NEGs)
- Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
- Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
- Buckets in Cloud Storage
- Cloud CDN also delivers content hosted on-premises or in another cloud over Google’s high-performance distributed edge caching infrastructure.
Pricing
- When Cloud CDN serves your content, you’re charged for:
- Bandwidth
- HTTP/HTTPS requests.
- You are also charged for cache invalidations you initiate.
- Google Cloud Load Balancing allows you to put your resources behind a single IP address.
Features
- Can be set to be available externally or internally with your Virtual Private Network (VPC).
- HTTP(S) load balancing can balance HTTP and HTTPS traffic across multiple backend instances, across multiple regions.
- Enable Cloud CDN for HTTP(S) load balancing to optimize application delivery for your users with a single checkbox.
- You can define the autoscaling policy and the autoscaler performs automatic scaling based on the measured load. No pre-warming required — go from zero to full throttle in seconds.
- Manage SSL certificates and decryption.
Types of Google Cloud Load Balancers
- External Load Balancer
- External HTTP(s)
- Supports HTTP/HTTP(s) traffic
- Distributes traffic for the following backend types:
- Instance groups
- Zonal network endpoint groups (NEGs)
- Serverless NEGs: One or more App Engine, Cloud Run, or Cloud Functions services
- Internet NEGs, for endpoints that are outside of Google Cloud (also known as custom origins)
- Buckets in Cloud Storage
- Scope is global
- Destination ports
- HTTP on 80 or 8080
- HTTPS on 443
- On each backend service, you can optionally enable Cloud CDN and Google Cloud Armor.
- External Network TCP/UDP
- A network load balancer that distributes TCP or UDP traffic among virtual machines in the same region.
- Regional in scope
- Can receive traffic from:
- Any client on the Internet
- Google Cloud VMs with external IP
- Google Cloud VMs that have Internet access through Cloud NAT or instance-based NAT
- Network load balancers are not proxies.
- Load-balanced packets are received by backend VMs with their source IP unchanged.
- Load-balanced connections are terminated by the backend VMs.
- Responses from the backend VMs go directly to the clients, not back through the load balancer. The industry term for this is direct server return.
- SSL Proxy Load Balancer
- Supports TCP with SSL offload traffic.
- It is intended for non-HTTP(S) traffic.
- Scope is global.
- By using SSL Proxy Load Balancing, SSL connections are terminated at the load balancing layer, and then proxied to the closest available backend.
- Destination ports
- 5, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200, and 9300
- TCP Proxy
- Traffic coming over a TCP connection is terminated at the load balancing layer, and then proxied to the closest available backend.
- Destination Ports
- 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200, and 9300.
- Can be configured as a global service where you can deploy your backends in multiple regions and it automatically directs traffic to the region closest to the user.
- Internal Load Balancer
- Internal HTTP(s)
- A proxy-based, regional Layer 7 load balancer that enables you to run and scale your services behind an internal IP address.
- Supports HTTP/HTTP(s) traffic.
- Distributes traffic to backends hosted on Google Compute Engine (GCE) and Google Kubernetes Engine (GKE).
- Scope is regional.
- Load Balancer destination ports
- HTTP on 80 or 8080
- HTTPS on 443
- Internal TCP or UDP
- A regional load balancer that allows you to run and scale your services behind an internal load balancing IP address that is accessible only to your internal virtual machine instances.
- Distributes traffic among virtual machine instances in the same region in a Virtual Private cloud network by using an internal IP address.
- Does not support:
- Backend virtual machines in multiple regions
- Balancing traffic that originates from the Internet
- Cloud DNS is Google’s infrastructure for production quality and high-volume authoritative DNS serving.
Features
- Authoritative DNS Lookup
- Cloud DNS translates requests for domain names like www.google.com into IP addresses like 74.125.29.101.
- Manage your DNS records for your domain using Google Cloud Console.
- Create managed zones for your project so you can add, edit, and delete DNS records.
- You can control permissions at a project level and monitor your changes as they propagate to DNS name servers.
- Can perform DNS Forwarding for hybrid architecture.
- You can create Private DNS zones that provide an easy-to-manage internal DNS solution for your private Google Cloud networks to help you eliminate the need to provision and manage additional software and resources.
- Private DNS logs records on queries received from virtual machines and inbound forwarding flows within your networks.
- View DNS logs in Cloud Logging and export logs to any destination that Cloud Logging export supports.
Pricing
- With Cloud DNS, the charge is per zone per month (regardless of whether you use your zone), and you also pay for queries against your zones.
- The pricing applies both to all zone types: public, private, and forwarding.
- A fully managed NoSQL database service designed for large analytical and operational workloads and enables you to store terabytes or even petabytes of data.
Features
- You can use Cloud BigTable to store and query time-series data.
- It is ideal for storing large amounts of single-keyed data.
- Scales seamlessly from thousands to millions of reads/writes per second.
- Resize your cluster nodes to adjust Cloud Bigtable throughput without restarting – all without downtime.
Pricing
- When you use Cloud Bigtable, you are charged for the following:
- Type of Cloud Bigtable instance
- Total number of nodes in your instance’s clusters
- Amount of storage that your tables use
- Amount of network bandwidth that you use
