すべてのプロダクト
Search
ドキュメントセンター

Virtual Private Cloud:ルートターゲットグループ

最終更新日:Feb 26, 2026

Gateway Load Balancer エンドポイント (GWLBe) などのゾーンレベルのクラウドサービスをルートのネクストホップとして使用する場合、プライマリゾーンが障害を起こすと、通常は手動でトラフィックをセカンダリインスタンスにリダイレクトする必要があります。ルートターゲットグループを使用すると、2 つのネクストホップインスタンスをプライマリセカンダリモードで構成できます。システムは各インスタンスのヘルス状態を継続的に監視し、インスタンスの状態が異常になると、自動的にゾーンレベルのディザスタリカバリスイッチオーバーを実行します。これにより、目標復旧時間 (RTO) を短縮できます。

仕組み

image
  1. プライマリセカンダリモード:ルートターゲットグループを作成する際には、異なるゾーンに同じタイプのプライマリインスタンスとセカンダリインスタンスをそれぞれ 1 つずつ構成する必要があります。

    • プライマリインスタンス:重みは 100 です。正常な状態ではすべてのトラフィックを処理し、ヘルスチェックが成功している間はアクティブのままになります。

    • セカンダリインスタンス:重みは 0 です。プライマリインスタンスが障害を起こした場合にトラフィックを引き継ぎ、ディザスタリカバリ用のバックアップとして機能します。

  2. ヘルスチェック:ルートターゲットグループはヘルスチェックメカニズムを使用して、プライマリおよびセカンダリインスタンスの可用性を継続的にプローブします。これにより、障害を正確に検出し、トラフィックを切り替えることが可能になります。

    • 障害検出:ヘルスチェックが対象インスタンスのプローブに 3 回連続で失敗すると、システムはそのインスタンスを Unhealthy とマークします。プライマリインスタンスが Unhealthy になった場合、セカンダリインスタンスへのスイッチオーバーが自動的にトリガーされます。

    • 障害回復:Unhealthy となったインスタンスが回復した後、ヘルスチェックが 3 回連続で成功すると、システムはそのインスタンスを Healthy とマークします。

  3. スイッチオーバー

    • 自動スイッチオーバー:ヘルスチェックによってプライマリインスタンスが利用不可であると検出された場合、システムは自動的にルートのネクストホップトラフィックをセカンダリインスタンスに切り替えます。

    • 手動フェイルバック:計画的なメンテナンスや災害復旧訓練、またはプライマリインスタンスの回復後に手動で切り戻す場合に使用します。

    • 自動フェイルバックはサポートされていません:プライマリインスタンスのネットワークジッターによって頻繁に自動スイッチオーバーが発生し、サービスが不安定になることを防ぐため、ルートターゲットグループはプライマリインスタンスが回復しても自動的にトラフィックをプライマリに戻しません。プライマリインスタンスが Healthy になった後は、オフピーク時間帯に手動でフェイルバックを実行できます。

    スイッチオーバーシナリオ

    トリガー方法

    スイッチオーバー時間

    フェイルオーバー

    自動 (ヘルスチェックによるトリガー)

    < 30s

    フェイルバック

    手動フェイルバック

    < 10s

適用範囲

  • サポートされるターゲットインスタンスタイプ:現在、Gateway Load Balancer エンドポイント (GWLBe) のみがサポートされています。

  • インスタンスデプロイメント要件:プライマリインスタンスとセカンダリインスタンスをそれぞれ 1 つずつ構成する必要があります。両方のインスタンスは同一の仮想プライベートクラウド (VPC) に属し、異なるゾーンにデプロイされている必要があります。これにより、クロスゾーンディザスタリカバリが可能になります。

  • クォータ制限:1 つの VPC 内で最大 10 個のルートターゲットグループを作成できます。

ルートベースのディザスタリカバリの構成

