DEV Community: Micheal Angelo

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.

A URL Worked on My Work Laptop but Not My Personal Laptop — Here's What That Taught Me About VPNs, ARP, and Networking

Micheal Angelo — Sat, 13 Jun 2026 02:41:14 +0000

One of the most effective ways to learn networking is to stop memorizing protocols and start investigating real problems.

Recently, I encountered a situation that seemed simple at first.

A newly deployed internal service was accessible from my work laptop but not from my personal laptop.

A month later, the exact same URL became accessible from both devices.

At first glance this looked like a permissions issue.

But the more I investigated, the more networking concepts started connecting together.

What began as a simple question eventually led me through:

Cloud networking
VPNs
Public vs private IP addresses
MAC addresses
ARP
Ethernet frames
Packet captures in Wireshark

This article summarizes the mental models that finally helped these concepts click.

The Original Question

The observation was simple:

Work Laptop
     ↓
URL works

Personal Laptop
     ↓
URL does not work

Later:

Work Laptop
     ↓
URL works

Personal Laptop
     ↓
URL also works

The obvious question was:

How does a server know the difference between two laptops?

Both devices were connected to the same home network.

Both were using the same internet connection.

So what was different?

My First Hypothesis: Cloud Networking Rules

My first assumption was that the answer lived inside the cloud platform.

Regardless of whether a service runs on:

AWS
Azure
GCP

all cloud providers offer mechanisms for controlling network access.

Examples include:

AWS

Security Groups
Network ACLs

Azure

Network Security Groups (NSGs)

GCP

Firewall Rules

The names differ.

The underlying goal is the same:

Allow traffic
Block traffic
Control who can reach a service

This led me to a hypothesis:

Perhaps the service was initially restricted and later opened to a broader audience.

That explanation seemed plausible.

But there was another possibility.

The VPN Realization

My work laptop regularly connects through a VPN.

Specifically:

GlobalProtect VPN

This changed how I thought about the problem.

Without a VPN, traffic follows a path similar to:

Laptop
   ↓
Home Router
   ↓
ISP
   ↓
Internet
   ↓
Destination Server

With a VPN:

Laptop
   ↓
Home Router
   ↓
ISP
   ↓
VPN Gateway
   ↓
Company Network
   ↓
Destination Server

This raised a new possibility.

The server might not care about:

Work Laptop
vs
Personal Laptop

Instead, it might care about:

Company Network
vs
Public Internet

That distinction made much more sense.

Understanding IP Addresses

This investigation also exposed a misunderstanding I had about IP addresses.

There isn't just one IP address involved.

There are several.

Local IP Address

Assigned by your router through DHCP.

Example:

192.168.1.10

This address exists only inside your home network.

Internet servers never see it directly.

Public IP Address

Assigned by your ISP.

Example:

103.x.x.x

This is the address most internet services see.

VPN Address

Assigned by the VPN infrastructure.

Example:

10.50.x.x

When connected to a VPN, company systems may see this address instead of your ISP-assigned address.

This was an important realization.

A server often identifies where a request is coming from based on IP addresses—not based on the physical laptop itself.

The MAC Address Misconception

Another misconception I had involved MAC addresses.

Initially I assumed that remote services might somehow see the MAC address of my network card.

That is not how networking works.

What Actually Happens

Imagine traffic moving toward GitHub:

Laptop
   ↓
Router
   ↓
ISP Router
   ↓
More Routers
   ↓
Datacenter Router
   ↓
GitHub

At every hop:

MAC Address
Changes

IP Address
Remains the same

This means:

GitHub never sees the MAC address of my Wi-Fi card.

GitHub sees my public IP address.

That single insight corrected a large part of my networking mental model.

Where ARP Fits In

This naturally led to another question:

If devices communicate using MAC addresses locally, how does a device discover a MAC address?

The answer is:

ARP

Address Resolution Protocol.

The Problem ARP Solves

Suppose a device knows:

192.168.1.10

but does not know:

2c:9c:58:8b:2d:7b

ARP exists to bridge that gap.

Its purpose is simple:

IP Address
      ↓
Find MAC Address

An ARP Request in Plain English

A typical ARP request looks like:

Who has 192.168.1.10?
Tell 192.168.1.1

Translated into normal language:

I am 192.168.1.1

I am looking for
192.168.1.10

Who owns that address?

ARP requests are broadcast to the entire local network.

The ARP Reply

The device that owns the address responds:

192.168.1.10 is at
2c:9c:58:8b:2d:7b

Meaning:

I own that IP address.

Here is my MAC address.

The router can now send Ethernet frames directly to the correct device.

A Discovery from Wireshark

While inspecting packets in Wireshark, I noticed something surprising.

The packet structure looked like:

Frame
   ↓
Ethernet II
   ↓
ARP

Notice what is missing.

There is no:

IP

layer between Ethernet and ARP.

This was unexpected.

I initially assumed ARP worked inside IP.

It does not.

ARP operates alongside IP.

Why ARP Has No TTL

Another misconception involved TTL.

I assumed every networking protocol contained fields such as:

TTL
Routing information
IP headers

That assumption was wrong.

TTL exists because IP packets travel through routers.

Example:

Laptop
   ↓
Router
   ↓
ISP
   ↓
Internet
   ↓
Destination

Each router decreases the TTL value.

ARP packets never leave the local network.

They are not routed across the internet.

Because of that:

No Routing
      ↓
No TTL Needed

Once I understood this, ARP's design suddenly made much more sense.

The Mental Models That Finally Clicked

After all of this investigation, several concepts became much easier to remember.

Cloud Networking

Different names.

Same networking fundamentals.

VPN

Changes the route packets take.

IP Address

Identifies a device across networks.

MAC Address

Identifies a network interface on a local network.

ARP

Answers:

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

DHCP

Answers:

"I just joined the network. Which IP address should I use?"

DNS

Answers:

"I know the website name. Which IP address does it map to?"

Final Thoughts

What started as a simple access issue turned into a useful networking lesson.

The biggest takeaway wasn't a specific protocol.

It was a different way of learning.

Instead of memorizing definitions, I found it far more effective to observe actual packet exchanges and then ask:

Why did that happen?

Wireshark made invisible networking behavior visible.

And once the packets became visible, many concepts that previously felt disconnected finally started fitting together.

Learning DevOps from First Principles: What an EC2 Instance Actually Is

Micheal Angelo — Mon, 08 Jun 2026 03:16:19 +0000

One of the first cloud concepts many people encounter while learning AWS is EC2.

The name sounds technical.

The documentation is extensive.

And the number of configuration options can make it feel like something fundamentally different from a regular computer.

But while trying to understand cloud computing, I found myself repeatedly coming back to a simple thought:

At the end of the day, an EC2 instance is just another computer.

That realization helped me understand cloud infrastructure much more clearly.

The Intimidation Factor

When people first open the AWS console, they encounter terms such as:

EC2
VPC
Security Groups
Elastic IPs
Auto Scaling

It is easy to feel that cloud computing is an entirely different world.

But before diving into those concepts, it helps to ask a simpler question:

What is an EC2 instance actually providing?

Starting with the Name

EC2 stands for:

Elastic Compute Cloud

The important word here is:

Compute

AWS is essentially renting computing resources.

When you launch an EC2 instance, AWS allocates:

CPU
Memory (RAM)
Storage
Networking

to a virtual machine that you can access.

In other words:

You are renting a computer that lives inside AWS's infrastructure.

Comparing It to a Personal Computer

Consider a typical laptop.

It contains:

A processor
RAM
Storage
An operating system
Network connectivity

Now consider an EC2 instance.

It also contains:

Virtual CPUs
RAM
Storage
An operating system
Network connectivity

The location is different.

The concepts are the same.

The Main Difference: Ownership

The biggest difference is not technical.

It is operational.

With a personal computer:

You own the hardware.
The machine sits near you.
You maintain it.

With EC2:

AWS owns the hardware.
The machine runs in a data center.
AWS manages the physical infrastructure.

You only manage the virtual machine running on top of it.

Why Linux Knowledge Transfers

This was one of the most interesting observations during my learning.

If an EC2 instance runs Linux, many of the same concepts apply:

File permissions
Processes
Services
Logs
Package management
Networking

For example, if you already know how to:

ssh user@server

check running processes:

ps aux

or inspect network interfaces:

ip addr show

those skills remain useful inside a cloud environment.

The cloud does not replace Linux.

It builds upon it.

Why Networking Suddenly Matters

A local computer often works without much thought about networking.

Cloud systems are different.

To access an EC2 instance, you must think about:

IP addresses
Ports
Firewalls
Security Groups
Routing

Questions such as:

Which traffic should be allowed in?

and

Which traffic should be allowed out?

become important very quickly.

This is one reason networking appears so frequently in DevOps discussions.

The "Elastic" Part

One aspect that does make EC2 different from a personal machine is elasticity.

A laptop has fixed hardware.

An EC2 instance can be changed relatively easily.

Need more RAM?

Choose a larger instance type.

Need more CPU?

Launch a different instance.

Need multiple servers?

Create several instances.

The computer remains conceptually the same.

The flexibility changes.

A Useful Mental Model

The way I currently think about it is:

```text id="l6t4uy"
Personal Computer
↓
Virtual Machine
↓
Cloud Virtual Machine (EC2)




The further you move down this chain, the more infrastructure management is abstracted away.

But the underlying concepts remain familiar.

---

## Why This Perspective Helped Me

Initially, cloud services felt like hundreds of disconnected products.

But viewing EC2 as "just another computer" made many concepts easier to understand.

Instead of asking:

> "How does AWS work?"

I could start by asking:

> "How would I do this on a Linux machine?"

Often, the cloud version turns out to be an abstraction of something that already exists.

---

## Final Thoughts

Cloud computing introduces many new terms.

Some of them are genuinely new concepts.

Others are familiar ideas presented at a larger scale.

For me, EC2 became much easier to understand once I stopped thinking of it as a cloud product and started thinking of it as a computer.

A computer with CPU, RAM, storage, networking, and an operating system.

Just running somewhere else.

And sometimes, understanding a complex system begins by realizing that it may be simpler than it first appears.

Same Hardware, Different Experience: Why Linux Feels Faster

Micheal Angelo — Mon, 08 Jun 2026 03:16:05 +0000

A few weeks after switching from Windows to Linux, I noticed something interesting.

The hardware had not changed.

The processor was the same.

The RAM was the same.

The SSD was the same.

And yet, the laptop felt noticeably faster.

Not necessarily because applications were completing tasks dramatically quicker, but because the entire system felt more responsive.

Keyboard input felt immediate.

Windows opened faster.

Terminal commands appeared instantly.

The desktop experience felt smoother.

This raised a question:

How can the same hardware feel different simply because the operating system changed?

While I'm still learning, this is the mental model I've built so far.

The Hardware Didn't Change

Consider a laptop with:

AMD Ryzen processor
16 GB DDR5 RAM
NVMe SSD
Modern integrated graphics

When switching operating systems, none of these components change.

The CPU does not suddenly become faster.

The RAM does not magically increase.

The SSD remains identical.

From a hardware perspective:

```text id="u3m9xd"
Before → Same Hardware
After → Same Hardware




So the difference must come from somewhere else.

---

## An Operating System Is Not Just a User Interface

Many people think of an operating system primarily as the desktop they see.

But an operating system does far more than display windows and icons.

It manages:

* Memory
* CPU scheduling
* Processes
* Storage
* Networking
* Device drivers
* Background services

In other words:

> The operating system decides how hardware resources are used.

Two operating systems can therefore create very different experiences using the same hardware.

---

## Perceived Performance vs Raw Performance

One thing I have learned is that performance is not always about benchmarks.

A system can have excellent benchmark scores and still feel sluggish.

Why?

Because users experience responsiveness, not benchmark numbers.

Examples include:

* How quickly a window opens
* How fast a menu appears
* How responsive typing feels
* How quickly applications launch

