Root user, IAM users, MFA आणि तुमचा पहिला EC2 server launch करणं

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

1. Practice का महत्त्वाची

का. AWS वरचे शंभर videos बघा, तरी console मध्ये error आला की हात थांबतात. Errors च खरं शिकवतात. आणि errors फक्त तुम्ही स्वतः steps केल्या तरच येतात.

काय. प्रत्येक student चं स्वतःचं AWS account पाहिजे. मित्राचं account नाही, trainer ची screen नाही.

कसं.

1. आजच स्वतःच्या email address ने AWS account उघडा.
2. एक वही ठेवा. प्रत्येक error आणि त्याचा fix त्यात लिहा.
3. या chapter ची प्रत्येक step त्याच दिवशी स्वतःच्या account मध्ये करा.

उदाहरण: एक demo का पुरत नाही.

1. समजा trainer ने 1 server launch केलेला तुम्ही बघितला.
2. तोच server तुम्ही स्वतः 5 वेळा, 5 वेगवेगळ्या दिवशी launch केला.
3. दिवस 2 ला key pair विसरलात. दिवस 4 ला चुकीचा Region निवडला आणि server सापडेना.
4. म्हणजे 2 खरे errors, जे तुम्ही स्वतः सोडवले. Interview मध्ये या 2 गोष्टी, बघितलेल्या 1 demo पेक्षा जास्त कामाच्या.

2. Console चा sign-in screen

का. कुठलाही server बनवायच्या आधी तुम्हाला AWS Management Console मध्ये जावं लागतं. ही ती website जिथे click करून गोष्टी बनवतो.

काय. "AWS management console sign in" search करा, किंवा https://console.aws.amazon.com/ उघडा. Board वर screen असा दाखवला:

1. IAM user name साठी एक box.
2. Password साठी एक box.
3. Sign in button.
4. एक link: Sign in using root user email.

Board वर न दाखवलेला अजून एक box असतो: IAM user ला account ID किंवा account alias पण लागतो, म्हणजे तो user name कुठल्या account चा ते AWS ला कळतं. Browser बहुतेक वेळा तो लक्षात ठेवतो, म्हणून कधी कधी दिसत नाही. दोन्ही screens section 8 मध्ये बघू.

कसं (पहिल्यांदा, नवीन account सोबत).

1. Console चं sign-in page उघडा.
2. Sign in using root user email वर click करा (काही screens वर: Root user निवडा).
3. Sign up करताना दिलेला email टाका, मग password.
4. AWS विचारेल तेव्हा MFA set करा (section 9). AWS आता root user साठी MFA compulsory करतं.

3. Root user आणि IAM user: कोण कोण

का. एक AWS account बऱ्याचदा खूप लोक वापरतात. "मालक" आणि "account मध्ये काम करणारे लोक" यांच्यात फरक करायला AWS ला काहीतरी पाहिजे.

काय.

1. Root user म्हणजे account उघडताना email address आणि password ने (आणि AWS विचारेल तेव्हा payment method ने) तयार होणारी identity. Account मधल्या सगळ्या गोष्टींवर पूर्ण access असतो, आणि त्याला कोणी limit करू शकत नाही.
2. IAM user म्हणजे account च्या आत बनवलेला वेगळा login. IAM म्हणजे Identity and Access Management. IAM user ला जेवढी परवानगी दिली तेवढंच तो करू शकतो.
3. IAM user ला स्वतःचा email address लागत नाही. Admin एक user name ठरवतो, उदा. satish.

Board चं उदाहरण (समजा). समजा एक मोठं social media app AWS वर चालतं. लाखो servers, हजारो employees. समजा त्याचा founder, Mark, याने r@b.com या email ने AWS account उघडलं. (हे फक्त शिकण्यासाठी "समजा" उदाहरण आहे. कुठली खरी company अशी चालते असं आपण म्हणत नाही.)

1. r@b.com हा root user. तो म्हणजे Mark, मालक.
2. Mark root म्हणून sign in करतो, स्वतःसाठी full admin rights असलेला mark नावाचा IAM user बनवतो, आणि root मधून sign out करतो.
3. बाकी सगळ्यांना (developers, testers, support चे लोक) IAM user मिळतो. Root चा email आणि password इतर कोणालाच मिळत नाही.

4. Least privilege: प्रत्येकाला फक्त गरजेपुरतं

का. Login कडे जितकी जास्त power, तितकं जास्त नुकसान एखादी चूक किंवा चोर करू शकतो. म्हणून प्रत्येकाला त्याच्या कामापुरत्याच permissions द्यायच्या. याला म्हणतात least privilege.

काय काय control करता येतं? AWS कडे 200 पेक्षा जास्त services आहेत. Board वर आपण त्यातल्या पाच वापरल्या:

आणि class मधला अजून एक शब्द: AMI (Amazon Machine Image) म्हणजे ज्यावरून server launch होतो ते template: operating system आणि जे software असेल ते. ते "backup" नाही. Disk चे backups म्हणजे snapshots.

उदाहरण: board वरचं account (समजा numbers).

1. समजा account मध्ये 100 EC2 servers, 20 S3 buckets आणि 10 databases आहेत.
2. IAM user satish ला परवानगी: जास्तीत जास्त 10 EC2 servers start आणि stop करणं. परवानगी नाही: servers delete करणं, कुठलाही database उघडणं.
3. satish ने server delete करायचा प्रयत्न केला, तर AWS उत्तर देतं Access denied.
4. 100 + 20 + 10 = 130 resources पैकी satish फक्त 10 ला हात लावू शकतो. म्हणजे account च्या 10 ÷ 130 ≈ 7.7%.

Data ला सगळ्यात कडक नियम का. बऱ्याच companies साठी database हीच सगळ्यात मौल्यवान गोष्ट: customers, orders, payments.

1. समजा एखाद्या competitor ने एका employee ला customer database च्या copy साठी 10 कोटी रुपये offer केले.
2. 500 employees database वाचू शकत असतील, तर एखाद्याचा निर्णय चुकायच्या 500 शक्यता.
3. फक्त 3 विश्वासू लोक वाचू शकत असतील, तर 3 शक्यता. म्हणजे 500 ÷ 3 ≈ 167 पट कमी.
4. म्हणून database चा access फक्त 2 किंवा 3 विश्वासू लोकांनाच.

अजून limits: वेळ आणि जागा. बऱ्याच companies लोक कधी आणि कुठून काम करू शकतात यावरही limit घालतात:

1. वेळ: फक्त सकाळी 9 ते संध्याकाळी 6.
2. जागा: फक्त office network वरून (office चा public IP address) किंवा company च्या laptop वरून.

AWS मध्ये IAM policies हे conditions ने करू शकतात, उदा. aws:SourceIp (request कुठल्या IP address वरून आली) आणि aws:CurrentTime (request कधी आली).

5. Accountability: 1000 लोकांनी एकच login का वापरू नये

का. कधीतरी काहीतरी बिघडणार. तेव्हा company ला एका प्रश्नाचं उत्तर देता आलं पाहिजे: हे कोणी केलं?

Board वरचा प्रश्न. समजा 1000 लोक एकाच root email आणि password ने sign in करतात. एका सकाळी 1000 servers delete झाले.

Class ने चार उत्तरं try केली:

1. वेळ. सगळे 9:00 ते 9:15 मध्ये sign in करतात. Delete 9:07 ला झालं. हे 1000 जणांना लागू पडतं.
2. IP address. सगळे एकाच office मधून काम करतात, म्हणून AWS ला 1000 जणांचा एकच office public IP दिसतो.
3. MAC address. हे तर अजिबात चालत नाही. MAC address तुमच्या local network मध्येच राहतो; internet वरून AWS पर्यंत पोचतच नाही.
4. Logs. AWS actions चा record ठेवतं (AWS CloudTrail). पण प्रत्येक line मध्ये एकच नाव: root.

निकाल: 4 उत्तरं, 0 नावं.

काय. प्रत्येकाला स्वतःचा IAM user द्या. आता प्रत्येक action सोबत नाव येतं.

उदाहरण.

1. तेच 1000 लोक, पण प्रत्येकाचा स्वतःचा IAM user.
2. Record दाखवतो: 09:07, user satish, terminate instances, ×1000.
3. आता वेळ, IP, log वरून अंदाज लावायची गरजच नाही. नाव record मध्ये आहे.
4. 1000 संशयित → 1 माणूस, ज्याला उत्तर द्यावं लागेल.

6. Mark चा setup: root एकदाच, मग सगळ्यांना IAM users

का. आता sections 3 ते 5 एकत्र करून कामाचा खरा क्रम लावूया.

कसं (board वरच्या steps).

1. Mark r@b.com ने account उघडतो. हा root user.
2. Mark root म्हणून sign in करतो, रोजच्या कामासाठी शक्यतो हे एकदाच, आणि root साठी MFA चालू करतो.
3. Mark full admin rights असलेला IAM user mark बनवतो (AWS managed policy AdministratorAccess).
4. Mark root मधून sign out करतो आणि IAM user mark म्हणून sign in करतो.
5. mark म्हणून तो employees साठी IAM users बनवतो: satish, mahesh, ravi, raja, rani.
6. प्रत्येकासाठी पहिला password ठेवतो आणि "User must create a new password at next sign-in" वर tick करतो.
7. प्रत्येक employee ला तीन गोष्टी पाठवतो: account ची console sign-in link, user name, आणि पहिला password.
8. पहिल्या sign-in ला प्रत्येक employee ला नवीन password ठेवावाच लागतो. आता तो password फक्त employee लाच माहित.

Password बदलायला का लावायचा? परत accountability.

1. समजा Mark ने satish चा password ठेवला आणि satish ने तो कधी बदललाच नाही.
2. आता satish चा password 2 लोकांना माहित: satish आणि Mark.
3. Satish च्या login वरून server delete झाला, तर satish म्हणू शकतो "Mark ने केलं असेल". उलट कोणी सिद्ध करू शकत नाही.
4. Password बदलल्यानंतर तो फक्त 1 माणसाला माहित. Login, आणि action, फक्त satish चे.

Root अजून कधी लागतो? काही कामं फक्त root च करू शकतो, अशी AWS ची list आहे. नेहमीच्या account साठी, उदा.: root चा email किंवा password बदलणं, account बंद करणं, आणि एकुलत्या एक admin ने स्वतःलाच lock केलं तर permissions परत देणं. बाकी सगळ्यासाठी IAM user वापरा.

7. Root रोज का वापरायचा नाही, आणि IAM चं safety net

का. Root सगळं करू शकतो, account चा email आणि phone बदलणं सुद्धा. चोराच्या हातात root गेला, तर account तुमचं राहत नाही.

Board वरची गोष्ट: एक निष्काळजी click.

1. Mark रोज root वापरतो.
2. एक दिवस browser विचारतो "Save password?" आणि चुकून तो Save दाबतो.
3. नंतर laptop मध्ये malware, एखादं वाईट browser extension किंवा keylogger येतो. तो saved password वाचतो.
4. Hacker root म्हणून sign in करतो आणि root password बदलतो.
5. Hacker servers आणि databases delete करतो.
6. Hacker account चा email आणि phone number बदलतो.
7. Bank account वरचा nominee कोणीतरी बदलावा तसं, आता recovery चे messages hacker कडे जातात. Account तुमचं आहे हे सिद्ध करणं खूप अवघड आणि खूप वेळखाऊ होतं.

Safety net. आता समजा Mark ने section 6 प्रमाणे केलं आणि रोज IAM user mark म्हणून काम करतो.

1. तोच malware IAM user mark चा password चोरतो.
2. Hacker mark म्हणून sign in करून delete करायला लागतो.
3. Mark root म्हणून sign in करतो (email + password + MFA). हे hacker कडे नाही.
4. Root म्हणून Mark IAM user mark delete किंवा disable करतो. Hacker लगेच बाहेर.
5. Mark नवीन admin IAM user बनवतो आणि passwords बदलतो.

उदाहरण: किल्ल्या मोजा.

1. Root रोज वापरला तर: चोराला 1 च गोष्ट लागते, saved root password. तो गेला, account गेलं.
2. रोज IAM आणि root MFA सोबत बाजूला ठेवला तर: चोराला root email + root password + तुमचा MFA device लागतो. म्हणजे 3 गोष्टी, आणि root password browser मध्ये कधी save झालाच नव्हता.

8. Company मध्ये IAM मिळतो, root नाही; आणि दोघांचं sign in कसं

का. Company join केल्यावर तुम्हाला कोणी root login देणार नाही. IAM user म्हणून sign in करता आलं पाहिजे.

Class मध्ये. शिकताना, स्वतःच्या account मध्ये, पहिले काही दिवस तुम्ही MFA चालू ठेवून root म्हणून sign in कराल. जरा सवय झाली की स्वतःसाठी admin IAM user बनवा आणि तोच वापरा.

काय. Sign in चे दोन रस्ते:

Sign-in link. Admin बहुतेक वेळा IAM users ना अशी link पाठवतात ज्यात account आधीच असतो: https://<account-ID-or-alias>.signin.aws.amazon.com/console. या link ने account ID चा box आपोआप भरलेला येतो.

9. MFA: तीन प्रकार

का. फक्त password चोरीला जाऊ शकतो (section 7). MFA (multi-factor authentication) दुसरा पुरावा जोडतो: तुमच्याकडे असलेली गोष्ट, जसा तुमचा phone किंवा छोटी key. फक्त password असलेला चोर तरीही sign in करू शकत नाही.

काय. AWS आता root user साठी MFA compulsory करतं. प्रत्येक IAM user साठी पण तो चालू करता येतो. प्रत्येक user 8 पर्यंत MFA devices register करू शकतो. Board वर तीन प्रकार होते:

प्रकार 1. Passkeys आणि security keys.

1. Passkey तुमच्या phone च्या किंवा laptop च्या password manager मध्ये राहते (Apple, Google, Microsoft वगैरे). Fingerprint, face किंवा PIN ने ती unlock होते. Laptop वर sign in करायला phone ने QR code scan करूनही चालतं.
2. Security key म्हणजे pen drive एवढा छोटा physical device, जो लावायचा किंवा tap करायचा.
3. AWS हेच आधी recommend करतं: हे phishing-resistant आहेत, म्हणजे खोटं login page त्यांना फसवू शकत नाही.

Security keys च्या किमती model आणि seller प्रमाणे खूप बदलतात; घेण्याआधी नीट बघा.

प्रकार 2. Authenticator app (virtual MFA).

1. Authenticator app install करा, उदा. Google Authenticator किंवा Microsoft Authenticator.
2. AWS मध्ये authenticator app निवडा, आणि app ने QR code scan करा.
3. आता app मध्ये 6 आकडी code दिसतो, जो दर 30 seconds ला बदलतो. Sign in करताना चालू code टाका.

प्रकार 3. Hardware TOTP token. Digital घड्याळ किंवा key-ring सारखा दिसणारा छोटा device. त्याच्या स्वतःच्या screen वर 6 आकडी code दिसतो. AWS फक्त AWS च्या MFA page वरच्या links वरून घेतलेले tokens च चालवतं, कारण AWS ला प्रत्येक token चं secret माहित असावं लागतं.

Internet शिवाय code येतो कसा? Board वर हाच भाग चुकला होता.

1. QR code scan केला की app आणि AWS दोघंही तोच secret seed ठेवतात. (Hardware token ला seed factory मध्येच मिळतो, आणि AWS कडे त्याची copy असते.)
2. दर 30 seconds ला app seed + चालू वेळ घेऊन TOTP (time-based one-time password) नावाचा ठरलेला formula चालवतो.
3. AWS तोच formula, तोच seed आणि तीच वेळ घेऊन चालवतं.
4. तोच seed + तीच वेळ = तोच code. तुमचा code जुळला, की तुम्ही आत.
5. Satellite नाही, internet नाही, SMS नाही. Token पूर्णपणे offline चालतो.

उदाहरण: अंदाजाने का जमत नाही.

1. 6 आकडी code च्या 10 × 10 × 10 × 10 × 10 × 10 = 10,00,000 (10 लाख) शक्यता.
2. दर 30 seconds ला नवीन code, म्हणजे एका दिवसात 24 × 60 × 60 ÷ 30 = 2,880 codes.
3. एकदा अंदाज लावणाऱ्या चोराला 10 लाखात 1 chance, आणि 30 seconds नंतर तो code कामाचाच नाही.

SMS OTP का नको?

1. Phone वरची इतर apps कधी कधी येणारे SMS codes वाचू शकतात.
2. SIM swap मध्ये गुन्हेगार तुमचा number नवीन SIM वर हलवून घेतो आणि तुमचे SMS त्याला मिळतात.
3. AWS आता SMS MFA चालूच करू देत नाही. वरच्या तीनपैकी एक प्रकार वापरा.

10. कोणता MFA निवडायचा, आणि backup ठेवणं

का. MFA तेव्हाच वाचवतो जेव्हा तो हरवत नाही. Backup नसलेला phone हरवला तर तुम्हीच बाहेर अडकू शकता.

काय. तिघांची तुलना:

कसं (class ने सांगितलं ते, सुरक्षित करून).

1. Practice account साठी authenticator app पुरेसं आणि free आहे.
2. App चं backup किंवा sync चालू करा (उदा. Google Authenticator तुमच्या Google account मध्ये signed in), म्हणजे नवीन phone वर codes परत येतात.
3. अजून चांगलं: 2 devices register करा, उदा. phone वर app + laptop वर passkey. एक हरवला तर दुसऱ्याने sign in करा.
4. Hardware token online attacks पासून खूप safe आहे, पण तो physically चोरीला जाऊ शकतो. कुलूपबंद ठेवा.

11. MFA device हरवला? परत आत कसं यायचं

का. Phones फुटतात, हरवतात. प्लॅन हे होण्याआधी तयार पाहिजे.

Root user (AWS च्याच steps).

1. Email आणि password ने root म्हणून sign in करा.
2. MFA page वर Troubleshoot MFA निवडा (कधी "Troubleshoot your authentication device" असं दिसतं).
3. Sign in using alternative factors निवडा.
4. तुमचा email verify करा: AWS एक message पाठवतं; त्यातल्या link वर click करा.
5. तुमचा phone verify करा: AWS account च्या primary contact number वर call करतं; screen वर दिसणारा 6 आकडी number phone च्या keypad वर टाका.
6. तुम्ही आत. जुना MFA device काढा आणि नवीन जोडा.
7. Device चोरीला गेला असेल तर root password पण बदला.

Email किंवा phone call मिळतच नसेल, तर मग AWS Support ला contact करा.

IAM user.

1. स्वतःचा MFA तुम्ही reset करू शकत नाही.
2. तुमच्या admin ला सांगा (ज्याने user name दिला तो). Admin तुमचा जुना device deactivate करतो.
3. Sign in करा आणि नवीन device register करा.

उदाहरण: 2 devices कसे वाचवतात.

1. तुम्ही 2 MFA devices register केले: phone app + laptop passkey.
2. Phone हरवला. Passkey ने sign in: 1 minute.
3. फक्त 1 device असता तर email check + phone call लागला असता, आणि phone number हरवलेल्या phone च्या SIM वरच असेल तर आधी नवीन SIM ची वाट बघावी लागली असती.

12. तुमचा account ID

का. प्रत्येक AWS account चा एक unique number असतो. IAM users ना sign in करायला तो लागतो, आणि AWS Support पण तो विचारतं.

काय.

1. Account ID हा 12 आकडी number असतो, उदा. AWS चा स्वतःचा sample 111122223333.
2. तो console मध्ये वर उजवीकडे account menu मध्ये दिसतो.
3. Account alias म्हणजे त्याऐवजी ठेवता येणारं सोपं नाव, जे sign-in link मध्ये वापरलं जातं.

उदाहरण. 12 आकड्यांमध्ये 10¹² = 1,000,000,000,000 (एक लाख कोटी) IDs बसतात. खूप accounts साठी जागा आहे.

13. Free plan आणि $200 चे credits

का. Surprise bill शिवाय शिकायचं आहे. AWS चा Free Tier July 2025 मध्ये बदलला, म्हणून जुने blogs आणि videos चुकीचे आहेत. AWS च्या स्वतःच्या pages वर आज काय आहे ते हे (October 2026 ला check केलं).

काय (15 July 2025 किंवा नंतर बनलेली accounts).

1. Sign up करताच $100 credits.
2. अजून $100 पर्यंत: Console Home page वरच्या "Explore AWS" box मधल्या 5 activities पैकी प्रत्येकी $20:
   1. Amazon EC2 ने instance launch करा.
   2. AWS Budgets ने cost budget set करा.
   3. Amazon Bedrock playground मध्ये foundation model वापरा.
   4. AWS Lambda ने web app बनवा.
   5. Amazon RDS database बनवा.
3. Sign up करताना Free plan किंवा Paid plan निवडता.
4. Free plan वर तुम्हाला charge होत नाही. तो जास्तीत जास्त 6 महिने चालतो, किंवा credits संपेपर्यंत, जे आधी होईल ते. मग account बंद होतं; AWS तुमचा data 90 दिवस ठेवतं, आणि त्या काळात Paid plan वर upgrade करून पुढे चालू ठेवता येतं.
5. Credits usage साठी वापरले जातात. Cash म्हणून काढता येत नाहीत, दुसऱ्या account मध्ये हलवता येत नाहीत.
6. Credits फक्त नवीन customers ना. तुमचं आधीच AWS account असेल, किंवा कधी होतं, तर तुम्ही eligible नाही. आणि प्रत्येक AWS account ला स्वतःचा वेगळा email address लागतो.

उदाहरण 1: credits ची बेरीज.

1. Sign-up credit: $100.
2. 3 activities पूर्ण केल्या (EC2, budget, RDS): 3 × $20 = $60.
3. आतापर्यंत: $100 + $60 = $160.
4. उरलेल्या 2 पूर्ण केल्या: + 2 × $20 = $40. एकूण $200.

उदाहरण 2: एका छोट्या server ला $100 किती दिवस पुरतात? (N. Virginia मध्ये t3.micro ची AWS ची on-demand Linux किंमत, October 2026: $0.0104 प्रति तास.)

1. एक महिना ≈ 30 दिवस × 24 तास = 720 तास.
2. 720 × $0.0104 = $7.488 प्रति महिना, server सतत चालू ठेवला तर.
3. सहा महिने: 6 × $7.488 = $44.93.
4. म्हणजे $100 मध्ये एक छोटा server पूर्ण 6 महिने चालतो, आणि disks आणि practice साठी पैसे उरतात. (Disks आणि इतर services चे पैसे वेगळे लागतात, म्हणून Billing console नेहमी बघा.)

14. Console मधले Regions, आणि opt-in Region enable करणं

का. Console च्या वर उजवीकडे जो Region निवडलेला असेल, तिथेच तुमचा server launch होतो. चुकीचा निवडला की server "हरवतो".

काय. Class मधला isolation चा demo:

1. Region menu मध्ये US West (Oregon) होतं. आत्ता launch केलेला server Oregon च्या data center मध्ये बसला असता.
2. Asia Pacific (Mumbai) ap-south-1 वर switch करा: Instances page वर फक्त Mumbai चे servers दिसतात.
3. US East (N. Virginia) us-east-1 वर switch करा: वेगळीच list.
4. Servers गायब झाले नाहीत. प्रत्येक Region फक्त स्वतःचे resources दाखवतो. Regions isolated असतात.

