In the previous lesson, you created your first ECS cluster and learned about the fundamental building blocks of Amazon ECS. You successfully deployed a basic cluster using aws ecs create-cluster --cluster-name my-ecs-cluster and verified its creation. While that cluster is ready to run Fargate tasks, it uses default settings that may not be optimal for all scenarios.

In this lesson, you'll take your cluster configuration skills to the next level by learning about launch types and capacity providers. These concepts determine how and where your containers actually run, giving you control over cost optimization and resource allocation. By the end of this lesson, you'll understand the key differences between Fargate and EC2 launch types, and you'll be able to create clusters with specific capacity provider configurations that match your application's needs.

Your main goal is to create an ECS cluster with explicit capacity providers and inspect its configuration using AWS CLI commands. This hands-on approach will help you understand how capacity providers work and prepare you to make informed decisions about container deployment strategies in real-world scenarios.

When you deploy containers on ECS, you must choose a launch type that determines where your containers run. Think of launch types as different hosting models for your applications. The launch type you choose affects everything from cost to control over the underlying infrastructure.

Fargate is the serverless option where AWS manages all the infrastructure for you. You specify your container requirements, and Fargate provisions exactly the right amount of compute resources. Key benefits include:

• No infrastructure management: No servers to patch, no capacity planning, and no infrastructure management overhead
• Predictable costs: You pay per task based on the CPU and memory you allocate, making costs directly tied to your application's resource consumption
• Automatic scaling: Resources are provisioned exactly when needed

The EC2 launch type gives you full control over the underlying infrastructure. You provision and manage EC2 instances, then register them with your ECS cluster. Key characteristics include:

• Full infrastructure control: You're responsible for patching, scaling, and maintaining EC2 instances
• Flexibility: More options for specialized workloads and custom configurations
• Cost efficiency for consistent workloads: Can be more cost-effective for large, consistent workloads since you pay for the EC2 instances regardless of how many containers are running

The trade-offs are clear: Fargate prioritizes simplicity and operational efficiency, while the EC2 launch type offers control and potential cost savings for specific use cases. Fargate excels for variable workloads, development environments, and applications where you want to focus on code rather than infrastructure. The EC2 launch type works well for large-scale production workloads, applications requiring specific instance types, or scenarios where you need direct access to the underlying operating system.

Capacity providers are the mechanism that ECS uses to manage compute resources for your clusters. They act as an abstraction layer between your tasks and the underlying infrastructure, allowing ECS to make intelligent decisions about where to place your containers.

For Fargate, AWS provides two built-in capacity providers: FARGATE and FARGATE_SPOT. The FARGATE capacity provider uses standard Fargate infrastructure with guaranteed availability and consistent performance. The FARGATE_SPOT capacity provider uses spare AWS capacity at significantly reduced costs, but your tasks may be interrupted with a two-minute warning when AWS needs the capacity back.

For EC2 launch types, you create custom capacity providers backed by Auto Scaling groups. These capacity providers can automatically scale your EC2 instances based on task demand, providing a bridge between the flexibility of containers and the control of EC2 infrastructure.

Capacity provider strategies define how ECS distributes tasks across multiple capacity providers. The strategy includes three key components: base (the minimum number of tasks to run on a specific provider), weight (the relative proportion of tasks), and the overall distribution logic. For example, you might set a base of 2 tasks on FARGATE for reliability, then use weights to distribute additional tasks between FARGATE and FARGATE_SPOT for cost optimization.

There are two ways to configure Fargate clusters:

1. Basic clusters (from Unit 1): Created without explicit capacity provider configuration. These have empty capacityProviders arrays but can still run Fargate tasks by specifying --launch-type FARGATE in your service/task commands.

2. Capacity provider configured clusters: Explicitly configured with capacity providers and strategies. These allow for more sophisticated task placement, cost optimization, and automatic scaling decisions by ECS.

Both approaches work, but capacity provider configuration gives you more control and optimization options.

Now let's create a cluster with explicit capacity provider configuration. This approach is different from the basic cluster created in Unit 1, which had empty capacity provider arrays. Here we're explicitly configuring capacity providers, giving you more control over how your tasks are distributed and allowing you to take advantage of cost optimization opportunities like Spot pricing.

aws ecs create-cluster \
  --cluster-name my-ecs-cluster \
  --capacity-providers FARGATE FARGATE_SPOT \
  --default-capacity-provider-strategy capacityProvider=FARGATE,weight=1

This command creates a cluster named my-ecs-cluster with both FARGATE and FARGATE_SPOT capacity providers available. The --default-capacity-provider-strategy parameter sets FARGATE as the default with a weight of 1, meaning all tasks will use standard Fargate unless you specify otherwise when creating services or running tasks.

When you run this command, you'll see output similar to this:

{
    "cluster": {
        "clusterArn": "arn:aws:ecs:us-east-1:123456789012:cluster/my-ecs-cluster",
        "clusterName": "my-ecs-cluster",
        "status": "ACTIVE",
        "registeredContainerInstancesCount": 0,
        "runningTasksCount": 0,
        "pendingTasksCount": 0,
        "activeServicesCount": 0,
        "statistics": [],
        "tags": [],
        "settings": [
            {
                "name": "containerInsights",
                "value": "disabled"
            }
        ],
        "capacityProviders": [
            "FARGATE",
            "FARGATE_SPOT"
        ],
        "defaultCapacityProviderStrategy": [
            {
                "capacityProvider": "FARGATE",
                "weight": 1,
                "base": 0
            }
        ]
    }
}

