Compute rightsizing, scaling, availability, and load-balancer economics

Rightsizing starts with the resource that limits completed work. Inspect CPU percentiles, memory pressure, network packets and bytes, EBS throughput and IOPS, accelerator use, request rate, latency, and queueing over representative peaks. Average CPU cannot clear a memory-bound service. Vertical scaling changes the capacity of one instance and may require stop, restart, or replacement; it is useful for a stateful or single-thread-constrained component but retains a finite ceiling and can enlarge a failure unit. Horizontal scaling adds replaceable instances and is favored for stateless tiers that can distribute traffic and externalize session state. It improves aggregate capacity and failure replacement but adds coordination, load balancing, warm-up, and downstream connection pressure. Compare both against the bottleneck and deployment model. Preserve enough healthy capacity to meet demand after the declared instance or AZ failure. A smaller fleet that passes normal load but collapses when one AZ is unavailable is not rightsized. Select a proportional scaling signal such as requests per target when it tracks load better than host CPU.

Nonproduction demand should be treated as a schedule rather than a discounted always-on baseline. Stopping an EC2 instance removes compute charges but leaves attached EBS and other resources billable; starting requires applications to rebuild memory state. Hibernation preserves RAM contents to the encrypted root EBS volume and can shorten resume for eligible workloads, but it must be enabled and satisfy current AMI, instance-family, RAM, root-volume, and other prerequisites documented by AWS. It is a launch-time architecture choice, not an emergency toggle for every running host. Use it when expensive in-memory tool state has measurable reload value that exceeds additional storage and operational constraints. Ordinary stop/start wins when boot and warm-up are cheap. Termination or ephemeral recreation wins when no local state is needed. Always-on capacity wins only when availability or unpredictable access makes scheduling invalid. Recheck eligibility and maximum hibernation behavior because these details evolve. A schedule should include holidays, time zones, patch windows, and an exception process so savings automation does not interrupt active work.

Choose load-balancer function before comparing bills. ALB provides HTTP and HTTPS Layer 7 routing such as host or path decisions. NLB serves Layer 4 transport needs including TCP or UDP and supports static-address-oriented designs. GWLB inserts and scales compatible virtual appliance fleets rather than routing application URLs. Each service carries load-balancer time and a capacity-unit dimension under current ELB pricing, so traffic characteristics—not just bytes—affect cost. Include target fleet hours, cross-zone or transfer paths where applicable, logging, and spare capacity for a failed AZ. Health checks decide target eligibility, but a passing listener path does not prove the application fulfills its transaction SLO; inspect target response and dependency health. Horizontal scaling behind the correct load balancer can reduce idle peak capacity, provided warm-up and downstream limits are modeled. Vertical scaling may remain the better short-term repair for a memory-bound monolith that cannot safely duplicate state. Document the condition that would reverse the choice, then verify the selected architecture with a peak test and an AZ-capacity-loss test.