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 No, for HTTP/HTTPS |
| 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:
- 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.
- 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.
- 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.
- 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.
Costs
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.
Pricing
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.
Costs
Both Google Cloud and AWS charge based on the amount of data generated.
DNS
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 |
Costs
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: