翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Direct Connect メンテナンス
Direct Connect は、サービスのセキュリティ、可用性、スケーラビリティの確保に取り組んでいます。これらの標準を維持するには、ハードウェアネットワークデバイスの定期的なメンテナンスが必要です。Direct Connect のメンテナンスには、計画的と緊急の 2 種類があります。
これらのメンテナンスイベントには、セキュリティの脆弱性とハードウェアの問題への対応、標準に準拠するためのデバイス移行の実行、欠陥の修正、新機能の提供が含まれます。「メンテナンスイベントの準備」で説明されているプラクティスに従うことで、メンテナンスイベント中の中断を避けられるよう Direct Connect 環境をより適切に準備できます。回復力のないネットワーク設定または 1 つの接続がある場合、オンプレミスネットワークと AWS リソース間の接続が中断されます。
Direct Connect は、Direct Connect 接続または仮想インターフェイスリソースを所有する AWS アカウントに関連付けられた E メールアドレスに、計画されたメンテナンスイベントと緊急メンテナンスイベントに関する E メール通知を送信します。お客様がいずれかの Direct Connect デリバリーパートナーと共同で Direct Connect ホスト接続を使用している場合、メンテナンスイベントに関するメール通知はお客様とパートナーアカウントの両方に送信されます。通知を受け取るメールアドレスまたはディストリビューションリストを追加することもできます。詳細については、 AWS 「アカウントの代替連絡先の更新」を参照してください。
Direct Connect の計画的メンテナンス
計画的メンテナンスイベントには、可用性の向上と新機能の提供に必要なネットワークアップグレード (オペレーティングシステムのパッチ適用やハードウェアデバイスエンドポイントの設定更新など) が含まれます。
これらのメンテナンスイベントは 14 日前にスケジュールされ、通常はデバイスエンドポイントが存在する Direct Connect ロケーションでトラフィックが少ない時間帯に 4 時間の時間枠で実行されます。メンテナンスアクティビティは通常、4 時間の時間枠が完全に終了する前に完了し、作業が完了するとお客様に通知が届きます。まれに、予期しない状況が発生してメンテナンス期間の延長が必要になる場合、改訂された完了見積もりが記載された通知を別途送信します。
次のスケジュールを使用して、最初の通知とリマインダー通知がリソースを所有する AWS アカウントに送信されます。
-
計画的メンテナンスイベントの 14 暦日前
-
計画的メンテナンスイベントの 7 暦日前
-
計画的メンテナンスイベントの 1 日前
注記
暦日には、非営業日と現地の祝日が含まれます。
加えて、
-
AWS Healthと統合すると、お使いのモニタリングシステムまたはチケットシステムに通知が届きます。統合するには AWS Health、AWS Health 「 ユーザーガイド」の「Amazon EventBridge AWS Health を使用した でのイベントのモニタリング」を参照してください。
-
Health Dashboard
に計画的メンテナンスのスケジュールが表示されます。
まれに、計画的メンテナンスイベントをスケジュールどおりに実行できない状況が発生することがあります。これが発生した場合、キャンセル通知を送信するので、上記と同じプロセスに従って今後のイベントを再スケジュールします。
Direct Connect の緊急メンテナンス
緊急メンテナンスイベントは、サービスに影響を及ぼす差し迫ったイベントを防止したり、既に接続の中断を引き起こしている障害を解決したりするために、緊急ベースで開始されます。このような場合は、影響を受けているエンドポイントを正常な状態に復元するためにすぐにアクションを実行する必要があります。
可能な限り事前に通知するよう努めますが、状況によってはメンテナンスをすぐに開始しなければならない場合があります。緊急メンテナンスがスケジュールされるか、既に開始されたとき、および完了したときにお客様に通知が届きます。
これらのイベントは通常、デバイスエンドポイントが存在する Direct Connect ロケーションで 2 時間の時間枠で実行されます。メンテナンスアクティビティは通常、この時間枠内に完了します。予期しない状況 (ハードウェアの交換など) が発生してメンテナンス期間の延長が必要になる場合、改訂された完了見積もりが記載された通知を別途送信します。
サードパーティーのメンテナンス
AWS 開始されたメンテナンスイベント以外にも、オンプレミスから Direct Connect ロケーションへのネットワーク接続を提供している Direct Connect 配信パートナーまたはネットワークサービスプロバイダーがメンテナンスアクティビティを実行する場合があります。Direct Connect 配信パートナーは からメンテナンスイベント通知を受け取り AWS 、重複を避けるために独自のメンテナンススケジュールを計画できます。 AWS はパートナーのメンテナンスアクティビティを可視化できないため、スケジューリングプロセス、通知方法、ベストプラクティスについて確認する必要があります。
メンテナンスイベントの準備
メンテナンスイベント中に本稼働ワークロードが引き続き機能するように、Direct Connect では AWS Direct Connect Resiliency Toolkit を使用してネットワーク接続を最大耐障害性に設定することをお勧めします。最大回復性モデルの例については、「最大回復性」を参照してください。
最大限の回復性では、接続は 2 つ以上の Direct Connect ロケーションに分散され、各 Direct Connect ロケーション内にある 2 つの一意のデバイスエンドポイントで終了します。これにより、複数の冗長性レイヤーが提供され、単一エンドポイントの障害のリスクが軽減されるとともに、メンテナンスイベント中に接続を維持することが可能になります。Direct Connect は、複数の冗長接続を同時に停止させる計画的メンテナンスイベントをスケジュールすることは決してありません。 AWS Direct Connect Resiliency Toolkit を使用して最大回復性を設定する手順については、「」を参照してください最大限の回復性を設定する。
計画的メンテナンスイベント中、Direct Connect はメンテナンス中の接続エンドポイントとの間で送受信されるトラフィックをドレインし、トラフィックに冗長接続を使用するよう強制します。これにより、最大限の回復性が設定されていない場合の手動介入を必要とせずに、よりシームレスなネットワークトラフィックの再ルーティングが可能になります。または、ローカル優先設定のボーダーゲートウェイプロトコル (BGP) コミュニティを使用して、メンテナンス期間中の冗長接続間のトラフィック再ルーティングを制御することもできます。BGP コミュニティの詳細については、「ルーティングポリシーと BGP コミュニティ」を参照してください。
最大回復性モデルを使用して Direct Connect 環境を設定することで、メンテナンスイベントやインフラストラクチャの障害の際にビジネスが影響が受けないようにすることができます。適切に実装およびテストされている場合、通常はこれらのメンテナンスイベントについて何らかのアクションを実行する必要はありません。
回復性の検証
Direct Connect 環境が回復性を備えるように設定している場合は、接続が中断されたときにトラフィックが他の冗長接続を介してルーティングされることを定期的に検証します。定期的なプロアクティブテストは、実際のメンテナンスイベントまたは障害シナリオの際に潜在的な問題が本番稼働ワークロードに影響を与える前に、それらの問題を特定して解決するのに役立ちます。これにより、メンテナンスイベント中のネットワークの信頼性に対する自信が高まります。Direct Connect フェイルオーバーテストを使用して、冗長接続の回復性を検証します。 Direct Connect フェイルオーバーテストを使用する手順については、「Direct Connect フェイルオーバーテスト」を参照してください。
Amazon CloudWatch Network Monitor を活用して、Direct Connect 接続をアクティブにモニタリングすることもできます。詳細については、「Amazon CloudWatch Network Synthetic Monitor によるハイブリッド接続のモニタリング
オープンソースのサンプルソリューションである Network Resilience Agent を使用して、回復力のベストプラクティスに照らして Direct Connect トポロジーを検出、視覚化、評価することもできます。詳細については、「」の「Network Resilience Agent
メンテナンスイベントの延期またはキャンセルのリクエスト
Direct Connect デバイスは複数のお客様の間で共有されます。そのため、メンテナンスの再スケジュールやキャンセルに関する特定のリクエストには対応していません。あるお客様のリクエストを再スケジュールまたはキャンセルすると、そのエンドポイントを使用している他のお客様に悪影響が及ぶ可能性があります。また、可用性やセキュリティの問題をタイムリーに軽減する上でリスクが生じる可能性もあります。