こんにちは。株式会社NTTデータ九州の山下です。
Amazon Web Services（AWS） を中心にクラウドアーキテクチャの設計・構築を担当しています。

本記事では、Amazon Aurora PostgreSQL から Amazon Simple Storage Service（S3）へのエクスポートにおいて、
「公式ドキュメント通りに構成したはずなのに、なぜか動かない」、という事象に遭遇し、要件を整理し直すことで解決に至った事例を紹介します。

本件の原因は、S3 エクスポート処理において内部的に利用される AWS サービスを見落としていたことでした。

※本記事は 2026 年 4 月時点の情報に基づいて作成しています。サービス仕様は変更される可能性があるため、実際の利用時には最新の公式ドキュメントをご確認ください。
※本記事の内容は検証環境での事例であり、実際の商用環境とは異なる場合があります。

構成概要

公式ドキュメントを参考に、Aurora PostgreSQL のデータを S3 にエクスポートする構成を検討しました。

参考：Amazon Aurora PostgreSQL からの Amazon S3 へのデータのエクスポート（公式ドキュメント）

今回の構成は、以下を前提としています。

リージョン：東京（ap-northeast-1）
同一 AWS アカウント / 同一 VPC
Aurora PostgreSQL はプライベートサブネットに配置
S3 への通信は VPC Endpoint 経由の閉域網通信
Aurora PostgreSQL バージョン：16.4

AWS サポートからは、S3 へのアクセスにおいて Gateway Endpoint / Interface Endpoint のいずれも利用可能であるとの回答を得ました。
今回は既存設計との整合性を考慮し、Interface Endpoint に統一しました。

実際に NACL や Route Table を設定し、S3 エクスポートを実行しましたが──結果は失敗しました。

発生したエラーと状況整理

この検証以前から S3 Interface Endpoint は作成済みで、他のサブネットからは問題なく利用できていました。
また Reachability Analyzer でも、Aurora ENI → S3 Interface Endpoint の到達性は確認できていました。

一方、Aurora PostgreSQL に出力されたエラーは次の通りです。

2026-01-01 00:00:00 UTC:10:10:10:10(51916):user@database:[21827]:ERROR:     could not upload to Amazon S3  
2026-01-01 00:00:00 UTC:10:10:10:10(51916):user@database:[21827]:DETAIL:     Amazon S3 client returned 'curlCode: 28, Timeout was reached'

このエラーは、Aurora から S3 への接続でタイムアウトが発生したことを示しています。
S3 自体には到達できている前提だったため、S3 以外の AWS サービスへの通信で問題が発生している可能性を疑いました。

改めて AI ツールを用いて要件を整理し、公式ドキュメントを再確認したところ、次の事実に気づきました。

Aurora PostgreSQL の S3 エクスポートでは、S3 以外の AWS サービスへの API コールが必要

Aurora PostgreSQL の S3 エクスポートに必要な依存関係

実際に必要だった AWS サービスは、次の 2 つです。

1. AWS Security Token Service（STS）

一時クレデンシャルの発行
IAM ロールの AssumeRole 実行
エクスポート処理の認証

2. AWS Key Management Service（KMS）

S3 にエクスポートするデータの暗号化
GenerateDataKey などの KMS API コール

つまり、S3 Interface Endpoint に到達できても、
Aurora PostgreSQL から STS / KMS への通信経路がなければ、エクスポートは正常に動作しません。

今回の構成では、STS と KMS の Interface Endpoint への通信経路を用意していなかったことが原因でした。

補足：必要な Interface Endpoint

com.amazonaws.ap-northeast-1.s3
com.amazonaws.ap-northeast-1.sts
com.amazonaws.ap-northeast-1.kms

補足：使用した MCP Server

Aurora PostgreSQL の S3 エクスポートについて調査する中で、MCP Server が役立ちました。
MCP Server を使うことで、公式ドキュメントの文脈を踏まえて以下を整理できました。

S3 だけでなく STS / KMS が内部的に使われている点。
公式ドキュメント上では前提として扱われているが、構成次第では見落としやすい点。

使用した MCP Server は以下の通りです。

AWS Documentation MCP Server：
AWS公式ドキュメントを検索・参照し、サービス仕様や前提条件などの一次情報を確認するために使用する。
AWS Knowledge MCP Server：
公式ドキュメントをもとに整理・要約された知識やベストプラクティスを参照し、設計判断や構成検討の妥当性を補強するために使用する。
AWS Terraform MCP Server：
Terraform 定義や AWS リソース構成に関する情報を参照し、IaC を用いた設計やレビューを支援するために使用する。

その後の対応

原因が「STS / KMS への通信経路不足」と判明した後、
公式トラブルシューティングで示されている前提条件を、VPC Endpoint 構成としてどう満たすかを整理して確認しました。

参考：Amazon S3 へのアクセスのトラブルシューティング（公式ドキュメント）

アウトバウンド通信（TCP 443）の再確認

TCP トラフィックの送信ルールを確認しました。

Aurora にアタッチされた Security Group
- アウトバウンドで TCP 443 が許可されていること
Interface Endpoint 側の Security Group
- Aurora の Security Group からの 443 通信を受け入れていること

STS / KMS Interface Endpoint への通信確認

次に、STS / KMS Interface Endpoint への到達性の確認を行いました。

Route Table
- Aurora PostgreSQL が配置されているサブネットから
  STS / KMS Interface Endpoint 宛通信が正しくルーティングされていること
NACL
- エンドポイントとの双方向通信を阻害するルールが存在しないこと
Reachability Analyzer
- Aurora ENI → STS / KMS Interface Endpoint まで到達可能であること

Interface Endpoint を作成しただけで安心せず、
公式ドキュメントで暗黙的に前提となっている「AWS API に到達できること」を一つずつ確認しました。

IAM ポリシーについて（S3 / STS / KMS）

Aurora PostgreSQL 用の IAM ロールおよびポリシーについては、以下の権限を付与しました。

STS / KMS 関連

sts:AssumeRole
kms:GenerateDataKey
kms:Decrypt

S3 関連

s3:PutObject
s3:AbortMultipartUpload

修正後の結果

STS / KMS の Interface Endpoint を追加し、
アウトバウンド通信（TCP 443）とルーティングを確認したうえで
再度 S3 エクスポートを実行したところ、

curlCode: 28（Timeout）エラーは発生せず
S3 バケットに正常にオブジェクトが作成されること

を確認しました。

まとめ

Aurora PostgreSQL の S3 エクスポートには、必要な AWS API（S3 / STS / KMS）への通信が成立していることが重要。
マネージドサービスの機能であっても、内部的に利用されるAWSサービスの通信要件を明示的に整理することが重要。
MCP Server は、一次情報の確認から実装検討までを補助し、設計やトラブルシュートの初動において有効。

同様のハマりポイントがあれば、ぜひコメントでご共有ください。

免責事項

本記事は筆者個人の見解に基づくものであり、所属組織の公式見解ではありません。
また、本記事の内容を利用したことによって生じたいかなる損害についても、筆者は責任を負いかねます。