Amazon Timestreamで時系列データを処理する手順は、2025年6月20日を境に前提が変わりました。サーバーレスのTimestream for LiveAnalyticsが新規顧客の受付を終了し、手を動かす対象がマネージドInfluxDBのエンジンへ移ったためです。この記事では2026年8月時点の仕様で、クラスタ作成からline protocolでの書き込み、SQLとInfluxQLでのクエリ、既存データのS3経由の移行までを実装順に整理します。掲載するコマンドはAWS公式ドキュメントと移行ツールの実ソースで確認したもので、公式の記載どおりに書くと動かない箇所も併せて示します。
まとめ：2026年のTimestream実装で押さえる要点
Timestream for LiveAnalyticsは2025年6月20日付で新規顧客への提供が閉じられ、新しく構築する環境はTimestream for InfluxDBが対象になります。2025年10月にInfluxDB 3への対応が加わり、単一ノードのCoreと、マルチノードとコンパクションを備えるEnterpriseから選ぶ構成になりました。
実装は、VPCとセキュリティグループを用意してクラスタを作り、Secrets Managerからオペレータートークンを取り出し、line protocolで書き込み、SQLかInfluxQLで読む順序で進みます。書き込みの推奨値は1リクエスト5,000〜10,000行または10MB、gzip圧縮、タグキーの辞書順ソートです。既存のLiveAnalyticsからの移行は、UNLOADを使う公式エクスポートツールでS3にParquetを出し、そこから取り込む二段構えになります。費用は、実使用量にかかわらず月200GB相当のストレージ最低課金が効くため、小規模構成ほど割高です。
実装前に決めるエンジンとエディションの選択
最初の分岐はどちらのエンジンで手を動かすかで、ここを取り違えると作成できないサービスの手順書をなぞることになります。サービスの位置づけや汎用DBとの使い分けから確認したい場合は、Amazon Timestreamとは？仕組み・2つのエンジンと料金モデル・採用判断を実装者目線で解説で前提を固めてから戻ってください。
LiveAnalytics新規受付終了後に選べるエンジン
AWSは公式ドキュメントで「close new customer access to Amazon Timestream for LiveAnalytics, effective 6/20/25」と明記しています。稼働中のワークロードには影響せず、既存顧客への改善投資は継続すると表明したうえで、新規顧客には機能が近いTimestream for InfluxDBの評価を推奨する、という書き方です。これから書き込みとクエリを実装する読者の対象はInfluxDBエンジン、既存のLiveAnalyticsを運用中の読者の対象は後半の移行手順、と読み分けてください。
InfluxDB 3のCoreとEnterpriseの選び分け
InfluxDB 3は、Apache Arrowによるインメモリ処理、Apache DataFusionによるクエリ実行、Amazon S3上のParquet列指向ストレージという構成に作り替えられたエンジンです。Coreは単一ノードのみでコンパクション機能を持たず、AWS公式ドキュメントは「数日程度の直近データを対象にしたニアリアルタイム用途向け」で、長期保存と分析には推奨しないと明記しています。Enterpriseはマルチノード構成とコンパクションを備え、3ノード構成はwriter兼readerが2ノードと専用コンパクタが1ノード、カスタムパラメータグループを使えば最大15ノードまで広げられます（専用コンパクタは3ノード以上で必須）。検証や単一EC2からの取り込みならCore、保持期間が数日を超える本番監視ならEnterprise、が実務上の分かれ目です。InfluxDB本体の設計思想やセルフホストとの比較はInfluxDBとは？時系列DBの仕組み・InfluxDB 3の設計から採用判断まで実装者向けに解説で扱っています。
ノードクラスとサイジングの決め方
ここでつまずくのがクラス名の二重表記です。請求やハードウェア諸元の表に出るのはdb.influxIOIncluded系ですが、CLIやAPIで指定するのはdb.influx系で、AWS自身も「請求書にはdb.influxIOIncludedと表示される」と注記しています。サイジングはカーディナリティ3,000万系列・1リクエスト5,000行を前提にした目安が公開されており、書き込みレートを起点に選ぶと外しません。
| 書き込み(行/秒) | クエリ(件/秒) | ノードクラス(請求表記) | vCPU/メモリ | エディション |
|---|---|---|---|---|
| 約150,000 | 25未満 | db.influxIOIncluded.large | 2/16GiB | Core |
| 約200,000 | 約25 | db.influxIOIncluded.xlarge | 4/32GiB | Core |
| 約250,000 | 約35 | db.influxIOIncluded.2xlarge | 8/64GiB | Enterprise |
| 約500,000 | 約50 | db.influxIOIncluded.4xlarge | 16/128GiB | Enterprise |
| 750,000未満 | 100未満 | db.influxIOIncluded.8xlarge | 32/256GiB | Enterprise |
| 750,000超 | 100超 | マルチノード構成 | クラス統一 | Enterprise |
クラスは最小のmediumが1vCPU・8GiB、最大の24xlargeが96vCPU・768GiBまで並びます。AWSはCPUとメモリの平均使用率が65%程度に収まるクラスを推奨しており、スパイクの余地として一段上を取るのが安全です。クラスタ内のノードは同じクラスに揃える必要があり、初期リリースでは作成後にノード数を変更できません。
クラスタ作成とネットワーク・認証の設定
作成前に決めるのは、VPCとサブネット、セキュリティグループの受信ルール、公開設定、待ち受けポートです。プライベート構成にする場合は、クラスタがS3を使う都合上、S3のVPCエンドポイントを先に作り、エンドポイントポリシーで必要な権限を許可しておく必要があります。共有VPCはInfluxDB 3では未対応です。
エディションをパラメータグループで指定するCLI手順
InfluxDB 3のクラスタはcreate-db-clusterで作ります。エディションは専用オプションではなくサービス定義のパラメータグループ識別子で決まり、Core単一ノードはInfluxDBv3Core、Enterprise 3ノードはInfluxDBv3Enterprise、Enterprise単一ノードはInfluxDBv3Enterprise1Nodeです。ここを誤ってcreate-db-instanceを使うと、InfluxDB 2系のインスタンスができあがります。
aws timestream-influxdb create-db-cluster \
--region ap-northeast-1 \
--name "issoh-metrics" \
--db-parameter-group-identifier "InfluxDBv3Core" \
--db-instance-type db.influx.large \
--vpc-subnet-ids subnet-12345abc subnet-67890def \
--vpc-security-group-ids sg-12345abc \
--publicly-accessible false4ノード以上にするときは、先にcreate-db-parameter-groupでingestQueryInstances（writer兼reader、1〜4）、queryOnlyInstances（読み取り専用、0〜13）、dedicatedCompactor、dataFusionNumThreadsを設定したカスタムグループを作り、その識別子を渡します。dataFusionNumThreadsはインスタンスのvCPU数に合わせるのがAWSの指示で、db.influx.2xlargeなら8です。クラスタ作成には10〜20分かかります。
トークンの取得場所とアクセス経路
クラスタ作成後のオペレータートークンはAWS Secrets Managerに保管され、シークレット名はクラスタ識別子と同じです。Enterpriseではデータベース単位に読み取り専用・書き込み専用・読み書きを割り当てるリソーストークンを発行でき、収集エージェントには書き込み専用、ダッシュボードには読み取り専用を渡す運用が組めます。トークンはHTTPヘッダーのAuthorization: Bearerで送り、influxdb3 CLIでは環境変数INFLUXDB3_AUTH_TOKENで渡します。401が返るときは、トークンの失効か対象データベースの読み取り権限不足を先に疑ってください。
influxdb3 query \
--host "example123-3ksj4dla5nfjhi.timestream-influxdb3.ap-northeast-1.on.aws:8086" \
--database "sensors" \
--token "REPLACE_WITH_TOKEN" \
"SHOW TABLES"ポート番号はドキュメント間で記述が割れているため、推測で開けないでください（詳細は後述のよくある質問）。
line protocolでの書き込み実装とTelegrafの設定
書き込み口は、新規実装で推奨されるネイティブの/api/v3/write_lp、InfluxDB 2系からの移行用の/api/v2/write、v1系からの移行用の/writeの3系統で、いずれもline protocolを受け付けます。v2互換APIではbucketパラメータがデータベース名に対応するため、既存のTelegrafやクライアントライブラリは向き先だけ差し替えれば動きます。
curl -v "https://example123-3ksj4dla5nfjhi.timestream-influxdb3.ap-northeast-1.on.aws:8086/api/v3/write_lp?db=sensors&precision=s" \
--header "Authorization: Bearer REPLACE_WITH_TOKEN" \
--data-raw "home,room=kitchen temp=21.1,hum=35.9,co=0i 1735545600"挙動を変えるパラメータが2つあります。no_syncをtrueにするとWALへの永続化を待たずに応答を返すため遅延は最小ですが、クラッシュ時にデータを失う可能性があります。accept_partialは既定でtrueで、不正な行だけを弾いて有効な行を書き込み、400と失敗行の詳細を返します。全件成功か全件失敗かを担保したいバッチではfalseにします。
スループットを落とさない書き込みの実装値
AWSがInfluxDB 3向けに挙げる推奨値は、1リクエストあたり5,000〜10,000行または10MB、大きなペイロードはgzip圧縮、タグキーは辞書順ソート、タイムスタンプは目的に足る最も粗い精度を明示指定、というものです。書き込み先はwriter兼readerのエンドポイントとし、複数コネクションへ分散させます。Telegrafで収集する場合の設定は次の形です。
[agent]
interval = "10s"
metric_batch_size = 5000
precision = "0s"
[[outputs.influxdb_v2]]
urls = ["https://example123-3ksj4dla5nfjhi.timestream-influxdb3.ap-northeast-1.on.aws:8086"]
token = "REPLACE_WITH_TOKEN"
organization = "issoh"
bucket = "sensors"ここは公式ドキュメントを写すと動かない箇所です。AWSの開発者ガイドはmetric_batch_sizeの値をクォートで囲って載せていますが、この設定は整数型のため、文字列のままでは「cannot unmarshal TOML string into int」で読み込みに失敗します。token・organization・bucketを省いた設定も、起動はできてもbucketとorgが空のまま送信されて書き込みが失敗します。content_encodingの指定は不要で、influxdb_v2出力は未指定でもgzipが既定です。precisionの”0s”は精度をゼロにする意味ではなく収集間隔から自動決定する指定で、interval = “10s”ならタイムスタンプは秒相当に丸められます。
スキーマ設計でつまずくInfluxDB 3固有の制約
InfluxDB 3はスキーマオンライトで、最初の書き込みでテーブルとスキーマが自動生成され、以降はそのスキーマに対して検証されます。タグは作成後に型を変更できず、同一テーブルでタグとフィールドに同じ名前は付けられず、フィールドの型も書き込みごとには変えられません。設計の勘所は、リクエストIDやハッシュのようにほぼ一意な値をタグに入れないことに尽きます。なお「1インスタンスあたり1,000万系列キー」という上限の目安はTSMエンジンを使うInfluxDB 2系の数値で、InfluxDB 3のページには数値上限がなく「タグのカーディナリティを抑える」とのみあります。実測に使われてきたFluxのcardinality関数やInfluxQLのSHOW SERIES CARDINALITYも対応機能として挙げられていないため、2系の運用手順を持ち込まないでください。
SQL・InfluxQLでのクエリと可視化の実装
InfluxDB 3が対応するクエリ言語はSQLとInfluxQLです。主言語はApache DataFusionが実行するSQLで、InfluxQLは後方互換として残る位置づけです。2.x系で書いてきたFluxのクエリはInfluxDB 3の対応言語として挙げられていないため、移行時は書き換え前提で工数を見積もってください。
SELECT time, temperature, location
FROM weather
WHERE time > now() - INTERVAL '1 hour'
ORDER BY time DESC
LIMIT 100実行経路はHTTPとFlight（gRPC）で、手元からはinfluxdb3 CLI、v3のHTTPクエリAPI、v1互換API、InfluxDataが配布するWeb UIのInfluxDB 3 Explorerが使えます。Explorerは自前で動かす形のため、プライベート構成では同一VPC内のEC2や踏み台、VPN経由で起動します。
クエリが遅いときに確認する箇所
まず疑うのはスキャン対象のParquetファイル数で、query-file-limitの設定を確認します。次にインスタンスサイズに対するDataFusionのスレッド数、再起動直後ならParquetのメモリキャッシュが冷えている可能性です。Enterpriseではコンパクションの稼働も必ず見ます。止まると小さなファイルが積み上がり、時間の経過とともに性能が落ちます。直近値や一意なメタデータの取得は、last-valueキャッシュとdistinct-valueキャッシュを使えば特定のユースケースで10ミリ秒未満の応答が期待できるため、ダッシュボードの最新値表示はこちらへ寄せると効きます。
Grafanaのデータソース設定と権限の絞り方
可視化は、InfluxDB互換のデータソースを持つGrafanaを繋ぐのが最短です。ダッシュボード用のサーバーを増やしたくない場合はAmazon Managed Grafanaとは？機能・料金・データソースと始め方で扱ったマネージド版を使い、データソースにはクラスタの読み取り用エンドポイントと、対象データベースの読み取り専用リソーストークンだけを設定します。書き込み権限を持つオペレータートークンをダッシュボードに置かない一線を最初に引いておくと、トークン失効時の影響範囲も切り分けやすくなります。
既存LiveAnalyticsデータのS3エクスポートと移行
AWSの移行ガイドは移行先を、多くのワークロードで推奨されるTimestream for InfluxDB 3、低レイテンシの運用系ワークロード向けのTimestream for InfluxDB 2、時系列以外の用途に使うAuroraまたはRDS for PostgreSQLの3つに整理しています。移行先を問わず、まずS3へエクスポートして中間層を作る進め方が推奨手順です。
UNLOADを使ったエクスポートの実行
エクスポートには、awslabsのamazon-timestream-toolsリポジトリ（mainlineブランチ）のtools/python/liveanalytics_migration_scripts/unload/unload.pyを使います。同じリポジトリのcopy-table配下にも同名のスクリプトがあるので取り違えないでください。内部でTimestreamのUNLOADを呼び、指定した時間範囲をバッチに分割して出力します。
python unload.py \
--export-table \
--database MyDB \
--table MyTable \
--start-time '2024-05-14 00:00:00' \
--end-time '2025-05-14 00:00:00' \
--partition month \
--export-format PARQUET \
--compression NONE \
--region ap-northeast-1 \
--s3-uri s3://my-bucket \
--enable-dynamodb-logger trueここも公式ドキュメントの表記をそのまま打つと落ちます。開発者ガイドの例はオプション名をアンダースコアで書いていますが、実ソースのargparseが定義しているのはすべてハイフン区切りで、–enable-dynamodb_loggerや–export-all_databasesはunrecognized argumentsで終了します。分割サイズも重要で、1パーティションを約350GB未満に収めないと「The query computation exceeds maximum available memory」で失敗します。年単位で超えるなら月単位、それでも溢れるなら日単位や時間単位へ落とし、1バッチの幅を決める–custom-partition-count（既定99）も併せて下げます。
切り替えを段階に分ける進め方
書き込み経路を先に二重化し、過去データのエクスポートと取り込みを裏で走らせ、最後にクエリ側を切り替える順序が事故を減らします。–recent-first trueを付けると新しいデータから出力されるため、直近データで新環境のダッシュボードを先に立ち上げ、古いデータを後から埋める進め方も取れます。DynamoDBロガーを有効にすると設定内容とエクスポート件数が残り、完全性の検証に使えます。ただし自動で再開する機能はないため、失敗時は記録から失敗バッチを特定し、同じ–migration-tagと該当する–start-timeで手動再実行します。
コスト設計と実装を見送るべき条件
ここは判断を言い切ります。InfluxDB 3で効いてくるのは下限です。稼働時間は1秒単位で計算されるものの課金対象の状態変化のたびに最低10分ぶんが計上され、ストレージには実使用量にかかわらず月200GB相当の最低課金があります。EnterpriseはvCPU時間あたりのInfluxDataライセンス料がAWS Marketplace経由で別建てになります。データが数GBしかない検証環境でも、この下限は消えません。なお同一VPC内やAZ間の転送は、InfluxDB 3の課金コンポーネントとしては無料と記載されている一方、料金ページはAZをまたぐEC2との通信に両側のリージョン内データ転送料金がかかると書いています。記述が割れているため、AZ分散の構成は料金ページで自分の構成に当てて確認してください。
小規模な時系列でTimestreamを見送る判断基準
秒間の書き込みが数百行に届かず保持期間も短いなら、専用の時系列基盤は過剰です。既存の業務データベースに1テーブル追加して済むなら、Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説で整理したマネージドのリレーショナルDBに寄せるほうが、運用対象もコストも増えません。PostgreSQLで時系列の集計だけ強化したい場合は、拡張で解くTimescaleDBとは？PostgreSQL拡張の仕組みと採用可否の判断基準が、200GB最低課金を踏まずに済む現実解です。Timestreamが効くのは、秒〜分粒度の計測値が大量に積み上がり、時間軸の集計が分析の主役で、TelegrafやGrafanaを含む時系列エコシステムに乗せたい、という条件が同時に成り立つ場合に限られます。
Core構成を長期保存に使わない理由
Coreは単価が安く単一ノードで済むため検証では選ばれがちですが、コンパクションが無いためデータが古くなるほどクエリ性能が落ちます。AWS自身が長期保存と分析には推奨しないと書いている以上、「まずCoreで作って様子を見る」は数か月後に性能劣化の調査工数を払う選択と同義です。作成後はノード数もパラメータグループも変更できず、構成だけ後から差し替える逃げ道もありません。保持期間が数日を超える本番監視は、最初からEnterpriseで見積もってください。
よくある質問
Amazon Timestreamは今から新規に使えますか？
Timestream for LiveAnalyticsは2025年6月20日付で新規顧客へのアクセスが閉じられ、稼働中のワークロードと既存顧客の利用のみ継続します。新規構築の対象はTimestream for InfluxDBです。
InfluxDB 3ではFluxのクエリを使えますか？
AWS公式のInfluxDB 3向けドキュメントが対応クエリ言語として挙げているのはSQLとInfluxQLで、Fluxの記載はありません。2.x系でFluxを使ってきた場合は、SQLかInfluxQLへの書き換えを移行工数に含めてください。
接続先のポート番号は何番ですか？
AWS CLIリファレンスは既定値をInfluxDB 2系が8086、InfluxDB 3系が8181と記載する一方、開発者ガイドの接続例やcurlの例はInfluxDB 3でも8086を使っており、記述が一致していません。指定範囲は1024〜65535で、2375〜2376・7788〜7799・8090・51678〜51680は予約済みです。作成時の指定値をget-db-clusterの出力で確認してからセキュリティグループを開けてください。
Timestreamの料金はどの単位で決まりますか？
ノードクラス別の稼働時間、S3上の実データ量、リージョン外へのデータ転送で決まります。稼働時間は1秒単位で計算されますが課金対象の状態変化ごとに最低10分ぶんが計上され、ストレージには実使用量にかかわらず月200GB相当の最低課金があります。EnterpriseはvCPU時間あたりのライセンス料がAWS Marketplace経由で加わり、S3へのI/O費用はノード単価に含まれます。
既存のLiveAnalyticsから移行するときの最初の一歩は何ですか？
移行先を問わず、まずS3へのエクスポートで中間層を作ることがAWSの推奨手順です。awslabsが公開するexport tool（unload.py）でUNLOADを実行し、1パーティションを約350GB未満に収めて出力します。移行先がTimestream for InfluxDBなら形式はParquet、圧縮はNONEを指定し、DynamoDBロガーを有効にして件数を記録できる状態にしてから本番データに着手してください。
関連記事
- Amazon Timestreamとは？仕組み・2つのエンジンと料金モデル・採用判断を実装者目線で解説：本記事の前段にあたる、エンジン選定と採用可否の判断をまとめた記事
- InfluxDBとは？時系列DBの仕組み・InfluxDB 3の設計から採用判断まで実装者向けに解説：Timestreamが採用するInfluxDB本体の設計とセルフホストとの比較
- Amazon Managed Grafanaとは？機能・料金・データソースと始め方：書き込んだ時系列データを可視化するダッシュボード側の構築手順
- TimescaleDBとは？PostgreSQL拡張の仕組みと採用可否の判断基準：専用の時系列基盤が過剰な規模で検討するPostgreSQL拡張の選択肢
- Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説：少量の時系列を汎用リレーショナルDBで持つ場合の比較対象
