Cloud Engineering
AWS, GCP and Azure architecture, migrations, infrastructure as code, high availability and cost control.
The engagement usually opens with one question: if this server disappeared tonight, how long until it is back, and does anyone actually know? Where the answer depends on something a departed contractor configured by hand, that is what gets fixed first — before performance, before cost.
What the starting position usually looks like
A production server nobody wants to touch. Deployment by FTP or a script on someone's laptop. Staging that diverged from production years ago. Backups running, never restored from. Monitoring that alerts on disk space and nothing that correlates with what users experience. A cloud bill that grew steadily and that nobody can break down.
None of this is unusual, and it is rarely the result of incompetence. It is the accumulation of reasonable decisions made under deadline, with nobody owning the infrastructure long enough to consolidate them.
Infrastructure into code
The first substantial deliverable, and the one everything else depends on. Existing infrastructure gets imported into Terraform or CloudFormation, with remote state and locking, and separate workspaces or accounts per environment. Configuration moves into Ansible or immutable container images.
After this, recreating an environment is a command rather than an archaeology exercise, and every production change is reviewable in a pull request. It is unglamorous work and it is what makes everything after it safe to attempt.
Deployment that stops being an event
A pipeline running cheap checks first so trivial mistakes fail in a minute, promoting a single build artefact through environments rather than rebuilding per stage, with the pipeline definition living beside the code it deploys.
Rollback has to be real rather than theoretical, which mostly means handling database migrations with expand-and-contract — a schema supporting both old and new code, migrated, then cleaned up in a later release. Feature flags decouple deploying from releasing, turning a rollback into a configuration change.
Observability worth having
Structured logs with request correlation so a user journey can be followed across services. Metrics on user-visible health — error rate, latency percentiles, queue depth — rather than raw CPU. Alerts tied to symptoms, because an alert that fires with no clear action trains people to ignore alerts. Plus a runbook written by someone who has used it.
Disaster recovery, actually tested
Every DR engagement includes a real restore into a scratch environment, timed, with the gaps written down. This step reliably reveals at least one thing nobody expected — a missing credential, a dependency that was never in the backup, a restore that takes four hours when the agreed objective was one.
Cost
Reviewed alongside, because the same visibility that makes infrastructure reproducible makes the bill legible. Right-sizing against actual utilisation, storage lifecycle policies, shutting down non-production outside working hours, and tagging so spend can be attributed. On an environment never previously reviewed, a third off is a common result and rarely requires giving anything up.
Something similar in mind?
Client identities and confidential implementation details are intentionally omitted here. Happy to talk through the specifics of your situation directly.
Start a conversation