今こそ押さえておきたい アマゾンウェブサービス（AWS）の データベースの基礎

サーバーワークススキルアップトレーニングの登壇資料です。
登壇の動画はこちらでオンデマンド配信しております。
https://www.serverworks.co.jp/event/20260218_skilltraining_ondemand.html

Transcript

1. 今こそ押さえておきたい アマゾンウェブサービス（AWS）の データベースの基礎 2026.02.18 SATOSHI KANEYASU ー サーバーワークススキルアップトレーニング ー
2. 2 氏名：兼安 聡 所属：株式会社サーバーワークス アプリケーションサービス部 在住：広島（フルリモート） 担当：DevOps、技術支援、PM、SM SNS(X)：@satoshi256kbyte • 2025 AWS Community Builders • 2025 Japan AWS Top Engineers (AI/ML Data Engineer) • 2025 Japan AWS All Certifications Engineers • 認定スクラムマスター • PMP Speaker Introduction
3. 1. Database Savings Plansとは 2. AWSのデータベースの種類 3. データベースの使い分け 4. バックアップと復元の運用 5. オンプレミスのデータベースをAWSに移行した場合の注意点 6. 直近で発表されたデータベース系のアップデートについて ※今回はAmazon DSQLとベクトルデータベース系の話題は対象外としています 目次
4. Database Savings Plansとは このページ以降、Database SPと記載します
5. 5 DBサービス群を対象とした柔軟な料金プラン ⚫ Database Savings Plansはデータベースサービス群を対象とした料金プラン ⚫ 1年期間で一定の使用量にコミットする場合に、最大35%の削減が適用 ⚫ アマゾンウェブサービス（AWS）のデータベースの費用を抑える方法として、 Reserved Instance（RI）がありますが、それとの違いは「柔軟性」 ⚫ ＜特徴＞  リージョンを跨いでも適用される  データベースエンジンを変更しても適用される  データベースサービス（Amazon RDSからAmazon DynamoDBなど）を変更しても適用される  割引率は、RIには劣る
6. 6 対象となるデータベースサービス ⚫ Amazon RDS/Aurora/Aurora Serverless v2 ⚫ Amazon Aurora DSQL ⚫ Amazon DynamoDB ⚫ Amazon ElastiCache for Valkey（インスタンス、Serverless） ⚫ Amazon DocumentDB（インスタンス、Serverless） ⚫ Amazon Neptune（インスタンス、Serverless） ⚫ Amazon Keyspaces ⚫ Amazon Timestream ⚫ Amazon OpenSearch Service ⚫ AWS Database Migration Service （インスタンス、Serverless）
7. 7 Savings Plan 購入アナライザー ⚫ AWSマネジメントコンソール  Billing and Cost Management（請求とコスト管理）
8. 8 一定の使用量にコミットするとは？ 購入アナライザーの画面 Saving Plansの購入画面 ⚫ 入力したコミットメントにより割引率が決定 ⚫ コミットメントを超える使用量については、オンデマンド料金となる ➢ 参考：Database Savings Plans 次頁から次の章に移ります
9. AWSのデータベースの種類
10. 10 AWSのデータベースの種類 ➢ 参考：AWS クラウドのデータベース 種類 使用例 データベースサービス Database SP対象 リレーショナル 基幹システム、ECサイト（頻繁な書き込み・読み込み） Amazon Aurora ◦ Amazon RDS ◦ データウェアハウス 大規模分析、BIツール連携（数億件の集計処理） Amazon Redshift Key-Value 高トラフィックのWEBアプリケーション Amazon DynamoDB ◦ インメモリ キャッシュ、セッション管理 Amazon ElastiCache ◦ Amazon MemoryDB ドキュメント コンテンツ管理、カタログ、ユーザープロファイル Amazon DocumentDB （MongoDB互換） ◦ グラフ 不正検出、ソーシャルネットワーキング、レコメンデーションエンジン Amazon Neptune ◦ ワイドカラム 高スケールの業界アプリケーション、設備のメンテナンス Amazon Keyspaces ◦ 時系列 (IoT) アプリケーション、産業用テレメトリ Amazon Timestream ◦ 検索・分析 全文検索、ログ分析、ベクトル検索（AI連携） Amazon OpenSearch Service ◦ 分散データベース グローバルかつ高可用性を要するアプリケーション Amazon Aurora DSQL ◦
11. 11 リレーショナル - Amazon AuroraとAmazon RDS ⚫ オンプレミスで構築したDBに使用感が近いのはAmazon RDS ⚫ Amazon AuroraはAmazon RDSに比べてスループットと可用性に優れる ⚫ スループットに優れるというのは、同じ性能なら捌けるリクエスト量がAuroraの方が 多いという意味 ⚫ 高いスループットはストレージを分散させているからであり、 可用性に優れる理由でもある ➢ 参考：サーバーワークスエンジニアブログ – Amazon Aurora の料金
12. 12 データウェアハウス（DWH） - Amazon Redshift ⚫ Database SPの対象外です ⚫ データウェアハウスは分析・意思決定に活用するためのデータの倉庫 ⚫ 「列（カラム）指向ストレージ」を採用した大規模データ分析に特化 ⚫ 数億件〜数千億件といった、通常のDBではタイムアウトしてしまうような大規模クエリを 高速に処理できる ＜類似・関連＞ ⚫ Amazon S3などにあるデータをAmazon RedshiftからクエリできるRedshift Spectrum ⚫ Amazon S3で分析クエリを実行できるAmazon Athena
13. 13 Key-Value – Amazon DynamoDB ⚫ サーバーの管理が不要なフルマネージドNoSQL ⚫ データ量が数TBに増えても、アクセスが秒間数万件に達しても、応答速度（1桁 ミリ秒）が変化しないのが最大の特徴 ⚫ サーバーの「大きさ」を上げるのではなく、分散することで「横に」無限に拡張できる ⚫ AWS Lambdaとの相性が良い ⚫ SQLは使用不可（NoSQL）なので、集計・分析に向かない  SQLライクなデータ操作は可能ではあるが（筆者が知る限り）テーブル結合が不可能だったりと一般的な SQLとは使用感がかなり異なる ⚫ テーブルの設計と維持の作法が浸透していない
14. 14 インメモリ – Amazon ElastiCache、Amazon MemoryDB ⚫ インメモリDBに分類 ⚫ データの読み書きをすべてメモリ内で行うため、ディスクI/Oが発生せず、極めて低い レイテンシ（遅延）を実現する ⚫ 低いレイテンシを活かして、キャッシュ、セッション管理に用いられる ⚫ MemoryDBは、インメモリDBの低レイテンシに加えマルチAZにまたがるデータの 「永続性」を持つ
15. 15 ドキュメント – Amazon DocumentDB（MongoDB互換） ⚫ データはJSON形式（BSON） ⚫ データ構造を柔軟に変更可能 ⚫ MongoDBのアプリケーション、ドライバ、ツールをそのまま、あるいは最小限の変更 で利用可能
16. 16 強力な検索機能- Amazon OpenSearch Service ⚫ 全文検索などの強力な検索機能を提供するサービス ⚫ ベクトルデータベースとしても使用可能で、Amazon Bedrockと連携して生成AI の精度を向上に役立てることが可能 ⚫ 使い方の選択肢が多すぎて非常に難解なサービス ⚫ 単独でデータベース兼検索サービスとして使用可能だが、 データそのものはAmazon DynamoDB、Amazon DocumentDB、 Amazon S3などに置くことも可能（ゼロETL） ⚫ データを外部に置く場合、OpenSearch Serviceは索引（インデックス）部分と 検索機能の部分を提供するイメージとなる 次頁から次の章に移ります
17. データベースの使い分け
18. 18 Amazon AuroraとAmazon RDSとマルチAZ Oracle・Microsoft SQL Server などを使用していない 割高であるAuroraのコストを 許容できるか？ ⚫ AuroraとRDSをどちらを選択するか RDS Aurora Yes Yes No No ⚫ マルチAZにするかどうか AZ障害時の ダウンを許容できるか？ 自動アップデート時の ダウンを許容できるか？ シングルAZ Yes Yes No No マルチAZ 自動アップデートをしない場合、手動アップデートによる管理が必要になります
19. 19 PostgreSQL互換とMySQL互換 ⚫ 2026年現在、最も勢いのあるデータベースはPostgreSQLです 故に、今から新規でAmazon RDS／Amazon Auroraを構築する場合は PostgreSQLまたはPostgreSQL互換を選択するのが無難でしょう ➢ 参考：2025 Stack Overflow Developer Survey ⚫ ただし、「互換」は同じSQLなどが使えるという意味であり、 「同じもの」ではないことに留意する必要があります 同じSQLが実行できても、同じ速度が出るとは限りません
20. 20 RDBMSとNoSQL ⚫ 業務システムにおいては、 迷ったらRDBS(Amazon Aurora/RDB)をメインに選択した方がよいと思います ⚫ NoSQL(Amazon DynamoDB)は整合性を維持する設計・運用とその維持の 難度が高く、業務システムの相性がそこまでよくありません ⚫ 明らかに大量の読み書きが発生する部分はAmazon DynamoDBの方が有利 です  ただし、Amazon DynamoDBは分析・集計に向かないので、 RDBMSとは扱うデータを棲み分けた方がよいでしょう  少々複雑になりますがAmazon DynamoDBで書き込みを受けて、分析・集計はRDBMSという構成も あります
21. 21 Amazon ElastiCacheは要るのか？ ⚫ インメモリDBであるAmazon ElastiCacheはキャッシュやセッション管理に用いら れます ⚫ キャッシュはアプリケーション側でも持つことはできますが、それだと負荷分散に不利に になるので、コストに問題がなければアプリケーションサーバーとは別にキャッシュサー バーがあった方がよいと思います
22. 22 大規模データ分析サービスの選択 ⚫ 基本的にコストが割高なサービス群なので、分析頻度で使い分けます ⚫ 現実的にはAmazon Athenaで事足りることが多いです サービス 分析頻度 コストモデル Amazon Redshift 高（定常的） 起動時間（インスタンス） Amazon Athena 低（単発） クエリごとのスキャン量のみ Redshift Spectrumは頻度とコストで選ぶものではなく、 「Amazon Redshiftを使っていてAmazon S3のデータを合わせて集計したい」 のようなケースで選ぶ拡張的な機能です 次頁から次の章に移ります
23. バックアップと復元の運用
24. 24 バックアップはAWS Backupによる一元管理がお勧め ⚫ 例えばAmazon Aurora/Amazon RDSはバックアップをAmazon Aurora/Amazon RDSの画面でもAWS Backupのどちらでも取ることができま す ⚫ 実運用では、バックアップの設定が複数画面に分散しているのは煩わしさを感じるこ とが多いので、一元管理できるAWS Backupがお勧めです
25. 25 定期バックアップとポイントインタイムリカバリ（PITR) ⚫ ポイントインタイムリカバリ（PITR）は、データベースやシステムを「過去の特定の時 点」の状態に復元する機能です ⚫ 定期バックアップとPITRのどちらを選ぶか決める際は、 必ずRPO（どの時点まで遡ってデータを復旧させるかを示す指標）についての議 論をしておいてください ⚫ システムが複数あり、一斉に戻すのが許容し難い場合はPITRの方が有利です 片方のシステムで障害が起きた場合、 昨晩のバックアップ時点に戻すという行為がもう片方の システムとの不整合よを起こす場合がある
26. 26 バックアップからの復元のテストはされていますか？ ⚫ バックアップは取れているが復元のテストがされておらず、 いざ障害が発生した際に復元をやりきれないというケースがあります リリース前に必ず復元のテストをしておきましょう ⚫ AWSのデータベースサービスの多くは、復元の際に一時的に新たなインスタンスを 作ることになります これを行うと、多くの場合IaCとの矛盾が発生します ⚫ 復元により矛盾が発生したままだと、その後IaCやCI/CDが回せなくなります このことを踏まえてテストするようにしてください ⚫ 復元によるIaCとの矛盾の解消方法はこちらのブログをご覧ください。  Amazon Auroraをバックアップから復元した時にIaCとの矛盾が起きる現象への対策 次頁から次の章に移ります
27. オンプレミスのデータベースをAWSに 移行した場合の注意点
28. 28 オンプレミスとAWSでは使用感に差が出る ⚫ 基本的にオンプレミスとAWSでは使用感に差が出ます これは、ハードウェア（特にストレージ）やネットワーク構成が異なることに起因します ⚫ ストレージ構成の差などにより、Amazon RDSよりもAmazon Auroraの方が差が 大きく、特に書込速度の感覚にかなりの差が生まれます これによりバッチ処理が非常に遅くなるという現象がよく見られます ➢ 参考：サーバーワークスエンジニアブログ – Amazon Aurora の料金
29. 29 パラメータグループの編集は慎重に ⚫ Amazon RDS/Amazon Auroraにおいて、my.cnf・postgresql.confなどの データベースの設定ファイルはパラメータグループが相当します ⚫ パラメータグループで、 my.cnf・ postgresql.confと同じような設定は可能です が、オンプレミスにおける設定をそのまま適用するのは待ってください ⚫ パラメータグループはデフォルトの状態でAWSに最適化されているので、オンプレミス の感覚で設定を編集すると性能が発揮されなくなる可能性があります RDS/AuroraのパラメータはデフォルトでAWSに 最適化されています また、インスタンスサイズに比例して設定値が変化 するようになっています
30. 30 AWS Lambdaとの組み合わせにおける注意点 ⚫ AWS LambdaとAmazon RDS/Amazon Auroraの組み合わせはコネクションの枯 渇問題を起こしやすくなります AWS Lambdaのようなサーバーレス関数は短時間に大量に起動するためです 大量に起動・終了するため、AWS Lambda側でコネクションプーリングするのも難しいで す ⚫ これを回避するために、Amazon RDS Proxyというコネクションプーリングの専用サービ スがあります
31. 31 データベースサービスは組み合わせて良い ⚫ 先述した通り、業務システムにおいては迷ったらRDBMS(Amazon RDS/ Amazon Aurora)だと思いますが、全部をRDBMSでやる必要はありません ⚫ AWSには多数のデータベースサービスがあるので、突き詰めるとそれらを組み合わせ た方が有利になります ⚫ 例えば、大量かつ頻繁に読み書きをする部分はAmazon DynamoDBの方が適 しているし、セッション管理はRDBMSよりもAmazon ElastiCacheの方が適して います。
32. 32 CloudWatch Database Insightsの保持期間に注意 ⚫ Amazon RDS/Amazon Auroraにおいて、遅いクエリの特定や改善案の検討 にはCloudWatch Database Insights（旧Performance Insights）が便 利です ⚫ 性能の課題をベンダーやAWSサポートに相談する場合にも便利です ⚫ 一方で、CloudWatch Database Insightsは無料だと7日分しかパフォーマン スデータ履歴を保持しないことを覚えておいてください 相談しようとした場合に肝心のパフォーマンスデータが既に消失しているということが 起き得ます
33. 33 移行スケジュールに最適化のための期間を設ける ⚫ オンプレミスのデータベースをAWSに移行する場合、設計・実装も重要ですが、改 めて性能に関するテストの期間を明確に設けることをお勧めします ⚫ 一通り揃わないと見つけられない性能問題は存在し得るからです 次頁から次の章に移ります 設計 実装 性能に関するテスト 機能に関するテスト 移行プロジェクトの進行
34. 直近で発表されたデータベース系の アップデートについて
35. 35 11月から2月13日までのDB系アップデート ⚫ 2025年11月から、本資料執筆時点の2026年2月13日までのAWSのデータ ベース系のアップデートを一覧にまとめました ⚫ 次のページからアップデートの傾向と、気になるアップデートをピックアップします
36. 36 Oracle Database@AWSが東京リージョンでGA ⚫ Oracle Database@AWSが3つの新しいリージョン（US-East-2、EU- Central-1、AP-Northeast-1）でGA（一般提供開始）  EUと日本の顧客がデータ居住性要件を満たしながらOracle ExadataアプリケーションをAWSに移行可 能  計5つのリージョンでOCI Exadata Database Service、OCI Autonomous Database on Dedicated Infrastructure、OCI Autonomous Recovery Serviceが利用可能  AWS Marketplace経由でのプライベートオファー要求とAWS Management Consoleでのリソース設 定が必要 ⚫ Oracle Database@AWSの持つ意味  エンタープライズ系システムのクラウド移行における巨大な壁を取り払うこと  OCIのハードウェア（Exadata等）を物理的にAWSのデータセンター内に配置することで、アプリ （AWS）とDB（Oracle）の間のネットワーク遅延を低減  同時にデータ居住性要件をクリアする
37. 37 順調に進化するAmazon Aurora DSQL ⚫ Amazon Aurora DSQLはAWSの提供する分散データベース ⚫ AWSが分散データベースを提供し、進化させ続けていることは、分散データベースと いうジャンルにとって意味があるだろう ⚫ DSQLについては別の機会に改めてお話しします
38. 38 Amazon Aurora PostgreSQLの動的データマスキング ⚫ pg_columnmask拡張機能による動的データマスキングをサポート ⚫ ユーザーの権限に基づいた機密データアクセス制御が可能 ⚫ GDPR、HIPAA、PCI DSSなどのデータプライバシー規制への準拠を支援 ⚫ 組み込み関数やユーザー定義関数を使用した柔軟なマスキングポリシーの作成が 可能 ⚫ DSQLや最近の特徴的な機能追加がPostgreSQL系によっていることに注目 ➢ 参考：Amazon Aurora PostgreSQLの動的データマスキング登場：今こそ整理するRLSとCLSの違い
39. 39 AWS DatabasesがVercel Marketplaceで利用可能に ⚫ AWS DatabasesがVercel Marketplaceで一般提供開始  Amazon Aurora PostgreSQL  Amazon Aurora DSQL  Amazon DynamoDB ⚫ VercelからAWSデータベースを数秒で作成・接続可能 ⚫ サーバーレスオプションにより使用時のみの課金でコスト削減 ⚫ 自然言語プロンプトを使用してWebアプリケーションを構築できる「Vercel v0」で も利用可能 ⚫ AI駆動開発とバックエンドの隠蔽化（Backend as a Service化）の肯定 ➢ 参考①：Vercel マーケットプレイスで AWS データベースが入手可能に ➢ 参考②：Vercel の v0 で AWS データベースが使用可能に
40. 40 Amazon Aurora PostgreSQLのKiro powers ⚫ Kiro powersは、AWSが提供するAIエージェント「Kiro」の機能を拡張し、特定 の技術やドメインに関するツールや専門知識を動的に追加できるプラグインシステム  MCP Serverとの違いは動的追加機能によるコンテキストの効率性 ⚫ Aurora PostgreSQL用のKiro powersは、データベース開発ガイダンスと専門 知識をAIエージェントに提供 ⚫ データプレーンとコントロールプレーン操作の両方をサポート ⚫ Kiro IDEとウェブページでワンクリックインストール可能 ⚫ AIによるデータベースアクセスの増加の可能性を感じさせるアップデート ⚫ 参考①：Kiro powers ⚫ 参考②：Amazon Aurora PostgreSQL が Kiro powers との統合をサポート 次頁から次の章に移ります
41. 最後に
42. 42 最後に ⚫ 今回はAWSのデータベースの知識を広く紹介しました ⚫ AIの隆盛に伴うアプリケーション開発の仕方の変化により、データベースの役割・運 用・トレンドは変化しています ⚫ 次の機会には、今回触れられなかったKiro powersやOpenSearchを用いたベ クトルデータベースの紹介などをお届けしたいと思います