Running AWS ECS Fargate with Auto Scaling and ALB Integration

Containers have reshaped how Australian organisations deploy workloads. Migrating a .NET monolith from a Sydney data centre to ap-southeast-2 or building microservices for a Brisbane fintech, AWS ECS Fargate removes the burden of patching EC2 host fleets. The trade-off is more configuration responsibility in scaling, traffic distribution, and observability.

For administrators used to VMware, Hyper-V, or bare-metal Linux, the shift is significant. Capacity, networking, and security become declarative YAML and JSON artefacts version-controlled alongside application code, trading granular control for operational velocity. There are no cluster nodes to RDP into, no hypervisor patches to schedule during Sunday change windows.

The two AWS components that make Fargate production-ready are the Application Load Balancer and Service Auto Scaling. The ALB handles layer-7 routing, TLS termination, and target health verification, while auto scaling policies watch CloudWatch metrics and adjust task counts in response to load. Together they replace the load-balancer VIPs and cluster-autoscaler logic many local teams stitched together over the past decade.

This walkthrough covers cluster setup, task definitions, IAM roles, ALB listener rules, scaling policies, observability, and gotchas that emerge when workloads span Sydney and Melbourne regions.

Preparing the ECS Cluster and Task Definitions

The cluster is a logical boundary rather than a pool of pre-provisioned hosts, which surprises engineers coming from vSphere. Creating it is a one-liner: aws ecs create-cluster --cluster-name prod-melbourne-web. All Fargate capacity is requested per task definition, and AWS provisions it on demand inside the chosen Availability Zone.

Task definitions describe container image, CPU and memory allocation, port mappings, logging drivers, and environment variables. A Sydney platform might pull from a private ECR repository and retain CloudWatch logs for 30 days to satisfy APRA CPS 234. The awsvpc network mode is mandatory, giving each task its own elastic network interface and private IP.

Configuring IAM Roles and Security Boundaries

Fargate task roles differ from EC2 instance profiles because there are no instances to profile. Two distinct roles govern each task: the execution role, which lets ECS pull images and write logs, and the task role, which the application assumes to call AWS APIs.

The execution role needs ecr:GetAuthorizationToken, ecr:BatchGetImage, ecr:GetDownloadUrlForLayer, and logs:CreateLogStream. The task role should follow least-privilege principles aligned with the ACSC Essential Eight, granting only the S3 buckets, SQS queues, or DynamoDB tables the workload legitimately needs. Security groups attach at the ENI level, so inbound rules should allow traffic from the ALB security group only.

Setting up the Application Load Balancer

The ALB sits in front of the ECS service and forwards traffic to a target group of task IP addresses. Because Fargate uses awsvpc mode, target type must be ip rather than instance, a detail that trips up engineers used to EC2-backed clusters. Listener configuration typically uses HTTPS on port 443 with a certificate imported via AWS Certificate Manager.

Health checks deserve more attention than they usually receive. The default 30-second intervals with a 2-response threshold can mask intermittent failures during rollout. Tightening the path to a dedicated /healthz endpoint returning 200 only when downstream dependencies are reachable, and reducing the healthy threshold to 2, catches degraded tasks faster. This rigour mirrors what seasoned administrators already practise when tuning VMware distributed switch health checks on-prem.

Building Service Auto Scaling Policies

Service Auto Scaling in ECS works through CloudWatch alarms and AWS Application Auto Scaling. Target tracking is the most common policy type because it behaves like a thermostat: specify a target value for a metric such as average CPU or memory utilisation, and the service adjusts task count to maintain that target.

A target tracking policy keeping CPU at 60% produces visible scaling activity that lines up with demand spikes. Step scaling suits predictable scheduled events, where discrete scaling actions fire at specific CloudWatch alarm thresholds. A 60-second cooldown is usually appropriate, though workloads writing to RDS benefit from 300 seconds to let the database tier absorb new connections.

Container Networking, Health Checks, and Observability

Subnets, route tables, and NAT gateways determine whether tasks reach the internet for outbound API calls and whether inbound traffic flows correctly from the ALB. Tasks in private subnets route through a NAT gateway for egress, while the ALB lives in public subnets. Many Australian environments share a single NAT gateway to control costs, but compliance-sensitive workloads serving APRA-regulated entities benefit from one per AZ.

CloudWatch Container Insights provides per-task CPU, memory, network, and storage metrics viewable through the ECS console. Pairing these with AWS X-Ray traces gives a request-level view that simplifies troubleshooting latency regressions, while cross-account subscription filters and Kinesis Data Firehose transformation Lambdas scrub sensitive fields before log centralisation.

Hybrid Integration Patterns and Multi-Region Considerations

Many Australian organisations still run core systems on-premises while pushing new workloads to AWS. Direct Connect links between Equinix SY3 in Sydney and ap-southeast-2 provide consistent latency for hybrid applications where ECS tasks call back to on-prem databases. AWS Transit Gateway simplifies routing between VPCs and on-premises networks when multiple accounts are involved.

Active-active deployments across Sydney and Melbourne improve resilience but require Route 53 latency-based routing to direct users to the nearest region. Container images must exist in both regional ECR repositories, ideally replicated via ECR cross-region replication. For federal government clients operating under the Hosting Certification Framework, IRAP-assessed patterns in ap-southeast-2 are mandatory, and PSPF-aligned documentation turns ECS Fargate into a defensible platform choice.

Operational Hardening and Cost Control

Fargate pricing is per vCPU-hour and GB-hour, so over-provisioning adds up quickly. AWS Compute Optimizer provides right-sizing recommendations after a workload has run for at least 12 hours with sufficient utilisation variance, and Spot capacity for Fargate can cut compute costs by up to 70% for fault-tolerant batch workloads.

Image vulnerability scanning through Amazon ECR, paired with AWS Inspector, catches CVEs in base images before production. Tagging images with Git SHA hashes keeps the supply chain auditable for ACSC reporting cycles. Savings Plans and Compute Savings Plans apply to Fargate just as they do to EC2, with a 1-year no-upfront commitment typically yielding around 27% savings for predictable traffic patterns common in Australian retail workloads.

Practical Recommendations for Production Rollouts

• Provision task definitions via CI/CD pipelines using ECS service updates with deployment circuit breaker enabled.
• Enable ECR image scanning on push; fail builds that introduce critical vulnerabilities.
• Configure target tracking auto scaling on request count per target, not just CPU.
• Use ACM certificates with automatic renewal and HTTPS-only ALB listeners, redirecting HTTP at the listener level.
• Store task definitions and ECS service configurations in CloudFormation or Terraform.
• Implement CloudWatch alarms on MemoryUtilized to catch leaks before OOM-driven restart loops.
• Test failover between ap-southeast-2 and ap-southeast-4 quarterly, documenting RTO and RPO.