so. i finally sat down and actually did AWS. not just watched tutorials, not just read docs actually clicked buttons, broke things, fixed them, and now i have opinions.

this is a writeup of everything i learned practically in this last 1 week, in the order i learned it, with zero fluff. if you're someone who learns by doing and wants a no-nonsense walkthrough of core AWS concepts you're in the right place.

let's go.

spinning up my first EC2 instance

EC2 is basically "rent a computer from Amazon and it runs 24/7 somewhere in a data center." that's the whole thing. everything else is just configuration.

i launched a t3.micro in ap-south-1 (Mumbai) free tier, which is perfect for learning. named it my web server because i'm creative like that.

what actually matters when launching: the AMI (think: OS), the instance type (think: hardware specs), and your key pair (SSH access). everything else can be changed later. don't overthink it.

once it's running, you get a public IPv4. EC2 Instance Connect lets you SSH directly from the browser which is actually very clean for beginners. no terminal setup needed.

one thing that tripped me up the instance showed "Running" but that doesn't mean your application is running. the VM is up, your code is not. different things.

deploying a "website" (lol)

my first deployed website on AWS was literally this:

Hi, i am Ansh. and this is my first AWS based self deployed website. WOHOOOO!!! let's gooo!!!

one line of HTML. serving it with nginx. accessible on port 80 over HTTP. it's terrible and i loved it.

hitting that raw IP in the browser and seeing that text load that was a real moment. first cloud-deployed thing i've ever built. it's plain text and i don't care, it counts.

the actual commands to get Apache running:

# update, install, start
sudo apt-get update -y
sudo apt-get install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx

# drop your HTML here
sudo nano /var/www/html/index.html

that's literally it. the web server is now live. the hard part was not the code it was getting the networking right, which brings us to...

security groups - what even is a port?

security groups are basically firewall rules for your EC2 instance. when i first tried hitting my instance's IP in the browser, nothing loaded. timeout. because i hadn't opened port 80 (HTTP).

i set up a security group called ssh-http-web-secgrp with two inbound rules:

1. SSH on port 22 so i can connect to the instance via terminal. source: 0.0.0.0/0 (anywhere) for learning, should be your IP in prod.

2. HTTP on port 80 so the world can access the web server. source: the load balancer's security group, not the open internet.

actually important thing: security groups are stateful if you allow inbound on port 80, the response traffic goes out automatically. you don't need a matching outbound rule. this confused me for a bit.

load balancer + two instances

this is where things got interesting. i spun up two EC2 instances web-1 and web-2 both running nginx, both in ap-south-1 but in different availability zones (ap-south-1c and ap-south-1a).

internet
    ↓
ALB: web-auto-scale-1  (internet-facing · application)
    ↙            ↘
web-1            web-2
ap-south-1c      ap-south-1a
13.200.143.71    13.200.250.228

the load balancer (ALB = Application Load Balancer) sits in front of both. traffic hits the ELB DNS name, it routes to whichever instance is healthy. hitting the ALB URL shows the nginx default page because both instances are healthy and serving traffic.

the ALB had its own security group (LB-SG) that only allowed HTTP traffic, and the EC2 security group was configured to only accept HTTP from the LB-SG. proper layering.

why two AZs matter: if ap-south-1c goes down (data center fire, power, whatever), ap-south-1a is still up. your site stays live. this is the whole point of availability zones. use them.

stress testing my own server (intentionally)

once i had CloudWatch monitoring set up, i wanted to see the CPU spike. so i SSH'd into web-1 and did something slightly chaotic:

# install the stress tool
sudo apt-get install stress -y

# hammer 2 CPUs for 600 seconds in the background
stress --cpu 2 --timeout 600 &

# more
stress --cpu 1 --timeout 600 &

# even more
stress --cpu 2 --timeout 60

then i opened the CloudWatch monitoring tab and watched the CPU utilization graph spike in real time. went from near 0% to peaking hard. network in/out graphs lit up too.

