DynamoDBとAthenaの特徴と構成例

最終更新日:2026年8月10日

この記事でわかること

はじめに

項目 AWS Microsoft Azure Google Cloud
世界シェア 約33%(首位) 約22% 約11%
強み サービス数・実績 Microsoft製品連携 データ分析・AI
無料枠 12ヶ月+常時無料 12ヶ月無料 常時無料枠あり
主な資格 CLF / SAA / SAP AZ-900 / AZ-104 ACE / PCA

AWSのデータベースサービスであるDynamoDBとAthenaの特徴と用途と構成例についてまとめました。

DynamoDBの特徴と用途

Amazon DynamoDBは、ECサイトAmazon.comで利用していたRDBMS(リレーショナルデータベース管理システム)のスケール限界を超えるために開発されたデータベースが起源と言われています。

DynamoDBには、RDBMSにはない特徴があります。データを複数のコンピュータに分散的に配置できるため、ハードウェアを増やした分だけ性能が向上します。複数のアベイラビリティーゾーン(AWSの各リージョンに存在するデータセンター)で冗長化する構成でもパフォーマンスが劣化せず、ストレージも自動拡張されるため、利用者は考慮不要です。

データの操作方法もRDBMSとは異なります。NoSQLのため、SQLではなく、AWSのサービスをコマンドラインから操作し、管理するためのツールであるAWS CLIや各種AWS SDKを利用してAPIベースで行います。

基本的にはキーをJSON(JavaScript Object Notationの略で、XMLなどと同様のテキストベースのデータフォーマット)形式で指定してデータを操作するため、検索や集計など複雑なクエリは向いていません。ただDynamoDBはスキーマレスなため事前のスキーマ定義の必要がなく、同じテーブル内で違うカラムのデータも扱えます。

利用用途としては、ユーザー情報の格納やバッチ処理、アプリケーションのメタ情報の格納などです。インフラの管理がいっさい不要なため、運用スクリプトのちょっとしたデータ格納にも利用できます。APIベースでデータ操作を行うため、サーバーレス構成時のデータベースとしても選択されることが多いです。

DynamoDBはトランザクションや複雑なクエリに向いていないため、アプリケーションの特性に合うかは事前に検証が必要です。

DynamoDBの構成例

DynamoDBは抽象度の高いサービスです。利用者側はAPIでDynamoDBにアクセスします。DynamoDBにアクセスするための認証についてはIAM(AWS Identity and Access Management :AWS リソースへのアクセスを安全に管理するためのウェブサービス)を使います。IAMポリシーにより、アクセスするテーブルや読み書き権限を指定します。DRマルチリージョン用途としてグローバルテーブルを作成することもできます。

Athenaの特徴と用途

Amazon Athena(以下Athena)はデータレイク(多数のソースからのビッグデータを元のままの多様な形式で保持する中央ストレージリポジトリ)上のデータにSQLでアクセスできるサービスです。AWSではS3がデータレイクの役割を果たします。
S3とは、Amazon Simple Storage Serviceの略で、Amazon Web Services によって提供されるオンラインストレージのWebサービスのことです。Amazon S3は、Webサービスのインタフェースを介してストレージを提供しています。 Athenaはスキーマの定義が不要なデータベースです。

目的に応じ使用できるように膨大なデータを格納するシステムであるデータウェアハウスのRedshiftなどは、事前にスキーマを定義、整形してロードする必要がありますが、AthenaはS3へのデータ保存時にスキーマ定義は不要です。
ただし、S3に保存されたデータからデータベースを作成するときにはスキーマを定義します。  データレイクとして利用するS3は、データを無制限に保存できる拡張性、複数のアベイラビリティーゾーンをまたいだ構成による高可用性と耐久性を持つオブジェクトストレージ(データをオブジェクト単位で扱うストレージのアーキテクチャ)です。

AthenaはS3に保存されたデータに対し、SQLクエリを使ってデータ分析します。
サーバーレスのためインフラ管理が必要なく、大規模データに対しても高速なクエリを実行できるのが特徴です。

