Dari Alibaba Cloud ke AWS: Catatan Migrasi dengan AWS MGN

April 11, 2026 · 8 min read

Catatan migrasi server dari Alibaba Cloud ke AWS menggunakan AWS MGN — pengalaman nyata, lesson learned, dan tips.

Kalau kamu pernah mengelola infrastruktur di Alibaba Cloud dan tiba-tiba dapat mandat untuk migrasi ke AWS, kamu tahu rasanya — campuran antara excited, overwhelmed, dan “harus mulai dari mana ini?”

Itulah yang aku hadapi. Beberapa server production dan staging berjalan di Alibaba Cloud ECS, dan karena pertimbangan bisnis, semuanya perlu dipindahkan ke AWS tanpa downtime yang panjang. AWS menyediakan tool khusus untuk ini: Application Migration Service alias AWS MGN.

Post ini bukan step-by-step official tutorial — dokumentasi AWS sudah cukup lengkap untuk itu. Ini lebih ke catatan lapangan: apa yang aku temui, keputusan teknis yang aku buat, dan hal-hal yang mungkin belum kamu baca di docs.

ℹ️ Info: AWS MGN (Application Migration Service) adalah evolusi dari CloudEndure Migration. Sebelum mulai, pastikan kamu sudah familiar dengan konsep dasar replication dan lift-and-shift migration.

Kondisi Awal: Infrastruktur di Alibaba Cloud

Setup di Alibaba Cloud sebelum migrasi kurang lebih seperti ini:

ECS instances (beberapa dengan OS Ubuntu 20.04, ada juga CentOS)
RDS for PostgreSQL (ini tidak migrasi via MGN — handled separately)
OSS (Object Storage) untuk static assets
SLB (Server Load Balancer) sebagai entry point
VPC dengan multiple security groups

Yang akan dimigrasi via MGN: ECS instances (compute). Database dan storage punya jalur migrasi tersendiri.

⚠️ Penting: MGN cocok untuk lift-and-shift server (OS + aplikasi). Jangan ekspektasikan MGN bisa sekalian migrasi managed services seperti RDS atau object storage — itu perlu pendekatan berbeda.

Cara Kerja AWS MGN (Singkat)

Sebelum terjun ke proses, penting untuk paham mekanisme MGN:

Phase	Yang Terjadi
1. Install Agent	AWS Replication Agent dipasang di source server (Alibaba ECS). Agent ini yang akan handle replikasi data.
2. Initial Sync	MGN melakukan replikasi awal semua data disk ke Replication Server di AWS (berjalan di background, tidak ganggu production).
3. Continuous Replication	Setelah initial sync selesai, MGN terus mereplikasi perubahan secara real-time (lag biasanya < 1 menit).
4. Test Cutover	Kamu bisa launch instance test tanpa ganggu source server. Validasi aplikasi berjalan normal di AWS.
5. Cutover	Launch instance final di AWS, DNS/routing dipindah, source server dibiarkan jalan sebentar sebagai fallback.

Yang menarik: proses ini non-destructive. Source server tetap jalan sampai kamu yakin AWS instance sudah siap.

Setup: Apa yang Perlu Disiapkan

Prerequisites

AWS account dengan IAM user/role yang punya akses ke MGN service
Network connectivity antara Alibaba ECS dan AWS (bisa via internet atau dedicated connection)
Port 443 (HTTPS) dan port 1500 (TCP) harus bisa reach AWS MGN endpoints dari source server
OS yang didukung: sebagian besar Linux distro modern dan Windows Server

Inisialisasi MGN Service

Pertama, initialize MGN di AWS Console atau via CLI:

bashCopy
# Pastikan region sudah benar
aws mgn initialize-service --region ap-southeast-1

# Cek status
aws mgn describe-source-servers --region ap-southeast-1

Setelah service diinisialisasi, kamu akan dapat Replication Settings Template — ini yang menentukan tipe instance dan konfigurasi Replication Server.

