本記事は、 Timestream for InfluxDB 3 workload analysis and best practices を翻訳したものです。 Amazon Timestream for InfluxDB 3 のデプロイメントにおいて、適切なインスタンスサイズの選択は、時系列インフラストラクチャを設計する上で最も影響の大きい判断の 1 つです。インスタンスが小さすぎるとクエリパフォーマンスの低下や取り込みのボトルネックにつながり、大きすぎると未使用のキャパシティに対して余分なコストを支払うことになります。 本記事では、デプロイメントのサイジングの選び方について解説します。このガイドを参考に、お客様のビジネスユースケースに合った Timestream for InfluxDB 3 の構成を選択してください。Amazon Timestream for InfluxDB 3 を今すぐ使い始めるには、 ドキュメント をご覧ください。 サイジングのガイダンス パフォーマンス特性の理解 Amazon Timestream for InfluxDB 3 のデプロイメントに適切なインスタンスサイズを選択するには、ワークロードパターンごとのデータベースの挙動を把握することが重要です。 時系列データベースのパフォーマンスは、相互に関連する多くの要因に左右されます。クエリの複雑さはパフォーマンスに大きく影響します。直近のデータに対するシンプルな集計は、数か月分の履歴データにまたがる複雑な分析クエリとはパフォーマンスが異なります。データモデルも大きく影響します。数百万のユニークなタグの組み合わせを持つ高カーディナリティのデータセットは、低カーディナリティのモニタリングデータとは異なるパフォーマンス特性を示します。バッチサイズ、取り込みレート、ラインプロトコルポイントの構造といった書き込みパターンもパフォーマンスに影響します。 同時実行される操作には、固有の考慮事項があります。複数のアプリケーションがデータベースに同時にクエリを実行しながらデータの取り込みも継続している場合、取り込みとクエリ処理の間でリソースのバランスを取る必要があります。クエリの時間範囲も大きな影響を与えます。InfluxDB 3 のキャッシュとインメモリ最適化により直近のデータへのクエリは非常に高速であり、履歴データへのクエリ（Enterprise クラスターの場合）はコンパクター（圧縮を行うコンポーネント）と Parquet ストレージを使用して効率的に取得します。 本記事の目的は、お客様のワークロードに対する正確な予測を提供することではなく、デプロイメントの出発点となる情報を提供することです。 データとクエリに関する考慮事項 クエリと取り込みのパフォーマンスを向上させるには、以下の点を考慮してください。 カーディナリティが低い場合（ユニークなタグの組み合わせが少ない場合）、クエリがフィルタリングする必要のある系列が少なくなるため、パフォーマンスが向上する可能性があります。InfluxDB 3 ではカーディナリティは問題ではなくなりましたが、カーディナリティが際限なく増加してもパフォーマンスに影響がないわけではありません。クエリ操作のメモリ使用量が増え、圧縮パフォーマンスにも影響する可能性があります。 クエリがシンプルな場合（集計ではなく単一フィールドの取得など）、InfluxDB 3 の Last Value Cache の恩恵を受け、大幅に高速なレスポンスタイムが得られます。クエリが生データに対して数時間または数日にわたる集計を行う場合、データサイズの増加に伴いクエリパフォーマンスは低下します。可能な限り処理エンジンを使用して ダウンサンプリング を行い、クエリ結果として表示したい形式に合わせてデータを事前にフォーマットしてください。 書き込みバッチが大きい場合（medium から 4xlarge インスタンスでは 1 バッチあたり 5,000 ポイント、より大きなインスタンスでは 1 バッチあたり 10,000 ポイント以上）、リクエストあたりのオーバーヘッドが減少するため、書き込みスループットが向上します。 クエリが直近のキャッシュウィンドウを超える長い時間範囲や履歴データを対象とする場合、すべてのエディションで利用可能な ダウンサンプリング と、Enterprise エディションで利用できるコンパクター（圧縮を行うコンポーネント）により、良好なパフォーマンスを維持できます。 同時読み取りユーザーが少ない場合、多数の同時操作にリソースが分散されないため、クエリあたりのパフォーマンスが向上します。 デプロイメントの監視 インスタンスのデプロイ後、サイジングの妥当性を検証し、最適化の余地がないかを確認するため、パフォーマンスをモニタリングすることが重要です。Amazon CloudWatch は、CPU 使用率やメモリ使用量など、Timestream for InfluxDB 3 の重要なメトリクスを提供します。InfluxDB 3 の処理エンジンに含まれる System Metrics Plugin は、CloudWatch と同様のサーバーレベルのパフォーマンスデータを収集します。これには、詳細な CPU 統計（全体およびコアごと）、メモリ使用量の内訳、ディスク I/O パフォーマンス、ネットワークインターフェイス統計が含まれます。詳細な長期メトリクスについては、CloudWatch が 10 秒ごとに同じ粒度でメトリクスを記録するのに対し、System Metrics Plugin は カスタムスケジュール を設定できるため、CloudWatch よりも適しています。 データベース固有のパフォーマンスメトリクスについてより深い洞察を得るには、メトリクスエンドポイントをスクレイピングすることで、クエリパフォーマンス、書き込みスループット、その他のサービスレベル指標を詳細にモニタリングするための包括的な内部メトリクスを収集できます。Timestream for InfluxDB インスタンスの /metrics エンドポイントをスクレイピングする包括的なメトリクス収集ソリューションを提供しています。このソリューションは、 Telegraf を実行する Amazon EC2 インスタンスをデプロイし、クエリパフォーマンス、書き込みスループット、メモリ使用パターンなどの内部エンジンメトリクスを継続的に収集した後、CloudWatch に取り込み、事前設定された Grafana ダッシュボードで可視化します。ダッシュボードには、インスタンスのサイジング仕様に基づく主要パフォーマンス指標をモニタリングするパネルが含まれており、サイジングの判断の検証と最適化の機会の特定に役立ちます。 デプロイメントの手順、設定オプション、サンプルスクリプトについては、 GitHub リポジトリ をご覧ください。リポジトリには、Telegraf の設定から Grafana ダッシュボードの作成まで、セットアッププロセスを自動化する AWS CDK アプリケーションが含まれています。 サイジングの始め方 最初にデプロイメントを計画する際は、以下のアプローチを推奨します。 ベースライン要件を見積もる : 予想される書き込みレート（1 秒あたりのポイント数）とクエリの同時実行数（同時クエリ数）を計算します。データ量の増加や負荷のスパイクに備え、バッファを持たせてください。 開始するインスタンスサイズを選択する : 理想的な条件でインスタンスサイズを決定するための目安として、以下を参考にしてください。ニーズにおおよそ合致するインスタンスをデプロイし、パフォーマンスに応じて調整します。 書き込み（1 秒あたりの行数） 読み取り（1 秒あたりのクエリ数） インスタンスクラス ~35,000 ~40 db.influx.medium <100,000 ~140 db.influx.large ~120,000 ~290 db.influx.xlarge ~130,000 ~400 db.influx.2xlarge ~140,000 ~425 db.influx.4xlarge <200,000 <430 db.influx.8xlarge ~200,000 <430 db.influx.12xlarge ~210,000 ~430 db.influx.16xlarge ~230,000 ~430 db.influx.24xlarge 直近のデータモニタリング（3〜5 日間）に重点を置いたワークロードの場合は、db.influx.xlarge から始めてください。 書き込みスループットやクエリの同時実行数がより高い要件には、db.influx.2xlarge または db.influx.4xlarge を検討してください。 最大スループットが必要な場合は、db.influx.8xlarge や db.influx.24xlarge で評価してください。 履歴データの保持と分析が必要な場合は、適切なインスタンスサイズで Enterprise エディションを選択してください。 インスタンスサイズとワークロード特性に応じて、デプロイメント用の パラメータグループ を作成し設定します。 本番相当のデータでテストする : 本番環境のカーディナリティと時間範囲に一致するデータセットをロードし、実際のクエリパターンを実行してパフォーマンスを検証します。 モニタリングと調整 : CloudWatch メトリクスと System Metrics Plugin を使用して、CPU、メモリ、クエリレイテンシー、書き込みスループットを監視します。リソース使用率が常に高い場合やパフォーマンスが低下している場合は、スケールアップしてください。 本番レベルで稼働する正常なインスタンスは、CPU とメモリの使用率が平均で 40%〜70% の間であるべきです。 通常 40% を下回っており、ワークロードが安定している場合は、オーバープロビジョニングです。 70% の閾値を超えるスパイクがある場合は、最適化またはスケーリングを検討してください。クエリは書き込みよりも CPU 使用率に大きな影響を与えることに留意してください。 ワークロードの変化に応じて、短時間のダウンタイムを伴いますがインスタンスサイズのスケールアップまたはスケールダウンが可能です。控えめな構成から始め、注意深くモニタリングし、お客様固有のユースケースから得られる実際のパフォーマンスデータに基づいて調整してください。 まとめ Amazon Timestream for InfluxDB 3 のデプロイメントを効果的にサイジングするには、スループット要件、クエリパターン、コストの考慮事項のバランスを取る必要があります。Amazon Timestream for InfluxDB 3 がお客様のビジネスニーズにどのように応えるかを判断する出発点として、本記事を活用してください。ワークロードパターン、クエリの複雑さ、履歴データのニーズを分析することで、要件に合った適切な構成を選択できます。 今すぐ Amazon Timestream for InfluxDB のドキュメント にアクセスし、ビジネスが求めるパワー、柔軟性、スケーラビリティを備えた時系列ワークフローの構築を始めましょう。 著者について Victor Servin Victor は AWS の Amazon Timestream チームのシニアプロダクトマネージャーです。プロダクトレッドグロース戦略やスケーラブルなアーキテクチャでスタートアップを支援してきた長年の専門知識を持ち、データドリブンなアプローチで Timestream のような分析プロダクトの普及を推進しています。豊富な経験とカスタマーサクセスへの取り組みにより、お客様が効率的に目標を達成できるようサポートしています。 Forest Vey Forest は Improving 社のチームリードです。時系列およびサーバーレステクノロジーの経験を持ち、クラウド開発と組み込みシステムへの情熱が高まっています。ソフトウェア開発の学習以外の時間では、友人とのロッククライミングやハイキングを楽しんでいます。 Trevor Bonas Trevor は Improving 社のシニアソフトウェア開発者です。時系列データベースと ODBC ドライバーの開発経験があります。プライベートでは小説の執筆や、ゲーム開発にも取り組んでいます。 Fred Park Fred は Improving 社のシニアソフトウェア開発者で、時系列データベースと AI エージェントのオブザーバビリティを専門としています。VR やクラウドサービスから量子コンピューティングまで幅広いバックグラウンドを持ち、新しいテクノロジーに惹かれています。コーディング以外の時間は、ハイキングに出かけたり友人と音楽を作ったりしています。 本記事の翻訳はクラウドサポートエンジニアの平出が担当しました。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 10 月 27 日 (火) 14:00 から、オンラインハンズオンワークショップ 「ハンズオンワークショップ：Amazon EKS で Platform Engineering を加速する」 を開催します。開発者が自分でアプリをデプロイできるセルフサービス型の仕組みは、リリースを速くできます。一方で、複数のツールを組み合わせる必要があり、インフラも複雑になります。前半の座学では、Platform Engineering の全体像と、社内の開発者向けに基盤を用意する内部開発者プラットフォーム (IDP) の考え方を整理します。後半のハンズオンでは、Backstage、Argo CD、ACK、kro を使って実際に IDP を構築します。Kubernetes の導入を進めたい方や、それを支援する SI 企業の方はぜひご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2026年9月28日週の主要なアップデート 9/28(月) Amazon SageMaker Unified Studio が 2 つの新しい接続機能をサポート: Iceberg REST Catalog 接続と Amazon DocumentDB の IAM 認証 Amazon SageMaker Unified Studio に 2 つの接続機能が追加されました。1 つ目は Iceberg REST Catalog (IRC) 接続で、Snowflake Open Catalog (Polaris) や Databricks Unity Catalog など、Iceberg REST 仕様に準拠した外部 Apache Iceberg カタログへ接続できます。2 つ目は Amazon DocumentDB の IAM 認証で、ユーザー名・パスワードを保存せずに接続の IAM ロールで認証できます。どちらも SageMaker Unified Studio が利用可能なすべての AWS リージョンで、追加料金なしで利用できます。 AWS Backup が Amazon FSx for NetApp ONTAP の論理的エアギャップボールトサポートを追加 AWS Backup の論理的エアギャップボールトが Amazon FSx for NetApp ONTAP に対応しました。FSx for ONTAP ボリュームのバックアップを、コンプライアンスモードの Vault Lock で保護された領域に保存できます。保護された領域は AWS RAM で他アカウントと共有でき、共有先アカウントからコピーせずに直接リストアできるため、ランサムウェア被害やアカウント侵害時の復旧時間を短縮できます。Multi-party approval という機能と組み合わせることで、保護された領域を持つ AWS アカウントにアクセスできない状況でも､別の AWS アカウントで復旧する仕組みがあります｡東京リージョンと大阪リージョンを含む、両機能が利用可能なすべてのリージョンで使用できます。 Amazon EC2 Future-dated Capacity Reservations が開始日の延期に対応 Amazon EC2 Future-dated Capacity Reservations (FDCR) は、必要なキャパシティ、開始日、コミット期間を指定して最大 120 日先のキャパシティを事前に確保できる機能です。今回のアップデートで、キャパシティが配信される前であれば、予約の開始日を後ろ倒しできるようになりました。変更時には EC2 が新しい開始日と必要なコミット期間を示す見積もりを提示し、内容を確認して承諾すると予約が更新されます。開始日の 2 週間以内に変更する場合はコミット期間が増加します。従来は計画変更時にキャンセルと再作成しか選択肢がなく、キャンセル料が発生する場合がありました｡ 9/29(火) Amazon Route 53 Resolver DNS Firewall が Palo Alto Networks Advanced DNS Security のサポートを一般提供開始 Amazon Route 53 Resolver DNS Firewall で Palo Alto Networks (PANW) Advanced DNS Security のルールが利用できるようになり、32 の AWS リージョンで一般提供が開始されました。DNS Firewall のルールグループに PANW の脅威カテゴリ (C2、マルウェア、フィッシング、新規登録ドメインなど 30 種類以上) を直接設定し、VPC およびハイブリッド環境からの悪意ある DNS クエリを検出・ブロックできます。PANW のファイアウォール製品を別途デプロイしたり、VPC のルーティング設定を変更したりする必要はありません。2026 年 6 月の AWS Summit New York City でのプレビュー発表 (当初 8 リージョン) を経て、DNS Firewall が提供されるすべての商用リージョンに拡大されました。 Amazon CloudWatch Logs が頻繁にクエリされるフィールドを自動的にインデックス化 Amazon CloudWatch Logs が、CloudWatch Logs Insights クエリで頻繁に使われるフィールドを自動的にインデックス化するようになりました。対象は = および IN 演算子によるフィルタで使用されるフィールドで、手動設定は不要です。自動インデックスされたフィールドはロググループあたり 20 フィールドのポリシー上限にカウントされず、30 日間保持されます。クエリパターンの変化に応じて対象フィールドは自動的に更新され、恒久的に維持したい場合はフィールドインデックスポリシーへ昇格できます。追加料金はなく、フィールドインデックスがサポートされるすべてのリージョンで利用できます。 Amazon CloudWatch Logs Insights がクエリ実行前のスキャンバイト数の見積もりに対応 Amazon CloudWatch Logs Insights で、クエリを実行せずにスキャン対象となるログデータ量 (バイト数) を見積もれるようになりました。CloudWatch コンソールでは、ロググループの選択・時間範囲・クエリテキストを変更すると、クエリエディタに見積もり値が自動表示されます。AWS CLI や API では、クエリの末尾に estimate コマンドを追加して明示的に見積もりを取得します。estimate コマンドの実行に Logs Insights のクエリ課金は発生しません。全 AWS 商用リージョンで利用できます。 OpenAI GPT-6.1 Sol が Amazon Bedrock で一般提供開始 AWS は、OpenAI の GPT-6.1 Sol を Amazon Bedrock で一般提供開始しました。GPT-6.1 Sol は 2026 年 9 月 22 日に提供開始された GPT-6 Sol の後継モデルで、エージェンティックコーディング、computer use、業務ドキュメント作業に向けたモデルです。OpenAI によると、コーディングベンチマーク DeepSWE v1.1 では最上位モデル GPT-6 Astra と同等のスコアを、タスクあたり約 5 分の 1 のコストで達成します。Bedrock 上では explicit prompt caching に対応しており、コンテキストを繰り返し再利用するエージェントワークロードに適しています。料金は GPT-6 Sol と同水準 (Global CRIS で入力 $2.00 / 出力 $10.00 per 1M トークン) のまま性能が向上しています。 9/30(水) Amazon S3 Tables が Apache Iceberg V3 の全データ型をサポート Amazon S3 Tables が、Apache Iceberg Version 3 仕様で定義された geometry、geography、unknown、ナノ秒精度タイムスタンプの各データ型と、列デフォルト値に対応しました。既存対応の variant 型、deletion vectors、row lineage と合わせ、S3 Tables は V3 で導入された全データ型をサポートするサービスとなります。位置情報を文字列や緯度経度のペアで、イベント時刻を整数でエンコードする従来の回避策が不要になり、クエリ時のフィルタリングとストレージ効率が改善されます。今回追加された機能は、S3 Tables が利用可能なすべてのリージョンで使用できます。 AWS アカウントが電話番号の検証をサポート AWS アカウントのプライマリ連絡先電話番号を、SMS のワンタイムパスコード (OTP) で検証できるようになりました。従来は電話番号の形式チェックのみで、番号が実在するか、本人が受信できるかは確認されていませんでした。新しい SendPhoneNumberVerification API と VerifyPhoneNumber API、またはマネジメントコンソールから検証を実行でき、GetContactInformation API で検証ステータスを確認できます。AWS Organizations では、管理アカウントで検証済みの番号をメンバーアカウントに適用すると検証済みステータスが継承されるため、多数のアカウントで個別に SMS を受信する必要がありません。全 AWS 商用リージョンで利用できます。 Amazon Quick がダッシュボードのドリルダウンをガイドする階層フィルターを追加 Amazon Quick (旧 Amazon QuickSight) に階層フィルターが追加されました。Region → Country → City のような親子関係を持つディメンションを、最大 5 階層まで 1 つのドロップダウンコントロールにまとめられます。従来は階層ごとに個別のフィルターコントロールを並べる必要がありましたが、1 つのコントロールに置き換えることで画面上のコントロール数を減らし、読者は少ないクリック数で目的のデータに到達できます。本機能は Amazon Quick がサポートされるすべてのリージョン (東京リージョンを含む 26 リージョン) で利用できます。 Aurora PostgreSQL が Apache Iceberg および Parquet データのクエリに対応 Aurora PostgreSQL から、Amazon S3、Amazon S3 Tables、AWS Glue Data Catalog 上の Apache Iceberg / Parquet 形式のデータを、ETL パイプラインやデータ複製なしに直接クエリできるようになりました。PostgreSQL の外部テーブルとしてデータレイクを参照し、クエリ実行は PostgreSQL サーバーに組み込まれた DuckDB エンジンが担当します。既存のアプリケーション、ドライバー、BI ツールは同じ PostgreSQL エンドポイントをそのまま使えます。Aurora PostgreSQL 17.11 以降および 18.6 以降 (Aurora Serverless v2 を含む) で、全商用リージョンと GovCloud (US) リージョンにて追加料金なしで利用できます。 Amazon RDS が AMD ベースの M8a インスタンスをサポート Amazon RDS for PostgreSQL、MySQL、MariaDB が第 5 世代 AMD EPYC プロセッサ (開発コード名 Turin) を搭載した M8a データベースインスタンスに対応しました。各 vCPU が物理 CPU コアに 1 対 1 で対応するため、SMT によるスレッド競合がなく、コアあたりの性能が安定します。最大サイズの db.m8a.48xlarge では 192 vCPU、768 GiB メモリ、75 Gbps のネットワーク帯域、60 Gbps の EBS 帯域を利用できます。RDS ではこれまで M7a や M6a といった AMD ベースの汎用クラスが提供されていなかったため、オープンソースエンジン向けの AMD 汎用インスタンスとしては最新世代からの導入となります。提供リージョンはバージニア北部、オハイオ、オレゴン、ムンバイ、東京、ハイデラバード、アイルランド、フランクフルト、スペインの 9 リージョンです。 Amazon Aurora serverless がエージェント型 AI などのバースト性ワークロード向けにスケーリングを高速化 アップデート前は､現在の ACU 容量が大きいほど大きくスケールする仕組みとなっており、低容量時のスケールアップは小刻みでした。今回の強化で 1 秒以内に最大 16 ACU を追加できるようになり、最大 256 ACU まで到達する時間が短縮されました。最小刻み 0.5 ACU での細かい調整は従来どおりです。ワークロード終了後は 0 ACU まで自動でスケールダウンするため、使用した分だけの課金になります。バースト的なアクセス、長いアイドル期間、予測不能なトラフィックという特性を持つエージェント型 AI アプリケーションに適しています。 10/1(木) AWS IAM Identity Center がマルチリージョンサポートの対象リージョンを拡大 AWS IAM Identity Center のマルチリージョンサポートが、オプトインリージョン、AWS GovCloud (US) リージョン間、AWS 中国リージョン間に拡大されました。従来はデフォルトで有効な商用リージョンのみが対象でした。マルチリージョンサポートを有効にすると、ID、許可セット、割り当てなどがプライマリリージョンから追加リージョンへ自動レプリケートされ、プライマリリージョン障害時もユーザーはプロビジョニング済みの権限で AWS アカウントにアクセスを継続できます。利用には組織インスタンスとマルチリージョンのカスタマーマネージド KMS キー (CMK) が必要で、IAM Identity Center 自体は追加料金なしで利用できます。 10/2(金) Amazon Aurora DSQL がパーシャルインデックスをサポート Amazon Aurora DSQL で、テーブルの特定の行サブセットだけを対象とするパーシャルインデックスを作成できるようになりました。CREATE INDEX ASYNC に WHERE 句を追加すると、条件を満たす行だけがインデックスに格納されます。数年分の完了済み注文の中に少数の未処理注文が混在するような、小さなワーキングセットと大きな履歴データが同居するテーブルで、インデックスサイズとストレージコストを抑えながらクエリ性能を改善できます。本機能は Aurora DSQL が提供されているすべてのリージョンで利用できます。 AWS Health がソフトウェアライフサイクル管理のための version catalog を発表 AWS Health に、AWS サービス全体のソフトウェアバージョンのライフサイクル情報を一元的に確認できる version catalog が追加されました。Amazon RDS のエンジンバージョン、Amazon EKS の Kubernetes バージョン、AWS Lambda のランタイムなどについて、サポート終了日や推奨バージョンをサービス横断で確認できます。AWS Health Dashboard から参照できるほか、Business Support+、Enterprise Support、Unified Operations のいずれかのサポートプランを契約している場合は、新しい DescribeServiceLifecycle API で運用ワークフローに組み込めます。アカウント固有の Planned Lifecycle Events を受け取る前の段階で、アップグレード計画やガバナンス統制を構築できるようになります。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

