0Pricing
AWS Solutions Architect · Lesson

Fargate Profiles for Serverless Pods

Run Kubernetes pods on Fargate without managing EC2 nodes, configure Fargate profiles, and understand their namespace restrictions.

Fargate Profiles for Serverless Pods is a free AWS Solutions Architect lesson on CoddyKit — lesson 2 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the AWS Solutions Architect learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What Are Fargate Profiles?

AWS Fargate for EKS lets you run Kubernetes pods without provisioning or managing EC2 nodes. Instead of thinking about instance types and node groups, you define a Fargate profile that tells EKS which pods should run on Fargate based on their namespace and optional label selectors. AWS automatically provisions the right amount of compute for each pod and terminates it when the pod stops.

Fargate Profile Configuration

A Fargate profile is attached to an EKS cluster and contains one or more selectors — each selector specifies a namespace and optional Kubernetes label key-value pairs. A pod must match at least one selector to be scheduled on Fargate. The profile also specifies the pod execution role (an IAM role) and the private subnets Fargate should use to launch pods.

# Create a Fargate profile for the 'production' namespace
aws eks create-fargate-profile \
  --cluster-name my-cluster \
  --fargate-profile-name production-profile \
  --pod-execution-role-arn arn:aws:iam::111122223333:role/EKSFargatePodExecutionRole \
  --subnets subnet-aaa subnet-bbb \
  --selectors '[{"namespace":"production"},{"namespace":"staging","labels":{"fargate":"true"}}]'

Pod Execution Role

The pod execution role is an IAM role that EKS assumes when Fargate pulls container images and sends pod logs to CloudWatch. It must include the AmazonEKSFargatePodExecutionRolePolicy AWS-managed policy. Without this role, pods scheduled on Fargate will fail to start because Fargate cannot authenticate to ECR or write to CloudWatch Logs.

# Create the pod execution role trust policy
cat fargate-trust-policy.json
# {
#   "Version": "2012-10-17",
#   "Statement": [{
#     "Effect": "Allow",
#     "Principal": {"Service": "eks-fargate-pods.amazonaws.com"},
#     "Action": "sts:AssumeRole"
#   }]
# }

aws iam attach-role-policy \
  --role-name EKSFargatePodExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy

Namespace Restrictions on Fargate

Fargate imposes important namespace restrictions. The kube-system namespace is off-limits for most Fargate profiles because system pods such as kube-proxy run there. An exception is CoreDNS: AWS provides a guided process to patch the CoreDNS deployment to remove the eks.amazonaws.com/compute-type: ec2 annotation so it can run on Fargate. Pods in excluded namespaces will remain unscheduled if no EC2 nodes are available.

# Patch CoreDNS to allow Fargate scheduling
kubectl patch deployment coredns \
  -n kube-system \
  --type json \
  -p '[{"op":"remove","path":"/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'

# Restart CoreDNS to apply the patch
kubectl rollout restart deployment coredns -n kube-system

Fargate Pod Resource Sizing

Fargate allocates compute resources based on the CPU and memory requests defined in the pod spec. It rounds up to the nearest Fargate-supported vCPU/memory combination (for example, 0.25 vCPU / 0.5 GB up to 16 vCPU / 120 GB). You are billed only for the resources allocated per second while the pod runs. Always set accurate resource requests — under-requesting leads to out-of-memory kills; over-requesting increases cost.

# Pod spec with explicit resource requests and limits
apiVersion: v1
kind: Pod
metadata:
  name: api-pod
  namespace: production
spec:
  containers:
  - name: api
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/my-api:latest
    resources:
      requests:
        cpu: '500m'
        memory: '1Gi'
      limits:
        cpu: '1'
        memory: '2Gi'

Fargate vs EC2 Node Groups: Trade-offs

Fargate eliminates node management but has constraints: no daemonsets (since there are no persistent nodes to schedule them on), no privileged containers, and limited support for certain storage types. EC2 node groups support GPUs, custom kernels, and stateful workloads with local NVMe drives. A common pattern is to run stateless services on Fargate and stateful or GPU workloads on dedicated EC2 node groups within the same EKS cluster.

Fargate Networking and Security Groups

Each Fargate pod gets its own elastic network interface (ENI) and a private IP from the subnet you specified in the profile. This means you can apply a unique security group to each pod using the Security Groups for Pods feature. Fargate pods support all standard VPC security group rules, giving you fine-grained inbound and outbound traffic control at the individual pod level — a significant security advantage over shared node-level security groups.

