DEV Community: Bilal Bukhari

Launching an EC2 Instance, Connecting via RDP

Bilal Bukhari — Tue, 29 Sep 2026 16:11:41 +0000

Everything I'd built with AWS up to this point was S3 — storage, permissions, static hosting. Today moved into actual compute: launching a virtual machine on EC2, connecting into it remotely over RDP, and learning how to back it up and move that backup around using snapshots.

Topics Covered

Launching an EC2 instance
Connecting to it via RDP
Taking EBS snapshots
Sending and receiving snapshots

1. Launching an EC2 Instance

EC2 (Elastic Compute Cloud) is AWS's virtual machine service — instead of storing objects like S3, it gives you an actual running server you can log into and use. Launching one means choosing an AMI (Amazon Machine Image, essentially the OS template), an instance type (which determines CPU/RAM), a key pair for access, and a security group controlling what traffic can reach it.

For this lab, I launched a Windows instance on a t3.micro — small, cheap, enough to test with. A few minutes after launch, it showed up in the console as Running, with all status checks passed:

The instance state and status checks matter more than they look like at first glance — "running" just means the VM booted, while the status checks confirm the underlying hardware and the OS itself are actually healthy. A running instance that fails a status check is not one you want to trust yet.

2. Connecting via RDP

Since this was a Windows instance, the way in is RDP (Remote Desktop Protocol) rather than SSH. The security group has to explicitly allow inbound traffic on port 3389 for this to work at all — by default, nothing gets in.

The process: retrieve the administrator password using the key pair created at launch, then connect using any RDP client (Windows' own Remote Desktop Connection app works fine) pointed at the instance's public IP. Once connected, it behaves exactly like a normal Windows desktop — except it's running on AWS hardware somewhere in a data center rather than the physical machine in front of me.

This is the part that made cloud computing feel tangible in a way S3 hadn't. A bucket is abstract. A full remote desktop you're actively controlling is not.

3. Taking Snapshots

A snapshot is a point-in-time backup of an EBS volume (the virtual hard disk attached to an EC2 instance). Rather than backing up files individually, a snapshot captures the entire volume's state, incrementally — after the first full snapshot, later ones only store the blocks that changed.

I took three snapshots over the course of the lab, each showing as Completed with the full volume captured:

Snapshots are the foundation for a lot of what makes EC2 usable in production: recovering from a bad update, migrating a volume to a new instance, or scaling by launching new instances directly from a known-good image.

4. Sending and Receiving Snapshots

Beyond just creating them locally, snapshots can be copied — including across regions and across AWS accounts. Sharing a snapshot means modifying its permissions to grant another account access, after which that account can copy it into their own environment and create a volume from it.

This is the piece that turns a snapshot from "personal backup" into an actual transfer mechanism — moving a fully configured server environment from one place to another without manually reinstalling anything, just by handing over the snapshot and letting the other side spin up a volume from it.

Why This Matters

S3 taught me about storage and access control in the abstract. EC2 and snapshots are the first time I was working with something that behaves like a real, persistent machine — one that can be backed up, broken, restored, and handed off. That distinction between object storage and block storage tied to a running instance is a core piece of the AWS mental model, and this was the lab where it actually clicked instead of just being a definition I'd read.

What's Next

Now that I can launch, connect to, and snapshot an instance, the next logical step is automating this instead of doing it by hand through the console — looking at either the AWS CLI or Infrastructure as Code (Terraform or CloudFormation) to spin up the same setup repeatably.

Deploying a React E-Commerce Frontend on AWS S3

Bilal Bukhari — Fri, 25 Sep 2026 20:32:37 +0000

Most of what I've built on S3 so far has been about infrastructure — buckets, permissions, presigned URLs, events. Today was different: I took an actual frontend, a tech/gaming products landing page, and got it live on the internet using the same S3 static hosting setup I'd worked with before, just applied to something real this time instead of a placeholder template.

The Page Itself

It's a storefront-style landing page — hero section, top-rated products, featured categories, a trending products carousel, brand logos, and a footer. Nothing backend-driven yet, just the frontend shell of an e-commerce site: gaming peripherals, RAM, SSDs, cooling gear, that kind of catalog.

Getting It Onto S3

The deployment side was the same pattern I'd already built muscle memory for by this point: create the bucket, enable static website hosting, set index.html as the index document, turn off Block Public Access, and attach a bucket policy granting public s3:GetObject read access. What's different this time is that instead of one HTML file, this was a full asset folder — multiple image directories, nested paths, a real project structure instead of a single page.

Live here: http://laptop-605365943139-us-east-1-an.s3-website-us-east-1.amazonaws.com/index.html

What's Actually Different About a Real Project vs a Test Upload

Uploading one file to test hosting is a five-minute task. Uploading an entire project with a proper folder structure surfaces a different set of problems — relative paths that assumed a different root, asset folders that need to preserve their structure exactly, and making sure every referenced file actually made it into the bucket at the path the HTML expects it at. S3 doesn't care about folder structure conceptually (it's really just keys with slashes in them), but the moment an HTML file references ./icon/cart.png and that path doesn't resolve to an actual key in the bucket, you get a broken image instead of a build error — no failure message, just something quietly not showing up.

