Migration Foundations · Security, Cost & Resilience

Security, Cost & Resilience

Moving to the cloud is not just about picking up boxes and carrying them across town. Once your stuff arrives, four questions follow it everywhere: is it safe, does it obey the law, what does it cost, and what happens if the building catches fire? These are the cross-cutting provisions — the guardrails, receipts, and safety nets that wrap around every single migration.

Security & governance: who guards what

☺ Like you're 10: The building owner locks the lobby and the elevators. You still have to lock your own apartment door. If you leave it wide open, that's on you — not the landlord.

Cloud security starts with a deceptively simple question: whose job is each lock? Answer it wrong and you'll either waste effort re-guarding things the provider already guards, or — far worse — leave your own front door swinging open. Everything below hangs off one framework and three habits: the shared responsibility model, then identity, encryption, and guardrails.

The shared responsibility model

The most important idea in cloud security is the shared responsibility model. The cloud provider secures the things underneath you — the physical data centers, the servers, the network cables, the core software. You secure the things in your account — your data, who can log in, and how you configure everything. A useful shorthand: the provider is responsible for security of the cloud; you are responsible for security in the cloud.

Where exactly the line falls depends on the service model. Rent a raw virtual machine (IaaS) and you patch the operating system yourself; use a managed database or a serverless function (PaaS) and the provider patches far more of the stack for you; buy a finished SaaS product and you mostly just manage your data and who has access. The rule of thumb: the more managed the service, the more the provider carries — but your data and your access controls never stop being yours. Most real cloud breaches are not the provider's data center failing; they're a customer leaving a door open on their own side of the line.

Identity & access management (least privilege)

☺ Like you're 10: Give everyone only the keys they actually need — and no master key just because it's easier.

Identity & access management (IAM) is the part of security that decides who can do what. The golden rule is least privilege: give every person and every program only the exact permissions they need, and nothing more. The intern who reads reports should not hold the key that deletes the database.

A few habits make least privilege real rather than a slogan:

• Prefer roles over long-lived keys. Instead of handing a server a permanent password, give it a role it assumes for short-lived, automatically-rotating credentials. Fewer standing secrets means fewer secrets to steal.
• Group permissions, don't hand-craft them per person. Attach policies to groups (e.g. "billing-readers") and add people to the group, so access is consistent and easy to audit.
• Turn on multi-factor authentication (MFA). A stolen password alone shouldn't be enough to get in — the second factor is a cheap, huge upgrade.
• Lock away the all-powerful root account. The account owner login can do anything; use it almost never, protect it with MFA, and do daily work through limited identities.
• Remember machines have identities too. Apps, functions, and pipelines all authenticate — apply least privilege to them exactly as you would to a human.

The trade-off is friction versus safety: tighter permissions occasionally mean someone has to request access they don't yet have. That small annoyance is the price of a small blast radius — see anti-patterns for what over-broad access costs when it goes wrong.

Encryption in transit & at rest

☺ Like you're 10: Scramble your secrets so that even if someone grabs them, all they get is nonsense.

Encryption scrambles data so that only someone with the key can read it. You protect data in two states:

• In transit — while it travels across the network, using TLS/HTTPS. This stops anyone tapping the wire between Fort Rusty and Cloudville from reading (or tampering with) messages in flight.
• At rest — while it sits on a disk, a backup, or in a storage bucket. If a thief steals an encrypted drive, they get gibberish.

The real work of encryption is key management — because whoever holds the key holds the data. Clouds offer a Key Management Service (KMS) that stores and rotates keys for you. You choose between provider-managed keys (easy, the default) and customer-managed keys (more control and separation of duties, at the cost of running the key lifecycle yourself). Most managed storage and databases now encrypt at rest by default, so the interesting decisions are usually about who controls the keys, not whether encryption is on.

Guardrails & landing-zone governance

☺ Like you're 10: Build fences at the top of the cliff so nobody can wander off it in the first place.

Guardrails are automatic rules baked into your landing zone — the pre-built, secure home base your first workloads move into. A guardrail might block anyone from creating a storage bucket that's open to the whole internet, or forbid launching resources in an unapproved region. It's a fence at the top of the cliff instead of an ambulance at the bottom.

Guardrails come in two flavours, and mature setups use both:

• Preventive — stop the bad thing from happening at all (a policy that refuses to create the public bucket).
• Detective — watch for a bad state and raise an alert or auto-remediate (a scan that flags a bucket that somehow went public and locks it back down).