ルートエントリーのネクストホップをルートターゲットグループに設定します。その後、トラフィックはルートターゲットグループ内の現在アクティブなインスタンスに基づいて転送されます。インスタンスの状態が Unhealthy になると、システムは自動的にゾーンレベルのディザスタリカバリスイッチオーバーを実行します。

  • IPv4 ルートエントリーのみが、ネクストホップとしてルートターゲットグループを設定することをサポートしています。

  • ルートターゲットグループがネクストホップとして使用される場合、サポートされるルーティング操作はそのメンバーがサポートする操作と同じです。たとえば、ゲートウェイルートテーブルのシステムルートでは、ネクストホップを GWLBe に変更できます。GWLBe がルートターゲットグループのメンバーである場合、そのルートターゲットグループもゲートウェイルートテーブルのシステムルートのネクストホップとして使用できます。

コンソール

  1. ルートターゲットグループを作成します。VPC - Route Target Groups ページに移動し、Create Target Group をクリックします。

    • VPC:ターゲットインスタンスが存在する VPC を選択します。

    • Mode:現在、Active/Standby Mode のみがサポートされています。

    • Member Type: 現在、GWLB エンドポイントのみがサポートされています。

    • Member:異なるゾーンにデプロイされたプライマリおよびセカンダリインスタンスを選択します。

      構成が完了した後、ルートターゲットグループの製品ページに移動し、Modify Member を選択して非アクティブなインスタンスを変更できます。アクティブなインスタンスは編集できません。

    • インスタンス名所属するリソースグループとタグ:データ分類に使用します。

  2. ルートエントリーをルートターゲットグループに向けるように構成します。

    1. VPC - Route Tables ページに移動し、対象のルートテーブル ID を選択します。

    2. カスタムルート タブで、ルートエントリの追加 を選択します。

      • ターゲット CIDR:プライマリおよびセカンダリインスタンス経由でトラフィックを転送する宛先 CIDR ブロックを指定します。

      • ネクストホップの種類Route Target Group を選択します。

API

  1. CreateRouteTargetGroup を呼び出して、ルートターゲットグループを作成します。

  2. CreateRouteEntry を呼び出してカスタムルートエントリーを作成します。NextHopTypeRouteTargetGroup に設定します。

手動でのスイッチオーバーの実行

  • シナリオ:

    • 災害復旧訓練や計画的なメンテナンスのために、プライマリインスタンスとセカンダリインスタンス間のトラフィック切り替えを手動でトリガーします。

    • プライマリインスタンスのネットワークジッターによって頻繁に自動スイッチオーバーが発生し、サービスが不安定になることを防ぐため、ルートターゲットグループはプライマリインスタンスが回復しても自動的にトラフィックをプライマリに戻しません。プライマリインスタンスが Healthy になった後は、オフピーク時間帯に手動でフェイルバックを実行できます。

  • 機能制限:非アクティブなインスタンスが Unhealthy の場合は、スイッチオーバーを実行できません。

コンソール

  1. VPC - Route Target Groups ページに移動し、ルートターゲットグループ ID をクリックします。

  2. ページ右上隅の Switch Member をクリックします。

API

SwitchActiveRouteTarget を呼び出して、ルートターゲットグループのスイッチオーバーを実行します。

課金

ルートターゲットグループ機能は無料です。

ターゲットインスタンス(現在は GWLBe のみがサポートされています)およびそのバックエンドサービスについては課金されます。詳細については、「PrivateLink 課金」および「GWLB 課金ルール」をご参照ください。

本番環境に適用

  • 接続中断のリスク:持続的接続ファイアウォールや NAT セッションなどステートフルアプリケーションの場合、スイッチオーバーによって既存の接続が中断されます。サービス側でこれらの接続を再確立する必要があります。再接続メカニズムの実装を検討し、スイッチオーバーがサービスに与える瞬間的な影響を十分に評価してください。

  • 災害復旧訓練:サービストラフィックをグループに導入する前に、オフピーク時間帯またはメンテナンスウィンドウ中に手動スイッチオーバーを実行してください。これにより、セカンダリリンクの可用性、セキュリティグループポリシー、バックエンドサービスを検証する災害復旧訓練を実施できます。これにより、障害発生時にバックアップパスが期待通りに動作することを保証できます。