Advanced Cloud Migration #CAF #landing-zone #guardrails #governance

Cloud Adoption Framework & Landing Zones

5 exercises — master CAF and landing zone vocabulary: Cloud Adoption Framework phases, multi-account structure, hub-and-spoke networking, preventive/detective guardrails, operating model transformation, and centralised logging.

0 / 5 completed

CAF & landing zone vocabulary quick reference

CAF — Cloud Adoption Framework: structured methodology for cloud adoption (Envision → Align → Launch → Scale)
Landing zone — pre-configured, secure, multi-account cloud environment; foundation for all migrations
Multi-account structure — separate production, non-prod, shared services, security, log archive accounts
Hub-and-spoke — centralised network topology; all traffic inspected through the hub VPC/Transit Gateway
Preventive guardrail — blocks misconfigurations before they happen (SCPs, Azure Policy)
Detective guardrail — alerts on violations after the fact (AWS Config, GuardDuty, Security Hub)
Operating model transformation — shift from hardware management to cloud service governance; new skills, processes, teams

1 / 5

A cloud architect refers to the Cloud Adoption Framework (CAF). A junior team member asks: "Is that the same as AWS Well-Architected, or something different?"

How do you explain the difference?

2 / 5

The cloud foundation team says: "We need to complete the landing zone design before wave 1 can start. The key decisions are around the account structure and network topology."

What are the key design decisions in each area?

Multi-account structure and hub-and-spoke networking are the two most consequential landing zone design decisions.

Multi-account structure — why it matters:

Account type	What lives here
Production	Live customer-facing workloads; strictest guardrails
Non-production	Dev, test, staging — less restrictive, lower cost targets
Shared services	Centralised DNS, Active Directory, Secrets Manager
Security	GuardDuty aggregation, Security Hub, SIEM integration
Log archive	Immutable, append-only log storage. No human write access.

Benefits: blast radius containment (a security incident in dev doesn't affect prod), independent cost tracking, independent compliance scope per account.

Hub-and-spoke network topology:

[On-premises] ←→ [Transit Gateway / Hub VPC]
                          ↓
              ┌──────────────────────┐
         [Prod VPC]  [Dev VPC]  [Shared Services VPC]
         (spoke)     (spoke)    (hub-resident services)

• All traffic between spokes flows through the hub (where security inspection — NGFW, IDS — runs)
• Direct spoke-to-spoke traffic is blocked by default
• Centralised egress: all internet-bound traffic exits through the hub for inspection
• AWS: implemented with Transit Gateway; Azure: with Azure Virtual WAN or Hub VNet

Key vocabulary:
• Multi-account structure — multiple AWS accounts / Azure subscriptions organised in a management hierarchy
• Blast radius — the scope of impact if a security incident or misconfiguration occurs; multi-account limits it
• Hub-and-spoke — network topology with centralised hub for shared services and security inspection
• Transit Gateway — AWS service that connects multiple VPCs and on-premises networks through a central hub

3 / 5

A security architect says: "Our landing zone needs both preventive guardrails and detective guardrails. Which is more important?"

What's the right answer?

Preventive + detective guardrails form a defence-in-depth security strategy — neither replaces the other.

Preventive guardrails — block before it happens:
• Service Control Policies (SCPs) — AWS Organizations controls that override IAM. Example: "deny all actions in regions outside eu-west-1 and us-east-1"
• Azure Policy — deny deployments that violate policy. Example: "all VMs must use approved OS images"
• Permission boundaries — IAM constructs that cap the maximum permissions a role can have
• Examples of useful preventive guardrails:
— Block creation of public S3 buckets at account level
— Require encryption at rest for all storage services
— Prevent disabling of CloudTrail/logging
— Deny MFA-free IAM user creation

Detective guardrails — alert on violations:
• AWS Config rules — continuously evaluate resource configurations. Alert when drift detected.
• AWS Security Hub / Azure Security Center — aggregated security findings across accounts
• GuardDuty / Microsoft Defender — ML-based threat detection (unusual API calls, credential misuse)
• CloudTrail / Azure Monitor Logs — API call audit trail
• Examples of useful detective guardrails:
— Alert on any root account usage
— Alert on public security group rules for SSH/RDP
— Alert on IAM key age > 90 days
— Alert on unencrypted database instances

Why both?
• Preventive guardrails can't cover every scenario and may be too restrictive for some teams
• Some historical resources predate the guardrails and need detective coverage
• Detective alerts let you understand your security posture even where you chose not to block

Key vocabulary:
• Preventive guardrail — a control that blocks non-compliant actions before they can be executed
• Detective guardrail — a control that identifies and alerts on non-compliant configurations after the fact
• SCP (Service Control Policy) — AWS mechanism for account-level permission boundaries in an organisation
• Drift — when a resource's actual configuration diverges from its desired/compliant state

4 / 5

A CTO asks: "What does operating model transformation mean in practice? We keep hearing the term in every cloud presentation."

5 / 5

A team finalising their landing zone design is debating centralised vs. distributed logging. The security team insists on centralised, immutable logs. The operations team wants logs close to each application team. How do you resolve this?

The solution is layered logging: real-time operational access in-account + centralised immutable archive for compliance and security investigation.

Landing zone logging architecture (best practice):

Application Account (prod)
  ├── CloudWatch Logs → real-time operational use
  └── CloudTrail → API audit trail
         ↓ (continuous export)
Log Archive Account (immutable)
  └── S3 with Object Lock (WORM)
        └── Retention: 7 years
        └── Write: automated export only
        └── Read: Security team (read-only)
        └── Delete: Nobody (Object Lock prevents it)

What goes into centralised logs:
• CloudTrail / Azure Activity Log — all API calls across all accounts; critical for security investigation and audit
• VPC Flow Logs / NSG Flow Logs — network traffic logs for forensics
• DNS query logs — for detecting C2 (command and control) traffic
• Config snapshots — resource configuration history for compliance demonstation

Log archive account governance:
• No human write or delete access — even the security team's accounts can only read
• Object Lock / WORM (Write Once Read Many) — prevents modification or deletion for retention period
• SCP guardrail: SCPs on the log archive account deny all DeleteBucket, PutBucketPolicy actions

Why this matters:
• Insider threat scenario: a compromised admin can delete logs in their own account — they cannot delete the centralised archive
• Compliance: PCI-DSS, SOC 2, ISO 27001 all require tamper-evident log retention
• Incident investigation: security team can investigate any account using centralised logs without needing production account access

Key vocabulary:
• Log archive account — a dedicated, locked-down account for centralised, immutable log retention
• Object Lock (WORM) — storage feature preventing object modification or deletion for a retention period
• CloudTrail — AWS API call audit logging service; must be enabled in every account and region
• Tamper-evident logging — logs stored in a way that makes unauthorised modification detectable