すべてのプロダクト
Search

このプロダクト

    Server Load Balancer:ALB Health Checks

    ドキュメントセンター

    Server Load Balancer:ALB Health Checks

    最終更新日:Mar 20, 2026

    Application Load Balancer (ALB) は、ヘルスチェックを使用してバックエンドサーバーのステータスを継続的に監視します。ALB は、ビジネスの可用性を確保するために、異常なサーバーをサービスから自動的に削除します。

    各サーバーグループでヘルスチェックを個別に設定できます。ヘルスチェックは、すべてのサーバーグループでデフォルトで有効になっています。

    • ヘルスチェックを有効にすると、ALB はサーバーグループ内のすべてのバックエンドサーバーを継続的に監視し、正常なサーバーにのみリクエストをルーティングします。バックエンドサーバーは、正常と宣言される前に、指定された回数 (正常しきい値) のヘルスチェックに連続して合格する必要があります。これにより、ネットワークジッターによって引き起こされる誤検知を防ぎます。

    • バックエンドサーバーがヘルスチェックに失敗した場合、ALB は自動的に新しいリクエストを他の健全なバックエンドサーバーにルーティングします。

    • サーバーが回復すると、ALB は自動的にそのサーバーを負荷分散サービスに戻します。

    • ヘルスチェックでは短時間接続を使用します。ヘルスチェックが完了すると、接続は閉じられます。

    • サーバーグループ内のすべてのバックエンドサーバーがヘルスチェックに失敗した場合でも、ALB はスケジューリングアルゴリズムに基づいてそれらにリクエストをルーティングしようとします。これにより、サービスの中断を最小限に抑えます。

    説明

    • 重みが 0 のバックエンドサーバーは、ヘルスチェックに参加しません。

    • ALB は、特定の IP アドレスを使用してバックエンドサーバーと通信し、ヘルスチェックを実行します。バックエンドサーバーがこれらの IP アドレスをブロックしないようにしてください (iptables ルールやサードパーティのセキュリティソフトウェアを含む)。

      • スペックアップされた ALB インスタンスは、vSwitch CIDR ブロック (ローカル IP) からのプライベート IP アドレスを使用してバックエンドサーバーと通信します。これらのローカル IP は、インスタンス詳細ページで確認できます。

      • スペックアップされていない ALB インスタンスは、100.64.0.0/10 CIDR ブロック内の IP アドレスを使用してバックエンドサーバーと通信します。

    ヘルスチェックの作成

    コンソール

    1. ALB コンソールの [ヘルスチェック] ページに移動します。

    2. 上部のナビゲーションバーでターゲットリージョンを選択し、ヘルスチェックの作成 をクリックします。次のパラメーターを設定し、作成 をクリックします。

      • ヘルスチェック名: ヘルスチェックの名前を入力します。

      • プロトコル: ヘルスチェックプロトコルを選択します。

        • HTTP: ALB は、HEAD または GET リクエストを送信して、バックエンドサーバーアプリケーションが正常であるかを確認します。

        • [HTTPS]: ALB は HEAD または GET リクエストを送信して、バックエンドサーバーアプリケーションが正常であることを確認します。Standard および WAF 強化型 ALB インスタンスでサポートされています。Basic ALB インスタンスではサポートされていません。

        • TCP: ALB は、バックエンドサーバーのポートが利用可能であることを確認するために、SYN ハンドシェイクパケットを送信します。

        • gRPC: ALB は POST または GET リクエストを送信して、バックエンドサーバーアプリケーションが正常であるかを確認します。

      • ヘルスチェック方法: ヘルスチェックプロトコルがHTTP、HTTPS、またはgRPCの場合にのみ設定可能です。

        • [HEAD] (HTTP/HTTPS のデフォルト): バックエンドサーバーが HEAD リクエストをサポートしていることを確認してください。サポートしていない場合は、代わりに GET を使用してください。

        • [POST] (gRPC のデフォルト): バックエンドサーバーが POST リクエストをサポートしていることを確認してください。サポートしていない場合は、代わりに GET を使用してください。

        • [GET]: 8 KB を超える応答は切り捨てられますが、これはヘルスチェックの結果には影響しません。

      • HTTP バージョン: HTTP1.0 または HTTP1.1 を選択します。ヘルスチェックプロトコルが HTTP または HTTPS の場合にのみ設定できます。

      • ポート: ヘルスチェックに使用するポートです。空白のままにすると、バックエンドサーバーのポートが使用されます。有効値: 1～65535。ポート番号は 1 つのみ入力してください。

      • パス: ヘルスチェック用のパス（例: /health）。静的ページの使用を推奨します。空欄の場合は、ALB がルートパス（/）をチェックします。ヘルスチェックプロトコルが HTTP、HTTPS、または gRPC の場合にのみ設定可能です。

      • ドメイン名：ヘルスチェックに使用するドメイン名です。デフォルトでは、ALB はバックエンドサーバーのプライベート IP アドレスを使用します。ヘルスチェックプロトコルが HTTP、HTTPS、または gRPC の場合にのみ設定できます。

      • ヘルスチェックステータスコード: ALB は、ヘルスチェックリクエストが指定された状態コードのいずれかを返した場合にのみ、バックエンドサーバーを健全と見なします。ヘルスチェックプロトコルが HTTP、HTTPS、または gRPC の場合にのみ設定可能です。

        • HTTP または HTTPS の場合: http_2xx、http_3xx、http_4xx、または http_5xx を選択します。デフォルト: http_2xx および http_3xx。

        • gRPC の場合: 有効な状態コード: 0～99。最大 20 個の値の範囲をコンマ (,) で区切って指定できます。

        警告

        ヘルスチェック状態コードリストに 4XX または 5XX の状態コードを含めると、異常なインスタンスが迅速に削除されない可能性があります。バックエンドサービスが正しい 2XX または 3XX の状態コードを返すようにすることを推奨します。

      • ヘルスチェック応答タイムアウト：この時間内にバックエンドサーバーが有効な応答を返さない場合、ヘルスチェックは失敗します。有効値：1 ～ 300 秒。デフォルト：5 秒。

      • ヘルスチェック間隔：連続するヘルスチェック間の時間。有効な値：1〜50 秒。デフォルト：2 秒。

      • 正常しきい値: バックエンドサーバーを正常と宣言する前に必要な、連続成功ヘルスチェックの回数です。有効な値: 2～10。デフォルト: 3。

      • 異常しきい値: バックエンドサーバーを異常と判断するために必要な、連続して失敗したヘルスチェックの回数です。 有効値: 2～10。 デフォルト: 3。

      • タグとリソースグループ：

        • タグキー および タグ値: ヘルスチェックにキーと値のペアを付与して、フィルター処理および管理を容易にします。

        • リソースグループ: ヘルスチェック用のリソースグループを選択します。

    ヘルスチェックを作成したら、サーバーグループを作成する際に、ヘルスチェックの設定 セクションでそれを選択します。

    また、サーバーグループの作成時にヘルスチェックを設定でき、ヘルスチェックとして新しい設定を保存すると、次回クイックコピーして使用できます。

    API

    1. CreateHealthCheckTemplate を呼び出して、ヘルスチェックテンプレートを作成します。

    2. ApplyHealthCheckTemplateToServerGroup を呼び出して、ヘルスチェックテンプレートをサーバーグループに適用します。

    ヘルスチェックの変更

    警告

    • ヘルスチェックを無効化すると、ALB はバックエンドサーバーの健全性状態を監視しなくなります。バックエンドサーバーが停止した場合、ネットワークトラフィックを自動的に健全なバックエンドサーバーに切り替えることができません。

    • ヘルスチェックの間隔を長く設定すると、ALB が不健全なバックエンドサーバーを検出するまでに要する時間が長くなります。

    コンソール

    1. ALB コンソールの ヘルスチェック ページへ移動します。

    2. 対象のヘルスチェックを特定し、操作 列の 編集 をクリックします。

    3. ヘルスチェック設定の変更 ダイアログボックスで設定項目を変更し、保存 をクリックします。

    また、サーバーグループページでヘルスチェックを編集することもできます。

    API

    UpdateHealthCheckTemplateAttribute API を呼び出して、ヘルスチェックテンプレートの属性を更新します。

    ヘルスチェックステータスの確認

    ALB インスタンスにリスナーが設定されており、そのサーバーグループに対してヘルスチェックが有効になっている場合、リスナー タブでヘルスチェックステータスを確認できます。

    コンソール

    1. ALB コンソールの [インスタンス] ページへ移動します。

    2. 対象の ALB インスタンスを見つけ、そのインスタンス ID をクリックします。

    3. リスナー タブをクリックします。リスナーリストの ヘルスチェックステータス 列で、バックエンドサーバーのヘルスチェックステータスを確認します。

    API

    GetListenerHealthStatus API を呼び出して、リスナーのヘルスチェックステータスをクエリします。

    ヘルスチェックの削除

    コンソール

    1. ALB コンソールで、 [ヘルスチェック] ページに移動します。

    2. 対象のヘルスチェックを探し、操作 列の 削除 をクリックします。

    3. 削除 ダイアログボックスで、メッセージを確認し、OK をクリックします。

    API

    DeleteHealthCheckTemplates を呼び出してヘルスチェックテンプレートを削除します。

    本番運用時の注意点

    • 専用のヘルスチェックエンドポイントを作成する：常に HTTP 200 を返す専用のインタフェイス（例：/health）を作成します。権限検証やリソースの不足などにより 4XX を返す可能性のあるビジネスパスは使用しないでください。

    • ヘルスチェック失敗時にバックエンドサービスを優先的に修正する：ヘルスチェックパスが正しい 2XX または 3XX の状態コードを返すよう、バックエンドサービスの問題を特定・修正してください。状態コードの判定基準を緩和しないでください。

    • ヘルスチェックパラメーターを適切に構成する：デフォルト設定はほとんどのシナリオで有効です。バックエンドサービスの起動が遅い場合は、ヘルスチェック間隔または異常しきい値を増加させます。ネットワーク遅延が高い場合は、応答タイムアウトを増加させます。

    • curl を使用してヘルスチェックをシミュレートする：ヘルスチェックの問題をトラブルシューティングする際は、以下のコマンドを使用して ALB のヘルスチェック動作をシミュレートします。実際の構成に応じて、メソッド（HEAD/GET）、ドメイン名、IP アドレス、ポート、およびパスを置き換えてください：

      curl -Iv -X HEAD --http1.0 -H "Host: your-domain.com" http://backend_ip:port/health_path

    課金

    ヘルスチェックに追加料金は発生しません。ALB の課金ルールについては、「ALB の課金情報」をご参照ください。

    クォータ

    リージョンごとに最大 50 個のヘルスチェックテンプレートを作成できます。このクォータは増やすことはできません。

    参照