Cloud, DevOps & SRE
Infrastructure you could rebuild from an empty account
We build AWS estates defined entirely in code, delivered through pipelines nobody has to babysit, and measured against SLOs with real error budgets. Then we hand over the runbooks, the cost baseline and a timed restore drill that proves the backups work.
Engagement at a glance
- Capabilities
- 05
- Deliverables
- 08 artefacts
- Stack groups
- 04
- Ways to start
- 03
Engagement options
- Infrastructure and cost audit2 weeks
- Platform build8–14 weeks
- SRE partnership6–12 months, retained
What breaks
The failure modes we keep meeting
Cheap to design around at the start. Expensive to discover once the system is carrying real traffic.
The console became the source of truth
Someone widens a security group during an incident and never commits it. A support engineer bumps a Lambda’s memory. Six months later the plan output proposes forty changes nobody can explain, so nobody applies it. The estate is no longer reproducible — and the orphaned resources from that period never stop billing.
Staging is a scale model, not a rehearsal
Staging runs one small instance against a single-AZ Postgres with 2 GB of scrubbed data. Production runs Aurora with 400 GB and real concurrency. Connection-pool exhaustion, lock contention, cold-start storms and IOPS credit burn are structurally invisible until the release that meets live traffic.
Green dashboards, unrehearsed recovery
Two hundred alarms, thirty of them chronically firing, and an on-call channel everyone has muted. The nightly backup has been green for three years and has never once been restored. Autoscaling thresholds were guessed during a launch two years ago. The first honest load test is the incident.
Capabilities
What the work actually consists of
01
Landing zone and infrastructure as code
One tool, one state strategy, no console write access in production. Existing hand-built resources get imported rather than ignored, because an IaC repository that only covers the new things is a second source of truth.
- Multi-account landing zone on AWS Organizations and Control Tower — workload separation by environment and blast radius, with SCPs denying what the guardrails cannot.
- Import of existing click-ops resources into state (terraform import, or cdk import backed by CloudFormation resource import) and a deliberate campaign to drive drift to zero before anything new is built.
- Versioned, reusable constructs or modules — VPC, ECS service, Aurora cluster, static site — so a new service is a fifty-line stack rather than a copy-paste.
- Secrets in Secrets Manager or SSM Parameter Store with rotation, referenced by ARN at task start — never a plaintext value in a repository, an AMI or a console form.
- Drift detection and policy-as-code in CI (cfn-guard, Checkov, OPA) failing the plan stage, not surfacing in a quarterly audit.
02
Runtime architecture chosen on merit
Containers or serverless is a workload question, not an identity. The right answer usually depends on traffic shape, state, and how much control plane the team can genuinely afford to operate.
- ECS on Fargate for steady request/response services; EKS with Karpenter where the Kubernetes API itself is load-bearing — operators, CRDs, custom scheduling.
- Lambda for spiky and event-driven paths, with provisioned concurrency or SnapStart only where p99 cold starts actually reach a user.
- Graviton (arm64) as the default family, with multi-arch images via buildx — the cheapest performance change most estates have available.
- Autoscaling policies derived from Container Insights percentiles and measured queue depth, with scale-in cooldowns tuned against real traffic shape rather than defaults.
- Network design that costs what you expect: VPC endpoints for S3 and DynamoDB, AZ-aware placement, and an explicit look at cross-AZ and NAT Gateway transfer before it appears on the bill.
03
Delivery with a bounded blast radius
A deploy should be a non-event. That means the pipeline decides to roll back on signal, the schema change survives a code rollback, and nothing in CI holds a credential that outlives the job.
- GitHub Actions or CodePipeline federated to IAM via OIDC — no long-lived access keys in CI secrets, anywhere, including the one somebody added for a hotfix.
- Canary or linear rollouts through CodeDeploy or the ECS deployment circuit breaker, with rollback triggered by SLO burn rate instead of a human watching a graph.
- Expand/contract database migrations, so rolling back code never requires rolling back schema — the failure mode that turns a five-minute incident into a four-hour one.
- Ephemeral preview environments per pull request, provisioned from the same modules as production and destroyed on merge.
- Supply-chain controls: immutable image digests, Trivy scanning, SBOM generation and signature verification gating the deploy step.
04
Observability, SLOs and incident response
Alerting on CPU tells you a machine is busy. Alerting on error-budget burn tells you a user is suffering. We instrument for the second, and delete most of the first.
- OpenTelemetry instrumentation through the ADOT collector — traces, metrics and logs correlated by trace ID rather than joined by timestamp guesswork.
- SLIs defined from user-visible behaviour (availability, p99 latency, data freshness), SLOs agreed with the business, and multi-window multi-burn-rate alerts that page for the right reasons.
- Log tiering as a cost decision: hot in CloudWatch for the retention that supports on-call, cold in S3 with Athena over it — log spend is routinely the second-largest line item.
- Runbooks per alert class and a severity ladder with an incident commander role, so the first ten minutes are procedure rather than improvisation.
- Blameless postmortems with tracked action items, and a monthly review where chronically firing alarms are either fixed, re-thresholded or deleted.
05
Cost engineering and proven recovery
Surprise bills and surprise outages share a root cause: nobody measures the thing until it matters. Both are fixed the same way — make it visible, make it owned, then rehearse it.
- Tag policy enforced by SCP and AWS Config, so every line on the bill maps to a team, an environment and a service before any optimisation starts.
- Cost and Usage Report in Athena with unit-cost metrics — cost per order, per tenant, per thousand inferences — because a falling total can just mean falling traffic.
- Savings Plans and Reserved Instance coverage modelled against the committed baseline rather than the peak, with Spot and capacity-rebalance handling for interruptible pools.
- The unglamorous backlog that carries most of a first-pass saving: gp2 to gp3, S3 lifecycle and Intelligent-Tiering, idle NAT Gateways, orphaned EBS snapshots and forgotten dev environments.
- RPO and RTO documented per data store, then proven — a timed restore into an isolated account, on a schedule, with the measured number replacing the aspirational one.
Outcomes
Targets, and where each number comes from
The basis line under every figure is the point of this section. Where a number is a design standard rather than a measured delivery, it says so — we would rather be checkable than impressive.
- First-pass reduction in AWS spend on an untuned estate
- 15–30%First-pass reduction in AWS spend on an untuned estateTypical range for estates that have never had a structured FinOps pass — rightsizing, storage tiering, Graviton and transfer cleanup. Measured against your own Cost and Usage Report before and after, never assumed in advance.
- DORA deployment frequency and change lead time as the delivery target
- Elite bandDORA deployment frequency and change lead time as the delivery targetTarget defined against the public DORA / State of DevOps performance bands — on-demand deploys, lead time under a day. Stated as the target we design the pipeline to reach, not a measured claim.
- Error budget at a 99.9% availability SLO
- 43 min / monthError budget at a 99.9% availability SLOArithmetic, not a promise: 0.1% of a 30-day month. The tier is chosen with you — a higher target means multi-AZ becomes multi-region and the cost changes accordingly.
- Restore drills executed against real backups
- Quarterly, timedRestore drills executed against real backupsOperating practice we build into the engagement. The RTO that counts is the one the drill measures, not the one written in the continuity policy.
Stack
What we reach for, and when
Defaults, not dogma. The list below is what we would propose on a blank page; an existing estate, a procurement constraint or a team's operating experience all legitimately move it.
- AWS CDK (TypeScript)
- Terraform / OpenTofu
- CloudFormation
- AWS Organizations & Control Tower
- Service Control Policies
- cfn-guard
- Checkov
- Open Policy Agent
- ECS on Fargate
- EKS with Karpenter
- AWS Lambda (Graviton, SnapStart)
- Step Functions
- Aurora PostgreSQL
- DynamoDB
- ElastiCache for Valkey
- S3 and CloudFront
- GitHub Actions with OIDC
- CodePipeline / CodeBuild / CodeDeploy
- Argo CD
- Docker buildx
- Trivy
- Syft SBOM
- Sigstore cosign
- AWS Secrets Manager & SSM Parameter Store
- OpenTelemetry with the ADOT collector
- CloudWatch Application Signals & Container Insights
- AWS X-Ray
- Amazon Managed Grafana
- Amazon Managed Service for Prometheus
- Athena over the Cost and Usage Report
- AWS Backup & Resilience Hub
- PagerDuty or AWS Incident Manager
Deliverables
What you keep
Everything below lands in your repositories and your accounts, under your licence, with the reasoning written down. There is no runtime you have to keep renting from us.
08 artefacts, handed over
- An infrastructure repository that stands the whole environment up from an empty AWS account — organisation, network, workloads, DNS, certificates — with a documented bootstrap order.
- Multi-account structure with SCPs, an enforced tag policy, per-account budget alarms, and the IAM role and OIDC trust design that CI authenticates through.
- Per-service delivery pipelines with canary stages, automatic rollback on error-budget burn, and expand/contract migration steps wired into the release.
- An SLO catalogue: SLIs, targets, burn-rate alert rules committed as code, and the single dashboard per service that answers whether it is broken and since when.
- Runbooks for the highest-frequency alert classes — symptom, first check, blast-radius assessment, mitigation, escalation — written for a new joiner at 3am.
- An incident process: severity ladder, comms templates, on-call rota configuration, and a blameless postmortem template with action-item tracking.
- A cost baseline: CUR in Athena, unit-cost dashboards, and a savings backlog ranked by value against effort and reversibility.
- A DR document stating RPO and RTO per data store, with the recorded output and elapsed time of a restore drill run against a real backup.
Engagements
Three honest ways to start
Sized so the first one can end. Each option is designed to produce something usable even if we never work together again.
Infrastructure and cost audit
2 weeks
An estate that grew by hand and now surprises you — monthly on the bill, occasionally at 3am.
Includes
- Drift and inventory sweep across accounts and regions
- IAM, network and secrets review with the findings ranked by exploitability
- Cost and Usage Report analysis with a savings backlog scored by risk
- Resilience gap list: backups, restore evidence, single points of failure
- Prioritised remediation plan with effort estimates your team can execute alone
Platform build
8–14 weeks
Teams moving onto AWS, or rebuilding an estate that can no longer be reproduced from source.
Includes
- Landing zone, network and IaC repositories built with your engineers, not handed over at the end
- Two or three services migrated end to end onto the new pipeline as working proof
- Observability, SLOs and alerting wired to the services that matter
- Runbooks, incident process and the first timed restore drill
- Working sessions and code review with your team throughout, so ownership transfers as it is built
SRE partnership
6–12 months, retained
A live system that needs on-call discipline, error budgets and a cost curve managed while the product team ships features.
Includes
- Escalation cover on an agreed rota, alongside your own on-call
- Monthly SLO, incident and cost review with a written reliability backlog
- Incident response, postmortems and follow-through on action items
- Continuous platform work: upgrades, capacity, deprecations, security patching
- Quarterly DR drill and a refreshed savings model as commitments come up for renewal
Questions
The awkward ones
The questions that decide whether this is worth starting — answered the way we would answer them on a call.
Neither by default. Terraform or OpenTofu if you are multi-cloud, already carry modules, or your operators prefer declarative HCL. CDK if you are AWS-only and your team writes TypeScript daily, because the abstraction pays for itself. What actually matters is picking one, having a single state strategy, and removing console write access in production.
Adjacent work
These are the practices this one leans on and the reference architectures that show it assembled.
Related solutions
Reference architectures
Next step
Bring us the problem you keep deferring.
A 45-minute working session on your Cloud, DevOps & SRE work. We will tell you what we would build, what we would not build, and roughly what it costs. No deck.