Build your AWS Foundation Right- The Landing Zone Guide.

From identity and networking to security and cost governance, discover how an AWS Landing Zone sets the foundation for successful cloud migration and scale.

4 minutes

17th of June, 2026

Building an AWS Landing Zone for Cloud Migration: Identity, Security, Networking, and More

A cloud landing zone gives enterprises a secure, repeatable starting point for AWS adoption. It defines how workloads are separated, who can access them, how networks connect, where logs are stored, how costs are tracked, and how the environment is operated in production. For organisations planning a migration or scaling cloud operations, that foundation matters early.

This is why a landing zone is more than an AWS setup. It is a business foundation for migration, governance, compliance, repeatable delivery, cost control, and managed operations.

For AWS environments, the foundation usually starts with AWS Organizations, which provides the structure for accounts, organisational units, consolidated billing, and governance policies. AWS Control Tower and Landing Zone Accelerator on AWS can then help organisations establish and govern a secure multi-account environment. Control Tower supports account provisioning, sets up IAM Identity Center for centralised access management by default, and applies centralised logging and controls. Landing Zone Accelerator can work with Control Tower or independently alongside AWS Organizations, and extends that foundation for regulated workloads and complex compliance needs.

The Cloud Foundation Before Migration

Cloud migration is easier to plan when the landing zone is ready before major workloads move. Think of it like preparing a site before construction starts: roads, access points, safety rules, and boundaries need to be in place before people begin building. In AWS, those same ideas show up as accounts, identity, networks, logs, controls, policies, and operating standards.

At a high level, a landing zone consists of core accounts, workload accounts, and governance policies:

AWS Organization
+-- Core OUs
|   +-- Security account
|   +-- Log archive account
|   +-- Network account
|   +-- Shared services account
+-- Workload OUs
|   +-- Development accounts
|   +-- Test accounts
|   +-- Production accounts
+-- Policy layer
    +-- Service control policies
    +-- Resource control policies
    +-- Tag policies
    +-- Backup policies
    +-- Control Tower controls

Account Structure Gives Workloads A Proper Home

A multi-account model separates workloads, environments, and shared services to create cleaner ownership, limit the impact of configuration mistakes, and make billing easier to understand. Akkodis applied this in its Government Cloud Establishment case study, helping a government department in Western Australia use AWS Organizations and a multi-account structure as the foundation for secure cloud delivery and long-term support.

Identity Is Where Trust Begins

Identity sits at the centre of every landing zone: get it right and everything downstream is cleaner. In AWS, IAM is the authorisation layer in every account; every API request is checked against IAM policies. IAM Identity Center adds centralised human access at the organisation level: single sign-on, federation with an identity provider such as Microsoft Entra ID, Okta, or Google Workspace, and permission sets provisioned into each member account as IAM roles. By default, AWS Control Tower sets up IAM Identity Center as part of its baseline.

The pattern is simple: users and groups are defined once in the identity provider, people receive temporary credentials through single sign-on, and applications assume roles. IAM users with long-term access keys play no part in daily work; where they already exist, the landing zone gives them a path to retire.

Strong landing zones enforce single sign-on, use least-privilege permission sets, keep production access separate from non-production, and require multi-factor authentication at sign-in. Each account's root identity is secured with a physical FIDO2 hardware key and left unused for daily work. Break-glass emergency access is monitored: a security team knows within minutes if it is used.

Networking Sets The Routes And Boundaries

Network design is where early decisions have the most visible downstream effect on migration and operations. The landing zone should define VPC structure, IP ranges, routing, DNS, private connectivity, internet egress, and inspection points before application teams start designing their workloads.

A hub-and-spoke model using AWS Transit Gateway is a common enterprise pattern: workload VPCs connect to a central hub handling shared services, egress, and inspection. Internet-bound traffic passes through AWS Network Firewall or approved third-party inspection. Private access to AWS services uses VPC endpoints, which keep traffic within the AWS network entirely rather than routing it across the public internet.

Security Controls Create A Safer Path

Security controls are part of the foundation, not something added later when the auditors ask. Identity answers who can do what; these controls set the outer boundaries that hold even when a role grants too much. AWS Organizations provides two complementary policy types. Service control policies (SCPs) cap what IAM principals can do across accounts and organisational units. Resource control policies (RCPs) cap what can be done to supported resources such as S3 buckets and KMS keys, whoever is calling. Neither grants access; an action succeeds only when SCPs, RCPs, and IAM all allow it.

