AWS मध्ये Step by Step 3-Tier Architecture कसं बनवायचं (VPC, ALB, Auto Scaling, RDS)

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

1. या design ची चार goals

का: एकच server म्हणजे failure चा एकच point. तो crash झाला, किंवा त्याच्या data centre मध्ये problem आला, तर पूर्ण app बंद. ही चार goals प्रत्येकी एका "जर असं झालं तर?" ला उत्तर देतात:

1. Highly available (HA): "पूर्ण data centre बंद पडलं तर?" आपण दोन Availability Zones (AZs) वापरतो. AZ म्हणजे Region मधलं एक किंवा जास्त वेगळं data centre, स्वतःची power आणि network असलेलं. प्रत्येक tier चे servers दोन्ही AZs मध्ये असतात. Worked example: app चा traffic सांभाळायला 2 web servers लागतात. AZ a मध्ये 2 आणि AZ b मध्ये 2, म्हणजे एकूण 4. AZ a बंद पडला तरी AZ b मध्ये लागणारे 2 आहेतच. या lab मध्ये bill कमी ठेवायला आपण प्रत्येक AZ मध्ये 1 ने सुरुवात करतो (desired 2); हरवलेला server Auto Scaling group healthy AZ मध्ये परत बनवतो.
2. Fault tolerant: "एक server बिघडला तर?" Health check fail होणाऱ्या server ला load balancer traffic पाठवणं बंद करतो, आणि Auto Scaling group तो terminate करून AMI वरून नवीन copy launch करतो. रात्री कुणाला उठायची गरज नाही.
3. Low latency: "users लांब असतील तर?" Request ला लागणारा वेळ अंतराबरोबर वाढतो. भारतातल्या users ना दुसऱ्या continent मधल्या Region पेक्षा Mumbai Region मधून लवकर उत्तर मिळतं, म्हणून users जवळचा Region निवडायचा (आणि बऱ्याच देशांमधले users असतील तर एकापेक्षा जास्त Regions मध्ये deploy करायचं).
4. Disaster recovery (DR): "data गेला किंवा पूर्ण Region वापरता येत नसेल तर?" RDS automated backups घेतो आणि तुम्ही snapshots घेऊ शकता; मोठ्या systems साठी backups दुसऱ्या Region मध्ये copy करतात किंवा stack ची copy तिथे चालवतात. हा chapter HA आणि fault-tolerant भाग बनवतो; DR हा त्याच्यावरचा पुढचा layer.

2. Design, वरून खाली

काय: एक request पाच layers मधून खाली जाते आणि उत्तर त्याच रस्त्याने वर येतं.

Web servers पण private का: users कधीच nginx server शी direct बोलत नाहीत. ते internet-facing ALB शी बोलतात, आणि internet gateway कडे route फक्त ALB ला लागतो. म्हणून public subnets मध्ये फक्त ALB, JumpServer आणि थोड्या वेळासाठीचे development servers असतात. तिन्ही tiers (web, app, database) private subnets मध्ये असतात, आणि attacker बाहेरून त्यांना एक packet सुद्धा पाठवू शकत नाही.

Web आणि app च्या मध्ये internal load balancer का: PHP servers Auto Scaling मुळे येतात-जातात, त्यामुळे त्यांचे IPs सतत बदलतात. nginx ला PHP requests पाठवायला एक fixed नाव लागतं. Internal ALB ते नाव देतो आणि requests दोन्ही AZs मधल्या healthy PHP servers वर वाटतो.

3. Build खालून वर, rules वरून खाली

खालून वर का: प्रत्येक tier पूर्ण करायला त्याच्या खालच्या tier चा address आधी लागतो.

1. आधी RDS. तो database endpoint देतो.
2. मग PHP servers. PHP AMI बनवण्याआधी submit.php मध्ये RDS endpoint लिहिलेला लागतो.
3. मग internal ALB. तो App Auto Scaling group सोबतच बनतो आणि त्याचं DNS name देतो.
4. मग nginx. Web AMI बनवण्याआधी त्याच्या proxy_pass line ला internal ALB चं DNS name लागतं.
5. शेवटी internet-facing ALB, web Auto Scaling group च्या समोर.

वरून खाली गेलात तर web servers ना point करायला काहीच नसताना launch कराल, आणि नंतर प्रत्येकावर login करून config दुरुस्त करावा लागेल. 2 servers असतील तर त्रास; Auto Scaling group ने launch केलेले 100 servers असतील तर अशक्य, आणि एका AMI वरून एकसारखे servers या कल्पनेच्याच विरुद्ध.

Security rules वरून खाली का वाचायचे: प्रत्येक tier फक्त त्याच्या लगेच वरच्या tier वर विश्वास ठेवतो. Tier चा rule असा लिहितो: "port X फक्त वरच्या tier च्या security group कडून घ्या". म्हणून ते internet पासून खाली वाचायचे आणि check करायचे: WebAlbSG, WebEc2SG, AppAlbSG, AppEc2SG, DbSG.

सगळे security groups आधी का बनवायचे: Rule फक्त आधीच असलेल्या security group कडे point करू शकतो. पाचही groups रिकामे बनवा, मग rules add करा. Servers मात्र खालून वरच बनतात.

4. Immutable servers: live server वर कुणी login का करत नाही

हा विषय का आला. Public subnets काढताना प्रश्न आला: खरे servers सगळे private आहेत, तर jump server आणि NAT gateway तिथे ठेवायचे तरी का?

पार्श्वभूमी. जुन्या पद्धतीत admin प्रत्येक live server वर login करून हाताने updates चालवतो. काही काळाने प्रत्येक server थोडा वेगळा होतो ("configuration drift"), आणि त्यावर नक्की काय आहे ते कुणालाच माहीत नसतं. Immutable पद्धतीत चालू server कधीच बदलत नाही. Development server बदलायचा, test करायचा, नवी AMI बनवायची, ती launch template च्या नव्या version मध्ये टाकायची, आणि instance refresh ने Auto Scaling group जुने servers बदलतो. काही बिघडलं तर मागच्या version वर rollback.

3-tier build शी संबंध. खालचा build नेमका हाच आहे: phpdevelopmentserver आणि nginxdevelopmentserver public subnet मध्ये हाताने बनतात, त्यांच्या phpami आणि webami होतात, आणि मग ते delete होतात. JumpServer फक्त database setup साठी आणि debug करताना logs वाचण्यासाठी. NAT gateway फक्त तेव्हाच लागतो जेव्हा private servers ना स्वतः internet वर जायचं असतं, उदा. packages install करायला किंवा बाहेरचा API call करायला. आपल्या private servers ना सगळं AMI मधून मिळतं आणि ते फक्त ALB आणि RDS शी बोलतात, म्हणून या build ला NAT gateway लागत नाही. लागलाच तर तो concept chapter मध्ये आहे.

5. Address plan: आठ /20 subnets

आठच का: subnet चे 4 प्रकार (public, web, app, DB) × 2 AZs = 8. प्रत्येक tier ला प्रत्येक AZ मध्ये एक subnet मिळतो, म्हणजे एक AZ गेला तरी पूर्ण tier कधीच जात नाही. AZs आलटून-पालटून का (1 AZ a मध्ये, 2 AZ b मध्ये): एका tier चे दोन्ही subnets एकाच AZ मध्ये असतील तर तो tier highly available राहतच नाही.

Worked example: /20 चं गणित

1. VPC 10.0.0.0/16 आहे: 32 − 16 = 16 host bits, म्हणजे 2^16 = 65,536 addresses, 10.0.0.0 ते 10.0.255.255.
2. /20 मध्ये 32 − 20 = 12 host bits: 2^12 = 4,096 addresses.
3. 4,096 = 16 × 256, म्हणजे प्रत्येक /20 तिसऱ्या octet च्या 16 values घेतो. पुढचा /20 16 ने पुढे सुरू होतो: 10.0.0.0, 10.0.16.0, 10.0.32.0, वगैरे.
4. AWS प्रत्येक subnet मध्ये 5 addresses ठेवून घेतो (network address, VPC router, DNS, पुढच्या वापरासाठी एक, आणि शेवटचा address), म्हणून 4,096 − 5 = 4,091 usable.
5. एका /16 मध्ये 65,536 ÷ 4,096 = 16 subnets /20 चे बसतात. आपण 8 वापरतो, ते 10.0.127.255 ला संपतात. 10.0.128.0 ते 10.0.255.255 पुढच्यासाठी मोकळं राहतं.

Examples Seoul Region (ap-northeast-2) वापरतात. कुठलाही Region चालतो, उदा. Mumbai (ap-south-1, AZs ap-south-1a आणि ap-south-1b). फक्त सगळं एकाच Region मध्ये ठेवा. CIDR ची binary पद्धत AWS VPC म्हणजे काय आणि CIDR IP Ranges कसे काढायचे मध्ये आहे.

6. Security group plan

काय: पाच groups साखळी बनवतात, आणि दोन छोटे helper groups फक्त setup साठी.

Setup च्या वेळी DbSG JumpSG कडून पण 3306 allow करतो, म्हणजे JumpServer database बनवू शकतो. App चालायला लागल्यावर तो rule काढायचा.

Source म्हणून IP नाही, security group का: Auto Scaling servers प्रत्येक replacement ला नवीन private IP घेतात. "WebEc2SG कडून" rule म्हणजे "WebEc2SG लावलेल्या कुठल्याही server कडून", म्हणून कितीही servers आले-गेले तरी तो चालत राहतो. IP चा rule पहिल्याच replacement नंतर तुटेल.

प्रत्येक role ला वेगळा group, कधीच share नाही, का: ALB आणि nginx servers ने 80 सगळ्यांना allow करणारा एकच group share केला, तर server चा address कळलेला user load balancer टाळू शकतो. वेगळे groups आणि साखळीतले sources प्रत्येक hop स्पष्ट करतात.

Debugging चा वेळ वाचवणाऱ्या दोन गोष्टी:

1. Security groups stateful असतात: request आत allow झाली की तिचं reply बाहेर आपोआप allow होतं. इथे फक्त inbound rules लिहायचे; default outbound rule (all traffic) तसाच राहतो.
2. Rule destination च्या group वर check होतो. "nginx PHP पर्यंत पोहोचत नाही" हे AppAlbSG/AppEc2SG वर दुरुस्त होतं, WebEc2SG वर नाही.

Security groups आणि NACLs बद्दल जास्त: AWS मध्ये Security Group vs NACL.

7. Auto Scaling चे numbers, गणितासकट

का: दोन्ही tiers Auto Scaling groups मध्ये चालतात, म्हणजे servers ची संख्या load प्रमाणे बदलते आणि बिघडलेले servers बदलले जातात. Lab मध्ये वापरलेल्या values आणि प्रत्येक काय करते:

Desired 2, min 1, max 4

1. Desired 2: सुरुवातीला group 2 servers चालवतो. 2 AZs मध्ये 2 subnets, म्हणजे प्रत्येक AZ मध्ये एक.
2. Min 1: traffic नसेल तर policy 1 पर्यंत कमी करू शकते, पण 0 कधीच नाही, म्हणजे app कधी गायब होत नाही.
3. Max 4: policy 4 च्या वर कधीच जाऊ शकत नाही. ही तुमच्या bill ची मर्यादा: traffic spike किंवा bug मुळे 50 servers सुरू होऊ शकत नाहीत.
4. Example: तुम्ही हाताने desired 6 केलं. Console नकार देतो, कारण desired min आणि max च्या मध्येच पाहिजे.

Average CPU वर target tracking, target 20%

Target tracking group चा average CPU target जवळ ठेवायला desired capacity बदलतो, साधारण प्रमाणात:

1. 2 servers, average CPU 50%: 2 × 50 ÷ 20 = 5 servers लागतील, पण max 4 आहे, म्हणून group 4 पर्यंत वाढतो.
2. 4 servers, 10%: 4 × 10 ÷ 20 = 2, म्हणून group परत 2 वर येतो.
3. 2 servers, 4%: 2 × 4 ÷ 20 = 0.4, वर round करून 1, आणि min 1 आहे, म्हणून तो 1 वर येतो. म्हणूनच अजिबात traffic नसताना group स्वतःहून एक server काढताना दिसू शकतो.
4. Scale-out काही मिनिटांत होतो; scale-in जास्त थांबतो (साधारण 15 मिनिटं CPU कमी राहिला तर), म्हणजे छोट्या dip मुळे servers जात नाहीत.
5. 20 का: lab मध्ये खरे users नसताना scaling होताना बघता यावं म्हणून मुद्दाम कमी ठेवलाय. Production साठी 50 ते 70 सारखी realistic value घ्या.

Instance warmup 60 s: नवीन server सुरू झाल्यावर 60 s त्याचा CPU group average मध्ये मोजत नाहीत. नवा server boot होण्यात busy असतो; तो मोजला तर policy अजून servers वाढवेल.

Health check grace period 60 s: server launch झाल्यावर 60 s group failed health checks कडे दुर्लक्ष करतो, म्हणजे nginx सुरू करत असलेल्या server ला तो मारत नाही. आपल्या AMIs एका मिनिटाच्या आत boot होऊन nginx सुरू करतात; तुमच्या app ला सुरू व्हायला जास्त वेळ लागत असेल तर ही value वाढवा.

ELB health checks on: default ला group फक्त EC2 instance running आहे का ते बघतो. ELB health checks on केले की ज्या server चं web page load balancer चा health check fail करतं, तो पण unhealthy धरून बदलला जातो. यामुळेच tier fault tolerant होतो.

