A $30/month VM can look like a bargain. But microservices add network hops, telemetry, duplicate environments, and operational work. Those costs can outweigh cheap compute.
Network and telemetry turn cheap compute into a larger bill
Microservice costs rise through data transfer, managed network services, and observability. Observability includes logs, metrics, and traces. These show what happens across services.
Internal calls are not always free
Cross-availability-zone traffic moves data between separate cloud data centers in one region. It improves availability while adding per-GB charges. A chatty design multiplies the effect.
Ten million requests can trigger 12 calls with 100 KB payloads. That moves roughly 11 GB before retries, responses, and telemetry. Replication, cache misses, and incidents can raise transfer to 2 to 10 times that estimate.
Every request can cross another paid boundary.
For microservices, a low compute rate matters less than the number of paid boundaries each request crosses.
NAT, egress, and load balancers add up
NAT gateways let private workloads reach the internet. Hourly and per-GB charges apply to logs, package updates, API calls, and telemetry. Internet egress, inter-region replication, and load balancers create separate paid paths.
Check provider pricing before modeling production traffic. Include the AWS pricing catalog in that review.
| Architecture path | Typical paid network boundaries | Latency risk | Best fit |
|---|
| Single-zone VPS | Internet egress only in many plans | Low inside one host | Steady, simple SaaS workloads |
| Multi-AZ public cloud | Cross-AZ, NAT, load balancers | Moderate with remote calls | Apps needing zone failure tolerance |
| Multi-region cloud | Inter-region replication and egress | Higher across regions | Global recovery or residency needs |
Logs and traces can exceed app hosting
Observability grows with every service. One request can produce logs, metric labels, and traces in several systems. Avoid retaining all data at full detail.
High-cardinality metrics and 100% trace sampling for 30 to 90 days are costly defaults.
Telemetry can cost more than the application itself.
A practical telemetry starting point: Retain searchable production logs for 14 to 30 days. Keep security-required audit data separately. Sample normal traces at 1% to 10%, and raise sampling only for failing routes. Measure GB ingested per service every month.
A modular monolith is usually cheaper for small teams
A modular monolith is one deployable application with clear domain boundaries. It can keep code organized without most network, Kubernetes, and monitoring costs.
A monthly model for a small SaaS
This model assumes a US-based SaaS with 10 million monthly requests. It includes a managed database, 30-day logs, development and staging environments, and 99.9% availability. Planning ranges include loaded engineering-hour assumptions of $85 to $130.
| Monthly cost area | Monolith | Modular monolith | Kubernetes microservices |
|---|
| Compute, database, storage | $450-$850 | $550-$1,000 | $1,300-$2,600 |
| Network, ingress, backups | $80-$220 | $120-$350 | $500-$1,500 |
| Monitoring and log retention | $80-$250 | $150-$450 | $600-$2,000 |
| Operations labor | $1,000-$2,000 | $1,700-$3,500 | $4,500-$10,000 |
| Total planning range | $1,610-$3,320 | $2,520-$5,300 | $6,900-$16,100 |
Clean boundaries still prepare growth
Keep billing, identity, catalog, and notifications in separate modules with explicit APIs. Use in-process calls while the team is small. Define data ownership and contract tests early.
Extract a service only when its scaling, deployment, security, or ownership need is proven.
Microservices also change ordinary development costs. Separate teams may need API contract talks and version checks. They may also need test-data coordination, separate CI pipelines, and synchronized releases.
A small checkout change may involve identity, pricing, order, and notification owners. It must be safe before reaching production. Clear ownership and backward-compatible APIs reduce this friction.
Contract tests and documented failure behavior also help. But they need ongoing maintenance.
Small teams often move faster with one release path.
For a small team, an in-process modular monolith can preserve domain ownership. It also keeps one build and a local debugging workflow. The right comparison includes developer time for each customer-facing feature.
Managed Kubernetes reduces control-plane work. But applications still need nodes, ingress, storage, registries, add-ons, and skilled operators.
Requests and limits create idle capacity
CPU requests reserve capacity, and memory limits cap usage. Imperfect packing leaves paid node space unused. Autoscaling also needs room for bursts, rolling releases, and node failures.
Services with 99.9% availability commonly keep 20% to 50% more capacity than normal demand.
Add-ons multiply in every environment
Production clusters often need ingress, load balancers, DNS, secrets, policies, backups, persistent volumes, scans, log shipping, and alerting. Staging and recovery environments repeat many of those costs.
How a $60 compute workload becomes a distributed platform bill
Compute
$60
+
Ingress and NAT
$90-$220
+
Logs and traces
$150-$600
+
Operations time
$1,000+
Exact amounts vary, but the direction is predictable. Every service boundary creates another operating surface.
Distributed debugging has a direct cost. Infrastructure estimates often miss it. One customer timeout can involve an API gateway, authentication, catalog, pricing, inventory, and a queue consumer.
Each component emits only a partial signal. Without consistent request IDs, tracing, and service-level objective dashboards, engineers can spend hours finding the cause. The cause may be code, a dependency, a retry storm, or a network path.
Those operational costs often exceed a small service's compute bill during incidents.
Cloud cost management should track observability costs with reliability outcomes. Measure mean time to detect and mean time to recover. Also measure trace volume and incidents diagnosed without manual log joining.
Price labor, security, and failure modes before migrating
A reliable TCO model includes provider invoices. It also includes the human time needed to keep systems safe and available.
Use this migration cost check
- Service count: List every service, worker, queue, database, cache, and third-party endpoint needed in production.
- Call volume: Multiply monthly requests by internal calls per request. Then estimate request and response bytes.
- Environment count: Include development, staging, preview, production, and recovery capacity. Do not count production alone.
- Telemetry policy: Set log days, trace sample rate, metric labels, and external monitoring data transfer.
- Labor: Estimate between 10 and 40 monthly hours for small-platform care. Then add incident and release work.
- Availability target: Price extra nodes, replicas, backups, and cross-zone transfer needed for promised uptime.
Avoid the costly early mistakes
Do not assume internal traffic is free. Do not default to full tracing, long log retention, or production-like staging. Microservices can make financial sense when teams release independently and often.
They can also fit when one workload needs far more capacity. They fit when isolation lowers reliability or compliance risk.
Start with a modular monolith when one team owns a product and traffic is predictable. Split services only after measuring a distinct scaling, release, or isolation need. This advice does not fit a large organization with independent teams or strict data boundaries. In those cases, service separation can lower outage and delivery risk. Price that risk reduction against added monthly platform and labor costs.
This cost model matters less for a single-service app with minimal traffic. It also matters less for a short-lived prototype. A fully managed platform may intentionally hide network topology and operations. Microservices are not always costly. At enough scale, several teams or strict isolation needs can justify their added monthly cost.
Turn the checklist into a monthly estimate with a simple TCO equation. Monthly TCO = baseline compute and managed services + network charges + observability costs + engineering time.
For network charges, estimate requests × internal calls per request × average bytes. Then apply cloud charges for cross-availability-zone traffic, NAT gateways, internet egress, and multi-region replication. For telemetry, estimate services × requests × log or trace bytes × retention days.
Add separate allowances for high-cardinality metrics and distributed tracing.
Multiply platform, release, incident, and security hours by a loaded hourly rate. Recalculate when service count, SLOs, retention policies, or environment count changes. These variables often grow faster than application traffic.
Common questions
Are microservices more expensive than monoliths?
Usually, yes, for small teams and low-to-medium traffic. Network paths, deployment pipelines, monitoring data, and on-call work can make total cost two to five times higher.
What hidden cloud costs affect microservices most?
Network transfer, NAT gateways, load balancers, managed databases, telemetry ingestion, backups, and labor are frequent hidden costs. Cross-AZ and inter-region calls are especially costly for chatty synchronous services.
Is managed kubernetes worth it for a startup?
It is worth it when the team can own cluster operations. It also fits independent scaling, high availability, or many separately deployed services. It is often premature for one stable application.
How much log retention should a SaaS keep?
Keep searchable application logs for 14 to 30 days. Keep more only when legal, security, or contract needs demand it. Store required audit records separately from debug logs.
Can a cheap VPS run a production SaaS?
Yes, when traffic is steady and the app is simple. Backups and recovery must be tested. Use two instances or a clear restore plan for strict uptime commitments.
When should I split a modular monolith into services?
Split a module when it has a separate scaling pattern, release schedule, data boundary, or compliance need. The benefit must be measurable. Do not split it only because Kubernetes is available.
