AWS मध्ये Auto Scaling म्हणजे काय? Min, Max आणि Desired सोप्या भाषेत

By Ravindra Bagale, trainer · LinkedIn · Last updated: 18 October 2026

1. Manual scaling का फसतं

फक्त alarm आणि SNS असेल तर scaling असं दिसतं:

1. Average CPU 5 minutes 70% च्या वर राहतो; alarm वाजतो.
2. SNS admin ला email करतो.
3. Admin तो वाचतो, AMI मधून server launch करतो आणि target group मध्ये register करतो.
4. Admin झोपलेला, प्रवासात किंवा busy असेल तर step 3 होतच नाही, आणि चालू servers slow होऊन crash होऊ शकतात.

समजा आपण Hotstar आहोत आणि मोठी cricket match चालू आहे. Match रंगात आली की minutes मध्ये viewers वाढतात. नवीन servers ready व्हायला minutes लागतात, म्हणून launching आपोआप, लगेच सुरू व्हायला हवं.

2. Auto Scaling कसं चालतं

1. CloudWatch alarm group चा average CPU बघतो.
2. तो वाजला की Auto Scaling group ची scaling policy थेट call करतो, उदा. "1 instance add करा". (SNS फक्त लोकांना कळवायला; scaling साठी त्याची गरज नाही.)
3. Policy desired एकाने वाढवते.
4. Group त्याच्या launch template मधून, तुम्ही निवडलेल्या subnets मध्ये, server launch करतो.
5. Group त्याला load balancer च्या target group मध्ये आपोआप register करतो. Health check pass झाला की त्याला traffic मिळतं.
6. Low alarm वाजला (उदा. average 30% च्या खाली) की policy desired कमी करते आणि group एक server terminate करतो.

सगळे policy types (simple, step, target tracking, scheduled) Every Auto Scaling policy मध्ये आहेत.

3. Launch template: प्रत्येक नवीन server ची recipe

Group ला नक्की काय launch करायचं ते माहीत हवं. Launch template ते एकदाच ठेवतो:

1. AMI: तुमच्या तयार web server ची image (Nginx, PHP, तुमचा code).
2. Instance type: उदा. t3.micro.
3. Key pair: SSH साठी, गरज असेल तर.
4. Security group: उदा. web-sg, जो फक्त load balancer च्या SG कडून 80 allow करतो.
5. Storage (EBS): root volume ची size आणि type.
6. User data: पहिल्या boot ला चालणारी script, उदा. web server सुरू करायला किंवा latest code आणायला.

छोटं user data example:

```bash

!/bin/bash

sudo yum install nginx -y sudo service nginx start ```

Subnets template मध्ये नसतात; ते group मध्ये निवडायचे.

Golden AMI: एक development server बनवा, त्यावर Nginx आणि तुमचा code install करा, test करा, मग Actions > Image and templates > Create image. Template तोच AMI launch करतो, म्हणून प्रत्येक नवीन server boot ला सगळं install करण्याऐवजी एक-दोन minutes मध्ये तयार होतो.

Template versions: launch template app updates सारखे क्रमांक असलेले versions ठेवतो. Version 1 तुमच्या app 1.0 चा AMI वापरतो; app 2.0 तयार झालं की नवीन AMI बनवून तो त्याच template चा version 2 म्हणून save करता. मग group आपले servers नवीन version वर नेऊ शकतो (section 11).

4. Min, desired आणि max

1. Desired: आत्ता किती servers चालायला हवेत. Group नेहमी चालू संख्या desired इतकी ठेवायला काम करतो.
2. Min: desired याच्या खाली कधीच जात नाही, रात्री 2 वाजता सुद्धा.
3. Max: सगळे servers busy असले तरी desired याच्या वर कधीच जात नाही.

Worked example 1: scale out. समजा min 1, desired 2, max 4.

1. Average CPU 70% च्या वर राहतो: desired 2 → 3. तिसरा server सुरू.
2. अजून 70% च्या वर: desired 3 → 4.
3. अजून 70% च्या वर: desired 4 च राहतो. 5वा server नाही, कारण max 4.

Worked example 2: scale in. तोच group रात्री 2 वाजता.

