【2026年版】Aurora PostgreSQL 実践チートシート ― クラスター作成直後にやる確認SQL・スキーマ設計・接続・設定まとめ

はじめに

Aurora PostgreSQL でクラスターを立てるたびに「あれ、最初に何を確認するんだっけ」「このパラメータはクラスター側？インスタンス側？」と毎回ググっている人向けの 逆引き＋コピペチートシート です。

製造業向けの小規模案件で何度も同じ初期構築をやってきた経験から、「クラスター作成直後に流す確認SQL」「最低限やっておくと後で泣かない設定」をまとめました。

検証環境: Aurora PostgreSQL 18.3 / 17系（2026年6月時点の最新）、リージョンは Tokyo (ap-northeast-1) を想定。

注意（バージョン）

• 最新メジャー: PostgreSQL 18（Aurora 18.3、2026年6月提供開始）
• 標準サポート対象メジャー: 14 / 15 / 16 / 17 / 18
• PostgreSQL 13 は 2026年2月28日に標準サポート終了（EOL）。延長サポート（有償）対象です。新規構築は 16 以上、できれば 17/18 を推奨。

---

1. まずバージョンとサポート状況を確認する

SQLで確認

-- PostgreSQLエンジンの完全なバージョン文字列
SELECT version();

-- 数値だけ欲しいとき（例: 180003）
SHOW server_version_num;

-- Aurora固有バージョン（パッチ含む）
SELECT aurora_version();

AWS CLIで利用可能バージョンを確認

# Tokyoリージョンで使えるAuroraPostgreSQLのエンジンバージョン一覧
aws rds describe-db-engine-versions \
  --engine aurora-postgresql \
  --region ap-northeast-1 \
  --query 'DBEngineVersions[].EngineVersion' \
  --output table

PG18の主な強化点（記事を書く時点でのトピック）:

• B-tree skip scan: 複合インデックスの先頭列を省いた検索でもインデックスが効きやすくなり、冗長なインデックスを減らせる
• メジャーバージョンアップグレード時に optimizer統計を保持 → アップグレード直後の性能劣化（再ANALYZE待ち）を回避
• 論理レプリケーションの大規模トランザクション並列ストリーミング → レプリ遅延の低減
• uuidv7() 関数の追加（時系列でソート可能なUUID）
• pg_roaringbitmap 拡張のサポート（大量整数の集合演算が高速）

---

2. 接続方法

2-1. エンドポイントの種類を理解する

Auroraには複数のエンドポイントがあります。混同すると「書き込みがレプリカに飛んで失敗」などが起きます。

エンドポイント	用途	接続先
クラスターエンドポイント（ライター）	読み書き	常に現在のプライマリ
リーダーエンドポイント	読み取り専用	リードレプリカに自動分散
インスタンスエンドポイント	特定インスタンス直結	個別インスタンス（基本使わない）
カスタムエンドポイント	任意グループ	自分で定義したインスタンス群

アプリは原則 ライター＝クラスターエンドポイント / 参照系＝リーダーエンドポイント に分けます。

2-2. psql での基本接続

# 環境変数で渡す（履歴にパスワードを残さない）
export PGHOST="mycluster.cluster-xxxxxxxx.ap-northeast-1.rds.amazonaws.com"
export PGPORT=5432
export PGDATABASE="appdb"
export PGUSER="app_user"

# パスワードは ~/.pgpass に置くのが安全
# ~/.pgpass の中身: hostname:port:database:username:password
chmod 600 ~/.pgpass

psql

2-3. SSL/TLS を必須にする

Auroraは証明書を提供しています。本番では sslmode=verify-full を推奨。

# AWSのCA証明書を取得（グローバルバンドル）
curl -o ~/rds-global-bundle.pem \
  https://truststore.pki.rds.amazonaws.com/global/global-bundle.pem

psql "host=$PGHOST port=5432 dbname=appdb user=app_user \
  sslmode=verify-full sslrootcert=$HOME/rds-global-bundle.pem"

-- 接続が暗号化されているか確認
SELECT ssl, version, cipher
FROM pg_stat_ssl
WHERE pid = pg_backend_pid();

2-4. IAM認証で接続（パスワードレス）

パスワード管理をなくしたい場合。トークンは15分有効です。

-- DBユーザーにIAM認証を許可
CREATE USER iam_user WITH LOGIN;
GRANT rds_iam TO iam_user;

