DEV Community: Bilal Bukhari

Building Secure AWS Cloud Networking: VPC Peering, Private EC2, NAT Gateway, and S3 Gateway Endpoint

Bilal Bukhari — Sat, 17 Oct 2026 12:17:44 +0000

A Hands-On Implementation of Multi-VPC Connectivity, Controlled Internet Access, IAM-Based Authentication, and Private AWS Service Routing

By Syed Bilal Bukhari
Cloud Computing / AWS / Cloud Networking · Foundational to Intermediate · Region: US East (N. Virginia), us-east-1

Introduction

In cloud networking, "it connects" and "it connects the way I intended" are different statements. A packet leaving an EC2 instance is steered by route tables, filtered by security groups, translated by gateways, and authorized (for AWS APIs) by IAM. When something fails, the cause sits in one of those layers, and you can only find it if you know which path the traffic is supposed to take.

I built this lab to make those paths explicit. It has two VPCs in us-east-1, one public EC2 instance, and one private EC2 instance with no public IPv4 address. The private instance has three jobs: talk to the public VPC over VPC Peering, reach the internet outbound-only through a NAT Gateway, and reach Amazon S3 using an IAM role instead of stored access keys.

This is a foundational-to-intermediate lab, not a production design. I will point out where it falls short as I go. I will also separate what the AWS Console configuration shows from what the terminal tests prove, because those are two different kinds of evidence.

Project Objectives

Give the public EC2 instance internet access through an Internet Gateway.
Connect two VPCs privately using VPC Peering, with non-overlapping CIDR blocks.
Reach the private EC2 instance over SSH through the public instance as a jump host.
Let the private instance start outbound internet connections through a NAT Gateway, without a public IP.
Add an S3 Gateway Endpoint so S3-bound traffic from the private route table has a dedicated route.
Authenticate the private instance to AWS with an IAM role rather than permanent access keys.
Validate each step with real terminal tests and Console configuration.

AWS Services and Tools

Component	What it did in this lab
Amazon VPC (two VPCs)	Isolated networks: `mys-vpc-001` and `myp-vpc-002`
Subnets and route tables	Decide what is "public" or "private" through their routes
Internet Gateways	One per VPC; the target for internet-routable traffic
VPC Peering	Private routing between the two VPCs
NAT Gateway + Elastic IP	Outbound-only IPv4 internet access for the private subnet
S3 Gateway VPC Endpoint	Route-table target for regional S3 traffic
IAM role	Temporary credentials for the private instance
Security Groups	Instance-level traffic filtering (ICMP, SSH)
EC2 (t3.micro, Amazon Linux 2023)	One instance in each VPC
MobaXterm, ping, curl, AWS CLI	SSH access and connectivity verification

Architecture Overview

Figure 1. Architecture of the lab. Orange arrows are internet-bound traffic, the dashed blue line is inter-VPC traffic over peering, and green arrows are S3 traffic through the Gateway Endpoint. The private EC2 instance has no direct path to an Internet Gateway; its internet traffic goes through the NAT Gateway first.

	Public VPC	Private VPC
Name / CIDR	`mys-vpc-001` / 10.0.0.0/24	`myp-vpc-002` / 10.0.1.0/24
Subnets	`mys-subnet-01` 10.0.0.0/28 (us-east-1a)	`myp-private-subnet-002` 10.0.1.0/28 and `myp-nat-public-subnet` 10.0.1.16/28 (both us-east-1b)
EC2	`my-public-ec2`, 10.0.0.6, public IPv4	Private EC2, 10.0.1.6, no public IPv4
Gateways	Internet Gateway	`myp-igw-002`, NAT Gateway `myp-nat-gateway-002` (10.0.1.22 + Elastic IP)

Public VPC Configuration

The Public VPC has one public subnet. The instance my-public-ec2 is a t3.micro running Amazon Linux 2023, with private IP 10.0.0.6 and a public IPv4 address. I reached it over SSH with key authentication from MobaXterm. It plays two roles: the internet-facing test host and the jump host for the private instance.

Figure 2. The EC2 console showing running t3.micro instances that passed 3/3 status checks. my-public-ec2 is in us-east-1a; the instance used for private-side testing is in us-east-1b.

A subnet is public because of its route table, not its name. mys-public-rt sends VPC-local traffic locally, sends 0.0.0.0/0 to the Internet Gateway, and sends 10.0.1.0/24 to the peering connection.

Figure 3. mys-public-rt (captured from the Edit routes view). All three routes are Active: local, 10.0.1.0/24 via the peering connection, and 0.0.0.0/0 via the Internet Gateway.

Private VPC Configuration

The VPC is called "Private VPC", but that name is only a label. Whether a subnet is public or private depends on its route table. This VPC deliberately contains one of each:

myp-private-subnet-002 (10.0.1.0/28) holds the private EC2 instance at 10.0.1.6. Its route table has no route to an Internet Gateway.
myp-nat-public-subnet (10.0.1.16/28) holds only the NAT Gateway. Its route table, myp-nat-public-rt, has a default route to the Internet Gateway myp-igw-002, which makes it a public subnet.

Figure 4. The Private VPC resource map: two subnets in us-east-1b, three route tables, and the connections myp-igw-002, myp-nat-gateway-002 (public NAT, one ENI and one EIP) and myp-s3-endpoint (gateway endpoint to S3). The right edge of the original capture is cut off.

VPC Peering

Concepts

VPCs are isolated by default. A VPC Peering connection creates a private routing path between two VPCs using private IP addresses. It is not a gateway and not a VPN, and it does not provide internet access.

Four properties shaped the design:

Non-overlapping CIDRs are mandatory. If both VPCs used the same range, a route for that range could not say which VPC a destination belongs to. Here the VPCs use 10.0.0.0/24 and 10.0.1.0/24.
Request and accept. One VPC (the requester, mys-vpc-001) asks and the other (the accepter, myp-vpc-002) accepts. Until it is accepted, the connection is not usable.
Both sides need routes. An Active peering connection only creates the possibility of traffic. Each VPC's route table needs a route to the other VPC's CIDR with the peering connection as the target.
Peering is not transitive. AWS documents that two VPCs cannot use a third, peered VPC as a transit path. Peering also does not bypass Security Groups or Network ACLs, which still filter the traffic.

Figure 5. public-private-peering (pcx-0763ca5cff1e5a68e) in Active status, with requester VPC vpc-044079de0026185ef. The accepter column is off-screen in this capture, so the accepter details come from my project notes.

Routes on both sides

The Public VPC's route (Figure 3) sends 10.0.1.0/24 to the peering connection. The Private VPC's route table, myp-private-rt-002, has the mirror route plus two more:

Destination	Target	Purpose
10.0.1.0/24	local	Traffic inside the Private VPC
10.0.0.0/24	Peering connection	Traffic to the Public VPC
0.0.0.0/0	NAT Gateway `nat-04d646b2df4be7880`	Everything else, IPv4
`pl-63a5400a`	Gateway endpoint `vpce-0f6dfcad71b59e9d9`	S3 (regional prefix list)

Figure 6. myp-private-rt-002 with all four routes Active. This is also the evidence that the S3 prefix-list route exists (see the S3 section).

AWS picks the most specific matching route (longest prefix match). A packet to 10.0.0.6 matches 10.0.0.0/24 and goes over peering, not to the NAT Gateway, even though 0.0.0.0/0 also matches. A packet to an S3 address falls in a range from the S3 prefix list, which is more specific than 0.0.0.0/0, so it takes the endpoint route. Anything else falls through to the NAT Gateway.

Reachability test

From the public instance (10.0.0.6) I pinged the private instance:

ping -c 4 10.0.1.6

Figure 7. Four packets transmitted, four received, 0% loss. Replies took between 0.452 and 0.468 ms. The final min/avg/max line is cut off in my capture; the mean of the four replies is about 0.457 ms.

This proves ICMP reachability between instances in separate VPCs. It does not prove that every application port works, because ping only exercises ICMP. The first attempts were blocked until I added the right Security Group rule (see Challenges).

SSH Access Between VPCs

I confirmed that the public instance could reach port 22 on the private instance over the peering link. For access from my own machine I used MobaXterm's SSH gateway (jump host) feature, which opens the session to the private address through the public instance, so the private machine never needs a public IPv4 address. I did not copy the private key onto the jump host.

Port 22 on the private instance should accept connections only from the jump host's side, not from 0.0.0.0/0. I did not capture screenshots of the Security Group rules, so I am describing that intent rather than showing the rule set.

NAT Gateway for Outbound Internet Access

The private instance has no public IP, so by itself it cannot reach the internet. A public NAT Gateway in a public subnet fixes that:

Private EC2 → private route table → NAT Gateway → Internet Gateway → Internet

Why each piece is there:

The NAT Gateway is in a public subnet (myp-nat-public-subnet) because it needs a route to an Internet Gateway, and it has an Elastic IP that serves as its public address.
The NAT subnet's route table points to myp-igw-002. Without that, the NAT Gateway has no way out.
The private instance keeps only its private IP. The NAT Gateway translates its source address on the way out and maps replies back.
Inbound is limited by design. AWS documents that connections through a NAT Gateway must start from inside the VPC, so unsolicited inbound connections from the internet cannot reach the private instance this way.

A NAT Gateway does not replace Security Groups, and it is not application-level security. It simply provides address translation for outbound IPv4.

