翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # RFC モード RFC モードは、AMS Advanced オペレーションプランのお客様向けのデフォルトモードです。これには、変更または RFCs のリクエストを含む変更管理システムと、アカウントに必要な追加または変更をリクエストするために使用する変更タイプのカタログが含まれます。この変更管理システムは、アカウントを変更できるユーザーを制限するためのセキュリティレベルを提供します。 AMS Advanced 変更タイプの詳細については、[「AMS 変更タイプとは](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html)」を参照してください。 AMS Advanced へのオンボーディングの詳細については、[AWS Managed Servicesオンボーディングの概要](https://docs.aws.amazon.com/managedservices/latest/onboardingguide/index.html)」を参照してください。 変更タイプのウォークスルーの例については、*AMS Advanced Change Type Reference* [Change Types by Classification](https://docs.aws.amazon.com/managedservices/latest/ctref/classifications.html) セクションの関連する変更タイプの「追加情報」セクションを参照してください。 **注記** RFC モードは、以前は「変更管理モード」または「標準 CM モード」と呼ばれていました。 **Topics** + [RFCsの詳細](ex-rfc-works.md) + [変更タイプとは?](understanding-cts.md) + [AMS での RFC エラーのトラブルシューティング](rfc-troubleshoot.md) # RFCsの詳細 変更のリクエスト、または RFCs、2 つの方法で機能します。まず、RFC 自体に必要なパラメータがあります。これらは `CreateRfc` API のオプションです。次に、RFC のアクションに必要なパラメータ (実行パラメータ) があります。`CreateRfc` オプションの詳細については、*AMS API リファレンス*の [CreateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html) セクションを参照してください。これらのオプションは通常、RFC ページの作成**の追加設定**領域に表示されます。 `CreateRfc` API、CLI、または AMS `aws amscm create-rfc` コンソールの RFC ページの作成を使用して、RFC を作成して送信できます。RFC の作成に関するチュートリアルについては、「」を参照してください[RFC を作成する](ex-rfc-create-col.md)。 **Topics** + [RFC とは?](what-r-rfcs.md) + [AMS API/CLI を使用する場合の認証](ex-rfc-authentication.md) + [RFC セキュリティレビューを理解する](rfc-security.md) + [RFC 変更タイプの分類を理解する](ex-rfc-csio.md) + [RFC アクションとアクティビティの状態を理解する](ex-rfc-action-state.md) + [RFC ステータスコードを理解する](ex-rfc-status-codes.md) + [RFC 更新 CTs と CloudFormation テンプレートドリフト検出を理解する](ex-rfc-updates-and-dd.md) + [RFCs](ex-rfc-scheduling.md) + [RFCs](ex-rfc-approvals.md) + [RFC の制限された実行期間をリクエストする](ex-rfc-restrict-execute.md) + [RFCs の作成、クローン作成、更新、検索、キャンセル](ex-rfc-use-examples.md) + [RFCs](ex-rfc-gui.md) + [一般的な RFC パラメータについて説明します。](rfc-common-params.md) + [RFC の毎日の E メールにサインアップする](rfc-digest.md) # RFC とは? 変更のリクエスト、つまり RFC は、AMS が管理する環境を変更する方法、またはユーザーに代わって変更を行うように AMS に依頼する方法です。RFC を作成するには、AMS 変更タイプから選択し、RFC パラメータ (スケジュールなど) を選択し、AMS コンソールまたは API コマンド [CreateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html) と [SubmitRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_SubmitRfc.html) を使用してリクエストを送信します。 RFC には 2 つの仕様が含まれています。1 つは RFC 自体用で、もう 1 つは変更タイプ (CT) パラメータ用です。コマンドラインでは、インライン RFC コマンド、または作成した CT JSON スキーマファイル (CT パラメータに基づく) とともに入力して送信する JSON 形式の標準の CreateRfc テンプレートを使用できます。CT 名は、CT の非公式な説明です。CSIO (カテゴリ、サブカテゴリ、項目、オペレーション) は、CT のより正式な説明です。RFC を作成するときは、CT ID のみを指定する必要があります。 RFCs、検証と実行の 2 つの主要な段階があります。 1. 検証段階では、AMS は RFC リクエストの完全性と正確性を確認します。AMS は、セキュリティ[技術標準に従ってセキュリティ](rfc-security.md#rfc-security.title)のリクエストも評価します。AMS は、リクエストされた変更が有効で実行可能であることを確認します。 1. 実行ステージでは、AMS はアカウントでリクエストされた変更を試みます。 AMS は、自動プロセス、手動プロセス、またはその両方の組み合わせを通じて両方のステージを処理します。手動プロセスは AMS オペレーションチームによって処理されます。詳細については、「[自動 CT と手動 CTs](ug-automated-or-manual.md)」を参照してください。 AMS には、リクエストを処理するための 3 つの実行モードがあります。 + **(AMS 推奨) 実行モード: 自動**。これらの CTs RFC の検証と実行に自動化を使用します。これは、ビジネス成果を達成するための最も迅速な方法です。 + **(AMS 推奨) 実行モード: 手動および指定: マネージドオートメーション**。これらの CTs、RFC の検証と実行のための自動プロセスと手動プロセスの組み合わせを使用します。オートメーションがリクエストされた変更を実行できない場合、RFC は手動処理のために (自動ルーティングまたは代替 RFC の作成によって) AMS オペレーションチームに転送されます。これらの CTs を送信すると、リクエストをより構造化し、AMS オートメーションで補完して、処理と実行の結果の時間枠を改善できます。 + **実行モード: 手動および指定: レビューが必要**。[ct-1e1xtak34nx76 管理 \$1 その他 \$1 その他 \$1 更新 (レビューが必要)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-other-other-update-review-required.html) または [ct-0xdawir96cy7k 管理 \$1 その他 \$1 その他 \$1 作成 (レビューが必要)](https://docs.aws.amazon.com/managedservices/latest/ctref/management-other-other-create-review-required.html) を通じてリクエストされた変更。これらの CTs、検証と実行の手動処理に依存しています。これらの CTs は、変更リクエストの手動解釈によって異なります。 AMS は、変更が正常に完了したとき (成功) または失敗したとき (失敗) に通知します。 **注記** RFC 障害のトラブルシューティングについては、「」を参照してください[AMS での RFC エラーのトラブルシューティング](rfc-troubleshoot.md)。 次の図は、ユーザーが送信した RFC のワークフローを示しています。 ![\[お客様が送信した RFC のワークフロー。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/requestForChange-v5g.png) # AMS API/CLI を使用する場合の認証 AMS API/CLI を使用する場合は、一時的な認証情報を使用して認証する必要があります。フェデレーティッドユーザーの一時的なセキュリティ認証情報をリクエストするには、cal [ GetFederationToken](https://docs.aws.amazon.com/STS/latest/UsingSTS/CreatingFedTokens.html)、[AssumeRole](https://docs.aws.amazon.com/STS/latest/UsingSTS/sts_delegate.html)、[AssumeRoleWithSAML](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithsaml)、または [ AssumeRoleWithWebIdentity](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#api_assumerolewithwebidentity) AWS セキュリティトークンサービス (STS) APIs。 一般的な選択肢は SAML です。セットアップ後、呼び出す各オペレーションに 引数を追加します。例: `aws --profile saml amscm list-change-type-categories`。 SAML 2.0 プロファイルのショートカットは、 を使用して各 API/CLI の開始時にプロファイル変数を設定することです `set AWS_DEFAULT_PROFILE=saml` (Windows の場合、Linux の場合、 になります`export AWS_DEFAULT_PROFILE=saml`）。CLI 環境変数の設定については、[「AWS コマンドラインインターフェイスの設定、環境変数](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-environment)」を参照してください。 # RFC セキュリティレビューを理解する AWS Managed Services (AMS) 変更管理承認プロセスにより、アカウントに加えた変更のセキュリティレビューが確実に実行されます。 AMS は、AMS 技術標準に照らしてすべての変更リクエスト (RFCs) を評価します。技術標準から逸脱することでアカウントのセキュリティ体制を低下させる可能性のある変更は、セキュリティレビューの対象となります。セキュリティレビュー中、AMS は関連するリスクを強調し、セキュリティリスクが高い、または非常に高い場合は、承認されたセキュリティ担当者が RFC を承認または拒否します。すべての変更は、AMS の運用能力への悪影響を評価するためにも評価されます。潜在的な悪影響が見つかった場合は、AMS 内で追加のレビューと承認が必要です。 ## AMS 技術標準 AMS 技術標準は、アカウントのベースラインセキュリティを確立するための最小限のセキュリティ基準、設定、プロセスを定義します。これらの標準には、AMS とユーザーの両方が従う必要があります。 技術標準から逸脱することでアカウントのセキュリティ体制を低下させる可能性のある変更は、リスク受理プロセスを経て、関連するリスクが AMS によって強調表示され、承認されたセキュリティ担当者がユーザーから承認または拒否します。そのような変更はすべて、アカウントを運用する AMS の能力に悪影響があるかどうかを評価するために評価され、その場合は AMS 内で追加のレビューと承認が必要になります。 ## RFC カスタマーセキュリティリスク管理 (CSRM) プロセス 組織の誰かがマネージド環境への変更をリクエストすると、AMS は変更を確認して、リクエストが技術標準に違反してアカウントのセキュリティ体制を悪化させる可能性があるかどうかを判断します。リクエストがアカウントのセキュリティ体制を低下させ、AMS がセキュリティチームの連絡先に関連リスクを伝えて変更を実行する場合、または変更が環境に高いまたは非常に高いセキュリティリスクをもたらす場合、AMS はセキュリティチームの連絡先にリスク承諾の形式で明示的な承認を求めます (次に説明）。AMS 顧客リスク承諾プロセスは、以下を目的として設計されています。 + リスクが明確に特定され、適切な所有者に伝えられるようにする + 環境に対する特定されたリスクを最小限に抑える + 組織のリスクプロファイルを理解している指定されたセキュリティ担当者から承認を取得して文書化する + 特定されたリスクに対する継続的な運用オーバーヘッドを削減する ## 技術標準と高リスクまたは非常に高いリスクにアクセスする方法 AMS 技術標準ドキュメントをレポートとして [https://console.aws.amazon.com/artifact/](https://console.aws.amazon.com/artifact/) で参照できるようにしました。AMS 技術標準ドキュメントを使用して、変更リクエスト (RFC) を送信する前に、承認されたセキュリティ担当者から変更のリスクを受け入れる必要があるかどうかを理解します。 デフォルトの AWS Managed Services (AMS) Technical Standards」を検索して、技術標準レポートを検索します。 AWS Artifact **** **AWSManagedServicesChangeManagementRole** **注記** AMS 技術標準ドキュメントは、単一アカウントランディングゾーンの Customer\$1ReadOnly\$1Role からアクセスできます。マルチアカウントランディングゾーンでは、セキュリティ管理者が使用する AWSManagedServicesAdminRole と、アプリケーションチームが使用する AWSManagedServicesChangeManagementRole を使用して、ドキュメントにアクセスできます。チームがカスタムロールを使用している場合は、その他 \$1 その他の RFC を作成してアクセスをリクエストすると、指定されたカスタムロールが更新されます。 # RFC 変更タイプの分類を理解する RFC の送信時に使用する変更タイプは、次の 2 つのカテゴリに分かれています。 + **デプロイ**: この分類はリソースの作成用です。 + **管理**: この分類は、リソースを更新または削除するために使用します。**管理**カテゴリには、インスタンスへのアクセス、AMIs暗号化または共有、スタックの開始、停止、再起動、または削除のための変更タイプも含まれています。 # RFC アクションとアクティビティの状態を理解する `RfcActionState` (API) / **Activity State** (コンソール) は、RFC に対する人間の介入またはアクションのステータスを理解するのに役立ちます。手動 RFCs に主に使用される は、ユーザーまたは AMS オペレーションに必要なアクションがいつ必要か`RfcActionState`を理解し、AMS オペレーションが RFC でアクティブに動作しているかを確認するのに役立ちます。これにより、RFC のライフサイクル中に RFC に対して実行されるアクションの透明性が向上します。 `RfcActionState` (API) / **アクティビティ状態** (コンソール) 定義: + **AwsOperatorAssigned**: AWS オペレーターが RFC でアクティブに作業しています。 + **AwsActionPending**: AWS からのレスポンスまたはアクションが必要です。 + **CustomerActionPending**: 顧客からのレスポンスまたはアクションが想定されます。 + **NoActionPending**: AWS または顧客からのアクションは必要ありません。 + **NotApplicable**: この状態は AWS オペレーターまたはお客様が設定することはできません。この機能がリリースされる前に作成された RFCs にのみ使用されます。 RFC アクションの状態は、送信された変更タイプが手動レビューを必要とし、スケジュールが **ASAP** に設定されているかどうかによって異なります。 + RFC **ActionState** は、遅延スケジューリングを使用した手動変更タイプのレビュー、承認、開始中に変更されます。 + スケジュールされた手動 RFC を送信すると、**ActionState** は自動的に **AwsActionPending** に変更され、オペレータが RFC を確認して承認する必要があることを示します。 + オペレーターが RFC のアクティブレビューを開始すると、**ActionState** は **AwsOperatorAssigned** に変わります。 + オペレータが RFC を承認すると、RFC ステータスはスケジュール済みに変わり、**ActionState** は自動的に **NoActionPending** に変わります。 + RFC のスケジュールされた開始時刻に達すると、RFC ステータスは **InProgress** に変わり、**ActionState** は自動的に **AwsActionPending** に変わり、RFC のレビューのためにオペレータを割り当てる必要があることを示します。 + オペレータが RFC のアクティブ実行を開始すると、**ActionState** が **AwsOperatorAssigned** に変更されます。 + 完了すると、オペレータは RFC を閉じます。これにより、**ActionState** が自動的に **NoActionPending** に変更されます。 ![\[遅延スケジューリングを使用した手動変更タイプのレビュー、承認、開始中の RFC ActionState の変更\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/actionStateRfc.png) **重要** アクションの状態を設定することはできません。RFC の変更に基づいて自動的に設定されるか、AMS 演算子によって手動で設定されます。 RFC にコレスポンデンスを追加すると、**ActionState** は自動的に **AwsActionPending** に設定されます。 RFC が作成されると、**ActionState** は自動的に **NoActionPending** に設定されます。 RFC が送信されると、**ActionState** は自動的に **AwsActionPending** に設定されます。 RFC が拒否、キャンセル、または完了し、ステータスが Success または Failure の場合、**ActionState** は自動的に **NoActionPending** にリセットされます。 アクション状態は自動 RFCs の両方で有効になりますが、これらのタイプの RFCs では通信が必要になることが多いため、主に手動 RFCs では重要です。 # RFC アクションの状態を確認するユースケースの例 **ユースケース: 手動 RFC プロセスの可視性** + 手動 RFC を送信すると、RFC アクションの状態は自動的に に変わり`AwsActionPending`、オペレータが RFC を確認して承認する必要があることを示します。オペレーターが RFC のアクティブレビューを開始すると、RFC アクションの状態は に変わります`AwsOperatorAssigned`。 + 承認され、スケジュールされ、実行を開始する準備ができている手動 RFC を検討してください。RFC ステータスが に変わると`InProgress`、RFC アクションの状態は自動的に に変わります`AwsActionPending`。オペレーター`AwsOperatorAssigned`が RFC のアクティブ実行を開始すると、再び に変わります。 + 手動 RFC が完了 (「成功」または「失敗」としてクローズ) すると、RFC アクションの状態が に変わり`NoActionPending`、顧客またはオペレーターからそれ以上のアクションが不要であることを示します。 **ユースケース: RFC 対応** + 手動 RFC が の場合`Pending Approval`、AMS オペレーターからさらに情報が必要になる場合があります。オペレーターは RFC にコレスポンデンスを投稿し、RFC アクションの状態を に変更します`CustomerActionPending`。新しい RFC 対応を追加して応答すると、RFC アクションの状態は自動的に に変わります`AwsActionPending`。 + 自動または手動 RFC が失敗した場合は、RFC の詳細にコレスポンデンスを追加し、RFC が失敗した理由を AMS オペレーターに尋ねることができます。コレスポンデンスが追加されると、RFC アクションの状態は自動的に に設定されます`AwsActionPending`。AMS オペレーターが RFC をピックアップしてコレスポンデンスを表示すると、RFC アクションの状態は に変わります`AwsOperatorAssigned`。オペレータが新しい RFC コレスポンデンスを追加して応答すると、RFC アクションの状態を に設定して`CustomerActionPending`、顧客からの別の応答が予想されることを示すか、 に設定して`NoActionPending`、顧客からの応答が不要または予想されることを示すことができます。 # RFC ステータスコードを理解する RFC ステータスコードは、リクエストの追跡に役立ちます。これらのステータスコードは、CLI 出力で RFC を実行するとき、またはコンソールで RFC リストページを更新することで確認できます。 RFC のコードは、RFC の詳細ページでも確認できます。 ![\[RFC ステータスコード。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/guiRfcStatusCodes.png) 送信していない RFC がリストに表示される場合があります。AMS 演算子が内部専用 CT を使用する場合は、RFC に送信され、RFC リストに表示されます。詳細については、「[内部のみの変更タイプ](ct-internals.md)」を参照してください。 **重要** RFC の状態変更の通知をリクエストできます。詳細については、[「RFC 状態変更通知](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-state-change-notices.html)」を参照してください。 **RFC ステータスコード** | Success | 失敗 | | --- | --- | | 編集中: RFC は作成されていますが、送信されていません PendingApproval / Submited: RFC が送信され、システムは承認が必要かどうかを判断し、必要に応じてその承認を取得します。 AWS による承認/顧客による承認: RFC が承認されました。自動 RFCsは AWS によって承認され、手動 RFCsはオペレーター、場合によっては顧客によって承認されます。 スケジュール済み: RFC は構文と要件チェックに合格し、実行がスケジュールされています InProgress: RFC が実行されています。複数のリソースをプロビジョニングする、または UserData が長時間実行される RFCs の実行には時間がかかることに注意してください。 実行済み: RFC が実行されました Success/Succeeded: RFC が正常に完了しました | 拒否: RFCsは通常、検証に失敗するため拒否されます。たとえば、使用できないリソース、つまりサブネットが指定されます。 キャンセル済み: RFCsは通常、設定された開始時刻が経過する前に検証に合格しないためキャンセルされます。 Failure: RFC が失敗しました。失敗の理由については出力の StatusReason を参照してください。AMS オペレーションは自動的にトラブルチケットを作成し、必要に応じてユーザーと通信します。 | **注記** キャンセルまたは拒否された RFCs「」も参照してください[RFCsを更新する](ex-update-rfcs.md)。 [UpdateRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_UpdateRfc.html) RFC が必要なすべての条件に合格した場合 (たとえば、すべての必須パラメータが指定されている場合）、ステータスは に変わります `PendingApproval` (自動 CTsでも承認が必要で、構文とパラメータチェックが合格すると自動的に行われます）。合格しない場合、ステータスは に変わります`Rejected`。`StatusReason` は拒否に関する情報を提供し、 `ExecutionOutput`フィールドは承認と完了に関する情報を提供します。エラーコードには以下が含まれます。 + InvalidRfcStateException: RFC は、呼び出されたオペレーションを許可しないステータスです。たとえば、RFC が送信済み状態に移行した場合、変更できなくなります。 + InvalidRfcScheduleException: StartTime、EndTime、または TimeoutInMinutes パラメータが超過しました。 + InternalServerError: システムに問題が発生しました。 + InvalidArgumentException: パラメータが正しく指定されていません。たとえば、許容できない値が使用されます。 + ResourceNotFoundException: スタック ID などの値が見つかりません。 変更が承認される前に、スケジュールされたリクエストの開始時刻と終了時刻 (変更実行ウィンドウとも呼ばれます) が発生した場合、RFC ステータスは に変わります`Canceled`。変更が承認されると、RFC ステータスは に変わります`Scheduled`。ASAP RFCs の変更実行ウィンドウは、送信された時刻に CT `ExpectedExecutionDuration`の値を加えたものです。 変更実行ウィンドウの到着前であればいつでも、スケジュールされた変更 (CLI `RequestedStartTime`の で送信) を変更またはキャンセルできます。スケジュールされた変更が変更された場合は、再送信する必要があります。 変更の開始時刻 (スケジュールまたは ASAP) が到着し、承認が完了すると、ステータスは に変わり`InProgress`、変更を加えることはできません。指定された変更実行ウィンドウ内に変更が完了すると、ステータスは に変わります`Success`。変更の一部が失敗した場合、または変更実行ウィンドウの終了時に変更がまだ進行中である場合、ステータスは に変わります`Failure`。 **注記** `InProgress`、、`Success`または の状態`Failure`の変更中、RFC を変更またはキャンセルすることはできません。 次の図は、CreateRFC 呼び出しから解決までの CreateRFCステータスを示しています。 ![\[CreateRFC 呼び出しから解決までの CreateRFCステータス。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/RfcStateFlow2.png) # RFC 更新 CTs と CloudFormation テンプレートドリフト検出を理解する AMS でプロビジョニングされたリソースは、変更された CloudFormation テンプレートを使用します。リソースのパラメータがサービスの AWS マネジメントコンソールから直接変更された場合、そのリソースの CloudFormation 作成レコードは同期しなくなります。この場合、AMS 更新変更タイプを使用して AMS のリソースを更新しようとすると、AMS は元のリソース設定を参照し、変更されたパラメータをリセットする可能性があります。このリセットはダメージを与える可能性があるため、追加の AMS 設定の変更が検出された場合、AMS は更新変更タイプの RFCs を禁止します。 更新変更タイプのリストについては、 コンソールフィルターを使用します。 ## ドリフト修復FAQs AMS ドリフト修復に関する質問と回答。ドリフト修復を開始するために使用できる変更タイプは 2 つあります。1 つは実行モード = 手動または「マネージドオートメーション」で、もう 1 つは実行モード = 自動です。 ### ドリフト修復でサポートされているリソース (ct-3kinq0u4l33zf) これらは、ドリフト修復変更タイプ (ct-3kinq0u4l33zf) でサポートされているリソースです。  リソースを修正するには、代わりに「マネージドオートメーション」 (ct-34sxfo53yuzah) 変更タイプを使用します。 ``` AWS::EC2::Instance AWS::EC2::SecurityGroup AWS::EC2::VPC AWS::EC2::Subnet AWS::EC2::NetworkInterface AWS::EC2::EIP AWS::EC2::InternetGateway AWS::EC2::NatGateway AWS::EC2::NetworkAcl AWS::EC2::RouteTable AWS::EC2::Volume AWS::AutoScaling::AutoScalingGroup AWS::AutoScaling::LaunchConfiguration AWS::AutoScaling::LifecycleHook AWS::AutoScaling::ScalingPolicy AWS::AutoScaling::ScheduledAction AWS::ElasticLoadBalancing::LoadBalancer AWS::ElasticLoadBalancingV2::Listener AWS::ElasticLoadBalancingV2::ListenerRule AWS::ElasticLoadBalancingV2::LoadBalancer AWS::CloudWatch::Alarm ``` ### ドリフト修復の変更タイプ AMS ドリフト修復変更タイプの使用に関する質問と回答。 ドリフト修復機能でサポートされているリソースのリストについては、「」を参照してください[ドリフト修復でサポートされているリソース (ct-3kinq0u4l33zf)](#drift-remeditate-faqs-sr)。 **重要** ドリフト修復はスタックテンプレートやパラメータを変更し、最新のスタックテンプレートやパラメータを使用するようにローカルテンプレートリポジトリまたはこれらのスタックを更新するオートメーションを更新する必要があります。同期せずに古いテンプレートやパラメータを使用すると、基盤となるリソースに有害な変更が生じる可能性があります。 マネージドオートメーションなし、自動、CT (ct-3kinq0u4l33zf) は、RFC あたり 10 個のリソースの修復のみをサポートします。残りのリソースを 10 個のバッチで修正するには、すべてのリソースが修正されるまで新しい RFCs を作成します。 どのドリフト修復変更タイプを使用すべきですか? 以下の場合は、**マネージドオートメーションなし**の自動 CT (ct-3kinq0u4l33zf) を使用することをお勧めします。 + 自動 CT を使用して既存のスタックリソースの更新を実行しようとすると、スタックが であるため RFC が拒否されます`DRIFTED`。 + 過去に Update CT を使用していて、スタックが DRIFTED になったため失敗しました。更新を再試行する必要はなく、代わりにマネージドオートメーション、手動、CT を使用できます。 **マネージドオートメーション**、手動 CT (ct-34sxfo53yuzah) を使用するのは、ドリフト修復でドリフトリソースタイプがサポートされていない場合、マネージドオートメーション、自動、CT (ct-3kinq0u4l33zf) がない場合、またはドリフト修復でマネージドオートメーション、自動、CT が失敗した場合のみです。 修復中にスタックにどのような変更が実行されますか? 修復には、ドリフトするプロパティに応じて、スタックテンプレートやパラメータの更新が必要です。修復は、修復中にスタックのスタックポリシーを更新し、修復が完了するとスタックポリシーを以前の値に復元します。 スタックテンプレートやパラメータに対して実行された変更を確認するにはどうすればよいですか? RFC へのレスポンスでは、変更の概要に以下の情報が表示されます。 + `ChangeSummaryJson`: ドリフト修復の一環として、スタックテンプレートやパラメータの変更の概要が含まれます。修復は複数のフェーズで実行されます。この変更の概要は、個々のフェーズの変更で構成されます。修復が成功した場合は、最後のフェーズの変更を確認します。順番に実行されるフェーズについては、JSON の ExecutionPlan を参照してください。たとえば、RestoreReferences セクションが存在する場合、常に最後に実行され、修正後の変更のための JSON が含まれます。DryRun モードで修復が実行された場合、これらの変更はスタックに適用されません。 + `PreRemediationStackTemplateAndConfigurationJson`: スタックで修復がトリガーされる前に、テンプレート、パラメータ、出力、StackPolicyBody を含む CloudFormation スタックの設定スナップショットが含まれます。 修復が実行されたら、何をする必要がありますか? RFC の概要で提供されている最新のテンプレートとパラメータを使用して、修復されたスタックを更新するローカルテンプレートリポジトリまたはオートメーションを更新する必要があります。古いテンプレートやパラメータを使用すると、スタックリソースにさらに破壊的な変更が生じる可能性があるため、これを行うことが重要です。 この修復中にアプリケーションは有効になりますか? 修復は、CloudFormation スタック設定でのみ実行されるオフラインプロセスです。基盤となるリソースでは更新は実行されません。 管理 \$1 その他 \$1 その他の RFCsを引き続き使用して、修復後にリソースの更新を実行できますか? 使用可能な自動 Update CTs を使用して、スタックリソースの更新を常に実行することをお勧めします。利用可能な Update CTsがユースケースをサポートしていない場合は、 管理 \$1 その他 \$1 その他のリクエストを使用します。 修復によってスタックに新しいリソースが作成されますか? 修復では、スタックに新しいリソースは作成されません。ただし、修復は新しい出力を作成し、スタックテンプレート[メタデータ](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/metadata-section-structure.html)セクションを更新して、参照用に修復の概要を保存します。 修復は常に成功しますか? 修復には、テンプレート設定を慎重に分析して検証し、実行できるかどうかを判断する必要があります。これらの検証が失敗した場合、修復プロセスは停止され、スタックテンプレートまたはパラメータに変更は実行されません。また、修復はサポートされているリソースタイプでのみ実行できます。 修復が成功しなかった場合にスタックリソースの更新を実行するにはどうすればよいですか? Management \$1 Other \$1 Other \$1 Update CT (ct-0xdawir96cy7k) を使用して変更をリクエストできます。AMS はこのようなシナリオをモニタリングし、修復ソリューションの改善に取り組んでいます。 サポートされているリソースタイプとサポートされていないリソースタイプの両方を持つスタックを修復できますか? はい。ただし、修復は、サポートされているリソースタイプがスタックで DRIFTED が見つかった場合にのみ実行されます。サポートされていないリソースタイプが DRIFTED の場合、修復は続行されません。 CFN 以外の取り込み CTs を使用して作成されたスタックの修復をリクエストできますか? はい。修正は、スタックの作成に使用される変更タイプに関係なく、スタックで実行できます。 修復前にスタックに実行される変更を知ることはできますか? はい。どちらの変更タイプも、スタックが修正された場合に実行される変更をリクエストするために使用できる **DryRun** オプションを提供します。ただし、最終的な修復の変更は、修復時にスタックに存在するドリフトによって異なる場合があります。 # RFCs **スケジュール**機能を使用すると、RFCs の開始時間を選択できます。**スケジューリング**機能では、次のオプションを使用できます。 + **この変更をできるだけ早く実行する**: AMS は、承認されるとすぐに RFC を実行します。ほとんどの CTsは自動的に承認されます。RFC を特定の時間に開始しない場合は、このオプションを使用します。 + **この変更をスケジュール**する: RFC を実行する日、時刻、タイムゾーンを設定します。自動変更タイプの場合、RFC の送信予定から少なくとも 10 分後に開始時刻をリクエストするのがベストプラクティスです。マネージドオートメーションの変更タイプでは、RFC の送信予定から少なくとも 24 時間後に開始時刻をリクエストする必要があります。RFC が設定された開始時刻までに承認されない場合、RFC は拒否されます。 ## RFC スケジュールを設定する RFC をスケジュールするには、次のいずれかの方法を使用します。 **この変更をできるだけ早く実行**します。 + コンソール: 何もしません。これはデフォルトの RFC スケジュールを使用します。 + API または CLI: RFC の作成オペレーションで `RequestedStartTime`および `RequestedEndTime`オプションを削除します。 **ASAP** RFCs は、送信後 30 日以内に承認されない場合、自動拒否されます。 **この変更をスケジュール**します。 + コンソール: ** この変更のスケジュール**ラジオボタンを選択します。**開始時間**領域が開きます。手動で日を入力するか、カレンダーウィジェットを使用して日を選択します。ISO 8601 形式で表される時刻を UTC で入力し、ドロップダウンリストを使用して場所を選択します。デフォルトでは、AMS は ISO 8601 形式 YYYYMMDDThhmmssZ または YYYY-MM-DDThh:mm:ssZ を使用します。どちらの形式も使用できます。 **注記** **デフォルトの終了時刻**は、入力した**開始時刻**から 4 時間です。スケジュールされた変更の終了**時刻**を 4 時間を超えて設定するには、API または CLI を使用して変更を実行します。 + API または CLI: RFC の作成オペレーションで `RequestedStartTime`および `RequestedEndTime`パラメータの値を送信します。設定済みの を渡`RequestedEndTime`しても、既に開始されている自動変更タイプの実行は停止されません。「マネージドオートメーション」の変更タイプで、AMS オペレーションの研究がまだ進行中に `RequestedEndTime`に到達し、AMS と通信している場合は、拡張機能をリクエストするか、RFC の再送信を求められる場合があります。 **ヒント** UTC タイムリードアウトの例については、Time-is ウェブサイトの[「UTC](https://time.is/UTC)」を参照してください。2:20pm: 2016-**2016-12-05T14**1205T142000Z 2016-12-05 の日付/時刻値の ISO 8601 形式の例。 **20161205T142000Z** 指定した場合.. + のみ`RequestedStartTime`、RFC はスケジュール済みと見なされ、 `RequestedEndTime`は `ExecutionDurationInMinutes`値を使用して入力されます。 + のみ`RequestedEndTime`、InvalidArgumentException をスローします。 + `RequestedStartTime` と の両方で`RequestedEndTime`、指定された開始時刻に `ExecutionDurationInMinutes`値を加えた`RequestedEndTime`値で を上書きします。 + `RequestedStartTime` も も、`RequestedEndTime`これらの値は null のままで、RFC は ASAP RFC として扱われます。 **注記** スケジュールされたすべての RFCs について、未指定の終了時刻は、指定された時刻に、送信された変更タイプの `ExpectedExecutionDurationInMinutes` 属性`RequestedStartTime`を加えた時刻として書き込まれます。たとえば、 `ExpectedExecutionDurationInMinutes`が「60」 (分) で、指定された `RequestedStartTime`が `2016-12-05T14:20:00Z` (2016 年 12 月 5 日午前 4 時 20 分) の場合、実際の終了時刻は 2016 年 12 月 5 日午前 5 時 20 分に設定されます。`ExpectedExecutionDurationInMinutes` 特定の変更タイプの を検索するには、次のコマンドを実行します。 ``` aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}" ``` ## RFC Priority オプションを使用する `execution mode = manual` 変更タイプで **Priority** オプションを使用して、リクエストの緊急性を AMS オペレーションに警告します。 の **Priority** オプション`execution mode = manual`: 手動 RFC の優先度を **High**、**Medium**、または **Low** に指定します。**High **に分類されRFCs は、RFCs サービスレベル目標 (SLOs) とその送信時間に従って、**Medium** に分類される RFC の前にレビューおよび承認されます。優先度**が低い**、または優先度が指定されていない RFCs は、送信された順序で処理されます。 # RFCs 承認が必要な (手動) CTs で送信される RFCs は、ユーザーまたは AMS によって承認される必要があります。事前承認CTs は自動的に処理されます。詳細については、「[CT 承認要件](constrained-unconstrained-ctis.md)」を参照してください。 **注記** 手動 CTs を使用する場合、AMS では ASAP **スケジューリング**オプション (コンソールで **ASAP** を選択し、API/CLI で開始時刻と終了時刻を空白のままにする) を使用することをお勧めします。これらの CTs では、AMS オペレータが RFC を調べ、承認して実行する前にお客様と通信する必要があるためです。これらの RFCsスケジュールする場合は、少なくとも 24 時間かかります。スケジュールされた開始時刻より前に承認が行われない場合、RFC は自動的に拒否されます。 承認が必要な RFC が AMS によって正常に送信された場合は、明示的に承認する必要があります。または、承認が必要な RFC を送信する場合は、AMS によって承認される必要があります。AMS が送信した RFC を承認する必要がある場合は、承認をリクエストする E メールまたはその他の事前定義された通信が送信されます。通信には RFC ID が含まれます。通信が送信されたら、次のいずれかを実行します。 + コンソールの承認または拒否: 関連する RFC の RFC 詳細ページを使用します。 ![\[RFC の詳細ページ。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/AMS_Console-App-Rej.png) + API / CLI 承認: [ApproveRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ApproveRfc.html) は変更を承認済みとしてマークします。アクションは、所有者とオペレーターの両方が必要な場合に実行する必要があります。以下は、CLI 承認コマンドの例です。次の例では、RFC\$1ID を適切な RFC ID に置き換えます。 ``` aws amscm approve-rfc --rfc-id RFC_ID ``` + API / CLI 拒否: [RejectRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_RejectRfc.html) は変更を拒否済みとしてマークします。CLI 拒否コマンドの例を次に示します。次の例では、RFC\$1ID を適切な RFC ID に置き換えます。 ``` aws amscm reject-rfc --rfc-id RFC_ID --reason "no longer relevant" ``` # RFC の制限された実行期間をリクエストする 以前はブラックアウトデーと呼ばれていましたが、特定の期間の制限をリクエストできます。この間は変更を実行できません。 制限された実行期間を設定するには、[UpdateRestrictedExecutionTimes](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_UpdateRestrictedExecutionTimes.html) API オペレーションを使用して、UTC で特定の期間を設定します。指定した期間は、指定した以前の期間よりも優先されます。指定された制限された実行時間内に RFC を送信すると、送信は無効な RFC スケジュールというエラーで失敗します。最大 200 の制限期間を指定できます。デフォルトでは、制限された期間は設定されていません。以下は、リクエストコマンドの例です (SAML 認証が設定されている）。 ``` aws amscm --profile saml update-restricted-execution-times --restricted-execution-times="[{\"TimeRange\":{\"StartTime\":\"2018-01-01T12:00:00Z\",\"EndTime\":\"2018-01-01T12:00:01Z\"}}]" ``` RestrictedExecutionTimes API オペレーションを実行して、現在の RestrictedExecutionTimes 設定を表示することもできます。 [ListRestrictedExecutionTimes](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListRestrictedExecutionTimes.html) 例: ``` aws amscm --profile saml list-restricted-execution-times ``` 指定された制限された実行時間内に RFC を送信する場合は、**OverrideRestrictedTimeRanges** の値を持つ **RestrictedExecutionTimesOverrideId** を追加し、通常どおり RFC を送信します。この方法は、緊急または緊急の RFC にのみ使用するのがベストプラクティスです。詳細については、[SubmitRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_SubmitRfc.html) の API リファレンスを参照してください。 # RFCs の作成、クローン作成、更新、検索、キャンセル 以下の例では、さまざまな RFC オペレーションについて説明します。 **Topics** + [RFC を作成する](ex-rfc-create-col.md) + [AMS コンソールを使用して RFCs のクローンを作成する (再作成）](ex-clone-rfcs.md) + [RFCsを更新する](ex-update-rfcs.md) + [RFCs の検索](ex-rfc-find-col.md) + [RFCs](ex-cancel-rfcs.md) # RFC を作成する ## コンソールを使用した RFC の作成 以下は、AMS コンソールでの RFC 作成プロセスの最初のページです。**クイックカード**が開き、**変更タイプの参照**がアクティブになっています。 ![\[Quick create section with options for common AWS stack operations and access management.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/quickCreate1.png) 以下は、AMS コンソールで RFC 作成プロセスの最初のページで、**カテゴリ別に選択**がアクティブになっています。 ![\[Create RFC page with change type categorization options for managed services environment.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/guiRfcCreate1-2.png) 仕組み: 1. **RFC **の作成ページに移動します。AMS コンソールの左側のナビゲーションペインで**RFCs** をクリックして RFCsリストページを開き、**RFC の作成**をクリックします。 1. デフォルトの変更タイプ参照ビューで一般的な**変更タイプ** (CT) を選択するか、**カテゴリ別選択ビューで CT **を選択します。 + **変更タイプ別に参照**: **クイック作成**エリアで一般的な CT をクリックすると、すぐに **RFC の実行**ページを開くことができます。クイック作成で古い CT バージョンを選択することはできません。 CTs をソートするには、**カード**ビューまたは**テーブル**ビューで**すべての変更タイプ**エリアを使用します。どちらのビューでも、CT を選択し、**RFC の作成**をクリックして **RFC の実行**ページを開きます。必要に応じて、RFC **の作成ボタンの横に古いバージョンで**作成オプションが表示されます。 **** + **カテゴリ別に選択**: カテゴリ、サブカテゴリ、項目、オペレーションを選択すると、CT 詳細ボックスが開き、必要に応じて**古いバージョンで作成する**オプションが表示されます。**RFC の作成**をクリックして、**RFC の実行**ページを開きます。 1. **RFC の実行**ページで、CT 名エリアを開き、CT の詳細ボックスを表示します。**件名**は必須です (**変更タイプの参照**ビューで CT を選択した場合は入力されます）。**追加設定**領域を開き、RFC に関する情報を追加します。 **実行設定**領域で、使用可能なドロップダウンリストを使用するか、必要なパラメータの値を入力します。オプションの実行パラメータを設定するには、**追加設定**エリアを開きます。 1. 完了したら、**実行** をクリックします。エラーがない場合、**RFC が正常に作成された**ページに、送信された RFC の詳細と最初の**実行出力**が表示されます。 1. **Run parameters** 領域を開き、送信した設定を確認します。ページを更新して RFC 実行ステータスを更新します。必要に応じて、RFC をキャンセルするか、ページ上部のオプションを使用してコピーを作成します。 ## CLI を使用した RFC の作成 仕組み: 1. インライン作成 (すべての RFC と実行パラメータを含む`create-rfc`コマンドを発行) またはテンプレート作成 (2 つの JSON ファイルを作成します。1 つは RFC パラメータ用、もう 1 つは実行パラメータ用) のいずれかを使用し、2 つのファイルを入力として`create-rfc`コマンドを発行します。どちらの方法もここで説明します。 1. 返された RFC ID を使用して RFC: `aws amscm submit-rfc --rfc-id ID` コマンドを送信します。 RFC: `aws amscm get-rfc --rfc-id ID` コマンドをモニタリングします。 変更タイプのバージョンを確認するには、次のコマンドを使用します。 ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID ``` **注記** 変更タイプのスキーマの一部であるかどうかにかかわらず、任意の RFC で任意の`CreateRfc`パラメータを使用できます。たとえば、RFC ステータスが変更されたときに通知を受け取るには、リクエストの RFC パラメータ部分 (実行パラメータではなく) `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"`にこの行を追加します。すべての CreateRfc パラメータのリストについては、[AMS 変更管理 API リファレンス](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html)を参照してください。 *インライン作成*: インラインで指定された実行パラメータ (インラインで実行パラメータを指定する場合は引用符をエスケープ) を指定して create RFC コマンドを発行し、返された RFC ID を送信します。たとえば、コンテンツを次のような内容に置き換えることができます。 ``` aws amscm create-rfc --change-type-id "CT_ID" --change-type-version "VERSION" --title "TITLE" --execution-parameters "{\"Description\": \"example\"}" ``` *テンプレートの作成*: **注記** RFC を作成するこの例では、Load Balancer (ELB) スタック変更タイプを使用します。 1. 関連する CT を見つけます。次のコマンドは、**項目**名に「ELB」が含まれている CT 分類の概要を検索し、Category、Item、Operation、ChangeTypeID の出力をテーブル形式で作成します (両方のサブカテゴリは です`Advanced stack components`)。 ``` aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries[?contains(Item,'ELB')].[Category,Item,Operation,ChangeTypeId]" --output table ``` ``` --------------------------------------------------------------------- | CtSummaries | +-----------+---------------------------+---------------------------+ | Deployment| Load balancer (ELB) stack | Create | ct-123h45t6uz7jl | | Management| Load balancer (ELB) stack | Update | ct-0ltm873rsebx9 | +-----------+---------------------------+---------------------------+ ``` 1. CT の最新バージョンを見つけます。 `ChangeTypeId` および `ChangeTypeVersion`: このウォークスルーの変更タイプ ID は `ct-123h45t6uz7jl` (ELB を作成) です。最新バージョンを確認するには、次のコマンドを実行します。 ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-123h45t6uz7jl ``` 1. オプションと要件について説明します。次のコマンドは、CreateElbParams.json. ``` aws amscm get-change-type-version --change-type-id "ct-123h45t6uz7jl" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateElbParams.json ``` 1. 実行パラメータ JSON ファイルを変更して保存します。この例では、CreateElbParams.json. プロビジョニング CT の場合、StackTemplateId はスキーマに含まれ、実行パラメータで送信する必要があります。 TimeoutInMinutes の場合、RFC が失敗するまでにスタックの作成に許可される分数。この設定は RFC の実行を遅らせませんが、十分な時間を与える必要があります (たとえば、「5」を指定しないでください）。UserData: Create EC2 and Create ASG が長時間実行される CTs」～「360」です。他のすべてのプロビジョニング CTs」をお勧めします。 スタックを作成する VPC の ID を指定します。VPC ID は CLI コマンド で取得できます`aws amsskms list-vpc-summaries`。 ``` { "Description": "ELB-Create-RFC", "VpcId": "VPC_ID", "StackTemplateId": "stm-sdhopv00000000000", "Name": "MyElbInstance", "TimeoutInMinutes": 60, "Parameters": { "ELBSubnetIds": ["SUBNET_ID"], "ELBHealthCheckHealthyThreshold": 4, "ELBHealthCheckInterval": 5, "ELBHealthCheckTarget": "HTTP:80/", "ELBHealthCheckTimeout": 60, "ELBHealthCheckUnhealthyThreshold": 5, "ELBScheme": false } } ``` 1. RFC JSON テンプレートを CreateElbRfc.json: ``` aws amscm create-rfc --generate-cli-skeleton > CreateElbRfc.json ``` 1. CreateElbRfc.json ファイルを変更して保存します。実行パラメータを別のファイルに作成したため、`ExecutionParameters`行を削除します。たとえば、コンテンツを次のような内容に置き換えることができます。 ``` { "ChangeTypeVersion": "2.0", "ChangeTypeId": "ct-123h45t6uz7jl", "Title": "Create ELB" } ``` 1. RFC を作成します。次のコマンドは、実行パラメータファイルと RFC テンプレートファイルを指定します。 ``` aws amscm create-rfc --cli-input-json file://CreateElbRfc.json --execution-parameters file://CreateElbParams.json ``` レスポンスで新しい RFC の ID を受け取り、それを使用して RFC を送信およびモニタリングできます。送信するまで、RFC は編集状態のままであり、開始されません。 ## ヒント **注記** AMS API/CLI を使用して、RFC JSON ファイルまたは CT 実行パラメータ JSON ファイルを作成せずに RFC を作成できます。これを行うには、 `create-rfc` コマンドを使用し、必要な RFC および実行パラメータを コマンドに追加します。これは「インライン作成」と呼ばれます。すべてのプロビジョニング CTs には、リソースのパラメータを含む`Parameters`配列が`execution-parameters`ブロックに含まれていることに注意してください。パラメータには、バックスラッシュ (\$1) でエスケープされた引用符が必要です。 RFC を作成する他の文書化された方法は、「テンプレートの作成」と呼ばれます。ここでは、RFC パラメータ用の JSON ファイルと実行パラメータ用の別の JSON ファイルを作成し、 `create-rfc` コマンドを使用して 2 つのファイルを送信します。これらのファイルはテンプレートとして機能し、将来の RFCs に再利用できます。 テンプレートを使用して RFCs を作成する場合、 コマンドを使用して、次に示すようにコマンドを発行することで、必要な内容の JSON ファイルを作成できます。コマンドは、表示された内容で「parameters.json」という名前のファイルを作成します。これらのコマンドを使用して RFC JSON ファイルを作成することもできます。 # AMS コンソールを使用して RFCs のクローンを作成する (再作成） AMS コンソールを使用して、既存の RFC のクローンを作成できます。 AMS コンソールを使用して RFC のクローンを作成または再作成するには、次の手順に従います。 1. 関連する RFC を見つけます。左側のナビゲーションで、**RFCs**をクリックします。 RFCsが開きます。 1. クローンを作成する RFC が見つかるまでページをスクロールします。**フィルター**オプションを使用してリストを絞り込みます。クローンを作成する RFC を選択します。 RFC の詳細ページが開きます。 1. **コピーの作成**をクリックします。 **変更リクエストの作成**ページが開き、すべてのオプションが元の RFC で として設定されます。 1. 必要な変更を加えます。追加オプションを設定するには、**基本**オプションを**アドバンス**トに変更します。すべてのオプションを設定したら、**送信**を選択します。 アクティブな RFC の詳細ページが開き、クローン RFC の新しい RFC ID が表示され、クローン RFC が RFC ダッシュボードに表示されます。 # RFCsを更新する RFC を更新して送信するか、再送信することで、拒否された RFC またはまだ送信されていない RFC を再送信できます。ほとんどの RFCs は拒否されることに注意してください。これは、指定された `RequestedStartTime` が送信前に渡されたか、指定された TimeoutInMinutes が RFC の実行に不十分であるためです (TimeoutInMinutes は成功した RFC を延長しないため、Amazon EC2 または長時間実行される UserData を持つ Amazon EC2 Auto Scaling グループでは、常にこれを「60」以上「360」以下に設定することをお勧めします）。このセクションでは、 `UpdateRfc` コマンドの CLI バージョンを使用して、新しい RFC パラメータで RFC を更新する方法、または文字列化された JSON または更新されたパラメータファイルを使用して新しいパラメータを更新する方法について説明します。 この例では、AMS UpdateRfc API の CLI バージョンの使用について説明します ([「RFC の更新](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/update-rfc.html)」を参照）。一部のリソース (DNS プライベートおよびパブリック、ロードバランサースタック、スタックパッチ適用設定) を更新するための変更タイプがありますが、RFC を更新する CT はありません。 一度に 1 つの UpdateRfc オペレーションを送信することをお勧めします。DNS スタックなどで複数の更新を送信すると、更新が同時に DNS を更新しようとして失敗する可能性があります。 必須データ: `RfcId`: 更新する RFC。 オプションデータ: `ExecutionParameters`: などの必須でないフィールドを更新しない限り`Description`、RFC が拒否またはキャンセルされた原因となった問題に対処するために、変更された実行パラメータを送信します。送信された NULL 以外の値はすべて、元の RFC の値を上書きします。 1. 関連する拒否またはキャンセルされた RFC を見つけて、このコマンドを使用できます ( 値を に置き換えることができます`Canceled`）。 ``` aws amscm list-rfc-summaries --filter Attribute=RfcStatusId,Value=Rejected ``` 1. 次のいずれかの RFC パラメータを変更できます。 ``` { "Description": "string", "ExecutionParameters": "string", "ExpectedOutcome": "string", "ImplementationPlan": "string", "RequestedEndTime": "string", "RequestedStartTime": "string", "RfcId": "string", "RollbackPlan": "string", "Title": "string", "WorstCaseScenario": "string"} ``` 説明フィールドを更新するコマンドの例： ``` aws amscm update-rfc --description "AMSTestNoOpsActionRequired" --rfc-id "RFC_ID" --region us-east-1 ``` ExecutionParameters VpcId フィールドを更新するコマンドの例： ``` aws amscm update-rfc --execution-parameters "{\"VpcId\":\"VPC_ID\"}" --rfc-id "RFC_ID" --region us-east-1 ``` RFC を、更新を含む実行パラメータファイルで更新するコマンドの例。[EC2 スタック \$1 作成](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ec2-stack-create.html)：」のステップ 2 の実行パラメータファイルの例を参照してください。 ``` aws amscm update-rfc --execution-parameters file://CreateEc2ParamsUpdate.json --rfc-id "RFC_ID" --region us-east-1 ``` 1. `submit-rfc` と RFC が最初に作成されたときと同じ RFC ID を使用して RFC を再送信します。 ``` aws amscm submit-rfc --rfc-id RFC_ID ``` RFC が成功した場合、コマンドラインに確認メッセージやエラーメッセージは表示されません。 1. リクエストのステータスをモニタリングし、実行出力を表示するには、次のコマンドを実行します。 ``` aws amscm get-rfc --rfc-id RFC_ID ``` # RFCs の検索 ## コンソールで変更リクエスト (RFC) を検索する AMS コンソールを使用して RFC を検索するには、次の手順に従います。 **注記** この手順は、スケジュールされた RFCs、つまり **ASAP** オプションを使用しなかった RFCs にのみ適用されます。 1. 左側のナビゲーションで、**RFCs**をクリックします。 RFCsが開きます。 1. リストをスクロールするか、**フィルター**オプションを使用してリストを絞り込みます。 RFC リストはフィルター条件ごとに変わります。 1. 目的の RFC のサブジェクトリンクを選択します。 RFC の詳細ページが開き、RFC ID などの情報が表示されます。 1. ダッシュボードに多数の RFCs がある場合は、**フィルター**オプションを使用して RFC で検索できます。 + **件名**: RFC の作成時に指定された件名またはタイトル (API/CLI の場合）。 + **RFC ID**: RFC の識別子。 + **アクティビティ状態**: RFC の状態がわかっている場合は、オペレータが現在 RFC を見ていることを示す **AwsOperatorAssigned**、**AwsActionPending** のいずれかを選択できます。つまり、AMS オペレータは RFC 実行を続行する前に何かを実行する必要があります。**CustomerActionPending** は、RFC 実行を続行する前に何らかのアクションを実行する必要があることを意味します。 + **ステータス**: RFC ステータスがわかっている場合は、次のいずれかを選択できます。 + **スケジュール**: スケジュールされた RFCs。 + **キャンセル済み: **キャンセルされた RFCs。 + **進行中**: RFCsが進行中です。 + **Success**: RFCs。 + **拒否:** 拒否された RFCs。 + **編集**中: 編集中の RFCs。 + **Failure**: 失敗した RFCs。 + **承認保留中**: AMS またはユーザーが承認するまで続行できない RFCs。通常、これは RFC を承認する必要があることを示します。サービスリクエストリストにこのサービス通知が表示されます。 + **変更タイプ**: Category****、**Subcategory**、**Item**、**Operation** を選択すると、変更タイプ ID が自動的に取得されます。 + **リクエストされた開始時刻**または**リクエストされた終了時刻**: このフィルターオプションでは、**前**または**後**を選択し、**日付**と、オプションで**時刻** (hh:mm とタイムゾーン) を入力できます。このフィルターは、スケジュールされた RFCs (ASAP RFCs。 + **ステータス**: **スケジュール**済み、**キャンセル済み**、**進行中**、**成功**、**拒否済み**、**編集中**、または**失敗**。 + **件名**: RFC にした件名 (または RFC が API/CLI で作成された場合はタイトル）。 + **変更タイプ ID**: RFC で送信された変更タイプの識別子を使用します。 次のスクリーンショットに示すように、検索ではフィルターを追加できます。 ![\[Search or filter options including Subject, RFC ID, Activity state, and various time-related fields.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/filterRfcAllOptions3.png) 1. 目的の RFC の件名リンクをクリックします。 RFC の詳細ページが開き、RFC ID などの情報が表示されます。 ## CLI を使用した変更リクエスト (RFC) の検索 複数のフィルターを使用して RFC を検索できます。 変更タイプのバージョンを確認するには、次のコマンドを使用します。 ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CT_ID ``` **注記** 変更タイプのスキーマの一部であるかどうかにかかわらず、任意の RFC で任意の`CreateRfc`パラメータを使用できます。たとえば、RFC ステータスが変更されたときに通知を受け取るには、リクエストの RFC パラメータ部分 (実行パラメータではなく) `--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"`にこの行を追加します。すべての CreateRfc パラメータのリストについては、[AMS 変更管理 API リファレンス](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_CreateRfc.html)を参照してください。 RFC ID を書き留めず、後で見つける必要がある場合は、AMS 変更管理 (CM) システムを使用して ID を検索し、フィルターまたはクエリを使用して結果を絞り込むことができます。 1. CM API [ListRfcSummaries](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListRfcSummaries.html) オペレーションにはフィルターがあります。論理 AND オペレーションで `Attribute`と `Value`を組み合わせて、または `Attribute`、、 に基づいて`Condition`結果を[フィルタリング](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_Filter.html)できます`Values`。 **RFC フィルタリング** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/ex-rfc-find-col.html) 例: SQS (SQS が CT のアイテム部分に含まれている) に関連するすべての RFCs の IDs を見つけるには、次のコマンドを使用できます。 ``` list-rfc-summaries --query 'RfcSummaries[?contains(Item.Name,`SQS`)].[Category.Id,Subcategory.Id,Type.Id,Item.Id,RfcId]' --output table ``` これは次のようなものを返します。 ``` ---------------------------------------------------------------------------- | ListRfcSummaries | +----------+--------------------------------+-------+-------+----------------+ |Deployment| Advanced Stack Components |SQS |Create |ct-123h45t6uz7jl| |Management| Monitoring & Notification |SQS |Update |ct-123h45t6uz7jl| +----------+--------------------------------+-------+-------+----------------+ ``` で利用できるもう 1 つのフィルター`list-rfc-summaries`は`AutomationStatusId`、自動または手動RFCs を検索する です。 ``` aws amscm list-rfc-summaries --filter Attribute=AutomationStatusId,Value=Automated ``` で使用できるもう 1 つのフィルター`list-rfc-summaries`は `Title` (コンソールの**件名**) です。 ``` Attribute=Title,Value=RFC-TITLE ``` RFCs を返す JSON の新しいリクエスト構造の例は次のとおりです。 + (タイトル 「Windows 2012」または「Amazon Linux」というフレーズが含まれます) + (RfcStatusId EQUALS "Success" OR "InProgress") AND + (20170101T00000Z <= RequestedStartTime <= 20170103T000000Z) AND (ActualEndTime <= 20170103T000000Z) ``` { "Filters": [ { "Attribute": "Title", "Values": ["Windows 2012", "Amazon Linux"], "Condition": "Contains" }, { "Attribute": "RfcStatusId", "Values": ["Success", "InProgress"], "Condition": "Equals" }, { "Attribute": "RequestedStartTime", "Values": ["20170101T000000Z", "20170103T000000Z"], "Condition": "Between" }, { "Attribute": "ActualEndTime", "Values": ["20170103T000000Z"], "Condition": "Before" } ] } ``` **注記** より高度な では`Filters`、AMS は今後のリリースで次のフィールドを廃止する予定です。 Value: Value フィールドは Filters フィールドの一部です。より高度な機能をサポートする Values フィールドを使用します。 RequestedEndTimeRange: より高度な機能をサポートするフィルターフィールド内で RequestedEndTime を使用します。 RequestedStartTimeRange: より高度な機能をサポートする Filters フィールド内で RequestedStartTime を使用します。 CLI クエリの使用の詳細については、[「--query オプションで出力をフィルタリングする方法](https://docs.aws.amazon.com/cli/latest/userguide/controlling-output.html#controlling-output-filter)」および「クエリ言語リファレンス」の[JMESPath 仕様](http://jmespath.org/specification.html)」を参照してください。 1. AMS コンソールを使用している場合: **RFCs**リストページに移動します。必要に応じて、RFC **サブジェクト**をフィルタリングできます。これは、RFC の作成`Title`時に RFC として入力した内容です。 ## ヒント **注記** この手順は、スケジュールされた RFCsつまり **ASAP** オプションを使用しなかった RFCs にのみ適用されます。 # RFCs コンソールまたは AMS API/CLI を使用して RFC をキャンセルできます。 コンソールで RFC をキャンセルするには、RFC リストで RFC を見つけて開きます。**キャンセル**をクリックします。 必要なデータ： + `Reason`: RFC をキャンセルする理由。 + `RfcId`: キャンセルする RFC。 1. 通常、RFC は送信直後にキャンセルします (そのため、RFC ID は便利です）。そうしないと、スケジュールして指定した開始時刻より前でない限りキャンセルできません。RFC ID を見つける必要がある場合は、このコマンドを使用できます (手動で承認された RFC `Value``PendingApproval`の代わりに を使用できます）。 ``` aws amscm list-rfc-summaries --filter Attribute=RfcStatusId,Value=Scheduled ``` 1. RFC をキャンセルするコマンドの例： ``` aws amscm cancel-rfc --reason "Bad Stack ID" --rfc-id "RFC_ID" --profile saml --region us-east-1 ``` # RFCs AMS コンソールには、RFCs。 ## RFC リストページを使用する (コンソール) AMS コンソール**RFCs** リストページには、次のオプションがあります。 + **フィルター**による高度な RFC 検索。詳細については、「[RFCs の検索](ex-rfc-find-col.md)」を参照してください。 + RFC が最後に**変更された**時刻を検索します。この値は、RFC ステータスが最後に変更された時刻を表します。 + RFC **サブジェクト**を使用した RFC の詳細の表示。このリンクを選択すると、その RFC の詳細ページが開きます。 + RFC ステータスの表示。詳細については、「[RFC ステータスコードを理解する](ex-rfc-status-codes.md)」を参照してください。 ![\[RFC リストページ。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/guiRfcListTable.png) ## RFC クイック作成を使用する (コンソール) RFC クイック作成カードまたはリストテーブルを使用するか、分類別に RFCs の変更タイプを選択します。 詳細については[RFC を作成する](ex-rfc-create-col.md)を参照してください。 ## RFC コレスポンデンスとアタッチメントを追加する (コンソール) コレスポンデンスは、送信後、承認前に RFC に追加できます。例えば、PendingApproval」の状態です。RFC が承認されると (「スケジュール済み」またはInProgress」の状態）、リクエストの変更として解釈される可能性があるため、コレスポンデンスを追加できません。RFC が完了すると (「キャンセル済み」、「拒否済み」、「成功」、または「失敗」の状態）、通信は再度有効になりますが、RFC が 30 日以上閉じられると通信は無効になります。 **注記** 各コレスポンデンスは 5,000 文字に制限されています。 **添付ファイルの制限:** + コレスポンデンスごとに 3 つの添付ファイルのみ。 + RFC ごとに 50 個のアタッチメントを制限します。 + 各アタッチメントのサイズは 5 MB 未満である必要があります。 + プレーンテキスト (`.txt`)、カンマ区切り値 ()、JSON (`.csv`)、YAML (`.json`) などのテキストファイルのみが受け入れられます`.yaml`。YAML 形式の場合は、ファイル拡張子 を使用してファイルをアタッチする必要があります`.yaml`。 **注記** XML コンテンツを含むテキストファイルは禁止されています。AMS と共有する XML コンテンツがある場合は、サービスリクエストを使用します。 + ファイル名は 255 文字に制限されており、数字、文字、スペース、ダッシュ (-)、アンダースコア (\$1)、ドット (.) のみを使用できます。 + RFC での添付ファイルの更新と削除は現在サポートされていません。 RFC にコレスポンデンスと添付ファイルを追加するには、次の手順に従います。 1. AMS コンソールの RFC の詳細ページで、ページの下部にある**「Correspondence**」セクションを見つけます。 通信前: ![\[空のコレスポンデンスセクション。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/correspondence-rfc-detail-new.png) いくつかの通信の後: ![\[返信フォームと受信した通信を示す通信セクション。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/correspondence-reply-form2.png) 1. 新しいコレスポンデンスを追加するには、**返信**テキストボックスにメッセージを入力します。対応に関連するファイルをアタッチするには、**添付ファイルの追加**を選択し、必要なファイルを選択します。 ![\[コメントボックスと添付ファイルを示すコレスポンデンスセクション。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/correspondence-add-attachments.png) 1. 完了したら、**送信**を選択します。 新しいコレスポンデンスは、添付ファイルへのリンクとともに、RFC の詳細ページのコレスポンデンスリストに表示されます。 ![\[受信した通信のリスト。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/correspondence-list2.png) # RFC E メール通知を設定する (コンソール) AMS コンソール**の変更リクエスト**の作成ページには、RFC の状態変更の通知を受信する E メールアドレスを追加するオプションがあります。 ![\[E メールアドレスを追加して、RFC の状態変更の通知を受信します。\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/emailNoticeOption2.png) さらに、次のような変更タイプに通知用の E メールアドレスを追加できます。 ``` aws amscm create-rfc --change-type-id --change-type-version 1.0 --title "TITLE" --notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}" ``` パラメータ部分ではなく、RFC パラメータ部分の任意の変更タイプのインラインリクエストまたはテンプレートリクエストに同様の行 (`--notification "{\"Email\": {\"EmailRecipients\" : [\"email@example.com\"]}}"`) を追加します。 # 一般的な RFC パラメータについて説明します。 以下は、送信する必要がある RFC パラメータと、RFCs。 + 変更タイプ情報: ChangeTypeId と ChangeTypeVersion。変更タイプ IDs[「変更タイプリファレンス](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html)」を参照してください。 CLI `list-change-type-classification-summaries`で `query`引数を使用して を実行し、結果を絞り込みます。たとえば、結果を絞り込んで、`Item`名前に「アクセス」を含むタイプを変更します。 ``` aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries [?contains (Item, 'access')].[Category,Subcategory,Item,Operation,ChangeTypeId]" --output table ``` を実行し`get-change-type-version`、変更タイプ ID を指定します。次のコマンドは、ct-2tylseo8rxfsc の CT バージョンを取得します。 ``` aws amscm get-change-type-version --change-type-id ct-2tylseo8rxfsc ``` + タイトル: RFC の名前。これは AMS コンソール RFC リストの RFC の**サブ**ジェクトになり、 `GetRfc` コマンドとフィルターを使用して検索できます。 `Title` + スケジュール: スケジュールされた RFC が必要な場合は、 パラメータ`RequestedStartTime`と `RequestedEndTime`パラメータを含めるか、**この変更のスケジュール**コンソールオプションを使用する必要があります。**ASAP** RFC (承認されるとすぐに実行される) の場合、CLI を使用するときは、 `RequestedStartTime`と `RequestedEndTime` null のままにします。コンソールを使用する場合は、**ASAP **オプションを受け入れます。 `RequestedStartTime` が見つからない場合、RFC は拒否されます。 + CT のプロビジョニング CTs: 実行パラメータ、または `Parameters`は、リソースのプロビジョニングに必要な特定の設定です。CT によって大きく異なります。 + 非プロビジョニング CTs: アクセス CTsやその他 \$1 その他などのリソースをプロビジョニングしない CT、またはスタックを削除しない CTs は、最小限の実行パラメータを持ち、`Parameters`ブロックはありません。 + RFCs、 を指定するか`TimeoutInMinutes`、RFC が失敗するまでにスタックの作成に何分かかるかも指定する必要があります。長時間実行される UserData の有効な値は 60 (分) から 360 までです。を超える前に実行を完了できない場合、RFC `TimeoutInMinutes` は失敗します。ただし、この設定では RFC の実行が遅延することはありません。 + S3 バケットや ELB などのインスタンスを作成する RFCs は、通常、最大 7 つのタグ (キーと値のペア) を追加できるスキーマを提供します。デプロイ \$1 高度なスタックコンポーネント \$1 タグ \$1 変更タイプの作成 (ct-3cx7we852p3af) を使用して RFC を送信することで、S3 バケットにタグを追加できます。EC2、EFS、RDS、および多層 (HA 2 階層および HA 1 階層) スキーマでは、最大 50 個のタグを使用できます。タグはスキーマの `ExecutionParameters`部分で指定されます。タグを提供することは大きな価値があります。詳細については、「[Amazon EC2 リソースにタグを付ける](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html)」を参照してください。 AMS コンソールを使用する場合は、タグを追加するには**追加設定**エリアを開く必要があります。 **ヒント** 多くの CT スキーマには、スキーマの上部近くに `Description` および `Name`フィールドがあります。これらのフィールドは、スタックまたはスタックコンポーネントに名前を付けるために使用されます。作成するリソースには名前を付けません。一部のスキーマは、作成するリソースに名前を付けるパラメータを提供し、そうでないスキーマもあります。たとえば、Create EC2 スタックの CT スキーマは、EC2 インスタンスに名前を付けるパラメータを提供しません。そのためには、キー「Name」と名前の値を持つタグを作成する必要があります。このようなタグを作成しない場合、EC2 インスタンスは EC2 コンソールに名前属性なしで表示されます。 ## RFC AWS リージョンオプションを使用する AMS API および CLI (`amscm` および `amsskms`) エンドポイントは にあります`us-east-1`。Security Assertion Markup Language (SAML) とフェデレーションする場合、 AWS リージョンを us-east-1 に設定するスクリプトがオンボーディング時に提供されます。SAML を使用する場合、コマンドを発行するときに `--region`オプションを指定する必要はありません。SAML が us-east-1 を使用するように設定されていても、アカウントがその AWS リージョンにない場合は、他の AWS コマンド (例: ) を発行するときに、アカウントオンボーディングリージョンを指定する必要があります`aws s3`。 **注記** このガイドに記載されているコマンド例のほとんどには、 `--region`オプションは含まれていません。 # RFC の毎日の E メールにサインアップする RFC ダイジェスト機能を使用して、過去 24 時間のアカウントの RFC アクティビティをまとめた毎日の E メールにサインアップできます。RFC ダイジェスト機能は、アカウントの RFCs。RFC ダイジェストは、応答を保留しているアクションを見逃す可能性を減らす可能性があります。 RFC ダイジェスト機能を有効にするには、AMS Cloud Service Delivery Manager (CSDM) にお問い合わせください。CSDM がサブスクライブします。RFC ダイジェスト E メールリストに含める E メールアドレス (またはエイリアス) を最大 20 個リクエストできます。現在の E メールスケジュールは 09:00 UTC-8 に固定されています。 RFC ダイジェスト機能をオフにするには、CSDM に連絡してリクエストしてください。 RFC ダイジェストを設定せず、RFCs に関する通知が必要な場合、または RFCs ダイジェストが提供する情報よりも RFC に関する詳細情報が必要な場合は、変更管理システムを使用して、情報が必要な個々の RFC ごとに CloudWatch Events 通知または E メール通知を設定します。RFC 通知の設定については、[「RFC 状態変更通知](https://docs.aws.amazon.com/managedservices/latest/userguide/rfc-state-change-notices.html)」を参照してください。 RFC ダイジェストに含まれるトピックは次のとおりです。 + Pending Customer Approval: **PendingApproval** ステータスの RFCs を一覧表示し、承認待ちにします + Pending Customer Reply: RFCsを待っている RFC を一覧表示します + 保留中の AWS 承認または応答: AMS が応答または承認を待っている RFCs を一覧表示します + 完了: **成功**、**失敗**、**キャンセル、****拒否**のステータスRFCs を一覧表示します RFC ダイジェストの例を次に示します。 ![\[RFC ダイジェストの例\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/RFCDigestExample.png) # 変更タイプとは? 変更タイプとは、AWS Managed Services (AMS) による変更リクエスト (RFC) が実行し、変更アクション自体、および変更のタイプを手動と自動で含めるアクションを指します。AMS には、他の Amazon ウェブサービスでは使用されていない変更タイプの大規模なコレクションがあります。これらの変更タイプは、リソースをデプロイ、管理、またはアクセスするための変更リクエスト (RFC) を送信するときに使用します。 **Topics** + [自動 CT と手動 CTs](ug-automated-or-manual.md) + [CT 承認要件](constrained-unconstrained-ctis.md) + [変更タイプバージョン](ct-versions.md) + [変更タイプを作成する](ct-creates.md) + [変更タイプを更新する](ct-updates.md) + [内部のみの変更タイプ](ct-internals.md) + [変更タイプスキーマ](ct-schemas.md) + [変更タイプのアクセス許可の管理](ct-permissions.md) + [変更タイプから機密情報を編集する](ct-redaction.md) + [クエリオプションを使用した変更タイプの検索](ug-find-ct-ex-section.md) # 自動 CT と手動 CTs 変更タイプの制約は、自動か手動かです。これは、AMS コンソールで**実行モード**と呼ばれる変更タイプの`AutomationStatusId`属性です。 自動変更タイプには期待される結果と実行時間があり、通常は 1 時間以内に AMS 自動システムを通じて実行されます (これは CT がプロビジョニングするリソースに大きく依存します）。手動変更タイプは一般的ではありませんが、実行する前に AMS オペレーターが RFC を操作する必要があるため、扱いが異なります。つまり、RFC 送信者と通信する場合があるため、手動の変更タイプでは、完了までにさまざまな時間がかかることがあります。 スケジュールされたすべての RFCs について、未指定の終了時刻は、指定された時刻に、送信された変更タイプの `ExpectedExecutionDurationInMinutes` 属性`RequestedStartTime`を加えた時刻として書き込まれます。たとえば、 `ExpectedExecutionDurationInMinutes`が「60」 (分) で、指定された `RequestedStartTime`が `2016-12-05T14:20:00Z` (2016 年 12 月 5 日午前 4 時 20 分) の場合、実際の終了時刻は 2016 年 12 月 5 日午前 5 時 20 分に設定されます。`ExpectedExecutionDurationInMinutes` 特定の変更タイプの を検索するには、次のコマンドを実行します。 ``` aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}" ``` **注記** スケジュールされた RFCs**の実行モード** = コンソールでは、少なくとも 24 時間後に実行するように設定する必要があります。 **注記** 手動 CTs を使用する場合、AMS では ASAP **スケジューリング**オプション (コンソールで **ASAP** を選択し、API/CLI で開始時刻と終了時刻を空白のままにする) を使用することをお勧めします。これらの CTs では、AMS オペレータが RFC を調べ、承認して実行する前にお客様と通信する必要があるためです。これらの RFCsスケジュールする場合は、少なくとも 24 時間かかります。スケジュールされた開始時刻より前に承認が行われない場合、RFC は自動的に拒否されます。 AMS は手動 CT に 4 時間以内に応答することを目指しており、できるだけ早く対応しますが、RFC が実際に実行されるまでにかなり時間がかかる場合があります。 手動であり、AMS レビューが必要な CTs**「変更タイプ CSV ファイル**」を参照してください。 **YouTube Video**: [ AMS RFCs の自動変更タイプを見つけるにはどうすればよいですか?](https://www.youtube.com/watch?v=sOzDuCCOduI&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=2&t=1s) AMS コンソールで CT **の実行モード**を見つけるには、**変更タイプの参照**検索オプションを使用する必要があります。結果には、一致する変更タイプまたは変更タイプの実行モードが表示されます。 AMS CLI を使用して`AutomationStatus`特定の変更タイプの を検索するには、次のコマンドを実行します。 ``` aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{AutomationStatus:AutomationStatus.Name}" ``` すべての [AMS 変更タイプに関する情報を提供する AMS 変更タイプリファレンス](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html)で変更タイプを検索することもできます。 **注記** AMS API/CLI は現在 AWS API/CLI の一部ではありません。AMS API/CLI にアクセスするには、AMS コンソールから AMS SDK をダウンロードします。 # CT 承認要件 AMS CTs には、常に **AwsApprovalId** と **CustomerApprovalId** の 2 つの承認条件があり、RFC が実行を承認するために AMS またはユーザー、あるいは誰かを必要とするかどうかを示します。 承認条件は実行モードと多少関連しています。詳細については、「」を参照してください[自動 CT と手動 CTs](ug-automated-or-manual.md)。 CT の承認条件を確認するには、[AMS 変更タイプリファレンス](https://docs.aws.amazon.com/managedservices/latest/ctref/index.html)を参照するか、[GetChangeTypeVersion](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetChangeTypeVersion.html) を実行します。どちらも CT モード`AutomationStatusId`または**実行モード**も提供します。 RFCs を承認するには、AMS コンソールを使用するか、次のコマンドを使用します。 ``` aws amscm approve-rfc --rfc-id RFC_ID ``` **CT 承認条件** | CT 承認条件が の場合 | からの承認が必要です | And | | --- | --- | --- | | `AwsApprovalId: Required` | AMS 変更タイプシステム | アクションは必要ありません。この条件は、自動 CTs。 | | `AwsApprovalId: NotRequiredIfSubmitter` | 送信された RFC が送信されたアカウント用である場合、AMS 変更タイプシステムであり、他に誰もいません。 | アクションは必要ありません。この条件は、AMS 演算子によって常にレビューされるため、手動 CTs では一般的です。 | | `CustomerApprovalId: NotRequired` | AMS 変更タイプシステム | RFC が構文チェックとパラメータチェックに合格すると、自動承認されます。 | | `CustomerApprovalId: Required` | AMS 変更タイプシステムとユーザー | 通知が送信され、通知に応答するか、[ApproveRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ApproveRfc.html) オペレーションを実行して、RFC を明示的に承認する必要があります。 | | `CustomerApprovalId: NotRequiredIfSubmitter` | RFC を送信した場合は、AMS 変更タイプシステムであり、他のユーザーではありません。 | RFC が構文チェックとパラメータチェックに合格すると、自動承認されます。 | | 緊急のセキュリティインシデントまたはパッチ | AMS | 自動承認され、実装されています。 | # 変更タイプバージョン 変更タイプはバージョン管理され、バージョンは変更タイプにメジャーな更新が行われたときに変更されます。 AMS コンソールを使用して変更タイプを選択したら、**追加設定**エリアを開き、変更タイプバージョンを選択するオプションがあります。API/CLI コマンドラインで変更タイプバージョンを指定することもできます。これは、次のようなさまざまな理由で実行できます。 + 更新する**変更**タイプのバージョンは、更新するリソースの作成に使用した変更タイプの**作成**バージョンと一致する必要があります。たとえば、ELB Create change type version 1 で作成した Elastic Load Balancer (ELB) インスタンスがあるとします。更新するには、ELB 更新バージョン 1 を選択します。 + 最新の変更タイプとは異なるオプションを含む変更タイプバージョンを使用します。AMS は主にセキュリティ上の理由から変更タイプを更新するため、これはお勧めしません。常に最新バージョンを選択することをお勧めします。 # 変更タイプを作成する 変更タイプの作成は、version-to-version更新変更タイプと一致します。つまり、リソースのプロビジョニングに使用する変更タイプバージョンは、後でそのリソースを変更するために使用する更新変更タイプのバージョンと一致する必要があります。例えば、Create S3 Bucket change type version 2.0 で S3 バケットを作成し、後で RFC を送信してその S3 バケットを変更する場合は、バージョン 3.0 の Update S3 Bucket change type version 2.0 があっても、Update S3 Bucket change type version 2.0 も使用する必要があります。 後で Update 変更タイプを使用してリソースを変更する場合に備えて、Create 変更タイプでリソースをプロビジョニングするときに使用する変更タイプ ID とバージョンを記録しておくことをお勧めします。 # 変更タイプを更新する AMS には、Create change types で作成されたリソースを更新するための Update change types が用意されています。Update 変更タイプは、リソースのプロビジョニングに最初に使用された Create 変更タイプとversion-to-version一致させる必要があります。 更新しやすいように、リソースをプロビジョニングするときに使用する変更タイプ ID とバージョンを記録しておくことをお勧めします。 **YouTube 動画**: [ 更新 CTs を使用して AWS Managed Services (AMS) アカウントのリソースを変更する方法を教えてください。](https://www.youtube.com/watch?v=dqb31yaAXhc&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=8&t=30s) # 内部のみの変更タイプ 内部使用のみの変更タイプを確認できます。これにより、AMS が実行できる、または実行するアクションがわかります。使用できる内部のみの変更タイプがある場合は、サービスリクエストを送信します。 例えば、管理 \$1 モニタリングと通知 \$1 CloudWatch アラーム抑制 \$1 CT の更新は内部専用です。AMS はこれを使用してインフラストラクチャの更新 (パッチ適用など) をデプロイし、更新が誤ってトリガーされる可能性のあるアラーム通知をオフにします。この CT が送信されると、RFC リストに CT の RFC が表示されます。RFC にデプロイされている内部専用 CT は、RFC リストに表示されます。 # 変更タイプスキーマ すべての変更タイプは、リソースの作成、変更、またはアクセスの入力に JSON スキーマを提供します。スキーマは、変更リクエスト (RFC) を作成するためのパラメータとその説明を提供します。 RFC が正常に実行されると、実行出力になります。RFCsプロビジョニングの場合、実行出力には CloudFormation のスタックを表す「stack\$1id」が含まれ、CloudFormation コンソールで検索できます。実行出力には、作成されたインスタンスの ID の出力が含まれる場合があり、その ID を使用して対応する AWS コンソールでインスタンスを検索できます。例えば、Create ELB CT 実行出力には、CloudFormation で検索可能な「stack\$1id」が含まれ、Elastic Load Balancing の Amazon EC2 コンソールで検索可能な key=ELB value= を出力します。 CT スキーマを見てみましょう。これは、かなり小さなスキーマである CodeDeploy Application Create のスキーマです。一部のスキーマには、非常に大きな`Parameter`領域があります。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/ct-schemas.html) **注記** このスキーマでは最大 7 つのタグを使用できますが、EC2、EFS、RDS、および多層作成スキーマでは最大 50 個のタグを使用できます。 # 変更タイプのアクセス許可の管理 カスタムポリシーを使用して、異なるグループまたはユーザーが使用できる変更タイプ (CTs) を制限できます。 これを行う方法の詳細については、「AMS ユーザーガイド」セクション「アクセス[許可の設定](https://docs.aws.amazon.com/managedservices/latest/userguide/setting-permissions.html)」を参照してください。 # 変更タイプから機密情報を編集する AMS 変更タイプスキーマ`"metadata":"ams:sensitive":"true"`は、パスワードなどの機密情報を含むパラメータに使用されるパラメータ属性を提供します。この属性を設定すると、指定された入力は不明瞭になります。このパラメータ属性は設定できないことに注意してください。ただし、AMS を使用して変更タイプを作成し、入力時に不明瞭にするパラメータがある場合は、これをリクエストできます。 # クエリオプションを使用した変更タイプの検索 この例では、AMS コンソールを使用して、送信する RFC の適切な変更タイプを見つける方法を示します。 コンソールまたは API/CLI を使用して、変更タイプ ID (CT) またはバージョンを検索できます。検索または分類の選択の 2 つの方法があります。どちらの選択タイプでも、**最も頻繁に使用される**、**最近使用された**、または**アルファベット**のいずれかを選択して検索をソートできます。 **YouTube 動画**: [ AWS Managed Services CLI を使用して RFC を作成する方法と、CT スキーマの場所を教えてください。](https://www.youtube.com/watch?v=IluDFwnJJFU&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=3&t=150s) AMS コンソールの **RFCs** -> **RFC の作成**ページで、次の操作を行います。 + **変更タイプによる参照** (デフォルト) を選択した場合、次のいずれかを実行します。 + **クイック作成**エリアを使用して、AMS の最も一般的な CTs から選択します。ラベルをクリックすると、**RFC の実行**ページが開き、**件名**オプションが自動的に入力されます。必要に応じて残りのオプションを完了し、**実行**をクリックして RFC を送信します。 + または、**すべての変更タイプ**領域までスクロールダウンし、オプションボックスに CT 名を入力し始めます。変更タイプ名を完全または完全に設定する必要はありません。関連する単語を入力して、変更タイプ ID、分類、または実行モード (自動または手動) で CT を検索することもできます。 デフォルトの**カード**ビューを選択すると、入力時に一致する CT カードが表示され、カードを選択して **RFC の作成**をクリックします。**テーブル**ビューを選択し、関連する CT を選択し、**RFC の作成**をクリックします。どちらの方法でも**、RFC の実行**ページが開きます。 + または、変更タイプの選択肢を確認するには、ページ上部の**「カテゴリ別に選択**」をクリックして、一連のドロップダウンオプションボックスを開きます。 + **カテゴリ**、**サブカテゴリ**、**項目**、**オペレーション**を選択します。その変更タイプの情報ボックスは、ページの下部にパネルが表示されます。 + 準備ができたら、**Enter** キーを押すと、一致する変更タイプのリストが表示されます。 + リストから変更タイプを選択します。その変更タイプの情報ボックスがページの下部に表示されます。 + 正しい変更タイプを取得したら、**RFC の作成**を選択します。 **注記** これらのコマンドを機能させるには、AMS CLI をインストールする必要があります。AMS API または CLI をインストールするには、AMS コンソール**のデベロッパーリソース**ページに移動します。AMS CM API または AMS SKMS API のリファレンスマテリアルについては、「 ユーザーガイド」の「AMS 情報リソース」セクションを参照してください。認証`--profile`のオプションを追加する必要がある場合があります。例: `aws amsskms ams-cli-command --profile SAML`。また、 など、すべての AMS コマンドが us-east-1 を使い果たすため、 `--region`オプションを追加する必要がある場合があります`aws amscm ams-cli-command --region=us-east-1`。 **注記** AMS API/CLI (amscm および amsskms) エンドポイントは、AWS N. Virginia リージョン にあります`us-east-1`。認証の設定方法や、アカウントとリソースが存在する AWS リージョンによっては、コマンドの発行`--region us-east-1`時に追加が必要になる場合があります。認証方法である場合は`--profile saml`、 を追加する必要がある場合もあります。 AMS CM API ([ListChangeTypeClassificationSummaries](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListChangeTypeClassificationSummaries.html) を参照) または CLI を使用して変更タイプを検索するには： フィルターまたはクエリを使用して検索できます。ListChangeTypeClassificationSummaries オペレーションには、`Category`、、`Subcategory``Item`、および の[フィルター](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_ListChangeTypeClassificationSummaries.html#amscm-ListChangeTypeClassificationSummaries-request-Filters)オプションがありますが`Operation`、値は既存の値と完全に一致する必要があります。CLI を使用する際のより柔軟な結果を得るには、 `--query`オプションを使用できます。 **AMS CM API/CLI を使用した変更タイプのフィルタリング** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/ug-find-ct-ex-section.html) 1. 変更タイプの分類を一覧表示する例をいくつか示します。 次のコマンドは、すべての変更タイプカテゴリを一覧表示します。 ``` aws amscm list-change-type-categories ``` 次の コマンドは、指定されたカテゴリに属するサブカテゴリを一覧表示します。 ``` aws amscm list-change-type-subcategories --category CATEGORY ``` 次の コマンドは、指定されたカテゴリとサブカテゴリに属する項目を一覧表示します。 ``` aws amscm list-change-type-items --category CATEGORY --subcategory SUBCATEGORY ``` 1. CLI クエリで変更タイプを検索する例をいくつか示します。 次のコマンドは、項目名に「S3」が含まれている CT 分類の概要を検索し、カテゴリ、サブカテゴリ、項目、オペレーション、変更タイプ ID の出力をテーブル形式で作成します。 ``` aws amscm list-change-type-classification-summaries --query "ChangeTypeClassificationSummaries [?contains(Item, 'S3')].[Category,Subcategory,Item,Operation,ChangeTypeId]" --output table ``` ``` +---------------------------------------------------------------+ | ListChangeTypeClassificationSummaries | +----------+-------------------------+--+------+----------------+ |Deployment|Advanced Stack Components|S3|Create|ct-1a68ck03fn98r| +----------+-------------------------+--+------+----------------+ ``` 1. その後、変更タイプ ID を使用して CT スキーマを取得し、パラメータを調べることができます。次のコマンドは、CreateS3Params.schema.json. ``` aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3Params.schema.json ``` CLI クエリの使用の詳細については、[「--query Option で出力をフィルタリングする方法](https://docs.aws.amazon.com/cli/latest/userguide/controlling-output.html#controlling-output-filter)」および「クエリ言語リファレンス」の[JMESPath Specification](http://jmespath.org/specification.html)」を参照してください。 1. 変更タイプ ID を取得したら、変更タイプのバージョンを検証して最新バージョンであることを確認することをお勧めします。次のコマンドを使用して、指定された変更タイプのバージョンを検索します。 ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=CHANGE_TYPE_ID ``` `AutomationStatus` 特定の変更タイプの を検索するには、次のコマンドを実行します。 ``` aws amscm --profile saml get-change-type-version --change-type-id CHANGE_TYPE_ID --query "ChangeTypeVersion.{AutomationStatus:AutomationStatus.Name}" ``` `ExpectedExecutionDurationInMinutes` 特定の変更タイプの を検索するには、次のコマンドを実行します。 ``` aws amscm --profile saml get-change-type-version --change-type-id ct-14027q0sjyt1h --query "ChangeTypeVersion.{ExpectedDuration:ExpectedExecutionDurationInMinutes}" ``` # AMS での RFC エラーのトラブルシューティング 多くの AMS プロビジョニング RFC 障害は、CloudFormation ドキュメントを通じて調査できます。[ AWS CloudFormation のトラブルシューティング: エラーのトラブルシューティング](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors)」を参照してください。 追加のトラブルシューティングの提案については、以下のセクションで説明します。 ## AMS の「管理」RFC エラー AMS "Management" カテゴリ変更タイプ (CTs) を使用すると、リソースへのアクセスをリクエストしたり、既存のリソースを管理したりできます。このセクションでは、いくつかの一般的な問題について説明します。 ### RFC アクセスエラー + RFC で指定したユーザー名と FQDN が正しく、ドメインに存在することを確認します。FQDN の検索については、[「FQDN の検索](https://docs.aws.amazon.com/managedservices/latest/userguide/find-FQDN.html)」を参照してください。 + アクセス用に指定したスタック ID が EC2-relatedスタックであることを確認します。ELB や Amazon Simple Storage Service (S3) などのスタックは、アクセス RFCsの候補ではなく、読み取り専用アクセスロールを使用してこれらのスタックリソースにアクセスします。スタック ID の検索については、[「スタック IDs](https://docs.aws.amazon.com/managedservices/latest/userguide/find-stack.html)」を参照してください。 + 指定したスタック ID が正しく、関連するアカウントに属していることを確認します。 その他のアクセス RFC 障害については、[「アクセス管理](https://docs.aws.amazon.com/managedservices/latest/userguide/access-mgmt.html)」を参照してください。 **YouTube 動画**: [ 拒否や失敗を避けるために、変更リクエスト (RFC) を適切に作成するにはどうすればよいですか?](https://www.youtube.com/watch?v=IFOn4Q-5Cas&list=PLhr1KZpdzukc_VXASRqOUSM5AJgtHat6-&index=5&t=242s) ### RFC (手動) CT スケジューリングエラー ほとんどの変更タイプは ExecutionMode=Automated ですが、一部は ExecutionMode=Manual であり、RFC の失敗を避けるためのスケジュール方法に影響します。 ExecutionMode=Manual のスケジュールされた RFCs は、AMS コンソールを使用して RFC を作成する場合は、少なくとも 24 時間後に実行するように設定する必要があります。 AMS は手動 CT に 8 時間以内に応答することを目指しており、できるだけ早く対応しますが、RFC が実際に実行されるまでにかなり時間がかかる場合があります。 ### 手動更新 CT RFCs の使用 CTs AMS オペレーションは、更新するスタックタイプの更新変更タイプがある場合、 管理 \$1 その他 \$1 スタックの更新に関するその他の RFCs を拒否します。 ### RFC スタック削除エラー RFC 削除スタックの失敗: Management \$1 Standard stacks \$1 Stack \$1 Delete CT を使用する場合、AMS スタック名を持つスタックの詳細なイベントが CloudFormation コンソールに表示されます。スタックは、AMS コンソールの名前と照合することで識別できます。 CloudFormation コンソールには、障害の原因に関する詳細が表示されます。 スタックを削除する前に、スタックの作成方法を考慮する必要があります。AMS CT を使用してスタックを作成し、スタックリソースを追加または編集しなかった場合、問題なく削除できます。ただし、削除スタック RFC を送信する前に、手動で追加されたリソースをスタックから削除することをお勧めします。たとえば、フルスタック CT (HA Two Tier) を使用してスタックを作成する場合、セキュリティグループ - SG1 が含まれます。次に AMS を使用して別のセキュリティグループ SG2 を作成し、フルスタックの一部として作成された SG1 内の新しい SG2 を参照し、削除スタック CT を使用してスタックを削除した場合、SG2 SG1 は削除しません。 SG1 **重要** スタックを削除すると、望ましくない結果や予期しない結果が生じる可能性があります。AMS は、この理由から、お客様に代わってスタックまたはスタックリソースを \$1削除しない\$1 ことを優先します。AMS は、ユーザーに代わって (送信された管理 \$1 その他 \$1 その他 \$1 変更タイプの更新を通じて）、削除する適切な自動変更タイプを使用して削除できないリソースのみを削除することに注意してください。追加の考慮事項: リソースが「削除保護」に対して有効になっている場合、管理 \$1 その他 \$1 その他 \$1 変更タイプを更新し、削除保護を削除した後、自動 CT を使用してそのリソースを削除することで、AMS はこれをブロック解除できます。 スタックに複数のリソースがあり、スタックリソースのサブセットのみを削除する場合は、CloudFormation Update 変更タイプを使用します ([CloudFormation Ingest Stack: Updatedating](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-cfn-ingest-update-col.html)」を参照）。管理 \$1 その他 \$1 その他 \$1 更新変更タイプを送信することもできます。AMS エンジニアは、必要に応じて変更セットの作成を支援します。 ドリフトが原因で CloudFormation Update CT の使用に問題がある場合、AMS は、管理 \$1 その他 \$1 その他 \$1 更新を送信してドリフトを解決し (AWS CloudFormation サービスでサポートされる限り）、自動 CT、管理/カスタムスタック/CloudFormation テンプレートからのスタック/変更セットと更新の承認を使用して検証および実行できる ChangeSet を提供できます。 AMS は、予期しない、または予期しないリソースの削除がないように、上記の制限を維持します。 詳細については、[AWS CloudFormation のトラブルシューティング: スタックの削除が失敗](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-delete-stack-fails)する」を参照してください。 ### 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 セキュリティレビューを理解する](rfc-security.md)。 一般的な IAM リソースリクエスト: + CloudEndure などの主要なクラウド互換アプリケーションに関連するポリシーをリクエストする場合は、AMS の事前承認された IAM CloudEndure ポリシー: [WIGs Cloud Endure ランディングゾーンの例](samples/wigs-ce-lz-examples.zip)ファイルを解凍し、 `customer_cloud_endure_policy.json` **注記** より寛容なポリシーが必要な場合は、CloudArchitect/CSDM とニーズについて話し合い、必要に応じて、ポリシーを実装する RFC を送信する前に AMS セキュリティレビューとサインオフを取得します。 + デフォルトでは、アカウントに AMS によってデプロイされたリソースを変更する場合は、既存のリソースに変更を加えるのではなく、そのリソースの修正されたコピーをリクエストすることをお勧めします。 + (ユーザーに許可をアタッチするのではなく) 人間のユーザーの許可をリクエストする場合は、その許可をロールにアタッチし、そのロールを引き受ける許可をユーザーに付与します。これを行う方法の詳細については、[「一時的な AMS Advanced コンソールアクセス](https://docs.aws.amazon.com/managedservices/latest/userguide/access-console-temp.html)」を参照してください。 + 一時的な移行またはワークフローに例外的なアクセス許可が必要な場合は、リクエストでそれらのアクセス許可の終了日を指定します。 + リクエストの件名についてセキュリティチームとすでに話し合っている場合は、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\$1COMPLETE 状態である可能性があります。 CloudFormation スタックを特定すると、イベントには作成に失敗した特定のリソースとその理由が表示されます。 ### CloudFormation ドキュメントを使用したトラブルシューティング ほとんどの AMS プロビジョニング RFCs は CloudFormation テンプレートを使用しており、そのドキュメントはトラブルシューティングに役立ちます。その CloudFormation テンプレートのドキュメントを参照してください。 + アプリケーションロードバランサーの作成の失敗: [ AWS::ElasticLoadBalancingV2::LoadBalancer (Application Load Balancer)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-elasticloadbalancingv2-loadbalancer.html) + Auto [ Scaling グループの作成: AWS::AutoScaling::AutoScalingGroup (Auto Scaling グループ)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-group.html) + memcached キャッシュの作成: [ AWS::ElastiCache::CacheCluster (キャッシュクラスター)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html) + Redis キャッシュの作成: [ AWS::ElastiCache::CacheCluster (キャッシュクラスター)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-elasticache-cache-cluster.html) + DNS ホストゾーンの作成 (DNS プライベート/パブリックの作成で使用): [ AWS::Route53::HostedZone (R53 ホストゾーン)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-route53-hostedzone.html) + DNS レコードセットの作成 (DNS プライベート/パブリックの作成で使用): [ AWS::Route53::RecordSet (リソースレコードセット)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-route53-recordset.html) + EC2 スタックの作成: [ AWS::EC2::Instance (Elastic Compute Cloud)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-instance.html) + Elastic File System (EFS): [ AWS::EFS::FileSystem (Elastic File System)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-efs-filesystem.html) + ロードバランサーの作成: [ AWS::ElasticLoadBalancing::LoadBalancer (Elastic Load Balancer)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-elb.html) + RDS DB の作成: [ AWS::RDS::DBInstance (リレーショナルデータベース)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-rds-database-instance.html) + Amazon S3 の作成: [ AWS::S3::Bucket (Simple Storage Service)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-s3-bucket.html) + キューの作成: [ AWS::SQS::Queue (簡易キューサービス)](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-sqs-queues.html) ### RFC AMI AMIs の作成エラー Amazon マシンイメージ (AMI) は、ソフトウェア構成 (オペレーティングシステム、アプリケーションサーバー、アプリケーションなど) を記録したテンプレートです。AMI から、クラウドで仮想サーバーとして実行される AMI のコピーである*インスタンス*を起動します。AMIs は非常に有用であり、EC2 インスタンスまたは Auto Scaling グループの作成に必要ですが、いくつかの要件に従う必要があります。 + に指定するインスタンスは、RFC が成功するためには停止状態`Ec2InstanceId`である必要があります。ASG は停止したインスタンスを終了するため、このパラメータに Auto Scaling グループ (ASG) インスタンスを使用しないでください。 + AMS Amazon マシンイメージ (AMI) を作成するには、AMS インスタンスから始める必要があります。インスタンスを使用して AMI を作成する前に、インスタンスが停止され、そのドメインから接続解除されていることを確認することで、インスタンスを準備する必要があります。詳細については、[「Sysprep を使用して標準 Amazon マシンイメージを作成する](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/Creating_EBSbacked_WinAMI.html#23ami-create-standard)」を参照してください。 + 新しい AMI に指定する名前は、アカウント内で一意である必要があります。そうしないと、RFC は失敗します。これを行う方法については、[「AMI \$1 Create](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html)」で説明されています。詳細については、「」および[「AWS AMI Design](https://aws.amazon.com/answers/configuration-management/aws-ami-design/)」を参照してください。 **注記** AMI 作成の準備の詳細については、[「AMI \$1 ](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html)作成」を参照してください。 ### EC2s または ASGs エラーを作成する RFCs タイムアウトを伴う EC2 または ASG 障害の場合、AMS では、使用する AMI がカスタマイズされているかどうかを確認することをお勧めします。その場合は、このガイドに含まれている AMI 作成手順 ([「AMI \$1 ](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html)作成」を参照) を参照して、AMI が正しく作成されたことを確認してください。カスタム AMI を作成する際の一般的な間違いは、 ガイドの手順に従って Sysprep の名前を変更または呼び出すことではありません。 ### RDS エラーを作成する RFCs Amazon Relational Database Service (RDS) の障害は、RDS の作成時にさまざまなエンジンを使用でき、各エンジンには独自の要件と制限があるため、さまざまな理由で発生する可能性があります。AMS RDS スタックを作成する前に、AWS RDS パラメータ値を慎重に確認してください。[CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html)」を参照してください。 サイズのレコメンデーションなど、Amazon RDS 全般の詳細については、[Amazon Relational Database Service ドキュメント](https://aws.amazon.com/documentation/rds/)」を参照してください。 ### Amazon S3s エラーを作成する RFCs S3 ストレージバケットを作成する際の一般的なエラーの 1 つは、バケットに一意の名前を使用しないことです。以前に送信したものと同じ名前の S3 バケット Create CT を送信した場合、その BucketName を持つ S3 バケットがすでに存在するため、失敗します。これは CloudFormation コンソールで詳しく説明され、スタックイベントにバケット名がすでに使用されていることが示されます。 ## RFC 検証エラーと実行エラー RFC の失敗と関連するメッセージは、選択した RFC の AMS コンソール RFC の詳細ページの出力メッセージによって異なります。 + 検証失敗の理由は、ステータスフィールドでのみ使用できます。 + 実行失敗の理由は、実行出力とステータスフィールドで使用できます。 ![\[Request for change details showing rejected status due to no domain trust found.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/rfcReason.png) ## RFC エラーメッセージ リストされた変更タイプ (CTs) で次のエラーが発生した場合は、これらのソリューションを使用して問題の原因を見つけて修正できます。 `{"errorMessage":"An error has occurred during RFC execution. We are investigating the issue.","errorType":"InternalError"}` 以下のトラブルシューティングオプションを参照してさらにサポートが必要な場合は、RFC 通信を通じて AMS をエンゲージしてください。詳細については、[「RFC の通信と添付ファイル (コンソール)](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-gui.html#ex-rfc-correspondence)」を参照してください。 ### ワークロード取り込み (WIGS) エラー **注記** Windows と Linux の両方の検証ツールは、オンプレミスサーバーと AWS の EC2 インスタンスに直接ダウンロードして実行できます。これらは、*「AMS Advanced Application Developer's Guide* [Migrating workloads: Linux pre-ingestion validation](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-linux-validation.html)」および[「Migrating workloads: Windows pre-ingestion validation](https://docs.aws.amazon.com/managedservices/latest/appguide/ex-migrate-instance-win-validation.html)」で確認できます。 + EC2 インスタンスがターゲット AMS アカウントに存在することを確認します。たとえば、AMS 以外のアカウントから AMS アカウントに AMI を共有している場合は、ワークロード取り込み RFC を送信する前に、共有 AMI を使用して AMS アカウントに EC2 インスタンスを作成する必要があります。 + インスタンスにアタッチされたセキュリティグループで送信トラフィックが許可されているかどうかを確認します。SSM エージェントはパブリックエンドポイントに接続できる必要があります。 + インスタンスに SSM エージェントに接続するための適切なアクセス許可があるかどうかを確認します。これらのアクセス許可には が付属`customer-mc-ec2-instance-profile`しています。これは EC2 コンソールで確認できます。 ![\[EC2 instance details showing IAM role set to customer-mc-ec2-instance-profile.\]](http://docs.aws.amazon.com/ja_jp/managedservices/latest/onboardingguide/images/ec2ConsoleWCircle.png) ### EC2 インスタンススタック停止エラー + インスタンスが既に停止状態か終了状態かを確認します。 + EC2 インスタンスがオンラインであり、`InternalError`エラーが表示された場合は、AMS が調査するためのサービスリクエストを送信します。 + 変更タイプ Management \$1 Advanced stack components \$1 EC2 instance stack \$1 Stop ct-3mvt2zkyveqj を使用して Auto Scaling グループ (ASG) インスタンスを停止することはできません。ASG インスタンスを停止する必要がある場合は、サービスリクエストを送信します。 ### EC2 インスタンススタックの作成エラー メッセージは CloudFormation からの`InternalError`ものです。CREATION\$1FAILED ステータスの理由です。CloudWatch スタックイベントでスタックの障害に関する詳細を確認するには、次の手順に従います。 + AWS マネジメントコンソールでは、スタックの作成、更新、または削除中にスタックイベントのリストを表示できます。このリストから失敗イベントを探して、そのイベントのステータスの理由を確認します。 ステータスの理由には、問題を理解するのに役立つ AWS CloudFormation または特定のサービスからのエラーメッセージが含まれている場合があります。 + スタックイベントの表示の詳細については、[「AWS マネジメントコンソールでの AWS CloudFormation スタックデータとリソースの表示](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-view-stack-data-resources.html)」を参照してください。 ### 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 には、サポートを求めるための手段がいくつか用意されています。 + オープン RFC または完了しても正しくない RFC のサポートが必要な場合は、RFC 双方向通信を通じて AMS をエンゲージします。詳細については、[「RFC の通信と添付ファイル (コンソール)](https://docs.aws.amazon.com/managedservices/latest/userguide/ex-rfc-gui.html#ex-rfc-correspondence)」を参照してください。 + マネージド環境に影響する AWS または AMS サービスのパフォーマンスの問題を報告するには、AMS コンソールを使用してインシデントレポートを送信します。詳細については、[「インシデントの報告](https://docs.aws.amazon.com/managedservices/latest/userguide/gui-ex-report-incident.html)」を参照してください。AMS インシデント管理の一般的な情報については、[「インシデント対応](https://docs.aws.amazon.com/managedservices/latest/userguide/sec-incident-response.html)」を参照してください。 + お客様またはお客様のリソースやアプリケーションが AMS とどのように連携しているかに関する具体的な質問、またはインシデントのエスカレーションについては、以下のうち 1 つ以上を E メールで送信してください。 1. まず、サービスリクエストまたはインシデントレポートのレスポンスに満足できない場合は、CSDM に E メールを送信してください: ams-csdm@amazon.com 1. 次に、エスカレーションが必要な場合は、AMS Operations Manager に E メールを送信できます (CSDM はおそらくこれを行います): ams-opsmanager@amazon.com 1. さらなるエスカレーションは、AMS Director: ams-director@amazon.com に行われます。 1. 最後に、AMS VP にいつでもアクセスできます: ams-vp@amazon.com