Fundamental Cloud Concepts

Study guide for Cloud Digital Leader, Unit 1 · Topic 2. This is the topic's lecture in reading form — every slide's teaching, figures and worked examples, in order — followed by the official Google Cloud pages its claims rest on.

What the exam guide asks. Explain general cloud concepts.

Objectives, quoted from the exam guide:

1. Describe how transitioning to a cloud infrastructure affects flexibility, scalability, reliability, elasticity, agility, and total cost of ownership (TCO). Apply these concepts to various business use cases.
2. Explain how an organization’s transition from an on-premises environment to the cloud shifts their capital expenditures (CapEx) to operational expenditures (OpEx), and how that affects their total cost of ownership (TCO).
3. Identify when private, hybrid, or multicloud infrastructures best apply to different business use cases.
4. Define basic network infrastructure terminology, including: IP address; internet service provider (ISP); domain name server (DNS), regions, and zones; fiber optics; subsea cables; network edge data centers, latency; and bandwidth.
5. Discuss how Google Cloud supports digital transformation with global infrastructure and data centers connected by a fast, reliable network.

Fundamental cloud concepts

What moving to cloud changes: the system, the money, the place, the path

The system — six properties, each with its own mechanism. The money — capital expenditure becomes operational expenditure, and total cost still counts management. The place — private, hybrid or multicloud, read from the scenario. The path — how a user's request reaches Google's network, and the words for every step.

Topic one asked why cloud is transforming business. Topic two asks what, concretely, changes when a workload moves — and the guide's summary for it is just four words: explain general cloud concepts. Its five objectives fall into four questions. What happens to the system itself: six properties — flexibility, scalability, reliability, elasticity, agility and total cost — each with a different mechanism underneath. What happens to the money: spending moves from buying assets up front to paying as resources are consumed, and that changes what total cost of ownership means. Where the workload should live: private, hybrid or multicloud, which the exam asks as a scenario rather than a definition. And how a user actually reaches it: the network vocabulary — addresses, names, providers, regions, zones, cables, the edge, latency and bandwidth — and the global network Google runs underneath all of it. Keep those four questions in view and the objectives stop being a list.

Six properties, six different mechanisms

What the cloud changes about each one

Worked example (synthetic). A ticketing site sells out twice a year. Scalability says it can grow for the sale; elasticity says it shrinks again afterwards without anyone deciding to — and only the second changes the bill.

The first objective lists six properties, and the exam separates candidates who can attach each one to its mechanism from those who treat them as synonyms. Flexibility is about reach and adaptation: Google says enterprises and their users can access cloud services from anywhere with an internet connection, and calls flexibility and versatility one of the hallmarks of cloud, allowing enterprises to quickly adapt to changing markets or metrics. Scalability is about growth without ownership — scaling faster and more efficiently without the burden of buying and maintaining your own data centers and servers. Elasticity is the one most often confused with it. Google describes cloud-native applications as designed to take advantage of the elasticity of the cloud, and the concrete mechanism is autoscaling: managed instance groups automatically add or delete virtual machine instances based on increases or decreases in load. Scalability is being able to grow; elasticity is capacity that follows the load in both directions. Reliability is about failure: putting resources in different zones reduces the risk of one infrastructure outage affecting everything at once, and different regions give an even higher degree of failure independence. Agility is about time — new applications reach production without worrying about the underlying infrastructure. And total cost of ownership is about what you count: Google's framework says to consider not only the cost of provisioning and using resources, but also the cost of managing them.

Which property answers which business case

The exam gives you the situation, never the property's name

Figure. Six cards, each pairing a business complaint with the cloud property that answers it: elasticity for a one-week traffic peak, agility for an earlier launch, reliability for a facility failure, flexibility for staff in many countries, total cost of ownership for patching overhead, and scalability for long-term growth.

Worked example (synthetic). An item describes a firm whose peak lasts a week and asks which property cuts its idle spend. Scalability is the tempting answer; elasticity is the graded one, because the saving comes from scaling back in.

The objective does not stop at naming the properties — it says apply these concepts to various business use cases, and that is how the exam asks. You get a complaint, not a property name, so rehearse the mapping in that direction. Paying for idle servers after a short peak is elasticity: Google says autoscaling helps apps gracefully handle increases in traffic and reduce costs when the need for resources is lower. A launch date that moved earlier is agility. A facility failure that must not stop the business is reliability, answered by copies in different zones. Staff spread across many countries is flexibility — access from anywhere with an internet connection. The fifth card is the one candidates miss: virtual machines that looked cheap, and a team spending its weeks patching them. Google's framework says exactly this — virtual machines might be a cost-effective option, but when you consider the overhead to maintain, patch and scale them, the total cost of ownership can increase. And steady long-term growth is scalability. Two of these cards sound alike — the peak and the growth — and the difference is direction: growth only goes up, while elasticity comes back down.

