From Single-Cloud to Multi-Cloud: Migrating AWS-Only Infrastructure to AWS + Azure + GCP

White Paper

ItBytes LLC

May 2026

---

Abstract

This paper documents the real-time migration of a single-cloud AWS infrastructure to a multi-cloud architecture spanning AWS, Microsoft Azure, and Google Cloud Platform. The migration was driven by cost optimization, vendor lock-in avoidance, and compliance requirements. It was executed in a single 12-hour session using AI-assisted development — and immediately encountered the failures that make multi-cloud hard. This paper presents the architecture, the implementation, the blockers, and the lessons.

---

1. Business Rationale

1.1 Cost Optimization

AWS costs for a small organization compound quickly. By distributing workloads across providers:

• Azure's free tier covers identity management (Entra ID) and O365 integration
• GCP's always-free tier covers lightweight compute and storage
• AWS remains primary for production workloads with established infrastructure

1.2 Vendor Lock-In Avoidance

Single-cloud dependency creates risk:

• AWS service outages affect all systems simultaneously
• Pricing changes have no competitive pressure
• Skills concentrate on one platform, limiting hiring options

1.3 Compliance

Federal compliance frameworks (NIST 800-53, CIS Benchmarks) require:

• Business continuity planning across providers
• Data sovereignty options
• Independent security monitoring per environment

---

2. Starting State

2.1 AWS Infrastructure (Established)

Security posture: GuardDuty, Security Hub (CIS), AWS Config, WAF, VPC with private subnets, PrivateLink endpoints, zero-trust API authorization.

2.2 Azure (None)

No subscriptions, no identity, no resources.

2.3 GCP (Legacy)

Two abandoned projects (mediamanager, my-first-project) under a personal org (tzb164-org). No active workloads.

---

3. Target Architecture

3.1 Environment Parity

Every cloud mirrors the same 3-environment structure:

3.2 Identity Per Cloud

3.3 Security Baseline Per Cloud

---

4. Implementation

4.1 Timeline (Single Session: 2026-05-22)

4.2 Automation Created

4.3 Central Registry

All cloud accounts, identities, and connections stored in DynamoDB (itinfra-connections):

PK: PROJECT#aws-mgmt     SK: CLOUD#aws
PK: PROJECT#aws-prod     SK: CLOUD#aws
PK: PROJECT#aws-dti      SK: CLOUD#aws
PK: PROJECT#itmanageso365 SK: CLOUD#azure
PK: PROJECT#itmanagesgcp  SK: CLOUD#gcp
PK: PROJECT#it4bytes-prod-core SK: CLOUD#gcp
PK: PROJECT#it4bytes-dti-core  SK: CLOUD#gcp
PK: PROJECT#it4bytes-mgmt-core SK: CLOUD#gcp

---

5. The AWS Management Account Lockout

5.1 What Happened

During the multi-cloud expansion, the AWS management account (379047601618) SSO session expired. All attempts to re-authenticate failed:

• `aws sso login` returned ForbiddenException
• All SSO-based profiles (`it4bytes-mgmt`, `it4bytes-prod`, `it4bytes-dti`) were inaccessible
• The root account MFA phone number needed updating but couldn't be accessed

5.2 Impact

• **Route53 changes blocked** — can't issue Let's Encrypt certificates for new services
• **Identity Center changes blocked** — can't modify SSO configurations
• **Terraform state bucket inaccessible** — can't deploy infrastructure changes
• **All AWS automation halted** — scripts depending on SSO profiles fail

5.3 Workaround

Fallback IAM user credentials (dti and prod profiles) provided limited access to non-mgmt accounts. This allowed:

• DynamoDB operations in dti
• S3 deployments to dti and prod
• CloudFront invalidations

But Route53, Identity Center, and cross-account operations remained blocked.

5.4 Lesson

Single points of failure in identity systems are catastrophic. The mgmt account controls DNS, SSO, and shared state. When it's inaccessible, all three clouds are affected because:

• Azure/GCP DNS validation requires Route53 (mgmt)
• Certificate issuance requires Route53 (mgmt)
• SSO federation originates from mgmt

Mitigation: Establish independent DNS and identity in each cloud so a single account lockout doesn't cascade.

---

6. Failures and Lessons

6.1 Azure MFA — Already Enabled

Spent 45 minutes trying to enable MFA via Security Defaults, Conditional Access, and per-user MFA pages — when MFA was already active on the account via Microsoft Authenticator.

Lesson: Verify current state before trying to change it.

6.2 Duplicate Infrastructure

Ran the security baseline script against the production subscription without checking existing resources. Created duplicate VNets, resource groups, and NSGs with wrong names.

Lesson: Read before write. Check what exists before creating.

6.3 License Confusion

Directed the user to purchase Entra ID P1 when the existing Business Premium license should have covered the feature. The actual blocker was a preview approval gate, not a missing license.

Lesson: Check existing entitlements before recommending purchases.

6.4 Portal Navigation Failure

Provided 6+ incorrect portal URLs and navigation paths for enabling Security Defaults. Microsoft's portal layout varies by license tier and changes frequently.

Lesson: If you can't verify a UI path, don't guess. Use the API or admit the limitation.

---

7. Current State

7.1 What's Working

7.2 What's Blocked

• AWS mgmt account SSO access
• Let's Encrypt certificate issuance (needs Route53)
• Azure Security Defaults toggle (preview approval pending)
• GCP 2SV enforcement (needs Workspace admin)

7.3 What's Next

1. Resolve AWS mgmt account access

2. Establish independent DNS per cloud

3. Merge itGathers + itManagesO365 + itManagesGCP into itManagesClouds

4. Complete security baseline (MFA enforcement, flow logs)

5. Deploy first cross-cloud workload

---

8. Recommendations

For organizations considering multi-cloud:

1. Start with identity — establish service accounts and app registrations before deploying workloads

2. Mirror your environment structure — same prod/dev/mgmt pattern across all clouds

3. Centralize the registry — one source of truth for all accounts, identities, and connections

4. Automate the baseline — security controls applied by script, not by clicking through portals

5. Plan for lockouts — every cloud account will eventually have an access issue; ensure no single account is a dependency for all others

6. Verify before acting — check existing state, licenses, and entitlements before making changes

---

9. Conclusion

Multi-cloud is not a technology problem — it's an operations problem. The APIs work. The automation works. What fails is the human process: expired sessions, portal confusion, duplicate resources, and assumptions about what's already configured.

This migration was completed in 12 hours of active work. The infrastructure exists and is secured. But the operational maturity — independent identity, automated failover, unified management — requires continued investment. The foundation is laid; the building comes next.

---

*Published by ItBytes LLC. Part of the AI-Assisted Development series.*