翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Outposts サーバーメンテナンス
[責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)の下で、 AWS は AWS サービスを実行するハードウェアとソフトウェアを担当します。これは AWS Outposts、 AWS リージョンと同様に に適用されます。例えば、 は、セキュリティパッチ AWS の管理、ファームウェアの更新、Outpost 機器の保守を行います。 は、Outposts サーバーのパフォーマンス、ヘルス、メトリクス AWS もモニタリングし、メンテナンスが必要かどうかを判断します。
**警告**
基盤となるディスクドライブに障害が発生した場合、またはインスタンスが終了すると、インスタンスストアボリュームのデータは失われます。データ損失を防ぐために、インスタンスストアボリュームの長期データをAmazon S3バケットやオンプレミスネットワーク内のネットワークストレージデバイスなどの永続的ストレージにバックアップすることをお勧めします。
**Topics**
+ [連絡先の情報を更新する](#outpost-owner-update)
+ [ハードウェアメンテナンス](#outpost-hardware-maintenance-events)
+ [ファームウェアの更新](#outpost-firmware-updates)
+ [電力およびネットワーク イベントのベスト プラクティス](#outpost-power-network-events)
+ [サーバーデータを暗号化して細断する](#outpost-server-cryptographically-shred-data)
## 連絡先の情報を更新する
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)」を参照してください。
AWS は、インスタンスの廃止日に影響を受けるインスタンスを終了します。インスタンス ストア ボリューム上のデータは、インスタンスの終了後は保持されません。したがって、インスタンスの廃止日より前にアクションを起こすことが重要です。まず、長期データを、影響を受ける各インスタンスのインスタンス ストア ボリュームから、Amazon S3 バケットやネットワーク内のネットワーク ストレージ デバイスなどの永続ストレージに転送します。
代替サーバーが Outpost サイトに発送されます。次に、以下の操作を実行します。
+ 修復できないサーバーからネットワークおよび電力ケーブルを取り外し、必要に応じてラックから取り外します。
+ 同じ場所に交換用のサーバーを取り付けます。「[Outposts サーバーの設置](https://docs.aws.amazon.com/outposts/latest/install-server/install-server.html)」の設置手順に従ってください。
+ 修復不可能なサーバーを、代替サーバーが到着したのと同じパッケージ AWS で にパックします。
+ コンソールにアタッチされた注文構成の詳細または交換サーバーの注文に利用可能な、事前支払いの返品配送ラベルを使用してください。
+ サーバーを に返します AWS。詳細については、「[AWS Outposts サーバーを返却する](https://docs.aws.amazon.com/outposts/latest/server-userguide/shipping-outposts-server.html)」を参照してください。
## ファームウェアの更新
通常、Outpost ファームウェアを更新しても、Outpost 上のインスタンスには影響しません。まれに、アップデートをインストールするために Outpost 機器の再起動が必要になる場合があり、その容量で実行されているインスタンスについてインスタンスの廃止通知が届きます。
## 電力およびネットワーク イベントのベスト プラクティス
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 インスタンス、LNI ネットワーク、インスタンスストレージボリュームは、引き続き正常に動作し、ローカルネットワークと LNI 経由でローカルにアクセスできます。同様に、Amazon ECS ワーカーノードなどの AWS サービスリソースは引き続きローカルで実行されます。ただし、API の可用性は低下します。例えば、実行、開始、停止、終了 API は機能しない場合があります。インスタンスメトリクスとログは最大 7 日間ローカルにキャッシュされ、接続が戻ると AWS リージョンにプッシュされます。7 日以上切断すると、メトリクスとログが失われる可能性があります。
オンサイトの電源の問題またはネットワーク接続の喪失が原因でサービスリンクがダウンした場合、 は Outposts を所有するアカウントに通知 Health Dashboard を送信します。中断が予想される場合でも、ユーザーも もサービスリンクの中断の通知を抑制する AWS ことはできません。詳細については、「AWS Health ユーザーガイド」の「[Health Dashboardの開始方法](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html)」を参照してください。
ネットワーク接続に影響を与える計画的なサービス メンテナンスの場合は、次の予防的な手順を実行して、潜在的な問題のあるシナリオの影響を制限してください。
+ ネットワークのメンテナンスを管理している場合は、サービス リンクのダウンタイムの期間を制限します。メンテナンスプロセスに、ネットワークが回復したことを確認するステップを含めます。
+ 発表されたメンテナンス期間の終了時にサービス リンクがバックアップされていない場合、ネットワーク メンテナンスを管理できない場合は、発表されたメンテナンス期間に関してサービス リンクのダウンタイムを監視し、計画されたネットワーク メンテナンスの担当者に早めにエスカレーションしてください。
### リソース
計画的または計画外の電力イベントやネットワーク イベントの後、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)」を参照してください。
## サーバーデータを暗号化して細断する
サーバー上のデータを復号化するには、Nitro セキュリティ キー (NSK) が必要です。サーバーを に返すときは AWS、サーバーを交換するかサービスを中止するかにかかわらず、NSK を破棄してサーバー上のデータを暗号化的にシュレッダーできます。
**サーバー上のデータを暗号化してシュレッドするには**
1. サーバーを返送する前に、サーバーから NSK を削除します AWS。
1. サーバーに同梱されている正しい NSK を使用していることを確認してください。
1. ステッカーの下から小さな六角工具/六角レンチを取り外します。
1. 六角工具を使用して、ステッカーの下にある小さなネジを 3 回転させます。このアクションにより NSK が破壊され、サーバー上のすべてのデータが暗号化されてシュレッドされます。
![\[六角工具と六角工具を挿入する蝶ネジを識別するラベルが付いた NSK。\]](http://docs.aws.amazon.com/ja_jp/outposts/latest/server-userguide/images/nsk-details.png)