Architecture pattern: platform, security and operations

Secure cloud foundation: set up the base before the first workload

A cloud foundation, often called a landing zone, is the base every later workload stands on: how accounts are organised, who can sign in, how networks connect, what is recorded and what you may spend. Here is how the pieces fit, which service plays each part on AWS, Azure and Google Cloud, and the order to set them up in.

Quick answer

A secure cloud foundation, or landing zone, organises the cloud into separate accounts under one top-level organisation, with policies that apply to all of them. Staff sign in through one directory with multi-factor sign-in, least-privilege roles limit access, a central audit log records every action, and budgets watch spending.

Best forAny organisation about to run real workloads in the cloud, and teams that must show control to auditors or customers
Less suited whenA short-lived test with no real data, where one sandbox account with a budget alert is enough
Start withOne organisation, separate accounts for production and other work, single sign-on with multi-factor sign-in, a central audit log and budget alerts
Main services on AWSAWS CloudTrail, AWS Security Hub, AWS Cost Explorer and Budgets, AWS Organizations, AWS IAM Identity Center, AWS IAM, Amazon VPC
Main services on AzureAzure Activity Log, Microsoft Defender for Cloud, Microsoft Cost Management, Management groups and Azure Policy, Microsoft Entra ID, Azure role-based access control, Azure Virtual Network
Main services on Google CloudCloud Audit Logs, Security Command Center, Cloud Billing reports and budgets, Resource Manager, Cloud Identity, Cloud IAM, Virtual Private Cloud

The idea in plain words

Most cloud problems that hurt, such as an open storage bucket, a leaked key or a surprise bill, trace back to how the account was first set up. A foundation is the set of decisions you make once, early, so that every later project starts safe by default instead of fixing the basics under pressure.

The parts are the same on every cloud. An organisation groups many accounts, subscriptions or projects, and each workload or team gets its own, so a mistake stays contained. Policies set at the top apply to all of them. Staff sign in through one directory, roles grant only the access needed, networks are planned before anything is placed on them, and logs go somewhere workload owners cannot edit.

Build the foundation as code, review it like software and keep it small. You can extend it later, but moving a workload between accounts or redoing a network once it is busy costs far more.

The architecture

Boxes show the job each part does. Pick a cloud to see the service for each job.

Secure cloud foundation: architecture diagramTwo rows of boxes. The numbered steps below describe the same flow in words.records every changeflags risky settingsbudget per workloadstart from a template1. Always on, from day one (record, check, budget)Audit logsEvery action recordedand kept safeAWS CloudTrailAzure Activity LogCloud Audit LogsPosture checksFlags risky settingsand missing controlsAWS Security HubMicrosoft Defenderfor CloudSecurity CommandCenterBudgets and alertsShows spend and warnsbefore it runs awayAWS Cost Explorerand BudgetsMicrosoft CostManagementCloud Billingreports andbudgets2. Build the structure (in this order)OrganisationGroups accounts andsets rules for allAWS OrganizationsManagement groupsand Azure PolicyResource ManagerStaff sign-inOne directory, onelogin, a second factorAWS IAM IdentityCenterMicrosoft Entra IDCloud IdentityAccess rolesEach person andservice gets only whatit needsAWS IAMAzure role-basedaccess controlCloud IAMNetworkPrivate address space,split by purposeAmazon VPCAzure VirtualNetworkVirtual PrivateCloudWorkload accountsA separate home foreach app and stageSecure cloud foundation: architecture diagramBoxes from top to bottom. The numbered steps below describe the same flow in words.records every changeflags risky settingsbudget per workload1. Always on, from day one (record,check, budget)Budgets and alertsShows spend and warns before itruns awayAWS Cost Explorer andBudgetsMicrosoft Cost ManagementCloud Billing reports andbudgetsPosture checksFlags risky settings and missingcontrolsAWS Security HubMicrosoft Defender for CloudSecurity Command CenterAudit logsEvery action recorded and keptsafeAWS CloudTrailAzure Activity LogCloud Audit Logs2. Build the structure (in thisorder)OrganisationGroups accounts and sets rules forallAWS OrganizationsManagement groups and AzurePolicyResource ManagerStaff sign-inOne directory, one login, a secondfactorAWS IAM Identity CenterMicrosoft Entra IDCloud IdentityAccess rolesEach person and service gets onlywhat it needsAWS IAMAzure role-based accesscontrolCloud IAMNetworkPrivate address space, split bypurposeAmazon VPCAzure Virtual NetworkVirtual Private CloudWorkload accountsA separate home for each app andstage↩ start from a template, back to organisation
Arrows show the direction of the flow, and dashed lines connect the rows. Each box names the main service for that job, taken from CloudBrum's service suggester.

