AWS MCPサーバーをReadOnlyで安全に連携し、コストレポートに「誰が作ったか」を可視化してみた

はじめに

こんにちは。DXソリューション営業本部の岡田です。
前回の記事では、Kiro PowersのAWS Cost Optimization Powerを使って週次コストレポートを自動生成し、コスト急増の原因を特定する方法をご紹介しました。

Kiro Powers AWS Cost Optimization Powerでコスト急増の原因を特定してみた | QES ブログ
KiroのAWS Cost Optimization Powerを使って週次コストレポートを自動生成し、コスト急増の原因を特定する方法を紹介
 

朝会でこのレポートを共有したところ、こんなフィードバックをもらいました。

確かに、Cost Explorer APIで取得できるのはインスタンスIDとコスト金額だけ。「このリソース消していいの？」を判断するには、誰が・いつ・何のために作ったかが必要です。

そこで今回は、AIエージェントにAWS環境を探索させてこれらの情報を取得するため、「マネージド版AWS MCPサーバー」を追加することにしました。
ただし、AIエージェントにAWSの操作権限を渡す際、誤ったリソースの削除や変更といったトラブルを防ぐためには「ReadOnly（読み取り専用）」での運用が鉄則です。
本記事では、最少権限のReadOnly構成で、安全にリソース情報を取得する手順を解説します。

マネージド版AWS MCPサーバーとは

AWS MCPサーバーには「OSS版」と「マネージド版」の2種類があります。

前回使ったAWS Cost Optimization PowerはOSS版で、コスト分析に特化しています。今回追加するマネージド版は、EC2やCloudTrailなど15,000以上のAWS APIに自然言語でアクセスできるため、Nameタグや作成者の取得に最適です。

AWS公式ブログ

ガードレール設計：ReadOnly + 機密情報Deny

AIエージェントにAWSの操作権限を渡すことにはリスクがあります。ReadOnlyであっても、機密情報の読み取りには注意が必要です。

今回は以下の3層構造でガードレールを設計しました。

IAMポリシー構成

MCP専用のIAMユーザーに以下の2つのポリシーをアタッチします。

1. ReadOnlyAccess（AWSマネージドポリシー）

EC2、CloudTrail等の全サービスの読み取り権限を付与します。書き込み操作は一切できません。

2. カスタムインラインポリシー（mcp-guardrail）

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowMCPAccess",
      "Effect": "Allow",
      "Action": [
        "aws-mcp:InvokeMcp",
        "aws-mcp:CallReadOnlyTool",
        "aws-mcp:CallReadWriteTool"
      ],
      "Resource": "*"
    },
    {
      "Sid": "DenySecretsAccess",
      "Effect": "Deny",
      "Action": [
        "secretsmanager:GetSecretValue",
        "ssm:GetParameter*",
        "kms:Decrypt"
      ],
      "Resource": "*"
    }
  ]
}

ポイント：

• aws-mcp:CallReadWriteTool — 名前に反してS3の読み取り等にも必要なため許可しています。実際の書き込み防止はReadOnlyAccessポリシーで担保します。
• Secrets Manager / SSM Parameter Store — 認証情報・APIキーが格納されている可能性があるため明示的にDeny
• KMS Decrypt — 暗号化データの復号を防止

セットアップ手順

Step 1: MCP専用IAMユーザーの作成

1. IAMコンソール → ユーザー → ユーザーを作成
2. ユーザー名: mcp-readonly（任意）
3. 「AWSマネジメントコンソールへのアクセスを提供する」にチェック
4. 許可ポリシーで ReadOnlyAccess をアタッチ
5. ユーザー作成後、インラインポリシー mcp-guardrail を追加（上記JSON）

Step 2: AWS CLIプロファイルの設定

aws login を使えばアクセスキー不要で認証できます。

aws login --profile mcp-readonly

ブラウザが開くので、作成したユーザーでログインします。

※ aws login を使う場合は、IAMユーザーに iam-local-development:CreateToken の許可が必要です。詳しくは下記ブログをご覧ください。

新しく追加されたAWS CLIのaws login使ってみたらアクセスキーが不要になった！| QES ブログ
新しく追加されたAWS CLIのaws loginについて紹介
 

認証後、動作確認します。

aws sts get-caller-identity --profile mcp-readonly

{
    "UserId": "AIDAXXXXXXXXXXXXXXXXX",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/mcp-readonly"
}

Step 3: Kiroのmcp.jsonに追加

AWS公式ドキュメントを参考に、~/.kiro/settings/mcp.json の mcpServers セクションに以下を追加します。

"aws-mcp": {
  "command": "uvx",
  "timeout": 100000,
  "args": [
    "mcp-proxy-for-aws@latest",
    "https://aws-mcp.us-east-1.api.aws/mcp",
    "--metadata",
    "AWS_REGION=ap-northeast-1"
  ],
  "env": {
    "AWS_PROFILE": "mcp-readonly"
  },
  "disabled": false,
  "autoApprove": []
}

Kiroを再起動すると、aws-mcpが接続されます。

実践：「誰が作った？」を特定する

前回のコストレポートで「NEW」として検出されたインスタンスの詳細を調べてみます。

Before（前回のレポート）

After（aws-mcpで詳細を取得）

Kiroがaws-mcp経由でEC2 DescribeInstancesとCloudTrail LookupEventsを実行し、Nameタグと作成者を返してくれます。

インスタンスIDだけだった情報が、Name（用途）・作成者・作成日まで一目でわかるようになりました。「このリソース消していいの？」がレポートを見るだけで判断できます。

全インスタンスの作成者一覧

検証アカウント内の全EC2インスタンスについても一括で調べられます。

書き込み拒否の確認

ReadOnly権限が正しく機能しているか、書き込み操作を試みて拒否されることを確認します。

ReadOnlyAccessポリシーにより、書き込み操作は拒否されます。AIエージェントが誤ってリソースを作成・変更・削除するリスクがゼロになります。

同様に、機密情報へのアクセスも確認します。

機密情報Denyポリシーにより、Secrets ManagerやSSM Parameter Storeの値は読み取れません。

まとめ

今回は、コストレポートの「誰が作ったかわからない」という課題を、マネージド版AWS MCPサーバー + ReadOnly権限で解決しました。

• コストレポートで気になるリソースがあれば、aws-mcpに「誰が作った？」と聞くだけ
• ReadOnly権限なので、AIエージェントが誤ってリソースを変更するリスクはゼロ
• 機密情報Denyで、認証情報の漏洩リスクも防止

AIエージェントにAWSを触らせる際は、まずReadOnlyから始めて、習熟度に応じて権限を広げていくのがおすすめです。
ぜひみなさんもお試しください！