AWS Cloud Development

Infrastructure as code, deployed without a single long-lived key.

We run client platforms on AWS the way we would want ours run: every resource defined in Terraform, every environment in its own isolated account, and every deploy authenticated through GitHub OIDC so there is no long-lived access key to leak.

The commercial case is usually simpler than the technical one. On the DCSA portal, re-engineering the deployment environment and right-sizing resources cut AWS costs by 60% with no loss of performance or uptime.

What we build with AWS

Terraform module catalogue

A reusable internal module library standardising ECS services, ALB, WAF, SSL, alerting, schedulers and database provisioning across every client platform.

Multi-account isolation

Dev, staging and production each with their own account-level networking, cluster, state and trust relationships — composed from the same modules.

Keyless CI deploys

GitHub Actions assumes per-environment roles via OIDC. No static credentials in CI, which is one fewer thing an audit can find.

Containers and serverless

ECS and Fargate for long-running services, Lambda for transcoding and transcription workloads, API Gateway in front of both.

Cost engineering

Right-sizing, environment scheduling and deployment re-engineering treated as ongoing work rather than a one-off exercise at launch.

AWS CDK where it fits

TypeScript CDK stacks for teams already living in TypeScript, deployed alongside the application in the same repository.

What is actually in our AWS projects

Not a wish list. Every library below is running in a repository we maintain.

Compute

  • ECS
  • Fargate
  • Lambda
  • API Gateway
  • AWS Amplify

Data

  • RDS
  • Aurora
  • S3
  • SQS
  • DynamoDB
  • Amazon Transcribe

Network & edge

  • VPC
  • ALB
  • WAF
  • CloudFront
  • Route 53
  • ACM

Security & config

  • IAM / OIDC
  • Secrets Manager
  • SSM Parameter Store
  • KMS

Infrastructure as code

  • Terraform
  • AWS CDK
  • devenv / Nix
  • Docker
  • ECR

Operations

  • GitHub Actions
  • CloudWatch
  • Slack alerting
  • Sentry
  • Bugsnag

How we work in AWS

Choosing the stack is the easy part. These are the decisions that determine whether the codebase is still maintainable after we hand it over — and they are the same on every AWS project we run.

Our certifications
  • Terraform state is held per environment and per account, so a production apply cannot reach a staging resource by accident.

  • Deploy roles are assumed through GitHub OIDC rather than stored as secrets, which removes the most commonly exploited credential in a CI pipeline.

  • Reproducible developer shells via devenv and Nix mean an engineer's local Terraform matches CI's exactly, down to the provider version.

  • ECS cluster modules ship with Slack alerting wired in, so an unhealthy service reaches a human without anyone remembering to configure it.

  • This site runs on the same pattern — S3, CloudFront and Lambda defined in AWS CDK — which is how we keep our own dogfood honest.

Looking for the service rather than the stack?

AWS is how we build. If you would rather start from what you need delivered, our bespoke software development page covers scope, process and engagement.

Bespoke Software Development

Building on AWS?

Tell us what you are building — or what you have inherited. We will come back with a straight answer on scope and approach.

Get in Touch