AWS मध्ये SNS सोबत CloudWatch CPU Alarm कसा set up करायचा

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

1. Users वाढले: scale up की scale out

का: समजा आपली site popular झाली आणि traffic दर आठवड्याला वाढतंय. एक t3.micro web server दमायला लागतो.

1. Scale up (vertical): मोठा instance type. Type बदलायला instance stop करावा लागतो, म्हणजे तेवढा वेळ site बंद. Details: Vertical scaling.
2. Scale out (horizontal): त्याच size चे जास्त servers, शेजारी शेजारी. Downtime नाही, आणि live apps साठी हीच normal पद्धत. Details: Horizontal scaling.

Scale out केलं की दोन प्रश्न येतात, आणि हा chapter दोन्हींची उत्तरं देतो: एकाच नावाने users अनेक servers पर्यंत कसे पोचणार, आणि server कधी वाढवायचा?

2. दोन servers, एक domain: फक्त DNS का पुरत नाही

समजा example.com चे दोन web servers आहेत. पटकन सुचणारी idea म्हणजे एकाच नावासाठी दोन A records, प्रत्येक server च्या IP साठी एक. मग DNS दोन्ही IPs आळीपाळीने देतो (DNS round robin).

थोडं load वाटलं जातं, पण:

1. असमान: browsers, phones आणि ISPs उत्तर cache करतात. पूर्ण office किंवा पूर्ण mobile network एकाच IP ला चिकटू शकतं.
2. Health checks नाहीत: server 2 बंद पडला तरी DNS त्याचा IP देत राहतो, आणि त्या users ना error येतो.
3. बदलायला वेळ: बंद IP काढला तरी cache केलेली उत्तरं expire झाल्यावरच फरक पडतो (record चा TTL).

Load balancer तिन्ही सोडवतो: users एकाच नावावर येतात, आणि load balancer प्रत्येक request साठी healthy server निवडतो. आधी हाताने करून बघायचं असेल तर Manual load balancing.

3. Server कधी वाढवायचा: CloudWatch, threshold आणि period

Amazon CloudWatch तुमच्या resources कडून आकडे (metrics) गोळा करतो. EC2 साठी इथे आपण CPUUtilization बघतो, percent मध्ये.

"CPU 70% च्या वर, server वाढवा" का नाही? एका spike ने पण trigger होईल.

1. समजा CPU एका minute साठी 90% ला जातो आणि परत 40% वर येतो.
2. नवीन server boot होऊन ready व्हायला काही minutes लागतात. तोपर्यंत spike संपलेला असतो, आणि नको असलेल्या server चे पैसे लागतात.
3. म्हणून threshold आणि period एकत्र वापरा: 5 minutes ची average CPU ≥ 70%.
4. पूर्ण period भर load जास्त राहिलं तरच alarm वाजतो.

Spiky apps मध्ये alarm लवकर. समजा आपण Instagram आहोत आणि breaking news आली: minutes मध्ये users येऊन पडतात. नवीन servers ready व्हायला minutes लागतात, म्हणून team कमी threshold ठेवते, उदा. 50%, किंवा छोटा period, म्हणजे servers लवकर वाढायला लागतात.

Alarm states आणि settings बद्दल आणखी: CloudWatch alarm.

Basic vs detailed monitoring

1. Basic monitoring (free, by default चालू): EC2 दर 5 minutes ला एक data point पाठवतो.
2. Detailed monitoring (paid): दर 1 minute ला एक data point.
3. Worked example: CPU 10:05 ला उडी मारतो. Basic monitoring मध्ये पुढचा data point कदाचित 10:10 लाच येईल, म्हणजे alarm 5 minutes पर्यंत उशिरा react करतो, आणि नवीन servers येण्याआधी overload झालेला server बंद पडू शकतो. Detailed monitoring मध्ये alarm ला ते साधारण 10:06 पर्यंत दिसतं.
4. म्हणूनच नवीन instance चा Monitoring tab सुरुवातीला रिकामा दिसतो: पहिले 5-minute points अजून आलेले नसतात.
5. CPU वर scale होणाऱ्या live projects साठी detailed monitoring चालू करा.

