Saat hendak memeriksa apakah AWS berjalan baik atau mengalami kendala, tidak cukup hanya melihat lampu hijau atau merah: Anda harus melewati panel kesehatan, sinyal waktu nyata, dan ulasan spesifik sumber daya AndaDengan pendekatan gabungan ini, Anda akan mengetahui apakah masalahnya bersifat umum, regional, atau terkait dengan infrastruktur Anda sendiri, dan Anda akan dapat bertindak tanpa mengambil langkah gegabah.
Dalam panduan ini, saya akan meninggalkan Anda dengan segala sesuatu yang terstruktur dengan baik untuk memeriksa status AWS dengan kepala: dari AWS Health Dashboard dan integrasinya dengan EventBridge, cara melihat status pembaruan di ACM, menginterpretasikan pemeriksaan EC2, dan merespons metrik serta alarm CloudWatch. Anda juga akan mempelajari langkah-langkah yang harus diambil jika konsol menolak untuk dimuat, cara memeriksa halaman status publik, dan mengapa pihak ketiga seperti Downdetector berguna untuk konteks, tetapi tidak untuk otomatisasi.
AWS Health Dashboard: Titik Awal
AWS Health Dashboard menampilkan pemadaman, kejadian aktif, dan pemeliharaan terencana yang dapat memengaruhi layanan dan sumber daya Anda. Itu bagian dari akun Anda, tidak memerlukan konfigurasi, dan menyediakan visibilitas kontekstual. tentang apa yang sedang terjadi. Jika Anda tidak masuk ke instance atau konsol tertentu, ini adalah tempat pertama yang harus Anda kunjungi.
Sebuah detail yang sering terlupakan: AWS bersifat regionalPilih wilayah yang tepat dari panel pemilih Kesehatan, karena jika Anda mencari wilayah yang salah, Anda mungkin melewatkan insiden yang memengaruhi Anda. Presisi ini mencegah kesalahan diagnosis jika masalahnya terbatas pada wilayah geografis tertentu.
Mulai tahun 2023, saat membuka acara publik di panel Kesehatan, URL browser menyertakan tautan mendalam ke acara tersebutHal ini memungkinkan Anda untuk membagikan insiden yang sedang Anda lihat atau membukanya kembali dan kembali ke tampilan yang sama dengan jendela pop-up yang dimuat, sehingga memudahkan kerja tim selama insiden terjadi.
Jika konsol admin tidak terbuka atau menampilkan kesalahan browser (misalnya, 404), jangan terburu-buru. Pertama, periksa apakah ada peristiwa aktif yang relevan di Dasbor Kesehatan, lalu terapkan tindakan lokal seperti membersihkan cache dan cookie, mencoba browser lain, dan mengonfirmasi dengan tim TI Anda bahwa jaringan Anda tidak memblokir domain Amazon (amazon.com dan subdomain seperti aws.amazon.com).
Penyerapan acara yang andal: EventBridge lebih baik daripada RSS
Ada umpan RSS dengan acara kesehatan, tetapi formatnya dapat berubah seiring waktu dan merusak integrasi AndaMengikis atau mengandalkan RSS untuk jalur penting adalah tindakan yang berisiko, paling tidak begitulah.
Hal yang kuat adalah mengintegrasikan AWS Health dengan Amazon EventBridgeDengan cara ini, Anda menerima kejadian dengan skema yang stabil, secara real time, dan siap untuk dirutekan ke Lambda, antrean, notifikasi, atau dasbor internal, sehingga menciptakan rangkaian insiden Anda tanpa bagian yang rapuh.
Dengan EventBridge Anda memperoleh ketertelusuran dan ketahanan: Anda dapat menandai, memperkaya, menghubungkan, dan mengotomatiskan respons tergantung pada layanan, wilayah, atau dampaknya. Dan jika detail presentasi umpan publik berubah besok, integrasi Anda akan tetap utuh.
ACM: Tinjau pembaruan sertifikat tanpa masalah
Dengan AWS Certificate Manager, Anda dapat memverifikasi bahwa sertifikat Anda diperbarui dengan benar dan terkelola. Sertifikat memenuhi syarat untuk perpanjangan otomatis bila dikaitkan dengan layanan AWS (misalnya, ELB atau CloudFront) atau jika diekspor sejak penerbitan atau perpanjangan terakhir.Kelayakan ini adalah landasan untuk melupakan pembaruan manual.
Saat siklus pembaruan dimulai, ACM menampilkan kolom status dalam rincian sertifikat. Dari konsol, API atau CLI Anda dapat memeriksa RenewalStatus untuk mengetahui kondisi Anda. Anda juga akan melihat status relevan di dasbor Kesehatan Anda jika ada masalah yang memerlukan perhatian Anda.
Jika Anda lebih suka perintah, CLI mempermudahnya: Operasi describe-certificate mengembalikan rincian, termasuk status pembaruan.. Sebagai contoh:
Contoh: aws acm describe-certificate --certificate-arn arn:aws:acm:REGION:ACCOUNT:certificate/CERTIFICATE_ID
Dalam respons JSON, lihat kolom RenewalStatus. Jika kolom tersebut belum muncul, ACM belum memulai pembaruan terkelola.Sebaiknya Anda merencanakannya terlebih dahulu: ACM mencoba memperbarui secara otomatis sekitar 60 hari sebelum masa berlaku habis, dan jika terjadi kesalahan (misalnya, validasi domain), Anda akan menerima pemberitahuan di Kesehatan sebelumnya: 45, 30, 15, 7, 3 dan 1 hari.
Saat konsol tidak dapat diisi daya: langkah cepat dan efektif
Kesalahan 404 atau kegagalan koneksi saat mengakses konsol AWS biasanya dapat dipecahkan. Mulailah dengan meninjau Dasbor Kesehatan di wilayah tempat sumber daya Anda berada. untuk menghentikan kejadian yang sedang berlangsung yang memengaruhi layanan atau konsol tersebut.
Jika tidak ada insiden terbuka, terapkan tindakan lokal: hapus cache dan cookie browser, coba masuk dengan browser lain dan konfirmasikan dengan administrator sistem Anda bahwa jaringan perusahaan tidak memblokir amazon.com atau subdomain seperti aws.amazon.com.
Masalahnya mungkin terbatas pada sumber daya tertentu. Misalnya, suatu instansi EC2 mungkin sedang menjalani pemeliharaan terencana., dan panel Kesehatan akan menampilkan jendela dan dampak peristiwa tersebut. Mengakses root akan menghemat waktu Anda.
Selain itu, jika akun Anda terkunci, sebaiknya selalu sediakan artikel bantuan yang berguna: Buat dan aktifkan akun baru, masuk ke konsol, atau minta bantuan.Dengan adanya panduan ini, waktu tunggu pada saat stres dapat dikurangi.
EC2 secara detail: pemeriksaan status dan apa yang harus dilakukan jika gagal
Amazon EC2 melakukan pemeriksaan otomatis per instans untuk mendeteksi masalah platform atau perangkat lunak yang memengaruhi aplikasi Anda. Pemeriksaan ini dijalankan setiap menit dan ditandai OK atau terganggu tergantung pada hasilnya.. Mereka tidak dapat dimatikan dan merupakan peringatan dini Anda.
Setiap jenis verifikasi didukung oleh metrik di CloudWatch. Jika pemeriksaan gagal, metrik terkait akan meningkat dan inilah saatnya untuk membunyikan alarm.Dengan ini, Anda dapat mengotomatiskan notifikasi dan tindakan untuk meminimalkan waktu henti.
Pemeriksaan sistem (platform dasar)
Pemeriksaan ini memantau infrastruktur tempat instansi Anda berjalan. Jika terjadi kegagalan, biasanya ada masalah pada platform yang memerlukan intervensi AWS atau tindakan untuk memindahkan instans ke host lain..
Dalam kasus yang didukung EBS, tindakan yang efektif adalah hentikan dan mulai instance untuk memindahkannya ke host baruJika instans Anda menggunakan penyimpanan instans (Linux), Anda dapat memilih untuk mengakhiri dan menggantinya, dengan mengetahui bahwa volume sementara akan hilang saat dimatikan.
Metrik yang mencerminkan kegagalan ini adalah StatusCheckFailed_SystemSempurna untuk alarm yang memicu buku petunjuk, pemulihan otomatis, atau membuka kasus dukungan jika situasi berlanjut.
Ada keanehan dengan Bare Metal: Memulai ulang sistem operasi mungkin dapat menyebabkan kesalahan pemeriksaan sistem untuk sementara.Ketika instans kembali berfungsi, statusnya akan kembali OK tanpa intervensi lebih lanjut.
Pemeriksaan instans (konektivitas dan perangkat lunak)
Pemeriksaan ini menganalisis kesehatan OS dan jaringan instansi itu sendiri. EC2 memvalidasi konektivitas dengan mengirimkan permintaan ARP ke NIC untuk memverifikasi apakah ia merespons.Kegagalan di sini biasanya memerlukan penyesuaian di pihak Anda.
Jika pemeriksaan gagal, saatnya bertindak: Nyalakan ulang instans, periksa firewall/iptables, periksa log sistem, dan pastikan jaringan merespons.Jika penyebabnya adalah perangkat lunak atau konfigurasi, menunggu saja tidak cukup.
Metrik yang perlu diperhatikan adalah StatusCheckFailed_InstanceGunakan untuk memicu alarm yang menjalankan prosedur diagnostik (mengumpulkan log, melakukan boot ulang terkontrol, atau melakukan rollback jika terdeteksi tidak dapat pulih).
Sekali lagi, di Bare Metal, kesalahan sementara mungkin muncul saat melakukan boot ulang dari OS. Ketika instance selesai di-boot, pemeriksaan biasanya kembali ke OK., jadi jangan panik.
Pemeriksaan Terlampir EBS (I/O pada Volume)
Pemeriksaan ini memvalidasi apakah volume EBS yang terpasang dapat diakses dan dapat menyelesaikan operasi input/output. Metrik biner StatusCheckFailed_AttachedEBS menunjukkan kemunduran saat satu atau beberapa volume gagal..
Kesalahan pada bagian ini mungkin disebabkan oleh masalah komputasi yang mendasar atau masalah di EBS. Anda dapat mengharapkan mitigasi dari AWS atau mengambil tindakan: Ganti volume, hentikan dan mulai instans untuk memindahkannya ke host lain, atau tinjau ukuran IOPS jika Anda melihat hambatan.
Jika beban Anda tidak melakukan I/O tetapi terjadi penurunan, Siklus berhenti dan mulai dapat menyelesaikan masalah host yang memengaruhi aksesibilitas volume.Dilengkapi dengan metrik EBS asli di CloudWatch untuk mendeteksi pola kinerja yang buruk.
Dalam grup Penskalaan Otomatis, konfigurasikan kebijakan untuk Hapus contoh dengan kegagalan persisten dalam pemeriksaan EBS terlampirAnda akan menjaga armada Anda tetap sehat tanpa intervensi manual dan menghindari waktu henti yang berkepanjangan.
Alarm dan Otomatisasi: CloudWatch + Penskalaan Otomatis
Dengan semua metrik kesehatan, CloudWatch menjadi sistem saraf Anda. Tentukan ambang batas, buat alarm, dan atur tindakan: notifikasi, Lambda, pemulihan atau penggantian instansIni adalah dasar untuk respons yang otomatis dan konsisten.
Jika Anda memerlukan kelangsungan bisnis, pertimbangkan untuk mengotomatisasi dan mengganti: Penskalaan Otomatis dapat menghentikan instance yang gagal dan meluncurkan instance yang baru, sementara alarm Anda mengaktifkan saluran notifikasi yang sesuai (email, Slack, PagerDuty atau apa pun yang Anda gunakan).
Pandangan lengkapnya berasal dari sumber-sumber yang berkorelasi: Metrik dan log CloudWatch, jejak, dan peristiwa AWS Health melalui EventBridgeDengan petak ini, Anda akan dapat membedakan apakah masalahnya ada pada aplikasi, instans, volume, atau platform, dan Anda akan dapat bereaksi secara akurat.
Sumber resmi dan kontekstual untuk mengetahui apakah AWS gagal
Ketika rumor tentang kejatuhan beredar — seperti Gangguan global AWS yang menyebabkan kegagalan besar—, idealnya adalah memprioritaskan sumber resmi. Periksa halaman publik status.aws.amazon.com untuk melihat status berdasarkan layanan dan wilayah., dan gunakan AWS Health Dashboard jika Anda masuk untuk informasi khusus akun.
Sumber pihak ketiga menyediakan konteks dan sinyal sosial tambahan. Downdetector mencerminkan lonjakan laporan pengguna, dan The Stack Status merangkum status beberapa penyedia.Mereka berguna untuk memperkirakan jangkauan, meskipun tidak menggantikan saluran resmi.
Namun, ia membedakan antara visibilitas dan otomatisasi. Untuk penyerapan peristiwa terprogram, EventBridge lebih baik daripada umpan RSS atau pengikisan., karena format eksternal dapat berubah dan membuat Anda terlibat dalam suatu insiden.
Bagaimana penurunan besar terwujud dan apa yang dapat Anda harapkan
Insiden besar cenderung terkonsentrasi di wilayah yang banyak digunakan (seperti Pantai Timur AS), dan Dampaknya terasa dalam rantai: penyimpanan, komputasi, basis data, atau DNSBukan hal yang aneh untuk melihat layanan seperti S3, EC2, RDS, Route 53, atau Kinesis tercantum di antara layanan yang terpengaruh oleh lonjakan kesalahan.
Dalam kasus ini, perusahaan streaming, alat kolaborasi, e-commerce, atau aplikasi seluler mungkin mengalami latensi, kesalahan autentikasi, dan kegagalan berkala. Polanya tidak merata: berhasil bagi sebagian pengguna, tetapi tidak bagi yang lain., berdasarkan rute, titik kehadiran, dan wilayah aktif.
Saluran resmi biasanya menerbitkan pembaruan rutin: Identifikasi awal penyebabnya (misalnya, masalah resolusi DNS pada API), penerapan mitigasi, dan rekomendasi percobaan ulangSaat pemulihan berlangsung, kesalahan berkurang dan lalu lintas kembali normal.
Di negara atau sektor tertentu, Anda akan melihat berita utama tentang layanan tertentu yang terpengaruh. Platform seperti Netflix, Disney+, Slack, bank, atau aplikasi yang sangat populer dapat terpengaruh ketika kawasan tempat mereka bergantung menderita, dan bahkan bisnis di LATAM (seperti iFood, Mercado Livre atau PicPay dalam insiden sebelumnya) telah merasakan dampaknya.
Dampak ekonomi dan reputasi dari kejatuhan
Di luar sisi teknis, penghentian layanan cloud memiliki biaya nyata: Kerugian per menit, dukungan yang kelebihan beban, pelanggan yang frustrasi, dan tekanan mediaEfek jaringan diperkuat oleh sentralisasi pilar-pilar Internet tertentu.
Organisasi yang mengoperasikan layanan penting sangat memahami hal ini: Jika kegagalan terus terulang, kepercayaan akan terkikis dan memulihkan citra merek membutuhkan biaya lebih besar daripada perbaikan teknis itu sendiri.
Krisis-krisis ini membawa pelajaran yang jelas namun tidak mengenakkan: kita sangat bergantung pada infrastruktur bersamaMerancang ketahanan dan asumsi kegagalan yang realistis tidak lagi opsional.
Strategi untuk lebih tangguh menghadapi insiden berikutnya
Jika bisnis Anda tidak dapat ditutup, ada taktik yang mengurangi risiko operasional. Pertimbangkan arsitektur multiwilayah untuk mendistribusikan beban antara berbagai zona AWS. dan menghindari satu titik kegagalan geografis.
Jika kasus penggunaan membenarkannya, evaluasi multi-cloud. Mendistribusikan fungsionalitas inti ke penyedia lain (Azure, GCP) memberi Anda jaring pengaman., meskipun melibatkan kompleksitas dan biaya koordinasi yang lebih besar.
Pada lapisan pengiriman, CDN yang dikonfigurasi dengan baik membantu mengatasi badai. Layanan seperti CloudFront atau alternatif seperti Cloudflare memungkinkan Anda menyajikan konten statis bahkan jika asal Anda tersendat., memberi pengguna dan sistem waktu istirahat.
Tak satu pun dari hal ini akan berhasil tanpa adanya organisasi: Tentukan rencana respons insiden dengan peran, saluran, eskalasi, dan komunikasi eksternalDi saat panas, kejernihan menghemat menit-menit yang berharga.
Praktik terbaik untuk memeriksa status AWS tanpa tersesat
Centraliza la observabilidad: Gunakan AWS Health Dashboard untuk konteks platform dan CloudWatch untuk metrik operasionalPendekatan ganda ini mencegah Anda dari keterkejutan akibat satu lapisan mana pun.
Dengan sertifikat, otomatisasi. Pantau RenewalStatus di ACM dan tanggapi peringatan yang meningkat dari dasbor Kesehatan agar tidak salah mencapai tanggal kedaluwarsa.
Tetapkan alarm pada metrik utama EC2. StatusCheckFailed_System, StatusCheckFailed_Instance dan StatusCheckFailed_AttachedEBS sangat penting, terkait dengan tindakan pemulihan, mulai ulang, failover, atau penggantian melalui Penskalaan Otomatis, sesuai dengan SLA Anda.
Dan jika konsol menolak, ingat daftar periksa: Periksa acara Kesehatan di wilayah yang benar, bersihkan cache dan kuki Anda, ganti peramban Anda, dan konfirmasikan dengan tim TI bahwa domain AWS tidak diblokir. Pemeriksaan sederhana ini menyelesaikan lebih dari yang Anda duga.
Sumber Daya Terkait dan Bantuan Akun
Untuk memperluas dan memperkuat operasi Anda, tinjau dokumentasi untuk layanan yang terlibat. AWS Health dan EventBridge untuk perutean peristiwa, ACM untuk pembaruan, dan referensi CloudWatch/EC2 untuk metrik dan tindakan., membentuk perlengkapan yang kuat.
- Dasbor Kesehatan AWS: Visibilitas acara publik dan akun tertentu, tanpa memerlukan konfigurasi tambahan.
- Jembatan Acara Amazon: Penyerapan peristiwa kesehatan yang andal dengan aturan fleksibel untuk perutean ke beberapa tujuan.
- Manajer Sertifikat AWS (ACM): Pelacakan status pembaruan dan pemberitahuan bertahap sebelum kedaluwarsa.
- Amazon EC2 + CloudWatch: Pemeriksaan per menit, metrik status, dan alarm yang memicu respons otomatis.
Jika Anda memiliki pertanyaan tentang mengakses atau mengelola akun Anda, silakan lihat artikel dukungan yang paling umum: Cara membuat dan mengaktifkan akun baru, cara masuk ke konsol, dan cara meminta bantuan dengan akun dan sumber daya Anda.Menemukannya akan mempercepat proses jika ada yang tidak sesuai.
Melihat satu panel saja tidak akan pernah menceritakan keseluruhan cerita: Memeriksa kesehatan AWS memerlukan penggabungan konteks Health Dashboard, penyerapan yang andal dengan EventBridge, sinyal ACM, dan pemeriksaan EC2.Dengan alarm yang dirancang secara matang dan buku petunjuk yang jelas, diagnosis datang lebih cepat, respons lebih akurat, dan operasi menjadi jauh lebih lancar bahkan saat lalu lintas meningkat atau terjadi kerusuhan regional.
