How to Structure Cloud Environments

A cloud environment is more than an application configuration value. It includes the identities that can deploy, the data they can reach, the network paths they can open, the limits they can consume, and the damage a mistake can cause.

For most teams, the minimum sensible design is one isolation boundary for production and another for non-production. As the product, team, or regulated-data scope grows, development, staging, and production should each receive their own boundary. In AWS that normally means accounts; in Google Cloud, projects; and in Azure, subscriptions.

Sources reviewed 13 Aug 2026: current AWS Organizations and multi-account guidance, Google Cloud resource hierarchy and landing-zone guidance, Azure management-group and landing-zone guidance, and HHS cloud-computing, Security Rule, risk-analysis, and contingency-planning material.

Use the strongest practical boundary

Environment names, tags, resource groups, VPC subnets, and Kubernetes namespaces are useful organization tools. On their own, they are weak protection against an over-permissioned role, a deployment pointed at the wrong target, a shared quota, or a destructive infrastructure change.

The point is not to maximize the number of accounts. It is to place a hard boundary where access, data sensitivity, operational ownership, or acceptable failure impact changes.

A vendor-neutral shape

The provider vocabulary changes, but a durable cloud foundation usually has five areas:

Cloud organization or tenant
├── Security and audit
├── Shared infrastructure
├── Sandbox
├── Non-production workloads
│   ├── Development
│   └── Staging
└── Production workloads

Security and platform accounts should not become general-purpose hosting areas. Their value comes from narrow ownership and limited ways for an application failure to interfere with the controls used to detect or investigate it.

Use AWS accounts as workload boundaries

AWS recommends separating production from non-production and grouping accounts by security and operational needs rather than mirroring the reporting chart. AWS Organizations provides the hierarchy; organizational units (OUs) group accounts that need similar controls; and service control policies (SCPs) limit the maximum permissions available beneath them.

AWS Organization
├── Security OU
│   ├── Log Archive account
│   └── Security Tooling account
├── Infrastructure OU
│   ├── Network account
│   └── Shared Services account
├── Sandbox OU
├── Non-Production OU
│   ├── Product Development account
│   └── Product Staging account
└── Production OU
    └── Product Production account

A small team can begin with production and non-production accounts plus a management account that hosts no workloads. A larger platform can allocate one account per product and environment. Keep the OU hierarchy shallow. SCPs do not grant permissions, and they do not apply to principals in the management account, which is another reason to keep workload data and runtime out of it.

Controls to establish

• Use IAM Identity Center or another federated identity path for human access, with short-lived roles, MFA, separate production permission sets, and a monitored emergency path.
• Apply SCPs to cap member-account permissions, such as denying attempts to disable required logging or use unapproved Regions; pair them with IAM policies that grant only the access a role needs.
• Aggregate CloudTrail, AWS Config, GuardDuty, Security Hub CSPM, and other required evidence into security-owned accounts.
• Give each environment separate VPCs, KMS keys, secrets, deployment roles, budget alerts, backup vaults or policies, and service quotas where practical.
• Use Control Tower or account-vending automation so a new account arrives with the baseline already installed.

Cross-account access should be deliberate and visible. A development pipeline should not be able to assume a production deployment role merely because both accounts sit in the same organization.

Use GCP projects as environment boundaries

Google Cloud places an organization at the top of its resource hierarchy, optional folders beneath it, and projects below. Projects are the normal trust boundary and the fundamental unit for service enablement, IAM, quotas, resource lifecycle, and billing attribution. Allow, deny, and organization policies can be attached higher in the hierarchy and inherited by descendants.

Google Cloud Organization
├── Common folder
│   ├── Security project
│   ├── Logging project
│   └── Shared Services project
├── Sandbox folder
├── Non-Production folder
│   ├── product-dev project
│   └── product-stage project
└── Production folder
    └── product-prod project

Use Organization Policy constraints and carefully scoped folder-level IAM for common guardrails, then grant workload-specific access at the project level. Remember that a broad role granted at the organization or folder flows into every descendant; inspect the effective policy, not only what appears directly on a project. Keep project creation controlled so experiments do not become ownerless production dependencies.

Controls to establish

• Use separate projects for development, staging, and production; split runtime, sensitive data, security, logging, and shared networking further when ownership or risk differs.
• Design Shared VPC host projects intentionally. Google documents environment-specific networks for production, development, and testing in its landing-zone example.
• Route required audit and application logs through aggregated sinks into a restricted logging project.
• Use workforce federation for people and Workload Identity Federation or attached service accounts for workloads instead of distributing long-lived service-account keys.
• Apply organization constraints, billing-account links, budgets, labels, backup policies, and project provisioning through an approved foundation pipeline.

A shared network can simplify connectivity, but it can also blur environment ownership. Separate host projects or clearly segmented networks are easier to reason about when production has different inspection, egress, or regulatory requirements.

Use subscriptions to separate Azure environments

