AWS Application Load Balancer setup for a small team

For a small team deploying a containerized app, an AWS Application Load Balancer costs roughly $16–$25/month before traffic, terminates TLS, and routes HTTP requests to healthy containers by hitting a health-check path. That is the whole job. You do not need the enterprise playbook of WAF integrations, dozens of listener rules, and cross-zone tuning to get a production-safe setup. You need one target group, one listener on 443, a health check that reflects reality, and a security group that only lets the load balancer talk to your app. This post walks through the minimum viable ALB and where the money and the gotchas actually live.

What an ALB is doing (and what you’re paying for) #

An Application Load Balancer sits at the edge of your VPC, accepts inbound HTTPS, and forwards requests to a target group — a pool of container tasks or instances. The pricing has two parts: a flat hourly charge of about $0.0225/hour in us-east-1 (roughly $16.20/month if it runs continuously) plus a usage charge measured in Load Balancer Capacity Units (LCU). For a small app serving a few requests per second with modest connection counts, LCU charges typically add a few dollars, so budgeting $16–$25/month for a single ALB is honest. That is not free, and it is a line item worth knowing before it shows up — the same category of surprise we cover in the anatomy of an AWS bill shock.

The ALB is worth it once you have more than one container behind a stable URL, want zero-downtime deploys, or need TLS terminated somewhere other than inside your app. If you are running a single always-on container and want to skip the load balancer entirely, that is a genuine architectural fork, not a default — Caddy vs ALB as an ingress decision lays out when each wins and how to change your mind later without a rewrite.

The four pieces you actually configure #

An ALB in front of ECS Fargate breaks into a small number of resources. The load balancer itself needs to live in at least two subnets across two availability zones — AWS requires this, and it is why you cannot launch an ALB into a single-subnet VPC. The listener on port 443 holds your ACM certificate and terminates TLS. The target group defines the health check and the protocol used to reach your containers. And a pair of security groups enforces that the internet talks only to the ALB, and the ALB talks only to your app’s container port. Getting that last part tight matters more than any feature toggle.

The single most common failure for small teams is a health check that lies. If your target group probes / but your app returns a 302 redirect there, every task registers as unhealthy and the ALB drains traffic to nothing. Point the check at a dedicated endpoint that returns a plain 200 and touches no external dependency — not the database, not the cache, just proof that the process is alive. A typical target-group health check for a Fargate service looks like this:

{
  "HealthCheckPath": "/health",
  "HealthCheckProtocol": "HTTP",
  "HealthCheckIntervalSeconds": 30,
  "HealthyThresholdCount": 2,
  "UnhealthyThresholdCount": 3,
  "Matcher": { "HttpCode": "200" }
}

With a 30-second interval and a healthy threshold of 2, a fresh task takes about a minute to start receiving traffic. That is fine for most apps, but if your container is slow to boot, add a health check grace period on the ECS service so the scheduler does not kill a task that simply has not finished warming up yet. This interacts directly with cold-start behavior; if you are weighing container startup against serverless, the numbers in our container cold-start comparison put real figures on the trade-off.

The security group mistake to avoid #

Small teams almost always open the app’s container security group to 0.0.0.0/0 on the app port because it is the fast way to make things work. Don’t. The correct rule set is: the ALB security group allows inbound 443 from the internet, and the app security group allows inbound on the container port only from the ALB’s security group — referenced by group ID, not by CIDR. That way your containers are unreachable from the public internet even if someone discovers their private IPs. We generate exactly this shape automatically and argue it produces tighter security groups than most hand-written ones, because the rules are derived from the ports your code actually listens on.

How Vylara sets this up for you #

The point of Vylara is that you do not assemble these four pieces by hand. You install the GitHub App, pick a repo, and the Vylara agent analyzes your code to detect the framework, the container port, and the services your app needs. When you approve and run your first deploy, the agent provisions the load balancer, listener, target group, and security groups in your own AWS account using a blue/green strategy — the ALB shifts all traffic to a new target group only after the new tasks pass their health checks, giving you zero-downtime releases and rollback without configuring any of it yourself.

After the deploy lands, the connection URL and the health path are persisted to your project’s config, so the dashboard and the in-app infrastructure chat reference the same host, port, and health endpoint. If a service starts returning 502s, you can ask the chat what is happening and it will read your CloudWatch logs and describe the load balancer and security group configuration before proposing a fix — and any change that modifies infrastructure waits for your explicit approval. Two honest limits are worth stating: sizing is an educated guess until you see real traffic, and the ALB is an AWS-only resource today, so this specific setup applies to AWS accounts, not Azure or GCP. For the broader picture of running production infrastructure this way, start with our AWS pillar or the guide on managing AWS without a DevOps engineer.

The takeaway for a small team: an ALB is cheaper and simpler than the enterprise guides imply, its correctness lives almost entirely in the health check and the security-group references, and if you would rather not hand-wire those, the first deploy provisions them in your account and hands you back a URL that works.