उदाहरण.

1. तुम्ही Mumbai मध्ये 2 आणि N. Virginia मध्ये 1 server launch केले.
2. Region = Mumbai: list मध्ये 2.
3. Region = N. Virginia: list मध्ये 1.
4. Bill मध्ये मात्र तिन्ही, 3 (section 15).

Default आणि opt-in Regions. AWS ने 20 March 2019 नंतर launch केलेले Regions opt-in आहेत: तुम्ही enable करेपर्यंत ते बंद असतात. Class मध्ये table वर Cape Town, Hyderabad आणि Melbourne Disabled होते, आणि जुने Regions Enabled by default.

Enable कसा करायचा.

1. वर उजवीकडे तुमच्या account नावावर click करा.
2. Account निवडा (ते Billing and Cost Management मध्ये उघडतं).
3. खाली AWS Regions पर्यंत scroll करा.
4. Region निवडा, उदा. Asia Pacific (Hyderabad), आणि Enable दाबा.
5. थांबा: बहुतेक वेळा काही minutes, कधी कधी काही तास. Enable करणं free आहे.

15. एकच global bill, नंतर भरायचं: budget alert लावा

का. AWS post-paid आहे: आधी वापरा, मग भरा. विसरलेला server दर तासाला bill वाढवत राहतो.

काय.

1. Billing console मध्ये Global दिसतं: सगळ्या Regions चं मिळून एकच bill.
2. AWS दर महिन्याला bill करतं. Bill तुमच्या payment method वर जातं.
3. Bill भरलं नाही तर AWS account suspend करू शकतं: तुमच्या servers आणि data चा access जातो. AWS च्या help page प्रमाणे suspension नंतर 30 दिवसांत थकबाकी भरावी लागते, नाहीतर AWS account बंद करतं; post-closure काळ संपला की content delete होतो. Agreement प्रमाणे उशिरा भरलेल्या पैशावर व्याजही लागू शकतं. पैसे तर देणंच लागतात.

कसं: budget alert बनवा (ही पण $20 ची एक activity आहे).

1. Billing and Cost Management → Budgets → Create budget उघडा.
2. Use a template (simplified) → Monthly cost budget निवडा.
3. एक रक्कम टाका, उदा. $5.
4. तुमचा email address टाका.
5. Create budget दाबा. Template ने ठरवलेल्या limits खर्चाने ओलांडल्या की AWS तुम्हाला email करतं.

उदाहरण: विसरलेला server किती पटकन वाढतो.

1. N. Virginia मध्ये एक t3.micro चालू ठेवून विसरलात: $0.0104 प्रति तास.
2. एक दिवस: 24 × $0.0104 = $0.2496.
3. एक महिना: 720 × $0.0104 = $7.488.
4. असे 10 servers महिनाभर विसरलात: 10 × $7.488 = $74.88. $5 चा budget alert पहिल्या काही दिवसांतच तुम्हाला सावध करेल.

16. Practice साठी N. Virginia का, आणि economy of scale

का. Practice साठी जास्त capacity आणि बहुतेक वेळा कमी किमती असलेला Region हवा.

काय. US East (N. Virginia), us-east-1:

1. हा AWS चा पहिला Region, 2006 मध्ये launch झाला.
2. त्यात 6 Availability Zones आहेत, बहुतेक Regions पेक्षा जास्त.
3. त्याच्या किमती बहुतेक वेळा सगळ्यात कमी किमतींपैकी असतात. किमती Region प्रमाणे असतात, म्हणून EC2 pricing page नेहमी बघा.

उदाहरण: खऱ्या किमती, October 2026 (on-demand Linux t3.micro, AWS चा publish केलेला price data).

1. एका server चा महिन्याचा फरक: $8.064 − $7.488 = $0.576.
2. 100 servers साठी: 100 × $0.576 = $57.60 प्रति महिना.
3. शिकण्यासाठी $0.58 काहीच नाही. हजारो servers असलेल्या company साठी हे वाढतं. पण India मध्ये users असलेली company speed साठी तरीही Mumbai निवडू शकते (मागच्या chapter मधली latency आठवा).

Economy of scale. काम जितकं मोठं, तितकी प्रत्येक unit ची किंमत कमी. AWS hardware, वीज आणि network प्रचंड प्रमाणात घेतं, म्हणून प्रत्येक server-hour त्याला स्वस्त पडतो, आणि AWS ने वर्षानुवर्षे अनेक वेळा किमती कमी केल्या आहेत.

Class मधल्या उपमा (सगळी समजा उदाहरणं, कल्पना समजण्यासाठी, खरा किमतींचा इतिहास नाही):

1. Biscuit चा पुडा. समजा 10 रुपयांच्या पुड्यात 100 g होते. Company मोठी झाली, खूप जास्त माल बनवायला लागली, म्हणून प्रति gram खर्च कमी झाला. आता 10 रुपयांत 120 g.
2. Toothpaste. समजा 20 रुपयांच्या tube मध्ये 50 g होते, आणि मोठ्या प्रमाणात त्याच 20 रुपयांत 70 g मिळतात.
3. Dividend. Company जास्त कमावते तेव्हा नफ्यातला थोडा भाग shareholders ना dividend म्हणून देते. Cloud मोठा होतो तेव्हा बचतीतला थोडा भाग customers ना कमी किमतींच्या रूपात देऊ शकतो.
4. Board वरचे numbers. समजा एक server $1.00 प्रति तास होता. मोठ्या प्रमाणात तो $0.70 झाला. प्रति तास बचत: $0.30. 720 तासांसाठी: 720 × $0.30 = $216 प्रति महिना, प्रति server.

17. EC2 = Elastic Compute Cloud

