Why teams choose AWS, and what it really asks of you
AWS is the cloud with the widest range of managed services, the largest hiring pool and the most third-party tooling built around it. That breadth is the reason most startups and scale-ups land there. It is also the catch: with several hundred services and a permissions model that can express almost anything, a poorly structured AWS account becomes expensive and risky quickly.
Our AWS consulting is about getting the foundations right once, so every later decision is easier. That means account structure, identity, networking, logging and cost ownership first, workloads second. If you are earlier in the journey, our cloud migration service covers moving from a single server or another host into that structure.
Landing zone and account structure
The strongest isolation boundary in AWS is the account, not the VPC or the security group. A compromised credential or a runaway script is contained by the account it lives in. We therefore design an AWS Organization with a small, deliberate set of accounts and apply service control policies at the organisational unit level.
A typical starting layout for a growing product company:
| Account | Purpose |
|---|---|
| Management | Billing and organisation administration only, no workloads |
| Security and logging | Central CloudTrail, Config and detection findings, read access for auditors |
| Shared services | CI runners, container registries, shared DNS |
| Production | Customer-facing workloads |
| Non-production | Staging and development, with tighter budgets |
Service control policies then set the outer limits: deny disabling logging, deny leaving approved regions, deny creating IAM users where single sign-on is the standard. These guardrails are cheap to write and remove entire classes of incident.
Everything in code
We provision the organisation, accounts, networking and baseline policies with Terraform, using separate state per account and a pipeline that plans on pull request and applies on merge. If your estate was built in the console, the path from ClickOps to Terraform is one we have walked many times: inventory, import, verify a clean plan, then lock down console changes.
Identity: the real perimeter
Most serious AWS incidents start with a credential, not a network exploit. Our baseline is:
- Human access through IAM Identity Center federated with your identity provider, with roles per account and no long-lived keys on laptops.
- Compute access through IAM roles (instance profiles, task roles, and IRSA or Pod Identity on Kubernetes), never embedded keys.
- Permission boundaries and service control policies so that even an over-generous role cannot exceed agreed limits.
- Access Analyzer reviews to find unused permissions and unintended external access.
A least-privilege policy scoped to a single bucket prefix looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:PutObject"],
"Resource": "arn:aws:s3:::example-app-uploads/tenant-data/*"
}
]
}
Writing policies this narrowly takes more effort than attaching a managed administrator policy. It is also the difference between a leaked token reading one prefix and a leaked token reading everything.
Networking that does not need rework in a year
VPC design is hard to change once workloads depend on it, so we plan address space before building. We allocate non-overlapping ranges per environment, leave room for growth and for peering or transit connectivity, and split subnets into public, private and data tiers across at least two availability zones.
Practical decisions we make early:
- Workloads sit in private subnets; only load balancers face the internet.
- VPC endpoints for S3 and other heavily used services, which improves security and reduces NAT gateway data charges.
- A deliberate egress design, because NAT gateway processing is a classic hidden cost.
- Security groups referenced by other security groups rather than wide CIDR ranges.
Cost control
AWS costs are rarely mysterious once they are attributed. We enforce a small tag standard (environment, team, service) in Terraform, enable cost allocation tags, set budgets per account and turn on anomaly detection with a named owner for every alert. Only after waste is removed and workloads are right-sized do we model savings plans against the steady baseline. Our EKS cost guide goes deeper for Kubernetes-heavy estates, and the EKS cost calculator gives a quick starting estimate.
Managed services we lean on
We prefer services AWS operates over software we have to patch: RDS or Aurora for relational data, S3 for object storage, SQS and SNS for messaging, ECS or Amazon EKS for containers, and KMS for key management. The trade-off is less low-level control and some lock-in. For most teams, that is a good exchange. Where portability matters, we keep the application portable and let the platform around it be AWS-specific.
Common failure modes
- One big account. Everything shares a blast radius and a bill. Split early.
- Console changes. Drift accumulates and nobody knows what is real. Move to code.
- Unreviewed security groups. Open ports added “temporarily” that stay for years.
- Untested backups. A snapshot you have never restored is a hope, not a backup. Our backup and disaster recovery service includes regular restore tests.
- Surprise data transfer. Cross-region and NAT egress charges appear only after launch.
When AWS is not the right choice
Be wary of AWS if your organisation is deeply tied to Microsoft licensing and Entra ID, where Microsoft Azure integrates more naturally, or if your product is dominated by analytics and machine learning pipelines where Google Cloud can be a better fit. A very small team with a simple app may also be better on a platform as a service until it outgrows it.
If you would like a second opinion on your AWS setup, book a consultation or see how we work.
Official documentation: aws.amazon.com