Google Cloud for AWS Professionals: Networking

Updated April 9, 2019

Compare the networking services that Amazon and Google provide in their respective cloud environments. Networking services provide connectivity across virtual machines, on-premises servers, and other cloud services.

Service model comparison

Amazon Web Services

Amazon EC2-Classic, the original offering from Amazon Web Services, has been deprecated since late 2013 and is not discussed in this document.

Amazon VPC is the current model. The service model offers support for a wide array of networking features in regional VPCs, such as:

  • Support for creating private address spaces and subnetting
  • Network access control lists (NACLs)
  • Inbound and outbound firewall rules
  • Routing
  • VPN

Google Cloud

Google Cloud treats networking as a global feature that spans all services. Google Cloud networking is based on Google's Andromeda architecture, which can create networking elements at any level with software. This software-defined networking allows Google Cloud services to implement networking features that fit the service's exact needs, such as firewalls for virtual machines in Compute Engine, fast connections between database nodes in Cloud Bigtable, or fast query results in BigQuery.

When you create virtual machine instances in a Google Cloud project, Compute Engine automatically connects them to a default internal network. If needed, you can create additional networks as well. As with Amazon VPC, each network is private, and each supports firewall rules, routing, VPNs, private address spaces, and subnetting.

Most of the networking entities in Google Cloud, such as load balancers, firewall rules, and routing tables, have global scope. More importantly, networks themselves have a global scope. This means that you can create a single private IP space that is global, without having to connect multiple private networks and manage those spaces separately. Due to this single, global network, your Compute Engine instances can be addressed within your network by both IP address and name.

Google Cloud offers two Network Service Tiers: Standard Tier, and Premium Tier.

  • The default, Premium Tier, delivers traffic using Google's global network, with high performance.

  • Standard Tier is a lower cost option that offers network performance comparable to other public clouds.

Feature comparison

IP addresses

Google Cloud and Amazon VPC IP addresses have the following similarities:

  • All instances are assigned an internal IP.

  • You can request an external IP. By default, an external IP is ephemeral: it is tied to the life of the instance.

  • You can request a permanent IP address to attach to an instance. This IP address is yours until you choose to release it, and can be attached to, and detached from, instances as needed.

The following table maps the terminology differences for IP types:

IP type AWS Google Cloud
Permanent IP Elastic IP Static IP
Temporary IP Public IP Ephemeral IP
Internal IP Private IP Internal IP

Load balancing

Load balancers distribute incoming traffic across multiple instances. When configured appropriately, load balancers help make apps more resilient to faults and increase app availability.

AWS and Google Cloud load balancing services

Both AWS and Google Cloud offer several load balancing services, collectively referred to as Elastic Load Balancing (AWS), or Cloud Load Balancing (Google Cloud):

  • Internal Layer 4 load balancing
  • External Layer 4 load balancing
  • Internal Layer 7 load balancing
  • External Layer 7 load balancing

AWS load balancing services can be used both internally and externally. Google Cloud load balancing services are separated between external access and internal access. Google Cloud's internal options are Internal TCP/UDP Load Balancing and Internal HTTP(S) Load Balancing.

Note: AWS offers Classic Load Balancer, and two newer load balancing options: Network Load Balancer and Application Load Balancer. This document compares Cloud Load Balancing with the two newer load balancing options. For more information about all AWS load balancers, see the AWS comparison page for Elastic Load Balancing. For more information about load balancing in Google Cloud, see the Cloud Load Balancing feature description page.

AWS and Google Cloud load balancing comparisons

The following table shows a comparison of the external Layer 4 load balancing options: AWS Network Load Balancer and Google Cloud Network Load Balancing.

Feature AWS Google Cloud
Network load balancing Yes Yes
Supported protocols TCP, TLS, UDP TCP, UDP
Multiple ports Yes Yes
Port ranges No Yes
Support for static IP address Yes - one per subnet Yes - one per load balancer
DNS failover Yes Not required, because GCP failover uses a single Anycast IP
Preserve source IP address Yes Yes
Deployment locality Regional Regional
Direct Server Return (DSR) No Yes
Targets VM instances, ECS containers, IP addresses VM instances

The following table shows a comparison of the external Layer 7 load balancing options. Layer 7 load balancing can be implemented in AWS using Application Load Balancer, and in Google Cloud using HTTP(S) Load Balancing, TCP Proxy Load Balancing, or SSL Proxy Load Balancing.

Feature AWS Google Cloud
Supported protocols HTTP, HTTPS HTTP, HTTPS, SSL/TLS, TCP
SSL offloading Yes Yes
Preserve source IP address No No
Multiple ports Yes Yes
Port ranges No No
Deployment locality Regional Global
WebSockets support Yes Yes
Path- and host-based routing Yes Yes
IPv6 support Yes Yes
HTTP/2 support Yes Yes
QUIC support No Yes
Targets VM instances, ECS containers, IP addresses VM instances, Google Kubernetes Engine containers, IP addresses

The following table shows a comparison of the internal load balancing options. AWS load balancing services can be used both internally and externally. Google Cloud offers Internal TCP/UDP Load Balancing and Internal HTTP(S) Load Balancing for internal connections.