From capital expenditure to operational expenditure

Buying assets up front becomes paying as you consume

• On-premises: assets are acquired, then depreciated over their operating life
• Cloud: most costs are OpEx, incurred when the resources are consumed
• No capacity bought ahead of demand, and none overbuilt for spikes
• TCO still counts managing what you run, not just upfront costs

Worked example (synthetic). A clinic network plans an imaging archive. On-premises, finance approves a hardware purchase and depreciates it for years. On cloud, the archive is an operating cost that tracks what is stored — cancelled in month four, it stops costing in month four.

The second objective is the money, and Google's cost optimization framework states the difference in one line: the cost models for on-premises and cloud workloads differ significantly. On-premises information technology (IT) costs include both capital expenditure, or CapEx, and operational expenditure, or OpEx. The capital part works like this: hardware and software assets are acquired, and the acquisition costs are depreciated over the operating life of the assets. The organization pays first and uses later, for years, whether or not the capacity is needed. In the cloud, the costs for most resources are treated as OpEx, incurred when the resources are consumed. That is why Google's cloud computing page says enterprises get scalable resources without needing to worry about capital expenditures or limited fixed infrastructure, only pay for the computing resources they use, and do not need to overbuild data center capacity to handle unexpected spikes. Two cautions keep this from becoming a slogan. First, the word is most: Google notes you might be able to classify the cost of some services, such as Compute Engine sole-tenant nodes, as capital expenditure. Second, the shift does not by itself lower total cost of ownership, or TCO — and TCO is the number Google says to manage: maximize the business value the cloud resources provide and minimize the total cost of ownership. The framework also tells teams to adopt a holistic attitude toward cloud spending, with an emphasis on TCO and not just upfront costs — so a lower upfront bill is the start of the calculation, not the answer.

Two cost timelines, one total

Where the money goes first, and what total cost still counts

Figure: Two flows side by side. On-premises: acquire hardware and software, then depreciate over the operating life. Cloud: consume a resource, and the cost is incurred as it is consumed. Both flows end in the same box, total cost of ownership, which counts provisioning, use and managing.

Worked example (synthetic). Two proposals land on a finance director's desk: a hardware refresh and a cloud migration. The figure's point is that both must be priced to the same box — including the staff time to run them.

Drawn out, the second objective has a shape that a list hides. On the left, the on-premises timeline: assets are acquired, and the acquisition cost is depreciated over the operating life of the assets. On the right, the cloud timeline: a resource is consumed, and the cost is incurred as it is consumed — which is why Google can say enterprises only pay for the computing resources they use. The two timelines look like opposites, and the tempting conclusion is that the right-hand one is always cheaper. The figure refuses that conclusion by sending both arrows into the same box. Total cost of ownership is the thing actually being compared, and Google's framework defines what goes in it: consider not only the cost of provisioning and using the resources, but also the cost of managing them. A cloud design that trades a purchase order for months of manual maintenance has moved its cost, not removed it.

Private, hybrid or multicloud: which fits

Read the scenario for the constraint, then choose the model

• Private: one organization's data centers, for control of data
• Hybrid: regulated or resident data on-premises, public scale beside it
• Hybrid: gradual migrations, hard-to-move mainframes, low-latency edge sites
• Multicloud: best capability per vendor, and no single cloud as a failure point

Worked example (synthetic). A bank must keep customer records in-country but wants a public provider's analytics. That is the hybrid signal: data residency on one side, public scale on the other.

Topic one defined the deployment models. The third objective here asks when each one best applies, and the exam asks it as a scenario. Private cloud is chosen for control: Google says private clouds provide greater control, security and management of data while still giving internal users a shared pool of resources. Hybrid has the most signals, so learn them. It is popular with companies in highly regulated industries that have strict data privacy requirements. It suits you if you want the scale and security of a public cloud while keeping your data on-premises to comply with data residency laws, or supporting computing needs closer to your customers. Migrations lead to it naturally, because organizations often have to transition applications and data slowly and systematically. And it is the answer for industries that demand edge computing for low latency — Google's examples are kiosks in retail and networks in telecom. Multicloud has two signals of its own. One is fit: it lets you match specific features and capabilities to your workloads based on speed, performance, reliability, geographical location, and security and compliance requirements. The other is failure: an outage in one cloud will not necessarily impact services in other clouds. And underneath both sits the freedom Google names directly — a strategy that uses multiple vendors lets you pick the capabilities that best suit your needs and minimize vendor lock-in. Every choice has a price, and Google names hybrid's plainly — you still have to invest in and maintain in-house hardware.

The signal in the scenario, and the model it points to

Each model has a sentence that gives it away

Worked example (synthetic). An item says a retailer migrates one application per quarter and asks which model it runs in the meantime. The graded answer is hybrid — the gradual migration is the signal, not the retailer's destination.

