Multi-Cloud Consulting · Amazon Web Services
An AWS organisation that is governed before the first workload lands
We design the account structure, organisational units, service control policies and identity model for your AWS estate, and deliver them as Terraform in your repositories. Your platform team gets a foundation it can extend, audit and run without us.
The problem
Where this usually breaks down
Accounts created by ticket
Each new account arrives with whatever baseline its requester remembered. Logging, network ranges and access differ from one account to the next, and nobody can say which controls apply where.
Policies applied after the fact
Service control policies added to a live estate break workloads that grew up around their absence, so exceptions pile up and the policy set stops meaning what it says.
Shared logins and long-lived keys
Long-lived access keys and shared administrator logins are hard to revoke and harder to audit. Moving people to federated sign-in is simplest before more teams depend on the old way.
What we do
What we set up, and how each part works
We work in your repositories and through your change process, so everything we set up can be reviewed, run and changed by your engineers after we leave.
Organisational units that match accountability
We lay out the organisation root and organisational units around who owns security, shared infrastructure and each workload environment. A control or a budget then attaches to an OU once, not to every account.
Service control policies as code
We write service control policies and resource control policies in Terraform, test them against a sandbox OU, and attach them where they belong. Denying unused Regions, protecting the logging baseline and blocking root user actions are the usual starting set.
AWS Control Tower or a lighter alternative
Where AWS Control Tower fits, we set up its landing zone, the log archive and audit accounts, and the controls you select. Where it does not, we build the same baseline directly on AWS Organizations.
Account vending through a pipeline
New accounts are requested through a merge request, created by Terraform, and placed in the right OU with networking, logging and access already attached. The request itself becomes the record of who asked and why.
Federated access through AWS IAM Identity Center
We connect your identity provider to AWS IAM Identity Center, define permission sets per job role and retire long-lived keys. Access to every account is then granted, reviewed and removed in one place.
Central logging and shared networking
AWS CloudTrail and AWS Config are enabled across the organisation and write to a log archive account that workload teams cannot alter. A network account holds the transit gateway and traffic inspection, and shares subnets where that suits.
What you keep
What stays with your team when we finish
Everything is committed to your repositories or written into your documentation, under your access controls. Nothing depends on us to keep running.
Terraform for the whole foundation
Modules for the OU structure, policies, account baseline and networking, in your repository, with the plan reviewed on every merge request.
A policy register
Each service control policy with its purpose, the OUs it attaches to, how it is tested and who approves a change to it.
An account vending pipeline
The pipeline and request template that create, baseline and place a new account, so your team can issue accounts without us.
Runbooks and decision records
Written decisions on OU design, Region use and identity, plus runbooks for break-glass access, account closure and policy exceptions.
How we work
How an engagement runs, phase by phase
Each phase ends with something your team reviews and signs off before the next one starts. We work inside your change control, not around it.
01
Map the current estate
We inventory existing accounts, access paths, logging and network ranges, and agree with you which workloads come first. Accounts that already carry production traffic get a placement plan before any policy touches them.
02
Design the organisation
We agree the OU structure, the policy set, the identity model and whether AWS Control Tower fits, and write each decision down with the options we set aside and why.
03
Build and test in sandbox
The foundation is written in Terraform and applied first to a sandbox OU, where policies are tested against real workload patterns before they reach anything that matters.
04
Place accounts and hand over
Existing accounts move into their OUs in agreed batches, with your engineers making the changes alongside ours. By the end, your team runs the vending pipeline and owns every module.
Technology
The tools this work runs on
Each group says whether a tool appears in our published work, so you can tell what we have shown from what we offer.
Offered, not in published work
- AWS
- AWS Organizations
- AWS Control Tower
- AWS IAM Identity Center
- AWS CloudTrail
- AWS Config
- AWS Transit Gateway
- Terraform
Questions
What teams ask before we start
Do we have to use AWS Control Tower?
No. It suits many estates, because it sets up the log archive and audit accounts and a managed set of controls. Where its constraints get in the way, such as an existing organisation it would have to enrol, we build the same baseline directly on AWS Organizations with Terraform.
We already have a lot of accounts. Do we start again?
Rarely. Existing accounts are enrolled into the new OU structure in batches, starting with those carrying the least risk. Each batch is checked against the policies in a sandbox OU first, so a control never lands on a production account untested.
What access do you need to our AWS organisation?
Read access to the management account and member accounts for the assessment. For build work, we propose changes as Terraform merge requests, and your engineers approve and apply them through your pipeline, under your change control.
Who owns the foundation once you step back?
You do. The Terraform, the pipeline, the policy register and the runbooks live in your repositories from the first commit. Your engineers work on them with us throughout, so handover is a continuation rather than an event.
Related services
What teams often need alongside this
Azure landing zones
Azure landing zones in Terraform: management groups, policy at scale and a hub-and-spoke network that every subscription inherits.
On-premises and hybrid cloud
Private connectivity, one identity boundary and shared governance between your data centres and the cloud, with each side kept operable.
Infrastructure as code with Terraform
Terraform modules, a plan reviewed on every merge request, applies only from the pipeline, and drift reported before it becomes an incident.
Next step
Plan your AWS organisation with us
Tell us how your accounts are organised today and what is coming next. We will come back with the questions that shape the OU and policy design.