Part 1: Day 1 — Building the Cloud Fundamentals
Quick backstory before I get into this.
I’ve been knee deep in cybersecurity for a while, mostly VA&PT and CTFs, and I hit that point where everything starts feeling like homework. Not burnt-out burnt out, but close enough that I knew I needed to look at something else for a bit before I lost interest in the thing I actually like. As a third-year CSE student at Parul University, I’m used to jumping between subjects, so when I heard about a Cloud Computing and DevOps workshop happening under Lakshya Connect, taken by Kinjal Gandhi ma’am, I signed up mostly just to change the scenery in my head. Turned out to be exactly what I needed.
Understanding Cloud Computing
Day 1 was all about AWS basics, but the way it was taught made a lot of things click that I’d only half understood before.
We started with something dumb simple, actually. Where does your data go when you post a photo on Instagram or hit play on Netflix? Sounds obvious, but most of us never actually sit and think about it. Somewhere behind that one tap is computing, storage, and networking, all working together, and none of it is on your phone or laptop. That’s cloud computing: using someone else’s computers and infrastructure over the internet instead of running everything on your own hardware.
Then we got into cloud vs traditional IT, which honestly is just “buy everything yourself” vs “rent what you need, when you need it.” Traditional IT means servers, data centers, and hardware maintenance, all paid for upfront whether you use them or not. Cloud computing flips that: you switch things on when you need them, and pricing is usually based on what you actually use, though that varies by service and provider. Made a lot more sense once it was put that way.
We also went over IaaS, PaaS, and SaaS. Infrastructure as a Service, Platform as a Service, Software as a Service, basically how much of the “behind the scenes” work you’re responsible for changes depending on which one you’re using. With IaaS you’re managing more yourself; with SaaS, almost none of it. Not going to lie, this part needed a second explanation before it stuck, but it did. I used to think “the cloud” was just one big generic thing you either used or didn’t. Turns out it’s layers, and figuring out which layer you’re working at changes how much control, and how much responsibility, you actually have.
Getting Hands-On: IAM, EC2, and S3
Then came the part I actually came for.
IAM first. Identity and Access Management, boiled down to three questions: who are you, what are you allowed to do, and what can you touch. The whole idea is giving people only the access they need, nothing more, which is basically the principle of least privilege. As someone from a security background, this felt oddly familiar, and I liked that.
Then EC2, Elastic Compute Cloud, basically a computer that lives somewhere in AWS instead of on your desk, that you can spin up, shut down, and configure however you want. We went through the terms: AMI (the template your instance is built from), instance type (how much power and memory you get), key pairs (how you securely log in), and security groups (your instance’s firewall rules). Then we just… launched one. There’s something weirdly satisfying about watching your own instance come alive on the console for the first time.
Last was S3, Simple Storage Service. If EC2 is your machine, S3 is basically your storage locker: images, files, backups, whatever you need to keep around. Created a bucket, uploaded a file, done. Simple, but it made the whole thing feel real instead of just slides.
The “AHA” Moment
This is where it actually clicked for me. I’d been treating IAM, EC2, and S3 as three separate things to learn, checkboxes on a workshop agenda. Then it hit me: they’re not separate at all. If an EC2 instance needs to read or write something in an S3 bucket, it doesn’t just reach in and grab it. It needs permission, and that permission comes from IAM. You attach an IAM role to the instance, and that role decides exactly what it’s allowed to do in S3, nothing more. That was the moment the three pieces stopped being separate slides and started being one system: IAM decides who can act, EC2 is where the action happens, and S3 is where the result lives.
What I Learned on Day 1
By the end of the day, the whole picture was pretty clean in my head: cloud computing leads to AWS, AWS leads to who has access (IAM), where the computing happens (EC2), and where stuff gets stored (S3). Going in, I thought cloud services were mostly about saving money on hardware. Coming out, I understood it’s really about how responsibility and control get divided up between you and the provider, and that changes everything about how you design, secure, and pay for a system.
Needed this reset more than I realised. Thankful to Kinjal Gandhi ma’am for making it this easy to follow, and to Lakshya Connect for putting it together. Day 1 gave me the fundamentals; Day 2 moves into DevOps, where those AWS basics actually get put to work. I’ll share that next.
Top comments (0)