利用用途としては、データレイク上のデータをBI(ビジネス・インテリジェンス:企業の情報システムなどに蓄積される膨大な業務データを収集して分析し、その結果を可視化し、業務や経営の意思決定に活用する仕組み)や機械学習、データ探索に利用します。データがアクセスログなら、行動分析や障害調査などに利用します。Athenaはデータの加工ではなく、分析や可視化が得意なサービスです。

Athenaの構成例

【要注意】クエリエンジンに関する記述を更新
以前はAthenaのクエリエンジンを「Prestoを利用」とだけ説明していましたが、現行のAthenaエンジンバージョン3はPresto由来の技術をベースにしつつ、Trinoコミュニティの改善も継続的に取り込む形で開発が進められています。単純に「Presto」とのみ説明するのは古い前提です。

Athenaはサーバーレスのためインフラ管理が不要です。分散クエリエンジンであるPresto由来の技術をベースに、Trinoコミュニティの改善も取り込みながら開発が進められているエンジンを利用しており、メモリ上で処理します。AthenaへのSQLクエリは各種AWS SDKやJDBC(Java Database Connectivity は、Java と関係データベースの接続のためのAPI)、アプリケーションソフトがデータベース管理システムなどに接続し、データの取得や書き込み、操作などを行う方法の標準を定めたODBCで行い、認証はIAMで行います。

テーブル情報(カラムやS3上のデータの場所)、パーティション情報などはAWS Glueのデータカタログ機能を利用します。データの可視化はAmazon QuickSightが利用できます。
料金はクエリのスキャンデータ数がベースとなります。パーティション、データの圧縮、効率的な列指向フォーマットに変更するといったチューニングが可能です。クエリの同時実行数やタイムアウトに上限があるので注意が必要です。AWSへの上限緩和申請や、スキャンデータの削減でクエリ速度を上げます。なお、具体的な料金は変更される場合があるため、最新料金はAWS公式サイトでご確認ください。

押さえておきたいポイント

  • DynamoDBはNoSQL型でスキーマレス、複数のコンピュータへの分散配置により高いスケーラビリティを持つ一方、複雑なクエリやトランザクション処理には不向きなため、用途に応じた設計判断が必要です。
  • Athenaはデータレイク(S3)上のデータにSQLでアクセスできるサーバーレスサービスで、事前のスキーマ整形が不要な点がRedshiftなどのデータウェアハウスとの大きな違いです。
  • Athenaの料金はスキャンしたデータ量に応じて課金されるため、パーティション設計やデータ圧縮、列指向フォーマット(Parquet等)への変換によるコスト最適化が重要です。

よくある質問

DynamoDBとAthenaはどう使い分ければよいですか?

DynamoDBはアプリケーションからAPIベースで高速に読み書きするオンライン処理(ユーザー情報の格納やメタ情報管理など)に向いています。一方Athenaはデータレイク上に蓄積されたデータをSQLで分析・可視化する用途に向いており、リアルタイムのトランザクション処理には使いません。目的がアプリケーションのデータストアなのか、データ分析なのかで選択します。

Athenaを使う前にS3側で何か準備は必要ですか?

S3へのデータ保存自体にスキーマ定義は不要ですが、Athenaでクエリを実行するにはAWS Glueのデータカタログ機能などを使ってテーブル情報(カラム定義やS3上のデータの場所)やパーティション情報を定義する必要があります。

DynamoDBのスケーラビリティに上限はありますか?

DynamoDBはデータを複数のコンピュータに分散配置する設計のため、ハードウェア(キャパシティ)を増やすことで性能を拡張できます。ストレージも自動拡張されるため利用者側での容量管理は基本的に不要ですが、実際の性能はテーブル設計(パーティションキーの選び方等)にも左右されるため、事前の設計検証が重要です。

▼ アクロビジョンについて

👔

一緒に働きましょう

一人ひとりのキャリアに向き合い、
活躍できる現場をご紹介します。

採用サイトを見る →
💻

システム開発のご依頼・ご相談

コンサルティングから運用保守まで、
ワンストップで対応します。

まずはお気軽にご相談ください →