# Assign a security group to a pod via annotation
apiVersion: v1
kind: Pod
metadata:
  name: secure-api
  namespace: production
  annotations:
    vpc.amazonaws.com/pod-eni: 'true'
spec:
  securityGroups:
    groupIds:
    - sg-0abc1234def56789a
  containers:
  - name: api
    image: 111122223333.dkr.ecr.us-east-1.amazonaws.com/secure-api:v2

Fargate Logging to CloudWatch

Fargate pods send logs to Amazon CloudWatch Logs using the built-in Fluent Bit log router. You configure logging by creating a ConfigMap named aws-logging in the aws-observability namespace. The pod execution role must have permission to create log groups and write log events. Logs are organised into CloudWatch log groups per cluster and namespace, making centralised log aggregation easy without running a separate log agent.

# ConfigMap to enable Fargate logging
apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-logging
  namespace: aws-observability
data:
  flb_log_cw: 'true'
  output.conf: |
    [OUTPUT]
        Name cloudwatch_logs
        Match *
        region us-east-1
        log_group_name /aws/eks/my-cluster/fargate
        log_stream_prefix fargate-
        auto_create_group true

Horizontal Pod Autoscaler on Fargate

Fargate supports the Kubernetes Horizontal Pod Autoscaler (HPA). When HPA scales out replicas, Fargate automatically provisions new micro-VMs without you having to adjust any node group size. This creates a true serverless autoscaling experience: HPA controls the number of pods and Fargate handles the compute elastically. You still need the Metrics Server deployed in the cluster for HPA to read CPU and memory usage.

# Deploy Metrics Server (required for HPA)
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# Create an HPA for a Fargate-scheduled deployment
kubectl autoscale deployment my-api \
  --namespace production \
  --cpu-percent=60 \
  --min=2 \
  --max=20

Fargate Pricing Model

You pay for Fargate by the vCPU-second and GB-second consumed, with a 1-minute minimum per pod. There are no node-level costs, reserved capacity charges, or AMI/OS patching costs. Fargate is typically more expensive per unit of compute than right-sized EC2 on-demand instances, but the total cost of ownership is often lower when you factor in the engineering time saved on node management, patching, and scaling decisions.

Common Fargate Limitations to Know

Key Fargate limitations for the SAA-C03 exam: no DaemonSet support (pods cannot be placed on each node because there are no persistent nodes), no privileged containers, no hostNetwork mode, and ephemeral storage is limited to 20 GB per pod (expandable to 200 GB with a configuration). Persistent block storage with EBS is not supported — use EFS for shared persistent file storage with Fargate pods.

# Mount EFS in a Fargate pod (EBS is NOT supported on Fargate)
apiVersion: v1
kind: Pod
metadata:
  name: efs-pod
  namespace: production
spec:
  volumes:
  - name: efs-storage
    persistentVolumeClaim:
      claimName: efs-pvc
  containers:
  - name: app
    image: my-image:latest
    volumeMounts:
    - name: efs-storage
      mountPath: /data

Quick Check

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

Lesson Recap

In this lesson you learned: Fargate profiles use namespace and label selectors to schedule pods serverlessly, the pod execution role grants Fargate permission to pull images and write logs, and Fargate does not support DaemonSets or EBS — use EFS for persistent storage. Next up we explore EKS networking with the VPC CNI plugin and the AWS Load Balancer Controller.

Frequently asked questions

Is the “Fargate Profiles for Serverless Pods” lesson free?

Yes — the full text of “Fargate Profiles for Serverless Pods” is free to read here on the web, and the AWS Solutions Architect course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the AWS Solutions Architect course, upgrade to CoddyKit PRO.

What will I learn in “Fargate Profiles for Serverless Pods”?

Run Kubernetes pods on Fargate without managing EC2 nodes, configure Fargate profiles, and understand their namespace restrictions. You practise AWS Solutions Architect with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start AWS Solutions Architect?

No prior experience is required. AWS Solutions Architect on CoddyKit is structured for beginners through advanced learners; this is — lesson 2 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “Fargate Profiles for Serverless Pods” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this AWS Solutions Architect lesson?

Yes. Every AWS Solutions Architect lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

  1. EKS Control Plane and Worker Nodes
  2. Fargate Profiles for Serverless Pods
  3. EKS Networking: VPC CNI and Load Balancing
  4. IAM Roles for Service Accounts (IRSA)
← Back to AWS Solutions Architect