DEV Community: Temitope Olatunji

Build a highly available containerized API with Python, Amazon ECR, ECS and AWS API Gateway

Temitope Olatunji — Mon, 02 Feb 2026 22:06:45 +0000

This project demonstrates building a containerized API management system for querying sports data. It leverages Amazon ECS (Fargate) for running containers, Amazon API Gateway for exposing REST endpoints, and an external Sports API for real-time sports data. The project showcases advanced cloud computing practices, including API management, container orchestration, and secure AWS integrations.

Project Architecture

Understanding the workflow

This workflow begins with a Python Flask backend app that fetches sports data from a SERP API endpoint.
The Python app is containerized using Docker for easy accessibility on Amazon ECR(Elastic Container Registry) as a publicly accessible docker image.
Amazon ECS Cluster uses Fargate to create and run containers, which allocate resources automatically for running containers.
Application Load Balancer handles distributing request evenly to the running containers on the ECS Cluster.
Amazon API Gateway add much more security by providing a public-facing URL endpoint for the API for client/user to request from. With API Gateway we can implement authorization, throttling which protects backend system from attacks.

Prerequisites

Register for a free account/subscription at serpapi.com and obtain your API Key
Install and configure AWS CLI to programmatically interact with AWS
Install Serpapi library in local environment “pip install google-search-results”
Install docker CLI and Docker Desktop to build and ush container images
Create AWS account with basic understanding of containers, APIs and Python

Technologies

Cloud Provider: AWS
Core Services: Amazon ECS (Fargate), API Gateway, CloudWatch
Programming Language: Python 3.x
Containerization: Docker
IAM Security: Custom least privilege policies for ECS task execution and API Gateway

Project Structure

Check the Github repository here

Implementation

STEP 1: Docker Python Flask Application

The project folder contains a Dockerfile. This file defines how our application and dependencies should be packaged into a docker image.

docker build --platform linux/amd64 -t sports-api:1.0 .

STEP 2: Push Docker Image to ECR

The first initial step is to create a repository on ECR to host the docker image.

aws ecr create-repository --repository-name <repo-name> --region <your-region>

Pushing docker to ECR requires Authenticate to AWS

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin <AWS_ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com

Tag Docker Image

docker tag sports-api:latest <AWS_ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/nfl-sports-api:1.0

Push Image to ECR

docker push <AWS_ACCOUNT_ID>.dkr.ecr.us-east-1.amazonaws.com/nfl-sports-api:1.0

Here's a screenshot of the AWS ECR repository

STEP 3: Set up ECS Cluster with Fargate to Deploy Image

Create an ECS cluster

Fargate is a serverless architecture which need not provisioning of servers

Go to the ECS Console → Clusters → Create Cluster

Create a Task definition

Task definition tells ECS how to run the containers, including details like the container image to use, ports, and any environment variables needed by the container.

Choose the launch type (Fargate)
Add the container image from ECR.
Name the container
Set the container port to 8080.
Pass “sports_api_key” API key as an environment variable.

Create a Service

Specify the number of tasks you want to run (e.g., 2 or more tasks for high availability).
A new security group (firewall rules) and set it to allow all TCP traffic from anywhere.
Attach an Application Load Balancer (ALB) to the service, which routes user requests to the containers.
Set up a health check for the ALB to ensure the application is functioning properly (/sports).

Go to the AWS loadbalancer console and click on the DNS endpoint to access the application

STEP 4: Integrate API Gateway

Create a New REST API:

Go to the API Gateway Console.
Click on Create API and select REST API.
Name the API.

Set Up Integration:
Create a resource named “/sports”.
Create a GET method for the resource.
Choose HTTP Proxy as the integration type.
Enter the DNS name of the ALB that includes “/sports”
Deploy the API:
Deploy the API to a stage (e.g., “prod or dev”).
Note the endpoint URL provided by the API Gateway.

Key Lessons

While implementing the Sports API Management System, I learned several key lessons:

Simplified Deployment with Docker: Docker containers made it easy to package and deploy the application by bundling everything needed to run the app. This ensured consistency across different environments.
Serverless Infrastructure with AWS Fargate: Using AWS Fargate eliminated the need to manage underlying infrastructure, allowing me to focus on the application itself. Fargate handled the compute resources, making the deployment process seamless.
Secure and Scalable API Exposure with API Gateway: Amazon API Gateway provided a secure and scalable way to expose the REST API to the internet. It added a layer of security and control, ensuring that only authorized users could access the API.
High Availability and Load Balancing with ALB: The Application Load Balancer (ALB) distributed incoming traffic across multiple containers, ensuring high availability and improved performance. The ALB also performed health checks to ensure the application was functioning properly.
Automated Scaling: With AWS tools like ECS, Fargate, and API Gateway, the system was ready to scale automatically based on demand. This reduced the overhead of managing infrastructure and allowed me to focus on the application.
Cloud-Native Tools: Leveraging cloud-native tools simplified traditionally complex workflows, providing a solid foundation for containerized application deployment and API management. These learnings provided valuable insights into how cloud-native tools can simplify and enhance the deployment and management of containerized applications.