CloudWatch ला by default काय दिसतं, आणि काय नाही

1. Default EC2 metrics operating system च्या बाहेरून येतात: CPUUtilization, NetworkIn, NetworkOut, NetworkPacketsIn, NetworkPacketsOut, disk आणि status checks.
2. Memory (RAM) आणि disk-space usage default metrics नाहीत. AWS ला virtual machine hypervisor कडून दिसतं, OS च्या आतून नाही.
3. ते मिळवायला server वर CloudWatch agent install करा. तो memory, disk आणि तुमचे स्वतःचे metrics पाठवतो.
4. Custom metrics: समजा आपण shopping app बनवतोय आणि "Share" button चे clicks मोजायचे आहेत. App प्रत्येक count PutMetricData API ने CloudWatch ला पाठवतं, आणि तुम्ही CPU सारखाच त्याचा graph आणि alarm बनवू शकता.
5. Logs: access logs 8 GB root disk वर वाढू देऊ नका; requests चा पूर आला तर disk भरून server थांबू शकतो. CloudWatch agent ते CloudWatch Logs log group मध्ये पाठवू शकतो.
6. AWS, Azure आणि Google Cloud एकत्र वापरणाऱ्या teams सगळ्या clouds साठी एक dashboard म्हणून बऱ्याचदा Prometheus आणि Grafana वापरतात. AWS वर CloudWatch हाच built-in पर्याय आहे.

Alarm states:

1. Insufficient data: alarm नुकताच सुरू झालाय, किंवा अजून पुरेसे data points नाहीत.
2. OK: metric threshold च्या आत आहे.
3. In alarm: metric ने period भर threshold ओलांडला; actions (उदा. SNS) चालतात.

4. रात्री 3 वाजता graphs कोणी बघत नाही: alarm ते SNS

का: माणूस रात्रभर CPU graph कडे बघत बसू शकत नाही.

म्हणून alarm स्वतःच लोकांना कळवतो, Amazon SNS (Simple Notification Service) मधून:

1. Topic: नाव दिलेला channel, उदा. cpu-high-alerts.
2. Publisher: topic ला message पाठवणारा. इथे CloudWatch alarm.
3. Subscribers: topic वरचा प्रत्येक message घेणारे: email, SMS, mobile push, Lambda function आणि आणखी.
4. Email subscriber ला आधी AWS कडून mail येतो आणि त्याला Confirm subscription click करावं लागतं. तोपर्यंत काहीच deliver होत नाही.

Email set-up बद्दल आणखी: SNS: email when the alarm changes.

5. नवीन server AMI मधून येतो

Alert आला. Admin नक्की काय launch करणार?

1. चालू असलेल्या web server ची एकदा AMI बनवा (Nginx, PHP, तुमचा code, सगळं set up केलेलं).
2. Alert आला की त्या AMI मधून नवीन instance launch करा. काहीच install न करता तो minutes मध्ये ready.
3. त्याला load balancer मागे add करा (section 7).

हे हाताने करायला अजूनही जागा माणूस लागतो. Auto Scaling हेच steps तुमच्यासाठी करतो; ते Auto Scaling मध्ये आहे.

6. पहिल्या दिवसापासून load balancer

एकाच server ला का? DNS मुळे.

1. Load balancer नसेल तर तुमचा domain थेट server च्या IP कडे जातो (A record).
2. ज्या दिवशी दुसरा server लागेल, त्या दिवशी domain load balancer कडे हलवावा लागेल.
3. तो DNS बदल cache केलेली उत्तरं expire झाल्यावरच पसरतो, म्हणजे TTL वर अवलंबून. तोपर्यंत काही users जुन्याच IP वर जातात, आणि तेही तुमच्या सगळ्यात busy दिवशी.
4. पहिल्या दिवसापासून load balancer असेल तर domain कधीच बदलत नाही. फक्त त्याच्या मागे servers add करायचे.

