DEV Community: Micheal Angelo

From Local FastAPI to AWS: Deploying a Dockerized Backend with ECR, ECS Fargate, and RDS PostgreSQL

Micheal Angelo — Sun, 09 Aug 2026 17:17:53 +0000

Deploying an application to the cloud for the first time can feel overwhelming.

There are containers, container registries, networking, IAM, databases, security groups, task definitions, services, and many other concepts that need to work together.

This article documents my first end-to-end AWS deployment.

I took a FastAPI backend running locally, containerized it with Docker, pushed the image to Amazon ECR, deployed it using Amazon ECS with AWS Fargate, and connected it to PostgreSQL running on Amazon RDS.

The goal wasn't simply to get an application running on AWS.

I wanted to understand what actually happens when a locally developed backend becomes a cloud-hosted application.

Starting Point: A FastAPI Application

The application started as a normal FastAPI backend running on my local machine.

The basic architecture was:

Client
   │
   ▼
FastAPI
   │
   ▼
PostgreSQL

Locally, I could start the application with Uvicorn and connect it to a PostgreSQL database running on my machine.

This is convenient for development, but eventually the application needs to run somewhere other than my laptop.

That raised the first question:

How do I move this application to AWS?

Step 1 — Containerizing the Application

The first step was to package the FastAPI application into a Docker container.

Instead of depending on my local Python installation, virtual environment, and manually installed packages, Docker allows the application and its dependencies to be packaged together.

The conceptual architecture becomes:

FastAPI Application
        │
        ▼
    Dockerfile
        │
        ▼
   Docker Image

The Docker image contains the application code, Python environment, dependencies, and the instructions required to start the application.

This gives us a consistent artifact that can be moved between environments.

Instead of asking:

"Does this server have the correct Python version and dependencies?"

we can ask:

"Can this server run the Docker image?"

That is a much simpler deployment model.

Step 2 — Amazon ECR

Once the Docker image was created locally, the next problem was:

Where should the image be stored?

This is where Amazon Elastic Container Registry (ECR) comes in.

ECR is a managed container registry provided by AWS.

The workflow becomes:

Developer Laptop
       │
       │ docker build
       ▼
   Docker Image
       │
       │ docker push
       ▼
     Amazon ECR

ECR acts as the place where AWS can retrieve the container image when deploying the application.

The important distinction is:

ECR stores the image.

It does not run the application.

Step 3 — Amazon ECS

After storing the image in ECR, we need something that can actually run it.

This is where Amazon Elastic Container Service (ECS) comes in.

ECS is a container orchestration service.

It manages the deployment and operation of containers.

Conceptually:

Amazon ECR
     │
     │ Pull Image
     ▼
Amazon ECS
     │
     ▼
Container

However, ECS itself does not necessarily provide the underlying compute capacity.

That brings us to Fargate.

Step 4 — AWS Fargate

AWS Fargate allows ECS containers to run without us having to manage EC2 servers ourselves.

With a traditional EC2-based deployment, we would need to manage:

EC2
 ├── Operating System
 ├── Docker
 ├── Security Updates
 ├── Container Runtime
 └── Application

With Fargate, AWS manages the underlying compute infrastructure.

We primarily define:

Which container image should run
How much CPU it needs
How much memory it needs
Which ports it uses
Which IAM permissions it requires
Which networking configuration it should use

The architecture becomes:

Amazon ECR
     │
     ▼
ECS Task
     │
     ▼
AWS Fargate
     │
     ▼
FastAPI Container

This was one of the important distinctions I learned:

ECS manages the containers, while Fargate provides the serverless compute capacity for those containers.

Step 5 — Connecting PostgreSQL with Amazon RDS

The FastAPI application also needed a database.

Instead of continuing to use PostgreSQL running on my laptop, I moved the database to Amazon RDS.

Amazon RDS is a managed relational database service.

The architecture now looked like:

             AWS
              │
       ┌──────┴──────┐
       │             │
       ▼             ▼
 ECS Fargate       RDS
       │          PostgreSQL
       │
   FastAPI

The FastAPI container communicates with PostgreSQL over the AWS network.

This introduced an important networking concept.

The application and database don't simply communicate because they are both "inside AWS."

They need appropriate networking and security configuration.

Understanding the Network

This was one of the most important parts of the deployment.

A simplified architecture looked like:

Internet
    │
    ▼
AWS Networking
    │
    ▼
ECS Fargate
    │
    │ PostgreSQL connection
    ▼
RDS PostgreSQL

The ECS task and RDS instance need to be able to communicate with each other through the configured network.

This means understanding concepts such as:

VPC
Subnets
Security Groups
IP addresses
Ports
Inbound rules
Outbound rules

For PostgreSQL, the default port is:

The database security configuration therefore needs to allow the appropriate application traffic to reach that port.

This was a good reminder that deploying an application isn't simply about putting a Docker container somewhere.

The components need to be able to communicate securely.

Security Groups

Security Groups act as virtual firewalls for AWS resources.

For example, the RDS database should not simply allow PostgreSQL traffic from the entire Internet.

Instead, the goal is to allow only the traffic that actually needs access to the database.

Conceptually:

Internet
   X
   │
   │ PostgreSQL traffic
   │
   ▼
RDS PostgreSQL

Only trusted application traffic
should be allowed to reach port 5432.

This follows an important security principle:

Allow only the traffic that is actually required.

IAM and Permissions

Another major part of the deployment was IAM — Identity and Access Management.

AWS resources should not simply have unrestricted access to everything else.

Instead, AWS uses identities and policies to determine what actions are permitted.

For example, the ECS task may need permission to:

Pull an image from ECR
Write logs to CloudWatch
Access other AWS services when required

This is where IAM roles become important.

Rather than embedding AWS credentials inside the application container, AWS allows services to assume IAM roles.

Conceptually:

ECS Task
   │
   ▼
IAM Role
   │
   ▼
AWS Permissions

This is much safer than putting long-lived access keys directly inside the application.

Task Definitions

One of the concepts I had to understand while working with ECS was the Task Definition.

A task definition describes how an ECS task should run.

It specifies information such as:

Container image
CPU
Memory
Port mappings
Environment variables
IAM roles
Logging configuration

Conceptually:

Task Definition
       │
       ├── Container Image
       ├── CPU
       ├── Memory
       ├── Ports
       ├── Environment
       └── IAM Configuration

ECS uses this definition to know how to launch the container.

ECS Service

A task is a running instance of the container configuration.

An ECS Service manages the desired number of running tasks.

For example:

ECS Service

Desired Tasks = 1

        │
        ▼

   FastAPI Task

If we later configure:

Desired Tasks = 3

ECS can maintain multiple running tasks.

This is where ECS begins to become useful for building scalable containerized applications.

Environment Variables

The application also needs configuration such as:

DATABASE_HOST
DATABASE_PORT
DATABASE_NAME
DATABASE_USER
DATABASE_PASSWORD

These values should not be hardcoded into the application.

Instead, the container receives configuration through its runtime environment.

This creates another useful separation:

Application Code
       +
Environment Configuration

The same Docker image can therefore be deployed to different environments with different configuration.

The Complete Deployment Flow

After putting all the pieces together, the deployment flow becomes:

Developer
    │
    ▼
FastAPI Application
    │
    ▼
Docker Build
    │
    ▼
Docker Image
    │
    ▼
Amazon ECR
    │
    ▼
Amazon ECS
    │
    ▼
AWS Fargate
    │
    ▼
FastAPI Container
    │
    ▼
Amazon RDS
    │
    ▼
PostgreSQL

Each component has a specific responsibility.

Docker
→ Packages the application

ECR
→ Stores the Docker image

ECS
→ Manages the container workload

Fargate
→ Provides serverless compute for the container

RDS
→ Runs managed PostgreSQL

IAM
→ Controls permissions

VPC / Security Groups
→ Control network communication

What Made This Deployment Difficult?

The difficult part wasn't writing the FastAPI application.

The challenging part was understanding how all the infrastructure pieces fit together.

A locally running application can feel deceptively simple:

FastAPI
   │
   ▼
PostgreSQL

In AWS, the architecture becomes much more explicit:

                    AWS
                     │
              ┌──────┴──────┐
              │             │
              ▼             ▼
          ECS/Fargate      RDS
              │          PostgreSQL
              │
          FastAPI
              │
              ▼
        Network + IAM

Every connection has to be intentionally configured.

The deployment therefore became an exercise in understanding infrastructure rather than simply moving code from one machine to another.

The Biggest Lessons

This was my first end-to-end deployment of a FastAPI backend to AWS, and several concepts became much clearer after actually building it.

1. Docker separates the application from the machine

The application becomes a portable artifact rather than a collection of files that must be manually configured on every server.

2. ECR and ECS have different responsibilities

ECR stores container images.

ECS runs and manages containers.

They solve different problems.

3. Fargate removes server management

I don't need to manually manage an EC2 instance just to run my Docker container.

4. RDS separates database infrastructure from the application

The FastAPI application doesn't need to run PostgreSQL itself.

AWS manages the database infrastructure through RDS.

5. Networking is part of application deployment

A backend and database don't communicate automatically just because they are both hosted on AWS.

VPC configuration, subnets, routes, security groups, ports, and connectivity all matter.

6. IAM is fundamental

Cloud applications need controlled access between services.

IAM roles and policies provide that control without requiring applications to store long-lived credentials.

From Localhost to AWS

The most interesting part of this project was seeing how familiar local development concepts map to AWS infrastructure.

Locally:

Laptop
 │
 ├── FastAPI
 │
 └── PostgreSQL

In AWS:

