Cloud Architect

Cloud Architect

When to Use

• Define cloud strategy — single vs multi-cloud, regions, sovereignty, exit criteria
• Design landing zones — OUs, accounts, guardrails, shared services
• Map workloads to service models — serverless, containers, VMs, SaaS
• Produce reference architectures — web app, data platform, event-driven, hybrid
• Run Well-Architected reviews (security, reliability, performance, cost, ops, sustainability)
• Plan migration — assess, 7Rs, waves, dependency order, rollback
• Architect network and security — segmentation, private connectivity, zero-trust hooks
• Model cost — TCO, reservation strategy, chargeback tags at design time
• Author cloud ADRs and review decks for engineering and security sign-off

When NOT to Use

• Provision RDS, fix IAM errors, tune autoscaling → cloud-engineer
• Author Terraform modules and pipeline YAML → infrastructure-engineer, devops
• Helm releases and cluster upgrades → cluster-deployment-engineer
• Developer portal and golden-path roadmap → platform-engineer
• Cross-domain integration and strangler ADRs (not cloud-specific) → senior-system-architecture
• Data mesh, lakehouse, warehouse modeling → data-architect
• Release cutover runbooks → deployment-strategist
• Security control program and GRC evidence → cybersecurity, compliance-engineer
• Implement cloud guardrails, CSPM, IAM/network security controls → cloud-security-engineer
• LLM/RAG/agent architecture → applied-ai-architect-commercial-enterprise, ai-engineer
• Program RAID and milestones → technical-program-manager
• Physical DC design → data-center-design-execution-lead
• Multi-BU landing zones, CCoE, EA, regulated enterprise program → enterprise-cloud-architect
• Multi-year cloud strategy, migration portfolio, EA governance → vp-of-cloud
• Multi-year TCO/NPV and option economics for ADRs → cloud-economist
• Customer RFP, deal integration architecture, PoC scope → solutions-architect

Related skills

Core Workflows

1. Architecture principles and NFRs

Pillars, constraints, quality attributes.

See `references/cloud_architecture_principles.md`.

2. Landing zone and organization

Accounts, guardrails, shared services.

See `references/landing_zone_org_design.md`.

3. Workload placement and services

Compute model and vendor selection.

See `references/workload_placement_service_selection.md`.

4. Network and security architecture

Segmentation, connectivity, controls.

See `references/network_security_architecture.md`.

5. Migration and hybrid

Roadmaps, hybrid patterns, exit.

See `references/migration_and_hybrid.md`.

6. Deliverables and review

Diagrams, ADRs, review checklist.

See `references/architecture_deliverables.md`.

Outputs

• Context diagram — users, systems, external dependencies
• Target architecture — logical and physical (cloud services labeled)
• ADR set — decisions, options, consequences
• Migration wave plan — scope, risks, prerequisites
• WAF findings — prioritized remediation backlog
• Cost model — order-of-magnitude TCO drivers

Principles

• Design for operability — if it cannot be observed and owned, it is not ready
• Prefer managed until a clear constraint requires self-managed
• Explicit non-goals — scope control prevents architecture creep
• Reversibility — call out one-way doors; phase commits
• Security and compliance early — not a late gate

Architecture deliverables

Table of contents

1. Diagram types 2. ADR template 3. Review checklist 4. Stakeholder packaging

Diagram types

Use consistent legend: environments, data classification, encryption in transit.

ADR template

# ADR-NNN: Title

## Status
Proposed | Accepted | Deprecated | Superseded by ADR-XXX

## Context
Forces and constraints (NFRs, compliance, timeline).

## Decision
What we will do.

## Options considered
| Option | Pros | Cons |

## Consequences
Positive, negative, risks to monitor.

## Follow-up
Tickets, pilots, review date.

Store ADRs in repo; link from architecture wiki.

Review checklist

Before Accepted:

• [ ] NFRs traced to design elements
• [ ] Security review scheduled or complete
• [ ] Cost estimate (ROM) with assumptions
• [ ] Operational ownership named
• [ ] DR and backup approach stated
• [ ] Migration/rollback for changes to prod
• [ ] No undocumented one-way doors

Stakeholder packaging

Program tracking → technical-program-manager.

Cloud architecture principles

Table of contents

1. Well-Architected pillars 2. NFR mapping 3. Design principles 4. Anti-patterns

Well-Architected pillars

Run a review before major launch; track risks in backlog.

NFR mapping

Capture measurable targets:

Trace each NFR to concrete services and patterns in the target design.

Design principles