Figure 8. myp-nat-gateway-002 in Available state: connectivity type Public, private IPv4 10.0.1.22, in myp-nat-public-subnet of myp-vpc-002. The account ID in the ARN and the Elastic IP are redacted.

From the private instance:

curl -I --max-time 15 https://www.google.com

Figure 9. HTTP/2 200 received from the private EC2 prompt (ip-10-0-1-6). I cropped the screenshot to remove the cookie headers that followed.

Before the routing was right, this same command timed out. That is covered in Challenges.

S3 Gateway Endpoint and IAM Role

The endpoint

A VPC endpoint lets resources in a VPC reach an AWS service without going over the public internet path. There are two types: Interface endpoints (an ENI with private IPs in your subnet, powered by PrivateLink) and Gateway endpoints (a route-table target, available for S3 and DynamoDB). I used a Gateway endpoint because it fits the lab: it needs no ENI in my subnet, and AWS states there is no additional charge for it.

Because it works through routing, it is associated with route tables. When I associated myp-private-rt-002, AWS added the route pl-63a5400a → vpce-0f6dfcad71b59e9d9, where pl-63a5400a is the managed prefix list for regional S3 addresses. That route is visible in Figure 6.

Figure 10. myp-s3-endpoint (vpce-0f6dfcad71b59e9d9): type Gateway, service com.amazonaws.us-east-1.s3, VPC myp-vpc-002, status Available.

Three limits are worth stating. The endpoint covers S3 only, so other traffic still needs the NAT Gateway. It serves only the route tables it is associated with, and AWS documents that resources across a peering connection cannot use it. And an endpoint policy and an IAM policy do different jobs: one limits what can pass through the endpoint, the other limits what the caller may do. My screenshots show no custom endpoint policy, so I am not claiming one was applied.

The IAM role

Initially, aws configure list showed that credentials were not configured. After attaching an IAM role to the private instance, it reported:

access_key : ************ : iam-role
secret_key : ************ : iam-role
region     : us-east-1    : imds

The credentials come from the EC2 Instance Metadata Service as temporary credentials that rotate, so no access key is stored on disk. This is the approach AWS recommends over putting long-term keys on an instance. The network endpoint and IAM are separate: the endpoint provides a route; IAM decides whether the call is allowed.

My screenshots do not show the role's name or policy, so I am not stating what permissions it had. For a production version I would scope the role to the specific bucket and actions, for example s3:ListBucket on one bucket and s3:GetObject on the prefixes actually needed, rather than broad S3 access. Note that aws s3 ls with no arguments also needs s3:ListAllMyBuckets, which a tightly scoped role might deliberately omit.

S3 listing

aws s3 ls s3://supplychain-de-2026-pk84726/

Figure 11. The private instance lists the historical/ and raw/ prefixes of an existing bucket.

I want to be precise about what this shows. The listing proves authenticated S3 API access from the private instance. The route table (Figure 6) shows that the intended network path for S3 addresses is the Gateway Endpoint. But the private subnet also has a NAT default route, so this command would likely have worked through NAT too. I did not run a packet trace or flow-log analysis, so I am not claiming that this specific request used the endpoint. To prove that, I would temporarily remove the NAT default route and confirm the S3 listing still works while curl to Google fails.

Validation and Testing

Test	Command (run from)	Observed result	Evidence
A. Public EC2 internet	`curl -I --max-time 15 https://www.google.com` (public EC2)	`HTTP/2 200`	Recorded in my notes; not pictured
B. Peering reachability	`ping -c 4 10.0.1.6` (10.0.0.6)	4 sent, 4 received, 0% loss	Figure 7
C. SSH reachability	SSH to port 22 on 10.0.1.6; MobaXterm jump host	Connected	Recorded in my notes; not pictured
D. Private EC2 internet via NAT	`curl -I --max-time 15 https://www.google.com` (10.0.1.6)	`HTTP/2 200`	Figure 9
E. AWS CLI present	`aws --version`	AWS CLI 2.36.47	Recorded in my notes; not pictured
F. IAM role credentials	`aws configure list`	Credentials from `iam-role`; region from `imds`	Recorded in my notes; not pictured
G. S3 service access	`aws s3 ls`	Listed an accessible bucket	Recorded in my notes; not pictured
H. S3 prefix listing	`aws s3 ls s3://supplychain-de-2026-pk84726/`	`PRE historical/`, `PRE raw/`	Figure 11

Console figures (3 to 6, 8, 10) show how the network is configured; the terminal tests (B, D, H) show that traffic and API calls worked.

Challenges and Troubleshooting

Overlapping VPC CIDR blocks. My first pair of VPCs had overlapping ranges. VPC Peering requires non-overlapping CIDRs, so that pair could not be peered as designed. I created a replacement VPC, myp-vpc-002, with 10.0.1.0/24, which is the one used throughout this article.

