Deploy Go API ke ECS Fargate
dari ECR sampai ALB

ECS Fargate mengubah Docker image menjadi task yang hidup di VPC AWS

Di Chapter 1 sampai 4 Roadmap 8 kamu sudah punya Docker image multi-stage, docker compose lokal, CI pipeline, dan paham fondasi AWS. Sekarang image itu harus benar-benar hidup sebagai API production yang menerima trafik pelanggan.

Kalau kamu terbiasa deploy React ke Vercel atau Laravel ke VPS lewat git pull dan php artisan migrate, ECS terasa jauh lebih banyak langkah. Ia sengaja memisahkan registry (ECR), runtime (Fargate), jaringan (VPC dan subnet), load balancer (ALB), identitas (IAM role), log (CloudWatch), dan rahasia (Secrets Manager) menjadi bagian-bagian terpisah. Pemisahan ini terlihat ramai, tetapi itulah yang memberi kontrol untuk backend yang menyimpan data pelanggan, order, inventory, dan pembayaran.

Sebelum bicara registry dan load balancer, satu hal harus benar lebih dulu: aplikasi Go-mu wajib punya endpoint health check yang ringan.

Build, push ke ECR, register task definition, update service, lalu trafik mengalir lewat ALB

Deploy ke ECS bukan satu perintah ajaib. Ia rangkaian perubahan kecil yang masing-masing bisa diaudit, dan diagram berikut adalah peta mental yang akan kita pakai sepanjang modul.

flowchart LR
  Dev["Developer atau CI"] -->|docker build| Image["Image skincare-api"]
  Image -->|docker tag SHA| Tag["Tag berbasis commit"]
  Tag -->|docker push| ECR["Amazon ECR (privat)"]
  ECR -->|image URI| TD["Task definition (revisi)"]
  TD -->|register| ECS["ECS Service"]
  ECS -->|run desired count| Task["Fargate task (private subnet)"]
  ALB["ALB (public subnet)"] -->|GET /healthz| TG["Target group (type ip)"]
  TG -->|forward :8080| Task
  Task -->|query| RDS[("RDS PostgreSQL")]
  Task -->|logs awslogs| CW["CloudWatch Logs"]
  SM["Secrets Manager"] -.->|inject saat start| Task

Gambar 1. Jalur deploy Go API skincare dari image sampai menerima trafik publik melalui ALB.

Perhatikan arah trafik dan arah outbound. Request masuk dari internet ke ALB di public subnet, lalu diteruskan ke task di private subnet. Sebaliknya, task yang butuh keluar (menarik image dari ECR, mengambil secret, memanggil API gateway pembayaran) jalannya lewat NAT Gateway, karena task tidak punya IP publik.

ALB hanya mengirim trafik ke target sehat, jadi endpoint ini menentukan apakah deploy dianggap berhasil

Health check adalah kontrak antara aplikasimu dan ALB. Kalau ia tidak pernah balas 200, target tidak pernah jadi healthy, dan rolling deployment akan menggantung lalu di-rollback otomatis.

Di dunia Kubernetes atau Cloud Run kamu mungkin kenal istilah liveness dan readiness probe. Bedakan dua hal serupa juga di sini: liveness (apakah proses hidup) dan readiness (apakah siap menerima trafik, termasuk koneksi database). ALB target group hanya menerima satu path health check, jadi pola umum yang aman adalah membuat /healthz super ringan untuk ALB dan /readyz yang mengecek dependency untuk dipakai investigasi.

internal/httpapi/health.goSalin
package httpapi

import (
	"context"
	"encoding/json"
	"net/http"
	"time"

	"github.com/go-chi/chi/v5"
	"github.com/jackc/pgx/v5/pgxpool"
)

type healthResponse struct {
	Status string `json:"status"`
}

// RegisterHealthRoutes memasang /healthz (liveness, dipakai ALB) dan
// /readyz (readiness, mengecek koneksi database untuk investigasi).
func RegisterHealthRoutes(r chi.Router, pool *pgxpool.Pool) {
	r.Get("/healthz", livenessHandler)
	r.Get("/readyz", readinessHandler(pool))
}

