From an Elastic Fleet to Serverless: Migrating Webinar Infrastructure to AWS Fargate

Context

By this point the client's webinar platform already ran on an elastic fleet of large EC2 instances, container-orchestrated to grow and shrink with demand. Looking closely at real usage patterns told a clearer story: webinars ran overwhelmingly during business hours, 9am to noon and 2pm to 8pm client local time, and almost never overnight, 1am to 5am. Even the bare minimum the system kept always ready (its own control service plus one warm EC2 instance) was a real, ongoing cost; with instances that large, that idle floor added up to real money, every single day.

The project

1. AWS Fargate had just launched, letting containers run without managing the EC2 fleet underneath them at all. Since the platform already ran on Docker, this was a natural next step rather than a rewrite.
2. Thinking about it as "serverless containers" made the next decision obvious too: replace the old EC2-hosted control service itself with AWS Lambda, an event-driven, serverless layer to match.
3. Designed a pool of Fargate tasks with a real lifecycle of its own states, requested, starting, running, draining, stopped, managed by Lambda functions reacting to real webinar events rather than a always-running process polling for work.
4. Real AWS limits got in the way of doing this naively. Launching a Fargate task is far faster than booting a new EC2 instance, but AWS's own API throttles how many task launches can happen at once (on the order of 10 every 10 seconds), so a genuine burst of simultaneous demand could still queue up and feel slow to users. The fix, worked out together with the client: let scheduled webinars register ahead of time, so their capacity could be reserved and pre-warmed instead of requested cold at the last second.

Our role

• Designing the Fargate task pool and its lifecycle states.
• Replacing the EC2-hosted control service with Lambda-based, event-driven orchestration.
• Working with the client to design the reservation mechanism for scheduled webinars, to stay within real AWS rate limits without making users feel it.
• Migrating the platform end to end from the earlier EC2/container fleet to the new serverless architecture without disrupting a live, already-growing product.

Technologies

• AWS Fargate, for running containers without managing the underlying EC2 fleet.
• AWS Lambda, for event-driven orchestration replacing the earlier always-on control service.
• Docker containers, unchanged from the platform's existing architecture.

Conclusion and lessons learnt

Moving from elastic to genuinely serverless didn't just cut cost; it removed an entire category of operational work, EC2 lifecycle management, that the previous architecture had simply baked in as a fixed cost of doing business. The real lesson was that "elastic" and "serverless" aren't the same destination: the first still asks you to manage machines, just more efficiently; the second asks a genuinely different question about what your infrastructure should have to think about at all.