Step by step

  1. Plan the structureDecide how many accounts you need and how they group: production apart from other work, shared services such as logging and networking in their own accounts, and one account per workload or team where it makes sense.
  2. Create the organisation and set rulesCreate the top-level organisation and attach policies that apply to every account below it, for example allowed regions, blocked risky actions and required tags. Protect the management account like a vault.
  3. Connect staff sign-inLink your company directory so people sign in once, with multi-factor sign-in, and lose access automatically when they leave. Keep one or two emergency accounts, locked away and tested.
  4. Define access rolesGive people and applications roles with the least permissions they need, grouped by job. Prefer short-lived credentials to long-lived keys, and review roles regularly.
  5. Plan the networkChoose address ranges that will not clash with your offices or other clouds, split networks by purpose and connect them through a shared hub. Keep workloads off the public internet unless they must be there.
  6. Turn on records and checksSend audit logs from every account to a separate, locked account. Enable the provider's threat detection and posture checks so risky settings and new threats raise an alert.
  7. Set budgets and templatesSet budgets and alerts per account, require cost tags and create a template so new accounts start with the same rules, logging and network. Write the whole foundation as code.

Services side by side

The main service for each job on each cloud, with a second option where one exists. Names checked on 23 October 2026.

JobAWSAzureGoogle Cloud
Audit logs: who did what
  • AWS CloudTrailRecords API calls and account activity
  • Azure Activity LogSubscription-level record of who did what, part of Azure Monitor
  • Cloud Audit LogsAdmin activity and data access logs for Google Cloud
Security posture and compliance checks
  • AWS Security HubSecurity checks and findings across accounts, including CIS benchmarks
  • AWS Config
  • Microsoft Defender for CloudSecure score and recommendations (CSPM)
  • Azure Policy
  • Security Command CenterPosture management, misconfiguration findings and compliance
  • Organization Policy Service
Track and reduce cloud costs
  • AWS Cost Explorer and BudgetsSee, forecast and alert on spend
  • Savings Plans
  • Microsoft Cost ManagementCost analysis, budgets and recommendations
  • Azure Reservations and savings plans
  • Cloud Billing reports and budgetsSpend reports, budgets and alerts
  • Committed use discounts
Multi-account setup and governance (landing zone)
  • AWS OrganizationsMultiple accounts with consolidated billing and policies
  • AWS Control Tower
  • Management groups and Azure PolicyOrganise subscriptions and enforce standards
  • Azure landing zones
  • Resource Manager (organisation, folders, projects)The hierarchy for access and policy
  • Organization Policy Service
Staff sign-in, single sign-on and directory
  • AWS IAM Identity CenterSingle sign-on to AWS accounts and apps from your directory
  • AWS Managed Microsoft AD
  • Microsoft Entra IDSingle sign-on, MFA and Conditional Access for staff (formerly Azure Active Directory)
  • Cloud IdentityManage users, SSO and devices for your organisation
  • Managed Service for Microsoft Active Directory
Who can access what (IAM)
  • AWS IAMUsers, roles and policies that control access to AWS
  • Azure role-based access control (RBAC)Assign roles on subscriptions, resource groups and resources
  • Managed identities
  • Cloud IAMRoles and policies on projects and resources; service accounts for workloads
Private network (VPC / virtual network)
  • Amazon VPCYour private network: subnets, routing and security groups
  • Azure Virtual NetworkPrivate network with subnets, routing and network security groups
  • Virtual Private Cloud (VPC)Private network with subnets and firewall rules; one VPC can span regions
Encryption keys (KMS and HSM)Optional
  • AWS Key Management Service (KMS)Creates and controls encryption keys; integrated with most AWS services
  • AWS CloudHSM
  • Azure Key VaultManaged keys and customer-managed key support
  • Azure Key Vault Managed HSM
  • Cloud Key Management ServiceCreates and manages encryption keys, including customer-managed keys
  • Cloud HSM

Each cloud names the top level differently: an organisation with accounts on AWS, management groups with subscriptions on Azure, and an organisation with folders and projects on Google Cloud.

Common variations

  • A small team with one product. Start with fewer accounts: one for production, one for everything else, plus a separate account for logs. Add more when teams or rules require it.
  • Regulated data such as health or payments. Keep regulated workloads in their own accounts with stricter policies, stronger key controls and longer log retention. See the healthcare and payments patterns.
  • More than one cloud. Keep one identity directory and common rules across clouds, and accept that network and policy tools differ on each. Standardise the principles, not the products.
  • Offices or data centres to connect. Add a shared network hub with a VPN or a dedicated link, and choose address ranges that do not overlap with your offices.

Try this in the service suggester

Provider starter kit or your own infrastructure as code?

