DEV Community: saheed

Deploying Your First Server with Terraform: A Beginner's Guide

saheed — Tue, 17 Mar 2026 20:37:32 +0000

INTRODUCTION
Welcome to Day 3 of my 30-Day Terraform Challenge! In the "ancient" days of software, deploying a server was a manual, fragile process involving physical hardware and manual commands Today, we use Infrastructure as Code (IaC) to automate this entire process using a simple, declarative language if you are just starting out, this guide walks you through the exact steps I took to launch my first virtual server on AWS.

The Compute Resource: aws_instance

In the Terraform world, a virtual server is defined using the aws_instance resource. To get my server running, I had to provide two critical arguments:

AMI (Amazon Machine Image): This is the OS snapshot for the server. I used an Ubuntu 20.04 image

Instance Type: I chose t2.micro, which is perfect for learning because it falls under the AWS Free Tier

One important lesson I learned is that AMI IDs are region-specific
If I move my deployment from us-east-2 to us-west-2, I have to update that ID, or the deployment will fail

The first step in any Terraform project is to define your Provider, which tells Terraform which cloud platform you are using For this challenge, I am using AWS

provider 
"aws" {
  region = "us-east-2"
}

Note: I chose us-east-2 (Ohio), but remember that resources like AMI IDs are region-specific

By default, AWS is a "walled garden" that denies all incoming traffic
To see our web server in action, we must create an aws_security_group to open specific ports

Port 80 (HTTP): To allow users to view our website

Port 22 (SSH): To allow us to securely log into the server for maintenance

The Terraform Lifecycle in Action

With the code ready, I followed the standard Terraform workflow to bring the server to life

terraform init: This prepares the directory and downloads the AWS provider plugin

terraform plan: A "sanity check" dry run. My plan showed 2 resources to add (the instance and the security group)

terraform apply: This executes the changes. After typing yes, Terraform provisioned the server in about 40 seconds

terraform destroy: Once I was done testing, I ran this to cleanly remove all resources and avoid unnecessary AWS costs

CONCLUSION
The most important lesson today was understanding Terraform's declarative nature I don't tell AWS how to build a server; I just describe what I want the server to look like Terraform builds a dependency graph and handles the heavy lifting of figuring out the most efficient way to make it happen I am thrilled to continue this journey alongside the AWS AI/ML UserGroup Kenya, Meru HashiCorp User Group, and EveOps communities.

Step-by-Step Guide to Setting Up Terraform, AWS CLI, and Your AWS Environment

saheed — Tue, 17 Mar 2026 07:35:49 +0000

INTRODUCTION

Building a production-grade infrastructure starts with a rock-solid environment. Below is the exact walkthrough of how I configured my system, the commands I used, and the logic behind my decisions.

Preparing the AWS "House"
The first step is ensuring Terraform has the right permissions to act on your behalf. As noted in the sources, you should never use your root account for daily operations.

IAM User Creation: I navigated to the IAM Console and created a new user with Programmatic Access.

Permissions: I attached the AdministratorAccess Managed Policy
While broad, this is recommended for learning environments to ensure Terraform isn't blocked when trying to create complex networking resources like VPCs or NAT Gateways.

Security: I immediately saved my Access Key ID and Secret Access Key Once you leave that screen, AWS will never show the secret key again.

Installing the Tooling
Terraform Installation: Since I am working on a MacBook Air (Darwin arm64), I used Homebrew to install Terraform

brew tap hashicorp/tap
brew install hashicorp/tap/terraform

Verification: I ran a quick check to ensure everything was installed correctly.

My Version: Terraform v1.14.7 Provider: AWS Provider v6.36.0

Configuring the Environment

Terraform needs to know who is running the commands. I configured my credentials as environment variables to keep them out of my source code.
Decision: I chose to deploy in the us-east-1 region This is a standard choice as it is often the first to receive new AWS features

Executing the Terraform Lifecycle
With the environment ready, I implemented a foundational networking stack (VPC, subnets, and gateways). I followed the core workflow commands defined in the sources.

Step A: terraform init This initialized the backend and downloaded the AWS Provider v6.36.0 this step is idempotent, meaning I can run it safely multiple times if I add new providers later

