DEV Community: Renato Mendoza

One-Click Deployments #2: AWS EKS Fargate Cluster Using Terraform and Helm

Renato Mendoza — Wed, 24 Sep 2025 03:05:02 +0000

Welcome to my One-Click AWS EKS Deployment tutorial. This is a complete guide to deploying a production-ready EKS Fargate cluster.

In this post, you'll deploy a complete EKS Fargate infrastructure with sample application using a single Terraform command. No more spending hours setting up VPCs, EKS clusters, RBAC, load balancers, and applications separately. We use Terraform modules + Helm charts to provision everything from network infrastructure to a running nginx website with load balancer automatically.

What You Get

A single terraform apply command creates:

🌐 Complete networking infrastructure across 2 availability zones
- VPC with public/private subnets
- Internet Gateway, NAT Gateway with EIP (cost-optimized single NAT)
- Security groups with least-privilege access
🚀 Production-ready EKS Fargate cluster
- Managed control plane with Fargate-only execution (no EC2 management)
- AWS Load Balancer Controller for native ALB/NLB integration
- Comprehensive RBAC with IAM Groups (devops, developers, viewers)
- CloudWatch logging and monitoring ready
📦 Nginx sample application deployed automatically
- Custom HTML content and health check endpoints
- Kubernetes deployment, service, and ingress resources
- Application Load Balancer with optional custom domain/SSL
🔧 Multi-environment support for dev, staging, and production configurations

Why This Matters

Building a production-ready EKS cluster from scratch is complex and time-consuming. You need to understand AWS networking, EKS configuration, Kubernetes RBAC, load balancing, security best practices, and how all these components work together.

Most tutorials only show you isolated pieces - how to create a VPC, or how to set up EKS, or how to deploy an app. But getting everything to work together securely and reliably? That's where the real challenge lies.

This solution eliminates the complexity by providing:

✅ Proven architecture that follows AWS best practices
✅ Complete automation - no manual steps or configuration gaps
✅ Production-ready security with proper RBAC and network isolation
✅ Working example you can immediately extend with your own applications

Instead of spending weeks learning and debugging, you get a solid foundation in minutes.

Repository Structure

one-click-aws-eks/
├── infra/
│   └── envs/              # Root module with environment configs
│       ├── dev/           # Development environment settings
│       ├── staging/       # Staging environment settings
│       └── prod/          # Production environment settings
├── modules/
│   ├── network/           # VPC, subnets, NAT gateway, security groups
│   ├── eks/              # EKS cluster, Fargate profiles, RBAC, Load Balancer Controller
│   └── applications/     # Helm charts for nginx sample application
└── scripts/              # Cleanup and utility scripts

Architecture Overview

┌─────────────────────────────────────────────────────────────────────────────────┐
│                                    AWS VPC                                      │
│                                 (10.0.0.0/16)                                  │
│                                                                                 │
│  ┌─────────────────────┐                      ┌─────────────────────┐         │
│  │   Public Tier       │                      │   Public Tier       │         │
│  │  (us-east-1a)       │                      │  (us-east-1b)       │         │
│  │ ┌─────────────────┐ │                      │ ┌─────────────────┐ │         │
│  │ │ Public Subnet   │ │  ┌─────────────────┐ │ │ Public Subnet   │ │         │
│  │ │ 10.0.0.0/20     │◄┼──┤ Internet Gateway ├─┤ 10.0.16.0/20    │ │         │
│  │ └─────────────────┘ │  └─────────────────┘ │ └─────────────────┘ │         │
│  │         │           │                      │                     │         │
│  │    ┌────▼────┐      │                      │                     │         │
│  │    │ ALB     │      │                      │                     │         │
│  │    │(nginx)  │      │                      │                     │         │
│  │    └─────────┘      │                      │                     │         │
│  └─────────────────────┘                      └─────────────────────┘         │
│              │                                                                 │
│  ┌───────────▼─────────┐                               ┌─────────────────────┐ │
│  │   Private App Tier  │                               │   Private App Tier  │ │
│  │    (us-east-1a)     │                               │    (us-east-1b)     │ │
│  │ ┌─────────────────┐ │     ┌─────────────────────┐   │ ┌─────────────────┐ │ │
│  │ │ Private Subnet  │ │     │                     │   │ │ Private Subnet  │ │ │
│  │ │ 10.0.32.0/20    │ │     │      EKS Cluster    │   │ │ 10.0.48.0/20    │ │ │
│  │ └─────────────────┘ │     │   (Control Plane)   │   │ └─────────────────┘ │ │
│  │                     │     │                     │   │                     │ │
│  │ ┌─────────────────┐ │     │   ┌─────────────┐   │   │ ┌─────────────────┐ │ │
│  │ │   EKS Fargate   │◄┼─────┼───┤ API Server  │   │   │ │   EKS Fargate   │ │ │
│  │ │     Pods        │ │     │   └─────────────┘   │   │ │     Pods        │ │ │
│  │ │                 │ │     └─────────────────────┘   │ │                 │ │ │
│  │ │ • nginx-sample  │ │                               │ │ • apps namespace│ │ │
│  │ │ • custom HTML   │ │                               │ │ • ready for     │ │ │
│  │ │ • /health       │ │                               │ │   more apps     │ │ │
│  │ └─────────────────┘ │                               │ └─────────────────┘ │ │
│  └─────────────────────┘                               └─────────────────────┘ │
│                                                                                 │
│  ┌─────────────────────┐                               ┌─────────────────────┐ │
│  │   Private DB Tier   │                               │   Private DB Tier   │ │
│  │    (us-east-1a)     │                               │    (us-east-1b)     │ │
│  │ ┌─────────────────┐ │                               │ ┌─────────────────┐ │ │
│  │ │ Private Subnet  │ │        (Ready for RDS,        │ │ Private Subnet  │ │ │
│  │ │ 10.0.64.0/20    │ │         ElastiCache)         │ │ 10.0.80.0/20    │ │ │
│  │ └─────────────────┘ │                               │ └─────────────────┘ │ │
│  └─────────────────────┘                               └─────────────────────┘ │
└─────────────────────────────────────────────────────────────────────────────────┘