Because these rules are written as policy-as-code and applied organization-wide, one team's hard-won lesson becomes everyone's default without anyone having to remember it. Benny the Beaver builds the landing zone; see best practices for how these habits fit together and anti-patterns for the mistakes they prevent.

Compliance & data residency: obeying the law

☺ Like you're 10: Some toys have rules about where they're allowed to live. A medical record can't just sleep anywhere — the law says which room, which country, and who's allowed to peek.

Security is about keeping data safe; compliance is about proving you keep it safe in the specific ways the law and your customers demand. Two ideas cover most of it for a beginner: the compliance frameworks that set the rules, and data residency, which says where the data may physically live.

Compliance frameworks: GDPR, HIPAA, PCI DSS, SOC 2

A compliance framework is a published set of rules for handling a particular kind of information. An audit — an outside inspection — checks that you actually do what you claim, usually by reviewing evidence (logs, configs, policies). Different rules cover different kinds of data; the common frameworks a beginner will hear:

The pattern to notice: each framework is tied to a kind of data, not a kind of company, and a single business often lives under several at once. An online health shop, for instance, may touch HIPAA (medical info), PCI DSS (card numbers), and GDPR (European buyers) all at the same time. Getting audited means gathering evidence that the right controls — encryption, least-privilege access, logging — are switched on and staying on.

Data residency & sovereignty

☺ Like you're 10: Some data isn't allowed to leave the country. You must keep it in the right room, in the right building, in the right land.

Closely related is data residency (also called data sovereignty): the idea that some data must physically stay inside a certain country or region. A German bank's records may legally be required to live in an EU data center, and never be copied to servers elsewhere. Clouds solve this with regions — geographic clusters of data centers you can pick from. Choosing the right region is often a legal decision, not just a speed one.

