Fase 9 · Deploy di AWS

Memilih compute di AWS

Keputusan ini menentukan bentuk seluruh sisa fase. Untungnya, karakteristik Laravel mempersempit pilihannya jauh lebih cepat daripada yang terlihat dari panjangnya daftar layanan AWS.

Sumber asli docs.aws.amazon.com Resmi Rangkuman ~7 menit baca

Intisari

ECS Fargate adalah default yang tepat: kontainer tanpa mengelola server, terintegrasi penuh dengan layanan AWS lain.
EKS hanya kalau organisasimu memang sudah berjalan di atas Kubernetes.
Lambda menuntut aplikasi stateless berdurasi pendek — bisa untuk Laravel, tapi dengan kompromi yang nyata.
EC2 saat butuh kendali penuh atas kernel, ekstensi, atau tipe instans khusus.
Beban kerja Laravel biasanya berumur panjang dan terikat I/O — itu profil kontainer, bukan fungsi.

Peta pilihan

Layanan	Model	Untuk Laravel
ECS + Fargate	Kontainer, tanpa server yang dikelola	Default yang disarankan
ECS + EC2	Kontainer di atas instans milikmu	Saat butuh tipe instans khusus atau lebih murah pada skala besar
EKS	Kubernetes terkelola	Hanya kalau organisasi sudah memakai Kubernetes
Lambda	Fungsi, per pemanggilan	Bisa (lewat Bref/Vapor), dengan kompromi
App Runner	Kontainer, sangat disederhanakan	Prototipe; kendalinya terbatas
Elastic Beanstalk	Platform lama	Hindari untuk proyek baru
Lightsail	VPS sederhana	Proyek kecil, satu server

Kenapa ECS Fargate untuk Laravel

Kebutuhan aplikasi Laravel	Fargate menjawabnya dengan
Proses web berumur panjang	Task yang terus hidup, bukan fungsi berumur pendek
Worker antrean	Service terpisah dengan penskalaan sendiri
Penjadwal	Satu task, atau dipicu EventBridge Scheduler
Worker mode (Fase 8)	Proses yang tetap hidup — syarat mutlak
Rahasia dari secret store	Integrasi `secrets` di task definition
Tidak mau mengelola OS	Tidak ada instans yang perlu di-patch
Skala mendatar	Naikkan jumlah task; ALB menyeimbangkannya

Poin keempat itu yang menentukan. Kalau kamu berencana memakai FrankenPHP atau RoadRunner, kamu butuh proses yang tetap hidup di antara permintaan. Lambda membangun dan membekukan lingkungan eksekusi per pemanggilan, jadi model worker mode tidak cocok dengan bentuknya. Fargate memberimu proses biasa yang berjalan terus — persis yang dibutuhkan.

Kompromi kalau memilih Lambda

Hal	Konsekuensi di Lambda
Cold start	Permintaan pertama setelah menganggur terasa lambat
Durasi maksimum	15 menit — cukup untuk web, mengikat untuk job berat
Berkas	Filesystem hanya baca kecuali `/tmp`
Koneksi database	Butuh RDS Proxy; ribuan pemanggilan bisa menghabiskan koneksi
Worker mode	Tidak berlaku
Biaya saat lalu lintas stabil	Sering lebih mahal daripada kontainer
Biaya saat lalu lintas sangat tidak merata	Bisa jauh lebih murah

Aturan praktisnya soal biaya. Lambda menang saat aplikasimu benar-benar menganggur sebagian besar waktu lalu melonjak tajam. Untuk lalu lintas yang berjalan sepanjang hari dengan puncak yang bisa diperkirakan, kontainer yang berjalan terus hampir selalu lebih murah — dan lebih sederhana, karena tidak perlu proxy koneksi dan tidak perlu memikirkan cold start.

Arsitektur acuan yang dibangun di fase ini

                  Route 53
                     │
                CloudFront  ──────────►  S3 (aset & media)
                     │
                    WAF
                     │
            Application Load Balancer          (subnet publik)
                     │
        ┌────────────┴────────────┐
        │      ECS Fargate        │            (subnet privat)
        │  ┌───────────────────┐  │
        │  │ service: web      │  │  FrankenPHP + Laravel
        │  │ service: worker   │  │  queue:work
        │  │ service: scheduler│  │  schedule:work
        │  └───────────────────┘  │
        └────────────┬────────────┘
                     │
     ┌───────────────┼────────────────┬──────────────┐
  Aurora        ElastiCache          SQS       Secrets Manager
 (writer +        (Redis)                       + CloudWatch
  reader)

Komponen	Perannya	Materi
CloudFront + S3	Aset, media, dan halaman publik yang di-cache	S3 & CloudFront
ALB	TLS, health check, penyebaran lalu lintas	ALB
ECS Fargate	Menjalankan kontainer web, worker, penjadwal	Fargate, task definition
Aurora	Database, writer dan reader terpisah	Aurora
ElastiCache	Cache, session, lock	ElastiCache
SQS	Antrean yang tahan gangguan	SQS
Secrets Manager	Kredensial dan `APP_KEY`	Secrets Manager

Tentang jaringan

Task ECS tinggal di subnet privat. Hanya ALB yang boleh menghubunginya.
Database dan Redis di subnet privat, security group-nya hanya menerima dari security group task.
Akses keluar lewat NAT Gateway — atau lewat VPC endpoint untuk layanan AWS, yang lebih murah pada volume besar.
Jangan pernah memberi alamat IP publik pada task aplikasi.

Aturan pertama itu punya kaitan langsung dengan Fase 1. Karena hanya ALB yang bisa menjangkau task, konfigurasi trusted proxy dengan at: '*' menjadi aman — tidak ada seorang pun di luar yang bisa memalsukan X-Forwarded-For. Kalau task punya IP publik, asumsi itu runtuh dan rate limiting-mu bisa ditembus.

Latihan: gambar ulang diagram di atas untuk aplikasimu sendiri, dan tandai untuk setiap komponen: apakah ia di subnet publik atau privat, dan siapa saja yang boleh menghubunginya. Diagram inilah yang nanti kamu terjemahkan jadi security group.

Rangkuman ini sengaja dipangkas ke bagian yang dipakai di roadmap. Buka sumber aslinya saat kamu butuh detail lengkap atau referensi parameter.