AWS ECS Fargate_SPOT fall back to Fargate

Hello,

Your understanding of the current ECS capacity provider strategy limitations regarding SPOT fallback is correct. As of now, there's no automatic fallback mechanism from Fargate Spot to Fargate On-Demand when Spot capacity is unavailable.

While adjusting weights (e.g., FARGATE_SPOT: 6, FARGATE: 1) can prioritize Spot usage, it doesn't guarantee a perfect fallback. Setting base values to 0 allows ECS to allocate tasks freely based on weights. However, using equal weights of 1 for both providers won't create a reliable fallback system.

The feature request for a true fallback mechanism (Issue #852 in the AWS ECS roadmap) is currently marked as "Not planned." Given these limitations, you might consider workarounds like using separate services with custom logic, overprovisioning, or implementing custom automation to monitor and adjust task allocation.

While not ideal, these approaches can help manage the balance between cost-saving and availability until a native fallback feature in the future is potentially implemented.

... there is indeed a mechanism for ECS to fall back to Fargate on-demand when Fargate Spot capacity is unavailable

Where in the AWS Documentation is this "fallback mechanism" described? I've read all the referenced docs, and don't see anything suggestion that ECS will "fallback" to FARGATE when FARGATE-SPOT is unavailable.

Your understanding of the ECS capacity provider strategy is generally correct, but there are a few points to clarify and confirm.

First, it's important to note that there is indeed a mechanism for ECS to fall back to Fargate on-demand when Fargate Spot capacity is unavailable. The capacity provider strategy you've described can work to achieve this goal, but the effectiveness depends on the specific configuration.

Using equal weights of 1 for both FARGATE_SPOT and FARGATE can work, but it may not provide the strong preference for Spot instances that you're looking for. With equal weights, ECS will attempt to distribute tasks evenly between the two capacity providers. This means that even when Spot capacity is available, you might end up with a mix of Spot and on-demand instances.

The suggestion to use a higher weight for FARGATE_SPOT (like 6) and a lower weight for FARGATE (like 1) is a good approach. This configuration will strongly favor Spot instances while still allowing fallback to on-demand when necessary. With this setup, ECS will attempt to launch all tasks on Fargate Spot first, and only use Fargate on-demand if Spot capacity is unavailable.

Regarding the base value, your understanding is correct. Setting the base to 0 for both providers allows ECS to flexibly allocate tasks between the two capacity providers based on their weights and availability. This configuration doesn't guarantee a minimum number of tasks on either provider, which aligns with your goal of prioritizing Spot instances but falling back to on-demand when necessary.

To summarize:

1. A fallback mechanism from Fargate Spot to Fargate on-demand does exist.
2. Using equal weights of 1 for both providers will work, but may not strongly prioritize Spot instances.
3. Using a higher weight for FARGATE_SPOT (e.g., 6) and a lower weight for FARGATE (e.g., 1) will better prioritize Spot instances while allowing fallback.
4. Setting the base to 0 for both providers is appropriate for your use case.

Remember that the actual behavior may vary depending on the availability of Spot capacity at any given time. It's also worth noting that when using Fargate Spot, you should design your applications to be interruption-tolerant, as Spot instances can be reclaimed with only a two-minute warning.
Sources
AWS Fargate Spot compared to Reserved Instances - Prebid Server Deployment on AWS
Using Amazon EC2 Spot and FARGATE_SPOT - Amazon Elastic Container Service
Amazon ECS Capacity Providers Now Support Update Functionality
Amazon ECS capacity providers for the EC2 launch type - Amazon Elastic Container Service