Availability Zone distribution: Balanced best effort

साधारणपणे group प्रत्येक AZ मध्ये सारखेच servers ठेवतो. कधी कधी एखाद्या AZ मध्ये एखादा instance type तात्पुरता संपतो. Diwali, Dussehra, Eid, Christmas किंवा 31 December सारख्या peak दिवशी असं होतं, जेव्हा बऱ्याच companies एकाच वेळी scale out करतात.

1. Balanced only: capacity नसलेल्या AZ मध्येच group launch करत राहतो. Launch fail होत राहतो आणि नेमक्या सगळ्यात busy दिवशी app ला servers कमी पडतात.
2. Balanced best effort: एका AZ मध्ये launch fail झाला तर group दुसऱ्या healthy AZ मध्ये launch करतो. काही वेळ split असमान राहतो (उदा. 3 + 1), पण app ला लागणारी capacity मिळते, आणि group नंतर rebalance करतो.
3. म्हणून Balanced best effort च ठेवा.

Instance maintenance policy: No policy. Instance refresh सारख्या replacements च्या वेळी काय करायचं ते हे ठरवतं: जुना server terminate करण्याआधी नवा launch करायचा (capacity टिकते, क्षणभर थोडा जास्त खर्च) की आधी terminate करायचा (पैसे वाचतात, थोडा वेळ servers कमी). "No policy" default behaviour ठेवतो, lab साठी ठीक; production साठी "Launch before terminating" पूर्ण capacity ठेवतो.

CloudWatch मध्ये group metrics: हे tick केलं की desired, in-service आणि pending instances सारखे group metrics दर मिनिटाला CloudWatch ला जातात, म्हणजे group ने काय केलं त्याचा graph बघता येतो.

Launch templates आणि min, max, desired बद्दल जास्त: AWS मध्ये Auto Scaling म्हणजे काय? Min, Max आणि Desired सोप्या भाषेत.

8. Passwords: code मध्ये लिहिलेला vs Secrets Manager

Code मधला password problem का

हा विषय का आला. RDS database बनवताना master password कसा manage करायचा ते निवडायचं असतं, आणि PHP code ला connect करायला तो password लागतो.

पार्श्वभूमी. या lab मध्ये password submit.php मध्ये लिहिलाय आणि phpami मध्ये bake झालाय. शिकण्यासाठी ठीक, पण 1,000 PHP servers असलेल्या खऱ्या app चा विचार करा: प्रत्येक server वर password आहे; एक server hack झाला, किंवा password माहीत असलेला developer सोडून गेला, तर database उघडा पडतो; आणि password बदलायचा म्हणजे नवी AMI आणि instance refresh, साधारण एक तास, ज्यात काही servers कडे अजून जुना password असतो आणि त्यांचे database calls fail होतात.

3-tier build शी संबंध. AWS Secrets Manager password secret म्हणून ठेवतो (key-value pair, AWS KMS ने encrypted). PHP code फक्त secret चं नाव ठेवतो आणि runtime ला AWS SDK ने (GetSecretValue) value वाचतो, server वरच्या IAM role वापरून. Secrets Manager मध्ये एकदा password बदला, की प्रत्येक server ला पुढच्या read ला नवी value मिळते. Secrets Manager schedule वर password rotate पण करू शकतो (दर 4 तासांइतकं वारंवार), म्हणजे कुठल्याच माणसाला तो माहीत असण्याची गरज नाही. RDS बनवताना Managed in AWS Secrets Manager option master password साठी हेच करतो (default ला दर 7 दिवसांनी rotation). त्याला दोन गोष्टी लागतात: secretsmanager:GetSecretValue असलेला IAM role, आणि private servers पासून Secrets Manager पर्यंत network रस्ता (VPC interface endpoint किंवा NAT gateway).

GitHub वर push झालेले secrets

हा विषय का आला. Code मधल्या password नंतर लगेच: password किंवा AWS access key असलेला code public GitHub repository वर push झाला की हीच चूक होते.

पार्श्वभूमी. Bots public repositories सतत scan करतात आणि काही मिनिटांत keys शोधतात; चोरलेल्या AWS keys ने साधारणपणे crypto-mining साठी खूप मोठे servers सुरू केले जातात, आणि ते तुमच्या bill वर येतं. AWS सुद्धा public GitHub वर उघड्या access keys scan करतं; सापडली की त्या user ला quarantine policy (AWSCompromisedKeyQuarantine) लावून key काय करू शकते ते मर्यादित करतं, आणि तुम्हाला email करतं. Commit delete करणं पुरेसं नाही, कारण key history मध्ये आणि forks मध्ये राहते. उपाय: key लगेच deactivate आणि rotate करा, मग account मध्ये तुम्ही न बनवलेलं काही आहे का ते तपासा.

3-tier build शी संबंध. खरा password असलेला submit.php public repository मध्ये कधीच commit करू नका. Secrets code च्या बाहेर ठेवा (Secrets Manager, किंवा निदान .gitignore मध्ये असलेली config file), आणि GitHub secret scanning आणि push protection on करा. Servers वर access keys ऐवजी IAM role वापरा, म्हणजे leak व्हायला key च नसते.

9. Hands-on lab: पूर्ण build, step by step

हा क्रम का: Parts A ते D आधी network आणि सगळे security rules बनवतात, कारण पुढचा प्रत्येक resource त्याच्या form मध्ये VPC, subnet किंवा security group विचारतो. Parts E ते G database आणि मग त्याच्यावर app tier बनवतात, म्हणजे प्रत्येक tier त्याच्या खालच्या चालणाऱ्या tier सोबत test होतो. Parts H ते J test केलेल्या servers ना load balancers मागच्या Auto Scaling groups मध्ये बदलतात. Part K test करून lock करतो, Part L servers सुरक्षितपणे कसे बदलायचे ते दाखवतो, आणि Part M सगळं काढून टाकतो.

सुरू करण्याआधी

• Sign in करता येईल असं AWS account, आणि साधारण तीन तास. Load balancers, RDS आणि servers चालू असताना थोडे पैसे लागतात; Part M त्याच दिवशी करा.
• सगळ्यासाठी एकच Region. Lab Asia Pacific (Seoul) ap-northeast-2 आणि AZs 2a, 2b वापरतो; Mumbai ap-south-1 1a आणि 1b सोबत तसंच चालतं.
• OpenSSH असलेला terminal (Windows 10/11 वर PowerShell, Mac किंवा Linux वर Terminal).
• <rds-endpoint> सारखे angle brackets मधले values तुमचे, console मधून copy करायचे.

Part A: Region आणि VPC

1. पूर्ण build साठी एक Region निवडा

   • करा: AWS console मध्ये sign in करा. वर उजवीकडे Region menu उघडा आणि Asia Pacific (Seoul) ap-northeast-2 (किंवा तुम्ही निवडलेला Region) निवडा.
   • Check करा: आता उघडाल त्या प्रत्येक page वर वर उजवीकडे Region चं नाव दिसतं.
   • का: इथला प्रत्येक resource (VPC, subnets, security groups, RDS, AMIs, load balancers) एका Region चा असतो आणि त्याच Region मधल्या resources सोबतच वापरता येतो. Regions मिसळणं हे "list मध्ये दिसत नाही" चं सगळ्यात common कारण.

2. Create VPC page उघडा

   • करा: VPC search करा > Your VPCs > Create VPC.
   • का: VPC म्हणजे AWS मधलं तुमचं स्वतःचं private network; या build मधलं बाकी सगळं त्याच्या आत राहतं.

3. Resources to create: VPC only

   • करा: VPC only निवडा.
   • का: "VPC and more" स्वतःच्या नावांनी आणि sizes ने subnets, route tables आणि gateways पण बनवेल. प्रत्येक भाग स्वतः बनवला तरच तो काय करतो ते कळतं, आणि आपल्या plan चे नेमके आठ subnets मिळतात.

4. Name tag: ThreeTierVpc

   • करा: Name tag मध्ये ThreeTierVpc type करा.
   • का: प्रत्येक account मध्ये प्रत्येक Region ला आधीच default VPC असतो. स्पष्ट नाव असलं की पुढच्या 20 dropdowns मध्ये चुकून default VPC निवडला जात नाही.

5. IPv4 CIDR: IPv4 CIDR manual input, 10.0.0.0/16

   • करा: IPv4 CIDR manual input निवडा आणि 10.0.0.0/16 type करा.
   • का: /16 मुळे 65,536 private addresses मिळतात, सोळा /20 subnets साठी जागा. 10.0.0.0/8 private range आहे (RFC 1918): तो internet वर कधीच route होत नाही, म्हणून public addresses शी clash होत नाही.

6. IPv6 CIDR block: No IPv6 CIDR block

   • करा: No IPv6 CIDR block तसंच ठेवा.
   • का: App फक्त IPv4 वर चालतं. प्रत्येक जास्तीची address family म्हणजे secure करायचे अजून routes आणि rules.

7. Tenancy: Default

   • करा: Default ठेवा आणि Create VPC click करा.
   • काय दिसेल: हिरवा banner "You successfully created vpc-… / ThreeTierVpc".
   • का: Default मध्ये तुमचे servers shared hardware वर चालतात, तरीही इतर customers पासून पूर्ण वेगळे. Dedicated tenancy प्रत्येक instance एकाच customer च्या hardware वर ठेवते आणि खूप जास्त खर्च होतो.

8. Resource map बघा

   • करा: VPC page वर Resource map tab उघडा.
   • काय दिसेल: Subnets (0), Route tables (1).
   • का: VPC सोबत AWS ने main route table बनवलं (आणि default network ACL आणि default security group). त्या route table मध्ये फक्त local route आहे, म्हणून जे ते वापरतं ते private. हे माहीत असलं की नवीन subnets private का सुरू होतात ते कळतं.

9. Main route table ला ThreeTierMainRouteTable नाव द्या

   • करा: Route tables: VPC ThreeTierVpc आणि Main: Yes असलेली row शोधा, Name मधल्या pencil वर click करा, ThreeTierMainRouteTable type करा, Save.
   • का: थोड्याच वेळात या VPC मध्ये दोन route tables असतील, आणि account मध्ये इतर VPCs चे अजून. नाव नसलेले route tables सगळे rtb-0abc… सारखेच दिसतात, आणि चुकीचा निवडला तर subnet चुकून public किंवा private होतो.

Part B: आठ subnets

10. Create subnet उघडा आणि VPC ID: ThreeTierVpc निवडा

    • करा: VPC > Subnets > Create subnet, VPC ID = ThreeTierVpc.
    • का: हा dropdown आठही subnets कुठे जाणार ते ठरवतो. Default VPC वरच ठेवला तर आठही तिथे बनतात आणि पुढे काहीच त्यांना शोधू शकत नाही.
    • जर दिसलं subnets default VPC खाली: VPC dropdown बदलला नव्हता. ते subnets delete करा (Actions > Delete subnet) आणि ThreeTierVpc मध्ये परत बनवा.

11. Subnet 1: PublicSubnet1, ap-northeast-2a, 10.0.0.0/20

    • करा: Subnet name PublicSubnet1, Availability Zone ap-northeast-2a, IPv4 VPC CIDR block 10.0.0.0/16, IPv4 subnet CIDR block 10.0.0.0/20.
    • का: VPC चा पहिला /20 block, AZ a मध्ये. यात internet-facing ALB, JumpServer आणि development servers असतील.

12. Add new subnet: PublicSubnet2, ap-northeast-2b, 10.0.16.0/20

    • करा: Add new subnet click करा आणि या values भरा.
    • का: Internet-facing ALB ला किमान दोन AZs मध्ये subnet लागतो, आणि AZ b मधला दुसरा public subnet तो देतो. Block 16 ला सुरू होतो कारण /20 तिसऱ्या octet च्या 16 values घेतो.

13. WebSubnet1, ap-northeast-2a, 10.0.32.0/20

    • करा: या values सोबत Add new subnet.
    • का: AZ a मधल्या nginx servers चं private घर.

14. WebSubnet2, ap-northeast-2b, 10.0.48.0/20

    • करा: या values सोबत Add new subnet.
    • का: AZ b मधला web tier, म्हणजे AZ a गेला तरी web tier टिकतो.

15. AppSubnet1, ap-northeast-2a, 10.0.64.0/20

    • करा: या values सोबत Add new subnet.
    • का: AZ a मधल्या PHP servers आणि internal ALB चं private घर.

16. AppSubnet2, ap-northeast-2b, 10.0.80.0/20

    • करा: या values सोबत Add new subnet.
    • का: AZ b मधला app tier.

17. DBSubnet1, ap-northeast-2a, 10.0.96.0/20

    • करा: या values सोबत Add new subnet.
    • का: AZ a मधला database चा subnet.

18. DBSubnet2, ap-northeast-2b, 10.0.112.0/20, मग Create subnet

    • करा: शेवटचा subnet add करा आणि Create subnet click करा.
    • काय दिसेल: "You have successfully created 8 subnets".
    • का: RDS ला single instance साठी सुद्धा किमान दोन AZs मध्ये subnets लागतात, म्हणजे तो standby ठेवू शकतो किंवा नंतर database तिकडे हलवू शकतो.
    • जर दिसलं "Failed to request credentials" किंवा "NetworkError when attempting to fetch resource": लांब form उघडा असताना console session expire झाला किंवा एक request fail झाली. Page refresh करा, सांगितलं तर परत sign in करा, Subnets list मध्ये अर्धवट बनलेले subnets आहेत का बघा, आणि form परत भरा. Section 10 बघा.

