# Ec2 Bastion Postgres Setup

> 踏み台サーバー経由で private EC2 に SSH 接続する手順と、外向き通信が弱い private Amazon Linux 上で PostgreSQL を構築する手順を説明・運用する Skill。bastion SSH、agent forwarding、秘密鍵の権限エラー、RPM の持ち込みインストール、PostgreSQL 初期化と設定、あるいは生ログを機密を除いて再利用可能な手順に変換したいときに使う。

- Skill: `satoru314/ec2-bastion-postgres-setup` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add satoru314/ec2-bastion-postgres-setup`
- Raw SKILL.md: https://api.skillmd.com/api/skills/satoru314/ec2-bastion-postgres-setup/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Satoru314 (https://skillmd.com/u/satoru314)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/satoru314/ec2-bastion-postgres-setup

---


# EC2 Bastion Postgres Setup

次の 2 点を分けて説明する。

1. ローカル端末から踏み台経由で private EC2 に入る方法
2. private Amazon Linux 上で PostgreSQL を構築する方法

実際のパスワード、秘密鍵、公開 IP、private IP、固有ユーザー名、DB 秘密情報は残さない。必ずプレースホルダに置き換える。

## 出力方針

まず、ユーザーが欲しいものを次から判定する。

- `Connection flow`
- `Server architecture`
- `PostgreSQL setup`
- `Troubleshooting from shell logs`

特に指定がなければ、次の順で説明する。

1. 構成と、なぜ bastion が要るか
2. プレースホルダ付きの接続フロー
3. 構築またはインストール手順
4. 失敗パターンと切り分け

## 接続フロー

SSH 接続の話をするときは [references/ssh-bastion-access.md](./references/ssh-bastion-access.md) を読む。

説明の順番はこれを基本にする。

1. 秘密鍵はローカル Linux 側に置く。Windows マウント配下を前提にしない。
2. 接続前に鍵の権限を絞る。
3. agent forwarding が必要なら `ssh-agent` を起動する。
4. 鍵を `ssh-agent` に登録する。
5. `ssh -A` で bastion に入る。
6. bastion から private IP か private DNS で private host に入る。

説明時は、次の違いをはっきり分ける。

- `Connection timed out` はだいたいネットワーク経路かセキュリティ設定の問題
- `Permission denied (publickey)` は到達はしているが認証に失敗している状態

## PostgreSQL 構築フロー

PostgreSQL の話をするときは [references/private-postgres-setup.md](./references/private-postgres-setup.md) を読む。

説明は最小完結の流れにする。

1. パッケージを入れる
2. DB クラスタを初期化する
3. サービスを起動し自動起動を有効にする
4. `psql` 内でロールと DB を作る
5. 必要な private network または security group だけに開ける
6. 再起動して確認する

private host がパッケージリポジトリへ直接出られないなら、private host にインターネットがある前提で話さず、bastion 経由の RPM 持ち込み手順を説明する。

## 構成説明

「こういうサーバーをどう組むか」を説明するときは [references/aws-private-server-pattern.md](./references/aws-private-server-pattern.md) を読む。

特に次を押さえる。

- public bastion、private workload host、必要なら app host
- `22/tcp` と `5432/tcp` の security group 関係
- NAT、VPC endpoint、あるいはパッケージ中継がないと `dnf update` が失敗しやすい理由
- PostgreSQL を基本 private に置き、app network からだけ受ける理由

## ログ解釈ルール

ユーザーがログを貼ったら、単なる言い換えではなく `原因 -> 対処` に正規化する。

- `UNPROTECTED PRIVATE KEY FILE` -> 鍵の置き場所か権限を直す
- `Could not open a connection to your authentication agent` -> `ssh-agent` を起動して `ssh-add`
- 1 段目は通るが 2 段目で `Permission denied (publickey)` -> agent forwarding 不足か private host 側の authorized key 不足
- `dnf` mirror timeout -> private subnet から外へ出る経路がない
- `CREATE: command not found` -> SQL を `psql` ではなく shell に打っている
- `postgres-#` prompt -> SQL 文がまだ閉じていない。`;` で終えるか `Ctrl+C`

ログをなぞるだけで終わらせず、順番つきの診断に変換する。

## セキュリティ原則

説明では常に次を守る。

- 秘密情報はプレースホルダにする
- 秘密鍵は `chmod 600` を基本にする
- `pg_hba.conf` で `0.0.0.0/0` は原則避ける
- `listen_addresses` は可能なら private 側に寄せる
- 長期運用なら NAT Gateway、VPC endpoint、Systems Manager を候補に出す