Notice how the capacityProviders array now shows both FARGATE and FARGATE_SPOT, and the defaultCapacityProviderStrategy reflects your configuration. This cluster is now ready to use either capacity provider, with FARGATE as the default choice.

The default capacity provider strategy you set during cluster creation can be customized to match your specific cost and reliability requirements. Let's explore some common patterns that balance cost optimization with application reliability.

A popular strategy for cost-conscious deployments is to mix FARGATE and FARGATE_SPOT with different weights. Here's an example that runs most tasks on Spot pricing while maintaining some guaranteed capacity:

aws ecs create-cluster \
  --cluster-name cost-optimized-cluster \
  --capacity-providers FARGATE FARGATE_SPOT \
  --default-capacity-provider-strategy capacityProvider=FARGATE,weight=1,base=2 \
  --default-capacity-provider-strategy capacityProvider=FARGATE_SPOT,weight=3

This configuration ensures at least 2 tasks always run on standard FARGATE (the base), then distributes additional tasks with a 1:3 ratio between FARGATE and FARGATE_SPOT. If you're running 10 tasks total, 2 will be on FARGATE (base), and the remaining 8 will be split with 2 on FARGATE and 6 on FARGATE_SPOT based on the weight ratio.

When using FARGATE_SPOT, it's important to understand the interruption model. AWS provides a two-minute warning before terminating Spot tasks, giving your application time to gracefully shut down. Your containers should be designed to handle these interruptions by saving state, completing in-flight requests, or implementing retry logic. Spot interruptions are relatively rare, but planning for them ensures your application remains resilient.

For development environments where cost is the primary concern, you might use a strategy that heavily favors Spot pricing:

aws ecs create-cluster \
  --cluster-name dev-cluster \
  --capacity-providers FARGATE FARGATE_SPOT \
  --default-capacity-provider-strategy capacityProvider=FARGATE_SPOT,weight=4 \
  --default-capacity-provider-strategy capacityProvider=FARGATE,weight=1

This approach runs 80% of tasks on Spot pricing, significantly reducing costs while accepting the possibility of occasional interruptions.

After creating clusters with different capacity provider configurations, you can inspect and compare them to understand how your settings translate into actual cluster behavior. The describe-clusters command with specific queries helps you focus on the capacity provider information.

aws ecs describe-clusters \
  --clusters my-ecs-cluster \
  --query 'clusters[0].capacityProviders'

This command returns just the capacity providers for your cluster:

[
    "FARGATE",
    "FARGATE_SPOT"
]

You can also inspect the default capacity provider strategy to see exactly how tasks will be distributed:

aws ecs describe-clusters \
  --clusters my-ecs-cluster \
  --query 'clusters[0].defaultCapacityProviderStrategy'

The output shows the complete strategy configuration:

[
    {
        "capacityProvider": "FARGATE",
        "weight": 1,
        "base": 0
    }
]

To compare different cluster configurations side by side, you can inspect multiple clusters in a single command. This is particularly useful when you're experimenting with different strategies:

aws ecs describe-clusters \
  --clusters my-ecs-cluster cost-optimized-cluster \
  --query 'clusters[*].{Name:clusterName,Providers:capacityProviders,Strategy:defaultCapacityProviderStrategy}'

This query returns a comparison view showing the cluster name, available capacity providers, and default strategy for each cluster. When you're planning deployments, always check these settings to ensure your cluster configuration matches your application's requirements for cost, reliability, and performance.

You can modify capacity provider configurations on existing clusters using the put-cluster-capacity-providers command. This is useful when your application requirements change or you want to adjust cost optimization strategies.

aws ecs put-cluster-capacity-providers \
  --cluster my-ecs-cluster \
  --capacity-providers FARGATE FARGATE_SPOT \
  --default-capacity-provider-strategy capacityProvider=FARGATE_SPOT,weight=2 \
  --default-capacity-provider-strategy capacityProvider=FARGATE,weight=1

This command updates my-ecs-cluster to use a 2:1 ratio favoring FARGATE_SPOT over standard FARGATE. Changes take effect immediately for new tasks, but existing running tasks continue using their original capacity provider.

Important: Plan capacity provider updates during maintenance windows, as they can impact running services that depend on specific capacity provider configurations.

In this lesson, you've learned the fundamental differences between Fargate and EC2 launch types, and mastered capacity providers for flexible resource allocation strategies. You've gained hands-on experience creating clusters with specific capacity provider configurations and inspecting them using AWS CLI commands.

You can now create clusters that balance cost optimization with reliability requirements, using strategies that mix standard Fargate with Spot pricing. You understand capacity provider strategies, including base allocations and weight distributions, and can troubleshoot common configuration issues.

In the upcoming practice exercises, you'll apply these concepts by running actual tasks and services that use your configured capacity providers. You'll learn how to override the default strategy for specific workloads and see how ECS distributes tasks according to your capacity provider rules.