こんにちは。エンタープライズ第一本部 戦略ソリューション 1 部の英です。 普段はAWSでWebアプリ作るなどしています。 趣味ではボードゲームを嗜んでおり、なんと自宅に約200種類以上のボドゲを所有しています。ボードゲーマーです。 そんな私のために登場したと言っても過言ではない、とんでもないニュースが飛び込んできました。 → AmazonのAWSサービスを学べるカードゲーム「AWS BuilderCards」日本語版が予約受付中 そう、 AWSのボドゲ です。 ちょっと何を言ってるかわからないので、とりあえず購入してみました。( Amazon購入リンク ) はたして テックブログなのかどうか悩ましいところですが 、今回はこのゲームをAWSエンジニア兼ボードゲーマーとして ガチレビュー をしていこうと思います。 (きっと社内レビューも通るはず) どんなゲーム？ AWSのリソースを組み合わせてシステムを構築し、スコアを競うカードゲームです。 というのは表向きの説明で、その本性としては デッキ構築 ジャンルの 軽量級ボードゲーム でした。 ビルダーのみなさん、ようこそ！ 今日はあなたがITアーキテクトとして採用された初日です！あなたの仕事は、チームを立ち上げ、モダンで、革新的で、クラウドネイティブなアプリケーションをたくさん作ること(最重要！)です！しかし、まだオンプレミスのインフラが残っています。既存のリソースを賢く使い、新しいサービスを採用し、AWSアーキテクチャを構築し、たくさんのWell-Architectedポイントを取得してください！ AWS BuilderCardsは、AWSサービスについて学びながら、実際のアーキテクチャを構築するためのカードゲームです。 AWSに関連した自身の業務やシステムとの結びつけてプレイするのが最適です。 ※引用：パッケージ背面 ゲーム概要 ジャンル：デッキ構築 プレイ人数：2～4人 ゲーム時間：20～30分 対象年齢：12+ 開封の儀 中身はこんな感じ。 コンポーネントはカードのみで、クイックリファレンスカードも内包されています。 正直なところ、私はクイックリファレンスカードだけでルールを理解することは難しかったので、箱の裏面に記載のQRコードからマニュアルを確認させていただきました。 内容物 クイックリファレンスカード(簡易ルール説明)：2枚 Starter Cards(初期デッキ)：10枚×4 AWS Well-Architectedカード(勝利点)：12枚 ビルダーカード(コスト無)：77枚 ビルダーカード(コスト有)：14枚 ゲームの流れ 基本的には以下の2ステップを行います。 手札のカードを使ってアーキテクチャを構築する 得られたクレジットで 新しいカード または 得点カード を購入する 感覚としては クランク！ や ドミニオン に近いゲーム性を感じました。 カードごとに相性があり、コンボを決めて気持ち良くなるタイプのゲームです。 一例として、 「AWS CloudTrail」と「Amazon OpenSearch Service」を組み合わせると1ドローできる 「Amazon DynamoDB」と「AWS Lambda」を組み合わせると1ドローできる のようなかたちで、 実際のAWSでも相性のよいサービス間にシナジーがあるように設計されています 。 ※ドロー：山札からカードを引く 1はログ検索の基盤として、2はサーバレスアーキテクチャの基盤としてよく組み合わせるサービスですよね。 セットアップ 今回は一人まわしを1時間ほどプレイしてみました。めちゃくちゃ自宅の風景ですみません。 以下はセットアップ風景です。 左上の山：コスト無のビルダーカード 右上の山：コスト有のビルダーカード 右上の表の山：Well-Architectedカード(勝利点) 下部のカード：現在取得できるビルダーカード(カードショップのようなもの) プレイ Amazon S3とAmazon CloudFrontを取得しました。 カードテキストを見るとわかるとおり、これらのカードにはシナジーがあります。 左上のビルダーカードから新しいカードを公開します。 AWS Lambdaが公開されました。今所有しているAmazon S3とシナジーがあるので欲しいところです。 ※今回は一人回しですが、複数プレイヤーの場合は欲しいカードが競合します 初手で5枚引きます。全てスタートデッキ(Sが付いているカード)のため、コスト有のカードは買えません。 次のターンになりました。Amazon CloudFrontの効果で1ドローできます。 さらにターンを進めていきます。ここで初めてデッキ圧縮が発動しました。 発動条件はターン開始時の5枚の手札で、Builder Cardの枚数がStarter Cardの枚数より多いことです。（添付の場合、Starter 2枚 < Builder 3枚） オンプレのDocument Storeをゲームから除外します。これでデッキ内のビルダーカードの比率が向上し、デッキサイクルが改善されます。 上の図では2+2+2で6クレジットありますので、AWS Well-Architectedカードも購入できます。 Well-Architected Cardの購入コストは、3点カードが8クレジット、1点カードが3クレジットです。（ここが若干ややこしい） 要素として「おしい！」と感じたところ 以下はボードゲーマーとしての個人の感想です。 序盤が単調すぎる＆序盤の運が後半に響く 初期デッキ10枚ではアーキテクチャ構築によるクレジットをほぼ生み出せないため、序盤はコストなしBuilder Cardを取得するターンが続きやすい 初回のデッキ圧縮が発生したタイミングから急加速する (Builder Cardの比率が上がると、急にデッキが回り始める) コンボが動き始めるタイミングに運要素(カードの引き)が強く、序盤に開いた差が埋まりにくい。 改善案：デッキ圧縮に条件を定めず、毎ターン1枚のカードを除外できるようにする ※このゲームではデッキ圧縮や除外のことをリタイアと呼びます 良い設計をした人が必ず勝てるわけではない 勝利点の計算はWell-Architectedカードの合計です。 カード購入でビルダーカードを選ぶか、Well-Architectedカードを選べるわけですが、ビルダーカードばっかり買っていると良い構築にはなるが勝利点にならない仕組みです。 つまり、 良い構築を直接評価する仕組みではない というわけです。ただ、良い構築ならば、Well-Architectedカードを買うチャンスが多く発生します。 ドミニオン というゲームと同じで、いつ勝負を仕掛けるか(点数を取りに行くか)が勝敗に大きく影響します。 改善案：サブミッションなど追加で勝利点が得られる仕組みを導入する ボードゲームによくある形式として、プレイするたびにランダムな目標がセットされるケースがあります。最近だと デワン というゲームがその仕組みでした。 今回のAWSのゲームであれば、「クライアントはオンプレ環境に大量の書類データを管理しており、耐障害性で困っているようです。ゲーム終了時にEFSやS3を含んだ構築になっていたら追加で勝利点+3点」など各ゲームごとに変化をもたらすシナリオカードがあれば、リプレイ性が向上します。 で、実はなんとAWS公式からこれに近い Mission Card というオプション要素が用意されています。すばらしい！ Mission Cardはベースゲームにも適用でき、Generative AI Add-On Packという追加パックにも含まれています。 引用： 上級ルール英語版 上記は「Boost Developer Productivity（開発者の生産性を高める）」というミッションです。Amazon CodeCatalyst、Amazon Q Developer、Compute Service を組み合わせた指定のアーキテクチャを完成させることで、Mission Cardを得点として獲得できます。 ランダム性が薄く、単調に感じる ボードゲームは良くも悪くも 思うようにいかないところに楽しさ があります。プレイヤーが燃えるポイントです。 現在の仕組みだと、欲しいカードを取り合うプレイヤー間のインタラクションは発生しますが、比較的戦略通りに進めやすいため、ランダム性はやや薄く感じました。 改善案：障害や攻撃要素があるとよいかも 例えば、10ラウンドごとに「災害」「ハッカーによる攻撃」の要素でシステムの一部がダウン(カード除外)するなどのランダムイベントを設定し、その所定ターンまでに対策を打っておかないと、せっかく自分が構築したシステムに被害が出てしまうみたいなのがあると、勝利点を集める以外の 追加目標 になりますし、AWSとしてのリアリティも感じられて、ゲームとしての没入感がより一層高まるのではないかと思います。 と思ったら、なんとこれも拡張版として提供されています。すばらしすぎる。 Resilience Expansion という拡張が存在し、各ラウンド後に Chaos Event が発生。 それをチームで対処しながら耐障害性の高いアーキテクチャを構築していく協力型ゲームになります。さすがAWS。本当に抜け目がないですねえ。 まとめ(感想) はい。というわけで、今回は日本語版のAWS BuilderCardsで遊んでみました。 基本セットだけで遊ぶとやや単調に感じる部分もありましたが、AWSサービス同士の関係性をカードゲームとして直感的に体験できる点は、とても面白かったです。 さらに、Mission CardやResilience Expansionなどの追加要素まで含めると、「AWSを学ぶゲーム」としてかなりよく考えられていると感じました。 あと、単純にカードにAWSリソースが描かれているだけでもテンション上がりますよね。 コレクション目的で購入するのも全然ありだと思います。 1回20～30分で遊べるので、AWSに初めて触れる人向けの勉強会や、採用・研修時のアイスブレイクにも使いやすそうです。 参考 AWS BuilderCards 公式サイト AWS BuilderCards 2nd Edition 公式ルール AWS BuilderCards Builder's Guideline AWS BuilderCards Resilience Expansion AWS BuilderCards Second Edition / Generative AI Add-On Pack 紹介 採用情報 先日Xで「JTCでは社内のAI利用が進んでおらず働きにくい」みたいなのが話題になってましたが、弊社はこの数年間で各種AIツールのライセンスや申請周りがかなり整備され、めちゃくちゃ働きやすいです。 AIを使って効率的に仕事したいSIの方はぜひご検討ください。ClaudeCodeもCodexも使いたい放題です。(2026年9月現在) ↓ のスターを押していただけると嬉しいです。励みになります。 最後まで読んでいただき、ありがとうございました。 エンタープライズ第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 新卒採用-エンタープライズ第一本部 執筆： 英 良治 (@hanabusa.ryoji) レビュー： @azeta.takuya （ Shodo で執筆されました ）