का. AWS मधलं प्रत्येक service चं नाव short form आहे. नाव वाचता आलं की service काय करते ते कळतं.

काय. Film च्या नावासारखं वाचा. Kabhi Khushi Kabhie Gham ला K3G का म्हणतात माहित आहे ना, कारण "K" तीन वेळा येतो? AWS पण तसंच करतं:

1. Elastic Compute Cloud: E + C + C. C दोनदा येतो, म्हणून EC2.
2. Simple Storage Service: S तीनदा, म्हणून S3.

प्रत्येक शब्द:

1. Elastic = rubber band सारखं. ताणलं की वाढतं, सोडलं की परत येतं. Traffic वाढलं, capacity वाढवा. Traffic कमी झालं, कमी करा.
2. Compute = processing, CPU करतो ते काम: 2 + 3 = 5 करणं, image resize करणं, app चालवणं.
3. Cloud = machine तुमच्या टेबलावर नाही, AWS च्या data center मध्ये आहे. तुम्ही ती internet वरून वापरता.

उदाहरण: elastic आकड्यांत (समजा).

1. नेहमीच्या दिवशी तुमच्या site ला 2 servers लागतात.
2. मोठ्या sale मध्ये traffic 5 पट: 2 × 5 = 10 servers.
3. Sale संपल्यावर परत 2.
4. समजा एक server $0.0104 प्रति तास, आणि sale 48 तास चालला. जास्तीचा खर्च: 8 जास्तीचे servers × 48 तास × $0.0104 = $3.99. जास्तीच्या 8 servers चे पैसे फक्त त्या 48 तासांचे.

18. Orange button: click करण्याआधी विचार करा

का. EC2 console मध्ये मुख्य action एक orange button आहे: Launch instance. Launch केलं की पैसे लागू शकणारी गोष्ट सुरू होते.

तिथे कसं पोचायचं.

1. Console च्या search bar मध्ये ec2 टाका, आणि EC2 उघडा.
2. EC2 dashboard उघडतो. Orange Launch instance button शोधा.

Traffic signal ची उपमा. लाल म्हणजे थांबा. हिरवा म्हणजे जा. नारंगी म्हणजे: सावकाश, बघा, विचार करा. AWS मधल्या प्रत्येक orange button कडे असंच बघा.

19. Launch च्या 7 steps

का. Screen बघायच्या आधी आपण विचारलं: server सुरू करायला काय काय लागतं? Students नी सांगितलं: Region, RAM, operating system, storage, security group, key pair. म्हणजे जवळजवळ संपूर्ण launch page. AWS हे 7 भागांत मांडतं (आणि त्याआधी तुम्ही निवडलेला Region).

1. Name and tags
2. AMI: operating system ची image
3. Instance type: किती CPUs आणि किती RAM
4. Key pair: login कसं करणार
5. Network settings: security group (firewall)
6. Storage: disk
7. Number of instances

मग: Launch instance. पुढचे sections एकेक step घेतात.

20. Step 1: Name and tags

का. AWS प्रत्येक server ला i-0123456789abcdef0 सारखा ID देतं. i-0123… वर कुठलं app आणि i-0fed… वर कुठलं, कोणालाच लक्षात राहत नाही.

काय. नाव optional आहे, पण नेहमी द्या. नाव म्हणजे खरं तर एक tag: Name key आणि तुम्ही ठरवलेली value असलेलं label.

कसं.

1. Name and tags मध्ये server काय करतो ते सांगणारं नाव टाका, उदा. my-first-server.
2. Class मध्ये नाव "pehli wali" होतं, म्हणजे "पहिलीवाली". कुठलंही स्पष्ट नाव चालेल.

उदाहरण.

1. समजा company चे 30 servers आहेत: 10 web, 10 app, 10 database.
2. नावं नसतील तर: 30 random IDs. Database servers शोधायला तिसही उघडावे लागतात.
3. web-1 … web-10, app-1 … app-10, db-1 … db-10 अशी नावं असतील, तर db ने filter करा आणि 10 लगेच दिसतात.

21. Step 2: AMI, operating system ची image

का. काहीही करायच्या आधी server ला operating system पाहिजे.

काय. AMI = Amazon Machine Image. ही तयार image AWS तुमच्या नवीन server च्या disk वर copy करतं: operating system, आणि कधी कधी software पण.

Group photo ची उपमा. Group photo एका क्षणी सगळ्यांना पकडतो. AMI एका क्षणी machine ला पकडते: OS, folders आणि files, zip सारखं बांधून. त्यावरून launch होणारा प्रत्येक server अगदी त्या photo सारखा सुरू होतो.

Console मध्ये काय दिसतं (Quick Start): Amazon Linux, macOS, Ubuntu, Windows, Red Hat, SUSE Linux, Debian. काही AMIs वर Free tier eligible label असतं.

कसं.

1. Default ठेवा: Amazon Linux 2023 AMI, Free tier eligible label असलेली.
2. Architecture default ठेवा (64-bit x86).

उदाहरण.

1. समजा तुम्ही 1 server वर तुमची website install करून तो तुमची स्वतःची AMI म्हणून save केला.
2. उद्या अजून 5 web servers लागले. त्या AMI वरून 5 launch करा.
3. पाचही servers website आधीच install असलेले सुरू होतात. Setup एकदाच, 6 वेळा नाही.

22. Step 3: Instance type (CPU आणि RAM)

का. वेगवेगळ्या apps ना वेगवेगळी power लागते. छोट्या blog ला थोडी; मोठ्या database ला खूप. Instance type CPU आणि RAM ठरवतो, आणि किंमत पण.

काय. नाव वाचा: t3.micro.

1. t = family (इथे: burstable general purpose).
2. 3 = generation.
3. micro = size.

Board वरच्या इतर families: c (compute चं जास्त काम), r (memory चं जास्त काम), i (storage चं जास्त काम), f (खास FPGA hardware). vCPU म्हणजे virtual CPU. Quad-core किंवा octa-core phone आठवा: जास्त cores, एकाच वेळी जास्त काम.

