This series is designed for technology experts already proficient with Amazon Web Services who are looking to understand Google Cloud. It aims to bridge the gap by mapping the core concepts, products, and terminology you are familiar with in AWS to their counterparts in the Google Cloud ecosystem. We will explore both the similarities and the key differences in philosophy and architecture. This comparative approach will provide the foundational knowledge needed to confidently navigate this new platform, leveraging your existing expertise in cloud infrastructure. We will begin by examining the very bedrock of both platforms: the global infrastructure, accounts, and core management interfaces.
The Google Cloud Foundation
For over two decades, Google has built and managed one of the largest, fastest, and most sophisticated cloud infrastructures on the planet. This global foundation was not originally built for public consumption; it was engineered to power Google’s own planet-scale services, including its core Search engine, Gmail, Maps, and YouTube. These high-traffic applications demanded extreme reliability, low latency, and massive scalability. As a result, Google invested heavily in optimizing its infrastructure and creating a suite of powerful internal tools to manage it efficiently. Google Cloud is the externalization of this battle-tested infrastructure and management suite, making the same resources and innovations available to developers and businesses worldwide.
Understanding Regions and Zones
Like AWS, Google Cloud’s services are available in regions and zones located across the globe. An AWS region is a physical location in the world where multiple Availability Zones are clustered. Each AWS AZ consists of one or more discrete data centers, each with redundant power, networking, and connectivity, housed in separate facilities. Similarly, Google Cloud regions are large geographical areas that are subdivided into zones. These zones are isolated failure domains within a region. They are the primary locations where you deploy resources like virtual machines. For a complete mapping of all available locations, you can consult the official Google Cloud documentation on its locations page.
The AWS Availability Model
By design, AWS regions are completely isolated and independent from other AWS regions. This architecture ensures that the availability of one region does not impact the availability of another. This is a core tenet of AWS’s design, providing high fault tolerance. Services within a region, such as an EC2 instance, are also generally independent of services in other regions. While this isolation is excellent for fault tolerance, it means that building multi-region applications requires you to explicitly manage data replication, cross-region networking, and failover mechanisms. The Availability Zones within a single region are connected with high-bandwidth, low-latency networking, allowing you to build highly available applications that span AZs.
The Google Cloud Global Model
Google Cloud’s regions are also isolated from each other for availability. However, a key difference in philosophy is Google’s built-in functionality that enables services to synchronize data across regions according to the needs of a given service. This is most evident in Google’s networking. A Google Cloud Virtual Private Cloud (VPC) is a global resource by default, meaning you can have subnets in different regions within the same VPC, and they can communicate over Google’s private backbone without complex peering. This global-by-default nature for key services like load balancers, VPCs, and some storage options is a significant architectural difference from the region-centric model of AWS.
Global, Regional, and Zonal Resources
This distinction between global, regional, and zonal resources is a critical concept for AWS professionals to grasp. In AWS, most resources are regional. An EC2 instance, an EBS volume, and a VPC are all tied to a single region. To use them elsewhere, you must create new resources in the other region. In Google Cloud, the hierarchy is more explicit. Some resources are global, such as a global load balancer, a VPC network, or a Compute Engine machine image. Other resources are regional, such as a regional managed instance group or a regional persistent disk. Finally, some resources are zonal, such as a Compute Engine virtual machine instance or a standard persistent disk. Understanding which resources live at which scope is fundamental to designing robust applications on the platform.
The Role of Points of Presence
Both Google Cloud and AWS utilize a network of Points of Presence, or POPs, in many more locations around the world than their core data center regions. These POP locations are used to cache content closer to end-users, reducing latency. However, each platform uses its POPs in different ways. AWS primarily uses its POPs to deliver its content delivery network service, Amazon CloudFront. When you use CloudFront, your content is cached at these edge locations, providing faster delivery to your users.
Google’s Private Network and POPs
Google Cloud also uses its POPs to provide its content delivery network, Google Cloud CDN, as well as built-in edge caching for services like Cloud Storage and App Engine. However, there is a more significant function: Google’s POPs are entry points to its massive, private, software-defined global network. When traffic from a user hits a Google POP, it does not traverse the public internet to reach your services. Instead, it is immediately brought onto Google’s high-speed, low-latency, Google-owned fiber backbone and carried privately to the data center region hosting your application. This unimpeded connection means that applications based on Google Cloud have fast, reliable, and secure access to the full range of services, often resulting in lower latency for end-users.
Content Delivery Network Comparison
For an AWS professional, the go-to CDN service is Amazon CloudFront. It is a highly configurable, powerful service that is set up as a “distribution” in front of an origin, such as an S3 bucket or a load balancer. It offers deep customization, security features like WAF integration, and advanced capabilities. Google Cloud CDN operates differently. It is not a standalone service in the same way. Instead, it is a feature that you enable with a single checkbox on a Google Cloud global load balancer. Once enabled, it automatically caches content at Google’s numerous POPs. While it may seem simpler, it is deeply integrated and leverages the same infrastructure that Google uses to serve its own content, providing high performance.
Shifting Your Infrastructure Mindset
The most significant mental shift for an AWS professional moving to Google Cloud is moving from a region-first to a global-first mindset, especially for networking. In AWS, your design process starts with picking a region. In Google Cloud, you can start by thinking about your application globally. You can have a single global load balancer with a single Anycast IP address that routes traffic to backend instances in the regions closest to your users, all within a single VPC network. This simplifies the architecture for global applications, removing the need for complex DNS-based routing or third-party global load balancing solutions.
Navigating the New Management Landscape
For any AWS professional, a deep understanding of AWS accounts, AWS Organizations, and Identity and Access Management (IAM) is foundational to security and governance. Google Cloud has a different, though analogous, model for organizing, managing, and securing resources. Instead of the “account” being the primary container, Google Cloud uses a “project.” Understanding this hierarchical model, along with its unique approach to billing and resource management, is the first step toward building a secure and well-architected environment. This part will map the AWS constructs you know to their new Google Cloud counterparts, starting with the most fundamental unit: the project.
The AWS Account and Organization Structure
To set a baseline, let’s review the AWS model. In AWS, the account is the primary, fundamental container. It provides a hard boundary for security, resource isolation, and billing. All resources like EC2 instances or S3 buckets live within an account. For managing multiple accounts, AWS provides AWS Organizations. This service allows you to group accounts into Organizational Units (OUs), apply central governance policies called Service Control Policies (SCPs) to restrict what services can be used, and consolidate billing into a single payer account. This model is powerful but is often described as a “bolted-on” enhancement to the original single-account model.
The Google Cloud Project Model
In Google Cloud, the fundamental unit of organization is the project. A project is a container for all your cloud resources. It is where you enable and manage APIs for services, manage billing, and control permissions. Every resource you create, such as a Compute Engine virtual machine or a Cloud Storage bucket, must belong to a project. Each project has a unique project name, a project ID, and a project number. This project-based model is a significant departure from the AWS account model. You can think of a single Google Cloud project as being similar in scope to a single AWS account, but it is more lightweight and designed to be used in greater numbers, often to isolate individual applications or environments (e.t., “prod-app-one” and “dev-app-one”).
Resource Hierarchy: From OUs to Folders
Where AWS uses Organizations and OUs to manage accounts, Google Cloud uses a resource hierarchy. At the very top of this hierarchy is the Organization node. This node represents your company. Below the Organization, you can create folders. Folders are used to group projects and other folders, allowing you to model your company’s structure, such as creating folders for different departments (e.g., “Engineering,” “Marketing”) or environments (e.g., “Production,” “Development”). Projects are then placed within these folders. This hierarchical structure (Organization > Folders > Projects > Resources) is a core part of the platform, not an add-on. It provides a powerful and logical way to manage policies and permissions, which are inherited down the tree.
Identity and Access Management (IAM) Philosophy
Both platforms use a service called Identity and Access Management, or IAM, but their philosophies differ. AWS IAM is a complex and powerful system centered on policies. These JSON-based policies are attached to identities (users, groups, or roles) or to resources themselves. An AWS IAM policy explicitly defines who can do what to which resources under what conditions. Google Cloud IAM, by contrast, is conceptually simpler. It is built around the triad of “Who,” “What,” and “Where.” The “Who” is the member (e.g., a user account, a group, or a service account). The “What” is the role, which is a collection of permissions (e.g., “Compute Instance Admin”). The “Where” is the resource (e.g., a project, a folder, or a specific virtual machine) to which the policy is attached.
Comparing IAM Roles and Policies
In AWS, you spend a lot of time writing and debugging JSON policies. In Google Cloud, you will spend more time assigning roles to members. Google Cloud provides three types of roles. First are basic roles: Owner, Editor, and Viewer. These are broad, powerful roles that apply at the project level and are similar to the original administrator and read-only roles in AWS. Second are predefined roles, which are granular, service-specific roles like “roles/compute.instanceAdmin” or “roles/storage.objectViewer.” These are the strong equivalent of AWS’s managed policies. Finally, you can create custom roles, which are collections of permissions you define, similar to an AWS customer-managed policy. Permissions in Google Cloud IAM are inherited from parent to child in the resource hierarchy.
The Service Account Analogy
In AWS, a common pattern for granting permissions to a service, such as an EC2 instance, is to use an IAM Role. The instance “assumes” this role, which grants it temporary credentials to access other services, like S3 or DynamoDB, without hardcoding access keys. The direct equivalent in Google Cloud is a service account. A service account is a special type of “member” in Google Cloud IAM. It is an identity that represents an application or a virtual machine, not a human user. You create a service account, grant it the specific IAM roles it needs (e.g., “Storage Object Creator”), and then attach that service account to your Compute Engine VM. The VM can then use this identity to automatically authenticate to other Google Cloud APIs.
Billing and Cost Management Concepts
In AWS, billing is managed through Consolidated Billing within AWS Organizations. You have a payer account, and all member accounts’ charges roll up to it. You use tools like AWS Cost Explorer to analyze and visualize your spending. Google Cloud’s model is different and provides powerful flexibility. Billing is managed via a Cloud Billing Account. This billing account is set up separately and then linked to one or more projects. All charges for resources within a linked project are then charged to that billing account. This model allows you to link projects from different organizations to a single billing account (e.g., for a consultancy managing client projects) or to have multiple billing accounts within one organization (e.g., for different subsidiaries with separate payment methods).
Understanding Pricing and Discounts
The source article mentions that pricing changes frequently, but the models are important. AWS is famous for its Reserved Instances (RIs) and, more recently, Savings Plans, which provide a significant discount in exchange for a one- or three-year commitment. AWS also has Spot Instances for massive, short-term discounts. Google Cloud offers similar concepts. The equivalent of RIs or Savings Plans are Committed Use Discounts (CUDs). You can commit to a certain level of vCPU and memory usage for a one- or three-year term. A key difference is that Google Cloud also offers Sustained Use Discounts (SUDs). These are automatic discounts applied to Compute Engine VMs that run for a significant portion of the month. There is no commitment required; the longer you run a VM, the larger the automatic discount becomes, simplifying cost management for steady-state workloads.
Limits, Quotas, and Management Interfaces
Both platforms have default soft limits, as the source article notes. AWS calls these “service limits,” while Google Cloud calls them “quotas.” In Google Cloud, quotas are managed at a per-project level and often per-region. You can monitor your quota usage and request increases directly from the Google Cloud console. For management interfaces, the AWS CLI is the standard tool for AWS. Google Cloud provides the Cloud SDK, which includes the gcloud command-line tool. Both are powerful, cross-platform CLIs. You can also use the Cloud SDK directly in your browser via the Google Cloud Shell, which is a persistent, pre-authenticated command-line environment with the SDK and other common tools pre-installed, available from anywhere. Both platforms also provide full-featured web-based consoles for managing resources.
Comparing Core Compute Services
Compute is the engine of the cloud. For AWS professionals, compute primarily means Amazon EC2, with a growing ecosystem of containers (ECS, EKS) and serverless (Lambda). Google Cloud offers a direct and powerful set of counterparts for each of these. The core Infrastructure as a Service (IaaS) offering is Google Compute Engine, the container ecosystem is anchored by Google Kubernetes Engine, and the serverless portfolio includes Cloud Functions and the highly popular Cloud Run. This part will dissect these compute services, mapping your EC2 knowledge to GCE, your container strategy to GKE, and your serverless patterns to Google’s equivalents, highlighting key differentiators like live migration and custom machine types.
Virtual Machines: Amazon EC2 vs. Google Compute Engine
Amazon EC2 is the most well-known IaaS service in the world, offering a vast and sometimes bewildering array of instance families and types optimized for different workloads. As an AWS expert, you are accustomed to choosing from families like ‘m’ for general purpose, ‘c’ for compute-optimized, or ‘r’ for memory-optimized. Google Compute Engine (GCE) is the direct competitor. GCE also offers predefined machine types that align with these same categories. However, GCE has two standout features. The first is its extremely fast boot time; GCE VMs often provision in seconds. The second, and perhaps more significant, is the ability to create custom machine types. Instead of being forced to pick a predefined shape, GCE allows you to specify the exact amount of vCPU and memory you need, which can lead to significant cost savings by rightsizing your instances.
A Key Differentiator: Live Migration
One of the most compelling features of Google Compute Engine, and a significant difference from EC2, is live migration. Google Cloud uses live migration to keep your virtual machine instances running even when a host system event occurs, such as a software or hardware update. During a host maintenance event, Google automatically migrates your running instance to another host in the same zone. This process is transparent to the user and the application; the instance continues to run, and its network connections are maintained. This dramatically reduces the need for reboots and maintenance windows that AWS users often have to plan for. This feature is enabled by default for most GCE instances and is a core part of Google’s high-availability promise.
Instance Purchasing Models
In AWS, you manage costs using a mix of On-Demand instances, Spot Instances (for interruptible, market-priced workloads), and long-term commitments like Reserved Instances or Savings Plans. Google Cloud has an analogous but simpler set of models. On-Demand instances are the standard, billed per second. The equivalent of Spot Instances are Preemptible VMs (PVMs). PVMs offer a massive discount (up to 80%) but can be “preempted” or shut down at any time, with a 30-second warning. Unlike Spot, their price is fixed, not market-driven. For long-term commitments, Google offers Committed Use Discounts (CUDs), which are a direct parallel to RIs and Savings Plans. Finally, Google offers automatic Sustained Use Discounts (SUDs) for any VM that runs for more than 25% of a month, with no commitment required, rewarding steady-state workloads.
Machine Images and Boot Disks
In AWS, the template for your virtual machine is the Amazon Machine Image (AMI). AMIs are a regional resource; to launch an instance in a new region, you must first copy the AMI to that region. The root volume for an EC2 instance is an Elastic Block Store (EBS) volume. Google Cloud’s equivalent of an AMI is a machine image. Images in Google Cloud are global resources, meaning you can use a single image to launch instances in any region around the world without needing to copy it first. The root volume for a GCE instance is a Persistent Disk, which is the direct equivalent of EBS. These disks are zonal by default but can also be created as regional disks, which are synchronously replicated across two zones in a region for higher availability.
Scaling and Load Balancing
For horizontal scaling in AWS, you use Auto Scaling Groups (ASGs) to manage a fleet of EC2 instances. You place an Elastic Load Balancer (ELB) in front of the ASG to distribute traffic. ELBs come in different flavors, such as Application Load Balancers (ALB) and Network Load Balancers (NLB), which are regional resources. Google Cloud’s equivalent of an ASG is a Managed Instance Group (MIG). A MIG can be zonal or regional and manages a group of identical GCE instances. The load balancing story is a key differentiator. Google Cloud Load Balancing is a global, software-defined service. You can create a single global load balancer with a single Anycast IP address. This load balancer can have backend instances in multiple regions (via their MIGs), and it will automatically route user traffic to the closest healthy backend, providing global-scale, low-latency, and high-availability without complex DNS configuration.
The Kubernetes Engine: EKS vs. GKE
Both platforms are dominant forces in the container ecosystem, and both offer a managed Kubernetes service. AWS offers the Elastic Kubernetes Service (EKS). EKS provides a managed Kubernetes control plane, while you (traditionally) manage the EC2 worker nodes that form the data plane. Google’s offering is the Google Kubernetes Engine (GKE). GKE is widely regarded as a more mature and feature-rich managed Kubernetes service, which is unsurprising given that Google originally invented Kubernetes (as an open-source version of its internal “Borg” orchestrator). GKE features like a more automated cluster lifecycle, node auto-repair, and a deep integration with Google’s operations suite make it a favorite among developers. GKE also offers an “Autopilot” mode that completely abstracts away the worker nodes, creating a truly serverless Kubernetes experience.
Container Orchestration Alternatives
While Kubernetes is the market leader, it is not the only option. AWS has its own proprietary orchestrator, the Elastic Container Service (ECS). ECS is often seen as a simpler, more tightly integrated alternative to EKS for running containers on AWS, especially when paired with AWS Fargate, which provides a serverless compute engine for containers. Google Cloud’s primary alternative to GKE is Cloud Run. Cloud Run is a fully managed, serverless platform that allows you to run stateless containers. It is not an orchestrator in the same way as ECS; it is a platform for running container images that are automatically scaled up or down, even to zero, based on incoming HTTP requests. It is an incredibly simple and powerful way to deploy containerized applications and microservices.
Serverless Functions: AWS Lambda vs. Google Cloud Functions
For event-driven, serverless compute, AWS Lambda is the pioneer and market leader. Lambda allows you to run code in response to events, such as an object being uploaded to S3 or a request to an API Gateway, without managing any servers. Google Cloud Functions is the direct equivalent. It is also an event-driven serverless compute platform, allowing you to run small snippets of code (in languages like Node.js, Python, Go, etc.) in response to events. These events can come from Google Cloud services like Pub/Sub or Cloud Storage, or they can be triggered by HTTP requests. While Lambda has a more mature ecosystem and a wider range of event sources, Cloud Functions is deeply integrated into the Google Cloud environment and is a natural choice for event-driven automation.
Platform as a Service: Elastic Beanstalk vs. App Engine
Before containers and serverless functions, there was Platform as a Service (PaaS). AWS’s PaaS offering is Elastic Beanstalk. You provide your application code (e.g., a Java, Node.js, or Python application), and Elastic Beanstalk automatically provisions and manages the underlying infrastructure, including EC2 instances, an auto-scaling group, a load balancer, and application health monitoring. Google’s original PaaS, and one of its very first cloud products, is Google App Engine. App Engine provides a fully managed platform for building and running applications. It comes in two flavors: the “Standard” environment, which is a highly restrictive but massively scalable “sandbox,” and the “Flexible” environment, which runs your application in a Docker container, giving you more control. App Engine is a powerful, fully-managed solution for web applications.
A New Landscape for Data Storage
Data is the lifeblood of modern applications, and an AWS professional has a rich toolkit of storage services: Amazon S3 for object storage, Amazon EBS for block storage, and Amazon EFS for file storage, not to mention various archival and data transfer services. Google Cloud provides a one-to-one mapping for these core storage needs, with Google Cloud Storage, Persistent Disk, and Filestore. However, as with its compute services, Google Cloud’s storage offerings have unique architectural differences—such as multi-regional storage buckets and regional persistent disks—that can simplify the design of highly available and globally distributed applications. This part will explore these parallels and powerful distinctions.
Object Storage: Amazon S3 vs. Google Cloud Storage
Amazon S3 is arguably the most well-known cloud service in the world, setting the standard for object storage. As an AWS user, you are familiar with S3 buckets, which are created in a specific region, and a variety of storage classes to optimize cost. Google Cloud Storage (GCS) is the direct equivalent. Like S3, GCS provides a scalable, durable, and highly available service for storing unstructured data. A key difference, however, is the concept of a bucket’s “location.” While you can create a GCS bucket in a single region (just like S3), you can also create buckets that are “dual-regional” or “multi-regional.” A multi-regional bucket automatically and redundantly stores your data across multiple regions within a continent (e.g., the United States), providing extreme availability and low-latency access for users across that geography without you having to manage any replication.
Object Storage Classes and Lifecycle Management
AWS S3 offers a granular spectrum of storage classes to manage costs: S3 Standard for frequent access, S3 Intelligent-Tiering for unknown access patterns, S3 Standard-Infrequent Access, S3 One Zone-IA, and multiple archival tiers under the Glacier brand. Lifecycle policies are used to automate the transition of objects between these tiers. Google Cloud Storage simplifies this with four primary storage classes: Standard, Nearline, Coldline, and Archive. Nearline is for data accessed less than once a month, Coldline for data accessed less than once a quarter, and Archive for data accessed less than once a year. Each of these tiers has a progressively lower storage cost but a higher retrieval cost. GCS also has lifecycle management policies, allowing you to automatically change an object’s storage class or delete it based on rules, such as the object’s age.
Block Storage: Amazon EBS vs. Persistent Disk
For high-performance block storage attached to your virtual machines, AWS provides Amazon Elastic Block Store (EBS). An EBS volume is created in a specific Availability Zone and can only be attached to an EC2 instance in that same AZ. To move it, you must detach it or create a snapshot. Google Cloud’s equivalent is Persistent Disk (PD). A standard Persistent Disk is a zonal resource, just like EBS, and is attached to a Compute Engine instance in that same zone. However, Persistent Disk also offers a “regional” type. A regional PD provides synchronous replication of your data across two zones in the same region. You can attach a regional PD to an instance, and if that instance’s zone fails, you can force-attach the disk to a new instance in the other zone, providing a simple and robust high-availability solution for stateful workloads.
Persistent Disk Features and Flexibility
Beyond its regional replication capability, Google Cloud’s Persistent Disk has other features that differ from EBS. Persistent Disks can be resized while they are attached to a running VM, and the new size is often available to the operating system immediately without a reboot. This provides great flexibility for managing storage growth. Furthermore, a standard zonal or regional Persistent Disk can be attached to multiple virtual machines simultaneously, but only in “read-only” mode. This multi-attach, read-only capability is very useful for scenarios where you need to share common, static data across a fleet of compute instances, such as web servers or data processing workers, without needing a full network file system.
Instance Storage: EC2 Instance Store vs. Local SSD
Both platforms offer ephemeral, high-performance storage that is physically attached to the host machine running your virtual machine. In AWS, this is called the EC2 Instance Store, and it is available on specific instance types. This storage provides very high IOPS and low latency, but any data stored on it is lost when the instance is stopped or terminated. It is ideal for temporary data, caches, or scratch space. The Google Cloud equivalent is Local SSD. You can attach one or more Local SSD partitions to a Compute Engine VM when you create it. Like Instance Store, Local SSDs provide extremely high performance, and the data on them does not persist if the instance is stopped or deleted. It serves the exact same use cases: caching, buffering, or as storage for high-performance, fault-tolerant databases.
File Storage: Amazon EFS vs. Google Cloud Filestore
For managed, scalable network file storage (NFS), AWS offers Amazon Elastic File System (EFS). EFS provides a simple, serverless, “set-and-forget” elastic file system that can be mounted by thousands of EC2 instances across multiple Availability Zones in a region. It scales automatically as you add or remove files and you pay only for the storage you use. Google Cloud’s managed NFS solution is called Cloud Filestore. Filestore is a different type of service; it is a high-performance, provisioned NFS server. Instead of being elastic, you provision a Filestore instance with a specific service tier (Basic, High Scale, etc.) and a fixed capacity. This model provides extremely low latency and predictable, high performance for workloads like media rendering or genomics processing, but it is less elastic in its pricing and scaling model compared to EFS.
Archival Storage Deep Dive
For long-term, low-cost archival, AWS is famous for the Amazon S3 Glacier brand, which includes several tiers like Glacier Instant Retrieval, Glacier Flexible Retrieval (formerly Glacier), and Glacier Deep Archive. These offer a spectrum of retrieval times (from milliseconds to hours) and costs. As mentioned, the Google Cloud Storage equivalent is the “Archive” storage class. This is the lowest-cost, long-term storage available on the platform. It is designed for data accessed less than once a year, such as for regulatory compliance or disaster recovery. Retrieval from the Archive class is not instant and incurs a higher retrieval cost, making it analogous to the Glacier tiers. The simpler GCS class structure (Standard, Nearline, Coldline, Archive) is often easier to manage than the more complex and granular S3 tiers.
Data Transfer and Hybrid Storage
Both platforms provide a suite of tools for moving large amounts of data into the cloud. AWS has the AWS Snowball family (Snowball, Snowmobile) for offline appliance-based transfer, and AWS DataSync for online transfer. Google Cloud has its Transfer Appliance for offline transfers and the Storage Transfer Service for managing online data movement from other cloud providers (like S3) or on-premises locations. For hybrid storage, AWS Storage Gateway provides on-premises access to cloud storage. Google Cloud often partners with third-party NAS providers for hybrid file scenarios, integrating their solutions with the core Google Cloud platform.
Choosing the Right Storage in Google Cloud
For the AWS professional, the mapping is straightforward at a high level. If you use S3, you will use Google Cloud Storage. If you use EBS, you will use Persistent Disk. If you use EFS, you will evaluate Cloud Filestore. The key is to look beyond the one-to-one mapping and leverage the unique architectural benefits of the Google Cloud platform. This means considering a multi-regional GCS bucket instead of managing S3 cross-region replication yourself. It means evaluating a regional Persistent Disk for high availability instead of building your own disk-level replication. These built-in, higher-level abstractions can significantly simplify your architecture.
The Data-Driven Cloud
While compute and storage are the foundation, the true power of a cloud platform is unlocked by its managed data services. AWS provides an incredibly broad portfolio, including Amazon RDS for relational databases, DynamoDB for NoSQL, and Redshift for data warehousing. Google Cloud not only has direct competitors for these services but also brings its own unique, planet-scale innovations to the table, such as Cloud Spanner and BigQuery. For data analytics professionals, this is where Google Cloud’s history of managing massive, global datasets truly shines. This part will compare the database and analytics services that are crucial for modern applications.
Relational Databases: Amazon RDS vs. Google Cloud SQL
Amazon Relational Database Service (RDS) is the go-to service for managed relational databases on AWS. It supports multiple engines, including MySQL, PostgreSQL, SQL Server, and Oracle, and it manages the provisioning, patching, backups, and high-availability (Multi-AZ) configurations. The direct counterpart on Google Cloud is Cloud SQL. Cloud SQL provides a fully managed service for MySQL, PostgreSQL, and SQL Server. Like RDS, it handles all the mundane database administration tasks, including automated backups, replication, and high-availability configuration with a single click. For any AWS professional who has used RDS, Cloud SQL will feel very familiar and intuitive.
Cloud-Native Relational: Amazon Aurora vs. Google Cloud Spanner
This is where the comparison becomes more interesting. AWS’s flagship relational database is Amazon Aurora, a high-performance, MySQL and PostgreSQL-compatible database with a custom, log-structured storage backend that provides high availability and read scaling. Google Cloud’s flagship relational offering is Cloud Spanner. Spanner is not just a managed MySQL; it is a unique, globally distributed, horizontally scalable, and strongly consistent relational database. Spanner allows you to build applications that can scale to millions of transactions per second across the globe, all while maintaining strict transactional consistency using a SQL interface. It is a fundamentally different class of database, designed for planet-scale applications, and has no direct equivalent in the AWS portfolio.
Managed NoSQL: Amazon DynamoDB vs. Cloud Bigtable
For high-performance NoSQL, Amazon DynamoDB is the key-value and document database standard on AWS. It delivers single-digit millisecond latency at any scale and is a fully managed, serverless database. Google Cloud offers two primary NoSQL services. The first is Cloud Bigtable. Bigtable is a managed wide-column NoSQL database, the same database that powers Google Search, Maps, and Gmail. It is built for massive-scale (petabytes), high-throughput, and low-latency analytical workloads. It is not a direct DynamoDB equivalent; it is more analogous to a managed Apache HBase. It is ideal for time-series data, financial data, or IoT data streams, but less so for general-purpose web application backends.
Managed NoSQL: DynamoDB vs. Google Cloud Firestore
The other Google Cloud NoSQL offering, and a much closer competitor to DynamoDB for application developer use cases, is Google Cloud Firestore (or its predecessor, Cloud Datastore). Firestore is a flexible, scalable, and fully managed document database. It is designed to be the backend for web, mobile, and IoT applications. Its key features include real-time data synchronization (where changes in the database are pushed to connected clients automatically) and a strong “offline-first” SDK for mobile and web. While DynamoDB is a pure key-value/document store, Firestore is more of a comprehensive backend solution for building responsive applications, making it a strong competitor in the serverless application space.
Data Warehousing: Amazon Redshift vs. Google BigQuery
This is one of the most famous and important comparisons in the cloud. Amazon Redshift is a powerful, petabyte-scale data warehouse based on PostgreSQL. Traditionally, it required you to provision and manage a cluster of nodes, though it has recently added a serverless option. It is a powerful tool for complex SQL analytics. Google’s offering is BigQuery. BigQuery is a fully managed, serverless, “petabyte-scale” data warehouse that is one of Google Cloud’s most defining services. With BigQuery, there are no clusters to manage or nodes to provision. It is a true serverless platform where you pay for the data you store and the queries you run. Its architecture, which separates storage and compute, allows it to scale to massive datasets and handle complex SQL queries with incredible speed. For many, BigQuery is a primary reason to choose Google Cloud.
Data Stream Processing: Amazon Kinesis vs. Google Cloud Dataflow
For real-time data streaming, AWS provides Amazon Kinesis. Kinesis is a family of services that includes Kinesis Data Streams (for ingesting and storing streams, similar to Apache Kafka), Kinesis Data Firehose (for loading streams into data stores), and Kinesis Data Analytics (for processing streams with SQL). Google Cloud’s solution is different. For ingestion, it provides Google Cloud Pub/Sub, a global, scalable message bus. For processing, it provides Google Cloud Dataflow. Dataflow is a fully managed service for executing data processing pipelines written using the open-source Apache Beam SDK. The power of Beam and Dataflow is that they provide a unified programming model for both batch and stream processing, allowing you to write your pipeline once and run it on historical batch data or live streaming data with minimal changes.
Message Queuing: SQS/SNS vs. Google Cloud Pub/Sub
In AWS, application integration is handled by two distinct services: Amazon Simple Queue Service (SQS) for durable, decoupled message queues, and Amazon Simple Notification Service (SNS) for publish/subscribe (pub/sub) fan-out messaging. Google Cloud combines these two concepts into a single, powerful service: Google Cloud Pub/Sub. Pub/Sub is a global, fully managed messaging service that supports both queuing (via “pull” subscriptions) and fan-out (via multiple “push” or “pull” subscriptions to a single topic). Because it is a global service, a publisher in one region can publish a message that is then consumed by subscribers in multiple other regions around the world, all on a single topic, simplifying global application architecture.
ETL and Data Pipelines
For Extract, Transform, and Load (ETL) workloads, AWS offers AWS Glue, a fully managed ETL service that uses a serverless Apache Spark environment, as well as the older AWS Data Pipeline. Google Cloud’s ecosystem for this is rich. For custom pipelines, Dataflow (Apache Beam) is the preferred tool for transformation. For managed Hadoop and Spark clusters (similar to AWS EMR), Google Cloud offers Dataproc. Dataproc clusters can be created in seconds, are deeply integrated with BigQuery and Cloud Storage, and are billed per second. For a no-code, graphical ETL experience, Google Cloud also offers Data Fusion, which is a fully managed service based on the open-source Cask Data Application Platform (CDAP).
Business Intelligence and Visualization
After you have stored and processed all your data, you need to visualize it. AWS’s native BI tool is Amazon QuickSight, a cloud-powered BI service that allows you to create and share interactive dashboards. Google Cloud’s primary, free visualization tool is Looker Studio (formerly known as Data Studio). Looker Studio is a web-based tool that integrates seamlessly with BigQuery and hundreds of other data sources to create rich, interactive dashboards. For more advanced, enterprise-grade BI, Google also offers Looker, a separate, acquired, and deeply integrated platform that provides a powerful modeling layer and governance for enterprise-wide business intelligence.
Beyond Infrastructure: Advanced Cloud Services
We have covered the core pillars of compute, storage, and data. This final part explores the higher-level services that build on this foundation. As the source article mentions, these can be grouped into machine learning, management services, and application services. For an AWS professional, this means mapping your experience with Amazon SageMaker, CloudWatch, and CloudFormation to their powerful Google Cloud counterparts. This is where Google’s deep history in artificial intelligence and planet-scale site reliability engineering (SRE) becomes evident in its product design.
The Machine Learning Landscape
Both AWS and Google are leaders in the AI and machine learning space, but they come from different backgrounds. AWS has built a very broad and deep set of ML services, with Amazon SageMaker at its center, catering to data scientists and developers. Google, as one of the world’s primary AI research organizations, infuses machine learning into many of its products. Its platform, Vertex AI, is designed to unify the entire ML lifecycle, leveraging Google’s own powerful innovations like TensorFlow and TPUs (Tensor Processing Units), which are custom-designed hardware for ML workloads.
ML Platforms: Amazon SageMaker vs. Google Vertex AI
Amazon SageMaker is a comprehensive, modular platform. It is not a single service but a suite of tools for every step of the ML lifecycle: data labeling (SageMaker Ground Truth), notebooks, training, optimization, and deployment. You can pick and choose the components you need. Google Cloud’s offering is Vertex AI. Vertex AI is a unified platform designed to provide a more seamless, end-to-end MLOps experience. It integrates managed datasets, an “AutoML” track for building models with no code, and a “Custom Training” track for advanced users. It aims to reduce the friction between experimentation and production, making it easier to manage, deploy, and monitor models at scale.
Pre-built AI and ML APIs
For developers who are not data scientists but want to add AI capabilities to their applications, both platforms offer a suite of pre-trained APIs. In AWS, this includes services like Amazon Rekognition for image and video analysis, Amazon Polly for text-to-speech, and Amazon Transcribe for speech-to-text. Google Cloud has a parallel set of powerful APIs: the Vision AI API, the Speech-to-Text AI API, and the Natural Language AI API, among others. Both sets of services are highly competitive and very powerful, allowing you to integrate sophisticated AI into an application with a simple API call. Google’s APIs are often lauded for their quality, building on the research that powers Google Photos, Google Assistant, and Google Translate.
Monitoring and Observability: CloudWatch vs. Cloud Operations
The source article maps Amazon CloudWatch to Google Stackdriver. This suite is now known as Google Cloud Operations. Amazon CloudWatch is the foundational observability service in AWS, providing metrics, logs (CloudWatch Logs), and alarms. It is a solid, reliable, and essential service. The Google Cloud Operations suite (formerly Stackdriver) is a powerful and deeply integrated set of tools. It includes Cloud Monitoring (for metrics and dashboards), Cloud Logging (for log management), Cloud Trace (for distributed tracing), and Cloud Debugger (for debugging live applications). Many users find Google’s logging and monitoring to be more powerful and easier to use out of the box, with a more advanced query language and faster log ingestion.
Infrastructure as Code (IaC)
For deploying infrastructure as code, the native AWS solution is AWS CloudFormation. It uses JSON or YAML templates to define and provision a “stack” of AWS resources. The native Google Cloud equivalent is Cloud Deployment Manager (CDM). CDM also uses YAML templates and is a capable, stateful IaC tool. However, a key difference in the community is that the open-source tool Terraform, by HashiCorp, is often treated as a first-class citizen by Google. Google actively co-develops the Google Cloud Terraform provider and it is very common for organizations on Google Cloud to use Terraform as their primary IaC tool, even more so than the native CDM.
Understanding the Foundations of Cloud Networking
The evolution of cloud computing has fundamentally transformed how organizations approach networking and security infrastructure. While the concept of global virtual private clouds provides the foundational networking layer, the true power of modern cloud platforms emerges through their higher-level networking services. These sophisticated services enable businesses to manage complex networking requirements, handle massive traffic volumes, and maintain robust security postures without the burden of managing physical infrastructure.
The distinction between foundational networking and application-level networking represents a critical understanding for cloud architects and engineers. Foundational networking deals with the core connectivity between resources, such as virtual machines, containers, and storage systems. Application-level networking, however, focuses on how external users and services interact with your applications, how traffic is routed intelligently across global infrastructure, and how APIs are exposed, managed, and secured at scale.
Modern enterprises require networking solutions that can handle diverse workloads, from simple web applications to complex microservices architectures. The networking services provided by major cloud platforms have evolved to meet these demands, offering managed services that abstract away much of the complexity while providing granular control when needed. These services form the critical bridge between your applications and the users who depend on them, making them essential components of any cloud architecture.
Domain Name System Management in the Cloud
The Domain Name System serves as the internet’s phonebook, translating human-readable domain names into IP addresses that computers use to identify each other on the network. In cloud environments, DNS management becomes even more critical because applications are distributed across multiple regions, availability zones, and sometimes even multiple cloud providers. The ability to manage DNS efficiently and reliably directly impacts application availability, performance, and disaster recovery capabilities.
Cloud platforms offer managed DNS services that eliminate the operational overhead of running your own DNS infrastructure. These services provide high availability through globally distributed DNS servers, automatic scaling to handle query volumes that can reach millions of requests per second, and built-in protection against DNS-based attacks. The managed nature of these services means that cloud providers handle the underlying infrastructure, software updates, and security patches, allowing organizations to focus on configuring their DNS records and routing policies.
Advanced DNS management in cloud environments extends far beyond simple domain name resolution. Modern DNS services support sophisticated routing policies that can direct traffic based on geographic location, health checks, weighted distributions, and latency measurements. This enables organizations to implement multi-region architectures where users are automatically directed to the nearest healthy application endpoint, improving both performance and reliability.
The integration of DNS services with other cloud components creates powerful capabilities. DNS can trigger automated failover during outages, support blue-green deployments by allowing instant traffic switching between different application versions, and enable gradual rollouts by progressively shifting traffic percentages. These capabilities make DNS a critical component in modern deployment strategies and disaster recovery plans.
Health checking functionality within managed DNS services provides continuous monitoring of application endpoints. When an endpoint becomes unhealthy, the DNS service automatically stops routing traffic to it, ensuring users are only directed to functioning resources. This self-healing capability significantly improves application availability without requiring manual intervention or complex monitoring systems.
API Gateway Services and Management
Application Programming Interfaces have become the fundamental building blocks of modern software architecture. As organizations embrace microservices, mobile applications, and third-party integrations, the number and complexity of APIs grow exponentially. Managing these APIs effectively requires specialized infrastructure that can handle authentication, rate limiting, request transformation, and monitoring at scale.
API gateway services provide a managed solution for creating, publishing, maintaining, monitoring, and securing APIs. These gateways act as a front door for applications to access data, business logic, or functionality from backend services. By centralizing API management, organizations gain consistent control over how their services are accessed and used, while backend services remain isolated and protected from direct external access.
The architecture of a modern API gateway encompasses multiple critical functions. Request routing directs incoming API calls to the appropriate backend service, which might be a serverless function, a container, or a virtual machine. Request and response transformation allows the gateway to modify data formats, add or remove headers, and adapt legacy backend systems to modern API standards. This transformation capability proves invaluable when integrating diverse systems or maintaining backward compatibility.
Authentication and authorization represent crucial security functions performed by API gateways. The gateway can validate API keys, JSON Web Tokens, or integrate with identity providers to ensure only authorized clients can access specific APIs. This centralized authentication simplifies security management and prevents each backend service from implementing its own authentication logic, reducing complexity and potential security vulnerabilities.
Rate limiting and throttling protect backend systems from being overwhelmed by too many requests. API gateways can enforce usage quotas, implement burst limits, and provide different rate limits for different customer tiers. This capability ensures fair resource usage, protects against denial of service attacks, and enables monetization strategies based on API consumption.
Monitoring and analytics built into API gateway services provide visibility into API usage patterns, performance metrics, and error rates. Organizations can identify which APIs are most popular, detect performance bottlenecks, and troubleshoot issues quickly. This data-driven insight enables continuous optimization and helps inform decisions about resource allocation and API design.
Support for different API protocols and patterns has become essential. Modern gateways handle traditional REST APIs with their stateless request-response model, but also support WebSocket APIs for real-time bidirectional communication. WebSocket support enables applications like chat systems, live dashboards, and collaborative editing tools that require instant updates without constant polling.
Enterprise-Grade API Management Platforms
While basic API gateway services suffice for many use cases, large enterprises with extensive API programs require more comprehensive solutions. Enterprise API management platforms provide a complete lifecycle approach to API development, deployment, and governance. These platforms extend beyond simple gateway functionality to encompass API design, developer portals, monetization, and advanced analytics.
The concept of full-lifecycle API management recognizes that APIs require structured processes from initial design through retirement. API design tools help teams create consistent, well-documented APIs that follow organizational standards and industry best practices. Version management ensures that updates to APIs can be deployed without breaking existing integrations, while deprecation features provide a controlled path for retiring outdated API versions.
Developer experience stands as a critical differentiator for enterprise API platforms. Developer portals serve as a centralized location where external and internal developers can discover available APIs, read documentation, test endpoints in interactive sandboxes, and register their applications. Self-service API key provisioning accelerates integration projects by allowing developers to get started immediately without waiting for manual approval processes.
Monetization capabilities enable organizations to treat APIs as products, creating revenue streams from their data and services. These platforms support various pricing models including pay-per-call, tiered subscriptions, and freemium approaches. Billing integration automates the process of tracking API usage and generating invoices, while analytics help optimize pricing strategies based on actual consumption patterns.
Advanced security features in enterprise platforms include threat detection, API traffic analysis to identify suspicious patterns, and data loss prevention capabilities. These platforms can automatically detect and block common API attacks such as injection attempts, broken authentication, and excessive data exposure. Integration with security information and event management systems provides comprehensive security monitoring across the entire technology stack.
Multi-cloud and hybrid cloud support becomes increasingly important as organizations adopt complex cloud strategies. Enterprise API management platforms that can operate consistently across different cloud providers and on-premises environments enable organizations to avoid vendor lock-in and maintain flexibility in their infrastructure choices. This consistency simplifies management and ensures uniform API policies regardless of where backend services run.
API governance features help organizations maintain control over their API ecosystem as it grows. Policy enforcement ensures all APIs comply with security standards, performance requirements, and data protection regulations. Approval workflows can require review before new APIs are published or existing APIs are modified. Compliance reporting demonstrates adherence to industry regulations and internal policies.
Security Services and Architecture
Security in cloud environments requires a fundamentally different approach than traditional on-premises security. The distributed nature of cloud resources, the dynamic provisioning and deprovisioning of infrastructure, and the shared responsibility model between cloud providers and customers create unique challenges and opportunities. Comprehensive cloud security encompasses identity and access management, threat detection, security monitoring, and encryption services.
Identity and access management forms the cornerstone of cloud security. Every interaction with cloud resources, whether by a human user, an application, or a service, requires authentication and authorization. Modern IAM systems provide fine-grained control over who can access what resources and what actions they can perform. The principle of least privilege guides IAM configuration, ensuring entities only receive the minimum permissions necessary to accomplish their tasks.
Role-based access control simplifies permission management by grouping related permissions into roles that can be assigned to users or services. Rather than managing individual permissions for each entity, administrators assign appropriate roles based on job functions or application requirements. This approach reduces complexity and minimizes the risk of over-permissioning that often occurs with ad-hoc permission grants.
Service accounts provide identity for applications and automated processes. Unlike human users, services require long-lived credentials and often need to authenticate programmatically. Proper service account management prevents security issues that arise when developers hardcode credentials in application code or configuration files. Integration with secret management systems ensures credentials are stored securely and rotated regularly.
Multi-factor authentication adds an additional security layer beyond passwords. By requiring a second form of verification such as a one-time code from a mobile device or a biometric confirmation, MFA significantly reduces the risk of unauthorized access even if passwords are compromised. Modern IAM systems support various MFA methods and can enforce MFA requirements for sensitive operations or privileged accounts.
Threat Detection and Security Monitoring
Continuous monitoring for security threats represents a critical capability in cloud environments where attacks can occur at any time from anywhere in the world. Automated threat detection services analyze vast amounts of log data, network traffic, and resource configurations to identify suspicious activity, potential vulnerabilities, and active attacks. These services leverage machine learning and threat intelligence to distinguish normal behavior from malicious activity.
Anomaly detection identifies unusual patterns that may indicate security incidents. For example, a user account suddenly accessing resources in a geographic region where they never operated before, or a compute instance generating unusually high outbound network traffic, could signal compromised credentials or a malware infection. By establishing baselines of normal behavior and alerting on deviations, these systems help security teams respond quickly to potential threats.
Integration with threat intelligence feeds provides context about known malicious actors, compromised IP addresses, and emerging attack techniques. When cloud resources interact with known bad actors or exhibit behaviors associated with specific attack patterns, threat detection systems can automatically raise alerts or trigger automated responses. This intelligence-driven approach improves detection accuracy and reduces false positives.
Security monitoring platforms aggregate findings from multiple sources including threat detection services, vulnerability scanners, configuration assessments, and compliance checks. This centralized view enables security teams to prioritize issues based on severity and potential impact. Automated prioritization helps teams focus on the most critical security risks rather than being overwhelmed by low-priority findings.
Automated response capabilities enable immediate action when threats are detected. Instead of simply alerting human responders, modern security systems can automatically isolate compromised resources, revoke suspicious credentials, block malicious IP addresses, or trigger incident response workflows. This automation dramatically reduces the time between threat detection and containment, limiting potential damage.
Encryption and Key Management
Data protection through encryption ensures that even if unauthorized parties gain access to data, they cannot read or use it without the appropriate decryption keys. Cloud platforms provide encryption services for data at rest and data in transit, but the effectiveness of encryption depends entirely on proper key management. Compromised encryption keys render encryption useless, making key management services critical security components.
Encryption at rest protects data stored in databases, object storage, block storage, and other persistent storage systems. Cloud platforms can automatically encrypt data using provider-managed keys, or organizations can use their own keys for additional control. The choice between provider-managed and customer-managed keys involves trade-offs between convenience and control. Provider-managed keys require no operational overhead but give the cloud provider access to encryption keys, while customer-managed keys provide more control but require organizations to manage key lifecycle operations.
Encryption in transit protects data as it moves between systems. This includes traffic between clients and applications, between different services within a cloud environment, and between cloud environments and on-premises systems. Transport Layer Security provides encryption for most network communications, but proper certificate management and protocol configuration are essential to maintain security. Mutual TLS authentication adds an additional security layer by verifying both client and server identities.
Key management services provide secure storage, access control, and lifecycle management for encryption keys. These services use hardware security modules to protect keys from unauthorized access and ensure cryptographic operations occur in secure, tamper-resistant environments. Automatic key rotation reduces the risk associated with long-lived keys by periodically generating new keys and re-encrypting data.
Audit logging for key usage enables security teams to track which entities accessed which keys and when. This visibility proves essential for compliance requirements and security investigations. Comprehensive logs capture key creation, deletion, rotation, and usage, creating a complete audit trail of cryptographic operations.
Zero Trust Security Architecture
Traditional security models assume that everything inside an organization’s network can be trusted, focusing security controls on the network perimeter. This approach fails in cloud environments where there is no clear perimeter, resources are distributed globally, and users access applications from various locations and devices. Zero trust security replaces the perimeter-based model with the principle that no user or service should be trusted by default, regardless of network location.
The core tenets of zero trust include verifying every access request explicitly, using least privilege access principles, and assuming breach. Verification requires strong authentication and authorization for every resource access, not just initial network entry. Least privilege ensures entities only receive the minimum access needed for specific tasks, with permissions granted just-in-time when possible. Assuming breach means designing systems to limit the impact of compromised credentials or resources through network segmentation and continuous monitoring.
Identity becomes the new security perimeter in zero trust architectures. Every user, device, and service must prove its identity before accessing resources. Context-aware access policies consider multiple factors including user identity, device health, location, and risk level when making authorization decisions. High-risk access attempts may trigger additional verification steps or be denied entirely.
Microsegmentation divides cloud environments into small, isolated segments with specific security controls. Rather than allowing broad network access once authenticated, microsegmentation ensures that services can only communicate with explicitly authorized endpoints. This containment strategy limits lateral movement if an attacker compromises a resource, preventing them from easily accessing other systems.
Continuous verification replaces the traditional approach of authenticate once and trust until session expiration. Zero trust systems continuously evaluate risk throughout a session, potentially requiring re-authentication or additional verification if user behavior or context changes. This ongoing assessment ensures that compromised credentials or devices can be detected and addressed quickly.
Integration and Unified Security Management
The multitude of security services and tools available in cloud platforms creates both opportunities and challenges. While specialized services provide deep capabilities for specific security domains, managing numerous disparate tools can become overwhelming. Unified security management platforms integrate findings from multiple security services, providing a centralized view of security posture and enabling coordinated response to incidents.
Security orchestration, automation, and response capabilities tie together various security tools and automate common workflows. When a threat is detected, orchestration systems can automatically gather additional context from multiple sources, assess the severity based on comprehensive information, and execute appropriate response actions. This automation accelerates incident response while reducing the manual effort required from security teams.
Compliance management features help organizations maintain adherence to regulatory requirements and industry standards. Automated compliance checks continuously assess cloud configurations against frameworks such as payment card industry standards, health insurance portability requirements, and data protection regulations. Compliance dashboards provide visibility into adherence levels and highlight areas requiring remediation.
Conclusion
The sophistication of application networking and security services in modern cloud platforms reflects the complex requirements of contemporary digital businesses. From DNS management and API gateways to comprehensive security monitoring and zero trust architectures, these services provide the building blocks for secure, scalable, and reliable cloud applications. Organizations that effectively leverage these capabilities can focus on innovation and business value rather than infrastructure management, while maintaining robust security postures in an increasingly threat-filled digital landscape. The continued evolution of these services promises even greater capabilities, with increasing automation, intelligence, and integration making cloud security and networking more accessible and effective for organizations of all sizes.