Deploying Continuous Services

Introduction: From Task Definitions to Running Services

In the previous lesson, you registered a task definition, which serves as a blueprint for your containerized web application. However, a task definition is just a plan; it doesn't run anything on its own. To bring your application to life, you need an ECS Service, which takes your blueprint and transforms it into a continuously running application. The key difference between running a single task and deploying a service lies in persistence and automation. A single task runs once and stops, like a batch job. A service, on the other hand, maintains your desired state continuously. It ensures your specified number of tasks is always running by automatically replacing failed tasks, handling rolling deployments when you update your application, and integrating with load balancers for traffic distribution. This self-healing capability is essential for production-grade applications. In this lesson, you'll deploy your my-web-task definition as a service named my-web-service on your Fargate cluster. You will configure the necessary networking to connect your container to the internet, monitor the deployment process, and learn to manage the service lifecycle, including scaling and cleanup. By the end, you'll have a fully operational web service running on AWS, capable of maintaining high availability.

Understanding Fargate Service Requirements

Join the 1M+ learners on CodeSignal

Be a part of our community of 1M+ users who develop and demonstrate their skills on CodeSignal

Gathering Network Configuration Details

Before creating your service, you need to identify the specific networking components that Fargate will use to deploy your tasks. This includes finding suitable subnets within your VPC and identifying security groups that allow the appropriate network traffic for your web application.

Your AWS account includes a default VPC that comes pre-configured with public subnets in multiple availability zones. These subnets are perfect for Fargate tasks that need internet access. You can discover your default VPC subnets using the AWS CLI with a query that filters for public subnets and extracts their subnet IDs.

Shell

# Find public subnets in your default VPC
aws ec2 describe-subnets \
  --filters "Name=default-for-az,Values=true" \
  --query 'Subnets[*].SubnetId' \
  --output text

# Find public subnets in your default VPC
aws ec2 describe-subnets \
  --filters "Name=default-for-az,Values=true" \
  --query 'Subnets[*].SubnetId' \
  --output text

This command returns a space-separated list of subnet IDs that look like subnet-xxxxxxxx subnet-yyyyyyyy. These represent public subnets in different availability zones within your default VPC. Using multiple subnets provides redundancy — if one availability zone experiences issues, your service can place replacement tasks in other zones.

For security groups, you need one that allows inbound traffic on port 3000, which is the port your web application exposes. Your default VPC includes a default security group, but it typically only allows traffic from other resources within the same security group. You can find your default security group and check its rules using these commands:

Shell

# Find your default security group
aws ec2 describe-security-groups \
  --filters "Name=group-name,Values=default" \
  --query 'SecurityGroups[0].GroupId' \
  --output text

# Find your default security group
aws ec2 describe-security-groups \
  --filters "Name=group-name,Values=default" \
  --query 'SecurityGroups[0].GroupId' \
  --output text

The output will be a security group ID like sg-zzzzzzzz. For a web application that needs to accept traffic from the internet, you would typically create a custom security group with an inbound rule allowing TCP traffic on port 3000 from anywhere (0.0.0.0/0). However, for this lesson, we'll use the existing default security group to keep the focus on service deployment rather than security group management.

When you create your service, you'll need to format these networking details into the specific syntax that the create-service command expects. The network configuration uses a nested structure that specifies the subnets array, security groups array, and public IP assignment setting, all within an awsvpcConfiguration object.

Creating Your First ECS Service

With your networking information gathered, you're ready to create your first ECS service that will run your web application continuously. The aws ecs create-service command brings together your cluster, task definition, and networking configuration to deploy a managed service that maintains your desired application state.

Shell

# Create the ECS service
aws ecs create-service \
  --cluster my-ecs-cluster \
  --service-name my-web-service \
  --task-definition my-web-task \
  --desired-count 1 \
  --launch-type FARGATE \
  --platform-version LATEST \
  --network-configuration "awsvpcConfiguration={subnets=[<subnet-xxxxxxxx>,<subnet-yyyyyyyy>],securityGroups=[<sg-zzzzzzzz>],assignPublicIp=ENABLED}"