Each cloud offers a ready-made starting point for a landing zone. The alternative is to write the foundation yourself as infrastructure as code, using the tools shown in the table.

 AWSAzureGoogle Cloud
Infrastructure as code
  • AWS CloudFormationDefines AWS resources in templates; the AWS CDK lets you write them in code
  • BicepAzure's readable language for ARM templates
  • Infrastructure ManagerManaged Terraform deployments on Google Cloud

Provider's landing-zone starter

Good

  • Sensible defaults ready in days
  • Follows the provider's own good practice
  • Less to design from scratch

Watch out

  • Opinionated, and hard to bend later
  • Different shape on each cloud
  • You still must understand what it created

Your own infrastructure as code

Good

  • Fits your structure and rules exactly
  • Reviewed and versioned like software
  • One method across teams

Watch out

  • Takes design time and skilled people
  • You maintain it as services change
  • A mistake in the base affects everything
A common path. Use the provider's starter for a first version if it fits, then bring it under your own code and review so you control every later change.

Keep in mind

  • Protect the top accounts. The management account and its root sign-in can undo everything. Use a long unique password, a hardware key for multi-factor sign-in and a shared mailbox you control, and almost never sign in with it.
  • Least privilege, then review. Broad admin rights are a common cause of breaches. Start narrow, use group-based roles, expire temporary access and review who holds powerful roles every quarter.
  • Logs the workload cannot delete. Send audit logs to a separate account and store them where nobody can alter them or remove them early, for as long as your regulators or customers expect. Logs that the people being logged can edit are weak evidence.
  • Shared responsibility. The provider protects the data centres, hardware and base services, while you protect your identities, data, settings and code. Each provider publishes a shared-responsibility description. Read it for every service you use, and record who owns each control.
  • Standards to measure against. Use a recognised baseline such as the CIS Benchmarks, the NIST Cybersecurity Framework or ISO/IEC 27001 controls, plus each cloud's own well-architected guidance, so reviews and audits have a clear yardstick.
  • Data location and rules. Decide which regions you may use and block the rest with a policy. Data-protection laws such as the GDPR and India's DPDP Act, and sector regulators, can restrict where data, logs and backups are kept, so write the allowed regions into the foundation itself.
  • Cost control from day one. Tag every resource with an owner and a project, set budgets per account with alerts at 50, 80 and 100 per cent, and review the bill weekly in the first months.
A starting point, not a design review. This is a general pattern. Your documents, users, rules and budget decide the real design. Confirm features, limits, pricing and regions on each provider's own pages. CloudBrum is independent of AWS, Microsoft and Google.

Words used on this page

Services in this pattern that have changed

Cloud providers rename and retire services often. These affect the parts above. Checked on 23 October 2026.

  • AWS Shut down AWS Proton reached end of support on 7 October 2026 and its console and resources are no longer accessible; infrastructure it already deployed keeps running. AWS suggests CloudFormation Git sync as the replacement. Details
  • Google Cloud Shut down Google Cloud Deployment Manager support ended on 31 March 2026. Existing resources keep working but can no longer be managed with it. Google points to Infrastructure Manager (or Terraform) instead. Details

Sources and further reading

Check details such as features, limits, prices and regions in the providers' own documentation.

Announcements about the changed services above

Frequently asked questions

What is a cloud landing zone?

A landing zone is a prepared, secure base in the cloud where workloads can be placed. It sets up accounts, identity, networking, logging, policies and budgets in advance, so every new project starts with the same safe defaults instead of its own ad hoc setup.

Why use several cloud accounts, subscriptions or projects?

Separate accounts contain mistakes and breaches, let you give each team its own limits and budget, and make bills and permissions easier to read. Production, other environments and shared services such as logging usually live apart.

What is the shared responsibility model?

The cloud provider secures the underlying infrastructure, such as data centres, hardware and the base services. You secure what you build on it: identities, data, configuration, network rules and applications. Where the line sits shifts with the service, so check each one.

How long does it take to set up a secure foundation?

A basic foundation with accounts, sign-in, logging and budgets can be ready in days using the provider's starter. A tailored one with a hub network, policies, regulated workloads and review by security staff usually takes several weeks. Allow time for decisions as well as setup.

Do I need a landing zone for a small project?

A small project still benefits from the basics: a separate account, multi-factor sign-in, an audit log and a budget alert. A full multi-account design can wait until you have several teams, regulated data or enough workloads to justify it.

Want this reviewed for your case?

CloudBrum architects can adapt this pattern to your documents, users, rules and budget, and estimate the cost. Nothing is sent until you choose.

Building something else?

Describe it in plain words and get matching services on all three clouds.

Service suggester → Cloud consulting →