トップ > AWS MCP Serverで2アカウント同時操作をやってみた

AWS MCP Serverで2アカウント同時操作をやってみた

記事タイトルとURLをコピーする

はじめに

今月誕生日の人、おめでとうございます🎉 エデュケーショナルサービス課の森純子です。

AWS MCP Server に接続するクライアントプロキシ「mcp-proxy-for-aws」を使うと、AIエージェントから直接AWSリソースを操作できます。 でも、「アカウントをまたいで操作できたらもっと便利なのに…」と思っていた方も多いのではないでしょうか。

そんな方々に朗報です！ 2026年6月5日のAWSアップデートで、クロスアカウント・クロスロールアクセスに対応しました🎉

The AWS MCP Server now supports cross-account and cross-role access（2026年6月5日）

aws.amazon.com

これにより、1つのセッション内で複数アカウントをセッション再起動なしにシームレスに操作できるようになりました。

マルチアカウント環境を運用していると、「アカウントAのログを確認して、アカウントBのLambdaの状態も見て」という操作をシームレスに行えるのは大きなメリットですよね。ということで、やってみました。

※ 本記事では Amazon CloudWatch Logs を「CloudWatch Logs」、AWS Lambda を「Lambda」と表記します。

全体イメージ

全体イメージ

手順

ステップ1: 子アカウントにIAMロールを作成する

子アカウントA・Bそれぞれに、管理アカウントからAssumeRoleできるIAMロールを作成します。

信頼ポリシー（子アカウント側）:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::＜管理アカウントID＞:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

ポイント:

  • 今回は検証目的のため、MFA条件なしのロールを作成しています
  • 本番運用では、MFA条件付きまたはIAM Identity Center経由でのAssumeRoleを推奨します
  • 許可ポリシーは ReadOnlyAccess を付与しました（最小権限の原則に基づき、必要なサービスのみに絞ることを推奨します）

ステップ2: AWS CLIプロファイルを設定する

~/.aws/config に各アカウント用のプロファイルを追加します。

[profile management]
role_arn = arn:aws:iam::＜管理アカウントID＞:role/general-role
source_profile = management
region = ap-northeast-1

[profile account-a]
role_arn = arn:aws:iam::＜子アカウントAのID＞:role/general-role
source_profile = management
region = ap-northeast-1

[profile account-b]
role_arn = arn:aws:iam::＜子アカウントBのID＞:role/general-role
source_profile = management
region = ap-northeast-1

~/.aws/credentials には管理アカウントのIAMユーザーのアクセスキーを設定します。

[management]
aws_access_key_id = AKIA...
aws_secret_access_key = ****

各プロファイルは、管理アカウントの認証情報（source_profile = management）を使って、各子アカウントのIAMロールにAssumeRoleする構成です。子アカウント側にIAMユーザーのアクセスキーは使用しません。AssumeRoleに必要なのは、子アカウント側のIAMロールのみです。

疎通確認:

$ AWS_PROFILE=account-a aws sts get-caller-identity
{
    "Account": "＜子アカウントAのID＞",
    "Arn": "arn:aws:sts::＜子アカウントAのID＞:assumed-role/general-role/botocore-session-..."
}

$ AWS_PROFILE=account-b aws sts get-caller-identity
{
    "Account": "＜子アカウントBのID＞",
    "Arn": "arn:aws:sts::＜子アカウントBのID＞:assumed-role/general-role/botocore-session-..."
}

ステップ3: MCP Server設定ファイルを作成する

~/.kiro/settings/mcp.json を以下の内容で作成します。

{
  "mcpServers": {
    "aws": {
      "command": "/home/morisumi/.local/bin/uvx",
      "args": [
        "mcp-proxy-for-aws@latest",
        "https://mcp.us-east-1.amazonaws.com",
        "--profile", "account-a", "account-b",
        "--region", "us-east-1"
      ]
    }
  }
}

設定のポイント:

  • command: uvxのフルパスを指定します。Kiro CLI起動時にPATHが通らない場合があるためです
  • endpoint: https://mcp.us-east-1.amazonaws.com（us-east-1 または eu-central-1 のみ利用可能）
  • --profile: 操作を許可するプロファイルを列挙します。ここに登録されていないプロファイルへのアクセスはブロックされます
  • --region: エンドポイントのリージョンを指定します。操作対象リソースのリージョンはプロファイルのregion設定（ap-northeast-1）に従う ため、東京リージョンのリソース操作に問題はありません

ステップ4: 検証用リソースを作成する

子アカウントA（account-a）: CloudWatch Logsにテストログを作成

$ export AWS_PROFILE=account-a

$ aws logs create-log-group --log-group-name /mcp-test/cross-account --region ap-northeast-1