func livenessHandler(w http.ResponseWriter, _ *http.Request) {
	writeJSON(w, http.StatusOK, healthResponse{Status: "ok"})
}

func readinessHandler(pool *pgxpool.Pool) http.HandlerFunc {
	return func(w http.ResponseWriter, r *http.Request) {
		ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)
		defer cancel()

		if err := pool.Ping(ctx); err != nil {
			writeJSON(w, http.StatusServiceUnavailable, healthResponse{Status: "db_unavailable"})
			return
		}
		writeJSON(w, http.StatusOK, healthResponse{Status: "ready"})
	}
}

func writeJSON(w http.ResponseWriter, status int, body any) {
	w.Header().Set("Content-Type", "application/json")
	w.WriteHeader(status)
	_ = json.NewEncoder(w).Encode(body)
}

Image lokal belum bisa dipakai ECS sampai ia ada di registry yang bisa ditarik task execution role

Amazon ECR adalah Docker registry privat milik AWS. ECS tidak menarik image dari mesinmu, melainkan dari repository ECR yang sudah berisi image dengan tag tertentu.

Alurnya empat langkah: build image dari Dockerfile, beri tag yang mengandung URI registry plus tag commit, login Docker ke registry ECR dengan token sementara, lalu push. Token login ECR berumur pendek (sekitar 12 jam) dan diminta lewat AWS CLI, bukan password statik.

TerminalSalin
export AWS_ACCOUNT_ID="123456789012"
export AWS_REGION="ap-southeast-1"
export ECR_REPO="skincare-api"
export IMAGE_TAG="$(git rev-parse --short HEAD)"
export ECR_REGISTRY="$AWS_ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com"
export ECR_URI="$ECR_REGISTRY/$ECR_REPO"

# 1. Build image dari Dockerfile multi-stage (binary Go kecil)
docker build -t "$ECR_REPO:$IMAGE_TAG" .

# 2. Tag ke URI registry ECR
docker tag "$ECR_REPO:$IMAGE_TAG" "$ECR_URI:$IMAGE_TAG"

# 3. Login Docker ke ECR dengan token sementara dari AWS CLI
aws ecr get-login-password --region "$AWS_REGION" \
  | docker login --username AWS --password-stdin "$ECR_REGISTRY"

# 4. Push image ke repository privat
docker push "$ECR_URI:$IMAGE_TAG"

Repository ECR perlu dibuat sekali. Aktifkan scan-on-push agar image dipindai kerentanan, dan pertimbangkan immutable tags agar tag yang sama tidak bisa ditimpa diam-diam.

TerminalSalin
aws ecr create-repository \
  --repository-name skincare-api \
  --image-scanning-configuration scanOnPush=true \
  --image-tag-mutability IMMUTABLE \
  --region "$AWS_REGION"

Image lama menumpuk dan memakan storage berbayar. Lifecycle policy menghapusnya otomatis, misalnya hanya menyimpan 10 tag terbaru dan membuang image untagged setelah satu hari.

ecr-lifecycle-policy.jsonSalin
{
  "rules": [
    {
      "rulePriority": 1,
      "description": "Hapus image untagged setelah 1 hari",
      "selection": {
        "tagStatus": "untagged",
        "countType": "sinceImagePushed",
        "countUnit": "days",
        "countNumber": 1
      },
      "action": { "type": "expire" }
    },
    {
      "rulePriority": 2,
      "description": "Simpan 10 image bertag terbaru",
      "selection": {
        "tagStatus": "any",
        "countType": "imageCountMoreThan",
        "countNumber": 10
      },
      "action": { "type": "expire" }
    }
  ]
}

Di sinilah image, CPU, memory, port, environment, secrets, IAM role, dan log dikunci jadi satu revisi

Task definition adalah kontrak runtime ber-versi. ECS service tidak menyimpan detail container langsung, ia menunjuk ke sebuah revisi task definition. Ganti satu hal, kamu membuat revisi baru.

Untuk Fargate, cpu dan memory ditetapkan di level task dengan kombinasi valid tertentu (misalnya 256 CPU / 512 MiB, atau 512 CPU / 1024 MiB). networkMode wajib awsvpc, yang membuat tiap task dapat ENI dan IP privat sendiri.

task-definition.jsonSalin
{
  "family": "skincare-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/skincareApiTaskRole",
  "runtimePlatform": {
    "operatingSystemFamily": "LINUX",
    "cpuArchitecture": "ARM64"
  },
  "containerDefinitions": [
    {
      "name": "skincare-api",
      "image": "123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/skincare-api:8f3a2c1",
      "essential": true,
      "portMappings": [
        {
          "name": "http",
          "containerPort": 8080,
          "protocol": "tcp",
          "appProtocol": "http"
        }
      ],
      "environment": [
        { "name": "APP_ENV", "value": "production" },
        { "name": "HTTP_ADDR", "value": ":8080" },
        { "name": "AWS_REGION", "value": "ap-southeast-1" }
      ],
      "secrets": [
        {
          "name": "DATABASE_URL",
          "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/prod/database-url-AbCdEf"
        },
        {
          "name": "JWT_SECRET",
          "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/prod/jwt-secret-AbCdEf"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/skincare-api",
          "awslogs-region": "ap-southeast-1",
          "awslogs-stream-prefix": "api"
        }
      },
      "readonlyRootFilesystem": true
    }
  ]
}

Register task definition lewat CLI. Setiap register menghasilkan revisi baru (skincare-api:1, skincare-api:2, dan seterusnya).

TerminalSalin
aws ecs register-task-definition \
  --cli-input-json file://task-definition.json \
  --region "$AWS_REGION"

ECS memakai dua role berbeda untuk dua tujuan berbeda, dan mencampurnya adalah sumber kebingungan klasik

Ini bagian yang paling sering bikin developer baru ECS bingung. Ada dua role di task definition, dan keduanya bukan untuk hal yang sama.

flowchart TD
  subgraph Fargate["Fargate Task"]
    Agent["Agen ECS / Fargate"]
    App["Container: Go API"]
  end
  ExecRole["Execution Role<br/>ecsTaskExecutionRole"]
  TaskRole["Task Role<br/>skincareApiTaskRole"]
  Agent -->|pakai| ExecRole
  App -->|pakai via SDK| TaskRole
  ExecRole -->|pull image| ECR["ECR"]
  ExecRole -->|kirim log| CW["CloudWatch Logs"]
  ExecRole -->|GetSecretValue| SM["Secrets Manager"]
  TaskRole -->|PutObject| S3["S3 gambar produk"]
  TaskRole -->|SendMessage| SQS["SQS antrian job"]

Gambar 2. Execution role melayani infrastruktur task (pull, log, inject secret). Task role melayani panggilan AWS dari kode aplikasimu.

Kredensial ECR, log, dan secret dari execution role tidak terekspos ke dalam container. Jadi kalau kode Go-mu butuh memanggil S3 atau SQS, ia harus pakai task role, bukan menumpang execution role.

Terapkan least privilege. Untuk execution role yang menarik secret kustom, tambahkan inline policy yang membatasi secretsmanager:GetSecretValue hanya ke ARN secret yang dipakai, bukan *.

exec-role-secrets-policy.jsonSalin
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["secretsmanager:GetSecretValue"],
      "Resource": [
        "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/prod/database-url-*",
        "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/prod/jwt-secret-*"
      ]
    }
  ]
}

Service menjaga task tetap hidup, ALB menyalurkan trafik hanya ke task sehat di banyak AZ

Untuk API publik, polanya berlapis: ALB di public subnet menerima internet, task ECS di private subnet menerima trafik hanya dari ALB, dan RDS di private subnet menerima koneksi hanya dari task.

Inti keamanannya ada di security group yang saling mereferensikan, bukan membuka IP. ALB SG menerima 80/443 dari internet, task SG menerima port 8080 hanya dari ALB SG, dan RDS SG menerima 5432 hanya dari task SG. Security group bersifat stateful, jadi reply otomatis diizinkan tanpa aturan outbound terpisah.

flowchart LR
  Net["Internet 0.0.0.0/0"] -->|:443 / :80| ALBSG["ALB SG"]
  ALBSG -->|:8080 hanya dari ALB SG| TaskSG["ECS Task SG"]
  TaskSG -->|:5432 hanya dari Task SG| RDSSG["RDS SG"]
  ALBSG -.public subnet.-> ZoneA["AZ-a"]
  TaskSG -.private subnet.-> ZoneA
  RDSSG -.private subnet.-> ZoneA

Gambar 3. Security group berlapis. RDS tidak pernah membuka 5432 ke internet maupun ke ALB, hanya ke source security group task.

Target group untuk Fargate dengan awsvpc wajib bertipe ip (bukan instance), karena setiap task punya IP sendiri. Health check path mengarah ke /healthz, dan hanya target healthy yang menerima trafik.

TerminalSalin
aws elbv2 create-target-group \
  --name skincare-api-tg \
  --protocol HTTP \
  --port 8080 \
  --vpc-id vpc-0123456789abcdef0 \
  --target-type ip \
  --health-check-protocol HTTP \
  --health-check-path /healthz \
  --matcher HttpCode=200 \
  --health-check-interval-seconds 15 \
  --healthy-threshold-count 2 \
  --region "$AWS_REGION"

Buat service yang menjaga 2 task, di private subnet across dua AZ, terhubung ke target group, tanpa public IP.

TerminalSalin
aws ecs create-service \
  --cluster skincare-prod \
  --service-name skincare-api \
  --task-definition skincare-api \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-private-a,subnet-private-b],securityGroups=[sg-ecs-api],assignPublicIp=DISABLED}" \
  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:ap-southeast-1:123456789012:targetgroup/skincare-api-tg/abc123,containerName=skincare-api,containerPort=8080" \
  --health-check-grace-period-seconds 30 \
  --deployment-configuration "minimumHealthyPercent=100,maximumPercent=200" \
  --region "$AWS_REGION"

Konfigurasi biasa boleh plain, tetapi credential sensitif harus lewat Secrets Manager

Di Go, konfigurasi production dibaca dari environment variable. Bedanya di ECS: tidak semua environment variable boleh ditulis sebagai plain value di task definition.

Field environment berisi key/value polos yang terlihat di task definition dan docker inspect. Field secrets berisi valueFrom yang menunjuk ARN Secrets Manager atau SSM Parameter Store. Saat task start, execution role mengambil nilai secret lalu menyuntikkannya sebagai environment variable ke container, sehingga aplikasimu tetap membacanya lewat os.Getenv.

sequenceDiagram
  participant ECS as ECS / Fargate Agent
  participant Exec as Execution Role
  participant SM as Secrets Manager
  participant App as Container Go API
  ECS->>Exec: assume role saat task start
  ECS->>SM: GetSecretValue (ARN DATABASE_URL)
  SM-->>ECS: nilai secret (terdekripsi)
  ECS->>App: inject sebagai env DATABASE_URL
  App->>App: os.Getenv("DATABASE_URL")

Gambar 4. Secret di-resolve saat startup oleh execution role, lalu disuntik sebagai env. Kode Go tetap membaca dari os.Getenv.

Dari sisi aplikasi Go, env biasa dan secret yang diinjeksi sama-sama muncul sebagai environment variable. Maka kode config-mu tidak perlu tahu bedanya, ia cukup membaca dan memvalidasi.

internal/config/config.goSalin
package config

import (
	"fmt"
	"os"
)

type Config struct {
	Env         string
	HTTPAddr    string
	DatabaseURL string
	JWTSecret   string
}

func Load() (Config, error) {
	cfg := Config{
		Env:         getenv("APP_ENV", "development"),
		HTTPAddr:    getenv("HTTP_ADDR", ":8080"),
		DatabaseURL: os.Getenv("DATABASE_URL"),
		JWTSecret:   os.Getenv("JWT_SECRET"),
	}

	// Fail fast: lebih baik task gagal start daripada jalan tanpa kredensial.
	if cfg.DatabaseURL == "" {
		return Config{}, fmt.Errorf("config: DATABASE_URL wajib diisi")
	}
	if cfg.JWTSecret == "" {
		return Config{}, fmt.Errorf("config: JWT_SECRET wajib diisi")
	}

	return cfg, nil
}

func getenv(key, fallback string) string {
	if v := os.Getenv(key); v != "" {
		return v
	}
	return fallback
}

Untuk mengambil satu key spesifik di dalam JSON secret, tambahkan nama key ke ARN dengan format ...:secret:name-XXXXX:DATABASE_URL::.

task-definition.json (potongan secrets dari JSON key)Salin
{
  "secrets": [
    {
      "name": "DATABASE_URL",
      "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/prod/app-AbCdEf:DATABASE_URL::"
    },
    {
      "name": "JWT_SECRET",
      "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/prod/app-AbCdEf:JWT_SECRET::"
    }
  ]
}

Register revisi baru, update service, lalu ECS mengganti task bertahap hanya setelah yang baru sehat

Rolling deployment membuat task baru berjalan dan lulus health check lebih dulu, baru task lama dihentikan. Pelanggan tidak pernah melihat 503, asalkan health check dan kapasitas diatur benar.

sequenceDiagram
  participant CI as CI Pipeline
  participant ECR as ECR
  participant ECS as ECS Service
  participant ALB as ALB Target Group
  participant Old as Task Lama
  participant New as Task Baru
  CI->>ECR: Push skincare-api:8f3a2c1
  CI->>ECS: Register revisi task definition baru
  CI->>ECS: Update service ke revisi baru
  ECS->>New: Start task baru (private subnet)
  ALB->>New: GET /healthz
  New-->>ALB: 200 OK (healthy)
  ALB->>New: Mulai forward trafik
  ECS->>Old: Drain lalu stop task lama
  CI->>ECS: wait services-stable

Gambar 5. Rolling deployment bergantung pada health check yang benar dan kapasitas minimal task sehat selama transisi.

minimumHealthyPercent=100 berarti ECS menjaga jumlah task sehat tidak pernah turun di bawah desired count selama deploy. maximumPercent=200 memberi ruang menjalankan task baru di samping task lama (sampai dua kali desired count) sebelum yang lama dibuang. Kombinasi ini menghasilkan deploy tanpa penurunan kapasitas.

TerminalSalin
# 1. Register revisi baru dan tangkap ARN-nya
NEW_TD_ARN=$(aws ecs register-task-definition \
  --cli-input-json file://task-definition.json \
  --query "taskDefinition.taskDefinitionArn" \
  --output text \
  --region "$AWS_REGION")

# 2. Arahkan service ke revisi baru
aws ecs update-service \
  --cluster skincare-prod \
  --service skincare-api \
  --task-definition "$NEW_TD_ARN" \
  --region "$AWS_REGION"

# 3. Tunggu sampai deployment stabil (atau timeout)
aws ecs wait services-stable \
  --cluster skincare-prod \
  --services skincare-api \
  --region "$AWS_REGION"

Pasangkan dengan CI. Setelah job quality (lint, test, build) lulus dan image ber-SHA terdorong ke ECR, job deploy mengganti image di task definition lalu register dan update service. OIDC membuat GitHub Actions assume role tanpa access key statik.

.github/workflows/deploy.ymlSalin
name: Deploy
on:
  push:
    branches: [ main ]
permissions:
  id-token: write
  contents: read
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789012:role/gha-ecs-deploy
          aws-region: ap-southeast-1
      - id: ecr
        uses: aws-actions/amazon-ecr-login@v2
      - uses: docker/setup-buildx-action@v3
      - uses: docker/build-push-action@v7
        with:
          context: .
          push: true
          tags: ${{ steps.ecr.outputs.registry }}/skincare-api:${{ github.sha }}
          cache-from: type=gha
          cache-to: type=gha,mode=max
      - name: Render task definition dengan image baru
        id: td
        uses: aws-actions/amazon-ecs-render-task-definition@v1
        with:
          task-definition: task-definition.json
          container-name: skincare-api
          image: ${{ steps.ecr.outputs.registry }}/skincare-api:${{ github.sha }}
      - name: Deploy ke ECS dan tunggu stabil
        uses: aws-actions/amazon-ecs-deploy-task-definition@v2
        with:
          task-definition: ${{ steps.td.outputs.task-definition }}
          service: skincare-api
          cluster: skincare-prod
          wait-for-service-stability: true

Latihan minimal dari image lokal sampai service stabil yang menerima trafik lewat ALB

Latihan ini mengasumsikan VPC, subnet, security group, ALB, listener, ECR repository, CloudWatch log group, dan secret di Secrets Manager sudah ada. Fokusnya: mendorong image dan menggerakkan service.

TerminalSalin
curl -i http://localhost:8080/healthz

docker build -t "$ECR_REPO:$IMAGE_TAG" .
docker tag "$ECR_REPO:$IMAGE_TAG" "$ECR_URI:$IMAGE_TAG"

aws ecr get-login-password --region "$AWS_REGION" \
  | docker login --username AWS --password-stdin "$ECR_REGISTRY"

docker push "$ECR_URI:$IMAGE_TAG"

Setelah service di-update, validasi statusnya. Lihat deployment yang sedang berjalan dan jumlah task yang running.

TerminalSalin
# Status deployment dan running count
aws ecs describe-services \
  --cluster skincare-prod \
  --services skincare-api \
  --query "services[0].{running:runningCount,desired:desiredCount,deployments:deployments[].status}" \
  --region "$AWS_REGION"

# Kesehatan target di target group
aws elbv2 describe-target-health \
  --target-group-arn "$TG_ARN" \
  --query "TargetHealthDescriptions[].TargetHealth.State" \
  --region "$AWS_REGION"

# Hit endpoint publik lewat DNS ALB
curl -i "http://$ALB_DNS/healthz"

Deploy ECS gagal biasanya bukan karena Go, melainkan network, IAM, image tag, dan health check

Binary Go jarang jadi penyebab utama deploy gagal. Yang sering bermasalah adalah asumsi dari pola deploy lama yang tidak cocok dengan model ECS.

Soal SIGTERM penting dan sering terlupa. Saat rolling deploy menghentikan task lama, ECS mengirim SIGTERM lalu menunggu sebentar sebelum SIGKILL. Server Go harus menangkapnya dan menyelesaikan request yang sedang jalan.

cmd/api/main.goSalin
package main

import (
	"context"
	"errors"
	"net/http"
	"os"
	"os/signal"
	"syscall"
	"time"
)

func runServer(srv *http.Server) error {
	// Tangkap sinyal dari ECS saat task akan dihentikan.
	ctx, stop := signal.NotifyContext(context.Background(),
		syscall.SIGINT, syscall.SIGTERM)
	defer stop()

	errCh := make(chan error, 1)
	go func() {
		if err := srv.ListenAndServe(); err != nil &&
			!errors.Is(err, http.ErrServerClosed) {
			errCh <- err
		}
	}()

	select {
	case err := <-errCh:
		return err
	case <-ctx.Done():
		// SIGTERM diterima: drain request in-flight, jangan terima yang baru.
		shutdownCtx, cancel := context.WithTimeout(context.Background(), 15*time.Second)
		defer cancel()
		return srv.Shutdown(shutdownCtx)
	}
}

var _ = os.Stdout

Deploy ke ECS Fargate adalah proses mengubah Docker image menjadi service yang stabil, aman, terukur, dan bisa di-rollback presisi, untuk backend skincare yang menyimpan data pelanggan dan transaksi nyata.

Dengan API skincare sudah hidup di ECS, langkah berikutnya di Roadmap 8 adalah melengkapi sistem production: deploy worker SQS terpisah (Chapter 6), menyambung RDS PostgreSQL privat dengan connection pool yang tepat (Chapter 7), menyimpan gambar produk di S3 dengan CloudFront (Chapter 8), lalu memasang observability berupa CloudWatch alarm untuk CPU, memory, ALB 5xx, dan backlog antrian (Chapter 9). Pola yang kamu kunci di sini, image immutable, secret terpisah, jaringan berlapis, dan deploy tanpa downtime, akan dipakai ulang di setiap service berikutnya.