Study guide
Technical reference and lesson notes
Launch an ECS EC2 Task with an Application Load Balancer
Purpose of This Lesson
This hands-on lesson demonstrates how to launch an Engine X web container on an Amazon ECS cluster using the EC2 launch type, validate that the task can run, and then place an Application Load Balancer (ALB) in front of the service.
The workflow is:
- Create an ECS task definition.
- Run a standalone task to verify compatibility with the cluster.
- Stop the test task.
- Create an ECS service with two task replicas and an ALB.
- Validate access through the ALB DNS name.
- Clean up the service, cluster, load balancer, and supporting resources.
This is especially relevant to CloudOps scenarios that require selecting the correct ECS launch type, configuring task resources, exposing a containerized web application, and troubleshooting deployment behavior.
Key Concepts
ECS task definition
A task definition describes how ECS should run one or more containers. In this lesson, the definition includes:
- Family name:
Engine X-task - Launch type: Amazon EC2 instances only
- Operating system and architecture: Linux X86_64
- Network mode:
awsvpc - Task size:
0.25vCPU and0.5GB memory - Container name:
Engine X - Container image:
Engine X:latestfrom a Docker registry - Container port: TCP port 80
A task definition revision is created whenever the definition is changed. When launching a task or creating a service, the selected family and revision determine the exact configuration ECS uses.
Task role versus task execution role
The task role grants application containers permission to call AWS APIs. This exercise does not require a task role because the web container does not need to access other AWS services.
The task execution role is used by ECS to perform actions needed to start the task, such as retrieving the image and handling other ECS-managed operations. The console selects an execution role for the task definition.
Do not treat these roles as interchangeable: the task role is for the application, while the execution role is for ECS task startup and management operations.
ECS EC2 launch type
With the EC2 launch type, tasks run on container instances that belong to the ECS cluster. The cluster in the lab contains two EC2 container instances, allowing two task replicas to be distributed across the instances.
The task definition must be compatible with the available instance capacity. The lesson uses a small task size because the underlying instances are T2 micro instances.
awsvpc networking
The task uses the awsvpc network mode. This provides task-level networking within a VPC, but the task tested in the lesson does not receive a public IP address. Therefore, directly connecting to the task from the public internet is not the intended access path.
The ALB provides the public-facing entry point and forwards HTTP traffic to the container on port 80.
ECS service
An ECS service maintains the desired number of running tasks and manages their deployment. It also integrates the tasks with a load balancer.
In this lesson, the service is configured to:
- Use the EC2 launch type.
- Run two task replicas.
- Use an Application Load Balancer.
- Create a listener on HTTP port 80.
- Register tasks in a target group named
MyTG ECS. - Forward traffic to the container on port 80.
- Use a web-access security group allowing port 80 from any source address.
Application Load Balancer and target group
The ALB receives client requests through its listener and forwards them to healthy task targets in the target group. The load balancer is created with a DNS name that can be used to test the application.
The important port relationship in this lab is:
Client -> ALB listener: HTTP 80 -> target group: HTTP 80 -> Engine X container: port 80
ECS EC2 Deployment and Validation Workflow
1. Create the task definition
In the ECS console, create a new task definition family and select Amazon EC2 instances only. Configure Linux X86_64, awsvpc, and the small task size of 0.25 vCPU and 0.5 GB memory.
Define the Engine X container using the Engine X:latest image and expose container port 80. Logging is not required for this exercise, so log collection can be removed before creating the definition.
2. Run a standalone task first
Before creating the service, run one task using the EC2 launch type. This is a useful compatibility check: if the task reaches the Running state, the task definition is compatible enough with the cluster resources and configuration for this test.
The task is not expected to be directly reachable through a public IP in this setup. The purpose of this step is to validate task startup, not public application access.
3. Stop the test task
After confirming that the task reaches the Running state, stop it. The service will later create and maintain its own task replicas.
4. Create the ECS service
Create a service from the task definition family and appropriate revision. Select the EC2 launch type and configure two replica tasks. The lesson leaves the default deployment options in place rather than using a blue/green deployment.
Select the web-access security group, create an Application Load Balancer, and configure a new HTTP listener and target group on port 80. Leave service auto scaling disabled for this lab; it could otherwise be configured using target tracking or step scaling based on performance metrics.
5. Validate the deployment
Deployment can take several minutes. Check the ALB in the EC2 console, inspect the target group, and confirm that tasks are registering as targets. Once the load balancer is active and a task is available, open the ALB DNS name in a browser.
A successful Engine X web page confirms the end-to-end path:
- The service launched the tasks.
- The tasks registered with the target group.
- The ALB listener accepted the request.
- The ALB forwarded the request to the container on port 80.
AWS Systems Manager and ECS Container Instance Inspection
AWS Systems Manager Session Manager can provide shell access to the EC2 container instances without requiring a separate remote-access workflow in the lab.
The lesson uses Fleet Manager and Session Manager to select an instance and start a session. If Systems Manager has not been configured, the console can enable Default Host Management Configuration and create a recommended role so the required permissions are available to the container instances.
From the instance command line, the lesson inspects the ECS configuration file with:
cat /etc/ecs/ecs.config
The ECS configuration file includes the cluster name. For manually registering ECS container instances, the instances need the necessary permissions, the ECS agent, and a configuration that identifies the cluster.
The Session Manager Terminate action ends the session; it does not terminate the EC2 instance. This terminology can be misleading during operational work.
Exam- or Assessment-Relevant Takeaways
- Use an ECS task definition to specify container image, ports, resource requirements, network mode, and roles.
- Use the EC2 launch type when tasks must run on ECS container instances in an EC2-backed cluster.
- Match task resource requirements to the capacity available on the container instances. The lab deliberately uses
0.25vCPU and0.5GB memory for T2 micro instances. - A task reaching the Running state validates startup compatibility, but it does not prove public reachability.
- With
awsvpcin this setup, do not assume the task has a public IP address. Use an ALB for client access. - An ECS service maintains the desired task count and integrates tasks with the load balancer.
- An ALB listener and target group must route to the container’s exposed port, which is port 80 in this exercise.
- Distinguish the task role from the task execution role. The application does not need a task role here, while ECS still uses an execution role.
- If tasks are running but the application is inaccessible, inspect the ALB, listener, target group, target registration, and security group rather than assuming the task definition is invalid.
- Cleanup is part of the operational workflow: delete the service, remove the cluster and its associated resources, and ensure the load balancer is removed.
Tool / Feature Decision Guide
| Requirement | Feature or choice | Why |
|---|---|---|
| Run containers on the existing EC2-backed ECS cluster | EC2 launch type | The tasks must be placed on the cluster’s container instances. |
| Allow the containerized web application to make AWS API calls | Task role | This grants permissions to the application inside the container. It is unnecessary for this lab. |
| Allow ECS to perform task startup operations | Task execution role | This supports ECS-managed operations such as starting the task and retrieving the image. |
| Confirm task-definition and cluster compatibility before exposing the app | Standalone task | Reaching Running is a focused startup validation. |
| Provide client access to tasks without relying on a task public IP | Application Load Balancer | The ALB supplies a listener and forwards traffic to registered task targets. |
| Maintain multiple running copies of the task | ECS service with replica tasks | The service maintains the desired task count. |
| Adjust task count automatically based on metrics | Service auto scaling | The lesson identifies target tracking and step scaling as available approaches, but does not enable them. |
| Inspect an EC2 container instance | Systems Manager Session Manager | It provides command-line access for operational inspection. |
| End a Session Manager connection | Terminate the session | This ends the session only; it does not terminate the instance. |
Common Traps / Misconceptions
- A Running task is automatically publicly reachable. Not in this configuration. The task does not receive a public IP, so the ALB is needed for access.
- The task role and execution role are the same. They serve different principals and purposes.
- A standalone task provides service-level availability. A standalone task is a test run. Use an ECS service to maintain a desired number of replicas.
- The ALB listener port and container port can be ignored. The listener, target group, host-side routing, and container port must align with the intended HTTP path.
- Two desired tasks guarantee one task per EC2 instance. The lesson configures two replicas for two container instances, but task placement is still managed by ECS and the defaults are left in place.
- Session Manager’s Terminate action destroys the EC2 instance. It only terminates the management session.
- Deleting the service completes all cleanup. The service stops tasks, but the cluster, load balancer, target group, and EC2-backed resources must also be checked and removed as appropriate.
- The latest task-definition revision is always the correct one. When definitions are edited, select the revision that contains the required configuration.
Real-World Engineer / Analyst Notes
- Validate in stages. First prove that the task can start, then introduce the service and load balancer. This narrows troubleshooting scope.
- Check resource capacity early when using the EC2 launch type. A task definition can be syntactically valid but remain pending if the cluster lacks suitable capacity.
- During an ALB deployment, inspect both control-plane state and data-plane behavior: confirm the load balancer is active, verify target registration, and then test the DNS endpoint.
- Security groups are part of the traffic path. The lab uses a web-access security group permitting port 80 from any source, but production designs should apply narrower access where possible.
- Avoid relying on the
latestimage tag for controlled production releases. The lesson uses it for convenience; operationally, an explicit image version makes deployments easier to reproduce. - Treat cleanup as a deliberate checklist. Services, tasks, load balancers, target groups, EC2 container instances, and CloudFormation-managed resources can all contribute to ongoing cost or configuration drift.
- When inspecting a manually registered ECS container instance, verify the ECS agent, permissions, and
/etc/ecs/ecs.config, including the cluster name.
Quick Reference Summary
Task definition family: Engine X-task
Launch type: EC2 instances only
OS/architecture: Linux X86_64
Network mode: awsvpc
Task size: 0.25 vCPU / 0.5 GB memory
Container image: Engine X:latest
Container port: 80
Service replicas: 2
Load balancer: Application Load Balancer
Listener: HTTP 80
Target group: MyTG ECS, HTTP 80
Validation: Open the ALB DNS name
Inspection: AWS Systems Manager Session Manager
Cleanup: Delete service, remove cluster/resources, verify ALB removal
Flashcards
Q: A task definition must run on the existing EC2-backed ECS cluster. Which launch type should be selected?
A: Select Amazon EC2 instances only. This places tasks on the cluster’s registered EC2 container instances.
Q: Why does this lab use 0.25 vCPU and 0.5 GB memory for the task?
A: The cluster uses T2 micro instances with limited capacity. The smaller task size is chosen so the Engine X container can fit on that infrastructure.
Q: What is the purpose of running a standalone ECS task before creating the service?
A: It verifies that the task definition can start successfully on the cluster. Reaching Running validates startup compatibility but not public connectivity.
Q: A task is Running, but clients cannot connect directly to it over the internet. What is the decisive explanation in this lab?
A: The task uses awsvpc but does not have a public IP address. Client access is provided through the Application Load Balancer instead.
Q: When should an ECS service be used instead of a standalone task?
A: Use a service when ECS must maintain a desired number of task replicas and optionally integrate them with a load balancer.
Q: What does the task role allow, and why is it omitted here?
A: It allows application containers to call AWS APIs. The Engine X web container in this exercise does not need access to other AWS services.
Q: How does the task execution role differ from the task role?
A: The execution role supports ECS-managed task startup operations, while the task role supplies AWS permissions to the application running inside the container.
Q: A service needs to expose an HTTP container on port 80. What ALB configuration is used?
A: Create an ALB with an HTTP port 80 listener and a target group forwarding HTTP port 80 to the task container.
Q: Why create two service replicas in a cluster with two container instances?
A: Two replicas provide two running task copies and allow ECS to place them across the available container instances according to its placement behavior.
Q: Which feature should be selected to adjust the desired task count from performance metrics?
A: ECS service auto scaling. The lesson identifies target tracking and step scaling as possible strategies but leaves auto scaling disabled.
Q: How can an operator inspect the ECS cluster configuration on a container instance?
A: Use Systems Manager Session Manager to access the instance, then inspect /etc/ecs/ecs.config, including the configured cluster name.
Q: What is the operational trap when clicking Terminate in Session Manager?
A: It terminates the Session Manager connection, not the EC2 instance itself.
Q: A service deployment is still in progress. Which checks help confirm whether the ALB path is working?
A: Confirm the ALB is active, inspect the target group for registered tasks, and test the ALB DNS name once a target is available.
Q: What should be removed after completing this lab?
A: Delete the ECS service, stop its tasks, remove the cluster and associated resources, and verify that the load balancer and container instances are also gone.
Practice Questions
Question 1
An ECS task definition reaches the Running state on an EC2-backed cluster, but opening the task’s network address from the internet is not possible. The task uses awsvpc and has no public IP. What should the engineer use for client access?
A. A task role
B. An Application Load Balancer
C. A new task-definition revision
D. Systems Manager Session Manager
Correct answer: B. An Application Load Balancer
Explanation: The task is running, but it lacks a public IP. An ALB provides the listener and forwards traffic to the task through its target group.
Question 2
An engineer wants ECS to keep two copies of an Engine X container running and expose them through HTTP. Which configuration best matches the lesson?
A. Run two unrelated standalone tasks with no load balancer
B. Create an ECS service with two replica tasks, an HTTP 80 listener, and a port 80 target group
C. Create a task role and assign it to the ALB
D. Use Session Manager as the public web endpoint
Correct answer: B. Create an ECS service with two replica tasks, an HTTP 80 listener, and a port 80 target group
Explanation: The ECS service maintains the desired task count and integrates the tasks with the ALB and target group.
Question 3
The application inside a task must call AWS APIs, but ECS itself also needs permissions to retrieve the image and start the task. Which roles should be considered?
A. Use only the task role for both purposes
B. Use only the execution role for both purposes
C. Use a task role for application API calls and an execution role for ECS startup operations
D. Use the ALB security group as the IAM role
Correct answer: C. Use a task role for application API calls and an execution role for ECS startup operations
Explanation: The task role belongs to the application, while the execution role is used by ECS for task startup and management actions.
Question 4
A deployment appears slow. The ALB is active, but the engineer wants to determine whether tasks have become available targets before testing the endpoint. Where should the engineer look?
A. The EC2 target group and its registered targets
B. The task role policy only
C. The Session Manager termination history
D. The task family name only
Correct answer: A. The EC2 target group and its registered targets
Explanation: The target group shows whether tasks have registered behind the ALB. The lesson uses this check before opening the ALB DNS name.
Question 5
After the lab, the engineer deletes the ECS service but wants to avoid leaving billable or unwanted resources behind. What is the next appropriate cleanup approach?
A. Delete only the task-definition family
B. Delete the cluster and verify that the ALB and container instances are removed
C. Terminate a Session Manager session
D. Change the listener from HTTP to HTTPS
Correct answer: B. Delete the cluster and verify that the ALB and container instances are removed
Explanation: Deleting the service stops its tasks, but the cluster, load balancer, target group, and EC2 container instances still require cleanup. The lesson notes that cluster deletion removes the associated CloudFormation-managed resources.
WordPress Metadata
Suggested Slug:
ecs-ec2-task-application-load-balancer
Meta Description:
Study how to define, validate, and expose an Amazon ECS EC2 task running Engine X through an Application Load Balancer, including networking, roles, deployment, and cleanup.
Tags:
AWS ECS, Amazon EC2, ECS task definitions, ECS services, Application Load Balancer, AWS VPC networking, ECS task placement, AWS Systems Manager, Session Manager, CloudFormation