19. आठ subnets check करा

    • करा: Subnets, VPC = ThreeTierVpc filter करा.
    • Check करा: 8 subnets, 4 ap-northeast-2a मध्ये आणि 4 ap-northeast-2b मध्ये, CIDRs section 5 च्या table प्रमाणे, Available IPv4 addresses प्रत्येकी 4091.
    • का: आत्ताचा एक चुकीचा CIDR किंवा AZ खूप नंतर ALB, subnet group किंवा Auto Scaling groups बिघडवतो, जिथे तो दिसणं जास्त अवघड असतं.

20. Resource map: आठही main route table वापरतात

    • करा: Your VPCs > ThreeTierVpc > Resource map.
    • काय दिसेल: आठही subnets ThreeTierMainRouteTable ला जोडलेले.
    • का: नवीन subnet आपोआप main route table शी associate होतो. आत्ता त्या table मध्ये फक्त local route आहे, म्हणून आठही subnets private आहेत. हा safe default आहे: तुम्ही public केल्याशिवाय काहीच public नाही.

Part C: Internet gateway आणि route tables

21. Internet gateway ThreeTierIGW बनवा

    • करा: VPC > Internet gateways > Create internet gateway, Name tag ThreeTierIGW, Create internet gateway.
    • काय दिसेल: State: Detached.
    • का: Internet gateway म्हणजे VPC चा internet कडे जाणारा दरवाजा. त्याशिवाय internet-facing ALB ला एकही request मिळू शकत नाही.

22. Attach करा: Actions > Attach to VPC > ThreeTierVpc

    • करा: Actions > Attach to VPC, ThreeTierVpc निवडा, Attach internet gateway.
    • काय दिसेल: State: Attached.
    • का: नवीन internet gateway कुठल्याच VPC ला जोडलेला नसतो. Detached gateway route target म्हणून निवडता येत नाही.

23. ThreeTierPublicRouteTable बनवा

    • करा: Route tables > Create route table, Name ThreeTierPublicRouteTable, VPC ThreeTierVpc, Create route table.
    • का: Public subnets ना स्वतःचं route table लागतं. Main table private राहतं, म्हणजे नंतर add केलेला कुठलाही subnet तुम्ही ठरवेपर्यंत private राहतो. Route table नावामुळे public होत नाही; internet gateway कडे route असेल तेव्हाच तो public होतो.

24. Route 0.0.0.0/0 → ThreeTierIGW add करा

    • करा: Routes tab > Edit routes > local row तशीच ठेवा > Add route: Destination 0.0.0.0/0, Target Internet Gateway > ThreeTierIGW > Save changes.
    • काय दिसेल: दोन routes: 10.0.0.0/16 local आणि 0.0.0.0/0 igw-…, दोन्ही Active.
    • का: 10.0.0.0/16 → local VPC च्या आतलं सगळं traffic नेतो (ALB ते nginx, PHP ते RDS) आणि तो राहिलाच पाहिजे. 0.0.0.0/0 म्हणजे "बाकी प्रत्येक address", आणि तो internet gateway ला पाठवला की subnet public होतो.
    • जर दिसलं Internet Gateway खाली रिकामी list: gateway अजून detached आहे. Cancel करा, attach step करा, मग परत या.

25. फक्त दोन public subnets associate करा

    • करा: Subnet associations tab > Edit subnet associations > फक्त PublicSubnet1 आणि PublicSubnet2 tick करा > Save associations.
    • का: Subnet नेमका एकच route table वापरतो. PublicSubnet1 आणि PublicSubnet2 public table वर हलवले की ते दोन public होतात; बाकीचे सहा private main table वरच राहतात.

26. Resource map check करा

    • करा: Your VPCs > ThreeTierVpc > Resource map.
    • Check करा: ThreeTierPublicRouteTable → PublicSubnet1, PublicSubnet2 → ThreeTierIGW; ThreeTierMainRouteTable → 6 Web, App आणि DB subnets.
    • का: हे चित्र म्हणजे section 2 चा network plan. आत्ता ते वेगळं दिसत असेल, तर पुढची प्रत्येक step बिघडेल.

Part D: आधी सगळे security groups, मग rules

27. WebAlbSG बनवा (अजून rules नाहीत)

    • करा: EC2 > Security Groups > Create security group: Name WebAlbSG, Description Internet-facing ALB, VPC ThreeTierVpc, inbound rules नाहीत > Create security group.
    • का: Security group एका VPC चा असतो आणि त्याच VPC मधल्या resources ना लावता येतो. आधी सगळे groups बनवले की प्रत्येक rule आधीच असलेल्या group कडे point करू शकतो.

28. WebEc2SG बनवा

    • करा: तोच page: Name WebEc2SG, Description nginx web servers, VPC ThreeTierVpc, Create.
    • का: nginx servers ना ALB पासून वेगळा स्वतःचा group, म्हणजे ALB टाळता येत नाही.

29. AppAlbSG बनवा

    • करा: Name AppAlbSG, Description Internal ALB, VPC ThreeTierVpc, Create.
    • का: Internal ALB साखळीतला स्वतंत्र hop आहे, त्याला स्वतःचा group लागतो.

30. AppEc2SG बनवा

    • करा: Name AppEc2SG, Description PHP app servers, VPC ThreeTierVpc, Create.
    • का: PHP servers चा group. DbSG नेमका याच group वर विश्वास ठेवेल.

31. DbSG बनवा

    • करा: Name DbSG, Description RDS MySQL, VPC ThreeTierVpc, Create.
    • का: Database चा group, RDS बनवताना निवडायचा.

32. SSH 22 from My IP सोबत JumpSG बनवा

    • करा: Name JumpSG, Description Jump server, VPC ThreeTierVpc, Add rule: Type SSH, Source My IP > Create.
    • का: JumpServer ला SSH फक्त तुमच्या स्वतःच्या public IP वरून. 0.0.0.0/0 ला उघडा port 22 bots दिवसभर scan करतात आणि password आणि key attacks ना आमंत्रण देतो.

33. SSH 22 आणि HTTP 80 from My IP सोबत DevSG बनवा

    • करा: Name DevSG, Description Development servers, VPC ThreeTierVpc, rules: SSH from My IP, HTTP from My IP > Create.
    • का: दोन development servers ना setup साठी SSH आणि browser मध्ये pages test करायला HTTP लागतं, पण फक्त तुमच्याकडूनच.

34. WebAlbSG inbound: HTTP 80, source Anywhere-IPv4 0.0.0.0/0

    • करा: WebAlbSG select करा > Inbound rules > Edit inbound rules > Add rule: Type HTTP, Source Anywhere-IPv4 > Save rules.
    • का: Public ALB हीच एक गोष्ट आहे जिने internet वरच्या प्रत्येक user ला घेतलं पाहिजे.

35. WebEc2SG inbound: HTTP 80, source WebAlbSG

    • करा: WebEc2SG > Edit inbound rules > Add rule: Type HTTP, Source Custom, WebAlbSG type करायला सुरुवात करा आणि Security Groups मधून निवडा > Save rules.
    • का: nginx फक्त internet-facing ALB कडून traffic घेतो, health checks सकट. Server चा address कळला तरी user तिथे पोहोचू शकत नाही.

36. AppAlbSG inbound: HTTP 80, source WebEc2SG

    • करा: AppAlbSG > Edit inbound rules > HTTP, Source Custom WebEc2SG > Save rules.
    • का: Internal ALB ला PHP requests फक्त nginx servers पाठवू शकतात.

37. AppEc2SG inbound: HTTP 80, source AppAlbSG

    • करा: AppEc2SG > Edit inbound rules > HTTP, Source Custom AppAlbSG > Save rules.
    • का: PHP servers फक्त internal ALB ला घेतात. त्याचे health checks पण AppAlbSG कडूनच येतात, म्हणून ते पण pass होतात.

38. DbSG inbound: MySQL/Aurora 3306, source AppEc2SG, आणि setup साठी JumpSG

    • करा: DbSG > Edit inbound rules > Add rule: Type MYSQL/Aurora, Source Custom AppEc2SG; Add rule: MYSQL/Aurora, Source Custom JumpSG > Save rules.
    • का: Database ला फक्त PHP servers connect करू शकतात. JumpSG चा rule फक्त database आणि table बनवण्यासाठी आहे, आणि शेवटी तो काढायचा. Port 3306 कधीच 0.0.0.0/0 ला उघडत नाही.

39. साखळी एकदा वरून खाली वाचा

    • करा: Security Groups, VPC ID = ThreeTierVpc filter करा, प्रत्येक group चे Inbound rules उघडा.
    • Check करा: WebAlbSG ← 0.0.0.0/0:80, WebEc2SG ← WebAlbSG:80, AppAlbSG ← WebEc2SG:80, AppEc2SG ← AppAlbSG:80, DbSG ← AppEc2SG:3306 आणि JumpSG:3306, नेमकं Figure 3 प्रमाणे.
    • का: इथे दोन मिनिटं check केलं तर नंतर timeouts मागे धावण्याचा एक तास वाचतो.

Part E: DB subnet group आणि RDS MySQL

40. DB subnet group ThreeTierDBSubnetGroup बनवा

    • करा: RDS search करा (Aurora and RDS) > Subnet groups > Create DB subnet group: Name ThreeTierDBSubnetGroup, Description ThreeTierDBSubnetGroup, VPC ThreeTierVpc.
    • का: RDS थेट subnet घेत नाही; तो subnet group घेतो, म्हणजे database ठेवता येईल अशा subnets ची list. Group तुम्ही निवडलेल्या VPC मध्ये बनतो, आणि database त्याच VPC मध्ये बनू शकतो.

41. AZs ap-northeast-2a, ap-northeast-2b; फक्त DBSubnet1 आणि DBSubnet2 subnets, मग Create

    • करा: Availability Zones: दोन्ही tick करा. Subnets: DBSubnet1 (10.0.96.0/20) आणि DBSubnet2 (10.0.112.0/20) tick करा > Create.
    • काय दिसेल: List मध्ये threetierdbsubnetgroup (RDS नाव lower case मध्ये ठेवतो), Status Complete.
    • का: Tick केलेल्या AZs मधलेच subnets list मध्ये दिसतात. फक्त दोन DB subnets निवडले की database कधीच public किंवा app subnet मध्ये जाऊ शकत नाही.
    • जर दिसलं तुमचे DB subnets list मध्ये नाहीत: चुकीचा VPC निवडलाय, किंवा त्यांचा AZ tick नाही. List च्या वरची VPC किंवा AZ निवड दुरुस्त करा.

42. Databases > Create database: Standard create, engine MySQL

    • करा: Standard create निवडा, Engine type MySQL, default engine version ठेवा.
    • का: Standard create प्रत्येक network setting दाखवतो. Quick option त्या defaults ने भरतो, आणि default VPC तर नेमका टाळायचाय.

43. Templates: Free tier

    • करा: Free tier निवडा.
    • का: Lab ला पैसे लागू नयेत म्हणून ते choices छोट्या free-tier instance पुरते ठेवतं.

44. Availability: Single-AZ DB instance

    • करा: Single-AZ DB instance deployment (1 instance) ठेवा.
    • का: Multi-AZ दुसऱ्या AZ मध्ये synchronous replication सोबत standby copy ठेवतो आणि आपोआप failover करतो, साधारण एक ते दोन मिनिटांत. खऱ्या highly available app ला हेच लागतं, पण त्याने database चा खर्च साधारण दुप्पट होतो, म्हणून lab एकच instance वापरतो. Company मध्ये production databases Multi-AZ वरच चालतात.

45. Identifier database-1, master username root

    • करा: DB instance identifier database-1, Master username root.
    • का: Identifier console मध्ये database चं नाव असतो आणि endpoint name त्यानेच सुरू होतं. Master username mysql -u मध्ये आणि submit.php मध्ये type करता तो; console admin सुचवतो, आणि सगळीकडे तेच वापरलं तर कुठलंही allowed नाव चालतं.

46. Credentials management: Self managed, password दोनदा type करा

    • करा: Self managed निवडा, Master password आणि Confirm master password भरा. लिहून ठेवा; अजून तीनदा लागेल.
    • का: Self managed मुळे lab सोपा राहतो: तुम्ही password type करता आणि submit.php मध्ये टाकता. RDS master passwords 8 ते 41 characters चे असतात आणि त्यात /, ', ", @ किंवा space चालत नाही. खऱ्या apps साठी Managed in AWS Secrets Manager निवडा (section 8).
    • जर दिसलं "contains invalid characters": password मधून @, /, quotes आणि spaces काढा.

47. Instance class आणि storage: free-tier defaults ठेवा

    • करा: Instance configuration आणि Storage तसेच ठेवा.
    • का: Sign-up table साठी 20 GiB storage सोबत db.t3.micro किंवा db.t4g.micro पुरेसा आहे आणि free tier मध्ये राहतो.

48. Compute resource: Don't connect to an EC2 compute resource

    • करा: Connectivity खाली Don't connect to an EC2 compute resource निवडा.
    • का: "Connect to an EC2 compute resource" database ला एका ठराविक instance शी बांधतं, त्यासाठी security group rules बनवून. आपले app servers Auto Scaling group बनवतो आणि बदलतो, म्हणून बांधायला एक instance नाहीच; DbSG आधीच पूर्ण AppEc2SG group वर विश्वास ठेवतो.

