Amazon Web Services は現在ダウンしていますか?

Amazon Web Servicesで問題が発生していますか?AWS Healthで該当するサービスまたはリージョンのインシデントを確認し、問題がアカウント、ワークロード、設定、ネットワーク経路のどこに限定されているかを切り分けます。

SA

Site Administrator

最終レビュー: September 25, 2026

最新の記録ステータス

稼働中 直近のチェックでは、Amazon Web Services のWebサイトは稼働し、正常に応答しているようでした。

Webサイト (aws.amazon.com) 稼働中
応答時間 143 ms
最終確認 2026-11-09 14:04:48 UTC
現在のエンドポイント観測
エンドポイント状態観測時刻
aws.amazon.comOperational2026-11-09 14:04 UTC

あなたの環境では動作していますか?

最近の報告は 0 件です。傾向を示すにはもう少しデータが必要です。

単一の外部チェックでは見逃す可能性がある部分的・地域的な障害も含めて確認するには、Amazon Web Services の公式ステータスページも参照してください。 公式ステータスページ.

この確認で分かること

  • 本番環境の設定を変更したり、リソースを再デプロイしたりする前に、AWS Healthを確認する。
  • 障害をAWSの正確なサービス、リージョン、アカウントまたは環境、リソースと照合する。AWSプラットフォーム全体の可用性は一様ではない。
  • タイムアウト、接続拒否、HTTP 5xxレスポンスは、アプリケーション、プロキシ、ロードバランサー、DNS、ルーティング、セキュリティルール、AWSリソースが原因である可能性がある。
  • 一致するインシデントが一覧にない場合は、安全な範囲で、失敗しているリクエストを正常なワークロード、エンドポイント、リージョン、ネットワークと比較する。
  • エスカレーションする前に、サービス、リージョン、リソース、タイムスタンプ、操作、正確なエラー、リクエストIDまたは相関ID、最近の変更を記録する。
Amazon Web Services live status check banner

Amazon Web Services の信頼性について

AWSの可用性の仕組み

Amazon Web Servicesは、アカウント、リージョン、アベイラビリティーゾーンにまたがって稼働するクラウドサービスの集合体です。1つのアプリケーションに、全体で共通する単一の稼働状態があるわけではありません。特定のサービスやリージョンに影響するインシデントが発生していても、ほかのAWSワークロードは正常に動作している場合があります。

まず、AWS公式のHealthステータスページを確認します。表示されたイベントと、影響を受けているサービス、リージョン、リソース、アカウントまたは環境、およびおおよその障害発生時刻を照合してください。一致するイベントがない場合は、AWS全体の障害と判断する前に、アカウント固有、ワークロード、設定、接続に起因する可能性を調査します。

公開ステータスページが正常でも、すべてのリソースが正常であるとは限りません。認証情報、権限、DNS、ルーティング、セキュリティ制御、エンドポイントの選択、デプロイの変更、アプリケーションコードは、AWSを利用するサービスの状態に影響する可能性があります。

Amazon Web Services のトラブルシューティング

AWSの障害をトラブルシューティングする

1. サービスまたはリージョンのインシデントを確認する

AWS公式のHealthステータスページを開き、影響を受けているサービス、リージョン、およびおおよその発生時刻に一致するイベントを探します。一致するイベントがあれば、プロバイダー側の問題である可能性が高くなります。インシデントの調査中は、本番環境の設定を繰り返し変更したり、リソースを再デプロイしたりしないでください。

一致するイベントが表示されない場合、問題は1つのアカウント、ワークロード、リージョン、リソース、またはネットワーク経路に限定されている可能性があります。

2. 障害が発生しているレイヤーを特定する

AWSコンソールを開く、コードをデプロイする、ホスト名を解決する、AWSエンドポイントを呼び出す、ストレージから読み取る、データベースに接続するといった、失敗している操作を正確に定義します。同じリージョン内にある、関係のないリソースやサービスが動作しているか確認してください。

障害と、最近行ったデプロイや設定変更を照合します。ログで、正確なAWSエラー、リクエスト時刻、リージョン、リソース識別子、操作を確認してください。HTTP 5xxレスポンスだけでは、AWSが停止していることは示されません。アプリケーション、プロキシ、ロードバランサー、ゲートウェイが生成した可能性もあります。

3. アカウント、権限、設定に起因する原因を確認する

1つのアカウント、環境、またはリソースに限定された障害では、選択中のリージョン、リソースの状態、認証情報、権限、エンドポイント、クォータ、最近のインフラ変更を確認します。アプリケーションが意図したアカウントとリージョンを使用していることを確認してください。あるIDやデプロイだけが失敗し、正常な経路では動作する場合は、プラットフォーム全体の問題と考える前に、アクセスと設定を調査します。

4. ブラウザーとコンソール固有の問題を確認する

