Scopely Delivers a Seamless Player Experience for Star Trek Fleet Command Using Amazon ECS

Scopely, founded in 2011, is a global interactive entertainment company and mobile game developer. The company's portfolio includes MONOPOLY GO!, MARVEL Strike Force, and Stumble Guys. For the launch of Star Trek Fleet Command, Scopely leveraged Amazon Elastic Container Service (Amazon ECS) as its container platform, deploying workloads on Amazon Elastic Compute Cloud (Amazon EC2) Spot Instances. While ECS offered a fully managed orchestration service, enabling developers to efficiently deploy, manage, and scale containerized applications, Spot Instances provided a cost- effective compute layer for fault-tolerant workloads, delivering up to a 90% discount compared to EC2 On-Demand pricing. This approach enabled Scopely to pay only for the compute capacity it used, billed by second, while significantly optimizing infrastructure costs with Spot. As Star Trek Fleet Command gained popularity and player demand surged - particularly during peak- traffic events like Black Friday—Scopely’s team encountered certain operational challenges. Manually shifting workloads from Spot to On-Demand Instances to maintain availability became increasingly complex and time-consuming.This prompted the team to revisit and optimize the architecture, leading to a series of improvements, including the development of automated and scalable solution to dynamically balance On-Demand and Spot Instance capacity.

Scopely relied on Amazon EC2 Auto Scaling to adjust compute capacity based on demand. To further optimize its performance, they adopted Attribute-based instance type selection (ABIS), enabling its Auto Scaling groups to seamlessly adopt the latest EC2 instance types as soon as they became available. With customizable price protection thresholds, Scopely gained granular control over balancing cost savings with availability, thus enabling the team to make smarter, data-driven compute investment decisions.

To eliminate manual intervention during Spot to OnDemand capacity transitions, Scopely developed a custom solution using AWS Lambda - Lambda enabled them to run code without thinking about servers or clusters. This solution helped them to dynamically adjust Auto Scaling group distribution between Spot and On-Demand Instances. The team also defined attributes such as minimum CPU and memory requirements and can now monitor Auto Scaling groups for capacity issues and automatically switch to On-Demand Instances when needed. Additionally, Scopely also created dedicated Auto Scaling groups for latency-sensitive workloads, ensuring they did not compete for capacity with other services.

With above automation in place, Scopely can now seamlessly transition back to Spot Instances when capacity becomes available, thus maximizing cost efficiency. This automation is powered by two Lambda functions - one automatically detects unfulfilled Spot capacity events and incrementally adjusts the Auto Scaling group composition to include more On-Demand Instances, while another one runs every 30 minutes to gradually scale On-Demand usage back to zero, returning the system to 100% Spot instances.

Since implementing this automated solution, Scopely has eliminated the need for manual intervention during capacity transitions. “Custom Lambda automation and Attribute-based instance type selection on Auto Scaling groups offers us the sweet spot where we can automate our Spot Instance management with very little operational overhead while maintaining virtually the same cost advantages”, says Nicolás Piechocki, Principal DevOps Engineer at Scopely.

Building on this momentum, Scopely turned its attention to optimizing task placement strategies within Amazon ECS—shifting from a spread to binpack. While the spread strategy distributed containers across multiple EC2 instances to maximize availability, binpack placement consolidated tasks more efficiently, reducing resource fragmentation and waste.

To further streamline compute resource allocation, Scopely adopted Amazon ECS capacity providers to automatically scale EC2 instances based on real-time capacity requirements. Previously, scaling was reactive triggered only when tasks failed due to capacity constraints. With ECS managed scaling, which comes with capacity providers, the company can now scale its Auto Scaling groups within 1 minute, ensuring faster responsiveness and improved workload placement. (See figure 1. Scopely’s architecture for Amazon ECS on Amazon EC2.)

These optimizations delivered measurable impact: reduced development environment costs by 50 percent and production workload costs decreased by about 30 percent. “We need to run everything as cost efficiently as possible while still delivering a seamless player experience,” says Nicolás Piechocki. “By using Amazon ECS and optimizing our infrastructure, we’ve achieved that balance—or we’re much closer than we were 3 years ago.”

Using Amazon ECS and Spot Instances, Scopely proved that even fully mature games can further improve efficiency and reach new frontiers. Using the comprehensive AWS infrastructure, Scopely can access the same powerful, robust capabilities that help some of the world’s most sophisticated companies scale while removing the technical barriers that previously required constant manual intervention.

Now that the company has reduced costs, minimized operational overhead, and enhanced player experience, Scopely is turning its attention to future improvements. The next initiative will focus on implementing comprehensive health checks using native AWS features, designed to monitor not just uptime of services, but also the actual health status of underlying components such as databases, network connectivity, and other system dependencies.

“In development, you want to fail fast because you want to recover even faster,” says Nicolás Piechocki. “I think that’s going to be our next big initiative—conducting health checks and understanding service status so that we can quickly replace components, scale appropriately, shift resources, or raise alarms in response to early warning signs.”