Skip to content
SkillPilotNavigate Your Career

Cloud Architect Roadmap

A path into cloud architecture as the job it actually is — trade-off analysis, migration of systems you did not write, disaster recovery you have rehearsed, decision records, and influence without formal authority.

Entry level
$159,276
Cloud Architect total pay estimate, 25th percentile (US, 1,420 salaries submitted)
Mid level
$202,355
Cloud Architect total pay estimate (US average, 1,420 salaries submitted)
Senior level
$260,623
Cloud Architect total pay estimate, 75th percentile (US, 1,420 salaries submitted)
Glassdoor

Most cloud architecture writing describes greenfield systems. Real architects spend their time on systems that already exist, that nobody fully understands, and that cannot be switched off — which is why migration, disaster recovery you have actually rehearsed, and the ability to persuade a team you do not manage get as much room here as the design patterns do.

New to Linux and the command line?

This path assumes fundamentals you may not have yet. Our Foundations Pack is out and free — Linux, the shell and Git, with exercises that mark your work and explain why you got it wrong. We're writing an agents pack next; leave your email if you want to hear when it ships.

One email when the pack launches. No spam, unsubscribe any time.

Your progress0%

The path, phase by phase

  1. Cloud Fundamentals and Service Models

    Before designing anything, learn what you are actually buying: a rented failure domain with someone else's operational assumptions baked in. IaaS, PaaS and serverless differ less in features than in which failures become your problem. Done when you can take one workload and state, for each of the three models, what you stop being responsible for and what new constraint you accept in exchange.

    3-4 weeks
    7 Skills
    Shared Responsibility Model
    IaaS, PaaS and Serverless Trade-offs
    Regions, Zones and Failure Domains
    Cloud Service Taxonomy
    Managed vs Self-hosted Analysis
    Provider Pricing Models
    Well-Architected Framework
    Show details, projects and resources

    Skills you'll master

    Shared Responsibility Modelintermediate
    IaaS, PaaS and Serverless Trade-offsintermediate
    Regions, Zones and Failure Domainsintermediate
    Cloud Service Taxonomybeginner
    Managed vs Self-hosted Analysisintermediate
    Provider Pricing Modelsintermediate
    Well-Architected Frameworkintermediate

    Hands-on projects

    1. 01Take one existing workload and write the same design three times — on VMs, on a managed platform, and serverless — with the operational burden each one removes and the constraint each one adds
    2. 02Map a provider's region and availability zone topology for the two regions you would actually use, and record which of your dependencies are zonal, regional or global
    3. 03Run a Well-Architected review against a system you did not design, and rank the findings by what would hurt first rather than by pillar
    4. 04Write the shared responsibility boundary for a specific managed database, naming three failures that remain yours after the provider takes over
    5. 05Price the same workload under on-demand, committed-use and spot pricing, and state the utilisation point where each becomes the cheapest

  2. Compute and Networking Design

    Networking is where cloud designs fail quietly and expensively. Addressing decisions made in week one constrain the architecture for years, because renumbering a live VPC is close to impossible. Done when you have designed an address plan for three environments that can absorb a corporate VPN and a second region without overlapping, and can defend every subnet boundary in it.

    4-6 weeks
    8 Skills
    VPC and Subnet Design
    IP Address Planning
    Routing and Egress Control
    Load Balancing Strategy
    Compute Sizing and Families
    Container and Serverless Placement
    Hybrid Connectivity
    DNS Architecture
    Show details, projects and resources

    Skills you'll master

    VPC and Subnet Designadvanced
    IP Address Planningadvanced
    Routing and Egress Controladvanced
    Load Balancing Strategyintermediate
    Compute Sizing and Familiesintermediate
    Container and Serverless Placementintermediate
    Hybrid Connectivityadvanced
    DNS Architectureintermediate

    Hands-on projects

    1. 01Produce an IP address plan for dev, staging and production that leaves room for a second region and a corporate VPN, and justify every CIDR boundary
    2. 02Build a three-tier network with public, private and data subnets, then prove the data tier cannot reach the internet by testing it rather than by reading the route table
    3. 03Compare a layer 7 and a layer 4 load balancer for one real workload, measuring the latency difference rather than quoting the documentation
    4. 04Design egress for a private subnet three ways — NAT gateway, VPC endpoints, proxy — and price each at your actual traffic volume
    5. 05Take a monolith and write the placement decision for each component across VMs, containers and functions, with the reason each one landed where it did
    6. 06Document a hybrid connectivity design for an office network, including what breaks during a failover and who notices first

  3. Storage and Data Architecture

    Choosing a data store is the least reversible decision an architect makes: compute can be rewritten in a sprint, but a data model that no longer fits takes a migration project. Done when you can justify a store choice for a real workload from its access pattern, consistency need and growth curve, and say what it would cost to move off it later.

    4-5 weeks
    7 Skills
    Object, Block and File Storage
    Relational vs Non-relational Selection
    Consistency and Replication Models
    Access Pattern Modelling
    Caching Strategy
    Storage Tiering and Lifecycle
    Data Migration Paths
    Show details, projects and resources

    Skills you'll master

    Object, Block and File Storageintermediate
    Relational vs Non-relational Selectionadvanced
    Consistency and Replication Modelsadvanced
    Access Pattern Modellingadvanced
    Caching Strategyintermediate
    Storage Tiering and Lifecycleintermediate
    Data Migration Pathsadvanced

    Hands-on projects

    1. 01Write the access patterns for one application first, then pick its data store from those patterns, and record which candidate you rejected and why
    2. 02Design an S3 lifecycle policy for a real retention requirement and calculate the annual saving against storing everything in the hot tier
    3. 03Add a cache to a read-heavy workload, measure the hit rate under realistic traffic, and document the staleness the design now tolerates
    4. 04Model the same dataset relationally and in a document store, and write the query that is trivial in one and painful in the other
    5. 05Estimate the cost and downtime of migrating one production dataset to a different engine, including the dual-write period

  4. Identity, Security and Compliance

    In cloud architecture identity is the perimeter, and most breaches are a permissions design failure rather than an exploit. The architect's job is the account topology and the trust boundaries, not the individual policy document. Done when you have designed a multi-account structure with guardrails that make the insecure action difficult by default rather than merely forbidden by policy.

    5-6 weeks
    8 Skills
    IAM Policy and Role Design
    Multi-account Topology
    Least Privilege in Practice
    Encryption and Key Management
    Federation and SSO
    Compliance Controls
    Guardrails and Service Control Policies
    Secrets Management
    Show details, projects and resources

    Skills you'll master

    IAM Policy and Role Designadvanced
    Multi-account Topologyadvanced
    Least Privilege in Practiceadvanced
    Encryption and Key Managementadvanced
    Federation and SSOintermediate
    Compliance Controlsintermediate
    Guardrails and Service Control Policiesadvanced
    Secrets Managementintermediate

    Hands-on projects

    1. 01Design an account structure separating production, non-production and security tooling, with the service control policies that enforce the separation
    2. 02Take an over-permissioned role, rebuild it from observed usage logs, and record what broke when you removed the extra permissions
    3. 03Implement a key management design with rotation, and document who can decrypt what and who can grant that ability
    4. 04Write the control mapping for one compliance requirement, naming the specific cloud control that satisfies each line
    5. 05Federate a directory into cloud roles and prove that removing a user upstream revokes their access within a stated time
    6. 06Audit a running account for public exposure and produce a prioritised remediation list ordered by blast radius

  5. High Availability and Disaster Recovery

    Every system has a disaster recovery plan; most have never run it, which means they have a document rather than a capability. The architect's contribution is turning vague availability ambitions into an RTO and RPO someone will fund. Done when you have executed a failover in a non-production environment and the measured recovery time is written next to the one you promised.

    4-5 weeks
    7 Skills
    RTO and RPO Definition
    Multi-AZ and Multi-region Patterns
    DR Strategy Selection
    Failover Design and Testing
    Backup and Restore Verification
    Single Point of Failure Analysis
    Graceful Degradation
    Show details, projects and resources

    Skills you'll master

    RTO and RPO Definitionadvanced
    Multi-AZ and Multi-region Patternsadvanced
    DR Strategy Selectionadvanced
    Failover Design and Testingadvanced
    Backup and Restore Verificationintermediate
    Single Point of Failure Analysisadvanced
    Graceful Degradationadvanced

    Hands-on projects

    1. 01Write RTO and RPO for three tiers of one system and get a non-engineer to agree the numbers are worth their cost
    2. 02Compare backup-and-restore, pilot light, warm standby and active-active for the same workload, pricing each and stating the recovery time each buys
    3. 03Execute a region failover in a test environment and record the real recovery time against the target you published
    4. 04Restore a production backup into a clean environment and time it — a backup that has never been restored is a hypothesis
    5. 05Map single points of failure in an existing architecture, including the ones outside the cloud account such as DNS registrar and CI system
    6. 06Design a degraded mode for one service that keeps its core function working when its main dependency is unavailable

  6. Cost and Performance Trade-offs

    An architecture nobody can afford is a failed architecture, and cost is the constraint most designs discover only after the first full month of billing. This phase turns cost from a finance report into a design input. Done when you can present two designs for the same requirement with their monthly cost, and recommend one on grounds a finance stakeholder finds legible.

    3-4 weeks
    7 Skills
    Cost Modelling Before Build
    Commitment and Spot Purchasing
    Rightsizing and Autoscaling
    Data Transfer Cost Analysis
    Performance Benchmarking
    Cost Attribution and Tagging
    Build vs Buy Analysis
    Show details, projects and resources

    Skills you'll master

    Cost Modelling Before Buildadvanced
    Commitment and Spot Purchasingintermediate
    Rightsizing and Autoscalingintermediate
    Data Transfer Cost Analysisadvanced
    Performance Benchmarkingintermediate
    Cost Attribution and Taggingintermediate
    Build vs Buy Analysisadvanced

    Hands-on projects

    1. 01Model the monthly cost of a design before building it, then compare the estimate against the first real bill and explain the gap
    2. 02Find the data transfer charges in an existing bill and trace each one to the architectural decision that created it
    3. 03Benchmark two instance families on the same workload and calculate cost per unit of work rather than cost per hour
    4. 04Design a tagging scheme that lets every line of a bill be attributed to a team, and test it against a month of real spend
    5. 05Write a build-versus-buy analysis for one managed service, costing the engineering time the self-hosted option consumes

  7. Migration and Modernisation

    Most cloud architecture work is not greenfield: it is moving something that already runs, that nobody fully understands, and that cannot stop. The seven migration strategies matter less than knowing which applies to each application and why. Done when you have produced a migration plan for a real system with its cutover sequence, its rollback point and the strategy chosen per component.

    5-6 weeks
    7 Skills
    Migration Strategy Selection
    Application Discovery and Dependency Mapping
    Strangler Fig Pattern
    Data Migration and Dual Writes
    Cutover and Rollback Planning
    Legacy Constraint Analysis
    Modernisation Sequencing
    Show details, projects and resources

    Skills you'll master

    Migration Strategy Selectionadvanced
    Application Discovery and Dependency Mappingadvanced
    Strangler Fig Patternadvanced
    Data Migration and Dual Writesadvanced
    Cutover and Rollback Planningadvanced
    Legacy Constraint Analysisintermediate
    Modernisation Sequencingadvanced

    Hands-on projects

    1. 01Take an application you did not write, map its real dependencies including the undocumented ones, and mark which block a move
    2. 02Assign a migration strategy to each component of one system and write the reason each was not simply rehosted
    3. 03Design a strangler fig migration for a monolith, naming the first slice to extract and how traffic gets routed during the transition
    4. 04Write a cutover runbook with a rollback point at each step, and identify the step after which rollback stops being possible
    5. 05Plan a data migration with a dual-write period, including how you verify both stores agree before switching reads
    6. 06Estimate a migration in engineering weeks and record which assumption would hurt most if it were wrong

  8. Multi-Cloud and Hybrid

    Multi-cloud is demanded more often than it is justified, and the architect who cannot argue against it when it is wrong will build an expensive lowest-common-denominator platform. The honest position is that it solves specific problems — regulatory, acquisition, genuine vendor risk — at a real operational cost. Done when you can write the case for and against multi-cloud for one organisation and recommend a position you would defend to its board.

    3-4 weeks
    6 Skills
    Multi-cloud Justification Analysis
    Portability vs Managed Service Trade-off
    Hybrid Architecture Patterns
    Cross-cloud Networking
    Vendor Lock-in Assessment
    Data Residency and Sovereignty
    Show details, projects and resources

    Skills you'll master

    Multi-cloud Justification Analysisadvanced
    Portability vs Managed Service Trade-offadvanced
    Hybrid Architecture Patternsadvanced
    Cross-cloud Networkingadvanced
    Vendor Lock-in Assessmentadvanced
    Data Residency and Sovereigntyintermediate

    Hands-on projects

    1. 01Write both sides of a multi-cloud proposal for one organisation, then state your recommendation and the evidence that decided it
    2. 02Cost the operational overhead of running one workload on two providers, including the training and on-call burden
    3. 03Quantify lock-in for a specific managed service as the engineering weeks needed to leave it, not as an adjective
    4. 04Design a hybrid architecture with a genuine on-premises constraint such as a device, a licence or a data residency rule
    5. 05Map data residency requirements to specific regions and record what those constraints forbid architecturally

  9. Architecture Decision Records

    An architecture is the set of decisions that were expensive to change, and most of them get made in conversations nobody wrote down. Six months later the team relitigates a choice because the constraint that forced it is forgotten. Done when a decision you recorded is read by someone who was not in the room and they can explain why the rejected option was rejected.

    2-3 weeks
    6 Skills
    Writing Decision Records
    Trade-off Articulation
    Documenting Rejected Options
    Architecture Diagramming
    Fitness Functions
    Technical Writing for Architects
    Show details, projects and resources

    Skills you'll master

    Writing Decision Recordsintermediate
    Trade-off Articulationadvanced
    Documenting Rejected Optionsadvanced
    Architecture Diagrammingintermediate
    Fitness Functionsadvanced
    Technical Writing for Architectsintermediate

    Hands-on projects

    1. 01Write three decision records for choices already made in a system you know, reconstructing the constraints that applied at the time
    2. 02Document a decision including the option you rejected, and have a colleague who disagreed review whether you represented their case fairly
    3. 03Produce a C4 diagram set for one system and test it by asking a new joiner to trace a request through it unaided
    4. 04Define one fitness function that fails a build when an architectural constraint is violated, and watch it catch a real violation
    5. 05Revisit a decision record after a change of circumstances and write the follow-up that supersedes it rather than editing the original

  10. Influence and Stakeholder Architecture

    The architect usually has no authority over the teams who must implement the design, so the work is persuasion backed by evidence. A technically correct design that no team adopts has failed as completely as a wrong one. Done when a team implements a design you proposed but could not mandate, and you can name the argument that changed their mind.

    3-4 weeks
    7 Skills
    Influence Without Authority
    Stakeholder Communication
    Presenting Trade-offs to Executives
    Architecture Review Facilitation
    Technical Debt Negotiation
    Mentoring Engineers
    Handling Disagreement
    Show details, projects and resources

    Skills you'll master

    Influence Without Authorityadvanced
    Stakeholder Communicationadvanced
    Presenting Trade-offs to Executivesadvanced
    Architecture Review Facilitationadvanced
    Technical Debt Negotiationadvanced
    Mentoring Engineersintermediate
    Handling Disagreementadvanced

    Hands-on projects

    1. 01Present one architecture two ways — to engineers and to a budget holder — and note which objections only appeared in the second version
    2. 02Facilitate a review where you are not the author, and leave with the author still committed to their design or genuinely convinced to change it
    3. 03Turn one piece of technical debt into a funded work item by expressing it as risk and cost rather than as untidiness
    4. 04Propose a design to a team you cannot direct, and record what actually persuaded them or why they declined
    5. 05Write the one-page version of a complex design for someone who will spend ninety seconds on it

