翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# CLI チュートリアル: 高可用性 2 層スタック (Linux/RHEL)
このセクションでは、AMS CLI を使用して高可用性 (HA) 2 層スタックを AMS 環境にデプロイする方法について説明します。
**注記**
このデプロイのチュートリアルは、AMZN Linux および RHEL 環境でテストされています。
タスクと必要な RFCs の概要：
1. インフラストラクチャの作成 (HA 2 層スタック）
1. CodeDeploy アプリケーション用の S3 バケットを作成する
1. WordPress アプリケーションバンドルを作成し、S3 バケットにアップロードする
1. CodeDeploy を使用してアプリケーションをデプロイする
1. WordPress サイトにアクセスしてログインし、デプロイを検証します。
# 開始する前に
Deployment \$1 Advanced Stack Components \$1 High Availability Two Tier Stack Advanced \$1 Create CT は、Auto Scaling グループ、ロードバランサー、データベース、CodeDeploy アプリケーション名とデプロイグループ (アプリケーションと同じ名前) を作成します。CodeDeploy の詳細については、[CodeDeploy とは」を参照してください。](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
このチュートリアルでは、UserData を含む高可用性 2 層スタック (アドバンスト) RFC を使用し、CodeDeploy がデプロイできる WordPress バンドルを作成する方法について説明します。
この例`UserData`に示す は、http://169.254.169.254/latest/meta-data/ で利用可能な EC2 インスタンスメタデータサービスをクエリすることで、実行中のインスタンス内からインスタンス ID、リージョンなどのインスタンスメタデータを取得します。ユーザーデータスクリプトのこの行: は`REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//')`、メタデータサービスからサポートされているリージョンの \$1REGION 変数にアベイラビリティーゾーン名を取得し、それを使用して CodeDeploy エージェントをダウンロードする S3 バケットの URL を完了します。169.254.169.254 IP は VPC 内でのみルーティング可能です (すべての VPCsはサービスをクエリできます）。サービスの詳細については、[「インスタンスメタデータとユーザーデータ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html)」を参照してください。また、UserData として入力されたスクリプトは「ルート」ユーザーとして実行され、「sudo」コマンドを使用する必要はありません。
このチュートリアルでは、以下のパラメータをデフォルト値 (表示) のままにします。
+ Auto Scaling グループ: `Cooldown=300, DesiredCapacity=2, EBSOptimized=false, HealthCheckGracePeriod=600, IAMInstanceProfile=customer-mc-ec2-instance-profile, InstanceDetailedMonitoring=true, InstanceRootVolumeIops=0, InstanceRootVolumeType=standard, InstanceType=m3.medium, MaxInstances=2, MinInstances=2, ScaleDownPolicyCooldown=300, ScaleDownPolicyEvaluationPeriods=4, ScaleDownPolicyPeriod=60, ScaleDownPolicyScalingAdjustment=-1, ScaleDownPolicyStatistic=Average, ScaleDownPolicyThreshold=35, ScaleMetricName=CPUUtilization, ScaleUpPolicyCooldown=60, ScaleUpPolicyEvaluationPeriods=2, ScaleUpPolicyPeriod=60, ScaleUpPolicyScalingAdjustment=2, ScaleUpPolicyStatistic=Average, ScaleUpPolicyThreshold=75`。
+ Load Balancer: `HealthCheckInterval=30, HealthCheckTimeout=5`。
+ データベース: `BackupRetentionPeriod=7, Backups=true, InstanceType=db.m3.medium, IOPS=0, MultiAZ=true, PreferredBackupWindow=22:00-23:00, PreferredMaintenanceWindow=wed:03:32-wed:04:02, StorageEncrypted=false, StorageEncryptionKey="", StorageType=gp2`。
+ アプリケーション: `DeploymentConfigName=CodeDeployDefault.OneAtATime`。
+ S3 バケット: `AccessControl=Private`。
その他の設定：
`RequestedStartTime` RFC をスケジュール`RequestedEndTime`する場合は、 を使用して正しい UTC 時間[Time.is](https://time.is/UTC)を決定できます。提供された例は適切に調整する必要があります。開始時刻が経過すると、RFC は続行できません。または、これらの値をオフのままにして、承認が渡されるとすぐに実行される ASAP RFC を作成することもできます。
**注記**
以下に示すものとは異なる設定を選択できるパラメータが多数あります。この例に示すパラメータの値はテスト済みですが、適切ではない可能性があります。
# インフラストラクチャを作成する
開始する前に次のデータを収集すると、デプロイがより速くなります。
必須データにはスタックがあります。
+ AutoScalingGroup:
+ `UserData`: この値は、このチュートリアルで提供されています。これには、CodeDeploy のリソースをセットアップし、CodeDeploy エージェントを起動するためのコマンドが含まれています。
+ `AMI-ID`: この値は、Auto Scaling グループ (ASG) がスピンアップする EC2 インスタンスの種類を決定します。アカウントで「customer-」で始まり、目的のオペレーティングシステムの AMI を選択してください。AMS SKMS API リファレンスで AMI IDs を検索するには、AWS Artifact コンソールの**レポート**タブを参照してください。 オペレーション (CLI: list-amis) または AMS コンソール VPCs-> VPCsの詳細ページ。このチュートリアルは、Linux AMI を使用するように設定された ASGs を対象としています。
+ データベース:
+ これらのパラメータ 、`DBEngine`、 は、例に示す値がテスト済みですが`EngineVersion`、状況に応じて設定`LicenseModel`する必要があります。
+ これらのパラメータ 、`DBName`、`MasterUsername`、 `MasterUserPassword`は`RDSSubnetIds`、アプリケーションバンドルをデプロイするときに必要です。RDSSubnetIds には、2 つのプライベートサブネットを使用します。
+ LoadBalancer:
+ これらのパラメータ 、`DBEngine`、 は、例に示す値がテスト済みですが`EngineVersion`、状況に応じて設定`LicenseModel`する必要があります。
+ `ELBSubnetIds`: 2 つのパブリックサブネットを使用します。
+ アプリケーション: `ApplicationName`値は CodeDeploy アプリケーション名と CodeDeploy デプロイグループ名を設定します。これを使用してアプリケーションをデプロイします。アカウント内で一意である必要があります。アカウントで CodeDeploy 名を確認するには、CodeDeploy コンソール」を参照してください。この例では「WordPress」を使用していますが、その値を使用する場合は、まだ使用されていないことを確認してください。
この手順では、高可用性 2 層スタック (アドバンスド) CT (ct-06mjngx5flwto) と Create S3 storage CT (ct-1a68ck03fn98r) を使用します。認証されたアカウントから、コマンドラインで以下のステップに従います。
1. インフラストラクチャスタックを起動します。
1. HA 2 層スタック CT の実行パラメータ JSON スキーマを、CreateStackParams.json.
```
aws amscm get-change-type-version --change-type-id "ct-06mjngx5flwto" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateStackParams.json
```
1. スキーマを変更します。必要に応じて*変数*を置き換えます。たとえば、ASG が作成する EC2 インスタンスに必要な OS を使用します。後でアプリケーションのデプロイに使用する`ApplicationName`ため、 を記録します。最大 50 個のタグを追加できます。
```
{
"Description": "HA two tier stack for WordPress",
"Name": "WordPressStack",
"TimeoutInMinutes": 360,
"Tags": [
{
"Key": "ApplicationName",
"Value": "WordPress"
}
],
"AutoScalingGroup": {
"AmiId": "AMI-ID",
"UserData": "#!/bin/bash \n
REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//') \n
yum -y install ruby httpd \n
chkconfig httpd on \n
service httpd start \n
touch /var/www/html/status \n
cd /tmp \n
curl -O https://aws-codedeploy-$REGION.s3.amazonaws.com/latest/install \n
chmod +x ./install \n
./install auto \n
chkconfig codedeploy-agent on \n
service codedeploy-agent start"
},
"LoadBalancer": {
"Public": true,
"HealthCheckTarget": "HTTP:80/status"
},
"Database": {
"DBEngine": "MySQL",
"DBName": "wordpress",
"EngineVersion": "8.0.16 ",
"LicenseModel": "general-public-license",
"MasterUsername": "admin",
"MasterUserPassword": "p4ssw0rd"
},
"Application": {
"ApplicationName": "WordPress"
}
}
```
1. CreateStackRfc.CreateStackRfc.json:
```
aws amscm create-rfc --generate-cli-skeleton > CreateStackRfc.json
```
1. RFC テンプレートを次のように変更して保存します。コンテンツを削除して置き換えることができます。`RequestedStartTime` と `RequestedEndTime`はオプションになりました。これらを除外すると、承認されるとすぐに実行される ASAP RFC が作成されます (通常は自動的に実行されます）。スケジュールされた RFC を送信するには、これらの値を追加します。
```
{
"ChangeTypeVersion": "3.0",
"ChangeTypeId": "ct-06mjngx5flwto",
"Title": "HA-Stack-For-WP-RFC"
}
```
1. CreateStackRfc.json ファイルと CreateStackParams.json 実行パラメータファイルを指定して、RFC を作成します。
```
aws amscm create-rfc --cli-input-json file://CreateStackRfc.json --execution-parameters file://CreateStackParams.json
```
レスポンスで RFC ID を受け取ります。後続のステップの ID を保存します。
1. RFC を送信します。
```
aws amscm submit-rfc --rfc-id RFC_ID
```
RFC が成功した場合、出力は受信されません。
1. RFC ステータスを確認するには、 を実行します。
```
aws amscm get-rfc --rfc-id RFC_ID
```
RFC ID を書き留めておきます。
1. S3 バケットを起動する
開始する前に次のデータを収集すると、デプロイがより速くなります。
必須データ S3 バケット：
+ `VPC-ID`: この値により、S3 バケットの場所が決まります。以前に使用したものと同じ VPC ID を使用します。
+ `BucketName`: この値は S3 バケット名を設定します。これを使用してアプリケーションバンドルをアップロードします。アカウントのリージョン全体で一意である必要があり、大文字を含めることはできません。BucketName の一部としてアカウント ID を含めることは必須ではありませんが、後でバケットを識別しやすくなります。アカウントに存在する S3 バケット名を確認するには、アカウントの Amazon S3 コンソールに移動します。
1. S3 ストレージ作成 CT の実行パラメータ JSON スキーマを CreateS3StoreParams.json.
```
aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3StoreParams.json
```
1. スキーマを次のように変更し、コンテンツを削除して置き換えることができます。*VPC\$1ID* を適切に置き換えます。この例の値はテスト済みですが、適切ではない可能性があります。
**ヒント**
はアカウントのリージョン全体で一意`BucketName`である必要があり、大文字を含めることはできません。BucketName の一部としてアカウント ID を含めることは必須ではありませんが、後でバケットを識別しやすくなります。アカウントに存在する S3 バケット名を確認するには、アカウントの Amazon S3 コンソールに移動します。
```
{
"Description": "S3BucketForWordPressBundle",
"VpcId": "VPC_ID",
"StackTemplateId": "stm-s2b72beb000000000",
"Name": "S3BucketForWP",
"TimeoutInMinutes": 60,
"Parameters": {
"AccessControl": "Private",
"BucketName": "ACCOUNT_ID-BUCKET_NAME"
}
}
```
1. CreateRfc の JSON テンプレートを、CreateS3StoreRfc.json:
```
aws amscm create-rfc --generate-cli-skeleton > CreateS3StoreRfc.json
```
1. CreateS3StoreRfc.json ファイルを変更して保存し、コンテンツを削除して置き換えることができます。`RequestedStartTime` と `RequestedEndTime`はオプションになりました。これらを除外すると、承認されるとすぐに実行される ASAP RFC が作成されます (通常は自動的に実行されます）。スケジュールされた RFC を送信するには、これらの値を追加します。
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-1a68ck03fn98r",
"Title": "S3-Stack-For-WP-RFC"
}
```
1. CreateS3StoreRfc.json ファイルと CreateS3StoreParams.json 実行パラメータファイルを指定して、RFC を作成します。
```
aws amscm create-rfc --cli-input-json file://CreateS3StoreRfc.json --execution-parameters file://CreateS3StoreParams.json
```
レスポンスで新しい RFC の RfcId を受け取ります。後続のステップの ID を保存します。
1. RFC を送信します。
```
aws amscm submit-rfc --rfc-id RFC_ID
```
RFC が成功した場合、出力は受信されません。
1. RFC ステータスを確認するには、 を実行します。
```
aws amscm get-rfc --rfc-id RFC_ID
```
# アプリケーションの作成、アップロード、デプロイ
まず、WordPress アプリケーションバンドルを作成し、CodeDeploy CT を使用してアプリケーションを作成してデプロイします。 CTs
1. WordPress をダウンロードし、ファイルを抽出して ./scripts ディレクトリを作成します。
Linux コマンド：
```
wget https://github.com/WordPress/WordPress/archive/master.zip
```
Windows: ブラウザウィンドウ`https://github.com/WordPress/WordPress/archive/master.zip`に貼り付け、zip ファイルをダウンロードします。
パッケージをアセンブルする一時ディレクトリを作成します。
Linux:
```
mkdir /tmp/WordPress
```
Windows: WordPress」ディレクトリを作成します。後でディレクトリパスを使用します。
1. WordPress ソースをWordPress」ディレクトリに抽出し、./scripts ディレクトリを作成します。
Linux:
```
unzip master.zip -d /tmp/WordPress_Temp
cp -paf /tmp/WordPress_Temp/WordPress-master/* /tmp/WordPress
rm -rf /tmp/WordPress_Temp
rm -f master
cd /tmp/WordPress
mkdir scripts
```
Windows: 作成したWordPress」ディレクトリに移動し、そこに「scripts」ディレクトリを作成します。
Windows 環境の場合は、スクリプトファイルのブレークタイプを Unix (LF) に設定してください。Notepad \$1\$1 では、これはウィンドウの右下にあるオプションです。
1. WordPress ディレクトリに CodeDeploy **appspec.yml** ファイルを作成します (例をコピーする場合は、インデント、各スペース数を確認します）。重要: WordPress ファイル (この場合は WordPress ディレクトリ) を目的の宛先 (/var/www/html/WordPress) にコピーするための WordPress 「ソース」パスが正しいことを確認します。この例では、appspec.yml ファイルは WordPress ファイルを含む ディレクトリにあるため、「/」のみが必要です。また、Auto Scaling グループに RHEL AMI を使用した場合でも、「os: linux」行はそのままにしておきます。appspec.yml ファイルの例：
```
version: 0.0
os: linux
files:
- source: /
destination: /var/www/html/WordPress
hooks:
BeforeInstall:
- location: scripts/install_dependencies.sh
timeout: 300
runas: root
AfterInstall:
- location: scripts/config_wordpress.sh
timeout: 300
runas: root
ApplicationStart:
- location: scripts/start_server.sh
timeout: 300
runas: root
ApplicationStop:
- location: scripts/stop_server.sh
timeout: 300
runas: root
```
1. WordPress ./scripts ディレクトリに bash ファイルスクリプトを作成します。
まず、次の内容`config_wordpress.sh`で を作成します (必要に応じて、wp-config.php ファイルを直接編集できます）。
**注記**
*DBName* を HA スタック RFC で指定された値 (例: ) に置き換えます`wordpress`。
*DB\$1MasterUsername* を HA スタック RFC で指定された`MasterUsername`値 ( など`admin`) に置き換えます。
*DB\$1MasterUserPassword* を HA スタック RFC で指定された`MasterUserPassword`値 ( など`p4ssw0rd`) に置き換えます。
*DB\$1ENDPOINT* を HA スタック RFC の実行出力のエンドポイント DNS 名 (例: ) に置き換えます`srt1cz23n45sfg.clgvd67uvydk.us-east-1.rds.amazonaws.com`。これは、[GetRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetRfc.html) オペレーション (CLI: get-rfc --rfc-id RFC\$1ID) または以前に送信した HA スタック RFC の AMS コンソール RFC の詳細ページで確認できます。
```
#!/bin/bash
chmod -R 755 /var/www/html/WordPress
cp /var/www/html/WordPress/wp-config-sample.php /var/www/html/WordPress/wp-config.php
cd /var/www/html/WordPress
sed -i "s/database_name_here/DBName/g" wp-config.php
sed -i "s/username_here/DB_MasterUsername/g" wp-config.php
sed -i "s/password_here/DB_MasterUserPassword/g" wp-config.php
sed -i "s/localhost/DB_ENDPOINT/g" wp-config.php
```
1. 同じディレクトリに、次の内容`install_dependencies.sh`で を作成します。
```
#!/bin/bash
yum install -y php
yum install -y php-mysql
yum install -y mysql
service httpd restart
```
**注記**
HTTPS は、ヘルスチェックを最初から機能させるために、起動時にユーザーデータの一部としてインストールされます。
1. 同じディレクトリに、次の内容`start_server.sh`で を作成します。
+ Amazon Linux インスタンスの場合は、以下を使用します。
```
#!/bin/bash
service httpd start
```
+ RHEL インスタンスの場合は、以下を使用します (追加のコマンドは、SELINUX が WordPress を受け入れることを許可するポリシーです）。
```
#!/bin/bash
setsebool -P httpd_can_network_connect_db 1
setsebool -P httpd_can_network_connect 1
chcon -t httpd_sys_rw_content_t /var/www/html/WordPress/wp-content -R
restorecon -Rv /var/www/html
service httpd start
```
1. 同じディレクトリに、次の内容`stop_server.sh`で を作成します。
```
#!/bin/bash
service httpd stop
```
1. zip バンドルを作成します。
Linux:
```
$ cd /tmp/WordPress
$ zip -r wordpress.zip .
```
Windows: WordPress」ディレクトリに移動し、すべてのファイルを選択して zip ファイルを作成します。必ず wordpress.zip という名前を付けます。
1. アプリケーションバンドルを S3 バケットにアップロードします。
スタックのデプロイを続行するには、バンドルを設定する必要があります。
作成した S3 バケットインスタンスに自動的にアクセスできます。踏み台または S3 コンソールからアクセスし、WordPress バンドルをdrag-and-dropでアップロードするか、zip ファイルを参照して選択できます。
シェルウィンドウで次のコマンドを使用することもできます。zip ファイルへの正しいパスがあることを確認してください。
```
aws s3 cp wordpress.zip s3://BUCKET_NAME/
```
1. WordPress アプリケーションバンドルをデプロイします。
開始する前に次のデータを収集すると、デプロイがより速くなります。
必須データ：
+ `VPC-ID`: この値により、S3 バケットの場所が決まります。以前に使用したものと同じ VPC ID を使用します。
+ `CodeDeployApplicationName` および `CodeDeployApplicationName`: HA 2-Tierスタック RFC で使用した`ApplicationName`値は、CodeDeployApplicationName と CodeDeployDeploymentGroupName を設定します。この例では「WordPress」を使用していますが、別の値を使用した可能性があります。
+ `S3Location`: には`S3Bucket`、`BucketName`以前に作成した を使用します。`S3BundleType` と `S3Key`は、S3 ストアに配置したバンドルのものです。
1. CodeDeploy アプリケーションデプロイ CT の実行パラメータ JSON スキーマを DeployCDAppParams.json.
```
aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.json
```
1. スキーマを次のように変更し、 として保存します。コンテンツを削除して置き換えることができます。
```
{
"Description": "DeployWPCDApp",
"VpcId": "VPC_ID",
"Name": "WordPressCDAppDeploy",
"TimeoutInMinutes": 60,
"Parameters": {
"CodeDeployApplicationName": "WordPress",
"CodeDeployDeploymentGroupName": "WordPress",
"CodeDeployIgnoreApplicationStopFailures": false,
"CodeDeployRevision": {
"RevisionType": "S3",
"S3Location": {
"S3Bucket": "BUCKET_NAME",
"S3BundleType": "zip",
"S3Key": "wordpress.zip" }
}
}
}
```
1. CreateRfc の JSON テンプレートを、現在のフォルダの DeployCDAppRfc.json:
```
aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.json
```
1. DeployCDAppRfc.json ファイルを変更して保存し、コンテンツを削除して置き換えることができます。`RequestedStartTime` と `RequestedEndTime`はオプションになりました。これらを除外すると、承認されるとすぐに実行される ASAP RFC が作成されます (通常は自動的に実行されます）。スケジュールされた RFC を送信するには、これらの値を追加します。
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-2edc3sd1sqmrb",
"Title": "CD-Deploy-For-WP-RFC"
}
```
1. DeployCDAppRfc ファイルと DeployCDAppParams 実行パラメータファイルを指定して、RFC を作成します。
```
aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json --execution-parameters file://DeployCDAppParams.json
```
レスポンスで新しい RFC の RfcId を受け取ります。後続のステップの ID を保存します。
1. RFC を送信します。
```
aws amscm submit-rfc --rfc-id RFC_ID
```
RFC が成功した場合、出力は受信されません。
1. RFC ステータスを確認するには、 を実行します。
```
aws amscm get-rfc --rfc-id RFC_ID
```
# アプリケーションのデプロイを検証する
WordPress デプロイパス: /WordPress を使用して、以前に作成したロードバランサーのエンドポイント (ELB CName) WordPress に移動します。例：
```
http://stack-ID-FOR-ELB.us-east-1.elb.amazonaws.com/WordPress
```
# アプリケーションのデプロイをティアダウンする
チュートリアルが終了したら、リソースに対して課金されないようにデプロイを破棄します。
以下は、一般的なスタック削除オペレーションです。HA 2-Tierスタックの場合は 1 回、S3 バケットスタックの場合は 1 回、2 回送信します。最後のフォローアップとして、S3 バケットのすべてのスナップショット (サービスリクエストに S3 バケットスタック ID を含める) を削除するサービスリクエストを送信します。これらは 10 日後に自動的に削除されますが、早期に削除すると多少のコストを節約できます。
このチュートリアルでは、AMS コンソールを使用して S3 スタックを削除する例を示します。この手順は、AMS コンソールを使用してスタックを削除する場合に適用されます。
**注記**
S3 バケットを削除する場合は、まずオブジェクトを空にする必要があります。
必須データ：
+ `StackId`: 使用するスタック。これは、左側のナビゲーションのリンクから入手できる AMS コンソール**スタック**ページから確認できます。AMS SKMS API/CLI を使用して、AMS SKMS API リファレンスについては、AWS Artifact Console の**レポート**タブを参照してください。 オペレーション (`list-stack-summaries` CLI の )。
+ このウォークスルーの変更タイプ ID は で`ct-0q0bic0ywqk6c`、バージョンは「1.0」です。最新バージョンを確認するには、次のコマンドを実行します。
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-0q0bic0ywqk6c
```
*インライン作成*：
+ インラインで指定された実行パラメータ (インラインで実行パラメータを指定する場合は引用符をエスケープ) を使用して、create RFC コマンドを発行します。E
```
aws amscm create-rfc --change-type-id "ct-0q0bic0ywqk6c" --change-type-version "1.0" --title "Delete My Stack" --execution-parameters "{\"StackId\":\"STACK_ID\"}"
```
+ RFC の作成オペレーションで返された RFC ID を使用して RFC を送信します。送信されるまで、RFC は `Editing`状態のままで、 に対して動作しません。
```
aws amscm submit-rfc --rfc-id RFC_ID
```
+ RFC ステータスをモニタリングし、実行出力を表示します。
```
aws amscm get-rfc --rfc-id RFC_ID
```
*テンプレートの作成*：
1. RFC テンプレートを現在のフォルダ内のファイルに出力します。例名は DeleteStackRfc.json:
```
aws amscm create-rfc --generate-cli-skeleton > DeleteStackRfc.json
```
1. DeleteStackRfc.json ファイルを変更して保存します。スタックの削除には実行パラメータが 1 つしかないため、実行パラメータは DeleteStackRfc.json ファイル自体に含めることができます (実行パラメータを使用して別の JSON ファイルを作成する必要はありません）。
ExecutionParameters JSON 拡張機能の内部引用符は、バックスラッシュ (\$1) でエスケープする必要があります。開始時刻と終了時刻のない例：
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-0q0bic0ywqk6c",
"Title": "Delete-My-Stack-RFC"
"ExecutionParameters": "{
\"StackId\":\"STACK_ID\"}"
}
```
1. RFC を作成します。
```
aws amscm create-rfc --cli-input-json file://DeleteStackRfc.json
```
レスポンスで新しい RFC の RfcId を受け取ります。例:
```
{
"RfcId": "daaa1867-ffc5-1473-192a-842f6b326102"
}
```
後続のステップの ID を保存します。
1. RFC を送信します。
```
aws amscm submit-rfc --rfc-id RFC_ID
```
RFC が成功した場合、コマンドラインに確認は送信されません。
1. リクエストのステータスをモニタリングし、実行出力を表示するには：
```
aws amscm get-rfc --rfc-id RFC_ID --query "Rfc.{Status:Status.Name,Exec:ExecutionOutput}" --output table
```