$ aws logs create-log-stream --log-group-name /mcp-test/cross-account --log-stream-name test-stream --region ap-northeast-1

$ aws logs put-log-events --log-group-name /mcp-test/cross-account --log-stream-name test-stream --region ap-northeast-1 --log-events '[{"timestamp":'$(date +%s000)',"message":"Hello from Elizabeth account - cross account test"}]'

子アカウントB（account-b）: Lambda関数を作成

マネジメントコンソールからLambda関数を作成します。

  • 関数名: mcp-test-cross-account
  • ランタイム: Python 3.14
  • アーキテクチャ: arm64
  • コード: デフォルトのまま（今回は関数情報の取得確認のみ）

ステップ5: Kiro CLIでクロスアカウント操作を実行する

Kiro CLIを起動（またはmcp.json作成後に再起動）し、チャット内でAWS MCP Serverを使ったクロスアカウント操作を試します。

検証1: account-aプロファイルでCloudWatch Logsを取得

> account-aプロファイルを使って、ap-northeast-1リージョンの
  CloudWatch Logsロググループ /mcp-test/cross-account のログイベントを取得してください

結果:

{
    "events": [
        {
            "timestamp": 1780994393000,
            "message": "Hello from account-a - cross account test",
            "ingestionTime": 1780994395938
        }
    ]
}

子アカウントAのCloudWatch Logsを正常に取得できました。

検証2: account-bプロファイルでLambda関数情報を取得

> account-bプロファイルを使って、ap-northeast-1リージョンの
  Lambda関数 mcp-test-cross-account の情報を取得してください

結果:

{
    "Configuration": {
        "FunctionName": "mcp-test-cross-account",
        "FunctionArn": "arn:aws:lambda:ap-northeast-1:＜子アカウントBのID＞:function:mcp-test-cross-account",
        "Runtime": "python3.14",
        "State": "Active",
        "Architectures": ["arm64"]
    }
}

同じセッション内で、再起動なしに別アカウントのLambda関数情報を取得できました。

技術的注意点・落とし穴

  1. Role Chainingの1時間制限: source_profileからAssumeRoleする構成ではセッション最大期間が1時間です。長時間の検証セッションではトークン期限切れが発生します。対策として、検証は1時間以内に完了させるか、aws login（IAM Identity Center、15分自動更新）を使用してください。

  2. MCP Serverのエンドポイントリージョン制限: us-east-1 または eu-central-1 のみです。東京リージョンにはエンドポイントがありません。ただし操作対象リソースのリージョンはプロファイルのregion設定に従うため、ap-northeast-1のリソース操作に問題はありません。

  3. uvxのパス: Kiro CLI起動時にPATHが通らず MCP Server接続に失敗するケースがあります。mcp.jsonのcommandにはuvxのフルパス（例: /home/user/.local/bin/uvx）を指定してください。

  4. 無効なプロファイル指定時の挙動: --profileに登録されていないプロファイルをエージェントが指定した場合、プロキシがエラーを返し、許可されたプロファイルのリストを提示します。意図しないアカウントへのアクセスは発生しません。

  5. MFAとの併用不可: mcp-proxy-for-awsは対話的にMFAコードを入力できません。MFA条件付きAssumeRoleの構成では動作しないため、MFA条件を外したロールを用意するか、IAM Identity Centerを使用してください。

コスト（2026年6月時点・ap-northeast-1）

リソース コスト
CloudWatch Logs 無料利用枠内（5GB/月の取り込み無料）
Lambda 関数作成のみ・実行しないため0円
IAMロール 無料
AWS MCP Server 無料（操作対象のAWSリソース利用料のみ）

AWS MCP Server自体は追加料金なしです。利用者が支払うのは操作対象のAWSリソース利用料のみです。

"The AWS MCP Server is available at no additional charge; you pay only for the AWS resources your agents use."

aws.amazon.com

まとめ

  • AWS MCP Server（mcp-proxy-for-aws）の --profile オプションにより、1つのKiro CLIセッション内で複数アカウントのリソースをセッション再起動なしに切り替えて操作できることを確認しました
  • 管理アカウントから子アカウントへのAssumeRole構成を利用するため、既存のマルチアカウント運用基盤をそのまま活用できます
  • --profileに登録したプロファイルのみアクセス可能なため、意図しないアカウントへの操作を防止するガードレールとしても機能します

マルチアカウント環境での運用負荷を少しでも軽くする一助になれば幸いです。

クラウド活用の「ちょっとした不安」や
「もっと良くしたい」に応えます
サーバーワークスは、AWSの構築から運用まで
幅広く支援しています
資料ダウンロード相談する

swx-sumiko-mori