This has real consequences for a migration: it constrains where a workload can land, which region you replicate backups to, and even which architecture patterns are allowed (you can't fail over to a region a law forbids). Regulated workloads with a residency rule are usually planned as a group so their controls are designed once — the same reasoning that drives wave planning to keep compliance-bound apps in the same batch.

Cost & FinOps: paying the right amount

☺ Like you're 10: The cloud is like renting scooters. Grab one for an hour whenever you want (expensive), promise to rent one for a whole year (big discount), or ride whatever nobody else is using right now (super cheap, but they can take it back mid-ride).

In the old data center you bought servers once and owned them (a big up-front capital cost). In the cloud you rent, and the meter is always running (an ongoing operating cost). FinOps (financial operations) is the practice of keeping that meter honest — matching what you pay to what you actually use, and making cost a thing engineers, not just finance, can see and steer.

The three pricing models

Sol's first lesson is the three ways to buy compute — the same machine can cost wildly different amounts depending on how you commit to it:

The art is layering them: buy a reserved commitment for the always-on baseline you're certain of, cover the unpredictable peaks with on-demand, and run any throwaway, interruption-safe work (batch crunching, CI tests, rendering) on cheap spot capacity. The one rule for spot is that your workload must survive being yanked away mid-run — never put a customer's checkout on it. Note the naming differs by cloud (AWS calls the commitment plans "Reserved Instances" and "Savings Plans"; Google says "committed-use discounts"; and spare capacity is "Spot" on AWS/Azure, "preemptible/Spot VMs" on Google) — the three shapes are the same everywhere.

Everyday habits: tagging, right-sizing, budgets

☺ Like you're 10: Label your boxes, don't rent a truck to carry a backpack, and set an alarm before the piggy bank runs dry.

Beyond how you buy, three everyday habits keep the bill sane:

• Tagging — sticking labels (like team=marketing or env=prod) on every resource so you can see who spent what. Untagged spending is a mystery bill, and you can't cut a cost you can't attribute.
• Right-sizing — matching the machine to the real workload. Paying for a moving truck to carry a single backpack is pure waste; shrink it to fit. The cloud makes this easy because you can resize or switch instance types later, once real usage data shows what the app actually needs.
• Budgets & alerts — automatic warnings that ping you before spending blows past a limit, so surprises arrive by email, not by invoice. Pair them with lifecycle cleanups: delete idle test environments, unattached disks, and forgotten snapshots that quietly charge rent forever.

Sol also tracks TCO (total cost of ownership) — the true, all-in price that counts not just the monthly bill but licensing, data transfer, staff time, and the cost of not decommissioning the old kit. See how Nutty the Squirrel counts the true price in provisions, across the migration journey, and with the cost-modelling helpers in the toolbox.

Resilience & disaster recovery: what if it all falls down

☺ Like you're 10: If your treehouse collapses, how fast do you need a new one, and how many drawings can you afford to lose? Pay a little and rebuild slowly, or pay a lot and have an identical treehouse already standing next door.

Disaster recovery (DR) is your plan for when things break — a region goes dark, a database corrupts, a fire strikes. It's worth separating two ideas that often blur together: high availability keeps a system running through small, everyday failures (one server dies, traffic just shifts to another), while disaster recovery is the bigger plan for recovering from a large failure that takes out a whole zone or region. This section is about the second.

The cloud’s geography: regions & availability zones

☺ Like you're 10: A big pizza chain has kitchens in many cities. Each city has two or three separate kitchens, so if one catches fire, the city still gets pizza. If the whole city loses power, another city takes over. Cities = regions; kitchens = availability zones.

Before the DR ladder makes sense, you need the cloud’s map. A region is a geographic area (say, Frankfurt or Ohio) where a provider runs a cluster of data centers. Inside each region sit two or more availability zones (AZs) — physically separate data centers with independent power, cooling, and networking, close enough for fast connections but far enough apart that one flood or fire can’t take out two at once.

The two layers answer two different fears. Spreading a workload across AZs in one region is high availability: a zone can die and users barely notice. Spreading it across two regions is disaster recovery: even a rare region-wide outage can’t erase you. Regions are also how data residency is honored — you choose regions in the countries where your data is allowed to live. Every rung of the ladder below is really a decision about how much you invest in that second region.

RTO & RPO: the two numbers that decide everything

Every DR decision is driven by two targets you must set before you shop for a solution:

• RTO — Recovery Time Objective: how long can you be down before it hurts? (The wait to get running again.)
• RPO — Recovery Point Objective: how much data can you afford to lose? (The gap back to your last good copy.)

Picture a timeline with the disaster in the middle. RPO measures backwards from the disaster — if you back up every 6 hours, you could lose up to 6 hours of data, so your RPO is 6 hours. RTO measures forwards — how long from "everything's down" to "we're serving customers again." Tighter numbers on either axis cost more, and the two are set by the business, not the engineers: a bank's ledger and a hobby blog live at opposite ends. These are the very same RTO/RPO targets a wave plan validates at each cutover.

The four DR strategies

Here are the four classic strategies, cheapest/slowest first — each buys you a tighter RTO/RPO for more money:

You don't need the priciest option for everything. A blog can live with Backup & Restore; a payment system probably needs Warm Standby or Active/Active. Timmy always says: pick your RTO and RPO first, then buy exactly the resilience they demand — and, just as importantly, test the recovery. A backup you have never restored is a wish, not a plan; a failover you've never rehearsed is the one that fails at 2 a.m.

Storage & networking basics: boxes and roads

☺ Like you're 10: Two practical questions for every app — where do its boxes live, and how do visitors reach its front door?

Security, cost, and resilience all sit on top of two nuts-and-bolts foundations you'll meet in every migration: storage (where the data rests) and networking (how traffic reaches it). You don't need to become an expert in either, but a handful of terms show up constantly.

Three shapes of storage: object, block, file

☺ Like you're 10: A giant warehouse for files, a fast disk bolted to one machine, and a shared folder the whole office opens.

The cloud offers three shapes of storage, each good at a different job:

• Object storage — a giant, cheap bucket for files: photos, videos, backups, logs. Endlessly scalable, accessed over the web. (Think of an unlimited self-storage warehouse.)
• Block storage — fast disks attached to a single server, like the hard drive a database writes to. Speedy but tied to one machine.
• File storage — a shared folder many servers can mount at once, like the network drive a whole office reads from.

A quick way to pick: if it's an app's own live disk (a database, an operating system volume), that's block; if many machines need the same folder at once, that's file; if it's a pile of standalone files served over the web, that's object. The three matter to migration because they move differently — a database's block volume usually rides along with the machine, while terabytes of object data are often shipped separately by Ellie the Elephant in data migration.

Storage tiers: hot, cool, archive

Object storage also has tiers that trade speed for price:

• Hot — accessed often; costs more to store, cheap and instant to read.
• Cool — occasional access; cheaper to store, with small retrieval fees.
• Archive — rarely touched; dirt-cheap to store, but slow (minutes to hours) and pricey to retrieve.

Moving old data down the tiers is one of Sol's favorite savings, and clouds can do it automatically with lifecycle rules (e.g. "after 90 days, shift logs to archive"). The catch to teach a beginner: archive is cheap to keep but expensive and slow to get back, so never park data there that you might need in a hurry.

Cloud networking essentials

☺ Like you're 10: Your cloud stuff lives inside its own gated neighborhood. Some houses face the public street; others sit hidden in back alleys. A traffic cop sends visitors to whichever house is free, and a phone book turns names into addresses.

You don't need to become a network engineer, but a handful of terms show up constantly:

• VPC / VNet (Virtual Private Cloud / Virtual Network) — your own private, walled-off neighborhood inside the cloud where your resources live.
• Subnets — smaller blocks inside the VPC. A public subnet can talk to the internet (your front-facing web servers); a private subnet is hidden from the internet (your databases). Keeping databases private is a basic safety habit.
• Load balancer — a traffic cop that spreads incoming visitors across many servers so none gets overwhelmed.
• DNS — the internet's phone book, turning a friendly name like shop.example.com into a numeric address.
• CIDR — the shorthand notation (like 10.0.0.0/16) that defines a block of addresses your network owns.
• Bandwidth vs latency — bandwidth is how much data can flow per second (the width of the pipe); latency is how long one message takes to arrive (the delay). A fat pipe with high latency is like a wide highway that's very long.

Two of these tie straight back to earlier sections. Putting databases in a private subnet is the network half of least privilege — the same fence-at-the-cliff-top idea as a guardrail. And the bandwidth vs latency distinction is exactly why tightly-coupled apps are kept in one wave: a long, slow round-trip between Fort Rusty and Cloudville quietly hurts even when the pipe is wide. Pip the Hummingbird handles the bridges between the two worlds — the connectivity side lives with the architecture patterns.

The migration team: who packs the provisions

☺ Like you're 10: Instead of every family figuring out the new building alone, a small helper crew learns the rules once and teaches everyone — so no one leaves their door unlocked.

Security, compliance, cost, resilience, storage, networking — that's a lot for any one person, and far too much for every team to reinvent from scratch. The last provision is really about people: making sure someone owns each of these worries and turns the answers into shared defaults.

The Cloud Center of Excellence (CCoE)

Many organizations form a Cloud Center of Excellence (CCoE): a small, cross-functional group that sets standards, builds shared guardrails and landing zones, spreads best practices, and coaches the rest of the company. It turns hard-won lessons into defaults so every future migration starts safer and cheaper. Crucially, a good CCoE enables rather than gatekeeps — it paves a fast, safe path so teams choose the guardrailed route because it's the easiest one, not because they're forced onto it. Its output is the same body of best practices (and the anti-patterns it steers around) that this whole course keeps pointing back to.

Who owns each provision

Across this course, each provision has a familiar face — a handy way to remember who worries about what:

• 🐢 Timmy the Turtle — security and resilience: locks, least privilege, tested rollbacks, and never skipping the recovery plan.
• 🦥 Sol the Sloth — cost and FinOps: the slow, careful money math across pricing models, tagging, right-sizing, and storage tiers.
• 🦫 Benny the Beaver — the landing zone and guardrails that make the secure choice the default.
• 🐘 Ellie the Elephant — the heavy lifting of moving the data into the right storage.
• 🐦 Pip the Hummingbird — the networking and connectivity bridges between Fort Rusty and Cloudville.
• 🐿️ Nutty the Squirrel — counting the inventory and the true cost so nothing (and no bill) is a surprise.

A CCoE is simply that whole crew, sitting together, turning their specialties into rules everyone else inherits for free.

Check your answers

1. You secure your data (plus identity, config, and encryption keys) — security in the cloud; the provider secures the physical data centers, servers, and core network — security of the cloud.
2. RTO = Recovery Time Objective, how long you can be down before recovering. RPO = Recovery Point Objective, how much data you can afford to lose (the gap to your last good copy).
3. Spot / preemptible instances — cheapest (up to ~90% off) but the provider can reclaim them with little warning. Best for fault-tolerant, interruptible work like batch jobs or testing.
4. Data residency (or sovereignty) means certain data must physically stay within a specific country or region. Clouds satisfy it by letting you choose the region where your data and workloads live.