ECS Fargate Self-Service: Ticket-to-Container in Minutes

Why — The Problem This Solves

A team wants to deploy a containerized service. Today that means someone hand-builds an ECS cluster, task definition, ALB target group, listener rule, security groups, and auto-scaling policy — an hour of console or Terraform work, repeated (and often done inconsistently) every time a new service needs to go live. Every hand-built service is a chance to skip a health check, forget a scaling policy, or wire the security group wrong.

The fix is the same self-service pattern the last eight weeks have been building toward: turn the ticket into the trigger. A ServiceNow ticket with an image URI and a port number becomes a running, load-balanced, auto-scaling Fargate service in minutes — no server management, no manual ALB wiring, and every service provisioned the same way every time.

The Business Value

This platform delivers a self-service path from ticket to running container, with the same operational guardrails every time: private-subnet-only tasks, target-tracking auto-scaling, and a per-ticket Step Functions execution history for auditability.

What You Need to Know — Skills & Tools

ECS Fargate vs. EC2 Launch Type

Fargate removes the underlying EC2 instance entirely — you specify CPU/memory per task, and AWS runs the container on infrastructure you never see or patch. The tradeoff is cost per vCPU/GB versus a comparable EC2 instance, but for a self-service platform where tasks come and go per ticket, not managing a cluster's worth of EC2 capacity is the whole point.

Path-Based Routing vs. Host-Based Routing

Key Concepts

Architecture — How It Fits Together

A ServiceNow ticket triggers an HMAC-signed webhook to API Gateway, which hands off to Step Functions. Step Functions runs fargate_provisioner (creates every AWS resource for the ticket) and then status_notifier (closes the ticket). The resulting service lives in a private subnet with no internet route, reachable only through the shared ALB.

Why Two Lambdas Instead of One

fargate_provisioner and status_notifier run as separate Step Functions states rather than one combined function. Splitting them means a provisioning failure and a ServiceNow-notification failure show up as distinct, individually-retryable states in the execution graph — you can tell at a glance whether the infrastructure itself failed or just the ticket-closing call did.

Why Step Functions Instead of Lambda Calling Lambda

The same reasoning that put Step Functions in front of Week 2's db_provisioner applies here: the workflow has real branching, retry, and catch semantics that a Lambda-calling-Lambda chain would have to hand-roll. The Retry block on ProvisionService retries on States.TaskFailed; the Catch routes to a NormalizeFailure state so a failed ticket still gets a clean, readable close-out instead of an unhandled exception.

How We Built It — Step by Step

Step 1 — Terraform Structure

Eight Terraform modules under week-09-ecs-fargate-self-service/terraform/modules/: vpc, security-groups, ecs-cluster, alb, iam, lambda, step-functions, and api-gateway — 50 resource blocks total. VPC endpoints (S3 gateway, ECR api/dkr, CloudWatch Logs) are defined directly in the root main.tf rather than inside the vpc module, to avoid a circular dependency with the security-groups module.

Step 2 — The Shared ALB

One ALB, one default listener with a static fixed-response 404 action. No target groups are created in Terraform — every per-service target group and listener rule is created imperatively by fargate_provisioner when a ticket arrives.

resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.shared.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type = "fixed-response"
    fixed_response {
      content_type = "text/plain"
      message_body = "Not Found"
      status_code  = "404"
    }
  }
}

Step 3 — fargate_provisioner: The Per-Ticket Pipeline

Seven boto3 calls per ticket, each idempotent (check-before-create — see Challenges for why that mattered):

1. ecr:CreateRepository — per-service image isolation, scan-on-push, immutable tags
2. logs:CreateLogGroup — /ecs/<project>-<service>
3. ecs:RegisterTaskDefinition — awsvpc network mode, FARGATE, shared execution role
4. elbv2:CreateTargetGroup — target_type=ip, health check path set to /<service>/
5. elbv2:CreateRule — path-pattern /<service>/* on the shared ALB's existing listener
6. ecs:CreateService — private subnets, ALB-only security group, no public IP
7. application-autoscaling:RegisterScalableTarget + PutScalingPolicy — target-tracking on CPU

Step 4 — Deploy via HCP Terraform

week-09-dev is a VCS-connected HCP Terraform workspace, same pattern as Weeks 5–8 — Terraform runs remotely from the GitHub repo, not from local CLI:

cloud {
  organization = "Katta"
  workspaces {
    name = "week-09-dev"
  }
}

The first apply attempt errored — see Challenges for the IAM and idempotency fixes that followed. The HCP run history below shows all four real runs against this workspace, including the one that errored:

Step 5 — Verify the Platform Baseline

Confirmed the shared ECS cluster came up with both capacity providers (FARGATE and FARGATE_SPOT) and Container Insights enabled, before submitting any tickets against it:

Step 6 — Submit a Real ServiceNow Ticket

With the platform baseline live, submitted an actual self-service catalog request — not a synthetic curl test — requesting a demo-nginx service:

Step 7 — Watch the Pipeline Execute

The webhook fired, Step Functions started, and the execution graph for this specific ticket (RITM0010026) showed both states completing green — ProvisionService then NotifySuccess:

Step 8 — Confirm the ECS Service Is Healthy

Checked the ECS service's target group health directly rather than trusting the pipeline's own success signal:

Step 9 — Hit the Live URL

Requested the service through the shared ALB, the same path an end user would take:

curl -i http://$ALB_DNS_NAME/demo-nginx/

Step 10 — Confirm the Ticket Closed Itself

Back in ServiceNow, RITM0010026 had already closed — status_notifier wrote the real work note the moment the ECS API calls succeeded, without anyone touching the ticket:

Challenges — What Actually Went Wrong

Security — Controls at Every Layer

Cost

All prices us-east-1, verified July 2026. Check aws.amazon.com/fargate/pricing and aws.amazon.com/elasticloadbalancing/pricing for current rates.

Cleanup

Delete any test services first, or the shared ALB/cluster/VPC destroy will fail on dependent target groups and ENIs still attached to a running service:

# Walks through the pre-destroy checklist for imperatively-created resources
bash week-09-ecs-fargate-self-service/scripts/cleanup.sh

# Then trigger destroy from HCP Terraform UI: week-09-dev → Actions → Start destroy plan
# (local terraform destroy fails on a VCS-connected workspace, same as deploy)

References

• AWS Docs: What Is AWS Fargate
• AWS Docs: ALB Listener Rules and Path Conditions
• AWS Docs: VPC Endpoints
• AWS Docs: Step Functions Error Handling (Retry/Catch)
• AWS Docs: Application Auto Scaling Service-Linked Roles
• Fargate Pricing (us-east-1, current)
• Source Code: week-09-ecs-fargate-self-service

Key Takeaways