The challenge
Our client is a UK-based financial services provider operating in the mortgage market. Like many growing companies, they had built up their cloud infrastructure over time with the help of an outsourced DevOps provider — but the arrangement had not delivered what they needed. The infrastructure had grown complex in ways that didn't reflect the application's actual requirements, deployments were not under the control of the development team, and there was no meaningful disaster recovery provision in place.
When we were brought in, the brief was straightforward: take ownership of the infrastructure, understand what was there, and make it work properly. In practice, that meant unpicking a setup that had accumulated unnecessary complexity, rebuilding the deployment pipeline in a way the development team could actually own, and putting a proper DR and observability foundation under a platform that handles sensitive financial data.
Simplifying the infrastructure
The first task was a thorough audit of the existing AWS setup. What we found was an environment that had grown through accretion — components added to solve immediate problems without a consistent architectural approach. The result was more moving parts than the application needed, unclear ownership of configuration, and deployment processes that required external intervention for routine releases.
We rationalised the setup, removing redundant components and consolidating configuration in ways that made the environment easier to reason about. Every change was documented, and the goal throughout was to end up with an infrastructure that the client's own team could understand and work with — not one that required specialist knowledge to operate on a day-to-day basis.
ECS Fargate: 100% Uptime and intelligent scaling
The core of the infrastructure work was migrating the application to ECS Fargate. The previous setup used EC2-based container hosting, which carried manual overhead and made rolling deployments difficult to execute cleanly.
Fargate solved both problems. Deployments now use a rolling update strategy — new task definitions are brought up alongside existing ones, traffic shifts once the new containers pass health checks, and old tasks are drained and replaced without any interruption to service. Production deployments that previously required a maintenance window or risked brief unavailability now happen transparently.
The second benefit of Fargate was cost-efficient scaling. Financial services platforms tend to have predictable traffic patterns — high activity during business hours, significantly lower demand overnight and at weekends. We configured the service to scale back out of hours, reducing the running task count when demand is low and scaling back up ahead of peak periods. The same containerised workload, properly configured, now costs materially less to run than the fixed-capacity EC2 setup it replaced.
GitHub-driven deployments
One of the clearest pain points in the previous arrangement was that the development team could not deploy their own code. Releases required coordination with the external provider, which added friction, slowed down iteration, and created a dependency that had no good reason to exist.
We replaced the deployment process with a GitHub Actions pipeline that gives the development team full control. Merging to the appropriate branch triggers a build, runs the test suite, and — on success — deploys to the target environment automatically. The pipeline also handles environment variable management directly: developers can update configuration through the repository without needing infrastructure access, and changes are applied cleanly as part of the deployment cycle. Secrets are managed through AWS Secrets Manager and surfaced to the application at runtime, keeping sensitive configuration out of source control while keeping it under developer control.
The result is a deployment workflow that is self-service, auditable, and fast — and that the development team owns entirely.
Disaster recovery
Financial services applications carry a clear obligation to keep customer data safe and services available. The previous infrastructure had no meaningful DR provision; a regional AWS outage or a severe data-tier failure would have been a significant incident with no tested recovery path.
We implemented cross-region replication to provide a DR target in a secondary AWS region. Application artefacts, database snapshots, and configuration are continuously replicated. In the event of a regional failure, the application can be brought up in the secondary region from a known-good state within a defined recovery time objective.
Critically, we don't just provision DR capability — we test it. Yearly DR exercises bring the full application up in the secondary region, validate that data and configuration are intact, and confirm that the recovery process works as documented. The test findings are reviewed and any drift from the expected state is remediated before the next cycle. For a regulated financial services environment, the difference between untested DR and a tested, documented recovery process is not a minor operational detail.
Observability and security
The production environment is monitored through a combination of Datadog and AWS CloudWatch. Datadog provides application-level observability — request rates, error rates, latency distributions, and custom metrics from the application itself. CloudWatch handles infrastructure-level monitoring and log aggregation, with alarms configured for key operational signals including error rate spikes, resource utilisation thresholds, and unusual traffic patterns.
AWS Config continuously monitors the infrastructure configuration against a defined set of compliance rules and raises alarms when configuration drift occurs — a security layer that detects changes like unexpected security group modifications or storage access policy changes before they can become incidents. For a financial services environment where the configuration of the infrastructure is itself a security concern, having automated, continuous configuration compliance monitoring is not optional.
The outcome
The client now operates on a significantly simpler, more capable infrastructure than the one we inherited. Production deployments are 100% Uptime and entirely under developer control. The environment scales intelligently to match demand, reducing cost without any impact on availability. Disaster recovery is tested annually against documented objectives, meeting the expectations of a regulated financial services business. And the observability and security monitoring stack gives both the development team and the business genuine confidence in what is running in production.
The engagement replaced a dependency that had been a source of friction and risk with infrastructure and processes the client's own team can own, operate, and build on.