Terraform on AWS EKS: Fargate Profiles — Serverless Pods Without Managing Nodes

There is a specific kind of on-call page that Fargate exists to delete: it is 02:00, a kube-system pod is CrashLoopBackOff because a node ran out of disk on the container runtime’s overlay filesystem, and you are cordoning, draining, and rolling an AMI at an hour when nobody should be touching a kernel. AWS Fargate for EKS removes the node from the picture entirely. You do not run EC2 instances; you run pods, and for each pod AWS quietly provisions a dedicated micro-VM, boots it, schedules exactly one pod onto it, patches its kernel on your behalf, and destroys it when the pod exits. There is no node group to size, no Auto Scaling Group to tune, no AMI to roll, no SSH, no kubelet you own. You describe which pods should run this way with an aws_eks_fargate_profile, and Terraform makes that description real.

That convenience is not free of trade-offs, and the entire craft of using Fargate well is knowing exactly where the edges are. A Fargate pod is one kernel, so a DaemonSet has no node to land on and is silently ignored — every node-level agent pattern (log shippers, security sensors, the CNI) has to become a sidecar or move to nodes. There is no EBS: persistent storage is EFS only. There are no privileged pods, no hostNetwork, no hostPort, no GPUs. Pods must sit on private subnets. Load balancing must use IP target type because there is no instance to register. And the pod’s size is not something you pick — Fargate reads your CPU and memory requests and provisions the smallest valid micro-VM that fits, which means your resource requests are quite literally your bill. Miss any one of these and the symptom is almost always the same maddening line: pod stuck Pending.

This lesson builds the whole thing in Terraform on top of an existing cluster — the one from the companion lesson Provisioning EKS: the Cluster, VPC & Managed Node Groups. You will write the aws_eks_fargate_profile, the IAM pod execution role it requires, a second profile that moves CoreDNS onto Fargate, and the aws-logging ConfigMap that turns on AWS’s built-in Fluent Bit router to CloudWatch. Then you run terraform init → plan → apply, deploy an app into the Fargate namespace, and confirm with kubectl get nodes that the pod is running on a fargate-ip-… virtual node that did not exist a minute earlier — the moment Fargate “clicks”. Finally you will see the logs land in a CloudWatch log group and terraform destroy it all so nothing lingers on the bill.

What you’ll build

The scenario is the one a platform team reaches when a new internal service needs to ship but nobody wants to grow the node fleet for it: a small, bursty, stateless web app that should run without adding any capacity to manage. You already have an EKS cluster with a managed node group carrying the DaemonSets and the steady workloads. You want a new namespace — apps-fargate — whose pods run on Fargate, isolated in their own micro-VMs, scaling from zero to a handful and back to zero over the day, billed by the second. You also want the cluster’s own DNS (CoreDNS) to stop depending on nodes, and you want every Fargate pod’s stdout to arrive in CloudWatch with no sidecar to maintain.

Concretely, one terraform apply (against the existing cluster) produces: an IAM pod execution role trusted by eks-fargate-pods.amazonaws.com and carrying AmazonEKSFargatePodExecutionRolePolicy plus a small logging policy; an aws_eks_fargate_profile named apps that selects the apps-fargate namespace on the cluster’s private subnets; a second profile system that selects kube-system so CoreDNS can move to Fargate; the aws-observability namespace + aws-logging ConfigMap that switches on the managed Fluent Bit log router to CloudWatch; and — through the kubernetes provider — a small Deployment + Service in apps-fargate you can prove landed on Fargate.

Why Terraform rather than eksctl create fargateprofile, the console, or CloudFormation? Because a Fargate profile is immutable — you cannot edit a selector or a subnet list in place; changing either forces a replace — and immutability is exactly where declarative IaC earns its keep. terraform plan shows you the replace before it happens; a for_each map turns “add a namespace to Fargate” into a one-line diff; and the profile, its execution role, and the logging config live in one reviewed, versioned change instead of three imperative commands nobody logged.

Here is the full inventory of what the demo creates, so you can see the moving parts before the HCL:

Read the diagram left to right: Terraform creates a Fargate profile on the EKS cluster (badge 6 — the same cluster still runs node groups for everything Fargate can’t); the profile’s selectors decide which pods qualify (badge 2) and its private subnets are mandatory (badge 3); a matching pod is placed on an AWS-managed micro-VM with no node for you to run (badge 1), sized per-pod from its requests (badge 5), and cannot use DaemonSets, EBS, GPUs, or privileged mode (badge 4); logs flow to CloudWatch through the built-in router. The six legend entries are the six decisions this lesson makes in code.

Fargate, managed nodes, and Karpenter: choosing the compute model

