Belajar Floci - Multi-Region & Simulasi Multi-Account

#Pendahuluan

Organisasi nyata tidak hidup dalam satu region dan satu akun: staging terpisah dari production, resource tersebar multi-region, tenant diisolasi per account. Pertanyaannya: bisakah satu instance floci lokal mensimulasikan kerumitan ini?

Jawabannya bisa — dengan memahami dua hal: perilaku region yang didukung native, dan teknik simulasi multi-account lewat konvensi penamaan. Episode 17 menutup FASE 3.

#Region

#Default Region & Region-Specific Resources

Set FLOCI_DEFAULT_REGION (episode 16) menentukan region asumsi ketika request tidak menyebutkan region. Namun perilaku per-request tetap hormat pada header region SDK:

export AWS_ENDPOINT_URL=http://localhost:4566
 
aws s3api create-bucket --bucket r-jkt \
  --create-bucket-configuration LocationConstraint=ap-southeast-3
aws s3api create-bucket --bucket r-virginia \
  --create-bucket-configuration LocationConstraint=us-east-1
 
aws s3api head-bucket --bucket r-jkt   # keduanya ada
aws s3api head-bucket --bucket r-virginia

Yang penting dipahami tentang semantik region di emulator:

• Bucket S3 membawa atribut region seperti aslinya.
• Sebagian besar layanan lain (SQS/SNS/Lambda) di floci bersifat global-per-instance — ARN mereka mencantumkan region dari request, tapi state disatukan.

#Multi-Account

#Simulasi Isolasi Tenant via Conventions

AWS punya account ID sungguhan; floci menerima apa pun. Itu justru pintu masuk simulasi:

# Tenant A "berjalan" sebagai account 111111111111
# Tenant B "berjalan" sebagai account 222222222222
# Konvensi: semua resource diberi awalan akun + env
BUCKET_A=floci-a-dev-app-assets
BUCKET_B=floci-b-dev-app-assets
 
aws s3 mb s3://$BUCKET_A && aws s3 mb s3://$BUCKET_B

Lapisan kedua: pasangkan konvensi dengan IAM policy yang menegakkan prefix — dilatih via simulator (episode 9):

cat > tenant-a.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
  "Action":"s3:*","Resource":["arn:aws:s3:::floci-a-*","arn:aws:s3:::floci-a-*/*"]}]}
EOF
aws --endpoint-url=http://localhost:4566 iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111111111111:role/tenant-a \
  --policy-input-list file://tenant-a.json \
  --action-names s3:PutObject \
  --resource-arns arn:aws:s3:::floci-b-dev-app-assets/x.txt
# denied -> logika isolasi policy tervalidasi walau runtime longgar

Pola ini mereplikasi strategi multi-account AWS Organizations nyata: isolation by naming convention + policy guardrails.

#Praktik

Target outline: setup dua "lingkungan" (dev/staging logic) dalam satu instance floci.

services:
  floci-dev:
    image: floci/floci:latest
    ports: ["4566:4566"]
    environment:
      FLOCI_STORAGE_MODE: memory        # dev = cepat & volatile
    volumes: [floci-dev:/app/data]
 
  floci-staging:
    image: floci/floci:latest
    ports: ["4567:4566"]                # port host beda
    environment:
      FLOCI_STORAGE_MODE: persistent    # staging = bertahan restart
    volumes: [floci-stg:/app/data]
volumes: { floci-dev: {}, floci-stg: {} }

docker compose up -d
export DEV=http://localhost:4566 STG=http://localhost:4567
 
aws --endpoint-url=$DEV s3 mb s3://floci-a-dev-app-assets
aws --endpoint-url=$STG s3 mb s3://floci-a-stg-app-assets
echo "staging data" | aws --endpoint-url=$STG s3 cp - s3://floci-a-stg-app-assets/k.txt
 
docker compose restart floci-dev && sleep 1
aws --endpoint-url=$DEV s3 ls | grep -c app-assets || echo "dev kosong (memory) - sesuai harapan"
aws --endpoint-url=$STG s3 ls | grep stg-app-assets && echo "staging selamat (persistent)"

Hasilnya adalah miniatur organisasi: dua lingkungan dengan karakter durability berbeda, konvensi penamaan lintas tenant, dan policy yang bisa diaudit — semua di satu laptop.

#Penutup

Rangkuman episode ini:

• Region: default via FLOCI_DEFAULT_REGION, bucket membawa region constraint; layanan lain cenderung per-instance.
• Multi-account disimulasikan via konvensi prefix/account-id + validasi policy lewat simulator IAM.
• Dua lingkungan (dev memory vs staging persistent) berdampingan di satu compose — pola organisasi dalam skala laptop.

FASE 3 selesai! Episode 18 membuka FASE 4 dengan tooling paling dituntut: Terraform & OpenTofu — plan/apply penuh secara lokal ke floci. Sampai jumpa!