Why This One Felt Different

Every previous S3 lab was a controlled exercise — one bucket, one file, one concept being tested. This was the first time it was "take something that looks like a real product and put it in front of people," asset pipeline and all. It's a small step, but it's the difference between knowing how static hosting works and actually shipping something with it.

Building a Netflix-Inspired Frontend with React

Bilal Bukhari — Thu, 24 Sep 2026 17:25:51 +0000

Building and Deploying a Netflix-Inspired React Landing Page on AWS S3 🎬☁️

I recently finished building and deploying a Netflix-inspired frontend landing page using React.

The project started as a way to practice React and frontend development, but I also wanted to take it one step further and actually put the finished application online using Amazon S3.

So instead of keeping the project running only on localhost, I built the production version and deployed it as a live website using AWS S3.

🌐 Live Demo

🎬 Live Website: http://netflixlanding-605365943139-us-east-1-an.s3-website-us-east-1.amazonaws.com

💻 GitHub Repository: https://github.com/himbukharidev

You can open the live website and interact with the frontend directly.

🛠️ Technologies Used

React — frontend development
Vite — development/build tool
JavaScript — application logic
HTML & CSS — structure and styling
React Router — navigation
Axios — HTTP requests
Lucide React — icons
AWS S3 — static website hosting

🎬 The Project

The goal was to build a complete Netflix-inspired landing page rather than just recreating a single section.

The page includes multiple sections and interactive elements.

Hero Section

The landing page starts with a large hero section designed around the visual style of a modern streaming platform.

It contains the main promotional content and call-to-action elements.

🎞️ Movie & Show Posters

The page contains different sections displaying movie and show posters.

I used reusable React components to avoid creating completely separate markup for every poster and section.

🖱️ Interactive Movie Details

The posters aren't just static images.

When a user clicks on a poster, a movie details popup/modal appears.

The selected movie's information is displayed inside the popup along with its poster, giving the interface a more interactive experience.

🃏 Cards

The landing page also contains additional card-based sections to make the page feel more complete rather than just being a collection of movie posters.

❓ FAQ Section

I added an FAQ section where users can interact with the questions and view their answers.

This was another opportunity to practice interactive React components.

📌 Footer

The page finishes with a complete footer containing additional navigation and information.

⚛️ Building the UI with React

One of the main things I wanted to practice was component-based development.

Instead of putting everything into one large component, I separated the interface into reusable pieces.

A simplified structure looks something like:

App
├── Navbar
├── Hero
├── Movie Sections
│   └── Movie Cards
├── Movie Details Modal
├── Cards
├── FAQ
└── Footer

The movie details popup was particularly useful for practicing React state.

When a user selects a poster, the application keeps track of the selected movie and displays the appropriate information inside the modal.

This allowed me to practice the basic React flow of:

User clicks poster
       ↓
Update state
       ↓
Selected movie changes
       ↓
Modal appears
       ↓
Movie information is displayed

📱 Making the Landing Page Responsive

I also worked on making the frontend responsive across different screen sizes.

The layout changes depending on the available screen space, including:

Movie poster dimensions
Card sizes
Spacing
Typography
Hero section
Navigation
Content layout

The goal was to keep the same overall design while making the page usable on smaller screens.

☁️ Deploying the React Application to AWS S3

This was one of the most useful parts of the project for me.

Building the application locally is one thing.

Taking that application and making it accessible through a public URL is another.

Since this project is a frontend/static application, Amazon S3 is suitable for hosting the production build.

The deployment process was essentially:

React Application
       ↓
npm run build
       ↓
Production Build
       ↓
Upload Build Files
       ↓
Amazon S3 Bucket
       ↓
Static Website Hosting
       ↓
Live Website

1. Creating the Production Build

Once the React application was finished, I generated the production build:

npm run build

Vite generated the production-ready files in the dist directory.

These are the files that need to be served to visitors instead of the development files used by npm run dev.

2. Creating the S3 Bucket

I created an S3 bucket specifically for the website.

The bucket is used to store the static files generated by the React build.

Instead of running a development server on my computer, the files are stored in AWS and served from there.

3. Uploading the Build

I uploaded the contents of the production build to the S3 bucket.

The important part here is uploading the contents of dist, rather than simply uploading the entire project folder.

The bucket therefore contains the files needed by the browser to load the application.

4. Configuring Static Website Hosting

I configured the S3 bucket for static website hosting.

This tells S3 that the bucket is being used to serve a website rather than simply storing files.

The website's entry point is the React application's index.html.

5. Making the Website Accessible

After configuring the required S3 settings and permissions, the files could be accessed through the S3 website endpoint.

This allowed the React application to be opened from a browser without running anything locally.

And that's the part I liked most about the deployment:

The application went from a local React project to an actual live website hosted on AWS.

🔄 Updating the Deployed Application

Another useful thing I learned was that deployment doesn't mean the project is permanently finished.

When I make changes to the React application, I can create a new production build:

npm run build

and upload the updated build files to S3.

So the workflow becomes:

Make changes
     ↓
Test locally
     ↓
npm run build
     ↓
Upload updated files
     ↓
Refresh live website

This gave me a simple introduction to the basic idea of a frontend deployment workflow.

🧠 What I Learned

This project helped me practice both frontend development and basic cloud deployment.

React

I became more comfortable with:

Reusable components
Props and state
Interactive UI
Modals
Rendering movie data
Component organization

Frontend Development

I practiced:

Responsive layouts
CSS
UI structure
Cards
Navigation
FAQ interactions
Designing a complete landing page

AWS

Most importantly, I got hands-on experience with:

Amazon S3
S3 buckets
Static website hosting
Uploading production files
Hosting a frontend application on AWS

The AWS part was especially useful because it showed me that cloud services aren't only something to read about — I can actually use them to deploy something I've built.

🚧 What's Not Included

This is a frontend project, so it does not currently include:

User authentication
User accounts
Watchlists
Custom backend
Database
Personalized recommendations
Actual video streaming

Those would require additional backend and infrastructure work.

For this project, I intentionally focused on the frontend experience and deployment.

🎯 Final Thoughts

This project was more than just recreating a familiar UI.

I got to take the project through the complete basic workflow:

Build
  ↓
Test
  ↓
Create production build
  ↓
Deploy
  ↓
Make it publicly accessible

The combination of React + AWS S3 gave me practical experience with taking a frontend application from local development to a real deployed website.

The project is now live, so feel free to check it out.

🎬 Live Demo: http://netflixlanding-605365943139-us-east-1-an.s3-website-us-east-1.amazonaws.com

💻 GitHub: https://github.com/himbukharidev

🔗 Connect With Me

If you're interested in following my journey as I continue learning Java, Spring Boot, React, and AWS, you can connect with me on LinkedIn:

LinkedIn: www.linkedin.com/in/bilalbukhari-dev

Thanks for reading!

Presigned URLs and Event Notifications with S3 and SNS

Bilal Bukhari — Sat, 19 Sep 2026 20:34:05 +0000

Up until now, every file I've touched in S3 has gone through the console, or through a bucket policy that made things public for everyone. Today's problem was different: how do you let one specific person upload or download one specific file, temporarily, without making anything public and without giving them AWS credentials at all? That's what presigned URLs solve. Alongside that, I set up SNS to get notified whenever something actually happens in a bucket, instead of having to go check manually.

The Problem With "Just Make It Public"

Public bucket policies work fine for something like a static website, where everyone should see the same content. They fall apart the moment access needs to be temporary or user-specific — a private document one customer should download, or an upload slot for one user that shouldn't stay open forever. Making the whole bucket public to solve that is the wrong tool for the job, and it's the kind of shortcut that turns into a real security problem later.

Implementing Presigned URLs

A presigned URL is a normal S3 object URL with a signature and expiry baked into the query string, generated using AWS credentials that already have permission on that object. Anyone holding that URL can perform the specific action it was signed for — a GET to download, a PUT to upload — until it expires, without needing any AWS credentials of their own.

I generated these using the AWS SDK rather than the console, since that's how this actually gets used in a real app: the backend decides someone is allowed to access a specific file, generates a short-lived signed URL for it, and hands that URL back to the client. The backend never has to stream the file itself, and the client never touches an AWS secret key.

The part worth paying attention to is the expiry window. Set it too long and you've basically recreated a public link with extra steps. Set it too short and legitimate users start hitting expired links mid-download. I ended up treating this as something to tune per use case rather than a single fixed number.

Adding SNS for Event Notifications

The second half of today was hooking up SNS (Simple Notification Service) to S3, so that instead of periodically checking a bucket to see if anything changed, the bucket tells me when something does. S3 can publish an event — object created, object removed, etc. — directly to an SNS topic, and anything subscribed to that topic (an email address, an endpoint, another service) gets notified.

Wiring this up is less about writing code and more about configuration: create the SNS topic, give the S3 bucket permission to publish to it, then configure the bucket's event notifications to fire on the events that matter (I focused on object creation for now, since "someone just uploaded something" is the one I actually needed to react to). Once that was in place, uploading a test file into the bucket produced a notification within seconds, with no polling involved anywhere.

Why These Two Belong Together

On their own, presigned URLs and SNS solve different problems — one is about controlled access, the other is about knowing when something happened. Put together, they start to look like the shape of a real upload pipeline: a backend issues a presigned URL so a user can upload directly to S3, and the moment that upload lands, an SNS notification fires so the rest of the system can react — kick off processing, update a database record, whatever needs to happen next — without the backend ever having to sit there polling the bucket to find out.

What's Next

Right now the SNS notification just proves the event fired — nothing is actually consuming it yet. The obvious next step is subscribing something more useful than my own inbox to that topic, likely an SQS queue or a Lambda function, so the notification actually triggers work instead of just being observed.

Replacing Basic Auth with JWT and OAuth2 in Spring Security

Bilal Bukhari — Fri, 18 Sep 2026 20:17:10 +0000

Basic auth was always the placeholder. It worked, but sending credentials on every single request never sat right — no real session, no expiry, no way to log someone out without changing their password. This week I finally replaced it with JWT, and wired up OAuth2 alongside it.

Why Move Off Basic Auth

The app was already stateless, so on paper basic auth and JWT look similar — no server-side session either way. The difference is what's actually being sent. With basic auth, the raw username and password go out with every request, base64-encoded, which is not encryption, just encoding. With JWT, credentials are exchanged once at login, and after that a signed token carries the identity and role claims — the password never has to leave the client again after that first request.

Implementing JWT

The flow ended up looking like this: a user logs in with username/password, the server verifies it, and issues a signed JWT containing the username and role as claims. Every request after that carries the token in the Authorization: Bearer <token> header instead of credentials.

