Cloud Service Bisa Berhenti: Pelajaran dari AWS App Runner dan WorkMail untuk Bisnis

Ketika bisnis mulai memakai cloud, sering muncul kesan bahwa layanan yang sudah dipilih akan tersedia selamanya. Selama tagihan dibayar dan aplikasi berjalan normal, banyak owner bisnis tidak terlalu memikirkan apa yang terjadi jika suatu layanan tiba-tiba masuk fase maintenance, tidak menerima pengguna baru, atau benar-benar dihentikan.

Berita terbaru dari InfoQ pada 26 April 2026 tentang keputusan AWS menghentikan WorkMail dan memindahkan App Runner ke maintenance mode menjadi pengingat yang cukup keras: layanan cloud besar sekalipun tetap punya siklus hidup. Produk bisa berubah arah. Fitur bisa dihentikan. Layanan yang dulu terlihat praktis bisa menjadi opsi yang tidak lagi strategis.

Bagi bisnis di Indonesia, pelajarannya bukan “jangan pakai cloud” atau “jangan pakai AWS”. Cloud tetap sangat berguna untuk mempercepat pengembangan produk digital, mengurangi kebutuhan infrastruktur fisik, dan membuat sistem lebih mudah diskalakan. Namun, bisnis perlu memahami bahwa memilih layanan cloud bukan hanya keputusan teknis. Ini juga keputusan operasional dan risiko bisnis.

Dari sudut pandang Havedev, isu seperti ini penting karena banyak sistem bisnis hari ini sudah menjadi tulang punggung operasional: website, dashboard, CRM, aplikasi internal, sistem booking, POS, ERP ringan, hingga automasi laporan. Jika fondasinya terlalu bergantung pada satu layanan spesifik tanpa rencana migrasi, risiko teknis bisa berubah menjadi gangguan bisnis yang nyata.

Apa yang sebenarnya terjadi?

Berdasarkan laporan InfoQ, AWS mengumumkan bahwa WorkMail akan dihentikan pada Maret tahun depan, sementara App Runner tidak lagi menerima pelanggan baru dan masuk maintenance mode. Beberapa layanan dan fitur lain juga ikut masuk fase maintenance atau sunset.

Untuk pembaca non-teknis, istilah ini perlu dibedakan:

Maintenance mode biasanya berarti layanan masih berjalan untuk pengguna existing, tetapi pengembangan besar dan akuisisi pengguna baru dibatasi.
Sunset berarti layanan akan dihentikan pada tanggal tertentu, sehingga pengguna perlu migrasi.
Deprecation berarti layanan atau fitur tidak lagi direkomendasikan dan suatu saat bisa dihapus.

Dalam praktiknya, tiga istilah ini sama-sama menuntut perhatian. Bedanya hanya tingkat urgensi. Jika layanan masuk maintenance mode, bisnis masih punya waktu untuk menilai opsi. Jika layanan sudah sunset, bisnis harus punya rencana migrasi yang jelas.

Kenapa bisnis perlu peduli walau tidak memakai AWS?

Sebagian bisnis mungkin merasa berita ini jauh dari realitas sehari-hari. “Kami tidak pakai WorkMail.” “Aplikasi kami bukan di App Runner.” “Kami hanya punya website company profile.” Namun yang penting bukan nama layanannya. Yang penting adalah pola risikonya.

Setiap sistem digital punya dependensi. Bisa berupa provider hosting, database, payment gateway, layanan email, CDN, storage, authentication, analytics, atau platform automasi. Ketika salah satu dependensi berubah, aplikasi yang terlihat stabil bisa ikut terdampak.

Untuk bisnis kecil dan menengah, dampaknya sering bukan pada level “server error” saja. Dampaknya bisa terasa sebagai:

lead dari website tidak masuk ke tim sales
email transaksional gagal terkirim
dashboard operasional tidak bisa dibuka
aplikasi internal melambat atau sulit di-deploy
biaya migrasi muncul mendadak
tim bingung karena dokumentasi sistem tidak lengkap

Karena itu, berita seperti ini sebaiknya dibaca sebagai pengingat untuk menata ulang cara memandang infrastruktur digital.

Cloud bukan sekadar tempat menaruh aplikasi

Kesalahan umum dalam proyek digital adalah melihat cloud hanya sebagai “tempat hosting”. Padahal setiap pilihan cloud membawa konsekuensi arsitektur. Ada layanan yang sangat praktis karena banyak hal sudah disiapkan. Namun semakin praktis sebuah layanan, sering kali semakin banyak asumsi teknis yang tersembunyi di dalamnya.

Misalnya, platform yang memudahkan deploy aplikasi bisa menghemat waktu developer. Tetapi jika aplikasi hanya bisa berjalan nyaman di platform itu, migrasi ke tempat lain menjadi lebih rumit. Begitu juga layanan email, database terkelola, queue, atau serverless function. Semuanya bisa mempercepat pekerjaan, tetapi tetap perlu dipilih dengan kesadaran risiko.

