はじめに
お疲れ様です。矢儀 @yuki_ink です。
AWSのMCPサーバを使って、自然言語でAWSを操作してますか？
AWSからはたくさんのMCPサーバが公開されています。
Claude DesktopやClaude Code、Cursorといったツール（MCPクライアント）を適切に設定して、これらのMCPサーバを利用すれば、自然言語で簡単にAWS環境を操作することができます。
「EC2を立てて」とお願いすればEC2が立ち上がる。そんな時代がすでに到来しています。
そんなMCPサーバからAWSの操作を行うときに、どんな認証情報でAWSにアクセスするかは重要な観点です。
主な選択肢は以下の4つです。
AWS CLIを操作するときに設定するものと同じです。
① アクセスキーを通じてIAMユーザの権限を利用
② IAMロールの権限を利用
③ IAM Identity CenterのユーザでSSO（aws configure sso + aws sso login）
④ ブラウザでマネジメントコンソールに接続しているIDの権限を利用（aws login）
本記事では、④の aws login に着目します。
aws login は、AWSマネジメントコンソールで使用しているのと同じサインイン方法を利用でき、セキュリティ面・運用面で優れた選択肢です。
個人的には、「MFA」や「スイッチロール」といった、従来から言われているベストプラクティスとの親和性が高い点が、非常にいいなと思っています。
AWSのMCPサーバで aws login の認証情報を利用しようとしたところ、つまづいたことがあったので、本記事に対応を残しておきます。
本記事はMCPサーバを uvx で動かす環境を想定しています。
DockerでMCPサーバを動かすケースで直接役に立つ内容ではないので、その点はご了承ください🙇♂️
本記事は、以前投稿した記事『Amazon WorkSpaces Applications(旧AppStream2.0)でKiro IDEを社内にセキュアに配信する』の中でチラッと紹介した内容を抜粋・深掘りしたものです。
AWSのMCPサーバをuvxで動かす環境で "aws login" の認証情報を使うために、mcp.json を工夫する
結論です。
MCPクライアント側の設定ファイル mcp.json にて、各MCPサーバの設定箇所の args に "--with", "botocore[crt]", を追記します。
// 例：cloudwatch-applicationsignals-mcp-serverの場合
{
"mcpServers": {
"applicationsignals": {
"command": "uvx",
"args": [
+ "--with",
+ "botocore[crt]",
"awslabs.cloudwatch-applicationsignals-mcp-server@latest"
],
"env": {
"AWS_PROFILE": "[The AWS Profile Name to use for AWS access]",
"AWS_REGION": "[AWS Region]",
"FASTMCP_LOG_LEVEL": "ERROR"
},
"disabled": false,
"autoApprove": []
}
}
}
上記で例に出した「cloudwatch-applicationsignals-mcp-server」のリポジトリはこちら。
なぜこの対応が必要なのか
順に説明します。
uvx で起動する仮想環境には pyproject.toml に記述されているパッケージしかインストールされない
uvx は、Rust製の高速Pythonパッケージマネージャ uv に含まれるコマンドで、Pythonツールを仮想環境ごとその都度生成して実行するものです（従来の pipx に相当）。
AWSが提供するMCPサーバでは、mcp.json で以下のような記述をして、uvx を使ってMCPサーバを起動するように案内されています。
{
"command": "uvx",
"args": ["awslabs.XXXXX-mcp-server@latest"]
}
uvx でMCPサーバを実行すると、そのMCPサーバのリポジトリに含まれる pyproject.toml に記載された依存パッケージのみがインストールされた仮想環境が自動的に作成され、その中でMCPサーバが起動します。
この仮想環境はコマンド実行のたびに再現され、ホスト環境を汚さずに済むのですが、それはつまり、pyproject.toml に記載されていないパッケージは仮想環境に含まれないということにもなります。
aws login の認証情報を使うためには botocore[crt]（AWS Common Runtime）が必要
aws login の認証情報でboto3（AWS SDK）を利用するには、実行環境に botocore[crt]（AWS Common Runtime） をインストールしておく必要があります。
インストールしていない場合には以下のようなエラーが発生します。
botocore.exceptions.MissingDependencyException: Missing Dependency: Using the login credential provider requires an additional dependency. You will need to pip install "botocore[crt]" before proceeding.
内部的にboto3を使ってAWSにアクセスするMCPサーバの場合、MCPサーバの実行環境にbotocore[crt]を入れておかないといけないということになります。
各MCPサーバの pyproject.toml には、依存関係に botocore[crt] の記述がない
これが一番の問題なのですが、記事執筆時点では、AWSが提供している各MCPサーバの pyproject.toml には、依存関係に botocore[crt] の記述がありません。
そこで、--with オプションを使います。
--with は、uvx でツールを実行する際に追加パッケージを一時的にインストールするためのオプションです。
これを使うことで、MCPサーバ本体の pyproject.toml を変更せずに、実行環境に botocore[crt] をインストールできます😇
今後、MCPサーバ側で pyproject.toml の改善がされれば、上記の対応は不要になります！
（余談①）プロファイルについて
ここから aws login に関連する情報を備忘的に残しておきます！
MCPクライアント側の設定ファイル mcp.json にて、各MCPサーバの設定箇所の env の AWS_PROFILE には好きなプロファイルを設定できます。
default でもいいですし、名前付きプロファイルでも構いません。
ちなみに aws login する際にプロファイルを指定するには、以下のように --profile オプションを使います（--profile オプションなしだと、default のプロファイルが更新される）
aws login --profile <プロファイル名>
MCPサーバでそのプロファイルを使いたい場合は、aws login の後に、env の AWS_PROFILE に同じプロファイル名を設定すればOKです。
"env": {
"AWS_PROFILE": "<プロファイル名>"
}
以下の記事では、aws login を実行した後に ~/.aws/config などの各ファイルがどのように変更されるのか、詳しく解説されています。
こちらを読んでいただくと、aws login 時のプロファイル関連の挙動も理解しやすくなると思います。
（余談②）aws login を使うための前提条件
そもそも aws login を利用するには、コマンドを実行する環境で以下の条件を満たしておく必要があります。
AWS CLI のバージョン
aws login コマンドは AWS CLI バージョン 2.32.0 以上 で利用可能です。
古いバージョンではコマンド自体が存在しないため、必要に応じて、事前にAWS CLIのアップデートをしておく必要があります。
IAM側の権限設定
aws login を使う場合は、対象のIAMユーザー・ロール側に、所定の権限を付けておく必要があります。
AWSマネージドポリシー SignInLocalDevelopmentAccess をアタッチしておくと確実です。
記事執筆時点での、マネージドポリシーの中身はこちら。
{
"Version" : "2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"signin:AuthorizeOAuth2Access",
"signin:CreateOAuth2Token"
],
"Resource" : "arn:aws:signin:*:*:oauth2/public-client/*"
}
]
}
参考にさせていただいたブログ