I hope you find this article and lab helpful, happy reading, happy building!!!
LinkedIn | Github | X

Understanding Regional and Global AWS Architecture

Temitope Olatunji — Thu, 22 Jan 2026 13:10:41 +0000

When building applications on AWS, one of the most common architectural mistakes is thinking only at the regional level and ignoring the global picture.

AWS is fundamentally designed as a global cloud platform, with services that operate at:

Global scope (e.g. Route 53, CloudFront, IAM)

Regional scope (e.g. EC2, RDS, Lambda)

Availability Zone scope (e.g. subnets, EC2 instances)

Understanding how these layers work together is essential for designing highly available, low‑latency, and resilient systems.

In this article, we’ll explore the global and regional perspectives of AWS architecture and how they interconnect in a production-ready application.
By examining the tiers that make up such an application, you will better understand how to optimize cloud-based infrastructure for high availability, performance, and reliability.

Global AWS Architecture

Global architecture answers one key question:

How do users from anywhere in the world reliably reach my application?

Example Scenario

Let's take for instance a global football streaming platform with users in Europe, North America, and Africa. Always our goals should be:

Low latency for users
High availability
Automatic failover if a region goes down

Amazon Route 53

Route 53 is AWS’s global DNS service. It routes user traffic to the best AWS region based on:

Latency‑based routing
Health checks
Geolocation or geoproximity

If one region becomes unhealthy, Route 53 can automatically route traffic to another region.

Amazon CloudFront

CloudFront is AWS’s global Content Delivery Network (CDN).

It caches static and dynamic content at edge locations close to users, reducing latency and offloading traffic from your regional infrastructure.

Regional AWS Architecture

Once traffic reaches a region, regional architecture determines how your application actually runs.

A best‑practice approach is to organize services into logical tiers. This architecture is organized into different functional tiers, each responsible for specific aspects of the application.

Web Tier

Initially, communications from customers will generally enter the web tier making this regional based AWS service such as an Application Load Balancer (ALB) or API gateway depending on the architecture that the application uses.

The purpose of the web tier is to act as an entry point for regional based applications whilst abstracting customers away from the underlying infrastructures. This in simple terms means that infrastructure can scale or fail or change without impacting customers or user experience.

Tier 2: Compute Tier

The functionality provide to the user/customer via the web tier is provided by the compute tier using services such as Amazon EC2, Lamba or containers.

In the instance given earlier, In this tier a load balancer will be responsible for serving request Amazon EC2 instances whilst handling auto scaling for demand spikes, multi-AZ deployment.

Tier 3: Storage Tier

The compute tier will consume storage services which is another part of all AWS architecture (global) and, this tier will use services such as Amazon EBS (Elastic Block Store), Amazon EFS (Elastic File System) for different media storage use cases and also quite useful with data resiliency (e.g S3 CRR).

Tier 4: Database Tier

In addition to file storage, most environment require data storage and within AWS, this is delivered using varieties of AWS services including Relational database system (Amazon RDS), Amazon Aurora, DynamoDB and Redshift for data warehousing.

In order to improve performance of streaming applications direct access to the database is not always best practice, instead it’s best for application to go via proxy or caching layer with AWS Amazon ElastiCache for general caching or DynamoDB accelerator(DAX) when using Amazon dynamoDB, consulting the cache first and only if the data is not present in the cache layer will the database be consulted and the content of the cache will then be updated.

One advantage of caching is that generally caching is in-memory so it’s cheap and fast which helps with cost management because databases tend to be expensive based on the volume of data required.

Tier 5: Application Services

The Application Services Tier provides decoupling and asynchronous processing functionalities such as streaming, messaging, or workflow orchestration wiht lambda or step function. Amazon Kinesis can handle real-time data streaming, useful for analytics or delivering live match updates.

Conclusion

AWS architecture is most effective when you think in layers:

Global services handle routing, performance, and resilience
Regional services handle compute, storage, and data processing

