Root user, IAM users, MFA and launching your first EC2 server

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

1. Why practice matters

Why. You can watch a hundred videos about AWS and still freeze when the console shows an error. Errors teach you. You only get errors when you do the steps yourself.

What. Every student needs an own AWS account. Not a friend's account, not the trainer's screen.

How.

1. Open an AWS account today, with your own email address.
2. Keep a notebook. Every time you see an error, write the error and the fix.
3. Do each step of this chapter in your account, the same day.

Worked example: why one demo is not enough.

1. Suppose you watch the trainer launch 1 server.
2. You launch the same server yourself 5 times, on 5 different days.
3. On day 2 you forget the key pair. On day 4 you pick the wrong Region and can't find your server.
4. That is 2 real errors you fixed yourself. In an interview, those 2 stories are worth more than the 1 demo you watched.

2. The console sign-in screen

Why. Before any server, you must get into the AWS Management Console, the website where you click to create things.

What. Search "AWS management console sign in", or open https://console.aws.amazon.com/. The board showed the screen like this:

1. A box for the IAM user name.
2. A box for the Password.
3. A Sign in button.
4. A link: Sign in using root user email.

There is one more box the board didn't show: an IAM user also needs the account ID or account alias, so AWS knows which account the user name belongs to. Your browser often remembers it, which is why it may not appear. We see both screens in section 8.

How (first time, with a new account).

1. Open the console sign-in page.
2. Click Sign in using root user email (on some screens: choose Root user).
3. Type the email you signed up with, then the password.
4. Set up MFA when AWS asks (section 9). AWS now requires MFA for the root user.

3. Root user and IAM user: who is who

Why. One AWS account is often used by many people. AWS needs a way to tell "the owner" apart from "people working inside the account".

What.

1. The root user is the identity created when someone opens the account with an email address and password (and, when AWS asks, a payment method). It has complete access to everything in the account, and nobody can limit it.
2. An IAM user is a separate login that is created inside the account. IAM means Identity and Access Management. An IAM user can do only what it is allowed to do.
3. An IAM user does not need its own email address. The admin chooses a user name, such as satish.

The board example (suppose). Suppose a big social media app runs on AWS. It has lakhs of servers and thousands of employees. Suppose its founder, Mark, opened the AWS account with the email r@b.com. (This is only a suppose example to learn with. We are not saying any real company runs this way.)

1. r@b.com is the root user. That is Mark, the owner.
2. Mark signs in as root, creates an IAM user called mark for himself with full admin rights, and signs out of root.
3. Everyone else (developers, testers, support people) gets an IAM user. Nobody else ever gets the root email and password.

4. Least privilege: give each person only what they need

Why. The more power a login has, the more damage a mistake or a thief can do with it. So each person gets only the permissions they need for their job. This is called least privilege.

What can be controlled? AWS has more than 200 services. On the board we used five of them:

And one more word from class: an AMI (Amazon Machine Image) is the template a server is launched from: the operating system plus any software. It is not "a backup". The disk backups are called snapshots.

Worked example: the board account (suppose numbers).

1. Suppose the account has 100 EC2 servers, 20 S3 buckets and 10 databases.
2. IAM user satish is allowed: start and stop up to 10 EC2 servers. Not allowed: delete servers, open any database.
3. If satish tries to delete a server, AWS answers Access denied.
4. Out of 100 + 20 + 10 = 130 resources, satish can touch only 10. That is 10 ÷ 130 ≈ 7.7% of the account.

Why data gets the strictest rules. For many companies the database is the most valuable thing they own: customers, orders, payments.

1. Suppose a competitor offers one employee 10 crore rupees for a copy of the customer database.
2. If 500 employees can read the database, you have 500 chances of one bad decision.
3. If only 3 trusted people can read it, you have 3 chances. That is 500 ÷ 3 ≈ 167 times fewer.
4. So database access goes to 2 or 3 trusted people only.

More limits: time and place. Many companies also limit when and from where people can work:

