Menggunakan Banyak Akun AWS di Satu Komputer

Mengelola lebih dari satu akun AWS dari satu komputer adalah kebutuhan sehari-hari bagi software engineer maupun DevOps — akun development untuk eksperimen, staging untuk testing sebelum rilis, production untuk sistem live, atau bahkan akun klien yang terpisah. Tanpa konfigurasi yang rapi, risiko terbesarnya nyata: menjalankan perintah destruktif di akun yang salah, misalnya menghapus resource production padahal maksudnya di staging. AWS CLI menyediakan mekanisme profile untuk menangani ini, tapi sekadar tahu cara membuat profile saja belum cukup — bagian yang sering luput justru bagaimana memastikan profile yang aktif benar-benar yang kamu maksud sebelum command dieksekusi. Artikel ini membahas profile AWS CLI secara menyeluruh, dari struktur file sampai kebiasaan kerja yang mencegah kesalahan fatal.

Konsep Dasar AWS Profile

AWS CLI menyimpan konfigurasi dalam dua file terpisah, dan memahami kenapa dipisah membantu menghindari kebingungan saat troubleshooting nantinya:

• ~/.aws/credentials — menyimpan Access Key dan Secret Key, data yang bersifat rahasia
• ~/.aws/config — menyimpan region, output format, dan pengaturan tambahan, data yang tidak rahasia

Pemisahan ini bukan kebetulan. Kredensial adalah sesuatu yang sangat sensitif dan idealnya dikelola secara berbeda dari pengaturan biasa seperti region — beberapa tim bahkan memisahkan permission file system di level OS antara dua file ini. Dengan profile, kamu menyimpan banyak set kredensial sekaligus di komputer yang sama, lalu memilih akun mana yang aktif saat menjalankan perintah tertentu.

flowchart TD
    A[aws CLI command] --> B{Profile mana yang aktif?}
    B --> C[Baca ~/.aws/credentials]
    B --> D[Baca ~/.aws/config]
    C --> E[Access Key + Secret Key untuk profile ini]
    D --> F[Region + output format untuk profile ini]
    E --> G[Request ke AWS API]
    F --> G

Struktur File credentials

File ~/.aws/credentials memakai format INI, dengan setiap blok [nama_profile] mewakili satu akun. Misalkan kamu mengelola tiga akun: default, staging, dan production.

[default]
aws_access_key_id = AKIADEFAULTEXAMPLE
aws_secret_access_key = secretdefaultkey

[staging]
aws_access_key_id = AKIASTAGINGEXAMPLE
aws_secret_access_key = secretstagingkey

[production]
aws_access_key_id = AKIAPRODEXAMPLE
aws_secret_access_key = secretproductionkey

Beberapa hal penting soal struktur ini:

• Blok [default] dipakai otomatis kalau tidak ada profile lain yang ditentukan secara eksplisit — ini berarti command tanpa flag profile apapun akan jatuh ke akun ini
• Profile selain default hanya aktif kalau dipanggil secara eksplisit, lewat flag atau environment variable
• Nama profile di file credentials ditulis polos tanpa prefix apapun: [staging], bukan [profile staging]

Jangan pernah menaruh kredensial akun production sebagai [default]. Kalau suatu saat kamu menjalankan command tanpa sadar lupa menentukan profile, command itu otomatis jatuh ke default — dan kalau itu production, kesalahan kecil bisa berakibat fatal.

Struktur File config

File ~/.aws/config menyimpan pengaturan non-rahasia seperti region dan output format per profile. Strukturnya mirip, tapi ada satu perbedaan krusial yang sering jadi sumber kebingungan developer baru.

[default]
region = us-west-2
output = json

[profile staging]
region = us-east-1
output = json

[profile production]
region = ap-southeast-1
output = json

Perhatikan baik-baik: di file config, setiap profile selain default harus diawali kata profile di dalam tanda kurung siku — [profile staging], bukan [staging]. Ini berlaku kebalikan dari file credentials, yang justru tidak memakai prefix apapun.

flowchart LR
    subgraph credentials [~/.aws/credentials]
        A1["[default]"]
        A2["[staging]"]
        A3["[production]"]
    end
    subgraph config [~/.aws/config]
        B1["[default]"]
        B2["[profile staging]"]
        B3["[profile production]"]
    end

Lupa menambahkan prefix profile di file config adalah kesalahan paling umum saat setup multi-account pertama kali. Akibatnya AWS CLI tetap bisa otentikasi (karena kredensial valid), tapi region atau output setting untuk profile itu tidak pernah terbaca — sering muncul sebagai error region yang membingungkan padahal kredensialnya benar.

Mengaktifkan Profile

Ada dua cara utama menentukan profile mana yang aktif untuk sebuah command, dan keduanya bisa saling tumpang tindih kalau dipakai bersamaan.

Flag --profile per Command

Cara paling eksplisit — profile hanya berlaku untuk satu command itu saja, tidak memengaruhi command lain di sesi terminal yang sama.

aws s3 ls --profile staging
aws iam list-users --profile production

Environment Variable AWS_PROFILE

Cara yang lebih praktis kalau kamu akan menjalankan banyak command berturut-turut di akun yang sama — set sekali, semua command setelahnya otomatis memakai profile itu sampai sesi terminal ditutup atau diubah lagi.

# macOS / Linux
export AWS_PROFILE=staging

# Windows PowerShell
$Env:AWS_PROFILE="staging"

Setelah env var ini di-set, semua perintah AWS CLI di sesi terminal yang sama otomatis memakai akun staging tanpa perlu mengulang flag --profile setiap kali.

Precedence Antara Keduanya

Kalau AWS_PROFILE sudah di-set sebagai env var tapi kamu juga menambahkan flag --profile di command tertentu, flag selalu menang untuk command itu saja — env var tidak berubah, hanya command itu yang memakai profile berbeda sesaat.

flowchart TD
    A[aws command dijalankan] --> B{Ada flag --profile?}
    B -- Ya --> C[Pakai profile dari flag]
    B -- Tidak --> D{AWS_PROFILE di-set?}
    D -- Ya --> E[Pakai profile dari env var]
    D -- Tidak --> F[Pakai default]

Kamu tidak bisa menjalankan dua profile aktif sekaligus dalam satu command. Profile harus ditentukan per command lewat flag, atau lewat environment variable yang berlaku untuk seluruh sesi terminal — tidak ada mekanisme “multi-profile” dalam satu eksekusi.

Verifikasi Profile Aktif Sebelum Eksekusi

Inilah bagian yang paling sering dilewatkan, padahal justru paling penting untuk mencegah risiko “salah akun” yang sudah disinggung di awal. Mengetahui cara mengaktifkan profile saja tidak cukup — kamu juga butuh kebiasaan memverifikasi profile mana yang sedang aktif, terutama sebelum menjalankan command yang sifatnya destruktif (delete, terminate, remove-stack, dan sejenisnya).

Command aws sts get-caller-identity menampilkan identitas akun yang sedang aktif berdasarkan kredensial yang dipakai saat ini:

aws sts get-caller-identity --profile production

{
    "UserId": "AIDAEXAMPLE",
    "Account": "111122223333",
    "Arn": "arn:aws:iam::111122223333:user/budi"
}

Field Account di sini adalah sumber kebenaran paling andal — bukan asumsi dari nama profile yang kamu ingat, melainkan account ID sungguhan yang dikembalikan AWS. Jadikan ini langkah wajib sebelum command berisiko tinggi:

# Kebiasaan aman sebelum command destruktif
aws sts get-caller-identity --profile production
# Periksa output Account ID sesuai harapan, baru lanjutkan:
aws cloudformation delete-stack --stack-name legacy-app --profile production

Pertimbangkan membuat alias shell sederhana seperti whoami-aws yang menjalankan aws sts get-caller-identity dengan profile aktif saat ini. Kebiasaan kecil ini jauh lebih murah dibanding biaya memulihkan resource production yang terhapus tidak sengaja.

Menggunakan Profile di Kode Aplikasi

Profile tidak hanya dipakai lewat AWS CLI secara langsung — SDK di berbagai bahasa juga mendukung pemilihan profile yang sama, membaca dari file credentials dan config yang sama persis.

Node.js

const AWS = require('aws-sdk');

const credentials = new AWS.SharedIniFileCredentials({
  profile: 'staging',
});

AWS.config.credentials = credentials;

const s3 = new AWS.S3();

Go

package main

import (
	"context"
	"log"

	"github.com/aws/aws-sdk-go-v2/config"
	"github.com/aws/aws-sdk-go-v2/service/s3"
)

func main() {
	cfg, err := config.LoadDefaultConfig(context.TODO(),
		config.WithSharedConfigProfile("staging"),
	)
	if err != nil {
		log.Fatal(err)
	}

	client := s3.NewFromConfig(cfg)
	_ = client
}

Python (boto3)

import boto3

session = boto3.Session(profile_name='staging')
s3 = session.client('s3')

Pola di ketiga bahasa ini sama: kamu tidak menyalin Access Key dan Secret Key langsung ke kode, melainkan merujuk ke nama profile yang sudah dikonfigurasi di file credentials. Ini sejalan dengan prinsip menghindari hard-code kredensial — SDK yang mengambil alih pembacaan file konfigurasi, kode aplikasi cukup tahu nama profile mana yang dipakai.

Jangan commit nama profile akun production sebagai default hard-coded di kode aplikasi yang di-share ke banyak environment. Kalau kode yang sama jalan di local development developer lain, mereka bisa tidak sengaja mengakses akun production karena profile itu memang ada di komputer mereka dengan nama yang sama.

Mengelola Profile dengan Tools Lain

Selain AWS CLI dan SDK aplikasi, tools infrastruktur seperti Terraform juga mengikuti mekanisme profile yang sama, karena di bawahnya tetap membaca file ~/.aws/credentials dan ~/.aws/config standar.

provider "aws" {
  region  = "ap-southeast-1"
  profile = "staging"
}

Atau lewat environment variable yang sama seperti AWS CLI:

export AWS_PROFILE=staging
terraform plan

Untuk project yang menangani banyak environment sekaligus, beberapa tim memakai tool seperti direnv untuk otomatis meng-set AWS_PROFILE yang sesuai begitu masuk ke direktori project tertentu — sehingga profile yang aktif selalu konsisten dengan project yang sedang dikerjakan, tanpa perlu mengingat untuk export manual setiap kali pindah terminal.

# .envrc di direktori project staging
export AWS_PROFILE=staging

Praktik Aman Mencegah Salah Akun

Mekanisme profile sendiri tidak otomatis mencegah kesalahan — ia hanya menyediakan caranya. Kebiasaan kerja di sekitarnya yang sebenarnya menentukan seberapa aman setup multi-account ini dalam praktik.

Gunakan nama profile yang konsisten dan tidak ambigu. Penamaan seperti dev, staging, prod jauh lebih aman daripada nama yang mengandalkan ingatan, seperti akun1 atau client-a-yg-baru. Konsistensi penamaan antar anggota tim juga mengurangi risiko miskomunikasi saat berkoordinasi.

Tampilkan profile aktif di shell prompt. Banyak konfigurasi shell (zsh, bash dengan plugin) bisa menampilkan nilai AWS_PROFILE langsung di prompt terminal, sehingga kamu selalu melihat profile mana yang aktif tanpa perlu mengecek manual setiap saat.

Verifikasi sebelum command destruktif, bukan setelahnya. Seperti dibahas di bagian sebelumnya, aws sts get-caller-identity sebelum command yang menghapus atau mengubah resource harus jadi kebiasaan, bukan langkah opsional.

Hindari menyimpan kredensial production di mesin yang sama dengan akses harian. Kalau memungkinkan, batasi siapa saja yang punya kredensial production tersimpan secara lokal — semakin sedikit komputer yang menyimpannya, semakin kecil permukaan risiko kebocoran atau kesalahan.

flowchart TD
    A[Mulai sesi kerja] --> B[Set AWS_PROFILE sesuai project]
    B --> C[Cek prompt shell menampilkan profile aktif]
    C --> D{Command destruktif?}
    D -- Ya --> E[Jalankan sts get-caller-identity]
    E --> F{Account ID sesuai harapan?}
    F -- Ya --> G[Lanjutkan command]
    F -- Tidak --> H[STOP - ganti profile dulu]
    D -- Tidak --> G

Tabel Ringkasan

Ringkasan

• AWS CLI menyimpan kredensial di ~/.aws/credentials dan pengaturan non-rahasia di ~/.aws/config — dua file dengan tujuan berbeda.
• Nama profile di credentials ditulis polos ([staging]), sementara di config wajib diawali profile ([profile staging]) kecuali untuk default.
• Profile default aktif otomatis kalau tidak ditentukan — jangan pernah menaruh kredensial production di sana.
• Aktifkan profile lewat flag --profile untuk sekali pakai, atau AWS_PROFILE env var untuk seluruh sesi terminal; flag selalu menang kalau keduanya dipakai bersamaan.
• aws sts get-caller-identity adalah cara paling andal memverifikasi akun mana yang benar-benar aktif — jadikan kebiasaan wajib sebelum command destruktif.
• SDK di Node.js, Go, dan Python semuanya mendukung pemilihan profile yang sama, membaca file konfigurasi standar yang sama dengan AWS CLI.
• Tools seperti Terraform mengikuti mekanisme profile yang sama; direnv bisa membantu otomatisasi profile per direktori project.
• Penamaan profile yang konsisten, profile aktif yang terlihat di shell prompt, dan verifikasi sebelum command berisiko adalah kebiasaan yang benar-benar mencegah kesalahan — bukan sekadar mekanisme teknisnya saja.