Peering "Pending Acceptance" and a blackhole route. A route that points at a peering connection that has not been accepted shows a blackhole status. The cause was the pending request; accepting it moved the connection to Active, and the routes then showed Active (Figures 3 and 6).

Ping blocked by Security Groups. The route was in place, but ICMP did not get through until I added the appropriate Security Group rule. Routing and filtering are separate layers, and peering does not bypass the filter.

NAT internet access timed out. Before the route-table configuration was corrected, curl from the private instance timed out. Two routes have to be right for this path: the private route table's default route to the NAT Gateway, and the NAT subnet's default route to the Internet Gateway. After correcting the routing, the same command returned HTTP/2 200.

AWS CLI credentials missing. The instance had no role, so the CLI had no credentials. Attaching an IAM role fixed it, and aws configure list then showed iam-role.

S3 endpoint route verification. After creating the endpoint, I checked the private route table and confirmed the pl-63a5400a route was Active rather than assuming the association worked.

Security Considerations

Subnet isolation. The private instance has no public IPv4 address and no inbound route from the internet. Its only inbound path is over the peering link, including SSH forwarded through the jump host.
Security Groups remain the instance-level control. Port 22 should be limited to the jump host, and ICMP opened only as needed.
The jump host concentrates access in one place, but it is itself an exposed system that needs patching and restriction. A managed option such as AWS Systems Manager Session Manager could avoid an open SSH port; I did not implement it.
IAM roles avoid stored keys but still need least-privilege policies, which I have described rather than demonstrated.
NAT blocks unsolicited inbound connections but does not filter outbound traffic by destination.
An S3 endpoint policy could restrict which buckets are reachable; I have not shown one.

The tests show the network behaves as designed on the paths I tested. That does not make the design hardened.

Cost Considerations

A lab like this is cheap only while you remember to remove it.

NAT Gateway is billed per hour while it exists, plus per GB processed. In a small lab it is usually the largest line item.
Public IPv4 addresses, including the NAT Gateway's Elastic IP and the public instance's address, are billed.
EC2 t3.micro instances accrue instance-hours while running.
Data transfer. AWS documents that peering traffic within one Availability Zone is free. My instances sit in different AZs (us-east-1a and 1b), so inter-AZ charges could apply to larger transfers; my ping and curl tests are trivial. The NAT Gateway is in the same AZ as the private instance, which avoids an extra cross-AZ hop on that path.
The S3 Gateway Endpoint has no additional hourly or processing charge.

Prices change, so check the VPC pricing page rather than trusting figures in an article. When you finish, terminate the instances, delete the NAT Gateway, and release its Elastic IP, which keeps billing if left allocated.

Key Lessons Learned

A route table defines "public" and "private". The Private VPC contains a public subnet because the NAT Gateway needs one.
An Active peering connection moves no packets by itself. It needs routes on both sides and permissive Security Groups.
A timeout usually points at a missing route. The NAT timeout was a routing problem, not a problem with the destination.
Longest-prefix matching lets the routes coexist. The peer CIDR and the S3 prefix list win over the 0.0.0.0/0 default.
Configuration evidence and test evidence answer different questions. A successful aws s3 ls does not by itself show which path carried the request.
Connectivity and authorization fail separately. The endpoint gave a route; the IAM role gave permission.

Conclusion

The lab verified these outcomes: the public instance reached the internet; two non-overlapping VPCs were joined by an Active peering connection with a 4/4 ping and 0% loss; the private instance, with no public IPv4 address, made outbound HTTPS requests through a NAT Gateway; and it listed an S3 bucket's prefixes using IAM role credentials, with an Active S3 Gateway Endpoint route in its route table.

A production-oriented version would add NAT Gateways per Availability Zone (or the regional NAT option), least-privilege IAM and an S3 endpoint policy, documented Security Group rules, a managed access path instead of an SSH jump host, VPC Flow Logs, and infrastructure-as-code. I also have not shown that S3 requests used the endpoint, which a route-removal test or flow logs could settle.

References

Amazon VPC documentation: https://docs.aws.amazon.com/vpc/
VPC peering connections: https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html
What is VPC peering (Peering Guide): https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/Welcome.html
VPC peering, connectivity options whitepaper: https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/vpc-peering.html
Configure route tables: https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Route_Tables.html
How route priority works: https://docs.aws.amazon.com/vpc/latest/userguide/route-tables-priority.html
Internet gateways: https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html
NAT gateways: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html
Gateway endpoints: https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html
Gateway endpoints for Amazon S3: https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-s3.html
IAM roles for Amazon EC2: https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-usingrole-ec2instance.html
Amazon VPC pricing: https://aws.amazon.com/vpc/pricing/

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.