On the server side, I added a filter that runs before Spring Security's normal authentication step — it pulls the token out of the header, validates the signature, checks it hasn't expired, and if everything checks out, builds an Authentication object from the claims and sets it into the security context. From that point on, the rest of the role-based access control I'd already built (USER vs ADMIN) just works unchanged, because it was always checking the authority on the authenticated principal, not caring how that principal got authenticated in the first place.

That was actually the most satisfying part — the RBAC layer didn't need to be touched at all. Swapping the authentication mechanism underneath it and having the authorization layer keep working exactly as before is a good sign the earlier design was reasonably sound.

Adding OAuth2

Alongside JWT, I set up OAuth2 login so users can authenticate through an external provider instead of only the app's own username/password flow. Spring Security's OAuth2 client support handles most of the heavy lifting here — the redirect to the provider, the callback, and pulling back user info — but I still had to decide how an OAuth2-authenticated user maps onto the same role system as everyone else, since a first-time OAuth2 login doesn't come with a role attached the way a normal registration does.

The approach I landed on: on first OAuth2 login, create a local user record with a default role, so from that point forward they're indistinguishable from a normal registered user as far as the rest of the app is concerned. Two different front doors, same house once you're inside.

Where I Got Stuck

Token expiry handling was the annoying part. It's easy to issue a token that works — it's less obvious, at first, how to handle a client whose token has expired mid-session without just throwing a generic 401 and leaving them confused. I ended up making sure expired-token responses are distinguishable from invalid-token responses, so the client side can actually tell "log in again" apart from "something is wrong," instead of treating every failure the same way.

What's Different Now

Basic auth is gone. Every request now carries a token instead of raw credentials, that token has a real expiry, and there are two legitimate ways to authenticate — direct login or OAuth2 — both of which land in the same role-based system underneath. It's a lot more moving parts than the app had a week ago, but each part is doing something basic auth genuinely couldn't.

Next up: refresh tokens, since right now an expired token just means logging in again from scratch, which isn't going to hold up once this is actually deployed somewhere.

Implementing Role-Based Access Control in Spring Boot — Users, Admins, and Where the Line Gets Drawn

Bilal Bukhari — Tue, 15 Sep 2026 19:53:24 +0000

There's a moment in every backend project where "anyone can call any endpoint" stops being acceptable, and you have to actually decide who gets to see what. That moment hit me this week, and the answer was Spring Security with role-based access control (RBAC).

Here's what I built: a registration system where a user can sign up as either a regular USER or an ADMIN, and depending on which one they are, they see a completely different slice of the application. A regular user can only view their own basic info — username, email, that's it. An admin, on the other hand, can pull up the full list of every registered user in the system.

Simple to describe. Not quite as simple to get right the first time.

Letting Users Pick a Role at Registration

The registration endpoint takes a role field alongside the usual username/password/email — but I didn't want to just trust whatever the client sends blindly forever, since that's an easy way to let anyone register as an admin. For now, at this stage of the project, the role is accepted at signup and stored against the user, tied to Spring Security's GrantedAuthority model, so every user ends up carrying a ROLE_USER or ROLE_ADMIN authority from the moment their account exists.

That authority is what everything downstream checks against — not a name, not a flag scattered through the code, just one consistent thing Spring Security already knows how to reason about.

Locking Down Endpoints by Role

This is where Spring Security actually earns its keep. Instead of writing if (user.getRole().equals("ADMIN")) checks inside every controller method — which gets messy and easy to forget — the access rules live in the security configuration itself:

/api/users/me → accessible to any authenticated user, returns only their own data
/api/admin/users → accessible only to ROLE_ADMIN, returns the full user list

If a regular user tries hitting the admin endpoint directly, Spring Security shuts it down before the request even reaches the controller — a clean 403, no leaked data, no custom guard clause needed. That was honestly satisfying to see work correctly on the first real test.

Worth noting: the app is already configured stateless (no server-side sessions), but JWT isn't in the picture yet — right now, authentication happens via HTTP Basic on each request. It works, but it's clearly a placeholder until token-based auth is in place.

The Part That Actually Took Time

