Cloud Scaling for Platforms: Find Bottlenecks, Control Costs

Cloud scaling works in a fixed order: measure the bottleneck, optimize the database and its queries, introduce caching and background processing, and only then scale instances up and down automatically. Larger or additional servers only help if computing power really is the bottleneck – on web platforms it is far more often found in the database, in slow queries or in work that is done synchronously although it could run in the background.

For mid-sized companies, scaling rarely means “as big as possible”; it means “reliable, affordable and manageable by your own team.” This article shows the right order of measures, the observability you need, the most important cost levers, and what to watch for in resilience, security and choice of provider (as of October 2026).

Scaling in the right order

When load problems appear, reaching for a bigger instance is tempting. But it is the most expensive and often the least effective measure. It is better to pull the cheap and effective levers first. The overview maps typical symptoms to their causes and the right first measure.

Symptom	Typical cause	First measure	Effort
Pages slow down under load, web servers barely busy	slow database queries, missing indexes, N+1 queries	analyze queries, add indexes, batch queries	low
The same data is recalculated again and again	missing caching	cache for frequent queries, HTTP caching, CDN for static content	low to medium
Reports, imports or email sending slow down user requests	work runs synchronously within the request	queue with background worker processes	medium
Read access overloads the database	all queries run on the primary instance	read replicas, caching of read results	medium
Application server CPU permanently high	genuine computing demand	stateless instances behind a load balancer, autoscaling	medium
Database write load at its limit	primary database exhausted	rework the data model, larger instance, partitioning; sharding only as a last step	high

The further down the table, the bigger the undertaking. The upper measures can usually be implemented with manageable effort and often deliver the biggest effect. The lower ones are projects in their own right that you should only tackle once measurement justifies them.

Scale vertically or horizontally?

• Vertical scaling means more CPU and memory for one instance. It is simple and needs no rebuild, but it hits limits and leaves a single point of failure in place.
• Horizontal scaling means several identical instances behind a load balancer. It is more robust and easier to fine-tune, but it requires a stateless application.

Stateless means: sessions are kept in an external store such as Redis or in the database, uploaded files in object storage, configuration in environment variables. If an instance only works with local state, it cannot be added or removed at will – and autoscaling stays theoretical.

The bottleneck behind the web server: the database

Every additional application instance opens more connections to the database. If you scale only the application, the load on the database grows with it – and the bottleneck moves there. Connection pooling, read replicas and a look at the most expensive queries therefore come before every scaling step. Heavy tasks such as reports, image processing or bulk emails belong in queues so that the application stays responsive for users even when a lot is happening in the background.

Which operating model suits your platform?

Scaling also depends on how you run the platform. More automation generally means more convenience under load, but also more operational know-how and higher baseline costs.

• Managed application platform (PaaS): you supply code or containers, the provider runs servers, updates and autoscaling. For many web applications the most economical choice, with less control over details.
• Virtual servers (IaaS): full control and easy to budget, but patching, hardening and scaling are up to you – sensible only with infrastructure as code.
• Kubernetes: powerful with many services and several teams, but operationally demanding. For a single product it is usually more than you need.
• Serverless: pay per use, no server operations. It suits fluctuating load and event processing; under permanently high load it can become more expensive, and runtime and provider limits must be considered.

Observ­ability: seeing what is happening

Without measurements, every optimization is flying blind. Three data sources belong together, and OpenTelemetry provides a vendor-neutral standard for capturing them from your application:

• Logs: What happened? Error messages, requests, events.
• Metrics: How does the system behave over time? Response times, utilization, error rates.
• Traces: Where does a single request spend its time – in the code, in the database, at an external service?

Alerts tied to the user experience

Many teams alert on technical thresholds such as high CPU utilization – and get woken up at night although no user notices anything. Service level objectives (SLOs) are more meaningful. An example: “Product search responds within one second for 99% of requests.” If that goal is missed, it is a real problem, regardless of how busy any single server is. Also link alerts to business impact: does the incident affect checkout, login or just an internal report?

Load tests before the real thing

You should not find out on the day itself whether a platform can handle a campaign, a seasonal launch or a press feature. With tools such as k6, Locust or JMeter you simulate many concurrent users – ideally in a production-like environment with realistic data volumes. The test shows where the system gives way first and delivers a reliable statement: up to this load, response time stays within the target. With that knowledge you can improve things calmly instead of under pressure.