1. Time: allowed only from 9 AM to 6 PM.
2. Place: allowed only from the office network (the office's public IP address) or a company laptop.

In AWS, IAM policies can do this with conditions, for example aws:SourceIp (which IP address the request comes from) and aws:CurrentTime (when the request is made).

5. Accountability: why 1000 people must never share one login

Why. One day something goes wrong. The company must be able to answer one question: who did it?

The board question. Suppose 1000 people all sign in with the same root email and password. One morning, 1000 servers are deleted.

The class tried four answers:

1. Time. Everyone signs in between 9:00 and 9:15. The delete happened at 9:07. That fits all 1000 people.
2. IP address. Everyone works from the same office, so AWS sees the same office public IP for all 1000.
3. MAC address. This doesn't work at all. A MAC address stays inside your local network; it never reaches AWS over the internet.
4. Logs. AWS keeps a record of actions (AWS CloudTrail). But every line says the same thing: root.

Result: 4 answers, 0 names.

What. Give every person their own IAM user. Now every action carries a name.

Worked example.

1. Same 1000 people, but each has an own IAM user.
2. The record shows: 09:07, user satish, terminate instances, ×1000.
3. Time, IP and the log are not needed to guess any more. The name is in the record.
4. 1000 suspects become 1 person who has to explain.

6. Mark's setup: root once, then IAM users for everyone

Why. Now we put sections 3 to 5 together into the real order of work.

How (the board steps).

1. Mark opens the account with r@b.com. That is the root user.
2. Mark signs in as root, ideally only this once for daily work, and turns on MFA for root.
3. Mark creates an IAM user mark with full admin rights (the AWS managed policy AdministratorAccess).
4. Mark signs out of root and signs in as IAM user mark.
5. As mark, he creates IAM users for the employees: satish, mahesh, ravi, raja, rani.
6. For each one he sets a first password and ticks "User must create a new password at next sign-in".
7. He sends each employee three things: the console sign-in link for the account, the user name, and the first password.
8. At first sign-in each employee must choose a new password. Now only the employee knows it.

Why force the password change? Accountability again.

1. Suppose Mark sets satish's password and satish never changes it.
2. Now 2 people know satish's password: satish and Mark.
3. If a server is deleted from the satish login, satish can say "maybe Mark did it". Nobody can prove otherwise.
4. After the forced change, only 1 person knows the password. The login, and the action, belong to satish alone.

When is root still needed? AWS lists a few tasks that only root can do. For a normal account, for example: changing the root email or root password, closing the account, and restoring permissions if the only admin locked himself out. For everything else, use an IAM user.

7. Why you don't use root every day, and the IAM safety net

Why. Root can do everything, including changing the account's email and phone. If a thief gets root, the account can stop being yours.

The board story: one careless click.

1. Mark uses root every day.
2. One day the browser asks "Save password?" and he clicks Save by mistake.
3. Later his laptop gets malware, a bad browser extension or a keylogger. It reads the saved password.
4. The hacker signs in as root and changes the root password.
5. The hacker deletes servers and databases.
6. The hacker changes the account email and phone number.
7. Like someone changing the nominee on your bank account, now the recovery messages go to the hacker. Proving that the account is yours becomes very hard and very slow.

The safety net. Now suppose Mark followed section 6 and works as IAM user mark every day.

1. The same malware steals the IAM user mark password.
2. The hacker signs in as mark and starts deleting.
3. Mark signs in as root (email + password + MFA). The hacker doesn't have these.
4. As root, Mark deletes or disables IAM user mark. The hacker is out at once.
5. Mark creates a new admin IAM user and changes the passwords.

Worked example: count the keys.

1. With root used daily: the thief needs 1 thing, the saved root password. Lose it, lose the account.
2. With IAM daily and root locked away with MFA: the thief needs the root email + the root password + your MFA device. That is 3 things, and the root password was never saved in the browser.

8. In a company you get IAM, not root; and how each one signs in

Why. When you join a company, nobody will hand you the root login. You must know how to sign in as an IAM user.

In class. While you learn, in your own account, you will sign in as root for the first days, with MFA turned on. As soon as you are comfortable, create an admin IAM user for yourself and use that.

What. The two sign-in paths:

The sign-in link. Admins usually send IAM users a link that already contains the account, in this form: https://<account-ID-or-alias>.signin.aws.amazon.com/console. With that link the account ID box is filled in for you.

9. MFA: three types

Why. A password alone can be stolen (section 7). MFA (multi-factor authentication) adds a second proof: something you have, like your phone or a small key. A thief with only your password still can't sign in.

What. AWS now requires MFA for the root user. You can also turn it on for every IAM user. Each user can register up to 8 MFA devices. The board listed three types:

Type 1. Passkeys and security keys.

1. A passkey lives in your phone's or laptop's password manager (Apple, Google, Microsoft and others). You unlock it with your fingerprint, face or PIN. You can also scan a QR code with your phone to sign in on a laptop.
2. A security key is a small physical device, about the size of a pen drive, that you plug in or tap.
3. AWS recommends these first: they are phishing-resistant, so a fake login page can't trick them.

Prices of security keys vary a lot by model and seller; check before you buy.

Type 2. Authenticator app (virtual MFA).

1. Install an authenticator app, for example Google Authenticator or Microsoft Authenticator.
2. In AWS, choose authenticator app, and scan the QR code with the app.
3. The app now shows a 6-digit code that changes every 30 seconds. Type the current code at sign-in.

Type 3. Hardware TOTP token. A small device that looks like a digital watch or a key-ring tag. It shows a 6-digit code on its own screen. AWS accepts only tokens bought through the links on AWS's MFA page, because AWS must know each token's secret.

How does a code appear without internet? This is the part the board got wrong.

1. When you scan the QR code, the app and AWS both store the same secret seed. (A hardware token gets its seed at the factory, and AWS gets a copy.)
2. Every 30 seconds, the app takes the seed + the current time and runs a fixed formula called TOTP (time-based one-time password).
3. AWS runs the same formula with the same seed and the same time.
4. Same seed + same time = same code. If your code matches, you are in.
5. No satellite, no internet, no SMS. The token works fully offline.

Worked example: why guessing doesn't work.

1. A 6-digit code has 10 × 10 × 10 × 10 × 10 × 10 = 1,000,000 possible values.
2. A new code comes every 30 seconds, so a day has 24 × 60 × 60 ÷ 30 = 2,880 codes.
3. A thief who guesses once has a 1 in 1,000,000 chance, and the code is useless 30 seconds later.

Why not SMS OTP?

1. Other apps on a phone can sometimes read incoming SMS codes.
2. In a SIM swap, a criminal gets your number moved to a new SIM and receives your SMS.
3. AWS no longer lets you turn on SMS MFA at all. Use one of the three types above.

10. Which MFA to choose, and keeping a backup

Why. MFA protects you only if you don't lose it. A lost phone with no backup can lock you out.

What. Comparing the three:

How (what the class recommended, made safe).

1. For your practice account, an authenticator app is fine and free.
2. Turn on the app's backup or sync (for example, Google Authenticator signed in to your Google account), so codes come back on a new phone.
3. Better: register 2 devices, for example the app on your phone + a passkey on your laptop. If one is lost, you sign in with the other.
4. A hardware token is very safe from online attacks, but it can be physically stolen. Keep it locked away.

11. Lost your MFA device? How to get back in

Why. Phones break and get lost. You need a plan before it happens.

Root user (AWS's own steps).

1. Sign in as root with your email and password.
2. On the MFA page choose Troubleshoot MFA (it may say "Troubleshoot your authentication device").
3. Choose Sign in using alternative factors.
4. Verify your email: AWS sends a message; click the link in it.
5. Verify your phone: AWS calls your account's primary contact number; type the 6-digit number shown on the screen into your phone's keypad.
6. You are in. Remove the old MFA device and add a new one.
7. If the device was stolen, also change the root password.

If you can't get the email or the phone call, then you contact AWS Support.

IAM user.

1. You can't reset your own MFA.
2. Ask your admin (the person who gave you the user name). The admin deactivates your old device.
3. Sign in and register a new device.

Worked example: why 2 devices save the day.

1. You registered 2 MFA devices: phone app + laptop passkey.
2. Your phone is lost. You sign in with the passkey: 1 minute.
3. With only 1 device you would need the email check + the phone call, and if the phone number is the lost phone's SIM, you would wait for a new SIM first.

12. Your account ID

Why. Every AWS account has a unique number. IAM users need it to sign in, and AWS Support asks for it.

What.

1. The account ID is a 12-digit number, for example AWS's own sample 111122223333.
2. You see it in the account menu at the top right of the console.
3. An account alias is a friendly name you can set instead, used in the sign-in link.

Worked example. 12 digits give 10¹² = 1,000,000,000,000 possible IDs. That is room for a lot of accounts.

13. The Free plan and the $200 credits

Why. You want to learn without a surprise bill. AWS's Free Tier changed in July 2025, so old blog posts and videos are wrong. Here is what AWS's own pages say today (checked October 2026).

What (accounts created on or after 15 July 2025).

1. $100 in credits as soon as you sign up.
2. Up to $100 more: $20 for each of 5 activities in the "Explore AWS" box on the Console Home page:
   1. Launch an instance using Amazon EC2.
   2. Set up a cost budget using AWS Budgets.
   3. Use a foundation model in the Amazon Bedrock playground.
   4. Create a web app using AWS Lambda.
   5. Create an Amazon RDS database.
3. You choose a Free plan or a Paid plan at sign-up.
4. On the Free plan you are not charged. It lasts up to 6 months, or until the credits are used up, whichever comes first. Then the account closes; AWS keeps your data for 90 days, and you can upgrade to the Paid plan in that time to continue.
5. Credits pay for usage. You can't withdraw them as cash or move them to another account.
6. Only new customers get the credits. If you already have, or ever had, an AWS account, you are not eligible. Each AWS account also needs its own email address.

Worked example 1: adding up the credits.

1. Sign-up credit: $100.
2. You finish 3 activities (EC2, budget, RDS): 3 × $20 = $60.
3. Total so far: $100 + $60 = $160.
4. Finish the other 2: + 2 × $20 = $40. Total $200.

Worked example 2: how long does $100 last for one small server? (AWS's on-demand Linux price for t3.micro in N. Virginia, October 2026: $0.0104 per hour.)

1. One month ≈ 30 days × 24 hours = 720 hours.
2. 720 × $0.0104 = $7.488 per month for the server, if it runs all the time.
3. Six months: 6 × $7.488 = $44.93.
4. So $100 covers one small server for the whole 6 months, with room left for disks and practice. (Disks and other services cost extra, so always check the Billing console.)

14. Regions in the console, and enabling an opt-in Region

Why. Your server is launched in whatever Region is selected at the top right of the console. Pick the wrong one and you "lose" your server.

What. The isolation demo from class:

1. The Region menu showed US West (Oregon). A server launched now would sit in an Oregon data center.
2. Switch to Asia Pacific (Mumbai) ap-south-1: the Instances page lists only the Mumbai servers.
3. Switch to US East (N. Virginia) us-east-1: a different list.
4. The servers didn't vanish. Each Region shows only its own resources. Regions are isolated.

Worked example.

1. You launch 2 servers in Mumbai and 1 in N. Virginia.
2. Region = Mumbai: the list shows 2.
3. Region = N. Virginia: the list shows 1.
4. The bill counts all 3 (section 15).

Default and opt-in Regions. Regions that AWS launched after 20 March 2019 are opt-in: they are off until you enable them. In class the table showed Cape Town, Hyderabad and Melbourne as Disabled, and older Regions as Enabled by default.

How to enable one.

1. Click your account name at the top right.
2. Choose Account (it opens in Billing and Cost Management).
3. Scroll to AWS Regions.
4. Select the Region, for example Asia Pacific (Hyderabad), and choose Enable.
5. Wait: usually minutes, sometimes a few hours. Enabling is free.

15. One global bill, paid later: set a budget alert

Why. AWS is post-paid: you use first and pay later. A forgotten server keeps adding to the bill every hour.

What.

1. The Billing console shows Global: one bill for all Regions together.
2. AWS bills monthly. The bill goes to your payment method.
3. If a bill stays unpaid, AWS can suspend the account: you lose access to your servers and data. AWS's own help page says you must clear the dues within 30 days of suspension, or AWS closes the account; after a post-closure period the content is deleted. The agreement also allows interest on late payments. You still owe the money.

How: create a budget alert (this is also one of the $20 activities).

1. Open Billing and Cost Management → Budgets → Create budget.
2. Choose Use a template (simplified) → Monthly cost budget.
3. Enter an amount, for example $5.
4. Enter your email address.
5. Choose Create budget. AWS emails you when your costs cross the limits the template sets.

Worked example: how fast a forgotten server adds up.

1. You forget one t3.micro running in N. Virginia: $0.0104 per hour.
2. One day: 24 × $0.0104 = $0.2496.
3. One month: 720 × $0.0104 = $7.488.
4. Forget 10 of them for a month: 10 × $7.488 = $74.88. A $5 budget alert would warn you in the first few days.

16. Why we practise in N. Virginia, and economy of scale

Why. For practice you want the Region with the most capacity and usually low prices.

What. US East (N. Virginia), us-east-1:

1. It is AWS's first Region, launched in 2006.
2. It has 6 Availability Zones, more than most Regions.
3. Its prices are usually among the lowest. Prices are per Region, so always check the EC2 pricing page.

Worked example: real prices, October 2026 (on-demand Linux t3.micro, AWS's published price data).

1. Difference per server per month: $8.064 − $7.488 = $0.576.
2. For 100 servers: 100 × $0.576 = $57.60 per month.
3. For learning, $0.58 is small. For a company with thousands of servers, it adds up. But a company with users in India may still choose Mumbai for speed (remember latency from the last chapter).

Economy of scale. The bigger the operation, the lower the cost of each unit. AWS buys hardware, power and network in huge amounts, so each server-hour costs it less, and AWS has cut its prices many times over the years.

The class analogies (all suppose examples to understand the idea, not real price history):

1. Biscuit packet. Suppose a 10-rupee biscuit packet had 100 g. The company grows and makes much more, so its cost per gram falls. Now 10 rupees gets you 120 g.
2. Toothpaste. Suppose a 20-rupee tube had 50 g, and at bigger scale it gives 70 g for the same 20 rupees.
3. Dividend. When a company earns more, it shares some of the profit with its shareholders as a dividend. When a cloud grows, it can share some of the saving with customers as lower prices.
4. Board numbers. Suppose a server cost $1.00 per hour. At bigger scale it costs $0.70. Saving per hour: $0.30. For 720 hours: 720 × $0.30 = $216 per month, per server.

17. EC2 = Elastic Compute Cloud

Why. Every service name in AWS is a short form. Once you can read the name, you know what the service does.

What. Reading the name like a film title. You know how Kabhi Khushi Kabhie Gham is written as K3G, because "K" comes three times? AWS does the same:

1. Elastic Compute Cloud: E + C + C. The C comes twice, so EC2.
2. Simple Storage Service: S three times, so S3.

Each word:

1. Elastic = like a rubber band. It stretches and comes back. Traffic goes up, you add capacity. Traffic goes down, you remove it.
2. Compute = processing, the work a CPU does: adding 2 + 3 = 5, resizing an image, running an app.
3. Cloud = the machine is in an AWS data center, not on your desk. You use it over the internet.

Worked example: elastic in numbers (suppose).

1. On a normal day your site needs 2 servers.
2. During a big sale, traffic is 5 times higher: 2 × 5 = 10 servers.
3. After the sale you go back to 2.
4. Suppose each server costs $0.0104 per hour, and the sale lasts 48 hours. Extra cost: 8 extra servers × 48 hours × $0.0104 = $3.99. You pay for the extra 8 only during those 48 hours.

18. The orange button: think before you click

Why. In the EC2 console the main action is an orange button: Launch instance. Launching starts something that may cost money.

How to reach it.

1. In the console search bar type ec2, and open EC2.
2. The EC2 dashboard opens. Look for the orange Launch instance button.

The traffic signal analogy. Red means stop. Green means go. Orange means: slow down, look, think. Treat every orange button in AWS like that.

19. The 7 launch steps

Why. Before the class saw the screen, we asked: what do you need to start a server? Students said: Region, RAM, operating system, storage, security group, key pair. That is almost the whole launch page. AWS groups it into 7 parts (plus the Region you choose first).

1. Name and tags
2. AMI: the operating system image
3. Instance type: how many CPUs and how much RAM
4. Key pair: how you will log in
5. Network settings: the security group (firewall)
6. Storage: the disk
7. Number of instances

Then: Launch instance. The next sections take one step at a time.

20. Step 1: Name and tags

Why. AWS gives every server an ID like i-0123456789abcdef0. Nobody remembers which app runs on i-0123… and which on i-0fed….

What. The name is optional, but always give one. The name is really a tag: a label with a key Name and a value you choose.

How.

1. In Name and tags type a name that says what the server does, for example my-first-server.
2. In class the name was "pehli wali", "the first one". Any clear name works.

Worked example.

1. Suppose a company runs 30 servers: 10 web, 10 app, 10 database.
2. Without names: 30 random IDs. To find the database servers you open all 30.
3. With names like web-1 … web-10, app-1 … app-10, db-1 … db-10, you filter by db and see the 10 at once.

21. Step 2: AMI, the operating system image

Why. A server needs an operating system before it can do anything.

What. AMI = Amazon Machine Image. It is a ready-made image that AWS copies onto your new server's disk: the operating system, and sometimes software too.

The group-photo analogy. A group photo captures everyone at one moment. An AMI captures a machine at one moment: the OS, the folders and the files, packed like a zip. Every server launched from it starts exactly like that photo.

What you see in the console (Quick Start): Amazon Linux, macOS, Ubuntu, Windows, Red Hat, SUSE Linux, Debian. Some AMIs carry a Free tier eligible label.

How.

1. Keep the default: Amazon Linux 2023 AMI, marked Free tier eligible.
2. Leave the architecture at the default (64-bit x86).

Worked example.

1. Suppose you prepare 1 server with your website installed and save it as your own AMI.
2. Tomorrow you need 5 more web servers. You launch 5 from that AMI.
3. All 5 start with the website already installed. Setup time: once, not 6 times.

22. Step 3: Instance type (CPU and RAM)

Why. Different apps need different power. A small blog needs a little; a big database needs a lot. The instance type decides CPU and RAM, and also the price.

What. Reading a name: t3.micro.

1. t = the family (here: burstable general purpose).
2. 3 = the generation.
3. micro = the size.

Other families from the board: c (compute-heavy work), r (memory-heavy work), i (storage-heavy work), f (special FPGA hardware). A vCPU is a virtual CPU. Think of a quad-core or octa-core phone: more cores, more work at the same time.

The T2 table (correct values, from AWS's T2 page):

There is no t2.3xlarge. Look at the RAM column: each step doubles it. 0.5 → 1 → 2 → 4 → 8 → 16 → 32.

Which types are "free"? It depends on when the account was created:

So in a new account the default is t3.micro: 2 vCPU, 1 GiB. That is what the class console showed.

Worked example 1: RAM doubling.

1. t2.micro has 1 GiB. Go up 3 sizes: micro → small → medium → large.
2. 1 × 2 × 2 × 2 = 8 GiB. Check the table: t2.large = 8. ✓

Worked example 2: price of one month (N. Virginia, Linux, on-demand).

1. t2.micro: $0.0116 per hour × 720 = $8.352.
2. t3.micro: $0.0104 per hour × 720 = $7.488.
3. The newer t3.micro gives 2 vCPU instead of 1, and costs $0.864 less per month.

23. Step 4: Key pair (login)

Why not just a password? Passwords can be guessed. Automated bots keep trying common passwords against servers on the internet. So for Linux servers AWS uses a key pair instead.

What. A key pair is two matching keys:

1. The public key: AWS puts it on the server when it launches.
2. The private key: a file that downloads to your laptop. Only you keep it.

What the key pair does, exactly.

1. Authentication. When you connect with SSH, the server sends a challenge. Only the matching private key can answer it. The private key itself never travels over the network.
2. Encryption. After you are let in, SSH and the server agree on a temporary session key, and every command and reply is encrypted with it.

Choices in the Create key pair window.

Which file for which laptop? (the board)

1. Windows + PowerShell (newer than the old CMD): .pem. Windows 10 (from version 1809, in 2018) and Windows 11 have Microsoft's OpenSSH client; if ssh is missing, add OpenSSH Client under Settings → Optional features.
2. Windows + PuTTY: .ppk. In the past Windows had no good built-in SSH, so PuTTY was common. PuTTYgen can convert .pem ↔ .ppk.
3. Mac (Terminal): .pem.
4. Linux (terminal): .pem.

So in most cases today: RSA + .pem.

How.

1. In Key pair (login) choose Create new key pair.
2. Name it the same as the server, for example my-first-server. (In class pehliwali already existed, so AWS said "Key pair already exists", and the name became pehliwali1.)
3. Type: RSA. Format: .pem.
4. Choose Create key pair. The file my-first-server.pem downloads, usually to your Downloads folder, and is selected for the server.
5. This is the only download. AWS gives you the private key file only this once. Move the file to a safe folder.
6. On Mac or Linux, lock the file so only you can read it: chmod 400 my-first-server.pem. SSH refuses keys that others can read.

Worked example: 2048 bits.

1. An RSA key from AWS is 2048 bits long. 2048 ÷ 8 = 256 bytes.
2. A 2048-bit number can have about 2²⁰⁴⁸ values, a number with 617 digits.
3. A 12-character password, even from 95 keyboard characters, has 95¹² ≈ 5.4 × 10²³ possibilities, a number with only 24 digits.

24. Step 5: Network settings and the security group

Why. Ports are the doors of a server (remember ports from the IP chapter). Attackers try open doors all day. A security group is the firewall that decides which doors are open, and for whom.

What.

1. Inbound rules = traffic coming into the server. A new security group has no inbound rules, so everything is blocked until you add a rule.
2. Outbound rules = traffic going out. A new security group allows all outbound traffic.
3. Each inbound rule has a type, a port and a source (who may connect).

The board rules:

What does 0.0.0.0/0 mean? "Every IPv4 address in the world". From our first class: 256 × 256 × 256 × 256 = 4,294,967,296 addresses. All of them may knock on that port.

How (in class).

1. In Network settings, keep Create security group.
2. Leave Allow SSH traffic from: Anywhere 0.0.0.0/0 ticked. SSH (port 22) is how we will log in next class.
3. The console shows a warning: rules with source 0.0.0.0/0 allow every IP address, and AWS recommends allowing only known IP addresses. For real work, change Anywhere to My IP.
4. (Later, for a web server, tick Allow HTTP and Allow HTTPS.)

With SSH open to Anywhere, only someone with your private key can log in, but bots will still try all day. My IP shuts them out at the door.

Worked example: Anywhere vs My IP.

1. Source 0.0.0.0/0: 4,294,967,296 possible addresses can reach port 22.
2. Source My IP, for example 203.0.113.25/32: exactly 1 address.
3. That is 4,294,967,296 times fewer addresses that can even try.

25. Step 6: Storage (the disk)

Why. RAM forgets everything when the power goes. The OS, your files and your database must live on a disk.

What. The server's main disk is an EBS root volume.

1. Amazon Linux 2023: the default is 1 × 8 GiB gp3. Linux without a desktop is small, so 8 GiB is enough to start.
2. Windows Server base AMIs: 30 GB root volume.
3. macOS: runs only on EC2 Mac dedicated hosts (real Mac minis), with a 24-hour minimum. Not part of any free offer.

How. Keep 1 × 8 GiB gp3.

Worked example: how many such disks fit in 30 GB?

1. Suppose you have 30 GB to use for disks.
2. One Linux server needs 8 GiB.
3. 30 ÷ 8 = 3.75, so 3 Linux servers.
4. One Windows server needs 30 GB alone: 1 Windows server.

26. Step 7: Number of instances

Why. Sometimes you need many identical servers at once.

What. Type a number, and AWS launches that many servers with exactly the same settings. 10 means 10 identical servers.

But there is a limit. New accounts have service quotas. For on-demand servers the quota is counted in vCPUs per Region, not in number of servers. If you need more, request an increase in the Service Quotas console.

Worked example (suppose quota).

1. Suppose your quota is 16 vCPUs in N. Virginia.
2. t3.micro has 2 vCPUs.
3. 16 ÷ 2 = 8 servers at most.
4. Ask for 10: AWS refuses the launch. Ask for 8: it works.

How (in class). Keep 1.

27. Launch, view, and check the Region

How.

1. Check the Summary box on the right: 1 instance, Amazon Linux 2023, t3.micro, new security group, 1 volume of 8 GiB.
2. Click the orange Launch instance. Think first (section 18).
3. A green success message appears. Click View all instances.
4. Your server shows Instance state: Running. The Status check shows Initializing for a few minutes, then "checks passed".
5. Look at the top right: N. Virginia, us-east-1. You are sitting in India, and your server is running in a data center in the USA.

Worked example: billing starts at Running.

1. Billing is per second, with a 1-minute minimum each time the server starts.
2. Suppose you keep it running for 10 minutes: 10 ÷ 60 × $0.0104 = $0.0017.
3. Suppose you keep it for 30 seconds: you still pay for 1 minute: 1 ÷ 60 × $0.0104 = $0.00017.

28. Stop or terminate?

Why. When you finish practice, you must decide: switch it off, or delete it.

What.

1. Stop = power off. You can Start it again later. You don't pay for server time while it's stopped, but you still pay for its EBS disk. (After a start it usually gets a new public IP address, the dynamic IP from our first class.)
2. Terminate = delete. The server is gone for good, and by default its root disk is deleted too. You stop paying for it as soon as it starts shutting down.

How to terminate (as in class).

1. Select the server (tick the box).
2. Instance state → Terminate (delete) instance.
3. Confirm.
4. The state changes to Shutting-down, then Terminated. After a while it disappears from the list.

Worked example: what does a stopped server cost? (AWS's EBS pricing page uses $0.08 per GB-month for gp3 as its example rate; check your Region.)

1. Stopped for a month, 8 GiB disk: 8 × $0.08 = $0.64.
2. Running for a month: $7.488 (server) + $0.64 (disk) = $8.128.
3. Terminated: $0.
4. So: stop if you will use it again soon; terminate if you're done.

29. Homework

Recap

Samjla ka? Aaj ratri account banva, MFA lava, ani ek server launch karun terminate kara. Udya Linux.

Ravindra Bagale, trainer: linkedin.com/in/ravindra-bagale. Mark, the social media app, the employee names, the 10 crore offer, the biscuit and toothpaste numbers and the $1 to $0.70 server are "suppose" examples for learning. AWS facts, prices and Free Tier rules are from AWS's own pages as of October 2026 and change often, so check the live AWS pages before you rely on them.