The RBAC rules themselves weren't the hard part — wiring up the UserDetailsService correctly so that authorities actually loaded and attached to the authenticated user on every request was where I spent most of my time. It's one of those things where the code looks fine, compiles fine, and then silently doesn't work because the authority string format doesn't match what the security config is checking for (ADMIN vs ROLE_ADMIN cost me a solid chunk of debugging time — Spring Security expects the ROLE_ prefix by convention, and it fails quietly rather than yelling at you about it).

Why This Matters Beyond the Exercise

This is the first time in this project that "the backend works" and "the backend is secure" stopped being the same statement. A working endpoint that returns data to anyone who asks isn't done — it's just functional. Adding the role layer is what actually makes it something you could put in front of real users without immediately regretting it.

Next up: extending this with proper password hashing policies and actually implementing JWT for authentication — the app is already configured stateless, so this is the natural next piece rather than a rework.

Static Website Hosting on Amazon S3: From Bucket to Live URL

Bilal Bukhari — Mon, 14 Sep 2026 20:07:26 +0000

Continuing from where I left off with S3 fundamentals, today's focus was turning a plain bucket into an actual live website using S3's static website hosting feature — no EC2 instance, no server management, just a bucket serving HTML directly over the web.

Topics Covered

Static website hosting configuration
Index and error documents
Public access blocking
Bucket policies for public reads
Testing the live endpoint

1. Enabling Static Website Hosting

By default, an S3 bucket is just object storage — it doesn't know how to behave like a website. Enabling static website hosting (found under the bucket's Properties tab) turns it into one by telling S3 two things: which file to serve when someone visits the root URL, and which file to show if a requested page doesn't exist.

Once enabled, S3 generates a dedicated website endpoint in the form:

http://<bucket-name>.s3-website.<region>.amazonaws.com

For this lab, I set up the bucket firststaticsite-605365943139-eu-north-1-an in eu-north-1, uploaded a landing page template, and had it live at that endpoint within minutes.

Live demo: http://firststaticsite-605365943139-eu-north-1-an.s3-website.eu-north-1.amazonaws.com/

2. Index and Error Documents

Two settings drive how the site behaves:

Index document — the file served when someone visits the root of the site (almost always index.html).
Error document — an optional custom page shown when a requested file doesn't exist, instead of S3's default XML error.

Getting these right matters more than it seems — a missing or misconfigured index document is one of the most common reasons a freshly enabled static site fails to load.

3. Public Access Block

By default, AWS blocks public access to every new bucket as a safety measure — which makes sense for general storage, but breaks a static website, since visitors need to reach the files without any AWS credentials.

To fix this, Block Public Access has to be explicitly turned off at the bucket level (Permissions tab). This is a deliberate extra step AWS added specifically to prevent people from accidentally exposing private data — so it's a conscious trade-off, not a default you stumble into.

4. Bucket Policy for Public Reads

Turning off Block Public Access alone isn't enough — the bucket also needs an explicit bucket policy granting read access to everyone. Something like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PublicReadGetObject",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::firststaticsite-605365943139-eu-north-1-an/*"
    }
  ]
}

This grants s3:GetObject (read-only) to anyone, scoped strictly to objects inside this one bucket — it doesn't expose anything else in the account.

5. Testing the Live Endpoint

Once hosting is enabled, public access is unblocked, and the policy is in place, the site becomes reachable by anyone with the URL — not just the account owner logged into the AWS console. That last part is an easy trap: a page can look "live" while you're logged in and still fail for an outside visitor if permissions aren't fully open. Testing in an incognito window (or asking someone else to open the link) is the real test of whether the site is actually public.

Summary

Static website hosting is a good next step after learning buckets and objects, because it forces you to actually deal with the permission model instead of just uploading files. The distinction between "the object exists in the bucket" and "the object is publicly reachable" is the core lesson here, and it's one that carries over directly into more advanced AWS work later on — IAM policies, CloudFront distributions, and beyond.

Amazon S3 Fundamentals: Buckets, Objects, Storage Classes, and Access Control

Bilal Bukhari — Sun, 13 Sep 2026 18:57:32 +0000