AWS
 │
 ├── ECS + Fargate
 │      └── FastAPI Container
 │
 └── RDS
        └── PostgreSQL

And the container image moves through:

Local Docker
     │
     ▼
Amazon ECR
     │
     ▼
ECS + Fargate

The application itself didn't fundamentally change.

The infrastructure around it did.

That was probably the biggest lesson from this deployment.

Final Thoughts

Before working on this project, services such as ECR, ECS, Fargate, RDS, IAM, and VPC felt like separate AWS concepts.

After deploying the application, they started to make sense as pieces of one larger system.

A cloud deployment isn't simply:

"Put the application on AWS."

It is a collection of decisions about:

Where the application runs
How it is packaged
Where the image is stored
How containers are managed
Where the database lives
How services communicate
Which permissions they have
How network traffic is controlled

This deployment gave me my first practical understanding of how those pieces fit together.

And more importantly, it showed me that moving from local development to the cloud is not just about learning AWS services.

It is about learning how applications, infrastructure, networking, security, and deployment processes work together.

Conclusion

This was my first end-to-end AWS deployment of a Dockerized FastAPI backend.

The final stack consisted of:

FastAPI
   │
   ▼
Docker
   │
   ▼
Amazon ECR
   │
   ▼
Amazon ECS
   │
   ▼
AWS Fargate
   │
   ▼
PostgreSQL
   │
   ▼
Amazon RDS

Along the way, I learned about Docker images, container registries, ECS task definitions, Fargate, RDS, IAM, VPC networking, security groups, environment configuration, and the overall deployment lifecycle.

For me, this was the point where AWS stopped feeling like a list of services and started feeling like an actual infrastructure platform.

I Built an Application—Should I Deploy It on EC2, ECS + Fargate, or AWS Lambda?

Micheal Angelo — Tue, 28 Jul 2026 08:46:24 +0000

One question kept coming up while I was learning AWS.

After building an application, where should it actually run?

AWS offers several compute services, but three appear repeatedly:

Amazon EC2
Amazon ECS with AWS Fargate
AWS Lambda

Initially they all seemed to do the same thing—they execute code.

The more I learned, the more I realised they represent three different deployment models rather than three competing services.

This article explains the mental model that helped me understand when each one makes sense.

Every Application Needs Compute

Regardless of whether you're building a REST API, processing uploaded images, or running background jobs, somewhere there must be a computer executing your code.

AWS offers different ways to provide that compute.

The question isn't:

Which service is the best?

Instead, the better question is:

Which execution model matches my application?

Option 1: Amazon EC2

Amazon EC2 gives you a virtual machine.

Inside that virtual machine you install:

Linux (or Windows)
Docker (optional)
Your application
Any additional software you need

Conceptually:

Amazon EC2
      │
      ▼
EC2 Instance
      │
      ▼
Ubuntu Linux
      │
      ▼
FastAPI / Node.js / Spring Boot

With EC2 you are responsible for managing the server.

That includes operating system updates, security patches, monitoring, backups, scaling, and maintenance.

When EC2 Makes Sense

EC2 is often a good choice when:

Your application runs continuously.
You need complete control over the operating system.
You install custom software.
You require GPU instances.
You need SSH access.

Typical examples include:

Web applications
Jenkins
GitLab
Minecraft servers
Machine learning servers

The biggest advantage is flexibility.

The trade-off is operational responsibility.

Option 2: AWS Lambda

Lambda follows a completely different execution model.

Instead of creating a server, you upload only your code.

Whenever an event occurs, AWS creates the execution environment, runs your function, returns the result, and then releases the compute resources.

Conceptually:

Event
   │
Start Function
   │
Execute Code
   │
Return Result
   │
Stop

Unlike EC2, no server sits waiting for requests.

Compute exists only while the function is running.

When Lambda Makes Sense

Lambda works particularly well for workloads that are:

Event-driven
Short-lived
Stateless

Common examples include:

Processing uploaded files
Sending emails
Scheduled tasks
Payment processing
API Gateway integrations
Image resizing

One major advantage is that there are no servers to manage.

AWS automatically provisions infrastructure whenever the function is invoked.

Option 3: Amazon ECS with AWS Fargate

Suppose you've already containerised your application using Docker.

You don't necessarily want to manage Linux servers, but you also don't want to rewrite the application as Lambda functions.

This is where ECS and Fargate become useful.

Amazon ECS manages containers.

AWS Fargate provides the compute needed to run those containers.

You simply provide a Docker image.

AWS handles the underlying infrastructure.

Conceptually:

Docker Image
      │
      ▼
Amazon ECS
      │
      ▼
AWS Fargate
      │
      ▼
Running Container

This provides many of the benefits of containers without requiring direct server administration.

When ECS + Fargate Makes Sense

Fargate is often a good choice when:

Your application already runs in Docker.
You want containers without managing Linux servers.
Your application runs continuously.
You're building microservices.

It provides a balance between the flexibility of containers and the convenience of managed infrastructure.

Comparing the Three

Requirement	Recommended Service
Need a virtual machine	Amazon EC2
Running Docker containers without managing servers	Amazon ECS + AWS Fargate
Event-driven function execution	AWS Lambda

Rather than replacing one another, these services address different architectural needs.

A Helpful Mental Model

One way I started thinking about these services was by asking what remains active while the application waits.

With a traditional web application:

Start Server
      │
Waiting...
      │
Receive Request
      │
Process
      │
Waiting...

The server is always running.

With Lambda:

Event
   │
Execute
   │
Finish

There is no continuously running server.

Execution begins only when an event occurs.

Background Processing

Another interesting distinction appears when using Amazon SQS.

With a traditional application:

Server
   │
Waiting
   │
Request
   │
Response

The application waits for work.

With SQS and Lambda:

Message
   │
SQS Queue
   │
Lambda Starts
   │
Process Message
   │
Lambda Stops

Instead of the server waiting, the queue stores work until Lambda is triggered.

This architecture is particularly useful for asynchronous tasks that don't need an immediate response.

So Which One Should You Choose?

Over time, I realised that the decision is usually simpler than it first appears.

If you need a virtual machine and complete control over the operating system, EC2 is often the right choice.

If you've already packaged your application as a Docker container and don't want to manage Linux servers, ECS with Fargate provides a managed container platform.

If your workload is short-lived and event-driven, Lambda allows you to focus entirely on your code without thinking about servers.

Each service solves a different problem.

The goal isn't to memorise features but to understand which execution model best matches the application you're building.

Final Thoughts

One lesson that stood out while learning AWS was that compute isn't a single concept.

Amazon EC2, ECS with Fargate, and Lambda all execute code, but they do so using different architectural approaches.

Understanding those approaches makes it much easier to choose the right service instead of trying to force every application into the same deployment model.

Once I started thinking in terms of execution models rather than AWS products, the differences between these services became much clearer.

Understanding AWS Compute Services: EC2, EC2 Instances, and When Lambda Makes More Sense

Micheal Angelo — Tue, 28 Jul 2026 05:51:51 +0000

One of the first AWS services most developers learn is Amazon EC2.

Soon after, they encounter AWS Lambda.

Since both are compute services, one obvious question comes to mind:

Why does AWS offer two different ways to run code?

Initially, I assumed the biggest difference was pricing.

As I learned more, I realized the distinction goes much deeper.

EC2 and Lambda represent two different approaches to running applications, each solving different kinds of problems.

This article summarizes the mental model that helped me understand both services.

What Is a Compute Service?

A compute service provides the processing power required to run your application.

Whether you're hosting a web application, processing uploaded files, or responding to API requests, somewhere there must be a machine executing your code.

AWS provides several compute services, but two of the most common are:

Amazon EC2
AWS Lambda

Although both execute code, they do so in very different ways.

Understanding Amazon EC2

Amazon EC2 (Elastic Compute Cloud) is an AWS service that allows you to create virtual machines on demand.

One misconception I had early on was using the terms Amazon EC2 and EC2 Instance interchangeably.

They're related, but they are not the same thing.

Conceptually:

Amazon EC2 (AWS Service)
        │
        ▼
EC2 Instance (Virtual Machine)
        │
        ▼
Operating System
        │
        ▼
Your Application

Amazon EC2 is the service.

An EC2 Instance is the virtual machine created by that service.

Inside the instance, you install an operating system such as Ubuntu, Amazon Linux, or Windows Server.

Your application then runs inside that operating system.

Where Does the Virtual Machine Come From?

AWS owns physical servers inside its data centres.

A hypervisor running on those servers creates multiple isolated virtual machines.

Conceptually:

Physical Server
        │
   Hypervisor
        │
 ├── EC2 Instance
 ├── EC2 Instance
 ├── EC2 Instance
 └── ...

Customers never interact with the hypervisor directly.

AWS manages it, allowing developers to focus only on the virtual machines they launch.

Why Do People Say "SSH into the EC2"?

This is simply shorthand.

When someone says:

"SSH into the EC2."

they actually mean:

"SSH into the operating system running inside the EC2 Instance."

Likewise, when someone says:

"Deploy it on EC2."

they usually mean:

"Deploy it on an EC2 Instance."

Understanding this terminology made AWS documentation much easier for me to follow.

Understanding AWS Lambda

AWS Lambda follows a completely different model.

Instead of creating and managing a virtual machine, you upload only your code.

Whenever an event occurs—such as an HTTP request, an S3 upload, or a message arriving in an SQS queue—AWS automatically provisions the infrastructure required to execute that function.

Once execution finishes, the compute environment is released.

As developers, we don't manage operating systems or servers.

We simply write the function.

Understanding the Pricing Model