AWS Control Tower controls can prevent public S3 buckets, restrict deployments to approved Regions, and enforce encryption. GuardDuty uses machine learning to detect anomalous patterns such as unusual geographic API activity or unexpected credential behaviour. For European organisations with strict data sovereignty needs, the AWS European Sovereign Cloud, launched in 2026 as a separate partition operated by a German legal entity, belongs in the landing zone conversation from the start.

Logging And Monitoring Give Teams Visibility

A landing zone should make visibility the default. A dedicated log archive account collects CloudTrail API activity, VPC Flow Logs, AWS Config history, and Security Hub findings from across the organisation. CloudTrail shows who called which API and from where; Config captures before-and-after resource state. Many organisations forward these feeds to a SIEM such as Microsoft Sentinel, Splunk, or Datadog. When this is in place before migration, teams can compare application behaviour before and after cutover and respond faster when something needs attention.

Cost Governance Belongs In The Design

Cloud cost management works better when it starts early. Tag policies requiring owner, project, and cost centre, enforced through AWS Config or AWS Organizations, give finance and engineering a shared view of spend. Budget alerts catch overruns before they compound. Separate production and non-production tracking keeps the picture clean. Regular review of reserved capacity and savings plans then turns visibility into ongoing savings. For organisations migrating Windows Server workloads, it is worth reviewing existing licence agreements at the same time: AWS's per-second billing under its Service Provider License Agreement with Microsoft often delivers better economics than most private volume agreements.

Automation, Backup, and the Operating Model

Infrastructure as code tools such as Terraform, AWS CloudFormation, or AWS CDK make account creation, network patterns, security baselines, and policy deployment repeatable and version-controlled. Without automation, every new account becomes a manual effort that drifts from the standard.

Backup policies, retention rules, and recovery objectives should be defined at the landing zone level. AWS Backup, S3, and EBS snapshots can be standardised across accounts and tested before they are needed.

Equally important: the landing zone needs clear ownership after it is built. A platform team or Cloud Centre of Excellence is responsible for account vending, guardrails, shared services, and continuous improvement. Without an agreed operating model, the environment drifts. Akkodis's managed services, DevOps, security, and Well-Architected experience can support this function across the full lifecycle.

Where Akkodis Fits

Akkodis has been delivering cloud migrations since 2012 and has been an AWS Partner since 2013, with delivery across migration, managed services, security, DevOps, training, and Well-Architected reviews, and more than 400 AWS certifications across the practice. For government and regulated engagements, the practice includes engineers with national security clearances.

Akkodis structures migration engagements in three phases: Assess builds the business case, Mobilize establishes the landing zone and a pilot workload migration, and Migrate moves workload waves in sequence. AWS partner funding through the Migration Acceleration Program (MAP) can offset part of the Assess and Mobilize costs for qualifying migrations.

Landing zone work is both advisory and hands-on. Akkodis teams can support customers with cloud readiness assessments, AWS account and organisation design, identity and network baseline design, centralised logging and monitoring, cloud financial management, infrastructure as code, managed cloud operations, Well-Architected reviews, and platform team support. For a public sector customer, the team set up an AWS Organization and core accounts using AWS Control Tower and AWS Landing Zone Accelerator, with attention to governance, observability, data security, logging, and long-term maintainability.

How Landing Zones Mature Over Time

Every landing zone starts somewhere and grows from there. The right level of maturity for day one is the level that lets teams move safely, not the level that looks complete on a slide. The three levels below reflect how Akkodis sees landing zones grow across migration engagements.

Maturity Level	What It Looks Like	Typical Focus
Level 1: Foundation	Core accounts, identity, logging, basic controls	Safe first workloads and migration readiness
Level 2: Governed Platform	Account vending, stronger SCPs and RCPs, monitoring, cost reporting	Migration waves and production support
Level 3: Self-Service Platform	Policy-as-code, service catalogue, automated compliance	Faster delivery with consistent governance

Ready To Build Your AWS Foundation?

Most organisations reach this conversation from one of two directions. Some are planning a migration and want the foundation ready before workloads move. Others are already in AWS and feeling the gaps: inconsistent account structures, unclear ownership, cost visibility that does not quite add up, or security findings with no clear owner. Both starting points are valid, and a landing zone assessment can work backwards from where you are today.

If your organisation is preparing for AWS migration, reviewing governance across an existing AWS footprint, or building a stronger platform operating model, Akkodis can help assess the current environment, design the landing zone, plan migration waves, and support the platform in production.