These small interactions shape our perception of speed.

---

## Background Services Matter

Modern operating systems often run numerous services in the background.

Examples include:

* Update services
* Search indexing
* Telemetry collection
* Synchronization services
* Device management services

Many of these provide useful functionality.

However, they also consume resources.

Even when no application is actively running, background processes may still be:

* Using memory
* Accessing storage
* Performing network activity
* Scheduling CPU work

This creates a baseline level of system activity.

---

## Resource Utilization Is a Shared Budget

A useful way to think about system resources is as a shared budget.

Your laptop has finite:

* CPU cycles
* Memory
* Storage bandwidth

Every running service consumes part of that budget.

The more resources allocated to background tasks, the fewer remain available for user-facing work.

This does not necessarily mean one operating system is "better" than another.

Different operating systems make different trade-offs.

---

## Different Priorities, Different Results

One realization that helped me understand the situation is this:

Operating systems are optimized for different goals.

Some prioritize:

* Broad hardware compatibility
* Enterprise features
* Legacy application support

Others prioritize:

* Simplicity
* Minimalism
* Resource efficiency

Neither approach is inherently right or wrong.

They simply optimize for different audiences.

---

## Why Linux Often Feels Lightweight

Many Linux distributions allow users to choose exactly what they install.

Examples include:

* Desktop environments
* Services
* Background applications
* System utilities

This flexibility often results in systems that run fewer background components by default.

Consequently:

* Memory usage may be lower
* Idle CPU usage may be lower
* Disk activity may be reduced

The hardware itself has not changed.

The workload placed on it has.

---

## The Importance of Responsiveness

One thing I did not fully appreciate before switching is how much responsiveness affects the user experience.

Consider typing.

If every keypress appears immediately, the system feels fast.

If there is even a slight delay, users notice it.

The same applies to:

* Opening terminals
* Launching applications
* Switching windows

The actual difference may only be milliseconds.

Yet those milliseconds accumulate into a perception of smoothness.

---

## Why This Matters for DevOps Learning

This observation also connects back to learning DevOps.

Many cloud servers run Linux.

Understanding Linux is not only about commands and configuration files.

It is also about understanding how operating systems manage resources.

Concepts such as:

* Memory usage
* Running processes
* Service management
* System monitoring

appear repeatedly in real-world infrastructure.

The desktop experience simply provides a visible example of those concepts.

---

## A Simple Mental Model

The way I currently think about it is:



```text id="r2n6wk"
Hardware
    +
Operating System
    +
Running Workloads
    =
User Experience

The hardware is only one part of the equation.

The operating system and workload distribution matter just as much.

Final Thoughts

After switching operating systems, the hardware remained exactly the same.

Yet the overall experience changed noticeably.

That experience made me realize something important:

Performance is not only about how powerful a machine is.

It is also about how efficiently its resources are used.

The fastest-feeling system is not always the one with the most powerful hardware.

Sometimes, it is simply the one asking the hardware to do less.

And that has been one of the most interesting lessons from exploring Linux so far.

Learning DevOps from First Principles: MAC Addresses vs IP Addresses — The Difference Finally Clicked

Micheal Angelo — Mon, 08 Jun 2026 03:15:52 +0000

One of the first networking concepts that confused me was this:

Why does a computer need both a MAC address and an IP address?

At first glance, they seem to solve the same problem.

Both appear to identify a device.

Both show up in networking tools.

Both appear in packet captures.

So why do we need two different addresses?

While exploring Linux networking tools and Wireshark, the distinction finally started making sense.

This article summarizes the mental model that helped me understand the difference.

Looking Inside the Machine

Before discussing addresses, it helps to understand where they come from.

If you open a typical laptop, you will usually find components such as:

Battery
RAM
Storage
Processor
Cooling system
Network interfaces

One of those network interfaces is typically:

A Wi-Fi card
An Ethernet controller

These components are responsible for network communication.

They are the parts of the machine that actually send and receive data across a network.

Every Network Interface Has an Identity

A network interface needs a way to identify itself.

This is where the MAC address comes in.

A MAC address is associated with a network interface card (NIC).

Example:

```text id="q3d9nm"
2C:9C:58:8B:2D:7B