Prerequisites

Required setup:

AWS account with EKS permissions
Terraform installed locally
kubectl installed locally (for post-deployment testing)
AWS CLI configured with appropriate credentials
Terraform backend with S3 + DynamoDB (optional but recommended)

Manual Deployment

1. Clone and setup

git clone https://github.com/rnato35/one-click-aws-eks.git
cd one-click-aws-eks

2. Configure your environment

# Edit development configuration
# Modify infra/envs/dev/terraform.tfvars with your settings:

# Basic settings
region      = "us-east-1"  # Your preferred AWS region
aws_profile = "your-aws-profile"  # AWS CLI profile to use

# Optional: For public load balancer with custom domain
nginx_sample_domain_name     = "demo.yourdomain.com"  # Your domain
nginx_sample_certificate_arn = "arn:aws:acm:us-east-1:ACCOUNT:certificate/YOUR-CERT-ID"  # ACM certificate

# Or leave these unset for local port-forwarding access

3. Deploy with Terraform

# Navigate to infrastructure directory
cd infra/envs

# Initialize Terraform (with optional remote backend)
terraform init
# terraform init -backend-config="bucket=YOUR_BUCKET" -backend-config="key=eks-dev/terraform.tfstate" -backend-config="region=us-east-1"

# Deploy everything with one command!
terraform apply -var-file="dev/terraform.tfvars"

What happens during deployment (5-15 minutes):

Infrastructure phase (3-8 min): VPC, subnets, EKS cluster, RBAC, Load Balancer Controller
Applications phase (4-8 min): nginx sample app with Kubernetes resources and ingress
Verification: Health checks and load balancer readiness

All in one Terraform configuration - No need to manage separate infrastructure and application deployments!

What Gets Deployed in Detail

🌐 Networking Infrastructure

VPC: 10.0.0.0/16 with DNS support across 2 availability zones
Public subnets: For load balancers (10.0.0.0/20, 10.0.16.0/20)
Private subnets: For EKS Fargate workloads (10.0.32.0/20, 10.0.48.0/20)
Single NAT Gateway: Cost-optimized outbound internet access (~50% cost reduction)
Security Groups: Least-privilege firewall rules for EKS and load balancers
Route Tables: Proper routing for public/private subnet traffic

🚀 EKS Cluster Components

Managed control plane: High availability, managed by AWS across multiple AZs
Fargate profiles: Serverless container execution for default, kube-system, and apps namespaces
OIDC provider: For secure Kubernetes service account authentication
EKS add-ons: VPC CNI, CoreDNS, kube-proxy (auto-managed versions)
AWS Load Balancer Controller: Native integration with ALB/NLB via Helm deployment
CloudWatch logging: API server and audit logs with configurable retention

🔒 Security & RBAC

Comprehensive IAM Groups-based access control:
- 🔴 eks-devops: Full cluster administration access (platform team)
- 🟡 eks-developers: Namespace-scoped access with read/write in apps, read-only elsewhere
- 🟢 eks-viewers: Read-only cluster access for monitoring and troubleshooting
Assumable IAM roles: Team members assume roles based on group membership
Service accounts: Secure pod-level AWS permissions using OIDC
Network isolation: Private subnets with no direct internet access
Encryption: EKS secrets encryption and secure communication

📦 Sample Nginx Application (Automatically Deployed)

Custom HTML content: Professional landing page with architecture information
Health endpoint: /health for application monitoring and load balancer health checks
Production-ready Kubernetes resources:
- Deployment with configurable replicas and resource limits
- Service for internal load balancing
- Ingress for external access with SSL termination
- ConfigMaps for HTML content and nginx configuration
Load balancer options: Public ALB with custom domain/SSL OR local port-forwarding

Post-Deployment: Access Your Website & Cluster

1. Set up cluster access (for admins)

Add your IAM user to the appropriate IAM Group, then:

# Assume the cluster admin role
aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT:role/one-click-dev-eks-cluster-admins \
  --role-session-name admin-session

# Export the temporary credentials, then configure kubectl
aws eks update-kubeconfig --name one-click-dev-eks --region us-east-1

# Verify cluster access
kubectl get nodes
kubectl get namespaces
kubectl get pods -n apps

2. Access your website

There are two options to visualize the nginx sample application:

Option 1: Public ALB with Custom Domain (Production-ready)

Configure a certificate and put its ARN in the nginx_sample_certificate_arn variable
Set your custom domain in the nginx_sample_domain_name variable
Access via your custom domain over HTTPS

Option 2: Local Port Forwarding (Development/Testing)

Don't define the certificate and domain variables
Use kubectl port forwarding to access the service locally:

# Forward local port to the nginx service
kubectl port-forward -n apps service/nginx-sample 8080:80

# Visit your website locally
curl http://localhost:8080/architecture
curl http://localhost:8080/health

For Option 1 (Public ALB):

# Get the load balancer URL
kubectl get ingress -n apps

# Visit your website
curl http://<your-alb-dns-name>/architecture

# Test health endpoint
curl http://<your-alb-dns-name>/health

3. Test RBAC with different roles

# For developers (namespace-scoped access)
aws sts assume-role \
  --role-arn arn:aws:iam::ACCOUNT:role/one-click-dev-eks-developers \
  --role-session-name dev-session

# Test permissions
kubectl get pods -n apps              # ✅ Allowed  
kubectl get nodes                     # ✅ Allowed (read-only)
kubectl delete namespace kube-system  # ❌ Forbidden

Deployment Process Explained

Unified Deployment Process

This project uses a single Terraform configuration that handles everything:

Infrastructure deployment
- VPC, subnets, EKS cluster, load balancer controller
- All networking components and security groups
Applications deployment
- nginx sample app and all Kubernetes resources
- Deployed automatically after infrastructure is ready

Environment Management

Terraform workspaces: Isolate state for different environments
Separate tfvars files: Environment-specific configurations
Sequential deployment: Infrastructure first, then applications automatically

Environment Isolation

Each environment uses:

Separate tfvars files (dev/, staging/, prod/)
Different cluster names and configurations
Isolated AWS resources and namespaces
Terraform workspace isolation

IAM Groups Integration

Automatic creation: IAM Groups are created for each cluster
User management: Add IAM users to groups for appropriate access
Role assumption: Users assume roles based on group membership
MFA support: Optional MFA requirements for role assumption

Advanced Features

Cost Optimization

Fargate pricing: Pay-per-pod, no idle EC2 instances
Resource limits: Prevent resource waste in containers

Production Readiness

Multi-AZ deployment: High availability by default
Health checks: Application-aware load balancer probes
Auto scaling: Horizontal Pod Autoscaler ready
Monitoring: CloudWatch integration ready for extension

Extensibility

Modular design: Add applications via additional Helm charts
RBAC foundation: Easy to add users to IAM Groups

🚀 Call to Action

Deploy your own production-ready EKS Fargate cluster with one command:

🔗 GitHub Repository: one-click-aws-eks

This Terraform solution gives you:

✅ Complete EKS infrastructure in 10-15 minutes
✅ Working nginx application with load balancer
✅ Comprehensive RBAC ready for your team
✅ Multi-environment support (dev/staging/prod)

Perfect starting point for your next Kubernetes project on AWS!

Found this helpful? ⭐ Star the repository and let me know what you'd like to see deployed with one click next!

Building Production-Ready AWS Three-Tier Architecture with Terraform and GitOps

Renato Mendoza — Sun, 21 Sep 2025 20:19:43 +0000

Modern web applications demand scalable, secure, and maintainable infrastructure. This project demonstrates how to deploy a complete three-tier architecture on AWS using Terraform with professional CI/CD workflows.

What You'll Build

A production-ready architecture featuring:

Web Tier: Application Load Balancer with SSL termination and Auto Scaling Groups
Application Tier: EC2 instances running PHP web application in private subnets
Database Tier: RDS MySQL with Multi-AZ support and encrypted storage

Key Features

🔒 Security First

Private subnets for application and database tiers
AWS Secrets Manager integration for database credentials
OIDC authentication (no long-term AWS keys)
Security groups with least-privilege access

🚀 GitOps Workflow

Environment-specific branches (env/dev, env/staging, env/prod)
Automated Terraform validation and planning on PRs
Manual approval gates for production deployments
Safe destroy workflows with confirmation requirements

📊 Infrastructure as Code

Modular Terraform design for reusability
Remote state management with S3 and DynamoDB
Environment-specific configurations
Comprehensive output values

Project Structure

aws-three-tier-terraform-cicd/
├── .github/workflows/
│   └── terraform.yaml         # CI/CD pipeline
├── docs/
│   └── MANUAL_WORKFLOWS.md    # Manual workflow documentation
├── infra/envs/
│   ├── dev/                   # Development environment config
│   │   └── terraform.tfvars   # Dev-specific variables
│   ├── staging/               # Staging environment config
│   │   └── terraform.tfvars   # Staging-specific variables
│   ├── prod/                  # Production environment config
│   │   └── terraform.tfvars   # Production-specific variables
│   ├── main.tf                # Main infrastructure configuration
│   ├── variables.tf           # Input variables
│   ├── locals.tf              # Local values
│   └── versions.tf            # Terraform and provider versions
├── modules/
│   ├── application/           # Application tier module
│   │   ├── main.tf            # Application module implementation
│   │   ├── variables.tf       # Application module variables
│   │   └── outputs.tf         # Application module outputs
│   └── network/               # Network tier module
│       ├── main.tf            # Network module implementation
│       ├── variables.tf       # Network module variables
│       └── outputs.tf         # Network module outputs
└── scripts/                   # Helper scripts

Quick Start

Fork the repository and configure GitHub secrets:

   DB_PASSWORD          # Database password
   AWS_ROLE_ARN         # OIDC role ARN

For detailed instructions on setting up OIDC authentication and configuring the Terraform backend, see: one-click-aws-terraform-backend-gitops-oidc

Set GitHub variables:

   AWS_REGION           # Target AWS region
   TF_BACKEND_*         # Terraform backend config

Configure environment by copying terraform.tfvars.example:

   region = "us-west-2"
   env_name = "dev"
   certificate_arn = "arn:aws:acm:..."
   domain_name = "yourdomain.com"

Deploy using GitOps:
- Create PR to environment branches → Terraform format check, validation, and plan
- Merge to env/dev → Deploy to development
- Merge to env/staging → Deploy to staging
- Merge to env/prod → Deploy to production (with manual approval)

CI/CD Pipeline Highlights

The GitHub Actions workflow provides:

Automated Planning: Terraform plans run on every PR with results commented
Environment Isolation: Separate workspaces for dev/staging/prod
Security Gates: Manual approval required for production changes
Safe Destruction: Multi-step confirmation for infrastructure teardown

Database Security

Credentials are handled through multiple security layers:

GitHub Secrets store the master password
AWS Secrets Manager receives the password via CI/CD
IAM Roles allow EC2 instances to retrieve credentials
No Hardcoding - passwords never appear in code or state

Production Considerations

Configure DNS manually (project doesn't create Route53 records)
Enable VPC Flow Logs for network monitoring
Use remote state backend for team collaboration

Why This Approach Works

This architecture pattern provides:

Scalability: Auto Scaling Groups handle traffic spikes
Security: Multi-layered security with private networking
Reliability: Multi-AZ deployment with load balancing
Maintainability: Modular Terraform with GitOps workflows
Cost Efficiency: Environment-specific scaling configurations

Ready to deploy enterprise-grade infrastructure? Check out the full repository for complete implementation details.

One-Click Deployments #1: Bootstrap a GitOps-Ready AWS Terraform Backend with GitHub Actions (OIDC)

Renato Mendoza — Tue, 12 Aug 2025 18:23:52 +0000

Welcome to the first post in my One-Click Deployments series. In this series, we build infrastructure with as little manual setup as possible.

In this post, you will bootstrap a secure AWS Terraform backend in one command. No more storing AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in GitHub secrets. We use GitHub Actions + OpenID Connect (OIDC) to assume an AWS IAM role at runtime, avoiding long-lived credentials entirely.

What You Get

A single terraform apply in infra/bootstrap creates:

S3 bucket for Terraform state
- Versioning enabled, SSE-KMS with a customer-managed key, bucket key enabled
- Public access blocked, TLS-only bucket policy
- Lifecycle to expire noncurrent versions after 365 days
DynamoDB table for state locking on-demand
KMS key with rotation enabled, alias created
GitHub OIDC provider in AWS
IAM role for GitHub Actions with least-privilege backend access
backend.generated.hcl written for you

Why This Matters

Setting up a secure Terraform backend is usually tedious:

Create and secure an S3 bucket
Add DynamoDB for state locking
Provision and wire a KMS key
Write and distribute backend config
Create an IAM role with correct trust
Configure OIDC

This template does it in one go and wires your GitOps workflow on branches env/dev, env/staging, env/prod.

Repository Structure

one-click-aws-terraform-backend-gitops-oidc/
├── infra/
│   ├── bootstrap/      # Creates S3, DynamoDB, KMS, OIDC, IAM role
│   └── envs/           # Root stack using the generated backend
└── .github/
    └── workflows/
        └── terraform.yaml  # GitOps workflow

Prerequisites

AWS account and credentials locally with permissions for IAM, S3, DynamoDB, and KMS
AWS CLI configured
Terraform 1.6 or newer
A GitHub repo with environments: dev, staging, prod

Quick Start

Clone the repository

git clone https://github.com/rnato35/one-click-aws-terraform-backend-gitops-oidc.git

Initialize and apply Terraform

cd ./one-click-aws-terraform-backend-gitops-oidc/infra/bootstrap && terraform init
terraform apply -var 'github_org=<your-gh-org-or-user>' -var 'github_repo=<your-github-repo>'

Notes:

The current trust policy matches repo:<org>/<repo>:* by default.
Branch filtering is enforced by GitHub Environments and branch protections.

Copy outputs to GitHub variables and secrets

Repository variables:

TF_BACKEND_BUCKET=<bucket_name>
TF_BACKEND_REGION=<region>
TF_BACKEND_DDB_TABLE=<dynamodb_table_name>
TF_BACKEND_KMS_KEY_ID=<kms_key_arn>

Environment secrets (dev, staging, prod):

AWS_ROLE_ARN=<github_role_arn_from_outputs>

GitOps Flow Explained

Branch Mapping

env/dev → GitHub environment dev
env/staging → GitHub environment staging
env/prod → GitHub environment prod

Pull requests targeting env/*:

Run plan only
Selects workspace based on PR base branch
Uses per-env tfvars (dev, staging, prod)
Posts plan in logs

Pushes to env/*:

Run apply
Selects workspace and env tfvars automatically
Production (env/prod) requires a manual approval step before apply
- Approvers can be changed in:
```
.github/workflows/terraform.yaml
```

Credentials

Uses OIDC to assume AWS_ROLE_ARN from the target GitHub environment

Backend Wiring

terraform init receives -backend-config values from repository variables TF_BACKEND_*
The same remote state is used locally via backend.generated.hcl

Recommended Guardrails

Protect env/staging and env/prod branches
Require reviewers in GitHub Environments staging and prod
Scope the IAM role to least privilege only the resources your infra needs

What the Bootstrap Creates in Detail

KMS Key

enable_key_rotation = true
7-day deletion window
Alias: alias/<name_prefix>-tfstate

S3 Bucket for State

Versioning on
SSE-KMS using the CMK, bucket key enabled
Public access block on
TLS-only bucket policy
Lifecycle to expire noncurrent versions after 365 days

DynamoDB Table for Locks

PAY_PER_REQUEST

backend.generated.hcl Content

bucket, key = global/terraform.tfstate, region, encrypt, kms_key_id, dynamodb_table, acl = private, workspace_key_prefix = envs

GitHub OIDC Provider and IAM Role

Trust: repo:<org>/<repo>:* with aud = sts.amazonaws.com
Inline policy for backend access: S3 objects + List, DynamoDB lock item CRUD, KMS use for state
Managed policy attachments via github_oidc_managed_policy_arns
Inline policies loaded from Policy/*.json

Important default: All JSON policies found in infra/bootstrap/Policy are attached as inline policies. The repository includes a couple of example policies you can adapt to your needs:

Policy/TerraformAdminNoBilling.json
Policy/TerraformBillingAccess.json

Review and remove or replace these files to meet your least-privilege needs before applying in production.

Call to Action

Try the repo and deploy your backend in one click:

GitHub Repository