1. Average CPU 30% च्या खाली: desired 4 → 3, मग 3 → 2, मग 2 → 1.
2. अजून कमी: desired 1 च राहतो. Min 1 असताना 0 होऊ शकत नाही.

5. किती servers सुरू होतात?

नवीन group desired इतके launch करतो, min नाही.

1. समजा min 2, desired 3, max 6.
2. बनवल्यावर 3 servers launch होतात.
3. नंतर policies desired 2 ते 6 मध्ये कुठेही हलवतात.

6. Max तुमचं bill वाचवतो

1. AWS वापरल्यानंतर bill करतो, चाललेल्या प्रत्येक server चं.
2. योग्य max नसेल तर अचानक spike, CPU खाणारा bug, किंवा junk traffic चा पूर, plan पेक्षा कितीतरी जास्त servers launch करू शकतो.
3. म्हणून max तुम्हाला परवडेल तेवढा ठेवा. खरी growth झाली आणि जास्त लागले, तर तो स्वतः, ठरवून वाढवा.

Worked example: max चा खर्च किती? समजा एका server चा खर्च तासाला ₹1 आहे (गणित सोपं ठेवायला घेतलेला गोल आकडा) आणि max 4. हा group जास्तीत जास्त 4 × ₹1 × 24 = दिवसाला ₹96 खर्च करू शकतो. Max 40 असेल तर ceiling दिवसाला ₹960. तुमच्या आकड्यांसाठी तुमच्या instance type ची खरी किंमत वापरा.

7. Subnets, AZs, आणि प्रत्येक tier ला एक group

1. Group तुमच्या VPC मध्ये तुम्ही निवडलेल्या subnets मध्ये launch करतो, आणि servers त्यांच्या AZs मध्ये वाटतो. एका AZ मध्ये problem आला तर बाकीचे serve करत राहतात.
2. Web tier आणि app tier चं काम आणि load वेगळं, म्हणून प्रत्येकाला स्वतःचा load balancer आणि स्वतःचा Auto Scaling group:
3. Internet → internet-facing load balancer → web Auto Scaling group.
4. Web tier → internal load balancer → app Auto Scaling group.
5. Database RDS आहे, जो स्वतःच्या पद्धतीने scale होतो (मोठा instance, read replicas).

सगळं एकत्र, highly available: 2 AZs, प्रत्येकात 4 subnets: एक public (load balancer, NAT gateway, bastion), आणि web, app आणि database साठी private. म्हणजे 2 × 4 = 8 subnets.

8. Self-healing: फक्त load balancer vs Auto Scaling सोबत

फक्त load balancer:

1. Server health check fail होतो आणि unhealthy mark होतो.
2. त्याला traffic मिळत नाही, पण तो बिघडलेल्या अवस्थेत तिथेच राहतो, कोणी दुरुस्त करेपर्यंत. आता एक server कमी.

Load balancer + ELB health checks सोबत Auto Scaling group:

1. Group load balancer ला त्याचे कुठले servers healthy आहेत ते विचारतो.
2. Unhealthy server terminate होतो.
3. Launch template मधून नवीन launch होऊन register होतो. कोणी जागं नसताना संख्या परत desired इतकी.

हे चालवणारी setting: group चा health check type default ने EC2 असतो, जो फक्त instance चालू आहे का एवढंच बघतो. Elastic Load Balancing health checks चालू करा, म्हणजे Nginx बंद पडलेला server पण बदलला जाईल. नवीन servers ना judge करण्याआधी boot व्हायला grace period द्या (उदा. 300 seconds).

आणखी एक: group चा server तुम्ही हाताने terminate केला तर group desired गाठायला सरळ नवीन launch करतो. Servers कायमचे बंद करायचे असतील तर desired आणि min 0 करा, किंवा group delete करा.

याचं lab version: Auto Scaling आणि How this connects to scaling.

9. Scaling policy चे प्रकार

का: "CPU जास्त झाला की server add करा" हा फक्त एक मार्ग आहे. वेगवेगळ्या traffic साठी AWS चार देतो.