# Create the ECS service
aws ecs create-service \
  --cluster my-ecs-cluster \
  --service-name my-web-service \
  --task-definition my-web-task \
  --desired-count 1 \
  --launch-type FARGATE \
  --platform-version LATEST \
  --network-configuration "awsvpcConfiguration={subnets=[<subnet-xxxxxxxx>,<subnet-yyyyyyyy>],securityGroups=[<sg-zzzzzzzz>],assignPublicIp=ENABLED}"

Each parameter in this command serves a specific purpose in defining your service configuration. Let's break down the key components:

Core Service Definition: You specify the --cluster (my-ecs-cluster) to host the service and give it a unique --service-name (my-web-service). The --task-definition (my-web-task) points to the blueprint for your container, and --desired-count 1 tells ECS to maintain exactly one running instance of that task.
Fargate Configuration: The --launch-type FARGATE explicitly instructs ECS to use serverless infrastructure. Using --platform-version LATEST ensures your service benefits from the most recent Fargate capabilities, including the latest security patches and feature updates.
Networking: The --network-configuration is critical for Fargate. The awsvpcConfiguration object contains three key elements: the subnets array lists the subnet IDs where tasks can be placed, the securityGroups array applies network access rules, and assignPublicIp=ENABLED ensures your tasks receive public IP addresses for internet connectivity.

When you execute this command successfully, ECS returns a detailed JSON response describing your newly created service. The response includes the service ARN, current status, and configuration details. Initially, your service will show a status of ACTIVE with a runningCount of 0 and a pendingCount of 1, indicating that ECS is in the process of starting your first task.

{
    "service": {
        "serviceArn": "arn:aws:ecs:us-east-1:123456789012:service/my-ecs-cluster/my-web-service",
        "serviceName": "my-web-service",
        "clusterArn": "arn:aws:ecs:us-east-1:123456789012:cluster/my-ecs-cluster",
        "status": "ACTIVE",
        "runningCount": 0,
        "pendingCount": 1,
        "desiredCount": 1,
        "taskDefinition": "arn:aws:ecs:us-east-1:123456789012:task-definition/my-web-task:1",
        "launchType": "FARGATE"
    }
}

{
    "service": {
        "serviceArn": "arn:aws:ecs:us-east-1:123456789012:service/my-ecs-cluster/my-web-service",
        "serviceName": "my-web-service",
        "clusterArn": "arn:aws:ecs:us-east-1:123456789012:cluster/my-ecs-cluster",
        "status": "ACTIVE",
        "runningCount": 0,
        "pendingCount": 1,
        "desiredCount": 1,
        "taskDefinition": "arn:aws:ecs:us-east-1:123456789012:task-definition/my-web-task:1",
        "launchType": "FARGATE"
    }
}

This output confirms that your service has been created successfully and ECS has begun the process of deploying your containerized application.

Monitoring Service Status and Health

After creating your service, ECS begins an orchestrated deployment process that involves several steps: provisioning Fargate infrastructure, pulling your container image from ECR, starting the container, and performing health checks. You can monitor this process using the describe-services command to track your service's progress and ensure everything deploys correctly.

Shell

# Check service status
aws ecs describe-services \
  --cluster my-ecs-cluster \
  --services my-web-service \
  --query 'services[0].status'

# Check service status
aws ecs describe-services \
  --cluster my-ecs-cluster \
  --services my-web-service \
  --query 'services[0].status'

This command focuses specifically on the service status, which will return "ACTIVE" when your service is running normally. However, the service status alone doesn't tell you whether your tasks are actually running successfully. The service can be ACTIVE while tasks are still starting up or experiencing issues.

To get a more complete picture of your deployment, you can examine the full service description without the query filter:

Shell

# Get detailed service information
aws ecs describe-services \
  --cluster my-ecs-cluster \
  --services my-web-service

# Get detailed service information
aws ecs describe-services \
  --cluster my-ecs-cluster \
  --services my-web-service

This returns comprehensive information about your service, including task counts, deployment status, and any events that occurred during the deployment process. Pay particular attention to the runningCount, pendingCount, and desiredCount fields. A healthy service will show runningCount equal to desiredCount with pendingCount at zero.