AWSコンソールまたはホストされたアプリケーションが1つのブラウザーや1台のデバイスだけで失敗する場合は、プライベートウィンドウ、別の対応ブラウザー、または別のデバイスを試します。サイトデータを消去する前に、画面に表示されたエラーを記録してください。コンソールだけの問題であり、基盤となるAWSリソースの状態とは別の場合があります。

5. ネットワーク、DNS、接続を確認する

可能であれば、2つ目のネットワークからテストします。影響を受けているホスト名について、DNS解決、TLSネゴシエーション、接続動作を比較してください。DNS障害、接続拒否、証明書エラー、タイムアウトは、ローカルDNS、VPNまたはプロキシ設定、ファイアウォールルール、ルーティング、セキュリティグループ、ネットワークACL、ロードバランサーのリスナー、接続先アプリケーションが原因で発生する可能性があります。

別のネットワークやリージョンからリクエストが成功する場合は、グローバルな障害と決めつけず、クライアントとAWSの間の経路を調査してください。

6. SDK、CLI、Webhook、自動化の障害を確認する

エラーの種類と操作の全体を記録します。認証または認可のエラーを、スロットリング、バリデーション、エンドポイント、タイムアウト、サーバー側のエラーと区別してください。設定されたリージョンとエンドポイントを確認し、繰り返しても安全な操作の場合にのみ再試行します。本番環境の変更では、トラブルシューティングやサポートへのエスカレーションに備えて、リクエストIDとタイムスタンプを保存してください。

情報源・参考資料

公式ソース

  • AWS Healthのステータス — AWSのサービスまたはリージョンで現在発生している可用性イベントを確認します。

現在の可用性情報にはステータスページを使用してください。アカウント固有またはワークロード固有の障害を診断するには、ログ、デプロイ履歴、エラーの詳細、ネットワークテストが必要です。

この確認の仕組み

このライブチェックは当社サーバーから実行されるため、すべての地域、アカウント、機能、ネットワーク経路を反映するとは限りません。

ライブステータスバッジを埋め込む

ダッシュボード、ドキュメント、ブログに追加できます。Erriscope のキャッシュ済み観測結果を表示し、このステータスページへリンクします。

Amazon Web Services status on Erriscope
<a href="https://erriscope.com/ja/status/aws/"><img src="https://erriscope.com/status/badge/aws.svg" alt="Amazon Web Services status on Erriscope" width="210" height="34"></a>

よくある質問

AWSが停止しているかどうかを確認するにはどうすればよいですか?

AWS公式のHealthステータスページで、影響を受けているサービス、リージョン、障害発生時刻に一致するイベントを確認します。1つのAWSサービスまたはリージョンで発生したインシデントが、プラットフォーム全体に影響するとは限りません。

AWSにインシデントが表示されていないのに、アプリケーションが停止しているのはなぜですか?

障害は、アカウント、リソース、デプロイ、認証情報、権限、アプリケーション、DNS、ネットワーク経路に限定されている可能性があります。ステータスページが問題を説明していると結論づける前に、正確に失敗している操作を特定し、正常なワークロードや経路と比較してください。

AWSのタイムアウトは、AWSの障害を証明しますか?

いいえ。タイムアウトは、クライアントとAWSの間、プロキシやロードバランサー、ネットワーク制御、または接続先アプリケーション内で発生する可能性があります。可能であれば別のネットワークからテストし、リージョン、エンドポイント、タイムスタンプ、完全なエラーを記録してください。

AWSのエラーをエスカレーションする前に、どのような情報を収集すべきですか?

影響を受けているサービス、リージョン、アカウントまたは環境、リソース、操作、タイムスタンプ、リクエストIDまたは相関ID、正確なエラーテキスト、最近の変更、別のネットワークやワークロードからも障害が発生するかどうかを記録します。

AWSサービスで障害が発生しているとき、再デプロイすべきですか?

自動的に再デプロイすべきではありません。まずAWS Healthを確認し、証拠を収集してください。実際の原因がプロバイダーのインシデント、認証情報の問題、権限の問題、ネットワーク障害、リージョン設定である場合、再デプロイによって元の障害が分かりにくくなったり、別の変更が発生したりする可能性があります。

AWSを利用するサイトが利用できないとき、どのようなエラーが表示される可能性がありますか?

障害が発生しているレイヤーによって、HTTP 500、502、503、504レスポンス、接続拒否、DNSエラー、タイムアウトなどが表示される場合があります。これらのメッセージはリクエストが失敗した場所を示すものであり、根本原因やAWS全体で広範な障害が発生しているかどうかを必ずしも示すものではありません。

← すべてのサービスへ戻る

このライブチェックは当社サーバーから実行されるため、すべての地域、アカウント、機能、ネットワーク経路を反映するとは限りません。