Webアプリから社内APIを繋ぎこんだあと、「画面には出てるけど、これ本当にAWS側のDBに入ってる?」が気になって、AWSコンソールを開いて片っ端から確認してみました。
結論から言うと、DynamoDB・S3・Cognitoは何の準備もなくコンソールから中身が丸見えでした。一方でAuroraだけは、コンソールから中身が一切見えません。同じ「AWS上のDB」なのに扱いが全然違ったのが、個人的に一番の学びでした。
同じように「AWSのDBの中身どうやって見るんだ」で手が止まった人向けのメモです。
確認したかったこと
Web画面から友だち申請を送ったりメッセージを投げたりしたあと、こういうことが知りたくなります。
- ユーザーのレコードはちゃんと作られたのか
- 送ったメッセージは保存されたのか
- 添付したファイルはどこに置かれたのか
フロント側のレスポンスを見れば「成功した」ことはわかるんですが、保存されたデータそのものを自分の目で見ないと安心できませんでした。
対象の構成
だいたいこんな構成です（名前はダミーに置き換えています）。
ブラウザ
→ Next.js の Route Handler（BFF）
→ API Gateway（HTTP API・Cognito の JWT オーソライザ）
→ Lambda（FastAPI）
├─ Aurora PostgreSQL Serverless v2 … アプリ本体のデータ
├─ DynamoDB … チャット・ユーザー等
└─ S3 … 添付ファイル
保存先が3種類に分かれているので、「DBを見る」と一言で言っても入口がバラバラになります。
結論: コンソールで見えるもの・見えないもの
先に一覧です。
| 見たいもの | 置き場所 | コンソールから中身が見えるか |
|---|---|---|
| チャット・ユーザー・友だち関係 | DynamoDB | 見える（テーブル項目の探索） |
| 添付ファイル | S3 | 見える（オブジェクト一覧） |
| アカウント | Cognito ユーザープール | 見える（ユーザー一覧） |
| アプリ本体のデータ | Aurora PostgreSQL | 見えない |
この表を作れた時点で、だいぶ気持ちが楽になりました。「見えないものは見えない」とわかっていれば、無駄に探し回らずに済みます。
DynamoDB: 「テーブル項目の探索」で全部見える
一番あっさり見えたのがDynamoDBでした。コンソールで DynamoDB → 左メニューの テーブル → 該当テーブルを選んで テーブル項目の探索 を押すだけです。スキャンが走って、中の項目がそのまま一覧で出てきます。
項目をクリックすると1件ずつ中身が見られますし、右上の JSON に切り替えるとDynamoDB JSON形式でも読めます。特定のキーで絞りたいときは、同じ画面でクエリモードに切り替えられます。
CLIから件数だけサッと見たいときはこちらでも確認できました。
aws dynamodb describe-table \
--profile dev \
--table-name Message \
--query 'Table.{name:TableName,items:ItemCount,size:TableSizeBytes}'
{
"name": "Message",
"items": 231,
"size": 61076
}
ちなみに ItemCount は約6時間ごとに更新される概算値なので、たった今入れた1件を数えたい用途には向きません。正確に見たいときは素直にコンソールで探索するのが早かったです。
S3: 添付ファイルはそのまま置いてある
アップロードした添付は、S3のバケットを開いてオブジェクトを辿れば見つかります。コンソールならファイル名・サイズ・更新日時が並ぶので、「さっき上げたやつ、これだな」がすぐわかります。
CLIだと1行です。
aws s3 ls s3://myapp-storage-dev-uploads/ --profile dev --recursive
「アップロードAPIは200を返したのに実体が無い」みたいな事故を切り分けるのに便利でした。
Cognito: アカウントはユーザープールで見る
ユーザーのアカウント情報はDBではなくCognitoのユーザープールにあります。コンソールで Cognito → ユーザープール → 該当プール → ユーザー を開くと、登録済みのアカウントが一覧で出ます。
自分の場合「アプリ側のユーザーテーブルには居るのにログインできない」を疑ったとき、ここを見て初めてCognito側とアプリ側でユーザーが二重管理になっていることに気づけました。DBだけ見ていたら詰まっていたと思います。
Auroraだけコンソールから中身が見えない
さて本題です。RDSのコンソールでAuroraクラスターを開いても、CPU使用率やコネクション数といったメトリクスは出ますが、テーブルの中身を見る画面がどこにもありません。最初は自分の探し方が悪いのかと思って結構な時間を溶かしました。
理由は2つでした。
1つ目は、DBがプライベートサブネットに居ること。 PubliclyAccessible が false なので、そもそも手元のMacからネットワーク的に到達できません。踏み台になるEC2も立っていませんでした。
aws rds describe-db-instances \
--profile dev \
--query 'DBInstances[].{id:DBInstanceIdentifier,public:PubliclyAccessible}'
[
{
"id": "myapp-db-dev-cluster-writer",
"public": false
}
]
2つ目は、RDSのクエリエディタが使えないこと。 RDSコンソールには「クエリ」というSQLを実行できる機能があるんですが、これは RDS Data API（HTTPエンドポイント）が有効になっているクラスターでしか使えません。今回のクラスターは無効でした。
aws rds describe-db-clusters \
--profile dev \
--query 'DBClusters[].{id:DBClusterIdentifier,http:HttpEndpointEnabled}'
[
{
"id": "myapp-db-dev",
"http": false
}
]
HttpEndpointEnabled が false。ここが true なら、コンソールの アクション → クエリ からブラウザ上でSQLが叩けて、ネットワーク設定なしにテーブルを覗けたわけです。
見えないと分かったので、代わりに以下で確認しました。
- APIのレスポンスで確認する — 一覧取得のエンドポイントを叩けば、Auroraに入った結果が返ってくる。結局これが一番手っ取り早かったです
- CloudWatch LogsでSQLエラーを見る — 入らなかった場合の原因はだいたいここに出ます。ログの探し方はAWSデプロイ後に見る3画面メモに書いたので、そちらもどうぞ
Auroraを直接覗きたい場合の選択肢としては、Data APIを有効化してクエリエディタを使う・踏み台EC2を立ててSSMのポートフォワードでpsqlを繋ぐ・VPC内にSQLを実行する使い捨てLambdaを置く、あたりがあるようです。ただどれも今回は試していないので、ここは受け売りです。Data APIの有効化はクラスター設定の変更になるので、共有環境で軽い気持ちで触るのはやめておきました。
まとめ
- DynamoDB・S3・Cognitoは、コンソールを開くだけで中身が見える
- Auroraはプライベートサブネット＋Data API無効だと、コンソールからは中身が見えない
- 「見えないDB」の中身を確かめたいときは、まずAPIのレスポンスとCloudWatch Logsで代替できないか考えると早い
AWS上のDBを確認したくなったら、まず describe-db-clusters で HttpEndpointEnabled を見るのがおすすめです。ここが false だった時点で「コンソールでSQLは叩けない」と確定するので、探し回る時間をまるごと節約できます。
参考
- Aurora クエリエディタの使用 — AWS ドキュメント
- Amazon RDS Data API の使用 — AWS ドキュメント
- ステップ 5: DynamoDB テーブル内のデータにクエリを実行 — AWS ドキュメント
関連記事
- AWSデプロイ後に見る3画面メモ（CloudFormation / Lambda / CloudWatch） … 同じ環境のデプロイ側の話。CloudWatch Logsの探し方はこちら
- AWS RDSとは？ DBを運用込みで借りるサービス … そもそもRDSとAuroraがどういう関係なのかを整理した入門記事
- FastAPI で「Summary 型」を作る — 一覧APIでユーザー情報を返すときの共通モデル … この記事で「結局APIのレスポンスで確認した」と書いた、そのAPI側の設計話