Until now, every piece of Kilometre Zero has run on specific machines: the three Cassandra nodes that Ansible configured in 07-05, the Kafka brokers that are restarted one at a time while respecting the ISR, the Patroni cluster with its etcd, the MinIO with its disks, the Kubernetes cluster on which the six services are deployed. Somebody has bought those machines, installed them in a data centre, fitted them with disks and network, and replaces them when they fail. And when 07-03 settled on a pilot light disaster recovery plan with a "secondary region", it left open the question of where that region is and who operates it. This lesson answers that by changing the premise: the infrastructure becomes an API that a provider offers on demand, with regions and availability zones, virtual networks, load balancers, autoscaling and, above all, managed services that do for us what we have assembled by hand throughout the course. We will look at the service and deployment models, the concepts that change the design (regions and zones, VPCs, elasticity), the mapping between each Kilometre Zero component and its managed equivalent on AWS and GCP, the advantages and challenges (including the one that requires a legal review), infrastructure as code with Terraform, the pillars of a well-architected design, and an introduction to FinOps with the platform's approximate monthly cost. The hands-on part deploys Kilometre Zero on AWS with Terraform and the k8s/ manifests from 07-05. Serverless, edge and CDN are left for 08-04.

1. Service models: IaaS, PaaS, SaaS and shared responsibility
2. Deployment models: public, private, hybrid and multi-cloud
3. Regions, availability zones and disaster recovery
4. Cloud networking: VPCs, subnets, load balancers and autoscaling
5. Managed services: what replaces each piece of Kilometre Zero
6. Advantages and challenges: elasticity, pay-as-you-go, lock-in, egress and compliance
7. Infrastructure as code with Terraform
8. Well-architected design: the pillars
9. FinOps: tags, reservations, spot, budgets and the cost of Kilometre Zero
10. Hands-on: Kilometre Zero on AWS with Terraform and EKS
11. Common Mistakes and Tips
12. Exercises
13. Conclusion

The cloud is defined by what the provider takes on and what remains the customer's responsibility. That line moves depending on the service model, and knowing where it lies in each case is what prevents both paying for what is not used and assuming that "the cloud takes care of it" when it does not.

Two rows never change column: data and identities always belong to the customer. That is the shared responsibility model every provider publishes: the provider is accountable for the security of the cloud (nobody gets physical access to the disk, the hypervisor isolates), the customer for security in the cloud (the bucket is not public, the IAM role does not have *, personal data is encrypted and in the right region). A km0-invoices bucket reachable without authentication is the customer's responsibility under any model.

For Kilometre Zero, the natural split is: PaaS for everything that has a managed equivalent (databases, Kafka, Kubernetes, cache, objects), IaaS only where there is none or where the control pays off (the Kubernetes worker nodes are IaaS underneath, but managed as a group), and SaaS for whatever makes no difference (identity, observability if the decision is taken to outsource it).

Kilometre Zero, which today has its own hardware, will move to the public cloud with a hybrid period during the migration (the VPN link between the data centre and the VPC lets Kafka replicate with MirrorMaker and lets Patroni have a replica in the cloud before the cutover). Multi-cloud is explicitly ruled out: with four teams, operating two providers would cost more than the risk it mitigates, and portability is preserved another way, with Kubernetes as the deployment layer and containers for whatever is not managed (section 6).

A provider organises its infrastructure into regions (a geographical area: Ireland, Frankfurt, Paris...) and, within each region, into several availability zones (AZs): physically separate data centres (kilometres apart, with independent power and network) connected with 1-2 ms latency. This structure maps directly onto the failure domains of 07-03:

• An AZ is a data-centre failure domain: fire, power cut, building network failure. Spreading replicas across AZs (the three Cassandra nodes in three AZs; the Patroni primary and its synchronous replica in different AZs; the Kafka brokers with broker.rack = AZ so that each partition's replicas are spread out) means that losing an AZ is not a disaster, just a failover. It is what topologySpreadConstraints did in 07-05 with the zone label.
• A region is a geographical (and regulatory) failure domain: a natural disaster, a failure of a provider's regional service, or a legal change. The secondary region of 07-03 is another region of the same provider, hundreds or thousands of kilometres away, with 10-80 ms latency, which rules out synchronous replication between them.

With that, the three DR strategies of 07-03 take concrete form in the cloud:

Kilometre Zero keeps the 07-03 decision (pilot light) on cost grounds, with one important difference from the in-house data centre: in the cloud, the secondary region costs nothing while it is empty. Terraform can create the secondary region's infrastructure in 20 minutes from the same code; the only thing that has to exist beforehand is the replicated data. Active-active is left as a next step in 08-05, because it involves resolving write conflicts between regions (03-04) and would change the consistency model for stock.

A VPC (Virtual Private Cloud) is an isolated private network inside the region, with its own address range (10.0.0.0/16), divided into subnets, each of which belongs to one AZ. The convention Kilometre Zero adopts, and the usual one, is three tiers per AZ:

Security groups are stateful firewalls per resource, and they express the same rules as the Kubernetes network policies of 07-05 but at the VPC layer: RDS only accepts 5432 from the EKS nodes' security group; MSK only 9094 (TLS) from EKS; nothing from outside. Managed services such as S3 are reached through VPC endpoints, which keep traffic to km0-photos from going out to the internet (and avoid the NAT cost).

Managed load balancers replace the Ingress + Kong of 07-05 at its outer layer: an application load balancer (ALB on AWS, HTTP(S) Load Balancer on GCP) terminates TLS with managed, automatically renewed certificates, spreads traffic across AZs, performs health checks and exposes an IP in several AZs. Kong still exists behind it, as the gateway with its plugins (06-05); the load balancer is only the door into the region. The WebSocket of 08-02 requires the load balancer to support Upgrade and to have a long idle timeout (the ALB allows it; a layer-4 network load balancer passes it through without looking).

Autoscaling operates at two levels that must be kept apart: the HPA of 07-05 adds Pods based on CPU or Kafka lag, but Pods need nodes; the cluster autoscaler (Cluster Autoscaler or Karpenter on EKS, node pool autoscaling on GKE) adds and removes virtual machines when there are pending Pods or empty nodes. Underneath, an Auto Scaling Group of virtual machines replaces them if they fail a health check and spreads them across AZs. Grape Harvest Week with k6 (07-06) thus becomes: the HPA scales orders from 3 to 12 Pods → 6 Pods pending for lack of CPU → Karpenter starts 2 nodes in 90 s → the Pods are scheduled. Those 90 s are the reason for keeping headroom (nodes with spare capacity) ahead of an announced campaign, or for scaling on a schedule.

This table is the mapping between what was built in the course and what the provider offers as a managed service. In every row, what is gained is what the provider takes on (installation, patches, failover, backups, scaling) and what is lost is control and portability.

Three notes on this table. First: GCP Pub/Sub is not Kafka: it has no Kafka-style partitions or offsets (although it offers ordering by key and replay), and consumer code with groups and commits changes; if you want Kafka on GCP, it is Confluent Cloud. Second: Keyspaces is CQL-compatible but it is not Cassandra: consistency levels and lightweight transactions have differences that must be verified against the 04-04 repository before migrating. Third: managed does not eliminate operations, it changes them: PostgreSQL is no longer patched by us, but the instance still has to be sized, the maintenance window chosen (RDS restarts to apply major patches), restores tested and connections watched.

In 07-05 a distinction was drawn between configuration tools (Ansible: bringing an existing machine to a given state) and provisioning tools (Terraform: creating the infrastructure itself), and the latter was deferred to this lesson. When the infrastructure is an API, describing it as code is what makes it possible to review it in a pull request, reproduce it in another region and know what exists. Terraform (and its open-source fork OpenTofu) is declarative: the desired state is described in .tf files (the HCL language) and the tool works out and executes the API calls needed to get there, in the order the dependencies dictate.

Four concepts are enough to read and write the hands-on part in section 10:

1. Providers: plugins that translate resources into API calls (aws, google, kubernetes, helm, kafka...). They are declared with a pinned version.
2. Resources and data sources: resource "aws_db_instance" "inventory" { ... } creates; data "aws_availability_zones" "available" {} queries. They reference each other (aws_vpc.km0.id), and those references are the dependency graph.
3. Remote state: Terraform keeps in a state file the correspondence between what is declared and what exists (real ids). That file is critical and shared: it is stored in a remote backend (S3 with versioning, and a DynamoDB table as a lock so that two people do not apply at the same time; it is the same mutual exclusion problem as in 03-03, solved with a managed service), it is encrypted and it is never committed to Git. It contains secrets (initial RDS passwords), which reinforces the point.
4. Modules: reusable folders of .tf files with input variables and outputs (module "vpc" { source = "terraform-aws-modules/vpc/aws" ... }). Kilometre Zero uses community modules for the VPC and EKS (hundreds of resources not worth writing by hand) and its own modules for each environment.

The cycle is terraform init (downloads providers and modules, connects to the state), terraform plan (computes the diff between what is declared and the state and shows it: + create, ~ modify, - destroy, -/+ replace), and terraform apply (executes it after confirmation). The plan is the most valuable piece: it runs in the pipeline (07-05) and is pasted into the pull request; a -/+ on aws_db_instance.inventory (replacing the database) is what a review must stop. In GitOps, apply is only ever run by the pipeline after the merge, never by a person from their laptop.

Providers publish "well-architected" frameworks with pillars that serve as a checklist. The six AWS pillars (GCP has an equivalent list) match course modules almost one to one:

Their practical use is the periodic review: every six months, walk through the framework's questions against the platform and note what is missing. It is an exercise in the final project (08-05).

In the cloud, cost is one more metric of the system, and like any metric it has to be measured, attributed and alerted on. The discipline is called FinOps and, at its basic level, it boils down to five practices:

1. Tagging: every resource carries team, service, environment and cost_centre tags. Without them, the bill is a number; with them, "the delivery team spent €1,840 in September, 60% of it on MSK". Terraform applies them to everything by default (default_tags).
2. Reservations and savings plans: committing to usage for 1 or 3 years in exchange for a 30-60% discount. Applied to the baseline that is always on (the minimum EKS nodes, RDS, MSK, ElastiCache), never to the peak.
3. Spot instances: the provider's spare capacity at a 60-90% discount, which can be reclaimed with 2 minutes' notice. Ideal for whatever tolerates interruptions and restarts on its own: Spark executors (05-03 already tolerated losing executors by recomputing partitions), EKS nodes for stateless workloads with several replicas. Never for RDS, Cassandra, Kafka or the control plane.
4. Budgets and alerts: a budget per team and environment, with alerts at 80% and 100% of forecast, and anomaly detection (a NAT gateway that suddenly moves 2 TB because someone served the photos without a CDN). They are alerts like those of 07-01, sent to the same channel.
5. Switching off idle resources: staging environments switched off at night and at weekends (with Terraform or with schedules), ephemeral Spark clusters (EMR starts up for the km0_daily_sales DAG and is destroyed when it finishes), orphaned volumes and snapshots.

The prices below are fictional and indicative, of the right order of magnitude for a European region, and serve the reasoning, not as a budget. The useful exercise is to see where the cost is, not the exact figure.

What the table teaches: compute (EKS + databases + Kafka) is two thirds of the total; reservations save 25-30% on the baseline; egress is the item most sensitive to design (the CDN of 08-04 divides it by six); and two managed services (MWAA, managed Flink) cost more than their self-managed equivalents on the cluster, which illustrates that "managed" does not always win: the decision depends on how much the time of the team that would operate it is worth.

The structure of the infrastructure code, added to the km0/ project:

What follows is main.tf explained block by block. It is simplified (some security and networking parameters that a real module includes are missing), but every block is real and corresponds to a decision from the previous sections.

The orders and catalog Pods carry in k8s/orders-deployment.yaml a toleration for km0/spot and an affinity that prefers base, so that during a campaign they overflow onto spot; Cassandra, Kafka (if it were self-managed) and the databases do not tolerate the taint and never land on spot. The cluster autoscaler (Karpenter, installed with the helm provider) is what takes the campaign group from 0 to 12 according to the pending Pods.

What replaces the hand-built pieces here: multi_az = true is Patroni + etcd + synchronous replica + automatic failover (RDS switches the endpoint's DNS to the standby in ~60 s; the application only needs to reconnect, which is what the pool with retries from 07-04 already does); backup_retention_period is the pgBackRest and WAL archiving of 07-03. What it does not replace: the weekly restore test, which remains an Airflow job that restores the latest snapshot onto a temporary instance and runs checks.

The catalog Pods need to write to km0-photos; the orders Pods need to read their secrets. Instead of long-lived credentials in a Kubernetes Secret (which 06-04 avoided with Vault), EKS allows an IAM role to be bound to a Kubernetes service account: the Pod obtains temporary credentials automatically, with least privilege, and CloudTrail records who did what. It is the workload identity of 06-04 (SPIFFE) with the provider's IAM.

In the k8s/catalog-deployment.yaml manifest all that is needed is serviceAccountName: catalog and the eks.amazonaws.com/role-arn: <role arn> annotation on the ServiceAccount; the AWS SDK in the Pod (boto3, the same photos.py from 04-03 pointed at S3 instead of MinIO) finds the credentials on its own.

The manifests do not change in shape: what changes are the configuration values pointing at the dependencies. In 07-05, orders-config had KAFKA_BOOTSTRAP=kafka-0.kafka:9092; now the pipeline generates it from the Terraform outputs:

What disappears from k8s/ when moving to managed services: the StatefulSets for PostgreSQL with Patroni, for Kafka and for Redis, and their operators. What stays: the six services, Kong, the mesh, Cassandra (if Keyspaces is not adopted), Prometheus/Loki/Tempo (if CloudWatch is not adopted) and Mosquitto. The HPA of 07-05 works the same; what is new is Karpenter underneath. And the tests of 07-06 are repeated against the staging environment deployed with staging.tfvars (small instances, no Multi-AZ, no DR), which is switched off at night.

• Assuming that "managed" means "no operations". RDS still restarts in the maintenance window, MSK still needs partitions sized, and nobody tests the restores for us. The work changes; it does not disappear.
• A single AZ "to save money". One NAT, one subnet, RDS without Multi-AZ: the provider's first AZ incident is a total outage. Multi-AZ for everything on the path of an order.
• Forgetting egress and inter-AZ traffic in the budget. They are the two items that surprise on the first bill. A CDN for public content, VPC endpoints for S3, client.rack on Kafka consumers.
• IAM roles with *. A service role with s3:* over every bucket turns a compromised Pod into a total leak. One policy per service account, with specific actions and resources (block 6).
• Terraform state in Git or on a laptop. It contains secrets and is the only map of what exists. An encrypted remote backend with versioning and a lock, always.
• Applying without reading the plan. A -/+ on a database is a destroy-and-recreate. The plan goes in the pull request and deletion_protection on production.
• Choosing the region only on price or latency. Personal data has residency restrictions; the region is a decision with a legal review, and a documented one.
• Buying reservations for the peak. Reservations cover the baseline that is always on; the peak goes to spot or on-demand. Over-buying is paying for capacity that is not used.
• Tip: deploy staging first with the same Terraform configuration and small sizes; 90% of the networking, IAM and security group mistakes show up there at minimal cost.
• Tip: put cost in Grafana next to the other metrics (providers export daily spend per tag). A chart of euros per order is the business metric that generates the most useful conversations.

Review the main.tf from section 10 and answer: (a) if AZ b disappears entirely, which Kilometre Zero components are affected, which mechanism recovers each one and in roughly how long; (b) what would have happened with one_nat_gateway_per_az = false; (c) which component of main.tf would not survive the loss of the region, and what would have to be run to recover it.

Using the cost table from section 9 (fictional prices), calculate the approximate monthly saving or extra cost of these three decisions and reason about whether they are worth it: (a) replacing MWAA with Airflow on EKS (estimate: €40 in nodes); (b) moving km0_analytics on RDS to Multi-AZ; (c) moving the permanent EKS nodes from on-demand to a 3-year reservation (estimated discount 55% instead of 40%), knowing that the team plans to reduce to 4 permanent nodes within a year.

For each of these components, decide whether Kilometre Zero should use the provider's managed service or deploy it on EKS, applying the "selective lock-in" criterion from section 6 (benefit of the managed service versus cost of the dependency): PostgreSQL, Kafka, Cassandra, Keycloak, Vault, Prometheus/Grafana. Justify each one in two sentences.

Exercise 1.

(a) With AZ b down: RDS km0_inventory: the standby was in b (or the primary; RDS decides); if it was the standby, nothing visible happens and RDS creates a new one in another AZ; if it was the primary, automatic failover to the standby in ~60 s, during which stock reservations fail and the saga retries (07-04). MSK: broker 2 goes down; the partitions whose leader was there elect a new leader from among the ISR (03-03) within seconds; with min.insync.replicas=2 and RF=3, writes continue. Cassandra: one node out of three; with QUORUM (2 of 3), reads and writes continue. ElastiCache: if the primary was in b, automatic failover to the replica (~30 s) and the cache refills; if it was the replica, nothing. EKS: the nodes in b disappear; Kubernetes reschedules their Pods onto a and c (07-05: topologySpreadConstraints guaranteed that no service had all its replicas in b) in 1-3 minutes, and Karpenter adds nodes if capacity is short. ALB: it stops sending to b once the health checks fail (seconds). NAT: the one in b goes down, but so do the nodes in b, so nobody needs it.

(b) A single NAT in, say, AZ a: if a goes down, the nodes in b and c stay alive but lose their outbound internet access: payments cannot reach the gateway, the pipeline cannot pull images. A healthy component is rendered useless by someone else's failure domain: exactly what 07-03 called non-independent redundancy.

(c) Everything in the primary region. What exists in the secondary: the RDS replica (inventory_dr), the replicated bucket and the minimal MSK with MirrorMaker. To recover: terraform apply of the same code with region = "eu-central-1" (some 20-30 min for VPC + EKS + ElastiCache), promote the RDS replica (aws rds promote-read-replica, ~5 min), deploy the manifests pointing at the new endpoints, restore Cassandra from the snapshots replicated to S3 (the longest step and the one that sets the RPO for orders), and switch the Route 53 record. It is the pilot light runbook from 07-03, and the real RTO is whatever comes out of the game day, not the one in the table.

Exercise 2.

(a) MWAA €320 → Airflow on EKS €40: saving ≈ €280/month (€3,360/year). It is worth it if the platform team takes on operating Airflow (upgrades, metadata database, on-call); with the Kubernetes operator and a small RDS instance for the metadata (~€30 more), it is still worth it, and it also avoids a provider-specific dependency. It is the example of managed not always winning.

(b) €210 → roughly double, ≈ €420: extra cost ≈ €210/month. For km0_analytics, whose temporary loss does not prevent selling (an RTO of hours in 07-03; it is rebuilt from the lake), it is not worth it; the 07-03 decision still stands.

(c) Node baseline: €900 on-demand; with a 1-year reservation at 40%: €540; with a 3-year reservation at 55%: €405. Difference in favour of 3 years: €135/month. But the 3-year reservation covers 6 nodes and within a year only 4 will be used: 2 reserved nodes would be paid for unused for 2 years (≈ 2 × €67 × 24 months ≈ €3,200), against a saving of 135 × 12 = €1,620 in the first year. Not worth it: a 1-year reservation, renegotiable when the sizing changes. Reservations are bought for the stable baseline, and "stable" includes the foreseeable future.

Exercise 3.

• PostgreSQL → RDS (managed). High benefit (Multi-AZ, PITR and patches replace the entire Patroni cluster) and low lock-in: it is standard PostgreSQL, a pg_dump moves it anywhere.
• Kafka → MSK (managed). High benefit (the broker rolling restarts of 07-05 and disk management disappear) and low lock-in: standard Kafka protocol, MirrorMaker replicates it to any Kafka. On GCP, Confluent rather than Pub/Sub for the same reason.
• Cassandra → on EKS (or EC2), not Keyspaces. Keyspaces changes the semantics (lightweight transactions, some types, a per-request cost model) and the 04-04 repository would need review: high lock-in for a medium benefit. It stays self-managed with the operator from 07-05, and is reconsidered if the platform team cannot keep up.
• Keycloak → on EKS, not Cognito. Cognito is more limited in flows and customisation, and migrating users and clients away from an identity provider is painful: high lock-in. Keycloak with two replicas and RDS behind it is easy to operate.
• Vault → Secrets Manager (managed), with a caveat. For static secrets and their rotation, Secrets Manager with IRSA is simpler and integrates with IAM. The dynamic database credentials and the PKI for mTLS that Vault provided in 06-04 have no direct equivalent: if the mesh takes over mTLS (08-01), Vault can be retired; if not, Vault stays on EKS for that alone.
• Prometheus/Grafana → on EKS. The services/common/ instrumentation is standard (OpenTelemetry, Prometheus exposition) and the 07-01 dashboards and alerts already exist; CloudWatch would cost more and would change the query language (PromQL). Avoidable lock-in at low cost. The provider's managed Prometheus/Grafana services are an acceptable middle ground if metrics storage grows.

The cloud turns infrastructure into an API, and with that it changes three things in the design of Kilometre Zero. The first is responsibility: IaaS, PaaS, SaaS and FaaS move the line between what the provider does and what the customer does, but data and identities always stay on this side of it. The second is geography: regions and availability zones are failure domains with names, AZs absorb everyday failures with Multi-AZ on everything an order touches, and the secondary region of the 07-03 pilot light becomes Terraform code that costs nothing while it is not run. The third is substitution: RDS for Patroni, MSK for the Ansible-managed brokers, S3 for MinIO, EKS for the in-house cluster, with a table that says what is gained and what is lost in every row, and a selective lock-in criterion (managed where the benefit is high and the API standard, self-hosted where the dependency would cost more than the operation). Terraform describes the VPC with three tiers per AZ, EKS with base and spot nodes, Multi-AZ RDS with its replica in another region, MSK, ElastiCache, S3 with versioning and replication, and IRSA so that every Pod has only the permissions it needs; the 07-05 manifests are deployed almost unchanged, and the Terraform plan is reviewed in the pull request like any other code. The well-architected pillars summarise the course as a checklist, and FinOps adds cost as a metric: tags, reservations for the baseline, spot for Spark and the peaks, budgets with alerts, and a table showing that compute is two thirds of the bill, that two managed services cost more than their equivalents on the cluster, and that egress is the item design can reduce the most.

Precisely that item, and two more questions, open the next lesson. Does it take a service on Kubernetes, with its replicas, its probes and its on-call rota, to generate a thumbnail every time Montblanc Dairy uploads a photo, or to produce a PDF when a payment.confirmed arrives? And why do the aged-cheese photos have to travel from Ireland to Anna's phone in Valencia on every visit, when they could be twenty kilometres away from her? Functions that exist only while there is an event to process, and compute and cache at the edge of the network: Serverless and Edge Computing Architectures.