What a Cloud Architect Actually Does

Day to day, week to week — and why this is one of the most consequential roles in modern technology

Cloud architect is one of the most senior and highest-compensated roles in modern technology. It is also one of the most commonly misunderstood by people who have not done it. The title suggests someone who draws boxes and arrows. The reality is a professional who makes decisions that determine whether an organisation's cloud investment produces value or creates technical debt at scale. 

The cloud architect works across three domains simultaneously: design (what should be built), engineering (how it should be built), and governance (whether it is being built and operated correctly). The balance between these three domains shifts depending on the organisation's maturity, the project in flight, and the week. 

This article is a realistic account of what a cloud architect does across a working week. 

The cloud architect's decisions are expensive to reverse. A network topology chosen in week one of a migration shapes the security posture, the cost structure, and the operational complexity of the environment for years. The architect who makes those decisions well saves the organisation millions. The one who makes them poorly costs the organisation more than that. 

The Three Domains of the Cloud Architect Role 

Design 

Cloud architects design systems: they make the decisions about which cloud services to use, how they fit together, how data flows between them, and how the design satisfies the non-functional requirements of security, resilience, performance, and cost. This is not drawing boxes. It is making trade-off decisions with significant financial and operational consequences, and being able to justify those decisions to engineering teams who will build them and to executives who will fund them.

Engineering 

Most cloud architects are hands-on to a significant degree. They write Infrastructure as Code: Terraform, AWS CDK, or Bicep for Azure. They build reference architectures that engineering teams use as templates. They review pull requests where engineers have deviated from established patterns. They debug production issues where the architecture is a contributing factor. The architect who cannot read and write IaC is not effective in a modern cloud environment. 

Governance 

Cloud governance means ensuring that what is built matches what was designed, that cost optimisation is continuous rather than occasional, that security controls are enforced rather than merely specified, and that the architecture evolves in a managed way rather than drifting through uncoordinated individual decisions. In practice this means: FinOps reviews, cloud security posture management alerts, architecture review boards, and the ongoing work of aligning what engineering teams are building with the standards the architect has defined.

The cloud architect who only designs and never looks at what is actually running in production is an architect whose designs progressively diverge from reality. Production is the truth. Architecture diagrams are hypotheses about what production should look like. 

A Typical Week

MON - Architecture review and design work

Monday morning: an architecture review for a new microservices migration. Three engineers present their proposed design for breaking a legacy monolith into five services. The architect reviews for: network segmentation between services, data consistency approach at service boundaries, observability strategy (how will anyone know when these services are misbehaving?), and cost implications of the proposed service mesh. Two design decisions need revisiting before the team proceeds. Monday afternoon: design session for a new data pipeline — Kafka to S3 to Snowflake — scoping the security controls for data in transit and at rest.

TUE  - IaC development and PR review

Tuesday is engineering work. The architect is building the Terraform modules for a new AWS landing zone: VPC design, transit gateway configuration, security group baseline, IAM role structure, and the CloudTrail logging configuration that will feed the SIEM. This is hands-on code that other teams will use as templates. The work is precise. In the afternoon: reviewing four pull requests from engineers who have built on top of last week's reference architecture. Two are clean. One has hardcoded credentials in the Terraform state. That gets flagged immediately and blocked from merging. 

WED - FinOps and cost optimisation review

The monthly cloud cost review. The architect pulls the AWS Cost Explorer and Azure Cost Analysis reports and maps the significant cost items against the architecture. Three findings this month: a development environment that was left running over a three-week holiday period, a data transfer cost spike from a misconfigured S3 bucket replication, and Reserved Instance coverage that has dropped as the workload has grown. Recommendations go to the engineering lead: schedule-based dev environment shutdown, fix the bucket policy, and a Reserved Instance purchase recommendation for approval. Wednesday afternoon: an architecture decision record (ADR) written up for the database selection decision made two weeks ago.

THU - Security posture and cloud governance

The weekly cloud security posture management review. The architect reviews the AWS Security Hub and Microsoft Defender for Cloud findings from the past seven days. Seven new findings: two critical (an S3 bucket with public read access that should be private, and an EC2 instance with an overly permissive IAM role), three high, two medium. Critical findings go immediately to the relevant team with a remediation deadline. Thursday afternoon: the architecture review board meeting where three teams present their new service architectures for approval. One is approved. One needs revision. One is rejected because it would create a vendor lock-in risk that the organisation has explicitly decided to avoid.

FRI - Strategy and documentation

Friday is the day the architect writes things down. An RFC (Request for Comments) for a proposed multi-region active-active failover design that will go to the engineering leadership for review next week. An update to the cloud architecture standards document to reflect a decision made on Thursday. A draft response to a board question about the organisation's cloud resilience posture — translating the technical architecture decisions into business risk language. Friday afternoon: 90 minutes of learning. A new AWS service announcement was made this week. The architect reads the documentation and decides whether it changes any of the architectural decisions currently in flight. 

What Makes a Good Cloud Architect 

Breadth across platforms 

The cloud architect who knows only AWS is a strong AWS engineer. The one who can design across AWS, Azure, and GCP, understand the trade-offs between each platform's services, and make principled choices about which platform is right for which workload, is the architect that multi-cloud organisations need. Breadth is developed deliberately — it does not come from working exclusively on one platform. 

The ability to say no with a reason 

Engineering teams will consistently propose solutions that are technically interesting but architecturally problematic: they create vendor lock-in, they violate the security model, they are 40% more expensive than the alternative. The architect who can say no to these proposals, explain precisely why, and propose a better alternative is the one who adds value. The one who says yes to everything is not an architect. They are a rubber stamp. 

Communication across audiences 

The cloud architect writes Terraform code in the morning and presents a cloud strategy to the board in the afternoon. The communication style for each of these audiences is completely different. The architect who can translate between technical precision and business risk language is rare and correspondingly valued. 

Cloud architecture is one of the few roles where decisions made by one person shape the cost, security, and resilience of the organisation's technology for years. The architect who does this well is among the most valuable technical professionals.

The Career Trajectory 

• Cloud Engineer: hands-on implementation, building and operating cloud infrastructure. Typically 0-4 years. 

• Senior Cloud Engineer: leading engineering workstreams, mentoring, beginning to contribute to architectural decisions. Typically 3-7 years. 

• Cloud Architect: design authority, governance oversight, cross-team influence. Typically 6-12 years. 

• Principal / Distinguished Architect: organisation-wide architectural standards, executive engagement, technology strategy. Senior career path. 

The cloud architect salary in the UK sits above most other technical roles in technology. In the UAE, where cloud architects are scarcer relative to demand, the compensation premium is even more pronounced. The combination of AWS or Azure certifications plus demonstrated architectural experience plus multi-cloud exposure is among the most financially rewarding technical career tracks in 2026.