T2 table (बरोबर values, AWS च्या T2 page वरून):

t2.3xlarge असा कुठलाच type नाही. RAM चा column बघा: प्रत्येक step ला तो दुप्पट होतो. 0.5 → 1 → 2 → 4 → 8 → 16 → 32.

कोणते types "free"? Account कधी बनलं त्यावर अवलंबून:

म्हणून नवीन account मध्ये default आहे t3.micro: 2 vCPU, 1 GiB. Class च्या console मध्ये हेच दिसलं.

उदाहरण 1: RAM दुप्पट होणं.

1. t2.micro ला 1 GiB. 3 sizes वर जा: micro → small → medium → large.
2. 1 × 2 × 2 × 2 = 8 GiB. Table बघा: t2.large = 8. ✓

उदाहरण 2: एका महिन्याची किंमत (N. Virginia, Linux, on-demand).

1. t2.micro: $0.0116 प्रति तास × 720 = $8.352.
2. t3.micro: $0.0104 प्रति तास × 720 = $7.488.
3. नवीन t3.micro 1 ऐवजी 2 vCPU देतो, आणि महिन्याला $0.864 कमी पडतो.

23. Step 4: Key pair (login)

फक्त password का नाही? Passwords चा अंदाज लावता येतो. Automated bots internet वरच्या servers वर सतत common passwords try करत असतात. म्हणून Linux servers साठी AWS त्याऐवजी key pair वापरतं.

काय. Key pair म्हणजे दोन जुळणाऱ्या keys:

1. Public key: server launch होताना AWS ती server वर ठेवतं.
2. Private key: तुमच्या laptop वर download होणारी file. ती फक्त तुमच्याकडे.

Key pair नक्की काय करतो.

1. Authentication. SSH ने connect करताना server एक challenge पाठवतो. फक्त जुळणारी private key च त्याचं उत्तर देऊ शकते. Private key स्वतः network वरून कधीच जात नाही.
2. Encryption. आत घेतल्यावर SSH आणि server एका तात्पुरत्या session key वर ठरवतात, आणि प्रत्येक command आणि reply त्याने encrypt होतो.

Create key pair window मधले पर्याय.

कुठल्या laptop ला कुठली file? (board)

1. Windows + PowerShell (जुन्या CMD पेक्षा नवीन): .pem. Windows 10 (version 1809, 2018 पासून) आणि Windows 11 मध्ये Microsoft चा OpenSSH client असतो; ssh सापडलं नाही तर Settings → Optional features मध्ये OpenSSH Client add करा.
2. Windows + PuTTY: .ppk. आधी Windows मध्ये चांगलं built-in SSH नव्हतं, म्हणून PuTTY खूप वापरायचे. PuTTYgen .pem ↔ .ppk convert करू शकतो.
3. Mac (Terminal): .pem.
4. Linux (terminal): .pem.

म्हणजे आज बहुतेक वेळा: RSA + .pem.

कसं.

1. Key pair (login) मध्ये Create new key pair निवडा.
2. Server चंच नाव द्या, उदा. my-first-server. (Class मध्ये pehliwali आधीच होतं, म्हणून AWS ने "Key pair already exists" सांगितलं, आणि नाव pehliwali1 झालं.)
3. Type: RSA. Format: .pem.
4. Create key pair दाबा. my-first-server.pem file download होते, बहुतेक Downloads folder मध्ये, आणि server साठी select होते.
5. हा एकच download. AWS private key ची file फक्त याच वेळी देतं. File सुरक्षित folder मध्ये हलवा.
6. Mac किंवा Linux वर file फक्त तुम्हालाच वाचता येईल अशी lock करा: chmod 400 my-first-server.pem. इतरांना वाचता येणाऱ्या keys SSH नाकारतं.

उदाहरण: 2048 bits.

1. AWS ची RSA key 2048 bits लांब असते. 2048 ÷ 8 = 256 bytes.
2. 2048-bit number च्या जवळपास 2²⁰⁴⁸ values असू शकतात, म्हणजे 617 आकडी number.
3. 12 characters चा password, keyboard च्या 95 characters मधून बनवला तरी, 95¹² ≈ 5.4 × 10²³ शक्यता, म्हणजे फक्त 24 आकडी number.

24. Step 5: Network settings आणि security group

का. Ports म्हणजे server चे दरवाजे (IP च्या chapter मधले ports आठवा). Attackers दिवसभर उघडे दरवाजे शोधत असतात. Security group हा firewall आहे, जो ठरवतो कुठले दरवाजे उघडे, आणि कोणासाठी.

काय.

1. Inbound rules = server मध्ये येणारं traffic. नवीन security group मध्ये एकही inbound rule नसतो, म्हणून rule add करेपर्यंत सगळं block.
2. Outbound rules = बाहेर जाणारं traffic. नवीन security group सगळं outbound traffic allow करतो.
3. प्रत्येक inbound rule मध्ये type, port आणि source (कोण connect करू शकतो) असतं.

Board वरचे rules:

0.0.0.0/0 म्हणजे काय? "जगातला प्रत्येक IPv4 address". पहिल्या class मधून: 256 × 256 × 256 × 256 = 4,294,967,296 addresses. हे सगळे त्या port वर ठोठावू शकतात.

कसं (class मध्ये).

1. Network settings मध्ये Create security group तसंच ठेवा.
2. Allow SSH traffic from: Anywhere 0.0.0.0/0 वर tick राहू द्या. SSH (port 22) ने आपण पुढच्या class मध्ये login करणार आहोत.
3. Console एक warning दाखवतो: source 0.0.0.0/0 असलेले rules प्रत्येक IP address ला allow करतात, आणि AWS फक्त ओळखीचे IP addresses allow करायला सांगतं. खऱ्या कामासाठी Anywhere बदलून My IP करा.
4. (नंतर web server साठी Allow HTTP आणि Allow HTTPS वर tick करा.)

