こんにちは、ちはらです。
AWS歴1年（IT歴1年半）の私が、配属されて間もない頃に上司から言われて驚いたことについてまとめようと思います。
私が驚いたこととは、タイトルの通り GUIとCLIで同じことをしているはずなのに、違う挙動をすることがある ということです。
どのような挙動の違いがあるのか、実際に私が遭遇したのは以下のケースです。
EC2インスタンスを削除せずにリストアを行うと
プライベートIPアドレスを所持するEC2インスタンスを、インスタンスが存在する状態でAWS Backupからリストアを実行します。
そうすると、GUIではIPアドレスが変更された状態でEC2インスタンスがリストアされますが、
CLIではエラーが表示され、リストアが失敗します。
今回は、IPアドレスが 10.0.1.167 のEC2インスタンスをリストアしていきます。
念のため、リストアで使用するメタデータに保持されているIPアドレスも確認します。
aws backup get-recovery-point-restore-metadata --backup-vault-name <backup-vault-name> --recovery-point-arn <arn>
メタデータも同じIPアドレスを持つことが確認できたので、このAWS Backupの復旧ポイントを指定してリストアをします。
（バックアップの手順に関する詳細は割愛します。）
GUI
「保護されたリソース」の画面にある「復旧ポイントID」を選択し、［復元］を実行します。そうすると、復元ジョブが実行され、 「ステータス」が「完了」 になります。
実際にリストアされたインスタンスのIPアドレスを確認してみます。
メタデータに保持されていたIPアドレスは 10.0.1.167 でしたが、リストアされたインスタンスのIPアドレスは 10.0.1.90 になっていることが分かります。
CLI
以下のコマンドを実施して、GUIと同じ復旧ポイントからリストアを実行します。
aws backup start-restore-job --region ap-northeast-1 --recovery-point-arn arn:aws:ec2:ap-northeast-1::image/ami-00bf58a7db8d7008f --iam-role-arn "<arn>" --metadata file://metadata_template.json
CLIでコマンドを実行すると復元ジョブIDが出力されるので、
GUIで該当の復元ジョブを確認すると 「ステータス」が「失敗」 になっています。
エラーメッセージを確認すると Address 10.0.1.167 is in use. と表示されており、IPアドレスが既に使用されているためリストアに失敗したことが分かります。
GUIでは成功するが、CLIでは失敗する
このように、同じ復旧ポイントIDからリストアを行っても、GUIではリストアが成功してCLIではリストアが失敗しました。
どのような違いがあるのかCloudTrailのイベント「RunInstances」を確認してみます。
GUI
{
～～～
"eventTime": "2024-08-31T10:58:22Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "RunInstances",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "backup.amazonaws.com",
"userAgent": "backup.amazonaws.com",
"requestParameters": {
"instancesSet": {
"items": [
{
"imageId": "ami-00bf58a7db8d7008f",
"minCount": 1,
"maxCount": 1,
"keyName": "XXXXX"
}
]
},
"groupSet": {
"items": [
{
"groupId": "sg-XXXXXXXXXX"
}
]
},
"instanceType": "t2.micro",
"blockDeviceMapping": {},
"tenancy": "default",
"monitoring": {
"enabled": false
},
"subnetId": "subnet-XXXXXXXXXX",
"disableApiTermination": false,
"disableApiStop": false,
"instanceInitiatedShutdownBehavior": "stop",
"clientToken": "B7A0EB7A-789E-C665-17C5-0FD6017CBCCE",
"ebsOptimized": false,
～～～
}
CLI
{
～～～
"eventTime": "2024-08-31T10:56:20Z",
"eventSource": "ec2.amazonaws.com",
"eventName": "RunInstances",
"awsRegion": "ap-northeast-1",
"sourceIPAddress": "backup.amazonaws.com",
"userAgent": "backup.amazonaws.com",
"errorCode": "Client.InvalidIPAddress.InUse",
"errorMessage": "Address 10.0.1.167 is in use.",
"requestParameters": {
"instancesSet": {
"items": [
{
"imageId": "ami-00bf58a7db8d7008f",
"minCount": 1,
"maxCount": 1,
"keyName": "XXXXX"
}
]
},
"instanceType": "t2.micro",
"blockDeviceMapping": {},
"availabilityZone": "ap-northeast-1a",
"tenancy": "default",
"monitoring": {
"enabled": false
},
"disableApiTermination": false,
"disableApiStop": false,
"instanceInitiatedShutdownBehavior": "stop",
"clientToken": "FFAED6A4-66B8-68C0-E24B-058594A4AF89",
"networkInterfaceSet": {
"items": [
{
"deviceIndex": 0,
"subnetId": "subnet-XXXXXXXXXX",
"deleteOnTermination": true,
"groupSet": {
"items": [
{
"groupId": "sg-XXXXXXXXXX"
}
]
},
"privateIpAddressesSet": {
"items": [
{
"privateIpAddress": "10.0.1.167",
"primary": true
}
]
},
"ipv6AddressCount": 0,
"interfaceType": "interface"
}
]
},
"ebsOptimized": false,
～～～
}
GUIではrequestParametersの中にprivateIpAddressesSetはなく、subnetIdのみを記述しているのでIPアドレスが変更された状態でリストアされたようです。
一方でCLIは、requestParametersの中にprivateIpAddressesSetの記述があるので（メタデータで記述しているので）「Address 10.0.1.167 is in use」というエラーが表示されてリストアに失敗しました。
ユーザとしては同じメタデータを使用してリストアを行っているのでパラメータも同じであろうと思ってしまいますが、
実はGUIからリストアをする時とCLIからリストアをするときでは違いがあったようです。
おわりに
自分としては同じことをしていると思っていても裏では異なった動きをしている、というのは少し変な感じがしますが、こういうこともあるということを念頭に今後の業務に取り組んでいきたいと思います。
今回、ANGEL Dojoのカレンダー企画に参加をして初めてブログを書きました。
今まではブログを書くのはハードルが高いなと思っていましたが、実際に書いてみると自分の知識の整理にもなって楽しいですね。
今後も継続的に発信をして、知識の整理とブログの精度向上を図っていきたいと思います。