Feedforce Developer Blog

フィードフォース開発者ブログ

AWS MCP Servers で進めるコスト最適化入門

こんにちは、dfplus.io のインフラを担当している唐津です。

dfplus.io のインフラチームでは、昨年 4 月以降 AWS のコスト最適化に継続的に取り組んできました。
少しずつ施策を実行してきた結果、月あたりのコストをピーク時の約 60 % 程度まで削減することができています。

これまでは各種コスト分析・可視化系のサービスなどを活用しながら地道に進めてきましたが、
ここ最近の生成 AI の発展により、複雑なコスト分析・最適化方針の検討も非常にやりやすくなってきているのではないかと考えています。

そこで、今回は AWS が提供する MCP サーバを利用して、
AWS のコスト分析、およびその後のコスト最適化対応を効率化できそうか、検討してみました。

実際にこれまで取り組んできた過去のデータや対応をベースに、出力の妥当性なども含めて確認してみたいと思います。

前提

以下の 2 つの MCP サーバーを利用します。
簡単な概要を記載しますが、詳細な利用方法等はドキュメントを参照ください。

AWS Cost Explorer MCP Server

https://awslabs.github.io/mcp/servers/cost-explorer-mcp-server/

Cost Explorer API を利用し、任意のアカウントのコスト状況を分析します。
単純な値の取得だけでなく、特定のディメンションやタグキーを用いた分析や、任意の2つの期間のコスト比較、変化の要因分析などにも対応しています。
AWS Cost Explorer を用いた分析の効率化が期待されます。

なお、Cost Explorer 側の仕様で、以下二点の注意点があります。

AWS Knowledge MCP Server

https://awslabs.github.io/mcp/servers/aws-knowledge-mcp-server/

AWS ドキュメントやベストプラクティスなどのナレッジを元に回答を行ってくれる MCP サーバです。
具体的な対応を進めるにあたって、利用する AWS の機能や仕様を理解する助けになります。

類似のツールとして AWS Documetation MCP Server も存在しますが、こちらはナレッジソースが AWS ドキュメントのみという違いがあります。
環境やワークロードに応じて最適な対応は異なるため、ドキュメントに加えて AWS 公式ブログなど信頼できるソースから実際の事例なども踏まえて回答してくれることのメリットは大きいのではないでしょうか。

ただし、AWS Knowledge MCP Server は比較的最近(2025/07)に登場し、プレビュー段階のツールであることはご留意ください。
また、レートリミットも設けられているようです。
リミットに到達したら、AWS Documentation MCP Server などに切り替えるなどの対応が必要になると思います。

MCP サーバーの設定

今回は MCP ホストとして、Amazon Q Developer CLI を利用します。
以下に設定例を示しますが、利用している MCP ホストに応じて、同等の内容を設定ください。

{
  "mcpServers": {
    "awslabs.cost-explorer-mcp-server": {
      "command": "uvx",
      "args": ["awslabs.cost-explorer-mcp-server@latest"],
      "env": {
        "FASTMCP_LOG_LEVEL": "ERROR",
        "AWS_PROFILE": "<対象アカウントの AWS_PROFILE を指定>"
      },
      "disabled": false,
      "autoApprove": []
    },
    "aws-knowledge-mcp-server": {
        "command": "npx",
        "args": [
            "mcp-remote",
            "https://knowledge-mcp.global.api.aws"
        ]
    }
  }
}

Amazon Q Developer CLI で MCP を利用する場合のドキュメントはこちらです。

具体的な分析の例

では、MCPサーバーがどの程度有効な提案をしてくれるか検証してみたいと思います。

dfplus.io では、昨年 5 月頃に、Aurora I/O-Optimized を導入しました。

詳細な説明は AWS 公式ブログ などを参照いただきたく思いますが、
I/O 集約型アプリケーションにおいて、コスト面・パフォーマンス面でメリットが見込める機能です。
当時、この機能による大幅なコスト削減効果が見込める状況であり、
実際に RDS のコストに関して 60 %ほどの削減効果を出すことができました。

この実績を踏まえ、「当時と同じ状況を分析させたら、適切に提案してくれるかどうか」「具体的に導入の検討を進めるにあたり、有用な情報を提供してくれるかどうか」を確認したいと思います。

