Vertical Scaling

Vertical scaling means scaling up by giving an existing resource more capacity, or scaling down by reducing its capacity. Moving a virtual machine from a configuration with two virtual CPUs and 8 GiB of memory to one with eight virtual CPUs and 32 GiB of memory is a typical example. Horizontal scaling instead adds or removes instances, replicas, or workers. An architecture can combine both approaches: several application servers can each use a larger instance size while their number also changes with demand.

Vertical scaling is useful when a workload needs a larger memory working set, more CPU capacity, or greater per-instance network and storage bandwidth. It often suits legacy applications and relational database writers that cannot easily distribute work across multiple nodes. However, additional CPUs help only when the application can use them. A single-threaded process might benefit more from better per-core performance, while a memory-constrained database might benefit from a larger buffer cache.

Choose a target configuration using measurements rather than CPU utilization alone. Examine memory pressure, swapping, query latency, connection counts, storage latency, throughput, and queue depth. Distinguish compute bottlenecks from storage bottlenecks: increasing database memory will not necessarily resolve an exhausted storage IOPS limit. Provisioned IOPS, storage throughput, and instance-level storage bandwidth are separate capacity-planning dimensions, and the lowest applicable limit can constrain performance.

In Amazon EC2, a common vertical-scaling operation is to stop an EBS-backed instance, change its instance type to a compatible type, and start it again. This interrupts the workload. Check processor architecture, driver compatibility, network configuration, and storage behavior before proceeding. Stopping an instance loses instance-store data, and an automatically assigned public IPv4 address generally changes after stop and start. EC2 hibernation preserves memory state for later resumption on supported configurations; it is not itself a scaling mechanism or a general method for resizing a running workload.

For Amazon RDS, changing the DB instance class adjusts compute and memory capacity. Plan for possible service interruption, select the appropriate maintenance timing, and test client reconnection behavior. A Multi-AZ deployment provides availability protection, but it does not make every class modification interruption-free. Adding read replicas is horizontal read scaling, not vertical scaling, and does not directly increase the primary writer's capacity. RDS storage autoscaling addresses storage growth rather than CPU or memory demand, and allocated storage generally cannot be reduced in place.

Managed services do not all expose scaling in the same way. Aurora Serverless v2 can automatically adjust compute and memory capacity within configured bounds. DynamoDB instead exposes provisioned read and write capacity or on-demand throughput, rather than a database instance size. Increasing DynamoDB capacity units is throughput scaling, not conventional instance-based vertical scaling; partition distribution and hot keys still affect results.

Vertical scaling has a finite ceiling determined by available resource sizes and service limits. It also leaves the workload dependent on the same number of failure domains. Horizontal scaling is often preferable for stateless applications with rapidly changing demand, while vertical scaling can be simpler for stateful or tightly coupled components. Amazon EC2 Auto Scaling normally changes instance count; it does not automatically resize running instances. Adopting a larger instance type through a launch template and instance refresh replaces instances rather than resizing them in place.

For cost optimization, compare the price of a larger instance with the throughput and latency improvement it actually delivers. Scaling down during sustained low demand can reduce waste, but repeated resizing may introduce unacceptable disruption. Maintain headroom, test the change under representative load, and define recovery or rollback procedures. Scalability is the ability to support greater load; elasticity adds timely adjustment as demand changes, which requires automation or operational procedures rather than simply choosing a large instance.