This chapter dives deep into AWS Fargate Spot, a cost-saving feature that allows you to run containerized tasks on spare AWS compute capacity at significant discounts. For the SAA-C03 exam, understanding Fargate Spot is critical as it falls under the Cost Optimized domain (Objective 4.3). Approximately 5-10% of exam questions touch on cost optimization strategies, and Fargate Spot is a prime candidate for scenarios requiring cost reduction without sacrificing scalability. You will learn its mechanics, configuration, integration with other services, and the essential design patterns to handle interruptions, which are frequently tested.
Jump to a section
Imagine a major airline that sells tickets for flights. Most passengers book in advance and pay full price. However, the airline knows that some passengers will cancel at the last minute, and sometimes they overbook. To avoid empty seats, the airline offers a special 'standby' ticket at a steep discount. Standby passengers can board only if there is a free seat after all full-fare passengers have boarded. The airline can bump standby passengers at any time before departure if a full-fare passenger shows up. Standby tickets are non-refundable but very cheap. In AWS Fargate Spot, the 'airline' is AWS with its spare EC2 capacity. The 'standby ticket' is the Spot pricing model. Your container tasks are standby passengers. They run on spare compute capacity at up to 70% discount. But AWS can 'bump' your tasks (terminate them) with a 2-minute warning if the capacity is needed for on-demand customers. You must design your application to handle this interruption gracefully, just as a standby passenger must be ready to take a later flight or not fly at all. The key difference is that AWS gives you a 2-minute notice before termination, allowing you to checkpoint or drain connections.
What is AWS Fargate Spot?
AWS Fargate Spot is a pricing model for AWS Fargate that allows you to run your containerized tasks on spare EC2 capacity at a discounted rate compared to Fargate On-Demand. The discount can be up to 70% off the On-Demand price, making it an attractive option for fault-tolerant, flexible, or stateless workloads. Fargate Spot is ideal for batch processing, data analysis, CI/CD pipelines, and other jobs that can be interrupted and resumed later.
How Fargate Spot Works
Fargate Spot leverages the same underlying Spot Instance mechanism used by Amazon EC2 Spot Instances. AWS has a vast pool of EC2 compute capacity across Availability Zones. To maximize utilization, AWS offers this unused capacity at a lower price. When demand for On-Demand or Reserved Instances increases, AWS can reclaim the Spot capacity with a two-minute warning.
When you launch a Fargate task with FARGATE_SPOT capacity provider, your task is scheduled on a Spot compute resource. The task runs normally until AWS needs the capacity back. At that point, AWS sends a SIGTERM signal to the task, followed by a SIGKILL after two minutes if the task does not stop. The task is then terminated. You are billed only for the time the task ran, down to the second.
Key Components and Defaults
Capacity Provider: You must use the FARGATE_SPOT capacity provider when creating an ECS service or running a task. You can also mix FARGATE (On-Demand) and FARGATE_SPOT in the same service for a blend of reliability and cost savings.
Spot Price: Not directly set by you. AWS determines the Spot price based on supply and demand. You never pay more than the On-Demand price, and typically much less.
Interruption Notice: AWS sends a two-minute warning via the SIGTERM signal. Your application must handle this to gracefully shut down.
Task Count: For services, you can specify a desired count and a minHealthyPercent and maxPercent to control how many tasks can be replaced during deployments or Spot interruptions.
Service Auto Scaling: You can use Application Auto Scaling to automatically adjust the number of tasks based on metrics like CPU or memory utilization. Spot interruptions can trigger scaling events.
Configuration and Verification
To use Fargate Spot, you need to create an ECS cluster with the FARGATE and FARGATE_SPOT capacity providers. Then, when creating a service or running a task, specify the capacity provider strategy.
Example: Creating an ECS service with a mix of Fargate and Fargate Spot
aws ecs create-service \
--cluster my-cluster \
--service-name my-service \
--task-definition my-task:1 \
--desired-count 5 \
--capacity-provider-strategy \
capacityProvider=FARGATE,weight=1,base=1 \
capacityProvider=FARGATE_SPOT,weight=4In this example, the service has a base of 1 task on Fargate On-Demand, and for every additional task, it uses a weighted random selection: 1 part Fargate, 4 parts Spot. So roughly 80% of tasks will run on Spot.
Verification: You can check the capacityProviderName in the task description using aws ecs describe-tasks. Also, CloudWatch metrics like CPUUtilization and MemoryUtilization are available, but there is no direct metric for Spot interruption count.
Interaction with Related Technologies
CloudWatch Events: You can capture Spot interruption events via CloudWatch Events (now Amazon EventBridge). When AWS sends the two-minute warning, it also publishes an event to the EC2 Spot Instance Interruption Warning event. You can trigger a Lambda function to save state or notify operators.
AWS Batch: AWS Batch can use Fargate Spot for job queues. You can define a compute environment with FARGATE_SPOT and set the bidPercentage (though for Fargate, bid price is not applicable; you just specify the capacity provider).
Application Auto Scaling: Use target tracking scaling policies to maintain a desired average CPU or memory. Spot interruptions may cause a drop in capacity, triggering scaling to launch new tasks on either Fargate or Spot.
Service Discovery: If using AWS Cloud Map for service discovery, ensure that tasks running on Spot are properly registered and deregistered upon termination.
Best Practices for Handling Interruptions
Design for Fault Tolerance: Your application should be stateless or have state externalized (e.g., in Amazon S3, DynamoDB, or ElastiCache). Use graceful shutdown to save progress.
Use a Mix of Capacity Providers: Always run at least one task on On-Demand to ensure baseline availability. Use Spot for the rest to save costs.
Implement a Checkpointing Mechanism: For long-running batch jobs, periodically save progress so that when a task is interrupted, it can resume from the last checkpoint.
Use Spot Instance Advisor: While not directly for Fargate, you can get an idea of the frequency of interruptions for different instance families. Fargate Spot uses similar underlying instances.
Monitor Interruption Rate: Use CloudWatch metrics and EventBridge to track how often your tasks are interrupted. Adjust your mix of On-Demand and Spot accordingly.
Common Pitfalls and How to Avoid Them
Not Handling Signals: If your container ignores SIGTERM, it will be killed after two minutes, potentially losing work. Always implement signal handlers.
Assuming No Interruptions: Even though Fargate Spot has a lower interruption rate than EC2 Spot (because AWS manages capacity more intelligently), interruptions still happen. Plan for them.
Setting `base` Too High: The base parameter in capacity provider strategy ensures a minimum number of tasks run on On-Demand. If you set base equal to desiredCount, you get no Spot savings. Use base sparingly.
Not Using Auto Scaling: Without auto scaling, if Spot tasks are terminated, the service may run below desired count. Auto scaling will replace them, but you might still want to launch on On-Demand to maintain performance.
Step-by-Step Configuration on AWS Console
Open the Amazon ECS console.
Choose your cluster, then click 'Create Service'.
Under 'Compute options', select 'Capacity provider strategy'.
Add FARGATE and FARGATE_SPOT capacity providers. For FARGATE, set base=1 and weight=1. For FARGATE_SPOT, set weight=3.
Configure task definition, networking, and load balancing as needed.
Under 'Deployment configuration', set desired number of tasks.
Review and create the service.
CLI Command to Run a Standalone Task with Fargate Spot
aws ecs run-task \
--cluster my-cluster \
--task-definition my-task:1 \
--capacity-provider-strategy \
capacityProvider=FARGATE_SPOT,weight=1This runs a single task on Fargate Spot. No base is needed for a standalone task.
How Fargate Spot Differs from EC2 Spot
No Persistent Request: Fargate Spot tasks are launched on demand, not via persistent Spot requests. You don't need to manage Spot Instances.
No Spot Price Setting: You cannot set a maximum bid price. AWS charges the Spot price, which is always lower than On-Demand.
No Instance Management: You don't choose instance types or sizes. AWS picks the best available Spot capacity for your task's CPU and memory requirements.
Two-Minute Warning: The interruption notice is similar, but Fargate tasks receive the warning via SIGTERM rather than a metadata endpoint. However, you can also use the EC2 metadata service inside the task (if network mode allows) to check for interruption, but the standard way is to handle the signal.
Exam Tips
The SAA-C03 exam will present scenarios where you need to reduce costs for containerized workloads. Fargate Spot is the correct answer for stateless, fault-tolerant batch jobs.
Be aware of the two-minute warning and the need for graceful shutdown.
Know that you can mix Fargate and Fargate Spot in the same service using capacity provider strategies with base and weight.
Remember that Fargate Spot is not suitable for stateful workloads or long-running services that cannot tolerate interruptions.
Understand that Spot interruptions are not failures; they are a normal part of the Spot model. Your application must handle them.
Create ECS Cluster with Capacity Providers
First, you need an ECS cluster. When creating the cluster, you must specify the capacity providers. You can do this via AWS CLI, SDK, or CloudFormation. The cluster must include both `FARGATE` and `FARGATE_SPOT` capacity providers. If you create the cluster using the console, it will automatically add these providers. However, if you use CloudFormation, you must explicitly define them. For example: `CapacityProviders: ['FARGATE', 'FARGATE_SPOT']`. Without these providers, you cannot use Fargate Spot. The cluster is the logical grouping of resources where your tasks run.
Define Task Definition with Appropriate Resources
Create a task definition that specifies the container image, CPU, memory, networking mode (must be `awsvpc`), and IAM role. For Fargate, task sizes are predefined: combinations of CPU (256, 512, 1024, 2048, 4096) and memory (512, 1024, 2048, etc.). Ensure your application is designed to handle `SIGTERM`. Implement a signal handler that saves state and exits cleanly. The task definition does not have a Spot-specific setting; the Spot behavior is determined at runtime by the capacity provider.
Create Service with Capacity Provider Strategy
When creating an ECS service, you specify a capacity provider strategy. This strategy is a list of capacity providers with a `base` and `weight`. The `base` defines the minimum number of tasks that must run on that provider before others are considered. The `weight` determines the proportion of tasks that use each provider. For example, `base=1` for FARGATE ensures at least one On-Demand task. Then, for the remaining tasks, the weight ratio decides the distribution. If you set `weight=1` for FARGATE and `weight=4` for FARGATE_SPOT, roughly 80% of tasks will run on Spot. This strategy is key to balancing cost and reliability.
Handle Interruption Gracefully
When AWS needs to reclaim the Spot capacity, it sends a `SIGTERM` signal to your container. Your application must catch this signal and begin graceful shutdown. You have two minutes to complete any in-flight work, save state, and close connections. If the task does not stop after two minutes, AWS sends `SIGKILL`, which forcefully terminates it. You can also use the EC2 metadata service (if accessible) to poll for interruption notices, but the signal is the primary mechanism. Implement a handler that flushes buffers, writes checkpoint data to S3 or DynamoDB, and deregisters from service discovery.
Monitor and Auto Scale
Use CloudWatch metrics to monitor the number of running tasks, CPU and memory utilization, and service counts. Set up Application Auto Scaling to automatically adjust the desired count based on these metrics. When Spot tasks are interrupted, the service count may drop below desired. Auto scaling will launch replacement tasks, which may also run on Spot (depending on your strategy). You can configure a step scaling policy to quickly add On-Demand tasks during Spot interruptions to maintain performance. Also, use EventBridge to capture Spot interruption events and trigger Lambda functions for custom actions.
Scenario 1: Batch Processing for Image Analysis
A media company processes thousands of images daily for content moderation and metadata extraction. The workload is CPU-intensive and stateless. Each image is processed independently. The company uses ECS with Fargate Spot to run containerized image analysis tasks. They set up a service with a capacity provider strategy: base=1 on Fargate, weight=5 on Fargate Spot. This ensures at least one On-Demand task for critical jobs, while the majority run on Spot. They implemented a graceful shutdown that saves the current image ID to an SQS queue so that if a task is interrupted, the image can be reprocessed. The interruption rate is low (less than 5% of tasks), and the cost savings are about 60% compared to running all tasks on On-Demand. The company monitors task interruptions via CloudWatch and adjusts the weight ratio if interruptions increase.
Scenario 2: CI/CD Pipeline Build Agents
A software development team uses AWS CodeBuild and ECS to run build agents for their CI/CD pipeline. Builds are ephemeral and can be restarted. They use Fargate Spot for the build agents to reduce costs. They created an ECS service with a desired count of 10, all using Fargate Spot (base=0). When a build is triggered, it runs on a Spot task. If the task is interrupted, the build fails and is retried automatically by the CI/CD system. The team configured the container to handle SIGTERM by saving build logs to CloudWatch Logs. They also set up a CloudWatch alarm that triggers if the number of running tasks drops below 8, sending a notification to the DevOps team. The cost savings are significant, and the occasional build retry is acceptable.
Scenario 3: Real-time Data Processing with Checkpointing
A financial analytics company processes real-time stock market data using Apache Flink on ECS. The workload is stateful, but they externalize state to Amazon DynamoDB. They use a mix of Fargate and Fargate Spot. For the Flink job managers, they use On-Demand (base=1). For task managers, they use Fargate Spot with a weight of 3. The Flink application is configured to save checkpoints to S3 every minute. When a Spot interruption occurs, the task manager receives SIGTERM, triggers a final checkpoint, and shuts down. The job manager detects the lost task manager and reassigns work to remaining task managers. New task managers are launched on Spot automatically. The company saves 50% on compute costs while maintaining high availability. They monitor the checkpoint duration to ensure it completes within the two-minute window.
SAA-C03 Exam Focus on Fargate Spot
This topic falls under Domain 4: Cost-Optimized Architectures, specifically Objective 4.3: Determine cost-optimized compute solutions. The exam tests your ability to identify scenarios where Fargate Spot is appropriate and how to configure it.
Common Wrong Answers and Why Candidates Choose Them
Using EC2 Spot Instances instead of Fargate Spot: Candidates often choose EC2 Spot because they are more familiar with it. However, if the scenario specifies containerized workloads on Fargate, Fargate Spot is the correct answer. EC2 Spot requires managing instances, which is not serverless.
Setting a bid price: Some candidates think they can set a maximum bid price for Fargate Spot. This is not supported. AWS determines the Spot price, and you always pay the Spot price, which is lower than On-Demand.
Using only Fargate Spot without On-Demand: While possible, the exam will likely test the best practice of mixing capacity providers. A scenario with a critical service should include at least one On-Demand task to ensure availability.
Ignoring the two-minute warning: Candidates may forget that Spot tasks can be interrupted. They might choose Fargate Spot for a stateful workload without checkpointing. The exam will penalize this.
Specific Numbers and Terms
Discount: up to 70% off On-Demand.
Interruption notice: 2 minutes via SIGTERM.
Capacity provider strategy parameters: base and weight.
Capacity provider names: FARGATE and FARGATE_SPOT.
Pricing: per second billing.
Edge Cases and Exceptions
Service with `desiredCount` less than `base`: If base is set to 2 but desiredCount is 1, the service will run 1 task on Fargate (On-Demand) because it cannot meet the base. The base is a minimum, not a maximum.
Spot task fails to launch: If no Spot capacity is available, the task will fail to launch. The service will attempt to launch it on the next available capacity provider according to the strategy. If all providers are unavailable, the task remains pending.
Multiple capacity providers: You can have more than two capacity providers, but for Fargate, only FARGATE and FARGATE_SPOT exist. For EC2, you can add custom capacity providers.
How to Eliminate Wrong Answers
If the question mentions 'serverless containers' or 'no infrastructure management', eliminate EC2 options.
If the workload is stateful and cannot tolerate interruptions, eliminate Spot options.
If cost reduction is the primary goal and the workload is fault-tolerant, Fargate Spot is likely correct.
Look for keywords like 'batch', 'CI/CD', 'stateless', 'fault-tolerant' to indicate Spot suitability.
Fargate Spot offers up to 70% discount for containerized tasks on spare EC2 capacity.
Tasks receive a 2-minute warning via SIGTERM before termination.
Use capacity provider strategy with base and weight to mix On-Demand and Spot in a service.
Fargate Spot is ideal for stateless, fault-tolerant, or batch workloads.
You must handle SIGTERM gracefully to checkpoint state and shut down cleanly.
Fargate Spot does not support bid pricing; AWS sets the Spot price.
Monitor interruption rates with CloudWatch and EventBridge.
These come up on the exam all the time. Here's how to tell them apart.
Fargate On-Demand
No risk of interruption; tasks run until stopped.
Higher cost; no discount.
Suitable for stateful or long-running workloads.
Always available if capacity exists in the region.
Billed per second with no savings.
Fargate Spot
Can be interrupted with a two-minute warning.
Up to 70% discount compared to On-Demand.
Suitable for stateless, fault-tolerant, or batch workloads.
Availability depends on Spot capacity; may not always be available.
Billed per second at the Spot price, which fluctuates.
Mistake
Fargate Spot tasks never get interrupted.
Correct
Fargate Spot tasks can be interrupted with a two-minute warning when AWS needs the capacity back. You must design your application to handle interruptions gracefully.
Mistake
You can set a maximum bid price for Fargate Spot.
Correct
Unlike EC2 Spot Instances, Fargate Spot does not allow you to set a bid price. AWS determines the Spot price, and you are charged that price, which is always lower than On-Demand.
Mistake
Fargate Spot is cheaper than Fargate On-Demand but more expensive than EC2 Spot.
Correct
Fargate Spot typically offers similar discounts to EC2 Spot (up to 70%) but includes the Fargate premium for managed infrastructure. However, you avoid the overhead of managing instances, so total cost of ownership may be lower.
Mistake
You can only use Fargate Spot for services, not standalone tasks.
Correct
You can use Fargate Spot for both services and standalone tasks via `run-task` with the `FARGATE_SPOT` capacity provider.
Mistake
Fargate Spot tasks run on dedicated Spot instances that are isolated from On-Demand.
Correct
Fargate Spot tasks run on the same underlying EC2 instances that AWS uses for Spot capacity. The isolation is at the container level, not the instance level.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Yes, but you should mix Fargate On-Demand and Spot using a capacity provider strategy. Set a base of at least 1 on On-Demand to ensure baseline availability. The remaining tasks can run on Spot to save costs. Your application must be able to handle Spot interruptions gracefully, e.g., by using a load balancer that distributes traffic to healthy tasks.
Implement a signal handler for SIGTERM in your container. Upon receiving the signal, save any necessary state to an external store (e.g., S3, DynamoDB), flush buffers, close connections, and exit. You have 2 minutes before SIGKILL is sent. You can also use the EC2 metadata service to check for interruption notices, but the signal is the primary mechanism.
Fargate Spot is a managed compute option for containers where AWS handles the underlying infrastructure. EC2 Spot requires you to manage EC2 instances. Fargate Spot does not allow you to set a bid price or choose instance types; AWS selects the best Spot capacity for your task's CPU and memory requirements. Both offer similar discounts and interruption behavior.
Yes. Use the `run-task` command with the `--capacity-provider-strategy` parameter specifying `FARGATE_SPOT`. For example: `aws ecs run-task --cluster my-cluster --task-definition my-task:1 --capacity-provider-strategy capacityProvider=FARGATE_SPOT,weight=1`.
When creating or updating an ECS service, specify a capacity provider strategy that includes `FARGATE_SPOT`. You can also include `FARGATE` for a mix. Use the `base` and `weight` parameters to control the distribution. For example, set base=1 for FARGATE and weight=4 for FARGATE_SPOT to ensure at least one On-Demand task and 80% Spot tasks.
Fargate Spot is available in most AWS regions where Fargate is supported. However, availability may vary, and you should check the AWS documentation for the latest regional availability. Some smaller or newer regions may not support Spot for Fargate.
If no Spot capacity is available, the task will fail to launch. If you are using a service with a capacity provider strategy that includes On-Demand, the service will attempt to launch the task on On-Demand if the Spot launch fails. You can also configure the service to use only Spot, but then the task will remain pending until capacity becomes available.
You've just covered Fargate Spot for Cost Savings — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?