AWS Solutions Architect · Pelajaran

Skenario Arsitektur Tangguh dan Berketersediaan Tinggi

Hadapi skenario pengalihan basis data Multi-AZ, penskalaan otomatis saat lalu lintas melonjak, dan pengalihan berdasarkan pemeriksaan kesehatan Route 53 untuk memperkuat konsep keandalan.

Skenario Arsitektur Tangguh dan Berketersediaan Tinggi adalah pelajaran AWS Solutions Architect gratis di CoddyKit. Ini adalah pelajaran 2 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar AWS Solutions Architect, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus AWS Solutions Architect mencakup 4 pelajaran total.

Skenario 1: Application Web Multi-AZ

Skenario: Sebuah perusahaan menjalankan Application web dua tingkat (ALB → EC2 → RDS) dan ingin menghilangkan setiap titik kegagalan tunggal di dalam AWS Region. Solusi: Deploy instance EC2 dalam Auto Scaling Group yang mencakup setidaknya 2 Availability Zone di belakang ALB (yang secara bawaan bersifat multi-AZ). Aktifkan RDS Multi-AZ untuk replikasi standby sinkron. Konfigurasikan health check pada ALB agar rute secara otomatis dialihkan dari instance yang tidak sehat. Dengan arsitektur ini, hilangnya satu AZ mana pun akan memicu failover otomatis pada setiap tingkat.

# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --engine mysql \
  --multi-az \
  --master-username admin \
  --master-user-password Pass123! \
  --allocated-storage 100

# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc

Skenario 2: Penskalaan Baca RDS Saat Beban Tinggi

Skenario: Instance RDS milik Application e-commerce mencapai batas CPU selama jam sibuk karena kueri analitik yang didominasi operasi baca dari tim business intelligence. Solusi: Buat Read Replica RDS dan arahkan kueri BI ke titik akhir replika tersebut. Read Replica menggunakan replikasi asinkron—sedikit keterlambatan masih dapat diterima untuk analitik. Cara ini mengurangi lalu lintas baca dari instance RDS Primary, yang digunakan untuk operasi tulis dan pembacaan oleh Application. Untuk beban kerja yang sangat didominasi operasi baca, tambahkan lapisan ElastiCache di depan RDS untuk data yang sering diakses.

# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-replica \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --availability-zone us-east-1b

# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)

Skenario 3: Auto Scaling Saat Lonjakan CPU

Skenario: API tanpa status berjalan di EC2 di belakang ALB. Penggunaan CPU melonjak hingga 90% selama jam kerja dan turun mendekati nol pada malam hari. Perusahaan ingin fleet diskalakan secara otomatis. Solusi: Konfigurasikan Auto Scaling Group dengan kebijakan penskalaan Target Tracking yang menargetkan rata-rata penggunaan CPU sebesar 60%. ASG akan menambahkan instance secara otomatis saat CPU melebihi 60% dan menghapus instance saat turun di bawah target. Tambahkan tindakan penskalaan terjadwal untuk menyiapkan kapasitas minimum sebelum jam kerja dimulai, sehingga mencegah keterlambatan saat lonjakan lalu lintas pagi hari.

# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0,
    "DisableScaleIn": false
  }'

# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name api-asg \
  --scheduled-action-name morning-scale-out \
  --recurrence '0 8 * * MON-FRI' \
  --min-size 5

Skenario 4: Failover Route 53 ke Situs DR

Skenario: Sebuah perusahaan menjalankan Application web Primary di us-east-1 dan ingin melakukan failover ke halaman pemeliharaan statis yang di-host di S3 pada us-west-2 jika Primary menjadi tidak sehat. Solusi: Buat health check Route 53 yang memantau titik akhir ALB Primary. Buat dua catatan Route 53 dengan kebijakan perutean failover: catatan Primary yang mengarah ke ALB (terkait dengan health check), dan catatan Secondary yang mengarah ke situs statis S3. Jika health check gagal, Route 53 akan menyajikan respons DNS dari catatan Secondary secara otomatis.

# Create Route 53 health check for primary ALB
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails

Skenario 5: Pemisahan dengan SQS untuk Ketangguhan

Skenario: Backend pemrosesan pesanan menulis ke Database, tetapi Database terkadang tidak tersedia selama jendela pemeliharaan sehingga pesanan hilang. Solusi: Tempatkan Queue SQS di antara Frontend (yang menerima pesanan) dan Backend (yang memprosesnya). Pesanan langsung dimasukkan ke Queue sehingga pelanggan segera menerima konfirmasi. Pekerja latar belakang mengambil pesanan dari Queue dan memprosesnya saat Database tersedia. Selama pemeliharaan, pesanan akan mengantre dan tidak dibuang—sehingga ketangguhan tercapai melalui pemisahan asinkron.

# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --message-body '{"orderId": "ORD-123", "items": [...]}'

# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --max-number-of-messages 10

# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)

Skenario 6: Pilot Light DR

Skenario: Sebuah perusahaan memerlukan solusi pemulihan bencana dengan RPO 1 jam dan RTO 4 jam dengan anggaran sedang. Solusi: Terapkan strategi DR Pilot Light. Pertahankan replikasi Database inti ke DR Region menggunakan RDS Cross-Region Read Replica. Server Application tidak berjalan di DR Region selama operasi normal—hanya 'inti' minimum (Database) yang tetap siap. Saat terjadi bencana, promosikan Read Replica menjadi mandiri dan luncurkan server Application dari AMIs yang telah dibuat sebelumnya menggunakan CloudFormation. RTO berlangsung dalam hitungan jam, bukan menit, karena server harus diluncurkan.

# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --source-region us-east-1 \
  --destination-region us-west-2

# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2

Skenario 7: Dead-Letter Queue SQS untuk Pesan yang Gagal

Skenario: Pesan pada Queue SQS berulang kali gagal diproses karena bug pada Lambda konsumen. Pesan terus muncul kembali dan memblokir Queue. Solusi: Konfigurasikan Dead-Letter Queue (DLQ) pada Queue utama. Setelah pesan gagal diproses sebanyak jumlah yang dapat dikonfigurasi (maxReceiveCount), SQS secara otomatis memindahkannya ke DLQ, bukan mengirimkannya kembali tanpa batas. Ini membebaskan Queue utama agar dapat memproses pesan yang sehat. Atur alarm CloudWatch pada metrik DLQ ApproximateNumberOfMessagesVisible untuk memberi tahu tim teknik saat pesan menumpuk di DLQ.

# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
  }'

# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
  --alarm-name orders-dlq-depth \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --dimensions Name=QueueName,Value=orders-dlq \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --period 60 --statistic Sum

Skenario 8: Aurora Global Database

Skenario: Sebuah perusahaan beroperasi di US dan Eropa. Pengguna di Eropa mengalami latensi baca Database yang tinggi karena RDS berada di us-east-1. Solusi: Gunakan Amazon Aurora Global Database. Cluster Primary berada di us-east-1; cluster Secondary hanya-baca ditambahkan di eu-west-1. Aurora mereplikasi data ke Region Secondary dengan latensi umum di bawah 1 detik menggunakan replikasi tingkat penyimpanan. Pengguna Eropa membaca dari cluster Secondary di eu-west-1. Jika terjadi bencana regional, Secondary dapat dipromosikan menjadi Primary dalam waktu kurang dari 1 menit (RTO terbaik di antara opsi DB multi-region AWS).

# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora

# Add secondary Region cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora-eu \
  --engine aurora-postgresql \
  --global-cluster-identifier prod-global \
  --region eu-west-1

Skenario 9: Layanan ECS dengan ALB dan Auto Scaling

Skenario: Layanan API dalam kontainer yang berjalan di ECS Fargate perlu diskalakan berdasarkan penggunaan CPU dan tetap beroperasi saat terjadi kegagalan AZ. Solusi: Daftarkan layanan ECS ke grup target Application Load Balancer agar lalu lintas didistribusikan ke seluruh tugas yang berjalan. Tempatkan tugas di beberapa AZ dengan menentukan beberapa subnet dalam konfigurasi layanan. Konfigurasikan Auto Scaling Layanan ECS dengan kebijakan Target Tracking pada penggunaan CPU layanan ECS untuk menaikkan dan menurunkan jumlah tugas secara otomatis. Jika sebuah AZ gagal, ECS akan memulai ulang tugas yang gagal di AZ yang sehat.

# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
  --cluster prod-cluster \
  --service-name api-service \
  --task-definition api-task:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
      "securityGroups": ["sg-app"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:...:targetgroup/api-tg/abc",
    "containerName": "api",
    "containerPort": 8080
  }]'

Skenario 10: Failover Health Check dengan Route 53

Skenario: Sebuah perusahaan menjalankan dua instance EC2 di AZ yang berbeda untuk melayani domain yang sama. Mereka ingin Route 53 berhenti mengirimkan lalu lintas ke instance yang tidak sehat secara otomatis. Solusi: Gunakan Weighted Routing Route 53 dengan bobot yang sama (50/50), lalu kaitkan health check titik akhir dengan setiap catatan. Saat Route 53 mendeteksi titik akhir yang tidak sehat, Route 53 menghapus catatan tersebut dari respons DNS dan mengirimkan 100% lalu lintas ke titik akhir yang sehat. Saat instance pulih dan health check kembali berhasil, Route 53 menyeimbangkan ulang lalu lintas secara otomatis—tanpa memerlukan perubahan DNS manual.

# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "instance-1a",
        "Weight": 50,
        "HealthCheckId": "hc-abc123",
        "TTL": 30,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

Skenario 11: DynamoDB Global Tables untuk HA Multi-Region

Skenario: Application permainan seluler memerlukan data pemain yang dapat dibaca dan ditulis dengan latensi rendah dari us-east-1 maupun ap-southeast-1. Satu Table DynamoDB dalam satu Region menyebabkan latensi tinggi bagi pengguna Asia. Solusi: Aktifkan DynamoDB Global Tables. Global Tables secara otomatis mereplikasi data ke seluruh Region yang ditentukan menggunakan replikasi multi-master—Region mana pun dapat menerima operasi tulis. Pengguna Asia menulis dan membaca dari Replica ap-southeast-1 dengan latensi lokal (~5ms). Global Tables menangani resolusi konflik menggunakan strategi 'penulis terakhir menang' berdasarkan stempel waktu. RTO untuk kegagalan regional penuh mendekati nol—lalu lintas cukup diarahkan ke Region yang masih bertahan.

# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
  --global-table-name PlayerData \
  --replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'

# Add another Region to an existing Global Table
aws dynamodb update-global-table \
  --global-table-name PlayerData \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

Pemeriksaan Cepat

Uji pemahaman Anda tentang konsep AWS Solutions Architect (SAA-C03) dari pelajaran ini.

Ringkasan Pelajaran

Dalam pelajaran ini, Anda mempelajari berbagai skenario yang mencakup: Multi-AZ ASG dan RDS untuk HA dalam satu Region, perutean failover Route 53 untuk DR lintas-Region, SQS DLQ untuk mengisolasi pesan yang gagal tanpa memblokir Queue, serta Aurora Global Database untuk penskalaan baca lintas-Region dan failover dengan RTO kurang dari satu menit. Selanjutnya, kita akan membahas skenario arsitektur berperforma tinggi dan berbiaya optimal.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Skenario Arsitektur Tangguh dan Berketersediaan Tinggi” gratis?

Ya — teks lengkap “Skenario Arsitektur Tangguh dan Berketersediaan Tinggi” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus AWS Solutions Architect, upgrade ke CoddyKit PRO. Kursus AWS Solutions Architect mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Skenario Arsitektur Tangguh dan Berketersediaan Tinggi”?

Hadapi skenario pengalihan basis data Multi-AZ, penskalaan otomatis saat lalu lintas melonjak, dan pengalihan berdasarkan pemeriksaan kesehatan Route 53 untuk memperkuat konsep keandalan. Kamu berlatih AWS Solutions Architect dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai AWS Solutions Architect?

Tidak diperlukan pengalaman sebelumnya. AWS Solutions Architect di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 2 dari 4.

Berapa lama pelajaran “Skenario Arsitektur Tangguh dan Berketersediaan Tinggi” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran AWS Solutions Architect ini?

Ya. Setiap pelajaran AWS Solutions Architect menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

Skenario Arsitektur Aman
Skenario Arsitektur Tangguh dan Berketersediaan Tinggi
Skenario Kinerja Tinggi dan Teroptimasi Biaya
Ujian Mini Lengkap Lintas Domain

← Kembali ke AWS Solutions Architect