Step B: terraform plan This is the "sanity check" My plan (seen in the screenshots) confirmed exactly what would happen: 18 resources to add, 0 to change, 0 to destroy. It detailed the creation of a VPC with a CIDR block of 10.0.0.0/16 and tags like demo_vpc

Step C: terraform apply This command executed the plan

Result: The terminal confirmed: "Apply complete! Resources: 18 added"

Step D: terraform destroy To avoid unnecessary costs from resources like the NAT Gateway and Elastic IP, I immediately tested the cleanup process. Terraform correctly identified all 18 resources and tore them down in the reverse order of their dependencies.

CONCLUSION

Terraform is incredibly efficient. It doesn't just build one thing at a time; it maps dependencies and builds everything it can simultaneously.

What is Infrastructure as Code and Why It's Transforming DevOps

saheed — Mon, 16 Mar 2026 21:01:03 +0000

INTRODUCTION

A long time ago, in a datacenter far, far away, an ancient group of beings known as “sysadmins” used to deploy infrastructure manually Every server, database, and network cable was managed by hand, a dark age of fear characterized by downtime, accidental misconfiguration, and slow, fragile deployments.

What is IaC and the Problem It Solves?
The core idea behind IaC is that you treat all aspects of operations as software Instead of clicking around a web console, you write and execute code to define, deploy, update, and destroy your infrastructure.

This solves several critical problems that plagued traditional manual provisioning:

Configuration Drift: Manual releases often lead to "snowflake servers," where every machine has a subtly different configuration from all the others, making bugs nearly impossible to reproduce

The Bus Factor: If your infrastructure exists only in one person's head, your business is at risk if they leave or go on vacation IaC acts as living documentation that anyone can read

Manual Error: Humans are prone to mistakes during repetitive tasks. IaC enables automation, making deployments significantly faster, safer, and more consistent

By defining infrastructure as code, we gain the ability to use software engineering best practices like version control, code reviews, and automated testing on our hardware setup.

Declarative vs. Imperative: The Shift in Thinking

One of the most important concepts to grasp is the difference between these two approaches:

Imperative (Procedural): Tools like Ansible or Chef encourage a style where you specify the step-by-step commands to achieve a state
The problem is that if you tell a procedural script to "add 5 servers" and run it twice, you might end up with 10 total servers when you only wanted 5, because the code doesn't fully capture the current state of the world

Declarative: Tools like Terraform focus on the desired end state
You simply declare, "I want 5 servers." Terraform handles the heavy lifting of figuring out what is currently deployed and makes the necessary API calls to match your request
If you update your code to 10 servers, Terraform realizes 5 already exist and only provisions the 5 new ones

This declarative nature ensures your code is always a 1:1 representation of reality, making it much easier to reason about and maintain over time.

Why Terraform is Worth Learning

Among the many IaC tools available, Terraform has emerged as a leader for several reasons:

Cloud Agnostic: It works with all popular cloud providers (AWS, Azure, GCP) and even platforms like Kubernetes, allowing you to manage your entire stack with a single language.

Simple Language: It uses HashiCorp Configuration Language (HCL), which is designed to be human-readable and much easier to learn than general-purpose programming languages like Java or Python.

Masterless and Agentless: You don't need to manage extra infrastructure or install software on your servers for Terraform to work; it communicates directly with cloud APIs via a single binary on your computer.

Explosive Community Growth: Terraform's community is massive and active, meaning there are thousands of reusable modules and plugins available to help you get started quickly.

Conclusion

Software isn't "done" when the code works on your laptop; it’s only done when it is delivered to the user. By adopting Terraform and IaC, you move away from the "fear and uncertainty" of manual configurations toward a world where infrastructure is stable, documented, and automated If you're ready to stop "shaving yaks" and start building production-grade systems, Terraform is the best place to start.

Stop risking security with long-lived keys. Upgrade your CLI, adopt aws login, and enjoy a cleaner, safer, and more efficient workflow the way AWS intended in 2025.

saheed — Sun, 30 Nov 2025 16:05:19 +0000

saheed

Nov 30 '25

AWS just changed how we log in to the CLI — By Saheed Ipaye

Comments

2 min read

AWS just changed how we log in to the CLI — By Saheed Ipaye

saheed — Sun, 30 Nov 2025 16:00:23 +0000

I just migrated away from long-term AWS access keys. Took me just 5 minutes.

The Old Way
For years, we've all been doing the same thing: generating IAM access keys, storing them in ~/.aws/credentials, and hoping nobody finds them. Every security audit flagged them. Every developer onboarding session involved that awkward "here's how to store secrets safely" talk.

Then AWS quietly released something that changes everything: aws login

My Migration Story

Step 1: Update AWS CLI
First, I checked my CLI version. Anything below v2.22 won't work:

aws --version

Step 2: Delete Those Permanent Keys
Then came the scary part deleting my credentials file. I opened

~/.aws/credentials, saw the familiar aws_access_key_id and aws_secret_access_key staring back at me, and just... deleted them:

rm ~/.aws/credentials

I kept my region and output format in the config you still need those.

Step 3: The Magic Moment
Now here's where it gets good. I typed:

aws login

My browser opened automatically. I signed in with my regular AWS console credentials the same email and password I use every day. No copying and pasting 40-character strings. No "wait, which key was for which account?" Within seconds, I was authenticated:


You are now logged in as arn:aws:iam::<account-id>:user/your-user
Credentials stored for profile 'default'

Step 4: Verify It Worked
Ran a quick test:

aws sts get-caller-identity

It worked. No access keys in sight. Just clean, secure, temporary tokens doing their job.

What Makes This Better?
The credentials it generates are temporary:

They expire in hours, not years, They auto-rotate every 15 minutes
They live in a secure cache, not a plain text file waiting to be accidentally committed to GitHub

You can check the expiration yourself

cat ~/.aws/cli/cache/*.json

You'll see something like:

{
  "Credentials": {
    "AccessKeyId": "...",
    "SecretAccessKey": "...",
    "SessionToken": "...",
    "Expiration": "2025-01-01T12:34:56Z"
  }
}

The Bottom Line

The entire migration took me 5 minutes. five minutes to eliminate one of the biggest security headaches in cloud development. If you're still using long-term access keys in 2025, this is your sign:

Update your CLI to v2.22+
Delete those credentials
Run aws login

Your security team will thank you. Your future self will thank you.
And honestly? It just feels better knowing those permanent keys aren't sitting there anymore.

Instead of deploying one NAT Gateway per Availability Zone, you can now deploy one NAT Gateway at the VPC level. Check this out to see how you can easily get it done.

saheed — Fri, 21 Nov 2025 07:52:39 +0000

AWS Just Changed NAT Gateway — Here’s What You Need to Know

saheed ・ Nov 21

#networking #news #architecture #aws

AWS Just Changed NAT Gateway — Here’s What You Need to Know

saheed — Fri, 21 Nov 2025 07:47:21 +0000

If you’ve worked with AWS for even a short time, you've probably crossed paths with the NAT Gateway the service that lets your private subnets access the internet without exposing them publicly. It’s reliable, managed, and simple… until you need to run workloads across multiple Availability Zones (AZs).

Suddenly you’re managing multiple NAT Gateways, multiple public subnets, multiple route tables and of course, multiple bills.

But AWS recently rolled out an update that changes the game: A new Regional NAT Gateway mode.

In this post, I’ll break down what changed, why it matters, and how you can start using it today.

What AWS Actually Changed

Traditionally, NAT Gateways were zonal. This meant you needed one NAT Gateway per AZ if you wanted high availability which led to higher cost and more complex architecture.

With the new update, AWS now allows you to create a single NAT Gateway at the VPC level, which:

Automatically scales across AZs as needed
Doesn’t require a public subnet in every AZ
Supports Elastic IPs (EIPs) or Bring-Your-Own-IP (BYOIP)
Automatically expands into an AZ when workloads appear there

You essentially get a central, smarter, self-adjusting NAT Gateway for your entire VPC.

Why This Update Is a Big Deal

1 Your Architecture Becomes Much Simpler

No more creating public subnets, NAT gateways, and route tables for every AZ. Your VPC diagram instantly gets cleaner.

2 Better High Availability (With Less Work)

The regional NAT Gateway expands into any AZ where you launch resources. No failover scripts. No manual setup. Just automatic coverage.

3 Better Security Posture

Since you don’t need public subnets in every AZ anymore, your VPC can lean more toward a “private-by-default” model.

4 Smarter IP Handling

AWS now automatically allocates additional IPs when connection limits are reached. It also integrates with IPAM, so large orgs can manage IP policies more cleanly.

5 Potential Cost Optimization

You’re not paying for multiple idle NAT Gateways, You pay only for the regional gateway hours in the AZs where traffic actually flows.

How to Use the Regional NAT Gateway

Here’s a simple AWS CLI example for creating one:

aws ec2 create-nat-gateway \
  --connectivity-type public \
  --subnet-id subnet-1234567890abcdef \
  --region-availability regional \
  --allocation-id eipalloc-0123456789abcdef

In Terraform:

resource "aws_nat_gateway" "regional" {
  connectivity_type    = "public"
  subnet_id            = var.public_subnet
  region_availability  = "regional"
  allocation_id        = aws_eip.nat.id
}

resource "aws_eip" "nat" {
  domain = "vpc"
}

Final Thoughts

This update feels like one of those subtle AWS changes that quietly unlock major improvements in how we design cloud networks. Instead of juggling multiple NAT Gateways, route tables, and subnets, you can now build cleaner, more resilient architectures with much less effort.

For teams that value scalability, security, and simplicity, this is a win.

If you haven’t tried the new Regional NAT Gateway yet, spin it up in a dev environment and watch how much simpler your VPC looks.

Author: SAHEED OLATUNDE IPAYE

How I Saved My Cloud Costs Before Spending a Dime - When I built a simple café website on AWS for practice, everything looked perfect until I asked myself a question no cloud engineer should ignore: “How much will this architecture cost me every month?”

saheed — Sun, 26 Oct 2025 14:39:33 +0000

saheed

Oct 26 '25

The Power of AWS Pricing Calculator - Your Secret Weapon for Cloud Cost Optimization

#tutorial #productivity #cloud #aws

Comments

5 min read

The Power of AWS Pricing Calculator - Your Secret Weapon for Cloud Cost Optimization

saheed — Sun, 26 Oct 2025 14:25:02 +0000

INTRODUCTION

Why Cloud Engineers Can't Afford to Ignore This Tool, Picture this: You've just deployed your application to AWS, feeling proud of your architecture. Then the first bill arrives, and your jaw drops. Sound familiar? You're not alone. Cloud cost surprises are one of the biggest challenges facing engineers today, but there's a powerful tool that most people aren't leveraging effectively: the AWS Pricing Calculator.

In this comprehensive guide, I'll walk you through a real-world scenario using the AWS Pricing Calculator to estimate costs and optimize spending. By the end, you'll understand why this tool should be your first stop before deploying any AWS infrastructure.

The Hidden Cost of "Figure It Out Later"

Many developers treat AWS pricing as an afterthought. They spin up resources, build their applications, and hope for the best. This approach can lead to:

Budget overruns that derail projects
Unexpected bills that catch stakeholders off-guard
Missed optimization opportunities that could save thousands
Difficult conversations with finance teams

The AWS Pricing Calculator eliminates these surprises by giving you accurate cost estimates before you commit a single dollar to infrastructure.

Real-World Scenario: Estimating Costs for a Café Website

Let's work through a practical example. Imagine you're running a café website on AWS and need to estimate your monthly costs. The current setup includes:

An EC2 instance running the web application
An RDS database for customer data
Storage for both the application and a decommissioned local database

We'll calculate the cost of this "before optimization" topology, which represents a common scenario where legacy components still occupy resources and cost money.

Our Infrastructure Components

Region: US East (N. Virginia) - or whichever region your resources run in

Amazon EC2 Instance:

Instance type: t3.small
Pricing model: On-Demand
Utilization: 100% per month (constant usage)
Operating system: Linux
Storage: 40 GB General Purpose SSD (gp2) - including 20 GB from a decommissioned database

Amazon RDS Instance:

Instance class: db.t3.micro
Database engine: MariaDB
Storage: 20 GB General Purpose SSD (gp2)
Deployment: Standard single-AZ

Step-by-Step: Building Your Cost Estimate

Let me walk you through the exact process of creating this estimate. Follow along, and you'll have a reusable framework for any future AWS projects.
**
Phase 1: Setting Up Your Estimate**

Step 1: Navigate to the AWS Pricing Calculator at https://calculator.aws and click Create estimate.

Step 2: Scroll through the service options until you find the Amazon EC2 service box, then click Configure.

Step 3: At the top of the page, select your region from the dropdown menu. For this example, we're using US East (N. Virginia). If prompted, confirm the region change by clicking Change Region.

Why this matters: AWS pricing varies significantly by region. Choosing the correct region ensures your estimate matches your actual costs.

Phase 2: Configuring Your EC2 Instance

Step 4: Select the Advanced estimate option for more detailed configuration control.

Step 5: In the EC2 instance specifications section, choose Linux as your operating system.

Step 6: Configure the workload settings:

Select Constant usage (since our café website runs 24/7)
Set Number of instances to 1

Step 7: In the EC2 instances search box, type and select t3.small as your instance type.

Pro tip: The t3.small is part of AWS's burstable performance instances, ideal for workloads with variable CPU usage. It provides a baseline performance with the ability to burst when needed.

Step 8: Under Pricing strategy, ensure On-Demand is selected. This gives you maximum flexibility without long-term commitments.

Step 9: Configure storage in the Amazon Elastic Block Storage (EBS) section:

Storage type: General Purpose SSD (gp2)
Storage amount: 40 GB
Snapshot Frequency: No snapshot storage

Key insight: Notice we're paying for 40 GB even though 20 GB is occupied by a decommissioned database. This is exactly the kind of waste the calculator helps you identify!

Step 10: Scroll down and click Add to my estimate.

Excellent! You've now calculated your EC2 costs. But we're not done yet.

Phase 3: Adding Your RDS Database

Step 11: On the My Estimate page, click Add service.

Step 12: Find and click Configure in the Amazon RDS for MariaDB service panel.

Step 13: Configure your RDS instance:

Region: Select the same region as your EC2 instance
MariaDB instance specifications: Standard (single-AZ)
Instance type: Search for and select db.t3.micro
Quantity: 1
Pricing model: On-Demand Instances
Storage volume: General Purpose SSD (gp2)
Storage amount: 20 GB per month

Important consideration: We're using single-AZ for this example, but production workloads should seriously consider Multi-AZ deployments for high availability. The calculator makes it easy to compare these costs.

Step 14: Click Add to my estimate.

Phase 4: Reviewing and Sharing Your Estimate

Congratulations! You now have a complete cost breakdown showing:

Individual service costs
Detailed configuration for each component
Total estimated monthly cost

Step 15: Click Save and share (agree to terms if prompted).

The Game-Changing Benefits of AWS Pricing Calculator

Now that you've seen the calculator in action, let's discuss why this tool is indispensable for every cloud engineer:

Eliminate Budget Surprises
No more anxiety when the monthly bill arrives. You know exactly what to expect, down to the dollar. This predictability lets you sleep better and build with confidence.
Data-Driven Optimization Decisions
Want to know if upgrading to a larger instance or switching to Reserved Instances saves money? Build two estimates and compare. The calculator turns "I think" into "I know."
Identify Waste Before It Costs You
In our example, we spotted 20 GB of storage from a decommissioned database. Without the calculator forcing you to itemize resources, would you have noticed? Probably not until you ran a cost audit months later.
Experiment Risk-Free
Wondering if a different architecture would be more cost-effective? Build estimates for multiple scenarios without spinning up a single resource. This is particularly valuable for proof-of-concept discussions.

CONCLUSION

The AWS Pricing Calculator isn't just a nice to have tool it's essential for responsible cloud engineering. In our café website example, we now have a clear baseline cost estimate. More importantly, we've identified an obvious optimization opportunity: that 20 GB of wasted storage.

Before you deploy your next AWS resource, take 15 minutes with the pricing calculator. Your future self (and your finance team) will thank you. The tool transforms cloud cost management from reactive firefighting into proactive planning.

Remember every dollar you save on AWS infrastructure is a dollar your organization can invest in innovation, better tools, or your next big idea.

Your Turn
Have you used the AWS Pricing Calculator before? What cost surprises have you encountered in your cloud journey? Share your experiences in the comments below—I'd love to hear your optimization stories!

Published by Saheed O. Ipaye.

[Boost]

saheed — Tue, 21 Oct 2025 20:14:05 +0000

From Zero to Cloud: Building a Serverless School Management System on AWS

saheed ・ Oct 21

#serverless #architecture #aws #tutorial

From Zero to Cloud: Building a Serverless School Management System on AWS

saheed — Tue, 21 Oct 2025 14:32:05 +0000

INTRODUCTION

When I started this project, my goal was simple to build something real on the cloud, I spent two weeks building a production ready web application with one simple goal to prove that you don't need expensive servers to ship real applications.

The result? A fully functional school management system that:

Scales from 1 to 1 million requests automatically
Costs less than $2/month to run
Handles real-world problems (CORS, data integrity, query optimization)

This isn't a "Hello World" serverless app. This is a real project with real challenges, real solutions, and real learnings let me show you exactly how I built it.

What We're Building

Before diving into code, here's what the final system does:

User Perspective:

View all school classes in a beautiful card-based interface
Click on a class to see all enrolled students
View detailed student information
Add new students with a form
Everything loads in under 200ms

Behind the Scenes:

Serverless backend with zero servers to manage
Auto-scaling to handle any traffic
NoSQL database optimized for the access patterns

Database Design : Create DynamoDB Tables
First, I went to AWS DynamoDB and created two tables

Why this structure?

ClassID as partition key for direct lookups
GSI on ClassID for querying students by class
Simple, flat structure (no complex joins)

Lambda Functions
I Created Four Lambda Functions
Each function handles one specific operation. I created them in Python 3.12 runtime.

Create REST API

Went to API Gateway console Created new REST API named SchoolManagementAPI

Created resources:

/classes
/classes/{classId}
/classes/{classId}/students
/students
/students/{studentId}

For each resource, created the appropriate HTTP method:

Critical Setting: Enable "Use Lambda Proxy integration" for each method.

Enable CORS

This is where I spent 2 hours debugging! For each resource:

Click "Actions" → "Enable CORS"

Set:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,POST,OPTIONS
Access-Control-Allow-Headers: Content-Type,X-Amz-Date,Authorization

Important: This creates an OPTIONS method automatically for preflight requests.

Deploy API

Click "Actions" → "Deploy API"
Select "[New Stage]"
Name it: dev
Copy the Invoke URL

curl https://school-management-app-saheed-ipaye.s3-website.eu-west-2.amazonaws.com/
/dev/classes

Frontend Deployment

Create S3 Bucket

Went to S3 console
Created bucket: school-management-app-saheed-ipaye
Disabled "Block all public access"

Upload Frontend

Saved React app as index.html
Uploaded to bucket root

Configure Static Website Hosting

Properties tab → Static website hosting
Enable it
Index document: index.html

Setup CloudFront

Create CloudFront distribution
Origin: Your S3 bucket
Redirect HTTP to HTTPS
Default root object: index.html
Deploy (takes 5-15 minutes)

Challenges I Faced

Challenge 1: CORS Errors
Problem: Frontend couldn't call API - "Access-Control-Allow-Origin missing"

Root Cause: CORS needed configuration at BOTH Lambda AND API Gateway

Solution:

Added headers in Lambda responses
Enabled CORS on all API Gateway resources
Created OPTIONS methods
Deployed changes

Challenge 2: Slow Database Queries
Problem: Students not showing up quickly

Root Cause: Using scan() instead of query() on DynamoDB

Solution:

Created Global Secondary Index (GSI) on ClassID
Changed from scan to query operation
Result: 500ms → 50ms (90% improvement!)

# Before (Slow)
response = table.scan(
    FilterExpression='ClassID = :classid',
    ExpressionAttributeValues={':classid': class_id}
)

# After (Fast)
response = table.query(
    IndexName='ClassID-index',
    KeyConditionExpression='ClassID = :classid',
    ExpressionAttributeValues={':classid': class_id}
)

Conclusion

Building this serverless application taught me that:

You don't need expensive infrastructure to ship real apps

✅ Cloud services require thinking differently about architecture
✅ The best learning happens when debugging production issues
✅ Documentation and clean code matter
✅ Shipping something imperfect beats perfecting in isolation

If you're thinking about serverless but haven't started yet Start today. Build something simple, break it, fix it, and learn.

The cloud is the future. Might as well get familiar with it now.

AUTHOR: SAHEED IPAYE

What's your biggest Docker pain point? Have you tried multi-stage builds? Drop your optimization tips below! 👇

saheed — Tue, 14 Oct 2025 15:39:38 +0000

saheed

Oct 14 '25

From 1.57GB to 189MB: How I Slashed My Docker Image Size by 88%

#devops #aws #docker #performance

Comments 3

3 min read