49. VPC ThreeTierVpc, DB subnet group threetierdbsubnetgroup

    • करा: Network type IPv4, Virtual private cloud (VPC) ThreeTierVpc, DB subnet group threetierdbsubnetgroup.
    • का: Database बनल्यावर त्याचा VPC बदलता येत नाही. चुकीच्या VPC मध्ये गेला, तर delete करून परत बनवणं हाच उपाय.

50. Public access: No

    • करा: No निवडा.
    • का: No ठेवलं की database ला public IP मिळत नाही आणि त्याचा endpoint फक्त private address ला resolve होतो, म्हणजे तो फक्त VPC च्या आतूनच पोहोचता येतो.

51. Security group: Choose existing, फक्त DbSG

    • करा: VPC security group (firewall): Choose existing, default काढा, DbSG add करा. Availability Zone: No preference. Database port (Additional configuration): 3306.
    • का: नाहीतर VPC चा default security group लागेल. DbSG आपल्या साखळीतली शेवटची कडी आहे.

52. Create database करा आणि Available ची वाट बघा

    • करा: Create database click करा. Add-ons चा pop-up आला तर बंद करा.
    • काय दिसेल: Banner "Creating database database-1"; Status Creating → Backing-up → Available, साधारण 5 ते 15 मिनिटं.
    • का: Instance, त्याचं storage आणि पहिला backup बनवायला RDS ला काही मिनिटं लागतात.
    • जर दिसलं "NetworkError when attempting to fetch resource": एक console request fail झाली. Databases उघडा; database-1 तिथे नसेल तर मागे जा, वरची प्रत्येक setting check करा आणि परत Create database click करा.

53. Endpoint copy करा

    • करा: Databases > database-1 > Connectivity & security: Endpoint copy करा (database-1.xxxxxxxxxxxx.ap-northeast-2.rds.amazonaws.com); Port 3306.
    • का: Endpoint हे DNS name आहे जे नेहमी सध्याच्या primary database कडे point करतं, Multi-AZ failover नंतर सुद्धा. IP address तुटेल; endpoint कधीच नाही.

Part F: JumpServer, database आणि table

54. JumpServer launch करा: Amazon Linux 2023, t3.micro

    • करा: EC2 > Instances > Launch instances: Name JumpServer, AMI Amazon Linux 2023 (64-bit x86), Instance type t3.micro.
    • का: Database private आहे, म्हणून तुमचा laptop तिथे पोहोचू शकत नाही. त्याच VPC मधल्या public subnet मधला एक छोटा server पोहोचू शकतो. Amazon Linux 2023 yum/dnf वापरतो; t3.micro बहुतेक accounts मध्ये free-tier eligible आहे आणि बहुतेक Regions च्या प्रत्येक AZ मध्ये मिळतो.

55. Key pair: Create new key pair ThreeTierKey, RSA, .pem

    • करा: Create new key pair: Name ThreeTierKey, Type RSA, Format .pem > Create key pair. Browser ThreeTierKey.pem download करतो.
    • का: AWS key चा फक्त public भाग ठेवतं; download झालेली .pem file private भागाची एकमेव copy. .pem Windows 10/11, Mac आणि Linux वरच्या OpenSSH सोबत चालते.

56. Network settings: ThreeTierVpc, PublicSubnet1, Auto-assign public IP: Enable, security group JumpSG

    • करा: Network settings > Edit: VPC ThreeTierVpc, Subnet PublicSubnet1, Auto-assign public IP Enable, Firewall Select existing security group > JumpSG.
    • का: Server internet वरून तेव्हाच पोहोचता येतो जेव्हा तिन्ही खरं असतं: त्याचा subnet internet gateway कडे route करतो, त्याला public IP आहे, आणि त्याचा security group तो port allow करतो. Public IP सोडला तर laptop वरून SSH करता येणार नाही.

57. Launch instance करा आणि public IP copy करा

    • करा: Launch instance > Instances मध्ये JumpServer उघडा.
    • काय दिसेल: Instance state Running, Status check 2/2 checks passed, एक Public IPv4 address.
    • का: पुढच्या steps मध्ये या address ला SSH करायचं.

58. Windows: key file ला फक्त तुमच्यासाठी read access द्या

    • करा: ThreeTierKey.pem वर right-click > Properties > Security > Advanced > Disable inheritance > Remove all inherited permissions from this object > Add > Select a principal > तुमचं Windows user name type करा (PowerShell मध्ये C:\Users\ नंतरचं नाव) > Check Names > OK > फक्त Read tick करा > OK > Apply > OK.
    • Command:

      icacls .\ThreeTierKey.pem /inheritance:r
      icacls .\ThreeTierKey.pem /grant:r "$($env:USERNAME):(R)"

    • Check करा: Downloads folder मध्ये PowerShell मधून वरच्या दोन icacls commands ने तेच result.
    • का: Computer वरची इतर accounts वाचू शकतील अशी private key OpenSSH नाकारतो. Download झालेली file Downloads folder चे permissions घेते, ज्यात इतर users आणि groups असतात. हे Mac आणि Linux वरच्या chmod 400 चं Windows version आहे: owner ला read, बाकी कुणालाच काही नाही.

59. Mac किंवा Linux: chmod 400

    • Command:

      chmod 400 ~/Downloads/ThreeTierKey.pem

    • का: 4 = owner ला read, group आणि others ला 0: SSH ला private key साठी नेमकं हेच पाहिजे.

60. JumpServer ला SSH करा

    • Command:

      ssh -i .\Downloads\ThreeTierKey.pem ec2-user@<JumpServer-public-IP>

    • काय दिसेल: Fingerprint च्या प्रश्नाला yes type करा; मग Amazon Linux 2023 banner आणि prompt [ec2-user@ip-10-0-… ~]$.
    • का: -i SSH ला कुठली private key वापरायची ते सांगतो; ec2-user Amazon Linux चा default user आहे.
    • जर दिसलं "WARNING: UNPROTECTED PRIVATE KEY FILE!" किंवा "Permission denied (publickey)": key file इतरांना वाचता येते; permission step परत करा, आणि ec2-user वापरलाय का ते बघा.
    • जर दिसलं "Connection timed out": JumpSG बनवल्यापासून तुमचा public IP बदलला (घरचा आणि mobile internet चा IP बदलतो), किंवा server ला public IP नाही किंवा तो public subnet मध्ये नाही. JumpSG edit करून परत My IP निवडा.

61. फक्त MySQL client install करा: mariadb105

    • Command:

      sudo yum install mariadb105 -y

    • काय दिसेल: शेवटी Complete!.
    • का: Database server RDS वर चालतो; JumpServer ला फक्त client program लागतो. तो नसेल तर mysql "command not found" देतो. mariadb105-server package तुम्हाला न लागणारा database server पण install करेल.

62. RDS ला connect करा

    • Command:

      mysql -h <rds-endpoint> -u root -p

    • काय दिसेल:

      Enter password:
      Welcome to the MariaDB monitor.  Commands end with ; or \g.
      Server version: 8.4.x Source distribution
      MySQL [(none)]>

    • का: -h host देतो; तो नसेल तर mysql local machine वर try करतो, जिथे database चालतच नाही. -p password न दाखवता विचारतो.
    • जर दिसलं ते अडकतं आणि मग "ERROR 2002" किंवा "ERROR 2003 Can't connect": DbSG मध्ये JumpSG कडून 3306 rule नाही, किंवा RDS दुसऱ्या security group सोबत बनला. Rule (Part D) किंवा database चा security group (Modify) दुरुस्त करा.
    • जर दिसलं "Access denied for user": user name किंवा password चुकलाय. नवा set करता येतो: RDS > database-1 > Modify > New master password > Continue > Apply immediately.

63. create database insta;

    • Command:

      create database insta;

    • काय दिसेल:

      Query OK, 1 row affected

    • का: App साठी एक database. त्याचं नाव submit.php मध्ये जातं.

64. use insta;

    • Command:

      use insta;

    • काय दिसेल:

      Database changed

    • का: पुढचा प्रत्येक command या database च्या आत चालतो.

65. users table बनवा

    • Command:

      create table users (id int primary key auto_increment, name varchar(50), mobile varchar(20), password varchar(255));

    • काय दिसेल:

      Query OK, 0 rows affected

    • का: id प्रत्येक row ला आपोआप number देतो (auto_increment) आणि ओळखतो (primary key). mobile text आहे, number नाही: number मध्ये सुरुवातीचा 0 किंवा + जातो, आणि 10 digits int मध्ये बसत नाहीत. password मध्ये hash ठेवतो, खरा password कधीच नाही; PHP चा password_hash() आज 60 characters देतो आणि PHP manual 255 पर्यंत जागा ठेवायला सांगतं.

66. desc users; ने check करा आणि exit

    • Command:

      desc users;
      exit

    • काय दिसेल:

      | id       | int          | NO   | PRI | NULL | auto_increment |
      | name     | varchar(50)  | YES  |     | NULL |                |
      | mobile   | varchar(20)  | YES  |     | NULL |                |
      | password | varchar(255) | YES  |     | NULL |                |
      4 rows in set
      Bye

    • का: PHP code त्यांच्यावर अवलंबून राहण्याआधी columns confirm होतात. Database tier आता पूर्ण.

Part G: PHP development server आणि phpami

67. ThreeTierVpc मध्ये phpdevelopmentserver launch करा

    • करा: Launch instances: Name phpdevelopmentserver, Amazon Linux 2023, t3.micro, key pair ThreeTierKey; Network settings > Edit: VPC ThreeTierVpc, Subnet PublicSubnet1, Auto-assign public IP Enable; Select existing security group: DevSG आणि AppEc2SG > Launch instance.
    • Check करा: Instance details मध्ये VPC ThreeTierVpc आणि दोन्ही security groups दिसतात.
    • का: App Auto Scaling group ला launch template लागतो, आणि template ला तयार AMI. हा तात्पुरता server म्हणजे ती AMI बनवायची आणि test करायची जागा. VPC दोनदा check करा: दोन वेगळ्या VPCs मधले servers default ला एकमेकांशी बोलू शकत नाहीत, म्हणून default VPC मधला PHP server RDS पर्यंत कधीच पोहोचणार नाही.
    • जर दिसलं instance default VPC मध्ये: instance दुसऱ्या VPC मध्ये हलवता येत नाही. Terminate करा आणि बरोबर VPC सोबत परत launch करा.

68. या server वर दोन security groups का

    • करा: Click करायचं काही नाही; पुढे जाण्याआधी वाचा.
    • का: AppEc2SG मुळे DbSG ला हा server अगदी पुढच्या app server सारखा दिसतो, म्हणजे इथली database test खरा रस्ता सिद्ध करते. DevSG setup साठी फक्त तुमच्या IP कडून SSH आणि HTTP add करतो. दोन्ही rule sets सरळ एकत्र जुळतात.

69. SSH करा

    • Command:

      ssh -i .\Downloads\ThreeTierKey.pem ec2-user@<php-dev-public-IP>

    • का: App tier चं सगळं software इथे एकदाच हाताने install होतं.

70. nginx, PHP, php-fpm आणि MySQL driver install करा

    • Command:

      sudo yum install nginx php php-fpm php-mysqlnd -y

    • काय दिसेल: Complete!
    • का: Internal ALB कडून आलेली HTTP request nginx घेतो. nginx स्वतः PHP चालवू शकत नाही, म्हणून तो .php files php-fpm ला देतो, आणि तो त्या चालवतो. php-mysqlnd हा driver PHP च्या mysqli ला MySQL शी बोलू देतो. Package names spelling अंदाजाने लिहिण्यापेक्षा Tab completion वापरून type करा.
    • जर दिसलं "No match for argument": sudo yum update -y ने package list refresh करा आणि Tab completion ने नाव परत type करा.

71. nginx start करा

    • Command:

      sudo service nginx start

    • काय दिसेल:

      Redirecting to /bin/systemctl start nginx.service

    • का: Service install केली म्हणजे ती सुरू होत नाही.

72. php-fpm start करा

    • Command:

      sudo service php-fpm start

    • का: php-fpm चालत नसेल तर nginx ला PHP द्यायला कुणीच नसतं आणि तो 502 देतो.

73. nginx boot ला enable करा

    • Command:

      sudo systemctl enable nginx

    • काय दिसेल:

      Created symlink /etc/systemd/system/multi-user.target.wants/nginx.service → /usr/lib/systemd/system/nginx.service.

    • का: या AMI वरून Auto Scaling group launch करतो ते servers कुणीही login न करता boot होतात. Start केलेली पण enable न केलेली service प्रत्येक boot नंतर बंद असते, म्हणजे प्रत्येक नवा server health check fail करेल.

74. php-fpm boot ला enable करा

    • Command:

      sudo systemctl enable php-fpm

    • का: तेच कारण: boot नंतर nginx चालू पण php-fpm बंद म्हणजे प्रत्येक PHP request 502 देते.

75. दोन्ही services check करा

    • Command:

      systemctl is-enabled nginx php-fpm
      systemctl is-active nginx php-fpm

    • काय दिसेल:

      enabled
      enabled
      active
      active

    • का: इथली चुकीची state AMI वरून बनणाऱ्या प्रत्येक server मध्ये copy होते.

76. Web root मध्ये जा

    • Command:

      cd /usr/share/nginx/html

    • का: Amazon Linux वर nginx /usr/share/nginx/html मधून files देतो.

