[アップデート] Amazon DynamoDB Accelerator (DAX) が大阪リージョンで使えるようになりました

いわさです。

先日のアップデートで Amazon DynamoDB Accelerator (DAX) が、大阪リージョンを含む 17 リージョンで新たに利用できるようになりました。

https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-dynamodb-accelerator/

DAX は DynamoDB の前段に置くインメモリキャッシュで、読み取りの多いワークロードの性能向上したい時に採用します。
東京リージョンでは以前から使えていましたが、大阪リージョンはこれまでずっと対応リージョンに入っていませんでした。
そのため東京・大阪の 2 リージョンで国内 DR を組みたいような時、大阪だけ DAX が使えないので東京でも採用できないというシーンがありました。
今回の追加で、東京・大阪のどちらでも同じように DAX を含めた構成を組めるようになりました。

今回こちらを確認してみたので紹介します。

実際に大阪リージョンで DAX クラスターを作ってみる

では早速、大阪リージョン（ap-northeast-3）で DAX クラスターを作ってみましょう。

コンソールのリージョンをアジアパシフィック (大阪) に切り替えて、ノードタイプ dax.t3.small のクラスターを 1 ノードで作成しました。

リージョンがアジアパシフィック (大阪)、状態が利用可能、エンドポイントも dax:// で払い出されています。
ノードは大阪のアベイラビリティーゾーン（ap-northeast-3c）で作成され、エンドポイントのドメインも dax-clusters.ap-northeast-3.amazonaws.com と大阪リージョンのものになっていますね。良いですね。

ノードタイプの選択肢やエンドポイントの払い出し方は東京リージョンで使っていたときと同じで、大阪でもそのまま使えます。

せっかくなので、大阪リージョンの EC2 からこの DAX クラスターにアクセスして、ちゃんとキャッシュとして速くなるかまで見てみます。

DAX のエンドポイントは VPC 内からアクセスする前提なので、クラスターと同じ VPC・同じセキュリティグループに EC2 を 1 台立てて検証してみます。
アプリ側は boto3 だけでなく、DAX 用のクライアント（Python なら amazon-dax-client）も入れました。

pip install amazon-dax-client boto3

接続先には、クラスターのディスカバリエンドポイントに dax:// を付けて指定します。
エンドポイントは次のコマンドで確認できます（コンソールのクラスター一覧のエンドポイント欄にも出ています）。

aws dax describe-clusters --cluster-names hoge-dax-osaka --region ap-northeast-3 \
  --query 'Clusters[0].ClusterDiscoveryEndpoint.Address' --output text
# hoge-dax-osaka.xxxxxx.dax-clusters.ap-northeast-3.amazonaws.com

あとは DynamoDB の resource を DAX クライアントに差し替えるだけです。
get_item などの呼び出し方は boto3 と同じなので、接続部分を差し替えれば既存コードを DAX 経由にできます。

import boto3
from amazondax import AmazonDaxClient  # パッケージ名は amazon-dax-client、import 名は amazondax

REGION = "ap-northeast-3"
DAX_EP = "dax://hoge-dax-osaka.xxxxxx.dax-clusters.ap-northeast-3.amazonaws.com"

# DAX 経由。boto3.resource("dynamodb") の代わりにこれを使う
dax = AmazonDaxClient.resource(endpoint_url=DAX_EP, region_name=REGION)
table = dax.Table("hoge-dax-demo")

item = table.get_item(Key={"pk": "item-001"})["Item"]
print(item)

性能比較してみた

せっかくなので大阪の EC2 を使って、大阪の DAX、大阪の DynamoDB 直、東京の DAX、東京の DynamoDB 直の 4 通りのアクセス先でレイテンシを測ってみました。
東京側は検証用に、同じテーブルと DAX クラスターを東京リージョンにも用意しました。そのうえで大阪の VPC とクロスリージョンの VPC ピアリングでつなぎ、大阪の EC2 から東京の DAX へ届くようにしています。

各パターンでウォームアップ後に get_item を 10 回実行した平均です。

1. 大阪の DAX       : avg=0.566ms min=0.472ms max=0.738ms
2. 大阪の DynamoDB  : avg=2.919ms min=2.449ms max=3.444ms
3. 東京の DAX       : avg=6.864ms min=6.760ms max=7.027ms
4. 東京の DynamoDB  : avg=12.629ms min=11.668ms max=13.514ms

言うてもあんま変わらんかな？とか思っていたのですが、結構明確に差が出ましたね。
東京の DAX（6.9ms）より大阪の DynamoDB 直（2.9ms）のほうが速いんだな。

さいごに

本日は Amazon DynamoDB Accelerator (DAX) が大阪リージョンで使えるようになったので、実際にクラスターを作って大阪の EC2 から読み取りまで確認してみました。

これまで大阪未対応で DAX 採用を見送っていた方は再度ご検討してみたはいかがでしょうか。