Before any HCL, get the mental model exact, because it drives every later decision. A managed node group is a fleet of EC2 instances you own inside the cluster: you pick the instance type, the DaemonSets run on them, many pods share each node, and you (or the Cluster Autoscaler) decide how many nodes exist. Karpenter is a smarter, faster autoscaler that provisions right-sized nodes just-in-time from the actual pending-pod shapes — still EC2 you own, but with far less bin-packing waste and second-scale response, covered in EKS Autoscaling: Cluster Autoscaler & Karpenter. Fargate is neither: there is no node you own at all. Each pod gets a private micro-VM, AWS patches and scales it, and you are billed for that pod’s vCPU-seconds and GB-seconds.

The three are not rivals so much as tools for different shapes of workload, and mature clusters run all three at once. The comparison that matters:

Two rows deserve emphasis because they surprise people. Cold start: a Fargate pod pays a VM-boot-plus-image-pull tax on every new pod, not just when the cluster scales — so a workload that scales from 0→50→0 many times an hour feels that latency repeatedly, while a node-based deployment keeps warm nodes and only pays when it adds a node. Cost: Fargate looks expensive per vCPU-hour, and for a dense, always-on fleet it is — but for a job that runs 4 minutes an hour you pay for ~4 minutes, whereas a node sits (and bills) 24×7. Duty cycle, not sticker price, decides who wins.

The billing dimensions, so “per-pod” is concrete (us-east-1 list price; check current AWS pricing for your region — prices vary and change):

And the decision heuristic — when each model is the right default:

The Fargate profile: how a pod lands on Fargate

The whole placement mechanism is one resource: aws_eks_fargate_profile. It is a rule attached to a cluster that says “pods matching these selectors, schedule them on Fargate, and give them an ENI in these subnets under this IAM role.” It does not run anything by itself; it changes where the EKS scheduler places matching pods. Here is the resource with every argument you will realistically set:

resource "aws_eks_fargate_profile" "apps" {
  cluster_name           = data.aws_eks_cluster.this.name
  fargate_profile_name   = "apps"
  pod_execution_role_arn = aws_iam_role.fargate_pod.arn
  subnet_ids             = local.private_subnet_ids   # MUST be private

  # A pod is placed on Fargate if it matches ANY selector below.
  selector {
    namespace = "apps-fargate"
  }

  # Narrow with labels: only pods in this namespace carrying compute=fargate.
  selector {
    namespace = "batch"
    labels = {
      compute = "fargate"
    }
  }

  tags = {
    Project = "kloudvin-fargate-demo"
  }

  # Creating/deleting a profile is slow (ENIs, warm-pool). Give it room.
  timeouts {
    create = "20m"
    delete = "20m"
  }
}

The argument reference — memorise the immutable ones, because they turn edits into replacements:

Attributes you will reference: arn, status (ACTIVE when usable), and id (cluster_name:fargate_profile_name). Because nothing about a selector or subnet is editable, treat a profile like a piece of naming: get it right, and when you must change it, expect terraform plan to show -/+ destroy and then create replacement — harmless for a placement rule, but you should know it is coming.

Selectors: the entire placement contract

A pod runs on Fargate iff it matches at least one selector on some profile in the cluster. Matching is simple and worth stating precisely so you can debug the inevitable “why is my pod on a node / stuck Pending?”:

The rules that trip people up, made explicit:

• Namespace is mandatory; labels are optional and additive. A selector with labels requires the pod to carry every label listed (AND within a selector). Across selectors and profiles it is OR.
• A pod’s labels are its own labels, not the Deployment’s — but a Deployment’s pod template labels become the pod labels, so template.metadata.labels is what the selector sees.
• No match, and you have node groups → the pod schedules on a node like normal. No match, and the cluster is 100% Fargate → the pod sits Pending forever. This is the classic “I deleted my node group and now nothing schedules” incident.
• Selectors are evaluated at pod admission by the fargate-scheduler. Adding a profile does not move already-running pods; you must recreate them (kubectl rollout restart) for the new rule to apply.

The pod execution role

Because Fargate does the low-level work on your pod’s behalf — pulling the image from ECR, wiring the ENI, shipping logs — it needs an IAM identity to do it as. That is the pod execution role, and it is not optional. It is trusted by the eks-fargate-pods.amazonaws.com service principal and carries AWS’s managed policy plus whatever your pods’ infrastructure needs (here, CloudWatch Logs):

data "aws_iam_policy_document" "fargate_assume" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["eks-fargate-pods.amazonaws.com"]
    }
    # Scope the trust to fargate profiles of THIS cluster (defence in depth).
    condition {
      test     = "ArnLike"
      variable = "aws:SourceArn"
      values   = ["arn:aws:eks:${var.region}:${data.aws_caller_identity.me.account_id}:fargateprofile/${data.aws_eks_cluster.this.name}/*"]
    }
  }
}

