Account strategy
One account per workload and environment, grouped into OUs.
Why. Limits blast radius, simplifies cost and IAM boundaries.
Trade-off. More accounts to bootstrap, so account vending must be automated.
Cloud platforms · AWS and Azure
Multi-account landing zone: AWS Organizations and Azure management groups
The foundation every other pattern sits on: separate accounts or subscriptions for blast-radius control, preventive guardrails, central identity, central logging and a security account that workloads cannot switch off.
A reference architecture from EITSAA, not a named client system. Service limits, prices and product features change, so confirm current details before you commit to a design.
- ACSC Essential Eight
- SA ISMF and ACSC ISM alignment
- IRAP-assessed region and services where required
- Sydney and Melbourne regions
Architecture
- Security and identity
- Request or data flow
- Asynchronous or optional
- Boundary: region, account, network or trust zone
Request and data flow
Staff are provisioned from the corporate IdP into IAM Identity Center by SCIM. Group membership, not individual IAM users, grants access.
A person signs in with MFA and assumes a permission set in a target account. The session is short-lived and every console and CLI action is attributed to them.
Service control policies set at the OU level deny actions no account should ever do, such as disabling CloudTrail, leaving the Organization or using non-approved Regions.
Every account sends CloudTrail, AWS Config and VPC Flow Logs to the log archive account. Workload administrators cannot modify the archive.
Security tooling aggregates GuardDuty, Security Hub and Inspector findings from all accounts and Regions to a delegated administrator account.
On Azure, management groups carry Azure Policy and RBAC down to subscriptions. Policy denies, audits or deploys-if-missing the baseline.
Defender for Cloud assesses posture and forwards signals to Microsoft Sentinel or the organisation's SIEM.
Components and why they were chosen
| Component | What it does | Why this choice |
|---|---|---|
| AWS Organizations | Account hierarchy, consolidated billing and policy attachment. | Accounts are the strongest isolation boundary in AWS. |
| AWS Control Tower | Opinionated landing zone, account factory and mandatory controls. | Faster than hand-built for most organisations. Customisations for Terraform (AFT) keep it in code. |
| Service control policies | Preventive guardrails that cap what accounts can do. | They apply even to account root users and cannot be removed by workload admins. |
| IAM Identity Center | Workforce SSO with permission sets across accounts. | No long-lived IAM users and one place to offboard staff. |
| CloudTrail, Config, Security Hub, GuardDuty | Audit, drift detection and threat detection. | Organisation-wide enablement from a delegated admin. |
| Azure management groups and Policy | Hierarchy for governance and baseline enforcement. | Follow the Azure Landing Zone (Cloud Adoption Framework) layout to stay supportable. |
| Microsoft Defender for Cloud and Sentinel | Posture management and SIEM. | Native to Azure and integrates with Microsoft 365 signals. |
| Terraform or Bicep with a pipeline | Accounts, baselines and policies as code. | Auditable, reviewable and repeatable. |
Design decisions and trade-offs
Guardrails
SCPs for hard denies, Config and Policy for detective controls.
Why. Prevent the catastrophic and detect the drift.
Trade-off. Over-tight SCPs block legitimate work. Roll out in audit mode first.
Regions
Allow ap-southeast-2 (Sydney) and optionally ap-southeast-4 (Melbourne), deny others by SCP, with us-east-1 exceptions for global services.
Why. Supports data residency and DR within Australia.
Trade-off. Some global services and CloudFront WAF need us-east-1, so exceptions are explicit.
Logging
Immutable central archive with Object Lock and a separate account.
Why. Evidence survives a compromised workload account.
Trade-off. Storage cost grows with retention.
Well-architected pillars
Security
Preventive SCPs, no IAM users, central logs, delegated security tooling and break-glass roles held offline.
Reliability
Account isolation contains failures. Landing zone itself is in code and can be rebuilt.
Performance
Hub-and-spoke or Transit Gateway for predictable network paths with inspection only where needed.
Cost optimisation
Tags and account-level billing make cost visible. Control Tower, Config and logging add baseline spend that should be budgeted.
Operational excellence
Account vending pipeline, drift detection, quarterly access review and a documented break-glass procedure.
Sustainability
Region choice, tagging for decommissioning and automated sandbox clean-up.
Network, identity and data
Networking
Transit Gateway (or Azure Virtual WAN or a hub VNet) connects spokes to shared services and on-premises over Direct Connect or ExpressRoute with a VPN backup. Egress and ingress inspection live in a dedicated networking account or hub subscription.
Identity and least privilege
One IdP, MFA enforced, SCIM groups to permission sets. Privileged permission sets need a shorter session and approval. The root users and management account are locked down with hardware MFA held by two named custodians.
Data and encryption
Account-level KMS keys and key policies stop cross-account misuse. Log archive buckets use SSE-KMS and Object Lock in compliance mode for the retention period required by policy.
Security and compliance mapping
| Control | How this design addresses it |
|---|---|
| Restrict administrative privileges | Permission sets with time limits, PIM on Azure, no standing admin. Essential Eight. |
| Multi-factor authentication | Enforced at the IdP for every sign-in. Essential Eight. |
| Regular backups | AWS Backup policies at the organisation level with a central vault. Essential Eight. |
| Logging and monitoring | Organisation CloudTrail, Config aggregation and Sentinel. Supports ISM event logging guidance. |
| Information security governance | Maps to ISMF policy expectations for SA Government suppliers. IRAP-assessed services should be verified for each service used. |
Mappings show how the design supports each control. They are not certifications, and EITSAA does not claim IRAP assessment or compliance for any reference architecture.
Failure modes, targets and scaling
- Target RTOHours to re-apply the baseline into a clean account from code
- Target RPONot data-bearing; logs are replicated or retained per policy
- Scaling and limitsAccount and OU quotas are high but raise them before bulk vending. Tens to hundreds of accounts are routine.
| Failure mode | Mitigation |
|---|---|
| SCP locks everyone out | Test in a sandbox OU, keep a break-glass path and use the management account only for SCP rollback. |
| Compromised workload account | Contained by account boundary, detected by GuardDuty, closed by revoking sessions and isolating through SCP. |
| IdP outage blocks access | Emergency break-glass IAM roles with hardware MFA and alerting on any use. |
| Region disabled by mistake | Region deny list reviewed in change control with exceptions for global services. |
Observability and runbooks
- Security Hub aggregated findings with severity routing to the on-call channel.
- Config conformance packs and Azure Policy compliance dashboards.
- Alerts for root login, SCP or trail changes, and break-glass use.
Cost drivers and levers
Config recorder items, CloudTrail data events, GuardDuty and Security Hub, log storage, Transit Gateway data processing.
- Record only needed resource types in Config.
- Use S3 lifecycle tiers on log archives.
- Limit data events to sensitive buckets.
- Share networking via Transit Gateway or Virtual WAN.
Implementation and fit
Phased approach
- Design the OU and subscription hierarchy and naming with the business.
- Deploy the baseline: identity, logging, security tooling and guardrails in audit mode.
- Vend a first workload account and migrate one workload.
- Enforce guardrails and automate vending.
Anti-patterns to avoid
- Everything in one account.
- IAM users with access keys.
- Admin access for the whole cloud team in every account.
- Security tooling in the same account as workloads.
When to use it
- Any organisation expecting more than one workload or team.
- Government suppliers and regulated industries.
- Teams starting a cloud journey.
When not to
- A single small static site (a standalone account with good hygiene is fine).
More in cloud platforms
AWS and Azure
CI/CD and infrastructure as code with GitHub Actions, Terraform, ECR and blue/green
A delivery pipeline with no long-lived credentials: pull requests plan, merges apply, images are scanned and signed, and releases shift traffic gradually with automatic rollback.
AWS and Microsoft
Data lake and BI with S3, Glue, Athena, Redshift and Power BI or QuickSight
A governed analytics platform: raw, curated and consumption layers on object storage, a catalogue with column-level access control and a semantic layer that business users can trust.
AWS and Azure
Disaster recovery: backup and restore, pilot light and warm standby
Choose recovery capability by business impact, not by habit. Three patterns with honest RTO and RPO, a cross-Region data path, an immutable backup vault and a failover that is rehearsed rather than hoped for.
Related insights
- Cloud cost control for SA councils and small businesses: a practical FinOps guide
- SA ISMF for ICT suppliers: what buyers expect in tenders
- Essential Eight for SA SMEs: what buyers expect when you bid for government ICT work
- A compliance standards map for SA SMEs supplying regulated entities
- CPS 234 information security for third-party, fintech and SaaS suppliers
Discuss this architecture
Tell us your systems, constraints and timeline. We reply within one business day, and the initial conversation is free.