Feature AWS Google Cloud
Supported protocols HTTP, HTTPS, TCP, UDP HTTP, HTTPS, TCP, UDP
Preserve source IP address Yes Yes, for TCP, UDP
Multiple ports Yes Yes
Port ranges No No
Deployment locality Regional Regional
Path- and host-based routing Yes No, for TCP and UDP
Yes, for HTTP and HTTPS
Targets VM instances, ECS containers, IP addresses Use TCP/UDP for VM instances
HTTP/HTTPS for Kubernetes pods/containers
IP address endpoints for HTTP and HTTPS

AWS load balancing

AWS's Elastic Load Balancing (ELB) service offers the following capabilities:

  • Enables directing traffic to your instances within one or several availability zones in a given region.
  • Performs regular health checks on each target instance, and redirects traffic if an instance becomes unhealthy.
  • Optional integration with AWS's Auto Scaling service, which enables adding and removing instances automatically when Auto Scaling scales them up or down.

When you create an Elastic Load Balancer, AWS provides a CNAME to which you can direct traffic. If you use AWS's Route 53 service, you can use Elastic Load Balancer as a root domain. Otherwise, you have to use a CNAME for the Elastic Load Balancer.

AWS offers Application Load Balancer for content-based routing and SSL offloading, and Network Load balancer for high-throughput, low latency, Layer 4 connections. See the AWS comparison page for Elastic Load Balancing for a detailed feature comparison.

Google Cloud load balancing

Like ELB, Compute Engine load balancers direct traffic to backend instances in one or many zones. However, unlike ELB, when you provision any external Compute Engine load balancer, you're given a single, globally accessible IP address. This IP address can be used for the lifetime of the load balancer, so it can be used for DNS A Records, allowlists, or configurations in apps. Compute Engine provides three types of load balancers:

  1. For external Layer 4 load balancing, Network load balancing is based on Google's Maglev technology and supports balancing both UDP and TCP traffic regionally. Traffic can be balanced to multiple ports, or to port ranges, and the load balancer does not sit in the return path of the traffic.
  2. For external Layer 7 load balancing, HTTP(S) load balancing, TCP Proxy and SSL proxy can balance traffic using various protocols globally as well as regionally. Traffic is automatically forwarded to the closest backends, based on available capacity.
  3. Internal TCP/UDP Load Balancing is a regional load balancing service supporting TCP and UDP traffic built on top of Andromeda network virtualization stack to provide software-defined load balancing that directly delivers the traffic from the client instance to a backend instance.
  4. Internal HTTP(S) Load Balancing is a regional load balancing service supporting HTTP and HTTPS traffic built on top of Andromeda network virtualization stack and is a managed service based on the open source Envoy proxy. This load balancer provides proxy-based load balancing of Layer 7 application data. It also supports advanced traffic management and TLS termination -- see the Cloud Load Balancing features page for a detailed overview.


AWS and Google Cloud load balancing services have slightly different pricing models.

Google Cloud charges for:

  • Ingress data processed through the load balancer.
  • The number of forwarding rules pointing to the load balancing services.

Additionally, Google Cloud Internal HTTP(S) Load Balancing charges for:

  • Data processed through the load balancer.
  • The number of proxy instances needed to satisfy your traffic needs.

For more information about Google Cloud's load balancing costs, see the pricing documentation.

AWS charges for:

  • Each hour or partial hour that a load balancer is running.
  • The number of Load Balancer Capacity (LCU) units used per hour.

For more information about AWS pricing, and how LCU units are calculated, see the AWS documentation.

Instance migration

The host machines on which instances run occasionally need to be removed from their data centers for maintenance or replacement.

  • AWS: Users must manually migrate their affected instances from host machines, either by rebooting the instances or recreating them using instance snapshots.

  • Google Cloud: Live migration automatically and transparently migrates affected instances.

Connectivity between VPCs

Both AWS and Google Cloud enable networking connections between VPCs.

  • AWS offers VPC Peering and Shared VPCs.

    • VPC Peering enables connections to VPCs within or between AWS Accounts, or regions.

    • Shared VPC enables multiple AWS accounts to use centrally managed VPCs. Subnets can be shared with an AWS account. Security groups within a subnet are controlled by the subnet owner, while network ACLs between subnets and other VPC resources are centrally managed.

  • Google Cloud offers VPC Network Peering and Shared VPC.

    • VPC Network Peering enables connections between Google Cloud projects in the same organizations or between different organizations. Firewall rules and routing are controlled in each project individually.

    • Shared VPC enables private connectivity within an organization. The service offers a VPC that is shared between multiple projects, and has the benefit of centralized administration and controls. Subnets can be shared with one or multiple individuals or teams. All firewall rules and routes are centrally controlled in the host project. You can extend the IP ranges of pre-configured subnetworks without any impact to existing instances and workloads.


There are no fixed charges for using these services.

AWS charges for egress between peered VPCs, even if resources are in the same region or zone.

Private connectivity to other networks