Di sinilah konsep portabilitas menjadi penting. Portabilitas bukan berarti semua sistem harus bisa pindah cloud dalam satu jam. Itu tidak realistis untuk banyak bisnis. Portabilitas berarti sistem dirancang agar tidak terkunci tanpa jalan keluar.

Tanda sistem terlalu bergantung pada satu layanan

Tidak semua ketergantungan itu buruk. Bisnis memang butuh vendor, tools, dan platform. Yang berbahaya adalah ketergantungan yang tidak disadari. Beberapa tanda yang perlu diperhatikan:

1. Tidak ada dokumentasi cara deploy

Jika hanya satu orang yang tahu cara menjalankan aplikasi, risiko bisnis sudah tinggi. Dokumentasi deploy, environment variable, database, dan konfigurasi dasar harus tersedia. Tidak perlu sempurna, tetapi cukup untuk membantu tim lain mengambil alih saat perlu.

2. Data sulit diekspor

Sistem yang sehat harus punya jalur backup dan export data. Jika data pelanggan, transaksi, atau laporan hanya bisa diakses melalui satu platform tanpa mekanisme keluar yang jelas, bisnis sedang menanggung risiko besar.

3. Fitur inti terlalu menempel ke layanan spesifik

Misalnya logic bisnis penting hanya hidup di konfigurasi vendor tertentu, bukan di kode aplikasi atau dokumentasi proses. Ketika vendor berubah, tim harus membangun ulang dari nol.

4. Tidak ada rencana fallback

Fallback tidak harus mahal. Untuk website, bisa berupa backup hosting dan backup konten. Untuk aplikasi operasional, bisa berupa prosedur manual sementara. Untuk email, bisa berupa alternatif provider yang sudah dipetakan. Yang penting: saat terjadi gangguan, bisnis tidak mulai berpikir dari titik nol.

Apa yang bisa dilakukan bisnis sekarang?

Bisnis tidak perlu panik atau langsung mengganti semua sistem. Langkah yang lebih sehat adalah melakukan audit kecil namun rutin.

Mulailah dengan membuat daftar layanan digital yang dipakai. Pisahkan antara layanan yang kritikal dan non-kritikal. Layanan kritikal adalah yang jika mati beberapa jam saja bisa mengganggu penjualan, operasional, atau layanan pelanggan.

Setelah itu, tanyakan beberapa hal sederhana:

Siapa vendor atau provider utama untuk layanan ini?
Apakah data bisa diekspor?
Apakah ada backup rutin?
Siapa yang tahu cara memperbaiki atau memigrasikan sistem?
Apakah ada alternatif jika layanan berubah harga, fitur, atau status?
Seberapa sulit memindahkan aplikasi ke platform lain?

Jawaban dari pertanyaan ini bisa membuka banyak hal. Kadang masalahnya bukan teknologi yang buruk, tetapi keputusan lama yang belum pernah ditinjau ulang.

Peran arsitektur yang pragmatis

Dalam dunia ideal, semua sistem dibuat sangat fleksibel, modular, dan mudah dipindahkan. Namun bisnis nyata punya budget, deadline, dan prioritas. Karena itu, pendekatan yang masuk akal bukan mengejar arsitektur paling canggih, melainkan arsitektur yang cukup kuat untuk kebutuhan bisnis.

Untuk website company profile, mungkin cukup dengan hosting stabil, backup rutin, dan struktur konten yang mudah dipindahkan. Untuk aplikasi internal, mungkin perlu container, dokumentasi deployment, database backup, dan pemisahan konfigurasi. Untuk sistem yang menyentuh transaksi, perlu rencana keamanan, monitoring, audit log, dan disaster recovery yang lebih matang.

Prinsipnya: semakin penting sistem bagi operasional, semakin serius desain keberlanjutannya.

Jangan tunggu layanan dihentikan baru bergerak

Berita tentang WorkMail dan App Runner menunjukkan bahwa perubahan platform bisa datang dari provider mana pun. Perusahaan teknologi besar pun akan terus merapikan portofolio layanan berdasarkan strategi, biaya, dan permintaan pasar.

Bagi bisnis, respons terbaik adalah tidak bergantung pada asumsi “karena ini dari vendor besar, pasti aman selamanya”. Yang lebih sehat adalah membangun sistem dengan kesadaran bahwa perubahan pasti terjadi.

Cloud tetap menjadi fondasi penting bagi bisnis modern. Namun cloud yang baik harus dipakai dengan desain yang matang: ada dokumentasi, backup, monitoring, jalur migrasi, dan keputusan teknis yang bisa dijelaskan secara bisnis.

Jika bisnis Anda sedang membangun website, aplikasi internal, dashboard, atau sistem operasional berbasis cloud, ini momen yang baik untuk meninjau fondasinya. Havedev dapat membantu melihat bukan hanya apakah sistem bisa berjalan hari ini, tetapi apakah sistem itu cukup siap menghadapi perubahan platform besok.