This overview is designed to help you understand the overall landscape of Google Cloud. 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 Google Cloud in various scenarios.
Google Cloud resources
Google Cloud consists of a set of physical assets, such as computers and
hard disk drives, and virtual resources, such as virtual machines (VMs), that
are contained in
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 Google Cloud services is long, and it keeps growing. When you develop your website or application on Google Cloud, 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 Google Cloud 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 poor performance. Thankfully, Google Cloud 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 Google Cloud, see Geography and Regions.
Any Google Cloud 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 Google Cloud project has the following:
- A project name, which you provide.
- A project ID, which you can provide or Google Cloud can provide for you.
- A project number, which Google Cloud provides.
As you work with Google Cloud, 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 Google Cloud. 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 Google Cloud projects and resources. When you use the Cloud Console, you either create a new project or choose an existing project, and then use the resources that you create in the context of that project. You can create multiple projects and use them 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 at the command line, you can perform most
Google Cloud tasks by using
gcloud command-line tool.
gcloud tool lets you manage development workflow and
Google Cloud resources in a terminal window.
For example, you can create a Compute Engine virtual machine (VM) instance
by running the
gcloud compute instances create command
in the shell environment.
You can run
gcloud commands in the following ways:
You can install the Cloud SDK. The SDK includes the
gcloudtool, so you can open a terminal window on your own computer and run commands to manage Google Cloud resources.
You can use Cloud Shell, which is a browser-based shell. Because it runs in a browser window, you don't need to install anything on your own computer. You can open the Cloud Shell from the Google Cloud Console.
Cloud Shell provides the following:
- A temporary Compute Engine virtual machine instance.
- A built-in code editor.
- 5 GB of persistent disk storage.
- Pre-installed 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 Cloud Console projects and resources.
For a list of
gcloud commands, see the
For more information about Cloud Shell, see How Cloud Shell works.
The Cloud SDK includes client libraries that enable you to easily create and manage resources. Google Cloud 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 Maps, 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 Google Cloud, see the pricing calculator.
Try it for yourself
If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.Get started for free