• Single responsibility per account or bounded context where possible
• Immutable infrastructure — no snowflake prod changes
• Defense in depth — network + identity + app layers
• Event-driven when decoupling domains; sync only when needed
• API-first integration between teams

Anti-patterns

• Lift-and-shift without refactoring dependencies
• One shared admin role for all workloads
• Public endpoints “temporarily” left open
• Multi-cloud active-active without operational maturity
• Architecture by slide deck without ADR or cost estimate

Enterprise-wide patterns spanning non-cloud systems → senior-system-architecture.

Landing zone and organization design

Table of contents

1. Organization structure 2. Guardrails 3. Shared services 4. Identity baseline

Organization structure

Typical AWS/GCP/Azure patterns:

Organization / Management group
├── Security OU (log archive, audit, tooling)
├── Infrastructure OU (network hub, DNS)
├── Workloads OU
│   ├── Prod accounts / subscriptions
│   ├── Non-prod accounts
│   └── Sandbox (SCP-limited)
└── Suspended / quarantine

Decisions to document in ADR:

• Account per env vs account per product
• Region allowlist
• Centralized vs distributed networking

Implementation detail → cloud-engineer; module libraries → infrastructure-engineer.

Guardrails

Exception process — time-bound, approved, logged.

Shared services

Centralize where economies of scale apply:

• Logging — CloudTrail, Activity Log, centralized SIEM feed
• DNS — public and private zones
• Connectivity — transit hub, VPN, Direct Connect
• Secrets — org-wide key management patterns
• CI/CD roles — OIDC federation from devops design

Identity baseline

• Human access via SSO only; no IAM users in workload accounts
• Break-glass accounts monitored
• Workload identity standard per compute type
• Cross-account roles with external ID for vendors

Security architecture sign-off → information-security-engineer.

Migration and hybrid

Table of contents

1. Assessment 2. 7Rs strategies 3. Wave planning 4. Hybrid operations 5. Exit and portability

Assessment

Inventory:

• Applications, dependencies, data stores
• RTO/RPO, compliance, peak load
• Technical debt (OS, licensing, coupling)
• Team readiness and runbook gaps

Output: migration catalog with recommended strategy per app.

7Rs strategies

Prefer refactor only when business case clears cost of delay.

Wave planning

Order waves by:

1. Low dependency, high learning value 2. Isolated domains before core systems 3. Data migration complexity and cutover window

Each wave: pilot → prod cutover → hypercare; rollback criteria documented.

Execution runbooks → deployment-strategist, cloud-engineer.

Hybrid operations

• Single pane for identity and DNS where possible
• Latency budget for cross-prem calls
• Split-brain risks on active-active databases
• Observability across cloud and on-prem — devops alignment

Exit and portability

Document:

• Data export formats and egress cost
• Vendor-specific lock-in services avoided or isolated
• Contractual termination clauses

Avoid architecture that cannot be operated without one proprietary skill set.

Network and security architecture

Table of contents

1. Segmentation 2. Connectivity 3. Edge and ingress 4. Zero trust hooks

Segmentation

Layers:

• Perimeter — WAF, DDoS, only approved ingress
• VPC/VNet tiers — public (ingress/NAT), private (apps), data (DB)
• Micro-segmentation — security groups / firewall rules least privilege
• Service mesh (optional) — mTLS east-west in Kubernetes

Document data flows — who talks to whom, ports, encryption.

Connectivity

Align with data-center-design-execution-lead for physical paths.

Edge and ingress

• TLS termination — ALB/GLB/API Gateway; cert lifecycle
• CDN — static assets, caching rules
• WAF rules — OWASP baseline; tune with devsecops
• Rate limiting — edge and app layers

Zero trust hooks

Architecture should enable (implementation with security engineering):

• Identity-aware proxy where applicable
• No flat network trust inside VPC
• Conditional access for human admin
• Centralized logging of network and identity events

Do not duplicate enterprise GRC catalog — cybersecurity.

Workload placement and service selection

Table of contents

1. Placement decision tree 2. Compute models 3. Data and integration 4. Selection matrix

Placement decision tree

1. Regulatory residency — limits regions and providers 2. Latency — user proximity, on-prem adjacency 3. Team skills — operational burden tolerance 4. Cost horizon — steady vs bursty, commitment appetite 5. Exit — contractual and technical portability

Document why not alternatives rejected.

Compute models

Data and integration

Prefer managed unless latency, cost, or compliance blocks it.

Selection matrix

Template columns:

| Option | NFR fit | Cost (3yr TCO) | Risk | Ops | Verdict |

Score 1–5 with weights agreed with stakeholders.

Include pilot scope before enterprise commit.