AWS, built as code and run like a product.
AI-native AWS engineers for landing zones, migrations, serverless and container platforms, data pipelines and cost control — Terraform-managed, observable, and handed over with the runbook.
- Terraform
- EKS
- Lambda
- Aurora PostgreSQL
- S3
- SQS
AWS is often the cloud a client already has.
AWS is often the cloud a client already has an account on, and the one with the deepest catalogue: a managed service for almost every component we would otherwise run ourselves. That breadth is the point and the danger. Used well, an AWS estate is a handful of well-chosen services — EKS or ECS, RDS for PostgreSQL, S3, SQS, a queue-driven Lambda or two — described entirely in Terraform. Used badly, it is two hundred resources nobody can name, a bill nobody can explain, and an IAM policy with a star in it.
We build the first kind. Our own products run on cloud infrastructure managed as code, and the same discipline goes into client accounts: a landing zone with organisations and SCPs, workloads in private subnets, identity through IAM Identity Center, everything observable, everything reproducible from a repository. The service we run under it is DevOps & Cloud; the move onto it is Cloud Migration.
When we don’t: an organisation with a Microsoft 365 estate, Entra ID and an existing enterprise agreement usually gets more from Azure; analytics-heavy teams who live in BigQuery are often better served on Google Cloud; and a small web product with no compliance burden can ship on Vercel and a managed Postgres without a cloud account at all. We are experienced across all three majors and financially neutral, so the recommendation follows your constraints, not ours.
Six things we ship on AWS.
Landing zones and account structure
AWS Organizations with separate accounts per environment and workload, service control policies, centralised logging, IAM Identity Center for people and roles for machines — the foundation every later decision rests on.
Container platforms on EKS and ECS
Managed Kubernetes with Karpenter for node provisioning, ArgoCD for deployments and IRSA so pods get exactly the permissions they need. ECS Fargate where a cluster is more platform than the team wants.
Serverless and event-driven back ends
Lambda, SQS, EventBridge and Step Functions for workloads that are spiky or asynchronous by nature — webhook ingestion, document processing, scheduled settlement runs — with idempotent handlers and dead-letter queues from the first commit.
Data platforms
RDS and Aurora for PostgreSQL, S3 as the lake, Glue and Athena or Redshift for the warehouse, MSK when Kafka is the backbone — the Data Engineering stack, managed.
Migrations from data centres
Database Migration Service for the schema and the ongoing replication, Application Migration Service for the servers that must move as they are, and a cutover plan rehearsed before the weekend it happens on.
AI workloads
Bedrock for managed model access inside your account boundary, SageMaker for training and hosting, and the retrieval, evaluation and guardrail layers from our AI & Machine Learning practice around them.
When to choose it.
Choose AWS when you need the widest set of managed services behind one identity and billing boundary, when your engineers already know it, or when a partner, marketplace or regulator expects it. It fits event-driven systems particularly well — SQS, EventBridge, Lambda and Kinesis are mature, cheap at low volume and predictable at high volume. It also fits organisations planning to run many workloads, because the account-per-workload model isolates blast radius and cost in a way a single subscription rarely does.
Look elsewhere when your identity, licensing and collaboration estate is Microsoft end to end — Azure’s integration with Entra ID and the Windows workloads you already own can save money and friction. Look elsewhere too when the product is a single web application with modest scale: a cloud account brings a landing zone, IAM and a networking layer that a small team does not need yet. We will say so before you sign anything.
A Postgres instance that is private, encrypted and backed up by default.
module "orders_db" {
source = "./modules/rds-postgres"
identifier = "orders-${var.env}"
engine_version = "16.3"
instance_class = var.env == "prod" ? "db.r7g.large" : "db.t4g.medium"
# Private subnets only; the app reaches it through a security-group rule, never the internet
subnet_ids = module.vpc.private_subnet_ids
kms_key_arn = aws_kms_key.data.arn
multi_az = var.env == "prod"
+ backup_retention_days = 35
+ deletion_protection = var.env == "prod"
tags = local.tags
}A typical Odeontech workload account on AWS.
What the AWS estates we hand over have.
- Everything in Terraform. No resource created in the console survives the next apply. Plans are reviewed in pull requests and applied by a pipeline, not a laptop.
- Least-privilege IAM as code. Roles per workload, permission boundaries, no long-lived access keys, and IAM Access Analyzer findings treated as build failures.
- Private by default. Databases, caches and clusters in private subnets; VPC endpoints for S3 and the AWS APIs; one deliberate ingress path through the load balancer and WAF.
- Encryption with keys you control. KMS customer-managed keys for data stores and backups, with rotation on and key policies reviewed like any other access rule.
- Observability wired in. CloudWatch and OpenTelemetry feeding Grafana dashboards, SLO-based alerts for the symptoms users feel, and CloudTrail plus Config in a log-archive account nobody can edit.
- Backups that have been restored. Retention set per data class, cross-region copies for the systems that need them, and a restore rehearsed and timed before go-live.
- Cost as a design input. Tagging enforced by policy, budgets with alerts per account, Graviton and Savings Plans where the workload is steady, spot where it is safe.
- Residency decided early. Region choice, replication scope and access paths documented for KVKK and GDPR before the first resource exists, not after the audit.
What usually ships alongside the infrastructure.
- A Terraform repository per landing zone and per workload, with modules, environments and a documented promotion path
- An account map: which account holds what, who can assume which role, and where the logs go
- CI/CD pipelines that plan, scan, apply and deploy — with rollback tested, not assumed
- Grafana dashboards and alert policies for the four golden signals, exported as code
- A cost baseline with tags, budgets and a rightsizing register reviewed regularly, at a rhythm agreed with you
- Runbooks for deploy, rollback, failover, restore and the incidents we rehearsed together
Frequently asked questions
Neighbouring stacks and the services that use them.
An AWS estate to build, move or tidy.
Tell us what runs where and what keeps you up at night. An AWS engineer reads it and replies in writing with how we would approach it.