Think of it as the identity of the network interface itself.

Not the operating system.

Not the browser.

Not the application.

The network hardware.

---

## What Is a MAC Address?

MAC stands for:

**Media Access Control**

A MAC address operates at the **Data Link Layer** of the OSI model.

Its primary purpose is to help devices communicate within a local network.

Examples include:

* Laptop to router
* Router to switch
* Switch to printer

In other words:

> MAC addresses help devices find each other on the same local network.

---

## What Is an IP Address?

An IP address serves a different purpose.

Example:



```text id="g8x4tc"
192.168.1.20

```text id="v6u7mz"
2405:201:8000::1




IP addresses operate at the **Network Layer**.

Their job is to identify where a device exists within a larger network.

This allows communication beyond a single local network.

For example:

* Home network → Internet
* Office network → Cloud server
* Laptop → GitHub

---

## The Question That Helped Me

The mental model that helped me most was:

**MAC Address answers:**

> Which physical device on this local network should receive this data?

**IP Address answers:**

> Which device anywhere in the world should receive this data?

They solve related but different problems.

---

## Hardware Identity vs Logical Identity

This is where things finally clicked for me.

A MAC address is tied to a network interface.

An IP address is assigned by the network.

Think of it this way:

### MAC Address



```text id="w2l7fa"
Identity of the network hardware

IP Address

```text id="h5r3ek"
Identity assigned within a network




One identifies the hardware.

The other identifies the location.

---

## Why Not Use Only MAC Addresses?

Initially, I wondered:

> Why not simply use MAC addresses everywhere?

The problem is scale.

Imagine trying to communicate with a server on another continent.

Routers across the internet cannot practically route traffic based on MAC addresses alone.

Instead:

* IP addresses handle routing across networks.
* MAC addresses handle delivery within local networks.

This division of responsibility makes networking scalable.

---

## Seeing It in Linux

One of the easiest ways to observe this is:



```bash id="j8r4np"
ip addr show

Typical output includes interfaces such as:

```text id="f2q7xs"
lo
eth0
wlp2s0




You may also see:

### MAC Address



```text id="c9m5vn"
link/ether 2c:9c:58:8b:2d:7b

IPv4 Address

```text id="u4x6la"
inet 192.168.1.20




### IPv6 Address



```text id="b7p8dw"
inet6 2405:201:8000::1

Seeing both together helped reinforce that they serve different purposes.

Where Wireshark Made It Click

While experimenting with Wireshark, I noticed that packets often contained both:

Source MAC Address
Destination MAC Address

and

Source IP Address
Destination IP Address

At first this felt redundant.

But it eventually became clear:

The packet needs:

IP information to determine where it should go globally.
MAC information to determine which device should receive it locally.

Both are necessary.

A Simple Analogy

Imagine sending a letter.

The city and street address represent the IP address.

They help the postal system route the letter across large distances.

The person's name on the mailbox resembles the MAC address.

Once the letter arrives at the correct location, it still needs to reach the correct recipient.

The analogy is not perfect, but it helped me visualize the distinction.

A Useful Mental Model

The way I currently think about it is:

```text id="n8y3vk"
IP Address
↓
Find the correct network

MAC Address
↓
Find the correct device




Together they allow communication to scale from local networks to the global internet.

---

## Why This Matters for DevOps

At first glance, MAC addresses and IP addresses seem like purely networking topics.

But they appear everywhere:

* Cloud servers
* Containers
* Virtual machines
* Kubernetes networking
* Load balancers
* VPNs

Understanding the distinction makes many higher-level networking concepts easier to grasp.

---

## Final Thoughts

For a long time, MAC addresses and IP addresses felt like two different labels describing the same thing.

They are not.

A MAC address identifies a network interface on a local network.

An IP address identifies a device's location within a larger network.

One focuses on hardware-level delivery.

The other focuses on network-level routing.

And once that distinction clicked, many networking concepts suddenly became much easier to understand.