Amazon S3 (Simple Storage Service) is typically the first AWS service most engineers encounter when they begin working with cloud infrastructure. It is deceptively simple on the surface, but has considerable depth once access control, storage tiering, and cost optimization enter the picture. This post covers the core S3 concepts I worked through, supported by a short hands-on lab.

Topics Covered

Buckets
Objects
Uploading files
Storage classes
Bucket policies
ACLs and permissions

1. Buckets

A bucket is the top-level container in S3 — the root under which every object is stored. Bucket names must be globally unique across all of AWS, not just within a single account, which is why they often follow a pattern like firstbucket-<account-id>-<region>.

Each bucket is also tied to a specific region at creation time (e.g., eu-north-1, Stockholm). This choice affects latency, cost, and data residency, since the underlying data physically resides in that region's data centers.

For this lab, I created a bucket named firstbucket-605365943139-eu-north-1-an. Immediately after creation, it was empty — zero objects — and ready to receive uploads.

2. Objects

Everything you store inside a bucket — images, videos, documents, backups, logs — is called an object. Each object consists of:

The data itself (the file)
A key (essentially its full path/name inside the bucket)
Metadata (content type, size, last modified date, etc.)

There's no real folder structure in S3 under the hood — folders are a UI convenience. What actually exists is a flat namespace of keys, and prefixes (like images/photo.jpg) just simulate folder hierarchy.

3. Uploading

Uploading is the process of adding an object to a bucket. In the AWS console, this is a straightforward Upload action, though the same operation is typically automated through the CLI or an SDK in production systems.

For this lab, I uploaded two JPEG images directly into the bucket. Once uploaded, S3 surfaces key metadata for each object — type, size, last modified timestamp, and storage class:

Name	Type	Size	Storage Class
WhatsApp Image ...11.01.41 PM.jpg	jpeg	201.5 KB	Standard
WhatsApp Image ...11.17.02 PM.jpeg	jpeg	123.0 KB	Standard

4. Storage Classes

Not all data needs to be instantly available all the time, and S3 gives you multiple storage classes to balance cost vs. retrieval speed:

S3 Standard — frequently accessed data, highest availability, most expensive.
S3 Intelligent-Tiering — automatically moves objects between tiers based on access patterns.
S3 Standard-IA / One Zone-IA — infrequently accessed data, cheaper storage but a retrieval fee.
S3 Glacier / Glacier Deep Archive — long-term archival, very cheap storage, but retrieval can take minutes to hours.

By default, newly uploaded objects land in Standard, which is exactly what I saw in the lab. Picking the right class for the right data is one of the easiest ways to cut cloud storage costs.

5. Bucket Policies

A bucket policy is a JSON document attached to the bucket itself that defines who can do what — for example, allowing public read access to a bucket used for a static website, or restricting access to specific IAM roles or AWS accounts.

Because a bucket policy applies at the bucket level, it's the go-to tool when you want a single, centralized rule for everything inside that bucket (e.g., "only this Lambda function's role can write objects here").

6. ACLs and Permissions

Access Control Lists (ACLs) are an older, more granular way to control access — at the level of individual buckets or individual objects. They predate bucket policies and IAM, and AWS now recommends disabling ACLs in favor of bucket policies and IAM policies for most use cases, since ACLs can get messy to manage at scale.

Broadly, S3 access boils down to three tools working together:

IAM policies — control what an AWS identity (user/role) can do across services.
Bucket policies — control access to a specific bucket.
ACLs — legacy, fine-grained access on buckets/objects (mostly discouraged today).

Understanding how these layers interact — and that they're evaluated together, not in isolation — is one of the more important "aha" moments when learning S3.

Summary

This lab was intentionally small in scope, but it establishes the core mental model required before working with S3 in more advanced contexts — static website hosting, data lake architectures, or backend integrations. The next step in this learning path is exploring IAM in more depth and integrating S3 into a Spring Boot application.

If you're working through AWS fundamentals as well, I'd be interested to hear which concept took longest to click. For me, it was distinguishing bucket policies, ACLs, and IAM policies — three mechanisms that all govern access, but at different layers and with different intended use cases.