そもそものきっかけ
皆さん、AWS Bedrock には触っていますか?
Bedrock では、用意されている CLI が bedrock と bedrock-runtime の2つに分かれています。
後者 "-runtime" で用意されていたコマンドが、 invoke-model 1つのみだった (2023年12月時点) のに気づいたことが、この記事を書くきっかけです。
AWS CLI と boto3 でできることが違う!(当たり前!)
aws cli でのコマンドでできることは上記の通りですが、boto3 の API と比べてみると、 bedrock-runtime クライアントでは、AWS CLI 相当の invoke_model のメソッドと、
- can_paginate
- close
- get_paginator
- get_waiter
といった、どのクライアントにも共通で用意されているメソッド以外にも、以下のメソッドが用意されていました。この boto3 メソッド (invoke_model_with_response_stream) に相当する AWS CLI は用意されていません。
ただし、これは名称からわかる通り、Bedrock からの応答を、Stream として 受け取るためのメソッドとなっており、基本的に逐次実行が想定されている AWS CLI では扱いづらい メソッドのため、CLI には用意されなかった操作なのだろう、ということが得心できました。
これまで私は、AWS CLI と boto3 でできることは、おおむねイコールなのではないか、という思い込みがありました。しかし、上記のような AWS CLI と boto3 でできることの差分が他にもあるのではないか? と考えたのが、以下で確認してみた内容になります。
Python スクリプトで確認してもらう
とは言え、(当たり前ですが)リファレンスなどから、差分をひとつひとつ確認するのは効率的ではありません。
そこで、AI に、python のクライアントのメソッドから、CLI の有無を確認してもらう スクリプトを書いてもらいました。
以下がその内容です。
念の為の注意事項
なお、下記スクリプトでは、内部から AWS CLI を呼び出します。
APIをたたいて、不必要なリソースを作成することのないよう、有効なアクセスキーなどが使えない状態(APIが実際に実行されることのない状態)で実行しないと、意図しない料金の請求などにつながりかねないので、ご注意ください。
(基本的には、オプションなしの実行では、基本的にコマンドは失敗することがほとんどのため、何かのリソースの作成、料金の請求につながる可能性は低いとは思いますが…)
import sys
import boto3
import subprocess
def generate_cli_commands(service_name, available_methods):
# AWS CLIスタイルのコマンドを生成
return [f"aws {service_name} {method.replace('_', '-')}" for method in available_methods]
def check_cli_command_exists(cli_command):
# AWS CLIコマンドが存在するか確認
try:
result = subprocess.run(cli_command, shell=True, check=False, stdout=subprocess.PIPE, stderr=subprocess.PIPE, encoding='utf-8')
if result.returncode == 252:
return result.returncode == 0 or "aws: error: the following arguments are required:" in result.stderr
elif result.returncode == 254:
return True
else:
return result.returncode == 0 # 終了エラーコードが252以外の場合はTrueを返す
except Exception as e:
print(f"Error executing command: {e}")
return False
def main():
# 引数からサービス名を取得
if len(sys.argv) != 2:
print("Usage: python script_name.py <service_name>")
sys.exit(1)
service_name = sys.argv[1]
# 引数で指定したリージョン
region_name = 'ap-northeast-1'
# Boto3クライアントの作成
try:
client = boto3.client(service_name, region_name=region_name)
except Exception as e:
print(f"Error creating boto3 client: {e}")
sys.exit(1)
# クライアントのメソッド一覧を取得
available_methods = [method_name for method_name in dir(client) if callable(getattr(client, method_name)) and not method_name.startswith('_')]
if not available_methods:
print(f"No methods found for {service_name} client.")
sys.exit(1)
# AWS CLIスタイルのコマンドを生成
cli_commands = generate_cli_commands(service_name, available_methods)
# 生成したコマンドがAWS CLIに存在するか確認
for cli_command in cli_commands:
if check_cli_command_exists(cli_command):
print(f"AWS CLI command exists: {cli_command}")
else:
print(f"AWS CLI command does not exist: {cli_command}")
if __name__ == "__main__":
main()
さて、こちらのスクリプトを実行してみます。
$ python check_boto3_method.py bedrock-runtime
AWS CLI command does not exist: aws bedrock-runtime can-paginate
AWS CLI command does not exist: aws bedrock-runtime close
AWS CLI command does not exist: aws bedrock-runtime generate-presigned-url
AWS CLI command does not exist: aws bedrock-runtime get-paginator
AWS CLI command does not exist: aws bedrock-runtime get-waiter
AWS CLI command exists: aws bedrock-runtime invoke-model
AWS CLI command does not exist: aws bedrock-runtime invoke-model-with-response-stream
最終行にて、boto3 の bedrock-runtime クライアントにはあるメソッドなのに、"invoke-model-with-response-stream" コマンドはないよ、ということで、期待するチェックができているようですね。
EC2 の場合
さて、前述のスクリプトを使って、
python check_boto3_method.py ec2
と、ec2 における AWS CLI と boto3 でできることの差分を確認してみます。
以下がその結果(boto3にのみ用意されているメソッド)になります(長いので全体は割愛)。
前者の "import_instance" のリファレンスには、まさに以下の記載もあります。
This API action is not supported by the Command Line Interface (CLI). For information about using the Amazon EC2 CLI,
これらの API にはなぜ CLI が用意されていないのでしょうか? "import_instance" のリファレンスには、以下の記載もありました。
この API アクションは、単一ボリューム VM のみをサポートします。 マルチボリューム VM をインポートするには、代わりに ImportImage を使用します。
こちらの記事を見ると、同じ CLI は用意されていないものの、マルチボリュームをサボートする、 aws ec2 import-image で同等の操作ができる(ので用意されていない)ということが言えそうですね。
RDS の場合
では、RDS の場合はどうでしょうか。
python check_boto3_method.py rds
実行の結果、RDS の場合に boto3にのみ用意されているメソッド は以下の1つでした。
オプショングループが Modify できないのは少々意外ですね。
こちらの リファレンス に、以下の記載がありました。
オプション設定を変更するには、変更するオプショングループおよびオプションを指定して、AWS CLI の add-option-to-option-group コマンドを使用します。
上記記載のように、aws rds add-option-to-option-group や、aws rds remove-option-from-option-group を使う、というのが、CLI から オプショングループを Modify する際のお作法、ということになるでしょうか。(こちらについては、複雑になりがちな気がするので、そもそも CLI から やりたくない、という向きが強そうな操作内容ではありますが。)
まとめ
本記事では、スクリプトを使って、AWS CLI と boto3 でできることの差分を確認してみました。
今回確認した範囲では、興味深い?結果を見つけることはあまりできませんでしたが、kinesis の subscribe_to_shard など、同様に AWS CLI が用意されていない boto3 メソッドは、他にもまだ埋もれていそうです。
こういった(ある意味、何の役にも立たない)調査も通じて、AWS に関する知見を深めていけるといいな、と思っています。
ちなみにですが、上記の Python スクリプトの生成を手伝ってもらった AI は、ChatGPT でした。(そこは Bedrock だろ!と言われそうなので、Amazon Bedrock の Text Playground にも、触っていきたいと思います!)
- AWS は、米国その他の諸国における Amazon.com, Inc. またはその関連会社の商標です。
- その他、本資料に記述してある会社名、製品名は、各社の登録商品または商標です。