One of the biggest differences between EC2 and Lambda is how they are billed.

With Amazon EC2, compute resources are reserved for your instance while it is running.

Whether the application receives one request or one million requests, the virtual machine continues to exist until you stop or terminate it.

You are primarily paying for keeping those compute resources available.

An analogy that helped me understand this was renting a flat.

You pay rent for as long as you occupy it, whether you're inside or away.

Lambda works differently.

You are charged only when your function executes.

The cost depends mainly on:

The number of invocations
The execution duration
The memory allocated to the function

If nobody invokes the function, there is effectively no compute charge.

A useful analogy is taking a taxi.

You pay only while you're travelling.

No journey means no fare.

EC2 vs Lambda

Amazon EC2	AWS Lambda
Creates a virtual machine	Executes individual functions
You manage the operating system	AWS manages the infrastructure
Compute resources remain available while the instance is running	Compute resources are allocated only during execution
Well suited for long-running applications	Well suited for event-driven workloads
Full control over the server	Focus primarily on application code

Neither approach is universally better.

They simply solve different problems.

When Might You Choose EC2?

EC2 is often a good fit when:

You need full control over the operating system.
Your application runs continuously.
You host databases or web servers.
You require custom software installations.
Long-running background services are involved.

When Might You Choose Lambda?

Lambda is often a good fit when:

Applications respond to events.
Workloads are short-lived.
Infrastructure management should be minimized.
Traffic is unpredictable.
You want to focus primarily on business logic.

Final Thoughts

One lesson that stood out while learning AWS was that understanding services individually isn't enough.

Building a mental model of how they fit into larger systems is much more valuable.

Amazon EC2 isn't simply "a server."

It is a service that creates virtual machines.

AWS Lambda isn't "cheaper EC2."

It is a different execution model designed around event-driven computing.

Once I understood those distinctions, choosing between them became much less about comparing features and much more about selecting the right tool for the problem I was trying to solve.

Understanding AWS Cognito: How User Authentication Works Without Storing Passwords Yourself

Micheal Angelo — Mon, 27 Jul 2026 10:24:43 +0000

Authentication is one of the first challenges developers encounter when building an application.

Initially, it seems straightforward: ask users for an email and password, verify the credentials, and allow access.

However, implementing authentication securely is much more involved than it first appears.

Questions quickly begin to arise:

Where should passwords be stored?
How should passwords be hashed?
How are password resets implemented?
How should Multi-Factor Authentication (MFA) be handled?
How are secure authentication tokens generated?
How can those tokens be trusted by the backend?

These responsibilities are exactly what AWS Cognito is designed to solve.

Rather than being just a JWT generator, Cognito is a fully managed identity and authentication service that handles the entire authentication lifecycle.

Why Use AWS Cognito?

Imagine building authentication entirely from scratch.

The authentication flow might look like this:

User
   │
Email + Password
   │
   ▼
Backend
   │
Query Database
   │
Retrieve Password Hash
   │
Compare Password
   │
Generate JWT
   │
Return Access Token

In this design, the backend becomes responsible for:

Storing passwords
Hashing passwords
Verifying credentials
Password resets
Email verification
Multi-factor authentication
Refresh tokens
JWT generation
JWT validation

Handling all of these securely is a significant engineering responsibility.

AWS Cognito removes much of this complexity by managing authentication on your behalf.

The User Pool

One of the central concepts in Cognito is the User Pool.

A User Pool is a managed identity database maintained by AWS.

It stores authentication-related information such as:

Email address
Username
Password hash
Phone number
Email verification status
MFA settings
User status
A unique identifier (sub)

Conceptually:

User Pool

---------------------------------------
Email                 Password Hash
---------------------------------------
alice@example.com     *************
bob@example.com       *************
john@example.com      *************
---------------------------------------

An important detail is that developers never have access to users' passwords or password hashes.

Those are managed entirely by Cognito.

Where Does the User Pool Live?

One question that initially confused me was where the User Pool actually exists.

It is not stored in:

Amazon RDS
DynamoDB
An EC2 instance
Your application's VPC

Instead, it exists inside AWS's managed Cognito service.

This separation is intentional because authentication is infrastructure managed by AWS rather than application-specific data.

Why Isn't Cognito Inside the VPC?

Many AWS resources live inside a Virtual Private Cloud (VPC), including:

EC2
RDS
ECS
Lambda (when configured for VPC access)

Cognito works differently.

Like IAM or Route 53, Cognito is an AWS-managed service that is accessed securely over HTTPS through AWS service endpoints.

Your application communicates with Cognito—it does not host Cognito.

How Authentication Works

When a user signs in, the flow is surprisingly simple.

User
 │
 │ Email + Password
 ▼
AWS Cognito
 │
 ▼
User Pool
 │
 ▼
Verify Credentials
 │
 ▼
Generate Tokens
 │
 ▼
Browser

Notice what does not happen.

The backend never:

Receives the user's password
Compares password hashes
Generates authentication tokens

Cognito performs all of those responsibilities.

Signing Up

During registration, the process is similar.

User
 │
 │ Email
 │ Password
 ▼
AWS Cognito
 │
 ▼
User Pool

Cognito automatically:

Validates password policies
Stores passwords securely
Sends verification emails (if configured)
Creates the user identity
Assigns a unique identifier

Applications no longer need to implement these features manually.

Understanding the Tokens

After successful authentication, Cognito returns three JWTs.

ID Token

The ID Token identifies the authenticated user.

It commonly contains information such as:

User ID (sub)
Email
Username

Its purpose is identity.

Access Token

The Access Token is presented when calling protected APIs.

For example:

Authorization: Bearer <Access Token>

The backend validates this token before allowing access.

Refresh Token

Access Tokens eventually expire.

Instead of asking users to log in again, the Refresh Token can be exchanged for a new Access Token until it too expires.

This allows users to remain signed in without repeatedly entering credentials.

How Does the Backend Trust Cognito?

Every protected request includes the Access Token.

Browser

Authorization: Bearer eyJhbGci...

Rather than checking passwords, the backend validates the JWT.

Typical checks include:

Signature verification
Issuer validation
Audience validation
Expiration time

If the token is valid, access is granted.

Otherwise, the request is rejected with a 401 Unauthorized response.

The backend trusts the identity because the token was signed by Cognito.

Authentication Data vs Application Data

One important architectural lesson is that authentication data and business data should remain separate.

Cognito manages identity information such as:

Email
Password
MFA
Verification status

Meanwhile, application databases store business information such as:

Orders
Addresses
User preferences
Shopping carts
Subscription details

Applications typically store the Cognito user identifier (sub) to associate business records with authenticated users.

Conceptually:

Authentication
      │
      ▼
 AWS Cognito

Business Data
      │
      ▼
RDS / DynamoDB

Keeping these responsibilities separate improves both security and maintainability.

What If the Application Server Is Compromised?

A question that naturally came to mind was:

What happens if someone gains access to the EC2 instance?

An attacker might obtain:

Application source code
Environment variables
Business database access (depending on IAM permissions)
Access to other AWS services (depending on IAM policies)

However, they still cannot retrieve users' passwords from Cognito.

That's because:

Passwords are never stored on the EC2 instance.
Password hashes are never stored in the application database.
Cognito does not expose password hashes through its APIs.

Separating authentication from application infrastructure significantly reduces the impact of a server compromise.

Can AWS Administrators See Passwords?

Another common misconception is that AWS administrators can retrieve user passwords.

They cannot.

Administrators can perform management operations such as:

Creating users
Disabling users
Resetting passwords
Viewing permitted user attributes

But neither plaintext passwords nor password hashes are exposed.

Those remain protected inside Cognito.

Why Use Cognito?

Beyond simplifying development, Cognito also provides several security advantages.

It offers:

Secure password storage
Built-in password policies
Multi-Factor Authentication (MFA)
Email verification
Secure JWT generation
Refresh token management
Reduced attack surface
Standards-based authentication

Rather than building these capabilities from scratch, applications can rely on a managed service designed specifically for identity management.

Final Thoughts

Before learning AWS Cognito, I viewed authentication mainly as checking usernames and passwords.

Working through Cognito changed that perspective.

Authentication is much more than credential verification—it involves securely managing identities, issuing trusted tokens, protecting user credentials, and separating authentication concerns from application logic.

Perhaps the biggest takeaway was realizing that good authentication systems don't simply authenticate users.

They minimize how much sensitive information an application is responsible for handling in the first place.

That separation is one of the strongest security advantages of using a managed identity service like AWS Cognito.

From Local Development to a Production-Style Deployment: Understanding Docker, Nginx, Linux, and AWS

Micheal Angelo — Fri, 03 Jul 2026 09:38:25 +0000

When I first started learning cloud computing, I assumed AWS was simply a collection of services like Amazon S3, EC2, Lambda, and DynamoDB.

Over time, I realized that cloud computing is much less about memorizing services and much more about understanding how distributed applications are deployed, communicate, and operate in production.

To better understand these concepts without incurring cloud costs, I built a document processing pipeline locally using FastAPI, Docker, Docker Compose, Floci (LocalStack), Amazon S3, Amazon SQS, DynamoDB, and Nginx.

The objective wasn't to reproduce AWS perfectly—it was to understand the architectural principles that remain the same whether an application runs on a laptop or inside an EC2 instance.

The complete project is available here:

GitHub Repository

https://github.com/micheal000010000-hub/aws-document-processing-pipeline/tree/release/v7.0

Looking Beyond Individual AWS Services

One realization stood out while working on this project.

Learning individual services is useful, but understanding how they collaborate is far more valuable.

