Cloud & Operations
Cloud Engineering Services
Cloud done well is invisible: it scales when it needs to, costs what it should, recovers from failure and passes an audit without a scramble. Cloud done badly is a monthly bill nobody can explain and an architecture one person understands. We build the former, on AWS, Azure and Google Cloud.
What Cloud Engineering means in practice
Who it’s for: Teams whose cloud bill, reliability or audit posture has become a problem the business can feel, and organisations building or migrating an environment they must live with for years.
A cloud environment should be able to answer four questions quickly and without a meeting. What is running here and why. Who can reach it. What does it cost, broken down by the things the business recognises. And what happens when part of it fails. Environments that cannot answer those questions are not unusual, they are the norm, and the reason is almost always the same: the infrastructure was created by hand, one console click at a time, over several years and several people, and no single artefact anywhere describes what exists. That is the problem we solve first, because every other improvement depends on it.
So our starting move is to make the environment legible. Everything is captured as code, typically Terraform or OpenTofu, so what exists is written down, reviewable in a pull request, reproducible in another account and recoverable if it is lost. Only then does improvement become safe: right-sizing without wondering what a resource was for, tightening access without breaking an undocumented dependency, adding failover to the things where an outage genuinely hurts, and wiring in the observability that turns "the site feels slow" into a specific answer in minutes. Legibility first is not a preference, it is the difference between engineering and guessing.
We work across AWS, Azure and Google Cloud: on greenfield architecture, on migrations off ageing infrastructure, and, most often, on environments that have grown past anyone’s understanding and now need taking in hand. The work covers account and landing-zone structure, networking, identity, data services, cost engineering, resilience and disaster recovery, and the observability platform underneath it all. The delivery side, pipelines and release strategy, is covered by our DevOps service; the two fit together, and we are careful not to sell you one when you needed the other.
What you get
- Your environment captured as infrastructure code with state managed properly, so every change is reviewed and every environment can be rebuilt rather than remembered
- A cost model naming the actual drivers, compute, storage, data transfer, logging and the managed services people forget, with tagging that attributes spend to teams or products
- Account, subscription and landing-zone structure with identity federated to your identity provider, and long-lived static credentials removed rather than rotated
- Network design where nothing is public that need not be, databases are private by default, and traffic paths are deliberate rather than inherited
- A resilience design matched to agreed recovery objectives, with backups and failover tested rather than assumed
- Observability as a platform: metrics, logs, traces, dashboards and alerting that pages on symptoms that matter, with retention sized so it does not become its own budget problem
What Cloud Engineering does for you
Change stops being frightening
The most expensive property of an undocumented cloud environment is not its bill, it is the paralysis. Nobody will touch the security group whose purpose is unclear, delete the instance that might be load-bearing, or resize the database in case something depends on the capacity. Work slows to the pace of the most cautious guess. Once the environment is defined as code and reviewed like code, a change becomes a plan you read before applying it, and the team gets its confidence back.
Spend becomes an engineering decision
Cloud cost is not a procurement problem, it is an architectural one, and it becomes controllable only when it is visible at the level of the thing causing it. Once a team can see that a particular service, environment or data flow owns a specific share of the bill, the conversation turns from cutting costs in the abstract to concrete decisions: this workload is oversized, this data belongs in a cheaper storage class, this traffic should never have crossed a chargeable boundary.
Recovery you have rehearsed rather than hoped for
Most organisations discover the state of their disaster recovery during a disaster, and what they find is that the backups were running but nobody had restored one, or that failover works for the database and not the queue, or that the runbook names a person who left. Agreeing recovery objectives, engineering to them and then testing them turns a document into a capability, and it tends to reveal at least one assumption that was never true.
Why teams choose us for Cloud Engineering
- You want an environment you can hand to any competent engineer, defined as code and documented, rather than an architecture living in one head and a set of console clicks.
- You want cost work done by engineers who quantify each change before making it, rather than a blanket recommendation to buy commitments that locks in yesterday’s architecture.
- You want resilience sized to what the business actually needs, with someone willing to tell you that the expensive multi-region design being proposed is not justified by your risk.
- You want everything in your own cloud accounts, billed directly to you at the provider’s prices, with no reseller margin and no dependency on us to keep it running.
What Cloud Engineering includes
The concrete pieces of work this covers, scoped to what your problem actually needs.
Infrastructure as code and environment rebuild
We define your infrastructure in Terraform or OpenTofu with proper state management, a sensible module structure and a plan you read before anything is applied. Where an environment already exists, we import it rather than rebuilding it underneath you, so the code and reality converge without a risky big-bang cutover, and drift becomes something you can detect instead of something you discover. The test we hold ourselves to is whether a whole environment can be stood up again from the definition, because an infrastructure repository that cannot recreate what it describes is documentation, not code.
Landing zones, accounts and identity
Structure decided early prevents a large class of later pain: separate accounts or subscriptions for production and non-production so a mistake in one cannot reach the other, guardrails applied centrally, and identity federated to your existing provider with role-based access and short-lived credentials. Continuous integration authenticates through workload identity federation instead of holding a permanent key in a secret store. Unglamorous work that pays out every time someone joins, leaves or gets audited.
Cost engineering and FinOps practice
We start with attribution, because a bill you cannot break down is a bill you cannot act on: a tagging standard enforced in code, and reporting that shows spend by product, environment and team. Then we go after the drivers in order of size. Right-sizing based on observed utilisation rather than the shape someone guessed at provisioning time. Storage lifecycle policies so cold data stops sitting in hot tiers. Cheaper processor families such as Graviton where the workload allows. And the quiet costs that rarely appear in a design review: cross-zone data transfer, NAT gateway traffic that private endpoints would avoid, idle load balancers, orphaned volumes and snapshots, and log ingestion that has become its own budget line. Commitment discounts come last, once the architecture is stable, because committing to a year of an oversized shape is an expensive way to feel efficient.
Resilience, backup and disaster recovery
Resilience engineering starts with a business conversation, not a technical one: for each critical service, how much downtime is genuinely tolerable and how much data loss is acceptable. Those two numbers, the recovery time and recovery point objectives, determine the design and stop it being decided by whoever is most anxious. From there we build to match, whether that is multi-zone redundancy with automated failover, warm standby, or a documented rebuild from code and backups for systems where a few hours is genuinely fine. Then we test it: restore the backup, fail the database over, run the procedure with the people who would be doing it at 2am, and fix what the rehearsal exposes.
Migration and modernisation
For a move to cloud or between clouds, we sequence rather than gamble. An application-by-application assessment establishes what should be rehosted as it is, what should be replatformed onto managed services, what should be rewritten and, importantly, what should be retired because nobody has used it in two years. Data migration and cutover get the most planning because they carry the most risk. We are also direct about the trap in a pure lift and shift: running the same machine shapes in a cloud with none of the elasticity is usually more expensive than the data centre it left, so it has to be a first step rather than the whole plan.
Observability and the operational platform
We build the layer that makes the environment legible while it is running: infrastructure and application metrics, structured logs that are searchable rather than merely stored, traces that show where a request spent its time, and dashboards aimed at the questions people ask during an incident. Alerting is tuned to symptoms a human should act on, because an alert nobody trusts is worse than no alert. We also size the observability itself, since ingestion at full verbosity can quietly become one of the larger lines on a cloud bill.
Where it fits
A bill that has outgrown its explanation
An organisation whose cloud spend has climbed steadily while usage has not, with no tagging, no attribution and a general sense that something in there is wasteful. We attribute the spend, name the top drivers in order, and work through them with each change quantified before and after. Typically a meaningful share turns out to be resources nobody uses, data transfer nobody designed for, and workloads sized for a peak that never occurred. The durable fix is the reporting that stops it recurring.
Inheriting an environment nobody documented
A team that has taken over infrastructure built by someone who has left, where changes are made carefully and slowly because nothing is understood well enough to be confident. We map it, capture it as code, remove what is genuinely unused, document the parts that must stay, and hand back an environment the team can change without holding its breath. The relief is usually less about the technology than about no longer needing one specific person to be available.
Preparing for an audit or a customer security review
An organisation facing a certification, a regulatory expectation or an enterprise customer’s due diligence, where the environment is probably fine but cannot demonstrate it. We make the controls explicit and evidenced: federated identity with roles, change control visible in reviewed infrastructure code, encryption and network posture defined in code, tested backups with records, and appropriate log retention. Evidence you can produce beats a control you believe you have.
Building a new environment properly the first time
A greenfield platform, or a business that has outgrown a single hand-built server. Here the value is in decisions taken before there is anything to unpick: account structure, network layout, identity, the data services, and how environments are created. It costs very little to get these right at the start and a great deal to change them once production depends on them, which is why this is the cheapest cloud engineering work anyone ever buys.
How we approach Cloud Engineering
We begin by mapping what you actually have, which is usually more than anyone expects and less coherent than the diagram in the wiki suggests. We inventory the running resources, trace how they connect, work out what each costs and what depends on it, and identify the orphans: load balancers with no targets, snapshots from a migration two years ago, the environment someone stood up for a proof of concept and never removed. That inventory is then encoded as infrastructure code, importing existing resources where sensible, so the environment stops being tribal knowledge and becomes something a team can review and change safely.
From that baseline we improve deliberately and in priority order, driven by what is actually hurting rather than by a generic best-practice checklist. If the pain is cost, we go after the largest drivers first and quantify each change before making it. If the pain is reliability, we work out where a failure would genuinely hurt the business and engineer for that specifically, then test it. If the pain is an approaching audit, we make the controls legible and evidenced. We change things incrementally, with a rollback path, because an environment people are already nervous about is not the place for a grand redesign.
How the engagement runs
We start with an assessment, and it is a real piece of work rather than a sales exercise. We inventory what is running, map the dependencies, break down the cost, review identity and network posture, and establish what the business actually needs from the environment in terms of availability, recovery and compliance. The output is a written picture of the current state and a prioritised plan: what to fix, in what order, with the reasoning and the expected effect of each item. Often that assessment is itself the most valuable deliverable, because it converts a vague unease about the cloud estate into a list somebody can act on.
Then we make it legible. Existing resources are brought under infrastructure code with state managed properly, structure is corrected where it is causing harm, and the obviously dead material is removed once we have confirmed it really is dead. This phase is deliberately conservative: we are not redesigning anything yet, we are establishing a reviewable baseline, because changes made to an environment nobody can describe are how outages happen.
With the baseline in place we work through the prioritised improvements incrementally. Cost changes are quantified before and measured after. Resilience work is agreed against explicit recovery objectives and then rehearsed. Security and access changes are staged so that tightening permissions does not take out an undocumented dependency at an inconvenient moment. Observability goes in early, because it is what tells us whether each change did what it was supposed to do. Each step is small enough to reverse.
What a well-built cloud environment looks like
It is defined as code, and that is the load-bearing property rather than a stylistic preference. Every resource exists because something in a repository says it should, changes go through review, and environments are created from the same definitions with different parameters rather than being assembled by hand and drifting apart. Manual changes in a console are treated as incidents to reconcile, not as normal operations. This is what makes an environment reproducible, auditable and safe to change, and it is also, quietly, the best disaster recovery documentation anyone ever writes.
Its structure is deliberate. Production is isolated from everything else at the account or subscription level so that a mistake in a test environment cannot reach customers. Networks are private by default, with databases and internal services unreachable from the internet and only load balancers and gateways exposed. Access is federated to your identity provider, granted by role and short-lived rather than by permanent credentials. Guardrails are applied centrally so that the safe path is also the easy path, which matters far more for real-world compliance than a policy document that relies on everyone remembering it.
Its shape is matched to the workload rather than to fashion. Managed services are preferred where they remove operational burden at an acceptable price: a managed database is almost always a better use of your engineers than running your own. Serverless functions are excellent for spiky, event-driven or low-volume work and become expensive and awkward for steady high-throughput workloads, where containers on a managed service fit better. Kubernetes is a real operational commitment to be taken on only when scale and team justify it. Autoscaling is configured against measured demand rather than an aspiration.
And it is observable and recoverable. Alerting is tuned so that a page means something, backups have been restored in a rehearsal, and failover has been triggered on purpose at least once. The gap between an environment that is theoretically resilient and one that is actually resilient is closed only by testing, and closing it is part of the work rather than an optional extra.
Identity, network posture and audit readiness
Most cloud security incidents are not exotic. They come from credentials that should not have existed, permissions far broader than the task required, storage that was public without anyone intending it, and a management interface reachable from the internet. So we concentrate on those. Identity is federated to your existing provider with multi-factor authentication and role-based access, so joiners and leavers are handled in one place. Long-lived static keys are eliminated in favour of short-lived credentials, including for automation, which authenticates through workload identity federation rather than holding a permanent secret. Permissions are moved towards least privilege iteratively, using actual access data rather than a guess, because an aggressive one-shot tightening usually breaks something undocumented and gets reverted wholesale.
Network and data posture is designed rather than inherited. Private subnets by default, databases with no public path, private endpoints for provider services where they both reduce exposure and cut data transfer cost, security groups written as code so their purpose is visible in review, and encryption in transit and at rest with keys managed properly. Where data residency matters, region selection and replication paths are decided explicitly rather than left to a default, which is a question worth settling early under UK GDPR and equivalent regimes rather than during a customer security review.
On compliance we aim at readiness and evidence, and we are clear about the boundary. Infrastructure as code with reviewed changes is strong change-control evidence. Federated identity with roles is access-control evidence. Tested backups, retained logs and defined encryption are the same. Provider frameworks such as the Well-Architected reviews and CIS benchmarks give a useful structure for assessing posture. What none of this substitutes for is an independent assessment or a formal certification, which require a qualified assessor rather than the team that built the environment. Where you need deeper security work, threat modelling, code and configuration review or compliance-readiness support, that is our cybersecurity service.
Signs it’s time
- The cloud bill grows faster than usage and nobody can explain the gap, so the conversation each month is about the total rather than about the drivers
- One person understands how the infrastructure fits together, and everyone plans quietly around their holidays
- Outages take too long to diagnose, because there is no real observability and the first signal is a customer telling you
- An audit, a security questionnaire or a customer’s due diligence is coming and the environment cannot evidence how access, backups or change control work
Legible, incremental, and sized to the actual risk
Our first rule is that we do not change what we cannot describe. An environment that has grown organically for years is holding up a business, and the fastest way to cause an outage is to start tidying before understanding why something is there. So the inventory and the infrastructure code come before the improvements, and improvements arrive as small, reversible steps whose effect is measured. This is slower than a redesign for the first fortnight and much faster over the length of an engagement, because nothing has to be undone.
Our second rule is proportionality, and it is where we most often disagree with a proposal already on the table. Cloud architecture attracts over-engineering: active-active across regions for an application whose users tolerate a few hours of downtime, a multi-cloud abstraction layer bought as insurance against a lock-in that was never the real risk, or an orchestration platform adopted for a handful of services. Each carries permanent cost and complexity, and each is sold as prudence. We size resilience and sophistication to your measured requirements and your team’s capacity to operate them, and we would rather leave a simpler environment your engineers understand than an impressive one that needs us on the phone.
Technologies we build it with
Chosen per problem, not per fashion. This is the stack we most often reach for on this work.
How we deliver
- 01
Discover
We map the system, the constraints and the business it serves, including the parts nobody documented.
Architecture brief
- 02
Architect
Decisions get made, written down and defended before a line of production code exists.
Decision records
- 03
Build
Short cycles against working software. You see progress in the product, not in a status deck.
Shipping increments
- 04
Operate
Monitoring, incident response and iteration. The system is alive, so the engagement is too.
Runbooks & SLOs
Want a straight answer on Cloud Engineering?
A short call with a senior engineer, before you write a brief. If Cloud Engineering is the wrong answer for your situation, we will say so and tell you what we think is right.
What changes
Costs you can explain
Spend attributed to the products, teams and services that cause it, with the largest drivers named and reduced, so the bill becomes a forecast rather than a surprise.
Reliable by design, and proven
Recovery objectives agreed with the business, engineered for and then tested, so resilience is a rehearsed procedure instead of an assumption.
An environment anyone can operate
Infrastructure as reviewable code, with documentation and runbooks, so the system stops depending on one person and stands up to an audit without a scramble.
Industries we serve
Domain knowledge changes what gets built. A few of the sectors we know before the first meeting.
How pricing works
- A fixed-scope cloud assessment as a starting point: inventory, dependency map, cost breakdown, identity and network review, resilience gap analysis, and a prioritised roadmap with the expected effect of each item. It stands on its own as a deliverable, and it is deliberately the cheapest way to find out whether the rest of the work is worth doing.
- A fixed-scope engagement for a defined outcome, such as bringing an environment under infrastructure code, building a landing zone, delivering a cost-reduction programme, or migrating a defined set of applications. Quoted once the assessment has established what is actually there, because estimating cloud work without that is guesswork dressed as a number.
- A monthly senior engagement where the platform keeps developing alongside your product, with continuity from the people who built it. This suits organisations that need ongoing cloud engineering capacity but not a permanent hire, and it is the shape most likely to keep an environment from degrading again.
- Cloud spend is always yours. The accounts are in your name, the provider invoices you directly at their prices, and there is no reseller margin in between. Third-party tooling and licences are bought on your accounts too. We model expected running cost during design and monitor it afterwards, so the bill is forecast rather than received.
Typical timeline
- 01
Assessment
One to two weeks inventorying what runs, mapping dependencies, breaking down cost, reviewing identity and network posture, and establishing what the business needs on availability and recovery. Ends in a written current state and a prioritised plan.
- 02
Baseline as code
Two to four weeks bringing the existing environment under infrastructure code with managed state, correcting structural problems that are causing harm, and removing what is confirmed to be unused. Conservative by design: a reviewable baseline before any redesign.
- 03
Prioritised improvement
Incremental work through the roadmap: cost drivers quantified and reduced, access tightened in stages, resilience engineered to agreed recovery objectives and rehearsed, observability wired in so each change is measurable.
- 04
Documentation and handover
Diagrams, decision records and runbooks written for people who did not build it, a walkthrough with your team, and the infrastructure repository handed over, so the environment no longer depends on any single person, us included.
What working with us actually means
We operate what we build
Our cloud work comes from running production, which is why we insist first on legibility, tested backups and alerting that means something. Those are the items deferred by people who will not be on call for the result, and the items you regret deferring at 2am.
Cost work with arithmetic attached
We quantify each change before making it and measure it afterwards, rather than issuing a generic recommendation to buy commitments. Discounts come after the architecture is right, because locking in a year of an oversized shape is an expensive way to feel efficient.
Proportionate, not impressive
We size resilience and complexity to your measured requirements, and will argue against the multi-region, multi-cloud or heavily orchestrated design when your risk profile does not justify what it costs to build and operate for years afterwards.
Your accounts, no lock-in
Everything runs in cloud accounts you own, billed to you directly at provider prices with no margin from us, defined in an infrastructure repository you hold. Ending the engagement means we stop working, not that anything must be untangled from us.
How to engage us
Three ways to work with us on this, chosen to fit the problem, not our margin.
- Dedicated team A standing team that works only on your product, in your rituals and your tooling. Best when the roadmap outlives the project. Ongoing product development
- Staff augmentation Named senior engineers embedded into your existing team, reporting into your leads. Best when you know what to build and need capacity. Filling a capability gap
- Software outsourcing A defined outcome delivered end-to-end by an accountable team. Best when you want the result owned, not just the hours filled. Outcome-owned delivery
Services in this practice
The specific services that make up this practice.
Related terms
Weighing the options
The decisions people are usually making at the same time as this one.
Common questions
Which cloud should we choose?
Less depends on this than vendors would like you to believe, and what does depend on it is usually your circumstances rather than the technology. AWS has the broadest service catalogue and the largest pool of engineers who know it. Azure tends to win where an organisation is already committed to Microsoft identity, licensing and tooling, because the integration and the commercial terms compound. Google Cloud is strong on data, analytics and Kubernetes. Any of the three will run a normal business application well, so we weigh what your team already knows, any existing enterprise agreement, the managed services your workload leans on, and region availability for data residency. What we would not do is choose one for a marginal technical advantage your team then pays for daily in unfamiliarity.
Should we go multi-cloud?
Usually not, and it is one of the more expensive ideas in circulation. Running the same workload across two providers means abstracting away the managed services that make each one worth using, so you end up operating a lowest common denominator platform, twice the tooling, twice the expertise requirement and twice the security surface, in exchange for a portability you will probably never exercise. The lock-in it is meant to guard against is real but far better managed by keeping your data models and application code portable than by refusing to use your provider properly. There are legitimate cases: a regulator or major customer requiring it, an acquisition that arrives with a second estate, or a specific service that only one provider offers well. Those are reasons. Insurance against a vague future is not, and we will say so before you commit to years of extra cost.
How much can you cut our cloud bill?
We will not quote you a percentage before looking, and you should be wary of anyone who does, because the honest answer depends entirely on how your environment was built. What we can tell you is where the money usually is: workloads sized for a peak that never happens, non-production environments running around the clock, data sitting in hot storage long after anyone reads it, log ingestion and retention nobody chose deliberately, data transfer across zones and through gateways that a different network design would avoid, and resources still running for projects that ended. We start with attribution so the drivers are visible, then work them in order of size with each change quantified before and after. Some environments have a great deal of slack; some are already lean, and if yours is, we will tell you that rather than manufacture savings by degrading it.
Do we need multi-region disaster recovery?
Probably not, and it is a business question before it is a technical one. Start with two numbers agreed with the people who own the service: how much downtime is genuinely tolerable, and how much data loss is acceptable. For many organisations the honest answers are a few hours and close to none, which a well-designed multi-zone deployment with tested backups and a rehearsed rebuild meets comfortably at a fraction of the cost. Full multi-region active-active brings continuous replication, difficult consistency trade-offs, roughly duplicated infrastructure and a permanent operational burden, and it is justified when downtime is measured in minutes or a regulator requires it. Writing the objectives down first usually settles the argument, because most designs proposed on instinct sit several tiers above what the business needs.
Is it ever right to move workloads off the cloud?
Occasionally, yes, and we would rather say so than pretend otherwise. Cloud economics are excellent for variable, spiky or growing demand, and for the enormous amount of undifferentiated operational work you no longer do. They are much less compelling for a large, steady, entirely predictable workload with heavy data transfer, where dedicated hardware or a colocation arrangement can be significantly cheaper if you have the appetite to operate it. The honest complication is that the operational burden comes back with it: capacity planning, hardware failures, physical security and the staff to handle all three, and those costs are easy to leave out of the comparison. In most cases the right answer is a better-engineered cloud environment rather than an exit, but we will do the arithmetic properly rather than assume the conclusion.
Thinking about Cloud Engineering?
Tell us the problem in your own words, not in requirements. A senior engineer reads it and comes back with a straight view on whether Cloud Engineering is the right answer here, or what would be.
- 01A senior engineer reads it. Not a form queue, and not an account manager.
- 02We reply either with questions or with a straight answer that we are not the right fit.
- 03If it looks like a fit, a technical call with the person who would actually run the delivery.
- 04Then scope, effort and risk in writing, before anyone signs anything.