AWS User Group UK Meetup #80

About this event

Welcome to our November event. We’re delighted to welcome Eduardo Aparicio Cardenes (https://www.linkedin.com/in/eacardenes/), Senior Frontend Engineer, Super, and a careers panel including Kimberley Clements (https://www.linkedin.com/in/kimberleyclements471/), Senior Solutions Architect, Amazon Web Services (AWS) and Mike Mead (https://www.linkedin.com/in/mike-mead/), Technical Director, Scale Factory Here’s what they’re bringing: 1.6 million transactions a day, over €300M in deposits a month, all running on shared Amazon S3 and CloudFront. Eduardo and his team moved that live payment frontend onto dedicated, jurisdiction-owned infrastructure with Terraform, and finished with zero production incidents. Tonight Eduardo is giving us the part the architecture diagram leaves out: dual deploys, feature flags and a way back that never needed an emergency release. Same AWS console, very different job. Inside AWS, at a consulting partner, alongside the public sector: where you do the work shapes the problems you get and where your career goes next. Tonight our panel walks us through what each path looks like day to day, what it gives you and what it costs. A big thank you to our sponsors Cloudscaler (https://rebrand.ly/cloudscaler) & Rayo (https://rebrand.ly/rayo-cloud) for making this event possible. Programme: • 18:00: Arrival, registration • 18:15: Talks start • 20:00: Networking with food and a drink provided by the generosity of our sponsors. Session 1: Zero Incidents, €300M+ in Monthly Deposits: Migrating a Multi-Jurisdiction Frontend from Shared to Dedicated AWS with Eduardo Aparicio Cardenes Our payment frontend handles more than 1.6 million transactions every day and over €300M in deposits every month across multiple jurisdictions. It originally ran on shared Amazon S3 and CloudFront infrastructure. As the platform grew, that shared model created wider failure boundaries: a change for one jurisdiction could affect another, while ownership, production access and cost attribution became increasingly difficult to isolate. We needed to move a live payment platform to dedicated, jurisdiction-owned AWS infrastructure without disrupting customers. Using Terraform, we created a repeatable infrastructure pattern for each jurisdiction, with dedicated S3 and CloudFront delivery, DNS, certificates, permissions, security policies, and separate production boundaries. Infrastructure changes moved from manual console operations into versioned, reviewed pull requests. But building the target architecture was only half of the migration. The harder part was moving customers safely. We deployed every application build to both the legacy and new infrastructure, validated the new path in production before customers depended on it, and used feature flags to migrate jurisdictions independently. If something went wrong, we could move that jurisdiction back to the legacy path without an emergency release. We started with the lowest-risk jurisdiction and expanded progressively, using both infrastructure health and payment behaviour to decide when to continue. The migration completed with zero production incidents. This talk shares what we learned about the part of cloud migrations architecture diagrams often miss: the transition. How coexistence, validation, observability and rollback allowed us to change the infrastructure underneath a live payment platform without making the migration a customer problem. Learning Takeaways • Design the transition architecture - coexistence, validation, observability and rollback - not only the target state. • Dual-deploy to legacy and new infrastructure so cutover becomes a routing decision, with feature flags to move each jurisdiction forward or back without an emergency release. • Shrink failure boundaries with jurisdiction-owned Terraform stacks, and gate each rollout stage on both infrastructure health and payment behaviour. Eduardo Aparicio Cárdenes is a Senior Frontend Engineer at Super with nearly 20 y