In production, applications are rarely a single process.

Instead, they consist of multiple independent components, each responsible for a specific task:

Web servers
Application servers
Object storage
Databases
Message queues
Background workers

Understanding how these components communicate is what transforms cloud services from isolated tools into a complete system.

Thinking About the Internet

The Internet allows computers located anywhere in the world to communicate using the TCP/IP protocol suite.

Now imagine that instead of communicating with another personal computer, your browser is communicating with a Linux server running continuously inside a cloud provider's data center.

That machine has:

CPU
Memory
Storage
Network connectivity

and behaves just like any other Linux computer.

An Amazon EC2 instance is essentially one such virtual Linux machine.

Deploying an application simply means copying your application onto that server and running it.

From Domain Name to Server

Suppose a user visits:

https://example.com

Before any application receives the request, the browser performs a DNS lookup.

DNS translates a human-readable domain name into a public IP address.

Once the IP address is known, the browser establishes a connection with the destination server.

This entire process happens before the application itself becomes involved.

IP Addresses, MAC Addresses, and NAT

Every network packet contains important addressing information.

At the network layer:

Source IP Address
Destination IP Address

At the data-link layer:

Source MAC Address
Destination MAC Address

One concept that became much clearer while studying networking was that MAC addresses only exist within a local network.

Packets travelling across the Internet never keep the same MAC address.

Each router forwards the packet by replacing the Layer 2 addressing information while preserving the end-to-end IP addresses.

Similarly, home routers perform Network Address Translation (NAT), replacing private addresses with a public address before forwarding traffic onto the Internet.

Understanding these concepts made cloud networking feel much less mysterious.

Why Ports Exist

Knowing the destination IP address isn't enough.

A Linux server may be running many different applications simultaneously.

For example:

22   → SSH
80   → HTTP
443  → HTTPS
5432 → PostgreSQL
6379 → Redis
8000 → FastAPI

Every process listens on a specific port.

When packets arrive, the Linux kernel examines the destination port and forwards the request to the appropriate application.

This explains why URLs such as:

http://localhost:8000

explicitly communicate with a FastAPI application running on port 8000.

Local Development

During development, frontend and backend applications often run independently.

For example:

Frontend
↓

localhost:3000

Backend
↓

localhost:8000

This setup is convenient because developers can work on each application separately.

However, exposing multiple ports directly to users becomes impractical in production.

Why Production Looks Different

Imagine asking users to remember:

example.com:3000
example.com:8000
example.com:9090

for different services.

That quickly becomes difficult to manage.

Instead, production systems expose a single public entry point.

This is where reverse proxies become important.

Understanding Nginx

One of the concepts that initially seemed confusing was the idea of a reverse proxy.

Eventually, it became much simpler after realizing that Nginx is simply another Linux process listening on ports 80 and 443.

Rather than exposing every application individually, only Nginx is exposed.

It receives incoming requests and forwards them internally to the correct application.

Conceptually:

Browser
     │
     ▼
Nginx
     │
     ├────────► Frontend
     │
     └────────► FastAPI

The browser communicates only with Nginx.

The backend applications remain hidden from direct Internet access.

Besides routing requests, Nginx also centralizes configuration, improves security, and simplifies deployment.

Understanding HTTPS

HTTPS initially sounded like a completely different protocol.

In reality, it is simply:

HTTP + TLS

A Certificate Authority (CA) issues a certificate for a domain after verifying ownership.

That certificate is configured inside Nginx.

When a browser connects:

A TLS handshake occurs.
The certificate is validated.
Encryption keys are negotiated.
HTTP communication becomes encrypted.

An interesting observation is that the FastAPI application itself remains unchanged.

Nginx performs TLS termination and forwards ordinary HTTP requests to the backend.

This separation allows backend services to focus entirely on application logic.

Building the Architecture Locally

Although the application currently runs on a local Linux machine, its architecture closely resembles a production deployment.

Browser
     │
     ▼
Nginx
     │
     ▼
FastAPI
     │
     ├────────► Amazon S3
     ├────────► Amazon SQS
     │                 │
     │                 ▼
     │            Background Worker
     │                 │
     ▼                 ▼
           Amazon DynamoDB

Using Floci made it possible to experiment with AWS-compatible services without requiring an active AWS account.

The same architectural principles remain applicable when deploying to EC2.

Lessons Learned

Working through this project connected many concepts that previously felt unrelated.

Some of the most valuable lessons included:

Understanding Docker and Docker Compose.
Building a multi-container application.
Using AWS-compatible services locally through Floci.
Learning event-driven architecture with Amazon SQS.
Separating file storage from metadata storage.
Running background workers independently from the API.
Understanding Linux processes and ports.
Connecting DNS, TCP/IP, NAT, and reverse proxies into one mental model.
Understanding HTTPS and TLS termination.
Organizing applications using production-style architecture.

Perhaps the biggest realization was this:

Cloud computing is not just about learning cloud services. It is about understanding the systems that connect them.

Once those architectural principles become clear, moving the same application from a local Linux machine to an EC2 instance becomes largely a deployment exercise rather than a redesign.

Final Thoughts

This project fundamentally changed the way I think about cloud computing.

Instead of seeing AWS as a catalog of independent services, I now see it as an ecosystem where networking, Linux, containers, storage, messaging, databases, and application servers collaborate to build scalable systems.

Learning these architectural principles has been far more valuable than memorizing individual services, because those principles remain applicable regardless of the cloud provider or deployment environment.

GitHub Repository

The complete project is available here:

Repository:

https://github.com/micheal000010000-hub/aws-document-processing-pipeline/tree/release/v7.0

Feedback and suggestions are always welcome.

From a Simple File Upload API to an Event-Driven AWS Document Processing Pipeline

Micheal Angelo — Tue, 30 Jun 2026 15:02:17 +0000

When I first started learning AWS, I assumed cloud computing was mostly about understanding individual services like Amazon S3, DynamoDB, Lambda, or EC2.

After spending time building a document processing pipeline locally, I realized something different.

Cloud computing isn't simply a collection of services—it's about how those services collaborate to solve real engineering problems.

Rather than learning each service in isolation, I gradually evolved a small FastAPI application into an event-driven, containerized backend. Along the way, I explored concepts like object storage, asynchronous processing, infrastructure automation, containerization, and continuous integration.

This article summarizes that journey and, more importantly, the architectural lessons learned along the way.

Starting with a Simple REST API

The project began with a straightforward goal: accept document uploads through a REST API.

The initial architecture looked like this:

Client
   │
   ▼
FastAPI
   │
   ▼
Local Storage

Uploaded files were simply written to a folder on the local machine.

While functional, this design tightly coupled the application to the local filesystem. The application worked only because it was running on my laptop.

Moving from Local Storage to Object Storage

The first architectural improvement was replacing local storage with Amazon S3.

Instead of keeping uploaded files inside the application directory, they were stored in an object storage service.

The architecture became:

Client
   │
   ▼
FastAPI
   │
   ▼
Amazon S3

This introduced one of the first important cloud concepts:

Application servers shouldn't permanently own user files.

Object storage provides durability, scalability, and independence from the application itself.

Learning AWS Without an AWS Account

Rather than using a paid AWS account, I used Floci, an open-source AWS emulator built on top of LocalStack.

The architecture looked like this:

FastAPI
    │
    ▼
localhost:4566
    │
    ▼
Floci
    │
    ├── S3
    ├── DynamoDB
    └── SQS

The application interacted with Floci using the official AWS SDK (boto3), making the experience very similar to working with real AWS services.

This made it possible to experiment with cloud concepts locally without worrying about cloud costs.

Using boto3 Instead of Raw HTTP Requests

Applications rarely communicate with AWS services by constructing HTTP requests manually.

Instead, AWS provides Software Development Kits (SDKs).

In Python, this is boto3.

A simple call like:

boto3.client("s3")

hides a significant amount of complexity.

The SDK handles authentication, request formatting, retries, and communication with AWS-compatible APIs, allowing developers to focus on application logic rather than protocol details.

Making Infrastructure Self-Initializing

Initially, the application assumed that the required S3 bucket already existed.

That meant manually creating resources before starting the application.

Instead, startup logic was introduced:

Application Starts
        │
        ▼
Check Bucket
        │
 ┌──────┴──────┐
 │             │
 ▼             ▼
Exists     Create Bucket

This small improvement made the application much easier to run in a fresh environment and reduced manual setup.

Separating Files from Metadata

Uploading files solved only part of the problem.

Information about each uploaded document—such as filename, upload time, size, and a unique identifier—also needed to be stored.

Instead of embedding this information within the files themselves, metadata was stored separately in Amazon DynamoDB.

S3
 │
 ▼
Document Files

DynamoDB
 │
 ▼
Document Metadata

Separating binary data from structured metadata is a common design pattern in cloud-native applications.

Introducing Event-Driven Architecture

Initially, the upload request handled every operation synchronously:

Upload File
      │
      ▼
Store Metadata
      │
      ▼
Return Response

This meant users had to wait until every task finished.

To improve the design, asynchronous processing was introduced using Amazon SQS.

The workflow became:

Client
      │
      ▼
FastAPI
      │
      ▼
Upload to S3
      │
      ▼
Send Message to SQS
      │
      ▼
Return Response

Instead of doing everything immediately, the application now creates a message describing the work that still needs to be done.

Why Queues Matter

Queues become especially valuable when traffic increases.

Imagine thousands of users uploading documents simultaneously.

Without a queue:

Requests
    │
    ▼
Application
    │
    ▼
Overloaded

With a queue:

Requests
    │
    ▼
