From Docker to AWS: Understanding How Containers Become Cloud Applications

One of the first things I learned while building backend applications was how different development can be on a local machine compared with running an application for real users.

My application could work perfectly on my laptop, but I started asking:

What happens when I want to deploy it to the cloud?

That question led me to Docker and eventually to AWS container services.

This article explains how I understand the journey from a local application to a containerized cloud application.

---

The Problem With "It Works on My Machine"

Imagine I have a FastAPI application.

On my laptop, I might have:

Python
FastAPI
PostgreSQL
Redis
Environment Variables
Dependencies

Everything works because my machine has been configured for the application.

But when another developer tries to run it, they might have a different Python version, missing dependencies, or a different configuration.

This is where containers become useful.

---

What Is a Container?

A container packages an application together with the environment it needs to run.

Instead of saying:

«"Install Python, install these packages, configure these variables, and then run the application."»

I can package the application into a container image.

The idea becomes:

Application
+
Dependencies
+
Runtime
↓
Container Image

The same image can then be used in different environments.

---

My First Step: Docker

For a FastAPI application, a Dockerfile can describe how the application should be packaged.

A simplified example looks like this:

FROM python:3.12

WORKDIR /app

COPY requirements.txt .

RUN pip install -r requirements.txt

COPY . .

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

Now the application can be built into a Docker image.

Dockerfile
↓
Docker Image
↓
Docker Container
↓
FastAPI Application

This was an important step in my understanding of deployment.

---

But Where Does AWS Come In?

Docker solves the packaging problem.

But we still need somewhere to run our containers.

This is where AWS provides several options.

For containerized applications, services such as Amazon ECS and AWS Fargate can be used to run containers without managing traditional servers in the same way as a manually configured virtual machine.

The architecture can look like:

Internet
│
▼
Load Balancer
│
┌─────────┴─────────┐
▼ ▼
Container 1 Container 2
│ │
└─────────┬─────────┘
▼
Application

Now we are starting to think about the application as a cloud system rather than a program running on one laptop.

---

What Is Amazon ECS?

Amazon ECS, or Elastic Container Service, is an AWS service for running and managing containers.

Instead of manually starting containers one by one, ECS can manage the desired number of running tasks.

For example:

ECS Service

Desired Tasks: 3

┌─────────────┐
│ Task 1 │
├─────────────┤
│ Task 2 │
├─────────────┤
│ Task 3 │
└─────────────┘

If the application needs more capacity, the number of tasks can be increased.

This introduces me to an important cloud concept:

scaling.

---

What Is AWS Fargate?

One reason I find Fargate interesting is that it allows containers to run without requiring me to manage the underlying servers directly.

The mental model becomes:

My Application
↓
Docker Image
↓
ECS
↓
Fargate
↓
AWS Infrastructure

I focus more on the application and container configuration while AWS manages much of the underlying infrastructure.

---

Where Does the Docker Image Live?

Before AWS can run my container, it needs access to the container image.

This is where Amazon Elastic Container Registry (ECR) can be used.

The workflow becomes:

Developer
↓
Build Docker Image
↓
Amazon ECR
↓
Amazon ECS
↓
AWS Fargate
↓
Running Application

This is a much clearer deployment pipeline for me than simply thinking:

«"Upload my project to AWS."»

---

Adding a Database

My backend also needs persistent data.

Instead of keeping the database inside the application container, a managed database service such as Amazon RDS can be used for relational database workloads.

The architecture could become:

Internet
│
▼
Load Balancer
│
┌─────┴─────┐
▼ ▼
FastAPI FastAPI
Container Container
│ │
└─────┬─────┘
│
▼
Amazon RDS

This separation is important.

The application containers can be replaced or scaled without treating the database as temporary application infrastructure.

---

What About Files?

Applications often need to store files, images, documents, logs, or other objects.

For object storage, AWS provides Amazon S3.

The architecture can then include:

FastAPI
│
├──────► RDS
│
└──────► S3

Each service has a specific responsibility.

This is one of the biggest lessons I'm learning about cloud architecture:

«Use the right service for the right problem.»

---

The Bigger Picture

Putting the pieces together, the architecture starts looking like this:

Users
│
▼
┌────────────────┐
│ Load Balancer │
└───────┬────────┘
│
┌───────────┴───────────┐
▼ ▼
┌────────────┐ ┌────────────┐
│ FastAPI │ │ FastAPI │
│ Container │ │ Container │
└─────┬──────┘ └──────┬─────┘
│ │
└──────────┬─────────────┘
│
┌────────────┼────────────┐
▼ ▼ ▼
RDS Redis S3

This is no longer just a backend application.

It is becoming a cloud-native architecture.

---

What I Learned

The biggest thing I learned is that Docker and AWS solve different problems.

Docker helps package and run applications consistently.

AWS provides infrastructure and managed services to run those applications at scale.

Together, they provide a powerful foundation for modern applications.

My learning path is becoming:

Python
↓
FastAPI
↓
PostgreSQL
↓
Redis
↓
Docker
↓
AWS
↓
Cloud-Native Applications

---

What's Next?

I want to take this knowledge further by learning how to:

- Build Docker images efficiently
- Push images to Amazon ECR
- Deploy containers using ECS and Fargate
- Configure networking with Amazon VPC
- Add load balancing
- Connect applications to RDS
- Store files in S3
- Monitor applications with CloudWatch
- Secure resources using IAM
- Automate deployment using CI/CD

Eventually, I want to deploy one of my own projects completely on AWS.

---

Final Thoughts

When I first started learning cloud computing, AWS looked like a huge collection of services.

Now I'm beginning to see it differently.

Instead of memorizing services, I'm trying to understand the engineering problem behind each one.

Docker answered:

"How can I package my application consistently?"

AWS answers:

"How can I run, connect, secure, monitor, and scale that application in the cloud?"

That shift in thinking is what makes cloud computing exciting for me.

And my next step is simple:

Take what works on localhost and learn how to make it work in the cloud.