Controlling cloud costs

The cloud makes scaling easy – and spending too. Without regular review, costs often grow faster than usage. Under the term FinOps, an established practice has emerged for this: make costs visible, name owners, optimize regularly. The most important levers:

• Rightsizing: match instances and databases to actual demand instead of paying for peak load around the clock.
• Autoscaling with limits: a lower limit for availability, an upper limit against cost explosions caused by misconfiguration or attacks.
• Reservations for the baseline load: for resources needed permanently, reservations or savings plans are cheaper than on-demand pricing; interruptible jobs run on cheaper spot capacity.
• Cleaning up: switch test environments off outside working hours; delete old snapshots, unused volumes and load balancers.
• Allocating costs: tag resources by project and environment and attach alerts to budgets.
• Limiting log volume: set retention periods and the level of detail for logs – on many platforms, logs are an underestimated cost item.

Some costs result from architecture decisions: data transfer between regions and to the internet, many small services each with their own baseline load, or databases permanently sized for rare peaks. Whether many small services are needed at all is covered in our article Microservices or monolith.

Security and resilience

Responsibility grows with the platform. In the cloud, the shared responsibility model applies: the provider secures the infrastructure, while you remain responsible for configuration, access, data and your application. Managed services take work off your hands, but not the responsibility.

• Grant access on the principle of least privilege, set up separate roles for people and services, and require multi-factor authentication for all administrators
• Keep secrets such as passwords and API keys in a secret store, not in the source code
• Schedule updates for operating systems, runtimes and dependencies as a fixed routine
• Store backups separately from the production system, for example in another account or region, and practice restoring them regularly

Define two target values for every application: the recovery time objective (RTO) says how long an outage may last at most, the recovery point objective (RPO) how much data may be lost at most. These determine how elaborate disaster recovery needs to be. Availability, too, is a question of cost:

Availability target	Downtime per year (calculated)	Downtime per month (calculated)
99%	approx. 3.65 days	approx. 7.3 hours
99.9%	approx. 8.8 hours	approx. 43.8 minutes
99.95%	approx. 4.4 hours	approx. 21.9 minutes
99.99%	approx. 53 minutes	approx. 4.4 minutes

Every additional nine requires redundancy across several availability zones or regions, automated failover and rehearsed procedures – and costs accordingly. So ask, for each system, what an hour of downtime actually costs, and choose the target on that basis.

Choice of provider, data protection and lock-in

Before moving, check which region your data resides in, whether a data processing agreement is in place and on what legal basis data is transferred to providers outside the EU. The EU Data Act has applied since September 12, 2025 and strengthens the right to switch providers: cloud providers must make switching possible, and charges for the switch itself are abolished from January 12, 2027. Ongoing data transfer costs in normal operation are not affected. Technically, you limit lock-in with containers, infrastructure as code and open standards; use proprietary specialty services deliberately. This article does not replace legal advice.

Practical example: a B2B portal before the season

Suppose a wholesaler runs a B2B portal and expects significantly more concurrent orders because of a catalog promotion. The load test shows that response times rise above a certain load even though the web servers are barely busy. The traces reveal that a price calculation spends most of its time in the database. An additional index and a cache for price lists remove the bottleneck, and the export of large order lists moves into a queue. Only then is autoscaling with upper and lower limits switched on, complemented by a budget with an alert. The second load test confirms that the response-time target holds – without paying for permanently larger servers.

Checklist: is your platform ready for growth?

• Bottlenecks are measured, not assumed
• The most frequent queries are reviewed, indexes and caching are in place where they make sense
• The application is stateless, or there is a plan for it
• Heavy tasks run in the background via queues
• Logs, metrics and traces come together in one place
• Alerts are based on user-relevant goals (SLOs)
• Load tests were run before important events
• Costs are reviewed monthly, resources are assigned to projects, budgets trigger alerts
• Access rights follow the principle of least privilege, secrets are in a secret store
• RTO and RPO are defined, restoring has been tested successfully – not just creating the backup
• Deployments are automated and traceable, as described in our article DevOps and GitOps

How Nano Concepts can help

Nano Concepts supports you with architecture, databases and cloud infrastructure as well as DevOps and CI/CD – from analyzing existing bottlenecks to ongoing operations. If a move is on the agenda, you will find our approach under cloud migration. In a free initial consultation, we clarify where your platform stands today and which steps make sense next.