When you create a resource in Google Cloud, you almost always have to decide where it lives. That decision, which the console presents as a simple drop-down, shapes the latency your customers suffer, the price you pay, which services are available to you, whether you comply with data protection law and what happens when a data centre fails. It is not a configuration detail: it is an architectural decision that is very costly to reverse afterwards.

In this lesson we will learn the geography of Google Cloud and what it means for a service to be zonal, regional, multi-region or global; why Google's private backbone network and its points of presence matter for latency; what criteria to use when choosing a region, applied to AlpinaShop's real decision between europe-west1 and europe-southwest1; what deploying across several zones protects against and what multi-region demands; and how responsibility is divided between Google and you depending on the type of service, including how to read SLAs and why an SLA does not promise that nothing will ever fail.

1. The geography of Google Cloud
2. Service scope: zonal, regional, multi-region and global
3. The private backbone and the points of presence
4. How to choose a region: the five criteria
5. AlpinaShop's decision: europe-west1 versus europe-southwest1
6. Failure domains and availability
7. The shared responsibility model
8. SLAs and service credits

Google Cloud organises its physical infrastructure at three levels:

Important details:

• The zones of a region are very close to each other, with network latencies typically below a millisecond. That allows synchronous replication between zones with no perceptible penalty: it is the basis of regional high availability.
• Zone letters are not stable across projects. The europe-west1-b zone in your project and in another customer's may correspond to different physical hardware. Google makes this mapping deliberately in order to spread the load.
• Latency between regions is significant. Between europe-west1 and europe-southwest1 there are on the order of a dozen milliseconds; between Europe and the United States, around 100 ms. Any architecture that crosses regions in the critical path of a request will notice it.

The names of the European regions most relevant to a Spanish company:

Every Google Cloud service has a scope that determines where it lives and which failures it survives. Understanding it is essential for designing any architecture.

A classification of the specific services that will appear in the course:

Two cases deserve a separate comment:

• The global VPC is a real difference from AWS and Azure, where the virtual network is regional. In Google Cloud a single VPC can have subnets in Belgium, Madrid and Tokyo, and the machines in all of them communicate over private IP without configuring peering. We will study it in lesson 03-01.
• The immutability of the location in Cloud Storage and BigQuery is a detail that catches many people out: if you create the alpinashop-catalogo bucket in the wrong region, the only solution is to create another one and copy the data, paying the corresponding traffic charges.

Google operates one of the largest private networks in the world: its own fibre plus contracted capacity linking its data centres to each other and to more than a hundred points of presence (PoPs) around the planet, Madrid included.

Why this matters in practice:

• Traffic enters Google's network early. When an AlpinaShop customer in Seville requests a page, their request reaches the nearest Google PoP (Madrid) after a few hops across the internet, and from there it travels to europe-west1 over Google fibre. The "unpredictable" part of the journey is shortened.
• Less latency and, above all, less variability. The public internet has unpredictable latency spikes; a privately managed end-to-end network does not.
• It is the basis of the global load balancer. Google's external HTTP(S) load balancer uses a single anycast IP address announced from every PoP. The user connects automatically to the nearest point and from there traffic travels over Google's network to the appropriate backend. It is covered in lesson 03-02.
• It is the basis of Cloud CDN. Static content —AlpinaShop's product images, for instance— can be cached at those PoPs, served from a few milliseconds away from the customer without ever touching the bucket. Lesson 03-03.

One architectural consequence worth retaining right away: with a well-configured CDN and global load balancer, the region where your backend lives matters less than it seems for static content, but it is still decisive for anything that has to talk to the database.

There are also two network service tiers that affect cost and performance:

Let us expand on the two that are most underestimated.

A very widespread confusion: the GDPR does not, as a general rule, require the data of European citizens to remain in a specific country or even within the EU. What it requires is that the processing complies with the regulation and that international transfers have adequate safeguards.

That said, in practice there are solid reasons to keep data in the EU:

• It completely avoids the legal complexity of international transfers.
• Many corporate and public sector customers require it contractually, even where the law does not impose it.
• Certain sectors (healthcare, banking, public administration) do have stricter specific requirements.

Google also offers organization policies to restrict by policy the regions in which resources can be created (gcp.resourceLocations), which turns data residency into something verifiable rather than merely an intention. It is covered in lesson 07-07.

