Aurora PostgreSQL — 人間がログインしないDB管理 完全ガイド

公開日: 2026-04-14
難易度: 中級〜上級
所要時間: 約120分
タグ: AWS, Aurora, PostgreSQL, Terraform, IAM認証, RDS Proxy, Lambda, IaC

1. なぜ「人間がログインしないDB管理」なのか

1-1. 従来のDB管理が抱える問題

多くの現場では、Aurora PostgreSQLを含むRDBMSの管理を「人間が直接ログインして操作する」方法で行っています。しかしこのアプローチには、セキュリティ・運用・コンプライアンスの観点から深刻な問題があります。

問題1: パスワードの共有と管理コスト

従来の構成では、DBのマスターパスワードやアプリ用パスワードをチームで共有することが一般的です。

問題2: 踏み台サーバーによる属人的な運用

多くの現場では「踏み台EC2 → SSH → psql」というオペレーションフローが定着しています。

[開発者PC] → SSH → [踏み台EC2] → psql → [Aurora PostgreSQL]

この構成の問題点:

• 属人化: 踏み台サーバーのIPアドレス、SSHキー、接続手順がドキュメントに散在
• セキュリティリスク: 踏み台サーバー自体が攻撃対象になる。SSHキーの漏洩リスク
• 変更追跡不可能: psqlで実行したSQLはCloudTrailに残らない
• スケール困難: 開発者が増えるたびにSSHキー発行・管理が必要

問題3: 手動DDLによる一貫性の欠如

「スキーマを変更したいとき」に開発者がpsqlで直接DDLを実行するケースは珍しくありません。

-- 開発者Aがログインして手動実行（ステージング環境に反映済み）ALTER TABLE users ADD COLUMN last_login_at TIMESTAMP;-- 本番環境への展開を忘れていた...

この問題は：
– 本番/ステージングの乖離: 誰かが手動で変更を加えると環境間で差分が生まれる
– レビュープロセスの欠如: コードと異なり、DBへの手動変更はPull Requestでのレビューがない
– ロールバックが困難: 誤ったDDLをロールバックするには再度手動で修正が必要

1-2. 理想の形: Infrastructure as Code + IAM認証

本記事が目指すアーキテクチャは 「人間がAurora PostgreSQLに直接ログインしない」 構成です。

理念

❌ 従来: 人間 → psql → Aurora（パスワード認証・手動操作）✅ 理想: コード → Terraform/Lambda → Aurora（IAM認証・自動実行）

具体的な解決策

1-3. 本記事のゴール

本記事では以下を実現します:

1. Aurora PostgreSQL Serverless v2 をVPC内に構築
2. RDS Proxy をフロントに配置してコネクション管理
3. IAM認証 を有効化し、パスワードなしで接続
4. Terraform cyrilgdn/postgresql provider でスキーマ・ロール・権限を宣言的管理
5. Lambda + psycopg2 でDDLを自動実行するサーバーレスパターンを実装
6. 全リソースを Terraform IaC で管理し、git push だけで環境を再現可能に

2. DB管理手法 徹底比較

Aurora PostgreSQLへのアクセス・管理方法は多岐にわたります。本セクションでは8つの代表的な手法を整理し、本記事でのハンズオン対象選定理由を説明します。

2-1. 8つの方法の概要

A. Terraform postgresql provider（cyrilgdn/postgresql）

Terraform HashiCorp Registryで公開されている cyrilgdn/postgresql プロバイダー（v1.26.0、2025年9月）を使い、Aurora PostgreSQLのスキーマ・ロール・権限をTerraformリソースとして宣言的に管理します。

• 特徴: 19種類のリソース（postgresql_database/postgresql_schema/postgresql_role/postgresql_grant等）
• IAM認証: scheme=awspostgres + aws_rds_iam_auth=true でパスワードレス接続対応（v1.25.0〜）
• ユースケース: 初期スキーマ構築・ロール管理・権限管理をIaCで完結させたい場合

B. Flyway（CodeBuild / Fargate）

Java製のDBマイグレーションツール「Flyway」をAWSサービス上で実行するパターン。AWS公式ブログでもCodePipeline + CodeBuildの構成が紹介されています。

• 特徴: SQLスクリプトをバージョン番号管理（V1.0__init.sql, V2.0__add_column.sql）
• IAM認証: 直接サポートなし（Secrets Manager経由のパスワード認証が一般的）
• ユースケース: 継続的なスキーママイグレーションをCI/CDパイプラインに組み込みたい場合

C. Lambda + psycopg2

Python製のPostgreSQL接続ライブラリ psycopg2 をLambda LayerとしてパッケージングしたLambda関数からAuroraにアクセスするパターン。

• 特徴: boto3.client('rds').generate_db_auth_token() でIAM認証トークンを生成し接続
• ユースケース: 軽量DDL実行・スキーマ初期化・EventBridge Schedulerでの定期実行

D. RDS Data API

AuroraにHTTPS経由でSQLを実行できるAPI。VPCへの接続不要でVPC外からも利用可能。

• 特徴: DDL対応、トランザクション対応、IAM認証（rds-data:ExecuteStatement権限）
• 制約: ENUM型非対応、結果サイズ上限1MB、T系インスタンス非対応
• ユースケース: VPC外からの軽量DB操作・開発環境でのデバッグ

E. IAM データベース認証

Aurora PostgreSQLクラスターレベルでIAM認証を有効化し、トークンベースのパスワードレス接続を実現する基盤機能。他の方法（A/C/F）と組み合わせて使用します。

• 仕組み: IAMポリシーで rds-db:connect 権限を付与 → 15分間有効のトークンを生成 → パスワード代わりに使用
• RDS Proxy連携: アプリ→RDS Proxy間はIAM認証、RDS Proxy→Aurora間はSecrets Manager

F. SSM Session Manager + ECS Run Task

SSM Session ManagerのPort Forwarding機能でEC2経由のポートフォワードを行い、ローカルPCからpsqlやpgAdminで接続するパターン、またはECS Fargateでpsqlコンテナを一時実行するパターン。

• SSM: aws ssm start-session --document-name AWS-StartPortForwardingSessionToRemoteHost → localhost:15432 で接続
• ユースケース: 開発者のad-hocなDB参照（踏み台EC2サーバー不要）

G. DMS / SCT（Database Migration Service）

異種DB間のスキーマ変換・データ移行ツール。同一エンジン（PostgreSQL → Aurora PostgreSQL）のスキーマ管理には不適切で、既存DBからの初期移行時のみ利用します。本記事の対象外です。

H. その他のパターン

• GitHub Actions OIDC: OIDC → IAMロール → generate_db_auth_token → Aurora接続。CI/CDパイプラインからパスワードなしでDB操作
• Secrets Manager 自動ローテーション: ローテーションLambdaをカスタマイズしてスキーマ変更も実行（非推奨）
• AWSコンソール Query Editor: Data APIを使ったGUI操作。開発・デバッグ用途

2-2. 比較表

2-3. 本記事でのハンズオン対象

本記事では以下を選定しました。

メインハンズオン: A + E + RDS Proxy（Terraform + IAM認証 + RDS Proxy）

[Terraform実行環境]↓（IAM認証 / awspostgres scheme）[RDS Proxy] → [Aurora PostgreSQL Serverless v2]↑[Lambda / アプリ]（IAM認証 / generate_db_auth_token）

選定理由:
– IaCに最も忠実: スキーマ・ロール・権限がすべてTerraform stateで管理され、terraform planで差分を可視化できる
– パスワードレス: IAM認証によりパスワード自体が存在しない。ローテーション不要
– 「人間がログインしない」コンセプトに最合致: コードのみがDBを操作し、全変更がGit管理される
– RDS Proxy: コネクションプーリングによるスケーラビリティ、フェイルオーバーの高速化

サブハンズオン: C（Lambda + psycopg2 + IAM認証）

Terraform providerでは管理できないインデックス作成やデータシードのユースケースをLambdaで補完します。Phase 4〜5で実装します。

解説のみ（ハンズオン手順なし）:

• D（RDS Data API）: VPC不要で最も手軽だが制約が多い。概要とQuery Editor紹介のみ
• B（Flyway on CodeBuild）: Java依存・Enterprise版が必要なケースあり。アーキテクチャ概要のみ
• F（SSM Port Forwarding）: 開発者のデバッグ用。コマンド例のみ
• H（GitHub Actions OIDC）: CI/CD応用パターンとして紹介

3. アーキテクチャ概要

3-1. 全体構成

本記事で構築するシステムの全体像を示します。

ネットワーク構成

システム全体はVPC内のプライベートサブネットに配置します。インターネットからAurora PostgreSQLへの直接アクセスは行いません。

ap-northeast-1（東京リージョン）└── VPC (10.0.0.0/16) ├── パブリックサブネット (10.0.1.0/24, 10.0.2.0/24) │└── NAT Gateway（Lambda → VPCエンドポイント用） └── プライベートサブネット (10.0.11.0/24, 10.0.12.0/24)  ├── Aurora PostgreSQL Serverless v2（マルチAZ）  ├── RDS Proxy  └── Lambda関数（VPC Lambda）

コンポーネント一覧

3-2. IAM認証フロー

IAM認証は「パスワードの代わりに15分間有効なトークンを使う」仕組みです。

フローの詳細

Terraform postgresql provider（スキーマ管理時）:

1. Terraform実行環境（IAMロール: terraform_pg_role）2. generate_db_auth_token（scheme=awspostgres が自動処理）3. RDS Proxy エンドポイントに接続（TLS必須）4. RDS Proxy → Aurora PostgreSQL（Secrets Manager認証）5. DDLリソースを作成/更新/削除

Lambda + psycopg2（DDL実行時）:

import boto3, psycopg2# IAM認証トークン生成（15分間有効）client = boto3.client('rds', region_name='ap-northeast-1')token = client.generate_db_auth_token( DBHostname=rds_proxy_endpoint, Port=5432, DBUsername='iam_user', Region='ap-northeast-1')# パスワード代わりにトークンを使用conn = psycopg2.connect( host=rds_proxy_endpoint, port=5432, user='iam_user', password=token, dbname='mydb', sslmode='require')

RDS Proxy の役割:

RDS Proxyを経由することで、アプリ側はIAM認証のみを意識すればよく、Aurora側のパスワード管理はRDS Proxyが吸収します。

3-3. マイグレーションフロー

スキーマ変更の流れを示します。

Terraformによるスキーマ変更フロー

① 開発者がpostgresql.tf を編集② git push → Pull Request作成③ CIで terraform plan を実行（差分レビュー）④ レビュー承認 → main ブランチにマージ⑤ CD（GitHub Actions等）で terraform apply 自動実行⑥ postgresql provider が RDS Proxy 経由でDDLを実行⑦ terraform state に変更後の状態を記録

Lambdaによるマイグレーションフロー（インデックス・データシード等）

① EventBridge Scheduler（毎日実行）またはStep Functions② Lambda関数（Python 3.12 + psycopg2）を起動③ Lambda が RDS Proxy 経由でIAM認証接続④ migration_versionテーブルで未適用マイグレーションを確認⑤ 未適用のDDL/DMLを冪等に実行（IF NOT EXISTS等）⑥ CloudWatch Logsに実行結果を記録

3-4. 各コンポーネントの役割詳細

VPC

プライベートサブネット内にAurora・RDS Proxy・Lambdaを配置し、インターネットからの直接アクセスを遮断します。セキュリティグループでポート5432の通信を制御します。

セキュリティグループ:- aurora_sg: ポート5432 ← rds_proxy_sg, lambda_sg のみ許可- rds_proxy_sg: ポート5432 ← lambda_sg, terraform_sg のみ許可- lambda_sg: アウトバウンドのみ（STS, Secrets Manager, RDS Data API）

Aurora PostgreSQL Serverless v2

最小0.5 ACU（Aurora Capacity Unit）から最大128 ACUまで自動スケールします。IAM認証有効化により、マスターパスワードを知っている人間でも、IAM権限なしでは接続できなくなります。

