A cloud architect exists to make the highest-leverage, hardest-to-reverse\ntechnical decisions about where and how software runs — on purpose, with the\ntradeoffs named, rather than by accident through a thousand choices. Cloud turned\n"buy a server" into "call an API," replacing old constraints with new ones: a\nbill that scales with mistakes, a blast radius that can span a continent, and a\nmenu where picking wrong and picking nothing both cost. The job is to impose\nstructure before freedom sprawls.
\n","wordCount":83},{"heading":"Core Mission","id":"core-mission","markdown":"Design systems on cloud infrastructure that meet the business's real\nrequirements for reliability, security, performance, and cost — and that the\nteams who inherit them can operate, change, and afford for years.","html":"Design systems on cloud infrastructure that meet the business's real\nrequirements for reliability, security, performance, and cost — and that the\nteams who inherit them can operate, change, and afford for years.
\n","wordCount":31},{"heading":"Primary Responsibilities","id":"primary-responsibilities","markdown":"The visible work is drawing diagrams; the actual work is making tradeoffs\nexplicit before they harden into infrastructure nobody can move. A cloud\narchitect translates business requirements into reliability, security, and cost\ntargets; chooses the topology that meets them; designs the landing zone and\nguardrails so teams build safely without a human in every loop; decides\nmanaged-versus-self-hosted per component; encodes everything as IaC; owns cost\nand security posture; and writes the ADRs that explain *why*. The recurring duty\nis saying no to complexity that doesn't earn its keep.","html":"The visible work is drawing diagrams; the actual work is making tradeoffs\nexplicit before they harden into infrastructure nobody can move. A cloud\narchitect translates business requirements into reliability, security, and cost\ntargets; chooses the topology that meets them; designs the landing zone and\nguardrails so teams build safely without a human in every loop; decides\nmanaged-versus-self-hosted per component; encodes everything as IaC; owns cost\nand security posture; and writes the ADRs that explain why. The recurring duty\nis saying no to complexity that doesn't earn its keep.
\n","wordCount":91},{"heading":"Guiding Principles","id":"guiding-principles","markdown":"- **Design for the requirement, not the brochure.** Start from the RTO/RPO and\n SLA the business will pay for; build the cheapest thing that meets it.\n- **Cost is a design parameter, not a monthly surprise.** Architecture decides the\n bill; a diagram that ignores it is wrong.\n- **Infrastructure as code or it doesn't exist.** If Terraform didn't create it,\n it's undocumented and untrustworthy.\n- **Push security left and down.** Encryption, least privilege, and network\n isolation are defaults in the landing zone, not bolted on later.\n- **Reversible by default.** Avoid one-way doors — data residency, database\n engine, account topology — unless the requirement forces them.\n- **Managed until proven otherwise.** Let the provider operate the hard parts;\n spend your operational budget on what differentiates.\n- **Loose coupling buys independent failure and change.** Components that fail and\n deploy alone are ones you can reason about.","html":"0.0.0.0/0 because it "made the demo work."A cloud architect is a force multiplier or a bottleneck depending on how they\nwork with the teams who build on their designs. With software engineers, the\narchitect provides the paved road — golden modules, reference architectures, ADRs\n— rather than approving every decision personally. With SREs and DevOps engineers\nthe architect designs the redundant substrate and the SRE keeps it alive.\nSecurity engineers co-own the threat model; finance and FinOps are genuine\nstakeholders. The failure pattern is the ivory-tower architect handing down\ndiagrams they've never operated.
\n","wordCount":87},{"heading":"Ethics","id":"ethics","markdown":"Cloud architects decide where data lives, who can reach it, and how much energy\na system burns — quiet but real power. The duties: design for the data residency\nthe law and the user require, not the cheapest region; make least privilege and\nencryption defaults so a breach is contained; be honest about cost and risk\nrather than designing to the budget and hoping; weigh the carbon cost of\nunjustified always-on redundancy; and resist lock-in that serves a sales\nrelationship over the freedom to leave. The harder gray zones —\nsurveillance-capable data lakes, jurisdictions that compel access — rarely have\nclean answers, but an architect who stays silent has chosen by default.","html":"Cloud architects decide where data lives, who can reach it, and how much energy\na system burns — quiet but real power. The duties: design for the data residency\nthe law and the user require, not the cheapest region; make least privilege and\nencryption defaults so a breach is contained; be honest about cost and risk\nrather than designing to the budget and hoping; weigh the carbon cost of\nunjustified always-on redundancy; and resist lock-in that serves a sales\nrelationship over the freedom to leave. The harder gray zones —\nsurveillance-capable data lakes, jurisdictions that compel access — rarely have\nclean answers, but an architect who stays silent has chosen by default.
\n","wordCount":112},{"heading":"Scenarios","id":"scenarios","markdown":"**\"We need multi-region active-active.\"** A VP returns from a conference\ndemanding active-active across three regions for an internal HR application. The\nexpert doesn't draw the diagram; they ask for the RTO and RPO. The honest answers\nare \"back within a few hours\" and \"we can lose a few minutes\" — for a system used\nby employees in one country during business hours. Active-active would roughly\ntriple cost and solve a region loss that has never occurred. The architect proposes\nmulti-AZ in a single region with automated cross-region backups and a tested\nrestore runbook — the real RTO/RPO at a fraction of the cost — in an ADR.\n\n**The end-of-month bill triples.** Finance escalates a bill that jumped with no\ntraffic increase. Cost-by-service shows two causes: a microservice chatty across\navailability zones (cross-AZ traffic is billed), and a pipeline reading and\nwriting across regions, racking up egress — neither visible on the diagram, which\nis the lesson. The fix: co-locate the chatty services in one AZ and move the\npipeline's compute to the data's region. The systemic fix: add Infracost to CI so\nthe next cross-region write shows its cost.\n\n**Choosing the database for a new product.** Engineering wants a trendy\ndistributed NewSQL database for a product expecting moderate, predictable load.\nThe architect runs the reversibility test: the primary datastore is a one-way\ndoor, so it earns scrutiny. The workload is read-heavy with strong-consistency\nneeds and a single-region home — managed PostgreSQL with read replicas meets\nevery requirement, while the distributed option buys write scale unneeded for\nyears. They choose Postgres and document the ceiling to revisit.","html":""We need multi-region active-active." A VP returns from a conference\ndemanding active-active across three regions for an internal HR application. The\nexpert doesn't draw the diagram; they ask for the RTO and RPO. The honest answers\nare "back within a few hours" and "we can lose a few minutes" — for a system used\nby employees in one country during business hours. Active-active would roughly\ntriple cost and solve a region loss that has never occurred. The architect proposes\nmulti-AZ in a single region with automated cross-region backups and a tested\nrestore runbook — the real RTO/RPO at a fraction of the cost — in an ADR.
\nThe end-of-month bill triples. Finance escalates a bill that jumped with no\ntraffic increase. Cost-by-service shows two causes: a microservice chatty across\navailability zones (cross-AZ traffic is billed), and a pipeline reading and\nwriting across regions, racking up egress — neither visible on the diagram, which\nis the lesson. The fix: co-locate the chatty services in one AZ and move the\npipeline's compute to the data's region. The systemic fix: add Infracost to CI so\nthe next cross-region write shows its cost.
\nChoosing the database for a new product. Engineering wants a trendy\ndistributed NewSQL database for a product expecting moderate, predictable load.\nThe architect runs the reversibility test: the primary datastore is a one-way\ndoor, so it earns scrutiny. The workload is read-heavy with strong-consistency\nneeds and a single-region home — managed PostgreSQL with read replicas meets\nevery requirement, while the distributed option buys write scale unneeded for\nyears. They choose Postgres and document the ceiling to revisit.
\n","wordCount":279},{"heading":"Related Occupations","id":"related-occupations","markdown":"A cloud architect is a software engineer zoomed out to the level of systems and\ndollars, trading day-to-day code for decisions about topology, cost, and risk.\nSite reliability engineers operate the redundant infrastructure the architect\ndesigns, and the two must agree on what \"reliable\" costs. DevOps engineers build\nthe pipelines and IaC tooling that turn the architecture into running systems.\nSecurity engineers co-own the guardrails; network engineers handle connectivity;\ndata engineers depend on the substrate provisioned.","html":"A cloud architect is a software engineer zoomed out to the level of systems and\ndollars, trading day-to-day code for decisions about topology, cost, and risk.\nSite reliability engineers operate the redundant infrastructure the architect\ndesigns, and the two must agree on what "reliable" costs. DevOps engineers build\nthe pipelines and IaC tooling that turn the architecture into running systems.\nSecurity engineers co-own the guardrails; network engineers handle connectivity;\ndata engineers depend on the substrate provisioned.
\n","wordCount":79},{"heading":"References","id":"references","markdown":"- AWS Well-Architected Framework (and Azure/Google equivalents)\n- *Designing Data-Intensive Applications* — Martin Kleppmann\n- *Cloud Native Patterns* — Cornelia Davis\n- *Fundamentals of Software Architecture* — Mark Richards & Neal Ford\n- *The Phoenix Project* — Kim, Behr & Spafford","html":"