For AlpinaShop, which sells to consumers in Spain and Portugal and processes customers' personal data (name, address, order history), the decision is clear: everything inside the EU. The question is between Belgium and Madrid.

Not all regions are the same. The oldest and largest regions have the full catalogue; the newer ones take on services progressively, and some machine types, accelerators (GPU, TPU) or data services take a while to arrive.

The first command lists the regions with their status. The second uses --filter to keep only the two candidate regions and --format with region.basename() to show the region's short name instead of its full URL. The third combines two conditions with AND and uses ~ to express "the name matches the regular expression ^n2-", which lets you check whether a particular machine family is available before committing to a region.

Marta analyses the two candidates with the company's real data: 85 % of orders come from Spain, 10 % from Portugal and 5 % from the rest of Europe.

AlpinaShop chooses europe-west1 as its main region for this first phase of the migration, with europe-west1-b as the default zone. The reasons:

1. It is a mature region, with all the services the course and the company will need, including the data and AI ones that will come later. Starting a migration in an incomplete region forces you to discover the gaps at the worst possible moment.
2. The price is lower for several of the services it will consume most.
3. The latency penalty is acceptable and can be mitigated: the 20-25 ms difference is perceptible in a measurement, but it is largely neutralised by serving static content from Cloud CDN at the Madrid PoP and caching the dynamic parts. The bulk of a catalogue page is images.
4. Data residency is satisfied: Belgium is European Union territory, and AlpinaShop has no sector-specific requirements demanding Spanish territory.

When Marta would revisit this decision. If AlpinaShop signed a contract with a Spanish public authority requiring data on national territory, or if the conversion analysis showed that latency is costing sales, the Cloud SQL instance alpinashop-pedidos and the alpinashop-catalogo bucket would be reconsidered in favour of europe-southwest1. That is why europe-southwest1 will appear several times in the course: it is the ever-present alternative whenever we talk about latency or data residency in Spain.

This pair of commands is among the most profitable in the course: without them, many commands use default values or ask interactively, and it is very easy to end up with resources scattered across half the world.

A failure domain is the set of resources that can go down together for the same reason. Designing for availability means spreading your resources across different failure domains.

What each step up involves:

• Going from one zone to several zones is the step with the best cost/benefit ratio, and the one that covers the vast majority of real incidents. It usually requires: synchronous database replication (Cloud SQL with HA), several instances behind a load balancer, and regional rather than zonal storage. Latency between zones is sub-millisecond, so synchronous replication is viable.
• Going from several zones to several regions changes the nature of the problem. Latency between regions makes synchronous replication unviable without penalising writes, so you have to choose between asynchronous replication (with possible loss of recent data) or databases designed for it, such as Spanner. On top of that you have to solve traffic routing and failover.

A warning against over-enthusiasm: multi-region is not "more availability" for free. It multiplies cost, complexity and error surface, and there are incidents it replicates rather than contains (a faulty deployment or an accidental deletion spreads to every region). For AlpinaShop, the right answer at this stage is multi-zone production within europe-west1, with backups in an EU multi-region bucket as additional protection.

The concepts of SLO, RTO and RPO, and the detailed design of high availability and disaster recovery architectures, are studied in lesson 07-06.

Security in the cloud is always shared. Google answers for the security of the cloud; you answer for security in the cloud. Exactly where the line falls depends on the type of service.

What never stops being yours, in any service model:

1. Your data: what you collect, how long you keep it, how you classify it, whether it is encrypted with keys you manage.
2. Who accesses it: the IAM policies, identity management, credential rotation.
3. Your configuration: a public bucket, a firewall rule that opens 0.0.0.0/0 to port 22 or a database with a public IP are exclusively your responsibility, and they are the cause of the vast majority of real cloud breaches.
4. Your code: the vulnerabilities in your application and in your dependencies.

Applied to AlpinaShop:

A note that surprises many people: encryption at rest is enabled by default in every Google Cloud storage service, without you having to do anything. Google manages the keys. If you need to manage them yourself (for regulatory reasons or internal policy), there are customer-managed keys with Cloud KMS, the subject of lesson 03-06.

An SLA (Service Level Agreement) is the contractual availability commitment for a service. Reading them properly avoids both naivety and cynicism.

Typical orders of magnitude (always check the current figures in each service's official terms, because they change):

How to read an SLA properly:

• The SLA depends on your architecture, not just on the service. Look at the table: the same VM has a very different commitment depending on whether it is alone in one zone or spread across several. Google does not guarantee you 99.99 % if you deploy in a single zone.
• An SLA is not a promise that nothing will fail. It is a financial commitment: if Google falls short, you are entitled to a service credit, that is, a discount on later months' bills.
• The credits are derisory compared with the real damage. A typical breach gives rise to a credit of 10-25 % of the affected service's bill for that period. If AlpinaShop loses an afternoon of the autumn campaign, the credit will not come close to covering the lost sales. The SLA is no substitute for designing for resilience.
• Credits have to be claimed. They are not applied automatically: you have to submit a request within a deadline, providing logs that document the unavailability. Another reason to have Cloud Monitoring properly configured (lesson 06-04).
• There are exclusions. The SLA does not cover anything caused by your own configuration, by third-party software, by exceeding quotas, or by services in preview.

The practical conclusion: use the SLA as a signal of the level of reliability Google is prepared to commit to for a given architecture, and as a criterion for choosing a configuration, not as a safety net for your business.

• Leaving the default region. Many tutorials and some defaults point at us-central1. For AlpinaShop that would mean 100 ms of extra latency and data outside the EU. Set the region and zone with gcloud config set from day one.
• Confusing region with zone. Creating a VM "in europe-west1" is not possible: VMs are zonal and live in europe-west1-b, -c or -d.
• Believing that multi-zone and multi-region are the same thing. Multi-zone protects against a data centre going down and is affordable; multi-region protects against the loss of an entire region and is expensive and complex.
• Creating a bucket or a dataset in the wrong location. The location of Cloud Storage and BigQuery is immutable: the only way out is to create another one and copy the data, paying for the move.
• Assuming every region has every service. Check availability before committing, especially with GPUs, TPUs and recent services.
• Thinking that "managed" means "secure by default". The configuration is yours in every model. A public bucket is a public bucket even when the service is serverless.
• Relying on the SLA as a continuity plan. The service credit does not pay for lost sales.
• Tip: measure, do not assume. Before deciding on a region for latency reasons, measure from where your real users are.
• Tip: separate the region decision from the architecture decision. First decide where the data must live (regulation, latency) and then how the compute is deployed.
• Tip: use an organization policy to restrict regions. It is the only way to guarantee that nobody carelessly creates a resource in Iowa.

For each AlpinaShop resource, state its scope (zonal, regional, multi-region or global) and what happens if the europe-west1-b zone goes down completely:

1. A Compute Engine instance serving the legacy Nginx, created in europe-west1-b.
2. The Cloud SQL instance alpinashop-pedidos configured with high availability in europe-west1.
3. The alpinashop-catalogo bucket created as EU multi-region.
4. The IAM policy that gives Lucía read permission on BigQuery.
5. A GKE cluster alpinashop-cluster created as zonal in europe-west1-b.
6. The external HTTP(S) load balancer that publishes the shop.

AlpinaShop signs an agreement with a chain of sports shops in Germany: the new B2B platform will serve wholesale orders from Germany, will process German companies' data and the contract requires that the data remains on German territory. The expected volume is small and requires neither GPUs nor exotic services.

1. Which region would you choose and why?
2. Should the B2B data live alongside the rest in the same tienda database? Justify your answer.
3. What mechanism would you use to guarantee technically that nobody creates resources for that project outside Germany by mistake?

Analyse these five real incidents and determine, in each case, whether responsibility lies with Google or with AlpinaShop, and what specific measure would have prevented it:

1. The alpinashop-catalogo bucket was left configured with public access and a search engine indexed invoices that had been uploaded there by mistake.
2. A zone in europe-west1 suffered a 40-minute power cut and the VM serving the shop became unreachable.
3. An attacker got in over SSH to the legacy VM using a weak password belonging to a system user.
4. A critical vulnerability in the PostgreSQL version used by Cloud SQL was patched without anyone at AlpinaShop being involved.
5. The Flask application had an SQL injection vulnerability in the product search.

Solution 1

1. Zonal. The instance is lost and with it the service, until it is recreated in another zone. The associated zonal persistent disk also becomes inaccessible.
2. Regional. Cloud SQL with HA keeps a standby replica in another zone of the region and fails over automatically. There is a brief outage during the failover (on the order of tens of seconds), but the service restores itself.
3. Multi-region. It is entirely unaffected: the data is replicated across several EU regions. It is the highest level of resilience of those appearing here.
4. Global. IAM has no location; the policy remains in force and Lucía keeps her access.
5. Zonal. The cluster's control plane and all its nodes are lost. A regional cluster would have replicated the control plane across three zones and kept the nodes in the surviving zones.
6. Global. The load balancer is unaffected, but it will stop sending traffic to backends in the failed zone. If all the backends were in that zone, it has nowhere to send the traffic: the global load balancer does not create availability on its own, it distributes it.

Solution 2

1. europe-west3 (Frankfurt), being a region on German territory with a full catalogue and a mature one at that. europe-west10 (Berlin) would be another valid option on German territory; between the two, Frankfurt offers greater service availability and a better price, while Berlin might appeal on latency grounds if the customers were concentrated there. Given that the volume is small and there are no exotic requirements, maturity weighs more.
2. No. The German B2B data should live in its own instance and its own project, in europe-west3. Mixing it with the tienda database in europe-west1 would directly breach the contractual residency requirement, and separating it later would be far more costly. The natural structure is a new project, for example alpinashop-de-prod, inside the produccion folder.
3. An organization policy restricting locations (constraints/gcp.resourceLocations) applied to the project or to a folder containing it, allowing only in:eu-west3-locations. Unlike a rule written in a document, this policy technically prevents the creation of resources outside the permitted location, even for users with broad permissions. It is studied in lesson 07-07.

Solution 3

1. AlpinaShop's responsibility. A bucket's access configuration is always the customer's. Google provides the controls; using them is your job. What would have prevented it: enabling public access prevention at organization level, using uniform bucket-level access, and not uploading documents containing personal data to a bucket intended for public catalogue images.
2. Google's responsibility as far as the infrastructure is concerned: a power cut in a zone is a cloud failure. But the unavailability of the service is AlpinaShop's responsibility, because it deployed a single VM in a single zone. Google meets its zonal SLA; AlpinaShop did not design for failure. What would have prevented it: a regional managed instance group behind a load balancer, with the database in Cloud SQL with HA.
3. AlpinaShop's responsibility. The operating system and its users are theirs under IaaS. What would have prevented it: disabling password authentication for SSH, using OS Login with Google identities, not exposing port 22 to the internet and connecting through Identity-Aware Proxy.
4. Google's responsibility, and it is exactly the value you buy when you use a managed service: patching the database engine is theirs. AlpinaShop only has to make sure the maintenance window is configured at an acceptable time and to keep track of major version changes.
5. AlpinaShop's responsibility. Application code is always the customer's, in every service model, serverless included. What would have prevented it: parameterised queries, code review, static analysis in the CI/CD pipeline and, as an additional layer, Cloud Armor rules against injection patterns (lesson 03-05).

We now know where AlpinaShop's resources are going to live and who answers for what. We have gone through Google Cloud's geography —zone, region and multi-region— and classified the course's services according to whether they are zonal, regional, multi-region or global, with the peculiarity that in Google Cloud the VPC is global and the location of a bucket or a dataset is immutable. We have seen why Google's private backbone and its points of presence reduce latency and make the global load balancer with an anycast IP and Cloud CDN possible. We have applied the five region selection criteria to AlpinaShop's real case and decided on europe-west1 with zone europe-west1-b, leaving europe-southwest1 as the alternative should residency requirements on Spanish territory appear or should latency start costing sales. We have understood what deploying across several zones protects against compared with what multi-region demands, and we have divided security between Google and ourselves with the rule that never changes: the data, the access, the configuration and the code are always yours. And we have learned to read an SLA for what it is: a financial commitment that depends on your architecture, not a guarantee that nothing will fail.

One last piece of the module remains, and it is the one that turns all of the above into real work. In the next lesson, Cloud Shell and the gcloud CLI, we will leave the theory behind and start typing: we will look at what Cloud Shell is and what limits it has, how to install the CLI locally, how a gcloud command is structured and how to master --format and --filter, how authentication and named configurations work for switching between alpinashop-dev and alpinashop-prod, and we will close the module with the course's first real deployment: Dani will publish an AlpinaShop "coming soon" page on the internet, end to end, from the browser.