Fargate serverless containers in AWS - Mini Project: Build & Apply

Fargate Serverless Containers

📖 Scenario: You are working for a small company that wants to run a simple web application without managing servers. AWS Fargate lets you run containers without worrying about the underlying servers.In this project, you will create a basic AWS ECS Fargate task definition and service configuration to run a containerized web app.

🎯 Goal: Build a minimal AWS ECS Fargate task definition and service configuration using JSON format. This will define a container running a simple web server image and configure it to run serverless on Fargate.

📋 What You'll Learn

Create an ECS task definition JSON with one container named webapp

Set the container image to nginx:latest

Specify CPU and memory requirements for the task

Configure the network mode to awsvpc

Add a service configuration referencing the task definition

Set the desired count of tasks to 1

💡 Why This Matters

🌍 Real World

Many companies use AWS Fargate to run containerized applications without managing servers, making deployment easier and scalable.

💼 Career

Understanding how to define ECS Fargate tasks and services is essential for cloud engineers and DevOps professionals working with containerized applications on AWS.

1

Create ECS Task Definition Basic Structure

Create a JSON object called task_definition with keys family set to fargate-webapp and networkMode set to awsvpc. Also add requiresCompatibilities as a list containing FARGATE.

AWS

{
  "family": "fargate-webapp",
  "networkMode": "awsvpc",
  "requiresCompatibilities": [
    "FARGATE"
  ]
  # Your code here
}

Hint

Use the keys exactly as family, networkMode, and requiresCompatibilities.

2

Add Container Definitions with Image and Resources

Add a key containerDefinitions with a list containing one container object. The container object must have name set to webapp, image set to nginx:latest, cpu set to 256, and memory set to 512.

AWS

{
  "family": "fargate-webapp",
  "networkMode": "awsvpc",
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "containerDefinitions": [
    {
      "name": "webapp",
      "image": "nginx:latest",
      "cpu": 256,
      "memory": 512
      # Your code here
    }
  ]
}

Hint

Remember to put the container details inside a list under containerDefinitions.

3

Add Task CPU and Memory Requirements

Add keys cpu set to 256 and memory set to 512 at the root level of the task_definition JSON.

AWS

{
  "family": "fargate-webapp",
  "networkMode": "awsvpc",
  "requiresCompatibilities": [
    "FARGATE"
  ],
  "containerDefinitions": [
    {
      "name": "webapp",
      "image": "nginx:latest",
      "cpu": 256,
      "memory": 512
    }
  ],
  "cpu": "256",
  "memory": "512"
  # Your code here
}

Hint

Task-level CPU and memory must be strings, not numbers.

4

Create ECS Service Configuration

Create a JSON object called service_definition with keys name set to webapp-service, taskDefinition set to fargate-webapp, desiredCount set to 1, and launchType set to FARGATE.

AWS

{
  "name": "webapp-service",
  "taskDefinition": "fargate-webapp",
  "desiredCount": 1,
  "launchType": "FARGATE"
  # Your code here
}

Hint

Use exact key names and values as specified.

Practice

1. What is the main benefit of using AWS Fargate for running containers?

easy

A. You have to configure virtual machines yourself.

B. You must manually scale the containers.

C. You need to install and maintain the operating system.

D. You don't need to manage servers or clusters.

Solution

1. Step 1: Understand Fargate's serverless nature

   AWS Fargate runs containers without requiring you to manage the underlying servers or clusters.

2. Step 2: Compare options

   The other options describe manual management tasks that Fargate removes for you.

3. Final Answer:

   You don't need to manage servers or clusters. -> Option D

4. Quick Check:

   Serverless container management = A [OK]

Hint: Fargate means no server management needed [OK]

Common Mistakes:

• Thinking you must manage servers manually
• Confusing Fargate with EC2 instances
• Assuming you handle OS updates

2. Which of the following is the correct way to specify CPU and memory for a Fargate task definition?

easy

A. "cpu": 512, "memory": 1024

B. "cpu": "512", "memory": "1024"