{
    "services": [
        {
            "serviceName": "my-web-service",
            "status": "ACTIVE",
            "runningCount": 1,
            "pendingCount": 0,
            "desiredCount": 1,
            "deployments": [
                {
                    "status": "PRIMARY",
                    "taskDefinition": "arn:aws:ecs:us-east-1:123456789012:task-definition/my-web-task:1",
                    "desiredCount": 1,
                    "runningCount": 1
                }
            ]
        }
    ]
}

{
    "services": [
        {
            "serviceName": "my-web-service",
            "status": "ACTIVE",
            "runningCount": 1,
            "pendingCount": 0,
            "desiredCount": 1,
            "deployments": [
                {
                    "status": "PRIMARY",
                    "taskDefinition": "arn:aws:ecs:us-east-1:123456789012:task-definition/my-web-task:1",
                    "desiredCount": 1,
                    "runningCount": 1
                }
            ]
        }
    ]
}

The deployments array shows the current deployment status. A PRIMARY deployment with runningCount equal to desiredCount indicates that your service has successfully deployed and is running as expected. If you see issues during deployment, the events array in the full service description will contain detailed messages about what went wrong, such as image pull failures, networking issues, or resource constraints.

During the initial deployment, it's normal to see the pendingCount remain at 1 for several minutes while Fargate provisions infrastructure and pulls your container image. The exact time depends on your image size and current AWS capacity, but most deployments complete within 2–5 minutes.

Managing Service Lifecycle

Once your service is running, you'll need to understand how to manage its lifecycle, including scaling operations and proper cleanup procedures. ECS services are designed to maintain their desired state continuously, so any changes you make should be done through service updates rather than direct task manipulation.

To scale your service up or down, you modify the desired count using the update-service command. This is useful when you need to handle increased traffic or reduce costs during low-usage periods. For example, if you wanted to run two instances of your web application for higher availability, you would update the desired count:

Shell

# Scale service to 2 instances (example - don't run this now)
aws ecs update-service \
  --cluster my-ecs-cluster \
  --service my-web-service \
  --desired-count 2

# Scale service to 2 instances (example - don't run this now)
aws ecs update-service \
  --cluster my-ecs-cluster \
  --service my-web-service \
  --desired-count 2

When you increase the desired count, ECS automatically starts additional tasks to meet the new target. When you decrease it, ECS gracefully stops excess tasks while maintaining the specified number of running instances.

For proper service cleanup, you must follow a two-step process. First, you scale the service down to zero instances, which stops all running tasks but keeps the service definition intact. Then, you delete the service entirely. This two-step approach ensures that all tasks are properly terminated before the service is removed.

Shell

# Delete the ECS service (set --force-new-deployment if needed)
aws ecs update-service \
  --cluster my-ecs-cluster \
  --service my-web-service \
  --desired-count 0

# Delete the ECS service (set --force-new-deployment if needed)
aws ecs update-service \
  --cluster my-ecs-cluster \
  --service my-web-service \
  --desired-count 0

This command tells ECS to stop all running tasks for your service. You'll see the runningCount decrease to zero as ECS gracefully terminates each task. Once all tasks have stopped, you can delete the service definition:

Shell

aws ecs delete-service \
  --cluster my-ecs-cluster \
  --service my-web-service \
  --force

aws ecs delete-service \
  --cluster my-ecs-cluster \
  --service my-web-service \
  --force

The --force flag allows you to delete the service even if it has a desired count greater than zero or if there are still tasks in the process of stopping. Without this flag, you would need to wait until the desired count is zero and all tasks have fully terminated before the delete operation would succeed.

After deletion, the service no longer exists in your cluster, and ECS will not attempt to maintain any tasks based on that service configuration. However, your task definition remains registered and available for creating new services or running individual tasks in the future.

Deploying Continuous Services

Introduction: From Task Definitions to Running Services

Understanding Fargate Service Requirements

Join the 1M+ learners on CodeSignal

Gathering Network Configuration Details

Creating Your First ECS Service

Monitoring Service Status and Health

Managing Service Lifecycle

Summary and Preparing for Practice