For teams choosing AWS services faster than they chose an account structure
AWS Cloud
AWS rewards a deliberate account structure and punishes an improvised one, usually months later in a bill nobody can explain. This practice designs the account boundary, picks services against your actual workload rather than the newest announcement, and builds the cost visibility a growing footprint needs from day one.
How an AWS account decision actually gets made
Account structure, service trade-offs and the cost discipline a growing footprint needs.
90 secSample frame · video pending01Before any account exists
Multi-account AWS is a structure, not a checkbox
A single AWS account is simple until three teams share it and nobody can isolate a mistake. Four questions decide how many accounts the workload actually needs.
How many teams touch this workload directly?
A single team can often stay in one well-governed account. Multiple teams sharing an account eventually collide over limits or billing.
Does compliance require workload isolation?
Some regulatory duties require a workload's blast radius to stop at an account boundary. That decides the account count before cost enters the conversation.
Which AWS service fits the actual workload shape?
Lambda suits short, event-driven work. ECS and EKS suit long-running services needing more control. Aurora suits relational data; DynamoDB suits key-based access.
What does current spend already commit you to?
Existing reserved instances change which services are cheapest today. A rebuild that ignores committed spend can raise cost while lowering complexity.
| Amazon ECS | Amazon EKS | |
|---|---|---|
| Control model | AWS-native scheduler | Full Kubernetes API |
| Operational load | Lower, less to run yourself | Higher, cluster upgrades are yours |
| Team fit | Teams new to containers | Teams that already run Kubernetes |
| Portability | AWS-specific by design | Portable to other Kubernetes clusters |
| Best for | A fast start on AWS | Multi-cloud or Kubernetes-native teams |
02Agreed before build starts
The ledger that keeps AWS work honest
Every AWS engagement fixes what you bring, what changes, what returns, and what never moves out of your control regardless of the account shape chosen.
- Your side
You bring
- Every AWS account currently in use across teams
- Any compliance duties the accounts need to satisfy
- Budget range and the timeline for consolidation
- Our side
We build
- An AWS Organizations structure with governed guardrails
- Landing zone accounts split by environment and workload
- Centralised billing, logging and identity across accounts
- Your side
You receive
- A documented account structure your team can extend
- Service control policies enforcing the guardrails agreed
- A migration path for existing workloads into the structure
Never leaves you
- The AWS billing relationship and contract terms
- Final approval over every guardrail and policy
- Ownership of every workload inside every account
Where the line sitsWe design the account boundary. The AWS relationship and the final say on every guardrail stay with you.
03From account model to first workload
Four stages, each closing on something you can inspect
AWS engagements drift when account decisions get made informally mid-build. Each stage below closes on an artefact you can inspect before the next one starts.
Model the account boundary
Environment split, guardrails and identity federation are chosen against your actual team structure, not a generic multi-account template.
An account structure with reasons attachedSelect services against real shape
Compute, data and networking choices are made against what each workload actually needs, not the newest AWS announcement.
Services matched to the workloadMove or build in ordered waves
Each wave carries its own rollback plan and runs against a dependency order set before any workload moves.
A tested migration or build sequenceHand over the operating model
Runbooks, cost dashboards and the account provisioning path move to your team, so growth after handover does not require calling us.
A system your team can operate
04What actually drives the number
Four drivers, not a flat rate card
AWS work is priced against the assessment, not a template, because these four factors change effort by multiples.
Number of accounts already in play
A single-account cleanup is faster than reconciling a dozen ungoverned accounts built by different teams over several years.
Service selection complexity
A lift-and-shift onto EC2 costs less to plan than a redesign across managed services and event-driven compute.
Migration risk and downtime tolerance
Workloads that cannot tolerate downtime need a more careful sequence, and that sequencing work is where effort concentrates.
Cost visibility already in place
Accounts with no tagging discipline need that built before a savings review can point at real owners at all.
05Evidence and proof
Accounts and bills that finally made sense.
AWS proof here is a governed account structure and a bill someone can explain, not a migration count. Every record waits for written client approval before production.
Explore case studiesTwelve ungoverned AWS accounts became one governed structure.
Nexa Foundry had a separate AWS account per factory line with no shared guardrails. A landing zone redesign brought every account under one governed structure without halting production systems.
- Accounts brought under governance
- 12
- Production incidents during rollout
- Zero
A weekend migration cut over without a customer noticing.
Aster North needed its production platform on AWS ahead of a contract renewal. A staged migration moved every workload in one weekend with a tested rollback held in reserve.
- Migration downtime
- Under one hour
- Rollback invoked
- Never
They mapped our AWS bill to actual teams before touching a single resource. The number finally meant something to our board.
Sample · pending client approval
06Read this first
When AWS engineering is the wrong spend
Paying for a multi-account redesign when one team runs one simple workload would cost more than it returns. The exits are marked before the pitch. When the work is justified, it runs against AWS Organizations, IAM, EC2, ECS, EKS, RDS and the Cost Explorer tooling underneath.
You run one workload for one team
A single well-governed account may already cover it. Multi-account structure solves a scale problem many teams have not reached yet.
- Kubernetes practice
You need the platform, not just one cloud
When workload portability across providers matters more than AWS-specific depth, a platform-agnostic route fits better than an AWS-only build.
- Hire AWS Developers
Your own engineers already run AWS well
If your team already owns AWS architecture and just needs more hands, hiring AWS developers fits better than adding a delivery layer.
| Shape | Best when | You direct | We carry |
|---|---|---|---|
| Scoped build | The account model is settled | Priorities and workload order | Migration or build delivery |
| Delivery pod | The model will evolve with learning | Product decisions each cycle | Engineering, quality, releases |
| Team extension | Your leads already run AWS well | Architecture and standards | Named engineers and continuity |
07Straight answers
Asked before an AWS budget gets approved.
01How is this different from a general cloud migration service?
This practice engineers around AWS specifically: Organizations structure, IAM boundaries and the trade-offs unique to compute, storage and data on AWS. A platform-agnostic migration service treats every cloud the same, which misses AWS-specific cost and account tools.
02Do you help choose between EC2, ECS, EKS and Lambda?
Yes, weighed against your workload's traffic pattern, team skill and operational appetite rather than a default preference. Serverless suits event-driven work; containers suit long-running services; EC2 suits workloads needing full control.
03How do you structure AWS Organizations for a growing company?
Typically by environment and business unit, with guardrails enforced through service control policies rather than trust. The exact split depends on compliance duties and how many teams need an isolated blast radius.
04Can you take over an AWS account another vendor set up?
Yes, starting with an account and cost review rather than a rebuild pitch. Many inherited AWS accounts need governance and tagging fixes, not a full redesign from scratch.
05What does AWS consulting cost?
Scoped engagements are priced against account count, service complexity and migration risk identified during assessment. Delivery afterward runs as a monthly team commitment matched to your roadmap.
06Do you also size Reserved Instances and Savings Plans?
We size the commitment against your actual usage pattern and hand over the reasoning, though the purchase and its renewal stay a decision your finance team makes.
07Will this work stop us from also using Azure or GCP?
No. Account and service structure on AWS does not prevent a future multi-cloud decision, though depth on one provider before splitting workloads across several is usually the safer order.