Replication Server Configuration

Ini salah satu keputusan penting yang sering dilewatin: pilihan instance type untuk Replication Server sangat mempengaruhi kecepatan initial sync.

⚠️ Lesson learned: Aku sempat pakai t3.small untuk Replication Server karena “irit”. Hasilnya, initial sync untuk server 100GB butuh hampir 18 jam. Setelah upgrade ke t3.large, turun jadi ~6 jam. Replication Server ini hanya aktif saat sync, jadi cost-nya relatif kecil.

Install AWS Replication Agent

Di source server (Alibaba ECS), download dan install agent:

bashCopy
# Download agent installer
wget -O ./aws-replication-installer-init.py \
  https://aws-application-migration-service-<region>.s3.<region>.amazonaws.com/latest/linux/aws-replication-installer-init.py

# Install agent
sudo python3 aws-replication-installer-init.py \
  --region ap-southeast-1 \
  --aws-access-key-id <ACCESS_KEY> \
  --aws-secret-access-key <SECRET_KEY> \
  --no-prompt

Setelah agent berhasil install, server akan muncul di MGN Console dengan status Stopped (initial sync belum mulai), lalu berubah jadi Not ready dan akhirnya Healthy saat replikasi berjalan.

✅ Best practice: Gunakan dedicated IAM user untuk MGN agent dengan policy AWSApplicationMigrationAgentPolicy. Jangan pakai root credentials atau admin user. Prinsip least privilege berlaku di sini.

Verifikasi Koneksi

bashCopy
# Cek apakah port 443 dan 1500 reachable dari source server
nc -zv mgn.ap-southeast-1.amazonaws.com 443
nc -zv <replication-server-ip> 1500

# Cek status agent
sudo systemctl status aws-replication-agent

Launch Settings: Menentukan Target Instance

Sebelum cutover, kamu perlu konfigurasi Launch Settings di MGN Console untuk setiap source server:

Setting	Rekomendasi	Catatan
Instance Type	Match atau lebih dari source	Bisa diubah setelah launch jika perlu
VPC & Subnet	Subnet private, bukan public	Sesuaikan dengan arsitektur target
Security Groups	Buat baru khusus migrated instances	Jangan copy paste dari source sembarangan
EBS Volume Type	gp3 (bukan gp2)	Lebih murah, performa lebih predictable
IAM Instance Profile	Assign sesuai kebutuhan aplikasi	Jangan lupa ini — sering kelupaan

Untuk EBS, aku konsisten pakai gp3 dengan throughput 125 MB/s (default). Untuk database server yang ikut dimigrasi (sebelum dipindahkan ke RDS), aku naikkan ke 250 MB/s.

Test Cutover: Validasi Sebelum yang Beneran

Ini fase yang paling underrated. Banyak orang skip test cutover karena “males” atau “nanti aja”. Jangan.

Test cutover meluncurkan instance baru di AWS dari state replikasi terkini, tapi source server tetap jalan. Kamu bisa masuk ke instance test dan validasi:

Aplikasi bisa start dengan normal
Koneksi ke database berjalan
Environment variables dan config files masih intact
Dependencies sistem (packages, libraries) semuanya ada
Cron jobs dan systemd services terkonfigurasi dengan benar

✅ Tip: Aku menemukan beberapa server punya hardcoded IP di config file yang mengarah ke Alibaba internal IP. Ini ketahuan saat test cutover — bukan saat production cutover. Sangat worth the time.

Yang Sering Ditemukan Saat Test Cutover

Dari pengalamanku, ini yang paling sering jadi masalah:

/etc/hosts entries yang masih pointing ke Alibaba internal IP
Application config yang hardcode hostname/IP internal
SSH keys dan authorized_keys perlu update
Timezone mismatch (Alibaba default ke Asia/Shanghai)
NTP server config yang masih ke Alibaba NTP

bashCopy
# Fix timezone setelah cutover
sudo timedatectl set-timezone Asia/Jakarta

# Verifikasi NTP sync
timedatectl status

# Cari config yang masih pakai IP internal Alibaba
grep -r "10.0." /etc/
grep -r "100.64." /etc/

Cutover Plan: Eksekusi dengan Tenang

Ini runbook cutover yang aku pakai:

Konfirmasi lag replikasi < 1 menit di MGN Console sebelum memulai
Notify stakeholder — set maintenance window
Stop traffic ke source server (update load balancer / turunkan DNS TTL dulu)
Tunggu final sync selesai (biasanya 2–5 menit)
Launch cutover instance di MGN
Jalankan smoke test di instance baru
Update routing (ALB target group / DNS)
Monitor selama 30–60 menit sebelum finalize cutover di MGN
Biarkan source server standby 24–48 jam sebelum terminate

✅ DNS TTL: Lowerin ke 60 detik setidaknya 1 jam sebelum cutover. Ini mengurangi downtime akibat DNS propagation saat kamu switch IP.

Post-Migration: Yang Sering Dilupakan

Cutover berhasil bukan berarti migrasi selesai.

Cleanup

Hapus AWS Replication Agent dari instance (tidak lagi diperlukan setelah cutover final)
Terminate Replication Servers yang sudah tidak aktif
Finalize cutover di MGN Console untuk setiap source server
Review dan hapus IAM user yang digunakan untuk MGN agent

Optimasi Instance

Saat lift-and-shift, instance type yang dipilih biasanya berdasarkan “match dengan source”. Setelah berjalan beberapa hari, aku review actual resource usage dengan AWS Compute Optimizer atau CloudWatch metrics. Dari situ berhasil right-size beberapa instance dan hemat ~20% dari compute cost.

Security Hardening

Review Security Groups — MGN sering menambah rules yang terlalu permissive
Enable AWS Inspector untuk vulnerability scanning
Pastikan semua instance pakai IMDSv2 (tidak IMDSv1)
Review IAM instance profiles

bashCopy
# Enforce IMDSv2 pada instance yang sudah berjalan
aws ec2 modify-instance-metadata-options \
  --instance-id i-xxxxxxxxxx \
  --http-tokens required \
  --region ap-southeast-1

Lesson Learned

Area	Apa yang Terjadi	Lesson
Replication Server sizing	Pakai instance kecil → initial sync lama banget	Sizing yang proper = waktu lebih singkat, cost selisih tipis
Network path	Traffic replikasi lewat internet, lambat di jam sibuk	Pertimbangkan bandwidth ke AWS saat scheduling initial sync
Config hardcoded	Ketemu IP Alibaba internal di beberapa config	Selalu grep config files sebelum cutover
Database timing	Database dicoba ikut MGN, bermasalah	Pisahkan migrasi DB — gunakan pg_dump, DMS, atau pglogical
Test cutover	Skip di awal karena “ribet”, akhirnya nyesel	Test cutover itu wajib, bukan opsional
DNS TTL	TTL masih tinggi (3600s) saat cutover → delay	Lowerin DNS TTL jauh-jauh hari sebelum cutover

Penutup

AWS MGN adalah tool yang solid untuk lift-and-shift migration. Non-destructive, relatively straightforward, dan documentation-nya cukup baik. Tapi seperti tool lainnya, hasilnya sangat bergantung pada seberapa matang persiapan dan execution plan-mu.

Hal yang paling aku syukuri: tidak langsung cutover production. Test cutover yang aku anggap “membuang waktu” ternyata yang paling banyak menyelamatkan dari masalah yang bisa panjang urusannya.

Kalau kamu sedang planning migrasi serupa dan punya pertanyaan spesifik, feel free untuk reach out.

Referensi:

AWS MGN Documentation
AWS Compute Optimizer
IAM Policy untuk MGN Agent: AWSApplicationMigrationAgentPolicy

#AWS #Migration #Cloud

Comments