# 認証トークンを生成して接続
export PGPASSWORD="$(aws rds generate-db-auth-token \
  --hostname $PGHOST \
  --port 5432 \
  --region ap-northeast-1 \
  --username iam_user)"

psql "host=$PGHOST port=5432 dbname=appdb user=iam_user \
  sslmode=verify-full sslrootcert=$HOME/rds-global-bundle.pem"

2-5. RDS Proxy（コネクションプーリング）

Lambdaなど大量・短命接続が前提のワークロードでは RDS Proxy を挟むと接続枯渇を防げます。アプリからはProxyのエンドポイントに接続するだけで、Secrets Manager経由の認証・フェイルオーバー高速化のメリットがあります。

---

3. クラスター作成直後に流す「確認SQL」一式

新規クラスターを作ったら、まずこのセットを流して状態を把握します。コピペ用にまとめました。

3-1. 基本情報

-- 現在の接続情報
SELECT
  current_database()    AS database,
  current_user          AS user,
  inet_server_addr()    AS server_ip,
  inet_server_port()    AS port,
  version()             AS version;

-- ライターかリーダーか（tならリードレプリカ）
SELECT pg_is_in_recovery();

-- タイムゾーン（AuroraデフォルトはUTC。アプリ要件次第で確認）
SHOW timezone;
SELECT now();

3-2. ロケール・エンコーディング（日本語環境で超重要）

-- データベースのエンコーディングと照合順序を一覧
SELECT
  datname,
  pg_encoding_to_char(encoding) AS encoding,
  datcollate,
  datctype
FROM pg_database
ORDER BY datname;

ここで template1 / template0 の datcollate が C や en_US.UTF-8 になっていると、そこから作ったDBも英語ロケールを引き継ぎ、日本語のソート順や LOWER() 等で意図しない挙動になります。詳細は後述の「日本語DB再作成」を参照。

3-3. データベース／スキーマ／ロールの棚卸し

-- データベース一覧（サイズ付き）
SELECT
  datname,
  pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database
WHERE datistemplate = false
ORDER BY pg_database_size(datname) DESC;

-- スキーマ一覧
SELECT schema_name
FROM information_schema.schemata
ORDER BY schema_name;

-- ロール一覧（権限属性付き）
SELECT
  rolname,
  rolsuper,
  rolcreatedb,
  rolcreaterole,
  rolcanlogin,
  rolconnlimit
FROM pg_roles
ORDER BY rolname;

3-4. インストール済み・利用可能な拡張機能

-- 既に有効な拡張
SELECT extname, extversion FROM pg_extension ORDER BY extname;

-- 利用可能な拡張（Auroraがサポートするもの）
SELECT name, default_version, installed_version, comment
FROM pg_available_extensions
ORDER BY name;

3-5. パラメータの実効値確認

-- よく見るパラメータをまとめて
SELECT name, setting, unit, source, context
FROM pg_settings
WHERE name IN (
  'max_connections',
  'shared_buffers',
  'work_mem',
  'maintenance_work_mem',
  'effective_cache_size',
  'rds.force_ssl',
  'log_statement',
  'log_min_duration_statement',
  'shared_preload_libraries',
  'timezone'
)
ORDER BY name;

source 列が default のままなら未調整、source=...auto.conf や database ならパラメータグループ／個別設定で上書き済み、と判別できます。

---

4. データベース・スキーマ・ロール設計

4-1. 役割分担の基本形

Auroraのマスターユーザーは万能ではなく rds_superuser（一部制限あり）です。本番ではマスターを直接アプリに使わず、用途別ロールを切ります。

-- 所有者ロール（オブジェクトの持ち主。ログインしない）
CREATE ROLE app_owner NOLOGIN;

-- アプリ実行ユーザー（読み書き）
CREATE ROLE app_rw LOGIN PASSWORD 'xxxx';

-- 参照専用ユーザー（BI・分析用）
CREATE ROLE app_ro LOGIN PASSWORD 'xxxx';

-- データベースを所有者ロール持ちで作成
CREATE DATABASE appdb OWNER app_owner;

4-2. スキーマと権限のテンプレート

public スキーマにそのまま作らず、専用スキーマを切るのが安全です（PG15以降 public への作成権限はデフォルトで絞られています）。

\c appdb

-- 専用スキーマ
CREATE SCHEMA app AUTHORIZATION app_owner;

-- 読み書きユーザーへ権限付与
GRANT USAGE ON SCHEMA app TO app_rw;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA app TO app_rw;
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA app TO app_rw;