What the job is actually like

Day to day
Meetings, and that is a description of the role rather than a complaint about it. A normal week is understanding a system nobody remembers designing, writing down the trade-off between two options that are both defensible, and getting a room of people with different incentives to agree on one. The writing is the deliverable: decision records that will be read by whoever inherits this in three years. Hands-on time exists but is smaller than the title suggests, usually a proof of concept built to settle an argument rather than to ship. The strain is accountability for outcomes without authority over the teams producing them.
The interview
A design round is the centre of it, and unlike systems design for an engineer, the scoring is on the trade-off rather than the diagram — call a technology the right choice without saying what it costs you and the round is going badly. Expect a migration scenario built on a legacy system with constraints you cannot remove, because that is the actual job. Many processes add a written exercise or ask you to present a past decision to a non-technical audience. Certifications get checked here more than in most engineering hiring, since they are a cheap proxy for breadth, but they will not survive the design round alone.
How people get in
This is a second career rather than a first. Senior engineers from the platform and site reliability paths arrive with operational instinct and have to learn to argue in business terms. Infrastructure and network specialists arrive with depth and have to build breadth across storage, data and identity. A third group comes from consulting, strong on stakeholders and often thin on having operated anything, which shows the first time a design meets a real failure. What transfers is having been on call for something you designed. What does not is the belief that the best technical answer wins the meeting.
After senior
Principal or distinguished architect keeps the technical fork open, moving from designing systems to setting the patterns everyone else designs within. Enterprise architecture is a genuinely different job — portfolio, cost and governance across many systems, further from technology than most engineers expect. Engineering management and CTO routes are common, since the influence skills transfer directly. The honest warning is that architecture roles are among the first cut in a downturn when they read as overhead, so keeping a hand in delivery is career insurance rather than a hobby.
Why people leave
The classic is drifting away from the systems, until the designs stop surviving contact with production and teams learn to route around you. It happens gradually, and the first symptom is being surprised by an incident. The second is producing documents nobody reads: a decision record is worth what it changes, and an architect measured on artefacts rather than outcomes is being measured on the wrong thing. The third is the organisation itself — a company that hires an architect but keeps the real decisions with whoever owns the budget has bought a title, and no amount of good design fixes that.

Frequently asked questions

Related certifications

Related roadmaps