C. "cpu": "0.5", "memory": "1GB"

D. "cpu": "512MB", "memory": "1GB"

Solution

1. Step 1: Check Fargate task definition format

   Fargate expects CPU and memory as strings representing CPU units and MiB memory, e.g., "512" and "1024".

2. Step 2: Evaluate options

   "cpu": "512", "memory": "1024" uses strings with numeric values, which is correct. Using numbers instead of strings is incorrect. Decimal values for CPU or units like GB/MB are invalid.

3. Final Answer:

   "cpu": "512", "memory": "1024" -> Option B

4. Quick Check:

   CPU and memory as strings = B [OK]

Hint: CPU and memory must be strings in task definition [OK]

Common Mistakes:

• Using numbers instead of strings
• Adding units like MB or GB
• Using decimal numbers for CPU

3. Given this Fargate task definition snippet:

{"cpu": "256", "memory": "512", "containerDefinitions": [{"name": "app", "image": "myapp:latest"}]}

What happens if you try to run this task with 1024 MiB memory requested in the service?

medium

A. The task runs with 512 MiB memory as defined in the task.

B. The task runs but may be terminated if it exceeds 512 MiB.

C. The task fails to start due to memory mismatch.

D. The service overrides the task memory to 1024 MiB automatically.

Solution

1. Step 1: Understand memory settings in Fargate

   Memory is defined in the task definition and must match the service configuration; mismatches cause failures.

2. Step 2: Analyze the mismatch

   The task requests 512 MiB, but the service requests 1024 MiB, causing a conflict and preventing the task from starting.

3. Final Answer:

   The task fails to start due to memory mismatch. -> Option C

4. Quick Check:

   Memory mismatch causes failure = D [OK]

Hint: Task and service memory must match exactly [OK]

Common Mistakes:

• Assuming service overrides task memory
• Thinking task runs with lower memory
• Ignoring mismatch errors

4. You created a Fargate service but the tasks keep failing with "RESOURCE:MEMORY" errors. What is the most likely cause?

medium

A. The task definition requests more memory than the Fargate platform allows.

B. The container image is missing from the registry.

C. The service is not attached to a load balancer.

D. The CPU units are set too high.

Solution

1. Step 1: Understand RESOURCE:MEMORY errors

   This error means the task requested more memory than available or allowed by Fargate limits.

2. Step 2: Evaluate other options

   Missing images cause different errors, load balancer issues don't cause memory errors, and CPU settings affect CPU, not memory.

3. Final Answer:

   The task definition requests more memory than the Fargate platform allows. -> Option A

4. Quick Check:

   Memory error means memory request too high = C [OK]

Hint: Memory errors usually mean request exceeds limits [OK]

Common Mistakes:

• Blaming missing container images
• Confusing CPU and memory errors
• Ignoring platform memory limits

5. You want to run a web app on Fargate that needs 2 containers: one for the app and one for logging. How should you configure the task definition to ensure both containers run together and share CPU and memory?

hard

A. Define both containers in the same task definition with combined CPU and memory settings.

B. Create two separate task definitions and run two Fargate services.

C. Run one container on Fargate and the other on EC2 instances.

D. Use one container and add logging as a sidecar process inside it.

Solution

1. Step 1: Understand multi-container tasks in Fargate

   Fargate supports multiple containers in one task definition sharing CPU and memory.

2. Step 2: Evaluate options for running two containers together

   Defining both containers in the same task definition with combined CPU and memory settings ensures they run together and share resources. Separating into different task definitions or services loses shared resource benefits and co-location. Adding logging as a sidecar process inside the app mixes concerns, which is not best practice.

3. Final Answer:

   Define both containers in the same task definition with combined CPU and memory settings. -> Option A

4. Quick Check:

   Multi-container task = single task definition with both containers [OK]

Hint: Use one task definition for multiple containers sharing resources [OK]

Common Mistakes:

• Splitting containers into separate tasks unnecessarily
• Mixing logging inside app container
• Running containers on different platforms