Presented by Adarsh Chakraborty · 7 August 2026
[0:00 – 0:20]
"Good morning / afternoon everyone. Over the next thirty minutes I'm going to take you from knowing nothing about the cloud to understanding what actually happens when you type a web address and hit Enter, and where Amazon Web Services fits into that."
"I'm going to assume zero background. If you've never opened AWS in your life, you're exactly who this is for. And if time allows, I may hop into the real AWS console so you can see the actual thing, not just my slides."
Tone: relaxed. Make eye contact. Don't rush this slide, set the expectation that questions are fine.
Where your data physically lives, and why renting beats owning.
Address → number → door → program. The whole chain.
There are 240+. You need about six.
You already know how to build software. Today is about where it runs once you ship it.
[0:20 – 1:00]
"Three parts. First, what the word 'cloud' even means, because it's the most over-used word in tech and it has a very concrete, unglamorous answer."
"Second, and this is the part I most want you to take away, what actually happens between you typing an address and a page appearing. Once you see that chain, every cloud service you ever hear about slots into a position on it."
"Third, the specific AWS services. Amazon offers over two hundred. Genuinely, you need about six to understand ninety percent of what people are talking about."
"Setting expectations: you all build software already. Today adds the missing half of the picture: where your code actually lives and runs once you ship it. By the end, the AWS side of any architecture discussion should feel familiar."
[1:00 – 2:00]
Audience-participation moment. Ask it, pause, and actually count hands. Don't rush it, it wakes the room up and tells you how much to simplify.
The question is half joke, half calibration. Everyone in this room uses servers every day; explaining one simply is the hard part, and simple explanations are exactly what the next thirty minutes practise.
Lots of confident hands: move faster through part one, they know the basics.
Few hands: slow down on the server-room slide and lean on the analogies.
Order the hardware, wait 6–12 weeks, hope you guessed demand right.
Too small → site dies on launch day. Too big → expensive metal gathering dust.
Power, cooling, backups, security patches, the 3 a.m. failed disk.
[2:00 – 3:30]
"To understand why the cloud exists, you have to understand what it replaced. Rewind twenty years. You want to launch a website. Here's what you did."
"You rented a room. You bought physical computers, servers, and stacked them in racks like this. You paid for the electricity, the air conditioning, the internet line, and a person to look after all of it."
Point at the price. "And critically, you paid for all of that before a single customer visited your site. Months before."
"Now here's the trap. How many servers do you buy? You have to buy for your busiest possible moment: Black Friday, or the day you get featured on the news. But that moment might be four hours a year. The other 8,756 hours, most of this room is sitting idle, burning electricity, doing nothing."
"And if you guess too low, your site falls over on the exact day it finally got popular. Guess too high, you've wasted a fortune. There's no way to guess right."
Optional relatable aside: "It's like buying a 50-seater bus because twice a year you drive your relatives to a wedding."
There is no cloud. There are enormous warehouses full of computers, owned by Amazon, that you rent a slice of, by the second, and reach over the internet.
[3:30 – 5:00]
"So, what is the cloud? The word is deliberately fluffy, and that's caused a lot of confusion. Let me give you the honest answer."
Advance so the cloud dissolves into the data centre.
"There is no cloud. There are buildings. Enormous, windowless, heavily-guarded warehouses full of computers, owned by Amazon, sitting in places like Mumbai, Virginia, Frankfurt. When you 'put something in the cloud', you put it on a physical machine in one of those buildings."
"The old joke is right: 'the cloud is just someone else's computer.' That's true, but it undersells it. The real definition is this:"
Read the orange box aloud, slowly. "Cloud computing is renting computing power over the internet, on demand, paying only for what you use."
"Three phrases matter there. On demand: you get it in seconds, not weeks. Over the internet: you never touch the hardware. Pay only for what you use: like a taxi meter, not a car purchase."
Every factory ran its own power plant. Expensive, unreliable, and completely beside the point of your actual business.
Power became a utility. You flip a switch, it's there, and at the end of the month you're billed for the units you actually used.
AWS did to computing exactly what the power grid did to electricity.
[5:00 – 6:00]
"If that still feels abstract, here's the analogy that makes it click, and it's not a metaphor, it's genuinely the same historical shift."
"Around 1900, if you ran a factory, you also ran a power plant. Every factory had its own generator in the back. It was expensive, it broke, and you had to employ someone who understood generators, even though your actual business was making shoes."
"Then the electrical grid arrived. And within about twenty years, essentially every factory shut down its generator and just... plugged into the wall. You stopped thinking about electricity as a thing you produce and started treating it as a thing you consume. You flip a switch, power appears, and at the end of the month you get a bill for exactly the units you used."
"That is precisely what AWS did to computing. Before: every company ran its own server room. After: you plug in, you consume, you're billed for what you used. And you get to spend your energy on your actual business instead of on air conditioning."
Land this line clearly, it's the anchor for everything that follows.
The trick is virtualisation, one very large physical machine, sliced into many independent virtual ones.
[6:00 – 7:30]
"Reasonable question: if it's a building full of computers, does Amazon hand me one whole physical computer? Almost never. The economics wouldn't work, and you usually don't need one."
"The trick that makes all of this possible is called virtualisation. Amazon buys one enormous physical machine, 128 processor cores, a terabyte of memory. Then a piece of software called a hypervisor slices it into many smaller virtual machines."
"Each slice behaves exactly like its own independent computer. It boots its own operating system. It has its own memory. And, this is the important part, it is completely walled off from its neighbours. The bank on that machine cannot see the blog next to it, and vice versa."
Analogy if the room looks lost: "It's an apartment block versus a house. Same building, same plumbing, but you have your own front door and your neighbour can't walk into your kitchen."
"Why does this matter to you? Because slices can be created and destroyed in seconds. That's what makes the next slide possible."
A flat line. Too low during the spike, your site dies. Too high the rest of the year, you burn cash.
Capacity tracks the curve. Traffic triples at 9 p.m., you get more machines automatically. It drops at 3 a.m., they're released and you stop paying.
Elasticity. If you remember one word from this section, make it this one.
[7:30 – 9:00]
"This chart is the single best argument for the cloud, so let me walk you through it slowly."
"Horizontal axis is time, say, a year. Vertical axis is how much traffic your website is getting."
Point at the red dashed line.
"Red dashed line: that's the old world. That's the hardware you bought. It's a flat line, because metal doesn't change size. You picked that number a year ago and you're stuck with it."
Point at the blue curve.
"Blue curve: that's what actually happened. Real demand. Notice it's nothing like a flat line."
"Two disasters follow. Where the blue goes above the red, that red patch, your site is down. That is your biggest day of the year, and customers are seeing an error page. And where blue sits below red, that orange region, you're paying full price for machines doing nothing."
Point at the green line.
"Green line is the cloud. Capacity hugs the demand curve. Traffic triples, you get more machines within a minute or two, automatically, nobody wakes up. Traffic drops overnight, machines are handed back and the meter stops."
"The word for that is elasticity. If you take one word from this section, take that one. It's the thing you genuinely cannot buy with owned hardware."
Going right, you hand over more work, and give up more control. Most of today is IaaS.
[9:00 – 10:00]
"You will hear three pieces of jargon constantly, and they all mean the same thing measured differently: how much of the stack do you still have to look after?"
"Read the rows bottom-to-top. Networking, servers, virtualisation at the bottom, that's raw plumbing. Operating system and runtime in the middle. Your application and your data at the top. The coloured boxes are yours to run. Grey means the cloud provider does it."
On-premises: "Everything is orange. You buy the network switch, you replace the failed hard drive, you patch the operating system, and you also write the app. All of it."
IaaS, Infrastructure as a Service: "Amazon takes the bottom three. You still get an operating system and you still manage it, but you never touch hardware again. EC2 is this. This is what most of today's talk is about."
PaaS, Platform as a Service: "You hand over the operating system too. You give the platform your code and it figures out the rest. You only own the app and the data."
SaaS, Software as a Service: "You manage nothing. You just log in and use it. Gmail. Slack. Salesforce. You are almost certainly using half a dozen SaaS products today without calling them that."
Closing line: "There's no 'best' column. Going right buys convenience and costs you control. Going left is the opposite."
Running the shop at Christmas scale forced Amazon to get world-class at big, reliable infrastructure. In 2006 it turned that skill into a product anyone could rent, S3 for storage, then EC2 for compute. That side business is now the most profitable part of Amazon.
Nobody knows all of them, not even AWS engineers. The catalogue is huge because it covers everything from satellites to genomics. Six services cover the vast majority of real projects, and we're doing those today.
[10:00 – 11:00]
"So that's cloud computing in general. AWS is simply the largest company doing it, roughly 30% of the entire global market, clearly ahead of number two, Microsoft Azure, and number three, Google Cloud."
"The origin story is genuinely a good one. Amazon the shop had to build colossal, never-fall-over infrastructure to survive Christmas, their busiest few weeks. Along the way they got world-class at exactly the problem from my earlier chart: running huge fleets of computers well."
"In 2006 they turned that skill into a product, storage and servers that anyone could rent. That side business is now the most profitable division of Amazon: it makes more profit than the retail store does."
Point at the 240 number, pre-empt the intimidation.
"Now, that 240 number frightens people. Let me defuse it: nobody knows all of them. Not one person at AWS knows all of them. The catalogue is enormous because it covers ground stations for satellites and DNA-sequencing pipelines. Six services cover the overwhelming majority of what anyone actually builds, and those six are what we'll do today."
A city-sized cluster. You choose one. Pick the one nearest your users: Mumbai for India, because distance costs milliseconds. Prices and available services differ per region.
Separate buildings inside that region, kilometres apart, on different power grids and flood plains. Run in two AZs and a fire, flood or power cut in one doesn't take you down.
600+ small outposts in far more cities, holding cached copies of your images and video so they're delivered from a few streets away instead of another continent.
[11:00 – 12:30]
"When you use AWS, the very first decision, before anything else, is where in the world your stuff lives. Three words explain the whole geography."
Region. "A cluster of data centres in one part of the world. Mumbai is a region. Frankfurt is a region. There are close to forty. You pick one. Two reasons to care: distance is latency, if your users are in Delhi and your servers are in Virginia, every click pays for a round trip across the planet. And law, a lot of regulation says citizens' data must physically stay in-country. Choosing 'Mumbai' is how you satisfy that."
Availability Zone. "Inside one region, AWS runs several physically separate buildings, kilometres apart, deliberately on different power grids and different flood plains. Those are Availability Zones."
"Why do you care? Because buildings fail. There are fires, floods, someone puts a digger through a fibre line. If everything you own is in one building, that's your outage too. If you're running in two AZs, one dies and you stay up. Spreading across two AZs is the single cheapest reliability decision you can make."
Edge locations. "Six hundred-plus much smaller outposts, in far more cities, that just hold cached copies of your images and videos so they're served from nearby. That's what a CDN is."
Optional demo cue, the console's region dropdown, top-right. Quick, 15 seconds, very concrete.
Three steps. Once you see them, every cloud service you'll ever hear about
slots into one of these positions.
[12:30 – 13:00]
Change of energy here. Slow down. This is the centrepiece of the talk.
"Right. Park AWS for a moment. I want to do the single most useful thing I can do for you in thirty minutes."
"You type an address. You hit Enter. Somewhere between a tenth and a half of a second later, a page appears. What happened in that gap?"
"Almost nobody outside engineering can answer this, and it is genuinely three steps. Not thirty. Three."
"And here's why it's worth your time: once you can see those three steps, every cloud service you ever hear mentioned, every acronym in every meeting, slots into one of these three positions. It stops being a soup of names and becomes a map."
Computers don't know names. They only know numbers. Something must translate.
You know your friend's name, not their phone number. You look the name up in a contacts list to get the number you can actually dial. DNS is that contacts list, for the entire internet.
"Route" as in routing traffic. And 53… is a number that means something very specific here. Hold that thought.
[13:00 – 14:30]
"Step one. You typed a name: mastersunion.org. Here's the problem: computers have no idea what names are. The network can only deliver to numbers. So the very first thing that must happen is a translation from name to number."
"That translation system is called DNS: the Domain Name System. Think of it as the internet's phone book."
Use the contacts analogy, it lands with every audience.
"You know your friend as 'Priya'. Your phone doesn't dial 'Priya', it looks Priya up and finds a number, and the number is what actually connects the call. You've never memorised the number. That's exactly the relationship between a domain name and an IP address."
Walk the diagram left to right. "Your browser asks a resolver: usually run by your internet provider, 'where is mastersunion.org?' The resolver goes and asks around. Eventually it reaches the machine that authoritatively knows the answer for that domain. On AWS, that's Route 53. And back comes a number: 54.239.28.85."
"That whole round trip is typically 20 to 50 milliseconds, and it's cached heavily so usually it's far faster."
SET UP THE QUESTION: say this, then advance immediately:
"Quick aside, why is it called Route 53? 'Route' is obvious, it routes traffic. But 53? That number is not random. It's a port number: port 53 is the port DNS runs on. Which brings me to the question I actually want to ask you…"
we know what the left side is · what's the right side doing there?
[14:30 – 16:00] · ★ AUDIENCE PARTICIPATION, DO NOT ADVANCE YET
STOP HERE. The answer is deliberately not on the screen. Do not click forward until 2–3 people have had a go. Silence is fine, count to seven in your head before you rescue them.
Ask it: "Port 53. Port 443. You've seen these numbers after a colon. So, what is a port? Anyone. Genuine guesses, there's no wrong answer here."
If nobody speaks, narrow it: "Okay, different angle, we said the IP address gets us to the right computer. So what work is left for that 443 to do?"
Nudges for common answers:
⚠ This drawer projects to the room, so the answer is deliberately NOT written here. It lives in the printed SCRIPT.md, memorise its one sentence before the talk, deliver it verbally after the discussion, then click forward: the next slide is the payoff picture.
Identifies one machine out of every machine on the internet. Like a street address, it gets the post to the right building.
A numbered door on that machine, telling it which program the traffic is for. Same building, many tenants, 65,535 possible doors.
[16:00 – 17:30]
Only arrive here after the audience has had their go at the question.
"So, a port is a numbered door on a computer."
"Here's the full picture. The IP address is the street address of the building. It gets your traffic to one specific machine out of the billions on the internet. But that machine is running lots of programs at once, a web server, a database, an admin login service. They all share one address."
"The port number is the door number. It's how the machine knows which of its programs your traffic is meant for. Knock on 443, the website answers. Knock on 5432, the database answers. Same building, different doors."
Point at the list. "There are 65,535 possible ports, but a handful appear constantly. 443 is the secure web, that's the padlock in your browser. 80 is the old unencrypted web. 22 is how engineers log in to a server remotely. And 53 is DNS: which is exactly where Route 53 gets its name. Now that name makes sense."
Security tie-in, worth 20 seconds, it pays off on the VPC slide later:
"And here's why this matters for security: most of those 65,000 doors should be locked. A big part of securing a server is simply deciding which doors are open and who's allowed to knock. We'll see exactly that in a few minutes."
A running program binds to a port, it claims that door and waits. If no program has claimed it, the knock is refused instantly. That's it. That's the whole thing.
Connection refused: you reached the machine, but nothing is listening on that door.
Timed out: you never even reached the building. Firewall, or wrong address.
Name → number → door → program. Every website on earth, including the one that pays your salary.
[17:30 – 18:45]
"Step three, and it's the shortest. We've arrived at the right building and knocked on the right door. Now, somebody has to be behind it."
"A running program, engineers say a process: claims a port and sits there waiting. The jargon is that it binds to that port. Nginx grabs 443 and waits. Postgres grabs 5432 and waits. Your application grabs 3000. Each one has claimed a door and is listening for knocks."
"If nothing has claimed the door you knock on, you get told 'no' immediately."
This next bit reliably gets a reaction, people have seen these errors for years without knowing what they meant.
"Which means you now understand two error messages you've been seeing your whole life. 'Connection refused' means: I found the machine, I knocked, and nobody was home behind that door, usually the program crashed. 'Connection timed out' means something different: I never reached the building at all, either a firewall stopped me, or I had the wrong address."
"Different problems, completely different fixes. And you can now tell them apart."
"So the whole chain is: name → number → door → program. That's every website on the internet."
[18:45 – 19:30]
"Let's watch the whole thing once, in one picture."
"You type a name. DNS, Route 53 on AWS, turns that name into a number. The number gets you to the right machine, and the port picks which door on that machine. Behind the door a process is listening, and it sends the page back."
"And the entire round trip is about a fifth of a second. Which is roughly how long it takes you to blink."
Pause here. Let the diagram sit for a beat. This is the slide people photograph.
"If you leave today with just this picture in your head, this was a good use of half an hour. Everything else is detail hung off these five boxes."
[19:30 – 20:00]
"Here's the payoff for all that groundwork. Same chain, greyed out at the top. Now I drop the AWS service names underneath."
"Name-to-number is Route 53. Which doors are open, and who's allowed to knock, is VPC and security groups. The thing actually running your program is EC2, or Lambda. Your files and your data sit in S3 and RDS. And wrapped around all of it, always, is IAM: who is permitted to touch what."
"That's the six. That's the whole talk in one picture. Let me spend a minute on each."
From here the pace picks up, roughly 45 seconds per service. Keep moving; the demo is where the detail lands.
A computer you rent by the second.
Five-second breather, then advance. Say the bridge line: "First service, and the one you will hear about most: EC2."
Elastic Compute Cloud. You pick a size, click launch, and ninety seconds later you have a running machine with an IP address.
One of those virtual slices from earlier. It boots Linux or Windows, you install what you like, and it behaves exactly like a computer under your desk, except it's in Mumbai and you never see it.
Billed per second while it's running. Stop it overnight and you stop paying. A small instance is roughly ₹700–900 a month if left on 24/7, and the sign-up credits cover one comfortably while you learn.
[20:00 – 21:00]
"EC2, Elastic Compute Cloud. If you only ever remember one AWS service, make it this one. It's the workhorse."
"It is, very simply, a computer you rent by the second. It's one of those virtual slices I showed you. You choose how big, you choose Linux or Windows, you choose which city it lives in, and about ninety seconds after you click Launch, you have a running machine with its own IP address."
"From that point it behaves exactly like a computer sitting under your desk. You can log in, install software, run your website on it. The only difference is it's in a building in Mumbai and you'll never touch it."
"On cost, you're billed per second while it's running. If you switch it off at night, you stop paying for those hours. A small one costs somewhere around seven to nine hundred rupees a month if you leave it on permanently. And the free credits you get at sign-up comfortably cover one while you're learning."
DEMO OPPORTUNITY: switch to the console here if you're on time. Show the instance list and the Launch wizard. Don't actually launch anything. Just show how few decisions there are, and point at the instance-type dropdown and the security-group step.
A bottomless bucket for files.
Five-second breather, then advance. Say the bridge line: "Compute done. Next question: where do the files live? S3."
Simple Storage Service. Throw any file in, get a URL back. It never fills up and it effectively never loses anything.
You create a bucket (a folder with a globally unique name) and put objects (files) in it. Photos, videos, PDFs, backups, logs. No size limit on the bucket.
AWS quotes 99.999999999%: eleven nines. In plain terms: store ten million files and you'd statistically expect to lose one every ten thousand years. It quietly keeps copies across multiple AZs.
[21:00 – 21:45]
"S3, Simple Storage Service. This is where files live."
"Mental model: Google Drive, but built for programs to use instead of people. You create something called a bucket: that's just a folder with a globally unique name, and you drop files into it. Photos, videos, backups, logs, anything. It never fills up. There's no 'disk full' in S3."
The eleven nines number is the crowd-pleaser here, deliver it as the punchline.
"And the reliability claim is genuinely remarkable. AWS quotes eleven nines of durability. What that means in practice: if you stored ten million files, you'd statistically expect to lose one of them every ten thousand years. It does that by silently keeping copies in multiple separate buildings, those Availability Zones from earlier."
"Practically, nearly every image and video you load on the web is coming out of something like S3. And it's about two rupees per gigabyte per month, which is why nobody thinks twice about it."
DEMO OPPORTUNITY: this is the best demo of the whole talk because it's so tangible. Open a bucket, drag a file in, then open it with the orange Open button (a default bucket's raw Object URL shows AccessDenied, public access is blocked by default). Takes 30 seconds and everyone immediately gets it.
A database AWS manages for you.
Five-second breather, then advance. Say the bridge line: "Files sorted. Structured data next: RDS."
Relational Database Service. Same MySQL or PostgreSQL you'd run yourself, except the backups, patches, and 3 a.m. failover are AWS's job, not yours.
Where it sits on our chain: RDS listens on a port too, 5432 for PostgreSQL, 3306 for MySQL. The critical difference from a website: that door is opened only to your own EC2 instances, never to the public internet.
[21:45 – 22:30]
"S3 is for files. RDS is for data: customers, orders, transactions. The structured stuff that lives in tables."
"You could absolutely install PostgreSQL on an EC2 instance yourself. It's free software. But then look at the left column, you own the backups, you own the patches, and you are the one awake at 3 a.m. when the disk fills up."
"RDS is the same database software, with all of that handed to AWS. Backups happen automatically. Patches happen in a window you pick. And the big one, you can ask for a standby copy in a different Availability Zone, and if the primary dies, it fails over on its own in about a minute. Nobody gets paged."
"My favourite feature: point-in-time restore. You can rewind the database to any single second in the last thirty-five days. Somebody ran a bad delete at 2:14pm? Restore to 2:13."
Tie back to ports, this reinforces the core lesson:
"And notice it fits our chain perfectly. The database also lives behind a door, 5432 for Postgres. The difference is that door is opened only to your own servers, never to the public. That's a security-group rule, which is the next slide."
Security groups: deciding who may knock on which door.
Five-second breather, then advance. Say the bridge line: "Now the part where the port lesson pays off: the fence."
Your own private slice of network inside AWS. Nobody else's servers are on it. Think of a fenced compound inside a shared industrial estate.
A firewall wrapped around one machine. It's a list of rules answering one question: which port, from which source? Everything not listed is silently dropped.
Web server: public, port 443 open to everyone.
Database: private, port 5432 open only to the web server.
Admin port 22: your office IP only.
[22:30 – 23:15]
"Remember I said most of those 65,000 doors should be locked? This is how you lock them, and it's where the port lesson pays off."
VPC: "Virtual Private Cloud. It's your own private network inside AWS. Nobody else's machines are on it. Picture a fenced compound inside a big shared industrial estate, same estate as everyone else, but your gate, your fence."
Security group: "A firewall wrapped around a single machine. And it's beautifully simple: it's a list of rules, and each rule answers one question, which port, open to whom? Anything not on the list is silently dropped, and remember 'timed out' from earlier? That's exactly what a dropped knock looks like from outside."
Walk the diagram, this is the standard architecture the audience will see everywhere.
"So look at the standard setup. The web server sits in a public subnet with port 443 open to the entire internet, that's the point, anyone should be able to visit. Port 22, the admin door, is open only to your office's IP address."
"The database sits in a private subnet. Port 5432 is open only to the web server, not to you, not to the internet. There is literally no route from the internet to that machine."
"That's the pattern. Front door wide open, back office locked, and the safe in a room with no exterior door at all. Ninety percent of real AWS architectures are that shape."
Who is allowed to do what.
Five-second breather, then advance. Say the bridge line: "Doors covered machines. IAM covers people and programs."
Identity and Access Management. Every single action on AWS, by a person or a program, is checked against IAM first. It is the one service you cannot avoid.
A user is a human with a login. A role is a set of permissions a machine or service can temporarily wear. Your EC2 instance wears a role to be allowed to read from S3.
The governing rule: give each person and program the smallest set of permissions that lets them do their job. The intern who uploads images gets "write to this one bucket", not the keys to the estate.
A brand new AWS user can do nothing at all until permissions are explicitly granted. That's the right way round, and it's why IAM feels fiddly at first.
Turn on multi-factor authentication on your root account today. The root account can do anything, delete every server, every backup, every bucket. A stolen root password with no MFA is the single most expensive mistake in cloud, and it happens constantly.
[23:15 – 24:00]
"IAM, Identity and Access Management. Nobody's favourite service, and completely unavoidable. Every single action anyone takes on AWS gets checked against IAM before it's allowed."
"Two words to know. A user is a human with a login, you, your colleague. A role is a set of permissions that a machine can wear temporarily. So your EC2 instance wears a role that says 'may read from this one S3 bucket', which is far safer than storing a password on the server."
"The governing principle is called least privilege: give every person and every program the smallest set of permissions that still lets them do the job. The intern who uploads product images gets 'write to this one bucket'. Not 'delete anything in the account'."
"And AWS defaults to deny. A brand new user can do absolutely nothing until you grant it. That's why IAM feels fiddly the first week, and it's completely the right way round."
Say the MFA warning with real weight. If they take one action home, make it this one.
"One genuine piece of advice, and it's the most important thing I'll say today. Your root account: the email address you signed up with, can do anything. Delete every server, every backup, every file, permanently. Turn on multi-factor authentication on it before you do anything else. Stolen root credentials with no MFA is the single most expensive mistake in this industry, and it happens every week."
Code that runs without a server.
Five-second breather, then advance. Say the bridge line: "Last one, and it breaks the pattern: Lambda."
You upload a function. AWS runs it when something happens, and charges you for the milliseconds it ran. There is no machine to size, patch, or switch off.
Idle costs nothing at all: not a reduced rate, zero. Nothing to patch. It scales from one request to ten thousand a second without you doing anything.
"Serverless" is marketing, there is absolutely a server, you just never meet it. Best for short, event-driven jobs; not for something that must run continuously.
[24:00 – 24:45]
"Last service, and it's the one that breaks the pattern. Lambda."
"With EC2, you rent a machine and it sits there running whether anyone visits or not. Lambda asks: what if you didn't rent a machine at all?"
"You upload just a function: a small piece of code that does one job. Then you tell AWS what should trigger it. Someone uploads a photo to S3. An API gets called. When that happens, AWS finds a machine somewhere, runs your function, gives you the result, and the whole thing disappears."
"You're billed for the milliseconds it actually ran. If nothing happens all day, you pay nothing: not a reduced rate, genuinely zero."
Be honest about the name, audiences appreciate this and it builds trust.
"Now, 'serverless' is a marketing word and I want to be straight with you. There is absolutely a server. You just never meet it, never size it, never patch it. It's 'serverless' the way a taxi is 'carless', not for the driver."
"It's brilliant for short, event-driven jobs. It's the wrong tool for something that needs to run continuously, that's still EC2."
[24:45 – 25:30]
"Here's all six together, and this is genuinely what a small, real production setup looks like. Not a toy diagram."
Trace the path with your hand as you talk. Don't read every label.
"User on the left. Route 53 turns the name into a number. CloudFront is the edge cache, if they're asking for a logo, it's served from a city near them and the journey stops right there."
"Otherwise we go into the VPC: the fenced compound. A load balancer spreads incoming traffic across two EC2 web servers, and notice they're in two different Availability Zones. That's deliberate. One building has a problem, the site stays up."
"Both talk to RDS, which has a standby copy in the other AZ. Images come from S3. And IAM governs who's allowed to touch any of it."
"That's a real architecture. And every box on it is something we've now covered."
No contract, no upfront. You're billed for what you consumed: seconds of server time, gigabytes stored, gigabytes transferred out. Switch a thing off and its meter stops.
Commit to a year and save ~40% (Savings Plans). Take spare capacity that can be reclaimed and save up to 90% (Spot). Move old files to cold storage for pennies (Glacier).
Realistically: a small production website on AWS runs about ₹3,000–8,000 a month. A learning project, done carefully, is ₹0.
[25:30 – 26:30]
"That architecture looks great, but notice: it runs twenty-four hours a day, whether anyone visits or not. Which brings us to the part everyone underestimates: the bill."
"The model is a taxi meter. No contract, nothing upfront. You're billed for what you consumed, seconds of server time, gigabytes stored, gigabytes transferred out. Switch something off and that meter stops."
"One thing that catches people: data going out costs money, data coming in is free. Amazon is very happy for you to upload."
Free credits: "And this is genuinely generous. The moment you sign up you get a hundred dollars of credit, around eight and a half thousand rupees, and up to two hundred if you complete a few short starter tasks. The credits last up to six months, which is more than enough to run everything I've shown you today for free. And a million Lambda runs a month are free forever, on any account."
The two warnings below are DELIVERED VERBALLY, nothing about them is on the slide. Say the billing-alert one firmly, it's the most practically useful advice of the talk.
"But, the flip side of infinite capacity is an infinite bill. Set a billing alert on your first day. Budgets, create a budget, email me if it goes past five hundred rupees. Two minutes of work. Every experienced person in this field has a story about a forgotten instance running over a long weekend, I'd rather you heard it from me than found out yourself."
"And one trap built specially for developers: functions that invoke other functions. A invokes B, B invokes A. Or a Lambda writes its output into the same S3 bucket that triggers it. That's an infinite loop with a price tag, running and billing forever until something stops it. AWS now detects some of these loops, but not all. Two habits prevent it: put a concurrency limit on every function, and never let a function write to its own trigger."
"Ballpark: a small real production website is three to eight thousand rupees a month. A learning project, done carefully, is free."
Real buildings, real machines, sliced up and billed by the second. Nothing mystical.
DNS, IP address, port, process. Every website on earth, one short chain.
EC2, S3, RDS, VPC, IAM, Lambda. The other 234 can wait.
Day one, before anything else. Both take two minutes.
[26:30 – 27:30]
"Let me leave you with four things."
"One: the cloud is rented computers in real buildings. There's nothing mystical about it, and now that you know that, half the jargon stops being intimidating."
"Two: and this is the one I most want to stick, name, number, door, program. DNS turns the name into a number. The number finds the machine. The port picks the door. A process answers. That's every website that exists."
"Three: six services do most of the work. EC2, S3, RDS, VPC, IAM, Lambda. Don't let the catalogue of 240 put you off."
"Four: if you go and sign up tonight: turn on multi-factor auth, and set a billing alert. Before anything else."
"If you want to keep going, the sign-up credits are real money to learn with, AWS Skill Builder has free courses, and Cloud Practitioner is the entry-level certification that's designed for exactly the level we've been at today."
Then advance to the final slide, thank the room, and open the floor.
Any questions? Nothing is too basic. That was the whole point of today.
Adarsh Chakraborty · 7 August 2026
[27:30 – 30:00] · Q&A
Thank the room, let the video loop, and open the floor. If you decide to show the console after all, this is the natural moment; the click-path is in SCRIPT.md under "Optional: console demo".
Then open the floor. Likely questions and short answers: