Skip to content

Why do your tasks have public IPs while the data stores stay private?

1 min read · main part only; folded sections are optional

After this you can answer: Why do your tasks have public IPs while the data stores stay private?

A public subnet has a default route to an internet gateway. A public IP enables an internet route; neither setting grants permission through a security group. The API service explicitly uses the public subnet IDs and enables public IP assignment. The web service does the same.

The private route table has no internet default route. API-to-database traffic uses private addresses and the VPC’s local route. Postgres allows TCP 5432 from the API group; Valkey allows TCP 6379 from that group. The web group cannot directly reach either store.

Moving tasks into private subnets needs an outbound plan for image pulls, logs, secrets and application AWS calls. NAT or appropriate VPC endpoints are design choices, not settings already present here. I would compare cost, dependency reachability and failure across Availability Zones before migrating.

Does a public IP expose the API to everyone?
Only if network routes and inbound rules permit the connection. The API application port allows the ALB group, not arbitrary internet clients.
What breaks if you move tasks without adding outbound access?
Tasks can fail before startup when they cannot fetch images or secrets. Running tasks can also lose AWS API access.
Is this highly available?
Two subnet locations do not prove redundancy. Desired task count, capacity choice and single-instance data stores still constrain availability.

Read the path chapter, select the relevant map piece →, then inspect infra/src/compute/service.ts → createApiService. Work through the related case for a diagnostic example.

Read this book online: https://book.theversehub.in/