Here are the five signals as the exam writes them. Strict control of data in the organization's own data centers points to private cloud. Data that must stay on-premises for data residency laws points to hybrid, because the scale of a public cloud can sit beside it. A migration that moves applications a few at a time, or a mainframe system that is difficult to move to the cloud, points to hybrid as well — Google says regulated applications that need to remain on-premises and mainframe systems are both reasons for it. Retail kiosks or telecom sites that need low latency point to hybrid at the edge. And a requirement that one provider's outage must not stop the business points to multicloud, because an outage in one cloud will not necessarily impact services in the others. Notice that three of the five rows say hybrid. That is not an accident of this table; it reflects how many constraints hybrid is Google's answer to, which is why a scenario with any on-premises constraint in it deserves a second look before you answer public cloud.

Addresses, names and providers

How a request finds the thing it is looking for

Worked example (synthetic). A customer types a shop's name into a browser. DNS turns the name into an address; the address is external, so any host on the internet can reach it; the customer's ISP carries the request to Google's network.

The fourth objective is vocabulary, and it is easiest to learn in the order a request uses it. An internet protocol address, or IP address, is what lets a resource communicate: Google says these IP addresses let Google Cloud resources communicate with other resources in Google Cloud, in on-premises networks, or on the public internet. There are two kinds that matter here. External IP addresses are publicly advertised, meaning they are reachable by any host on the internet. An internal IP address, by contrast, is not publicly routed. Nobody types an address, though, so the next term is DNS. The exam guide expands it as domain name server; Google's own documentation expands it as the domain name system, and defines it as a hierarchical distributed database that lets you store IP addresses and other data and look them up by name. Google's managed version, Cloud DNS, publishes your domain names to the global DNS. Last in this group is the internet service provider, or ISP — the user's own network. Google's region-selection guidance mentions it precisely because it is where the user's side of the latency path begins: it notes that many architects consider only the network latency, or distance, between the user's ISP and the virtual machine instance. And ISPs pass traffic along to each other: Google describes an ISP handing off traffic to a downstream ISP as quickly as it can, which is why a request can cross several providers before it reaches Google's network.

Regions, zones and the edge

Zones sit inside a region; the point of presence does not

Figure. Users reach a Google point of presence first, outside any region. Traffic is then carried to a region that contains three zones, each a single failure domain running a copy of the application. The callout notes that zones are inside the region and the point of presence is not.

Worked example (synthetic). A candidate proposes adding a zone to fix slow pages for users on another continent. The figure shows why that misses: a zone sits inside the same region, and distance to the user is an edge question.

This is the figure the vocabulary needs, because the terms are defined by what contains what. A region, in Google's words, is an independent geographic area that consists of zones, and a region consists of three or more zones housed in three or more physical data centers. A zone is a deployment area for resources within a region, and Google says zones should be considered a single failure domain. So a copy of the application in each zone survives one zone failing. Outside the region, on the left, is the edge. Google operates a global network of peering points of presence, which means customer traffic can travel within the Google network until it is close to its destination. The point of presence is where the user's traffic enters Google's network — near the user, not inside the region. Hold that containment and two common errors disappear: adding a zone does not bring an application closer to a distant user, and a point of presence is not somewhere you run a copy of the application for failover.

Latency, bandwidth, and the cables under both

Latency is how long; bandwidth is how much

Figure. Two cards and a band beneath them. Latency: round-trip time, which grows with distance at roughly one millisecond per hundred kilometres. Bandwidth: how much data a connection carries, a separate property from latency. Beneath both: fiber optics and subsea cables, the physical links, where every extra hop between internet service providers can add latency and limit bandwidth.

Worked example (synthetic). Users three thousand kilometres from the region complain pages feel slow, though the link is nowhere near full. That is latency, not bandwidth — more capacity would not shorten the trip.

The last pair of terms is the one the exam most likes to swap. Latency is about time. Google's region-selection guidance measures it as round-trip time — the time it takes to send an internet protocol packet and to receive the acknowledgment — and gives a rule of thumb: estimate one millisecond of round-trip latency for every hundred kilometres traveled. It also says why it matters: latency is often the key consideration for region selection, because high user latency can lead to an inferior user experience. Bandwidth is about quantity — how much data a connection can carry at once. Google treats the two as separate properties in a single sentence: zones have high-bandwidth, low-latency network connections to other zones in the same region. A link can have plenty of one and too little of the other, and a slow page far from its region is usually a latency problem that more bandwidth will not fix. Beneath both is the physical layer the objective names. Google describes engineering capacity into fiber optics that can be underground or laid at the bottom of the ocean, and notes that subsea cables carry ninety-nine percent of international network traffic. The same explainer ties the two properties back to the path a request takes: on the public internet, internet service providers hand traffic to one another as quickly as they can, and between the many hops you may face higher latency and limited bandwidth capacity.