Azure landing zones use a Microsoft Entra tenant, management groups, subscriptions, and resource groups. Microsoft recommends subscriptions as units of management and an application landing zone for each workload environment. Management-group Azure Policy and RBAC assignments cascade to descendant management groups, subscriptions, resource groups, and resources.

Microsoft Entra tenant
├── Platform management group
│   ├── Identity subscription
│   ├── Connectivity subscription
│   └── Management subscription
├── Sandbox management group
├── Non-Production management group
│   ├── Product Dev subscription
│   └── Product Stage subscription
└── Production management group
    └── Product Production subscription

Development, staging, and production subscriptions can remain under the same workload archetype management group when they should inherit the same baseline. Create a distinct management-group branch only when a group of subscriptions genuinely needs different inherited policy or access. Resource groups remain useful for lifecycle and ownership inside a subscription, but they should not replace a subscription when the environment needs independent access, policy, quota, cost, or blast-radius control.

Controls to establish

• Use separate Microsoft Entra groups and Azure RBAC assignments for each application landing zone; use Privileged Identity Management for just-in-time administrative access.
• Assign Azure Policy initiatives at management-group scope, restrict who can change assignments or exemptions, and verify each subscription's effective compliance state.
• Use dedicated platform subscriptions for connectivity, management and security services, with workload subscriptions connected through explicit hub-and-spoke or Virtual WAN routes.
• Give every environment its own managed identities, Key Vault boundaries, deployment federated credentials, budgets, diagnostic settings, and backup policies.
• Use subscription vending so new landing zones arrive with policy, role assignments, networking, logging, cost ownership, and lifecycle metadata already configured.

Avoid using one generic administrator group across landing zones. A developer who needs access to two subscriptions should be assigned through the appropriate group in each, leaving the production path independently reviewable and revocable.

Translate the principle, not just the names

OCI uses a tenancy with hierarchical compartments, IAM policies, quotas, VCNs, Security Zones, and landing-zone templates. Oracle recommends separate production and non-production compartments. For higher-risk systems, also evaluate whether separate tenancies or stronger network and identity boundaries are warranted.

Developer platforms such as Vercel and Cloudflare offer projects, teams, deployment environments, variables, and access controls. Use separate projects when production secrets, domains, billing ownership, or deployment permissions need a harder boundary than environment-scoped settings provide.

Kubernetes namespaces are valuable inside a cluster, but they do not isolate the cloud account, cluster control plane, node identity, or every cluster-wide component. A regulated or high-impact production workload may justify a separate cluster as well as a separate cloud account, project, or subscription.

Map the operating model, not only the hierarchy

The names differ, but every environment needs an owned implementation for the same control areas. These are starting points, not automatic security outcomes.

Do not treat a budget as a hard security limit or a centralized log destination as proof of coverage. Test the effective policy, deployment trust, routes, log sources, alert delivery, backup immutability, and restore permissions in each environment.

Different environments should actually behave differently

Staging should resemble production where that similarity proves a release assumption: service versions, deployment topology, policy, integrations, and failure behavior. It does not need production customer records or unrestricted production scale to do that job.

Make production access a separate decision

Federate workforce access into environment-specific groups and short-lived roles. Do not copy a broad developer or platform-administrator group across development, staging, and production. Use separate workload and deployment identities as well: a runtime identity should not deploy infrastructure, and a non-production pipeline should have no trust relationship that lets it become a production deployer.

Design break-glass access before the outage

• Create a very small, named emergency path for organization, identity, and production recovery; do not use it for routine administration.
• Protect emergency credentials with strong, independent authentication and a controlled recovery process that remains usable if the primary identity provider is unavailable.
• Alert on every sign-in, role activation, credential retrieval, and privileged action. Require a ticket or incident record, a second-person check where feasible, and a post-use review.
• Test the path on a schedule without making an uncontrolled production change. Rotate or reseal credentials after use and verify that logs reached the independent evidence boundary.

Emergency access should restore control, not create a permanent bypass. Provider-level root, organization, or tenant privileges need a stricter process than an application operator role.

Make experimentation disposable

Place sandboxes in a dedicated AWS OU, Google Cloud folder, or Azure management group with a visibly different policy set. Deny production trust paths, production data, regulated data, public exposure by default, and attachment to production networks. Allow only the services, Regions, and external connections the experiment needs.

Every sandbox needs an owner, budget alerts, quota limits, an expiry date, and automated cleanup. If an experiment becomes a product dependency, recreate it through the normal landing-zone and CI/CD path; do not move an opaque sandbox into production and inherit its identities, secrets, manual changes, and unknown data.

Promote artifacts, not cloud drift

Infrastructure modules should be reusable, but state, identities, variables, secrets, and approvals should be separated. Reusing the same Terraform module across environments is healthy. Pointing every environment at one state file, runner, or administrator credential is not.

1. Build, scan, sign where appropriate, and identify an immutable application artifact once.
2. Deploy it to development with the development identity and configuration.
3. Promote the same artifact to staging for release validation.
4. Require the production checks and approval appropriate to the risk, including a safe plan for database and policy changes.
5. Deploy by artifact digest through a narrowly scoped production identity, verify health and evidence, then exercise a tested rollback or roll-forward path if needed.

