はじめに
今回は、既存のAWS環境（過去の記事をご参照ください）
に、
・Amazon Relational Database Service（Aurora PostgreSQL Serverless v2）
・AWS Key Management Service (KMS)
・AWS Secrets Manager
を新規に追加し、Lambdaから「RDS Data API」経由でデータベースに接続するまでの手順（AWSコンソール上での手動設定）をまとめてみました。
少しでも参考になれば幸いです。
実装順に関連記事を公開していますので、過去の記事もぜひ合わせてご参照ください。
インフラ構成図
操作の流れ
- VPCの作成
- KMS CMKの作成
- データベースの作成
- Lambda環境変数の追加
- Lambda実行ロールにポリシー追加
- Lambdaエイリアスを張り替え
- GitHub ActionのDB操作専用IAMロールの作成
- 動作確認
1. VPCの作成
RDSはAWSが管理するデータベースですが、実際にはユーザー専用のネットワーク空間であるVPC（Virtual Private Cloud）内に配置されるため、まずはVPCを作成します。
今回はData API経由で接続するためNAT/IGWは不要です
AWSコンソール >> VPC >> 仮想プライベートクラウド >> お使いのVPC画面に遷移し、「VPCを作成」を押します。
①「作成するリソース」は「VPCなど」を選択します。（サブネットやルートテーブルをまとめて作成することが可能になります）
個別で作成する手順は、過去の記事をご参照ください。
②わかりやすい名前タグを入力します。
③IPv4 CIDR ブロックを入力します。
④「アベイラビリティゾーン (AZ) の数」は「2」を選択します（必要であればAZの指定も可）
※Auroraは通常、DBサブネットグループに最低2AZを指定します。ライターインスタンスを1台しか作らない場合でも最低2AZを指定する必要があります。
⑤「パブリックサブネットの数」は「０」にします。
⑥「プライベートサブネットの数」は「２」にします。
⑦「NAT ゲートウェイ」は「なし」にします。
⑧「VPC エンドポイント」は「なし」にします。
⑨「DNS オプション」は両方有効にします。
⑩（必要であれば）タグを追加します。
⑪「VPCを作成」を押します。
・ルートテーブルに0.0.0.0/0が無いこと(プライベートであること)
・Auroraは2AZ以上のサブネットグループが必須なので、2サブネットが別AZにあること
を確認します。
現時点のインフラ構成図：
2. KMS CMKの作成
Auroraの暗号化を有効化するためにはKMSキーが必要になります。
Auroraの暗号化機能は、内部的にAWS Key Management Service (KMS)を利用しています。
（Auroraの暗号化を有効化すると、Auroraはデータを直接暗号化するのではなく、KMSに保存された暗号鍵を使って暗号化・復号を行います）
・AWS Managed Key →AWSが管理
・Customer Managed Key (CMK) →ユーザーが管理
の２種類がありますが、
CMKキーは「削除可能」「無効化可能」「ローテーション可能」「鍵の管理権限をユーザー側で制御できる」といったデメリットが存在するため、データベースには通常CMKが使用されます。
また、AWS Secrets Managerのシークレット暗号化にも内部ではKMSが使用されており、デフォルトではAWS管理キーが使用されますが、今回の構成ではここで作成したCMKを再利用しています。
AWSコンソール >> Key Management Service >> カスタマー管理型のキー画面に遷移し、「キーの作成」を押します。
①「キーのタイプ」は「対象」を選択します。
②「キーの使用法」は「暗号化および復号化」を選択します。
①「エイリアス」にはわかりやすい名前を入力します。
（必要であれば、「説明」および「タグ」を設定します）
②「次へ」を押します。
①「キー管理者」には「あなたが今ログインしている運用Role」を選びます。
ここで選ぶのは「鍵を暗号化用途で使う人」ではなく「鍵そのものを管理（設定変更・無効化・削除）できる人」です。LambdaやDB操作Roleはここには関係しません（暗号化に使う権限は後段＋IAM側で付与します）
②「キーの削除」にチェックを入れておきます。
③「次へ」を押します。
「キーの使用法アクセス許可を定義」は何も指定しまいまま「次へ」を押します。
今回の設計は「キーポリシーは触らず、デフォルトのアカウントroot信頼＋IAM identityポリシーだけでDecryptを通す」方針です。
そのためキー使用者の指定ではLambda実行ロールやDB操作Roleをここで選ぶ必要はありません。
Decrypt権限は、後でインラインIAMポリシー側（kms:Decrypt + kms:ViaService/SecretARN条件）で与えます。
同様に「キーポリシーを編集」もデフォルトのまま「次へ」を押します。
確認画面が表示されるので、「完了」を押します。
現時点のインフラ構成図：
3. データベースの作成
Aurora PostgreSQL Serverless v2 クラスターを作成します。
AWSコンソール >> Aurora and RDS >> データベース画面に遷移し、「データベースの作成」を押します（データベース作成方法はフル設定）
①「エンジンのタイプ」は「Aurora (PostgreSQL Compatible)」を選択します。
②「データベース作成方法を選択」はデフォルト（フル設定）のままにします。
③テンプレートは「dev/stg」であれば「開発/テスト」を選択します。
①「クラスタースケーラビリティタイプ」は「Serverless v2」を選択します。
②最小容量 (ACU)は「0.5」を選択します。
③最大容量 (ACU)は「2」を選択します。
ACUとは
・Aurora Serverless v2の料金は「ACU料金」＋「ストレージ料金」＋「バックアップ料金」が基本であり、メインの料金がACUです。
・最小容量 (ACU)と最大容量 (ACU)の間でオートスケーリングします（垂直のみ）
・スケーリングは上がるだけでなく最小容量 (ACU)まで下がります。
・オートスケーリングはデフォルトで有効であり、無効化はできません。
・ACUは「CPU・メモリ・ネットワーク帯域・I/O性能・同時接続処理能力」をまとめてスケールさせます。
・ACUは0〜256ACUの範囲で設定可能です。
・MaxCapacity=256にしても、常に256ACUで課金されるわけではなく、実際の課金はその時点で使用している ACUに対してのみ発生します（異常クエリやアクセス集中時に、想定以上のコストが発生するリスクを防ぐため、適切な最大容量 (ACU)を設定することが推奨されています）
・開発/検証環境であれば0.5〜1、小規模Webサービスであれば2〜4ACUが目安と言われています（要確認）
autoPauseSecondsとは
非アクティブ後に一時停止（autoPauseSeconds）は最小容量（minCapacityAcu）が0のときのみ有効にすることができる機能です。
最大値は86,400秒（24時間）で、一時停止中は課金対象のACUが0になるためコストを削減することが可能になりますが、コールドスタートが発生するというデメリットもあります。
①「エンジンバージョン」をアプリに合わせて選択します。
②「DB クラスター識別子」をわかりやすく入力します。
③「マスターユーザー名」を入力します（固定値を使用する場合は注意）
④「認証情報管理」は「AWS Secret Managerで管理」を選択します。
⑤「暗号化キーを選択」は先ほど作成したCMKを選択します。
①「データベース認証」はデフォルトのまま（チェックしない）です（今回はData API（HTTPS経由のIAM認可）を使うため）
②「クラスターストレージ設定」は「Aurora スタンダード」を選択します。
※負荷の重い要件の場合、「Aurora I/O 最適化」を選択します（料金は上がります）
③「マルチ AZ 配置」は「Aurora レプリカを作成しない」を選択します（prod環境は有効化します）
マルチAZ配置とは
6 copies of your data across 3 Availability Zones
Auroraでは何もしなくても、データは自動的に3AZへ分散保存されストレージ層は共有されています（障害に強い）
（この3AZはユーザーが設定するものではない）
しかしDBインスタンス（Writer 1台の場合）は配置されているAZで障害が発生した場合に対応できません。
そのため、本番環境では通常マルチAZ配置を有効にし、以下のような配置にします。
AZ-a
└─ Writer
AZ-c
└─ Reader
Writer障害時はReaderが自動でWriterに昇格します（フェイルオーバー時間は通常数十秒程度）
また、ReaderのACUはWriterに追従します（いつでもフェイルオーバーできるように）
Readerインスタンスは増やさなくていい？
今回の構成で使用している「Data API」クエリは読み取りも書き込みもすべてWriterインスタンスでのみ実行される（Readerには流れない）ためです。
①VPCは先ほど作成したものを選択します。
②「DB サブネットグループ」は「新しいDBサブネットグループの作成」を選択します。
③「VPC セキュリティグループ」は既存のdefaultをそのまま使用します。
→今回の接続経路はLambda/GitHub Actions → IAM → Data API（AWSのAPI）→ Auroraで、ネットワーク的にAuroraへ直接インバウンド接続しません。そのためSGのインバウンドルールは実質的に効いてこず、default SG（同一SG内のみ許可・外部から閉じている）でも到達性に支障はありません。
DBサブネットグループとは
・RDSやAuroraが配置されるサブネットの集合です
・通常は異なるAZのサブネットを最低2つ登録します
・RDS/Aurora作成時に必須となるネットワーク設定です
・マルチAZ構成やフェイルオーバーのために利用されます
・DBサブネットグループ自体に料金は発生しません
・コンソールで作成する場合は、選択したVPC内のサブネットからAWSが自動的に作成してくれます
①「アベイラビリティーゾーン」は「指定なし」のままにします。
「WriterインスタンスをどのAZに固定するか」を手動指定するためのものですが、AWSの自動設定に任せます。
②「RDS Data API」を有効化します。
その他はデフォルトのままにします。
モニタリングの設定はすべてオフにします（追加課金対象のため）
prod環境では必要に応じて設定します。
「追加設定」にて
①「最初のデータベース名」に固定値「DB_NAME」（アプリ側でも使用しているもの推奨）を設定します
データベース名を指定しないと、Amazon RDS はデータベースを作成しません。
②「バックアップ保持期間」を最大の35日に設定しておきます。
その他はデフォルトのままで進みます。
①②「暗号化キー」には「カスタマーマネージド KMS キー」を選択し、先ほど作成したCMKを選択します。
③（prod環境では）削除保護の有効化にチェックします。
「データベースの作成」を押します。
ap-northeast-1cにライターインスタンスが作成されました。
現時点のインフラ構成図：
4. Lambda環境変数の追加
AWSコンソール >> Lambda >> 関数画面に遷移し、対象の関数を押します。
①「設定」タブに遷移します。
②「環境変数」を選択します。
③「編集」を押します。
新たに以下4つの環境変数を追加します。
| キー | 値 |
|---|---|
| DB_DRIVER | data-api |
| DB_CLUSTER_ARN | 作成したクラスターのARN |
| DB_SECRET_ARN | 作成されたシークレットのARN |
| DB_NAME | 命名したDB名 |
5. Lambda実行ロールにポリシー追加
同様のLambda関数の設定画面から、
①「アクセス権限」を選択します。
②実行ロールを押します。
①「許可を追加」を押します。
②「インラインポリシーを作成」を押します。
フォーマットは「JSON」形式を選択し、以下の
<CLUSTER_ARN> / <SECRET_ARN> / <KMS_KEY_ARN>
を置換して「次へ」を押し、わかりやすいポリシー名を設定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RdsDataApiExecute",
"Effect": "Allow",
"Action": [
"rds-data:ExecuteStatement",
"rds-data:BatchExecuteStatement",
"rds-data:BeginTransaction",
"rds-data:CommitTransaction",
"rds-data:RollbackTransaction"
],
"Resource": "<CLUSTER_ARN>"
},
{
"Sid": "ReadDbSecret",
"Effect": "Allow",
"Action": [
"secretsmanager:GetSecretValue",
"secretsmanager:DescribeSecret"
],
"Resource": "<SECRET_ARN>"
},
{
"Sid": "DecryptDbSecretKey",
"Effect": "Allow",
"Action": "kms:Decrypt",
"Resource": "<KMS_KEY_ARN>",
"Condition": {
"StringEquals": {
"kms:ViaService": "secretsmanager.ap-northeast-1.amazonaws.com",
"kms:EncryptionContext:SecretARN": "<SECRET_ARN>"
}
}
}
]
}
6. Lambdaエイリアスを張り替え
環境変数の変更は$LATESTバージョンに反映されただけで、HTTP APIはエイリアス（実際に公開されているバージョン）を指しているため、このままでは反映されません。
①Lambda関数の「バージョン」タブに移動し、
②「新しいバージョンを発行」を押します。
①Lambda関数の「エイリアス」タブに移動し、
②対象のエイリアスを選択し、
③「編集」を押します。
①「バージョン」を押します。
②先ほど作成した最新のバージョン（Latestではない）を選択します。
③「保存」を押します。
7. GitHub ActionのDB操作専用IAMロールの作成
GitHub ActionがData API経由でデータベースのmigrate/seed/resetを実行するための最小権限Roleを新規作成します。
※GitHub Actionワークフローの内容は次回の記事でCDKとまとめてご紹介いたします。
※migrate/seed/resetの各スクリプトファイルの内容は、こちらの記事をご参照ください。
AWSコンソール >> IAM >> ロール画面に遷移し「ロールを作成」を押します。
①「信頼されたエンティティタイプ」は「ウェブアイデンティティ」を選択します。
②「アイデンティティプロバイダー」は既存の「token.actions.githubusercontent.com」を選択します。
③「Audience」は既存の「sts.amazonaws.com」を選択します。
④「GitHub organization」を入力します。
⑤「次へ」を押します。
「許可を追加」では何も選択せずに「次へ」を押します（後でこのロールに対してインラインポリシーでアタッチ）
わかりやすい「ロール名」を設定し、「ロールを作成」を押します。
作成したロールの設定画面へ遷移し、「5. Lambda実行ロールにポリシー追加」と同様の手順で同じ内容のインラインポリシーを追加します。
以上で完了です！
次回は今回の構成をIaC化（CDKで記述）し、実際にGitHub Actionワークフローを実行するまでの手順を解説したいと思います。