resource "aws_iam_role" "fargate_pod" {
  name               = "${data.aws_eks_cluster.this.name}-fargate-pod-exec"
  assume_role_policy = data.aws_iam_policy_document.fargate_assume.json
}

# The AWS-managed policy: ECR pull, ENI, and base permissions Fargate needs.
resource "aws_iam_role_policy_attachment" "fargate_managed" {
  role       = aws_iam_role.fargate_pod.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy"
}

# Extra: let the built-in Fluent Bit router write to CloudWatch Logs.
resource "aws_iam_role_policy" "fargate_logging" {
  name = "fargate-logging-to-cloudwatch"
  role = aws_iam_role.fargate_pod.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = [
        "logs:CreateLogStream",
        "logs:CreateLogGroup",
        "logs:DescribeLogStreams",
        "logs:PutLogEvents",
        "logs:PutRetentionPolicy"
      ]
      Resource = "*"
    }]
  })
}

What each piece grants, and why it exists:

Note the crucial distinction: the pod execution role is infrastructure identity (image pull, logging, networking), not your application’s identity. Your application’s AWS permissions still come from IRSA / EKS Pod Identity on the pod’s service account — Fargate does not change that, and it is covered in the cluster and IRSA lessons. Do not overload the execution role with your app’s S3/DynamoDB permissions.

Why the subnets must be private

subnet_ids on a profile must be private — subnets whose route table sends 0.0.0.0/0 to a NAT gateway, not to an internet gateway. A Fargate pod scheduled onto a public subnet is rejected and the pod stays Pending with no ENI attached. Reuse the very same private subnets your node groups use (built in the EKS cluster provisioning lesson and the underlying VPC / subnets / NAT lesson). Tag them the way EKS and the load balancer controller expect so internal ALBs/NLBs can find them:

CoreDNS on Fargate: making the cluster nodeless

Out of the box, EKS pins its CoreDNS deployment to EC2 with an annotation on the pod template — eks.amazonaws.com/compute-type: ec2. That annotation exists precisely so that a brand-new cluster’s DNS does not accidentally try to schedule on Fargate before you have a profile for it. If your goal is a cluster with no nodes at all (everything, including system components, on Fargate), you must do two things: create a Fargate profile that selects kube-system, and patch off that annotation so the scheduler is allowed to place CoreDNS on Fargate.

The profile is just another aws_eks_fargate_profile selecting kube-system (optionally narrowed to k8s-app: kube-dns so only CoreDNS, not everything in kube-system, goes to Fargate):

resource "aws_eks_fargate_profile" "system" {
  cluster_name           = data.aws_eks_cluster.this.name
  fargate_profile_name   = "system"
  pod_execution_role_arn = aws_iam_role.fargate_pod.arn
  subnet_ids             = local.private_subnet_ids

  selector {
    namespace = "kube-system"
    labels    = { "k8s-app" = "kube-dns" }   # CoreDNS only
  }
}

The annotation removal is a kubectl patch — it is a mutation to a resource EKS created, not something you declare from scratch, so run it as a one-off (or a null_resource/kubernetes_annotation in more advanced setups):

# Remove the ec2 pin so CoreDNS may schedule on Fargate, then restart it.
kubectl patch deployment coredns -n kube-system --type json \
  -p='[{"op":"remove","path":"/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'
kubectl rollout restart deployment coredns -n kube-system

Which system components can move to Fargate, and how they behave:

The pattern to internalise: a fully nodeless cluster runs kube-system (CoreDNS) and your app namespaces on Fargate and accepts the DaemonSet limitation. A mixed cluster keeps a small node group for DaemonSets and CoreDNS and puts only chosen app namespaces on Fargate. Both are valid; the mixed cluster is more common because almost everyone runs at least one DaemonSet (a log or security agent).

Logging: sidecar-less Fluent Bit to CloudWatch

On nodes, you ship container logs with a DaemonSet (Fluent Bit / Fluentd) that tails /var/log/containers. On Fargate there is no node and no DaemonSet, so that pattern is impossible — which is exactly why AWS builds a managed log router into the Fargate runtime. You do not deploy Fluent Bit; you configure the built-in one by creating a specific ConfigMap, and AWS runs it out-of-band for every pod on the profile. No sidecar, no DaemonSet, no extra container in your pod.

The contract is exact: a namespace named aws-observability carrying the label aws-observability=enabled, containing a ConfigMap named aws-logging whose keys are Fluent Bit config fragments. Here it is in Terraform via the kubernetes provider:

resource "kubernetes_namespace" "observability" {
  metadata {
    name   = "aws-observability"
    labels = { "aws-observability" = "enabled" }   # required exactly
  }
}

resource "kubernetes_config_map" "aws_logging" {
  metadata {
    name      = "aws-logging"
    namespace = kubernetes_namespace.observability.metadata[0].name
  }

  data = {
    "flb_log_cw" = "true"   # emit Fluent Bit's own logs to CloudWatch too

    "output.conf" = <<-EOT
      [OUTPUT]
          Name                cloudwatch_logs
          Match               *
          region              ${var.region}
          log_group_name      /aws/eks/${data.aws_eks_cluster.this.name}/fargate
          log_stream_prefix   fargate-
          auto_create_group   true
    EOT

    "filters.conf" = <<-EOT
      [FILTER]
          Name                kubernetes
          Match               kube.*
          Merge_Log           On
          Keep_Log            Off
    EOT

    "parsers.conf" = <<-EOT
      [PARSER]
          Name   json
          Format json
    EOT
  }
}

The keys and what they control:

Output-plugin choices, and the permission each needs on the execution role:

Two failure modes to pre-empt: if the namespace is missing the aws-observability=enabled label, the router silently does nothing — no error, just no logs. And if the execution role lacks the logs:* permissions above, the router runs but every put is denied and, again, no logs appear. Both look identical from kubectl (the pod is healthy), so when logs are missing, check the label and the role first.

Load balancing Fargate pods: IP target type is mandatory

A classic ALB/NLB target group registers EC2 instance IDs (target_type = "instance") and routes to each instance’s port. Fargate pods have no EC2 instance to register — so instance mode simply cannot express them. Every load balancer in front of Fargate must use target_type = "ip", registering the pod’s own IP address, and the component that keeps those IP registrations in sync with your pods is the AWS Load Balancer Controller, covered in The AWS Load Balancer Controller. (The mechanics of target_type — and why it forces replacement when changed — are in the ALB/NLB & Target Groups lesson.)

The practical upshot: expose Fargate workloads with an Ingress (ALB) or an IP-mode Service (NLB) and let the controller register pod IPs. If you forget target-type: ip, the controller creates an instance-mode target group with no instances to register, and every request returns 503 because there are zero healthy targets.

Hands-on: build it with Terraform

Time to run it. This demo assumes you already have an EKS cluster with private subnets — build it with the cluster provisioning lesson first, or point the data sources below at any existing cluster. We deliberately keep the cluster in its own Terraform state and build Fargate + workloads in a second root, because configuring the kubernetes provider from a cluster you are creating in the same apply is the number-one way to get a config that plans clean and applies broken. Here the cluster already exists, so the data sources resolve at plan time and the provider is safe.

⚠️ Real spend. Fargate pods, any NAT data, and CloudWatch ingestion cost money. This demo is a few cents per hour, but run terraform destroy when you finish.

Step 1 — versions.tf

terraform {
  required_version = ">= 1.6"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.60"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.31"
    }
  }

  backend "s3" {
    bucket       = "kloudvin-tf-state"
    key          = "eks/fargate/terraform.tfstate"
    region       = "us-east-1"
    encrypt      = true
    use_lockfile = true   # S3-native locking (TF 1.10+); or dynamodb_table
  }
}

Step 2 — variables.tf

variable "region" {
  type    = string
  default = "us-east-1"
}

variable "cluster_name" {
  type        = string
  description = "Existing EKS cluster to attach Fargate profiles to"
  default     = "kloudvin-eks"
}

# Map of Fargate profiles → drives for_each. Add a namespace = one line here.
variable "fargate_profiles" {
  description = "profile name => { namespace, labels }"
  type = map(object({
    namespace = string
    labels    = optional(map(string), {})
  }))
  default = {
    apps   = { namespace = "apps-fargate" }
    system = { namespace = "kube-system", labels = { "k8s-app" = "kube-dns" } }
  }
}

Step 3 — providers.tf (data-driven, cluster already exists)

provider "aws" {
  region = var.region
}

data "aws_caller_identity" "me" {}

# Look up the existing cluster + its networking.
data "aws_eks_cluster" "this" {
  name = var.cluster_name
}

data "aws_eks_cluster_auth" "this" {
  name = var.cluster_name
}

# Private subnets, discovered by the tag the cluster lesson set.
data "aws_subnets" "private" {
  filter {
    name   = "vpc-id"
    values = [data.aws_eks_cluster.this.vpc_config[0].vpc_id]
  }
  tags = {
    "kubernetes.io/role/internal-elb" = "1"
  }
}

locals {
  private_subnet_ids = data.aws_subnets.private.ids
}

