Cutting a cloud bill by consolidating onto Docker hosts
- Where the money usually goes
- Consolidate with Docker
- Guardrails that make it safe
- Databases
- Staging and previews
- Measure before and after
- Typical results
- Where not to consolidate
Cloud bills grow in small increments: one more managed instance, one more staging environment, one more database that nobody turned off. Consolidating many small services onto a few Docker hosts is one of the most reliable ways to cut costs. It also needs guardrails so one noisy app does not take down the rest.
Where the money usually goes
Look at your bill by line item. The usual suspects:
- Many small instances or containers, each mostly idle
- Separate managed databases for low traffic apps
- Staging and preview environments running around the clock
- Load balancers per service
- Data egress you did not plan for
Idle capacity is the main waste. A service using 5 percent CPU on its own instance pays for the other 95.
Consolidate with Docker
Docker lets many services share one machine with isolated filesystems, networks and resource limits. Ten idle services on ten instances can become ten containers on one or two larger servers.
Guardrails that make it safe
Resource limits. Set memory limits on every container so a leak in one cannot starve the others.
services:
api:
deploy:
resources:
limits: { memory: 512M, cpus: "1.0" }
Health checks and restart policies. Unhealthy containers should restart automatically.
One reverse proxy. Route all services through one proxy with TLS instead of one load balancer each.
Separate production from experiments. Keep at least two hosts: one for production, one for staging and side projects.
Backups off the host. Consolidation means one server failure affects more services, so backups and a rebuild plan matter more.
Databases
Small apps often do not need their own managed database. One Postgres container can host several databases with separate users, or each app can have its own small container. Keep the critical, high traffic database managed if it needs failover, and consolidate the rest.
Staging and previews
Turn off what is not used. Stop preview environments when the pull request closes, and scale staging down outside working hours if your platform supports it.
Measure before and after
Record monthly cost per service before the move. After consolidating, watch CPU, memory and latency for a few weeks. If a host sits above 70 percent memory regularly, add capacity before it becomes an incident.
Typical results
Teams moving a dozen low traffic services from per service managed hosting to two well sized VPS instances often see savings of 50 to 80 percent. The tradeoff is ownership of updates and backups, which a deployment platform can mostly automate.
Where not to consolidate
- Workloads with strict isolation or compliance needs
- Services with very spiky resource usage that would disturb neighbors
- Anything that already scales automatically and cost effectively
More techniques, including image size and build caching, are in this article on reducing your cloud bill with Docker.
Disclosure: I work on Peon, a self-hosted deployment platform built around this kind of consolidation.
Write a comment