SQS Queue
    │
    ▼
Background Workers

The queue acts as a buffer, smoothing sudden spikes in traffic and allowing work to be processed at a sustainable pace.

Background Workers

A dedicated worker continuously monitors the queue.

Its responsibility is simple:

Receive Message
      │
      ▼
Process
      │
      ▼
Store Metadata
      │
      ▼
Delete Message

Separating background processing from the API keeps responsibilities clear and allows each component to scale independently.

Exploring Serverless Computing

I also experimented with AWS Lambda.

Instead of running workers continuously, Lambda executes code only when an event occurs.

Conceptually:

Event
   │
   ▼
Lambda
   │
   ▼
Execute
   │
   ▼
Terminate

This introduced the idea of serverless computing, where compute resources exist only while work is being performed.

Containerizing the Application

As the project grew, another challenge appeared.

How could another machine run the application without manually installing Python, dependencies, or configuring the environment?

Docker solved this problem.

A Docker image packages:

The application
Python
Dependencies
Configuration

into a single portable artifact.

Source Code
      │
      ▼
Docker Build
      │
      ▼
Docker Image

A container is simply a running instance of that image.

Managing Multiple Services with Docker Compose

Eventually, the project consisted of several independent services:

FastAPI
Background Worker
Floci

Instead of starting each one manually, Docker Compose orchestrated the entire environment.

Docker Compose
      │
 ┌────┼────┐
 ▼    ▼    ▼
API Worker Floci

This made local development significantly more reproducible.

Automating Builds with GitHub Actions

Running the application locally wasn't enough.

Every code change should also be verified automatically.

GitHub Actions introduced a simple CI pipeline:

Push Code
     │
     ▼
GitHub Actions
     │
     ▼
Install Dependencies
     │
     ▼
Build Docker Image
     │
     ▼
Report Status

Automation helps catch problems earlier and creates confidence that the project remains buildable.

Sharing Images Through Docker Hub

Docker images initially existed only on one machine.

Publishing them to Docker Hub changed that.

Local Build
     │
     ▼
Docker Hub
     │
     ▼
Any Machine

Once uploaded, the same image can be pulled and executed anywhere without rebuilding.

This is the essence of:

Build once, run anywhere.

Looking Ahead to Deployment

The next natural step is deployment.

Instead of running the application on a personal laptop, the same Docker image can be deployed to an Amazon EC2 instance.

Conceptually:

GitHub
     │
     ▼
GitHub Actions
     │
     ▼
Docker Hub
     │
     ▼
EC2 Instance
     │
     ▼
Docker Compose
     │
 ┌───┼────┐
 ▼   ▼    ▼
API Worker Floci

Cloud deployment becomes much simpler because the application is already packaged as a container.

Key Lessons Learned

This project reinforced several important ideas:

Cloud computing is about systems, not isolated services.
Object storage and metadata storage solve different problems.
Event-driven architectures improve scalability and responsiveness.
Queues decouple producers from consumers.
Background workers allow long-running tasks to happen asynchronously.
Containers provide consistent execution environments.
Continuous Integration improves software quality.
Good software engineering principles matter just as much as cloud knowledge.

Final Thoughts

Looking back, the biggest takeaway wasn't learning Amazon S3, DynamoDB, SQS, Docker, or GitHub Actions individually.

It was understanding how each component contributes a single responsibility within a larger system.

Cloud applications become easier to extend, maintain, and scale when responsibilities are clearly separated and services communicate through well-defined interfaces.

Building this project transformed cloud computing from a list of services into a connected ecosystem of architectural patterns—and that has been one of the most valuable lessons in my learning journey.

GitHub Repository

The complete project is available here:

Repository: https://github.com/micheal000010000-hub/aws-document-processing-pipeline/tree/release/v6.0

Feedback and suggestions are always welcome.

Building a Cloud Application Locally: Lessons in Backend Architecture and AWS

Micheal Angelo — Thu, 25 Jun 2026 13:07:32 +0000

When learning cloud computing, it's tempting to jump straight into individual services like Amazon S3, DynamoDB, or Lambda. While understanding each service is important, I found that the bigger lesson wasn't about the services themselves—it was about how applications are designed to evolve over time.

To explore this, I started building a document processing backend locally using FastAPI, Floci (an open-source AWS emulator), Docker, and boto3.

What began as a simple file upload endpoint gradually evolved into a small document management backend capable of uploading, listing, downloading, and deleting documents while keeping the application architecture modular.

The goal wasn't just to interact with AWS services. It was to understand how good backend design allows applications to grow without requiring major rewrites.

Starting Simple

The application originally had a single responsibility:

Accept a document through an API.

The initial architecture was straightforward:

Client
   │
   ▼
FastAPI
   │
   ▼
uploads/

Uploaded files were simply written to a local directory.

Although this worked, the API endpoint became tightly coupled to the storage implementation.

Changing the storage mechanism later would require modifying the route itself.

Introducing a Service Layer

To reduce that coupling, the storage logic was extracted into a dedicated service.

The architecture became:

Client
   │
   ▼
FastAPI
   │
   ▼
Storage Service
   │
   ▼
Local Storage

Although the application's behavior remained the same, this introduced an important software engineering principle:

Separation of Concerns.

The API became responsible for handling HTTP requests.

The storage service became responsible for managing files.

Swapping Local Storage for Amazon S3

Once the storage logic was isolated, replacing the implementation became surprisingly simple.

Instead of saving files locally, the storage service was updated to use Amazon S3 through the AWS SDK (boto3).

The architecture changed to:

Client
   │
   ▼
FastAPI
   │
   ▼
S3 Storage Service
   │
   ▼
Amazon S3 (Floci)

The API endpoints themselves didn't need to change.

Only the storage implementation changed.

That was one of the biggest takeaways from this project.

Making Infrastructure Self-Initializing

Another improvement was avoiding manual infrastructure setup.

Rather than assuming the S3 bucket already existed, the application now checks for it during startup and creates it if necessary.

Conceptually:

Application Starts
        │
        ▼
Check Bucket
        │
        ▼
Create If Missing

This makes the application easier to run on a fresh machine and reduces manual setup.

Evolving Beyond File Uploads

Initially, the project focused only on uploading files.

As development progressed, it evolved into a small document management backend.

The application now supports:

Uploading documents
Listing stored documents
Downloading documents
Deleting documents

The current API exposes endpoints such as:

POST /upload
GET /documents
GET /download/{filename}
DELETE /documents/{filename}

One realization stood out during this stage:

Good architecture doesn't eliminate future changes—it makes future changes easier to implement.

Because storage logic was already isolated behind a service layer, adding new endpoints required very little modification to the existing code.

Adding DynamoDB

Managing files solved only part of the problem.

Applications also need to manage information about those files.

To prepare for that, a dedicated DynamoDB service was introduced.

Its responsibilities include:

Generating unique document identifiers
Recording upload timestamps
Managing document metadata

The current architecture looks like this:

                 Client
                    │
        ┌───────────┴───────────┐
        ▼                       ▼
 Upload / Download        List / Delete
        │                       │
        └───────────┬───────────┘
                    ▼
                FastAPI
            ┌───────┴────────┐
            ▼                ▼
      S3 Storage        DynamoDB Service
            ▼                ▼
      Amazon S3       Amazon DynamoDB

At the moment, document storage is fully functional, while the DynamoDB service provides the foundation for future metadata management.

More Than Learning AWS

Although the project uses services like Amazon S3 and DynamoDB, the most valuable lessons weren't AWS-specific.

It reinforced several software engineering concepts:

Separation of Concerns
Service Layer Pattern
Dependency Isolation
Infrastructure Initialization
Modular Backend Design
Storage Abstraction

These ideas apply regardless of whether the backend eventually uses Amazon S3, Azure Blob Storage, Google Cloud Storage, or even a local filesystem.

The Bigger Lesson

One realization stood out throughout this project:

Cloud engineering isn't just about learning cloud services.

It's about designing applications that can evolve as requirements change.

The project started as a simple upload endpoint.

Over time it gained support for listing, downloading, and deleting documents without requiring a redesign of the application.

That flexibility came from separating responsibilities early rather than tightly coupling implementation details together.

For example:

Local Storage
        │
        ▼
Amazon S3

The API doesn't need to know which implementation is being used.

As long as the interface remains consistent, the underlying storage mechanism can evolve independently.

That flexibility is what makes production systems easier to extend, test, and maintain.

Final Thoughts

Building applications has been one of the most effective ways for me to learn cloud engineering.

Working through real architectural decisions made concepts like Amazon S3, DynamoDB, and the AWS SDK feel much more intuitive than simply reading documentation.

More importantly, this project reinforced that good cloud applications are built not just on cloud services, but on sound software engineering principles.

The cloud services may change over time.

A well-designed architecture makes those changes far less painful.

GitHub Repository

The complete project is available here:

Repository: https://github.com/micheal000010000-hub/aws-document-processing-pipeline/tree/Document_Processing_Pipeline

Feedback, suggestions, and contributions are always welcome.

Learning AWS by Building a Local Document Processing Pipeline (Without an AWS Account)

Micheal Angelo — Thu, 25 Jun 2026 08:23:48 +0000

Cloud computing often feels difficult to learn because many tutorials focus on individual services in isolation.

You create an S3 bucket in one tutorial, invoke a Lambda function in another, and experiment with DynamoDB somewhere else. While each service makes sense individually, it can still be hard to understand how they work together in a real application.

Instead of learning services one by one, I wanted to build something that connected them together.

Even better, I wanted to do it without creating an AWS account or worrying about cloud costs.

