**Cloud-Native Blueprints — architecting for high availability, resilience, and 12-factor scalability.** Cloud is no longer a deployment target; it is the architecture itself. This page describes how we approach the major hyperscalers (AWS, Azure, Google Cloud), the patterns of cloud-native architecture, and the discipline of running cloud workloads cost-effectively and securely at scale.
Cloud is three architectural commitments at once. It is a purchasing model — pay-as-you-go, elastic, no upfront capex. It is a deployment model — managed services that replace what teams used to operate themselves. It is a design model — patterns (statelessness, environment configuration, externalised state) that make applications portable, resilient, and operationally tractable at scale.
Treating cloud as just the first — moving servers from a data centre to AWS without changing the architecture — gives the worst of both worlds: cloud bills with on-prem operational profile, no elasticity, no resilience, no benefit. The patterns in this page assume the second and third are also adopted, deliberately, because that's where the actual value of the cloud lives.
AWS, Azure, and GCP each have technical strengths (AWS's breadth, Azure's enterprise integration, GCP's data and ML platforms) and organisational consequences (the talent market, the existing licensing relationship, the team's familiarity, the regulatory profile of available regions). Picking on a feature comparison alone — "GCP has BigQuery, we want BigQuery" — produces architectures that fit the chosen platform but not the team that has to operate them. The right cloud is the one where technical fit and organisational fit converge.
Gartner — Magic Quadrant for Cloud Infrastructure and Platform Services — the canonical industry comparison covering capability breadth, vision, and the operational considerations beyond feature lists.
The instinct to "go multi-cloud for resilience" sounds prudent and is usually wrong. Operating across two hyperscalers means the team has to manage two IAM systems, two networking models, two billing structures, two tooling stacks, two on-call rotations — every operational complexity is roughly doubled. The benefits are narrow: a hedge against vendor lock-in (rarely realised), genuine regulatory or data-residency requirements, and rare cases of best-of-breed service consumption. Most teams that adopt multi-cloud do so without these specific reasons and pay the operational tax forever. Multi-cloud is a strategy chosen for reasons; single-cloud-by-default is also a strategy, and a more defensible one for most teams.
Corey Quinn — The Multi-Cloud Industry's Inflated Hype — the industry's most-read sceptical voice on multi-cloud as a default, with practical analysis of when it's actually warranted.
A managed Postgres (RDS, Cloud SQL, Azure Database) costs more per CPU than self-managed Postgres on EC2. The self-managed option looks cheaper until the team computes the operational cost — patching, backups, replication, failover testing, the on-call burden when the database has an issue at 3am. For most workloads, the managed service is cheaper in total cost of operation because the operational savings dwarf the per-CPU premium. The exception is workloads at extreme scale or with specific requirements the managed service doesn't accommodate, where the per-CPU cost actually matters and the team has the depth to operate the alternative competently.
Charity Majors — Use the managed service — a working operator's case for managed services as the default, drawn from experience operating both sides.
Cloud pricing is not a flat rate. On-demand instances are the most expensive option; reserved instances or savings plans (committing 1-3 years) discount 40-70%; spot instances offer further 60-90% discounts for interruptible workloads. The architecture determines which pricing model is available — stateless workloads can run on spot; stateful workloads with predictable demand can run on reserved capacity; bursty workloads benefit from on-demand. Treating pricing as procurement's problem and the architecture as engineering's problem leaves significant cost on the table; treating them as joint decisions is what produces the bills cloud architects are proud of.
AWS Pricing Calculator and the FinOps Foundation Framework — the practical and organisational treatments of pricing as part of the architecture.
In the data-centre era, the network was the perimeter — the firewall separated trusted from untrusted, and inside the perimeter, things mostly trusted each other. In cloud, the network perimeter is dissolved by definition — services from anywhere can reach anywhere, and "inside the network" no longer means anything. The new perimeter is identity: every action is authenticated by an identity, authorised against policies, and audited by the cloud's IAM. Designing identity well — service principals with least-privilege roles, federated identity from the corporate directory, automatic credential rotation — is the architectural commitment that determines whether the cloud is secure or theatrically secure.
NIST SP 800-207 — Zero Trust Architecture — the canonical reference for identity-based perimeter architectures, articulating the principles every cloud security model now embeds.
Cloud bills surprise teams when no one is watching them. A development environment left running over the weekend, an unrotated S3 bucket accumulating logs, a queue with no consumer that bills for stored messages, an instance type that was right two years ago and is now 3x more expensive than the current generation — these are continuous leaks, individually small and collectively catastrophic. Treating cost as a daily concern with named ownership, regular reviews, and engineering action items is what keeps cloud bills predictable; treating it as procurement's job lets it grow unbounded between renewals.
FinOps Foundation Framework — the canonical industry treatment of cloud financial operations as a continuous discipline shared between engineering, finance, and operations.
The diagram below shows a canonical cloud-native architecture: a network perimeter defined by identity rather than IP; managed compute (containers, serverless) running stateless workloads; managed data services holding state; observability, security, and cost as cross-cutting concerns; multi-region deployment for high-availability workloads; spot/reserved capacity matching workload characteristics.
Moving on-premises servers to cloud VMs without changing the architecture. The team gets cloud bills with on-prem operational characteristics — no elasticity, no managed services, no resilience benefits — at higher cost.
Lift-and-shift is a starting point at most. The real work begins after: re-platforming to managed services, refactoring to stateless patterns, adopting cloud-native operational tooling. The gains accrue from these changes, not from the migration itself.
Operating across hyperscalers "for resilience" without identifying which failures multi-cloud actually mitigates. The team pays the integration cost forever; the imagined resilience benefit rarely materialises because the actual failures (regional outages, application bugs, configuration errors) are not addressed by multi-cloud.
Single-cloud by default with strong multi-region resilience. Multi-cloud only for specific reasons — regulatory data residency, genuine vendor risk that's been quantified, best-of-breed services that justify the operational tax.
Running Postgres, Kafka, Elasticsearch on EC2 because "we save on the managed service premium." The savings are typically 30-50%; the operational cost is 5-10x once on-call burden, patching, backups, and disaster recovery are honestly accounted for.
Managed services by default. Self-managed only at scale where the per-CPU premium becomes meaningful, with a team that has the depth to operate competently — not as a default driven by per-line-item pricing comparison.
Permissions added over time, never removed. Service accounts that were narrow at launch become Swiss Army knives. Roles that "needed full access for a migration" never get scoped back. The blast radius of a compromised credential grows quietly until an incident reveals it.
Least privilege as a discipline, with periodic review. Permissions are scoped at creation; expanded only with justification; reviewed quarterly; pruned when projects close or people leave.
Engineering owns architecture; procurement owns cost. The bill grows; engineering doesn't see it until renewal. The only lever procurement has is renegotiation, which doesn't address the underlying inefficiency.
Cost is an engineering concern with daily visibility. Engineers see their team's spend; anomalies trigger investigation; architectural reviews include cost projections; FinOps provides tooling, engineering applies changes.
The choice is defensible to a CTO joining in three years; the trade-offs are recorded; secondary clouds (where used) have explicit rationale tied to specific failure modes or capability gaps.
Specific workloads on each cloud; integration boundary is sharp; operational cost of multi-cloud is budgeted, not absorbed silently.
Total cost of operation includes engineering time and on-call burden; self-managed services are operated with same rigour as managed (HA, monitoring, DR), not casually.
Stateless/interruptible workloads use spot where viable; predictable baselines covered by reserved/savings plans; on-demand reserved for variable load. The mix is reviewed quarterly.
Service accounts narrowly scoped; no shared identities; no long-lived "convenience" credentials; permissions reviewed quarterly and pruned as projects close.
No long-lived IAM users for humans; cloud console access via SSO; elevated permissions granted just-in-time for the specific task; all sessions logged.
Retention period meets regulatory requirements; alerts on suspicious actions; the team has actually answered security/compliance questions from these logs, not just configured them.
Spend dashboards by service, environment, team; anomalies trigger investigation; tagging policies enforced; un-tagged resources flagged.
Cost is a design property surfaced at decision time; the choice between architectures considers spend at scale; FinOps reviews join engineering reviews for significant changes.
Multi-region or multi-zone HA matches RPO/RTO commitments; drills exercise the actual recovery, not just the runbook; the team has done it, not just configured it.
Other substantive pages in the library that link here: