Cara Setup AWS Systems Manager (SSM) untuk Akses EC2 dari Personal PC Tanpa SSH

Memahami AWS SSM Session Manager: Akses EC2 Tanpa SSH

AWS Systems Manager Session Manager (sering disebut “SSM”) adalah cara resmi dari AWS untuk membuka sesi shell ke instance (Linux/Windows) melalui channel yang aman dan terintegrasi dengan IAM. Berbeda dengan SSH tradisional, Session Manager tidak membutuhkan port inbound di Security Group, tidak butuh key pair, dan dapat berjalan meskipun instance berada di private subnet tanpa public IP—selama instance bisa menjangkau endpoint SSM. Dari sisi arsitektur, alurnya seperti ini: Personal PC → AWS CLI/Console → SSM API → SSM Agent di EC2 → Shell Session Pada praktiknya, ini memberi beberapa manfaat besar:

✅ Tidak perlu membuka inbound 22/tcp.
✅ Tidak perlu mengelola SSH key di banyak server.
✅ Akses bisa dibatasi granular dengan IAM (per instance/tag).
✅ Aktivitas sesi bisa di-audit (CloudTrail) dan direkam (S3/CloudWatch Logs).
✅ Cocok untuk organisasi yang mengejar “zero trust access”.

Kenapa SSM Lebih Aman dan Lebih Nyaman daripada SSH

SSH bukan “buruk”, tetapi sering menjadi sumber risiko operasional jika dipakai tanpa disiplin. Banyak tim membuka port SSH ke internet (bahkan hanya ke IP kantor), menyimpan private key di laptop, dan membuat akses server bergantung pada key yang jarang diputar. Selain itu, audit siapa melakukan apa sering tidak rapi. SSM memperbaiki pola ini dengan memindahkan kontrol akses ke IAM dan memaksa akses lewat jalur yang ter-enkripsi serta ter-audit. Anda bisa membuat rule: hanya role tertentu yang boleh “StartSession” ke instance yang bertag Environment=Prod, misalnya, dan sesi bisa Anda log.

⚠️ Perhatian: SSM bukan solusi “tanpa network sama sekali”. EC2 tetap perlu jalur keluar (VPC endpoint atau NAT) untuk berkomunikasi dengan layanan SSM.

Arsitektur Contoh Kasus: Personal PC → AWS SSM → EC2

Pada contoh kasus ini, asumsi yang digunakan:

Anda punya 1 akun AWS dan akses IAM administrator (minimal untuk setup awal).
Anda punya 1 instance EC2 Linux (Amazon Linux 2/2023 atau Ubuntu).
Instance idealnya berada di private subnet (tanpa public IP), tetapi SSM juga bisa untuk public subnet.
Anda ingin: dari personal PC, cukup pakai AWS CLI atau Console untuk masuk shell.

Ada dua opsi konektivitas dari EC2 ke SSM:

Opsi	Kebutuhan Network	Kelebihan	Kekurangan
NAT Gateway / Internet Gateway	Outbound internet	Setup cepat	Biaya NAT (kalau private subnet)
VPC Interface Endpoints (PrivateLink)	Tanpa internet	Lebih aman, private routing	Setup lebih banyak, ada biaya endpoint

Jika tujuan Anda benar-benar “private-only”, VPC endpoints adalah opsi terbaik.

Prasyarat yang Wajib Disiapkan

Sebelum mulai implementasi, pastikan komponen berikut tersedia:

IAM Role untuk EC2 yang punya permission Systems Manager.
SSM Agent aktif di instance.
Network path dari instance ke service SSM (via NAT atau VPC endpoints).
Permission IAM di user/role Anda untuk memulai session.
AWS CLI + Session Manager Plugin di personal PC (untuk start session lewat terminal).

💡 Tips Pro: Kalau Anda memakai Amazon Linux 2/2023, SSM Agent biasanya sudah terpasang. Namun statusnya tetap perlu dicek.

Langkah 1: Buat/Assign IAM Role untuk EC2 (Instance Profile)

Agar EC2 bisa “mendaftar” dan menerima instruksi dari Systems Manager, instance harus memiliki IAM role.

Role minimal yang direkomendasikan

AWS menyediakan policy managed yang paling umum:

AmazonSSMManagedInstanceCore

Langkah konfigurasi (konseptual):

Buka IAM → Roles → Create role.
Pilih Trusted entity: EC2.
Attach policy AmazonSSMManagedInstanceCore.
Buat role, misalnya: EC2Role-SSMManaged.
Assign ke instance: EC2 → Instances → (pilih instance) → Security → Modify IAM role.

✅ Best Practice: Gunakan naming yang konsisten dan batasi scope policy tambahan. Untuk kebutuhan dasar Session Manager, policy di atas sudah cukup.

Langkah 2: Pastikan SSM Agent Terpasang dan Running di EC2

Cek status SSM Agent (Linux)

Secara konsep, Anda perlu memastikan service amazon-ssm-agent berjalan. Contoh command (jika Anda masih punya akses awal via EC2 console/SSH sementara):

systemctl status amazon-ssm-agent

Jika belum berjalan:

sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

Untuk distro tertentu, instalasi bisa berbeda, tetapi idenya sama: pastikan agent aktif.

⚠️ Perhatian: Jika instance Anda benar-benar private dan belum punya jalur internet/VPC endpoint, agent tidak akan bisa “register” ke Systems Manager walaupun statusnya running.

Langkah 3: Siapkan Network Agar EC2 Bisa Mengakses Endpoint SSM

Ini bagian yang paling sering membuat SSM “tidak muncul” di Systems Manager.

Opsi A — Pakai NAT (lebih cepat untuk lab)

Jika instance ada di private subnet, pastikan route table private subnet punya default route 0.0.0.0/0 ke NAT Gateway, dan NAT berada di public subnet. Kelebihan: cepat. Kekurangan: ada biaya NAT per jam + data processing.

Opsi B — Pakai VPC Interface Endpoints (recommended untuk production private)

Untuk Session Manager, umumnya Anda perlu interface endpoint berikut pada VPC yang sama:

com.amazonaws.<region>.ssm
com.amazonaws.<region>.ec2messages
com.amazonaws.<region>.ssmmessages

Langkah konseptual:

VPC → Endpoints → Create endpoint.
Pilih tipe Interface.
Buat untuk tiga service di atas.
Tempatkan endpoint pada subnet yang relevan.
Assign Security Group ke endpoint yang mengizinkan inbound dari instance (biasanya 443/tcp).

🔒 Keamanan: Batasi SG endpoint hanya dari CIDR subnet/SG instance yang membutuhkan.

Langkah 4: Verifikasi Instance Sudah Terdaftar di Systems Manager

Jika role, agent, dan network sudah benar, instance akan muncul sebagai Managed node. Cek di:

Systems Manager → Fleet Manager atau Managed nodes

Indikator sehat:

Status: “Online”
Ping status: “Online”

Jika instance tidak muncul:

Cek IAM role benar ter-attach.
Cek agent running.
Cek outbound 443 ke endpoint SSM.
Cek DNS resolution di VPC (enable DNS hostnames/support).

📊 Metrik: Waktu normal instance muncul biasanya hitungan menit setelah komponen siap.

Langkah 5: Siapkan Personal PC (AWS CLI + Session Manager Plugin)

Untuk akses via terminal di personal PC, Anda butuh:

AWS CLI (v2 direkomendasikan)
Session Manager Plugin
AWS credentials yang punya izin ssm:StartSession

Jika Anda menggunakan macOS, umumnya instalasi dilakukan via Homebrew, lalu verifikasi versi.

💡 Tips Pro: Pastikan profile AWS CLI Anda memakai MFA jika akun Anda sensitif.

Langkah 6: Buat IAM Policy untuk User/Role yang Boleh Start Session

Akses SSM harus dibatasi. Secara minimum, principal (user/role) Anda memerlukan:

ssm:StartSession
ssm:TerminateSession
ssm:DescribeSessions
ssm:GetConnectionStatus

Dan untuk membatasi target instance, Anda bisa gunakan kondisi berbasis tag. Contoh pendekatan kebijakan yang aman:

Hanya boleh session ke instance dengan tag: SSMAccess=Enabled.

✅ Best Practice: Gunakan tag-based access control agar Anda tidak perlu maintain daftar instance ARN satu per satu.

Langkah 7: Mulai Session ke EC2 via SSM

Ada dua cara umum:

A) Via AWS Console

Systems Manager → Session Manager → Start session → pilih instance.

Ini paling mudah untuk troubleshooting awal.

B) Via Terminal (AWS CLI)

Alur konsepnya:

Dapatkan instance id (misalnya i-xxxxxxxx).
Jalankan perintah start session.

Jika semuanya benar, Anda akan masuk ke shell instance.

⚠️ Perhatian: User yang Anda dapatkan di session tergantung konfigurasi SSM dan OS; jangan berasumsi Anda otomatis root.

Best Practices: Logging, Audit, dan Hardening

Agar SSM benar-benar layak untuk production, pertimbangkan:

1) Rekam sesi (session logging)

Anda bisa mengaktifkan Session Manager preferences untuk:

Kirim log ke CloudWatch Logs
Simpan transcript ke S3
Enforce encryption (KMS)

Manfaatnya: audit dan compliance.

2) Nonaktifkan inbound SSH dari internet

Jika Anda sudah berhasil akses via SSM, pertimbangkan:

Hapus rule inbound 22/tcp di Security Group.
Gunakan SSM untuk operasi rutin.

3) Batasi akses dengan IAM + tag

Pisahkan akses prod vs non-prod.
Terapkan permission boundary untuk role tertentu.

4) Gunakan VPC endpoints untuk private-only environment

Kurangi dependensi NAT.
Kurangi permukaan serangan.

🔒 Keamanan: Pastikan CloudTrail aktif untuk mencatat StartSession dan perubahan konfigurasi.

Troubleshooting Cepat: SSM Tidak Bisa Connect

Berikut checklist paling sering:

Instance tidak muncul di Managed nodes
- IAM role belum ter-attach atau policy salah.
- Agent tidak berjalan.
- Tidak ada outbound 443/dns.
Muncul tapi status offline
- DNS/VPC endpoint bermasalah.
- NACL memblokir traffic.
Start session gagal dari PC
- IAM principal tidak punya ssm:StartSession.
- Session Manager plugin belum terpasang.
- Region/profile AWS CLI salah.

🚀 Optimasi: Untuk lab, mulai dulu via Console. Jika console sukses, baru lanjut CLI di PC.

Analisis Mendalam dan Rekomendasi Strategis

Banyak tim memulai akses server dengan SSH karena sederhana dan sudah “tradisi”. Namun saat jumlah instance bertambah atau ketika tuntutan audit meningkat, SSH cepat menjadi beban: key rotation, bastion, inbound rules, dan kontrol akses yang tidak seragam. SSM Session Manager unggul karena memusatkan kontrol akses di IAM dan membuat akses server menjadi bagian dari governance AWS. Untuk organisasi yang ingin meminimalkan permukaan serangan, pattern “private EC2 + SSM + VPC endpoints” adalah baseline yang kuat.

Kesalahan Umum yang Harus Dihindari

Menganggap SSM tidak butuh jaringan: tetap butuh path ke service SSM via NAT atau VPC endpoints.
Tidak membatasi StartSession: tanpa tag-based restriction, user bisa session ke semua instance.
Tidak mengaktifkan logging: Anda kehilangan jejak audit saat terjadi insiden.

Kesimpulan

SSM menggantikan SSH untuk banyak use case: akses shell tanpa inbound port dan tanpa key pair.
Role + agent + network adalah tiga syarat utama: jika salah satu tidak beres, instance tidak akan “managed”.
VPC endpoints membuat arsitektur benar-benar private: ideal untuk production yang ketat.
IAM dan tag-based control memberi governance yang scalable: akses bisa dibatasi per environment dan per tim.
Logging membuat akses bisa di-audit: penting untuk compliance dan incident response.

Dengan SSM, akses dari personal PC ke EC2 menjadi lebih aman, mudah dikelola, dan siap berkembang seiring bertambahnya infrastruktur. Setelah setup dasar berhasil, langkah berikutnya adalah mengunci SSH, menambahkan logging, dan menstandardisasi akses berbasis tag. Disclaimer: Tulisan ini disusun dari sudut pandang dan pengalaman pribadi dalam mengelola akses instance di AWS. Detail implementasi dapat berbeda tergantung kebutuhan organisasi, kontrol keamanan, dan kebijakan compliance yang berlaku.

Cara Setup AWS Systems Manager (SSM) untuk Akses EC2 dari Pe...