Google's global network and data centers

Choose where to run; let Google's network carry the rest

• Choose locations to meet latency, availability and durability requirements
• Traffic enters at a nearby point of presence and stays on Google's network
• Every cable cross section has multiple cables and no single point of failure
• Plan for losing a whole region: that is what a second region is for

Worked example (synthetic). A game studio launches in Europe and Asia. It picks a region near each player base; players' traffic enters Google's network at a nearby point of presence instead of crossing the public internet to reach it.

The fifth objective asks how Google Cloud supports a digital transformation with global infrastructure connected by a fast, reliable network — and the answer has three layers. The first is choice of place. Google Cloud infrastructure services are available in locations across North America, South America, Europe, Asia, the Middle East and Australia, and Google says you can choose where to locate your applications to meet your latency, availability and durability requirements. The second is the path. Because Google operates peering points of presence around the world, a user's traffic enters Google's network close to the user; Google says its global backbone reduces end-user latency by having interconnects close to you, and its Premium Tier keeps traffic on that private network backbone, requiring fewer hops between internet service providers. The third is redundancy in the cables themselves: fiber optic cables are part of the network backbone of the internet that links data centers together, and Google says it designs the network with extra capacity — each cross section has multiple cables and no single point of failure. Redundancy still leaves one decision to the customer. Google's own advice is that to protect against the loss of an entire region due to natural disaster, you should have a disaster recovery plan and know how to bring up your application if your primary region is lost. The network makes a second region cheap to reach; it does not choose one for you.

Two paths from a user to a region

Where traffic enters Google's network is a choice

Figure: A flow chart with two paths from an internet user through the user's internet service provider to the region running the application. On the Premium Tier path, traffic enters Google's network at a point of presence near the user and travels on Google's private backbone. On the Standard Tier path, traffic crosses regular ISP and transit networks and enters Google's network at a point of presence near the region.

Worked example (synthetic). A media company's viewers are worldwide and its application runs in one region. The Premium Tier path is the one that keeps their traffic on Google's backbone for most of the distance.

This figure makes the fifth objective concrete, because Google sells the network as two tiers and the difference is exactly where traffic joins it. Google's summary is one sentence: Premium Tier delivers traffic on Google's premium backbone, while Standard Tier uses regular internet service provider, or ISP, networks. On the Premium path, traffic from an internet user enters Google's network through peering or transit networks at a Google point of presence that is as close as possible to the user, and from there it rides Google's backbone to the region. On the Standard path, traffic crosses ordinary networks first and enters Google's network at a point of presence as close as possible to the region instead. Google's own explainer names the two routing styles: on the public internet an ISP hands off traffic to a downstream ISP as quickly as it can, which is hot potato routing, while Premium Tier keeps traffic on its private network backbone and offloads it to ISPs at the last possible moment, when the data is closest to the end user. Both arrive. The difference is how much of the journey happens on Google's network — and that is the practical meaning of a global infrastructure connected by a fast, reliable network. It is not only that the data centers exist; it is that a user far away can be on Google's network almost from the start.

What this topic actually tests

Four discriminations, five objectives

Scalability or elasticity? only one comes back down. Cheaper up front or cheaper in total? TCO counts managing. Which constraint is in the scenario? it picks private, hybrid or multicloud. How long, or how much? latency is time, bandwidth is capacity — and zones sit inside a region while the edge does not.

Close the topic on the four discriminations the exam leans on. First, scalability against elasticity: both involve growth, and only elasticity scales back in when the load falls, which is where autoscaling reduces costs. Second, cheaper up front against cheaper in total: the move from capital to operational expenditure changes when you pay, and total cost of ownership still counts the cost of managing what you run. Third, the constraint in the scenario: control of data points to private, residency or gradual migration or edge latency points to hybrid, and surviving one provider's outage points to multicloud. Fourth, the network: latency is how long a round trip takes and grows with distance, bandwidth is how much a connection carries, and zones sit inside a region while the point of presence where users join Google's network does not. Topic three takes the next step — who manages which layer under infrastructure, platform and software as a service — and it reuses every one of these words.

Official sources for this topic

• Cloud Digital Leader exam guide — Section 1
• What is cloud computing? — Google Cloud
• What is cloud native? — Google Cloud
• Autoscaling groups of instances — Compute Engine
• Regions and zones — Compute Engine
• Well-Architected Framework — Align cloud spending with business value
• Well-Architected Framework — Cost optimization
• What is hybrid cloud? — Google Cloud
• What is multicloud? — Google Cloud
• IP addresses — Virtual Private Cloud
• Cloud DNS overview
• Best practices for Compute Engine regions selection
• Google’s subsea fiber optics, explained — Google Cloud Blog
• Geography and regions — Google Cloud
• Network Service Tiers overview