なお、前述の通り、Cost Explorer API には取得制限があり、
I/O-Optimized 導入前の実際のコストは API 経由では取得できませんでした…。
したがって、精度は少し落ちますが、今回は以下の手順で擬似的に検証します。

  • 任意の月のコストの傾向から、RDS の費用の全体傾向を確認できることを確かめる
  • Aurora I/O の費用が高かった月の費用内訳を直接共有し、妥当な分析・提案を行うか確認する

以降の出力における数値は、実際の費用ではなく、ダミーの値に置き換えています。

1. AWS Cost Explorer MCP Server による全体傾向の確認

まずは、ざっくり任意の月を指定して、全体の傾向を見てもらいましょう。
特に細かいテクニックは用いずにざっくりと聞いてみて、どこまで踏み込んだ回答が返ってくるか見てみます。

分析で利用するツールについて確認を求められた場合は、適宜アクションを許可してください。
出力が長いため、回答部分は折りたたんでいます。

▶ 2024/6 月の傾向を確認

プロンプト

awslabscost_explorer_mcp_server を活用して、2024/6 のコストを確認し、費用が多くかかっているサービス上位5件の傾向を分析してください。

出力

> 2024年6月のAWSコストを分析して、費用が多くかかっているサービス上位5件の傾向を確認します。

まず、2024年6月のコストデータを取得します:

🛠️  Using tool: get_cost_and_usage from mcp server awslabscost_explorer_mcp_server
 ⋮ 
 ● Running get_cost_and_usage with the param:
 ⋮  {
 ⋮    "name": "get_cost_and_usage",
 ⋮    "arguments": {
 ⋮      "date_range": {
 ⋮        "start_date": "2024-06-01",
 ⋮        "end_date": "2024-06-30"
 ⋮      },
 ⋮      "granularity": "MONTHLY",
 ⋮      "group_by": "SERVICE",
 ⋮      "metric": "UnblendedCost"
 ⋮    }
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> t

 ⋮ 
 ● Completed in 1.63s

> 次に、比較のために前月(2024年5月)のデータも取得して傾向を分析します:

🛠️  Using tool: get_cost_and_usage (trusted) from mcp server awslabscost_explorer_mcp_server
 ⋮ 
 ● Running get_cost_and_usage with the param:
 ⋮  {
 ⋮    "name": "get_cost_and_usage",
 ⋮    "arguments": {
 ⋮      "date_range": {
 ⋮        "end_date": "2024-05-31",
 ⋮        "start_date": "2024-05-01"
 ⋮      },
 ⋮      "group_by": "SERVICE",
 ⋮      "metric": "UnblendedCost",
 ⋮      "granularity": "MONTHLY"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 0.313s

> 履歴データの制限があるため、2024年6月のデータのみで分析を行います。

## 2024年6月のAWSコスト分析結果

### 総コスト
• **総額**: $10,000

### 費用が多くかかっているサービス上位5件

1. EC2 - Other: $2,000 (20%)
   • EC2関連のその他サービス(EBS、Elastic IP等)

2. Amazon Elastic Compute Cloud - Compute: $1,800 (18%)
   • EC2インスタンスの計算リソース

3. Amazon Relational Database Service: $1,600 (16%)
   • RDSデータベースサービス

4. Amazon Simple Storage Service: $1,200 (12%)
   • S3ストレージサービス

5. Tax: $800 (8%)
   • 税金

### 傾向分析

コンピューティングリソースが主要コスト
• EC2関連(EC2 - Other + EC2 Compute)で合計 $3,800(38%)
• インフラストラクチャの基盤となるコンピューティングリソースが最大の費用項目

データベースとストレージの重要性
• RDS($1,600)とS3($1,200)で合計 $2,800(28%)
• データ管理とストレージが全体コストの約3割を占める

その他の注目すべきサービス
• AWS Glue: $600(データ統合・ETL処理)
• CloudWatch: $400(監視・ログ管理)
• VPC: $300(ネットワーク)

この構成から、データ処理・分析基盤を中心とした本格的なAWS環境を運用していることが分かります。
コスト最適化を検討する場合は、EC2インスタンスのサイジング、RDSの利用効率、S3のストレージクラス最適化などが効果的でしょう。

全体の傾向を適切に把握してくれています。
AWS マネジメントコンソールの Cost Explorer から見た傾向と大きな差分はありませんでした。
また、比較のため、指定した月の前月(2024年5月)のデータの取得も試みてくれていることもわかりますね。(履歴期間の制限により、ここでは失敗しています。)

続いて、任意のサービス(ここでは RDS)に絞って深堀りしてもらいます。

▶ RDS の費用内訳を確認

プロンプト

上記のうち、RDS の費用の内訳を詳細に確認してください。

出力

> RDSの費用内訳を詳細に確認するため、RDSサービスに絞って詳細な分析を行います。

まず、RDSの使用タイプ別の内訳を確認します:


🛠️  Using tool: get_cost_and_usage (trusted) from mcp server awslabscost_explorer_mcp_server
 ⋮ 
 ● Running get_cost_and_usage with the param:
 ⋮  {
 ⋮    "name": "get_cost_and_usage",
 ⋮    "arguments": {
 ⋮      "date_range": {
 ⋮        "end_date": "2024-06-30",
 ⋮        "start_date": "2024-06-01"
 ⋮      },
 ⋮      "group_by": "USAGE_TYPE",
 ⋮      "metric": "UnblendedCost",
 ⋮      "granularity": "MONTHLY",
 ⋮      "filter_expression": {
 ⋮        "Dimensions": {
 ⋮          "Key": "SERVICE",
 ⋮          "Values": [
 ⋮            "Amazon Relational Database Service"
 ⋮          ],
 ⋮          "MatchOptions": [
 ⋮            "EQUALS"
 ⋮          ]
 ⋮        }
 ⋮      }
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 1.130s


> 次に、RDSのインスタンスタイプ別の内訳も確認します:


🛠️  Using tool: get_cost_and_usage (trusted) from mcp server awslabscost_explorer_mcp_server
 ⋮ 
 ● Running get_cost_and_usage with the param:
 ⋮  {
 ⋮    "name": "get_cost_and_usage",
 ⋮    "arguments": {
 ⋮      "date_range": {
 ⋮        "end_date": "2024-06-30",
 ⋮        "start_date": "2024-06-01"
 ⋮      },
 ⋮      "group_by": "INSTANCE_TYPE",
 ⋮      "metric": "UnblendedCost",
 ⋮      "granularity": "MONTHLY",
 ⋮      "filter_expression": {
 ⋮        "Dimensions": {
 ⋮          "Values": [
 ⋮            "Amazon Relational Database Service"
 ⋮          ],
 ⋮          "Key": "SERVICE",
 ⋮          "MatchOptions": [
 ⋮            "EQUALS"
 ⋮          ]
 ⋮        }
 ⋮      }
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 0.825s


> さらに、RDSのデータベースエンジン別の内訳も確認します:


🛠️  Using tool: get_cost_and_usage (trusted) from mcp server awslabscost_explorer_mcp_server
 ⋮ 
 ● Running get_cost_and_usage with the param:
 ⋮  {
 ⋮    "name": "get_cost_and_usage",
 ⋮    "arguments": {
 ⋮      "date_range": {
 ⋮        "end_date": "2024-06-30",
 ⋮        "start_date": "2024-06-01"
 ⋮      },
 ⋮      "group_by": "DATABASE_ENGINE",
 ⋮      "metric": "UnblendedCost",
 ⋮      "granularity": "MONTHLY",
 ⋮      "filter_expression": {
 ⋮        "Dimensions": {
 ⋮          "Values": [
 ⋮            "Amazon Relational Database Service"
 ⋮          ],
 ⋮          "Key": "SERVICE",
 ⋮          "MatchOptions": [
 ⋮            "EQUALS"
 ⋮          ]
 ⋮        }
 ⋮      }
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 0.652s


> ## RDS費用の詳細内訳分析

### 総RDS費用: $1,600

### 1. 使用タイプ別内訳

インスタンス費用(約81%)
• **db.r6i.large(Heavy Usage)**: $1,000 (約63%)
  • リザーブドインスタンスまたは長期利用
• **db.r5.xlarge(IO Optimized)**: $300 (約19%)
  • IO最適化インスタンス

ストレージ・バックアップ費用(約19%)
• **Aurora バックアップ**: $150 (約9%)
• **Aurora IO最適化ストレージ**: $100 (約6%)
• **その他(RDS バックアップなど)**: $50 (約3%)

### 2. インスタンスタイプ別内訳

• **db.r6i.large**: $1,000 (約63%)
  • メモリ最適化インスタンス(最新世代)
• **db.r5.xlarge**: $300 (約19%)
  • メモリ最適化インスタンス(前世代、より大きなサイズ)
• **NoInstanceType**: $300 (約19%)
  • ストレージ、バックアップ等のインスタンス以外の費用

### 3. データベースエンジン別内訳

• **Aurora PostgreSQL**: $1,550 (約97%)
  • ほぼ全てがAurora PostgreSQLの利用
• **Any**: $50 (約3%)
  • 汎用的なRDS費用(バックアップ等)

### 分析結果とコスト最適化の提案

主要な費用要因
1. db.r6i.largeインスタンスが全体の約63%を占める
2. Aurora PostgreSQLが主要なデータベースエンジン
3. バックアップとストレージで約19%の費用

最適化の検討ポイント
• db.r6i.largeのリザーブドインスタンス利用状況の確認
• Aurora Serverless v2への移行検討(負荷変動がある場合)
• バックアップ保持期間の見直し
• IO最適化ストレージの必要性確認

この構成は、本格的なデータベースワークロードに適した設定ですが、利用パターンに応じてさらなる最適化の余地があります。

こちらも取得された値に大きな問題はなく、全体的に適切な結果を返してくれていました。
また、使用タイプやインスタンスタイプなど、複数の異なる観点から情報を提示してくれています。

もちろん AWS マネジメントコンソールから同等の情報を取ることもできますが、
操作に慣れていないと、グループ化の条件やフィルタなど、都度設定を更新するのも少々手間がかかります。
分析したい内容により、別の切り口で出力させることも可能ですし、
自然言語で容易に分析を進められることのメリットは大きいのではないでしょうか。

2. AWS Knowledge MCP Server を併用した深堀り分析

続いて、RDS に関する分析結果を元に、具体的な削減見込額や対応が知りたいです。
AWS Cost Explorer MCP Server でもコスト最適化提案は行ってくれていますが、
AWS Knowledge MCP Server も併用することで、より具体的な提案を得られるか確認します。

なお、前述の通り、過去の履歴データの取得制限の都合上、 一旦 I/O 料金が高かった時期の費用内訳を直接渡しています。
実際は、14 ヶ月も前のデータを根拠にコスト最適化を進めることは少ないはずなので、
前項の手順で得られた分析結果をインプットに使うか、この部分は割愛するかで問題ないかと思います。

▶ コスト最適化の具体的なアプローチの提案依頼

プロンプト

RDS のコストが高いので、費用を削減したいです。
ある月の請求の内訳は以下のようになりました。

- Amazon Aurora Storage and I/O: USD 2,000.00
- Amazon Relational Database Service for Aurora PostgreSQL: USD 250.00
- Amazon Relational Database Service Backup Storage: USD 50.00
- Amazon Relational Database Service for Aurora PostgreSQL Reserved Instances: USD 0.00

コスト最適化を図るため、どのようなアプローチが考えられますか?
aws_knowledge_mcp_server を利用して、提案してください。

出力

> RDSのコスト削減について、AWS公式ドキュメントを参照しながら具体的な提案をさせていただきます。まず、現在のコスト構造を分析し、関連するAWSドキュメントを確認してみましょう。


🛠️  Using tool: aws___search_documentation from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___search_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___search_documentation",
 ⋮    "arguments": {
 ⋮      "search_phrase": "Aurora cost optimization storage pricing",
 ⋮      "limit": 5
 ⋮    }
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> t


 ⋮ 
 ● Completed in 1.892s





🛠️  Using tool: aws___search_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___search_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___search_documentation",
 ⋮    "arguments": {
 ⋮      "limit": 5,
 ⋮      "search_phrase": "Aurora I/O-Optimized storage cost reduction"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 1.525s





🛠️  Using tool: aws___read_documentation from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___read_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___read_documentation",
 ⋮    "arguments": {
 ⋮      "url": "https://aws.amazon.com/blogs/database/how-moneylion-achieved-price-predictability-and-55-cost-savings-using-amazon-aurora-i-o-optimized-and-optimized-ri-purchases/"
 ⋮    }
 ⋮  }

Allow this action? Use 't' to trust (always allow) this tool for the session. [y/n/t]:

> t


 ⋮ 
 ● Completed in 1.128s





🛠️  Using tool: aws___read_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___read_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___read_documentation",
 ⋮    "arguments": {
 ⋮      "url": "https://aws.amazon.com/blogs/database/how-moneylion-achieved-price-predictability-and-55-cost-savings-using-amazon-aurora-i-o-optimized-and-optimized-ri-purchases/",
 ⋮      "start_index": 10000
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 1.200s





🛠️  Using tool: aws___search_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___search_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___search_documentation",
 ⋮    "arguments": {
 ⋮      "limit": 5,
 ⋮      "search_phrase": "Aurora Reserved Instances cost optimization"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 1.515s





🛠️  Using tool: aws___read_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___read_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___read_documentation",
 ⋮    "arguments": {
 ⋮      "url": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_WorkingWithReservedDBInstances.html"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 0.608s


> 現在のコスト構造を分析すると、最も大きな費用は「Amazon Aurora Storage and I/O」の$2,000で、全体の約87%
を占めています。AWS公式ドキュメントを参照した結果、以下のコスト最適化アプローチを提案いたします:

## 1. Aurora I/O-Optimized への移行(最優先)

効果:最大55%のコスト削減

現在のコスト構造から、I/O集約的なワークロードであることが明らかです。MoneyLionの事例では、Aurora I/O-
Optimizedに移行することで55%のコスト削減を実現しました。

メリット:
• I/O料金が0円(コンピュートとストレージに統合)
• 予測可能な料金体系
• パフォーマンス劣化なし
• ダウンタイムなしでの移行可能

移行方法:
bash
# Aurora クラスターの設定変更(コンソールまたはCLI)
aws rds modify-db-cluster \
    --db-cluster-identifier your-cluster-id \
    --storage-type aurora-iopt1


## 2. Reserved Instances(RI)の活用

効果:追加で10%以上のコスト削減

現在RIの利用が$0となっているため、大きな改善余地があります。

推奨アクション:
• 1年または3年のRIを購入
• Aurora I/O-Optimizedでは通常のRIより30%多くの正規化ユニットを消費するため、適切な容量を計算
• Size-flexible RIを活用してインスタンスサイズの変更に対応

## 3. ストレージとバックアップの最適化

現在のバックアップコスト:$50.00

最適化施策:
• バックアップ保持期間の見直し(デフォルト7日→必要最小限)
• 不要なスナップショットの削除
• バックアップウィンドウの最適化

bash
# バックアップ保持期間の変更
aws rds modify-db-cluster \
    --db-cluster-identifier your-cluster-id \
    --backup-retention-period 3


## 4. インスタンスサイズの最適化

推奨アクション:
• CloudWatchメトリクスでCPU使用率、メモリ使用率を確認
• 過剰にプロビジョニングされている場合はダウンサイジング
• Aurora Serverless v2の検討(変動するワークロード向け)

## 5. 段階的な実装計画

1. 第1段階(即座に実行):
   • Aurora I/O-Optimizedへの移行
   • バックアップ設定の見直し

2. 第2段階(1-2週間後):
   • コスト削減効果の測定
   • 適切なRIサイズの計算と購入

3. 第3段階(継続的):
   • パフォーマンスメトリクスの監視
   • 必要に応じたインスタンスサイズ調整

## 期待される効果

• **Aurora I/O-Optimized移行**:約$1,100/月の削減(I/O費用の55%削減)
• **RI活用**:追加で約$150/月の削減
• **バックアップ最適化**:約$20/月の削減

総削減見込み:月額$1,200-1,300(約55%のコスト削減)

これらの施策により、現在の月額約$2,300から約$1,000-1,100程度まで削減できる可能性があります。特にAurora I/O-Optimizedへの移行は、MoneyLionの実例でも証明されている効果的な手法です。

期待通り、Aurora I/O-Optimized の導入提案を行い、想定される削減コストまで算出してくれています。

また、Aurora I/O-Optimized には、ストレージ I/O 料金が無料になる代わりに、ストレージ使用料金が上がるという仕様があります。
プロンプトで渡している情報のみでは、そのあたりの考慮ができておらず、当時実際に想定していたコストとは差分がありましたが、
Cost Explorer MCP Server から取得した値をベースにすれば、実際に発生しているコストを元に適切に考慮させることは可能かと思います。

3. 特定の機能に関する信頼性の高い情報を収集

ここまでで、コスト最適化の大まかな方針を提案してもらうことができました。
特に効果が高そうな Aurora I/O-Optimized の導入を進めたいとします。

ただし、実際のコスト最適化の流れを考えると、「AI が言ったからそのまま進める」ということは考えにくいですよね。
当然、利用しようとしているサービスや機能の詳細を把握し、実際のワークロードへの影響も踏まえながら、慎重に計画していく必要があります。

ここでは、Aurora I/O-Optimized の詳細な仕様を把握していないと仮定して、
概要やメリット・デメリットなどを、信頼性の高い各種ナレッジをベースに回答してもらいましょう。

▶ Aurora I/O-Optimized の機能の詳細を確認

プロンプト

Aurora I/O-Optimized 移行を検討したいです。  
これはどのような機能ですか?
メリット・デメリット、および有効化する際の考慮事項などがあれば教えて下さい。

出力

> Aurora I/O-Optimizedについて、AWS公式ドキュメントを参照しながら詳しく説明いたします。


🛠️  Using tool: aws___search_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___search_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___search_documentation",
 ⋮    "arguments": {
 ⋮      "limit": 5,
 ⋮      "search_phrase": "Aurora I/O-Optimized configuration features benefits"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 2.740s





🛠️  Using tool: aws___read_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___read_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___read_documentation",
 ⋮    "arguments": {
 ⋮      "url": "https://aws.amazon.com/about-aws/whats-new/2023/05/amazon-aurora-i-o-optimized/"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 1.352s





🛠️  Using tool: aws___search_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___search_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___search_documentation",
 ⋮    "arguments": {
 ⋮      "limit": 5,
 ⋮      "search_phrase": "Aurora storage configurations I/O-Optimized vs Standard"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 2.81s





🛠️  Using tool: aws___search_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___search_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___search_documentation",
 ⋮    "arguments": {
 ⋮      "limit": 5,
 ⋮      "search_phrase": "Aurora I/O-Optimized limitations considerations migration"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 1.979s





🛠️  Using tool: aws___search_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___search_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___search_documentation",
 ⋮    "arguments": {
 ⋮      "limit": 5,
 ⋮      "search_phrase": "Aurora storage type configuration switching I/O-Optimized"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 2.254s





🛠️  Using tool: aws___read_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___read_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___read_documentation",
 ⋮    "arguments": {
 ⋮      "url": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.html"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 1.128s





🛠️  Using tool: aws___search_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___search_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___search_documentation",
 ⋮    "arguments": {
 ⋮      "limit": 5,
 ⋮      "search_phrase": "Aurora storage configurations aurora-iopt1 aurora-std"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 2.189s





🛠️  Using tool: aws___read_documentation (trusted) from mcp server aws_knowledge_mcp_server
 ⋮ 
 ● Running aws___read_documentation with the param:
 ⋮  {
 ⋮    "name": "aws___read_documentation",
 ⋮    "arguments": {
 ⋮      "url": "https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.Aurora_Fea_Regions_DB-eng.Feature.storage-type.html"
 ⋮    }
 ⋮  }

 ⋮ 
 ● Completed in 1.55s


> Aurora I/O-Optimizedについて、AWS公式ドキュメントの情報を基に詳しく説明いたします。

## Aurora I/O-Optimizedとは

Aurora I/O-Optimizedは、2023年5月にリリースされたAuroraの新しいストレージ設定で、I/O集約的なアプリケーション向けに設計された機能です。

### 基本的な仕組み

Aurora Standard(従来):
• コンピュート + ストレージ + I/O料金(読み書き操作ごとに課金)

Aurora I/O-Optimized:
• コンピュート + ストレージのみ(I/O料金は0円)
• I/O料金がコンピュートとストレージに統合された料金体系

## メリット

### 1. コスト削減
• **I/O料金が総コストの25%以上の場合、大きなコスト削減**が期待できる
• MoneyLionの事例では55%の削減を実現
• 予測可能な料金体系(I/O変動による料金変動なし)

### 2. パフォーマンス向上
• スループットの向上
• レイテンシの削減
• 無制限のI/O操作(スロットリングなし)

### 3. 運用面のメリット
• **ダウンタイムなしでの移行**
• 簡単な切り替え(コンソールでワンクリック、またはCLIコマンド一つ)
• 既存のRIがそのまま利用可能

## デメリット・考慮事項

### 1. コスト面の考慮
• **I/O使用量が少ない場合は割高**になる可能性
• Aurora StandardからI/O-Optimizedでは、RIの正規化ユニットが30%増加
• 低〜中程度のI/Oワークロードには不向き

### 2. 技術的制約
• **対応インスタンスタイプ:** T3, T4g, R5, R6i, R6g, X2g, R7g
• **対応バージョン:**
  • Aurora MySQL: 3.03.1以上
  • Aurora PostgreSQL: 16.1以上、15.2以上、14.7以上、13.10以上

### 3. 切り替え制限
• **I/O-Optimizedへの切り替えは30日に1回まで**
• Aurora Standardへの戻しはいつでも可能

## 有効化時の考慮事項

### 1. 事前評価
現在のI/O料金が全体の25%以上かどうかを確認:
I/O料金比率 = $2,000 / $2,300 = 約87%

→ 明らかにI/O-Optimizedが有効

### 2. 段階的移行の推奨
1. ステージング環境での検証(可能であれば)
2. 本番環境での移行
3. コスト効果の測定(AWS Cost Explorerで確認)

### 3. 移行手順
bash
# CLI での移行
aws rds modify-db-cluster \
    --db-cluster-identifier your-cluster-identifier \
    --storage-type aurora-iopt1 \
    --apply-immediately


### 4. 監視項目
• **コスト変化:** AWS Cost Explorerで月次比較
• **パフォーマンス:** CloudWatchメトリクスでレイテンシ、スループット確認
• **RI使用率:** 正規化ユニット消費量の変化

## 推奨判断基準

あなたのケースでは:
• I/O料金が87%を占める → 強く推奨
• RI(リザーブドインスタンス)が未適用 → インスタンス費用の追加削減の余地あり
• ダウンタイムなしで移行可能 → リスク最小

結論: 現在のコスト構造から判断すると、Aurora I/O-Optimizedへの移行は非常に有効で、月額$1,200以上のコスト削減が期待できます。

移行を検討される場合は、まずAWS Compute Optimizerの推奨事項も確認されることをお勧めします。

ドキュメントから得た情報をベースに、実際のコスト状況やアプリケーションへの影響も考慮して回答してくれていますね。

実際にはもう何度か追加のやり取りをしたり、実際に自分でドキュメントを確認したりしながら対応を計画していくことになるかと思いますが、
入口として有用な情報を提供してくれているのではないかと思います。

まとめ

今回は、2つの AWS MCP Servers を用いて、コスト最適化をどのように効率化できるかを検討してみました。
以下のような流れで進めることで、インフラエンジニア以外の方も含め、コスト最適化対応を進めていくうえで役立てられる可能性が十分にあると感じました。

  • AWS Cost Explorer MCP Server で全体の傾向を分析
    • 最適化の対象となりうるサービスをピックアップ
    • 最適化の大まかなアプローチを提案
  • AWS Knowledge MCP Server(AWS Documentation MCP Server)で深堀り
    • 提案された機能の概要、メリット・デメリット把握
    • 具体的な事例や考慮事項の確認

実際に発生しているコストとドキュメントを突き合わせた上で提案してくれることが回答の信頼性につながっており、
うまく活用することで精度向上・効率化が図れるのではないでしょうか。

課題

上記の例では、うまくいった部分を抽出していますが、
検証の中では明らかに誤った出力や、誤ってはいないが考慮が漏れているような出力も見受けられました。

もちろん、今回のように MCP Server を使うことに加え、 よりプロンプトを工夫したり、適切に背景情報を伝えたりすることで、不正確な出力の頻度は減らせると考えます。

ただ、今回の事例に限らないですが、受け取る側に一定の知識がないと、出力された内容に違和感を持つことは難しいと思います。
つまり、自身の持つ知識の範囲内でしか回答を評価できないと認識しています。

運用中のサービスに関するインフラの業務は、判断を誤るとお客様に大きな影響を及ぼしてしまうこともあります。
当然のことですが、生成 AI の出力を鵜呑みにしすぎず、しっかり検証を行って理解したうえで対応を進めるのが望ましいと考えます。

より踏み込んだ分析を行いたい場合

今回の検証では、Cost Explorer から得られる情報を元にした基本的な分析を行いました。
簡易な対応においては、これだけでも十分な有用な洞察が得られます。

ただし、より踏み込んだ分析を行いたい場合、Cost Explorer のみでは分析が難しく、Cost and Usage Reports(CUR) などを用いた分析が有効なケースがあります。

dfplus.io でも、 DuckDB を用いて、CUR から NAT Gateway や S3 の通信料などを分析し、コスト最適化対応を行いました。
こちらの DuckDB についても、現在は MCP Server が提供されており、CUR を用いたより高度な分析も、手軽に行うことができるようになっています。

こちらもそこそこの精度で分析できることが確認できているので、また機会があればご紹介したいと思います。