AWS Foundation
Peta Layanan Backend Skincare

Deploy bukan sekadar menjalankan binary, tetapi menempatkan binary di jaringan, izin, dan layanan yang benar.

Di Roadmap 8 kita tidak hanya membuat Docker image, kita menaruh image itu ke lingkungan cloud yang punya jaringan privat, permission eksplisit, database managed, object storage, log aggregation, secret store, dan queue.

Sampai Roadmap 7, backend skincare berjalan di laptop: go run ./cmd/api, PostgreSQL lokal, file .env, dan log mengalir ke terminal. Production di AWS mengubah hampir semua asumsi itu. Database hidup di server terpisah yang tak bisa kamu SSH. Log hilang begitu container mati. Secret tidak boleh ada di disk. Dan ada firewall di setiap lapisan yang harus kamu rancang, bukan diwariskan dari panel hosting.

Modul ini sengaja bukan deep dive konfigurasi (itu jatah Chapter 5 sampai 9). Targetnya: kamu bisa membaca diagram arsitektur, menyebut layanan yang benar untuk tiap kebutuhan, tahu data bergerak ke mana, dan bisa berdiskusi dengan DevOps, SRE, atau cloud engineer tanpa kehilangan arah. Anggap ini seperti membaca peta sebelum menyetir, bukan menghafal tiap belokan.

VPC adalah jaringan privatmu di AWS, subnet membaginya, dan Availability Zone membuatnya tahan gangguan.

Semua resource backend skincare (ALB, ECS task, RDS) hidup di dalam satu VPC. Memahami VPC dulu membuat layanan lain masuk akal, karena hampir semuanya ditempatkan relatif terhadap jaringan ini.

CIDR seperti 10.0.0.0/16 berarti VPC ini memiliki sekitar 65 ribu alamat IP privat (10.0.0.0 sampai 10.0.255.255). Angka /16 adalah panjang prefix: makin kecil angkanya, makin besar blok alamat. Kamu memecah blok besar ini menjadi subnet yang lebih kecil, misalnya 10.0.1.0/24 (256 alamat) untuk satu subnet.

Subnet adalah pecahan dari CIDR VPC, dan tiap subnet terikat ke tepat satu AZ. Inilah dua sumbu yang harus selalu kamu pikirkan: sumbu fungsi (public vs private) dan sumbu ketahanan (AZ mana). Production yang sehat menyebar tiap peran ke minimal dua AZ.

Yang membedakan public dari private bukan label, tetapi route table-nya. Public subnet punya rute 0.0.0.0/0 → Internet Gateway. Private subnet tidak. Untuk keluar ke internet, private subnet mengarahkan 0.0.0.0/0 → NAT Gateway yang dipasang di public subnet.

flowchart TB
  Internet(["Internet"])
  subgraph VPC["VPC skincare-prod (10.0.0.0/16)"]
    subgraph AZ1["Availability Zone A"]
      PubA["Public subnet 10.0.1.0/24<br/>ALB, NAT Gateway"]
      PrivA["Private subnet 10.0.11.0/24<br/>ECS API, worker, RDS"]
    end
    subgraph AZ2["Availability Zone B"]
      PubB["Public subnet 10.0.2.0/24<br/>ALB, NAT Gateway"]
      PrivB["Private subnet 10.0.12.0/24<br/>ECS API, worker, RDS"]
    end
    IGW["Internet Gateway"]
  end
  Internet <--> IGW
  IGW <--> PubA
  IGW <--> PubB
  PrivA -->|outbound via NAT| PubA
  PrivB -->|outbound via NAT| PubB

Gambar 1. VPC dengan public dan private subnet tersebar di dua AZ. Internet hanya menyentuh public subnet, private subnet keluar lewat NAT.

Subnet menentukan ke mana paket bisa dirutekan, Security Group menentukan paket mana yang diizinkan.

Setelah jaringan terbentuk, kita perlu firewall. Di AWS ada dua lapis: Security Group di level resource dan Network ACL di level subnet. Untuk backend skincare, Security Group adalah alat utama yang kamu pakai sehari-hari.

Kata kunci paling penting: stateful. Kamu cukup mengizinkan inbound, dan AWS otomatis mengizinkan reply keluar. Ini sangat berbeda dari Network ACL yang stateless.

Pola paling kuat adalah merujuk Security Group lain sebagai sumber, bukan rentang IP. Untuk skincare, traffic mengalir berlapis: internet hanya boleh menyentuh ALB, ALB hanya boleh menyentuh API, dan RDS hanya boleh disentuh API serta worker. Database tidak pernah membuka port ke internet maupun ke ALB.

flowchart LR
  Net(["Internet<br/>0.0.0.0/0"]) -->|443, 80| ALBSG["ALB SG"]
  ALBSG -->|8080 dari ALB SG| TaskSG["ECS task SG<br/>API & worker"]
  TaskSG -->|5432 dari task SG| RDSSG["RDS SG"]

Gambar 2. Setiap lapisan hanya menerima dari Security Group lapisan di atasnya. RDS tidak pernah menerima dari internet atau ALB.

Network ACL ada di level subnet dan stateless: kamu harus mengizinkan inbound dan outbound secara terpisah, termasuk port ephemeral untuk reply. Karena itu NACL jarang dipakai untuk aturan harian. Biarkan default-nya allow, dan andalkan Security Group untuk kontrol yang presisi. NACL berguna untuk pagar kasar tingkat subnet, misalnya memblokir rentang IP tertentu di seluruh subnet sekaligus.

IAM menjawab pertanyaan siapa boleh melakukan apa pada resource mana, dan Role memberi izin tanpa credential abadi.

Jaringan mengatur paket, IAM mengatur izin. Di AWS, kode Go-mu tidak login dengan username dan password, ia mengasumsikan Role yang memberi credential sementara dan berputar otomatis.

Untuk ECS, ada dua Role berbeda yang sering tertukar. Memisahkan keduanya adalah inti keamanan workload, jadi pahami siapa pemakainya, bukan sekadar namanya.

flowchart TB
  subgraph ECS["ECS Fargate Task"]
    Agent["Agen ECS / Fargate"]
    App["Kode Go (container)"]
  end
  Agent -->|execution role| ECR["ECR: pull image"]
  Agent -->|execution role| Logs["CloudWatch: kirim log"]
  Agent -->|execution role| SMstart["Secrets Manager: inject saat start"]
  App -->|task role| S3["S3: upload object"]
  App -->|task role| SQS["SQS: kirim message"]

Gambar 3. Dua Role berbeda. Execution role untuk pekerjaan runtime ECS, task role untuk kode aplikasimu.

Prinsip yang membungkus semuanya adalah least privilege: beri hanya action dan resource ARN yang dibutuhkan, bukan *. Untuk skincare, task role API cukup boleh s3:PutObject ke bucket gambar produk dan sqs:SendMessage ke queue tertentu, bukan akses penuh ke semua S3 dan semua queue.

iam/skincare-api-task-role.jsonSalin
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PutProductImages",
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::skincare-product-images/*"
    },
    {
      "Sid": "EnqueueBackgroundJobs",
      "Effect": "Allow",
      "Action": ["sqs:SendMessage"],
      "Resource": "arn:aws:sqs:ap-southeast-1:123456789012:skincare-jobs"
    }
  ]
}

Tiga layanan yang mengubah Docker image hasil CI menjadi API yang bisa diakses user.

Setelah CI membangun Docker image, perjalanannya jelas: image disimpan di ECR, dijalankan oleh ECS Fargate, lalu diekspos ke user lewat ALB. Tiga huruf ini adalah tulang punggung deployment.

ECR juga punya lifecycle policy: aturan otomatis menghapus image lama atau untagged, misalnya simpan 10 tag terbaru, agar storage tidak menggembung dari setiap commit yang menghasilkan image baru.

Task definition adalah blueprint berversi (tiap perubahan menghasilkan revisi baru). Inilah dokumen yang menyatukan hampir semua konsep modul ini: image dari ECR, port aplikasi, log ke CloudWatch, secret dari Secrets Manager, serta dua IAM Role tadi.

deploy/aws/skincare-api-taskdef.jsonSalin
{
  "family": "skincare-api",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/skincare-api-task-role",
  "containerDefinitions": [
    {
      "name": "api",
      "image": "123456789012.dkr.ecr.ap-southeast-1.amazonaws.com/skincare-backend:git-sha",
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
      "environment": [
        { "name": "APP_ENV", "value": "production" },
        { "name": "HTTP_ADDR", "value": ":8080" }
      ],
      "secrets": [
        {
          "name": "DATABASE_URL",
          "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/db-AbCdEf"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/skincare-api",
          "awslogs-region": "ap-southeast-1",
          "awslogs-stream-prefix": "api"
        }
      }
    }
  ]
}

Perhatikan networkMode: awsvpc yang wajib untuk Fargate: setiap task mendapat ENI dan IP privat sendiri di dalam subnet. Perhatikan juga pemisahan tegas antara environment (key-value biasa, terlihat di docker inspect) dan secrets (di-resolve dari ARN Secrets Manager saat startup oleh execution role). Bagian secret ini kita perdalam di Section berikutnya.

ALB (Application Load Balancer) adalah pintu masuk HTTP dan HTTPS. Listener-nya mendengarkan port (mis. 443 untuk HTTPS, 80 untuk redirect ke HTTPS), lalu meneruskan ke target group. Untuk Fargate, target group wajib bertipe ip (bukan instance), karena tiap task punya IP sendiri.

flowchart LR
  CI["GitHub Actions"] -->|push image| ECR["ECR<br/>skincare-backend"]
  ECR -->|pull saat deploy| Service["ECS Service"]
  Service -->|jaga desired count| Task1["Task A (AZ-A)"]
  Service --> Task2["Task B (AZ-B)"]
  ALB["ALB (public)"] -->|target group type ip| Task1
  ALB --> Task2
  ALB -.->|/healthz| Task1

Gambar 4. Alur dari CI ke production: image di ECR, dijalankan ECS Service di banyak AZ, diekspos lewat ALB yang health-check tiap task.

Data transaksi dan file produk punya karakter berbeda, maka tempatnya pun berbeda.

Order, payment, dan stock butuh transaksi relasional. Gambar produk butuh storage murah berkapasitas besar. PostgreSQL untuk yang pertama, S3 untuk yang kedua, dan keduanya saling melengkapi.

Untuk skincare, RDS menyimpan semua data relasional dari Roadmap 3 sampai 5: user, produk, variant, cart, order, payment, voucher, inventory movement, dan audit log. Versi PostgreSQL 17 sudah tersedia di RDS (GA sejak akhir 2024). Pilih major version, dan RDS mengisi minor terbaru. Cek versi yang tersedia di Region-mu dengan aws rds describe-db-engine-versions --engine postgres --default-only sebelum provisioning.

Tiga hal operasional RDS yang relevan sejak awal:

Penempatan dan keamanan RDS mengikuti pelajaran Section 2 dan 3: DB subnet group di private subnet (minimal 2 AZ), bukan publicly accessible, dan Security Group inbound 5432 hanya dari Security Group ECS, bukan dari CIDR 0.0.0.0/0.

Satu jebakan lain yang khas: jangan menjalankan migration saat boot tiap task. Kalau 4 task naik bersamaan dan semuanya mencoba migrate up, terjadi race condition. Pola yang benar adalah menjalankan migration sebagai one-off task terpisah (mis. ECS RunTask dengan command migrate up) atau sebagai langkah pipeline sebelum service di-update.

S3 menyimpan gambar produk, foto review, invoice PDF, dan export laporan. PostgreSQL cukup menyimpan metadata: s3_key, content_type, size_bytes, dan cdn_url. Memisahkan file fisik dari metadata membuat database tetap ramping dan storage tetap murah.

Production butuh credential aman dan jejak observability, bukan hanya bisa jalan.

Dua layanan ini menutup sisi yang sering diabaikan saat pertama deploy: dari mana secret datang, dan ke mana log pergi saat container mati.

Roadmap 7 sudah membahas pola konsumsi secret dari kode Go. Di sini fokusnya cara ECS menyuntikkan secret ke container. Di task definition, field secrets memakai valueFrom berisi ARN secret. Saat task start, execution role memanggil GetSecretValue, lalu menyuntikkan nilainya sebagai environment variable ke container.

deploy/aws/secrets-block.jsonSalin
{
  "secrets": [
    {
      "name": "DATABASE_URL",
      "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/db-AbCdEf"
    },
    {
      "name": "JWT_SECRET",
      "valueFrom": "arn:aws:secretsmanager:ap-southeast-1:123456789012:secret:skincare/auth-GhIjKl:JWT_SECRET::"
    }
  ]
}

Baris kedua menunjukkan pengambilan satu key dari secret JSON: tambahkan :JWT_SECRET:: di akhir ARN. Inilah yang membuat satu secret JSON bisa menampung banyak nilai sekaligus.

Inilah alasan structured logging dari Roadmap 4 berbuah di production. Karena aplikasi Go menulis JSON ke STDOUT lewat slog.NewJSONHandler, dan awslogs meneruskannya apa adanya, setiap field (level, order_id, latency_ms, trace_id) bisa di-query lewat CloudWatch Logs Insights.

cmd/api/main.go (logger production)Salin
package main

import (
	"log/slog"
	"os"
)

func newLogger() *slog.Logger {
	// JSON ke STDOUT: awslogs meneruskannya ke CloudWatch apa adanya.
	handler := slog.NewJSONHandler(os.Stdout, &slog.HandlerOptions{
		Level: slog.LevelInfo,
	})
	return slog.New(handler)
}

CloudWatch Logs InsightsSalin
fields @timestamp, level, msg, order_id
| filter level = "ERROR"
| stats count() by msg
| sort count() desc

Tidak semua pekerjaan harus selesai di dalam request HTTP user.

Saat customer checkout, mengirim invoice email atau resize gambar produk tidak perlu menahan response. API cukup menaruh pesan di antrian, lalu worker memprosesnya terpisah. SQS adalah antrian managed itu.

Untuk skincare, pilih jenis queue sesuai kebutuhan. Standard queue (throughput tinggi, urutan tidak dijamin, at-least-once) cocok untuk notifikasi email atau push. FIFO queue (urutan terjamin per group, exactly-once processing) cocok untuk event pembayaran yang urutan dan dedup-nya kritis.

sqs/send-invoice-message.jsonSalin
{
  "type": "send_invoice_email",
  "order_id": "INV-20260606-8F3A",
  "user_id": "usr_01HYZ9G5M0",
  "attempt": 1,
  "trace_id": "req_01J0AWSFOUNDATION"
}

Dua mekanisme SQS yang wajib kamu pahami sebelum menulis worker:

sequenceDiagram
  participant API as Go API
  participant Q as SQS Queue
  participant W as Worker (ECS)
  participant DLQ as Dead-letter Queue
  API->>Q: SendMessage (checkout selesai)
  W->>Q: ReceiveMessage (long polling)
  Q-->>W: pesan invoice (jadi invisible)
  alt sukses
    W->>Q: DeleteMessage
  else gagal terus sampai maxReceiveCount
    Q->>DLQ: pindahkan pesan beracun
  end

Gambar 5. Siklus pesan SQS: diproses dan dihapus saat sukses, atau dipindah ke DLQ setelah gagal berulang.

Karakter beban yang naik turun (banyak checkout sore hari, sepi tengah malam) membuat worker cocok di-scale otomatis. ECS Service Auto Scaling bisa menambah jumlah task worker berdasarkan panjang antrian, dengan pola Backlog per Task (ApproximateNumberOfMessagesVisible dibagi jumlah task). Saat antrian kosong, MinCapacity=0 memungkinkan scale-to-zero agar hemat biaya. Detail scaling worker diperdalam di Chapter 6.

Menyatukan semua layanan menjadi satu peta yang bisa kamu baca dari kiri ke kanan.

Sekarang semua kepingan bertemu. Diagram ini adalah peta layanan minimum backend skincare di AWS, dan menjadi rujukan untuk seluruh Chapter berikutnya di Roadmap 8.

flowchart TB
  User(["Customer / Admin"])
  CI["GitHub Actions CI"]

  subgraph AWS["AWS Account ap-southeast-1"]
    ECR["ECR<br/>skincare-backend"]
    S3["S3<br/>product images"]
    Secrets["Secrets Manager<br/>DB URL, JWT, payment key"]
    Logs["CloudWatch Logs<br/>api & worker"]
    SQS["SQS<br/>background jobs"]

    subgraph VPC["VPC skincare-prod"]
      subgraph Public["Public subnets, 2 AZ"]
        ALB["ALB HTTPS"]
        NAT["NAT Gateway"]
      end
      subgraph PrivApp["Private app subnets, 2 AZ"]
        API["ECS Fargate<br/>skincare-api"]
        Worker["ECS Fargate<br/>skincare-worker"]
      end
      subgraph PrivData["Private data subnets, 2 AZ"]
        RDS[("RDS PostgreSQL")]
      end
    end
  end

  User -->|HTTPS| ALB
  CI -->|push image| ECR
  ECR -.->|pull saat deploy| API
  ECR -.->|pull saat deploy| Worker
  ALB -->|forward ke task sehat| API
  API -->|SQL 5432| RDS
  Worker -->|SQL 5432| RDS
  API -->|enqueue| SQS
  SQS -->|consume| Worker
  API -->|upload| S3
  API -.->|inject saat start| Secrets
  Worker -.->|inject saat start| Secrets
  API -->|STDOUT JSON| Logs
  Worker -->|STDOUT JSON| Logs
  API -->|outbound| NAT
  Worker -->|outbound| NAT

Gambar 6. Arsitektur ringkas backend skincare: ALB publik, API dan worker di private app subnet, RDS di private data subnet, serta layanan managed untuk image, file, secret, log, dan antrian.

Baca alurnya seperti perjalanan satu request checkout. User mengetuk ALB lewat HTTPS, ALB meneruskan ke task API yang sehat di private subnet, API menulis order ke RDS dalam satu transaksi, lalu mengirim pesan send_invoice_email ke SQS dan langsung membalas user. Worker mengambil pesan itu, memproses, dan mengirim email. Sepanjang itu, secret datang dari Secrets Manager, log mengalir ke CloudWatch, dan outbound ke payment gateway lewat NAT.

Latihan ringan: bukan membuat semua resource, tetapi melatih membaca resource yang nanti dipakai saat deploy.

Sebelum membuat resource production (yang sebaiknya lewat IaC, bukan klik manual), latih dulu membacanya dengan AWS CLI. Tujuannya membangun mental model, bukan menghafal perintah.

TerminalSalin
# 1. Identitas dan Region aktif
aws sts get-caller-identity
aws configure get region

# 2. Repository image di ECR
aws ecr describe-repositories \
  --repository-names skincare-backend

# 3. Service ECS di cluster skincare-prod
aws ecs describe-services \
  --cluster skincare-prod \
  --services skincare-api skincare-worker \
  --query "services[].{name:serviceName,desired:desiredCount,running:runningCount}"

# 4. Versi PostgreSQL default yang tersedia di Region
aws rds describe-db-engine-versions \
  --engine postgres \
  --default-only \
  --query "DBEngineVersions[].EngineVersion"

# 5. Ikuti log API secara live
aws logs tail /ecs/skincare-api \
  --follow \
  --since 10m

Kebanyakan masalah deploy pertama bukan karena Go, tetapi karena mental model hosting lama dibawa ke arsitektur cloud.

Bug AWS pertama biasanya bukan soal sintaks, tetapi soal asumsi: menganggap jaringan, secret, dan log berperilaku seperti di VPS atau shared hosting.

Peta AWS memberi kosakata bersama sebelum kita masuk ke deployment detail.

AWS Foundation bukan tentang menghafal tiap tombol konsol, tetapi tentang punya peta: tahu layanan apa untuk kebutuhan apa, dan ke mana data bergerak di backend skincare.

Di proyek online shop skincare, peta ini menyatukan seluruh roadmap sebelumnya: domain dari Roadmap 5 hidup di RDS, security dari Roadmap 7 berlabuh ke IAM dan Secrets Manager, dan structured logging dari Roadmap 4 berbuah di CloudWatch. Langkah berikutnya adalah mengubah peta menjadi deployment konkret. Chapter 5 men-deploy API ke ECS Fargate di belakang ALB, Chapter 6 menjalankan worker dan SQS consumer, lalu Chapter 7 sampai 9 memperdalam database, gambar produk, dan observability. Mulai dari sini, kamu tidak lagi menebak nama layanan, kamu memetakannya.