翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AMS での RFC エラーのトラブルシューティング
多くの AMS プロビジョニング RFC 障害は、CloudFormation ドキュメントを通じて調査できます。 AWS CloudFormation のトラブルシューティング: エラーのトラブルシューティング」を参照してください。
追加のトラブルシューティングの提案については、以下のセクションで説明します。
AMS の「管理」RFC エラー
AMS "Management" カテゴリ変更タイプ (CTs) を使用すると、リソースへのアクセスをリクエストしたり、既存のリソースを管理したりできます。このセクションでは、いくつかの一般的な問題について説明します。
RFC アクセスエラー
RFC で指定したユーザー名と FQDN が正しく、ドメインに存在することを確認します。FQDN の検索については、「FQDN の検索」を参照してください。
アクセス用に指定したスタック ID が EC2-relatedスタックであることを確認します。ELB や Amazon Simple Storage Service (S3) などのスタックは、アクセス RFCsの候補ではなく、読み取り専用アクセスロールを使用してこれらのスタックリソースにアクセスします。スタック ID の検索については、「スタック IDs」を参照してください。
指定したスタック ID が正しく、関連するアカウントに属していることを確認します。
その他のアクセス RFC 障害については、「アクセス管理」を参照してください。
YouTube 動画: 拒否や失敗を避けるために、変更リクエスト (RFC) を適切に作成するにはどうすればよいですか？
RFC (手動) CT スケジューリングエラー
ほとんどの変更タイプは ExecutionMode=Automated ですが、一部は ExecutionMode=Manual であり、RFC の失敗を避けるためのスケジュール方法に影響します。
ExecutionMode=Manual でスケジュールRFCs は、AMS コンソールを使用して RFC を作成する場合は、少なくとも 24 時間後に実行するように設定する必要があります。この注意は AMS API/CLI には適用されませんが、少なくとも 8 時間前に手動 RFCs をスケジュールすることが重要です。
AMS は手動 CT に 4 時間以内に応答することを目指しており、できるだけ早く対応しますが、RFC が実際に実行されるまでにかなり時間がかかる場合があります。
手動更新 CT RFCs の使用 CTs
AMS オペレーションは、更新するスタックのタイプに更新変更タイプがある場合、管理を拒否する | その他 | スタックの更新に関するその他の RFCs。
RFC スタック削除エラー
RFC 削除スタックの失敗: 管理 | 標準スタック | スタック | CT を削除すると、AMS スタック名を持つスタックの詳細なイベントが CloudFormation コンソールに表示されます。スタックは、AMS コンソールの名前と照合することで識別できます。 CloudFormation コンソールには、障害の原因に関する詳細が表示されます。
スタックを削除する前に、スタックの作成方法を考慮する必要があります。AMS CT を使用してスタックを作成し、スタックリソースを追加または編集しなかった場合、問題なく削除できます。ただし、削除スタック RFC を送信する前に、手動で追加されたリソースをスタックから削除することをお勧めします。たとえば、フルスタック CT (HA Two Tier) を使用してスタックを作成する場合、セキュリティグループ - SG1 が含まれます。次に AMS を使用して別のセキュリティグループ SG2 を作成し、フルスタックの一部として作成された SG1 内の新しい SG2 を参照し、削除スタック CT を使用してスタックを削除した場合、SG2 SG1 は削除しません。 SG1
重要
スタックを削除すると、望ましくない結果や予期しない結果が生じる可能性があります。AMS は、この理由から、お客様に代わってスタックまたはスタックリソースを *削除しない* ことを優先します。AMS は、ユーザーに代わって (送信された管理 | その他 | その他 | 変更タイプの更新を通じて）、削除する適切な自動変更タイプを使用して削除できないリソースのみを削除することに注意してください。追加の考慮事項:
リソースが「削除保護」に対して有効になっている場合、管理 | その他 | その他 | 変更タイプを更新し、削除保護が削除された後、自動 CT を使用してそのリソースを削除することで、AMS はこれをブロック解除できます。
スタックに複数のリソースがあり、スタックリソースのサブセットのみを削除する場合は、CloudFormation Update 変更タイプを使用します (CloudFormation Ingest Stack: Updatedating」を参照）。管理 | その他 | その他 | 更新変更タイプを送信することもできます。AMS エンジニアは、必要に応じて変更セットの作成を支援します。
ドリフトが原因で CloudFormation Update CT の使用に問題がある場合、AMS は、管理 | その他 | その他 | 更新を送信してドリフトを解決し (AWS CloudFormation サービスでサポートされる限り）、自動 CT、管理/カスタムスタック/CloudFormation テンプレートからのスタック/変更セットと更新の承認を使用して検証および実行できる ChangeSet を提供できます。
AMS は、予期しないリソースの削除や予期しないリソースの削除がないように、上記の制限を維持します。
詳細については、AWS CloudFormation のトラブルシューティング: スタックの削除が失敗する」を参照してください。
RFC 更新 DNS エラー
DNS ホストゾーンを更新する複数の RFCs は、理由なしに失敗する可能性があります。DNS ホストゾーン (プライベートまたはパブリック) を更新するために複数の RFCs を同時に作成すると、同じスタックを同時に更新しようとしているために、一部の RFCs が失敗する可能性があります。AMS 変更管理は、スタックがすでに別の RFCs によって更新されているため、スタックを更新できない RFC を拒否または失敗します。AMS では、一度に 1 つの RFC を作成し、RFC が成功するのを待ってから、同じスタック用に新しい RFC を作成することをお勧めします。
RFC IAM エンティティエラー
AMS は、ニーズを満たすように設計されたいくつかのデフォルトの IAM ロールとプロファイルを AMS アカウントにプロビジョニングします。ただし、追加の IAM リソースをリクエストする必要がある場合があります。
カスタム IAM リソースをリクエストする RFCs を送信するプロセスは、手動 RFCsの標準ワークフローに従いますが、承認プロセスには、適切なセキュリティコントロールが実施されていることを確認するためのセキュリティレビューも含まれています。したがって、通常、このプロセスには他の手動 RFCsよりも時間がかかります。これらの RFCsのサイクル時間を短縮するには、次のガイドラインに従ってください。
IAM レビューの意味と、それが技術標準およびリスク許容プロセスにどのようにマッピングされるかについては、「」を参照してくださいRFC セキュリティレビューを理解する。
一般的な IAM リソースリクエスト：
CloudEndure などの主要なクラウド互換アプリケーションに関連するポリシーをリクエストする場合は、AMS の事前承認された IAM CloudEndure ポリシー: WIGs Cloud Endure Landing Zone の例ファイルを解凍し、
customer_cloud_endure_policy.json注記
より寛容なポリシーが必要な場合は、CloudArchitect/CSDM とニーズについて話し合い、必要に応じて、ポリシーを実装する RFC を送信する前に AMS セキュリティレビューとサインオフを取得します。
AMS によってアカウントにデプロイされたリソースをデフォルトで変更する場合は、既存のリソースに変更を加えるのではなく、そのリソースの修正されたコピーをリクエストすることをお勧めします。
（アクセス許可をユーザーにアタッチするのではなく) 人間のユーザーのアクセス許可をリクエストする場合は、アクセス許可をロールにアタッチし、そのロールを引き受けるアクセス許可をユーザーに付与します。これを行う方法の詳細については、「一時的な AMS Advanced コンソールアクセス」を参照してください。
一時的な移行またはワークフローに例外的なアクセス許可が必要な場合は、リクエストでそれらのアクセス許可の終了日を指定します。
リクエストの件名についてセキュリティチームとすでに話し合っている場合は、CSDM に承認の証拠をできるだけ詳しく提供します。
AMS が IAM RFC を拒否する場合は、拒否の明確な理由を指定します。例えば、IAM ポリシー作成リクエストを拒否し、ポリシーが不適切であることについて説明します。その場合は、特定された変更を行い、リクエストを再送信できます。リクエストのステータスをさらに明確にする必要がある場合は、サービスリクエストを送信するか、CSDM にお問い合わせください。
次のリストは、IAM RFCs を確認するときに AMS が軽減を試みる一般的なリスクを示しています。IAM RFC にこれらのリスクがある場合、RFC が拒否される可能性があります。例外が必要な場合、AMS はセキュリティチームの承認を求めます。このような例外を求めるには、CSDM と調整します。
注記
AMS は、何らかの理由で、アカウント内の IAM リソースへの変更を拒否することがあります。RFC 拒否に関する懸念については、サービスリクエストを通じて AMS オペレーションに問い合わせるか、CSDM にお問い合わせください。
独自のアクセス許可を変更したり、アカウント内の他のリソースのアクセス許可を変更したりできるアクセス許可など、権限のエスカレーション。例:
より特権的な別のロール
iam:PassRoleで を使用する。ロールまたはユーザーから IAM ポリシーをアタッチ/デタッチするアクセス許可。
アカウントの IAM ポリシーの変更。
管理インフラストラクチャのコンテキストで API コールを行う機能。
AMS サービスを提供するために必要なリソースまたはアプリケーションを変更するアクセス許可。例:
踏み台、管理ホスト、EPS インフラストラクチャなどの AMS インフラストラクチャの変更。
ログ管理 AWS Lambda 関数、またはログストリームの削除。
デフォルトの CloudTrail モニタリングアプリケーションの削除または変更。
Directory Services Active Directory (AD) の変更。
CloudWatch (CW) アラームを無効にする。
ランディングゾーンの一部としてアカウントにデプロイされたプリンシパル、ポリシー、名前空間の変更。
情報セキュリティを危険にさらす状態でインフラストラクチャを作成できるアクセス許可など、ベストプラクティス外のインフラストラクチャのデプロイ。例:
パブリックまたは暗号化されていない S3 バケットの作成または EBS ボリュームのパブリック共有。
パブリック IP アドレスのプロビジョニング。
広範なアクセスを許可するようにセキュリティグループを変更しました。
データ損失、整合性損失、不適切な設定、インフラストラクチャおよびアカウント内のアプリケーションのサービスの中断につながる可能性のあるアクセス許可など、アプリケーションに影響を与える可能性のある過度に広範なアクセス許可。例:
や などの APIs を介したネットワークトラフィックの無効化
ModifyNetworkInterfaceAttributeまたはリダイレクトUpdateRouteTable。マネージドホストからボリュームをデタッチしてマネージドインフラストラクチャを無効にする。
AMS サービスの説明の一部ではなく、AMS でサポートされていないサービスのアクセス許可。
AMS サービスの説明に記載されていないサービスは、AMS アカウントでは使用できません。機能またはサービスのサポートをリクエストするには、CSDM にお問い合わせください。
過度に寛大であるか、控えめであるか、間違ったリソースに適用されるため、指定された目標を達成できないアクセス許可。例:
関連するキーへのアクセス
s3:PutObject許可のない、必須の KMS 暗号化を持つ S3 バケットへのアクセスKMS:Encrypt許可のリクエスト。アカウントに存在しないリソースに関連するアクセス許可。
RFCs の説明がリクエストと一致しないように思われる IAM RFC。
「デプロイ」 RFC エラー
AMS "Deployment" カテゴリ変更タイプ (CTs) を使用すると、AMS がサポートするさまざまなリソースをアカウントに追加することをリクエストできます。
リソースを作成するほとんどの AMS CTs は、 CloudFormation テンプレートに基づいています。お客様は、 CloudFormation コンソールを使用して CloudFormation、 CloudFormation スタックの説明に基づいてスタックを表すスタックをすばやく特定できます。失敗したスタックは DELETE_COMPLETE 状態である可能性があります。 CloudFormation スタックを特定すると、イベントには作成に失敗した特定のリソースとその理由が表示されます。
CloudFormation ドキュメントを使用したトラブルシューティング
ほとんどの AMS プロビジョニング RFCs は CloudFormation テンプレートを使用しており、そのドキュメントはトラブルシューティングに役立ちます。その CloudFormation テンプレートのドキュメントを参照してください。
アプリケーションロードバランサーの作成の失敗: AWS::ElasticLoadBalancingV2::LoadBalancer (Application Load Balancer)
Auto Scaling グループの作成: AWS::AutoScaling::AutoScalingGroup (Auto Scaling グループ）
memcached キャッシュの作成: AWS::ElastiCache::CacheCluster (キャッシュクラスター）
Redis キャッシュの作成: AWS::ElastiCache::CacheCluster (キャッシュクラスター）
DNS ホストゾーンの作成 (DNS プライベート/パブリックの作成で使用): AWS::Route53::HostedZone (R53 ホストゾーン）
DNS レコードセットの作成 (DNS プライベート/パブリックの作成で使用): AWS::Route53::RecordSet (リソースレコードセット）
EC2 スタックの作成: AWS::EC2::Instance (Elastic Compute Cloud)
Elastic File System (EFS): AWS::EFS::FileSystem (Elastic File System)
ロードバランサーの作成: AWS::ElasticLoadBalancing::LoadBalancer (Elastic Load Balancer)
RDS DB の作成: AWS::RDS::DBInstance (リレーショナルデータベース）
Amazon S3 の作成: AWS::S3::Bucket (Simple Storage Service)
キューの作成: AWS::SQS::Queue (簡易キューサービス）
RFC AMI エラーの作成 AMIs
Amazon マシンイメージ (AMI) は、ソフトウェア構成 (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) を記録したテンプレートです。AMI から、クラウドで仮想サーバーとして実行される AMI のコピーであるインスタンスを起動します。AMIs は非常に有用であり、EC2 インスタンスまたは Auto Scaling グループの作成に必要ですが、いくつかの要件に従う必要があります。
RFC を成功させるには、 に指定するインスタンスが停止状態
Ec2InstanceIdである必要があります。ASG は停止したインスタンスを終了するため、このパラメータに Auto Scaling グループ (ASG) インスタンスを使用しないでください。AMS Amazon マシンイメージ (AMI) を作成するには、AMS インスタンスから始める必要があります。インスタンスを使用して AMI を作成する前に、インスタンスが停止され、そのドメインから切断されていることを確認することで、インスタンスを準備する必要があります。詳細については、「Sysprep を使用して標準 Amazon マシンイメージを作成する」を参照してください。
新しい AMI に指定する名前は、アカウント内で一意である必要があります。そうしないと、RFC は失敗します。これを行う方法については、「AMI | Create」で説明されています。詳細については、「」および「AWS AMI Design
」を参照してください。
注記
AMI 作成の準備の詳細については、「AMI | 作成」を参照してください。
EC2s または ASGs エラーを作成する RFCs
タイムアウトを伴う EC2 または ASG 障害の場合、AMS では、使用する AMI がカスタマイズされているかどうかを確認することをお勧めします。その場合は、このガイドに含まれている AMI 作成手順 (「AMI | 作成」を参照) を参照して、AMI が正しく作成されたことを確認してください。カスタム AMI を作成する際の一般的な間違いは、 ガイドの手順に従って Sysprep の名前を変更または呼び出すことではありません。
RDS エラーを作成する RFCs
Amazon Relational Database Service (RDS) の障害は、RDS の作成時にさまざまなエンジンを使用でき、各エンジンには独自の要件と制限があるため、さまざまな理由で発生する可能性があります。AMS RDS スタックを作成する前に、AWS RDS パラメータ値を慎重に確認してください。CreateDBInstance」を参照してください。
サイズのレコメンデーションなど、Amazon RDS 全般の詳細については、Amazon Relational Database Service ドキュメント
Amazon S3s エラーを作成する RFCs
S3 ストレージバケットを作成する際の一般的なエラーの 1 つは、バケットに一意の名前を使用していないことです。以前に送信したものと同じ名前の S3 バケット Create CT を送信した場合、その BucketName に S3 バケットがすでに存在するため、失敗します。これは CloudFormation コンソールで詳しく説明され、スタックイベントにバケット名がすでに使用されていることが示されます。
RFC 検証エラーと実行エラー
RFC の失敗と関連するメッセージは、選択した RFC の AMS コンソール RFC の詳細ページの出力メッセージで異なります。
検証失敗の理由は、ステータスフィールドでのみ使用できます。
実行失敗の理由は、実行出力とステータスフィールドで使用できます。
RFC エラーメッセージ
リストされた変更タイプ (CTs) で次のエラーが発生した場合は、これらのソリューションを使用して問題の原因を見つけて修正できます。
{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}
次のトラブルシューティングオプションを参照してさらにサポートが必要な場合は、RFC 通信を介して AMS をエンゲージするか、サービスリクエストを作成します。詳細については、「RFC の通信と添付ファイル (コンソール）」および「AMS でのサービスリクエストの作成」を参照してください。
ワークロード取り込み (WIGS) エラー
注記
Windows と Linux の両方の検証ツールは、オンプレミスサーバーと AWS の EC2 インスタンスに直接ダウンロードして実行できます。これらは、AMS Advanced Application Developer's Guide Migrating workloads: Linux pre-ingestion validation and Migrating workloads: Windows pre-ingestion validation で確認できます。
EC2 インスタンスがターゲット AMS アカウントに存在することを確認します。たとえば、AMS 以外のアカウントから AMS アカウントに AMI を共有している場合は、ワークロード取り込み RFC を送信する前に、共有 AMI を使用して AMS アカウントに EC2 インスタンスを作成する必要があります。
インスタンスにアタッチされたセキュリティグループで送信トラフィックが許可されているかどうかを確認します。SSM エージェントはパブリックエンドポイントに接続できる必要があります。
インスタンスに SSM エージェントに接続するための適切なアクセス許可があるかどうかを確認します。これらのアクセス許可には が付属
customer-mc-ec2-instance-profileしています。これは EC2 コンソールで確認できます。
EC2 インスタンススタック停止エラー
インスタンスが既に停止状態か終了状態かを確認します。
EC2 インスタンスがオンラインであり、
InternalErrorエラーが表示された場合は、AMS が調査するためのサービスリクエストを送信します。変更タイプ Management | Advanced stack components | EC2 instance stack | Stop ct-3mvt2zkyveqj を使用して Auto Scaling グループ (ASG) インスタンスを停止することはできません。ASG インスタンスを停止する必要がある場合は、サービスリクエストを送信します。
EC2 インスタンススタックの作成エラー
メッセージは CloudFormation からのInternalErrorものです。CREATION_FAILED ステータスの理由です。CloudWatch スタックイベントでは、以下の手順に従ってスタックの障害に関する詳細を確認できます。
AWS マネジメントコンソールでは、スタックの作成、更新、または削除中にスタックイベントのリストを表示できます。このリストから失敗イベントを探して、そのイベントのステータスの理由を確認します。
ステータスの理由には、問題を理解するのに役立つ AWS CloudFormation または特定のサービスからのエラーメッセージが含まれている場合があります。
スタックイベントの表示の詳細については、「AWS マネジメントコンソールでの AWS CloudFormation スタックデータとリソースの表示」を参照してください。
EC2 インスタンスボリュームの復元エラー
EC2 インスタンスボリュームの復元が失敗すると、AMS は内部トラブルシューティング RFC を作成します。これは、EC2 インスタンスボリュームの復元がディザスタリカバリ (DR) の重要な部分であり、AMS によってこの内部トラブルシューティング RFC が自動的に作成されるためです。
内部トラブルシューティング RFC が作成されると、バナーが表示され、RFC へのリンクが表示されます。この内部トラブルシューティング RFC は、RFC の障害をより詳細に可視化し、同じエラーにつながる再試行 RFCs を送信したり、この障害について AMS に手動で連絡したりするのではなく、変更を追跡して、障害が AMS によって処理されていることを知ることができます。これにより、AMS Operators がリクエストを待つ代わりに RFC 障害にプロアクティブに取り組むため、変更のtime-to-recovery (TTR) メトリクスも短縮されます。
RFC のヘルプを取得する方法
AMS に連絡して、障害の根本原因を特定できます。AMS の営業時間は、1 日 24 時間、1 週間 7 日、1 年 365 日です。
AMS には、サポートを依頼したり、サービスリクエストを行ったりするためのいくつかの手段が用意されています。
情報やアドバイスを求めたり、AMS が管理する IT サービスにアクセスしたり、AMS から追加のサービスをリクエストしたりするには、AMS コンソールを使用してサービスリクエストを送信します。詳細については、「サービスリクエストの作成」を参照してください。AMS サービスリクエストの一般的な情報については、「サービスリクエスト管理」を参照してください。
マネージド環境に影響する AWS または AMS サービスのパフォーマンスの問題を報告するには、AMS コンソールを使用してインシデントレポートを送信します。詳細については、「インシデントの報告」を参照してください。AMS インシデント管理の一般的な情報については、「インシデント対応」を参照してください。
お客様またはお客様のリソースやアプリケーションが AMS とどのように連携しているかに関する具体的な質問、またはインシデントのエスカレーションについては、以下のうち 1 つ以上を E メールで送信してください。
まず、サービスリクエストまたはインシデントレポートのレスポンスに満足できない場合は、CSDM に E メールを送信してください: ams-csdm@amazon.com
次に、エスカレーションが必要な場合は、AMS Operations Manager に E メールを送信できます (CSDM はおそらくこれを行います): ams-opsmanager@amazon.com
さらなるエスカレーションは、AMS Director: ams-director@amazon.com に行われます。
最後に、AMS VP にいつでもアクセスできます: ams-vp@amazon.com