Load balancer कडे कुठला DNS record point करतो?

1. A record: नाव → IP address. Load balancer ला वापरण्यासारखा एक fixed IP नसतो.
2. Load balancer तुम्हाला DNS name देतो, उदा. my-alb-123456.ap-south-1.elb.amazonaws.com (पुढे http:// नाही).
3. CNAME: नाव → दुसरं नाव. दुसऱ्या DNS provider वर www.example.com साठी हा वापरा. Root domain example.com वर CNAME चालत नाही.
4. Alias A record (Route 53): नाव load balancer कडे point करतो आणि root domain वर पण चालतो. Domain Route 53 मध्ये असेल तर हाच नेहमीचा choice.

7. Target groups आणि average CPU

Target group म्हणजे एक काम करणाऱ्या servers ची list, सोबत port आणि health check. Load balancer requests target group कडे पाठवतो, थेट servers कडे नाही. पूर्ण details: Target groups.

1. समजा एका account मध्ये दोन apps आहेत: प्रत्येक app च्या servers साठी एक target group.
2. नवीन server ला traffic तेव्हाच मिळतं जेव्हा तो target group मध्ये register होतो.

एका server वर नाही, average वर scale करा. समजा 3 servers चा CPU 80%, 70% आणि 60% आहे.

1. Average = (80 + 70 + 60) / 3 = 70%.
2. 5 minutes असंच राहिलं तर alarm वाजतो: 4था server add करा.
3. आता load 4 servers वर वाटलं जातं, आणि average खाली येतो.

प्रत्यक्षात group चा average Auto Scaling group च्या CPUUtilization metric मधून येतो, जो CloudWatch सगळ्या servers वर average करतो.

Scale in पण. रात्री 2 वाजता average खूप खाली जातो, म्हणून एक server काढा आणि त्याचे पैसे वाचवा. दुसरा, low alarm (उदा. average 30% च्या खाली) हे करतो.

8. Health checks: कोणाला traffic मिळत नाही

का: server चालू असतो पण त्यावरचा Nginx बंद असू शकतो. Check नसेल तर load balancer users ना तिकडेच पाठवत राहतो.

कसं चालतं:

1. प्रत्येक interval ला (उदा. 30 seconds), load balancer प्रत्येक target वर एक path मागतो, जसं / किंवा /index.html.
2. HTTP 200 = pass.
3. Unhealthy threshold = target unhealthy mark व्हायला सलग किती checks fail व्हायला हवेत (किमान 2).
4. Unhealthy target ला traffic मिळत नाही; बाकीचे ते वाटून घेतात.
5. Load balancer त्याला check करत राहतो. सलग healthy threshold इतके pass झाले की traffic परत सुरू.

गणित: बंद server वर users किती वेळ जातात? Interval 5 ते 300 seconds असू शकतो.

1. Interval 30 s × unhealthy threshold 2 = 1 minute पर्यंत requests बंद server कडे.
2. Interval 5 s × threshold 2 = साधारण 10 seconds.
3. छोटा interval लवकर react करतो, पण छोट्या hiccup ने पण server लवकर unhealthy होऊ शकतो. App प्रमाणे ठरवा.

Health checks चे प्रत्येक request चे पैसे लागत नाहीत. Application Load Balancer चं bill per hour आणि usage (LCUs) प्रमाणे.

Load balancer फक्त traffic पाठवणं थांबवतो; बिघडलेला server तसाच राहतो. तो आपोआप बदलणं हे Auto Scaling चं काम. सगळी settings Health checks मध्ये.

9. Listener rules: प्रत्येक path त्याच्या target group कडे

समजा आपण Instagram आहोत. Reels बघणं हलकं काम; video upload करणं जड (तो घ्यायचा, process करायचा, store करायचा).

1. दोघांनी एकच servers चा pool वापरला तर uploads च्या burst ने CPU संपतो आणि सगळ्यांचे reels slow होतात.
2. म्हणून दोन target groups: tg-reels लहान servers सोबत (समजा 4 GB RAM) आणि tg-upload मोठ्या servers सोबत (समजा 32 GB RAM). प्रत्येक स्वतंत्र scale होतो.

कोणता group ते कोण ठरवतो? Listener.

1. Listener म्हणजे load balancer ज्या protocol आणि port वर ऐकतो तो: HTTP:80 किंवा HTTPS:443.
2. त्याचे rules priority क्रमाने check होतात:
3. Path /reels* → tg-reels.
4. Path /upload* → tg-upload.
5. Default (बाकी सगळं) → tg-web.

आणखी rule types (host, header) आणि अनेक groups: Multiple target groups आणि Different HTTP listeners.

10. Round robin, login चा problem, आणि sticky sessions

Target group च्या आत, Application Load Balancer default ने round robin वापरतो:

1. Request 1 → server 1.
2. Request 2 → server 2.
3. Request 3 → server 3.
4. Request 4 → परत server 1.

Problem: समजा app login session ज्या server ने login handle केलं त्याच्या memory मध्ये ठेवतो.

1. User login करतो; request 1 server 1 कडे गेली, आता त्याला user लक्षात आहे.
2. पुढचा click server 2 कडे जातो, ज्याने user ला कधी पाहिलंच नाही.
3. Server 2 परत login screen दाखवतो.

Fix 1: sticky sessions (target group ची setting, extra पैसे नाहीत):

1. पहिल्या response वर load balancer browser मध्ये एक cookie (AWSALB) ठेवतो, ज्यात कोणत्या target ने serve केलं ते असतं.
2. Browser पुढच्या प्रत्येक request सोबत ती cookie पाठवतो.
3. Load balancer ती वाचून user ला त्याच server कडे पाठवतो, तुम्ही ठरवलेल्या duration पर्यंत (उदा. 1 दिवस).
4. Load balancer login बद्दल काहीच store करत नाही; cookie browser मध्ये राहते.

Fix 2, लांबच्या दृष्टीने चांगला: shared session store. Sessions Redis किंवा database मध्ये ठेवा, म्हणजे कुठलाही server कुठल्याही user ला serve करू शकतो. मग कोणाला logout न करता server काढता किंवा बदलता येतो.

Target निवडायच्या इतर पद्धती (least outstanding requests, weighted): Routing policy. कुठला load balancer type निवडायचा ते पुढच्या chapter मध्ये, आणि Which load balancer to use मध्ये.

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

Part A: SNS topic

1. SNS > Topics > Create topic, type Standard, नाव cpu-high-alerts, Create topic.
2. Create subscription, protocol Email, endpoint: तुमचा email address.
3. AWS चा mail उघडा आणि Confirm subscription click करा. Status Confirmed होतो.

Part A2: एका golden AMI मधून तीन web servers

का: load balancer मागचा प्रत्येक server सारखीच site दाखवायला हवा. एक server बनवा, तो image (golden AMI) म्हणून save करा, आणि बाकीचे त्यातून launch करा.

1. Public subnet मध्ये Amazon Linux 2023 t2.micro launch करा, 22 आणि 80 open असलेल्या security group सोबत.
2. Nginx install आणि start करा:

sudo yum install nginx -y sudo service nginx start sudo systemctl enable nginx

1. शेवटच्या line मुळे प्रत्येक reboot नंतर Nginx परत सुरू होतो, म्हणून image मधून launch केलेले servers लगेच pages देतात.
2. /usr/share/nginx/html/index.html मध्ये <h1>FIRST</h1> ठेवा.
3. Actions > Image and templates > Create image, name firstami. AMI Available होईपर्यंत थांबा.
4. AMIs > firstami > Launch instance from AMI: त्याच security group सोबत अजून 2 launch करा.
5. त्यांच्यावर page <h1>SECOND</h1> आणि <h1>THIRD</h1> करा, म्हणजे कोणत्या server ने उत्तर दिलं ते दिसेल.
6. काही AZs मध्ये प्रत्येक instance type मिळत नाही (उदा. us-east-1e). Capacity किंवा type मुळे launch fail झालं तर us-east-1a किंवा us-east-1b निवडा.

Part B: target group

1. EC2 > Target groups > Create target group, type Instances, नाव tg-web, protocol HTTP, port 80, तुमचा VPC.
2. Health checks: path /index.html. Advanced health check settings मध्ये interval आणि unhealthy threshold ठेवा (section 8).
3. Register targets: web servers tick करा, Include as pending below, Create target group.

Worked example: lab साठी जलद health-check settings

1. Path /index.html, success code 200.
2. Healthy threshold 2, unhealthy threshold 2.
3. Timeout 3 seconds, interval 5 seconds.
4. बंद पडलेला server 2 × 5 = साधारण 10 seconds मध्ये बाहेर; दुरुस्त झालेला अजून 2 × 5 = साधारण 10 seconds मध्ये परत.
5. Register targets मध्ये Include as pending below click केल्यावरच server add होतो.

Part C: load balancer आणि listener rules

1. EC2 > Load balancers > Create load balancer > Application Load Balancer, scheme Internet-facing.
2. तुमचा VPC आणि वेगवेगळ्या AZs मधले किमान दोन public subnets निवडा.
3. Security group alb-sg: 80 (आणि 443) सगळीकडून allow. Web servers चा SG फक्त alb-sg कडून 80 allow करतो.
4. Listener HTTP:80, default action: tg-web कडे forward. Create load balancer.
5. Listener उघडा, Manage rules > Add rule: condition Path /reels*, action tg-reels कडे forward. /upload* → tg-upload साठी परत तसंच.
6. Load balancer चं DNS name copy करून browser मध्ये उघडा. Route 53 मध्ये तुमच्या domain साठी त्याच्याकडे point करणारा Alias A record बनवा.

Part D: sticky sessions (app sessions server memory मध्ये ठेवत असेल तरच)

1. tg-web उघडा > Attributes > Edit.
2. Stickiness tick करा, type Load balancer generated cookie, duration 1 day. Save changes.

Part E: CloudWatch alarm

1. CloudWatch > Alarms > Create alarm > Select metric > EC2 > Per-Instance Metrics, web server चा CPUUtilization निवडा.
2. Statistic Average, period 5 minutes.
3. Condition Greater/Equal than 70.
4. Notification: In alarm → cpu-high-alerts ला पाठवा.
5. नाव cpu-high-web, Create alarm.

Part F: test करा

1. एका web server वर Nginx बंद करा: sudo service nginx stop. Interval × threshold नंतर target unhealthy दिसतो, आणि site दुसऱ्या server वरून चालूच राहते.
2. परत चालू करा: sudo service nginx start. Healthy threshold नंतर तो परत healthy.
3. CPU वर load द्यायला stress tool install करा: sudo yum install stress-ng -y, मग stress-ng --cpu 2 --timeout 600 चालवा. साधारण 5 minutes मध्ये alarm In alarm होतो आणि email येतो.

Part G: round robin बघा

1. तीन servers (FIRST, SECOND, THIRD) target group मध्ये register करा आणि load balancer चं DNS name उघडा.
2. काही वेळा refresh करा: page बदलतं, उदा. FIRST, THIRD, SECOND. ALB by default healthy targets मध्ये round robin ने requests वाटतो.
3. Servers चे स्वतःचे public IPs try करा: ते अजून उत्तर देतात. Servers चा port 80 rule source = load balancer चा security group करा, म्हणजे users load balancer ला टाळून जाऊ शकत नाहीत.

Part H: detailed monitoring आणि 1-minute alarm

1. EC2 > Instances, server select करा, Actions > Monitor and troubleshoot > Manage detailed monitoring, Enable tick करा, Confirm.
2. CloudWatch > Alarms > Create alarm > Select metric > EC2 > Per-Instance Metrics > त्या server चा CPUUtilization.
3. Statistic Average, period 1 minute, threshold type Static, Greater/Equal 50.
4. In alarm → तुमच्या SNS topic ला पाठवा. नाव ec2alarm, Create alarm. तो Insufficient data मध्ये सुरू होतो, मग OK दाखवतो.
5. CPU load करा:

sudo yum install stress-ng -y stress-ng --cpu 6 --timeout 120

1. काही minutes मध्ये alarm In alarm मध्ये जातो आणि email येतो. Test संपल्यावर तो परत OK होतो.

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

1. Alert email येत नाही: subscription अजून Pending confirmation आहे. AWS mail मधली link click करा (spam पण बघा).
2. सगळे targets unhealthy: web SG alb-sg कडून 80 allow करत नाही, Nginx बंद आहे, किंवा health-check path 404 देतो.
3. Alarm कधीच वाजत नाही: चुकीचा metric (दुसरा instance), किंवा threshold पूर्ण period भर राहत नाही.
4. Users सारखे logout होतात: sessions server memory मध्ये आहेत आणि stickiness बंद आहे. ती चालू करा, किंवा sessions shared store मध्ये हलवा.
5. /upload चुकीच्या servers कडे जातं: rules चा क्रम चुकलाय, किंवा path pattern मध्ये * नाही.
6. Server ला SSH timeout होतो: एक एक check करा: server public subnet मध्ये आहे; internet gateway attach आहे; subnet च्या route table मध्ये IGW कडे 0.0.0.0/0 आहे; security group तुमच्या IP कडून port 22 allow करतो.
7. Office मध्ये SSH चाललं पण घरी नाही: My IP rule तो बनवताना तुमचा जो public IP होता तो ठेवतो. घरी तुमचा internet provider वेगळा public IP देतो. Rule edit करून परत My IP निवडा.

1. एका server ला कधीच traffic मिळत नाही: त्याची Availability Zone load balancer वर enable नाही. जिथे targets आहेत त्या सगळ्या AZs select करा.
2. Lab नंतरही bill मध्ये थोडा charge राहतो: नको असलेला AMI अजून त्याचे EBS snapshots ठेवतो. AMI deregister करा आणि त्याचे snapshots delete करा.

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

1. Scale up = मोठा instance, stop करावा लागतो. Scale out = जास्त servers, downtime नाही.
2. दोन A records load असमान वाटतात आणि बंद server कडे users पाठवत राहतात. Load balancer दोन्ही सोडवतो.
3. Threshold + period वर alarm: 5 minutes ची average CPU ≥ 70%. Spiky apps मध्ये alarm लवकर.
4. SNS: topic, publisher (alarm), subscribers (email, SMS, Lambda...). Email ला Confirm subscription लागतं.
5. नवीन servers तयार AMI मधून. Auto Scaling हे automatic करतो.
6. पहिल्या दिवसापासून load balancer. त्याचं DNS name Alias A record (Route 53) मध्ये किंवा www साठी CNAME मध्ये.
7. Target group = एका कामाचे servers + health check. Group च्या average CPU वर scale; रात्री scale in.
8. Health check: interval 5-300 s, unhealthy threshold किमान 2. 30 s × 2 = 1 minute पर्यंत; 5 s × 2 ≈ 10 s.
9. Listener rules path प्रमाणे route करतात: /reels आणि /upload त्यांच्या groups कडे, बाकी default कडे.
10. Round robin मध्ये server memory मधलं login हरवू शकतं. Sticky sessions (AWSALB cookie, extra पैसे नाहीत) किंवा, अजून चांगलं, shared session store.

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

Recap

झटपट उजळणी cards

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

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