Forem: Eryan Fauzan

Fix ERR_TOO_MANY_REDIRECTS: WordPress di Belakang AWS ALB

Eryan Fauzan — Tue, 14 Apr 2026 03:03:19 +0000

Kalau kamu migrasi WordPress yang tadinya pakai Nginx sebagai SSL terminator ke setup dengan AWS Application Load Balancer (ALB) di depannya, ada satu masalah klasik yang hampir pasti muncul: ERR_TOO_MANY_REDIRECTS.

Artikel ini dokumentasi troubleshooting langsung dari production, mulai dari health check gagal, redirect loop, sampai fix di level Nginx dan WordPress.

Arsitektur Sebelum dan Sesudah

Sebelumnya:

Client → HTTPS → Nginx (SSL termination) → WordPress HTTP

Sesudah pakai ALB:

Client → HTTPS → ALB (SSL termination) → HTTP 80 → Nginx → WordPress

Di setup baru, ALB yang handle SSL. Nginx dan WordPress tidak perlu tahu soal SSL, mereka cukup terima traffic HTTP biasa dari ALB.

Masalah 1: Health Check Gagal dengan Kode 301

Setelah EC2 didaftarkan ke target group ALB, health check langsung Unhealthy dengan pesan:

Health checks failed with these codes: [301]

Kenapa Terjadi?

ALB secara default expect response 200 dari health check path. Tapi WordPress melakukan redirect (301), misalnya ke /en/ atau ke HTTPS, sehingga dianggap gagal.

Solusinya

Pergi ke EC2 > Target Groups > Health checks, lalu edit:

Health check path : /
Success codes     : 200,301

Atau ganti path ke endpoint yang langsung return 200. Tidak perlu menyentuh WordPress sama sekali.

Masalah 2: ERR_TOO_MANY_REDIRECTS

Setelah domain di-point ke ALB, browser langsung menampilkan ERR_TOO_MANY_REDIRECTS. Ini terjadi karena redirect loop:

ALB kirim HTTP ke Nginx
→ Nginx redirect ke HTTPS
→ ALB nerima HTTPS, forward lagi ke Nginx sebagai HTTP
→ Loop tidak berhenti

Fix Bagian 1: Bersihkan Config Nginx

Cek di mana redirect HTTPS berada:

sudo grep -rn "return 301" /etc/nginx/

Output:

/etc/nginx/sites-available/wordpress:5:    return 301 https://$host$request_uri;

Karena ALB sudah handle SSL termination, Nginx tidak perlu lagi melakukan redirect HTTPS. Backup dulu, lalu edit config-nya:

sudo cp /etc/nginx/sites-available/wordpress /etc/nginx/sites-available/wordpress.bak
sudo nano /etc/nginx/sites-available/wordpress

Ganti seluruh isi config dengan versi yang hanya listen di port 80 tanpa redirect:

server {
    listen 80;
    server_name example.com www.example.com;

    client_max_body_size 50M;
    root /var/www/html/wordpress;
    index index.php index.html index.htm;

    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param HTTPS on;
        include fastcgi_params;
    }
}

Poin penting:

Hapus server block port 443 karena SSL sekarang di ALB
Hapus return 301 https://... karena ini biang kerok redirect loop
Tambah fastcgi_param HTTPS on biar PHP/WordPress tahu request-nya HTTPS

Test dan reload:

sudo nginx -t
sudo systemctl reload nginx

Fix Bagian 2: wp-config.php

Setelah Nginx beres, masih bisa terjadi redirect loop dari sisi WordPress sendiri. Ini karena WordPress melihat request datang via HTTP (dari ALB ke Nginx), tapi WordPress dikonfigurasi untuk berjalan di HTTPS.

WordPress butuh dikasih tahu bahwa request originalnya adalah HTTPS melalui header X-Forwarded-Proto yang dikirim ALB.

Buka wp-config.php:

sudo nano /var/www/html/wordpress/wp-config.php

Tambahkan snippet ini sebelum baris require_once ABSPATH . 'wp-settings.php';:

/* Fix HTTPS detection behind ALB/reverse proxy */
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
    $_SERVER['HTTPS'] = 'on';
}

Setelah save, refresh browser dan redirect loop selesai.

Kenapa Dua Fix Diperlukan?

Layer	Masalah	Fix
Nginx	Redirect HTTP ke HTTPS meski ALB sudah handle SSL	Hapus `return 301`, listen HTTP only
WordPress	Tidak tahu request original adalah HTTPS	Set `$_SERVER['HTTPS']` dari header `X-Forwarded-Proto`

Keduanya saling terkait. Nginx fix menghentikan redirect di level server, tapi WordPress masih bisa generate URL HTTP dan redirect sendiri kalau tidak tahu konteks HTTPS-nya.

Lessons Learned

Masalah ini sebenarnya bisa dicegah jauh lebih cepat kalau dari awal sudah tahu detail setup server yang dipasang vendor.

Dalam kasus ini, vendor sebelumnya menginstall Nginx sebagai SSL terminator langsung di EC2. Tidak ada dokumentasi yang diserahkan, tidak ada catatan soal config apa yang aktif. Ketika infrastruktur berubah (masuk ALB), asumsinya server tinggal disambungkan. Ternyata ada konfigurasi lama yang konflik.

Beberapa hal yang sebaiknya didokumentasikan atau ditanyakan ke vendor sebelum migrasi:

Soal web server:

Nginx atau Apache? Versi berapa?
Ada berapa config file aktif di sites-enabled?
Apakah ada redirect HTTPS di level Nginx?
SSL terminate di mana, Nginx langsung atau ada layer lain?

Soal WordPress:

Ada custom snippet di wp-config.php selain yang default?
siteurl dan home di database point ke HTTP atau HTTPS?
Ada plugin caching atau security yang bisa interfere dengan redirect?

Soal server secara umum:

Service apa saja yang berjalan (systemctl list-units --type=service)?
PHP versi berapa, dan pakai FPM socket atau TCP?

Minta handover document atau minimal akses SSH sebelum mulai integrasi. Troubleshooting config orang lain tanpa dokumentasi itu bisa makan waktu jauh lebih lama dari yang seharusnya.

Catatan Tambahan

Kalau ada dua config file untuk domain yang sama (misalnya mysite dan mysite-old.conf), cek symlink di /etc/nginx/sites-enabled/ dan pastikan hanya satu yang aktif
Header X-Forwarded-Proto dikirim otomatis oleh ALB, tidak perlu konfigurasi tambahan di sisi ALB
Setelah semua beres, update juga ALB Listener Rules agar traffic untuk domain tersebut di-forward ke target group yang benar

Tested on: Ubuntu 22.04, Nginx 1.24, WordPress 6.x, AWS ALB

ALB Deep Dive: HTTPS, Host Header Routing, dan CNAME tanpa Route53

Eryan Fauzan — Fri, 10 Apr 2026 09:40:39 +0000

Kalau lo udah ngikutin artikel pertama, sekarang servicenya udah jalan di belakang ALB. Tapi setupnya masih basic masih HTTP dan baru satu service.

Di artikel ini gua bahas setup ALB yang lebih nyata dari pengalaman di production:

HTTPS dengan SSL (Wildcard) yang dibeli sendiri, bukan dari ACM gratis
Satu ALB untuk banyak service sekaligus
Routing berdasarkan subdomain via host header
CNAME di DNS provider lo

Kenapa Satu ALB untuk Banyak Service?

ALB itu billingnya per jam, bukan per service. Jadi kalau lo punya 5 service dan masing-masing pake ALB sendiri, lo bayar bakal mahal banget itu wkwk.

Pake satu ALB, lo bisa handle banyak service sekaligus lewat listener rules. app1.domain.com ke service A, app2.domain.com ke service B, semua lewat satu ALB yang sama.

Ini yang gua pake di production dan ini yang paling worth buat setup dari awal.

Step 1: Beli SSL dan Import ke ACM

Kebanyakan artikel yang ada pake SSL gratis dari ACM langsung. Tapi kalau lo beli domain di IDCloudhost, NiagaHoster, RumahWeb atau provider lokal lain dan mau pake SSL yang lo beli sendiri, caranya beda.

Format yang Dibutuhin ACM

Waktu import SSL ke ACM, lo butuh tiga hal:

Certificate body: file .crt atau .pem dari SSL lo
Private key: file .key yang lo generate waktu request SSL
Certificate chain: file intermediate/bundle dari provider SSL lo

Kalau lo beli SSL di third party, biasanya lo dapat file zip yang isinya ketiga file itu. Ada yang harus diminta lewat open ticket ada yang biasanya udah include langsung di service SSL, pokoknya tergantung dari third party lo. Pastiin lo nyimpen private keynya waktu generate CSR karena ACM bakal minta itu waktu import.

Cara Import ke ACM

Masuk ke AWS Console > Certificate Manager > Import certificate:

Paste isi file certificate body ke kolom Certificate body
Paste isi private key ke kolom Certificate private key
Paste isi certificate chain ke kolom Certificate chain
Klik Next, kasih tag kalau mau, lalu Import

Setelah berhasil, status certificate lo bakal Issued. Kalau statusnya Pending validation, itu berarti lo pake request ACM bukan import, pastiin lo pilih yang import.

Catatan: Private key itu sensitif. Jangan pernah commit ke repository atau share ke siapapun.

Step 2: Buat Target Group per Service

Sebelum setup ALB, lo harus siapin target group dulu untuk setiap service yang mau lo expose.

Masuk ke EC2 > Target Groups > Create target group:

Target type: IP (wajib untuk ECS Fargate karena networkMode awsvpc)
Protocol: HTTP
Port: sesuaikan dengan port container lo, misalnya 3000 untuk service A, 8000 untuk service B
VPC: pilih VPC yang sama dengan ECS service lo
Health check protocol: HTTP
Health check path: endpoint health check lo, misalnya /api/v1/health

Ulangi untuk setiap service yang mau lo attach ke ALB.

Soal Health Check Path

Ini yang sering bikin orang nyangkut. Health check path harus return status 200. Kalau lo belum punya endpoint health check di NestJS lo, bikin dulu yang simpel:

@Get('health')
health() {
  return { status: 'ok' };
}

Kalau health check gagal, ALB bakal terus drain dan replace task lo sampe circuit breaker dari ECS eksekusi biasanya sampe 3x cuma ini makan waktu sampe 20 menitan.

Step 3: Buat ALB dan Setup Listener 443

Buat ALB

Masuk ke EC2 > Load Balancers > Create > Application Load Balancer:

Name: kasih nama yang deskriptif
Scheme: Internet-facing
IP address type: IPv4
VPC: pilih VPC yang sama dengan ECS lo
Subnets: pilih minimal 2 public subnet di AZ yang berbeda, ini wajib
Security group: buat security group baru yang allow inbound port 443 dari 0.0.0.0/0

Buat Listener 443

Di bagian Listeners waktu buat ALB:

Protocol: HTTPS
Port: 443
Default SSL/TLS certificate: pilih certificate yang baru lo import di Step 1
Default action: untuk sekarang pilih "Return fixed response" dengan status 404, nanti lo ganti waktu tambah rules

Klik Create load balancer.

Step 4: Setup Listener Rules by Host Header

Ini inti dari artikel ini. Listener rules yang nentuin subdomain mana routing ke service mana.

Masuk ke EC2 > Load Balancers > pilih ALB lo > tab Listeners > klik View/edit rules di listener 443.

Tambah Rule per Service

Klik Add rule untuk setiap service:

Rule untuk app1.domain.com:

Condition: Host header = app1.domain.com
Action: Forward to target group app1-target-group
Priority: 1

Rule untuk app2.domain.com:

Condition: Host header = app2.domain.com
Action: Forward to target group app2-target-group
Priority: 2

Ulangi untuk setiap service yang lo punya.

Default Rule

Default rule itu yang jalan kalau request masuk tapi ga match sama rule manapun. Jangan dibiarkan kosong atau error, kasih fixed response 404 atau redirect ke halaman utama lo (kalo gua biasanya halaman landing page).

Penting: Urutan priority itu ngaruh. ALB ngecheck rules dari priority terkecil ke terbesar. Kalau ada dua rules yang bisa match, yang prioritynya lebih kecil yang menang.

Step 5: Tambah CNAME di DNS Provider Lo

Ini yang beda dari semua artikel lain yang pake Route53. Lo tinggal point subdomain lo ke ALB DNS name, dan ini bisa lo lakuin di DNS provider manapun yang lo pake, Cloudflare, Domainesia, Niagahoster, atau yang lain. Caranya pada dasarnya sama.

Ambil ALB DNS Name

Masuk ke EC2 > Load Balancers > pilih ALB lo. Di bagian bawah lo bakal liat DNS name, formatnya kira-kira:

nama-alb-lo-1234567890.ap-southeast-1.elb.amazonaws.com

Tambah CNAME Record

Di DNS provider lo, tambah record baru:

Type: CNAME
Name/Host: app1 (subdomain lo, fullnya jadi app1.domain.com)
Value/Target: paste ALB DNS name lo di sini
TTL: 300 (5 menit cukup buat testing)

Ulangi untuk setiap subdomain yang lo punya.

Tunggu beberapa menit untuk DNS propagation, biasanya 5 menit kalau TTL lo 300.

Step 6: Attach Target Group ke ECS Service

Kalau ECS service lo belum di-attach ke target group yang baru lo buat, lo perlu update servicenya.

Masuk ke ECS > cluster lo > service > Update service:

Di bagian Load balancing, tambah target group yang sesuai
Pastiin container name dan port match sama yang ada di task definition lo

Setelah update, ECS bakal register task yang jalan ke target group tersebut.

Step 7: Verifikasi

Setelah DNS propagation selesai, cek satu-satu:

Target Group di console, pastiin health check statusnya healthy. Kalau masih initial tunggu beberapa menit, kalau unhealthy cek health check path lo
Akses via browser, buka https://app1.domain.com dan pastiin HTTPSnya valid dan app lo respond
Cek certificate, klik ikon gembok di browser, pastiin certificate yang kepakai itu yang lo import tadi

Kalau HTTPSnya invalid atau browser bilang "certificate not trusted", kemungkinan certificate chain lo waktu import belum lengkap.

Lessons Learned

Beberapa hal yang gua pelajarin dari setup ini di production:

1. Urutan listener rules itu ngaruh
ALB ngecheck dari priority terkecil. Kalau lo punya wildcard rule kayak *.domain.com, taruh di priority paling besar (terakhir) supaya ga nutup rules yang lebih spesifik.

2. Default rule jangan dikosongkan
Kalau ada request yang masuk ke ALB tapi ga match rule manapun, default rule yang handle. Kasih fixed response 404 daripada biarkan error ga jelas atau langsung ke landing page aja.

3. Health check path harus konsisten
Gua pernah ganti path health check di code tapi lupa update di target group. Hasilnya task terus-terusan di-replace sama ECS karena ALB nganggep servicenya unhealthy.

4. Certificate chain harus lengkap
Waktu import SSL ke ACM, certificate chain itu wajib. Kalau lo skip atau paste yang salah, browser bakal bilang certificate not trusted meskipun SSL lo valid.

5. TTL DNS waktu testing
Set TTL ke 300 dulu waktu testing. Kalau lo set terlalu tinggi dan ada yang salah, lo harus nunggu lama banget sampai DNS update.

6. Satu service satu target group, jangan dicampur
Gua pernah kena kasus aneh, refresh page di app1.domain.com tapi responsenya bergantian dari dua service yang berbeda. Ternyata penyebabnya dua ECS service lo attach ke target group yang sama. ALB by default distribusi traffic secara round robin ke semua task yang registered di target group tersebut. Jadi request pertama ke service A, request kedua ke service B, terus bergantian. Solusinya simpel: satu service harus punya satu target group tersendiri.

7. Satu ALB bisa handle banyak certificate
Kalau lo punya beberapa domain yang berbeda (bukan subdomain), ALB support multiple certificate via SNI. Lo bisa import beberapa SSL dan attach ke listener yang sama.

Penutup

Setelah setup ini selesai, lo punya satu ALB yang handle semua service lo dengan HTTPS yang proper. Tiap kali mau tambah service baru, tinggal:

Buat target group baru
Tambah listener rule baru di ALB
Tambah CNAME baru di DNS provider lo
Attach target group ke ECS service

Ga perlu buat ALB baru, ga perlu beli SSL baru selama domainnya masih sama.

Kalau ada pertanyaan drop di komentar, gua jawab sesuai pengalaman gua.

Deploy NestJS ke AWS ECS Fargate Secara Manual: Cara Paling Simpel Buat Mulai

Eryan Fauzan — Sun, 05 Apr 2026 13:56:18 +0000

Ini artikel pertama gua di dev.to. Gua nulis ini karena makanan sehari-hari deploy NestJS ke ECS Fargate dan sebagai catetan gua juga di kala lupa.

Gua bakal nulis dari pengalaman nyata setup yang gua pake di kerjaan, bukan setup ideal tapi work in production karena waktu dan tenaga yang terbatas.

konten bahasa Indonesia yang ngebahas ini step by step jarang kayaknya ya wkwk atau terlalu niche ya? ajak-ajak gua lah kalo ada pembahasan terkait AWS khususnya DevOps dan WebDev.

buat step by step gua bikin masih narrative tapi gua coba bahas sedetail mungkin, gambarnya bertahap gua lengkapin

kemungkinan nantinya tulisan ini bakal ngelink ke beberapa tutorial lainnya dan aka di update bertahap.
Semoga artikel ini ngebantu lo yang lagi di posisi yang sama.

Kenapa ECS Fargate, Bukan EC2?

Kalau lo baru mau mulai deploy NestJS app ke AWS, pilihan pertama yang sering bikin bingung adalah: pakai EC2 atau ECS?

EC2 itu simpel secara konsep, lo dapat satu virtual machine (temen gua beberapa ada yang kecele dia rada binggung saat gua bilang VM, gua bilang kayak semacam VPS baru nyambung), lo install Node.js, lo jalanin app lo. Tapi di balik itu lo harus urus sendiri: update OS, manage process dengan PM2, handle restart kalau app crash, dan kalau mau scale lo harus setup sendiri.

ECS Fargate beda. Lo ga pegang server sama sekali. Lo cukup kasih container, define berapa CPU dan memory yang dibutuhkan, dan AWS yang urus sisanya kayak scheduling, restart, bahkan scaling kalau lo mau. Lo bayar per detik container jalan, bukan per jam instance hidup.

Artikel ini bakal ngajarin lo cara deploy NestJS app ke ECS Fargate secara manual tanpa CI/CD dulu. Cukup dari local, push ke ECR, setup di console AWS, dan app lo jalan di belakang ALB.

Ini cara yang paling gampang buat mulai, dan kalau lo udah paham flow-nya, nambah CI/CD belakangan jadi jauh lebih gampang.

Prasyarat

Sebelum mulai, pastiin lo udah punya hal-hal berikut:

AWS Side:

AWS account yang udah aktif
IAM user dengan akses ke ECR dan ECS (jangan pakai root account)
ECR repository yang udah dibuat
RDS PostgreSQL instance yang udah jalan di VPC yang sama
ALB yang udah di-setup atau siap di-setup

Local Side:

AWS CLI v2 terinstall dan sudah di-configure (aws configure)
Docker Desktop terinstall dan jalan
NestJS app yang udah siap di-deploy
Git (karena script deploy kita bakal pakai branch name dan commit hash buat image tag)

Networking:

VPC dengan minimal 2 public subnet untuk ALB
Security group yang udah direncanain ECS task perlu bisa terima traffic dari ALB, dan bisa konek ke RDS

Kalau semua udah siap, kita mulai dari langkah pertama.

Step 1: Dockerize NestJS App

Buat Dockerfile di root project lo:

# ---------- builder stage ----------
FROM node:22-alpine AS builder
WORKDIR /usr/app

# install build deps (include dev deps because we need tsc)
COPY package*.json ./
RUN npm ci

# copy source & build
COPY . .
RUN npm run build

# ---------- production stage ----------
FROM node:22-alpine
WORKDIR /usr/app

# copy only production deps and app metadata
COPY package*.json ./
# install only production deps
RUN npm ci --omit=dev

# copy built artifacts from builder
COPY --from=builder /usr/app/dist ./dist

# create non-root user (optional but recommended)
RUN addgroup -S app && adduser -S app -G app

# create exports directory with proper permissions
RUN mkdir -p /usr/app/exports && chown -R app:app /usr/app

USER app

# GANTI INI -- sesuaikan dengan port NestJS app lo
EXPOSE 3000

CMD ["node", "dist/main.js"]

Beberapa hal yang perlu diperhatiin:

Pakai multi-stage build. Stage pertama buat build, stage kedua buat production image. Hasilnya image lebih kecil karena ga bawa devDependencies.
node:22-alpine versi LTS terbaru, lebih ringan dari image full.
npm ci --omit=dev lebih modern dari --only=production, install hanya production dependencies.
Non-root user ini security best practice yang sering dilewatin. Container lo ga jalan sebagai root, jadi kalau ada exploit, dampaknya lebih terbatas.
mkdir exports kalau app lo ada fitur generate file, direktori ini udah siap dengan permission yang bener.

Test dulu di local sebelum push ke ECR:

docker build -t nama-app-lo .
docker run -p 3000:3000 nama-app-lo # GANTI INI - sesuaikan port

Step 2: Setup ECR dan Push Image

Buat ECR Repository

Masuk ke AWS Console > ECR > Create repository. Kasih nama yang deskriptif, misalnya nama-project/nama-service.

kalo mau liat push commandnya tinggal klik repository yang udah dibuat terus klik disana ada button "View Push Command"

tapi gua ada cara lebih gampang lagi biar ga berkali-kali push command kalo mau push image

Script Deploy ke ECR

Ini script yang gua pake buat build dan push image dari local ke ECR:

#!/usr/bin/env bash
set -e

# Pastiin AWS CLI ada di PATH lo
export PATH="/c/Program Files/Amazon/AWSCLIV2:$PATH"

echo "Using AWS CLI from: $(which aws.exe)"

# Variables
BRANCH_NAME=$(git rev-parse --abbrev-ref HEAD)
IMAGE_TAG="${BRANCH_NAME}-$(git rev-parse --short HEAD)"
LAST_COMMIT=$(git log -1 --pretty=format:"%h - %s (%cr) <%an>")
REGION="ap-southeast-1" # GANTI INI - sesuaikan region lo
ECR_URI="YOUR_ACCOUNT_ID.dkr.ecr.${REGION}.amazonaws.com/YOUR_REPO_NAME" # GANTI INI

# Display deployment info
echo "=== Deployment Information ==="
echo "Branch: ${BRANCH_NAME}"
echo "Commit: ${LAST_COMMIT}"
echo "Image Tag: ${IMAGE_TAG}"
echo "================================"

# Authenticate Docker ke ECR
aws.exe ecr get-login-password --region "${REGION}" \
  | docker login --username AWS --password-stdin "${ECR_URI}"

# Build & tag
docker build -t nama-app-lo . # GANTI INI
docker tag nama-app-lo:latest "${ECR_URI}:latest" # GANTI INI
docker tag nama-app-lo:latest "${ECR_URI}:${IMAGE_TAG}" # GANTI INI

# Push
docker push "${ECR_URI}:latest"
docker push "${ECR_URI}:${IMAGE_TAG}"

echo "Deployed image tag: ${IMAGE_TAG}"

Kenapa gua push dua tag sekaligus?

latest yang direferensiin di ECS task definition, jadi tiap deploy ECS tinggal pull yang terbaru
branch-commithash buat versioning, kalau ada masalah lo tau persis commit mana yang jalan di production
ini kepake banget saat lo nantinya di minta buat pisahan enviroment misalnya development, staging dan production lo ga binggung enviroment mana pake image yang mana dan branch. karena real casenya dev, stag, prod itu beda-beda semua enviromentnya saat ada keterbatasan team ini bisa nolong lo dari kepusingan itu

Step 3: Simpan .env di S3

Ini bagian yang jarang dibahas tapi sangat praktis. Daripada hardcode environment variable satu-satu di task definition, lo bisa simpan .env file di S3 dan ECS yang bakal load otomatis waktu container start.

Kenapa S3?

Lebih gampang di-manage, tinggal update file di S3, ga perlu update task definition
Lebih aman, file ada di S3 dengan permission yang bisa dikontrol
Familiar, format .env yang sama kayak di local

Cara Setup

1. Buat S3 bucket khusus buat env files:

nama-bucket-lo/
  nama-app-lo/
    staging/
      .env
    production/
      .env

2. Upload .env ke S3:

aws s3 cp .env s3://nama-bucket-lo/nama-app-lo/staging/.env # GANTI INI

3. Kasih permission ke ECS Task Execution Role:

ECS butuh permission buat baca file dari S3. Tambahkan policy ini ke ecsTaskExecutionRole di IAM:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::nama-bucket-lo/*"
    },
    {
      "Effect": "Allow",
      "Action": ["s3:GetBucketLocation"],
      "Resource": "arn:aws:s3:::nama-bucket-lo"
    }
  ]
}

Step 4: Setup Task Definition

Task definition itu blueprint container lo di ECS. Define image mana yang dipakai, berapa resource yang dialokasiin, port mana yang dibuka, dan dari mana env-nya diload.

Ini contoh task definition yang gua pake:

{
  "family": "nama-service-lo",
  "containerDefinitions": [
    {
      "name": "nama-service-lo",
      "image": "YOUR_ACCOUNT_ID.dkr.ecr.ap-southeast-1.amazonaws.com/YOUR_REPO:latest",
      "cpu": 0,
      "portMappings": [
        {
          "containerPort": 3000,
          "hostPort": 3000,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "environment": [],
      "environmentFiles": [
        {
          "value": "arn:aws:s3:::nama-bucket-lo/nama-app-lo/staging/.env",
          "type": "s3"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/nama-service-lo",
          "awslogs-region": "ap-southeast-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ],
  "executionRoleArn": "arn:aws:iam::YOUR_ACCOUNT_ID:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512"
}

Beberapa hal yang perlu diperhatiin:

cpu: 256 dan memory: 512 itu spec paling minimal di Fargate, dan perlu diingat ini dialokasiin di level task, bukan per container. Artinya kalau lo punya lebih dari satu container di task yang sama, semua sharing pool ini. Untuk single container staging cukup, tapi kalau lo mau nambah container lain di task yang sama, naikin spec dulu sebelum deploy.
networkMode: awsvpc mandatory buat Fargate, setiap task dapat ENI sendiri.
logDriver: awslogs log container lo otomatis masuk ke CloudWatch, sangat membantu waktu debugging.
environmentFiles yang nge-load .env dari S3 yang kita setup di step sebelumnya.

Buat CloudWatch log group dulu sebelum deploy. Ada dua cara:

Via AWS CLI:

# Buat log group
aws logs create-log-group \
  --log-group-name /ecs/nama-service-lo \
  --region ap-southeast-1 # GANTI INI

# Set retention 30 hari supaya ga numpuk dan kena billing
aws logs put-retention-policy \
  --log-group-name /ecs/nama-service-lo \
  --retention-in-days 30 \
  --region ap-southeast-1 # GANTI INI

Via AWS Console:

Masuk ke CloudWatch > Log groups > Create log group. Isi log group name dengan /ecs/nama-service-lo, lalu di bagian Retention setting pilih 30 days. Kalau lo skip retention policy, log lo bakal disimpan selamanya dan kena billing terus.

Step 5: Buat Cluster

Masuk ke AWS Console > ECS > Clusters > Create Cluster. Pilih AWS Fargate sebagai infrastructure.

Step 6: Setup ALB, Target Group & Service

Sebelum buat service, lo harus siapin ALB dan target group dulu karena lo bakal attach ini waktu buat service di Step selanjutnya.

Buat Target Group

Masuk ke EC2 > Target Groups > Create:

Target type: IP (bukan Instance, karena Fargate pakai awsvpc mode)
Protocol: HTTP
Port: sesuaikan dengan port container lo
Health check path: / atau endpoint health check lo kalau ada (biasanya gua pake pattern/api/v1/health) isinya json biasa aja

Buat ALB

Masuk ke EC2 > Load Balancers > Create > Application Load Balancer:

Scheme: Internet-facing (kalau mau diakses dari luar)
Subnets: minimal 2 AZ, pilih public subnet
Security group: allow inbound port 80 dan/atau 443
Listener: forward ke target group yang baru lo buat

Setelah ALB dan target group siap, baru lo buat service ECS-nya.

Buat Service

Masuk ke cluster yang baru lo buat, klik Create service:

Isi konfigurasi dasar:
- Launch type: Fargate
- Task definition: pilih yang lo buat di Step 4
- Service name: kasih nama yang deskriptif
- Desired tasks: 1 untuk awal
Di bagian Networking:
- Pilih VPC yang sama dengan RDS lo
- Pilih minimal 2 subnet
- Buat atau pilih security group yang allow inbound dari ALB dan allow outbound ke RDS
Di bagian Load balancing:
- Pilih Application Load Balancer
- Pilih ALB yang baru lo buat
- Pilih target group yang sesuai
- Pastiin health check path lo bener
Klik Create service

ECS bakal langsung pull image dari ECR dan jalanin task pertama lo. Setelah task RUNNING, ECS otomatis register ke target group dan ALB mulai routing traffic ke container lo.

Step 7: Deploy Ulang Setelah Setup Awal

Step 5 dan 6 itu cuma dilakuin sekali waktu pertama kali setup. Setelah infrastruktur jalan, workflow deploy lo jadi jauh lebih simpel.

Tiap kali ada update code, lo cukup:

1. Push image baru ke ECR:

./deploy.sh

2. Trigger ECS buat pull image terbaru:

#!/usr/bin/env bash
set -e

REGION="ap-southeast-1" # GANTI INI
CLUSTER="nama-cluster-lo" # GANTI INI
SERVICE="nama-service-lo" # GANTI INI

aws.exe ecs update-service \
  --region "${REGION}" \
  --cluster "${CLUSTER}" \
  --service "${SERVICE}" \
  --force-new-deployment > /dev/null 2>&1

echo "✅ Service '${SERVICE}' updated"

--force-new-deployment yang bikin ECS stop task lama dan start task baru dengan image latest yang baru aja lo push. Script ini cuma bisa dijalanin kalau service lo udah exist, makanya setup awal di Step 5 harus selesai dulu.

Dua script, selesai.

Step 8: Verifikasi

Setelah update-service jalan, tunggu beberapa menit (biasanya 2-5 menit) dan cek:

ECS Console > cluster lo > service > Tasks, pastiin task statusnya RUNNING
CloudWatch Logs, cek /ecs/nama-service-lo buat liat log container lo
Target Group, cek health check statusnya healthy
ALB DNS, akses DNS ALB lo di browser, harusnya app lo udah jalan

Kalau task gagal start, logs di task atau logs CloudWatch itu tempat pertama yang harus lo cek. keterangan log nya itu sama persis ketika lo jalanin di lokal seperti log error, warning, info dll

Lessons Learned

Beberapa hal yang gua pelajarin dari setup ini di production:

1. Health check itu krusial
Kalau health check path lo salah atau endpoint lo return status bukan 200, ALB bakal terus-terusan drain dan replace task dan ini yang pertama kali gua pikir selalu gagal 2 hari debugging ini ternyata dia nyari yang response 200. Pastiin health check path lo bener sebelum deploy.

2. Security group harus teliti
ECS task, ALB, dan RDS punya security group masing-masing. Yang paling sering bikin masalah: ECS task ga bisa konek ke RDS karena security group RDS belum allow inbound dari security group ECS. Cek ini kalau app lo gagal konek ke database.

3. S3 env file ga otomatis refresh
ini juga pain point, Kalau lo update .env di S3, container yang lagi jalan ga otomatis reload. Lo tetap harus trigger --force-new-deployment buat apply perubahan env.

4. Minimal spec dulu
Mulai dari 256 CPU / 512 MB memory. Monitor dulu di CloudWatch, baru scale up kalau emang butuh. Jangan langsung pakai spec besar karena Fargate billing per resource yang lo define.

Penutup

Setup ini mungkin keliatan banyak langkahnya, tapi setelah semua infrastruktur jalan, workflow deploy harian lo cuma dua script. Simpel dan bisa dikontrol.

Dari sini, langkah selanjutnya yang natural adalah:

Tambah CI/CD supaya ga perlu build dari local (AWS CodePipeline + CodeBuild)
Setup auto scaling di ECS service
Pisahin staging dan production environment

Kalau ada pertanyaan atau ada yang kurang jelas, drop di kolom komentar. Gua bakal jawab sesuai pengalaman gua.