Cloud Landing Zone Design: Account Structure, Identity, and Network Controls

The first workloads moved to the cloud often begin in a single account created for speed. As development, test, and production resources grow within the same management boundary, permissions, network connections, logs, and cost ownership can become entangled. Each team added later inherits those early choices. Because correcting the structure requires moving active workloads, the foundation established at the start matters.

A landing zone is the managed starting environment in which cloud workloads are placed. It defines the account or subscription hierarchy, identity model, network topology, security policies, logging, cost tags, and automation approach together. It is not a one-time template. It is a platform product that expands as new workloads arrive and is updated under version control.

Landing zone scope

A good landing zone does not force every application to use the same infrastructure. It provides shared rules and services while giving workload teams separate spaces in which they can operate within those boundaries. Central identity, baseline network connectivity, audit logs, security policies, and cost visibility are managed at the platform level. Application resources remain in separate areas appropriate to the production lifecycle.

When defining scope, the first question is not which cloud service to select, but which risks require central management. Identity and privileged access, external connections, data location, encryption, log retention, and incident response require shared decisions. Application-specific scaling and runtime choices can remain with the workload team. This division helps prevent the central team from becoming a bottleneck.

Account and resource hierarchy

Running many workloads in one account makes access boundaries, billing, and incident impact unclear. Provider-specific management units such as accounts, subscriptions, or projects should serve as security and ownership boundaries. Production and nonproduction environments should be separated. Critical data and highly privileged platform services may require additional separation.

The hierarchy should not simply copy the organization chart. Organizational units may change, while security and operational requirements are more durable. A functional structure with platform, security, connectivity, logging, and workload areas is often more resilient. Each area should have a defined owner, budget responsibility, permitted regions, and lifecycle.

Creating a new area should not depend on a manual ticket process. An approved request should automatically generate the required tags, budget thresholds, log destinations, baseline policies, and network connection. This gives each new workload the same minimum protection. Exceptions should require a separate record, duration, and approval.

Identity and privileged access

Use a central identity source instead of cloud-native local accounts, and connect the employee lifecycle to the access lifecycle. Rights should be updated promptly when a person joins, changes roles, or leaves. Assign roles to managed groups and job functions rather than directly to individuals. Prefer privileges granted only for the duration of a task over permanent broad access.

Emergency accounts are not suitable for daily use. Protect them strongly, ensure that they can operate independently of the normal identity infrastructure, and generate an alert whenever they are used. Store access keys, application passwords, and certificates in central secrets management rather than source code or user devices.

Workload identities should also be treated separately from human identities. Where possible, applications should use short-lived tokens and resource roles rather than static keys. Access from one service to another should be granted according to a verified workload identity and the required action scope, not primarily according to network location. NIST SP 800-210 recommends addressing access control according to component and service layers in cloud service models.

Network, DNS, and external connections

A landing zone network should balance routing all traffic through one central point against giving every team complete freedom. Shared connectivity, firewalls, private name resolution, and on-premises gateways can be managed in the platform area. Workload networks should be separated according to risk, environment, and connectivity needs. Connections between them should be restricted by default and opened only for defined flows.

The IP address plan should be prepared before cloud accounts are created. Overlapping address ranges make later private connections and on-premises network integration difficult. Name resolution belongs in the same plan. Define ownership of private zones, the route for forward and reverse queries, record lifecycles, and visibility between environments.

Internet-bound traffic requires an explicit egress policy. Instead of giving workloads public IP addresses directly, the architecture can use controlled exit points, domain or destination restrictions, and flow logs. The central egress layer must not become a single point of failure. Regional failure, capacity, and dependency scenarios should be tested.

Policy, code, and observability

Baseline rules should be expressed as policy as code wherever possible. Disallowed regions, publicly accessible storage, encryption requirements, logging, and tags can be checked automatically. A preventive control is appropriate when the risk is clear and the effect is understood. Some controls should initially operate in reporting mode and become mandatory only after their effect on existing workloads is known.

Infrastructure as code makes landing zone changes reviewable and repeatable. Networks, policies, account provisioning, and log destinations remain under version control. Changes are validated in a test environment first and have a rollback path. Direct changes through the management interface should either be blocked or detected as configuration drift.

Audit logs should not remain only in the source account. Send them to a separate, restricted logging area where source administrators cannot delete the history. Identity events, management operations, network flows, and policy violations should be searchable on a common timeline. Define retention according to incident-investigation and regulatory needs.

Data security and workload boundaries

Translate data classification into landing zone policy. Define the permitted region for sensitive data, the owner of the encryption key, the backup location, and the conditions for export. Key management can be separated from the application account, and key use and policy changes can be logged independently. Encryption does not replace access control.

Production, test, and development environments should not be separated only by naming tags. Use separate management areas, separate permission groups, and controlled data flows. Limit copying real production data into a test environment, and apply masking or synthetic data where needed. Explicitly test the boundaries that prevent a compromise in one environment from spreading to another.

Operating model and change management

A landing zone becomes outdated quickly if it is treated only as an implementation project. As cloud services, threats, and internal requirements change, the platform team must update the baseline modules. Each release should include an impact assessment, test results, migration notes, and rollback steps. Workload teams should know when an update becomes mandatory and what preparation it requires.

The platform team can define measurable service levels. It can track the time required to create a new account, the time to detect a policy violation, log-delivery success, the duration of privileged access, and the number of configuration-drift events. Resource count or cloud spending alone does not show the quality of governance.

Cost management should also be part of the baseline design. Mandatory tags, budget thresholds, unexpected-spend alerts, and unused-resource reports should operate in every area. Explaining at the outset how shared platform costs are allocated to workloads reduces later ownership disputes.

Common mistakes

The first mistake is postponing all workload migrations until the landing zone is complete. An overly broad design can take months and create incorrect assumptions without real usage data. Validate a minimum secure foundation with a representative workload, then expand it in stages. The second mistake is requiring manual approval from the central team for every control. Clear policies and automated guardrails should allow teams to work safely within defined boundaries.

Other mistakes include keeping production and development in the same account, granting permanent administrator rights, storing logs where a source administrator can delete them, leaving network and DNS ownership unclear, changing resources outside infrastructure as code, and keeping exceptions open indefinitely. A landing zone is not completed by purchasing a security product. Identity, network, policy, and operational decisions must work together.

A phased implementation plan

In the first phase, inventory current accounts, identity sources, network connections, and regulatory requirements. In the second, establish the minimum management hierarchy, central logging, identity federation, and baseline policy set. In the third, move a low-risk workload into the new area and test access, networking, backup, and cost visibility end to end.

In the fourth phase, automate account provisioning and policy distribution through infrastructure as code. In the fifth, strengthen production, data, and privileged-management boundaries and move existing workloads in planned waves. In the final phase, review configuration drift, exception duration, and control effectiveness regularly.