-- 参照専用ユーザーへ
GRANT USAGE ON SCHEMA app TO app_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA app TO app_ro;

-- 今後 app_owner が作る新規テーブルにも自動で権限が乗るように
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO app_rw;
ALTER DEFAULT PRIVILEGES FOR ROLE app_owner IN SCHEMA app
  GRANT SELECT ON TABLES TO app_ro;

-- search_path をスキーマに向ける（DB単位の既定値）
ALTER DATABASE appdb SET search_path TO app, public;

ALTER DEFAULT PRIVILEGES を最初に仕込んでおくと、後からテーブルを追加するたびに GRANT し直す手間が消えます。ここを最初にやるかどうかで運用の楽さが段違いです。

---

5. 日本語環境：ロケール／照合順序とDB再作成

製造業の業務データは日本語のソート・比較が絡むので、ロケールは構築時に決め切るべきポイントです。

5-1. 問題

Auroraのデフォルトテンプレートが英語ロケールだと、CREATE DATABASE した新DBもそれを継承し、後からロケールだけ変えることはできません（DBの再作成が必要）。

5-2. ja_JP.UTF-8 でDBを作り直す

-- 既存DBを ja_JP ロケールで作り直す例
-- ※ template0 から作るのがポイント（template1の汚染を避ける）
CREATE DATABASE appdb_ja
  WITH
    OWNER = app_owner
    ENCODING = 'UTF8'
    LC_COLLATE = 'ja_JP.UTF-8'
    LC_CTYPE   = 'ja_JP.UTF-8'
    TEMPLATE = template0;

5-3. PG15以降は ICU照合順序という選択肢も

OSロケールに依存しない ICU プロバイダーを使うと、ロケール定義の差異に振り回されにくくなります。

-- ICUを使った照合（PG15+）
CREATE DATABASE appdb_icu
  WITH
    OWNER = app_owner
    ENCODING = 'UTF8'
    LOCALE_PROVIDER = 'icu'
    ICU_LOCALE = 'ja-JP'
    TEMPLATE = template0;

どちらを採るかは要件次第ですが、新規なら ICU を検討しておくと将来のマイグレーションが楽になりがちです。

---

6. パラメータグループ：クラスター vs インスタンス

ここが Aurora 初学者が一番ハマる所です。パラメータには クラスターレベル と インスタンスレベル の2種類があり、設定する場所を間違えると反映されません。

6-1. 使い分けの原則

パラメータグループ	適用範囲	代表的なパラメータ
DBクラスターパラメータグループ	クラスター全体（全インスタンス共通）	rds.force_ssl, timezone, shared_preload_libraries, rds.logical_replication, 監査(pgaudit)系
DBパラメータグループ（インスタンス）	個々のインスタンス	shared_buffers, work_mem, max_connections などメモリ・接続系の一部

ざっくり: 「全体で揃える系・ログ/監査系」はクラスター、「インスタンスのスペックに応じて調整する系」はインスタンス、と覚えると外しにくいです。
ただし境界が紛らわしいものもあるので、実機で pg_settings の context（static=再起動要 / dynamic=即時）を見て確認するのが確実。

6-2. apply_method の罠

shared_preload_libraries のような context = static のパラメータは pending-reboot で適用 → インスタンス再起動が必須です。マネコンやCLIで変えただけでは効きません。

# CLI例: クラスターパラメータを変更
aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name my-cluster-pg \
  --parameters "ParameterName=rds.force_ssl,ParameterValue=1,ApplyMethod=pending-reboot" \
  --region ap-northeast-1

変更後は再起動して、SQL側で source と setting を確認するまでが一連の流れです。

---

7. 拡張機能（Extension）のセットアップ

7-1. shared_preload_libraries に積むもの

pgaudit / pg_stat_statements などは クラスターパラメータグループの shared_preload_libraries に追加してから再起動が必要です。

# クラスターパラメータグループでの設定値（カンマ区切り）
shared_preload_libraries = pg_stat_statements,pgaudit

再起動後にDB側で有効化:

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
CREATE EXTENSION IF NOT EXISTS pgaudit;

7-2. pgaudit（監査ログ）

監査要件がある案件では必須。クラスターパラメータで何を記録するか定義します。

# クラスターパラメータグループ
pgaudit.log = ddl,write          # DDLと書き込みを記録（read を足すと参照も）
pgaudit.log_relation = 1
pgaudit.role = rds_pgaudit       # 監査用ロール