# The kubernetes provider is configured FROM the existing cluster (safe:
# it resolves at plan time because the cluster is not created in this apply).
provider "kubernetes" {
  host                   = data.aws_eks_cluster.this.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.this.certificate_authority[0].data)
  # Short-lived token is fine for a demo; for CI prefer an exec { } block
  # that calls `aws eks get-token` so credentials refresh past 15 minutes.
  token = data.aws_eks_cluster_auth.this.token
}

Step 4 — main.tf (the execution role, the profiles, the app)

# ---------- pod execution role ----------
data "aws_iam_policy_document" "fargate_assume" {
  statement {
    effect  = "Allow"
    actions = ["sts:AssumeRole"]
    principals {
      type        = "Service"
      identifiers = ["eks-fargate-pods.amazonaws.com"]
    }
    condition {
      test     = "ArnLike"
      variable = "aws:SourceArn"
      values   = ["arn:aws:eks:${var.region}:${data.aws_caller_identity.me.account_id}:fargateprofile/${var.cluster_name}/*"]
    }
  }
}

resource "aws_iam_role" "fargate_pod" {
  name               = "${var.cluster_name}-fargate-pod-exec"
  assume_role_policy = data.aws_iam_policy_document.fargate_assume.json
}

resource "aws_iam_role_policy_attachment" "fargate_managed" {
  role       = aws_iam_role.fargate_pod.name
  policy_arn = "arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy"
}

resource "aws_iam_role_policy" "fargate_logging" {
  name = "fargate-logging-to-cloudwatch"
  role = aws_iam_role.fargate_pod.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect   = "Allow"
      Action   = ["logs:CreateLogStream", "logs:CreateLogGroup",
                  "logs:DescribeLogStreams", "logs:PutLogEvents",
                  "logs:PutRetentionPolicy"]
      Resource = "*"
    }]
  })
}

# ---------- the Fargate profiles (one per map entry) ----------
resource "aws_eks_fargate_profile" "this" {
  for_each = var.fargate_profiles

  cluster_name           = var.cluster_name
  fargate_profile_name   = each.key
  pod_execution_role_arn = aws_iam_role.fargate_pod.arn
  subnet_ids             = local.private_subnet_ids

  selector {
    namespace = each.value.namespace
    labels    = each.value.labels
  }

  timeouts {
    create = "20m"
    delete = "20m"
  }

  tags = { Project = "kloudvin-fargate-demo" }
}

# ---------- logging: managed Fluent Bit → CloudWatch ----------
resource "kubernetes_namespace" "observability" {
  metadata {
    name   = "aws-observability"
    labels = { "aws-observability" = "enabled" }
  }
}

resource "kubernetes_config_map" "aws_logging" {
  metadata {
    name      = "aws-logging"
    namespace = kubernetes_namespace.observability.metadata[0].name
  }
  data = {
    "flb_log_cw"  = "true"
    "output.conf" = <<-EOT
      [OUTPUT]
          Name                cloudwatch_logs
          Match               *
          region              ${var.region}
          log_group_name      /aws/eks/${var.cluster_name}/fargate
          log_stream_prefix   fargate-
          auto_create_group   true
    EOT
  }
}

# ---------- app namespace + a Deployment to prove Fargate ----------
resource "kubernetes_namespace" "apps" {
  metadata { name = "apps-fargate" }
}

resource "kubernetes_deployment" "hello" {
  metadata {
    name      = "hello"
    namespace = kubernetes_namespace.apps.metadata[0].name
  }
  spec {
    replicas = 2
    selector { match_labels = { app = "hello" } }
    template {
      metadata { labels = { app = "hello" } }
      spec {
        container {
          name  = "web"
          image = "public.ecr.aws/nginx/nginx:1.27"
          port { container_port = 80 }
          # requests = the Fargate micro-VM size. Rounds UP to 0.5 vCPU/1 GB.
          resources {
            requests = { cpu = "250m", memory = "512Mi" }
            limits   = { cpu = "500m", memory = "1Gi" }
          }
        }
      }
    }
  }
  # Fargate boots a VM per pod; give the rollout time before it's "unhealthy".
  timeouts { create = "10m" }
  depends_on = [aws_eks_fargate_profile.this]
}

resource "kubernetes_service" "hello" {
  metadata {
    name      = "hello"
    namespace = kubernetes_namespace.apps.metadata[0].name
  }
  spec {
    selector = { app = "hello" }
    port {
      port        = 80
      target_port = 80
    }
    type = "ClusterIP"
  }
}

Step 5 — outputs.tf

output "fargate_profile_arns" {
  value = { for k, p in aws_eks_fargate_profile.this : k => p.arn }
}

output "pod_execution_role_arn" {
  value = aws_iam_role.fargate_pod.arn
}

output "log_group" {
  value = "/aws/eks/${var.cluster_name}/fargate"
}

Step 6 — init, plan, apply

