Cloud

Cloud Architecture

Environments described in code, sized for the organisation you actually are

How this is usually engaged

Usually a design engagement of three to six weeks producing the architecture and the Terraform to stand it up, followed by build and migration scoped separately once the design is agreed. Availability and recovery commitments are agreed per engagement and written into the support agreement rather than quoted as a headline figure.

Start a project brief

Practice: Cloud & Infrastructure
Sectors: 4 served
Process: 5 stages
Standard: Built and tested to WCAG 2.2 AA

Cloud environments designed and defined as code, with network boundaries, identity, data durability and cost visibility settled before anything is running in production.

01What this solves

The problem this addresses

Most cloud estates are not designed; they accumulate. Somebody created a server by hand during a deadline, somebody else added a database from the console, credentials were pasted into an environment variable to get a demo working, and now nobody can say with confidence what is running, who can reach it, or what the monthly bill is paying for. The estate works until the person who built it is on holiday, or until an invoice arrives that nobody can explain line by line.

02Capabilities

What is included

Infrastructure as code

The whole environment expressed in Terraform with remote state and locking, so a change is a reviewable diff and a lost region or a corrupted account is a rebuild rather than an archaeology project.

Environment parity

Staging built from the same modules as production, differing in size and data rather than in shape. Where parity is deliberately broken — cost, licensing, third-party sandbox limits — we document exactly where, so nobody is surprised by a release that only fails in production.

Identity and secret management

Least-privilege roles, federated human access, and application secrets held in a managed store with a documented rotation procedure. If rotating a credential requires a person to remember six steps, it will not happen, so we automate it or make it a single command.

Network and data boundaries

Private subnets, controlled egress, and databases that are not reachable from the public internet. We define which services may talk to which, and enforce it in the network rather than in a convention people are asked to respect.

Backup, restore and recovery design

Automated backups with retention agreed against your obligations, plus a written restore procedure that we run at least once during the engagement. A backup nobody has restored is a hypothesis, not a safeguard.

Cost modelling and visibility

Resources tagged by environment and workload from day one, with budgets and anomaly alerts, so the bill can be read by service rather than as one number. We will also point out where a managed service costs less than the engineering time to avoid it.

03Use cases

Where this work usually starts

Consolidating an estate nobody fully mapped

Resources created by hand over several years across two or three accounts, with unclear ownership and a bill nobody can break down. We inventory what exists, bring it under code, and retire what turns out to be unused.

Professional Services

Moving off a single server

One machine that runs the application, the database, the cron jobs and the file storage, backed up to a disk in the same building. The move is about removing single points of failure without pretending you need nine regions.

Retail

Preparing for a due diligence or client security review

A buyer, insurer or enterprise customer is asking how access is controlled, where data lives and how it is recovered. Answering honestly usually requires the architecture to be documented and, in places, changed.

Finance

04Approach

How we approach it

We start from the workload and the data, not from a reference diagram. What has to be durable, what has to be private, what can be rebuilt from scratch in ten minutes, and what would end the business if it were lost. From there we define the environment in Terraform so it can be reviewed, versioned and recreated, keep staging and production parity deliberate rather than accidental, and put secrets in a managed secret store with rotation you can actually perform. Cost allocation tags go in at the start, because retrofitting them across a live estate is miserable work.

05Process

How the work runs

The order matters more than the ceremony. Stages overlap in practice, but none of them is skipped.

01
Discovery and inventory
What is running, what it depends on, what data it holds and which parts of it anyone still understands. Undocumented dependencies surface here or they surface during cutover.
02
Recovery objectives conversation
How much data you can afford to lose and how long you can afford to be down, decided by you with our input. These two numbers drive most of the cost, so they are agreed before the design, not after.
03
Architecture and cost design
The target environment with an estimated monthly run rate per component, so the design is chosen against a budget rather than presented to one.
04
Build in code
Terraform written and applied to a non-production account first, then promoted. Nothing reaches production through a console click.
05
Migration, restore test and handover
Cutover with a rollback path, a restore rehearsed against the new environment, and documentation your team can work from without us.

06Deliverables

What you receive

Everything below is handed over as part of the engagement. If you take the work elsewhere afterwards, the next team has what it needs.

Architecture documentEnvironments, data flows, trust boundaries and the reasoning behind each decision, including options rejected.
Terraform modules and repositoryVersioned, reviewed, with remote state and a documented bootstrap procedure.
Identity and access modelRoles, who holds them, and how production access is requested and recorded.
Backup and recovery runbookThe restore procedure, with the results of the restore we performed during the engagement.
Cost baseline and tagging scheme
Handover session and open risk register

07Technologies

What we use on this work

These entries are drawn from our managed technology directory, which records why each one is in our stack and what we reach for it for. Nothing outside this list is claimed for this service.

Data & Storage

PostgreSQL

Cloud Platforms

Amazon Web Services
Microsoft Azure
Google Cloud
Cloudflare

DevOps & Operations

Docker
Terraform

The full technology directory

Highlighted entries are used routinely on delivery work

08Security

How this is kept secure

Identity is the perimeter. Roles are scoped to the task rather than to the person, machine credentials are short-lived and issued by the platform instead of being long-lived keys in a file, and human access to production is separated from routine deployment access. Networks are private by default with explicit ingress, data is encrypted at rest and in transit, and every change to the estate arrives through a reviewed pull request so there is a history of who altered what and why.

Our full security and quality approach

09Questions

Asked before we start

Which cloud provider should we use?

Usually the one your team already knows, unless a specific requirement points elsewhere — data residency, an existing enterprise agreement, or a managed service that only one provider offers in a usable form. The differences between the major providers matter far less than whether the people maintaining the estate are comfortable in it. We work across AWS, Azure and Google Cloud and have no incentive to steer you.

Can you guarantee our uptime?

Not as a marketing number. Availability depends on the architecture you fund, the dependencies you cannot control and the response arrangement you buy, so any figure quoted before we understand those would be invented. We agree availability targets and recovery objectives with you during design and write them into the support agreement, where they mean something.

Is a cloud migration going to reduce our costs?

Sometimes, and often not immediately. Migrating a workload unchanged usually costs more than the server it left, because you are now paying for redundancy and managed services you did not previously have. The savings, where they appear, come from retiring unused capacity, right-sizing after real measurement, and no longer spending staff time on hardware. We will model this honestly before you commit, including the case where staying put is the better commercial decision.

Do we need multi-region or multi-cloud?

Almost certainly not, unless you have a regulatory requirement or a recovery objective measured in minutes that you are genuinely willing to fund. Both roughly double the operational surface, and the added complexity has caused more outages in our experience than the failures they defend against. If your recovery conversation lands somewhere less demanding, a single region with tested backups and a documented rebuild is the better engineering decision.

START HERE

Talk to us about Cloud Architecture

The project brief takes about five minutes and gives us enough to have a useful first conversation about Cloud Architecture rather than a generic one. If you would rather just ask a question, the short form is there for that.

Start a project Send a short message

We read every enquiry ourselves. If we are not the right fit, we will say so and tell you what to look for instead.