-- 監査用ロールを作成（pgaudit.role と一致させる）
CREATE ROLE rds_pgaudit;

監査ログはRDSのログ → CloudWatch Logsへエクスポートして集約します。

7-3. よく使う拡張

-- UUID生成（PG18なら uuidv7() がコア関数で使える）
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

-- ベクトル検索（AI/RAG用途）。PG17時点で pgvector 0.8.0
CREATE EXTENSION IF NOT EXISTS vector;

-- 地理空間
CREATE EXTENSION IF NOT EXISTS postgis;

-- あいまい検索・トライグラム
CREATE EXTENSION IF NOT EXISTS pg_trgm;

---

8. 運用・監視の確認SQL

日々の調査で使う逆引きSQL集です。

8-1. 接続状況

-- 状態別の接続数
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state
ORDER BY count(*) DESC;

-- max_connections に対する使用率
SELECT
  (SELECT count(*) FROM pg_stat_activity) AS used,
  setting::int AS max,
  round(100.0 * (SELECT count(*) FROM pg_stat_activity) / setting::int, 1) AS pct
FROM pg_settings WHERE name = 'max_connections';

8-2. 重いクエリ・遅いクエリ

-- 5秒以上実行中のクエリ
SELECT
  pid,
  now() - query_start AS duration,
  state,
  left(query, 100) AS query
FROM pg_stat_activity
WHERE state <> 'idle'
  AND now() - query_start > interval '5 seconds'
ORDER BY duration DESC;

-- pg_stat_statements で累積コストの高いクエリ TOP10
SELECT
  round(total_exec_time::numeric, 1) AS total_ms,
  calls,
  round(mean_exec_time::numeric, 2) AS mean_ms,
  left(query, 80) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

8-3. ロック待ち

-- ブロックしている／されているプロセスの関係
SELECT
  blocked.pid       AS blocked_pid,
  blocking.pid      AS blocking_pid,
  left(blocked.query, 60)  AS blocked_query,
  left(blocking.query, 60) AS blocking_query
FROM pg_stat_activity blocked
JOIN pg_stat_activity blocking
  ON blocking.pid = ANY(pg_blocking_pids(blocked.pid));

8-4. テーブル肥大化・VACUUM状況

-- デッドタプルの多いテーブル
SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  round(100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0), 1) AS dead_pct,
  last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

8-5. レプリカ遅延

-- リーダー側で実行：ライターからの遅延時間
SELECT
  CASE
    WHEN pg_is_in_recovery()
    THEN now() - pg_last_xact_replay_timestamp()
    ELSE NULL
  END AS replica_lag;

---

9. これだけはやっとけ設定チェックリスト

クラスター構築時に「やっておくと後で困らない」最低ラインです。

• rds.force_ssl = 1（クラスターPG）で平文接続を遮断
• マスターユーザーをアプリに直接使わない。用途別ロール（owner / rw / ro）を分離
• public に直置きせず専用スキーマを作り、ALTER DEFAULT PRIVILEGES を先に仕込む
• ロケール/照合順序を構築時に確定（日本語なら ja_JP.UTF-8 または ICU ja-JP）
• shared_preload_libraries に pg_stat_statements, pgaudit を積んで再起動
• log_min_duration_statement（例: 1000ms）でスロークエリをログ化
• RDSのログを CloudWatch Logsへエクスポート（postgresql, upgrade）
• Performance Insights を有効化（無料枠7日でもONに）
• 削除保護（Deletion Protection） をON
• 自動バックアップの保持期間 を要件に合わせて設定（最低7日推奨）
• Enhanced Monitoring を有効化（OSレベルメトリクス）
• マイナーバージョン自動アップグレードの方針を決める（本番は検証後に手動が無難）
• 接続枯渇が想定されるなら RDS Proxy を前段に
• パラメータ変更後は必ず pg_settings の source/setting で反映を確認

---

10. おわりに

Aurora PostgreSQL は「マネージドだから簡単」と思って初期設定を流すと、ロケール・パラメータグループの種別・スキーマ権限あたりで後からやり直し（=ダウンタイム）になりがちです。構築直後に確認SQLを一通り流す習慣と最初に権限テンプレートを仕込むだけで、運用フェーズの事故がかなり減ります。

この記事のSQLはそのままコピペして使えるようにしてあるので、自分のクラスター用にカスタマイズして手元のチートシートにしてもらえれば。

バージョン・サポート期限は変わるので、構築時点で AWS の公式リリースノート／リリースカレンダーを必ず確認してください。