Vertical Scaling

Vertical scaling, or scaling up, means increasing the capacity of a single instance instead of adding more instances. You give one machine, database or pod more or faster CPU, more memory, faster storage or more network bandwidth. In AWS that means a larger size or a newer generation, for example Aurora r7g.8xlarge to r7g.12xlarge or Graviton2 to Graviton4, a different family such as compute-optimised c7g or memory-optimised r7g, provisioned IOPS, or higher pod requests and limits in Kubernetes. It contrasts with horizontal scaling, which adds instances and spreads the load. Most real systems use both: vertical for stateful components, horizontal for stateless compute.

Its main advantage is simplicity: you get more capacity with no code changes and no distribution complexity, because there is still exactly one copy of the state. A relational writer that scales up keeps strong consistency, local transactions and joins; there is no sharding key to choose, no cross-shard query, no rebalancing and no distributed transaction. That makes it the fastest and safest way to buy capacity for databases, legacy monoliths and in-memory workloads. At ShopNow the orders writer went from 16 to 32 vCPUs through a reader promotion with about 30 seconds of failover, while a sharding project would have taken months of design and migration.

There are four main limits. First, a hard ceiling: the largest instance class exists, and growth will eventually reach it, so vertical scaling only buys time. Second, a larger failure domain: one big node holds all the load, so its failure or maintenance affects everything unless replicas and failover are in place. Third, possible disruption: some resizes need a restart or failover, although reader promotion and online scaling keep this to seconds. Fourth, cost grows faster than benefit near the top, and per-core software licences make big machines expensive. Software must also use the extra cores; a single-threaded or lock-bound workload will not get faster.

Use reader promotion rather than modifying the writer in place. Add a new Aurora replica with the target instance class to the cluster at promotion tier 0, and wait until it is available; because Aurora replicas share the cluster storage volume, there is no data copy and replica lag is typically milliseconds. Then trigger a failover to that replica, which usually takes around 30 seconds, while RDS Proxy keeps client connections open and reduces errors during the switch. Finally remove the old writer, or keep it as a reader. Expect a cold buffer cache on the new instance, so do it off-peak and keep the replicas the same class as the writer.

Look at what saturates as load rises. A CPU-bound workload shows sustained CPU above about 70% with latency rising, a run queue longer than the number of cores, database load dominated by CPU in Performance Insights, and hot methods in JFR or async-profiler flame graphs. A memory-bound workload shows a working set larger than RAM: falling buffer or cache hit ratios, more disk reads, frequent GC that reclaims little memory, evictions or OOM kills, while CPU stays moderate. Check container throttling too, because a CPU limit can look like CPU-bound behaviour. The diagnosis picks the family: compute-optimised c7g for CPU, memory-optimised r7g or x2g for memory.

Scaling up does not help when the bottleneck is not a resource the bigger machine adds. The common case is contention: lock waits on hot rows, a single synchronized section or a single-threaded process, where extra cores simply sit idle. ShopNow moved its inventory database to a larger instance and nothing changed, because 70% of database load was transaction-ID lock waits on hot SKUs; the fix was sharded counters. It also fails when the limit is external, such as a slow dependency, network latency, a connection limit on a partner API, or an inefficient algorithm whose cost grows faster than the hardware. Diagnose the bottleneck before buying capacity.

A bigger heap changes GC behaviour, so the collector and sizing need revisiting. G1 is fine up to about 4 GB, but larger latency-sensitive heaps should use generational ZGC, the only ZGC mode in Java 25, whose pauses stay below a millisecond regardless of heap size. Watch the 32 GB boundary: above it compressed object pointers are switched off and references take twice the space, so size to about 31 GB or go much larger. In containers, set -XX:MaxRAMPercentage to around 65 to 75 to leave room for metaspace, thread stacks, direct buffers and the OS, set memory requests equal to limits, and avoid tight CPU limits.

Often a newer CPU generation at the same size. Each generation gives more work per core for a similar price, so the CPU time per request falls without any architectural change. When ShopNow moved checkout pods from Graviton2 to Graviton4, CPU per request dropped from 110 to 82 ms, about 25% less, at a similar hourly cost. The move needs an arm64 container image and a quick check of native libraries, but Java code runs unchanged. Right-sizing over-provisioned services using VPA or Compute Optimizer recommendations is the other cheap move, because it frees money and node capacity for the services that really need to scale up.

Compute the ceiling horizon and start the next step before you reach it. Take today's peak utilisation, the growth rate and the largest instance class available, and work out when peak utilisation on that largest class would cross your threshold, usually around 70%. ShopNow's orders writer runs at 55% of 48 vCPUs at peak and grows 60% a year; even on the 64-vCPU class it reaches 70% in about 1.1 years. Sharding needs about nine months of lead time, so design starts now. Meanwhile, reduce demand with query fixes, caching and read replicas, and design data for later partitioning, with partition keys and no cross-entity transactions.

When the extra demand is predictable and short, such as a Diwali sale week, a product launch or month-end batch processing. Scaling up for the event and back down afterwards avoids paying for a large instance all year and avoids a risky architectural change for a peak that lasts days. ShopNow moves its orders writer from r7g.8xlarge to r7g.12xlarge and its Valkey nodes up one size for sale week, for about ₹3.1 lakh extra, then reverses both. Schedule the change days before the event using reader promotion and online scaling, warm the caches, load-test at the new size, and make scaling down an explicit part of the plan.