š High Availability (HA) vs š¼ Scalability
š High Availability (HA) vs š¼ Scalability
| Feature | High Availability (HA) | Scalability |
|---|---|---|
| Definition | Ensuring the system is continuously operational, even during failures | Ability to handle increased load by adding resources |
| Goal | Minimize downtime | Improve performance & capacity |
| Focus Area | Reliability, fault tolerance, uptime | Growth, performance, elasticity |
| Achieved by | - Multi-AZ deployments- Load balancers- Auto healing | - Auto Scaling Groups- Load balancing- Horizontal/vertical scaling |
| Typical AWS Services | - ELB (Elastic Load Balancing)- RDS Multi-AZ- Route 53 Failover- EC2 in multiple AZs | - EC2 Auto Scaling- DynamoDB scaling- Elastic Beanstalk- Lambda concurrency |
| Measured by | Uptime %, fault tolerance | Throughput, latency, resource utilization |
| Example | App still runs if one AZ fails | App scales from 2 to 20 EC2 instances on traffic spike |
š In Simple Terms:
- High Availability = "Your app keeps running even when parts fail."
- Scalability = "Your app can grow (or shrink) with traffic demand."
šÆ AWS Real-World Example
š¹ High Availability:
- Deploy a web app in 2+ Availability Zones
- Use Elastic Load Balancer (ELB) to route traffic
- Use RDS Multi-AZ to keep database resilient
šø Scalability:
- Enable Auto Scaling for EC2 instances
- Use DynamoDB on-demand capacity to scale with traffic
- Implement stateless architecture for horizontal scaling
ā Summary Table
| Criteria | High Availability | Scalability |
|---|---|---|
| Main Goal | Keep system up and running | Handle more users or data |
| Planning for | Failures | Growth |
| AWS Tools | ELB, Multi-AZ, Route 53 failover | Auto Scaling, ECS/EKS, DynamoDB, Lambda |
| Downtime | Aims for zero or near-zero | Not the focus |
Ā
š Horizontal vs š Vertical Scalability
| Aspect | Horizontal Scalability | Vertical Scalability |
|---|---|---|
| Also Known As | Scale-out | Scale-up |
| How it works | Add more machines/nodes | Increase resources of existing machine |
| Example | Add more EC2 instances behind a Load Balancer | Increase CPU/RAM of a single EC2 instance |
| Elasticity | Highly elastic | Limited by instance type/hardware |
| Fault Tolerance | ā Better (failure of one doesn't break system) | ā Poor (single point of failure) |
| Cost Over Time | More cost-efficient at large scale | Becomes expensive for high-end instances |
| AWS Services | Auto Scaling Group, ECS, EKS, DynamoDB, RDS Read Replicas | EC2 instance resize, RDS instance class upgrade |
| Best for | Distributed, stateless systems | Quick performance boost for small-scale apps |
š¦ AWS Real-World Example
š¹ Horizontal:
- Launch 5 small EC2 instances instead of 1 large one
- Use Auto Scaling + ELB to distribute traffic
- Example: Web servers, microservices, stateless APIs
šø Vertical:
- Upgrade from
t3.mediumtom5.2xlargeEC2 instance - Example: Legacy apps, monoliths, or fast performance tweaks
šÆ Summary Table
| Criteria | Horizontal | Vertical |
|---|---|---|
| Add resources by | Adding more servers | Upgrading a server |
| Complexity | Higher (needs orchestration) | Simpler (just upgrade instance) |
| Resilience | ā High | ā Low (one point of failure) |
| Scale Limit | Almost unlimited | Hardware-bound |
| AWS Usage Example | EC2 + ELB + Auto Scaling | EC2 instance type upgrade |