1. Target tracking (dynamic): तुम्ही एक target देता, उदा. "average CPU 50% ठेवा". Average त्याच्यावर गेला की group servers add करतो आणि बराच खाली आला की remove करतो. CloudWatch alarms तो स्वतः बनवतो आणि सांभाळतो. हाच नेहमीचा पर्याय.
2. Step किंवा simple scaling (dynamic): alarms तुम्ही स्वतः बनवता आणि काय करायचं ते सांगता, उदा. "CPU ≥ 70% 5 minutes: 1 server add करा" (section 13, Part C).
3. Predictive scaling: AWS तुमच्या जुन्या traffic वरून शिकतो आणि नेहमी येणाऱ्या peak आधी servers launch करतो. समजा आपण Netflix आहोत आणि दर Friday संध्याकाळी 6 ला traffic उडी मारतो: predictive scaling साधारण 5:55 पर्यंत servers चालू ठेवू शकतो.
4. Scheduled scaling: ठरलेल्या date आणि time साठी capacity तुम्ही set करता. समजा आपण Flipkart आहोत आणि sale सकाळी 6 ला सुरू होतो, किंवा phone launch 10 ला, किंवा cricket match संध्याकाळी 6 ला: desired त्याच्या जरा आधी वाढेल असा schedule करा.
5. Dynamic policies load आल्यावर react करतात; predictive आणि scheduled त्याच्या आधीच तयार होतात.

Worked example: एक busy server असून scale out का होत नाही

1. Group मध्ये 2 servers आणि 50% average CPU वर target tracking policy.
2. फक्त एका server ला 100% stress करा; दुसरा 0% जवळ राहतो.
3. Average = (100 + 0) ÷ 2 = 50%. तो target वरच आहे, वर नाही, म्हणून group कदाचित server add करणार नाही.
4. दोन्हींना 100% stress करा: average = (100 + 100) ÷ 2 = 100%, 50% च्या खूप वर, म्हणून group max 4 पर्यंत अजून servers launch करतो.

10. Warmup, grace period आणि health checks

Instance warmup (उदा. 60 seconds): नवीन server ला boot होऊन Nginx सुरू करायला वेळ लागतो, आणि तेवढ्या वेळात त्याचे CPU आकडे normal नसतात. Warmup संपेपर्यंत त्याचे metrics group च्या average मधून बाहेर ठेवले जातात, म्हणजे boot होणाऱ्या एका server मुळे अजून scaling होत नाही.

Health check grace period (उदा. 60 ते 300 seconds): launch नंतर server ची health ठरवण्याआधी group किती थांबतो. खूप कमी ठेवला तर boot होत असलेले servers loop मध्ये terminate होतात.

Health check प्रकार:

1. EC2 (नेहमी चालू): instance स्वतः चालू आहे का ते check करतो.
2. Elastic Load Balancing: server ने target group चा health check पण pass करायला हवा, उदा. Nginx / ला उत्तर देतो.
3. Amazon EBS: attach केलेला EBS volume impaired झाला (I/O किंवा hardware problem) की instance unhealthy ठरवतो. Disk किती भरली ते तो check करत नाही; disk usage साठी CloudWatch agent लागतो.

11. Downtime शिवाय servers update करणं

का: समजा load balancer मागे 10 servers तुमचं app version 1.0 चालवतात, आणि version 2.0 तयार आहे. सगळे 10 बंद करून नवीन सुरू केले तर site बंद पडेल.

1. Version 2.0 सकट नवीन AMI बनवा आणि तो launch template चा version 2 म्हणून save करा.
2. Group ला नवीन version कडे point करा.
3. Group वर Instance refresh सुरू करा. तो batches मध्ये servers बदलतो, आणि minimum healthy percentage राखतो, उदा. 90%, म्हणजे 10 पैकी एका वेळी फक्त 1 बदलतो.

Instance maintenance policy: server बदलताना group काय करतो.

1. Launch before terminating: नवीन server सुरू करा, तो healthy होईपर्यंत थांबा, मग जुना terminate करा. Capacity कधीच कमी होत नाही; थोडा वेळ एका extra server चे पैसे लागतात.
2. Terminate and launch: आधी जुना terminate, मग नवीन सुरू. स्वस्त, पण बदलताना capacity कमी होते.

12. Scale-in protection