77. index.php ने फक्त PHP test करा

    • करा: Command चालवा, <?php phpinfo(); ?> type करा, Ctrl+O, Enter, Ctrl+X ने save करा. Browser मध्ये http://<php-dev-public-IP>/index.php उघडा.
    • Command:

      sudo nano index.php

    • काय दिसेल: जांभळा "PHP Version 8.x" page.
    • का: एका वेळी एक कडी test करा. phpinfo() दिसलं तर nginx → php-fpm चालतंय, आणि पुढचा कुठलाही problem app code किंवा database मध्ये आहे, इथे नाही.
    • जर दिसलं file download होते, किंवा "502 Bad Gateway": php-fpm चालत नाही; start करा आणि page reload करा.

78. health.php बनवा

    • करा: <?php http_response_code(200); echo "ok"; type करून save करा.
    • Command:

      sudo nano health.php
      curl -s http://localhost/health.php

    • काय दिसेल:

      ok

    • का: Internal ALB ला PHP चालत असताना 200 देणारं एक छोटं page लागतं. ते database ला हात लावता कामा नये: database ला थोडा hiccup आला तर database वर अवलंबून health check प्रत्येक PHP server unhealthy ठरवेल आणि group ते सगळे बदलेल.

79. submit.php बनवा

    • करा: Code paste करा, तुमचा endpoint आणि password टाका, save करा.
    • Command:

      sudo nano submit.php

    • का: तो form चे तीन fields वाचतो आणि एक row insert करतो. $host RDS endpoint आहे, localhost नाही, कारण database RDS वर चालतो. Prepared statement (? placeholders) SQL injection थांबवतं, आणि password_hash() hash ठेवतो. Database ला हात लावण्याआधी POST नसलेलं सगळं तो नाकारतो.

80. submit.php चा code

    • Command:

      <?php
      // submit.php: saves one sign-up from forms.html into RDS
      $host = "database-1.xxxxxxxxxxxx.ap-northeast-2.rds.amazonaws.com"; // your RDS endpoint
      $user = "root";
      $pass = "YOUR_DB_PASSWORD";
      $db   = "insta";
      if ($_SERVER["REQUEST_METHOD"] !== "POST") {
          http_response_code(405);
          exit("Send the form with POST");
      }
      try {
          $conn   = new mysqli($host, $user, $pass, $db);
          $name   = trim($_POST["name"] ?? "");
          $mobile = trim($_POST["mobile"] ?? "");
          $hash   = password_hash($_POST["password"] ?? "", PASSWORD_DEFAULT);
          $stmt = $conn->prepare("INSERT INTO users (name, mobile, password) VALUES (?, ?, ?)");
          $stmt->bind_param("sss", $name, $mobile, $hash);
          $stmt->execute();
          echo "User registered successfully!";
          $stmt->close();
          $conn->close();
      } catch (mysqli_sql_exception $e) {
          http_response_code(500);
          echo "Database error";
      }

    • का: इथली प्रत्येक line वरच्या step मध्ये समजावली आहे; file नेमकी याच क्रमाने ठेवा.

81. Test साठी तात्पुरता forms.html बनवा

    • Command:

      sudo nano forms.html

    • का: submit.php POST fields वाचतो. Browser मध्ये त्याचा URL उघडला तर fields नसलेला GET जातो, म्हणून असं test करता येत नाही; form name, mobile आणि password पाठवतो. (Companies मध्ये testers हे लिहिलेल्या test cases ने करतात.)

82. forms.html चा code

    • Command:

      <!DOCTYPE html>
      <html>
      <head><meta charset="utf-8"><title>Sign up</title></head>
      <body>
      <h2>Create your account</h2>
      <form action="submit.php" method="post">
        <p><label>Name <input type="text" name="name" required></label></p>
        <p><label>Mobile <input type="tel" name="mobile" required></label></p>
        <p><label>Password <input type="password" name="password" required></label></p>
        <p><button type="submit">Register</button></p>
      </form>
      </body>
      </html>

    • का: action="submit.php" आणि method="post" तीन नाव असलेले fields submit.php ला पाठवतात; name attributes $_POST["name"], $_POST["mobile"] आणि $_POST["password"] शी जुळलेच पाहिजेत.

83. Form submit करा

    • करा: http://<php-dev-public-IP>/forms.html उघडा, fields भरा, Register click करा. Terminal मध्ये तेच curl ने test करता येतं.
    • Command:

      curl -s -X POST -d "name=Test&mobile=9999999999&password=Test@1234" http://localhost/submit.php

    • काय दिसेल: "User registered successfully!"
    • का: काहीही bake करण्याआधी DbSG मधून PHP → RDS चालतं हे सिद्ध होतं.
    • जर दिसलं page साधारण एक मिनिट फिरत राहतो आणि मग "504 Gateway Time-out" किंवा "Database error": DbSG AppEc2SG कडून 3306 allow करत नाही, किंवा या server ला AppEc2SG नाही. Security group connection packets शांतपणे drop करतो, PHP कधीच न येणाऱ्या उत्तराची वाट बघतो, आणि nginx 504 देऊन थांबतो. DbSG rule दुरुस्त करा किंवा instance ला AppEc2SG add करा (Actions > Security > Change security groups).
    • जर दिसलं लगेच "Database error": submit.php मधला endpoint, user, password किंवा database name चुकलाय; Part E आणि Part F शी तुलना करा.

84. JumpServer वरून row check करा

    • Command:

      mysql -h <rds-endpoint> -u root -p -e "select id, name, mobile, left(password,4) from insta.users;"

    • काय दिसेल: तुमच्या नावाची एक row आणि शेवटच्या column मध्ये $2y$.
    • का: Row खरंच RDS पर्यंत पोहोचली आणि password hash म्हणून ठेवलाय हे सिद्ध होतं (तो $2y$ ने सुरू होतो).

85. PHP server वरून forms.html आणि index.php काढा

    • Command:

      sudo rm /usr/share/nginx/html/forms.html /usr/share/nginx/html/index.php
      ls /usr/share/nginx/html

    • Check करा: List मध्ये health.php आणि submit.php दिसतात (आणि nginx च्या स्वतःच्या default files).
    • का: HTML web tier चं काम; app servers फक्त PHP चालवतात. phpinfo() उघडणाऱ्या कुणालाही तुमचं PHP configuration दाखवतं, जे attackers ना मदत करतं. submit.php आणि health.php ठेवा.

86. AMI phpami बनवा

    • करा: Instances > phpdevelopmentserver select करा > Actions > Image and templates > Create image: Image name phpami, Image description nginx + php-fpm + submit.php + health.php, Reboot instance tick ठेवा > Create image.
    • काय दिसेल: Images > AMIs: phpami, Status Pending → काही मिनिटांनी Available.
    • का: AMI हा test केलेला server गोठवते, म्हणजे Auto Scaling group त्याच्या एकसारख्या copies बनवू शकतो. Reboot on ठेवा: AWS क्षणभर writes थांबवतं म्हणजे disk snapshot consistent राहतो. स्पष्ट नाव महत्त्वाचं कारण दोन AMIs असतील आणि प्रत्येक template मध्ये बरोबर निवडायची आहे.
    • जर दिसलं "Failed to load image creation. Try reloading the page.": console glitch; page reload करा आणि परत बनवण्याआधी AMIs list check करा.

Part H: app tier (launch template, Auto Scaling group, internal ALB)

87. Launch template AppTierLaunchTemplate बनवा

    • करा: EC2 > Launch templates > Create launch template: Name AppTierLaunchTemplate, Template version description v1, Provide guidance to help me set up a template that I can use with EC2 Auto Scaling tick करा.
    • का: Launch template म्हणजे Auto Scaling group प्रत्येक वेळी server सुरू करताना वापरतो ती recipe: AMI, instance type, key pair आणि security group. Auto Scaling guidance tick केलं की group वापरू शकणार नाही अशा settings बद्दल console warning देतो.

88. AMI: My AMIs > phpami; type t3.micro; key pair ThreeTierKey

    • करा: Application and OS Images > My AMIs > Owned by me > phpami; Instance type t3.micro; Key pair ThreeTierKey.
    • का: phpami मध्ये software, files आणि enabled services आधीच आहेत, म्हणून नवा server boot होताच तयार असतो. Key pair मुळे नंतर debugging साठी SSH करता येतं.

89. Network: Subnet: Don't include in launch template, security group AppEc2SG

    • करा: Network settings: Subnet Don't include in launch template; Firewall Select existing security group > AppEc2SG; Advanced network configuration रिकामं ठेवा > Create launch template.
    • काय दिसेल: "Successfully created AppTierLaunchTemplate".
    • का: Subnets Auto Scaling group निवडतो, प्रत्येक AZ ला एक. Template मध्ये fix केलेला subnet प्रत्येक server ला एका AZ मध्ये बांधेल. Security group template मध्येच हवा कारण या tier च्या प्रत्येक server ला तोच लागतो.

90. AppTierLaunchTemplate वरून Auto Scaling group AppTierASG बनवा

    • करा: EC2 > Auto Scaling groups > Create Auto Scaling group: Name AppTierASG, Launch template AppTierLaunchTemplate, Version Default (1) > Next.
    • का: Group योग्य संख्येने servers चालू ठेवतो, ते AZs मध्ये पसरवतो, बिघडलेले बदलतो आणि load प्रमाणे servers वाढवतो किंवा कमी करतो. हे servers तुम्ही कधीच हाताने launch करत नाही.

91. Network: ThreeTierVpc, subnets AppSubnet1 आणि AppSubnet2

    • करा: VPC ThreeTierVpc, Availability Zones and subnets AppSubnet1 आणि AppSubnet2.
    • का: दोन AZs मध्ये दोन subnets: एक AZ बंद पडला तर group दुसऱ्यात servers सुरू करतो.
    • जर दिसलं "The requested instance type is not supported in the requested Availability Zone": प्रत्येक instance type प्रत्येक AZ मध्ये नसतो. t3.micro ठेवा, किंवा नवीन template version मध्ये दुसरा type निवडा (section 10).

92. AZ distribution: Balanced best effort

    • करा: Availability Zone distribution: Balanced best effort > Next.
    • का: Balanced only AZ मध्ये capacity नसेल तर त्याच AZ मध्ये थांबून परत try करतो. Balanced best effort त्याऐवजी दुसऱ्या AZ मध्ये launch करतो, म्हणजे app ला server आत्ता मिळतो आणि group नंतर rebalance करतो. सगळे एकाच वेळी servers launch करतात, जसं festival sale मध्ये shopping sites, तेव्हा एका AZ मध्ये एखादा type संपू शकतो; best effort मुळे service चालू राहते.

93. Attach to a new load balancer: Application Load Balancer AppTierInternalALB, Internal

    • करा: Load balancing: Attach to a new load balancer, Application Load Balancer, Load balancer name AppTierInternalALB, Load balancer scheme Internal.
    • का: Wizard load balancer, त्याचा listener आणि target group एकदम बनवतो आणि group चे servers त्यात register करतो. Internal म्हणजे load balancer ला फक्त private IPs मिळतात आणि त्याचं DNS name फक्त VPC च्या आत resolve होतं: फक्त web tier त्याच्यापर्यंत पोहोचू शकतो.

94. Listener HTTP 80, Create a target group AppTierTG

    • करा: Listeners and routing: Protocol HTTP, Port 80, Default routing Create a target group, New target group name AppTierTG.
    • का: Listener म्हणजे load balancer accept करतो तो port; target group म्हणजे तो forward करतो आणि health-check करतो त्या servers ची list.

95. Elastic Load Balancing health checks on करा, grace period 60

    • करा: Health checks: Turn on Elastic Load Balancing health checks tick करा, Health check grace period 60 > Next.
    • का: Default ला group server फक्त EC2 machine च बिघडली तर बदलतो. ELB health checks on असतील तर ज्याचं app उत्तर देणं बंद झालंय असा server पण बदलतो. Grace period नव्या server ला checks मोजले जाण्याआधी boot होण्यासाठी 60 seconds देतो.

96. Group size: Desired 2, Min 1, Max 4

    • करा: Desired capacity 2; Min desired capacity 1; Max desired capacity 4.
    • का: Desired 2 म्हणजे प्रत्येक AZ ला एक server. Min 1 म्हणजे scaling कधीच खाली जाणार नाही अशी मर्यादा; Max 4 bill आणि तुमचा vCPU quota मर्यादित ठेवतो.

97. Scaling: Target tracking, Average CPU utilization 20, warmup 60

    • करा: Automatic scaling: Target tracking scaling policy, Metric type Average CPU utilization, Target value 20, Instance warmup 60.
    • का: Group चा average CPU 20% च्या वर गेला की target tracking servers वाढवतो आणि बराच खाली आला की कमी करतो. 20 मुद्दाम कमी ठेवलाय म्हणजे lab मध्ये scaling दिसतं; production मध्ये बहुतेक 50 ते 70. Warmup group ला सांगतो की नव्या server चा CPU पहिले 60 seconds मोजू नको.

98. Maintenance policy: No policy; Enable group metrics collection tick करा

    • करा: Instance maintenance policy No policy; Additional settings: Enable group metrics collection within CloudWatch tick करा > Next > Next (notifications नाहीत).
    • का: No policy default replacement behaviour ठेवते. Group metrics Monitoring tab मध्ये वेळेनुसार servers ची संख्या दाखवतात, scaling होताना असंच बघता येतं.

