翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Outposts ラックメンテナンス
[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)の下で、 AWS は AWS サービスを実行するハードウェアとソフトウェアを担当します。これは AWS Outposts、 AWS リージョンと同様に に適用されます。例えば、 は、セキュリティパッチ AWS の管理、ファームウェアの更新、Outpost 機器の保守を行います。 は、Outposts ラックのパフォーマンス、ヘルス、メトリクス AWS もモニタリングし、メンテナンスが必要かどうかを判断します。
**警告**
インスタンスストアボリュームのデータは、基盤となるディスクドライブが故障した場合、またはインスタンスが 停止、休止状態、または終了した場合に失われます。データ損失を防ぐために、インスタンスストアボリューム上の長期データを Amazon S3 バケット、Amazon EBSボリューム、またはオンプレミスネットワーク内のネットワークストレージデバイスなどの永続的なストレージにバックアップすることをお勧めします。
**Topics**
+ [連絡先の情報を更新する](#outpost-owner-update)
+ [ハードウェアメンテナンス](#outpost-hardware-maintenance-events)
+ [ファームウェアの更新](#outpost-firmware-updates)
+ [ネットワーク機器のメンテナンス](#outpost-network-equipment-maintenance)
+ [電力およびネットワーク イベントのベスト プラクティス](#outpost-power-network-events)
## 連絡先の情報を更新する
Outpost の所有者が変更された場合は、新しい所有者の名前と連絡先の情報を[AWS サポート センター](https://console.aws.amazon.com/support/home#/)までご連絡ください。
## ハードウェアメンテナンス
がサーバープロビジョニングプロセス中、または Outposts ラックで実行されている Amazon EC2 インスタンスをホスト中にハードウェアに回復不可能な問題 AWS を検出した場合、影響を受けるインスタンスのリタイアが予定されていることをインスタンスの所有者に通知します。詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスのリタイア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-retirement.html)」を参照してください。
Outpost の所有者とインスタンスの所有者は、共に問題を解決することができます。インスタンスの所有者は、影響を受けるインスタンスを停止してから再起動し、利用可能な容量に移行させることができます。インスタンスの所有者は、自分たちにとって便利なタイミングで影響を受けるインスタンスを停止および再起動できます。それ以外の場合、 はインスタンスの廃止日に影響を受けるインスタンス AWS を停止して開始します。Outpost に追加の容量がない場合、インスタンスは停止した状態のままとなります。Outpost の所有者は、使用済みの容量を解放するか、Outpost に追加の容量をリクエストして移行を完了させることができます。
ハードウェアのメンテナンスが必要な場合は、Outpost 所有者 AWS に連絡して、 AWS インストールチームが訪問する日時を確認します。訪問は、Outpost の所有者が AWS チームと話し合ってから最短で 2 営業日以内に計画できます。
AWS インストールチームが現場に到着すると、異常なホスト、スイッチ、またはラック要素が置き換えられ、新しい容量がオンラインになります。オンサイトでハードウェアの診断や修理を行うことはありません。ホストを交換すると、NIST 準拠の物理セキュリティ キーが削除および破壊され、ハードウェア上に残る可能性のあるデータが効果的にシュレッダー化されます。これにより、データがサイトから流出することがなくなります。Outpost ネットワーク デバイスを交換する場合、デバイスがサイトから削除されたときにネットワーク構成情報がデバイス上に存在する可能性があります。この情報には、ローカル ネットワークへのパス、またはリージョンへ戻るパスを構成するための仮想インターフェイスを確立するために使用される IP アドレスと ASN が含まれる場合があります。
## ファームウェアの更新
通常、Outpost ファームウェアを更新しても、Outpost 上のインスタンスには影響しません。まれに、アップデートをインストールするために Outpost 機器の再起動が必要になる場合があり、その容量で実行されているインスタンスについてインスタンスの廃止通知が届きます。
## ネットワーク機器のメンテナンス
Outpost ネットワーキングデバイス (OND) のメンテナンスは、通常の Outpost の運用やトラフィックに影響を与えずに実施されます。メンテナンスが必要な場合、トラフィックは OND から離れます。AS-Path の前置や、Outpost のアップリンクでのトラフィックパターンの対応する変更など、一時的な BGP 広告の変更が発生する可能性があります。OND ファームウェアの更新中には、BGP のフラッピングが発生する可能性があります。
お客様のネットワーク機器は、BGP 属性を変更せずに Outpost から BGP アドバタイズを受信し、BGP マルチパス/ロードバランシングを有効にして最適なインバウンドトラフィックフローを可能にすることをお勧めします。AS-Path のプリペンドは、メンテナンスが必要な場合にトラフィックを OND から離れるようにするために、ローカルゲートウェイのプレフィックスに使用されます。お客様のネットワークは、4 の AS-Path length のルートよりも、1 の AS-Path length の Outposts からのルートを優先する必要があります。
お客様のネットワークは、すべての OND に対して、同じ属性を持つ同じ BGP プレフィックスをアドバタイズする必要があります。デフォルトでは、Outpost ネットワークロードバランスはすべてのアップリンク間でアウトバウンドトラフィックの負荷分散を行います。Outpost 側では、メンテナンスが必要な場合にトラフィックを OND から移行するために、ルーティングポリシーが使用されます。このトラフィックのシフトには、すべての OND で顧客側からの等しい BGP プレフィックスが必要です。お客様のネットワークでメンテナンスが必要な場合は、AS-Path への付加を使用して、特定のアップリンクからのトラフィックを一時的に移行することをお勧めします。
## 電力およびネットワーク イベントのベスト プラクティス
AWS Outposts お客様向けの[AWS サービス条件](https://aws.amazon.com/service-terms/)に記載されているように、Outposts 機器が配置されている施設は、Outposts 機器のインストール、メンテナンス、使用をサポートするために、最小限の[電力](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-requirements.html#facility-power)と[ネットワーク](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-requirements.html#facility-networking)要件を満たしている必要があります。Outposts ラックは、電力供給とネットワーク接続が中断されない場合にのみ正常に動作します。
### 電力イベント
完全な停電では、 AWS Outposts リソースが自動的にサービスに戻らないという固有のリスクがあります。冗長電源およびバックアップ電源ソリューションの導入に加えて、最悪のシナリオの影響を軽減するために、事前に次のことを実行することをお勧めします。
+ 制御された方法で DNS ベースまたはラック外のロードバランシングの変更を使用して、サービスとアプリケーションを Outposts の機器から移動させてください。
+ コンテナ、インスタンス、データベースを順序立てて停止し、それらを復元する際には逆の順序を使用してください。
+ サービスの移動または停止を制御するためのテスト計画。
+ 重要なデータと構成をバックアップし、Outpost の外部に保存します。
+ 電源のダウンタイムを最小限に抑えます。
+ メンテナンス中は電源の切り替え (オフ、オン、オフ、オン) を繰り返さないでください。
+ 予期せぬ事態に対処するために、メンテナンス期間内に余分な時間を確保してください。
+ 通常必要とされるよりも広いメンテナンス時間枠を伝えることで、ユーザーや顧客の期待に応えます。
+ 電源が回復したら、[AWS サポート センター](https://console.aws.amazon.com/support/home#/)でケースを作成して、 AWS Outposts および関連サービスが実行されていることの検証をリクエストします。
### ネットワーク接続イベント
Outpost と AWS リージョンまたは Outposts ホームリージョン間のサービスリンク接続は、通常、ネットワークメンテナンスが完了すると、アップストリームの企業ネットワークデバイスまたはサードパーティーの接続プロバイダーのネットワークで発生する可能性のあるネットワークの中断や問題から自動的に回復します。サービス リンク接続がダウンしている間、Outposts の操作はローカル ネットワーク アクティビティに限定されます。
Outposts 上の Amazon EC2 インスタンス、ローカルゲートウェイ、および Amazon EBS ボリュームは引き続き正常に動作し、ローカルネットワークを介してローカルにアクセスできます。同様に、Amazon ECS ワーカーノードなどの AWS サービスリソースは引き続きローカルで実行されます。ただし、API の可用性は低下します。例えば、実行、開始、停止、終了 API は機能しない場合があります。インスタンスメトリクスとログは最大 7 日間ローカルにキャッシュされ、接続が戻ると AWS リージョンにプッシュされます。7 日以上切断すると、メトリクスとログが失われる可能性があります。
詳細については、「*施設のネットワーク接続が切断されたときはどうなりますか?*」という質問を参照してください。「[AWS Outposts ラックに関するよくある質問](https://aws.amazon.com/outposts/rack/faqs/#Support_.26_maintenance)」ページにあります。
オンサイトの電源の問題またはネットワーク接続の喪失が原因でサービスリンクがダウンした場合、 は Outposts を所有するアカウントに通知 Health Dashboard を送信します。中断が予想される場合でも、ユーザーも もサービスリンクの中断の通知を抑制する AWS ことはできません。詳細については、「AWS Health ユーザーガイド」の「[Health Dashboardの開始方法](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)」を参照してください。
ネットワーク接続に影響を与える計画的なサービス メンテナンスの場合は、次の予防的な手順を実行して、潜在的な問題のあるシナリオの影響を制限してください。
+ Outposts ラックがインターネットまたはパブリック Direct Connect を介して親 AWS リージョンに接続する場合は、計画されたメンテナンスの前にトレースルートをキャプチャします。動作中の (ネットワーク メンテナンス前) ネットワーク パスと問題のある (ネットワーク メンテナンス後) ネットワーク パスを用意して違いを特定すると、トラブルシューティングに役立ちます。メンテナンス後の問題を AWS または ISP にエスカレーションする場合は、この情報を含めることができます。
以下の間のトレース ルートをキャプチャします。
+ Outposts の場所のパブリック IP アドレスと、`outposts.region.amazonaws.com` によって返された IP アドレス。*region* を親 AWS リージョンの名前に置き換えます。
+ パブリック インターネット接続と Outposts の場所のパブリック IP アドレスを持つ親リージョン内のインスタンス。
+ ネットワークのメンテナンスを管理している場合は、サービス リンクのダウンタイムの期間を制限します。メンテナンスプロセスに、ネットワークが回復したことを確認するステップを含めます。
+ 発表されたメンテナンス期間の終了時にサービス リンクがバックアップされていない場合、ネットワーク メンテナンスを管理できない場合は、発表されたメンテナンス期間に関してサービス リンクのダウンタイムを監視し、計画されたネットワーク メンテナンスの担当者に早めにエスカレーションしてください。
### リソース
計画的または計画外の電力イベントやネットワーク イベントの後、Outpost が正常に動作していることを保証できる監視関連リソースをいくつか紹介します。
+ AWS ブログ[「 のモニタリングのベストプラクティス AWS Outposts](https://aws.amazon.com/blogs/mt/monitoring-best-practices-for-aws-outposts/)」では、Outposts 固有のオブザーバビリティとイベント管理のベストプラクティスについて説明しています。
+ AWS ブログ[「Amazon VPC からのネットワーク接続用のデバッグツール](https://aws.amazon.com/blogs/networking-and-content-delivery/debugging-tool-for-network-connectivity-from-amazon-vpc/)」では、*AWSSupport-SetupIPMonitoringFromVPC* ツールについて説明します。本ツールは、お客様が指定したサブネットに Amazon EC2 Monitor Instance を作成し、対象の IP AWS Systems Manager アドレスを監視するためのドキュメント (SSM ドキュメント)です。このドキュメントでは、ping、MTR、TCP トレースルート、トレースパス診断テストを実行し、結果を Amazon CloudWatch Logs に保存し、CloudWatch ダッシュボードで視覚化できます。(例: 遅延、パケット損失)。Outposts モニタリングの場合、モニターインスタンスは親 AWS リージョンの 1 つのサブネットにあり、プライベート IP (複数可) を使用して 1 つ以上の Outpost インスタンスをモニタリングするように設定する必要があります。これにより、 AWS Outposts と親 AWS リージョン間のパケット損失グラフとレイテンシーが提供されます。
+ AWS ブログ [AWS Outposts を使用するための自動 Amazon CloudWatch ダッシュボードのデプロイ AWS CDK](https://aws.amazon.com/blogs/compute/deploying-an-automated-amazon-cloudwatch-dashboard-for-aws-outposts-using-aws-cdk/)では、自動ダッシュボードのデプロイに関連する手順について説明します。
+ 質問がある場合、または詳細情報が必要な場合は、「AWS サポートユーザー ガイド」の「[サポート ケースの作成](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case)」を参照してください。