Responsible engineering — the pillars.

"It works" is the lowest bar. Part 4 of Design for the Cloud is about the other four questions a responsible engineer answers: is it reliable, is it secure, is it cost-aware, and is it sustainable — plus the operational discipline to keep it that way. These are the Well-Architected pillars, told through real failures: the Capital One breach, the 99%-of-cloud-failures-are-customer-error stat, the 3,000 misconfigured assets the average enterprise is running right now. And the key idea: these pillars pull against each other, so responsible engineering is about making the trade-offs explicit.

So far this series has been about making systems that work (Part 1's shapes) and work under load (Part 2's habits, Part 3's traps). This part is about everything around "it works" — the qualities that decide whether a system is one you'd actually want to run, trust with data, and pay for. The major clouds have each codified these into a "Well-Architected Framework," and while the names differ slightly, they converge on the same handful of pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability.

Here's the framing that makes this part click and that most "best practices" lists miss: these pillars are in tension. More reliability means more components, which means more attack surface and more cost. Tighter security means more friction, which can slow operations. Aggressive cost-cutting can hurt reliability. There is no architecture that maxes out all of them. Responsible engineering isn't about scoring 100% on every pillar — it's about knowing which trade-offs you're making, on purpose, for your situation. An accidental trade-off is how you end up in a breach post-mortem.

The thing everyone gets wrong: shared responsibility

Before the pillars, the single most important concept in cloud engineering — and the one behind most breaches. The shared responsibility model divides security between you and your cloud provider:

• The provider secures the cloud — the physical data centers, the hardware, the hypervisor, the managed-service internals. AWS, Azure, and GCP are extraordinarily good at this.
• You secure what's in the cloud — your data, your access controls, your network rules, your application, your configuration. This is the part that breaks.

The numbers are stark. Gartner has projected that through 2025, 99% of cloud security failures are the customer's fault, not the provider's. Misconfigurations alone caused 23% of cloud security incidents in 2025, and the average enterprise is running over 3,000 misconfigured cloud assets at any given moment. The cloud isn't insecure — people misconfigure their half of it. Constantly.

Pillar 1 — Reliability: design for failure

The question: when something breaks — and it will — does the system keep working, and how fast does it recover?

Reliability in the cloud starts from an assumption we met in Part 2: everything fails eventually. Hardware dies, zones go dark, dependencies time out. A reliable system is one designed so that individual failures don't become user-visible outages. The core techniques:

• Eliminate single points of failure. Redundancy across instances, availability zones, sometimes regions. If one of anything can take you down, you have a reliability bug.
• Contain the blast radius. Design so a failure in one part can't cascade into the whole — the Bulkhead pattern from Part 3 (and Part 5). Partition resources so one drowning component doesn't sink the rest.
• Define and test recovery. Two numbers everyone should know for critical data: RTO (recovery time objective — how fast must you be back?) and RPO (recovery point objective — how much data can you afford to lose?). A backup you've never restored is not a backup; it's a hope.
• Test failure on purpose. Chaos engineering — deliberately killing instances, injecting latency, cutting dependencies in a controlled way — finds the reliability bugs before your users do. Netflix's Chaos Monkey made this mainstream for a reason.

Pillar 2 — Security: least privilege and blast radius

The question: if one credential, one service, or one component is compromised, how much damage can the attacker do?

The single most important security principle in the cloud is least privilege: every user, service, and component gets the minimum permissions it needs to do its job — and nothing more. It sounds obvious. It's violated almost everywhere: studies find 99% of cloud identities have far more permissions than they use. That gap is pure risk, because permissions define the blast radius — how far an attacker gets when (not if) a credential leaks.

The Capital One lesson

The 2019 Capital One breach — 106 million customer records — is the textbook case, and every element is a pillar failure you can avoid. An attacker exploited a misconfigured web application firewall to make a server-side request to the EC2 instance metadata service, which handed back credentials. The decisive detail: that firewall's role had far more permissions than it needed. With least privilege, the leaked credentials would have been nearly useless. Instead they unlocked the data. The breach wasn't one mistake; it was a misconfiguration plus an over-permissioned role — exactly the "accidental trade-off" this article warns about.

The security playbook that follows from this:

Practice	What it does
Least privilege	Minimize blast radius. A payment-webhook function does not need admin on the whole account.
Defense in depth	Multiple layers, so no single failure is fatal. Network rules and IAM and encryption and monitoring.
Encrypt everywhere	At rest and in transit, by default. So a leaked storage bucket is unreadable.
No secrets in code	Credentials in a secret manager, never in the repo. Leaked-credentials-in-Git is a top breach source.
Shift security left	Catch misconfigurations in the pipeline, before deploy — scan IaC, fail the build on a public bucket. Cheaper and safer than catching it in production.

Pillar 3 — Cost: treat money as a design metric

The question: are you delivering the value at a sensible price, or quietly bleeding money on waste?

The cloud's pay-for-what-you-use model is a double-edged sword: waste is no longer free. Every inefficiency — an oversized instance, an idle resource, a chatty cacheless service (Part 3) — shows up directly on the bill, every hour. And because spinning things up is so easy, cloud waste is enormous: industry estimates routinely put a third of cloud spend on resources that are idle or oversized.

The discipline that addresses this is FinOps — bringing finance, engineering, and the business together to treat cost as a first-class engineering concern rather than a surprise the finance team discovers at month-end. The practical moves:

• Right-size. Match instance sizes to actual usage. Most over-provisioning is "we guessed big and never revisited."
• Autoscale and scale to zero. Pay for peak only at peak (Part 2). Turn off dev/test environments overnight.
• Fix the antipatterns. As Part 3 stressed, a cacheless, chatty service autoscales to a bigger bill. Performance work is cost work.
• Make cost visible. Tag resources by team/feature, show engineers the cost of what they ship. People optimize what they can see.

Pillar 4 — Sustainability: efficiency is the green path

The question: are you minimizing the energy and resources your workload consumes?

Sustainability is the newest pillar, and the good news is it aligns almost perfectly with the others: inefficient systems waste energy, and efficient ones don't. An idle server still draws power and still has an embodied carbon cost. So most sustainability wins are the same moves as cost and performance wins:

• Maximize utilization. Idle capacity is wasted energy. Consolidate workloads, scale to zero, right-size — the same FinOps moves, now also lowering your carbon footprint.
• Prefer efficient managed services. A serverless function that runs for 200ms and stops beats a VM idling 24/7 for the same work.
• Minimize data movement and storage. Don't store what you don't need; don't move data across regions needlessly (it's also Part 3's Extraneous Fetching, now with a carbon cost).
• Pick efficient regions. Some data centers run on far cleaner energy than others.

The neat thing: you rarely have to choose between sustainability and cost. The wasteful thing is almost always both the expensive thing and the high-carbon thing. Fixing efficiency pays twice.

Pillar 5 — Operational excellence: run it like you mean it

The question: can you deploy, observe, and recover this system calmly and repeatably — or is every change an adventure?

This is the pillar that holds the others up, because reliability, security, and cost discipline all depend on operating the system well. The essentials:

• Infrastructure as Code (IaC). Define infrastructure in version-controlled code (Terraform, etc.), not by clicking in a console. Reproducible, reviewable, and — critically — scannable for misconfigurations before deploy. Click-ops is how the public S3 buckets happen.
• Automate deployments. CI/CD with automated tests and gates. Manual deploys are where human error lives.
• Observe everything. The metrics/logs/traces from Part 2. You can't operate what you can't see.
• Write runbooks and practice incidents. When something breaks at 3am, the team should follow a rehearsed playbook, not improvise. Blameless post-mortems turn each incident into a permanent fix.

The whole point: the trade-offs are the job

Now the idea that ties the pillars together. You cannot maximize all of them simultaneously — they pull against each other:

Pushing this pillar…	…tends to cost you here
More reliability (replicas, regions, buses)	More cost, more attack surface, more operational complexity
More security (patches, controls, gates)	More friction, slower delivery, possible downtime during patching
More cost-cutting (fewer resources)	Less reliability headroom, less redundancy
More performance (caching, replicas)	More cost, more complexity, more to keep consistent

A responsible engineer doesn't pretend these tensions don't exist. They make the call consciously: "this is a low-stakes internal tool, so we'll trade some reliability for lower cost," or "this handles payment data, so we accept the friction of strict least-privilege and extra audit logging." The same architecture can be right for one context and wrong for another. What's never right is making the trade by accident — which is precisely what an over-permissioned WAF role or a forgotten public bucket is: a security-for-convenience trade nobody decided to make.

A responsible-engineering scorecard

Run this on any system you own. Each "no" is a trade-off you're making — make sure it's on purpose.

Pillar	Ask yourself
Reliability	Is there a single point of failure? Do I know my RTO/RPO? Have I ever actually restored a backup?
Security	Does every role have least privilege? What's the blast radius if one key leaks? Any secrets in code? Any public storage?
Cost	Do I know what this costs to run? Anything idle or oversized? Are resources tagged and visible?
Sustainability	What's my utilization? Anything running idle 24/7 that could scale to zero?
Operations	Is the infra in code? Are deploys automated? Is there a runbook? Can I see p99 and errors?

FAQ

Isn't the cloud secure by default?

The cloud infrastructure is very secure — that's the provider's half of the shared responsibility model. But your configuration, access controls, and data are your half, and that's where ~99% of cloud security failures happen. Secure-by-default applies to the provider's job, not yours.

What's "blast radius" and why does everyone mention it?

It's how much damage results when one thing is compromised. A leaked key with admin rights = blast radius of the whole account. The same key with least privilege = blast radius of one read-only bucket. Minimizing blast radius (via least privilege and bulkheads) is the highest-leverage security move you can make.

Do I really have to think about all five pillars?

You're making decisions about all of them whether you think about it or not — the only question is whether the trade-offs are deliberate. You don't have to maximize each; you have to know which ones you're trading away and why. The scorecard above is the minimum.

Is sustainability just corporate box-ticking?

It mostly overlaps with cost and performance — the wasteful thing is usually both the expensive and the high-carbon thing. So sustainability work tends to pay for itself: higher utilization and right-sizing cut the bill and the footprint. It's rarely a separate sacrifice.

Takeaways

• "It works" is the floor. Reliable, secure, cost-aware, sustainable, operable — that's the bar for a system you'd actually want to run.
• Shared responsibility is the big one. The provider secures the cloud; you secure what's in it — and ~99% of failures are on your side, usually a misconfiguration.
• Least privilege limits blast radius. Most identities are wildly over-permissioned; that gap is what turns a leaked key into a Capital-One-scale breach.
• Cost and sustainability are efficiency. The wasteful thing is the expensive and the high-carbon thing. Fixing it pays twice.
• The trade-offs are the job. The pillars pull against each other. Responsible engineering is making those trades on purpose, not by accident.

One part left. You've got the shapes (Part 1), the habits (Part 2), the traps (Part 3), and the pillars (Part 4). Finally, the payoff: Part 5 — Cloud design patterns, the documented, reusable solutions that put all of this into practice and cure every antipattern from Part 3. The good patterns, at last.

References

• Azure Well-Architected Framework · the five pillars, in depth
• AWS Well-Architected Framework · the six-pillar version
• Security pillar · least privilege, defense in depth
• What is FinOps · cost as an engineering discipline

Extra reads

• The 2019 Capital One breach · the least-privilege case study
• The Netflix Simian Army · chaos engineering origins
• Terraform 1.15, in depth · Infrastructure as Code, the operations foundation
• Part 3 — performance antipatterns · where performance meets cost