99. Tag Name = AppTierServer, मग Create Auto Scaling group

    • करा: Add tag: Key Name, Value AppTierServer > Next > review > Create Auto Scaling group.
    • काय दिसेल: एक-दोन मिनिटांत दोन AppTierServer instances, प्रत्येक AZ मध्ये एक.
    • का: Tag नसेल तर group चा प्रत्येक server Instances list मध्ये रिकाम्या नावाने दिसतो आणि tiers ओळखता येत नाहीत. "Tag new instances" default ला tick असतं.
    • जर दिसलं group च्या Activity tab मध्ये "You have requested more vCPU capacity than your current vCPU limit": account चा On-Demand vCPU quota भरलाय. नको असलेले servers terminate करा, किंवा जास्त मागा (section 10).

100. AppTierInternalALB ला त्याचा स्वतःचा security group द्या

     • करा: EC2 > Load balancers > AppTierInternalALB > Security tab > Edit: सगळे groups काढा, AppAlbSG add करा > Save changes.
     • का: Wizard नव्या load balancer ला launch template चा security group लावतो. आपल्या साखळीला load balancer वर AppAlbSG पाहिजे, नाहीतर फक्त load balancer च्या group वर विश्वास ठेवणारा server security group प्रत्येक forward केलेली request block करतो.

101. AppTierTG चा health check /health.php वर set करा

     • करा: EC2 > Target groups > AppTierTG > Health checks tab > Edit: Health check path /health.php; Advanced health check settings: Healthy threshold 2, Unhealthy threshold 2, Timeout 2, Interval 5, Success codes 200 > Save changes.
     • का: Target group default ला / check करतो. /health.php सिद्ध करतो की या tier चा महत्त्वाचा भाग 200 देतोय. 5-second interval वर Healthy 2 आणि Unhealthy 2 म्हणजे server साधारण 10 seconds मध्ये target group मध्ये येतो किंवा बाहेर जातो; timeout (2 s) interval पेक्षा कमीच पाहिजे.

102. AppTierTG मध्ये दोन Healthy targets ची वाट बघा

     • करा: AppTierTG > Targets tab, refresh करा.
     • काय दिसेल: 2 Healthy, प्रत्येक AZ मध्ये एक target.
     • का: फक्त healthy targets ना traffic मिळतं. दोन्ही healthy असतील तर हा tier त्याच्या load balancer मधून पूर्ण चालतोय.
     • जर दिसलं Unhealthy, "Health checks failed" किंवा "Request timed out": server security group load balancer च्या security group कडून port 80 allow करत नाही, किंवा load balancer ला अजून चुकीचा group आहे (मागची step).
     • जर दिसलं "Health checks failed with these codes: [404]": {path} AMI मध्ये नाही. Dev server वर file दुरुस्त करा, नवी AMI आणि नवीन template version बनवा (Part L).
     • जर दिसलं Unhealthy होणारे आणि परत परत बदलले जाणारे targets: AMI बनवण्याआधी nginx किंवा php-fpm enable नव्हतं, म्हणून boot नंतर कुणीच ऐकत नाही. Dev server वर services enable करा आणि नवी AMI bake करा.

103. AppTierInternalALB चं DNS name copy करा

     • करा: Load balancers > AppTierInternalALB > Details > DNS name (copy icon).
     • काय दिसेल: internal-AppTierInternalALB-…ap-northeast-2.elb.amazonaws.com, Scheme Internal.
     • का: Web tier ला हे नाव त्याच्या nginx proxy मध्ये लागतं.

Part I: nginx development server आणि webami

104. phpdevelopmentserver terminate करा

     • करा: AMIs check करा: phpami Available आहे. मग Instances > phpdevelopmentserver > Instance state > Terminate (delete) instance.
     • का: phpami Available झाली तेव्हाच त्याचं काम संपलं; app servers आता AMI वरून येतात. पुढच्या server साठी quota चे 2 vCPUs पण मोकळे होतात.

105. DevSG आणि WebEc2SG सोबत nginxdevelopmentserver launch करा

     • करा: Launch instances: Name nginxdevelopmentserver, Amazon Linux 2023, t3.micro, ThreeTierKey; VPC ThreeTierVpc, Subnet PublicSubnet1, Auto-assign public IP Enable; security groups DevSG आणि WebEc2SG > Launch instance.
     • का: PHP server सारखीच कल्पना: WebEc2SG मुळे AppAlbSG ला तो खऱ्या web server सारखा दिसतो, म्हणजे proxy test खरा रस्ता सिद्ध करते; DevSG setup साठी आत येऊ देतो.
     • जर दिसलं "You have requested more vCPU capacity than your current vCPU limit of 16 allows": चालू servers आधीच तुमचा On-Demand quota वापरतायत. नको असलेले servers terminate करा, किंवा सध्या App group Desired 1 करा, किंवा Service Quotas मध्ये increase मागा (section 10).

106. SSH करा आणि फक्त nginx install करा

     • Command:

       ssh -i .\Downloads\ThreeTierKey.pem ec2-user@<nginx-dev-public-IP>
       sudo yum install nginx -y

     • काय दिसेल: Complete!
     • का: Web tier HTML देतो आणि PHP पुढे पाठवतो; तो स्वतः PHP चालवत नाही आणि database शी कधीच बोलत नाही.

107. nginx start आणि enable करा

     • Command:

       sudo service nginx start
       sudo systemctl enable nginx
       systemctl is-enabled nginx

     • काय दिसेल:

       enabled

     • का: webami bake करण्याआधी enable करा, नाहीतर प्रत्येक web server nginx बंद असताना सुरू होतो आणि web load balancer 502 देतो.

108. Web root मध्ये forms.html ठेवा

     • करा: Part G मधलाच forms.html code paste करून save करा.
     • Command:

       sudo nano /usr/share/nginx/html/forms.html
       curl -s http://localhost/forms.html | head -3

     • काय दिसेल:

       <!DOCTYPE html>
       <html>
       <head><meta charset="utf-8"><title>Sign up</title></head>

     • का: हा users ना दिसणारा page. त्याचं action="submit.php" relative आहे, म्हणून browser त्याच load balancer ला post करतो, आणि nginx ते app tier कडे पाठवतो.

109. nginx.conf चा backup घ्या आणि उघडा

     • Command:

       sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
       sudo nano /etc/nginx/nginx.conf

     • का: Edit मुळे file बिघडली तर copy मुळे एका command मध्ये मागे जाता येतं.

110. server { … } block च्या आत .php proxy add करा

     • करा: पहिल्या server block च्या listen 80; आणि root /usr/share/nginx/html; lines खाली, तुमच्या internal ALB DNS name सोबत खालचा block paste करा, save करा.
     • Command:

           location ~ \.php$ {
               resolver 10.0.0.2 valid=30s;
               set $app_alb "http://internal-AppTierInternalALB-xxxxxxxx.ap-northeast-2.elb.amazonaws.com";
               proxy_pass $app_alb;
               proxy_set_header Host $host;
               proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           }

     • का: .php ने संपणारी प्रत्येक request internal ALB कडे जाते; बाकी सगळं (forms.html) इथूनच दिलं जातं. resolver 10.0.0.2 हा VPC चा DNS server (VPC base address + 2). नाव variable मध्ये ठेवलं की nginx ते दर 30 seconds ला परत look up करतो; साध्या proxy_pass नावाने nginx ते start ला एकदाच resolve करतो, आणि ALB चे IP addresses बदलले (ते बदलतात) की requests 502 ने fail होऊ लागतात.

111. Config test करा आणि reload करा

     • Command:

       sudo nginx -t
       sudo service nginx reload

     • काय दिसेल:

       nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
       nginx: configuration file /etc/nginx/nginx.conf test is successful

     • का: nginx -t typos server बंद पाडण्याआधीच शोधतो; reload उघडी connections न तोडता बदल लागू करतो.
     • जर दिसलं "unexpected }" किंवा "directive is not allowed here": block server { } च्या बाहेर आहे किंवा brace राहिलाय. दुरुस्त करा, किंवा sudo cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf ने restore करा.

112. Dev server वरून पूर्ण chain test करा

     • करा: मग http://<nginx-dev-public-IP>/forms.html उघडा, भरा आणि Register click करा.
     • Command:

       curl -s http://localhost/health.php

     • काय दिसेल: Terminal मध्ये ok, मग browser मध्ये "User registered successfully!".
     • का: health.php फक्त app servers वर आहे, म्हणून इथे ok मिळालं म्हणजे nginx → internal ALB → PHP चालतंय. मग form test PHP → RDS पण सिद्ध करते.
     • जर दिसलं "504 Gateway Time-out": AppAlbSG WebEc2SG कडून port 80 allow करत नाही, किंवा या server ला WebEc2SG नाही, किंवा internal ALB ला अजून चुकीचा security group आहे.
     • जर दिसलं "502 Bad Gateway": $app_alb मधलं नाव चुकलंय किंवा resolver line नाही; sudo tail /var/log/nginx/error.log ने check करा.
     • जर दिसलं "503 Service Temporarily Unavailable": internal ALB कडे registered targets नाहीत: AppTierASG दोन servers चालवतोय का ते check करा.

113. AMI webami बनवा

     • करा: Instances > nginxdevelopmentserver > Actions > Image and templates > Create image: Image name webami, Description nginx + forms.html + php proxy > Create image.
     • काय दिसेल: काही मिनिटांनी AMIs मध्ये webami Available.
     • का: Test केलेला web server गोठवते: enabled nginx, forms.html आणि proxy config.

Part J: web tier (launch template, Auto Scaling group, internet-facing ALB)

114. Launch template WebTierLaunchTemplate बनवा

     • करा: EC2 > Launch templates > Create launch template: Name WebTierLaunchTemplate, Template version description v1, Provide guidance to help me set up a template that I can use with EC2 Auto Scaling tick करा.
     • का: Launch template म्हणजे Auto Scaling group प्रत्येक वेळी server सुरू करताना वापरतो ती recipe: AMI, instance type, key pair आणि security group. Auto Scaling guidance tick केलं की group वापरू शकणार नाही अशा settings बद्दल console warning देतो.

115. AMI: My AMIs > webami; type t3.micro; key pair ThreeTierKey

     • करा: Application and OS Images > My AMIs > Owned by me > webami; Instance type t3.micro; Key pair ThreeTierKey.
     • का: webami मध्ये software, files आणि enabled services आधीच आहेत, म्हणून नवा server boot होताच तयार असतो. Key pair मुळे नंतर debugging साठी SSH करता येतं.

116. Network: Subnet: Don't include in launch template, security group WebEc2SG

     • करा: Network settings: Subnet Don't include in launch template; Firewall Select existing security group > WebEc2SG; Advanced network configuration रिकामं ठेवा > Create launch template.
     • काय दिसेल: "Successfully created WebTierLaunchTemplate".
     • का: Subnets Auto Scaling group निवडतो, प्रत्येक AZ ला एक. Template मध्ये fix केलेला subnet प्रत्येक server ला एका AZ मध्ये बांधेल. Security group template मध्येच हवा कारण या tier च्या प्रत्येक server ला तोच लागतो.

117. WebTierLaunchTemplate वरून Auto Scaling group WebTierASG बनवा

     • करा: EC2 > Auto Scaling groups > Create Auto Scaling group: Name WebTierASG, Launch template WebTierLaunchTemplate, Version Default (1) > Next.
     • का: Group योग्य संख्येने servers चालू ठेवतो, ते AZs मध्ये पसरवतो, बिघडलेले बदलतो आणि load प्रमाणे servers वाढवतो किंवा कमी करतो. हे servers तुम्ही कधीच हाताने launch करत नाही.

118. Network: ThreeTierVpc, subnets WebSubnet1 आणि WebSubnet2

     • करा: VPC ThreeTierVpc, Availability Zones and subnets WebSubnet1 आणि WebSubnet2.
     • का: दोन AZs मध्ये दोन subnets: एक AZ बंद पडला तर group दुसऱ्यात servers सुरू करतो.
     • जर दिसलं "The requested instance type is not supported in the requested Availability Zone": प्रत्येक instance type प्रत्येक AZ मध्ये नसतो. t3.micro ठेवा, किंवा नवीन template version मध्ये दुसरा type निवडा (section 10).

119. AZ distribution: Balanced best effort

     • करा: Availability Zone distribution: Balanced best effort > Next.
     • का: Balanced only AZ मध्ये capacity नसेल तर त्याच AZ मध्ये थांबून परत try करतो. Balanced best effort त्याऐवजी दुसऱ्या AZ मध्ये launch करतो, म्हणजे app ला server आत्ता मिळतो आणि group नंतर rebalance करतो. सगळे एकाच वेळी servers launch करतात, जसं festival sale मध्ये shopping sites, तेव्हा एका AZ मध्ये एखादा type संपू शकतो; best effort मुळे service चालू राहते.

120. Attach to a new load balancer: Application Load Balancer WebTierPublicALB, Internet-facing

     • करा: Load balancing: Attach to a new load balancer, Application Load Balancer, Load balancer name WebTierPublicALB, Load balancer scheme Internet-facing.
     • का: Wizard load balancer, त्याचा listener आणि target group एकदम बनवतो आणि group चे servers त्यात register करतो. Internet-facing मुळे load balancer ला public IPs आणि public DNS name मिळतं: users उघडतात तो हाच एक address. Internet-facing load balancer साठी wizard त्याचे स्वतःचे subnets विचारतो: PublicSubnet1 आणि PublicSubnet2 निवडा.

121. Listener HTTP 80, Create a target group WebTierTG

     • करा: Listeners and routing: Protocol HTTP, Port 80, Default routing Create a target group, New target group name WebTierTG.
     • का: Listener म्हणजे load balancer accept करतो तो port; target group म्हणजे तो forward करतो आणि health-check करतो त्या servers ची list.