That's where Floci, an open-source AWS emulator, came in.

The Goal

The objective wasn't to recreate AWS perfectly.

It was to understand the interaction between services by building a simple document processing pipeline.

The architecture looked like this:

User
   │
   ▼
Upload Document
   │
   ▼
Amazon S3
   │
   ▼
AWS Lambda
   │
Extract Metadata
   │
   ▼
Amazon DynamoDB

Although the final automatic Lambda → DynamoDB write couldn't be completed due to a networking limitation inside Floci, the overall architecture mirrors how the same workflow would be built on AWS.

Why Learn AWS Locally?

Running AWS services locally offers several advantages while learning:

No cloud costs
Safe experimentation
Fast iteration
Ability to inspect every component
Easy debugging

Using the AWS CLI against a local endpoint also helped reinforce an important idea:

The AWS CLI is simply a client that sends API requests. Whether those requests go to Amazon's cloud or a local emulator depends on the configured endpoint.

What Each Service Taught Me

Amazon S3

The first service I explored was Amazon S3.

Rather than thinking of S3 as "cloud storage," it became much easier to understand it as object storage.

A bucket acts as a container, while every uploaded file is stored as an object.

Practical exercises included:

Creating buckets
Uploading files
Listing bucket contents
Downloading objects
Deleting objects

These simple operations clarified how applications persist documents before any further processing occurs.

Amazon DynamoDB

Once files could be stored, the next step was understanding structured data.

Unlike S3, DynamoDB doesn't store files—it stores records.

Creating tables, inserting items, retrieving data, and scanning tables helped reinforce the difference between object storage and NoSQL databases.

Instead of storing the document itself, DynamoDB became the place to store information about the document.

AWS Lambda

Lambda introduced a completely different mindset.

Instead of managing servers, code is packaged and uploaded as a deployment artifact.

The Lambda function processed uploaded documents and generated metadata such as:

Document ID
Filename
File size
Upload timestamp

This was also where I encountered some of the most interesting debugging challenges.

Debugging Was the Real Teacher

Building the project wasn't just about writing code.

It involved understanding how different environments interact.

Some issues I encountered included:

Missing AWS CLI inside the Lambda runtime
Updating deployment packages correctly
Lambda timeout while communicating with DynamoDB
Docker networking behaviour inside Floci

Each issue forced me to understand the difference between:

My Linux machine
Docker containers
Lambda runtime environments
AWS SDK (boto3)
AWS CLI

Those distinctions aren't always obvious from documentation alone, but debugging made them much clearer.

Understanding IAM

IAM was another concept that became easier through practice.

Rather than viewing it as just another AWS service, I started thinking of IAM as the system that answers three questions:

Who is making the request?
What action is being performed?
Is that action allowed?

Learning about users, groups, policies, and roles also clarified why Lambda functions execute with an IAM role instead of inheriting permissions automatically.

The Bigger Picture

One realization stood out throughout the project:

AWS services don't communicate because they're "inside AWS."

They communicate through well-defined APIs.

Whether the services are running in Amazon's cloud or emulated locally, the interaction model remains largely the same.

Understanding those interactions felt much more valuable than memorizing individual commands.

What This Project Reinforced

Working through this pipeline reinforced several ideas:

Building teaches more than reading documentation.
Debugging is part of learning cloud computing.
IAM is fundamentally about identities and permissions.
Lambda runs inside an isolated execution environment.
Cloud services are loosely coupled and communicate through APIs.

Final Thoughts

Cloud computing can seem overwhelming because of the sheer number of services available.

Building even a small end-to-end workflow makes those services feel much less abstract.

By connecting object storage, serverless compute, databases, and identity management into a single project, I gained a much clearer understanding of how these pieces fit together.

For anyone beginning their cloud journey, building a small pipeline—even locally—can often teach far more than reading documentation alone.

GitHub Repository

If you'd like to explore the project or contribute, here's the repository:

https://github.com/micheal000010000-hub/aws-document-processing-pipeline

Feedback, suggestions, and contributions are always welcome.

Learning AWS Without an AWS Account: Running S3, DynamoDB, and Lambda Locally

Micheal Angelo — Sun, 21 Jun 2026 01:38:07 +0000

Learning AWS Without an AWS Account: Running S3, DynamoDB, and Lambda Locally

Image: Local AWS architecture using Floci, Docker, and AWS CLI.

For a long time, I approached AWS the same way many beginners do.

I would read documentation, watch tutorials, and try to memorize services.

The problem was simple:

Reading about cloud services is very different from actually using them.

At the same time, I didn't want to create resources in a cloud account while learning basic concepts.

So I started looking for a way to experiment locally.

That's how I came across Floci, an open-source AWS emulator that exposes AWS-compatible APIs on a local machine.

The idea is surprisingly simple:

Instead of sending requests to AWS, send them to a local container that behaves like AWS.

Why Learn AWS Locally?

When learning cloud concepts, most beginners want to answer questions like:

What is S3 really used for?
How does DynamoDB store data?
What does Lambda actually execute?
What role does AWS CLI play?

These questions are easier to answer by creating resources than by reading definitions.

Local emulation makes that possible without worrying about cloud costs.

High-Level Architecture

The setup looked like this:

AWS CLI
    ↓
localhost:4566
    ↓
Floci Container
    ├── S3 Emulator
    ├── DynamoDB Emulator
    └── Lambda Emulator

Instead of communicating with AWS infrastructure, AWS CLI communicates with Floci running on the local machine.

Running Floci with Docker

The first step was starting the emulator.

A simple Docker Compose configuration was enough:

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"

Then:

docker compose up -d

Port 4566 became the endpoint through which AWS CLI communicated with Floci.

Understanding AWS CLI

AWS CLI stands for:

Amazon Web Services Command Line Interface

It acts as a client that converts commands into AWS API requests.

For example:

aws s3 ls

can be viewed conceptually as:

AWS CLI
     ↓
AWS API Request
     ↓
S3 Service

Normally those requests go to AWS.

With Floci, the destination changes:

--endpoint-url=http://localhost:4566

This tells AWS CLI to communicate with the local emulator instead.

Learning S3

What Is S3?

S3 is an object storage service.

A useful mental model is:

Bucket
 ├── resume.pdf
 ├── image.png
 └── hello.txt

A bucket acts as a container.

Everything stored inside it is called an object.

Creating a Bucket

aws --endpoint-url=http://localhost:4566 \
s3 mb s3://notes-app-bucket

Uploading a File

echo "Hello from AWS Learning" > hello.txt

aws --endpoint-url=http://localhost:4566 \
s3 cp hello.txt s3://notes-app-bucket/

Listing Objects

aws --endpoint-url=http://localhost:4566 \
s3 ls s3://notes-app-bucket

Downloading an Object

aws --endpoint-url=http://localhost:4566 \
s3 cp s3://notes-app-bucket/hello.txt .

Key Insight

S3 stores:

Images
Videos
Documents
Backups
Application assets

S3 is not a database.

It is object storage.

Learning DynamoDB

What Is DynamoDB?

DynamoDB is a NoSQL database service.

Instead of storing files, it stores records.

Example:

{
  "noteId": "1",
  "title": "Learning AWS",
  "content": "Today I learned S3"
}

Creating a Table

aws --endpoint-url=http://localhost:4566 \
dynamodb create-table \
--table-name Notes \
--attribute-definitions \
AttributeName=noteId,AttributeType=S \
--key-schema \
AttributeName=noteId,KeyType=HASH \
--billing-mode PAY_PER_REQUEST

Inserting Data

aws --endpoint-url=http://localhost:4566 \
dynamodb put-item \
--table-name Notes \
--item '{
  "noteId":{"S":"1"},
  "title":{"S":"Learning AWS"},
  "content":{"S":"Today I learned S3 and DynamoDB"}
}'

Retrieving Data

aws --endpoint-url=http://localhost:4566 \
dynamodb get-item \
--table-name Notes \
--key '{"noteId":{"S":"1"}}'

Key Insight

A useful distinction is:

S3
 ↓
Stores Files

versus

DynamoDB
 ↓
Stores Records

Understanding this difference made both services much easier to reason about.

Learning Lambda

What Is Lambda?

Lambda is a serverless compute service.

Unlike S3 or DynamoDB, Lambda does not primarily store data.

Its job is to execute code.

Example:

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "body": "Hello from Lambda"
    }

[Insert Figure 4: Lambda Execution Flow Here]

Packaging the Function

Lambda expects a deployment artifact.

The simplest option is a ZIP file.

zip function.zip handler.py

The ZIP package contains:

Application code
Supporting files
Dependencies

Creating the Function

aws --endpoint-url=http://localhost:4566 \
lambda create-function \
--function-name HelloLambda \
--runtime python3.11 \
--handler handler.lambda_handler \
--zip-file fileb://function.zip \
--role arn:aws:iam::000000000000:role/lambda-role

The First Failure

The first invocation failed with:

Failed to start Lambda container

This turned out to be a Docker issue.

Lambda execution inside Floci relies on runtime containers.

Floci needed access to Docker itself.

Fixing the Issue

The solution was mounting Docker's socket:

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

Once Floci could communicate with Docker, Lambda executed successfully.

Invoking Lambda

aws --endpoint-url=http://localhost:4566 \
lambda invoke \
--function-name HelloLambda \
response.json

Result:

{
  "statusCode": 200,
  "body": "Hello from Lambda"
}

A Brief Note on IAM

One interesting observation was that Lambda creation succeeded even though no real IAM role was created.

The emulator is intentionally more forgiving than AWS.

In real AWS, IAM is responsible for controlling:

Who can access resources
Which actions are allowed
Which services can communicate

A Lambda execution role acts as the identity under which the function runs.

Even simple functions require one because AWS needs to know what permissions the function should have if it later interacts with services such as S3 or DynamoDB.

What This Exercise Taught Me

By the end of the experiment, the following concepts became much clearer:

S3

Creating buckets
Uploading objects
Downloading objects
Listing objects

DynamoDB

Creating tables
Inserting records
Querying records
Understanding primary keys

Lambda

Packaging code
Deploying functions
Executing code
Troubleshooting runtime issues

Infrastructure Concepts

Docker containers
Service emulation
Runtime environments
Deployment artifacts
IAM fundamentals

Final Mental Model

When I started, S3, DynamoDB, and Lambda felt like unrelated AWS services.

After running them locally, a much simpler mental model emerged:

AWS CLI
     ↓
Floci
     ├── S3       → Stores Files
     ├── DynamoDB → Stores Records
     └── Lambda   → Runs Code

Sometimes the fastest way to understand cloud services isn't reading more documentation.

It's building a small environment, creating resources, breaking things, fixing them, and observing how the pieces fit together.

From Home Networking to Enterprise Networking: What Changes Behind the Scenes?

Micheal Angelo — Sat, 20 Jun 2026 07:26:15 +0000

From Home Networking to Enterprise Networking: What Changes Behind the Scenes?

For a long time, networking felt relatively straightforward.

A device connects to a router, the router connects to the Internet, and traffic eventually reaches its destination.

A simplified view looks like:

Laptop
   ↓
Router
   ↓
ISP
   ↓
Internet
   ↓
Website

While studying networking, I became curious about how enterprise environments work.

Corporate devices often have additional security software installed, VPN clients are common, and traffic sometimes appears to follow entirely different paths than it does on a home network.

This raised an interesting question:

What actually changes when networking moves from a home environment to an enterprise environment?

The Problem Organizations Are Trying To Solve

Home networks are usually optimized for convenience.

Enterprise networks have a different set of priorities.

Organizations need to:

Protect sensitive information
Restrict access to certain websites
Monitor traffic for security threats
Enforce compliance requirements
Control how applications communicate
Route traffic through approved paths

Simply allowing devices to communicate directly with the Internet is often insufficient.

Additional security layers are introduced to enforce these requirements.

What Is A Secure Web Gateway?

One common component in enterprise environments is a Secure Web Gateway (SWG).

Instead of traffic flowing directly to the Internet:

Browser
   ↓
Internet

traffic may follow a path like:

Browser
   ↓
Security Client
   ↓
Secure Web Gateway
   ↓
Internet

The gateway acts as an intermediary.

Before traffic reaches its destination, the gateway can:

Apply security policies
Filter websites
Inspect requests
Generate logs
Enforce compliance requirements

The user still experiences a normal browsing session, but additional checks occur behind the scenes.

Identity Matters More Than MAC Addresses

One misconception many beginners have is that organizations identify users primarily through:

MAC addresses
Local IP addresses

In reality, enterprise environments usually rely on richer forms of identity.

Examples include:

User authentication
Device certificates
Security agents
Corporate identity providers
Session information

This allows an organization to distinguish between:

An approved corporate device
A personal device

even when both devices are connected to the same home Wi-Fi network.

The decision is often based on identity and trust rather than simply an IP address.

Understanding Traffic Steering

One of the more interesting concepts in enterprise networking is traffic steering.

The basic idea is simple:

Different types of traffic may follow different paths.

For example:

Web Browsing
        ↓
Gateway A

Internal Applications
        ↓
Gateway B

Client Systems
        ↓
Gateway C

The path can be chosen based on:

User identity
Application type
Destination
Security policies

A useful analogy is an airport.

Passengers may enter through the same building, but different groups are routed through different checkpoints depending on where they are going.

Enterprise networks often work in a similar way.

Why Network Behavior Can Change Over Time

One observation that initially confused me was that network behavior sometimes changes without any visible action from the user.

A website that was inaccessible one day may suddenly become accessible later.

This often happens because enterprise security platforms periodically receive updated policies.

Those policies may modify:

Access permissions
Routing behavior
Security controls
Gateway selection

As a result, the path traffic follows today may not be identical to the path it follows next month.

Where VPNs Fit Into The Picture

Before learning more about networking, I assumed traffic always followed a simple path:

Laptop
   ↓
Router
   ↓
Internet
   ↓
Server

VPNs introduce an additional layer.

Conceptually:

Laptop
   ↓
Encrypted Tunnel
   ↓
VPN Gateway
   ↓
Destination

The VPN gateway becomes a trusted entry point into an organization's network.

Instead of communicating directly with internal resources, traffic first reaches the VPN infrastructure.

From there it is forwarded according to organizational policies.

One Device, Multiple IP Addresses

Another important concept is that a device may be associated with multiple IP addresses simultaneously.

Local IP Address

Assigned by the home router.

Examples:

192.168.x.x
10.x.x.x

Used only inside the local network.

Public IP Address

Assigned by the Internet Service Provider.

This is typically what external websites see.

VPN Address

Assigned by the VPN infrastructure.

When connected to organizational resources, this address may be used instead of the public ISP address.

Understanding these different layers helps explain why network traffic can appear differently depending on where it is observed.

DNS Still Plays A Critical Role

Regardless of whether traffic is flowing through a home network or an enterprise network, DNS remains fundamental.

Humans prefer names:

example.com

Computers require IP addresses.

DNS performs the translation:

example.com
        ↓
IP Address

One useful command is:

nslookup example.com

This allows you to observe how names are resolved into addresses.

Building On Earlier Networking Concepts

While learning networking, I spent a lot of time understanding:

ARP
DHCP
DNS
ICMP
IP
MAC Addresses

These protocols solve lower-level networking problems.

For example:

ARP asks:

I know the IP address. What is the MAC address?

DHCP asks:

What IP address should I use?

DNS asks:

What IP address corresponds to this domain name?

Enterprise networking introduces a different set of questions:

Who is the user?

Is this device trusted?

Which policy applies?

Which gateway should handle this traffic?

The focus shifts from simple connectivity to identity, security, and policy enforcement.

Final Thoughts

One thing that became clear while learning networking is that enterprise networking is not a completely different world.

The same fundamentals still exist:

IP addresses
DNS
Routing
TCP/IP

What changes is the addition of security, identity, and policy layers on top of those fundamentals.

The more I studied packet flows and network paths, the easier these concepts became to understand.

Rather than memorizing protocols individually, it became much more useful to ask:

Where is this packet going, and why is it taking that path?

That simple question often reveals how the entire system works.

One Public IP, Many Devices: How Your Router Knows Where Replies Belong

Micheal Angelo — Sat, 13 Jun 2026 17:26:18 +0000

After learning about DHCP, ARP, DNS, TCP, and NAT, I ran into a question that completely changed how I thought about home networking.

I already understood the basics of NAT.

My laptop might have:

192.168.1.100

while my router has a public address such as:

49.43.12.10

The router replaces the private address with its public address before sending packets to the Internet.

That part made sense.

But then a new question appeared.

The Problem

Imagine a home network with three devices.

Laptop
192.168.1.100

Phone
192.168.1.101

Tablet
192.168.1.102

All three devices are browsing websites simultaneously.

After NAT, every packet appears to originate from:

49.43.12.10

To the Internet, all three devices look identical.

Which raises an obvious question:

When replies come back, how does the router know which device should receive them?

This is where ports become extremely important.

Think of NAT Like an Apartment Building

Imagine a large apartment building.

The building has a single address:

49.43.12.10

Inside the building are:

Apartment 101
Apartment 102
Apartment 103

The public IP address is the building.

The ports are the apartment numbers.

Without apartment numbers, a package arriving at the building could not be delivered to the correct resident.

[Insert Figure 1: Apartment Building Analogy Here]

A Real Example

Suppose we have:

Laptop:
192.168.1.100

Phone:
192.168.1.101

Router:
49.43.12.10

The laptop performs a DNS lookup.

Its operating system chooses a temporary source port:

The packet looks like:

Source IP:
192.168.1.100

Source Port:
53001

Destination IP:
8.8.8.8

Destination Port:
53

The Phone Does the Same Thing

Now the phone also performs a DNS lookup.

It chooses:

as well.

The packet becomes:

Source IP:
192.168.1.101

Source Port:
53001

Destination IP:
8.8.8.8

Destination Port:
53

At first glance this looks problematic.

Both devices chose the same source port.

Surprisingly, this is completely valid.

Why?

Because their source IP addresses are different.

Inside the LAN they are still unique connections.

The Router Receives the First Packet

The router sees:

192.168.1.100:53001

and creates a translation entry:

192.168.1.100:53001
        ↓
49.43.12.10:40001

Notice something interesting.

The router did not keep:

It selected:

instead.

This becomes the public-facing connection.

The outgoing packet now looks like:

Source IP:
49.43.12.10

Source Port:
40001

Destination IP:
8.8.8.8

Destination Port:
53

The Router Receives the Second Packet

Now the phone's packet arrives.

The router creates another entry:

192.168.1.101:53001
        ↓
49.43.12.10:40002

Notice what changed.

The public IP stayed the same.

The public port changed.

The translation table now contains:

192.168.1.100:53001
        ↓
49.43.12.10:40001

192.168.1.101:53001
        ↓
49.43.12.10:40002

This table is the real magic behind modern home networking.

[Insert Figure 2: PAT Translation Table Here]

The Replies Return

Google sends a reply to:

49.43.12.10:40001

The router checks its translation table.

It finds:

40001
        ↓
192.168.1.100:53001

The packet is rewritten and delivered to the laptop.

A second reply arrives:

49.43.12.10:40002

The router checks the table again.

It finds:

40002
        ↓
192.168.1.101:53001

The packet is forwarded to the phone.

Both devices receive the correct response even though they share the same public IP address.

[Insert Figure 3: Reply Mapping Diagram Here]

This Is Actually PAT

Most people casually refer to this process as:

NAT

More specifically, what is happening here is:

PAT

which stands for:

Port Address Translation

Another common name is:

NAT Overload

because many devices are sharing a single public IP address.

Why PAT Is So Powerful

A port number can range from:

This provides roughly:

65,000+

possible ports.

That means thousands of simultaneous connections can share the same public IP address.

Without PAT, home networking as we know it would be much more difficult.

What Does the Router Actually Store?

The router does not simply remember IP addresses.

It maintains a connection table.

A simplified entry might look like:

Inside IP:
192.168.1.100

Inside Port:
53001

Outside IP:
49.43.12.10

Outside Port:
40001

Destination IP:
8.8.8.8

Destination Port:
53

Real routers store additional information such as:

Protocol
TCP state
Timeouts
Flags
Session metadata

This is what allows thousands of connections to coexist simultaneously.

What Happens When the Connection Ends?

Suppose the browser tab is closed.

Eventually the TCP session terminates.

The router notices.

The translation entry is removed.

For example:

49.43.12.10:40001

becomes available for reuse.

This process happens continuously behind the scenes.

Why Random Incoming Traffic Gets Dropped

Imagine a random server sends a packet to:

49.43.12.10:45000

The router checks its translation table.

No matching entry exists.

The router effectively says:

I don't know who requested this connection.

The packet is dropped.

This behavior is one reason home routers provide a basic level of protection against unsolicited traffic.

The Insight That Changed My Mental Model

Initially I thought NAT was simply:

Private IP
        ↓
Public IP

That is only part of the story.

The real magic is the translation table.

The router continuously maintains mappings between:

(Private IP, Private Port)
                ↔
(Public IP, Public Port)

for every active connection.

That is how one public IP address can support dozens of devices and thousands of simultaneous network conversations.

And once this idea clicked, ports stopped feeling like random numbers and started feeling like apartment numbers in a giant building.

Following a Packet: What Really Happens Between Opening Your Laptop

Micheal Angelo — Sat, 13 Jun 2026 10:30:24 +0000

For a long time, networking felt like a collection of unrelated acronyms.

DHCP.

ARP.

DNS.

TCP.

IP.

NAT.

VPN.

I could explain each one individually.

But if someone had asked:

"What actually happens when you open a website?"

I would have struggled to answer.

The turning point came when I stopped learning protocols individually and started following a single packet through the network.

This article follows that packet from the moment a laptop connects to Wi-Fi until a webpage finally appears in the browser.

Before We Begin: Data, Segments, Packets, and Frames

One of the biggest beginner misconceptions is that everything is called a packet.

Technically, that is not true.

As data moves through the networking stack, its name changes.

Application Layer

The browser creates:

GET /

At this stage it is simply:

Data

Transport Layer

TCP adds a header containing information such as:

Source Port
Destination Port
Sequence Number
Acknowledgement Number
Flags

Now we have:

TCP Header + Data

This is called a:

Segment

Network Layer

IP adds another header containing:

Source IP Address
Destination IP Address
TTL
Protocol

Now we have:

IP Header + Segment

This becomes a:

Packet

Data Link Layer

Ethernet or Wi-Fi adds:

Source MAC Address
Destination MAC Address

Now we have:

Ethernet Header + Packet

This becomes a:

Frame

The final structure looks like:

Frame
└── Packet
    └── Segment
        └── Data

This process is known as:

Encapsulation

Every packet on the Internet begins this way.

Our Example Network

To keep things simple, imagine the following setup.

Laptop

MAC = BB:BB:BB:BB:BB:BB

Router

LAN IP  = 192.168.1.1
LAN MAC = AA:AA:AA:AA:AA:AA
Public IP = 49.43.12.10

DNS Server

8.8.8.8

Website

example.com
104.26.10.50

Now let's follow the packet.

Step 1: Laptop Boots

Immediately after startup, the laptop knows surprisingly little.

It knows:

My MAC Address

But it does not yet know:

IP Address
Default Gateway
DNS Server

Those must be discovered.

Step 2: Connecting to Wi-Fi

The laptop successfully joins the wireless network.

At this point many people assume networking is ready.

It is not.

The laptop still lacks an IP address.

Without one, meaningful communication cannot occur.

Step 3: DHCP Gives the Laptop an Identity

The laptop broadcasts:

DHCP Discover

Meaning:

Is there a DHCP server available?

The router responds:

DHCP Offer

containing:

IP Address = 192.168.1.100
Gateway    = 192.168.1.1
DNS Server = 8.8.8.8

The laptop accepts.

Now it finally knows:

Who am I?
Where should I send traffic?
Which DNS server should I use?

DHCP has completed its job.

Step 4: The User Opens a Website

Suppose the user enters:

https://example.com

The browser immediately faces a problem.

It knows:

example.com

but websites are reached using IP addresses.

The browser asks:

What IP address belongs to example.com?

Step 5: Before DNS, ARP Happens

To contact the DNS server, the laptop must send traffic through the router.

It knows the router's IP address:

192.168.1.1

But it does not know:

Router MAC Address

So it broadcasts:

Who has 192.168.1.1?

This is an ARP request.

The router replies:

192.168.1.1 is AA:AA:AA:AA:AA:AA

The laptop stores this information in its ARP cache.

Problem solved.

Step 6: The DNS Query Leaves the Laptop

The laptop creates an IP packet.

Source IP      = 192.168.1.100
Destination IP = 8.8.8.8

Then it creates a frame.

Source MAC      = BB:BB:BB:BB:BB:BB
Destination MAC = AA:AA:AA:AA:AA:AA

This reveals an important networking principle:

Destination IP  = Final Destination

Destination MAC = Next Hop

For many beginners, this is the first surprising realization.

Step 7: NAT Changes the Source Address

The router receives the packet.

The router notices:

192.168.1.100

is a private IP address.

Private addresses cannot travel across the public Internet.

The router performs:

NAT

Network Address Translation.

The source address changes from:

192.168.1.100

to:

49.43.12.10

which is the router's public IP.

The router also records this translation in its NAT table.

This is how replies find their way back later.

Step 8: Routers Forward the Packet

The packet begins traveling across the Internet.

An important detail often goes unnoticed.

At every hop:

Old Ethernet Frame
      ↓
Discarded

New Ethernet Frame
      ↓
Created

This means:

MAC Addresses
Change at every hop

while:

IP Addresses
Remain largely unchanged

This is why networking engineers often say:

MAC = Hop-to-Hop

IP = End-to-End

Step 9: The DNS Server Responds

Eventually the packet reaches:

8.8.8.8

Google DNS receives:

Source IP = 49.43.12.10
Destination IP = 8.8.8.8

Notice something important.

Google never sees:

192.168.1.100

It only sees the public address created by NAT.

Google replies:

example.com = 104.26.10.50

Step 10: The Reply Finds Its Way Home

The DNS reply eventually returns to the home router.

The router consults its NAT table:

49.43.12.10:53001
        ↓
192.168.1.100:53001

The router now knows exactly which device requested the information.

The reply is forwarded back to the laptop.

Step 11: TCP Establishes a Connection

Now the browser finally knows:

example.com = 104.26.10.50

Before sending data, TCP establishes a connection.

The famous three-way handshake occurs:

SYN
 ↓
SYN-ACK
 ↓
ACK

The connection is now established.

Step 12: TLS Creates Encryption

Because the website uses HTTPS, encryption must be negotiated.

The browser and server exchange:

Certificates
Cryptographic parameters
Session keys

An encrypted channel is created.

Only after this step can secure communication begin.

Step 13: The Actual Website Loads

Finally, the browser sends:

GET /

The server responds with:

HTML
CSS
JavaScript
Images

The browser renders everything.

The webpage appears.

What Changes When a VPN Is Enabled?

Without a VPN:

Laptop
 ↓
Router
 ↓
ISP
 ↓
Website

With a VPN:

Laptop
 ↓
Router
 ↓
ISP
 ↓
VPN Server
 ↓
Website

The router does not disappear.

ARP still happens.

DHCP still happens.

Frames still exist.

The difference is that traffic is encrypted and sent to the VPN server first.

To the ISP:

VPN Server

appears to be the destination.

The actual website remains hidden inside the encrypted tunnel.

The Mental Model That Finally Helped

Networking became easier once I stopped imagining the Internet as a single connection.

Instead, I started viewing it as many small conversations.

Laptop ↔ Router

Router ↔ ISP Router

ISP Router ↔ ISP Router

ISP Router ↔ Destination

Each conversation uses different MAC addresses.

The IP packet survives the journey.

Once that idea clicked, concepts such as:

DHCP
ARP
DNS
NAT
VPNs
Routing
Wireshark captures

started feeling like pieces of the same puzzle instead of isolated protocols.

Final Thoughts

For a long time, networking felt overwhelming because every protocol seemed independent.

The breakthrough came when I followed a single packet from start to finish.

Rather than memorizing definitions, I began asking:

What problem is this protocol solving right now?

Viewed through that lens:

DHCP provides identity.
ARP finds local devices.
DNS finds destinations.
NAT enables Internet access.
TCP creates reliable communication.
TLS secures it.

And together, they make something as ordinary as loading a webpage possible.