terraform init      # downloads aws + kubernetes providers, configures S3 backend
terraform plan      # review — expect the profiles as CREATE, not replace

Representative plan summary (abridged):

Terraform will perform the following actions:

  # aws_eks_fargate_profile.this["apps"] will be created
  + resource "aws_eks_fargate_profile" "this" {
      + arn                    = (known after apply)
      + cluster_name           = "kloudvin-eks"
      + fargate_profile_name   = "apps"
      + pod_execution_role_arn = (known after apply)
      + status                 = (known after apply)
      + subnet_ids             = [ "subnet-0a1b…", "subnet-0c2d…" ]
      + selector { namespace = "apps-fargate" }
    }
  # aws_eks_fargate_profile.this["system"]  ... (CoreDNS)
  # aws_iam_role.fargate_pod ...
  # kubernetes_config_map.aws_logging ...
  # kubernetes_deployment.hello ...

Plan: 9 to add, 0 to change, 0 to destroy.

terraform apply -auto-approve

The two Fargate profiles are the slow part — each takes a couple of minutes to reach ACTIVE while EKS provisions the warm-pool plumbing, which is why we set generous timeouts. Total apply is typically 3–6 minutes.

Step 7 — verify the pods really landed on Fargate

This is the payoff. Point kubectl at the cluster and look at the nodes:

aws eks update-kubeconfig --name kloudvin-eks --region us-east-1
kubectl get nodes -o wide

The tell is node names: each Fargate pod runs on its own virtual node named fargate-ip-…, which did not exist before you deployed:

NAME                                                STATUS   ROLES    AGE   VERSION
fargate-ip-10-0-13-201.ec2.internal                 Ready    <none>   72s   v1.30.x-eks
fargate-ip-10-0-14-118.ec2.internal                 Ready    <none>   70s   v1.30.x-eks
ip-10-0-9-44.ec2.internal                           Ready    <none>   4h    v1.30.x-eks   <- a managed node (if any)

Two hello replicas → two fargate-… nodes. Confirm each pod’s node and that they are Running:

kubectl get pods -n apps-fargate -o wide

NAME                     READY   STATUS    NODE
hello-6d4c…-abcde        1/1     Running   fargate-ip-10-0-13-201.ec2.internal
hello-6d4c…-fghij        1/1     Running   fargate-ip-10-0-14-118.ec2.internal

If you patched CoreDNS onto Fargate (Step for the system profile), kubectl get pods -n kube-system -o wide shows coredns-* on fargate-… nodes too. Your verification checklist:

Step 8 — confirm logging reached CloudWatch

Generate a log line and look in CloudWatch:

kubectl exec -n apps-fargate deploy/hello -- sh -c 'echo "hello from fargate"'
aws logs describe-log-groups --log-group-name-prefix /aws/eks/kloudvin-eks/fargate
aws logs tail /aws/eks/kloudvin-eks/fargate --since 5m

You should see the log group /aws/eks/kloudvin-eks/fargate (auto-created by the router) with fargate-… streams carrying your container’s stdout. If it is empty, jump to troubleshooting — it is almost always the missing aws-observability=enabled label or the execution-role logging permissions.

Step 9 — destroy and clean up

terraform destroy -auto-approve

Destroy removes the profiles (each again a few minutes), the role, the ConfigMap, and the app. What Terraform does not delete, and you should check by hand:

Variables, outputs & making it reusable

The demo already hints at the reusable shape: the fargate_profiles map driving a single for_eached resource. “Put another namespace on Fargate” is now a one-line data change, not a copy-pasted resource block:

fargate_profiles = {
  apps    = { namespace = "apps-fargate" }
  system  = { namespace = "kube-system", labels = { "k8s-app" = "kube-dns" } }
  batch   = { namespace = "batch",       labels = { compute = "fargate" } }   # <- added
  ingress = { namespace = "ingress" }
}

Because the profile name is the map key, for_each gives you stable addresses (aws_eks_fargate_profile.this["batch"]) — adding or removing a key touches only that one profile, never the others. Contrast with count, which would re-index and threaten to replace unrelated profiles when you reorder the list. Always key Fargate profiles by name, never by index.

When to roll your own versus reach for the community module:

The registry module takes a fargate_profiles map that looks almost identical to ours and, critically, creates the pod execution role and its policy attachment for you — one less thing to get wrong. If your cluster is built with terraform-aws-modules/eks/aws, define Fargate there rather than bolting on a separate role. If your cluster predates the module or is hand-rolled, the standalone resources in this lesson are the right call.

A mixed cluster: Fargate and nodes side by side