122. Elastic Load Balancing health checks on करा, grace period 60

     • करा: Health checks: Turn on Elastic Load Balancing health checks tick करा, Health check grace period 60 > Next.
     • का: Default ला group server फक्त EC2 machine च बिघडली तर बदलतो. ELB health checks on असतील तर ज्याचं app उत्तर देणं बंद झालंय असा server पण बदलतो. Grace period नव्या server ला checks मोजले जाण्याआधी boot होण्यासाठी 60 seconds देतो.

123. Group size: Desired 2, Min 1, Max 4

     • करा: Desired capacity 2; Min desired capacity 1; Max desired capacity 4.
     • का: Desired 2 म्हणजे प्रत्येक AZ ला एक server. Min 1 म्हणजे scaling कधीच खाली जाणार नाही अशी मर्यादा; Max 4 bill आणि तुमचा vCPU quota मर्यादित ठेवतो.

124. Scaling: Target tracking, Average CPU utilization 20, warmup 60

     • करा: Automatic scaling: Target tracking scaling policy, Metric type Average CPU utilization, Target value 20, Instance warmup 60.
     • का: Group चा average CPU 20% च्या वर गेला की target tracking servers वाढवतो आणि बराच खाली आला की कमी करतो. 20 मुद्दाम कमी ठेवलाय म्हणजे lab मध्ये scaling दिसतं; production मध्ये बहुतेक 50 ते 70. Warmup group ला सांगतो की नव्या server चा CPU पहिले 60 seconds मोजू नको.

125. Maintenance policy: No policy; Enable group metrics collection tick करा

     • करा: Instance maintenance policy No policy; Additional settings: Enable group metrics collection within CloudWatch tick करा > Next > Next (notifications नाहीत).
     • का: No policy default replacement behaviour ठेवते. Group metrics Monitoring tab मध्ये वेळेनुसार servers ची संख्या दाखवतात, scaling होताना असंच बघता येतं.

126. Tag Name = WebTierServer, मग Create Auto Scaling group

     • करा: Add tag: Key Name, Value WebTierServer > Next > review > Create Auto Scaling group.
     • काय दिसेल: एक-दोन मिनिटांत दोन WebTierServer instances, प्रत्येक AZ मध्ये एक.
     • का: Tag नसेल तर group चा प्रत्येक server Instances list मध्ये रिकाम्या नावाने दिसतो आणि tiers ओळखता येत नाहीत. "Tag new instances" default ला tick असतं.
     • जर दिसलं group च्या Activity tab मध्ये "You have requested more vCPU capacity than your current vCPU limit": account चा On-Demand vCPU quota भरलाय. नको असलेले servers terminate करा, किंवा जास्त मागा (section 10).

127. WebTierPublicALB ला त्याचा स्वतःचा security group द्या

     • करा: EC2 > Load balancers > WebTierPublicALB > Security tab > Edit: सगळे groups काढा, WebAlbSG add करा > Save changes.
     • का: Wizard नव्या load balancer ला launch template चा security group लावतो. आपल्या साखळीला load balancer वर WebAlbSG पाहिजे, नाहीतर फक्त load balancer च्या group वर विश्वास ठेवणारा server security group प्रत्येक forward केलेली request block करतो.

128. WebTierTG चा health check /forms.html वर set करा

     • करा: EC2 > Target groups > WebTierTG > Health checks tab > Edit: Health check path /forms.html; Advanced health check settings: Healthy threshold 2, Unhealthy threshold 2, Timeout 3, Interval 5, Success codes 200 > Save changes.
     • का: Target group default ला / check करतो. /forms.html सिद्ध करतो की या tier चा महत्त्वाचा भाग 200 देतोय. 5-second interval वर Healthy 2 आणि Unhealthy 2 म्हणजे server साधारण 10 seconds मध्ये target group मध्ये येतो किंवा बाहेर जातो; timeout (3 s) interval पेक्षा कमीच पाहिजे.

129. WebTierTG मध्ये दोन Healthy targets ची वाट बघा

     • करा: WebTierTG > Targets tab, refresh करा.
     • काय दिसेल: 2 Healthy, प्रत्येक AZ मध्ये एक target.
     • का: फक्त healthy targets ना traffic मिळतं. दोन्ही healthy असतील तर हा tier त्याच्या load balancer मधून पूर्ण चालतोय.
     • जर दिसलं Unhealthy, "Health checks failed" किंवा "Request timed out": server security group load balancer च्या security group कडून port 80 allow करत नाही, किंवा load balancer ला अजून चुकीचा group आहे (मागची step).
     • जर दिसलं "Health checks failed with these codes: [404]": {path} AMI मध्ये नाही. Dev server वर file दुरुस्त करा, नवी AMI आणि नवीन template version बनवा (Part L).
     • जर दिसलं Unhealthy होणारे आणि परत परत बदलले जाणारे targets: AMI बनवण्याआधी nginx किंवा php-fpm enable नव्हतं, म्हणून boot नंतर कुणीच ऐकत नाही. Dev server वर services enable करा आणि नवी AMI bake करा.

130. WebTierPublicALB चं DNS name copy करा

     • करा: Load balancers > WebTierPublicALB > Details > DNS name (copy icon).
     • काय दिसेल: WebTierPublicALB-…ap-northeast-2.elb.amazonaws.com, Scheme Internet-facing.
     • का: हा पूर्ण app चा address आहे.

Part K: पूर्ण app test करा आणि lock करा

131. Public load balancer मधून app उघडा

     • करा: http://<WebTierPublicALB-DNS>/forms.html उघडा, form भरा, Register.
     • काय दिसेल: "User registered successfully!"
     • का: हाच खरा user path: browser → WebTierPublicALB → web server → AppTierInternalALB → app server → RDS. कुठलाही server थेट पोहोचला जात नाही.
     • जर दिसलं काही मिनिटं page अजिबात load होत नाही: नव्या load balancer चं DNS name resolve व्हायला काही मिनिटं लागतात. थांबा आणि परत try करा.

132. RDS मध्ये नवी row check करा

     • Command:

       mysql -h <rds-endpoint> -u root -p -e "select id, name, left(password,4) from insta.users;"

     • काय दिसेल: नवी row, password ची सुरुवात $2y$.
     • का: Request तिन्ही tiers पार करून गेली हे सिद्ध होतं.

133. Self-healing test: एक WebTierServer terminate करा

     • करा: Instances > एक WebTierServer > Terminate (delete) instance. Form page reload करत राहा. मग WebTierASG > Activity उघडा.
     • काय दिसेल: Page load होत राहतो; Activity मध्ये "Terminating EC2 instance" आणि मग "Launching a new EC2 instance"; एक-दोन मिनिटांत WebTierTG मध्ये परत 2 Healthy targets.
     • का: Group का आहे ते इथे दिसतं: health checks मुळे गायब server त्याला कळतो आणि तुमच्या मदतीशिवाय webami वरून replacement launch करतो, तोपर्यंत दुसरा server app चालू ठेवतो.

134. nginxdevelopmentserver terminate करा

     • करा: Instances > nginxdevelopmentserver > Terminate (delete) instance.
     • का: webami सोबत त्याचं काम संपलं. SSH आणि HTTP उघडे असलेला dev server म्हणजे attack surface आणि खर्च.

135. DbSG मधून JumpSG rule काढा

     • करा: Security groups > DbSG > Inbound rules > Edit inbound rules > source JumpSG असलेल्या MYSQL/Aurora rule ला Delete > Save rules. JumpServer आता लागत नसेल तर stop किंवा terminate करा.
     • Check करा: DbSG मध्ये एकच inbound rule: MYSQL/Aurora 3306, source AppEc2SG.
     • का: तो फक्त database आणि table बनवायला लागत होता. आता port 3306 पर्यंत जायचा एकमेव रस्ता AppEc2SG: नेमकं clean design.

136. Optional: CNAME ने तुमचा domain load balancer कडे point करा

     • करा: तुमच्या domain provider च्या DNS records मध्ये: Add record, Type CNAME, Name www, Value WebTierPublicALB चं DNS name, TTL default > Save. Route 53 मध्ये त्याऐवजी Alias A record वापरता येतो.
     • Check करा: nslookup www.yourdomain.com canonical name म्हणून ELB name दाखवतो; मग http://www.yourdomain.com/forms.html form उघडतो.
     • का: Users नी www.yourdomain.com type करावं, लांब ELB name नाही. CNAME म्हणतं "हे नाव त्या नावाचं दुसरं नाव आहे". Load balancer चे IPs बदलतात, म्हणून domain कधीच IP कडे point करत नाही; DNS name कडे करतो.
     • जर दिसलं browser मध्ये "Server Not Found": browser ला नाव resolve करता आलं नाही, म्हणजे request AWS पर्यंत पोहोचलीच नाही. DNS propagate व्हायची वाट बघा, record name check करा, किंवा दुसरं network किंवा DNS server try करा. हा कधीच security group problem नसतो.

Part L: servers सुरक्षितपणे बदला (नवीन template version + instance refresh)

137. Launch template चा नवीन version बनवा

     • करा: Launch templates > AppTierLaunchTemplate > Actions > Modify template (Create new version): Template version description v2, AMI phpami-v2 > Create template version.
     • का: Launch template जागेवर edit करता येत नाही: प्रत्येक बदल म्हणजे नवीन numbered version, म्हणजे आधी काय चाललं ते नेहमी बघता येतं आणि तिथे परत जाता येतं. उदाहरण: तुम्ही fix सोबत phpami-v2 bake केली.

138. Group ला Latest कडे point करा

     • करा: AppTierASG > Details > Launch template > Edit > Version Latest > Update.
     • का: Default (1) असेल तर group version 1 च launch करत राहतो. Latest मुळे पुढचा प्रत्येक launch सगळ्यात नवा version वापरतो.

139. Instance refresh start करा

     • करा: AppTierASG > Instance refresh tab > Start instance refresh: Minimum healthy percentage 50 आणि Maximum healthy percentage 100 (दोनपैकी एक server एका वेळी बदलतो, दुसरा traffic घेतो), Instance warmup 60 > Start instance refresh.
     • काय दिसेल: Status InProgress, मग Successful; instances list मध्ये नवे instance IDs.
     • का: Template बदलल्याने आधीच चालू servers ना काही होत नाही. Instance refresh त्यांना थोडे-थोडे करून बदलतो, प्रत्येक नवा server health checks pass करेपर्यंत थांबून, म्हणजे rollout चालू असताना app चालू राहतो.

Part M: cleanup, म्हणजे काहीही bill करत राहणार नाही

140. आधी दोन्ही Auto Scaling groups delete करा

     • करा: Auto Scaling groups > WebTierASG आणि AppTierASG select करा > Actions > Delete > delete type करा.
     • का: आधी servers terminate केले तर groups सरळ नवे launch करतात. Group delete केला की त्याचे servers terminate होतात.

141. दोन्ही load balancers, मग दोन्ही target groups delete करा

     • करा: Load balancers > दोन्ही > Actions > Delete load balancer > confirm type करा. Target groups > WebTierTG, AppTierTG > Actions > Delete.
     • का: Load balancers traffic नसलं तरी दर तासाला bill करतात. Listener वापरत असलेला target group delete होत नाही, म्हणून load balancers आधी.

142. RDS database delete करा

     • करा: RDS > Databases > database-1 > Actions > Delete: Create final snapshot untick, Retain automated backups untick, acknowledgement tick करा, delete me type करा > Delete.
     • का: Database तासाप्रमाणे आणि storage साठी bill करतो.

143. उरलेले instances terminate करा

     • करा: Instances > उरलेले select करा > Instance state > Terminate (delete) instance.
     • का: JumpServer आणि ठेवलेला कुठलाही dev server अजून खर्च करतो.

144. दोन्ही AMIs deregister करा आणि त्यांचे snapshots delete करा

     • करा: AMIs > phpami, webami (आणि कुठलीही -v2) > Actions > Deregister AMI. Snapshots > त्यांचे snapshots select करा > Actions > Delete snapshot.
     • का: AMI तिची disk EBS snapshot म्हणून ठेवते, आणि AMI deregister केल्यावरही snapshot storage चा खर्च करत राहतो.

145. Launch templates आणि DB subnet group delete करा

     • करा: Launch templates > दोन्ही > Actions > Delete template. RDS > Subnet groups > threetierdbsubnetgroup > Delete.
     • का: त्यांचा खर्च नाही, पण उरलेल्या गोष्टी account भरतात आणि पुढच्या build मध्ये गोंधळ करतात.

146. VPC सगळ्यात शेवटी delete करा

     • करा: VPC > Your VPCs > ThreeTierVpc > Actions > Delete VPC > delete type करा > Delete.
     • काय दिसेल: VPC list मधून जातो; EC2 > Instances, Load balancers आणि RDS > Databases रिकामे.
     • का: VPC delete केला की त्याचे subnets, route tables, internet gateway आणि security groups पण delete होतात, पण फक्त त्यांना दुसरं काही वापरत नसेल तेव्हाच.
     • जर दिसलं "has dependencies and cannot be deleted": अजून काहीतरी VPC वापरतंय, बहुतेक delete होत असलेला load balancer किंवा RDS, किंवा एखादा ENI. काही मिनिटं थांबा आणि परत try करा.

10. Build करताना आलेले side topics

यातला प्रत्येक विषय lab मध्ये कशाला तरी लागला म्हणून आला. प्रत्येकात तो का आला, पार्श्वभूमी, आणि 3-tier build मध्ये तो कुठे बसतो ते आहे.

