Hello! Welcome to the sixth lesson in our MLOps and Model Deployment module.
In our last lesson, we built a complete Continuous Integration pipeline with GitHub Actions. You learned how to automatically run tests and, more importantly, how to build your application into a standardized, portable Docker image and push it to a container registry like Docker Hub. That image is now a self-contained, deployable artifact.
But an image sitting in a registry isn't providing any value. How do we run it and make it accessible to users? This lesson bridges that final gap. Our learning outcome is to deploy containerized applications to cloud platforms (AWS/GCP basics). We will take the container we conceptually built in the last lesson and learn how to run it on the world's leading cloud infrastructure providers.
This step is what makes your AI application a real-world solution.
1. The Cloud Deployment Landscape
When we talk about deploying containers in the cloud, we're moving away from managing individual servers. Instead, we use services designed to run, manage, and scale containerized applications. The three major cloud providers—Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure—all offer powerful services for this.

The two main approaches we'll explore are:
- Amazon Elastic Container Service (ECS) on AWS: A highly scalable, high-performance container orchestration service. It can run containers on virtual machines you manage (EC2) or in a "serverless" mode called Fargate, where AWS manages the underlying infrastructure for you. We will focus on Fargate for its simplicity and power.
- Google Cloud Run on GCP: A fully managed platform that allows you to run stateless containers in a serverless way. It's known for its simplicity and speed, automatically scaling up or down (even to zero) based on traffic.
The general workflow for both platforms is conceptually similar:
- Push your Docker image to a container registry (like Docker Hub, AWS ECR, or Google Artifact Registry).
- Define a "service" or "task" on the cloud platform, telling it which image to run and what resources (CPU, memory) it needs.
- The cloud platform pulls the image from the registry and runs it, providing you with a public URL to access your application.
2. Deploying to AWS Elastic Container Service (ECS)
Let's start with AWS, the most dominant player in the cloud market. We will deploy a containerized FastAPI application to ECS using the Fargate launch type. This means we don't have to worry about provisioning or managing any servers.
The following video provides a complete, end-to-end walkthrough of this process. It picks up right where we left off in the last lesson: with a Docker image ready for deployment.
How to Deploy ML Solutions with FastAPI, Docker, & AWS
This video by Shaw Talebi demonstrates how to take a containerized ML application, push it to Docker Hub, and deploy it on AWS ECS with Fargate. This is a very practical and common workflow in the industry.
Watch the section from 00:19:38 to 00:25:57. This is a dense, step-by-step guide, so feel free to pause and re-watch parts. As you watch, focus on understanding these key AWS concepts: Task Definition: The blueprint for your application. It specifies the Docker image to use, CPU/memory allocation, and other container settings. Cluster: A logical grouping of your services and tasks. Think of it as a namespace for your application environment. Service: This is what actually runs and maintains your application. It ensures that a specified number of instances of your task definition are always running. Security Groups: A virtual firewall that controls inbound and outbound traffic to your service. The video mentions having to configure this to allow traffic from your IP address.

To recap the process from the video:
- Create a Task Definition: You define the container image URL (from Docker Hub), CPU and memory, and the port your application listens on.
- Create a Cluster: You create an ECS cluster that will host your service. You specify Fargate as the infrastructure.
- Create a Service: Within the cluster, you create a service, linking it to your task definition and specifying how many copies of the container you want running.
- Testing: AWS provisions the resources and starts your container. Once running, you can access it via the public IP address assigned to the task.
A Critical Reminder: Cloud resources cost money. As the video and official documentation emphasize, it is crucial to delete your resources (the cluster, service, etc.) after you are done experimenting to avoid unexpected charges. The AWS documentation "Deploy Docker Containers on Amazon ECS" (resource LINK) provides a simple, wizard-based walkthrough and has a clear section on cleaning up resources.
3. Deploying to Google Cloud Run
Now let's look at the process on Google Cloud Platform. We'll use Cloud Run, which is praised for its developer-friendly experience. It abstracts away even more of the configuration compared to ECS.
The following video demonstrates how to deploy a containerized ML model to Cloud Run using the gcloud command-line tool.
Quick & Easy Deploy ML Model into Google Cloud. Explained.
This video by Daniel provides a fantastic from-scratch guide to deploying on Google Cloud Run. We'll break it down into the key stages: setup, building the image, and deployment.
This is a detailed walkthrough. Follow these segments in order: Initial GCP Setup (Watch 10:56 - 15:35): Understand the one-time setup process: creating a billing account, installing the gcloud SDK, creating a project, and enabling the necessary APIs (Cloud Run, Artifact Registry, Cloud Build). Build and Push the Image (Watch 15:35 - 17:44): Observe how the gcloud build submit command is used. This command builds your Docker image in the cloud and pushes it to Google's Artifact Registry (GCP's equivalent of Docker Hub). Deploy to Cloud Run (Watch 17:44 - 19:29): This is the magic step. Pay attention to how a single gcloud run deploy command takes the image from Artifact Registry and deploys it, automatically providing a secure (HTTPS) public URL.
The process on GCP can be summarized as:
- Project Setup: Configure your GCP project, billing, and enable the required APIs. This is mostly a one-time task.
- Build & Push: Use the
gcloudCLI to build your Docker image and push it to Google Artifact Registry. - Deploy: Use the
gcloud run deploycommand, pointing to your image. Cloud Run handles the rest: it provisions infrastructure, starts your container, and gives you a live, secure HTTPS endpoint.
One of the significant advantages highlighted here is that Cloud Run automatically provisions a TLS certificate, meaning your endpoint is https by default without any extra configuration.
A Critical Reminder (Again!): Just like with AWS, you must clean up your GCP resources. The video explains how to delete the service and the entire project from 25:44 onwards to stop incurring costs. This is a non-negotiable step when learning.
Conclusion
Congratulations! You have now learned the final, crucial step in bringing an ML application to life: deploying it to the cloud. You've seen how to take a containerized application and make it a scalable, reliable service running on world-class infrastructure.
Key Takeaways:
- Cloud platforms like AWS and GCP offer managed services to run containerized applications without managing servers.
- AWS ECS with Fargate is a powerful orchestration service where you define Task Definitions, group them in Clusters, and manage them with Services.
- Google Cloud Run is a highly simplified, serverless platform where you can deploy a container with a single command and automatically get a secure HTTPS endpoint.
- The general deployment pattern is consistent: build an image, push it to a registry, and create a cloud service that runs that image.
- Always clean up your cloud resources after you're done! This is the most important habit to build when starting with the cloud.
Preview of the Next Lesson:
Our application is now running live on the internet. But our work as MLOps engineers isn't over. Is the application healthy? Is it responding quickly? Are the model's predictions accurate? In the next lesson, we will address these questions by learning how to monitor model performance metrics in production.