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.
Deploying a service on Fargate requires several specific configuration elements that differ from traditional server-based deployments. Since Fargate is a serverless container platform, it needs explicit instructions about networking, resource allocation, and platform compatibility to provision the right infrastructure for your containers.
The most critical requirement for Fargate services is networking configuration. Remember from your task definition that you specified networkMode: "awsvpc", which gives each task its own elastic network interface with a private IP address. This network isolation provides security benefits, but it also means that Fargate needs to know exactly where to place your tasks within your AWS network infrastructure. You must specify which VPC subnets to use for task placement and which security groups to apply for network access control.
Fargate also requires you to specify a platform version, which determines the underlying infrastructure capabilities available to your tasks. The LATEST platform version is typically the best choice, as it provides access to the newest features and security updates. However, in production environments, you might choose to pin to a specific platform version for consistency across deployments.
The desired count parameter tells ECS how many instances of your task should be running simultaneously. Setting this to 1 means you want exactly one copy of your web application running at all times. If that task fails or stops for any reason, ECS will automatically start a replacement to maintain your desired state. For production applications, you would typically set this to 2 or higher to ensure high availability, but for learning purposes, a single instance is sufficient.
Another important consideration is the assignPublicIp setting. Since your web application needs to be accessible from the internet, and your container image needs to be pulled from ECR, your tasks need internet connectivity. When you place tasks in public subnets and enable assignPublicIp=ENABLED, each task receives a public IP address that allows both inbound and outbound internet access. This is essential for web applications that serve external traffic.
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.
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:
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.
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.
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 1tells ECS to maintain exactly one running instance of that task. - Fargate Configuration: The
--launch-type FARGATEexplicitly instructs ECS to use serverless infrastructure. Using--platform-version LATESTensures your service benefits from the most recent Fargate capabilities, including the latest security patches and feature updates. - Networking: The
--network-configurationis critical for Fargate. TheawsvpcConfigurationobject contains three key elements: thesubnetsarray lists the subnet IDs where tasks can be placed, thesecurityGroupsarray applies network access rules, andassignPublicIp=ENABLEDensures 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.
This output confirms that your service has been created successfully and ECS has begun the process of deploying your containerized application.
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.
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:
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.
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.
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:
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.
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:
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.
You have now completed the full journey from infrastructure setup to running a production-ready containerized web application on AWS Fargate. You started by creating an ECS cluster, then built a comprehensive task definition with ECR integration and CloudWatch logging, and finally deployed it as a continuously running service with the correct networking configuration. This represents a significant milestone in container orchestration.
The my-web-service you created is more than just a running container; it's a managed application that automatically maintains its desired state and replaces failed tasks. You also learned the essential commands for managing its lifecycle—creating, monitoring, scaling, and deleting. This operational knowledge is critical for managing containerized applications in production, allowing you to respond to changing demands and troubleshoot issues by interpreting deployment events and service status.
In the upcoming practice exercises, you will apply these concepts hands-on. You'll create your own services, experiment with different configurations, and practice the monitoring and management techniques covered in this lesson. This will give you the confidence to manage the complete lifecycle of ECS services on Fargate using real networking components in your AWS account.