SSH Anywhere ला उघडं असलं तरी तुमच्या private key शिवाय कोणी login करू शकत नाही, पण bots दिवसभर प्रयत्न करत राहतात. My IP त्यांना दारातच थांबवतं.

उदाहरण: Anywhere विरुद्ध My IP.

1. Source 0.0.0.0/0: 4,294,967,296 addresses port 22 पर्यंत पोचू शकतात.
2. Source My IP, उदा. 203.0.113.25/32: फक्त 1 address.
3. म्हणजे प्रयत्न करू शकणारे addresses 4,294,967,296 पट कमी.

25. Step 6: Storage (disk)

का. वीज गेली की RAM सगळं विसरते. OS, तुमच्या files आणि database disk वरच राहायला पाहिजेत.

काय. Server ची मुख्य disk म्हणजे EBS root volume.

1. Amazon Linux 2023: default 1 × 8 GiB gp3. Desktop नसलेलं Linux छोटं असतं, म्हणून सुरुवातीला 8 GiB पुरे.
2. Windows Server base AMIs: 30 GB root volume.
3. macOS: फक्त EC2 Mac dedicated hosts वर चालतं (खरे Mac minis), 24 तासांच्या minimum सोबत. कुठल्याही free offer मध्ये नाही.

कसं. 1 × 8 GiB gp3 तसंच ठेवा.

उदाहरण: 30 GB मध्ये अशा किती disks बसतात?

1. समजा disks साठी तुमच्याकडे 30 GB आहेत.
2. एका Linux server ला 8 GiB लागतात.
3. 30 ÷ 8 = 3.75, म्हणजे 3 Linux servers.
4. एका Windows server ला एकट्यालाच 30 GB: 1 Windows server.

26. Step 7: Number of instances

का. कधी कधी एकाच वेळी अनेक सारखे servers लागतात.

काय. एक आकडा टाका, आणि AWS अगदी त्याच settings चे तेवढे servers launch करतं. 10 म्हणजे 10 सारखे servers.

पण limit आहे. नवीन accounts ना service quotas असतात. On-demand servers साठी quota प्रत्येक Region मध्ये vCPUs मध्ये मोजतात, servers च्या संख्येत नाही. जास्त लागले तर Service Quotas console मधून increase मागा.

उदाहरण (समजा quota).

1. समजा N. Virginia मध्ये तुमचा quota 16 vCPUs आहे.
2. t3.micro ला 2 vCPUs.
3. 16 ÷ 2 = जास्तीत जास्त 8 servers.
4. 10 मागितले: AWS launch नाकारतं. 8 मागितले: चालतं.

कसं (class मध्ये). 1 ठेवा.

27. Launch करा, बघा, आणि Region check करा

कसं.

1. उजवीकडचा Summary box बघा: 1 instance, Amazon Linux 2023, t3.micro, नवीन security group, 8 GiB चा 1 volume.
2. Orange Launch instance दाबा. आधी विचार करा (section 18).
3. हिरवा success message येतो. View all instances वर click करा.
4. तुमचा server Instance state: Running दाखवतो. Status check काही minutes Initializing दाखवतो, मग "checks passed".
5. वर उजवीकडे बघा: N. Virginia, us-east-1. तुम्ही India मध्ये बसलाय, आणि तुमचा server USA मधल्या data center मध्ये चालू आहे.

उदाहरण: billing Running पासून सुरू.

1. Billing प्रति second होतं, आणि server प्रत्येक वेळी start झाला की 1 minute minimum.
2. समजा 10 minutes चालू ठेवला: 10 ÷ 60 × $0.0104 = $0.0017.
3. समजा 30 seconds ठेवला: तरी 1 minute चे पैसे: 1 ÷ 60 × $0.0104 = $0.00017.

28. Stop की terminate?

का. Practice संपली की ठरवायचं: बंद करायचा, की delete करायचा.

काय.

1. Stop = power off. नंतर परत Start करता येतो. Stopped असताना server time चे पैसे लागत नाहीत, पण त्याच्या EBS disk चे लागतात. (Start केल्यावर बहुतेक वेळा नवीन public IP address मिळतो, पहिल्या class मधला dynamic IP.)
2. Terminate = delete. Server कायमचा गेला, आणि default ने त्याची root disk पण delete होते. तो shut down व्हायला लागला की लगेच त्याचे पैसे थांबतात.

Terminate कसं करायचं (class मध्ये केलं तसं).

1. Server select करा (box वर tick).
2. Instance state → Terminate (delete) instance.
3. Confirm करा.
4. State Shutting-down होते, मग Terminated. थोड्या वेळाने तो list मधून गायब होतो.

उदाहरण: stopped server ला किती पडतं? (AWS चं EBS pricing page gp3 साठी $0.08 प्रति GB-month हा example rate वापरतं; तुमच्या Region ची किंमत बघा.)

1. महिनाभर stopped, 8 GiB disk: 8 × $0.08 = $0.64.
2. महिनाभर running: $7.488 (server) + $0.64 (disk) = $8.128.
3. Terminated: $0.
4. म्हणजे: लवकरच परत वापरणार असाल तर stop; काम संपलं तर terminate.

29. Homework

Recap

समजलं का? आज रात्री account बनवा, MFA लावा, आणि एक server launch करून terminate करा. उद्या Linux.

Ravindra Bagale, trainer: linkedin.com/in/ravindra-bagale. Mark, social media app, employees ची नावं, 10 कोटींची offer, biscuit आणि toothpaste चे आकडे आणि $1 वरून $0.70 झालेला server ही शिकण्यासाठीची "समजा" उदाहरणं आहेत. AWS चे facts, किमती आणि Free Tier चे नियम October 2026 च्या AWS च्याच pages वरून घेतले आहेत आणि ते वारंवार बदलतात, म्हणून वापरण्याआधी live AWS pages बघा.