this is the kind of thing that makes auto scaling make sense. in a real setup, you'd have a scaling policy: "if CPU > 70% for 2 minutes, launch another instance." i had the infra for it the Auto Scaling Group and load balancer were ready. the scaling policies are the next thing i'm wiring up.

what monitoring taught me: CloudWatch metrics are per-instance. the load balancer has its own monitoring tab (target response time, request count). look at both. the LB view shows what users experience; the instance view shows what's happening inside.

IAM - learning what "not authorized" feels like

IAM (Identity and Access Management) is AWS's permission system. users, roles, policies. this one bit me directly.

i was poking around with a second AWS account and tried to view EC2 instances in eu-north-1 (Stockholm). got this:

You are not authorized to perform this operation.
User: arn:aws:iam::590128028909:user/Ansh-2 is not authorized
to perform: ec2:DescribeInstances because no identity-based
policy allows the ec2:DescribeInstances action

makes total sense in hindsight. the user had no IAM policies attached. by default in AWS you get nothing. zero permissions. you have to explicitly grant everything.

this is the opposite of how most beginners think about it. they expect "allow everything by default, block what's dangerous." AWS does "block everything by default, allow what you need." way more secure.

the IAM mental model:

• root account = god mode. don't use it for daily stuff.
• IAM user = a specific identity with attached policies.
• policy = JSON document saying "this action on this resource is allowed/denied."
• role = like a user but assumed temporarily (e.g., an EC2 instance acting as a user to access S3).

the ARN (Amazon Resource Name) in that error message is how AWS identifies every resource uniquely. arn:aws:iam::590128028909:user/Ansh-2 account ID, service, resource. you'll see ARNs everywhere.

S3 - storing stuff in the cloud like a normal person

S3 (Simple Storage Service) is object storage. not a file system, not a database a bucket that holds objects (files). infinitely scalable, stupidly cheap, and the backbone of half the internet.

i created a bucket called first-s3-bucket-by-ansh in ap-south-1 and uploaded one image:

maykl-dzhekson-michael-jackson.jpg  ·  62.2 KB  ·  Standard storage class

(yes that's how it was spelled. yes i kept it.)

first attempt to access it via the public URL, got this:

<Error>
  <Code>AccessDenied</Code>
  <Message>Access Denied</Message>
</Error>

because S3 buckets are private by default. again AWS defaults to locked down. to make an object publicly accessible you need to:

1. Disable "Block Public Access" at the bucket level. it's a safety setting that overrides everything.
2. Add a bucket policy that allows s3:GetObject for Principal: "*" on the objects.
3. or just hit "Make public" on the individual object. faster for learning, wrong for production.

after sorting that the image loaded. michael jackson silhouette on a black background(btw, I LOVE MICHAEL JACKSON SONGS!), served from my S3 bucket, accessible from anywhere in the world. the URL structure is:

https://[bucket-name].s3.[region].amazonaws.com/[object-key]

S3 is everywhere: static website hosting, ML model weights, application logs, database backups, CDN origin... you'll use S3 in basically every AWS architecture. understand it early.

tldr / what i actually learned

not just "what buttons to click" the mental models that stuck:

✅ AWS defaults to deny. no permissions, no access. you build up from zero. this is good, not annoying.

✅ Availability zones are not optional. run across at least two if anything needs to actually stay up.

✅ Security groups are stateful firewalls. inbound rules are all you need for most setups. outbound is open by default.

✅ Load balancers + auto scaling = resilience. horizontal scaling is the AWS way. don't make your instance bigger, make more of them.

✅ IAM is the foundation. understanding ARNs, policies, and roles unlocks everything else. don't skip it.

✅ S3 is not just file storage. it's an architecture primitive. almost every serious AWS app touches it.

what's next: auto scaling policies that actually trigger (stress test → new instance spins up automatically), RDS for a proper database, CloudFront for CDN, and Route 53 for a real domain instead of raw IP addresses.

also i need to terminate these instances before my free tier runs out.

• Ansh Dhanani