Windows key permissions म्हणजे chmod 400

हा विषय का आला. Windows वरून JumpServer ला SSH "UNPROTECTED PRIVATE KEY FILE" ने fail झालं (Part F).

पार्श्वभूमी. Private key तुम्ही कोण आहात ते सिद्ध करते, म्हणून computer चे इतर users copy करू शकतील अशी key OpenSSH वापरत नाही. Linux आणि Mac वर chmod 400 ने बाकी सगळ्यांचा access काढता (owner read, group 0, others 0). Windows मध्ये chmod नाही; तिथे files ना folder कडून inherit झालेल्या access lists (ACLs) असतात. Inheritance disable करणं, inherited entries काढणं आणि फक्त तुमच्या user ला Read देणं म्हणजे तोच 400, Windows च्या भाषेत. Command line वरून icacls file /inheritance:r /grant:r "%USERNAME%:R" तेच करतो.

3-tier build शी संबंध. या build मधला प्रत्येक server (JumpServer, दोन्ही dev servers, आणि debug कराल तो कुठलाही Auto Scaling server) एकाच ThreeTierKey.pem ने उघडतो, म्हणून हा fix प्रत्येक computer वर एकदाच लागतो.

Console "NetworkError" आणि session timeouts

हा विषय का आला. Build च्या मध्येच Auto Scaling groups किंवा Create database सारख्या pages वर "NetworkError when attempting to fetch resource" किंवा "Failed to load" आलं.

पार्श्वभूमी. Console हा browser मधून AWS APIs call करणारा web app आहे. एखादा call fail झाला (Wi-Fi गेलं, VPN, browser extension, किंवा sign-in session expire झालं; sign in कसं केलं त्याप्रमाणे console sessions 1 ते 12 तासांनी संपतात), तर page हा error दाखवतो. तुमच्या resources ना काही होत नाही. Page reload करा, विचारलं तर परत sign in करा, आणि परत Create click करण्याआधी list बघा, म्हणजे तीच गोष्ट दोनदा बनणार नाही.

3-tier build शी संबंध. या build मध्ये लांब wizards आहेत (RDS, दोन Auto Scaling groups). Create click केल्यावर error आला तर step परत करण्याआधी resource बनलाय का ते check करा; दुसरा RDS instance किंवा Auto Scaling group म्हणजे दुप्पट खर्च.

vCPU quota errors

हा विषय का आला. दोन्ही Auto Scaling groups चालू असताना nginx development server launch "You have requested more vCPU capacity than your current vCPU limit" ने fail झाला.

पार्श्वभूमी. प्रत्येक account ला Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances नावाचा Service Quota असतो, जो Region नुसार vCPUs मध्ये मोजला जातो, instances मध्ये नाही. नवीन accounts बहुतेक कमी limit ने सुरू होतात. t3.micro ला 2 vCPUs, म्हणून 16 ची limit 8 servers मध्ये संपते. Worked example: दोन groups त्यांच्या max 4 वर = 8 servers = 16 vCPUs, अधिक JumpServer (2) आणि dev server (2) = 20. उपाय: नको असलेले servers terminate करा, शिकताना Max कमी ठेवा, किंवा Service Quotas > AWS services > Amazon EC2 > Running On-Demand Standard … > Request increase at account level उघडा; approval ला काही तास ते दिवस लागू शकतात.

3-tier build शी संबंध. दोन Auto Scaling groups असलेला 3-tier build हा एकाच वेळी अनेक servers चालवणारा पहिला lab आहे, आणि scale out करायला quota मध्ये जागा लागते: launch करू न शकणारा group heal किंवा scale करू शकत नाही.

प्रत्येक AZ मध्ये प्रत्येक instance type मिळत नाही

हा विषय का आला. Auto Scaling group साठी subnets निवडताना एखादा AZ "not supported in the requested Availability Zone" म्हणून instance type नाकारू शकतो.

पार्श्वभूमी. प्रत्येक AZ चं स्वतःचं hardware असतं, आणि नवीन किंवा special families प्रत्येक AZ मध्ये नसतात. Build करण्याआधी check करा: EC2 > Instance types > type select करा > Networking AZs दाखवतं, किंवा aws ec2 describe-instance-type-offerings --location-type availability-zone --filters Name=instance-type,Values=t3.micro चालवा. याच्यापेक्षा वेगळं, एखाद्या AZ मध्ये एखाद्या type ची capacity तात्पुरती संपू शकते ("InsufficientInstanceCapacity"), आणि हेच Balanced best effort हाताळतो.

3-tier build शी संबंध. High availability ला दोन्ही AZs मध्ये तोच instance type लागतो. एकाच AZ मध्ये मिळणारा type दोन-AZ design ला शांतपणे एक-AZ design बनवतो.

Load balancer कडून 502, 503 आणि 504

हा विषय का आला. Tiers जोडताना कधी ना कधी हे प्रत्येक आले, आणि प्रत्येक वेगळ्या तुटलेल्या कडीकडे बोट दाखवतो.

पार्श्वभूमी. Code तुम्हाला कुठे बघायचं ते सांगतो:

अजून एक नियम: प्रत्येक target unhealthy असेल तर ALB "fail open" होतो आणि तरीही सगळ्यांना traffic पाठवतो, म्हणजे console सगळे targets Unhealthy दाखवत असताना page कदाचित load होईल (किंवा विचित्रपणे fail होईल). Health check दुरुस्त करा; यावर अवलंबून राहू नका.

3-tier build शी संबंध. या build मध्ये दोन load balancers आणि चार hops आहेत. आधी code वाचला की सगळं बदलण्याऐवजी कुठला hop check करायचा ते कळतं.

कुठले servers बदलायचे ते health checks ठरवतात

हा विषय का आला. Self-healing test मध्ये terminate केलेला web server आपोआप परत आला, आणि services enable न करता bake केलेले servers परत परत बदलले जात होते.

पार्श्वभूमी. Target group प्रत्येक server ला दर 5 seconds ला check करतो; 2 failures नंतर तो server Unhealthy ठरवतो आणि त्याला traffic पाठवणं बंद करतो. Auto Scaling group ELB health checks वापरतो म्हणून, 60-second grace period नंतर, तो तो server terminate करतो आणि launch template वरून नवा launch करतो. AMI च बिघडली असेल तर प्रत्येक replacement तसाच fail होतो आणि Activity मध्ये launches आणि terminations चं loop दिसतं; उपाय म्हणजे नवी AMI आणि template version, server हाताने दुरुस्त करणं कधीच नाही.

3-tier build शी संबंध. म्हणूनच /health.php फक्त PHP test करतो आणि bake करण्याआधी services enable पाहिजेत: health check च बिघडलेल्या server ला नव्या server मध्ये बदलतो.

"Server Not Found" म्हणजे तुमच्या बाजूचा DNS problem

हा विषय का आला. www CNAME add केल्यावर browser "Server Not Found" (Firefox) किंवा "This site can't be reached / DNS_PROBE_FINISHED_NXDOMAIN" (Chrome) दाखवू शकतो.

पार्श्वभूमी. या messages चा अर्थ browser ला नावाचा IP address करता आला नाही, किंवा connect च करता आलं नाही, म्हणजे request AWS पर्यंत पोहोचलीच नाही. Security groups, target groups आणि nginx चा इथे संबंध नाही. Record check करा (Name www, Value ELB name, http:// नाही), TTL संपेपर्यंत थांबा, nslookup www.yourdomain.com चालवा, आणि दुसरं network किंवा 8.8.8.8 सारखा public DNS server try करा. तुलना: 502/503/504 page म्हणजे request load balancer पर्यंत नक्की पोहोचली.

3-tier build शी संबंध. ही साखळीतली शेवटची कडी, WebTierPublicALB च्याही वर. Problem AWS च्या कुठल्या बाजूला आहे ते कळलं की चालणारे security groups बदलायची वेळ येत नाही.

EC2 Instance Connect ला पण port 22 लागतो

हा विषय का आला. Connect > EC2 Instance Connect ने browser मधून connect करणं Windows वरच्या SSH पेक्षा सोपं, पण ज्या servers चा security group फक्त My IP कडून SSH allow करतो तिथे ते fail झालं.

पार्श्वभूमी. EC2 Instance Connect एक one-time key पाठवतो आणि मग तुमच्या laptop वरून नाही तर AWS च्या स्वतःच्या address range मधून instance ला SSH उघडतो. म्हणून security group ला managed prefix list com.amazonaws.ap-northeast-2.ec2-instance-connect कडून port 22 लागतो (Source box मध्ये निवडा), आणि instance ला public IP लागतो. Private servers साठी EC2 Instance Connect Endpoint किंवा JumpServer वापरा.

3-tier build शी संबंध. JumpSG आणि DevSG फक्त My IP कडून SSH allow करतात. Browser आवडत असेल तरच prefix-list rule add करा, आणि Part K मध्ये बाकीच्या setup rules सोबत काढून टाका.

या build मध्ये NAT gateway का नाही

हा विषय का आला. AWS मध्ये VPC, NAT Gateway आणि RDS वापरून 3-Tier Architecture कसं बनवायचं मध्ये private app server ला software install करता यावं म्हणून NAT gateway वापरला. इथे private servers कधीच काही install करत नाहीत.

पार्श्वभूमी. NAT gateway private servers ना फक्त outbound internet access देतो, आणि त्याचं bill दर तासाला अधिक प्रति GB होतं. या build मध्ये सगळं software public subnet मधल्या development servers वर install होतं आणि AMIs मध्ये bake होतं, म्हणून web आणि app servers तयार boot होतात आणि त्यांना outbound access लागत नाही. Private servers ना internet पर्यंत जायचंच असेल, उदा. updates download करायला किंवा बाहेरचा API call करायला, तरच NAT gateway add करा.

3-tier build शी संबंध. Immutable AMIs (section 4) मुळेच NAT gateway optional होतो, आणि app चालतो त्या प्रत्येक तासाचे पैसे वाचतात.

Cleanup, म्हणजे काहीही bill करत राहणार नाही

हा विषय का आला. Part M testing नंतर लगेच सगळं ठराविक क्रमाने delete करतो.

पार्श्वभूमी. Load balancers आणि RDS कुणी वापरो वा न वापरो, दर तासाला bill करतात; public IPv4 addresses दर तासाला bill करतात; AMIs मागचे EBS snapshots प्रति GB-month bill करतात. क्रम महत्त्वाचा कारण AWS dependencies जपतं: आधी Auto Scaling groups (नाहीतर ते servers परत launch करतात), मग load balancers आणि target groups, मग RDS, instances, AMIs आणि snapshots, templates आणि DB subnet group, आणि VPC सगळ्यात शेवटी. नंतर दुसऱ्या दिवशी Billing and Cost Management > Bills check करा, आणि AWS Budgets alert set करा, उदा. 5 USD वर.

3-tier build शी संबंध. 3-tier build हा आत्तापर्यंतचा सगळ्यात महाग lab आहे कारण तो दोन load balancers, एक database आणि सहा किंवा जास्त servers एकाच वेळी चालवतो.

11. Troubleshooting checklist

साखळीच्या वरून खाली जा. प्रत्येक row म्हणजे एक कडी.

12. पूर्ण class एका page वर

1. का: एक server म्हणजे failure चा एक point; दोन AZs, load balancers आणि Auto Scaling मुळे high availability, fault tolerance आणि self-healing मिळतं.
2. Design: users → internet-facing ALB (public subnets) → nginx (Web subnets) → internal ALB → PHP (App subnets) → RDS (DB subnets).
3. क्रम: खालून वर build करा (network, database, app, web) म्हणजे प्रत्येक tier त्याच्या खालच्या चालणाऱ्या tier सोबत test होतो; security rules वरून खाली लिहा.
4. Network: ThreeTierVpc 10.0.0.0/16, आठ /20 subnets (प्रत्येकी 4,096 addresses), एक IGW, आणि फक्त दोन public subnets वापरतात असं public route table.
5. Security groups: WebAlbSG (कुठूनही 80) → WebEc2SG (WebAlbSG कडून 80) → AppAlbSG (WebEc2SG कडून 80) → AppEc2SG (AppAlbSG कडून 80) → DbSG (AppEc2SG कडून 3306). 3306 कधीच 0.0.0.0/0 ला उघडा नाही.
6. Database: दोन DB subnets चा DB subnet group; public access नसलेला RDS MySQL; एक database insta, hashes साठी password varchar(255) असलेला table users.
7. Servers: development server वर install करा, services enable करा, test करा, AMI bake करा (phpami, webami); servers बदलले जातात, patch कधीच नाही.
8. Scaling: subnet नसलेले launch templates; Balanced best effort, desired 2 / min 1 / max 4, 20% CPU वर target tracking, ELB health checks असलेले Auto Scaling groups.
9. Load balancers: wizard नंतर प्रत्येक ALB चा स्वतःचा security group set करा; health checks /health.php आणि /forms.html.
10. बदल: नवीन template version → group Latest वर → instance refresh.
11. Errors: Server Not Found = DNS; 502 = target ने नाकारलं; 503 = targets नाहीत; 504 = timeout, बहुतेक security group.
12. Cleanup क्रमाने करा, आणि budget alert ठेवा.

या build मागच्या concepts साठी AWS मध्ये VPC, NAT Gateway आणि RDS वापरून 3-Tier Architecture कसं बनवायचं कडे परत जा.

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

Recap

झटपट उजळणी cards

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

अजून cards: Ravi Sir's Cards: AWS VPC and Subnets.