Service

Cloud infrastructure setup and management on AWS, Azure and GCP

Architecture, provisioning and ongoing management of AWS, Azure and GCP environments, defined entirely as code.

Most cloud spend is wasted on infrastructure nobody fully understands. We design environments you can reason about: every resource declared in Terraform, every environment reproducible from an empty account, and a written handover so your team is never dependent on us to make a change.

What the engagement covers

Landing zone and account structure

Multi-account or multi-subscription layout with isolated environments, centralised identity, and guardrails applied through policy rather than convention.

Infrastructure as code

Terraform modules under version control, with plan output reviewed on pull requests. No click-ops, and no configuration that exists only in someone's memory.

Networking and access

VPC and subnet design, private connectivity to managed services, and least-privilege IAM rather than broad wildcard roles.

Cost visibility

Tagging strategy, budget alerts, and right-sizing review — so the bill is explainable line by line before it surprises you.

Observability

Metrics, structured logs and traces wired up from the start, with alerts that map to user-visible symptoms instead of raw resource thresholds.

Ongoing management

Patching, upgrades, incident response and capacity review on a retainer, or a clean handover to your team. Both are legitimate outcomes.

Tools we work with

Not an exhaustive list, and not a claim of certification — just what we reach for most often on this kind of work.

  • AWS
  • Azure
  • Google Cloud
  • Terraform
  • Pulumi
  • CloudFormation
  • Prometheus
  • Grafana
  • OpenTelemetry

Common questions

Do you work with an existing cloud account, or only greenfield?
Both. For existing accounts we start with a review of what is running, what it costs and where the risks are, then import resources into code incrementally rather than rebuilding everything at once.
Will we be locked into you afterwards?
No. Everything is delivered as code in your repository, in your cloud account, with documentation. Ongoing management is an option you choose, not a dependency we engineer in.
Which cloud should we use?
Usually the one your team already knows. We will tell you if a workload has a clear technical reason to sit elsewhere, but migrating for its own sake rarely pays for itself.

Talk to us about cloud infrastructure

Send over what you are dealing with. We will reply with a straight assessment of whether we are the right team for it.