Both AWS and Google Cloud offer multiple services that facilitate private connectivity to outside networks, such as your on-premises environment.

The following table shows a comparison of AWS and Google Cloud services:

Feature AWS Google Cloud
Virtual private network VPC-VPN Cloud VPN
Private connectivity to a VPC Direct Connect Dedicated Interconnect
Partner Interconnect
High speed connectivity to other cloud services Direct Connect Direct Peering
Carrier Peering
CDN connectivity CloudFront CDN Interconnect

Virtual private network

AWS and Google Cloud provide virtual private network (VPN) services that allow you to create a tunnel from an external network to your internal Amazon EC2 or Compute Engine network, and then establish a private connection over that tunnel.

  • Google Cloud: Cloud Router enables dynamic BGP route updates between Compute Engine networks and non-Google networks.

  • AWS: Amazon VPC offers a similar routing service.

Private connectivity to a VPC

In some scenarios, a VPN doesn't provide the speed required by a particular workload, or dedicated capacity is required. Private connectivity services enable leasing a network line that has a dedicated capacity level, connecting directly to a VPC using RFC 1918 addresses.

  • AWS offers Direct Connect, which allows you to create a private leased line to AWS from a partner carrier facility. You can either directly connect to this facility at 1 or 10 Gbps or work with an AWS Partner to facilitate a connection to your premises at speeds from 50 Mbps. You can access remote regions through a Direct Connect Gateway.

  • Google Cloud offers Dedicated Interconnect, which allows you to create direct physical connectivity into your GCP VPC environment from a partner facility in 10 Gbps increments. With Partner Interconnect you can use a partner service to facilitate a connection at speeds from 50 Mbps. With Cloud Router you can choose if you want to have access regionally or to your VPC globally.

High speed connectivity to other cloud services

Both AWS and Google Cloud enable high-speed connectivity when accessing cloud services outside of VPCs.

Google Cloud offers the following services:

  • To connect to cloud services outside your VPC using public IP addresses, Google Cloud offers Direct Peering. The service allows access directly to all Google services, including Google Workspace, by connecting with a private network line in any of Google's Edge Points of Presence.

  • Carrier Peering enables the same features as Direct Peering, but the connection is provided through a partner.

  • Private Google Access for on-premises hosts enables accessing services privately, using Dedicated Interconnect or Partner Interconnect.

AWS offers Direct Connect to access all AWS services through a separate virtual interface.

Content delivery network (CDN) connectivity

CDN connectivity provides discounted egress rates from your resources in the cloud to a CDN provider.

  • Google Cloud provides discounted egress rates to several CDN providers with CDN Interconnect.

  • Amazon provides discounted egress rates only for its own CDN service, Amazon CloudFront.

Costs for connectivity services

AWS and Google Cloud both charge for VPN services at an hourly rate.

Google Cloud and AWS charge a monthly fee per port for their direct private connectivity services: Direct Connect on AWS, and Dedicated Interconnect and Partner Interconnect on Google Cloud. Both Google Cloud and AWS provide discounted egress bandwidth through those services. Partner connections require separate costs that are paid directly to the partner.

Google Cloud doesn't charge for the following services:

  • Direct Peering or Carrier Peering. Google Cloud doesn't charge for these services, but partner charges apply for Carrier Peering.

  • CDN Interconnect. Google Cloud doesn't charge for this service, but partner CDNs set their own rates and charge customers directly. With CDN Interconnect, Google Cloud offers a discount over internet egress rates for traffic towards CDN partners.

Network telemetry

AWS offers network telemetry data through VPC Flow Logs. The service allows you to collect information about the amount of traffic flowing between different addresses and interfaces. Google Cloud enables the same functionality through VPC Flow Logs, but offers the data in a JSON format that contains annotations such as geolocation of external entities, or TCP round-trip time.


Both Google Cloud and AWS charge based on the amount of data generated.


A DNS service translates human-readable domain names to IP addresses that servers use to connect with each other. Managed DNS services, such as Amazon Route 53 (AWS) and Cloud DNS (Google Cloud), offer scalable, managed DNS services in the cloud.

Cloud DNS and Amazon Route 53 have the following similarities:

  • Support for nearly all DNS record types
  • Anycast-based serving
  • Domain name registration

Amazon Route 53 supports two kinds of routing that Cloud DNS does not: geography-based routing and latency-based routing. Geography-based routing lets you restrict your content to certain geographic regions of the world. Latency-based routing lets you direct traffic based on the latency measured by the DNS service.

The following table maps Amazon Route 53 to Cloud DNS features:

Feature Amazon Route 53 Cloud DNS
Zone Hosted zone Managed zone
Support for most DNS record types Yes Yes
Anycast-based serving Yes Yes
Latency-based routing Yes No
Geography-based routing Yes No
DNSSEC for DNS service No Yes
Private zones / Split horizon Yes Yes


Amazon Route 53 and Cloud DNS both charge based on the number of zones hosted per month, and the queries per month. Route 53 charges a higher rate for geographic-based routing and latency-based routing queries.

What's next?

Check out the other Google Cloud for AWS Professionals articles: