Menjalankan Script Otomatis saat EC2 Pertama Kali Menyala: Panduan User Data

Saat pertama kali deploy EC2, banyak engineer menghabiskan waktu untuk SSH ke instance baru lalu mengetik apt install nginx secara manual — padahal AWS sudah menyediakan mekanisme bernama User Data yang menjalankan shell script secara otomatis saat instance pertama kali boot. Artikel ini menjelaskan cara kerjanya, di mana menempatkan script-nya, dan jebakan umum yang membuat script tidak berjalan sama sekali.

TL;DR: Cara Cepat Install Nginx via EC2 User Data

Langkah	Detail
1. Buka EC2 Launch Wizard	AWS Console → EC2 → Launch Instance
2. Scroll ke bagian 'Advanced Details'	Bagian paling bawah form konfigurasi instance
3. Temukan field 'User Data'	Input box teks, pilih 'As text'
4. Paste shell script	Harus diawali dengan `#!/bin/bash`
5. Launch instance	Script berjalan sekali saat first boot sebagai root

Bagaimana EC2 User Data Bekerja

User Data adalah mekanisme cloud-init yang disediakan AWS untuk menjalankan instruksi otomatis saat instance pertama kali diluncurkan. Instance mengambil script dari endpoint metadata internal AWS (http://169.254.169.254/latest/user-data), lalu cloud-init mengeksekusinya sebagai root pada fase boot awal — sebelum instance benar-benar siap menerima koneksi SSH.

Penting dipahami: secara default, User Data hanya berjalan sekali saat first boot. Jika instance di-stop lalu di-start ulang, script tidak otomatis dijalankan kembali kecuali konfigurasi cloud-init diubah secara eksplisit. Ini bukan bug — ini desain yang disengaja agar operasi idempoten tidak perlu diproteksi dari eksekusi berulang.

graph TD A["EC2 Instance Launch"] --> B["cloud-init Starts"] B --> C["Fetch User Data dari Metadata Endpoint"] C --> D{"User Data Ada?"} D -- "Ya" --> E["Eksekusi Shell Script sebagai root"] D -- "Tidak" --> G["Instance Ready"] E --> F["Output ditulis ke /var/log/cloud-init-output.log"] F --> G G --> H["Instance Running"] H --> I["Reboot / Stop-Start"] I --> J["cloud-init Cek Status"] J --> K["Script TIDAK dijalankan ulang (default behavior)"]

Instance Launch: EC2 instance baru dibuat dari AMI yang dipilih.
cloud-init fetch: Proses cloud-init berjalan dan mengambil User Data dari endpoint metadata AWS.
Script Execution: Shell script dieksekusi sebagai root. Output ditulis ke log cloud-init.
Instance Ready: Setelah script selesai, instance masuk status running dan siap menerima traffic.
Subsequent Reboots: Pada reboot berikutnya, cloud-init tidak mengeksekusi User Data lagi (default behavior).

Di Mana Menempatkan Script User Data di AWS Console

Ini pertanyaan yang sering membingungkan karena lokasinya tersembunyi di dalam tab 'Advanced Details' yang sering dilewati begitu saja.

Langkah-langkah di AWS Console:

Buka EC2 Console → klik Launch Instance.
Isi Name, pilih AMI (misalnya Amazon Linux 2023 atau Ubuntu 22.04), pilih instance type.
Konfigurasi Key Pair dan Network Settings sesuai kebutuhan.
Scroll ke bawah hingga menemukan bagian Advanced Details — klik untuk expand.
Scroll ke paling bawah bagian Advanced Details hingga menemukan field User Data.
Pastikan opsi 'As text' dipilih (bukan 'As file').
Paste script shell Anda di dalam kotak teks tersebut.
Klik Launch Instance.

Bayangkan User Data seperti catatan instruksi yang ditempel di dalam kardus server baru. Teknisi (cloud-init) membaca catatan itu tepat satu kali saat kardus pertama dibuka, lalu membuangnya. Kalau server dinyalakan ulang, catatan sudah tidak ada — server berjalan apa adanya.

Script User Data untuk Install Nginx: Amazon Linux 2023

Berikut script yang sudah diuji untuk Amazon Linux 2023. Perhatikan bahwa package manager dan nama service berbeda antara distribusi — jangan copy-paste script Ubuntu ke Amazon Linux tanpa modifikasi.

#!/bin/bash
# User Data script untuk Amazon Linux 2023
# Dieksekusi sebagai root saat first boot

# Update semua package yang terinstall
dnf update -y

# Install Nginx
dnf install -y nginx

# Aktifkan Nginx agar otomatis start saat reboot
systemctl enable nginx

# Jalankan Nginx sekarang
systemctl start nginx

# Verifikasi status (output masuk ke log cloud-init)
systemctl status nginx

Script User Data untuk Install Nginx: Ubuntu 22.04 / 24.04

Untuk Ubuntu, package manager yang digunakan adalah apt. Satu detail yang sering terlewat: tambahkan DEBIAN_FRONTEND=noninteractive agar proses instalasi tidak menunggu input interaktif yang tidak akan pernah datang di environment non-TTY.

#!/bin/bash
# User Data script untuk Ubuntu 22.04 / 24.04
# Dieksekusi sebagai root saat first boot

export DEBIAN_FRONTEND=noninteractive

# Update package index
apt-get update -y

# Install Nginx
apt-get install -y nginx

# Aktifkan Nginx agar otomatis start saat reboot
systemctl enable nginx

# Jalankan Nginx
systemctl start nginx

# Verifikasi status
systemctl status nginx

Menjalankan User Data via AWS CLI

Jika instance diluncurkan via CLI — misalnya dalam pipeline otomasi atau Infrastructure as Code sederhana — User Data dikirim sebagai parameter --user-data. AWS CLI mengharapkan konten dalam format file atau string yang di-encode Base64 secara otomatis.

aws ec2 run-instances \
  --image-id ami-0c02fb55956c7d316 \
  --instance-type t3.micro \
  --key-name nama-key-pair-anda \
  --security-group-ids sg-0123456789abcdef0 \
  --subnet-id subnet-0123456789abcdef0 \
  --user-data file://userdata.sh \
  --region us-east-1

Simpan script Nginx di atas ke file bernama userdata.sh, lalu jalankan perintah tersebut. AWS CLI akan membaca file dan mengirimkannya sebagai User Data. Ganti nilai --image-id, --key-name, --security-group-ids, dan --subnet-id sesuai environment Anda.

Memverifikasi Eksekusi Script: Jangan Tebak, Baca Log-nya

Ini bagian yang paling sering dilewati — dan paling sering menjadi sumber frustrasi. Script User Data tidak memberikan feedback visual di console. Satu-satunya cara mengetahui apakah script berhasil atau gagal adalah dengan membaca log cloud-init langsung dari instance.

Setelah instance running, SSH ke instance dan jalankan:

# Lihat log eksekusi cloud-init secara keseluruhan
sudo cat /var/log/cloud-init-output.log

# Atau ikuti log secara real-time saat instance baru saja boot
sudo tail -f /var/log/cloud-init-output.log

Log ini mencatat seluruh output dari script Anda — termasuk error. Jika Nginx gagal install karena typo di nama package atau koneksi internet tidak tersedia, error-nya ada di sini.

Untuk melihat status cloud-init secara keseluruhan:

sudo cloud-init status --long

Melihat User Data yang Sudah Terpasang di Instance

Untuk memverifikasi User Data apa yang terpasang di instance yang sudah berjalan — berguna saat debugging instance yang dibuat orang lain:

# Dari dalam instance, akses metadata endpoint
curl http://169.254.169.254/latest/user-data

Atau via AWS CLI dari luar instance:

aws ec2 describe-instance-attribute \
  --instance-id i-0123456789abcdef0 \
  --attribute userData \
  --region us-east-1 \
  --query 'UserData.Value' \
  --output text | base64 --decode

Output dikembalikan dalam format Base64 — pipe ke base64 --decode untuk membaca isinya.

Pengalaman Lapangan: Script Jalan, Nginx Tidak Aktif

Ini pola yang cukup sering terjadi: cloud-init melaporkan sukses, instance running, tapi Nginx tidak merespons di port 80. Asumsi pertama biasanya 'script-nya salah' — padahal script berjalan sempurna.

Penyebab sebenarnya hampir selalu di dua tempat:

Security Group tidak membuka port 80. Script berhasil install dan start Nginx, tapi inbound rule Security Group hanya mengizinkan port 22 (SSH). Nginx berjalan di dalam instance, tapi traffic dari luar diblokir di layer firewall AWS. Verifikasi dengan:
```
aws ec2 describe-security-groups \
  --group-ids sg-0123456789abcdef0 \
  --region us-east-1 \
  --query 'SecurityGroups[*].IpPermissions'
```
Race condition antara dnf/apt update dan network availability. Pada beberapa konfigurasi, cloud-init mengeksekusi User Data sebelum interface jaringan sepenuhnya siap menerima koneksi keluar. Akibatnya, dnf update atau apt-get update gagal karena tidak bisa mencapai repository, dan eksekusi script berhenti di situ. Tambahkan retry sederhana atau cek koneksi di awal script jika ini terjadi di environment Anda.

Insight yang sering terlewat: Security Group adalah layer pertama yang harus dicek, bukan script-nya.

graph TD A["Nginx tidak bisa diakses"] --> B{"Nginx running di instance?"} B -- "Tidak" --> C["Baca log: /var/log/cloud-init-output.log"] C --> D{"Ada error di log?"} D -- "Error koneksi repository" --> E["Race condition jaringan Tambahkan retry di script"] D -- "Error lainnya" --> F["Perbaiki script dan re-launch instance"] B -- "Ya" --> G{"Port 80 terbuka di Security Group?"} G -- "Tidak" --> H["Tambahkan inbound rule port 80 di Security Group"] G -- "Ya" --> I["Cek Network ACL dan routing table"]

Nginx Running? Cek dengan systemctl status nginx dari dalam instance via SSH.
Port 80 Terbuka di SG? Jika Nginx running tapi tidak bisa diakses dari luar, masalah ada di Security Group inbound rules.
Script Error? Jika Nginx tidak running, baca /var/log/cloud-init-output.log untuk menemukan baris error.
Network Ready saat Boot? Jika log menunjukkan error koneksi ke repository, ini race condition jaringan — tambahkan mekanisme retry.

IAM Instance Profile: Kapan Dibutuhkan

Script User Data sederhana untuk install Nginx tidak memerlukan IAM Instance Profile. Namun jika script Anda perlu mengakses layanan AWS lain — misalnya mengambil konfigurasi dari S3 atau mengambil secret dari AWS Secrets Manager — instance harus memiliki IAM Instance Profile dengan permission yang sesuai.

Contoh policy minimal jika script perlu mengambil file konfigurasi dari S3:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::nama-bucket-anda/config/*"
    }
  ]
}

Attach policy ini ke IAM Role, lalu assign Role tersebut sebagai Instance Profile saat launch. Tanpa ini, perintah aws s3 cp di dalam User Data script akan gagal dengan error credentials.

Menjalankan User Data Kembali di Instance yang Sudah Ada

Secara default, User Data hanya berjalan saat first boot. Untuk memaksa cloud-init menjalankan ulang User Data di instance yang sudah berjalan — misalnya untuk testing — reset status cloud-init terlebih dahulu:

🔽 Klik untuk expand: Cara reset dan jalankan ulang cloud-init

# Untuk Amazon Linux 2023 / RHEL-based
# Hapus semua artefak cloud-init agar dianggap 'fresh'
sudo cloud-init clean --logs

# Reboot instance — cloud-init akan menjalankan User Data lagi
sudo reboot

# Alternatif: jalankan langsung tanpa reboot (untuk testing)
sudo cloud-init init
sudo cloud-init modules --mode=config
sudo cloud-init modules --mode=final

Peringatan: Perintah cloud-init clean menghapus semua state cloud-init termasuk konfigurasi yang mungkin sudah diaplikasikan. Gunakan hanya di environment testing, bukan di instance produksi.

Wrap-Up dan Langkah Selanjutnya

EC2 User Data adalah cara paling langsung untuk mengotomasi konfigurasi instance saat pertama kali boot — tanpa perlu tool tambahan untuk kasus sederhana seperti install Nginx. Kunci keberhasilannya ada di tiga hal: script diawali #!/bin/bash, Security Group membuka port yang dibutuhkan, dan log cloud-init selalu dibaca saat debugging.

Untuk kebutuhan yang lebih kompleks — multiple instance, konfigurasi yang sering berubah, atau manajemen state yang lebih ketat — pertimbangkan untuk beralih ke AWS Systems Manager Run Command, atau tool Infrastructure as Code seperti Terraform dan AWS CloudFormation yang menyediakan abstraksi lebih baik di atas User Data.

Referensi resmi: AWS EC2 User Guide — Run commands on your Linux instance at launch.

Glosarium Istilah Kunci

Istilah	Penjelasan
User Data	Script atau instruksi yang dikirim ke EC2 instance untuk dieksekusi otomatis saat first boot melalui mekanisme cloud-init.
cloud-init	Tool standar industri untuk inisialisasi cloud instance. Bertanggung jawab mengambil dan mengeksekusi User Data di EC2.
Instance Metadata Service (IMDS)	Endpoint internal AWS di `169.254.169.254` yang menyediakan informasi tentang instance, termasuk User Data.
IAM Instance Profile	Container untuk IAM Role yang di-attach ke EC2 instance, memberikan permission untuk mengakses layanan AWS lain.
Security Group	Firewall virtual di level instance yang mengontrol traffic inbound dan outbound berdasarkan aturan port dan protokol.

📄 Cara Mendapatkan Instance ID EC2 via Metadata: IMDSv2 vs IMDSv1

Cari Blog Ini

SW BBANG I