Quick answer
Before deploying production workloads, establish separate workload and administrative environments, federated access with least privilege, explicit network boundaries, protected audit logging, managed secrets and tested resource policies. Give each control an owner and a recovery procedure.
“Minimum viable” means simplifying the architecture—not omitting safeguards. AWS and Azure reference architectures provide starting points, but the implementation must reflect your organization’s requirements. (docs.aws.amazon.com)
This guide is for teams preparing their first production cloud environment or improving an informal setup. It assumes an identified workload, an approved cloud provider and people authorized to administer the environment. The worked example uses AWS terminology; it is a proposed design, not a deployment tutorial or a tested customer case study.
1. Define the foundation and its production acceptance criteria
A landing zone is the foundation into which workloads are deployed. AWS describes a multi-account environment covering organizational units, accounts, users and resources. Azure distinguishes a shared platform landing zone from workload landing zones where application teams operate within platform guardrails. Neither definition means that a landing zone replaces application architecture. (docs.aws.amazon.com)
Start with a short design record. AWS’s documentation guidance recommends identifying stakeholders, documenting decisions and sharing an approved, revision-controlled design. (docs.aws.amazon.com)
For a small team, record:
- Scope: Which workloads and environments will use the foundation?
- Ownership: Who approves identity, networking, policies and exceptions?
- Data requirements: What information will be stored, and what handling restrictions apply?
- Operations: Who receives alerts and investigates incidents?
- Acceptance tests: What evidence must exist before production deployment?
- Recovery: Who can reverse a faulty configuration change?
Use these as proposed acceptance criteria rather than a universal certification checklist. For example: an ordinary developer cannot administer production, an unauthorized identity cannot retrieve an application secret, and a sample administrative event reaches the protected log destination.
Keep workload-specific questions—such as backup restoration, capacity and application failover—in a separate readiness review. Passing the landing-zone checks should not be treated as permission to skip that review.
2. Separate workloads from administration and security
Organize environments around differences in trust, permissions and operational responsibility. For this baseline, use distinct production and nonproduction workload environments, and keep centralized governance and security functions outside application teams’ routine administrative control.
AWS Control Tower’s published shared-account model distinguishes management, log archive and audit accounts. Its documentation explicitly advises against running production workloads in the management account. Azure similarly separates centralized platform capabilities from workload environments. (docs.aws.amazon.com)
The useful question is not “How many accounts can we create?” It is “Which activities should remain separate?”
Document:
| Boundary | Decision to record |
|---|---|
| Production versus nonproduction | Who can deploy, change permissions and access data? |
| Platform versus workloads | Who controls shared policies and services? |
| Logs versus application administration | Who can read, delete or change retention? |
| Billing responsibility | Who reviews spending and approves new environments? |
Avoid treating names such as production or security as proof of isolation. Validate the actual role assignments and policy scopes.
Do not assume provider terms are interchangeable. An AWS account and an Azure subscription occupy different provider-specific architectures. Translate the intended boundary, then verify how that provider implements it.
3. Federate human access and narrow workload permissions
For AWS, official IAM guidance recommends federation with temporary credentials for human users, temporary credentials through roles for workloads, multifactor authentication and least-privilege permissions. It recommends IAM Identity Center for centralized account access management. (docs.aws.amazon.com)
Build your access model around responsibilities:
- Platform administrators: maintain the foundation.
- Workload deployers: release an application within its assigned environment.
- Operators: inspect health and perform approved operational actions.
- Security reviewers: investigate configuration and activity.
Avoid making administrator access the default developer experience. Define permitted actions and resources, then review unused permissions. Where people wear multiple hats, keep the roles separate and require an explicit switch into privileged access. These recommendations follow AWS’s least-privilege and access-review guidance. (docs.aws.amazon.com)
Treat application and deployment identities separately from human identities. A deployment pipeline should not inherit every permission held by its author.
Practical checks: Test both successful and denied access. Confirm that the deployment identity can perform the approved release but cannot change organization-wide policy.
Also propose and test an emergency-access procedure independent of normal sign-in. Record its custodian, protection, alerting and post-use review. Do not assume that emergency access bypasses every policy: AWS SCP restrictions can affect member-account administrators and root users. (docs.aws.amazon.com)
4. Make network paths explicit, including outbound traffic
Begin with a traffic table, not a large network diagram:
| Source | Destination | Intended access |
|---|---|---|
| Internet clients | Approved application entry point | Public application traffic |
| Application component | Database | Required database connection |
| Deployment system | Deployment interfaces | Release operations |
| Application component | External dependency | Documented outbound connection |
| Operators | Management interfaces | Approved administrative access |
AWS recommends security groups for controlling traffic to EC2 instances, network ACLs for subnet-level controls and VPC Flow Logs for observing IP traffic. These controls serve different purposes; flow logging is observation, not enforcement. (docs.aws.amazon.com)
A common mistake is reviewing inbound rules while ignoring outbound access. Newly created AWS security groups allow all outbound traffic by default and require rules to permit inbound traffic. Inspect the deployed rules rather than assuming both directions are restricted. (docs.aws.amazon.com)
For this baseline, avoid public database and management access. Test intended connections from the actual application and operator paths, and test that an unauthorized path fails.
A central network hub or inspection appliance is not automatically part of your minimum. Add it when connectivity or security requirements justify it. Keep a dependency list before restricting outbound access so that the approved policy preserves necessary deployment, identity and service connections.
5. Collect audit evidence outside routine workload control
Audit logging should let the team investigate who performed an action, what changed and where it occurred. AWS CloudTrail records supported account activity, including API and non-API activity, but event categories have different coverage. Trails log management events by default; data events must be selected explicitly and incur additional charges. (docs.aws.amazon.com)
Do not interpret “CloudTrail is enabled” as “all relevant data access is recorded.”
An AWS organization trail can cover the management account and member accounts. Users in member accounts cannot alter that organization trail through their local CloudTrail permissions. Creating one requires access through the management account or a delegated administrator, with the necessary permissions. (docs.aws.amazon.com)
For your proposed baseline:
- Identify required management and data events.
- Choose a central destination and approved retention.
- Separate log-reader permissions from log-management permissions.
- Assign an owner for collection failures and investigation alerts.
- Produce a harmless test event and locate it in the destination.
Verify the storage permissions separately. Protection of the trail configuration is not a substitute for reviewing who can alter its destination.
Use a recorded test action, identity and approximate time to check delivery. A configuration screenshot alone is not acceptance evidence.
6. Manage secrets and introduce guardrails gradually
Store credentials that cannot be replaced with workload identity in a managed secrets service. AWS Secrets Manager guidance covers finding exposed secrets in code, limiting access, choosing encryption keys, rotation and monitoring. It also cautions that these practices are considerations, not a complete security solution. (docs.aws.amazon.com)
For this baseline, give each workload access only to its required secrets. Test retrieval without printing the value, and test an unauthorized identity. Plan rotation together with the application’s credential-refresh behavior.
Be careful with network-based secret policies. AWS warns that restricting secret access to a VPC or endpoint can inadvertently block services retrieving secrets on your behalf. (docs.aws.amazon.com)
Distinguish two policy purposes:
- Identity permissions: what an identity may do.
- Guardrails: what remains prohibited or required despite those permissions.
AWS SCPs limit available permissions; they do not grant access. They also do not constrain users or roles in the organization’s management account. Azure Policy evaluates resource state, while Azure RBAC governs user actions. (docs.aws.amazon.com)
Propose a small initial rule set: approved deployment locations, restricted public exposure, required ownership metadata and protection of central logging. Verify service-specific support before implementing each rule.
Microsoft recommends starting policies in audit mode where appropriate. AWS recommends testing SCPs on a limited organizational scope before broad application. (learn.microsoft.com)
7. Worked example: a small-team AWS blueprint
Illustrative assumptions: One application, production and nonproduction environments, an existing identity provider, no on-premises connectivity requirement and no identified requirement for multi-region operation.
A proposed layout uses these account purposes:
| Account purpose | Intended contents |
|---|---|
| Management | Organization administration; no production application |
| Log archive | Central audit destination |
| Security/audit | Security review and tooling |
| Nonproduction | Development and release validation |
| Production | Production application resources |
The shared-account purposes follow AWS documentation; the two workload accounts are choices for this example, not a universal minimum or fixed requirement for every landing-zone product. (docs.aws.amazon.com)
Propose separate workload networks, explicit application-to-database rules, federated human roles, a scoped release identity, managed application secrets and centralized audit collection.
Then run a release rehearsal:
- A developer signs in and works in nonproduction.
- The release identity deploys the approved production change.
- The application retrieves its assigned secret without exposing its value.
- An unrelated identity fails the same retrieval check.
- A harmless administrative action appears in central audit storage.
- A test deployment violating one selected guardrail is rejected.
Treat these as expected results to verify, not outcomes already achieved.
Defer a transit network, enterprise directory servers, custom policy engine and multi-region foundation unless requirements call for them. Record those omissions and their triggers for reconsideration. The aim is an understandable foundation, not a miniature enterprise diagram.
8. Deploy safely, validate denials and preserve rollback
Before implementation, prepare a change record containing the target accounts or subscriptions, administrative scope, reviewed configuration, expected charges, test plan and rollback owner.
Use a staged procedure:
- Confirm permissions. Identify the authorized identity for each change; do not rely on a broadly privileged daily account.
- Capture the current state. Record policy assignments, role mappings, routes and relevant rules.
- Pilot narrowly. Apply changes to nonproduction or a limited test scope.
- Test allowed and denied actions. Include application, deployment and operational dependencies.
- Promote with review. Record exceptions, owners and expiry dates.
- Clean up safely. Remove disposable test resources without deleting audit evidence or shared foundations.
Microsoft recommends managing Azure Policy as code with manual reviews. AWS warns against modifying or deleting Control Tower-managed resources outside supported methods. (learn.microsoft.com)
Define rollback for the specific change: restore the previous role mapping, rule set or narrowly scoped policy assignment. Do not use “delete the landing zone” as the recovery plan.
Final checks: Can the team deploy without permanent administrator access? Can it investigate a change? Do forbidden actions fail? Can an authorized owner reverse a faulty guardrail?
Approve the foundation only when those answers are supported by recorded tests, then complete the separate workload-readiness review.
Read next: Regions and Availability Zones: What They Mean for Application Design