AWSでAmazon Auroraを動かす方法は、2026年3月25日に発表されたexpress configurationで数秒で作るやり方と、VPCの中にクラスターを組み立てるフル構成の2通りに分かれました。この記事では、AWS CLIのコマンドを実際の実行順に並べ、Aurora PostgreSQLをexpress configurationで作ってIAMトークンで接続する手順と、Aurora MySQLをVPC内にライター1台・リーダー1台で構築し、Secrets Managerのパスワードで接続する手順を解説します。続けてフェイルオーバー試験、クローン、課金を止める削除順と東京リージョンの費用目安まで示します。仕組みや料金構成から知りたい方はAmazon Auroraの仕組みと採用判断を解説した記事が先です。
まとめ：AWSでAuroraを動かす2つの作り方と検証から削除までの要点
とにかく早く触りたいなら、--with-express-configurationを付けたcreate-db-clusterを1回実行するだけで、Aurora PostgreSQLのサーバーレスインスタンスが数秒で立ち上がります。ただしVPCに関連付けられず、認証はIAMのみ、RDS ProxyやGlobal Databaseも使えないため、本番の設計検証には向きません。本番に近い構成を試すなら、DBサブネットグループとセキュリティグループを用意したうえで、空のクラスターを作り、ライターとリーダーをcreate-db-instanceで1台ずつ追加します。
検証で必ず見るのは、フェイルオーバー時にクラスターエンドポイントの接続先が切り替わる挙動です。終わったらインスタンスを先に削除し、最後にクラスターを消します。東京リージョンのdb.t4g.medium 2台を2時間動かしても約0.45ドルですが、消し忘れればその単価が24時間積み上がります。
AWSでAuroraを構築する前に決める作成方式と検証環境の前提
コマンドを打つ前に、作成方式と、手元のCLI・権限を確かめます。ここを飛ばすと「VPCを指定できない」「インスタンスが1台も無い」状態で止まります。
express configurationとフル構成の違いを8項目で比較
2つの方式は、同じcreate-db-clusterでもできあがる環境がまったく異なります。AWS公式のexpress configurationのドキュメントに書かれた既定値と制限を、フル構成と並べると次のとおりです。
| 項目 | express configuration | フル構成 |
|---|---|---|
| 対応エンジン | Aurora PostgreSQLのみ | MySQL互換・PostgreSQL互換 |
| VPC | 関連付け不可 | DBサブネットグループで指定 |
| 接続経路 | internet access gateway | VPC内から接続 |
| 認証 | IAM認証のみ | パスワード・IAM・Kerberos |
| インスタンス | サーバーレスを自動作成 | 自分で追加（0台から） |
| エンジン版 | 既定版のみ | 任意の版を指定 |
| 暗号化キー | サービス所有キー固定 | カスタマー管理キーも可 |
| RDS Proxy・Global DB | 非対応 | 対応 |
express configurationは「PostgreSQLでとにかくSQLを流したい」ときの近道です。VPC内のECSやLambdaから接続させる予定なら、最初からフル構成で組みます。
AWS CLI 2.37系と権限・DBサブネットグループの事前準備
手順はAWS CLI v2を前提にしています。コマンドリファレンスは2026年9月時点で2.37系で、--with-express-configurationのような新しいオプションは古いCLIでは認識されません。インストールや認証の設定がまだなら、AWS CLI v2の導入とSSO認証の設定手順を先に済ませてください。一時的な認証ならaws loginでも足ります。
express configurationに必要なIAM権限は、公式にrds:CreateDBCluster・rds:CreateDBInstance・rds:EnableInternetAccessGateway・ec2:DescribeAvailabilityZones・iam:CreateServiceLinkedRoleの5つと明記されています。フル構成では、2つ以上のAZのプライベートサブネットで作ったDBサブネットグループ（以下lab-db-subnets）と、接続元からポート3306だけを許可するセキュリティグループ（以下sg-0123456789abcdef0）を用意します。
検証環境の費用目安と東京リージョンの単価に基づく2時間の稼働試算
Auroraはインスタンスの稼働時間で課金されるため、検証の費用はほぼ「台数×時間」で決まります。AWSのPrice List APIから取得した東京リージョンの単価（2026年9月24日公開版）は次のとおりです。最新の単価はAmazon Auroraの公式料金ページで確認してください。
| 課金項目 | Aurora Standard | I/O-Optimized |
|---|---|---|
| db.t4g.medium | 0.113ドル／時 | 0.147ドル／時 |
| db.r7g.large | 0.333ドル／時 | 0.433ドル／時 |
| Serverless v2 | 0.15ドル／ACU時 | 0.20ドル／ACU時 |
| ストレージ | 0.12ドル／GB月 | 0.27ドル／GB月 |
| I/Oリクエスト | 0.24ドル／100万件 | 課金なし |
ライターとリーダーをdb.t4g.mediumで2時間動かすと0.113×2台×2時間で約0.45ドル、クローン用に1台を1時間足しても約0.57ドルです。データが数GBならストレージとI/Oは数セントです。Serverless v2のACU単位の課金とスケーリングの考え方は、Aurora Serverless v2の料金とスケーリングを解説した記事で詳しく扱っています。
express configurationでAurora PostgreSQLの作成・接続
ここでは、VPCもパスワードも用意せずにAurora PostgreSQLへSQLを流すところまで進めます。2026年3月25日のAWS News Blogの発表で追加された作成方式で、公式ドキュメントでは中東（UAE・バーレーン）とGovCloudを除く全リージョンで使えるとされています。
create-db-clusterを1回実行してサーバーレスのクラスターを作る
express configurationでは、クラスターとサーバーレスインスタンス、internet access gateway、管理ユーザー（既定はpostgres）のIAM認証がまとめて設定されます。指定するのはクラスター識別子とエンジンだけです。
aws rds create-db-cluster \
--db-cluster-identifier aurora-express-lab \
--engine aurora-postgresql \
--with-express-configuration \
--region ap-northeast-1
# 状態が available になったか確認する
aws rds describe-db-clusters \
--db-cluster-identifier aurora-express-lab \
--query 'DBClusters[0].[Status,EngineVersion]' --output textエンジン版は既定のメジャー版・マイナー版に固定され、作成時に選べません。後から上げることはできても下げることはできないため、特定の版で動作確認したい案件ではこの方式を使わないでください。Aurora PostgreSQLの対応版や拡張機能の互換性は、Aurora PostgreSQLの対応バージョンと拡張機能を整理した記事で確認できます。
generate-db-auth-tokenで15分有効のトークン発行とpsql接続
express configurationのクラスターはパスワード認証を持たず、IAMで発行した一時トークンをパスワードの代わりに使います。generate-db-auth-tokenのリファレンスの出力例にはX-Amz-Expires=900とあり、トークンの有効期限は15分です。
# 接続とセキュリティタブに表示されるライターエンドポイントを入れる
HOST=WRITER_ENDPOINT
export PGPASSWORD=$(aws rds generate-db-auth-token \
--hostname "$HOST" --port 5432 \
--username postgres --region ap-northeast-1)
psql "host=$HOST port=5432 dbname=postgres user=postgres sslmode=require" \
-c "SELECT version();"接続するIAMユーザーまたはロールにはrds-db:connectの権限が必要です。15分を過ぎると新しい接続は拒否されるため、pgAdminなどのGUIツールで長時間作業する場合はトークンを取り直します。ポートは5432固定で、変更できません。
express構成で使えない機能と本番の設計検証に持ち込まない理由
公式ドキュメントの制限事項には、VPCに関連付けないことに起因する非対応機能が並んでいます。検証の結論を本番へ流用するときに影響が大きい順に挙げます。
- RDS ProxyとAurora Global Databaseが使えない（接続プーリングとリージョン間DRの検証ができない）
- Secrets Managerのパスワード管理とKerberos認証が使えない（IAM認証は無効化もできない）
- Blue/Greenデプロイ、Zero-ETL統合、Babelfish、Database Activity Streamsが非対応
- カスタマー管理のKMSキーを指定できず、IPv4しか使えない
internet access gatewayも無効化できません。express configurationはSQLやPostgreSQL互換の挙動を確かめる用途に留め、ネットワーク・認証・可用性の検証は次のフル構成で行います。
VPC内にAurora MySQLクラスターをCLIで作成するフル構成の手順
フル構成では、クラスター（ストレージと設定の入れ物）とインスタンス（計算資源）を別々に作ります。create-db-clusterのリファレンスには、Auroraの場合このコマンドは空のクラスターを作るだけで、ライターはCreateDBInstanceで明示的に作る必要があると書かれています。
describe-db-engine-versionsで既定版とLTSの版を確認する
最初に、作成に使うエンジン版を決めます。Aurora MySQLのリリースカレンダーでは、2026年9月時点で最新がMySQL 8.4互換の8.4.8（2026年9月3日）とMySQL 8.0互換のversion 3の3.13（同8月27日）で、長期サポートのLTSは3.10（標準サポートは2028年4月30日まで）です。
# 既定の版を取得する
VER=$(aws rds describe-db-engine-versions --engine aurora-mysql \
--default-only --query 'DBEngineVersions[0].EngineVersion' --output text)
echo "$VER"
# その版で db.t4g.medium が選べるか確かめる
aws rds describe-orderable-db-instance-options --engine aurora-mysql \
--engine-version "$VER" --db-instance-class db.t4g.medium \
--query 'OrderableDBInstanceOptions[].AvailabilityZones[].Name' --output text2番目のコマンドが何も返さなければ、その版ではそのクラスを選べません。移行検証では--default-onlyを外し、本番と同じ版をVERに入れてください。8.4系を選ぶ場合の非互換や移行の前提は、Aurora MySQL 8.4の全体像と移行の前提を整理した記事にまとめています。
空のクラスターの作成とライター・リーダーの2台を追加するCLI手順
クラスターを作るときに--manage-master-user-passwordを付けると、マスターパスワードがSecrets Managerに自動生成されます。平文のパスワードをシェル履歴に残さずに済むため、検証でもこの指定を勧めます。
aws rds create-db-cluster \
--db-cluster-identifier aurora-lab \
--engine aurora-mysql --engine-version "$VER" \
--master-username admin --manage-master-user-password \
--db-subnet-group-name lab-db-subnets \
--vpc-security-group-ids sg-0123456789abcdef0 \
--storage-encrypted --backup-retention-period 1 \
--region ap-northeast-1
# ライター（昇格優先度0）とリーダー（優先度1）を追加する
aws rds create-db-instance --db-instance-identifier aurora-lab-writer \
--db-cluster-identifier aurora-lab --engine aurora-mysql \
--db-instance-class db.t4g.medium --promotion-tier 0
aws rds create-db-instance --db-instance-identifier aurora-lab-reader \
--db-cluster-identifier aurora-lab --engine aurora-mysql \
--db-instance-class db.t4g.medium --promotion-tier 1
aws rds wait db-instance-available --db-instance-identifier aurora-lab-reader最初に作ったインスタンスがライターになり、2台目以降はリーダー（Auroraレプリカ）になります。--promotion-tierは障害時にどのレプリカを昇格させるかの優先度で、0が最も高く15が最も低い値です。公式チュートリアルでは、インスタンスクラスとストレージの組み合わせによって利用可能になるまで最長20分かかることがあるとしています。
Secrets Manager管理のパスワードを取り出してmysqlで接続する
パスワードはクラスターのMasterUserSecretに記録されたシークレットARNから取り出します。Aurora と Secrets Manager によるパスワード管理の公式ページによると、Auroraはこのシークレットを既定で7日ごとにローテーションします。
WRITER=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab \
--query 'DBClusters[0].Endpoint' --output text)
READER=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab \
--query 'DBClusters[0].ReaderEndpoint' --output text)
SECRET_ARN=$(aws rds describe-db-clusters --db-cluster-identifier aurora-lab \
--query 'DBClusters[0].MasterUserSecret.SecretArn' --output text)
DB_PASS=$(aws secretsmanager get-secret-value --secret-id "$SECRET_ARN" \
--query SecretString --output text | jq -r .password)
mysql -h "$WRITER" -P 3306 -u admin -p"$DB_PASS" \
-e "SELECT @@aurora_server_id, @@innodb_read_only, CURRENT_TIMESTAMP;"接続元はクラスターと同じVPC内のEC2などにします。@@innodb_read_onlyはライターで0、リーダーで1を返すので、接続先をこの値で判別できます。ローテーションの周期変更やシークレットの料金は、AWS Secrets Managerのローテーション設定と料金を解説した記事で確認してください。
Auroraのフェイルオーバーとクローンを試してエンドポイントの挙動を確かめる
構築できたら、本番で起きる事象を先に起こしておきます。Auroraを選ぶ理由であるフェイルオーバーの速さは、自分の接続方式で確かめて初めて当てにできます。
failover-db-clusterで切り替えて中断している秒数を記録する
failover-db-clusterのリファレンスによると、このコマンドはクラスター内のAuroraレプリカ1台をプライマリへ昇格させます。1秒ごとに接続先を記録するループを別の端末で動かし、何秒途切れたかをログから読みます。
# 端末A：1秒ごとに接続先のサーバーIDと読み取り専用フラグを記録する
while true; do
echo "$(date +%T) $(mysql -h "$WRITER" -u admin -p"$DB_PASS" \
--connect-timeout=2 -N -e 'SELECT @@aurora_server_id, @@innodb_read_only')"
sleep 1
done
# 端末B：リーダーを指定してフェイルオーバーを起こす
aws rds failover-db-cluster --db-cluster-identifier aurora-lab \
--target-db-instance-identifier aurora-lab-reader
aws rds describe-db-clusters --db-cluster-identifier aurora-lab \
--query 'DBClusters[0].DBClusterMembers[].[DBInstanceIdentifier,IsClusterWriter]' \
--output table端末Aのログで@@aurora_server_idがaurora-lab-writerからaurora-lab-readerに変われば、クラスターエンドポイントが新しいライターを指したことになります。Auroraの高可用性に関する公式ドキュメントは、レプリカがある場合の復旧を通常60秒未満・多くは30秒未満、レプリカが無い場合は通常10分未満としています。空白がこの範囲を大きく超えるなら、アプリ側のDNSキャッシュやコネクションプールの設定を疑ってください。
クラスター・リーダー・インスタンスの3つのエンドポイントの使い分け
Auroraのエンドポイント接続の公式ページでは、クラスター・リーダー・インスタンス・カスタムの4種類が定義されています。アプリの設定には、書き込み用のクラスターと読み取り用のリーダーの2つだけを使います。
インスタンスエンドポイントは特定の1台に固定されるため、その1台がリーダーに降格すると書き込みがエラーになります。診断で特定の1台を見るときだけ使い、アプリの接続文字列には書かないでください。リーダーエンドポイントも昇格の瞬間に新しいプライマリへ短時間つながる場合があると公式に書かれています。
コピーオンライトのクローンで本番相当の検証用クラスターを作る
クローンは、元のクラスターとストレージを共有したまま別のクラスターを作る機能です。Auroraクローンの公式ドキュメントによると、作成直後の追加容量は最小限で、どちらかがデータを変更した部分にだけ新たなストレージが割り当てられます。
aws rds restore-db-cluster-to-point-in-time \
--source-db-cluster-identifier aurora-lab \
--db-cluster-identifier aurora-lab-clone \
--restore-type copy-on-write --use-latest-restorable-time \
--db-subnet-group-name lab-db-subnets \
--vpc-security-group-ids sg-0123456789abcdef0
# クローンにはインスタンスが無いので1台追加する
aws rds create-db-instance --db-instance-identifier aurora-lab-clone-1 \
--db-cluster-identifier aurora-lab-clone --engine aurora-mysql \
--db-instance-class db.t4g.medium--restore-type copy-on-writeを付け忘れると、クローンではなく通常の復元になり全データがコピーされます。copy-on-write方式は最大15個までで、16個目からはフルコピーです。スキーマ変更のリハーサルを本番に負荷をかけずに行えます。
検証終了後のAurora削除手順と課金を止め忘れる失敗パターン
Auroraの検証で多い失敗は、消したつもりのインスタンスやスナップショットが残り続けることです。
検証終了後にインスタンスを先に削除してからクラスターを消す順番
delete-db-clusterのリファレンスには、削除中（deleting）でないインスタンスが残っているクラスターは削除できないと書かれています。インスタンスを先に消し、状態が変わってからクラスターを削除します。
for id in aurora-lab-clone-1 aurora-lab-reader aurora-lab-writer; do
aws rds delete-db-instance --db-instance-identifier "$id"
done
aws rds wait db-instance-deleted --db-instance-identifier aurora-lab-writer
# クローンは最終スナップショット不要、元クラスターは念のため残す
aws rds delete-db-cluster --db-cluster-identifier aurora-lab-clone \
--skip-final-snapshot
aws rds delete-db-cluster --db-cluster-identifier aurora-lab \
--final-db-snapshot-identifier aurora-lab-final
# express構成のクラスターも同じ順で消す
aws rds describe-db-clusters --db-cluster-identifier aurora-express-lab \
--query 'DBClusters[0].DBClusterMembers[].DBInstanceIdentifier' --output textexpress構成のクラスターにもサーバーレスインスタンスが1台あるので、最後のコマンドで識別子を確かめて先に削除します。
検証終了時の削除保護・最終スナップショット・自動バックアップの扱い
削除コマンドが通らないときに確認するのは次の3点です。影響の大きいものから並べます。
- 削除保護：
--deletion-protectionが有効なクラスターは削除できません。modify-db-cluster --no-deletion-protectionで外してから削除します。 - 最終スナップショット：
--skip-final-snapshotを付けない場合は--final-db-snapshot-identifierの指定が必須です。 - 自動バックアップ：既定ではクラスター削除と同時に消え、復元できません。残したいデータは手動スナップショットにします。
逆に手動スナップショットはクラスターを消しても削除されないため、検証が終わったらaws rds describe-db-cluster-snapshots --snapshot-type manualで残っているものを一覧し、不要な分をdelete-db-cluster-snapshotで消してください。請求を見て初めて気づく残骸は、ほとんどがこのスナップショットか消し忘れたインスタンスです。
AuroraをCLIで構築する方式の採用条件とIaCへ移す判断基準
結論から言うと、CLIの手作業は検証までに留め、本番はIaCで作り直すべきです。
express構成・CLI手作業・IaCを使い分ける条件と見送る場面
express configurationを選んでよいのは、PostgreSQLの挙動を1日以内に確かめたい、アプリはまだVPCに無い、という場面だけです。VPC内から接続する、MySQL互換を使う、RDS Proxyを挟む、のどれか1つでも当てはまるなら見送ります。
フル構成のCLI手作業は、フェイルオーバーの測定やクローンでの移行リハーサルのように、作って壊す検証に向いています。同じ構成を開発・ステージング・本番の3環境に作る段階でコマンドを貼り回すと、パラメータグループや昇格優先度の指定漏れが出ます。本番の設定値はIaCのコードに残し、レビューを通してから適用してください。標準のRDSとAuroraのどちらで本番を組むかの判断は、Amazon RDSの対応エンジンと採用判断を解説した記事が材料になります。
既存DBからAuroraへの移行と本番設計を外部に任せる判断の目安
検証で扱った範囲を超えて外部の手を借りるべきなのは、オンプレミスや標準RDSで動いている既存DBをAuroraへ移す案件です。版の差によるSQLの非互換、移行中の差分同期、切り替え当日の停止時間の見積もりは、クローンとフェイルオーバーの試験だけでは埋まりません。
スキーマ設計からデータ移行、切り替え計画までを任せたい場合は、データベース設計・移行支援のサービスに移行元の版と停止許容時間を伝えて相談すると、見積もりの前提がそろいます。新規にAuroraを1クラスター立てるだけなら、この記事の手順とIaCで自社内で完結できます。
よくある質問
AWSでAuroraを構築するときに、手順の途中で出やすい疑問を公式ドキュメントに基づいて整理します。
AWSのAuroraは無料で試せますか？
公式ドキュメントでは、express configurationによるAurora PostgreSQLの作成はAWS無料利用枠の対象とされています。対象の条件やクレジット額はアカウントの作成時期とプランで変わるため、公式の料金ページで確認してください。無料枠の外でも、東京リージョンのdb.t4g.medium 2台を2時間動かす程度なら約0.45ドルです。
create-db-clusterを実行したのにAuroraに接続できないのはなぜですか？
フル構成のcreate-db-clusterは空のクラスターを作るだけで、create-db-instanceでライターを追加するまで接続先が存在しません。インスタンスを追加してもつながらない場合は、セキュリティグループで接続元からのポート3306（PostgreSQLは5432）が許可されているかを確認してください。
Auroraのフェイルオーバーにはどのくらい時間がかかりますか？
公式の目安は、レプリカがある場合で通常60秒未満、レプリカが無い場合で通常10分未満です。差が大きいので、本番で数十秒の中断に収めたいならリーダーを最低1台、ライターと別のAZに置いてください。実際の中断時間はアプリの再接続設定にも左右されるため、failover-db-clusterで事前に測っておきます。
express configurationのクラスターをVPC内に移せますか？
express configurationで作ったクラスターはVPCに関連付けられず、internet access gatewayも無効化できません。VPC内で使いたい場合は、スナップショットかポイントインタイムリカバリから、フル構成のクラスターとして復元します（公式ドキュメントに明記）。最初からVPC内で使う予定なら、フル構成で作るほうが手戻りがありません。
Aurora MySQLはversion 3と8.4のどちらで作るべきですか？
既存資産の制約が無い新規構築なら、標準サポートが2032年4月まである8.4系が候補です。version 3（MySQL 8.0互換）の標準サポートは2028年4月30日までです。MySQL 8.0前提の既存アプリは、LTSの3.10か最新の3.13で動作を確かめ、8.4への移行は非互換を洗い出してから計画してください。
関連記事
- Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説：本記事の手順の前提となる分散ストレージと料金構成、採用判断を整理した記事
- Aurora PostgreSQLとは？対応バージョン・拡張機能とBabelfish・RDSからの移行判断を実装者目線で解説：express configurationで作るPostgreSQL互換版の互換性と移行判断を扱った記事
- Aurora MySQL 8.4の全体像と移行を検討する読者が押さえる前提：フル構成で選ぶMySQL互換版の8.4系の前提を確認できる記事
- Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説：express構成が使うサーバーレスインスタンスのACU課金を深掘りした記事
- AWS CLIの導入と運用｜v2の設定・SSO認証・v1サポート終了への移行手順：本記事のコマンドを実行する前提になるCLI v2の設定手順をまとめた記事
