Untested load, on a fixed date
The traffic this customer would bring had no precedent in the platform’s existing usage.
Launch readiness
An AWS platform, made ready for its largest customer yet.
A growing software company had won its largest customer to date, and the deal came with a technical review neither the platform nor the team had faced before. The platform could probably grow — the question was whether it could prove it, on a date that had already been agreed.
← Some of our past work · anonymised prior delivery, no client named
Stack
Amazon RDSAuto ScalingAmazon CloudWatchAWS BackupTerraform
Rough timeline
| Phase | Typical duration |
|---|---|
| Readiness review across six pillars | 1 week |
| Highest-risk changes implemented, ahead of launch | 2–4 weeks |
| Evidence pack for the customer’s technical review | concurrent |
The challenge
The launch date did not move, and the load had never been tested.
The platform had grown organically alongside its existing customers, none of which individually resembled what was about to arrive at once.
The customer’s security team would ask, and the answer had to survive it
A technical review from a large enterprise buyer looks for the specific gap, not a general reassurance.
The work had to be prioritised by risk, not by discovery order
Everything found could not be fixed before the date — what mattered was fixing what actually blocked launch.
What we found
Scaling that was assumed, and a database that was a single point of failure.
None of it was surprising for a platform at this stage. All of it was material to a launch at this scale.
Scaling was assumed, not configured
Auto Scaling groups existed, with thresholds set early on and never revisited against the traffic this launch would actually bring.
The database was a single point of failure
RDS running without Multi-AZ on the workload the new customer would depend on most.
Monitoring told you something had happened, not that something was about to
Alarms existed on hard failures; nothing gave early warning on a resource heading toward its limit.
Incident readiness was informal
The team could respond, but there was no on-call runbook a new team member could follow at short notice.
What InfraEdge changed
The highest-risk items closed before the date, not merely identified.
The review covered six pillars. The work that followed was sequenced by what would actually block the launch.
| Change | What it did |
|---|---|
| Scaling reviewed and load-tested | Auto Scaling thresholds reset against a load test approximating the new customer’s expected traffic, not the traffic seen so far. |
| Database resilience added | RDS moved to Multi-AZ for the workloads this launch depended on most, with automated backups and a tested failover. |
| Deployment controls tightened | Production changes routed through a reviewed, plan-then-apply path ahead of a period the team could not afford a bad deploy in. |
| Monitoring extended | CloudWatch alarms added on leading indicators, not just hard failures, so a problem is visible before it is an outage. |
| Backup and incident readiness documented | A tested backup and restore path, and an incident runbook the team could actually follow under pressure. |
Outcome
A prioritised readiness plan, and clear evidence for the technical review.
The customer’s review needed evidence, not reassurance: a written record of what was checked, what was found, and what was fixed before launch.
The launch went ahead on the agreed date, with the production blockers that mattered closed rather than merely identified. This is the shape of EdgeReady: scored against production practice across six pillars, with the findings that matter fixed before the date that matters.
Book a 20-minute triage call
Twenty minutes, no charge. We work out what would actually help — which is sometimes us and sometimes not. Nothing is priced on the call; if there is work worth doing, a written scope and a price reach you within 24 hours.