Use CI/CD identity federation such as OIDC instead of storing long-lived cloud credentials. Bind trust to the expected repository, protected branch or tag, workflow, and environment—not merely to the CI vendor. Limit each identity to its environment. Keep infrastructure changes in review, canary policy changes before broad rollout, scan plans for cross-environment targets, and detect manual changes after deployment.

Share deliberately

A shared service needs an owner, availability expectation, access contract, data classification, cost-allocation model, and failure analysis. Use explicit network routes, firewall policy, private endpoints, DNS ownership, and service identities; avoid making every environment transitively reachable through a central hub. If one non-production experiment can exhaust, reconfigure, or delete a service required by production, the service is shared too casually.

Central artifact registries can be reasonable when non-production can publish only to a quarantine or candidate area and production consumes immutable, verified artifacts. Shared databases, queues, caches, secret stores, keys, and backup administration usually create more coupling and cross-environment risk than they save.

Keep evidence and recovery usable after compromise

Send organization, control-plane, identity, network, security, and required application telemetry to a security- or management-owned destination. Workload administrators should be able to emit and query the data they need without being able to silently disable collection or erase the authoritative copy. Verify log coverage with test events, alert delivery, retention checks, and periodic queries; a configured destination does not prove that every relevant source is arriving.

Debugging detail should still follow a field-level data policy. Redact or reject tokens, credentials, request bodies, patient identifiers, clinical content, and other sensitive payloads before they enter logs, traces, replays, metrics labels, alerts, or support integrations. Give each environment its own access and retention profile.

Backups need their own failure analysis. Separate backup administration and recovery credentials from routine workload administration, prevent or delay destructive deletion where supported, encrypt recovery points with an intentional key strategy, and account for cross-account, cross-project, cross-subscription, Region, and residency requirements. Test complete restores into an isolated recovery environment and record actual recovery time and data loss against the defined RTO and RPO.

Keep sensitive data out of lower environments

HHS guidance says a cloud service provider that creates, receives, maintains, or transmits ePHI on behalf of a regulated entity is a business associate even when it stores only encrypted ePHI and does not hold the key. A HIPAA-compliant BAA is therefore part of the contractual boundary, but neither a BAA nor a provider's eligible-services list configures the environment, performs the required risk analysis, or prevents a developer from copying PHI into a test database.

• Approve the accounts, projects, subscriptions, Regions, and services allowed to process ePHI.
• Inventory where ePHI is created, received, maintained, transmitted, backed up, logged, exported, and restored across every environment and vendor.
• Prefer synthetic data in development and staging. Use de-identified data only through a documented process appropriate to the use case.
• If a lower environment must process PHI, include it in the regulated scope and apply the corresponding risk, access, audit, retention, vendor, contingency, and incident controls.
• Separate encryption keys, secrets, deployment identities, audit trails, and backups from non-regulated workloads.
• Prevent production exports from becoming permanent test fixtures, CI artifacts, support attachments, observability payloads, or analytics files.

HHS risk-analysis guidance covers all ePHI an organization creates, receives, maintains, or transmits, and its contingency material addresses data backup, disaster recovery, emergency-mode operations, and periodic testing. Use those responsibilities to drive the environment design and documented operating procedures. This article is technical guidance, not legal advice, and no cloud layout by itself guarantees HIPAA compliance.

Environment-specific discovery controls can help verify the intended boundary. For example, Amazon Macie can identify possible PHI in S3, including data that has appeared outside its expected production location; discovery still needs an owned triage and remediation workflow.

Start with the risk you actually have

Do not create dozens of empty accounts without account vending, inventory, ownership, and baseline automation. More boundaries reduce blast radius only when the organization can govern them consistently.

Questions to answer before the next deployment

1. Can a non-production identity modify or read production resources?
2. Can a mistaken deployment target the wrong environment?
3. Are data, secrets, keys, networks, backups, and quotas environment-specific?
4. Have you inspected the effective inherited policy and access, including exemptions and cross-boundary trust?
5. Can security teams investigate an environment even if its workload administrators or primary identity path are compromised?
6. Have you tested emergency access, alert delivery, and a complete restore without relying on the failed environment?
7. Are new accounts, projects, or subscriptions provisioned from a maintained baseline with a technical and cost owner?
8. Is the same verified artifact promoted rather than rebuilt differently for production?
9. Are exceptions visible, owned, time-limited, and reviewed, and are sandbox resources automatically expired?

Continue into migration and data controls

Official cloud references: AWS multi-account design principles, AWS Organizations setup and policy behavior, Google Cloud resource hierarchy, Google Cloud landing-zone hierarchy, Azure management groups, and Azure application environments.

Official HHS references: cloud-computing guidance, Security Rule summary, risk-analysis guidance, and the HIPAA audit protocol sections covering access, audit controls, contingency planning, and restore testing.