The most common production shape is not “all Fargate” or “all nodes” — it is a mixed cluster where each workload lives where it fits best. Fargate takes the bursty, isolated, low-ops namespaces; managed nodes or Karpenter take everything Fargate can’t do. The routing is entirely by selector: a namespace with a matching profile goes to Fargate; everything else schedules on nodes.

Three coordination points make a mixed cluster behave:

• CoreDNS placement. If you keep a node group, you can leave CoreDNS on nodes (the default) and not patch the annotation — simpler. Patch it onto Fargate only when you want DNS resilient to node loss.
• The LB controller itself is a Deployment (not a DaemonSet), so it happily runs on either — but the workloads it fronts must use target-type: ip regardless of where they run, since a Fargate pod is IP-only.
• DaemonSet-shaped needs become sidecars for Fargate namespaces: a per-pod log/metrics sidecar replaces the per-node agent. For logging specifically, the built-in Fluent Bit router removes even that need.

Fargate limitations — the table to read before you migrate

Every limitation here is a design constraint, not a bug — Fargate’s per-pod-VM model causes them. Read this before moving any namespace:

The sizing table is worth internalising, because “no requests set” quietly gives you the smallest, most expensive-per-unit shape and surprises the bill. Fargate sums the pod’s container requests, adds ~256 MB for the kubelet and agents, and rounds up to the nearest valid vCPU/memory combination:

Your hello pod requested 250m CPU / 512Mi; add overhead and round up → it runs as 0.5 vCPU / 1 GB. That rounded shape, not your request, is what you pay for.

Common mistakes and troubleshooting

The nastiest real gotchas, expanded:

“Pending” is almost always the selector or the subnet. When a Fargate pod won’t schedule, the two suspects — in order — are: (1) no selector matches, and (2) the profile points at a public subnet. Run kubectl describe pod and look for the fargate-scheduler events; “no Fargate profile” means selector, a subnet/ENI error means networking. Nine out of ten Pending Fargate pods are one of these two.

DaemonSets fail silently, which is the cruelty. There is no error, no Pending pod, no event — the DaemonSet controller simply never creates a pod for a Fargate “node” because Fargate reports no schedulable node in the normal sense. If your security or logging agent is a DaemonSet and you moved its namespace to Fargate, it just vanishes. Audit for DaemonSets before migrating a namespace.

The CoreDNS trap on a “nodeless” cluster. People delete their node group to go all-Fargate, and DNS dies because CoreDNS is still annotation-pinned to EC2 and now has nowhere to run — which breaks everything, since pods can’t resolve services. Always add the kube-system profile and patch CoreDNS before removing the last node group, and verify kubectl get pods -n kube-system -o wide shows CoreDNS on Fargate.

Immutability turns careless edits into outages. Changing a selector or subnet list replaces the profile — and during the replace, matching pods have no profile and won’t schedule. For a live namespace, add a new profile with the new rule, shift pods over, then remove the old one, rather than editing in place.

Cost, cleanup & production notes

Fargate cost is duty-cycle arithmetic. A pod sized 0.5 vCPU / 1 GB (our rounded hello) costs roughly 0.5 × $0.04048 + 1 × $0.004445 ≈ $0.0247 per hour while running. Left running 24×7 that is ~$18/month per replica — more than a small shared node slice, which is the point: Fargate is not cheaper for always-on. But the same pod run for 5 minutes an hour costs ~$0.002/hour of wall-clock — pennies, where a node would bill the full hour. Model it:

To destroy cleanly, terraform destroy handles the profiles/role/app, then delete the auto-created log group by hand (it is outside state because auto_create_group=true created it), and re-pin CoreDNS to EC2 if you are keeping nodes. Production hardening notes:

Cheat-sheet

Core resources and their key arguments:

Verification and operational commands:

Placement rules in one glance:

Interview and exam questions

1. What is an EKS Fargate profile and what does it do? A cluster-level rule (aws_eks_fargate_profile) that declares which pods run on Fargate. It carries selectors (namespace + optional labels), a pod execution role, and private subnets. Pods matching any selector are placed by the fargate-scheduler onto AWS-managed micro-VMs — one per pod — instead of on nodes.

2. How does a pod get placed on Fargate? At admission, EKS checks the pod’s namespace and labels against every profile’s selectors. If it matches at least one, it goes to Fargate; a selector’s labels are AND (the pod must carry them all), across selectors/profiles it is OR. No match → a node (or Pending if there are no nodes).

3. Why must Fargate subnets be private? Fargate refuses to place a pod on a public subnet (one with a direct IGW route). The pod stays Pending with no ENI. Use subnets that route egress through a NAT gateway. It is the second-most-common cause of Pending Fargate pods after a bad selector.