1. Instance scale-in protection group scale in करताना तो instance terminate होऊ देत नाही. मधेच तुटू नये असं मोठं काम करणाऱ्या server साठी वापरा.
2. छोट्या dips ना protection लागत नाही. समजा आपण cricket match stream करतोय: ad break मध्ये viewers काही minutes कमी होतात आणि परत येतात. Target tracking हळू आणि सावधपणे scale in करतो, आणि policy साठी scale-in बंदही करता येतो, म्हणजे एका minute नंतर परत लागणारे servers group काढत नाही.

13. Console मध्ये बनवा

Part A: launch template

1. EC2 > Launch templates > Create launch template, नाव web-lt.
2. Provide guidance to help me set up a template that I can use with EC2 Auto Scaling tick करा.
3. AMI: तुमची web server AMI (My AMIs). Instance type: t3.micro. Key pair: तुमची.
4. Network settings: subnet निवडू नका; security group web-sg निवडा.
5. Advanced details > User data: section 3 मधली script paste करा. Create launch template.

Part B: Auto Scaling group

1. EC2 > Auto Scaling groups > Create Auto Scaling group, नाव web-asg, launch template web-lt. Next.
2. Network: तुमचा VPC, आणि दोन AZs मधले web subnets. Next.
3. Load balancing: Attach to an existing load balancer, target group tg-web निवडा (तो कसा बनवला).
4. Health checks: Turn on Elastic Load Balancing health checks tick करा, grace period 300 seconds. Next.
5. Group size: desired 2, min 1, max 4.
6. Scaling: आत्ता No scaling policies निवडा (Part C मध्ये add करू). लोकांना launches बद्दल कळावं म्हणून optional SNS notification टाका. Create Auto Scaling group.
7. दोन servers launch होऊन tg-web मध्ये healthy targets म्हणून दिसतात.

Part C: CloudWatch alarm ने चालणारी scaling policy

1. CloudWatch > Alarms > Create alarm > Select metric > EC2 > By Auto Scaling Group, web-asg, CPUUtilization. Statistic Average, period 5 minutes, ≥ 70. Email नको असेल तर notification काढा. नाव web-cpu-high, Create alarm.
2. web-cpu-low तसाच बनवा, < 30 सोबत.
3. web-asg > Automatic scaling > Create dynamic scaling policy उघडा, type Simple scaling, alarm web-cpu-high, action Add 1 capacity units, मग 300 seconds थांबा. Create.
4. Alarm web-cpu-low आणि action Remove 1 capacity units सोबत दुसरी policy बनवा.
5. (Target tracking policy, "average CPU 50% ठेवा", दोन्ही alarms तुमच्यासाठी बनवते; production मध्ये नेहमी हीच निवड.)

Part D: test करा

1. दोन्ही servers वर SSH करून sudo yum install stress-ng -y आणि stress-ng --cpu 2 --timeout 900 चालवा.
2. साधारण 5 minutes मध्ये web-cpu-high In alarm होतो; Activity मध्ये launch दिसतो; desired 3, नंतर 4, कधीच 5 नाही.
3. Stress संपलं की web-cpu-low तो परत खाली आणतो, 1 च्या खाली कधीच नाही.
4. एका server वर Nginx बंद करा: sudo service nginx stop. तो tg-web मध्ये unhealthy होतो, आणि group त्याला बदलतो.

Part E: group ला स्वतःचा load balancer बनवू द्या

1. Create Auto Scaling group मध्ये Load balancing step वर Attach to a new load balancer निवडा: Application Load Balancer, Internet-facing, port 80 वर नवीन target group.
2. Health checks: Elastic Load Balancing health checks चालू करा, grace period 60 seconds. Group size: desired 2, min 1, max 4. Policy: Target tracking, Average CPU utilization, target 50, instance warmup 60 seconds. Maintenance policy: Launch before terminating.
3. Activity मध्ये launches दिसतात, उदा. "changing the desired capacity from 0 to 2". Instance management मध्ये दोन्ही InService दिसतात; target group मध्ये ते initial मधून healthy होतात.
4. Load balancer चं DNS name उघडा. Timeout झालं तर load balancer चा security group internet कडून HTTP 80 allow करत नाही: त्यात HTTP, 80, 0.0.0.0/0 add करा, आणि page load होतं.
5. Servers च्या security group वर 80 फक्त load balancer च्या security group कडून allow करा. Servers ना public IPs लागत नाहीत: load balancer त्यांच्यापर्यंत private IPs वर पोहोचतो.