resource "aws_rds_cluster" "aurora_pg" {  engine  = "aurora-postgresql"  engine_mode= "provisioned"  engine_version= "16.4"  iam_database_authentication_enabled = true  # IAM認証を有効化  serverlessv2_scaling_configuration { min_capacity = 0.5 max_capacity = 4.0  }}

RDS Proxy

Aurora PostgreSQLのフロントに配置するフルマネージドのコネクションプロキシです。

• コネクションプーリング: Lambda関数が並列実行されても、Aurora側のコネクション数を抑制
• フェイルオーバー高速化: Aurora障害時のフェイルオーバーを66%高速化
• IAM認証必須（REQUIRED）: IAM認証なしの接続を完全拒否

Terraform postgresql provider

cyrilgdn/postgresql プロバイダーのv1.26.0（2025年9月リリース）を使用します。

terraform {  required_providers { postgresql = {source  = "cyrilgdn/postgresql"version = "~> 1.26" }  }}provider "postgresql" {  scheme = "awspostgres"  # IAM認証用スキーム  host= aws_db_proxy.main.endpoint  port= 5432  database  = "postgres"  username  = "terraform_user"  aws_rds_iam_auth= true  # IAMトークン自動生成  aws_rds_iam_region = "ap-northeast-1"  superuser = false}

Lambda（psycopg2）

Python 3.12ランタイムのLambda関数に psycopg2 をLayerとして追加します。VPC内に配置し、RDS Proxy経由でIAM認証接続します。

3-5. コスト概算

本記事の構成を1日稼働した場合の概算コスト（東京リージョン、2026年4月時点）:

4. 前提条件と環境準備

4-1. 必要な環境

ツールのバージョン確認

# Terraform バージョン確認（1.5以上が必要）terraform version# Terraform v1.9.x# AWS CLI v2 確認aws --version# aws-cli/2.x.x Python/3.x.x ...# Python（Lambda開発用）python3 --version# Python 3.12.x# Docker（任意: psycopg2 Layer ビルド用）docker --version# Docker version 27.x.x

4-2. IAM権限の確認

ハンズオンを実行するIAMユーザー/ロールには以下の権限が必要です。

{  "Effect": "Allow",  "Action": [ "rds:*", "rds-db:connect", "secretsmanager:*", "iam:*", "lambda:*", "ec2:*", "logs:*", "sts:GetCallerIdentity"  ],  "Resource": "*"}

4-3. 作業ディレクトリ構成

本記事のTerraformコードは以下の構成で管理します。

aurora-no-human-login/├── terraform/│├── providers.tf # AWSプロバイダー + PostgreSQLプロバイダー│├── variables.tf # 変数定義│├── outputs.tf# 出力値│├── vpc.tf # VPC/サブネット/NAT Gateway/セキュリティグループ│├── aurora.tf # Aurora PostgreSQL Serverless v2 + Secrets Manager│├── rds_proxy.tf # RDS Proxy + IAM認証設定│├── iam.tf # IAMロール/ポリシー（Terraform用・Lambda用）│├── postgresql.tf# スキーマ/ロール/権限（cyrilgdn/postgresql）│├── lambda.tf # マイグレーションLambda│└── terraform.tfvars# 変数値（gitignore推奨）├── lambda/│├── migration/││├── handler.py  # Lambda関数コード││└── requirements.txt  # psycopg2-binary│└── layer/│ └── build.sh # psycopg2 Layer ビルドスクリプト└── README.md

作業ディレクトリを作成します:

mkdir -p aurora-no-human-login/terraformmkdir -p aurora-no-human-login/lambda/migrationmkdir -p aurora-no-human-login/lambda/layercd aurora-no-human-logingit init

4-4. cyrilgdn/postgresql provider について

本記事のメインハンズオンで使用する cyrilgdn/postgresql プロバイダーの概要を事前に把握しておきましょう。

# providers.tf（最小構成）terraform {  required_version = ">= 1.5"  required_providers { aws = {source  = "hashicorp/aws"version = "~> 5.0" } postgresql = {source  = "cyrilgdn/postgresql"version = "~> 1.26" }  }}

主要リソース（本記事で使用するもの）

IAM認証での接続設定（scheme=awspostgres）

cyrilgdn/postgresql v1.25.0 以降、scheme=awspostgres を指定することでIAM認証トークンを自動生成して接続できます。パスワードを一切コードに記述する必要がありません。

provider "postgresql" {  scheme = "awspostgres"  # ← GoCloud経由のIAM認証  host= "<RDS Proxyエンドポイント>"  port= 5432  database  = "postgres"  username  = "terraform_user"  aws_rds_iam_auth= true  aws_rds_iam_region = "ap-northeast-1"  # password は不要！IAMトークンが自動使用される  superuser = false  sslmode= "require"}

4-5. コスト警告

5. Phase 1: VPC + Aurora PostgreSQL + RDS Proxy 構築（コンソール）

Aurora PostgreSQL クラスターを「人間がログインしないDB管理」に適した構成で構築します。このフェーズでは AWSコンソールを使い、VPC/ネットワーク基盤から Aurora クラスター・Secrets Manager・RDS Proxy までをセットアップします。

Phase 1-1: VPC・ネットワーク基盤の作成

Aurora を VPC のプライベートサブネットに配置し、外部から直接アクセスできない構成を作ります。

1. VPC の作成

1. AWSコンソール → VPC → 左メニュー「Your VPCs」→ 「Create VPC」をクリック
2. 以下の設定を入力します：

1. 「Create VPC」をクリック

2. サブネットの作成

VPC ダッシュボード → 「Subnets」→ 「Create subnet」

Public Subnet A（NAT Gateway 配置用）

「Add new subnet」をクリックして続けて追加：

Public Subnet C

「Add new subnet」→ Private Subnet A：

「Add new subnet」→ Private Subnet C：

4 つのサブネットをまとめて作成します。「Create subnet」をクリック。

3. Internet Gateway の作成とアタッチ

1. VPC ダッシュボード → 「Internet gateways」→ 「Create internet gateway」
2. Name tag: aurora-igw → 「Create internet gateway」
3. 作成後に「Attach to a VPC」が表示されます → aurora-db-vpc を選択して「Attach internet gateway」

4. NAT Gateway の作成

Public Subnet からプライベートサブネット内の Lambda がアウトバウンド通信できるように NAT Gateway を配置します。

1. VPC ダッシュボード → 「NAT gateways」→ 「Create NAT gateway」
2. 設定：

1. 「Create NAT gateway」をクリック

5. ルートテーブルの設定

パブリック用ルートテーブル（IGW 経由）

1. VPC ダッシュボード → 「Route tables」
2. aurora-db-vpc に紐づくデフォルトルートテーブルを選択（Name が空のもの）
3. 「Actions」→「Edit routes」→「Add route」
4. Destination: 0.0.0.0/0
5. Target: aurora-igw（先ほど作成した Internet Gateway）
6. 「Save changes」
7. 「Subnet associations」タブ → 「Edit subnet associations」
8. aurora-public-1a、aurora-public-1c を選択 → 「Save associations」

プライベート用ルートテーブル（NAT 経由）

1. 「Create route table」→ Name: aurora-private-rt、VPC: aurora-db-vpc
2. 「Create route table」→ 「Edit routes」→ 「Add route」
3. Destination: 0.0.0.0/0
4. Target: aurora-nat-1a（先ほど作成した NAT Gateway）
5. 「Save changes」
6. 「Subnet associations」→ aurora-private-1a、aurora-private-1c を追加 → 「Save associations」

Phase 1-2: セキュリティグループの作成

Aurora・RDS Proxy・Lambda の間の通信を最小権限で制御する 3 つのセキュリティグループを作ります。

VPC ダッシュボード → 「Security groups」→ 「Create security group」

セキュリティグループ 1: aurora-sg（Aurora PostgreSQL 用）

Inbound rules（後で追加）: RDS Proxy SG 作成後に設定

Outbound rules（デフォルト）: すべて許可

「Create security group」

セキュリティグループ 2: rds-proxy-sg（RDS Proxy 用）

Inbound rules（後で追加）: Lambda SG 作成後に設定

Outbound rules:

「Create security group」

セキュリティグループ 3: lambda-sg（Lambda 用）

Inbound rules: なし（Lambda は受信しない）

Outbound rules:

「Create security group」

セキュリティグループのルールを更新

aurora-sg の Inbound rules を追加:

1. aurora-sg を選択 → 「Edit inbound rules」→ 「Add rule」

1. 「Save rules」

rds-proxy-sg の Inbound rules を追加:

1. rds-proxy-sg を選択 → 「Edit inbound rules」→「Add rule」

1. 「Save rules」

Phase 1-3: Aurora PostgreSQL Serverless v2 クラスターの作成

1. AWSコンソール → RDS → 「Create database」
2. 設定を順番に入力します：

① Standard create を選択

② Engine options

③ Templates

④ Settings

⑤ Cluster storage configuration

⑥ Instance configuration

⑦ Availability & durability

⑧ Connectivity

⑨ Database authentication

⑩ Monitoring

⑪ Additional configuration

1. 「Create database」をクリック

Aurora クラスターの作成には約 5〜10 分かかります。Status が「Available」になるまで次のステップに進みます。

Phase 1-4: Secrets Manager シークレットの作成

RDS Proxy がマスターユーザーの認証情報を安全に管理するため、Secrets Manager にシークレットを登録します。

1. AWSコンソール → Secrets Manager → 「Store a new secret」
2. 設定：

① Secret type

「Next」

② Configure secret

「Next」

③ Configure rotation（ローテーション設定）

「Next」→「Store」をクリック

Phase 1-5: RDS Proxy の作成

RDS Proxy を介することで、コネクションプーリングと IAM 認証の一元管理が実現します。

1. AWSコンソール → RDS → 左メニュー「Proxies」→ 「Create proxy」
2. 設定：

① Proxy configuration

② Target group configuration

③ Connectivity

④ Additional configuration

1. 「Create proxy」をクリック

RDS Proxy の作成には約 5〜10 分かかります。Status が「Available」になったら Phase 2 に進みます。

6. Phase 2: IAM 認証設定と DB ユーザー作成

Phase 1 で構築した Aurora クラスターに IAM 認証用の DB ユーザーを作成し、パスワードレス接続の基盤を完成させます。

Phase 2-1: VPC 内からの初回接続

Aurora はプライベートサブネットに配置しているため、VPC 内のリソースからしかアクセスできません。Cloud9（または EC2）を使ってプライベートサブネット内から接続します。

Cloud9 環境の準備

1. AWSコンソール → Cloud9 → 「Create environment」
2. 設定：

1. 「Create」→ Cloud9 IDE が起動するまで待つ（約 2 分）

aws ssm start-session \  --target i-xxxxxxxxxxxxxxxxx \  --document-name AWS-StartPortForwardingSessionToRemoteHost \  --parameters '{"host":["<aurora-writer-endpoint>"],"portNumber":["5432"],"localPortNumber":["15432"]}'

psql のインストールと Aurora への接続

Cloud9 ターミナルで以下を実行します：

# PostgreSQL クライアントのインストールsudo dnf install -y postgresql15# Aurora Writer エンドポイントへの接続# （RDS コンソール → Databases → aurora-no-human-login-cluster → Connectivity & security タブで確認）AURORA_ENDPOINT="aurora-no-human-login-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com"psql -h $AURORA_ENDPOINT -U postgres -d appdb

パスワードを求められたら、Phase 1-3 で設定したマスターパスワードを入力します。

接続確認：

SELECT version();-- PostgreSQL 16.x (Aurora PostgreSQL ...)  が表示される

Phase 2-2: IAM 認証用 DB ユーザーの作成

PostgreSQL の rds_iam ロールを付与したユーザーだけが IAM トークンでログインできます。

-- Terraform 実行環境用 IAM ユーザーの作成CREATE USER iam_terraform_user;GRANT rds_iam TO iam_terraform_user;-- Lambda 関数用 IAM ユーザーの作成CREATE USER iam_lambda_user;GRANT rds_iam TO iam_lambda_user;-- 確認: rds_iam ロールが付与されているか確認SELECT usename, usesuper, memberofFROM pg_userJOIN pg_auth_members ON pg_user.usesysid = pg_auth_members.memberJOIN pg_roles ON pg_auth_members.roleid = pg_roles.oidWHERE pg_roles.rolname = 'rds_iam';

期待される出力：

  usename | usesuper | memberof-------------------+----------+--------- iam_terraform_user |  false| {rds_iam} iam_lambda_user |  false| {rds_iam}(2 rows)

-- psql を終了\q

Phase 2-3: IAM ポリシーの作成

rds-db:connect アクションを IAM ポリシーで許可します。

1. AWSコンソール → IAM → 「Policies」→ 「Create policy」
2. 「JSON」タブを選択して以下を入力：

まず Aurora クラスターのリソース ID を確認します：

1. AWSコンソール → RDS → aurora-no-human-login-cluster を選択
2. 「Configuration」タブ → 「Resource ID」の値をコピー（例: cluster-XXXXXXXXXXXXXXXXX）

{  "Version": "2012-10-17",  "Statement": [ {"Effect": "Allow","Action": "rds-db:connect","Resource": [  "arn:aws:rds-db:ap-northeast-1:{ACCOUNT_ID}:dbuser:{CLUSTER_RESOURCE_ID}/iam_terraform_user",  "arn:aws:rds-db:ap-northeast-1:{ACCOUNT_ID}:dbuser:{CLUSTER_RESOURCE_ID}/iam_lambda_user"] }  ]}

{ACCOUNT_ID} は自身の AWS アカウント ID（12桁）、{CLUSTER_RESOURCE_ID} は上で確認したリソース ID に置き換えます。

1. 「Next」→ Policy name: aurora-iam-db-access → 「Create policy」

Phase 2-4: IAM ロールの作成

Terraform 実行環境と Lambda 関数それぞれに IAM ロールを作成し、aurora-iam-db-access ポリシーをアタッチします。

aurora-terraform-role（Terraform 実行環境用）

1. IAM → 「Roles」→ 「Create role」
2. Trusted entity type: AWS service → EC2
3. Add permissions: aurora-iam-db-access を検索してアタッチ
4. Role name: aurora-terraform-role
5. 「Create role」

aurora-lambda-role（Lambda 実行用）

1. IAM → 「Roles」→ 「Create role」
2. Trusted entity type: AWS service → Lambda
3. Add permissions:
4. aurora-iam-db-access
5. AWSLambdaVPCAccessExecutionRole（VPC Lambda 実行に必要）
6. Role name: aurora-lambda-role
7. 「Create role」

Phase 2-5: IAM トークンの生成テスト

RDS Proxy エンドポイントに対してトークンを生成できるか確認します。Cloud9 ターミナルで実行します。

# RDS Proxy エンドポイントを変数に設定PROXY_ENDPOINT="aurora-no-human-login-proxy.proxy-xxxx.ap-northeast-1.rds.amazonaws.com"# IAM 認証トークンの生成TOKEN=$(aws rds generate-db-auth-token \  --hostname $PROXY_ENDPOINT \  --port 5432 \  --username iam_terraform_user \  --region ap-northeast-1)# トークンの先頭 80 文字を確認echo "Token (first 80 chars): ${TOKEN:0:80}..."

期待される出力例：

Token (first 80 chars): aurora-no-human-login-proxy.proxy-xxxx.ap-northeast-1.rds.amazonaws.com:5432/...

トークンは hostname:port/?Action=connect&DBUser=...&X-Amz-Credential=... 形式の署名付き URL です。

Phase 2-6: パスワードレス接続テスト

生成したトークンを使って RDS Proxy 経由で Aurora に接続します。

# SSL 証明書のダウンロード（ap-northeast-1）wget https://truststore.pki.rds.amazonaws.com/ap-northeast-1/ap-northeast-1-bundle.pem# IAM トークン（再生成）PROXY_ENDPOINT="aurora-no-human-login-proxy.proxy-xxxx.ap-northeast-1.rds.amazonaws.com"TOKEN=$(aws rds generate-db-auth-token \  --hostname $PROXY_ENDPOINT \  --port 5432 \  --username iam_terraform_user \  --region ap-northeast-1)# パスワードレス接続PGPASSWORD=$TOKEN psql \  "host=$PROXY_ENDPOINT \port=5432 \user=iam_terraform_user \dbname=appdb \sslmode=require \sslrootcert=ap-northeast-1-bundle.pem"

接続に成功したら以下が表示されます：

psql (15.x, server 16.x)SSL connection (protocol: TLSv1.3, cipher: ..., bits: 256, compression: off)Type "help" for help.appdb=>

-- 現在のユーザーとバージョンを確認SELECT current_user, version();

期待される出力：

 current_user | version--------------------+--------- iam_terraform_user | PostgreSQL 16.x ...(1 row)

Phase 2-7: RDS Proxy 経由の接続確認と設定まとめ

ここまでの設定を整理します。

設定済みリソース一覧

接続フローのまとめ

Client (Lambda/Terraform) ↓ generate_db_auth_token (AWS STS) ↓ 15分有効なIAMトークン取得 ↓ SSL接続 (user=iam_*_user, password=token)RDS Proxy ↓ IAMトークンを検証 ↓ Secrets Managerからmaster認証情報取得 ↓ 接続プール管理Aurora PostgreSQL

トラブルシューティング: Phase 1-2 よくあるエラー

エラー: PAM authentication failed for user "iam_terraform_user"

原因: RDS Proxy が IAM 認証モードなのに、psql コマンドに SSL 設定が不足している。

対処: sslmode=require を必ず指定する。

# NG: SSL なしpsql "host=$PROXY_ENDPOINT user=iam_terraform_user dbname=appdb"# OK: SSL ありPGPASSWORD=$TOKEN psql "host=$PROXY_ENDPOINT user=iam_terraform_user dbname=appdb sslmode=require"

エラー: FATAL: IAM authentication is not allowed for user "iam_terraform_user"

原因: Aurora クラスターの IAM DB Authentication が無効。

対処: RDS コンソール → クラスター → 「Modify」→ 「Database authentication」→「Password and IAM database authentication」に変更して Apply。

エラー: connection timeout または could not connect to server

原因: セキュリティグループのルールが誤っている、またはサブネットの設定ミス。

対処:
1. lambda-sg の Outbound: rds-proxy-sg へのポート 5432 が許可されているか確認
2. rds-proxy-sg の Inbound: lambda-sg からのポート 5432 が許可されているか確認
3. RDS Proxy が aurora-private-1a と aurora-private-1c の両サブネットにデプロイされているか確認

エラー: The provided token has expired

原因: IAM トークンの有効期限（15 分）が切れた。

対処: トークンを再生成してから接続する。アプリケーションコードでは、接続前に毎回 generate_db_auth_token を呼び出すのがベストプラクティスです。

# 毎回トークンを再生成（スクリプト化するとよい）TOKEN=$(aws rds generate-db-auth-token \  --hostname $PROXY_ENDPOINT \  --port 5432 \  --username iam_terraform_user \  --region ap-northeast-1)

7. Phase 3: Terraform postgresql provider でスキーマ管理

このPhaseでは、cyrilgdn/postgresql Terraform providerを使い、AuroraのDB・スキーマ・ロール・権限・拡張機能をコードで宣言的に管理します。これにより、terraform plan でスキーマ変更差分が可視化され、Pull Requestレビューと組み合わせたガバナンスが実現します。

7-1. cyrilgdn/postgresql provider の設定

cyrilgdn/postgresql は、PostgreSQL リソース（DB・スキーマ・ロール・権限）を Terraform リソースとして管理するサードパーティproviderです。AWS IAM認証に対応しており、scheme = "awspostgres" と aws_rds_iam_auth = true を指定することでパスワードなしのIAM認証が自動的に使用されます。

providers.tf に追加

terraform {  required_providers { aws = {source  = "hashicorp/aws"version = "~> 5.0" } postgresql = {source  = "cyrilgdn/postgresql"version = "~> 1.26.0" }  }}provider "postgresql" {  scheme = "awspostgres"  host= aws_db_proxy.main.endpoint  port= 5432  database  = "postgres"  username  = "iam_terraform_user"  superuser = false  aws_rds_iam_auth= true  aws_rds_iam_region = "ap-northeast-1"  # IAMロールARN（Terraform実行環境のロール）  # aws_rds_iam_provider_role_arn = var.terraform_role_arn  # assume role使用時}

前提: Terraform実行環境のIAMロールに必要な権限

Terraform CLIを実行するIAMロール（または実行ユーザー）には、以下のポリシーが必要です。

# iam.tf （抜粋）resource "aws_iam_policy" "terraform_pg_connect" {  name = "terraform-pg-connect"  policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect= "Allow"Action= "rds-db:connect"Resource = "arn:aws:rds-db:ap-northeast-1:${data.aws_caller_identity.current.account_id}:dbuser:${aws_db_proxy.main.id}/iam_terraform_user" }]  })}

7-2. postgresql_database — データベース作成

postgresql_database リソースでアプリケーション用のデータベースを作成します。

postgresql.tf

resource "postgresql_database" "app_db" {  name  = "app_database"  owner = postgresql_role.app_owner.name  encoding = "UTF8"  lc_collate  = "C"  lc_ctype = "C"  connection_limit  = -1  allow_connections = true}

7-3. postgresql_role — ロール/ユーザー作成

PostgreSQLのロール設計は「ロール（権限の束）」と「ログインユーザー（IAMユーザー）」を分離するのがベストプラクティスです。アプリケーションコードから直接ロールにログインするのではなく、IAMユーザー（例: iam_lambda_user）に対してロールをGRANTして使います。

# アプリ書き込みロールresource "postgresql_role" "app_writer" {  name = "app_writer_role"  login= false  # ロールとして使用（直接ログイン不可）  connection_limit = -1}# アプリ読み取り専用ロールresource "postgresql_role" "app_reader" {  name = "app_reader_role"  login= false  connection_limit = -1}# アプリオーナーロール（DB所有者・スキーマ作成権限）resource "postgresql_role" "app_owner" {  name = "app_owner_role"  login= false  createdb= true  connection_limit = -1}

IAMユーザーへのロール付与

iam_lambda_user に app_writer_role を付与する例です。postgresql_grant の object_type = "role" を使います。

# iam_lambda_user に app_writer_role を付与resource "postgresql_grant" "lambda_writer_role" {  database = postgresql_database.app_db.name  role  = "iam_lambda_user"  object_type = "role"  privileges  = []  # NOTE: object_type = "role" の場合、privileges は使用されない  # GRANT ROLE は postgresql_grant ではなく  # postgresql_grant_role リソースを使うことを推奨}# 推奨: postgresql_grant_role を使う場合# resource "postgresql_grant_role" "lambda_writer" {#role = "iam_lambda_user"#grant_role = postgresql_role.app_writer.name# }

7-4. postgresql_schema — スキーマ作成

postgresql_schema リソースでアプリケーション用のスキーマを作成し、ロールごとのUSAGE権限をインラインで設定します。

resource "postgresql_schema" "app" {  name  = "app"  database = postgresql_database.app_db.name  owner = postgresql_role.app_owner.name  policy { usage = true role  = postgresql_role.app_writer.name  }  policy { usage = true role  = postgresql_role.app_reader.name  }}

7-5. postgresql_grant — 権限付与（GRANT）

postgresql_grant リソースでスキーマ・テーブルへの権限を付与します。object_type ごとに別リソースを定義する必要があります。

# app_writer ロールにスキーマ使用権限resource "postgresql_grant" "writer_schema" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_writer.name  schema= postgresql_schema.app.name  object_type = "schema"  privileges  = ["USAGE", "CREATE"]}# app_reader ロールにスキーマ使用権限resource "postgresql_grant" "reader_schema" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_reader.name  schema= postgresql_schema.app.name  object_type = "schema"  privileges  = ["USAGE"]}# app_writer ロールにテーブル権限（読み書き）resource "postgresql_grant" "writer_table" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_writer.name  schema= postgresql_schema.app.name  object_type = "table"  privileges  = ["SELECT", "INSERT", "UPDATE", "DELETE"]}# app_reader ロールにテーブル参照権限resource "postgresql_grant" "reader_table" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_reader.name  schema= postgresql_schema.app.name  object_type = "table"  privileges  = ["SELECT"]}

object_type ごとの権限マッピング

7-6. postgresql_default_privileges — デフォルト権限

postgresql_grant はすでに存在するテーブルへの権限付与です。後から作成されるテーブルにも自動的に権限を付与するには postgresql_default_privileges を使います。

# app_owner が作成する新規テーブルに自動で app_writer の権限を付与resource "postgresql_default_privileges" "writer_tables" {  database = postgresql_database.app_db.name  schema= postgresql_schema.app.name  owner = postgresql_role.app_owner.name  object_type = "table"  role  = postgresql_role.app_writer.name  privileges  = ["SELECT", "INSERT", "UPDATE", "DELETE"]}# app_owner が作成する新規テーブルに自動で app_reader の権限を付与resource "postgresql_default_privileges" "reader_tables" {  database = postgresql_database.app_db.name  schema= postgresql_schema.app.name  owner = postgresql_role.app_owner.name  object_type = "table"  role  = postgresql_role.app_reader.name  privileges  = ["SELECT"]}# シーケンスへのデフォルト権限（SERIAL/BIGSERIAL型使用時）resource "postgresql_default_privileges" "writer_sequences" {  database = postgresql_database.app_db.name  schema= postgresql_schema.app.name  owner = postgresql_role.app_owner.name  object_type = "sequence"  role  = postgresql_role.app_writer.name  privileges  = ["USAGE", "SELECT", "UPDATE"]}

SQLでの確認方法

terraform apply 後、以下のSQLでデフォルト権限が正しく設定されているか確認できます。

-- デフォルト権限の確認SELECT  pg_get_userbyid(d.defaclrole) AS "owner",  pg_get_userbyid(acl.grantee) AS "grantee",  acl.privilege_type,  d.defaclobjtype AS "object_type"FROM  pg_default_acl d,  aclexplode(d.defaclacl) AS aclWHERE  d.defaclnamespace = (SELECT oid FROM pg_namespace WHERE nspname = 'app');

7-7. postgresql_extension — 拡張機能

Aurora PostgreSQLで利用可能な拡張機能をTerraformで管理します。

# UUID生成（uuid_generate_v4() 関数）resource "postgresql_extension" "uuid_ossp" {  name  = "uuid-ossp"  database = postgresql_database.app_db.name  schema= "public"}# 暗号化（crypt()、pgp_sym_encrypt() 等）resource "postgresql_extension" "pgcrypto" {  name  = "pgcrypto"  database = postgresql_database.app_db.name  schema= "public"}

Aurora PostgreSQL でよく使われる拡張機能一覧

7-8. terraform apply でスキーマ管理

provider設定とリソース定義が完了したら、terraform init → terraform plan → terraform apply の順で実行します。

初回実行手順

cd terraform/# プロバイダーをダウンロード（cyrilgdn/postgresql を含む）terraform init# 差分確認（何が作成・変更・削除されるか確認）terraform plan# 適用terraform apply

terraform plan の出力例

Terraform will perform the following actions:  # postgresql_database.app_db will be created  + resource "postgresql_database" "app_db" {+ name = "app_database"+ owner= "app_owner_role"+ encoding= "UTF8"+ lc_collate = "C"+ lc_ctype= "C"+ connection_limit = -1 }  # postgresql_schema.app will be created  + resource "postgresql_schema" "app" {+ name  = "app"+ database = "app_database"+ owner = "app_owner_role"+ policy { + role  = "app_writer_role" + usage = true  }+ policy { + role  = "app_reader_role" + usage = true  } }  # postgresql_role.app_writer will be created  + resource "postgresql_role" "app_writer" {+ name = "app_writer_role"+ login= false+ connection_limit = -1 }  # postgresql_grant.writer_table will be created  + resource "postgresql_grant" "writer_table" {+ database = "app_database"+ role  = "app_writer_role"+ schema= "app"+ object_type = "table"+ privileges  = ["DELETE", "INSERT", "SELECT", "UPDATE"] }  # postgresql_extension.uuid_ossp will be created  + resource "postgresql_extension" "uuid_ossp" {+ name  = "uuid-ossp"+ database = "app_database"+ schema= "public" }Plan: 12 to add, 0 to change, 0 to destroy.

実行ログの確認

# apply後、tfstateで管理対象リソースを確認terraform state list | grep postgresql# 出力例:# postgresql_database.app_db# postgresql_default_privileges.reader_tables# postgresql_default_privileges.writer_sequences# postgresql_default_privileges.writer_tables# postgresql_extension.pgcrypto# postgresql_extension.uuid_ossp# postgresql_grant.reader_schema# postgresql_grant.reader_table# postgresql_grant.writer_schema# postgresql_grant.writer_table# postgresql_role.app_owner# postgresql_role.app_reader# postgresql_role.app_writer# postgresql_schema.app

7-9. スキーマ変更の差分管理

Terraform postgresql providerはスキーマ（Schema）・ロール・権限・拡張機能の宣言的管理に対応していますが、テーブルレベルのDDL（ALTER TABLE等）には対応していません。テーブル変更は Section 8 のLambdaマイグレーション、またはnull_resource + local-exec で実施します。

対応パターン: テーブルの管理方法

null_resource + local-exec を使ったカラム追加の例

Terraformからpsqlコマンドを実行してALTER TABLEを行う代替パターンです。IAM認証トークンを動的に生成して使用します。

# 一例: usersテーブルに email_verified カラムを追加resource "null_resource" "add_email_verified_column" {  # トリガー: この値が変わるたびに再実行される  triggers = { migration_version = "v1_add_email_verified"  }  provisioner "local-exec" { command = <<-EOF# IAM認証トークンを生成（有効期間15分）TOKEN=$(aws rds generate-db-auth-token \  --hostname ${aws_db_proxy.main.endpoint} \  --port 5432 \  --region ap-northeast-1 \  --username iam_terraform_user)# psql で ALTER TABLE 実行PGPASSWORD="$TOKEN" psql \  "host=${aws_db_proxy.main.endpoint} \port=5432 \dbname=app_database \user=iam_terraform_user \sslmode=require" \  -c "ALTER TABLE app.users ADD COLUMN IF NOT EXISTS email_verified BOOLEAN DEFAULT FALSE;" EOF  }}

terraform plan による差分可視化

スキーマ変更をGitHubでレビューするワークフロー例です。

# 1. ブランチを切るgit checkout -b feat/add-app-schema-v2# 2. postgresql.tf を変更（例: 新しいロールを追加）# resource "postgresql_role" "app_analytics" { ... }# 3. terraform plan で差分確認terraform plan -out=tfplan.binaryterraform show -json tfplan.binary | jq '.resource_changes[] | {address, action: .change.actions}'# 出力例:# {#"address": "postgresql_role.app_analytics",#"action": ["create"]# }# 4. Pull Requestを作成（terraform plan の出力をPRコメントに貼付）git add postgresql.tfgit commit -m "feat: add app_analytics role for reporting"git push origin feat/add-app-schema-v2# → GitHub PR作成 → レビュー → マージ → terraform apply

Section 7 まとめ

次のSection 8では、Lambda + psycopg2 を使ったDDL実行（CREATE TABLE・CREATE INDEX等）と冪等マイグレーションの実装を解説します。

8. Phase 4: Lambda + psycopg2 で DDL 実行

Phase 3 では Terraform postgresql provider を使い、スキーマ・ロール・権限を IaC で管理しました。しかし Terraform provider が対応していない操作（ALTER TABLE、CREATE INDEX、データ投入、条件付き DDL）は別の手段が必要です。Phase 4 では Lambda 関数 + psycopg2 を使い、IAM 認証経由でこれらの DDL を実行します。

8-1. Lambda + psycopg2 パターンの概要

Terraform postgresql provider では以下の操作を直接管理できません:

これらを Lambda 関数から psycopg2 経由で実行することで、Terraform では管理しにくい操作を補完します。

8-2. psycopg2 Lambda Layer の作成

psycopg2 は C 拡張ライブラリを含むため、Lambda 実行環境（Amazon Linux 2023）に合わせた専用バイナリが必要です。ローカル環境で pip install psycopg2-binary しても Lambda では動作しません。Docker を使ってビルドします。

手順:

① Docker でバイナリをビルド

# 作業ディレクトリ作成mkdir -p lambda-migration/layer/python# Lambda 実行環境（Amazon Linux 2023）と同じコンテナでビルドdocker run --rm \  -v $(pwd)/lambda-migration/layer:/output \  public.ecr.aws/lambda/python:3.12 \  pip install psycopg2-binary -t /output/python/# ビルド結果を確認ls lambda-migration/layer/python/

② ZIP ファイル作成

cd lambda-migration/layerzip -r psycopg2-layer.zip python/cd ../..# ファイルサイズ確認（5〜10 MB 程度）ls -lh lambda-migration/layer/psycopg2-layer.zip

③ Lambda Layer として登録

aws lambda publish-layer-version \  --layer-name psycopg2-aurora \  --zip-file fileb://lambda-migration/layer/psycopg2-layer.zip \  --compatible-runtimes python3.12 \  --region ap-northeast-1

出力例:

{ "LayerVersionArn": "arn:aws:lambda:ap-northeast-1:123456789012:layer:psycopg2-aurora:1", "LayerArn": "arn:aws:lambda:ap-northeast-1:123456789012:layer:psycopg2-aurora", "Version": 1}

LayerVersionArn の値を控えておきます。後続の Lambda 関数作成で使用します。

8-3. Lambda 関数コードの作成

Lambda 関数は以下の役割を担います:

1. IAM 認証トークンを生成（毎回新規生成、15 分間有効）
2. RDS Proxy 経由で Aurora PostgreSQL に接続
3. 未適用のマイグレーションを検出して実行
4. べき等性を確保（schema_migrations テーブルで管理）

関数コード:

ローカルに lambda-migration/lambda_function.py を作成します。

import boto3import psycopg2import osimport logginglogger = logging.getLogger()logger.setLevel(logging.INFO)def get_connection(): """IAM 認証トークンで Aurora に接続（RDS Proxy 経由）""" rds_client = boto3.client('rds', region_name=os.environ['AWS_REGION']) # IAM 認証トークンを生成（毎接続前に新規生成することが重要） token = rds_client.generate_db_auth_token(  DBHostname=os.environ['RDS_PROXY_HOST'],  Port=5432,  DBUsername=os.environ['DB_USER'],  Region=os.environ['AWS_REGION'] ) conn = psycopg2.connect(  host=os.environ['RDS_PROXY_HOST'],  port=5432,  user=os.environ['DB_USER'],  password=token,  database=os.environ['DB_NAME'],  sslmode='require'  # IAM 認証では TLS 必須 ) return conndef lambda_handler(event, context): """べき等なマイグレーション実行ハンドラー""" logger.info("Migration Lambda started") conn = get_connection() try:  with conn.cursor() as cur:# バージョン管理テーブルの作成（べき等: 既存なら何もしない）cur.execute(""" CREATE TABLE IF NOT EXISTS schema_migrations (  version VARCHAR(255) PRIMARY KEY,  applied_at TIMESTAMPTZ DEFAULT NOW(),  applied_by VARCHAR(255) DEFAULT current_user )""")conn.commit()# 未適用マイグレーションの取得と実行migrations = get_pending_migrations(cur)logger.info(f"Pending migrations: {len(migrations)}")for migration in migrations: apply_migration(cur, migration) logger.info(f"Applied migration: {migration['version']}") conn.commit()  # マイグレーションごとにコミット  return {'statusCode': 200,'body': f'Applied {len(migrations)} migrations successfully'  } except Exception as e:  conn.rollback()  logger.error(f"Migration failed: {e}")  raise finally:  conn.close()def get_pending_migrations(cur): """適用済みマイグレーション一覧を取得し、未適用分を返す""" cur.execute("SELECT version FROM schema_migrations") applied = {row[0] for row in cur.fetchall()} logger.info(f"Already applied: {applied}") all_migrations = [  {'version': 'v001_create_users_table','sql': """ CREATE TABLE IF NOT EXISTS app.users (  idUUIDPRIMARY KEY DEFAULT gen_random_uuid(),  emailVARCHAR(255) UNIQUE NOT NULL,  name VARCHAR(255),  created_at TIMESTAMPTZ  DEFAULT NOW(),  updated_at TIMESTAMPTZ  DEFAULT NOW() )"""  },  {'version': 'v002_create_orders_table','sql': """ CREATE TABLE IF NOT EXISTS app.orders (  idUUID  PRIMARY KEY DEFAULT gen_random_uuid(),  user_id UUID  REFERENCES app.users(id) ON DELETE CASCADE,  amount  DECIMAL(10, 2) NOT NULL CHECK (amount >= 0),  status  VARCHAR(50) DEFAULT 'pending',  created_at TIMESTAMPTZ DEFAULT NOW() )"""  },  {'version': 'v003_add_index_users_email','sql': "CREATE INDEX IF NOT EXISTS idx_users_email ON app.users(email)"  },  {'version': 'v004_add_index_orders_user_id','sql': "CREATE INDEX IF NOT EXISTS idx_orders_user_id ON app.orders(user_id)"  },  {'version': 'v005_add_index_orders_created_at','sql': "CREATE INDEX IF NOT EXISTS idx_orders_created_at ON app.orders(created_at DESC)"  }, ] return [m for m in all_migrations if m['version'] not in applied]def apply_migration(cur, migration): """マイグレーションを実行し、バージョンテーブルに記録""" cur.execute(migration['sql']) cur.execute(  """  INSERT INTO schema_migrations (version)  VALUES (%s)  ON CONFLICT (version) DO NOTHING  """,  (migration['version'],) )

8-4. Lambda 関数のデプロイ（コンソール）

① Lambda 関数の ZIP 作成

cd lambda-migrationzip -j migration-function.zip lambda_function.py

② Lambda コンソールで関数を作成

1. AWS マネジメントコンソールで Lambda を開く
2. 「関数の作成」をクリック
3. 「一から作成」を選択し、以下を入力:
4. 関数名: aurora-migration
5. ランタイム: Python 3.12
6. アーキテクチャ: x86_64
7. 「デフォルトの実行ロールの変更」を展開:
8. 「既存のロールを使用する」を選択
9. 既存のロール: aurora-lambda-role（Phase 2 で作成）
10. 「関数の作成」をクリック

③ コードのアップロード

1. 関数の「コード」タブを開く
2. 「アップロード元」→「.zip ファイル」を選択
3. migration-function.zip をアップロード
4. 「保存」をクリック

④ VPC 設定

1. 「設定」タブ→「VPC」を選択
2. 「編集」をクリック
3. 以下を設定:
4. VPC: aurora-db-vpc（Phase 1 で作成）
5. サブネット: プライベートサブネット 2 つ（ap-northeast-1a、ap-northeast-1c）
6. セキュリティグループ: lambda-sg
7. 「保存」をクリック

⑤ 一般設定（タイムアウト変更）

1. 「設定」タブ→「一般設定」→「編集」
2. タイムアウト: 5 分 0 秒（デフォルト 3 秒では不足）
3. メモリ: 256 MB
4. 「保存」をクリック

⑥ 環境変数の設定

1. 「設定」タブ→「環境変数」→「編集」
2. 「環境変数を追加」で以下を設定:

1. 「保存」をクリック

⑦ Layer の追加

1. 「コード」タブの最下部にある「レイヤー」セクションを開く
2. 「レイヤーの追加」をクリック
3. 「カスタムレイヤー」を選択
4. カスタムレイヤー: psycopg2-aurora
5. バージョン: 1（8-2 で登録したもの）
6. 「追加」をクリック

8-5. EventBridge Scheduler での定期実行（任意）

マイグレーション Lambda を定期的に自動実行する場合は、EventBridge Scheduler を使います。べき等性が確保されているため、複数回実行しても問題ありません。

Terraform コード（lambda.tf に追記）:

# EventBridge Scheduler 用 IAM ロールresource "aws_iam_role" "scheduler" {  name = "aurora-migration-scheduler-role"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "scheduler.amazonaws.com" }Action = "sts:AssumeRole" }]  })}resource "aws_iam_role_policy" "scheduler_invoke" {  name = "invoke-migration-lambda"  role = aws_iam_role.scheduler.id  policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect= "Allow"Action= "lambda:InvokeFunction"Resource = aws_lambda_function.migration.arn }]  })}# EventBridge Scheduler（毎日 AM 3:00 に実行）resource "aws_scheduler_schedule" "migration" {  name = "aurora-migration-schedule"  group_name = "default"  flexible_time_window { mode = "OFF"  }  # 毎日 JST 3:00（UTC 18:00）  schedule_expression = "cron(0 18 * * ? *)"  schedule_expression_timezone = "Asia/Tokyo"  target { arn= aws_lambda_function.migration.arn role_arn = aws_iam_role.scheduler.arn  }}

9. Phase 5: 動作確認とトラブルシューティング

Lambda 関数のデプロイが完了したら、動作確認を行います。Terraform apply の確認、Lambda のテスト実行、CloudWatch Logs の確認の順に進めます。

9-1. Terraform apply の動作確認

Phase 3 で作成した Terraform コード（postgresql provider）の適用結果を確認します。

確認コマンド:

# 全リソースの状態確認terraform state list# 出力値の確認terraform output

出力例:

aurora_cluster_endpoint = "aurora-cluster.cluster-xxxx.ap-northeast-1.rds.amazonaws.com"rds_proxy_endpoint= "aurora-proxy.proxy-xxxx.ap-northeast-1.rds.amazonaws.com"

DB 内の状態確認（CloudShell または SSM Port Forwarding 経由）:

-- 作成されたデータベース一覧SELECT datname FROM pg_database WHERE datname = 'app_database';-- スキーマ一覧SELECT schema_name FROM information_schema.schemata WHERE schema_name = 'app';-- ロール一覧（IAM 認証ユーザーを含む）SELECT rolname, rolcanlogin FROM pg_rolesWHERE rolname LIKE '%app%' OR rolname LIKE '%iam%'ORDER BY rolname;-- 権限確認SELECT grantee, table_schema, table_name, privilege_typeFROM information_schema.role_table_grantsWHERE grantee IN ('app_readonly', 'app_readwrite', 'iam_lambda_user')ORDER BY grantee, table_schema, table_name;

期待する出力:

 datname----------- app_database(1 row) schema_name------------- app(1 row) rolname  | rolcanlogin----------------------+------------- app_readonly| t app_readwrite  | t iam_lambda_user| t iam_terraform_user| t(4 rows)

9-2. Lambda 関数のテスト実行

Lambda コンソールからテスト:

1. Lambda コンソールで aurora-migration 関数を開く
2. 「テスト」タブを選択
3. 「テストイベントを作成」:
4. イベント名: migration-test
5. テンプレート: hello-world
6. イベント JSON: {} のまま
7. 「保存」→「テスト」をクリック

初回実行の期待結果:

{  "statusCode": 200,  "body": "Applied 5 migrations successfully"}

2 回目以降（べき等性確認）:

{  "statusCode": 200,  "body": "Applied 0 migrations successfully"}

2 回目以降は全マイグレーションが適用済みとして検出され、0 件の変更で正常終了します。

9-3. CloudWatch Logs での確認

ログの確認手順:

1. Lambda コンソール → 「モニタリング」タブ
2. 「CloudWatch のログを表示」をクリック
3. 最新のログストリームを開く

期待するログ出力（初回）:

INFO Migration Lambda startedINFO Already applied: set()INFO Pending migrations: 5INFO Applied migration: v001_create_users_tableINFO Applied migration: v002_create_orders_tableINFO Applied migration: v003_add_index_users_emailINFO Applied migration: v004_add_index_orders_user_idINFO Applied migration: v005_add_index_orders_created_at

DB でのテーブル確認:

-- マイグレーション適用履歴SELECT version, applied_at, applied_byFROM schema_migrationsORDER BY applied_at;-- テーブル一覧SELECT tablename, tableownerFROM pg_tablesWHERE schemaname = 'app'ORDER BY tablename;-- インデックス一覧SELECT indexname, tablename, indexdefFROM pg_indexesWHERE schemaname = 'app'ORDER BY tablename, indexname;

期待する出力:

  version| applied_at  | applied_by------------------------------------+-------------------------------+-------------- v001_create_users_table| 2026-04-14 09:00:01.123+00 | iam_lambda_user v002_create_orders_table  | 2026-04-14 09:00:01.456+00 | iam_lambda_user v003_add_index_users_email| 2026-04-14 09:00:01.789+00 | iam_lambda_user v004_add_index_orders_user_id| 2026-04-14 09:00:02.012+00 | iam_lambda_user v005_add_index_orders_created_at| 2026-04-14 09:00:02.234+00 | iam_lambda_user(5 rows) tablename | tableowner-----------+-------------- orders | iam_lambda_user users  | iam_lambda_user(2 rows)

9-4. よくあるエラーと対処法

エラー 1: IAM 認証トークン期限切れ

FATAL: PAM authentication failed for user "iam_lambda_user"

原因: IAM 認証トークンの有効期限（15 分）が切れている。Lambda 関数内でトークンをキャッシュしている場合に発生します。

対処法:

# NG: グローバルスコープでトークン生成（期限切れになる）token = rds_client.generate_db_auth_token(...)  # Lambda コンテナ再利用時に15分で無効化# OK: ハンドラー内または接続関数内で毎回生成def get_connection(): token = rds_client.generate_db_auth_token(...)  # 毎回新規生成 return psycopg2.connect(password=token, ...)

エラー 2: セキュリティグループの設定ミス

[Errno 110] Connection timed out

原因: Lambda のセキュリティグループ（lambda-sg）から RDS Proxy のセキュリティグループ（rds-proxy-sg）へのポート 5432 通信が許可されていない。

対処法:

# lambda-sg の ID を確認aws ec2 describe-security-groups \  --filters Name=group-name,Values=lambda-sg \  --query 'SecurityGroups[0].GroupId' \  --output text# rds-proxy-sg の ID を確認aws ec2 describe-security-groups \  --filters Name=group-name,Values=rds-proxy-sg \  --query 'SecurityGroups[0].GroupId' \  --output text# rds-proxy-sg に inbound ルールを追加（lambda-sg からのポート 5432）aws ec2 authorize-security-group-ingress \  --group-id <rds-proxy-sg-id> \  --protocol tcp \  --port 5432 \  --source-group <lambda-sg-id>

エラー 3: RDS Proxy の IAM 認証拒否

SSL connection required for IAM authentication

原因: psycopg2.connect() に sslmode='require' が設定されていない。IAM 認証では TLS が必須です。

対処法: 接続コードに sslmode='require' を追加します。

conn = psycopg2.connect( host=os.environ['RDS_PROXY_HOST'], port=5432, user=os.environ['DB_USER'], password=token, database=os.environ['DB_NAME'], sslmode='require'  # 必須: IAM 認証には TLS が必要)

エラー 4: Terraform postgresql provider 接続エラー

Error: Error connecting to PostgreSQL server  on postgresql.tf line 1, in provider "postgresql":  Configuration for provider "postgresql" is invalid

原因: Terraform 実行環境の IAM ロールに rds-db:connect 権限がない。

対処法:

# Terraform 実行ロールのポリシーを確認aws iam list-attached-role-policies --role-name aurora-terraform-role# 権限がない場合はポリシーをアタッチaws iam attach-role-policy \  --role-name aurora-terraform-role \  --policy-arn arn:aws:iam::{ACCOUNT_ID}:policy/aurora-iam-db-access

aurora-iam-db-access ポリシーの内容（Phase 2 で作成）:

{ "Version": "2012-10-17", "Statement": [{  "Effect": "Allow",  "Action": "rds-db:connect",  "Resource": "arn:aws:rds-db:ap-northeast-1:{ACCOUNT_ID}:dbuser:*/*" }]}

エラー 5: VPC Lambda タイムアウト（STS API 疎通不可）

Task timed out after 300.00 seconds

ログには以下のようなメッセージ:

botocore.exceptions.EndpointConnectionError: Could not connect to the endpoint URL: "https://sts.ap-northeast-1.amazonaws.com/"

原因: VPC 内の Lambda が STS API（IAM 認証トークン生成に必要）に接続できない。NAT Gateway もなく、VPC エンドポイントも未設定の場合に発生します。

対処法: STS 用の VPC エンドポイントを作成します。

# VPC ID を取得VPC_ID=$(aws ec2 describe-vpcs \  --filters Name=tag:Name,Values=aurora-db-vpc \  --query 'Vpcs[0].VpcId' \  --output text)# プライベートサブネット ID を取得SUBNET_IDS=$(aws ec2 describe-subnets \  --filters Name=vpc-id,Values=$VPC_ID Name=tag:Type,Values=private \  --query 'Subnets[*].SubnetId' \  --output text | tr '\t' ',')# STS VPC エンドポイント作成aws ec2 create-vpc-endpoint \  --vpc-id $VPC_ID \  --service-name com.amazonaws.ap-northeast-1.sts \  --vpc-endpoint-type Interface \  --subnet-ids $SUBNET_IDS \  --security-group-ids <lambda-sg-id>

9-5. CloudWatch Metrics でのモニタリング

Lambda + Aurora の動作状態を確認するために、以下のメトリクスを監視します。

Lambda メトリクス（CloudWatch → Lambda → aurora-migration）:

RDS Proxy メトリクス（CloudWatch → RDS → aurora-proxy）:

Aurora メトリクス（CloudWatch → RDS → aurora-cluster）:

9-6. 動作確認完了の確認チェックリスト

Phase 4〜5 の動作確認が完了したら、以下の項目をすべて確認してください。

Terraform postgresql provider（Phase 3）:

• [ ] terraform state list で postgresql_* リソースが表示される
• [ ] app_database データベースが作成されている
• [ ] app スキーマが作成されている
• [ ] app_readonly、app_readwrite、iam_lambda_user、iam_terraform_user ロールが存在する
• [ ] GRANT 権限が正しく設定されている（information_schema.role_table_grants で確認）

Lambda + psycopg2（Phase 4〜5）:

• [ ] Lambda 関数 aurora-migration がデプロイされている
• [ ] VPC 設定（プライベートサブネット + lambda-sg）が正しい
• [ ] 環境変数（RDS_PROXY_HOST、DB_USER、DB_NAME）が設定されている
• [ ] Layer（psycopg2-aurora:1）が追加されている
• [ ] テスト実行で Applied 5 migrations successfully が返る
• [ ] 2 回目のテスト実行で Applied 0 migrations successfully が返る（べき等性）
• [ ] CloudWatch Logs にマイグレーション実行ログが出力されている
• [ ] schema_migrations テーブルに 5 件のレコードが存在する
• [ ] app.users、app.orders テーブルが作成されている
• [ ] インデックスが 3 件作成されている（pg_indexes で確認）

Section 10: Phase 6 — Terraform IaC 全リソース

Section 5〜9のコンソール・手動ハンズオンで構築した全リソースを、Terraform で再現可能な IaC として整理します。terraform apply 一発で Aurora PostgreSQL Serverless v2 + RDS Proxy + IAM認証 + Lambdaマイグレーション環境を構築できます。

10-1. ディレクトリ構成

プロジェクトディレクトリ terraform/ を作成し、以下の構成にします。

terraform/├── providers.tf # Providerバージョン固定 + PostgreSQL Provider設定├── variables.tf # 変数定義├── vpc.tf # ネットワーク基盤（VPC/サブネット/NAT/SG/VPCエンドポイント）├── aurora.tf # Aurora PostgreSQL Serverless v2 + Secrets Manager├── rds_proxy.tf # RDS Proxy（IAM認証 REQUIRED）├── iam.tf # IAMロール/ポリシー（RDS Proxy用・Lambda用・Terraform PG用）├── postgresql.tf# cyrilgdn/postgresql provider（DB/スキーマ/ロール/権限）├── lambda.tf # マイグレーションLambda + psycopg2 Layer + EventBridge Scheduler└── outputs.tf# 出力値

mkdir terraformcd terraform

10-2. providers.tf — Provider設定

terraform {  required_version = ">= 1.5.0"  required_providers { aws = {source  = "hashicorp/aws"version = "~> 5.0" } postgresql = {source  = "cyrilgdn/postgresql"version = "~> 1.26.0" }  }}provider "aws" {  region = var.aws_region}# PostgreSQL Providerは RDS Proxy エンドポイント経由で IAM認証接続# Aurora クラスターが起動済み・RDS Proxyが作成済みの状態で初めて有効になるprovider "postgresql" {  scheme = "awspostgres"  host= aws_db_proxy.main.endpoint  port= 5432  database  = "postgres"  username  = "iam_terraform_user"  superuser = false  aws_rds_iam_auth= true  aws_rds_iam_region = var.aws_region}

10-3. variables.tf — 変数定義

variable "aws_region" {  description = "AWSリージョン"  default  = "ap-northeast-1"}variable "project_name" {  description = "プロジェクト名（リソース名プレフィックス）"  default  = "aurora-no-human-login"}variable "vpc_cidr" {  description = "VPC CIDR ブロック"  default  = "10.0.0.0/16"}variable "db_name" {  description = "Aurora クラスターのデータベース名"  default  = "app_database"}variable "aurora_master_username" {  description = "Aurora マスターユーザー名"  default  = "postgres"  sensitive= true}variable "aurora_master_password" {  description = "Aurora マスターパスワード（terraform.tfvars で管理）"  sensitive= true}

terraform.tfvars（.gitignore に追加すること）:

aurora_master_password = "YourSecurePassword123!"

.gitignore:

*.tfvars*.tfstate*.tfstate.backup.terraform/.terraform.lock.hcl

10-4. vpc.tf — ネットワーク基盤

VPC・サブネット（パブリック×2 / プライベート×2）・NAT Gateway・セキュリティグループ・VPCエンドポイントを定義します。

# ─────────────────────────────────────────# データソース: AZリスト# ─────────────────────────────────────────data "aws_availability_zones" "available" {  state = "available"}# ─────────────────────────────────────────# VPC# ─────────────────────────────────────────resource "aws_vpc" "main" {  cidr_block  = var.vpc_cidr  enable_dns_support= true  enable_dns_hostnames = true  tags = { Name = "${var.project_name}-vpc" Project = var.project_name  }}# ─────────────────────────────────────────# サブネット（パブリック × 2）# ─────────────────────────────────────────resource "aws_subnet" "public_a" {  vpc_id= aws_vpc.main.id  cidr_block  = "10.0.1.0/24"  availability_zone = data.aws_availability_zones.available.names[0]  map_public_ip_on_launch = true  tags = { Name = "${var.project_name}-public-a" Project = var.project_name  }}resource "aws_subnet" "public_c" {  vpc_id= aws_vpc.main.id  cidr_block  = "10.0.2.0/24"  availability_zone = data.aws_availability_zones.available.names[1]  map_public_ip_on_launch = true  tags = { Name = "${var.project_name}-public-c" Project = var.project_name  }}# ─────────────────────────────────────────# サブネット（プライベート × 2）# ─────────────────────────────────────────resource "aws_subnet" "private_a" {  vpc_id= aws_vpc.main.id  cidr_block  = "10.0.10.0/24"  availability_zone = data.aws_availability_zones.available.names[0]  tags = { Name = "${var.project_name}-private-a" Project = var.project_name  }}resource "aws_subnet" "private_c" {  vpc_id= aws_vpc.main.id  cidr_block  = "10.0.11.0/24"  availability_zone = data.aws_availability_zones.available.names[1]  tags = { Name = "${var.project_name}-private-c" Project = var.project_name  }}# ─────────────────────────────────────────# Internet Gateway# ─────────────────────────────────────────resource "aws_internet_gateway" "main" {  vpc_id = aws_vpc.main.id  tags = { Name = "${var.project_name}-igw" Project = var.project_name  }}# ─────────────────────────────────────────# NAT Gateway（パブリックサブネット a に配置）# ─────────────────────────────────────────resource "aws_eip" "nat" {  domain = "vpc"  tags = { Name = "${var.project_name}-nat-eip" Project = var.project_name  }}resource "aws_nat_gateway" "main" {  allocation_id = aws_eip.nat.id  subnet_id  = aws_subnet.public_a.id  tags = { Name = "${var.project_name}-nat" Project = var.project_name  }  depends_on = [aws_internet_gateway.main]}# ─────────────────────────────────────────# ルートテーブル（パブリック）# ─────────────────────────────────────────resource "aws_route_table" "public" {  vpc_id = aws_vpc.main.id  route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.main.id  }  tags = { Name = "${var.project_name}-rt-public" Project = var.project_name  }}resource "aws_route_table_association" "public_a" {  subnet_id= aws_subnet.public_a.id  route_table_id = aws_route_table.public.id}resource "aws_route_table_association" "public_c" {  subnet_id= aws_subnet.public_c.id  route_table_id = aws_route_table.public.id}# ─────────────────────────────────────────# ルートテーブル（プライベート）# ─────────────────────────────────────────resource "aws_route_table" "private" {  vpc_id = aws_vpc.main.id  route { cidr_block  = "0.0.0.0/0" nat_gateway_id = aws_nat_gateway.main.id  }  tags = { Name = "${var.project_name}-rt-private" Project = var.project_name  }}resource "aws_route_table_association" "private_a" {  subnet_id= aws_subnet.private_a.id  route_table_id = aws_route_table.private.id}resource "aws_route_table_association" "private_c" {  subnet_id= aws_subnet.private_c.id  route_table_id = aws_route_table.private.id}# ─────────────────────────────────────────# セキュリティグループ: Aurora# ─────────────────────────────────────────resource "aws_security_group" "aurora" {  name  = "${var.project_name}-aurora-sg"  description = "Aurora PostgreSQL SG — RDS Proxy and Lambda only"  vpc_id= aws_vpc.main.id  tags = { Name = "${var.project_name}-aurora-sg" Project = var.project_name  }}resource "aws_security_group_rule" "aurora_ingress_proxy" {  type= "ingress"  from_port = 5432  to_port= 5432  protocol  = "tcp"  security_group_id  = aws_security_group.aurora.id  source_security_group_id = aws_security_group.rds_proxy.id  description  = "Allow from RDS Proxy"}resource "aws_security_group_rule" "aurora_ingress_lambda" {  type= "ingress"  from_port = 5432  to_port= 5432  protocol  = "tcp"  security_group_id  = aws_security_group.aurora.id  source_security_group_id = aws_security_group.lambda.id  description  = "Allow from Lambda migration"}resource "aws_security_group_rule" "aurora_egress" {  type  = "egress"  from_port= 0  to_port  = 0  protocol = "-1"  cidr_blocks = ["0.0.0.0/0"]  security_group_id = aws_security_group.aurora.id}# ─────────────────────────────────────────# セキュリティグループ: RDS Proxy# ─────────────────────────────────────────resource "aws_security_group" "rds_proxy" {  name  = "${var.project_name}-rds-proxy-sg"  description = "RDS Proxy SG — Lambda and Terraform PG provider"  vpc_id= aws_vpc.main.id  tags = { Name = "${var.project_name}-rds-proxy-sg" Project = var.project_name  }}resource "aws_security_group_rule" "rds_proxy_ingress_lambda" {  type= "ingress"  from_port = 5432  to_port= 5432  protocol  = "tcp"  security_group_id  = aws_security_group.rds_proxy.id  source_security_group_id = aws_security_group.lambda.id  description  = "Allow from Lambda"}resource "aws_security_group_rule" "rds_proxy_egress" {  type  = "egress"  from_port= 0  to_port  = 0  protocol = "-1"  cidr_blocks = ["0.0.0.0/0"]  security_group_id = aws_security_group.rds_proxy.id}# ─────────────────────────────────────────# セキュリティグループ: Lambda# ─────────────────────────────────────────resource "aws_security_group" "lambda" {  name  = "${var.project_name}-lambda-sg"  description = "Lambda migration function SG"  vpc_id= aws_vpc.main.id  tags = { Name = "${var.project_name}-lambda-sg" Project = var.project_name  }}resource "aws_security_group_rule" "lambda_egress" {  type  = "egress"  from_port= 0  to_port  = 0  protocol = "-1"  cidr_blocks = ["0.0.0.0/0"]  security_group_id = aws_security_group.lambda.id}# ─────────────────────────────────────────# VPCエンドポイント: STS（IAM認証トークン生成）# ─────────────────────────────────────────resource "aws_vpc_endpoint" "sts" {  vpc_id  = aws_vpc.main.id  service_name  = "com.amazonaws.${var.aws_region}.sts"  vpc_endpoint_type= "Interface"  subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_c.id]  security_group_ids  = [aws_security_group.lambda.id]  private_dns_enabled = true  tags = { Name = "${var.project_name}-sts-endpoint" Project = var.project_name  }}# ─────────────────────────────────────────# VPCエンドポイント: Secrets Manager# ─────────────────────────────────────────resource "aws_vpc_endpoint" "secretsmanager" {  vpc_id  = aws_vpc.main.id  service_name  = "com.amazonaws.${var.aws_region}.secretsmanager"  vpc_endpoint_type= "Interface"  subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_c.id]  security_group_ids  = [aws_security_group.lambda.id]  private_dns_enabled = true  tags = { Name = "${var.project_name}-sm-endpoint" Project = var.project_name  }}

10-5. aurora.tf — Aurora PostgreSQL Serverless v2

# ─────────────────────────────────────────# DB サブネットグループ# ─────────────────────────────────────────resource "aws_db_subnet_group" "main" {  name = "${var.project_name}-subnet-group"  subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_c.id]  tags = { Name = "${var.project_name}-subnet-group" Project = var.project_name  }}# ─────────────────────────────────────────# Aurora クラスター（Serverless v2）# ─────────────────────────────────────────resource "aws_rds_cluster" "main" {  cluster_identifier= "${var.project_name}-cluster"  engine= "aurora-postgresql"  engine_version = "16.4"  engine_mode = "provisioned"  database_name  = var.db_name  master_username= var.aurora_master_username  master_password= var.aurora_master_password  db_subnet_group_name = aws_db_subnet_group.main.name  vpc_security_group_ids  = [aws_security_group.aurora.id]  skip_final_snapshot  = true  deletion_protection  = false  storage_encrypted = true  # IAM データベース認証を有効化（パスワードレス接続の基盤）  iam_database_authentication_enabled = true  serverlessv2_scaling_configuration { min_capacity = 0.5 max_capacity = 16  }  tags = { Project = var.project_name  }}# ─────────────────────────────────────────# Aurora クラスターインスタンス（Writer）# ─────────────────────────────────────────resource "aws_rds_cluster_instance" "writer" {  cluster_identifier = aws_rds_cluster.main.id  instance_class  = "db.serverless"  engine = aws_rds_cluster.main.engine  engine_version  = aws_rds_cluster.main.engine_version  identifier= "${var.project_name}-writer"  tags = { Project = var.project_name  }}# ─────────────────────────────────────────# Secrets Manager（マスター認証情報）# RDS Proxy が参照するシークレット# ─────────────────────────────────────────resource "aws_secretsmanager_secret" "aurora_master" {  name  = "${var.project_name}/master"  recovery_window_in_days = 0  # ハンズオン用: 即時削除を許可  tags = { Project = var.project_name  }}resource "aws_secretsmanager_secret_version" "aurora_master" {  secret_id = aws_secretsmanager_secret.aurora_master.id  secret_string = jsonencode({ host  = aws_rds_cluster.main.endpoint port  = 5432 username = var.aurora_master_username password = var.aurora_master_password dbname= var.db_name  })}

10-6. rds_proxy.tf — RDS Proxy（IAM認証 REQUIRED）

# ─────────────────────────────────────────# RDS Proxy# ─────────────────────────────────────────resource "aws_db_proxy" "main" {  name = "${var.project_name}-proxy"  debug_logging = false  engine_family = "POSTGRESQL"  idle_client_timeout = 1800  require_tls= true  role_arn= aws_iam_role.rds_proxy.arn  vpc_security_group_ids = [aws_security_group.rds_proxy.id]  vpc_subnet_ids= [aws_subnet.private_a.id, aws_subnet.private_c.id]  auth { auth_scheme = "SECRETS" description = "Aurora master credentials via Secrets Manager" iam_auth = "REQUIRED"  # IAM認証を強制（パスワード直接接続を禁止） secret_arn  = aws_secretsmanager_secret.aurora_master.arn  }  tags = { Project = var.project_name  }  depends_on = [aws_rds_cluster_instance.writer]}# ─────────────────────────────────────────# RDS Proxy デフォルトターゲットグループ# ─────────────────────────────────────────resource "aws_db_proxy_default_target_group" "main" {  db_proxy_name = aws_db_proxy.main.name  connection_pool_config { connection_borrow_timeout = 120 max_connections_percent= 100 max_idle_connections_percent = 50  }}# ─────────────────────────────────────────# RDS Proxy ターゲット（Aurora クラスター）# ─────────────────────────────────────────resource "aws_db_proxy_target" "main" {  db_cluster_identifier = aws_rds_cluster.main.id  db_proxy_name= aws_db_proxy.main.name  target_group_name  = aws_db_proxy_default_target_group.main.name}

10-7. iam.tf — IAMロール / ポリシー

data "aws_caller_identity" "current" {}# ─────────────────────────────────────────# IAMロール: RDS Proxy 用（Secrets Manager読み取り）# ─────────────────────────────────────────resource "aws_iam_role" "rds_proxy" {  name = "${var.project_name}-rds-proxy-role"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "rds.amazonaws.com" }Action = "sts:AssumeRole" }]  })  tags = { Project = var.project_name  }}resource "aws_iam_policy" "rds_proxy_secrets" {  name = "${var.project_name}-rds-proxy-secrets-policy"  policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect= "Allow"Action= ["secretsmanager:GetSecretValue"]Resource = aws_secretsmanager_secret.aurora_master.arn }]  })}resource "aws_iam_role_policy_attachment" "rds_proxy_secrets" {  role = aws_iam_role.rds_proxy.name  policy_arn = aws_iam_policy.rds_proxy_secrets.arn}# ─────────────────────────────────────────# IAMロール: Lambda マイグレーション用# ─────────────────────────────────────────resource "aws_iam_role" "lambda_migration" {  name = "${var.project_name}-lambda-migration-role"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "lambda.amazonaws.com" }Action = "sts:AssumeRole" }]  })  tags = { Project = var.project_name  }}# VPC Lambda 基本実行権限resource "aws_iam_role_policy_attachment" "lambda_vpc_execution" {  role = aws_iam_role.lambda_migration.name  policy_arn = "arn:aws:iam::aws:policy/service-role/AWSLambdaVPCAccessExecutionRole"}# Aurora IAM認証: rds-db:connect 権限resource "aws_iam_policy" "aurora_iam_connect_lambda" {  name = "${var.project_name}-lambda-aurora-connect-policy"  policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Action = ["rds-db:connect"]Resource = [  "arn:aws:rds-db:${var.aws_region}:${data.aws_caller_identity.current.account_id}:dbuser:${aws_rds_cluster.main.cluster_resource_id}/iam_lambda_user"] }]  })}resource "aws_iam_role_policy_attachment" "lambda_aurora_connect" {  role = aws_iam_role.lambda_migration.name  policy_arn = aws_iam_policy.aurora_iam_connect_lambda.arn}# ─────────────────────────────────────────# IAMロール: Terraform postgresql provider 用# terraform apply 実行者のロールに rds-db:connect を付与# ─────────────────────────────────────────resource "aws_iam_policy" "aurora_iam_connect_terraform" {  name = "${var.project_name}-terraform-pg-connect-policy"  policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Action = ["rds-db:connect"]Resource = [  "arn:aws:rds-db:${var.aws_region}:${data.aws_caller_identity.current.account_id}:dbuser:${aws_rds_cluster.main.cluster_resource_id}/iam_terraform_user"] }]  })}# terraform apply 実行ユーザー/ロールにアタッチ# 実際の環境では適切なユーザーまたはロールにアタッチしてくださいresource "aws_iam_role_policy_attachment" "terraform_pg_connect" {  role = aws_iam_role.lambda_migration.name  # 本番では専用ロールを使用  policy_arn = aws_iam_policy.aurora_iam_connect_terraform.arn}

10-8. postgresql.tf — スキーマ / ロール / 権限管理（cyrilgdn/postgresql）

# ─────────────────────────────────────────# データベース作成# ─────────────────────────────────────────resource "postgresql_database" "app_db" {  name  = var.db_name  owner = "postgres"  encoding = "UTF8"  lc_collate  = "en_US.UTF-8"  lc_ctype = "en_US.UTF-8"  connection_limit  = -1  allow_connections = true}# ─────────────────────────────────────────# ロール定義（アプリケーション用）# ─────────────────────────────────────────# オーナーロール（DDL実行・テーブル所有）resource "postgresql_role" "app_owner" {  name = "app_owner"  login= false  inherit = true  connection_limit = -1}# ライタロール（INSERT/UPDATE/DELETE）resource "postgresql_role" "app_writer" {  name = "app_writer"  login= false  inherit = true  connection_limit = -1}# リーダーロール（SELECT のみ）resource "postgresql_role" "app_reader" {  name = "app_reader"  login= false  inherit = true  connection_limit = -1}# IAM認証ユーザー（Lambdaアプリ用）— app_writer を継承resource "postgresql_role" "iam_lambda_user" {  name = "iam_lambda_user"  login= true  inherit = true  connection_limit = 10  roles= [postgresql_role.app_writer.name]}# IAM認証ユーザー（読み取り専用アプリ用）— app_reader を継承resource "postgresql_role" "iam_readonly_user" {  name = "iam_readonly_user"  login= true  inherit = true  connection_limit = 10  roles= [postgresql_role.app_reader.name]}# ─────────────────────────────────────────# スキーマ作成# ─────────────────────────────────────────resource "postgresql_schema" "app" {  name = "app"  owner= postgresql_role.app_owner.name  database= postgresql_database.app_db.name  drop_cascade  = false}# ─────────────────────────────────────────# 権限付与（GRANT）# ─────────────────────────────────────────# app_writer: スキーマ USAGE + CREATEresource "postgresql_grant" "writer_schema" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_writer.name  schema= postgresql_schema.app.name  object_type = "schema"  privileges  = ["USAGE", "CREATE"]}# app_reader: スキーマ USAGEresource "postgresql_grant" "reader_schema" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_reader.name  schema= postgresql_schema.app.name  object_type = "schema"  privileges  = ["USAGE"]}# app_writer: 既存テーブルへの DML 権限resource "postgresql_grant" "writer_tables" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_writer.name  schema= postgresql_schema.app.name  object_type = "table"  privileges  = ["SELECT", "INSERT", "UPDATE", "DELETE"]}# app_reader: 既存テーブルへの SELECT 権限resource "postgresql_grant" "reader_tables" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_reader.name  schema= postgresql_schema.app.name  object_type = "table"  privileges  = ["SELECT"]}# app_writer: シーケンスへの権限（SERIAL/BIGSERIAL カラム用）resource "postgresql_grant" "writer_sequences" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_writer.name  schema= postgresql_schema.app.name  object_type = "sequence"  privileges  = ["USAGE", "SELECT", "UPDATE"]}# ─────────────────────────────────────────# デフォルト権限（将来作成されるオブジェクトへの自動付与）# ─────────────────────────────────────────# app_owner が作成したテーブルを app_writer が自動で DML 可能resource "postgresql_default_privileges" "writer_tables" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_writer.name  owner = postgresql_role.app_owner.name  schema= postgresql_schema.app.name  object_type = "table"  privileges  = ["SELECT", "INSERT", "UPDATE", "DELETE"]}# app_owner が作成したテーブルを app_reader が自動で SELECT 可能resource "postgresql_default_privileges" "reader_tables" {  database = postgresql_database.app_db.name  role  = postgresql_role.app_reader.name  owner = postgresql_role.app_owner.name  schema= postgresql_schema.app.name  object_type = "table"  privileges  = ["SELECT"]}# ─────────────────────────────────────────# 拡張機能（Extension）# ─────────────────────────────────────────resource "postgresql_extension" "uuid_ossp" {  name  = "uuid-ossp"  database = postgresql_database.app_db.name  schema= "public"}resource "postgresql_extension" "pgcrypto" {  name  = "pgcrypto"  database = postgresql_database.app_db.name  schema= "public"}

10-9. lambda.tf — マイグレーション Lambda

# ─────────────────────────────────────────# Lambda レイヤー: psycopg2# ─────────────────────────────────────────# 事前にビルドしたpsycopg2のzipを lambda_layer/ に配置してください# ビルド方法: Section 8-2 参照data "archive_file" "psycopg2_layer" {  type  = "zip"  source_dir  = "${path.module}/../lambda_layer/psycopg2"  output_path = "${path.module}/.terraform/psycopg2_layer.zip"}resource "aws_lambda_layer_version" "psycopg2" {  layer_name = "${var.project_name}-psycopg2"  filename= data.archive_file.psycopg2_layer.output_path  source_code_hash = data.archive_file.psycopg2_layer.output_base64sha256  compatible_runtimes = ["python3.12"]  description= "psycopg2-binary for PostgreSQL connection"}# ─────────────────────────────────────────# Lambda 関数コードのアーカイブ# ─────────────────────────────────────────data "archive_file" "lambda" {  type  = "zip"  source_dir  = "${path.module}/../lambda_src"  output_path = "${path.module}/.terraform/lambda_migration.zip"}# ─────────────────────────────────────────# Lambda 関数: マイグレーション# ─────────────────────────────────────────resource "aws_lambda_function" "migration" {  function_name = "${var.project_name}-migration"  role = aws_iam_role.lambda_migration.arn  filename= data.archive_file.lambda.output_path  source_code_hash = data.archive_file.lambda.output_base64sha256  handler = "migration.lambda_handler"  runtime = "python3.12"  timeout = 300  memory_size= 256  layers  = [aws_lambda_layer_version.psycopg2.arn]  vpc_config { subnet_ids= [aws_subnet.private_a.id, aws_subnet.private_c.id] security_group_ids = [aws_security_group.lambda.id]  }  environment { variables = {RDS_PROXY_HOST = aws_db_proxy.main.endpointDB_USER  = "iam_lambda_user"DB_NAME  = var.db_nameAWS_REGION_NAME = var.aws_region }  }  tags = { Project = var.project_name  }  depends_on = [ aws_iam_role_policy_attachment.lambda_vpc_execution, aws_iam_role_policy_attachment.lambda_aurora_connect,  ]}# ─────────────────────────────────────────# EventBridge Scheduler: 定期マイグレーション# ─────────────────────────────────────────resource "aws_iam_role" "scheduler" {  name = "${var.project_name}-scheduler-role"  assume_role_policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect = "Allow"Principal = { Service = "scheduler.amazonaws.com" }Action = "sts:AssumeRole" }]  })}resource "aws_iam_role_policy" "scheduler_lambda" {  name = "invoke-migration-lambda"  role = aws_iam_role.scheduler.id  policy = jsonencode({ Version = "2012-10-17" Statement = [{Effect= "Allow"Action= ["lambda:InvokeFunction"]Resource = aws_lambda_function.migration.arn }]  })}resource "aws_scheduler_schedule" "migration_trigger" {  name = "${var.project_name}-migration-schedule"  schedule_expression = "rate(1 day)"  schedule_expression_timezone = "Asia/Tokyo"  flexible_time_window { mode = "OFF"  }  target { arn= aws_lambda_function.migration.arn role_arn = aws_iam_role.scheduler.arn input = jsonencode({action = "migrate" })  }}

10-10. outputs.tf — 出力値

output "aurora_writer_endpoint" {  description = "Aurora クラスター Writer エンドポイント"  value = aws_rds_cluster.main.endpoint}output "aurora_reader_endpoint" {  description = "Aurora クラスター Reader エンドポイント"  value = aws_rds_cluster.main.reader_endpoint}output "aurora_cluster_resource_id" {  description = "Aurora クラスターリソースID（IAMポリシーで使用）"  value = aws_rds_cluster.main.cluster_resource_id}output "rds_proxy_endpoint" {  description = "RDS Proxy エンドポイント（アプリケーション接続先）"  value = aws_db_proxy.main.endpoint}output "migration_lambda_arn" {  description = "マイグレーション Lambda ARN"  value = aws_lambda_function.migration.arn}output "migration_lambda_name" {  description = "マイグレーション Lambda 関数名"  value = aws_lambda_function.migration.function_name}output "secrets_manager_arn" {  description = "Aurora マスター認証情報 Secrets Manager ARN"  value = aws_secretsmanager_secret.aurora_master.arn}

10-11. デプロイ手順

Aurora クラスターと cyrilgdn/postgresql provider の依存関係があるため、2段階で適用します。

Phase A: AWS インフラ基盤の構築

cd terraform/# 初期化（プロバイダーのダウンロード）terraform init# プラン確認（postgresql リソースを除外）terraform plan \  -var="aurora_master_password=YourSecurePassword123!" \  -target=aws_vpc.main \  -target=aws_rds_cluster.main \  -target=aws_rds_cluster_instance.writer \  -target=aws_db_proxy.main \  -target=aws_lambda_function.migration# 適用（VPC/Aurora/RDS Proxy/Lambda）terraform apply \  -var="aurora_master_password=YourSecurePassword123!" \  -target=aws_vpc.main \  -target=aws_rds_cluster.main \  -target=aws_rds_cluster_instance.writer \  -target=aws_db_proxy.main \  -target=aws_lambda_function.migration

Phase B: postgresql provider でスキーマ適用

# IAM認証ユーザーを事前に作成（Section 6 の手順）# その後、postgresql リソースを適用terraform apply -var="aurora_master_password=YourSecurePassword123!"

全リソース削除

terraform destroy -var="aurora_master_password=YourSecurePassword123!"

Section 11: 他の方法（概要解説）

本記事のメインハンズオンでは Terraform postgresql provider + IAM認証 + RDS Proxy を採用しましたが、実際の運用では要件に応じて複数の方法を組み合わせるケースもあります。以下に代表的な4つの方法を概説します。

11-1. RDS Data API — VPC接続不要のSQL実行

概要: HTTPS経由でSQLを実行できるマネージドAPIです。Lambda関数やCI/CDパイプラインからVPC設定なしでAuroraにアクセスできます。

アーキテクチャ:

クライアント（Lambda / CI/CD / コンソール） ↓ HTTPS + IAM認証（rds-data:ExecuteStatement）RDS Data API エンドポイント ↓Aurora PostgreSQL

AWSコンソール（Query Editor）での使用方法:

1. RDS コンソール → クラスター選択 → 「クエリエディター」タブ
2. データベースに接続（シークレット選択 or パスワード入力）
3. SQLを直接入力・実行

AWS CLI での実行例:

aws rds-data execute-statement \  --resource-arn "arn:aws:rds:ap-northeast-1:123456789:cluster:aurora-cluster" \  --secret-arn "arn:aws:secretsmanager:ap-northeast-1:123456789:secret:aurora/master" \  --database "app_database" \  --sql "SELECT table_name FROM information_schema.tables WHERE table_schema = 'app'"

Terraform連携 (null_resource + local-exec):

resource "null_resource" "create_schema_via_data_api" {  triggers = { schema_version = "v1"  }  provisioner "local-exec" { command = <<-EOFaws rds-data execute-statement \  --resource-arn "${aws_rds_cluster.main.arn}" \  --secret-arn "${aws_secretsmanager_secret.aurora_master.arn}" \  --database "${var.db_name}" \  --sql "CREATE SCHEMA IF NOT EXISTS app" EOF  }  depends_on = [aws_rds_cluster_instance.writer]}

主な制約:

推奨ユースケース: 開発・デバッグ用のad-hocクエリ、VPC外からの軽量DDL実行

11-2. Flyway on CodeBuild — バージョン管理マイグレーション

概要: Javaベースのマイグレーションツール「Flyway」をAWS CodeBuild上で実行し、SQL スクリプトをバージョン管理します。V001__init.sql, V002__add_index.sql のように連番管理されたスクリプトを順番に実行します。

アーキテクチャ:

GitHub / CodeCommit ↓ PushCodePipeline ↓ Source StageCodeBuild（Flyway Docker イメージ） ├─ Secrets Manager から認証情報取得 └─ Aurora PostgreSQL（VPC内）  ↓ V001, V002, ... を順番に適用

buildspec.yml の例:

version: 0.2phases:  pre_build: commands:- DB_HOST=$(aws secretsmanager get-secret-value --secret-id aurora-no-human-login/master --query SecretString --output text | jq -r .host)- DB_PASS=$(aws secretsmanager get-secret-value --secret-id aurora-no-human-login/master --query SecretString --output text | jq -r .password)  build: commands:- |  docker run --rm \ -v $(pwd)/migrations:/flyway/sql \ flyway/flyway:10 \ -url="jdbc:postgresql://${DB_HOST}:5432/app_database" \ -user=postgres \ -password="${DB_PASS}" \ migrate

メリット / デメリット:

参考: AWS公式ブログ — Automate database object deployments in Amazon Aurora using AWS CodePipeline

11-3. SSM Session Manager Port Forwarding — 開発者のad-hocアクセス

概要: AWS Systems Manager Session Manager を使って、踏み台サーバー（Bastion）なしに開発者のローカルマシンからAurora PostgreSQLへ接続します。EC2インスタンスをSSMエージェント経由で中継します。

接続コマンド:

# ローカルポート 15432 → Aurora エンドポイント:5432 へ転送aws ssm start-session \  --target i-xxxxxxxxxxxxxxxxx \  --document-name AWS-StartPortForwardingSessionToRemoteHost \  --parameters '{ "host": ["aurora-no-human-login-cluster.cluster-xxxxxx.ap-northeast-1.rds.amazonaws.com"], "portNumber": ["5432"], "localPortNumber": ["15432"]  }'

別ターミナルから接続:

# psql で接続psql -h localhost -p 15432 -U postgres -d app_database# pgAdmin や TablePlus の接続先# Host: localhost# Port: 15432# Database: app_database

必要条件:

• EC2インスタンスに SSM エージェントがインストール済み（Amazon Linux 2023はデフォルトでインストール）
• EC2に AmazonSSMManagedInstanceCore ポリシーをアタッチ
• 開発者ローカルに AWS CLI + Session Manager Plugin インストール

# Session Manager Plugin のインストール（macOS）brew install --cask session-manager-plugin

推奨ユースケース: 開発者のデータ確認・デバッグ・スキーマ変更のテスト。自動化ワークフローには不向き。

11-4. GitHub Actions OIDC連携 — CI/CDパイプラインからのパスワードレス接続

概要: GitHub Actions の OIDC（OpenID Connect）を使ってAWS IAMロールを一時的に引き受け、generate-db-auth-token でAurora IAM認証トークンを生成してDB操作を実行します。シークレットのローテーション不要でセキュリティを維持できます。

GitHub Actions ワークフロー例:

name: DB Migrationon:  push: branches: [main] paths:- 'migrations/**'permissions:  id-token: write  contents: readjobs:  migrate: runs-on: ubuntu-latest steps:- uses: actions/checkout@v4- name: Configure AWS Credentials（OIDC）  uses: aws-actions/configure-aws-credentials@v4  with: role-to-assume: arn:aws:iam::123456789012:role/github-actions-aurora-role aws-region: ap-northeast-1- name: Generate RDS Auth Token  id: token  run: | TOKEN=$(aws rds generate-db-auth-token \--hostname ${{ vars.RDS_PROXY_ENDPOINT }} \--port 5432 \--username iam_lambda_user \--region ap-northeast-1) echo "token=${TOKEN}" >> $GITHUB_OUTPUT- name: Run DB Migration  env: PGPASSWORD: ${{ steps.token.outputs.token }} PGSSLMODE: require  run: | psql \-h ${{ vars.RDS_PROXY_ENDPOINT }} \-U iam_lambda_user \-d app_database \-f migrations/V$(date +%Y%m%d)__migration.sql

IAMロール信頼ポリシー（GitHub Actions OIDC用）:

{  "Version": "2012-10-17",  "Statement": [{ "Effect": "Allow", "Principal": {"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": {"StringEquals": {  "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"},"StringLike": {  "token.actions.githubusercontent.com:sub": "repo:your-org/your-repo:ref:refs/heads/main"} }  }]}

メリット:
– GitHub Secretsにパスワードを保存不要
– IAM認証トークンは15分で自動失効（漏洩リスク低）
– GitHub Actions の OIDC は追加費用なし

Section 12: クリーンアップ

ハンズオン終了後は不要なリソースを削除してください。Aurora Serverless v2 は起動中のインスタンスに対して時間課金が発生します。

12-1. Terraform で構築したリソースの削除

Terraform で構築した場合は terraform destroy で一括削除できます。依存関係は自動解決されます。

削除前の確認（dry-run）

cd terraform/terraform plan -destroy -var="aurora_master_password=YourSecurePassword123!"

Plan: 0 to add, 0 to change, 38 to destroy.  # aws_db_proxy.main will be destroyed  # aws_lambda_function.migration will be destroyed  # aws_rds_cluster.main will be destroyed  # aws_rds_cluster_instance.writer will be destroyed  # aws_secretsmanager_secret.aurora_master will be destroyed  # ...

削除の実行

terraform destroy -var="aurora_master_password=YourSecurePassword123!"

確認プロンプトで yes を入力してください。

12-2. コンソールで構築したリソースの手動削除

コンソールハンズオン（Section 5〜6）で手動作成したリソースは以下の順序で削除します。

削除順序（依存関係を考慮）:

12-3. 部分削除（特定リソースのみ）

Terraform での部分削除は -target オプションで対象リソースを指定します。

# RDS Proxy のみ削除（コスト削減 + Aurora は残す場合）terraform destroy \  -var="aurora_master_password=YourSecurePassword123!" \  -target=aws_db_proxy.main \  -target=aws_db_proxy_default_target_group.main \  -target=aws_db_proxy_target.main

Section 13: まとめ

13-1. 本記事で実現したこと

本記事では「人間がログインしないDB管理」をコンセプトに、Aurora PostgreSQL の完全 IaC 化・パスワードレス化を実現しました。

構築したアーキテクチャのポイント:

13-2. 手法選定フローチャート

運用シナリオに合わせた手法の選び方：

13-3. セキュリティのベストプラクティス

本記事を通じて実践したセキュリティ原則：

最小権限の原則:
– Lambda には iam_lambda_user のみの rds-db:connect 権限
– リーダーには app_reader ロール（SELECT のみ）
– ライターには app_writer ロール（DML のみ、DDL不可）

パスワードレス化:
– RDS Proxy の iam_auth = "REQUIRED" でパスワード直接接続を禁止
– IAM認証トークンは15分で自動失効

暗号化:
– storage_encrypted = true（KMSによる保存データの暗号化）
– require_tls = true（転送データの暗号化）

13-4. 応用と次のステップ

マルチアカウント構成:
– Resource Access Manager（RAM）でサブネットを共有
– IAM ロールの cross-account trust で別アカウントの Lambda からアクセス

Blue/Green デプロイメント:
– Aurora Blue/Green Deployments でゼロダウンタイムのメジャーバージョンアップ
– Terraform で aws_rds_cluster_blue_green_update ブロックを使用（AWS Provider 5.x）

Flyway 統合:
– Terraform で基盤を構築し、アプリケーション層のマイグレーションは Flyway に委譲
– null_resource + local-exec で terraform apply 後に自動的に Flyway を実行

関連記事: Terraform基礎 — AWS IaC入門ハンズオン ▶

13-5. シリーズリンク

本記事は「AWS ハンズオン TechBlog」の Aurora PostgreSQL 完全ガイドです。

関連シリーズ:
– AWS Step Functions 入門 — コンソールとTerraformで学ぶハンズオン
– ECS × Step Functions 入門 — CSVバッチをFargateタスクでジョブ化するハンズオン
– Step Functions エラーハンドリング完全ガイド
– Step Functions 入出力データフロー制御完全ガイド
– Step Functions Callbackパターン完全ガイド
– Step Functions Distributed Map完全ガイド
– Terraform基礎 — AWS IaC入門ハンズオン

Section 14: 参考リンク

AWS 公式ドキュメント

• Aurora PostgreSQL での IAM データベース認証
• Amazon RDS Proxy ユーザーガイド
• Aurora Serverless v2 スケーリング設定
• RDS Data API の使用
• AWS Secrets Manager でのシークレット管理
• SSM Session Manager ポートフォワーディング
• EventBridge Scheduler — Terraform Lambda スケジュール

Terraform Registry

• cyrilgdn/postgresql Provider ドキュメント
• hashicorp/aws — aws_db_proxy リソース
• hashicorp/aws — aws_rds_cluster リソース
• hashicorp/aws — aws_lambda_function リソース
• hashicorp/aws — aws_scheduler_schedule リソース

AWS 公式ブログ

• Automate database object deployments in Amazon Aurora using AWS CodePipeline
• Automate schema version control and migration with Flyway and AWS Lambda on Amazon Aurora PostgreSQL
• Use IAM authentication to connect with pgAdmin to Amazon Aurora PostgreSQL
• Integrating GitHub Actions OIDC with AWS
• Amazon Aurora PostgreSQL — Express Configuration でIAM認証のデフォルト有効化（2025年発表）

GitHub / コミュニティ

• cyrilgdn/terraform-provider-postgresql（GitHub）
• psycopg2 Lambda Layer ビルドスクリプト例
• Flyway コミュニティ版（GitHub）