4. What is the pod execution role and how does it differ from IRSA? The execution role is the identity Fargate assumes to run your pod’s infrastructure — pull the image from ECR, attach the ENI, ship logs. It is trusted by eks-fargate-pods.amazonaws.com and carries AmazonEKSFargatePodExecutionRolePolicy. IRSA (or Pod Identity) is the application’s identity on its service account for calling AWS APIs (S3, DynamoDB). Keep app permissions out of the execution role.

5. Why don’t DaemonSets work on Fargate, and what do you do instead? Each Fargate pod is its own micro-VM with no shared node for a per-node daemon to occupy, so the DaemonSet controller never schedules pods there — silently. Replace node-agent patterns with sidecars, or keep those workloads on a node group. For logging specifically, use the built-in Fluent Bit router instead of a log DaemonSet.

6. How do you get CoreDNS running on Fargate? Create a Fargate profile selecting kube-system (optionally k8s-app: kube-dns), then patch off CoreDNS’s eks.amazonaws.com/compute-type: ec2 annotation and rollout restart it. Do this before removing your last node group, or DNS — and therefore everything — breaks.

7. How is a Fargate pod sized, and why does “no requests” cost more? Fargate sums the pod’s container CPU/memory requests, adds ~256 MB overhead, and rounds up to the nearest valid vCPU/memory combo (min 0.25 vCPU / 0.5 GB). With no requests set you get the smallest shape — which is the most expensive per unit and may be too small — so always set requests to the real need.

8. Why must load balancing to Fargate use IP target type? There is no EC2 instance to register, so target_type = "instance" cannot express a Fargate pod. Use target_type = "ip" (ALB via Ingress annotation alb.ingress.kubernetes.io/target-type: ip, or NLB IP mode) with the AWS Load Balancer Controller registering pod IPs. Forget it and you get a 503 with zero healthy targets.

9. How does Fargate logging work without a sidecar or DaemonSet? AWS runs a managed Fluent Bit log router in the Fargate runtime. You enable it by creating the aws-observability namespace (labelled aws-observability=enabled) and an aws-logging ConfigMap describing outputs/filters/parsers; the execution role needs the destination permissions (e.g. logs:PutLogEvents). No container is added to your pod.

10. When would you pick managed nodes or Karpenter over Fargate? For dense, steady 24×7 fleets (per-hour EC2 is cheaper than per-pod Fargate at high duty cycle), for DaemonSets, GPUs, privileged pods, hostNetwork, or EBS, and for large dynamic fleets that want Spot and minimal bin-packing waste (Karpenter’s sweet spot). Fargate wins for bursty, low-duty-cycle, isolation-sensitive, or zero-ops workloads.

11. (Terraform Associate 003) You change a selector block on an aws_eks_fargate_profile. What does terraform plan show? A replacement (-/+ destroy and then create) — selectors and subnet_ids are immutable, so any edit forces the profile to be recreated. Plan shows 1 to add, 0 to change, 1 to destroy for that resource. For a live namespace, add a new profile and migrate rather than editing in place.

12. (Terraform Associate 003) Why key Fargate profiles with for_each over a map instead of count over a list? for_each gives each profile a stable address by name (["batch"]), so adding/removing one entry touches only that resource. count indexes positionally, so reordering or removing a middle element re-indexes the rest and can force unintended replacements of unrelated profiles.

Key takeaways

• Fargate removes the node, not the pod. Each pod runs on its own AWS-managed micro-VM — no node groups, AMIs, SSH, or capacity planning — and you pay per-pod vCPU-seconds and GB-seconds with a 1-minute minimum.
• The profile is the whole placement contract. aws_eks_fargate_profile selectors (namespace + optional AND-ed labels) decide which pods go to Fargate; matching is OR across selectors/profiles; subnets must be private, and selectors/subnets are immutable (edits force replace).
• A pod execution role is mandatory and is infrastructure identity — trusted by eks-fargate-pods.amazonaws.com, carrying AmazonEKSFargatePodExecutionRolePolicy (+ logging). App AWS access still comes from IRSA/Pod Identity, not this role.
• Know the limits before you migrate: no DaemonSets (they vanish silently), no privileged/hostNetwork/GPU/Windows, EFS-only storage, IP-target LBs only, and per-pod sizing rounded up from requests.
• CoreDNS and logging need explicit steps: patch off the compute-type=ec2 annotation (+ a kube-system profile) to run DNS on Fargate; enable the built-in Fluent Bit router via the aws-observability namespace label and the aws-logging ConfigMap to reach CloudWatch.
• kubectl get nodes is your proof — Fargate pods appear as fargate-ip-… virtual nodes that materialise on demand and disappear when pods exit.
• Mixed clusters are the norm: run system + bursty namespaces on Fargate, keep DaemonSets, GPU, and steady fleets on managed nodes or Karpenter, all in one cluster.