Multi-account architecture
Organizations, OU design, account-vending, guardrails — with a clear separation between shared services, workloads and dev/test.
AWS OrganizationsControl TowerSCPs
Landing Zone Setup & Deployment
The
foundation everything else runs on.
Foundations that hold — production-ready from day one.
What we do
A landing zone is the account structure, network topology, identity, security baseline and governance that every workload will inherit. Done properly at the start, it saves years of retrofitting later.
Phoenix delivers landing zones on AWS (Control Tower + Organizations) and equivalent constructs on Azure and Huawei Cloud — mapped to the customer's operating model, not a generic template.
Inside the practice
What's in scope.
Network topology
Transit Gateway or hub-and-spoke VPC design, hybrid connectivity, DNS strategy — routing that scales with the estate.
Transit GatewayVPC designDirect Connect
Identity & access
IAM Identity Center (SSO), federation to existing IdPs, least-privilege role design, break-glass procedures.
IAM Identity CenterSSOMFA
Security baseline
GuardDuty, Security Hub, Config, encryption defaults, KMS strategy, secrets management. Compliance mapped to the customer's regime.
Security HubGuardDutyKMSSecrets Manager
Governance & guardrails
Preventive and detective controls, tagging strategy, budgets and alerts wired in from day one — not bolted on later.
Tag policiesBudgetsConfig Rules
Logging & observability
Centralized CloudTrail, VPC flow logs, application logging, dashboards and the alerting spine every downstream workload will use.
CloudTrailCloudWatchOpenSearch
How Phoenix delivers
The approach.
01
Discovery
Current-state assessment — existing accounts, networks, security posture, compliance obligations, operating model.
02
Design
Target landing-zone architecture, decision log, migration path from current state (if any). Signed off before code runs.
03
Deploy
Infrastructure-as-code build (Terraform / CDK), pipeline setup, guardrails and security services enabled, first pilot workload lands.
04
Handover
Runbooks, IaC repositories, admin training, and a clear operating model for the customer's cloud team.
What you get
Named deliverables.
Every engagement lands specific artefacts — not slides.
Signed-off target-state architecture and decision log.
Landing zone deployed as Infrastructure-as-Code — reproducible, versioned, reviewable.
Security baseline live (GuardDuty, Security Hub, Config, encryption defaults).
Identity federation to the customer's IdP.
One workload migrated as pilot — proving the foundation.
Runbooks and operations documentation.
Customer stories
Customers on this journey.
Real Phoenix engagements — measured outcomes at MEA scale.
More cloud services
The wider cloud practice.
FAQ
Frequently asked
Do you use AWS Control Tower or Landing Zone Accelerator?
Both, depending on scale and enterprise policy. Control Tower is the fast path for small-to-mid estates; Landing Zone Accelerator is the choice when regulated workloads, custom guardrails or complex organisation structures are on the table. The decision is made in the assessment, not by default.
Can you retrofit governance onto an existing AWS account?
Yes — that's a common starting point. Phoenix runs a landing-zone remediation programme against the existing accounts: baseline audit, guardrail rollout, org-structure realignment and IAM/SSO cutover, sequenced to avoid disrupting live workloads.
How do you decide the multi-account organisation structure?
Anchored to your operating model — business unit, environment (prod/non-prod), workload sensitivity and blast-radius considerations. The reference is AWS Well-Architected multi-account guidance; the shape lands per customer.
What's in the baseline security posture?
GuardDuty, Security Hub and Config across every account by default; IAM Identity Center for SSO; SCPs to enforce boundary policy; CloudTrail centralised; VPC baselines and network segmentation; encryption keys managed centrally. Anything beyond is scoped in.
Timeline to a production-ready landing zone?
6–10 weeks is typical — discovery, baseline design, deployment, workload pilot, and cutover. Faster if you're greenfield without existing accounts; longer if a heavy remediation of legacy accounts is in scope.
Talk to us
The earliest conversations
are usually the most useful.
Whether you're scoping an SAP move to cloud, restarting a stalled programme, or just trying to figure out where data and AI fit — start with a conversation.