Part F: group मधल्या server ला SSH

1. EC2 Instance Connect किंवा SSH साठी servers च्या security group मध्ये port 22 open हवा; 0.0.0.0/0 पेक्षा My IP वापरा.
2. Private subnets मधल्या servers साठी jump server मधून जा: ssh -J ec2-user@<jump-public-ip> ec2-user@<private-ip> (Bastion Host आणि NAT Gateway ने Private EC2 कसा access करायचा).
3. Windows वर PowerShell मध्ये chmod 400 चालत नाही. Key file च्या Properties > Security > Advanced मध्ये inheritance disable करा आणि फक्त तुमच्या user ला Read ठेवा; किंवा Git Bash किंवा WSL मधून SSH चालवा.
4. सैल permissions असलेल्या key ला UNPROTECTED PRIVATE KEY FILE warning येते. Login आधी Connection closed किंवा timeout म्हणजे सहसा network, security group किंवा firewall problem, key नाही.

14. काही चुकलं तर

1. नवीन servers launch होतात पण unhealthy च राहतात: user data fail झाला, AMI तयार web server ची नाही, किंवा web-sg load balancer SG कडून 80 allow करत नाही.
2. Servers सारखे terminate आणि launch होत राहतात: boot ला लागणाऱ्या वेळेपेक्षा grace period छोटा, किंवा health-check path error देतो.
3. Unhealthy target कधीच बदलला जात नाही: group चा health check type अजून फक्त EC2. ELB health checks चालू करा.
4. Alarm वाजतो पण काहीच launch होत नाही: desired आधीच max वर आहे, किंवा alarm scaling policy ला नाही, फक्त SNS ला जोडलाय.
5. तुम्ही servers terminate केले पण ते परत आले: group आपलं काम करतोय. Desired आणि min 0 करा, किंवा group delete करा.

15. संपूर्ण class एका page वर

1. Alarm → SNS → माणूस म्हणजे manual scaling; माणूस busy किंवा झोपलेला असेल तर फसतं.
2. Auto Scaling: alarm group ची scaling policy थेट call करतो; SNS फक्त लोकांसाठी.
3. Launch template: AMI, instance type, key pair, SG, EBS, user data. Subnets group मध्ये निवडायचे.
4. Desired = आत्ता चालू; min = खालची मर्यादा; max = वरची मर्यादा. Min 1, desired 2, max 4: वर 4 पर्यंत, खाली 1 पर्यंत.
5. नवीन group desired ने सुरू होतो, min ने नाही (min 2, desired 3, max 6 → 3).
6. Max म्हणजे तुमची खर्चाची मर्यादा; ठरवून वाढवा.
7. प्रत्येक tier: स्वतःचा load balancer (internet-facing / internal) आणि स्वतःचा group, AZs मध्ये.
8. ELB health checks चालू असतील तर group unhealthy servers बदलतो; फक्त load balancer त्यांना traffic पाठवणं थांबवतो एवढंच.
9. हाताने terminate → बदलला जातो. कायमचं थांबवायला: desired आणि min 0, किंवा group delete.
10. Policy प्रकार: target tracking (target राखा), step/simple (तुमचे alarms), predictive (नेहमीच्या peaks आधी), scheduled (ठरलेल्या dates).
11. Warmup boot होणारे servers average बाहेर ठेवतो; grace period health ठरवणं पुढे ढकलतो; EBS health checks impaired volumes पकडतात, भरलेल्या disks नाही.
12. नवीन version: नवीन AMI → template version 2 → instance refresh; launch before terminating capacity राखतो.
13. Scale-in protection मोठं काम करणाऱ्या server ला terminate होऊ देत नाही.

16. घरी करून बघा

Recap

झटपट उजळणी cards

हा lesson दोन मिनिटांत revise करा. Cards phone वर save करा किंवा PNG download करा. प्रत्येक card वरचा QR त्याचा lesson उघडतो.

अजून cards: Ravi Sir's Cards.