By combining both perspectives, you can design systems that are not only scalable and cost‑effective, but also resilient by default.

If you’re preparing for AWS certifications or designing real‑world systems, mastering this mental model will pay off every time.

If you’re an AWS Community Builder or cloud enthusiast, feel free to share your own architectural patterns or lessons learned in the comments.

User Management Automation With BASH SCRIPT

Temitope Olatunji — Fri, 05 Jul 2024 21:58:55 +0000

Introduction

Managing user accounts and groups on Linux systems can indeed be time-consuming, especially when dealing with multiple users. As a SysOps Engineer, you can simplify this process by creating a Bash script that automates user and group management. The script can read user and group information from a file, create users, assign them to groups, and set passwords. Let's explore the step-by-step process of achieving this automation. This task is courtesy of HNG, an internship program designed to enhance your programming knowledge across various domains. You can find more information about HNG on their website: HNG Internship. Now, let's dive into the details! 🚀🔍

Why automate?

Have you ever performed a long and complex task at the command line and thought, "Glad that's done. Now I never have to worry about it again!"? I have—frequently. I ultimately figured out that almost everything that I ever need to do on a computer will need to be done again sometime in the future.

Prerequisite

Basic knowledge of Linux command line
Text Editor

Script Code

#!/bin/bash
# automating user account creation

# Check if the script is run with the input file argument
if [ -z "$1" ]; then
  echo "Usage: sudo $0 <name-of-text-file>"
  exit 1
fi

# Input file (usernames and groups)
input_file="$1"

# Log file
log_file="/var/log/user_management.log"

# Secure password storage file
password_file="/var/secure/user_passwords.txt"

# Create secure directory
sudo mkdir -p /var/secure
sudo chmod 700 /var/secure
sudo touch "$password_file"
sudo chmod 600 "$password_file"

# Function to generate a random password
generate_password() {
    openssl rand -base64 12
}

# Read input file line by line
while IFS=';' read -r username groups; do
    # Skip empty lines or lines that don't have the proper format
    [[ -z "$username" || -z "$groups" ]] && continue

    # Create groups if they don't exist
    for group in $(echo "$groups" | tr ',' ' '); do
      sudo groupadd "$group" 2>/dev/null || echo "Group $group already exists"
    done

    # Create user if not exists
    if id "$username" &>/dev/null; then
        echo "User $username already exists"
        echo "$(date '+%Y-%m-%d %H:%M:%S') - User $username already exists" | sudo tee -a "$log_file" > /dev/null
    else
        sudo useradd -m -s /bin/bash -G "$groups" "$username" || { echo "Failed to add user $username"; continue; }

        # Set password for newly created user
        password=$(generate_password)
        echo "$username:$password" | sudo chpasswd || { echo "Failed to set password for $username"; continue; }

        # Log actions
        echo "$(date '+%Y-%m-%d %H:%M:%S') - Created user $username with groups: $groups" | sudo tee -a "$log_file" > /dev/null

        # Store password securely
        echo "$username:$password" | sudo tee -a "$password_file" > /dev/null
    fi
done < "$input_file"

echo "$(date '+%Y-%m-%d %H:%M:%S') - User management process completed." | sudo tee -a "$log_file" > /dev/null

Script Overview

The script performs the following tasks:

Creates two file, a log file to store logs and the other to store user's password.
Set right permission for both files.
Reads a list of users and groups from a file.
Creates users and assigns them to specified groups.
Generates random passwords for each newly created user.
Logs all actions to /var/log/user_management.log.
Stores the generated passwords securely in /var/secure/user_passwords.txt.

Key Features

Automated User and Group Creation:

The script automates the creation of users and their respective groups by reading from a file containing user and group information.
Personal groups are created for each user to ensure clear ownership and enhanced security.
Users can be assigned to multiple groups, facilitating organized and efficient permission management.

Secure Password Generation:

The script generates random passwords for each user, enhancing security.
Passwords are securely stored in a file with restricted access, ensuring that only authorized personnel can view them.

Logging and Documentation:

Actions performed by the script are logged to a file, providing an audit trail for accountability and troubleshooting.

Usage:

1 Input File: The script takes an input file containing the list and users and groups they are to be added. it is formatted as user;groups

Conclusion

Automating user and group management with a bash script is a very good way to streamline administrative tasks and ensure consistency across a system. In this module, we have demonstrated how to create a script that reads user and group information from a file, creates users, group and sets password while logging the entire process into a log file. This script can be modified and adapted into different environment and requirements making it a versatile tool for system administrators.
Here's a link to my script: here