Pick one of these common workloads to follow its journey through our infrastructure.
Follow the journey a query takes through our infrastructure to return its answer.
We keep your data protected even while it’s in transit. Find out how.
See how Kubernetes Engine automatically scales your app globally.
BigQuery gives you massive computational resources to search vast datasets in seconds. Let’s follow the complex journey each query takes through our infrastructure.Get started
Data encryption is just one of the many layers of security provided by Google Cloud. Learn more about the steps we take to protect your data in transit, including encryption by default.Get started
Kubernetes changed software development by standardizing application packaging models, and Google Kubernetes Engine took it a step further by automating it as a fully-managed service. Ever wonder what happens after you deploy your app on Kubernetes Engine? Let’s follow the journey it takes from your laptop to the cloud.Get started
Google’s network operates like one global computer, ensuring continuous flow of data to and from all corners of the planet.See it from space
While we don’t operate our own wind farms, we do buy enough wind and solar electricity annually to offset every unit of electricity our operations consume, globally—including both our data centers and offices.
High voltage power comes in, and is converted to a medium voltage suitable for connecting to the power equipment attached to the data center. Our data centers use 50% less energy than the typical data center. We keep the temperature at 80°F, use outside air for cooling, and build custom servers. We also share detailed performance data so other businesses can learn from our best practices.
Data flows to and from our data centers over a Google-operated private fiber optic backbone network. Each data center campus has multiple redundant fiber connections so no single failure or fiber cut will cause you to lose your connection to the data center.
The power management distribution center connects to both the substation and generators, so it can distribute power from either. It also converts the medium voltage received from the substation to a low voltage suitable for distribution inside the data center building.
Each of our global regions is made up of different zones. Each zone is isolated from each other inside the region so a problem in one zone will not affect another zone. For fault-tolerant applications with high availability, it’s a good idea to deploy your applications across multiple zones in a region to help protect against unexpected failures.
We also design custom chips, including Titan and Cloud TPUs.
Titan is a secure, low-power microcontroller designed with Google hardware security requirements and scenarios in mind. These chips allow us to securely identify and authenticate legitimate Google devices at the hardware level.
Cloud TPUs were designed to accelerate machine learning workloads with TensorFlow. Each Cloud TPU provides up to 180 teraflops of performance, providing the computational power to train and run cutting-edge machine learning models.
Google has a long history of building our own networking gear, and perhaps unsurprisingly, we build our own network load balancers as well, which have been handling most of the traffic to Google services since 2008. Maglev is our software network load balancer that enables Google Compute Engine load balancing to serve a million requests per second with no pre-warming.
For over a decade, we’ve been building our own network hardware and software to connect all of the servers in our data centers together. In that time, we’ve increased the capacity of a single data center network more than 100x. Our current generation—Jupiter fabrics—can deliver more than 1 Petabit/sec of total bisection bandwidth. To put this in perspective, this provides capacity for 100,000 servers to exchange information at 10Gb/s each, enough to read the entire scanned contents of the Library of Congress in less than 1/10th of a second.
The Networking Room is where the zone's Jupiter cluster network connects to the rest of Google Cloud through Google’s backbone network.
The electricity that powers a data center ultimately turns into heat. Most data centers use chillers or air conditioning units to cool things down, requiring 30-70% overhead in
energy usage. At Google data centers, we often use the “free cooling” provided by the climate through a water system.
The cooling plant receives hot water from the data center floor, and cold water from cooling towers, transferring the waste heat from the hot water to the cold water. Cooled water returns to the data center floor to extract more heat from the equipment there, and hot water flows to the cooling towers to be cooled. This allows us to use the ‘free cooling’ provided by the climate.
We've designed custom cooling systems for our server racks that we've named “Hot Huts” because they serve as temporary homes for the hot air that leaves our servers—sealing it away from the rest of the data center floor. Fans on top of each Hot Hut pull hot air from behind the servers through water-cooled coils. The chilled air leaving the Hot Hut returns to the ambient air in the data center, where our servers can draw the chilled air in, cooling them down and completing the cycle.
Cold water runs from the cooling plant to the data center floor, where it is used to extract heat from inside the "hot huts". The warm water is then returned to the cooling plant where the waste heat is removed, and the water is cycled back to the data center floor.
Ever wonder how many steps BigQuery takes to execute your query in a matter of seconds? Let’s follow your query and see what happens.
Because Google has hundreds of points of presence located all over the world, your nearest PoP is likely to be quite close.
Because the query travels on our private fiber network, it follows a well-provisioned, direct path from the PoP to the data center.
When Google first started, no one made data center networking gear that could meet our needs, so we built our own, which we call Jupiter. Our datacenter networks are built for modularity, constantly upgraded, and managed for availability so we can meet the needs of billions of global users. Most importantly, the same data center networks that power all of our internal infrastructure and services also power Google Cloud Platform.
It takes more than hardware to make your queries run fast. BigQuery requests are powered by Dremel, our massively scalable, interactive, ad-hoc query system, which turns your SQL query into an execution plan. Dremel is what we use inside Google—and it’s available to all Google Cloud customers through BigQuery. In a matter of milliseconds, BigQuery can scale to thousands of CPU cores dedicated to processing your task—no manual operations necessary.
To create the execution plan, Dremel decomposes your query into a series of steps. For each of those steps, Dremel reads the data from storage, performs any necessary computations, and then writes it to the in-memory shuffler. Dremel is widely used at Google—from Search to YouTube to Gmail—so BigQuery users get the benefit of continuous improvements in performance, durability, efficiency and scalability.
It can take milliseconds for BigQuery to send you the answer. We also write the answer to your query to storage so the next time you query it, the system will remember it and process the information even faster. Although there are many steps associated with BigQuery, what’s remarkable is that it can move through them in fractions of a second. In the end, one of the greatest benefits of BigQuery isn’t just that it gives you enormous computing scale for everyday SQL queries, but that it does it without you ever needing to worry about things like software, virtual machines, networks or disks.
When you send a request to a Google Cloud service like Google Cloud Storage or Gmail, that request is first routed by a globally distributed system called Google Front End (GFE). The GFE encrypts your traffic, and provides load balancing and DDoS attack prevention.
Because Google has more than 100 points of presence located all over the world, the nearest PoP is likely to be quite close.
When your data travels from the point of presence to a regional data center location, it’s authenticated by default. Not all data in transit inside Google is protected the same way—if your data leaves the physical boundaries of our network, we encrypt it.
Custom servers, storage and chips—like our Titan security chip—mean we know exactly what hardware is running in our infrastructure, and can verify its origin and identity at startup. Titan signs the boot loader and verifies machine peripherals. Verified boot and signing processes at the chip-level allows us to give every service in the infrastructure a unique cryptographic identity, which it can use to authenticate to other services. This means we can verify whether two services should be communicating with each other.
Google encrypts data prior to it being written to disk. Encryption is inherent in our storage systems—rather than added on afterward. Data for storage is split into chunks, and each chunk is encrypted with a unique data encryption key. Each chunk is then distributed across our storage systems, and is replicated in encrypted form for backup and disaster recovery.
A data encryption key (DEK) is generated for each chunk of data using Google’s common cryptographic library. Two chunks will not have the same encryption key, even if they are part of the same Google Cloud Storage object, owned by the same customer, or stored on the same machine. This partition of data, each using a different key, means the "blast radius" of a potential data encryption key compromise is limited to only that data chunk.
These data encryption keys are then further “wrapped” with the storage system’s key encryption key (KEK). This is done mainly for performance—so that a key unwrapping operation is very efficient, and the number of keys we need to centrally manage is much smaller.
Google’s internal key management service is globally distributed, and was built with resiliency and security in mind. KEKs are not exportable by design, and all encryption and decryption with these keys must be done within the key management service. This means the key management service can be a central point of enforcement.
Here’s what happens in reverse when you access your encrypted data. A user makes a request for their data to a service, like Gmail or Drive, which authenticates and authorizes the user. The service makes a request to the storage system, which verifies the service’s permissions, and retrieves the requested chunks of data. For each data chunk, the service retrieves the data encryption key for that chunk, and sends that to the key management service.
The key management service authenticates the storage system, using its identity. The key management service then decrypts each data encryption key by verifying that the storage system is indeed authorized to use the key encryption key associated with the service. It unwraps each data encryption key, and passes the unwrapped data encryption key back to the storage system. The storage system then receives the unwrapped data encryption keys, and uses these to decrypt the data chunks. It then puts the data back together.
After completing all these steps in fractions of a second, your data is reassembled and sent back to you. Google encrypts your data stored at rest by default, without any action required from you—and all of this almost instantaneously.
Once your app’s been written, it’s ready to be deployed with Kubernetes Engine where you can scale globally, roll out new code without downtime, and automatically stay up-to-date with new releases.
As soon as you deploy your app on Kubernetes Engine, it scales automatically as demand increases, activating new containers on more nodes so that your app can handle anything.
As demand increases, Kubernetes Engine's global load balancer automatically distributes traffic amongst all the containers. If your app gets high traffic in certain parts of the world, Kubernetes Engine will detect that and divert resources to those regions.
Kubernetes Engine's cluster autoscaler automatically resizes clusters, scaling them up or down based on demand. This means you’ll only pay for resources that are needed at any given moment, and you’ll automatically get additional resources when demand increases.
With node auto-repair enabled, Kubernetes Engine will periodically check the health of each node in your cluster, and if they fail, automatically repairs them. This means you won’t need to repair a machine manually at 3am, or scramble on a Sunday to apply a patch.
With node auto-upgrades enabled, Kubernetes Engine automatically keeps the nodes in your cluster up to date with the latest version of Kubernetes. Version updates roll out shortly after a new Kubernetes release.
With cluster management, auto-scaling, auto-repair, and auto-upgrades, Kubernetes Engine truly lets you deploy and forget. That means at the moment of your success, Kubernetes Engine will automatically scale up without any effort on your part. You won’t be turning users away.