This overview is designed to help you understand the overall landscape of Google Cloud Platform (GCP). Here, you'll take a brief look at some of the commonly used features and get pointers to documentation that can help you go deeper. Knowing what's available and how the parts work together can help you make decisions about how to proceed. You'll also get pointers to some tutorials that you can use to try out GCP in various scenarios.
GCP consists of a set of physical assets, such as computers and hard
disk drives, and virtual resources, such as virtual machines (VMs), that are
Google's data centers
around the globe.
Each data center location is in a region. Regions are available in
Asia, Australia, Europe, North America, and South America.
Each region is a collection of zones, which
are isolated from each other within the region. Each zone is identified by a
name that combines a letter identifier with the name of the region. For example,
a in the East Asia region is named
This distribution of resources provides several benefits, including redundancy in case of failure and reduced latency by locating resources closer to clients. This distribution also introduces some rules about how resources can be used together.
Accessing resources through services
In cloud computing, what you might be used to thinking of as software and hardware products, become services. These services provide access to the underlying resources. The list of available GCP services is long, and it keeps growing. When you develop your website or application on GCP, you mix and match these services into combinations that provide the infrastructure you need, and then add your code to enable the scenarios you want to build.
Global, regional, and zonal resources
Some resources can be accessed by any other resource, across regions and zones. These global resources include preconfigured disk images, disk snapshots, and networks. Some resources can be accessed only by resources that are located in the same region. These regional resources include static external IP addresses. Other resources can be accessed only by resources that are located in the same zone. These zonal resources include VM instances, their types, and disks.
The following diagram shows the relationship between global scope, regions and zones, and some of their resources:
The scope of an operation varies depending on what kind of resources you're working with. For example, creating a network is a global operation because a network is a global resource, while reserving an IP address is a regional operation because the address is a regional resource.
As you start to optimize your GCP applications, it's important to understand how these regions and zones interact. For example, even if you could, you wouldn't want to attach a disk in one region to a computer in a different region because the latency you'd introduce would make for very poor performance. Thankfully, GCP won't let you do that; disks can only be attached to computers in the same zone.
Depending on the level of self-management required for the computing and hosting service you choose, you might or might not need to think about how and where resources are allocated.
For more information about the geographical distribution of GCP, see Geography and Regions.
Any GCP resources that you allocate and use must belong to a project. You can think of a project as the organizing entity for what you're building. A project is made up of the settings, permissions, and other metadata that describe your applications. Resources within a single project can work together easily, for example by communicating through an internal network, subject to the regions-and-zones rules. A project can't access another project's resources unless you use Shared VPC or VPC Network Peering.
Each GCP project has:
- A project name, which you provide.
- A project ID, which you can provide or GCP can provide for you.
- A project number, which GCP provides.
As you work with GCP, you'll use these identifiers in certain command lines and API calls. The following screenshot shows a project name, its ID, and number:
In this example:
- Example Project is the project name.
- example-id is the project ID.
- 123456789012 is the project number.
Each project ID is unique across GCP. Once you have created a project, you can delete the project but its ID can never be used again.
When billing is enabled, each project is associated with one billing account. Multiple projects can have their resource usage billed to the same account.
A project serves as a namespace. This means every resource within each project must have a unique name, but you can usually reuse resource names if they are in separate projects. Some resource names must be globally unique. Refer to the documentation for the resource for details.
Ways to interact with the services
Google Cloud gives you three basic ways to interact with the services and resources.
Google Cloud Console
The Google Cloud Console provides a web-based, graphical user interface that you can use to manage your GCP projects and resources. When you use the Cloud Console, you create a new project, or choose an existing project, and use the resources that you create in the context of that project. You can create multiple projects, so you can use projects to separate your work in whatever way makes sense for you. For example, you might start a new project if you want to make sure only certain team members can access the resources in that project, while all team members can continue to access resources in another project.
If you prefer to work in a terminal window, the
Google Cloud SDK provides the
gcloud command-line tool,
which gives you access to the commands you need. The
gcloud tool can be used
both your development workflow and your GCP resources. See the gcloud
reference for the complete list of available
- A temporary Compute Engine virtual machine instance.
- Command-line access to the instance from a web browser.
- A built-in code editor.
- 5 GB of persistent disk storage.
- Pre-installed Google Cloud SDK and other tools.
- Language support for Java, Go, Python, Node.js, PHP, Ruby and .NET.
- Web preview functionality.
- Built-in authorization for access to GCP Console projects and resources.
The Cloud SDK includes client libraries that enable you to easily create and manage resources. GCP client libraries expose APIs for two main purposes:
App APIs provide access to services. App APIs are optimized for supported languages, such as Node.js and Python. The libraries are designed around service metaphors, so you can work with the services more naturally and write less boilerplate code. The libraries also provide helpers for authentication and authorization.
Admin APIs offer functionality for resource management. For example, you can use admin APIs if you want to build your own automated tools.
You also can use the Google API client libraries to access APIs for products such as Google Maps, Google Drive, and YouTube.
To browse pricing details for individual services, see the price list.
To estimate your total costs for running a specific workload on GCP, see the pricing calculator.