みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 8 月 21 日に Amazon Aurora の 10 周年を記念した YouTube のライブ配信 が行われました。Amazon Aurora の歴史を振り返りつつ、新機能を活用したデモも含まれています。pgvector を利用した AI アプリケーションの構築方法、新しい分散 SQL データベースの Aurora DSQL 料金モデルによるコスト最適化、グローバルアプリケーションのためのマルチリージョンの一貫性、といった内容も視聴可能です。 YouTube でいつでも視聴可能 なので、興味があればぜひご覧ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年8月18日週の主要なアップデート 8/18(月) AWS Batch でデフォルトインスタンスタイプオプションがサポート開始 AWS Batch で新しいインスタンスタイプオプション default-x86_64 と default-arm64 が追加されました。従来の optimal インスタンスタイプでは m4, m5 といった少し古いインスタンスファミリーが選択されていました。一方、AWS には、よりコストパフォーマンスが良い m6, m7 といった新しいインスタンスタイプがありますが、これらは従来の optimal では選択されていませんでした。新しく追加した default-x86_64 と default-arm64 では、新しい EC2 インスタンスタイプがリリースされると自動的に選択肢に追加されるため、常に最新世代の高性能・低コストなインスタンスでバッチ処理を実行できます。詳細は こちらの Blog 記事をご参照ください。 Amazon Bedrock が Anthropic Claude Sonnet 4 と OpenAI GPT-OSS モデルのバッチ推論をサポート開始 Amazon Bedrock で Anthropic Claude Sonnet 4 と OpenAI GPT-OSS モデルが Batch inference に対応しました。複数の推論リクエストを非同期で処理でき、オンデマンド価格の 50% で利用できます。大量の文書分析やコンテンツ生成、データ抽出などの作業を効率的かつ低コストで実行可能です。大量のデータをバッチ処理的に、定期的に一気に処理するようなユースケースで最適にご利用可能です。詳細は こちらのドキュメントをご参照ください。 Amazon S3 が保存されたデータセットのコンテンツを検証する新しい方法を導入 Amazon S3 で多くのオブジェクトを対象に、データの整合性を検証する新機能を提供開始しました。S3 Batch Operations を使用して、数十億の保存されたファイルが破損していないか、効率的にチェックサムの確認ができます。この機能を利用すると、処理されたすべてのオブジェクトのチェックサム情報を含む詳細なレポートをダウンロードできます。このレポートを、手元で保管し、コンプライアンスや監査目的で使用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora MySQL 3.10 を長期サポート (LTS) リリースとして発表 Amazon Aurora MySQL 3.10 が LTS (長期サポート) リリースとして提供開始されました。LTS を利用すると、データベースクラスターを最低 3 年間、もしくはメジャーバージョンの標準サポート終了まで、同じバージョンを継続利用できます。バージョンアップ作業の頻度を下げることができ、よりほかの作業に時間を費やしやすくなります。本番環境で長期間安定してデータベースを運用したいお客様に、よくご利用いただいています。LTS 期間中はセキュリティと運用上の重要な問題を修正するパッチが提供されます。このパッチには、新機能は追加されません。詳細は こちらのドキュメントをご参照ください。 Amazon QuickSight が計算フィールドの制限を拡張 Amazon QuickSight で計算フィールドの上限が拡張されました。分析 (Analysis) あたり 500 個から 2000 個に、データセットあたり 200 個から 500 個に拡張しています。これまで制限に引っかかって複雑な分析ができなかった大規模データセットでも、より多くのデータ変換やインサイトを発見しやすくなります。自然言語を使った計算フィールド作成機能も活用でき、データ分析の幅が広がります。詳細は こちらのドキュメントをご参照ください。 8/19(火) Amazon EC2 I7i インスタンスが追加の AWS リージョンで利用可能に Amazon EC2 I7i インスタンスが東京、シドニー、フランクフルト、ロンドン、マレーシアリージョンで新たに利用できるようになりました。第 5 世代 Intel Xeon プロセッサと AWS Nitro SSD を搭載し、前世代 I4i と比べて最大 23% のコンピュート性能向上と 50% のストレージ性能向上を実現しています。データベースやリアルタイム分析など、高い IOPS 性能と低レイテンシが求められるワークロードに最適で、torn write prevention 機能によりデータベースのボトルネックを解消しやすくなります。詳細は こちらのページをご参照ください。 Amazon Bedrock が OpenAI オープンウェイトモデルへの簡素化されたアクセスを提供開始 Amazon Bedrock で OpenAI のオープンウェイトモデル gpt-oss-120b と gpt-oss-20b へのアクセスがシンプルになりました。これまでは手動でモデルアクセスを有効化する必要がありましたが、今回のアップデートで全ユーザーで自動的に利用可能となり、コンソールや API ですぐに使い始められます。AI アプリケーション開発の初期検証やプロトタイピングが格段にスムーズになります。詳細は こちらの Blog 記事をご参照ください。 8/20(水) AWS Billing and Cost Management でカスタマイズ可能なダッシュボードを提供開始 AWS が Billing and Cost Management でカスタマイズ可能なダッシュボード機能を提供開始しました。これまで複数の画面で確認していた AWS の料金データを一つのダッシュボードで統合表示できるようになります。Cost Explorer や Savings Plans のデータを組み合わせてグラフやテーブルで可視化し、組織内でのコスト分析や FinOps チームでの標準的なレポート作成に活用できます。詳細は こちらの Blog 記事をご参照ください。 8/21(木) AWS IoT Core でカスタマー管理キーをサポート開始 AWS IoT Core で顧客管理キー (CMK) のサポートが開始されました。これまでは AWS 管理のキーのみでしたが、AWS KMS を使って独自の暗号化キーで IoT データを暗号化できるようになります。キーの作成からローテーション、削除まで自社で管理でき、セキュリティ要件の厳しい企業で利用がしやすくなりました。詳細は こちらのドキュメントをご参照ください。 Amazon CloudWatch が自然言語クエリ結果要約とクエリ生成のリージョンサポートを拡張 Amazon CloudWatch Logs Insights の自然言語機能が大幅に拡張されました。ログクエリ結果の要約機能が東京リージョンなど 15 リージョンに、自然言語クエリ生成機能が 6 リージョンに新たに対応しています。これまで複雑なクエリ言語の知識が必要だったログ分析の作業を、英語を使った指示ができるようになり、結果も自動で要約されるため、障害対応やログ解析をしやすくなりました。日本語は未サポートです。詳細は こちらのドキュメントをご参照ください。 8/22(金) Amazon Bedrock で Anthropic の Claude モデル向け Count Tokens API がサポート開始 Amazon Bedrock で Count Tokens API を提供開始しました。提供開始時点では、Claude モデルのみサポートしています。この API を使うことで、AI モデルにデータを送信する前に、消費トークン数を事前に確認できるようになります。従来は推論実行後にしかトークン数がわからなかったため、コスト予測が難しいことがありましたが、今回のアップデートにより事前にコストを把握できるようになりました。また、実行前にコンテキスト長の制限を超えないように事前に調整がしやすくなり、予期しないエラーやスロットリングを回避できます。詳細は こちらのドキュメントをご参照ください。 AWS Billing and Cost Management MCP サーバーの発表 AWS が Billing and Cost Management MCP サーバーをリリースしました。過去の支出を分析し、コスト最適化ができそうな箇所を見つける、新しいシステムのコストを見積もることが可能です。Amazon Q Developer CLI、Kiro IDE、Visual Studio Code、Claude Code など、MCP を利用できるクライアントからアクセスが可能です。詳細は こちらの GitHub リポジトリをご参照ください。 Amazon RDS for Db2 でリードレプリカがサポート開始 Amazon RDS for DB2 で read replica (読み取り専用レプリカ) 機能が利用可能になりました。最大 3 つまでのレプリカを作成でき、メインのデータベースに負荷をかけずに読み取り専用のアプリケーションを動かせます。レポート作成やデータ分析など、読み取り処理が多い業務で特に効果的です。また災害復旧時にはレプリカを昇格させて書き込み処理も可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon RDS for PostgreSQL で遅延リードレプリカがサポート開始 Amazon RDS for PostgreSQL で遅延リードレプリカ機能が利用可能になりました。この機能により、ソースデータベースから、レプリカデータベースにデータをレプリケーションする際に、最大 24 時間の範囲のなかでレプリケーションの遅延を設定できます。誤ってテーブルを削除したり、データを間違って変更したりする人的ミスからデータを保護するための、猶予時間を作れるうれしさがあります。従来のポイントインタイム復元では、大規模データベースだと数時間かかる場合がありましたが、この新機能を利用することで、より高速な復旧が実現しやすくなります。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です。

本記事は、2025 年 8 月 15 日に公開された Securing Amazon Aurora DSQL: Access control best practices を翻訳したものです。 Amazon Aurora DSQL は、常時利用可能なアプリケーションのための最速のサーバーレス分散 SQL データベースです。 革新的なアクティブ-アクティブ分散アーキテクチャにより、Aurora DSQL はシングルリージョン構成で 99.99% の可用性、マルチリージョン構成で 99.999% の可用性を実現するように設計されており、高可用性アプリケーションの構築に最適です。 パブリックエンドポイントと AWS PrivateLink エンドポイントを使用して、Aurora DSQL クラスターにアクセスできます。 このポストでは、AWS の内部と外部の両方から、パブリックエンドポイントと PrivateLink を介したプライベート VPC エンドポイントを使用して、Aurora DSQL クラスターへのアクセスを制御する方法をご紹介します。 Aurora DSQL パブリックエンドポイントを使用したアクセス制御 パブリックエンドポイントを介して Aurora DSQL にアクセスすることで、VPN や AWS Direct Connect のセットアップなしで、外部アプリケーションやオンプレミスシステムが Aurora DSQL クラスターに接続できる柔軟性が得られます。しかし、この利便性は強力なアクセス制御とバランスを取る必要があります。Aurora DSQL は AWS Identity and Access Management (IAM) と統合されており、ID ベースのアクセス許可を適用することで、承認されたロールのみが接続を開始できます。ユーザーロール、IP アドレス範囲、または仮想プライベートクラウド (VPC) 識別子に基づいて、アクセスを許可または拒否する詳細なポリシーを定義できます。たとえば、必要な dsql:DbConnect または dsql:DbConnectAdmin アクセス許可がない状態でユーザーが接続を試みた場合、パブリックエンドポイントに到達可能であっても、アクセス拒否エラーが発生します。 IAM ポリシー、セキュリティグループ、ネットワークアクセスコントロールリスト (ネットワーク ACL) を組み合わせることで、環境間での安全なアクセスを可能にしながら、Aurora DSQL クラスターへのアクセスを厳密に管理できます。 パブリックエンドポイントを介して Aurora DSQL クラスターにアクセスする場合、セキュリティのために以下のアクセス制御を実装することが不可欠です: 最小権限の原則 – 各データベースのロールまたはユーザーに必要最小限の IAM アクセス許可を付与します。 IP ベースのアクセス制御 – 指定した IP アドレスまたは IP アドレス範囲からの接続のみを許可します。 次の図は、このセットアップのアーキテクチャを示しています。 パブリックエンドポイントを使用したオンプレミスから Aurora DSQL へのアクセス制御の管理 このセクションでは、パブリックエンドポイントを使用して、オンプレミスネットワークから Aurora DSQL クラスターへのアクセスを安全に管理する手順を段階的に説明します。 IAM 権限を使用したデータベースアクセスの制御 Aurora DSQL は認証に従来のパスワードを使用しません。代わりに、 AWS SDK によって生成される短期間有効な認証トークンを使用します。 ユーザーまたはアプリケーションが Aurora DSQL クラスターに接続を試みると、Aurora DSQL はトークンを検証し、呼び出し元の IAM ポリシーを評価してアクセスを許可するかどうかを判断します。 このアプローチは、更新頻度の低さや資格情報の漏洩といった、長期間有効なパスワードに関連するリスクを軽減することでセキュリティを強化します。 IAM ベースのトークン認証を使用することで、明示的に承認されたロールとユーザーのみがデータベースに接続できるようになります。 また、システムにアクセスできるユーザーの一元管理と監査が可能になります。 これを実証するために、まず Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの IAM ロールに Aurora DSQL のアクセス許可 ( dsql:DbConnect または dsql:DbConnectAdmin ) を割り当てずに、Aurora DSQL クラスターのパブリックエンドポイントへの接続を試みます。 export PGSSLMODE=require export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT --region us-east-1) [root@ip-10-0-0-40 ~ ]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT psql: error: connection to server at "xxxxxxxxxxxxxxxxxxxxxxxxxx.dsql.us-east-1.on.aws" (18.97.33.130), port 5432 failed: FATAL: unable to accept connection, access denied DETAIL: Session Id: kvs6xpvbygqtwayg2o6pzp7lgi HINT: User: arn:aws:sts::123456789012:assumed-role/EC2Role/i-b188560f is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:123456789012:cluster/xxxxxxxxxxxxxxxxxxxxxxxxxx because no identity-based policy allows the dsql:DbConnectAdmin action これは、パブリックエンドポイントを介してアクセスする場合でも、IAM 認証を適用することで Aurora DSQL クラスターが保護されていることを示しています。 適切なポリシーを持たない接続試行は拒否され、不正アクセスを効果的に防止します。 次に、以下の IAM ポリシーを Amazon EC2 インスタンスの IAM ロールに関連付けます。 このポリシーは、管理者ロール ( dsql:DbConnectAdmin ) とカスタムデータベースロール ( dsql:DbConnect ) の両方を使用してクラスターに接続するための権限を付与します。 注意 : このブログ全体を通して、 山括弧（< >）で囲まれた値 を必ずご自身の情報に置き換えてください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "StatementAllow", "Effect": "Allow", "Action": [ "dsql:DbConnect", "dsql:DbConnectAdmin" ], "Resource": [ "arn:aws:dsql: <AWS-Region> : <account-id> :cluster/ examplecluster " ] } ] } 次に、以下のコマンドを実行して PostgreSQL の SSL モードを require に設定し、安全な接続を強制します。 Aurora DSQL はすべての接続に SSL を必須とし、SSL を使用しない接続の試みは拒否されます。 export PGSSLMODE=require 次に、認証トークンを生成し、 PGPASSWORD 環境変数に格納します。 デフォルトでは、Aurora DSQL の認証トークンは 15 分 (900 秒) で有効期限が切れます。 ただし、このチュートリアルでは、1 時間 (3,600 秒) で有効期限が切れるように設定した、より長い有効期限を持つトークンを生成します。 export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT --region us-east-1 --expires-in 3600) 必要な接続パラメータを設定したので、Aurora DSQL クラスターへの接続をテストしてみましょう。 [root@ip-10-0-0-40 ~ ]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT postgres=> select current_user ; current_user ----------------- admin (1 row) 前述のコードと出力は、パブリックエンドポイントを介してアクセスした場合でも、Aurora DSQL が IAM ベースの認証を効果的に実施していることを示しています。 安全で制御されたアクセスのために、常に最小権限の原則に従い、データベースアクセスを必要とするロールとユーザーに対して、必要な権限 ( dsql:DbConnect または dsql:DbConnectAdmin ) のみを付与してください。 定期的に IAM ポリシーを監査し、セキュリティリスクを軽減するために、長期間有効な認証情報の代わりに短期間のみ有効な認証トークンを使用してください。 IP アドレスまたは範囲に基づいたデータベースアクセスの制御 ここでは、ソース IP アドレスに基づいて Aurora DSQL クラスターへのアクセスを制限する方法を説明します。 この方法は、ネットワークレベルのセキュリティ層を追加し、信頼できる IP アドレスまたは CIDR ブロックからの接続のみを許可します。 aws:SourceIp 条件を含む IAM ポリシーを使用することで、ロールベースのアクセス制御を補完する明示的な許可または拒否ルールを定義できます。 これは、特定の企業オフィス、オンプレミスデータセンター、または既知のバスティオンホストへのアクセスを許可する場合に特に便利です。 次のコード例は、接続要求が指定された範囲外の IP アドレスから発信された場合に、Aurora DSQL クラスターへのアクセスを拒否する ID ベースの IAM ポリシーを作成する方法を示しています。 このポリシーでは、 "Effect": "Deny" 条件により、信頼された IP アドレス (この場合は 203.0.113.1/32) 以外からのリクエストをブロックします。 このアプローチにより、ユーザーまたはロールが必要な Aurora DSQL の権限を持っている場合でも、承認された IP からの接続のみが許可されます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "StatementDeny", "Effect": "Deny", "Action": [ "dsql:DbConnect", "dsql:DbConnectAdmin" ], "Resource": [ "arn:aws:dsql: <AWS-Region> : <account-id> :cluster/ examplecluster " ], "Condition": { "NotIpAddress": { "aws:SourceIp": "203.0.113.1/32" } } }, { "Sid": "StatementAllow", "Effect": "Allow", "Action": [ "dsql:DbConnect", "dsql:DbConnectAdmin" ], "Resource": [ "arn:aws:dsql: <AWS-Region> : <account-id> :cluster/ examplecluster " ] } ] } 異なる送信元 IP アドレスを持つ Amazon EC2 インスタンスから Aurora DSQL に接続する 前のセクションで説明した IP ベースの制限の有効性を検証するために、IAM ポリシーで定義された許可範囲外の異なるパブリック IP アドレスを持つ Amazon EC2 インスタンスから、Aurora DSQL クラスターへの接続を試みてみましょう。 ポリシーでは 203.0.113.1/32 に一致しない IP アドレスからのアクセスを明示的に拒否しているため、他のすべての IAM 権限が正しく設定されていても、この Amazon EC2 インスタンスからの接続試行は失敗するはずです。 接続をテストする前に、Amazon EC2 インスタンスのパブリック IP アドレスが、IAM ポリシーで定義された許可 IP 範囲の外にあることを確認する必要があります。 Amazon EC2 Instance Metadata Service Version 2 (IMDSv2) を IMDSv2 トークンと共に使用して、インスタンスのパブリック IPv4 アドレスを安全に取得するには、以下のコマンドを実行します： # IMDSv2 トークンを生成 TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" \ -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") # トークンを使用してパブリック IP アドレスを取得 public_ipv4=$(curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/public-ipv4) # IP を表示 echo $public_ipv4 192.0.2.1 IAM ポリシーは 203.0.113.1/32 以外のソース IP アドレスからのアクセスを明示的に拒否するため、パブリック IP アドレスが 192.0.2.1 である Amazon EC2 インスタンスからの接続試行は正しく拒否されます。 これにより、IP ベースの制限が意図したとおりに強制されていることが確認できます。 [root@ip-10-0-0-40 ~ ]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT psql: error: connection to server at "examplecluster.dsql.us-east-1.on.aws" (18.97.33.130), port 5432 failed: FATAL: unable to accept connection, access denied DETAIL: Session Id: abcdefghijaklmnop2ryunhve HINT: User: arn:aws:sts:: 12345678910:assumed-role/EC2Role/i-b188560f is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:12345678910:cluster/examplecluster with an explicit deny in an identity-based policy 上記のコードは、ユーザーまたはロールが適切な権限を持っている場合でも、Aurora DSQL が IP ベースの拒否ルールに従い、アクセスを信頼できるネットワーク境界に制限することを示しています。 許可されたソース IP アドレスを持つ Amazon EC2 インスタンスからの Aurora DSQL への接続 IP ベースのアクセスポリシーが期待通りに機能することを確認するため、IAM ポリシーで許可された IP 範囲 (203.0.113.1/32) に一致するパブリック IP アドレスを持つ Amazon EC2 インスタンスから Aurora DSQL クラスターに接続します。 インスタンスのパブリック IP アドレスが許可された範囲内にあり、IAM ロールに必要な dsql:DbConnect または dsql:DbConnectAdmin 権限があるため、接続はエラーなく成功するはずです。 接続をテストする前に、Amazon EC2 インスタンスのパブリック IP アドレスが、IAM ポリシーで定義された許可 IP 範囲 (203.0.113.1/32) 内にあることを確認しましょう。 これを行うために、IMDSv2 トークンを使用してインスタンスのパブリック IPv4 アドレスを安全に取得します。 # IMDSv2 トークンを生成 [root@ip-10-0-0-40 ~ ]# export PGSSLMODE=require [root@ip-10-0-0-40 ~ ]# export PGPASSWORD=$(aws dsql generate-db-connect-admin-auth-token --hostname $CLUSTER_ENDPOINT — region us-east-1) # トークンを使用してパブリック IP アドレスを取得 [root@ip-10-0-0-40 ~ ]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") [root@ip-10-0-0-40 ~ ]# public_ipv4=$(curl — silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/public-ipv4) # IP を表示 [root@ip-10-0-0-40 ~ ]# echo $public_ipv4 203.0.113.1 IAM ポリシーで IP アドレス 203.0.113.1 からのアクセスを許可するように正しく設定し、認証トークンや SSL モードなどの必要な接続パラメータをすべて設定したので、Aurora DSQL クラスターに正常に接続できるようになりました。 [root@ip-10-0-0-40 ~ ]# psql --quiet --username admin --dbname postgres --host $CLUSTER_ENDPOINT postgres=> select current_user ; current_user -------------- admin これにより、IP ベースのアクセス制御が正しく機能し、明示的に許可された IP アドレスからの接続のみを許可していることが確認できます。 PrivateLink とプライベート DNS エンドポイントを使用した Aurora DSQL へのアクセス制御 このセクションでは、PrivateLink とプライベート DNS エンドポイントを使用して Aurora DSQL に安全にアクセスする方法を探ります。 このアプローチにより、VPC と Aurora DSQL 間のトラフィックを完全に AWS ネットワーク内に留めることができ、パブリック IP アドレス、インターネットゲートウェイ、または NAT デバイスが不要になります。 PrivateLink を使用すると、インターフェース VPC エンドポイントを作成して、Aurora DSQL を自身の VPC の一部であるかのように接続できます。 プライベート DNS と組み合わせることで、これらのエンドポイントを使用してアプリケーションは標準のホスト名を使用して Aurora DSQL クラスターを解決しアクセスできるようになり、トラフィックはプライベートかつ安全にルーティングされます。 この構成は、データのプライバシーと低レイテンシー、安全な接続が重要な要件となる内部ワークロードやハイブリッド環境で特に有用です。 次の図は、PrivateLink を使用して Aurora DSQL クラスターへのアクセスを制御する方法を示しています。 前提条件 以下のセクションに進む前に、次の前提条件を満たしていることを確認してください。 Amazon VPC VPC 内のコンピューティングリソース ( Amazon EC2 インスタンス など) 単一の AWS リージョンにある Aurora DSQL クラスター インターフェース VPC エンドポイントの作成と Aurora DSQL へのアクセスに必要な IAM アクセス許可 PrivateLink インターフェイスエンドポイントの作成 Aurora DSQL の PrivateLink サポートにより、VPC にインターフェース VPC エンドポイントをプロビジョニングできます。 これらのエンドポイントを使用すると、パブリック IP アドレスやインターネット接続を必要とせずに、アプリケーションからプライベートに Aurora DSQL に接続できます。 Amazon VPC 内にデプロイされたアプリケーションは、インターフェースエンドポイントを介してプライベート DNS ホスト名を使用し、Aurora DSQL に安全にアクセスできます。 これにより、トラフィックは AWS ネットワーク内に完全に閉じられ、セキュリティとパフォーマンスの両方が向上します。 PrivateLink インターフェースエンドポイントの作成手順の詳細については、 AWS PrivateLink を使用した Amazon Aurora DSQL クラスターの管理と接続 をご参照ください。 PrivateLink インターフェイスエンドポイントを設定したら、次のステップでは、詳細な ID ベースの制御を通じて Aurora DSQL クラスターへのアクセスを制御するメカニズムを検討します。 VPC エンドポイントポリシーを使用したデータベースアクセスの制限 VPC エンドポイントポリシー を使用することで、ネットワーク内の信頼された IAM プリンシパルとリソースにのみアクセスを許可する堅牢な データ境界 を定義できます。 このアプローチにより、不正アクセスのリスクを最小限に抑え、Aurora DSQL クラスターへのアクセス方法をポリシーに基づいた厳密な制御ができます。 以下の例では、接続リクエストが特定の IAM ロールから発信されていない場合に、Aurora DSQL クラスターへのアクセスを拒否するアイデンティティベースの IAM ポリシーを作成する方法を示します。 このポリシーでは、 "Effect": "Deny" 条件により、信頼された IAM ロール EC2Role 以外からのリクエストをブロックします。 同時に、このポリシーは examplecluster Aurora DSQL クラスターに対する dsql:DbConnect および dsql:DbConnectAdmin アクションに適用されます。 このアプローチにより、承認された IAM ロールを使用した接続のみが許可されることを確実にします。 { "Statement": [ { "Effect": "Deny", "Principal": "*", "Action": "*", "Resource": "arn:aws:dsql: <AWS-Region> : <account-id> :cluster/ examplecluster ", "Condition": { "StringNotEquals": { "aws:PrincipalArn": "arn:aws:iam:::role/ EC2Role " } } }, { "Effect": "Allow", "Principal": "*", "Action": [ "dsql:DbConnect", "dsql:DbConnectAdmin" ], "Resource": "arn:aws:dsql: <AWS-Region> : <account-id> :cluster/ examplecluster " } ] } 認可されていない IAM ロールを使用した Aurora DSQL 接続のテスト 前述の VPC エンドポイントポリシーが意図したとおりに機能していることを確認するため、許可されていない IAM ロールを使用して Amazon EC2 インスタンスから Aurora DSQL クラスターへの接続を試みます。 この場合、インスタンスに関連付けられているロール ( ec2-admin-role ) は、VPC エンドポイントポリシーで明示的に許可されているロール ( ec2-role ) とは異なります。 まず、インスタンスに関連付けられている IAM ロールを確認しましょう： [root@ip-10-0-0-34 ~ ]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") [root@ip-10-0-0-34 ~ ]# curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/ ec2-admin-role 接続パラメータを以下のように設定します。 # Set environment variables export CLUSTERID=your-cluster-id export REGION=us-east-1 export SERVICE_IDENTIFIER=dsql-fnh4 # This should match the identifier in your service name # Construct the hostname export HOSTNAME="$CLUSTERID.$SERVICE_IDENTIFIER.$REGION.on.aws" # Generate authentication token export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $HOSTNAME) それでは接続して結果を確認してみましょう： [root@ip-10-0-0-34 ~ ]# psql --d postgres --h $HOSTNAME --U admin psql: error: connection to server at "examplecluster.dsql-fnh4.us-east-1.on.aws" (10.0.0.0), port 5432 failed: FATAL: unable to accept connection, access deniedDETAIL: Session Id: sfs65e33upgza5iywqh64wd7sq HINT: User: arn:aws:sts::123456789012:assumed-role/ec2-admin-role/i-XXXXXXXXXXX is not authorized to perform: dsql:DbConnectAdmin on resource: arn:aws:dsql:us-east-1:123456789012:cluster/examplecluster with an explicit deny in a VPC endpoint policy VPC エンドポイントポリシーは、権限のない IAM ロール ( ec2-admin-role ) のアクセスを正しく拒否しました。 許可された IAM ロールを使用した Aurora DSQL 接続のテスト VPC エンドポイントポリシーが意図した IAM アイデンティティに対してアクセスを許可していることを検証するため、承認された IAM ロール ( ec2-role ) で設定された Amazon EC2 インスタンスから接続を開始します。 まず、インスタンスに関連付けられた IAM ロールを確認します。 [root@ip-10-0-0-40 ~ ]# TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") [root@ip-10-0-0-40 ~ ]# curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials ec2-role これにより、Amazon EC2 インスタンスが許可された IAM ロール ( ec2-role ) を使用していることが確認できます。 次に、接続パラメータを設定し、Aurora DSQL クラスターへの接続を開始します。 export PGSSLMODE=require export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token — hostname $HOSTNAME) psql --d postgres --h $HOSTNAME --U admin psql (15.6, server 16.9) WARNING: psql major version 15, server major version 16. Some psql features might not work. SSL connection (protocol: TLSv1.3, cipher: TLS_AES_128_GCM_SHA256, compression: off) Type "help" for help. postgres=> select current_user ; current_user ---------------- admin (1 row) リクエストが承認された IAM ロールから発信された場合、VPC エンドポイントポリシーによってアクセスが正しく許可され、接続は想定通りに成功します。 セキュリティグループを使用した Aurora DSQL へのトラフィックの制限 セキュリティグループは、インバウンドとアウトバウンドの両方のトラフィックを制御する、AWS リソースの仮想ファイアウォールとして機能します。 Aurora DSQL PrivateLink VPC エンドポイント (インターフェイスエンドポイント) を使用する場合、セキュリティグループは VPC 内の特定のコンピューティングリソース、IP 範囲、またはサブネットへのクラスターアクセスを制限する強力なメカニズムを提供します。 このセクションでは、セキュリティグループを使用して Aurora DSQL クラスターへの接続を制御し、テストシナリオを通じて設定を順を追って説明します。 Amazon EC2 インスタンスに関連付けられたセキュリティグループの特定 Aurora PostgreSQL に接続を試みる Amazon EC2 インスタンスに関連付けられているセキュリティグループのリストを最初に取得します。 # Get EC2 metadata token TOKEN=$(curl --silent -X PUT "http://169.254.169.254/latest/api/token" \ -H "X-aws-ec2-metadata-token-ttl-seconds: 21600") # List attached security groups curl --silent -H "X-aws-ec2-metadata-token: $TOKEN" \ http://169.254.169.254/latest/meta-data/security-groups #Example Output: SecGroup-MySQL SecGroup-PG SecGroup-DSQL PrivateLink エンドポイントのセキュリティグループの確認 次に、Aurora DSQL PrivateLink エンドポイントに現在関連付けられているセキュリティグループを確認してみましょう。 aws ec2 describe-vpc-endpoints \ --vpc-endpoint-ids vpce-03ae184e1b904ecb5 \ --query "VpcEndpoints[0].Groups" #Example Output: [ { "GroupId": "sg-0b457c8e654a695f5", "GroupName": " SecGroup-ec2" } ] Amazon EC2 インスタンスと PrivateLink エンドポイントに共通のセキュリティグループがないことがわかります。そのため、明示的に許可しない限り、接続は失敗する可能性が高いです。 セキュリティグループの不一致による接続の試行 Amazon EC2 インスタンスから Aurora PostgreSQL クラスターへの接続を試み、アクセスが許可されているかどうかを確認するためにタイムアウトを設定します。 PGCONNECT_TIMEOUT 変数を設定して、10 秒後に接続がタイムアウトするようにしています。 export HOSTNAME="$CLUSTERID.$SERVICE_IDENTIFIER.$REGION.on.aws" echo $HOSTNAME examplecluster. dsql-fnh4.us-east-1.on.aws export PGCONNECT_TIMEOUT=10 export PGPASSWORD=$(aws dsql --region $REGION generate-db-connect-admin-auth-token --hostname $HOSTNAME) psql --quiet --username admin --dbname postgres --host $HOSTNAME #Example Output: psql: error: connection to server at " examplecluster. dsql-fnh4.us-east-1.on.aws" (10.0.0.0), port 5432 failed: timeout expired connection to server at " examplecluster. dsql-fnh4.us-east-1.on.aws (10.0.0.0), port 5432 failed: timeout expired 上記の出力は、VPC エンドポイントの制限された セキュリティグループ設定により、Amazon EC2 インスタンスが Aurora DSQL エンドポイントに到達できないことを示しています。 エンドポイントへの適切なセキュリティグループの割り当て エンドポイントに適切なセキュリティグループを関連付けるために、Amazon EC2 インスタンスで使用されているセキュリティグループを特定します。 aws ec2 describe-security-groups \ --filter Name=group-name,Values= SecGroup-DSQL \ --query "SecurityGroups[0].GroupId" #Example Output: "sg-078a098b3069c40de" 次に、既存の PrivateLink エンドポイントにセキュリティグループ sg-078a098b3069c40de を追加します。 aws ec2 modify-vpc-endpoint \ --vpc-endpoint-id vpce-03ab184c1d904efg5 \ --add-security-group-ids sg-078a098b3069c40de aws ec2 describe-vpc-endpoints \ --vpc-endpoint-ids vpce-privatelink-id \ --query "VpcEndpoints[*].Groups" # Example Output [ { "GroupId": " sg-078a098b3069c40de", "GroupName": " SecGroup-DSQL" } ] Amazon EC2 インスタンスからの接続の再テスト 正しいセキュリティグループを VPC エンドポイントに関連付けたので、Amazon EC2 インスタンスから接続を再試行します。 psql --quiet --username admin --dbname postgres --host $HOSTNAME postgres=>postgres=> select current_user ; current_user -------------- admin Aurora DSQL クラスターへの接続が成功し、PrivateLink を介したアクセスを有効にするためにはセキュリティグループの整合性が重要であることが確認できました。 Aurora DSQL PrivateLink エンドポイントでセキュリティグループを使用することで、IAM と VPC エンドポイントポリシーを補完する、重要なネットワークレベルのアクセス制御が提供されます。 Amazon EC2 インスタンスと VPC インターフェースエンドポイントに適切にセキュリティグループを関連付けることで、VPC 内の信頼できるリソースのみが Aurora DSQL クラスターに接続できるようになります。 このアプローチは、最小権限アクセスモデルを実施するだけでなく、意図しない、または許可されていないネットワークトラフィックがセンシティブなデータを扱うエンドポイントに到達することを防ぐことで、全体的なセキュリティ体制を強化します。 Aurora DSQL 向けの追加の IAM ベースのアクセス制御ポリシー セキュリティと監査の目的に応じて、IAM では Aurora DSQL クラスターに接続できるユーザーと、その接続試行の発信元となる VPC を制御するための柔軟なオプションを提供しています。 以下のサンプルポリシーは、環境に合わせた VPC ベースおよびアイデンティティベースのアクセス制御を適用するための出発点として活用できます。 IAM は世界中のデータセンターのコンピュータからアクセスされるサービスで、 結果整合性 と呼ばれる分散コンピューティングモデルを使用して動作していることに注意してください。 これは、IAM や関連する AWS サービスで行った変更 (例えば 属性ベースのアクセスコントロール (ABAC) タグの更新など) が、すべてのエンドポイントに反映され、表示されるまでに時間がかかる可能性があることを意味します。 この遅延は、データがサーバー間、レプリケーションゾーン間、AWS リージョン間で伝送される必要があるために発生します。 さらに、IAM はパフォーマンスを向上させるためにキャッシュを使用しており、これによってさらなる遅延が発生することがあります。 その結果、キャッシュされたデータが期限切れになるまで、変更が即座に反映されない場合があります。 詳細については、 変更が即座に反映されない を参照してください。 IAM 条件を使用した Aurora DSQL クラスターのパブリックアクセスのブロック Aurora DSQL のパブリックエンドポイントへのアクセスを厳密に制御するために、承認された VPC または PrivateLink エンドポイントから発信されないすべてのトラフィックをブロックできます。 以下の IAM ポリシーは、条件キーを使用して、接続リクエストが VPC またはインターフェースエンドポイントから発信されていない場合にアクセスを拒否します。 この例では、リクエストに有効な VPC ソース IP ( aws:VpcSourceIp )、ソース VPC 識別子 ( aws:SourceVpc )、または VPC エンドポイント識別子 ( aws:SourceVpce ) が含まれていない場合、ユーザーまたはロールが必要な Aurora DSQL のアクセス許可を持っていても、接続の試行は拒否され、インターネットからのアクセスがすべて効果的に防止されます。 { "Version": "2012-10-17", "Statement": [ { "Resource": "arn:aws:dsql: <AWS-Region> : <account-id> :cluster/ examplecluster ", "Effect": "Deny", "Action": [ "dsql:DbConnect", "dsql:DbConnectAdmin" ], "Condition": { "Null": { "aws:VpcSourceIp": "true", "aws:SourceVpc": "true", "aws:SourceVpce": "true" } } } ] } このポリシーは、信頼できるプライベートネットワークまたは明示的に設定された VPC インターフェースエンドポイントからの接続のみを許可することで、Aurora DSQL クラスターがパブリックインターネットに意図せず公開されることを防ぐ、強力なセーフガードとして機能します。 信頼できる VPC への Aurora DSQL PrivateLink アクセスの制限 Aurora DSQL へのアクセスを事前に定義された VPC グループ (例えば、承認された本番環境やステージング環境のネットワーク) からのみに制限する必要がある環境では、信頼された VPC ID からのリクエストでない限り、接続の試行を拒否できます。 次の例では、接続が vpc-abc または vpc-xyz のいずれかからでない場合、 dsql:DbConnect と dsql:DbConnectAdmin の両方を拒否します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictDSQLDBConnectToSpecificVPCs", "Effect": "Deny", "Action": [ "dsql:DbConnect", "dsql:DbConnectAdmin" ], "Resource": "*", "Condition": { "ForAnyValue:StringNotEquals": { "aws:SourceVpc": [ "vpc-abc", "vpc-xyz" ] } } } ] } このポリシーを設定することで、呼び出し元が必要な IAM 許可を持っていても、他の VPC からの接続試行はすべて拒否されます。 指定した VPC からの Aurora DSQL PrivateLink 接続の制限 高度に管理された環境では、Aurora DSQL へのアクセスを単一の VPC からのみに制限する必要がある場合があります。 以下のポリシーでは、VPC vpc-xyz からの接続以外のすべての接続試行を拒否します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictDSQLDBConnectToVPC", "Effect": "Deny", "Action": [ "dsql:DBConnect" ], "Resource": "*", "Condition": { "StringNotEquals": { "aws:SourceVpc": "vpc-xyz" } } } ] } これは、Aurora DSQL クラスターへのアクセスを、社内アプリケーションで使用される中央データサービス VPC のような、厳密に管理された VPC からのみに制限する必要がある場合に有用です。 Aurora DSQL PrivateLink における VPC および IAM ベースのアクセス制御の適用 最高レベルの制御を実現するために、同じポリシー内でネットワークベースの制限とアイデンティティベースの制限の両方を組み合わせることができます。 次の例では、リクエストが vpc-xyz から発信され、IAM ロール ApprovedRole またはユーザー ApprovedUser のいずれかを使用する場合にのみ、 dsql:DbConnect を許可します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "RestrictDSQLDBConnectByVPCAndPrincipal", "Effect": "Allow", "Action": [ "dsql:DBConnect" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceVpc": "vpc-xyz", "aws:PrincipalArn": [ "arn:aws:iam::444455556666:role/ApprovedRole", "arn:aws:iam::444455556666:user/ApprovedUser" ] } } } ] } このアプローチでは、承認された VPC からのリクエストであっても、信頼された IAM 主体の 1 つから発行される必要があります。 これにより、Aurora DSQL へのアクセスを許可する前に、ID とネットワークの起点を組み合わせることで、強力な多層防御を実現します。 セキュリティのベストプラクティス Aurora DSQL 用に PrivateLink を設定する際は、データとインフラストラクチャを保護するために、複数のレイヤーでアクセス制御を実装することが重要です。全体的なセキュリティ対策を強化するために、以下の セキュリティのベストプラクティス を検討してください： セキュリティグループ – VPC インターフェースエンドポイントに厳密に定義されたセキュリティグループを関連付けます。これらは、承認された Amazon EC2 インスタンスやアプリケーションサブネットなど、VPC 内の特定の信頼できるリソースからのトラフィックのみを許可し、PostgreSQL の場合は通常 TCP 5432 など、必要なポートへのアクセスを制限する必要があります。 IAM ポリシー – VPC エンドポイントの作成、変更、削除を制御する IAM ポリシーを定義することで、最小権限アクセスを実施します。これにより、承認されたエンドユーザーとサービスのみが Aurora DSQL クラスターへのネットワークアクセスを管理できるようになります。 ネットワーク ACL – ネットワーク ACL を使用して、ステートレスなサブネットレベルのトラフィックフィルタリングを提供します。セキュリティグループと併せて追加の保護層を提供するため、VPC エンドポイントのネットワークインターフェースをホストするサブネットに必要な着信および発信トラフィックのみを許可するようにネットワーク ACL を設定します。 これらのベストプラクティスを組み合わせることで、AWS 環境内の Aurora DSQL 接続を保護する、堅牢な多層防御戦略を構築できます。 デプロイ計画に関する考慮事項 Aurora DSQL を PrivateLink でデプロイする際は、以下の点を考慮してください： 共有エンドポイント – 同じサービス名を使用する場合、複数の Aurora DSQL クラスターで 1 つの PrivateLink インターフェースエンドポイントを共有できます。これにより、接続が簡素化され、運用オーバーヘッドを削減できます。 リージョンの範囲 – PrivateLink エンドポイントはリージョン固有です。同一リージョン内の Aurora DSQL クラスターにのみアクセスできます。PrivateLink を介したリージョン間アクセスはサポートされていません。 コストに関する考慮事項 – インターフェースエンドポイントとデータ処理の料金を含む、標準的な PrivateLink の料金が適用されます。PrivateLink の使用料は Aurora DSQL の使用料とは別に請求されるため、コスト計画に含める必要があります。 接続制限 – PrivateLink エンドポイントを介して同時に確立できる接続数は、 Aurora DSQL の接続制限 によって制限されます。スロットリングや接続エラーを避けるため、ワークロードの設計がこれらの制限に適合していることを確認してください。 これらの考慮事項を早期に理解することで、Aurora DSQL と PrivateLink を中心とした、安全でスケーラブル、かつコスト効率の高いアーキテクチャを設計することができます。 まとめ この投稿では、パブリックエンドポイントと PrivateLink エンドポイントの両方を使用して、Aurora DSQL クラスターへの安全な接続とアクセス制御を実現する方法について説明しました。 VPC 内からでも、オンプレミスのデータセンターからでも、Aurora DSQL にアクセスする際に、ここで説明したアプローチを使用することで、トラフィックをプライベートに保ち、きめ細かいアクセス制御を実施し、セキュリティのベストプラクティスに準拠することができます。 VPC インターフェイスエンドポイント、セキュリティグループ、IAM ポリシー、VPC エンドポイントポリシーを使用することで、信頼できるリソースとアイデンティティのみにアクセスを制限する堅牢なセキュリティ境界を構築できます。 Aurora DSQL の接続に関する安全でスケーラブルなソリューションを設計する際は、この記事の知見をアーキテクチャの判断材料として活用してください。 著者について Ranjan Burman Ranjan は AWS のシニアデータベーススペシャリストソリューションアーキテクトとして、大規模なデータ変換と複雑なデータベース移行を専門としています。Amazon RDS と Amazon Aurora に関する深い専門知識を活かし、パフォーマンス、スケーラビリティ、コスト効率を最適化したミッションクリティカルで堅牢なエンタープライズグレードのデータベースソリューションの設計を支援しています。リレーショナルデータベース、データウェアハウス、データ分析における約 20 年の経験を活かし、お客様のデータに関する課題をクラウドでの競争優位性に変えるためのパートナーとして活動しています。 Vijay Karumajji Vijay は AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトとして、お客様と協力してスケーラブルで安全なクラウドネイティブなデータベースアーキテクチャの設計に取り組んでいます。商用およびオープンソースのデータベースにおける 20 年以上の経験を持ち、組織のデータプラットフォームの最新化と AWS マネージドデータベースサービスの価値最大化を支援する深い技術的専門知識を提供しています。実際のニーズに応える新しいデータベース機能の形成と提供のため、AWS サービスチームと緊密に連携しています。

企業が生成AIを積極的に活用し、ビジネス価値を創出し始めています。SAP システムを利用している方で、どこから始めればよいのか、アイデアを探している方も多いのではないでしょうか。このブログでは、SAP データに関する一般的なビジネスユースケースと、AWS の GenAI サービスを使用した様々なアプローチについて説明します。 生成AIを活用するERP データ分析には、複数のアプローチがあります。 SAP Joule などのソフトウェアに組み込まれた AI Anthropic Claude や Amazon Nova などの Amazon Bedrock モデルへのアクセスを提供する SAP Gen AI Hub などのプラットフォームソリューション HR や法務など、業界固有のソリューションを含むデータ分析のための事前に構築済みのソリューション 独自のビジネスデータを使用した生成型 AI 技術によるアプリケーションの構築とカスタマイズ このブログシリーズでは、SAP データを AWS で活用する際の独自ソリューションの構築に関する以下のユースケースに焦点を当てます。 自然言語を使用した SAP Early Watch Analysis (EWA) レポートの分析 インテリジェントドキュメントプロセッシング (IDP) を使用した請求書処理の自動化 自然言語を使用した構造化された財務データからの業務上の知見の取得 AWS 生成 AI サービス このブログでは、AWS の以下の生成 AI サービスを使用します: Amazon Q Business : エンタープライズデータに基づいて質問への回答、要約の提供、コンテンツの生成、タスクの完了を行うように設定できる、フルマネージドの生成 AI 搭載アシスタントです。 Amazon Bedrock : 主要な AI 企業と Amazon が提供する高性能な基盤モデル (FM) を、統一された API を通じて利用できるフルマネージドサービスです。Bedrock の Knowledge Bases 機能により、基盤モデルとエージェントに企業の非公開データソースからコンテキスト情報を提供し、より関連性が高く、正確で、カスタマイズされた応答を実現できます。 自然言語を使用した SAP Early Watch Analysis (EWA) レポートの分析 EWA レポートには SAP システムの正常性に関する重要な詳細が含まれており、時間の経過に伴うトレンドを分析するために使用できます。 これらのドキュメントには詳細な情報が含まれているため、レポートが数十ページに及ぶことは一般的です。例えば、SAP が公開している S/4HANA EWA のサンプル は 213 ページあります。 レポートの分析、推奨事項の反映、時間の経過に伴うトレンドの把握は面倒な作業ですが、Amazon Q Business を使用して自動化することができます。 図 1 は、想定されるソリューションのアーキテクチャ図を示しており、このセクションではその構築手順を説明します。 組織の EWA レポート (すべての SAP システムから) を Amazon S3 バケットにアップロードします Amazon Q Business アプリケーション、Q Index を作成し、S3 をデータソースとして追加します Web UI を使用して EWA レポートを分析します 図 1: EWA 分析ツールアプリケーションのアーキテクチャ 組織の EWA レポート (すべての SAP システムから) を Amazon S3 バケットにアップロードします 新しい Amazon S3 バケットを作成するか、既存の空のバケットを使用することができます。すべての EWA レポートをダウンロードし、Amazon S3 バケットに保存します (S3 バケット名を控えておいてください。例: sap-early-watch)。 注 ：このソリューションを一般に公開されているレポートでテストしたい場合は、公開されている サンプルレポート を使用できます。 Amazon Q Business アプリケーション、Q Index を作成し、S3 をデータソースとして追加する Amazon Q Business アプリケーションを作成するには、以下の手順に従ってください： AWS コンソールで Amazon Q Business に移動し、[Get Started] ボタンをクリックします 図 2 に示すように、[Create Application] をクリックし、フォームを使用してアプリケーションを作成します AWS のベストプラクティスに従って AWS IAM Identity Center の使用が推奨されますが、AWS 外でユーザー認証を管理する場合は AWS IAM Identity Provider も使用できます すぐに始めるためにユーザーを選択します。これは後で編集することもできます (オプション) フォームの入力が完了したら、[Create] ボタンをクリックすると、数秒でウェブアプリが作成されます 図 2: Amazon Q Business でのアプリケーション作成 Amazon Q インデックスを追加するには、以下の手順に従ってください： 作成したアプリケーション (ABC-EWA-Analyzer) に移動し、図 3 に示すように Data sources を選択します。 図 3: Amazon Q Business のデータソース 「Add an index」オプションに移動し、新しいインデックスを作成します (図 4 を参照) フォームに入力してインデックスを追加します (完了まで最大 20 分かかる場合があります) 図 4: アプリケーション ABC-EWA-Analyzer へのインデックスの追加 S3 をデータソースとして追加するには、以下の手順に従ってください: インデックスを作成したら、(図 5 に示すように) Add Data sources をクリックし、EWA レポートが保存されている S3 バケット (この場合は sap-early-watch) を選択します 図 5: アプリケーションのデータソースとして Amazon S3 を追加する 同期タイプとスケジュールを選択します データソースフォームに記入し、「Add Data sources」ボタンをクリックしてタスクを完了します データソースが追加されたら、「今すぐ同期」を使用して初期同期を実行できます。レポートの数と長さによっては、最大 20 分かかる場合があります Web UI を使用して EWA レポートを分析 同期が完了したら、アプリケーションに表示されるデプロイされた URL を使用して EWA Analyzer アプリにアクセスします。 アプリに表示されるタイトル、ウェルカムメッセージ、会社のロゴを独自のものに変更することで、Web サイトの外観をカスタマイズできます。 図 6 は、カスタマイズしたアプリの表示例を示しています (ナレッジソースのトグルで company knowledge が選択されていることを確認してください)。 図 6: Early Watch Analyzer アプリ アプリを使用して以下のような分析を行うことで、生産性が向上するだけでなく、より深い調査が可能になります。 最も実行時間の長いデータベースクエリを見つける データベースとオペレーティングシステムが最新の状態に更新されているか確認する レポートで言及されているパフォーマンス向上のための具体的な推奨事項を得る 図 7 は、S3 バケットにアップロードされた EWA レポートに関連する質問をするためのアプリケーションの操作例を示しています。また、Amazon Q の 透明性 という側面にも注目してください。これは回答を生成するために使用されているソースを表示している点です。 図 7: Amazon Q Business アプリケーションを使用した EWA 分析 ヒント : Amazon Q Business アプリを使用して、 SAP レディネスチェックレポートやサイジングレポート などの分析も可能です。 これで、以下の内容について解説した EWA 分析のユースケースを終了します。 複数ページにわたる EWA レポートの手動レビュー時間を削減 複数の SAP システムにわたるシステムヘルスの迅速な分析を実現 時間の経過に伴うトレンドと推奨事項を追跡 インテリジェントドキュメントプロセッシング (IDP) を使用した請求書処理の自動化 従来の紙ベースやデジタル請求書の手作業による処理は、時間がかかるだけでなく、エラーが発生しやすく、支払いの遅延、コンプライアンスリスク、貴重な人的リソースの非効率な使用につながります。 ビジネスが拡大するにつれて請求書の量は指数関数的に増加し、手作業による処理はますます持続不可能になっています。 ここで生成系 AI ソリューションを活用して、負担を軽減することができます。 また、AWS テクノロジーに加えて、SAP Build プロセス自動化ソリューションを使用することもできます。 請求書の処理と分類: 組織が紙ベースまたは PDF/メールの請求書を扱っている場合、効率性と正確性の両立の難しさをご存知でしょう。また、手作業による処理は業務拡大に対応できません。このセクションでは、以下のユースケースに対して Amazon Bedrock Data Automation 機能を使用する方法を紹介します: SAP またはサードパーティシステムにおける紙/PDF ベースの請求書処理を自動化 請求書を異なるグループに分類し、さらなる分析を行う 注 : SAP に請求書を直接転記する場合は、処理を自動化するために SAP Build Process Automation （ AWS で利用可能な Business Technology Platform サービス）などの代替アプローチを使用することもできます。 Bedrock Data Automation (BDA) は、生成 AI を活用して非構造化ドキュメント (請求書など) やメディアからのデータ抽出を簡素化して、マルチモーダルデータを 構造化 フォーマットに自動変換します。BDA は、以下のように請求書の処理と分類に使用できます： 請求書からデータを抽出、正規化、検証します BDA の出力をカスタマイズし、既存の処理ワークフローと統合します 正規化された出力を請求書の分類 (ビジネスユニットごとなど) に使用します 図 8 はソリューションのアーキテクチャ図を示しており、このセクションではその構築手順を説明します。 組織の請求書を Amazon S3 バケットにアップロードします BDA プロジェクトを作成し、ブループリントを追加します 結果を既存のワークフローに取り込んで処理を行います 図 8: 請求書の処理と分類に BDA を使用するアーキテクチャ 組織の請求書を Amazon S3 バケットにアップロードする 新しい Amazon S3 バケットを作成するか、既存の空のバケットを使用することができます。すべての請求書 (PDF、スキャンした画像など) を Amazon S3 バケットにアップロードします。 BDA プロジェクトを作成してブループリントを追加する BDA プロジェクトとブループリントを作成するには、以下の手順に従ってください： AWS コンソールの Amazon Bedrock の Data Automation に移動し、図 9 のようにプロジェクトを作成します 図 9: 新しい BDA プロジェクトの作成 プロジェクトが作成されたら、図 10 に示すように、請求書が保存されている S3 バケットからデータをインポートするためにテストオプションを使用します 図 10: AWS コンソールからの請求書処理テスト 図 11 は BDA からの標準出力の例を示しており、JSON 形式でダウンロードすることができます。 図 11: BDA の標準出力の例 標準出力を評価し、さらなる制御が必要な場合は、カスタム出力 (図 12 に示すように) を使用し、「ブループリントプロンプト」を使用してブループリントを作成します。また、AWS が提供するブループリントのリストから選択することもできます。 図 12: BDA カスタム出力とブループリント 処理のための既存のワークフローに結果を統合: 入念なテストを行い、ブループリントが組織の運用に沿ってデータを抽出することを確認した後、SAP Business Technology Platform (BTP) サービスを使用して作成されたアプリケーションなど、SAP への請求書処理のための既存のワークフローに BDA プロジェクトを統合します。 AWS SDK for SAP ABAP : ワークフローにおいて、AWS SDK for SAP ABAP を使用することで、RISE with SAP、GROW with SAP、および自己管理環境内で SAP ABAP と 200 以上の AWS サービスをシームレスに統合できます。 ヒント : 抽出した情報に対して自然言語でクエリを実行するために、出力を検索拡張生成 (RAG) ワークフローの一部として使用することもできます。 以上で、IDP を使用した請求書処理のユースケースの説明を終えました。ここでは、以下の方法について説明しました。 非構造化された請求書データを構造化フォーマットに変換 紙ベースおよびデジタル請求書の処理を効率化 手作業による処理エラーを削減し、効率を向上 請求書の分類による分析を可能に コストの内訳例 以下の表は、デフォルトパラメータを使用して US East 1 (バージニア北部) リージョンでご自身の AWS アカウントにこのソリューションをデプロイした場合のコスト内訳のサンプルを示しています。 AWS サービス 料金単位 コスト (USD) Amazon Q Business Pro ユーザーあたり月額 $20 Enterprise Index インデックスユニットあたり月額 $192.72 Amazon Bedrock Data Automation (BDA) ブループリントを使用して処理された 1,000 ページあたり $40 Amazon S3 EWA と請求書用の 1 TB ストレージ $23.55 ヒント : コストの管理に役立てるため、 AWS Cost Explorer で 予算 (Budget) を作成することをお勧めします。詳細については、このブログで使用される各 AWS サービスの料金ページをご参照ください。 まとめ このブログでは、AWS Generative AI サービスを使用して SAP データの作業効率を向上させ、エラーを削減する方法について説明しました。 ブログのパート 2 では、自然言語を使用して構造化された財務データからビジネスインサイトを得る方法の詳細について説明します。 AWS の生成 AI サービス についてさらに詳しく学び、Amazon Q で独自のユースケースを始めましょう。 SAP on AWS に関するディスカッションへの参加 お客様のアカウントチームと AWS Support チャネルに加えて、AWS は re:Post サイト で公開の Q&A フォーラムを提供しています。 SAP on AWS ソリューションアーキテクチャチームは、お客様を支援するために、 SAP on AWS トピックで定期的にディスカッションや質問を監視しています。 サポート関連以外の質問がある場合は、 re:Post でディスカッションに参加し、コミュニティの知見に貢献することをご検討ください。 本ブログはパートナーソリューションアーキテクトの松本が翻訳しました。原文は こちら です。

このブログでは、 AWS Amplify 、 AWS AppSync 、 MongoDB Atlas を使用して、オフラインファーストのアプリケーションと楽観的な UI を作成する方法をご紹介します。開発者は、インターネット接続を必要としないオフラインファーストアプリケーションを設計します。楽観的な UI は、サーバーからのレスポンスに依存することなく、予想されるデータの変更で UI を更新することで、オフラインファーストのアプローチをさらに発展させます。このアプローチは通常、ローカルキャッシュの仕組みを活用します。 オフラインファーストと楽観的 UI を組み合わせたアプリケーションは、ユーザーに多くの利点をもたらします。これには、ローディング画面を実装する必要性の低減、データアクセスの高速化によるパフォーマンスの向上、アプリケーションがオフラインの状態におけるデータの信頼性、コスト効率の向上が含まれます。オフライン機能を手動で実装するには相当な労力が必要ですが、このプロセスを簡素化するツールを使用することができます。 リクエストのラウンドトリップが完了する前に MongoDB Atlas の CRUD 操作の結果を UI に即座に表示し、ユーザーエクスペリエンスを向上させる、 サンプルの Todo アプリケーション を提供しています。つまり、楽観的 UI を実装することで、ローディング状態やエラー状態の表示を容易にし、API 呼び出しが失敗した場合に開発者が UI 上の変更をロールバックできるようにしています。この実装では、 TanStack Query を活用して、 AWS Amplify と共に楽観的な UI の更新を処理します。図 1 は、UI とバックエンド間の連携を示しています。 TanStack Query は、TypeScript/JavaScript、React、Solid、Vue、Svelte、Angular 向けの非同期状態管理ライブラリです。Web アプリケーションにおけるサーバー状態のフェッチ、キャッシング、同期、更新を簡素化します。TanStack Query のキャッシングメカニズムを活用することで、ネットワーク接続がなくてもデータの可用性を確保できます。AWS Amplify が開発プロセスを効率化し、AWS AppSync が信頼性の高い GraphQL API レイヤーを提供し、MongoDB Atlas がスケーラブルなデータベースソリューションを提供します。この統合により、フルスタックアプリケーションアーキテクチャ内で TanStack Query のオフラインキャッシュを効果的に活用する方法が示されています。 図 1. インタラクション図 このサンプルアプリケーションは、一般的な ToDo 機能を実装しており、その具体的なアーキテクチャは 図 2 に示されています。このスタックの構成は以下の通りです。 データベースサービスには MongoDB Atlas を使用します。 フルスタックアプリケーションフレームワークには AWS Amplify を使用します。 GraphQL API 管理には AWS AppSync を使用します。 サーバーレスコンピューティングには AWS Lambda Resolver を使用します。 ユーザー管理と認証には Amazon Cognito を使用します。 図 2. アーキテクチャ アプリケーションのデプロイ アプリを AWS アカウントにデプロイするには、以下の手順に従ってください。デプロイが完了したら、ユーザーを作成し、認証を行い、Todo エントリを作成できます (図 8 を参照)。 MongoDB Atlas クラスターのセットアップ こちらのリンク 先で、 MongoDB Atlas クラスター 、データベース、 ユーザー 、 ネットワークアクセス をセットアップします ユーザーをセットアップします ユーザーを設定 GitHub リポジトリのクローン 以下のコマンドでサンプルアプリケーションをクローンします git clone https://github.com/mongodb-partners/amplify-mongodb-tanstack-offline AWS CLI 認証情報のセットアップ (ローカルでアプリケーションをデバッグする場合のオプション) サンドボックス環境 を使用してアプリケーションをローカルでテストする場合は、一時的な AWS 認証情報をローカルに設定できます。 export AWS_ACCESS_KEY_ID= export AWS_SECRET_ACCESS_KEY= export AWS_SESSION_TOKEN= AWS Amplify に Todo アプリケーションをデプロイ AWS Amplify コンソールを開き、GitHub オプションを選択 図 3. GitHub オプションの選択 2. GitHub リポジトリの設定 図 4. リポジトリのアクセス許可を設定 3. GitHub リポジトリを選択し、Next をクリック 図 5. リポジトリとブランチの選択 4. その他のオプションはすべてデフォルトのままにして、デプロイ 図 6. アプリケーションのデプロイ 環境変数の設定 デプロイが成功したら、環境変数を設定 図 7. 環境変数の設定 アプリケーションの起動とテスト 提供された URL からアプリケーションを開き、テストを実施します。 図 8. Todo エントリのサンプル MongoDB Atlas の出力 図 9. MongoDB 内のデータ アプリケーションの確認 アプリケーションがデプロイされたので、内部で何が起きているのか、何が設定されたのかについて説明しましょう。 Amplify の Git ベースのワークフローを活用して、継続的デプロイメントを備えたフルスタックのサーバーレス Web アプリケーションをホストしました。Amplify は、Next.js や Nuxt のようなサーバーサイドレンダリング (SSR) フレームワーク、React や Angular のようなシングルページアプリケーション (SPA) フレームワーク、Gatsby や Hugo のような静的サイトジェネレーター (SSG) など、さまざまなフレームワークをサポートしています。今回は、SPA の React ベースのアプリケーションをデプロイしました。フィーチャーブランチ、カスタムドメイン、プルリクエストのプレビュー、エンドツーエンドテスト、リダイレクト/リライトを含めることができます。Amplify Hosting は Git ベースのワークフローを提供し、デプロイ全体が完了した後にのみ更新が適用されるアトミックデプロイメントを実現します。 アプリケーションのデプロイには AWS Amplify Gen 2 を使用しました。これは TypeScript を使用したフルスタックアプリケーションの開発とデプロイを簡素化するために設計されたツールです。クラウドリソースの管理には AWS Cloud Development Kit (CDK) を活用し、スケーラビリティと使いやすさを確保しています。 最後に、アプリケーションの更新の同時実行性について理解することが重要です。私たちは、シンプルな楽観的先着順の競合解決メカニズムを実装しました。MongoDB Atlas クラスターは、受信した順序で更新を永続化します。更新が競合した場合、最後に到着した更新が以前の更新を上書きします。このメカニズムは、更新の競合が少ないアプリケーションでは有効に機能します。本番環境のニーズに合わせて、より高度なアプローチの必要性を検討することが重要です。TanStack は、さまざまな接続シナリオを処理するためのより複雑なメカニズムを提供します。デフォルトでは、TanStack Query は「オンライン」ネットワークモードを提供し、ネットワーク接続がない限りクエリとミューテーションは実行されません。クエリの実行中にオフラインになった場合、TanStack Query はリトライメカニズムも一時停止します。一時停止されたクエリは、ネットワーク接続が回復すると実行を再開します。UI を新しい値や変更された値で楽観的に更新するために、想定されるレスポンスでローカルキャッシュを更新することもできます。このアプローチは、TanStack の「オンライン」ネットワークモードと相性が良く、アプリケーションにネットワーク接続がない場合、ミューテーションは実行されずにキューに追加されますが、UI の更新にはローカルキャッシュを使用できます。下は、サンプルアプリケーションが期待されるミューテーション結果でUIを楽観的に更新する重要な例です。 const createMutation = useMutation({ mutationFn: async (input: { content: string }) => { // Use the Amplify client to make the request to AppSync const { data } = await amplifyClient.mutations.addTodo(input); return data ; }, // When mutate is called: onMutate: async (newTodo) => { // Cancel any outgoing refetches // so they don't overwrite our optimistic update await tanstackClient.cancelQueries({ queryKey: ["listTodo"] }); // Snapshot the previous value const previousTodoList = tanstackClient.getQueryData(["listTodo"]); // Optimistically update to the new value if (previousTodoList) { tanstackClient.setQueryData(["listTodo"], (old: Todo[]) => [ ...old, newTodo, ]); } // Return a context object with the snapshotted value return { previousTodoList }; }, // If the mutation fails, // use the context returned from onMutate to rollback onError: (err, newTodo, context) => { console.error("Error saving record:", err, newTodo); if (context?.previousTodoList) { tanstackClient.setQueryData(["listTodo"], context.previousTodoList); } }, // Always refetch after error or success: onSettled: () => { tanstackClient.invalidateQueries({ queryKey: ["listTodo"] }); }, onSuccess: () => { tanstackClient.invalidateQueries({ queryKey: ["listTodo"] }); }, }); 追加の競合解決戦略を実装する プルリクエスト を歓迎します。 AWS MarketPlace で MongoDB Atlas を試してみましょう。 AWS Amplify 、 Amplify Gen2 、 AppSync について理解を深めましょう。 アプリケーションのデプロイに関する詳細な手順については、ドキュメントの デプロイの手順 を参照してください。 改善点を プルリクエスト として提出してください 本記事は、2025 年 6 月 19 日に公開された Offline caching with AWS Amplify, TanStack, AppSync and MongoDB Atlas を翻訳したものです。翻訳は Solutions Architect の吉村が担当しました。 Dan Kiuna – Specialist Solutions Architect, AWS Dan is a Specialist Solutions Architect at AWS AppSync. He is well experienced at leveraging AppSync’s capabilities alongside other AWS services to create high-performance, real-time, and offline-enabled solutions. Igor Alekseev – Partner Solutions Architect, AWS Igor works with strategic partners helping them build complex, AWS-optimized architectures. Prior joining AWS, as a Data/Solution Architect he implemented many projects in the Big Data domain. As a Data Engineer he was involved in applying AI/ML to fraud detection and office automation. Igor’s projects spanned a variety of industries including communications, finance, public safety, manufacturing, and healthcare. Anuj Panchal – Partner Solutions Architect, Mongo DB As a Partner Solutions Architect at MongoDB, I ideate, develop, and deploy seamless integrations between MongoDB and AWS offerings. My mission is to simplify the developer experience when working with MongoDB and AWS. LoveYourDevelopers

はじめに エッジでの人工知能（AI）は、スマートビデオデバイスの分野で人気を集めています。例えば、スマートホームカメラやビデオドアベルは、家庭での監視システムに革命をもたらしました。 単なる録画と遠隔閲覧ツールだったものが、知的な観測者へと進化しました。AI の導入により、現在のカメラは常にシーンを分析し、モーションイベントをユーザーに通知し、顔なじみの顔を認識し、荷物の配達を検知し、録画動作を動的に調整できるようになりました。 エンタープライズ監視カメラも同様の例です。これらのカメラは優れた解像度と高性能なコンピューティング能力を備え、より高度な AI モデルを実現できます。 これらの機能強化により、より遠くからの鮮明な検出が可能になります。 顧客は、プライバシーを維持し、帯域幅コストを削減しながら、現地でデータを処理できる知能的な監視システムを求めています。 これらのニーズに対応するために、AWS Internet of Things（AWS IoT） チームは、 Amazon Kinesis Video Streams 、Realtek の低消費電力 Ameba Pro2 マイクロコントローラー、および Plumerai の効率的な機械学習モデルを組み合わせた、AWS パートナーとのスマートカメラソリューションを開発しました。 このブログ記事では、エッジでの人体検知アルゴリズム処理と連動したイベントトリガーによるビデオアップロードに関するガイダンスを提供します。 ソリューションアーキテクチャ このブログで採用しているシステム構成図はこちらです: まず、カメラ部分について説明します。デバイスのファームウェアには、定義済み API 経由でカメラモジュールにアクセスするための Realtek SDK が統合されています。 映像フラグメントは Plumerai の機械学習モデルに送信され、物体検出が行われます。 サンプルアプリケーションは、検出結果をバウンディングボックスのオーバーレイとして元のビデオフラグメントに追加します。このサンプルは、 Kinesis Video Streams Producer SDK を使用して、フラグメントを継続的にクラウドにアップロードします。(補足として、検出結果をトリガーとして 20 秒間の映像セグメントをアップロードするよう設定することも可能です。) Kinesis Video Streams Producer SDK は、HTTPS の持続的接続を使用する PutMedia API  を使用し、MKV フラグメントをストリーミング方式で継続的にアップロードします。 メディアデータは取り込まれ、サービスによって 後の分析のため にすべてのメディアデータが永続的に保存されます。 フロントエンドアプリケーションは、Kinesis Video Streams の HLS または DASH プロトコル を使用して、ライブ映像や録画済み映像を再生します。 このソリューションでは、AI エージェントによる分析のため、映像と音声のデータを Large Language Models (LLMs) に送信します。(セマンティックビデオ検索については次回のブログで説明します。) 統合のポイント Amazon Kinesis Video Streams の利用 Kinesis Video Streams によって、企業のIPカメラ、ロボット、自動車向けの映像ソリューションの在り方が大きく変わります。主な利点は次のとおりです。 完全マネージド型のアーキテクチャのため、エンジニアリングチームはインフラストラクチャではなくイノベーションに注力できます。特に、リソースが限られた企業に最適です。 AWS SDK はオープンソース化されています。大手企業は特に、プラットフォームの制約に縛られないこの独立性を高く評価します。 柔軟な従量課金モデルを提供。デバイス開発に数か月から数年を要する場合でも、カメラが実運用されるまでコストはかかりません。一般的なクラウドストレージの利用率は30%以下で、年々使用量が減少するため、固定ライセンス料と比較してコストを大幅に抑えることができます。 Plumerai Plumerai は埋め込み AI ソリューションに特化しており、特にディープラーニングを小規模かつ効率的にすることに注力しています。 Plumerai のモデルは、小型で手頃な価格の低電力ハードウェアでの推論をサポートします。 同社は、以下の方法で Realtek Ameba Pro2 プラットフォーム向けに AI モデルの最適化も行っています。 アセンブリレベルの最適化により、Arm Cortex-M CPU のパフォーマンスを最大化し、DSP 命令を利用して拡張シグナルプロセッシング機能を実現できます。 Neural Architecture Search (NAS) により、Realtek NPU およびメモリアーキテクチャに最適な AI モデルを選択し、0.4 TOPS の NPU アクセラレーション を実現します。 Plumerai モデルは、Realtek オンチップハードウェアアクセラレータ (スケーラー、フォーマットコンバーター) を利用して計算負荷を軽減します。 AI モデルは RTOS をサポートしており、SoC のリアルタイムオペレーティングシステムとシームレスに統合されます。 このアプリケーションは Realtek のメディアストリーミング フレームワーク と統合されています。 高速ブート設計により、短時間で起動でき、バッテリー寿命が延びるだけでなく、動体検出の高速化も実現します。 エッジ AI モデルは、3000 万枚の画像とビデオデータで学習されています。 これらの機能強化により、実際の運用環境では以下のような性能が実現されます： メモリの無駄なく精密に検出できます。 180 ° の広範囲レンズにより、広範囲の撮影が可能。 20 メートル (65 フィート) 以上離れた位置から人物を検出可能。 最大 20 人までを同時に追跡でき、混雑した状況でも対応可能。 固有の ID システムで個人を特定できる追跡が可能。 明るい日中から真っ暗闇まで、一貫した性能を発揮します。 Realtek Ameba Pro2 上図は、Realtek Ameba Pro2 のデータアーキテクチャを示しています。統合ビデオエンコーダ (IVE) と、メディアの生データを処理してビデオオフロードエンジン (VOE) に結果を渡すイメージシグナルプロセッサ (ISP) が含まれています。VOE は、複数のビデオチャネルと同時のビデオストリームを管理し、動体検出アルゴリズムをサポートします。ニューラルプロセッシングユニット (NPU) が、画像または画像領域の推論を実行します。並列処理ユニット (PPU) は、高解像度画像からの関心領域 (ROI) の切り出し、NPU 推論入力のリサイズ、高解像度チャネルからの最終出力の取得など、マルチタスク処理を担当します。このアーキテクチャにより、エッジでの映像分析において以下のような強力な機能が実現可能となります： 最大の効率を得るために最小限の CPU 電力で動作します。 動きに対してほぼリアルタイムで応答します。 起動シーケンス中でもビデオ処理を開始できます。 セキュアな WiFi または Ethernet 経由で、SD カードとクラウドの両方にストリーミングできます。 NPU を活用して優れた AI パフォーマンスを実現します。 マルチメディアフレームワーク SDK を通じて、Plumerai モデルと Kinesis Video Streams に統合できます。 手順 このセクションでは、エッジ AI を実行し、動画のフラグメントをストリーミングするためのソリューションの構築手順の概要を説明します。 必要なもの 次の権限を持つ AWS アカウント: AWS コンソールへのログイン Kinesis Video Streams API (GetDataEndpoint、DescribeStream、PutMedia) Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの作成 (SDK とバイナリをビルドするため) Kinesis Video Streams コンソール で作成された “kvs-plumerai-realtek-stream” という名前のストリームリソース。 Realtek Ameba Pro2 Mini MCU。 組み込みシステムと Linux 環境での作業に関する基本的な知識。 SDK をダウンロードし、AWS にビデオをアップロードするためのインターネット接続。 Plumerai が提要するライブラリと機械学習モデルのファイル 。( Plumerai ウェブサイト でリクエストを送信してください。) ビルド環境のセットアップ このブログでは、ビルド環境として Ubuntu LTS 22.04 の Amazon EC2 を使用しています。 独自の Ubuntu コンピュータを使って SDK をクロスコンパイルすることもできます。 Amazon EC2 インスタンスのセットアップ: AWS 管理コンソールにサインインし、 Amazon EC2 に移動します。 次の構成でインスタンスを起動します: インスタンス名: KVS_AmebaPlumerAI_poc アプリケーションと OS イメージ: Ubuntu Server 22.04 LTS (HVM) インスタンスタイプ: t3.large ログイン用の新しい秘密鍵作成: kvs-plumerai-realtek-keypair ストレージの設定: 100GiB SSH 接続を許可するため、 SSH 接続に関する事前設定 に従ってください。 GitHub からサンプルスクリプトをダウンロード:  次のコマンドを使用して、Amazon EC2 インスタンスにログインします (xxx.yyy.zzz をインスタンスの IP アドレスに置き換えてください)。詳細な手順は、 SSH クライアントを使用して Linux インスタンスに接続する を参照してください。 ssh -o ServerAliveInterval = 60 -i kvs-plumerai-realtek-keypair.pem ubuntu @ 54.xxx.yyy.zzz git clone https://github.com/aws-samples/sample-kvs-edge_ai-video-streaming-solution.git cd ./sample-kvs-edge_ai-video-streaming-solution/KVS_Ameba_Plumerai Plumerai ライブラリを取得する:  Plumerai のお問い合わせフォームから リクエストを送信 し、デモパッケージのコピーを受け取ってください。パッケージが手に入ったら、Amazon EC2 インスタンス内の「plumerai」ディレクトリをそのパッケージに置き換えてください。更新後のディレクトリ構造は以下のようになります。 Ameba SDK を入手する: 最新の Ameba Pro2 SDK を入手するには、 Realtek にお問い合わせください。ディレクトリ構造においては、Amazon EC2 内の “ambpro2_sdk” を置き換えてください。ディレクトリ構造は以下のようになります: 依存関係のインストールと環境構築 GitHub リポジトリの sample-kvs-edge_ai-video-streaming-solution ディレクトリ内にある setup_kvs_ameba_plumerai.sh スクリプトを実行します: chmod +x setup_kvs_ameba_plumerai.sh./setup_kvs_ameba_plumerai.sh スクリプトは自動的に、 Linux の依存関係のインストール、Realtek ツールチェーンのビルド、必要な Plumerai のパッチ実行、モデルファイルのコピー、Kinesis Video Streams Producer SDK のダウンロードを実行します。 プロセスでエラーが発生した場合は、Realtek または Plumerai へご連絡ください。 Kinesis Video Streams Producer SDK のサンプル設定 AWS の認証情報、ストリーム名、AWS リージョンを設定するには、以下を使用してください。これらは、 component/example/kvs_producer_mmf/sample_config.h ファイルで確認できます。 // KVS general configuration #define AWS_ACCESS_KEY "xxxxx" #define AWS_SECRET_KEY "xxxxx" // KVS stream configuration #define KVS_STREAM_NAME "kvs-plumerai-realtek-stream" #define AWS_KVS_REGION "us-east-1" #define AWS_KVS_SERVICE "kinesisvideo" #define AWS_KVS_HOST AWS_KVS_SERVICE "." AWS_KVS_REGION ".amazonaws.com" /home/ubuntu/KVS_Ameba_Plumerai/ambpro2_sdk/component/example/kvs_producer_mmf/app_example.c ファイル内の example_kvs_producer_mmf(); と example_kvs_producer_with_object_detection(); をコメントアウトしてください。 //example_kvs_producer_mmf(); //example_kvs_producer_with_object_detection(); コンパイルとビルド 以下のコードを実行して KVS_Ameba_Plumerai ディレクトリに移動し、コンパイルとビルドの更新を行います。 cd ./KVS_Ameba_Plumerai cmake -DVIDEO_EXAMPLE=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_TOOLCHAIN_FILE=../ambpro2_sdk/project/realtek_amebapro2_v0_example/GCC-RELEASE/toolchain.cmake -Sambpro2_sdk/project/realtek_amebapro2_v0_example/GCC-RELEASE -Bbuild cmake --build build --target flash_nn Ameba Pro2 の中のサンプルを実行 バイナリイメージのダウンロードと書き込み： Amazon EC2 インスタンスから flash_ntz.nn.bin バイナリイメージをローカルマシンにダウンロードします。例えば、以下のようなコマンドをローカルマシンで実行します（ IP アドレスとフォルダパスは適切なものに変更してください）： scp -i kvs-keypair.pem ubuntu @ 54.64.xxx.xxx:/home/ubuntu/sample-kvs-edge_ai-video-streaming-solution/KVS_Ameba_Plumerai/build/flash_ntz.nn.bin ./flash_ntz.nn.bin Ameba Pro2 MCU を USB 経由でローカルマシンに接続し、両側のボタンを押してダウンロードモードに入ります。Realtek が提供する Ameba Pro2 イメージツールを使用して、バイナリイメージを書き込み、再起動します。 例えば、Windows 環境では以下のようなコマンドを使用します（ツールへのパスと COM ポート番号は環境に合わせて変更してください）： C:\Users\Administrator\Desktop\Pro2_PG_tool_v1.3.0>.\uartfwburn.exe -p COM3 -f flash_ntz.nn.bin -b 2000000 -U Mac OS では以下のコマンドを使用してください。 ./uartfwburn.arm.darwin -p /dev/cu.usbserial-110 -f ./flash_ntz.nn.bin -b 3000000 処理が完了すると、以下のような出力ログが表示されます： WiFiの設定方法： 赤色 LED インジケーターの横にあるリセットボタンを押します。  シリアルツールを使用して、以下のように設定します： Baud rate = 115200 Data bits = 8 Parity = None stop bits = 1, XON_OFF WiFi の設定情報を貼り付けます（ご使用のネットワークに合わせて情報を変更してください）： ATW0=myHotspotName ATW1=myPassword ATWC 入力が終わったら、Enter キーを押します。 処理が完了すると、以下のような出力ログが表示されます： AWS マネジメントコンソールで映像を確認する Ameba Pro2 を USB ポートに接続したまま、カメラを人の動きが撮影できる向きに設置します。 Kinesis Video Streams のコンソールを開き、作成したビデオストリームを選択します。物体検出結果がバウンディングボックス付きで表示された映像を確認できます。 人物と顔を示すバウンディングボックス付きの映像フラグメントが、サービスに正常に取り込まれ、永続的に保存されました。 性能の概要 ラボでのテスト結果によると、エッジ上のアプリケーションはわずか 1.5MB の ROM スペースしか必要とせず、Ameba Pro2 の NPU に最適化されています。このファームウェアは CPU 使用率わずか 20% で、毎秒約 10 フレームの処理速度を実現しました。これにより、追加のアプリケーションを実行する余裕も十分に残されています。 コストとクリーンアップ 通常、コンパイルとテストの全工程は 10 時間程度で完了します。総コストは 5 米ドル未満です。Amazon EC2 の詳細な料金については「 Amazon EC2 オンデマンドインスタンスの料金 」を、Kinesis Video Streams については「 Kinesis Video Streamsの料金 」をご参照ください。このサンプルアプリケーションは以下の 3 つの部分で構成されています： Kinesis Video Streams へのデータ取り込み HLS を使用した Kinesis Video Streams からのデータ消費 Kinesis Video Streams でのデータ保存 コストを節約するため、作成したリソースは以下の手順で削除してください： Amazon EC2 コンソール を開き、KVS_AmebaPlumerAI_poc インスタンスを終了 Kinesis Video Streams コンソール を開き、kvs-plumerai-realtek-stream ストリームを削除 まとめ ビデオアプリケーションの詳細については、以下を参照してください： Kinesis Video Streams からの メディアデータ の使用 Amazon Kinesis Video Streams のサンプル 迅速なテストと実験のための amazon-kinesis-video-streams-media-viewer AWS IoT YouTube チャンネルの「 WebRTC 用 Amazon Kinesis Video Streamsでカメラを 10 分で接続 」の動画 AWS Black Belt オンラインセミナーの「 Amazon Kinesis Video Streams 基礎編 」「 Amazon Kinesis Video Streams 応用編 」 Amazon Kinesis Video Streams、Realtek、Plumerai の連携により、エッジビジョンAI と高度なビデオストリーミング機能を活用した最先端のホームセキュリティソリューションが実現しました。この統合システムは、スマートホームと企業向け監視市場の双方で高まりつつある AI/ML ビデオソリューションへの需要に応えるものです。また、このソリューションは、監視機能の向上、効率的な処理、シームレスなクラウド統合を提供することで、家庭やビジネスにおける AI を活用したセキュリティ強化の可能性を示しています。 デバイス上で直接 AI 検出を行うこのエッジファーストのアプローチにより、必要になるまでビデオデータをローカルに保持することができ、プライバシーを保護しながら帯域幅の使用を大幅に削減できます。インテリジェントなビデオソリューションへの需要が続く中、この技術は、スマート監視システムおよびビデオモニタリングシステムの分野における新たな基準を確立しています。 この記事は Zihang Huang、Marco Jacobs、Siva Somasundaram、Emily Chou によって書かれた Efficient video streaming and vision AI at the edge with Realtek, Plumerai, and Amazon Kinesis Video Streams の日本語訳です。この記事は ソリューションアーキテクトの深澤 真愛が翻訳しました。 著者情報 Zihang Huang は、AWS のソリューションアーキテクトとして、コネクテッドビークル、スマートホーム、スマート再生可能エネルギー、産業用IoTのエキスパートとして活動しています。AWS 入社前はボッシュとAlibaba Cloud で技術経験を積み、現在は AWS IoT、エッジコンピューティング、ビッグデータ、AI、機械学習を組み合わせた分野横断的なソリューションの開発に取り組んでいます。 Siva Somasundaram は、AWSのシニアエンジニアとして、Kinesis Video Streams 向けの組み込み SDK とサーバーサイドコンポーネントの開発に従事しています。動画ストリーミングサービスにおける15年以上の経験を活かし、大規模な動画取り込みに対応したメディア処理パイプライン、トランスコーディング、そしてセキュリティ機能の開発に携わってきました。 動画圧縮、WebRTC、RTSP、ビデオ AI など、幅広い専門知識を有しており、セマンティック検索や RAG （検索補助生成）機能を実現するメタデータハブの創造、そして動画技術の可能性を追求することに情熱を注いでいます。 Emily Chou は、Realtek Semiconductor Corp.（リアルテック・セミコンダクター）のディレクターを務めています。無線通信ネットワーク技術を専門とし、AmebaIoT MCU の複数世代にわたる開発に携わってきました。現在は、コネクティビティソリューション、映像分析、エッジ AI コンピューティングの分野において、チームを率いて開発を推進しています。 Marco Jacobs は、Plumerai のプロダクトマーケティングの責任者として、スマートホームカメラや IoT デバイス向けの小型で高精度な AI ソリューションの普及を推進しています。カメラおよび画像処理アプリケーションにおける 25 年の経験を活かし、経営陣とエンジニアをシームレスにつなぎ、イノベーションを促進しています。7 件の特許を取得しており、最先端の AI 技術を実用的なビジネスチャンスへと変換することに情熱を注いでいます。

本記事は 2025 年 7 月 31 日に公開された “ Introducing Extended Support for Amazon ElastiCache version 4 and version 5 for Redis OSS ” を翻訳したものです。 Redis Open Source Software (OSS) バージョン 4 と 5 は、それぞれ 2020 年と 2022 年にコミュニティのサポート終了を迎えました。これは、コミュニティからの更新、バグ修正、セキュリティパッチがもう提供されないことを意味します。 Amazon ElastiCache はお客様が自分のペースでアップグレードできるよう、これらのバージョンのサポートを継続してきました。しかし、ElastiCache における ElastiCache Redis OSS バージョン 4 と 5 の標準サポートは 2026 年 1 月 31 日に終了します。サポートが終了した Redis OSS バージョンを使い続けると、既知の Common Vulnerabilities and Exposures (CVE) に対してデータが脆弱になる恐れがあります。 Amazon ElastiCache は、ビジネス要件に合わせたペースで新しいメジャーバージョンにアップグレードできるように、延長サポートを提供するようになりました。延長サポートは有償のサービスで、2029 年 1 月 31 日まで ElastiCache for Redis OSS バージョン 4 および 5 に対する重要なセキュリティアップデート、バグ修正、継続的なサポートを提供します。2026 年 2 月 1 日以降、アップグレードされていない ElastiCache Redis OSS v4 および v5 クラスターは、継続的な可用性とセキュリティを提供するために延長サポートに自動的に登録されます。延長サポートは柔軟性を提供しますが、標準サポートの終了を本番環境ワークロードの計画マイルストーンとして扱うことをお勧めします。標準サポートの終了前に、Redis OSS v4 および v5 クラスターを ElastiCache for Valkey または Redis OSS v6 以降にアップグレードすることを強くお勧めします。 この投稿では、ElastiCache 延長サポートの内容、主な利点、および利用可能なアップグレードオプションについて説明します。 ElastiCache 延長サポートのメリット ElastiCache 延長サポートは、ElastiCache の標準サポート終了後 3 年間にわたり、Redis OSS メジャーバージョンに対する CVE の重要なセキュリティアップデートと不具合修正を提供します。アップグレードの計画と実行のための追加時間を確保しながら、セキュアで安定したワークロードを維持することができます。 ElastiCache 延長サポート期間を賢く活用して、アプリケーションの互換性を検証し、リスクを軽減し、ElastiCache for Valkey または ElastiCache for Redis OSS v6 以降への移行を進めましょう。 次の表は、Amazon ElastiCache の標準サポート終了日と延長サポート日をまとめたものです。 メジャーエンジンバージョン 標準サポート終了 延長サポート Y1 プレミアム開始 延長サポート Y2 プレミアム開始 延長サポート Y3 プレミアム開始 延長サポート終了およびバージョンの EOL （サービス終了） Redis OSS v4 2026/1/31 2026/2/1 2027/2/1 2028/2/1 2029/1/31 Redis OSS v5 2026/1/31 2026/2/1 2027/2/1 2028/2/1 2029/1/31 延長サポート期間中、アップグレードには 2 つのオプションがあります： Service Update API を使用して、ElastiCache for Valkey バージョン 8 に自動アップグレードする Modify API を使用して、選択した対応バージョンにアップグレードする ElastiCache for Redis OSS バージョン 4 およびバージョン 5 の延長サポートでは、以下のメリットを提供します： 重要度 Critical および High の CVE に対する継続的なセキュリティアップデート 重大な問題に対する不具合修正とパッチ 標準 ElastiCache SLA 内でサポートケースをオープンしてトラブルシューティングのヘルプを受ける機能 2026 年 2 月 1 日以降、Redis OSS v4 および v5 で実行されているクラスターは、サービスとセキュリティカバレッジを中断なく確保するために、自動的に延長サポートに移行します。これにより、お客様は自分のタイムラインでアップグレードを計画しテストする柔軟性が得られます。 ElastiCache 延長サポートの料金は、ElastiCache 標準サポート終了後、毎年増加し、詳細な価格情報は Amazon ElastiCache pricing で確認できるようになります。 ElastiCache 延長サポート期間が 2029 年 1 月 31 日に終了した後、Redis OSS v4 または v5 で実行されている残りのクラスターは、サービスを継続するために、自動的に ElastiCache for Valkey の最新の安定版にアップグレードされます。 延長サポートは、Redis OSS の ElastiCache バージョン v4.0 および v5.0 で利用可能です。サポートされているバージョンの完全なリストについては、 ElastiCache のエンジンバージョンとアップグレード をご覧ください。 ElastiCache 延長サポートのユースケース ElastiCache 延長サポートを使用すると、AWS の継続的なセキュリティパッチとメンテナンスアップデートへのアクセスを維持しながら、ビジネスニーズに合わせてバージョンアップグレードをスケジュールできます。 特定の Redis OSS v4 または v5 に依存するアプリケーションは、互換性をテストするために追加の時間が必要になる場合があります。 以下は ElastiCache 延長サポートが役立つシナリオです： アプリケーションの依存関係 – 特定のアプリケーションは、特定のデータ構造やカスタム機能との互換性など、ElastiCache for Redis OSS v4 または v5 に特定の依存関係がある場合があります。これらのアプリケーションを新しいバージョンに移行するには、徹底的なテストが必要になることがあります。ElastiCache 延長サポートを使用すると、アップグレードパスを検証しながら、アプリケーションのワークフローを中断することなく現在のバージョンを引き続き使用できます。 大規模フリートの要件 – 多数の Redis クラスターを運用しているお客様にとって、アップグレードの調整は時間がかかり、運用が複雑になる可能性があります。ElastiCache 延長サポートを使用すると、チームは時間をかけて段階的にアップグレードを行うことができ、IT リソースに負担をかけることなくスムーズな移行が可能になります。この段階的なアプローチにより、組織は完全な移行を行う前に、フリートの一部に対するアップグレードの影響をテストして検証することができます。 これらのシナリオがワークロードに該当する場合、または ElastiCache の標準サポート終了日 (2026 年 1 月 31 日) までにアップグレードを完了できない場合、延長サポートを利用することで、移行を完了しながら Redis OSS v4 および v5 クラスターの実行を継続する柔軟性が得られます。 ElastiCache の最新バージョンへのアップグレードの主な利点 ElastiCache for Redis OSS バージョン 6 以降では、Redis OSS v4 および v5 と比較して、パフォーマンス、セキュリティ、運用効率を向上させるいくつかの機能強化が導入されています。 ElastiCache for Redis OSS バージョン 6 では、アクセスコントロールリスト (ACL) を通じてロールベースのアクセス制御 (RBAC) を利用できます。コマンド全体にわたってユーザーと詳細な権限を定義でき、安全なマルチテナント Redis クラスターを実現できます。このバージョンには、サーバーサイドの無効化を伴うクライアントサイドキャッシングも含まれており、頻繁にアクセスされるキーのネットワークラウンドトリップを削減し、レイテンシーを改善するのに役立ちます。 ElastiCache for Redis OSS バージョン 7 は、強化された I/O マルチプレキシングを導入することで、これらの改善点をさらに発展させ、高並行環境において Redis OSS v6 と比較して最大 72% 高いスループットと 71% 低い P99 レイテンシーを実現します。 これらの新しいバージョンにアップグレードすることで、アプリケーションのキャッシュレイヤーがより安全で、パフォーマンスが高く、機能が豊富になるメリットを得ることができます。ElastiCache Redis OSS の新しいバージョンのメリットについて詳しく知るには、 新機能 – Amazon ElastiCache の Redis 6 互換性 および New for Amazon ElastiCache for Redis 7: Get up to 72% better throughput with enhanced I/O multiplexing を参照してください。 ElastiCache for Valkey バージョン 8 以降では、Redis OSS バージョンと比較して、パフォーマンス、セキュリティ、運用効率を向上させるいくつかの機能強化が導入されています。 ElastiCache version 8 for Valkey には Redis OSS v6 と v7 の利点が含まれており、さらにコスト最適化、スケーラビリティ、そしてメモリ効率が20％向上と大幅な改善が加えられています。Valkey は Redis OSS API と完全に互換性があるため、アプリケーションコードを変更せずにアップグレードできます。 ElastiCache version 8.1 for Valkey は、バージョン 8 に加えてメモリ効率を 20% 向上させる新しいハッシュテーブル、Bloom フィルターの組み込みサポート、インメモリワークロードの観測性強化を導入しています。これらの改善は、特に大規模でメモリバウンドなキャッシュを実行しているお客様にとって、1 バイト、 1 ミリ秒が重要な場合に大きな影響を与えます。 ElastiCache Serverless for Valkey は、 13 分以内に 1 秒あたり 500 万リクエスト までスケールでき、キャパシティを事前にプロビジョニングすることなくバースト性の高いワークロードをサポートします。ノードベースの ElastiCache for Valkey を使用するお客様は、以前のバージョンと比較してキーあたり 32 バイト少ないメモリ使用量という改善されたメモリ効率の恩恵を受けられ、大規模なデータセットに対して意味のある節約につながります。Valkey は価格面でも優位性を持ち、Redis OSS より Serverless は 33% 低価格で、ノードベースのクラスターは 20% 低価格です。これらの改善は、Valkey のマルチスレッド I/O アーキテクチャとメモリモデルの強化によって実現されており、 AWS はオープンソースコミュニティの一部としてこれに貢献しています 。キャッシングインフラストラクチャをモダナイズするお客様にとって、Valkey は長期的なイノベーションと運用の柔軟性を備えた魅力的な選択肢を提供します。 Redis OSS v4 および v5 から新しいバージョンへのアップグレードオプション Amazon ElastiCache では、Redis OSS v4 および v5 から新しい Redis OSS バージョンまたは ElastiCache for Valkey にアップグレードするための 2 つのメカニズムを提供しています： Modify API を使用したインプレースアップグレードと、Service Update API を使用した管理されたアップグレードです。 どちらのアップグレード方法も既存のエンドポイントとクラスター構成を保持するため、アプリケーションワークロードへの影響を最小限に抑えてバージョン移行ができます。 適切な方法は、現在のバージョン、ターゲットエンジン、およびアップグレードが管理された自動化の対象となるかどうかによって異なります。 Modify API パスを使用すると、既存の ElastiCache クラスターまたはレプリケーショングループに新しいエンジンバージョンを指定することで、インプレースアップグレードを開始できます。この方法はすべての Redis OSS および Valkey バージョンでサポートされており、 AWS Management Console 、 AWS Command Line Interface （ AWS CLI ）—特に modify-replication-group または modify-cache-cluster コマンド—、またはサポートされている ElastiCache SDK を使用して実行できます。 アップグレードが適用されると、ElastiCache は基盤となるノードを指定されたバージョンを実行するインスタンスに置き換えます。メンテナンスウィンドウ中にアップグレードをスケジュールするか、 ApplyImmediately フラグを使用して即時に適用することができます。このアプローチにより、チームはアップグレードのタイミングを直接制御でき、幅広いクラスターアーキテクチャをサポートします。 サポートされているシナリオ ( Redis OSS から Valkey へのクロスエンジンアップグレードを含む場合) では、 Service Update API も使用できます。この方法では、定義されたウィンドウ内でバージョンアップグレードを確認、延期、またはスケジュールできるマネージドアップグレード体験を提供します。 サービスアップデートは AWS を通じて調整され、ElastiCache コンソールに表示され、進捗状況は Amazon EventBridge 通知を通じて追跡されます。 コンソールまたは batch-apply-update-action AWS CLI コマンドを使用してサービスアップデートを適用でき、現在のエンドポイントと構成を保持しながらアップグレードプロセスを開始できます。 いずれのタイプのアップグレードを開始する前にも、AWS では エンジンバージョンの互換性 とリリースノートを確認し、ステージング環境でアプリケーションの動作をテストし、最新のスナップショットが存在することを確認することをお勧めします。 Modify API または Service Update API を通じた各アップグレードアプローチは、ElastiCache for Valkey または Redis OSS v6 以降のバージョンに、自信を持って運用への影響を最小限に抑えて移行するために必要なツールと柔軟性を提供します。 まとめ ElastiCache for Redis OSS バージョン 4 および 5 延長サポートは、セキュリティやサポートを犠牲にすることなく、アップグレードの移行を完了するための追加の時間と柔軟性を提供するように設計されています。 古い Redis OSS バージョンと密接に結合されたワークロード、より長期間の検証サイクルを必要とするアプリケーション、または大規模なフリート全体での運用において、延長サポートは標準サポート終了後も 3 年間、重要なパッチ、不具合修正、および AWS Support SLA への継続的なアクセスを提供します。 ElastiCache の標準サポート終了日である 2026 年 1 月 31 日よりも十分前に、アップグレードの計画を立てることをお勧めします。ElastiCache for Valkey または Redis OSS v6 以降へのアップグレードにより、強化されたセキュリティ、パフォーマンスの向上、メモリ効率の改善、そして長期的なコミュニティと AWS のサポートを利用できるようになります。 Modify API を使用したインプレースアップグレードや、Service Update API を使用した管理ワークフローなど、柔軟なオプションから選択できるため、運用ニーズに合わせたアップグレード方法を計画することができます。 次のステップとして、現在の Redis OSS エンジンバージョンを確認し、アップグレードのタイムラインに影響する可能性のある依存関係を特定し、ステージング環境で新しいバージョンのテストを開始してください。標準サポート終了までにアップグレードを完了しないお客様は、2026 年 2 月 1 日から自動的に ElastiCache 延長サポートに登録されます。料金は、 Amazon ElastiCache 料金ページ に記載されているように、バージョンと ElastiCache 延長サポートの期間に基づいて設定されます。 追加のガイダンスについては、 ElastiCache のバージョン管理 、 ElastiCache のエンジンバージョンとアップグレード 、および Amazon ElastiCache for Valkey の使用開始 を参照してください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Sai Chidam Sai は AWS のインメモリデータベースチームのプロダクトマネージャーで、ElastiCache サービスの成長に注力しています。仕事以外では、サッカーをしたり、シアトル周辺での自転車走行を楽しんでいます。 Sumit Goel Sumit は Amazon ElastiCache のシニアソフトウェア開発エンジニアです。仕事以外では、新しい場所を訪れたり、ギターを弾いたり、家族と時間を過ごすことを楽しんでいます。

このブログは、Ram Gorur、Ashish Chaurasia、Channa Samynathan によって書かれた Preventing Machine Breakdowns: How Physical AI Predicts Equipment Problems を翻訳したものです。翻訳は、ソリューションアーキテクトの戸塚智哉が担当しました。 フィジカル AI: 現実世界で機能するインテリジェンス フィジカル AI は、物理世界と直接相互作用して操作するという点で、従来の AI とは異なります。従来の AI がデータを処理し画面上にテキストを生成するのに対し、フィジカル AI はロボット、自動運転車、スマートシステムが、実際の 3 次元環境を認識、理解、行動することを可能にします。 重要な違い: 物理 AI は、合成データと実世界のデータで学習することにより、空間的な関係性と物理的な振る舞いを理解し、デジタル知能と物理行動の溝を埋めています。 動作の仕組み: 高精度のコンピュータシミュレーションにより、工場や都市の街路などの現実の空間のデジタルツインが作成されます。そこでは、実世界の物理法則をミラーリングする仮想センサやマシンを使って、高度に特化したモデルを学習させます。 メインテナンスの変革 フィジカル AI によってメンテナンスは対応型から自律型に移行します。これらのシステムは環境を認識し、コンポーネントの関係を理解し、問題が発生する前に予防措置を講じます。自動車の予測メンテナンス (PdM) の 市場 は 2032 年までに 1000 億ドルに達し、フィジカル AI の能力により、車両の世話が革命的に変わります。 電気自動車 (EV) は フィジカル AI を実際に活用できる良い例です。EV は周囲から常に学習し、性能を最適化するために即座に判断を下し、移動中に自身の健康状態を管理できるように設計できます。このようなシステムは、部品がどのように組み合わさって動作するかを理解し、物理的な力がさまざまな部品にどのように影響するかを予測し、摩耗を減らすために運転パターンを調整します。 車の PdM と同じ原理が、他の分野にも表れています。 製造ロボット は、故障が発生する前に、故障を予測して防止することができます。 スマートな倉庫 では、システムが最大の効率化のため、自身の保守管理をスケジューリングします。 医療ロボット は、自身の精度を監視し、必要に応じてセルフキャリブレーションを行います。 スマートな社会基盤インフラ さえ、自らの問題を検出し、修理を自動的に調整できます。 実際の仕組み 現代の EV に搭載された AI システムは、統合されたセンサーネットワークを介して、継続的に複数の車両システムを分析し、車両の監視とメンテナンスを行う高度なアプローチを表しています。このシステムはバッテリーの健康状態、モーターの性能、ブレーキ、サスペンションコンポーネントを追跡し、各コンポーネント間の動的モデルを構築します。AI は、温度、振動、電気負荷、機械的ストレスの関係を監視し、潜在的な故障を予測して防止します。バッテリーへのストレスを軽減するための充電パターンの調整や、磨耗を最小限に抑えるための回生ブレーキの変更など、事前対応を行います。この予知保全アプローチは、従来の受動的な車両メンテナンスから、実際の条件を理解し対応する、積極的なシステムへと変容させます。ただし、利点を定量化するには、具体的な性能指標と結果データが必要です。 概要 このブログでは、フィジカル AI AI 主導の製品データ管理 (PdM) を変革している生成 AI アプリケーションの種類と、AWS サービスがこれらのイノベーションを可能にする方法について学びます。 AWS Internet of Things (IoT) 、人工知能 (AI) /機械学習 (ML)、そして生成 AI は、フィジカル AI 駆動型 PdM (予知保全) のための革新的なソリューションを提供することで、コネクテッドカーの分野、特に EV の分野の状況を一変させました。これらの先進技術を統合することで、物理システムの深い理解を通じて、EV の最適なパフォーマンスと長期的な耐久性を確保するために、より効率的で効果的な EV の維持アプローチへの道が開かれました。 AWS IoT は多くの自動車顧客によって、物理 AI アプリケーション (自動運転、予防保全、インフォテインメントなど) の開発と管理に使用されています。AWS IoT により、電気自動車はクラウドに接続して、位置関係や部品間の物理的相互作用を含む状態とパフォーマンスについての リアルタイムデータを送信できます。そのデータはその後、AWS の AI / ML サービスを使って分析され、さまざまなシステムが現実世界でどのように物理的に相互作用するかを理解することで、パターンを特定し、異常を検出し、潜在的な問題を予測することができます。 フィジカル AI 駆動型 PdM における生成 AI は、次の 4 つの主要なステージで動作します。 機械の優先順位付け では、検索補完生成 (RAG) システムを使用して、構造化データと非構造化のメンテナンスデータを分析し、優先的に注意が必要な機器を特定します。 故障予測 では、リアルタイム分析と ML モデルを使用して機械のセンサーデータを処理し、故障が発生する前に予測します。 修理計画の生成 では、大規模言語モデルを利用して、複数のソースからデータを統合し、作業手順やリソース配分を含む包括的な作業指示書を作成します。 メンテナンス指針の生成 では、サービスメモと修理計画を生成 AI で組み合わせ、技術者向けに拡張され、実行可能な指針を提供します。 このアプローチにより、自動車メーカーは実際の物理的条件下での車両の性能に関する豊富なデータを収集できます。車両が物理環境とどのように相互作用するかを把握し、実際の物理法則と使用パターンを考慮したコンポーネントの改良について、確かな情報に基づく意思決定を行うことで、将来の車両設計を改善できるのです。 アーキテクチャの概要 EV における PdM とは、収集した洞察に基づいて監視、分析、処理を行うことを指します。EV には、バッテリー状態、車両位置、モーター状態、ブレーキ状態などのさまざまなデータを収集するためのセンサーが装備されています。運用コストを最小限に抑えるため、このパターンはセンサーデータを利用して PdM モデルを作成することで、EV の保守を強化することを目的としています。 1. データ取り込みおよび処理 コネクテッドカーは、自動車メーカーにとって車両品質、安全性、自動運転性を高める機会となります。しかし、これらの進歩には課題があり、特にコネクテッドカーから生成される膨大なデータを効果的に管理し活用することが挙げられます。車両データの収集は、さまざまなメーカーが採用する ECU (電子制御ユニット) の独自データ形式が多様であることと、データ収集体制の拡大に伴うコスト増が大きな問題となっています。 AWS IoT FleetWise は、自動車業界向けの AWS 製専用サービスです。車種、モデル、オプションにかかわらず、車両に存在する様々な形式のデータを簡単に収集・変換・転送できます。このサービスでは、データ形式を標準化するため、クラウド上で分析する際にカスタムデータ収集システムを必要としません。AWS IoT FleetWise では、インテリジェントなフィルタリング機能を利用して、データをほぼリアルタイムでクラウドに効率的に転送できます。転送するデータを選択し、天候条件、場所、車種などのパラメータに基づいてルールやイベントを定義することで、クラウドに送信するデータ量を削減できます。 このセクションでは、AWS IoT FleetWise を使用して車両データを収集し、S3 に保存します。これは、予測分析のための機械学習モデルを学習するためです。 車両に AWS IoT FleetWise エッジエージェントをセットアップ – AWS IoT FleetWise の Edge Agent を作成し、車両とクラウドの間の通信を促進します。Edge Agent は、車両データ収集用に設計された C ++ で記述された完全なソフトウェアで、ほとんどの組み込み Linux プラットフォームで実行できます。IoT FleetWise は、Edge Agent から車両から収集・転送するデータを制御します。 シグナルカタログを作成する – シグナル は車両のデータとメタデータを個別のタイプに構造化します: センサー は温度などのリアルタイム測定値を取得し、それぞれのシグナル名、データ型、単位を保存します。 属性 はメーカーや製造日などの固定情報を含みます。ブランチは階層的な構造を作ります。 Vehicle ブランチから Powertrain が分かれ、さらに combustionEngine サブブランチが作成されます。センサーデータは、液体レベル、温度、振動などの車両の即時状況を追跡します。 アクチュエータ データはモーターやドアロックなどのコンポーネントの状態を制御します。デバイスを調整する (ヒーターのオン/オフを切り替えるなど) と、アクチュエータデータを更新します。 シグナルカタログは、あらかじめ定義されたシグナルで車両モデリングを簡素化します。AWS IoT FleetWise は Vehicle Signal Specification (VSS) を統合し、「vehicle_speed」のような標準シグナルを時速 (km/h) で定義します。この標準センサーとシグナルの中央リポジトリにより、シグナルを効率的に再利用することで、新しい車両モデル作成を加速できます。 車両モデルを作成する – 車両モデルを使って、車両のフォーマットを標準化します。車両モデルにより、同じ種類の複数の車両でデータが均一になり、車両の集団からのデータ処理を効率化できます。同じ車両モデルから作成された車両は、一貫したシグナルのセットを継承します。 デコーダマニフェストの作成 – デコーダマニフェストには、AWS IoT FleetWise がバイナリ形式の車両データを簡単に理解できる値に変換するためのデコーディング情報が含まれています。IoT FleetWise は OBD II、CAN バス、ROS2 などの車載ミドルウェアをサポートしています。たとえば、車両が OBD ネットワークインターフェースを利用している場合、デコーダマニフェストには、メッセージ ID 11 と 0000 × 11 のようなバイナリデータを OBDCoolantTemperature に関連付けるシグナルを含める必要があります。 ビークルの作成 – ビークルはビークルモデルのインスタンスです。ビークルは、ビークルモデルから作成され、デコーダーマニフェストに関連付ける必要があります。ビークルは、1 つ以上のデータストリームをクラウドにアップロードします。例えば、ビークルは走行距離、バッテリー電圧、ヒーターの状態などのデータをクラウドに送信できます。 車両データを収集するキャンペーンの作成とデプロイ – 車両がモデル化され、シグナルカタログが作成されると、モデル内で作成されたシグナルを使用してデータ収集キャンペーンを作成できるようになります。キャンペーンとは、データ収集ルールの指示の束です。キャンペーンでは、AWS IoT FleetWise エッジエージェントソフトウェアにデータを選択、収集、クラウドに転送する方法を指示します。すべてのキャンペーンはクラウドで作成されます。チームメンバーによってキャンペーンが承認されると、AWS IoT FleetWise は自動的にそれらを車両にデプロイします。自動車チームは特定の車両またはフリートに対してキャンペーンをデプロイするかを選択できます。稼働中のキャンペーンが車両にデプロイされるまで、エッジエージェントソフトウェアは車両のネットワークからのデータの収集を開始しません。 車両データを S3 に格納する – AWS IoT FleetWise 用のエッジエージェントソフトウェアが、選択された車両データを Amazon Timestream または Amazon Simple Storage Service (Amazon S3) に転送します。データが転送先に到着したら、他の AWS サービスを使ってデータを可視化したり共有したりすることができます。 2. PdM モデルのトレーニング 機械学習 (ML) アルゴリズムは、ここで電気自動車 (EV) の故障を予測し、保守活動を最適化するための予知保全 (PdM) 分析に活用されています。予知保全は、リアルタイムのデータを使用して、故障の原因となる様々な要因を分析することで、潜在的な故障の発生を予測できます。この積極的なアプローチにより、予期しない車両の故障を効果的に最小限に抑え、EV 部品の寿命を延ばし、総修理費用を削減することができます。 EV データが AWS 環境に取り込まれると、Amazon S3 バケットに保存されます。Amazon S3 に保存されたデータを使って、学習済みでデプロイされた ML モデルから、リアルタイムの予測が生成されます。この予測は更に処理され、ダウンストリームのアプリケーションで必要なアクションを実行し、PdM アクティビティを開始するために利用されます。このソリューションは以下のセクションから構成されています。 モデルの訓練とデプロイ – データリポジトリから PdM データセットを使用し、SageMaker で XGBoost アルゴリズムによる機械学習モデルを訓練します。その後、訓練したモデルを SageMaker の非同期推論エンドポイントにデプロイします。 モデルの訓練 – モデルを訓練するために、まず EV データを Amazon S3 に保存します。これにより、扱うデータの膨大な量を安全かつ効率的に保管できます。データを保存したら、Amazon SageMaker Training を使って訓練プロセスを開始できます。このサービスは、様々な機械学習モデルを大規模に訓練できるよう設計されています。その機能により、大規模データセットを扱う場合でも、高速かつ正確なモデル訓練を実現できます。つまり、モデル訓練の効率と有効性を確保し、高品質な結果を得られます。 リアルタイム近くの EV データ取り込み – 車両から収集された EV データは、AWS 環境で処理された後、Amazon S3 に保存されます。このデータには、バッテリー電圧、バッテリー温度、モーター状態、位置情報などの重要なパラメータが含まれています。その後、Amazon Lambda 関数がトリガーされ、非同期の Amazon SageMaker エンドポイントを呼び出します。 リアルタイム近くで PdM を実行 – 非同期の Amazon SageMaker エンドポイントを利用して、デプロイされたモデルから入力 EV データに対する推論を生成します。これらのエンドポイントは、大きなペイロードサイズに対応しており、数分以内に推論を生成できるため、PdM ワークロードに適しています。モデルから生成された推論は Amazon S3 に保存されます。これらの推論を、ダッシュボードの作成、可視化、生成 AI タスクの実行などに活用できます。 予測メンテナンスソリューションが大規模展開においても効果的に機能するようにするには、機械学習に関する AWS Well-Architected フレームワークの原則 [3] を参照し、堅牢な訓練とデプロイのパイプラインを実装してください。 3. 生成 AI AWS Glue クロールラー (または別の方法) を使用して AWS Glue Data Catalog を作成します。Amazon Bedrock の Titan-Text-Embeddings モデルを使って、メタデータをエンベディングに変換し、Amazon OpenSearch Serverless ベクトルストアに保存します。これが、私たちの RAG フレームワーク におけるナレッジベースとなります。この段階で、自然言語によるクエリを受け取る準備ができています。 ユーザーは自然言語でクエリを入力します。チャット UI を提供するためのウェブアプリケーションは任意のものを使用できます。そのため、投稿では UI の詳細については取り上げていません。 ソリューションは、ベクトルデータベースからのメタデータの追加コンテキストを利用してシミラリティ検索による RAG フレームワークを適用します。この表は、正しいテーブル、データベース、属性を見つけるために使われます。 モデルは生成された SQL クエリを受け取り、Athena に接続して構文をチェックします。 最後に、Athena で SQL を実行し、出力を生成します。ここでは、出力をユーザーに提示します。アーキテクチャの単純化のため、この手順は示していません。 まとめ 生成 AI と フィジカル AI の融合は、あらゆる業界で条件に基づいた予防保全と予測保全を根本的に再構築しています。これまでの議論で探ってきたように、生成 AI は膨大なデータセットを分析し、合成的な訓練シナリオを生成し、知的なアドバイスを提供する能力を持っており、フィジカル AI システムの自己モニタリング、診断、自己保全の仕方を変革させています。バッテリー劣化を予測する電気自動車から、自らのメンテナンスをスケジューリングする産業用ロボットまで、単にタスクを実行するだけでなく、自らの運用能力を積極的に維持し最適化する知的システムへのパラダイムシフトを目の当たりにしています。 参考資料 NVIDIA: 物理 AI とは何か？ 予知保全: 機械が修理が必要なことを前もって知る ウェル・アーキテクトされた機械学習 複雑なクエリを生成し、自己修正し、様々なデータソースを問い合わせる堅牢なテキスト to SQL ソリューションを構築する 世界の自動車予知保全市場のコンポーネント別分析 GitHub – 予知保全 MVP 著者について Ram Gorur は、エッジ AI とコネクテッド・プロダクツにフォーカスした農業とコンサルティング・サービスを専門とする AWS のシニア・ソリューション・アーキテクトです。バージニア州を拠点とし、23 年以上にわたる包括的なIT経験を活かして、AWS のエンタープライズ顧客がエッジデバイスからクラウドインフラストラクチャに至るまで IoT ソリューションを実装できるよう支援しています。エッジコンピューティングとクラウド機能の橋渡しをするカスタマイズされたアーキテクチャフレームワークを開発しています。農業、IoT、クラウド技術に関するラムの知識を組み合わせることで、エッジからクラウドへの接続を通じて企業の業務の近代化を支援する統合ソリューションを生み出すことができます。 Ashish Chaurasia は、 AWS の シニア・テクニカル・アカウント・マネージャーとして、2020年以降、クラウド技術を戦略的なビジネス成果に結びつけるため、企業顧客と提携しています。17 年以上のソフトウェア開発経験を持ち、クラウドネイティブのトランスフォーメーション・ジャーニーを通じて組織を導くことを専門としています。IoT愛好家であり、日々のタスクを自動化するDIYプロジェクトを構築するのが趣味です。 Channa Samynathan は、AWS Edge AI & Advanced Compute のシニア・ワールドワイド・スペシャリスト・ソリューション・アーキテクトです。テクノロジー業界で 29 年以上の経験を持ち、設計エンジニアリング、システムテスト、オペレーション、ビジネスコンサルティング、製品管理など、さまざまな職務を歴任。キャリアは複数の多国籍通信企業にまたがり、営業、事業開発、技術ソリューション設計の分野で一貫して専門性を発揮してきた。26 カ国以上で働いたグローバルな経験により、深い技術的洞察力と新技術への迅速な適応能力を備えています。AWS では、顧客との協業、エッジからクラウドまでのエッジコンピュートアプリケーションの設計、AWS のバリュープロポジションに関する顧客教育、顧客向けの出版物への貢献に注力しています。

8 月 18 日週のアップデートは、私が特に楽しみにしていることから始めます。それは、近日公開予定の BeSA (Become a Solutions Architect) グループです。BeSA は無料のメンタープログラムで、私を含む数人の AWS 従業員がボランティアとして主催しています。参加者がクラウドでのキャリアにおいて活躍できるように支援するプログラムです。先週、9 月 6 日から始まる 6 週間のグループのインストラクターが確定しました。本グループは、AWS での移行とモダナイズに焦点を当てます。詳細については、 BeSA のウェブサイト をご覧ください。 先週のもう 1 つのハイライトは、技術的なリーダーシップを発揮し、AWS コミュニティに大きく貢献した 6 人の新しい AWS ヒーローの発表でした。これらのコミュニティリーダーの詳細については、 アナウンス全文 をお読みください。 8 月 11 日週のリリース 8 月 11 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Amazon EC2 シングル GPU P5 インスタンスの一般提供を開始 – NVIDIA H100 GPU を 1 基搭載した新しい Amazon Elastic Compute Cloud (Amazon EC2) P5 インスタンスサイズでは、機械学習 (ML) とハイパフォーマンスコンピューティング (HPC) のリソースを、コスト効率よく適切なサイズに調整できます。 AWS Advanced Go Driver の一般提供を開始 – AWS Advanced Go Driver を Amazon Relational Database Service (Amazon RDS) および Amazon Aurora PostgreSQL 対応と MySQL 対応のデータベースクラスターで使用できるようになりました。これにより、スイッチオーバーとフェイルオーバーにかかる時間を短縮し、フェデレーション認証と AWS Secrets Manager または AWS ID とアクセス管理 (IAM) による認証を行うことができます。 GitHub のインストールガイドに沿って、Windows、Mac、または Linux 用の PostgreSQL パッケージと MySQL パッケージをインストールできます。 Amazon EKS Hybrid Nodes を使用した Cilium のサポートの拡大 – Cilium は Cloud Native Computing Foundation (CNCF) の卒業プロジェクトで、Kubernetes ワークロードのコアネットワーキング機能を提供します。これにより、Amazon EKS Hybrid Nodes で Cilium を使用する場合、アプリケーションイングレス、クラスター内負荷分散、Kubernetes ネットワークポリシー、kube-proxy 置換モードなど、Cilium の幅広い特徴量について AWS からサポートを受けることができます。 Amazon SageMaker AI が P6e-GB200 UltraServer のサポートを開始 – Amazon SageMaker HyperPod とモデルトレーニングの新しい P6e-GB200 UltraServer サポートにより、1 つの NVLink ドメインで最大 72 台の NVIDIA Blackwell GPU を使用して、基盤モデル (FM) のトレーニングとデプロイを兆パラメータ規模で加速できます。 Amazon SageMaker HyperPod では、 コンピューティングリソースのきめ細かなクォータ割り当て 、 LLM タスクのトポロジに応じたスケジューリング 、 カスタム Amazon マシンイメージ (AMI) のサポートを開始しました。コンピューティングリソースの分散を最適化するために、インスタンス内の GPU、Trainium アクセラレータ、vCPU、vCPU メモリにきめ細かなコンピューティングクォータを割り当てることができます。トポロジ対応のスケジューリングにより、大規模言語モデル (LLM) タスクを最適なネットワークトポロジ上でスケジューリングできるため、ネットワーク通信を最小限に抑え、トレーニングの効率を高めることが可能です。カスタム AMI を使用すると、特定の組織要件を満たす事前設定済みのセキュリティ強化環境でクラスターをデプロイできます。 その他のアップデート 興味深いと感じたその他のニュース項目とブログ記事をいくつかご紹介いたします。 Amazon Aurora イノベーションの 10 周年をお祝いしましょう – 2025 年 8 月 21 日に開催される ライブストリームイベント に参加して、Aurora データベースのイノベーションの 10 年をお祝いしましょう。 2025 Gartner Magic Quadrant の Strategic Cloud Platform Services 部門で AWSが「リーダー」に選出 – Gartner は 15 年連続で、Gartner Magic Quadrant の Strategic Cloud Platform Services (SCPS) 部門で AWS を「リーダー」に選出しました。これにより、AWS は Magic Quadrant における最長の「リーダー」となりました。 AWS Cloud Control API (CCAPI) MCP サーバーのご紹介 – 自然言語を使用して、CCAPI MCP サーバーを用いたクラウドインフラストラクチャの管理ができるようになりました。自然言語を使ってリソースの作成、読み取り、更新、削除、一覧表示を行うことができます。 Amazon Bedrock AgentCore Identity のご紹介 – AgentCore Identity は、エージェントの ID を一元管理し、認証情報を保護し、Sigv4、標準化された OAuth 2.0 フロー、API キーを通じて AWS やサードパーティーのサービスとのシームレスな統合をサポートする機能を提供します。 Amazon Bedrock AgentCore Gateway のご紹介 – AI エージェントをツールやサービスに接続するフルマネージド型サービスです。一元化されたツールサーバーとして機能し、エージェントがツールの検出、アクセス、呼び出しを行うことができる統一されたインターフェイスを提供します。 近日開催予定の AWS イベント カレンダーを確認して、今後の AWS や AWS コミュニティのイベントにサインアップしましょう。 AWS re:Invent 2025 (2025 年 12 月 1 日〜5 日、ラスベガス) – AWS の主力年次カンファレンスでは、ピアツーピア学習、専門家主導のディスカッション、貴重なネットワーキングの機会を通じて、共同イノベーションを提供します。 AWS Summit – クラウドコンピューティングコミュニティが集まり、交流し、協力し、AWS について学ぶことができる無料のオンラインイベントと対面イベントにご参加ください。間もなく ヨハネスブルグ (8 月 20 日) と トロント (9 月 4 日) でサミットが開催されます。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18 日)、 南アフリカ (9 月 20 日) です。 AWS Builder Center に参加して、AWS コミュニティで AWS ビルダーとともに学び、構築し、交流しましょう。今後開催される追加の 対面イベント と デベロッパー向けのバーチャルイベント をこちらでご覧ください。 8 月 18 日週のニュースは以上です。8 月 25 日週にお届けする次回の Weekly Roundup もお楽しみに! – Prasad 原文は こちら です。

2025 年 8 月 4 日、Gartner Magic Quadrant for Strategic Cloud Platform Services (SCPS) を発表しました。Gartner が 15 年連続でリーダーとして選出している Amazon Web Services (AWS) は、最も長期にわたる Magic Quadrant のリーダーの地位を確立しています。 Gartner はこのレポートで、AWS を「実行能力」軸で再び最高位に位置付けました。当社はこれを、イノベーションを加速するための極めて幅広く奥深い機能セットと、お客様が最も重要なアプリケーションのために信頼できる比類のないセキュリティ、信頼性、パフォーマンスをお客様に提供するという、当社の継続的な取り組みが評価されたものであると考えています。 2025 Magic Quadrant for Strategic Cloud Platform Services をグラフ化した図を以下に示します。 Gartner は、AWS の強みを次のように認識しています: 最大のクラウドコミュニティ – AWS は、クラウドプロフェッショナルの強力なグローバルコミュニティを構築し、学習とエンゲージメントのための重要な機会を提供しています。 クラウドにインスピレーションを得たシリコン – AWS は、クラウドコンピューティング分野での経験を活かし、 AWS Graviton 、 AWS Inferentia 、 AWS Trainium などのカスタムシリコン設計を開発しました。これにより、ハードウェアとソフトウェアのより緊密な統合、電力効率の向上、サプライチェーンに対するより強力なコントロールが可能になります。 グローバルな規模と運用上の実行 – AWS はグローバルなクラウド市場の収益において大きなシェアを占めており、これにより、この分析に含まれる他のいくつかのプロバイダーよりも大規模かつ堅牢な統合パートナーネットワークを構築できています。これは、組織が成功裏にクラウドを導入するのに役立っています。 お客様から最も多く寄せられるフィードバックは、AWS には最大規模かつ極めてダイナミックなクラウドコミュニティがあり、世界中の何百万ものアクティブなお客様や何万ものパートナーに質問したり、学んだりすることが容易であるというものです。当社は最近、 AWS ヒーロー や AWS コミュニティビルダー と直接つながることができるコミュニティハブである AWS Builder Center を立ち上げました。また、お近くの都市で開催される AWS ユーザーグループ や AWS クラウドクラブ を詳しく確認して、参加することもできます。 さらに、 AWS Migration Acceleration Program など、さまざまな エンタープライズプログラム を通じて、エンタープライズのお客様のデジタルトランスフォーメーションの促進にも注力しています。移行とモダナイゼーションに 生成 AI を活用し、.NET、メインフレーム、VMware などのミッションクリティカルなビジネスワークロードのエンタープライズモダナイゼーションを加速するために開発された初のエージェンティック AI サービスである AWS Transform を導入しました。 詳細については、 Gartner レポート全文 をご覧ください。これには、レポートに含まれる各クラウドサービスプロバイダーの評価に使用された方法論と評価基準の概要が記載されています。このレポートは、顧客に代わってイノベーションを支援するクラウドプロバイダーを選ぶ際の指針となります。 – Channy Gartner は、その調査出版物に記載されているベンダー、製品、またはサービスを推薦するものではなく、最高評価または他の認定を受けたベンダーのみを選定するようテクノロジーユーザーに助言するものでもありません。Gartner の調査出版物は、Gartner の調査組織による見解で書かれたものであり、事実を表明するものではありません。Gartner は、本調査に関して、明示または黙示を問わず、商品性または特定目的適合性に関する保証を含め、一切の保証を放棄します。 GARTNER は Gartner の登録商標およびサービスマークであり、Magic Quadrant は Gartner, Inc. および/またはその米国および他国の関連会社の登録商標であり、許可を得て使用されています。All rights reserved. 原文は こちら です。

10 年前、 弊社は Amazon Aurora の一般提供の開始を発表しました 。Amazon Aurora は、高性能な商用データベースのスピードと可用性、そして、オープンソースデータベースのシンプルさとコスト効率を兼ね備えたデータベースです。 Jeff が リリース時のブログ記事 で述べているように、「3 つのアベイラビリティーゾーン内で、およびこれらのアベイラビリティーゾーン全体でストレージがレプリケートされ、クォーラム書き込みによる更新モデルを備えた Amazon Aurora は、最大 64 TiB のストレージまで簡単かつ効率的にスケールしながら、高いパフォーマンスと 99.99% の可用性を実現するように設計されています」。 弊社は、10 年以上前に Aurora の開発を開始したとき、アーキテクチャに関して、データベースのあり方を永遠に変える根本的な意思決定を下しました。ストレージとコンピューティングを疎結合したのです。この斬新なアプローチにより、Aurora は、商用データベースと同等のパフォーマンスと可用性を 10 分の 1 のコストで実現できました。 これが、数十万の AWS のお客様がリレーショナルデータベースとして Aurora を選択する理由の 1 つです。 8 月 15 日は、 2025 年 8 月 21 日に開催される、Aurora データベースのイノベーション 10 周年を記念するライブストリームイベント に皆様をご招待します。 これまでの歩みを簡単に振り返る Aurora の進化を通じて、当社は 4 つのコアイノベーションテーマに注力してきました。すなわち、最優先事項としてのセキュリティ、増大するワークロードに対応するスケーラビリティ、コスト管理を改善する予測可能な料金、グローバルアプリケーションのためのマルチ リージョン 機能です。Aurora の歩みにおける重要なマイルストーンをいくつかご紹介します。 弊社は re:Invent 2014 で Aurora をプレビュー し、 2015 年 7 月に一般提供を開始 しました。リリース時には、Aurora を「コスト効率の高い新しい MySQL 互換データベースエンジン」として紹介しました。 2016 年 6 月には、 リーダーエンドポイント と クロスリージョンリードレプリカ を導入し、続いて 10 月には AWS Lambda との統合と Amazon S3 からテーブルを直接ロードする機能 を追加しました。2017 年 6 月には、データベースのクローン作成と Amazon S3 へのエクスポート機能を追加し、同年 10 月には PostgreSQL との完全な 互換性 を実現しました。 このジャーニーは、2017 年 11 月の サーバーレス プレビューにつながり、2018 年 8 月には一般提供が開始されました。2018 年 11 月には、クロスリージョンディザスタリカバリのための グローバルデータベース がリリースされました。データベース更新を簡素化する ブルー/グリーンデプロイ と、クエリパフォーマンスを改善する 最適化された読み取りインスタンス を導入しました。 2023 年には、Aurora PostgreSQL 向けに 類似性検索用の pgvector を使用したベクトル機能 と Aurora I/O-Optimized を追加し、大量の I/O が発生するアプリケーションのために、最大 40% のコスト削減と予測可能な料金を実現しました。 Amazon Redshift との Aurora ゼロ ETL 統合の提供もしました。これにより、抽出、変換、ロード (ETL) オペレーションを実行する複雑なデータパイプラインの構築と維持が不要になり、Aurora からのペタバイト規模のトランザクションデータに対して Amazon Redshift を使用してほぼリアルタイムの分析と ML を実行できるようになります。今年は、 Amazon Sagemaker との Aurora MySQL ゼロ ETL 統合も追加しました。これにより、SageMaker のレイクハウスアーキテクチャでデータにほぼリアルタイムでアクセスし、幅広い分析を実行できるようになります。 2024 年には、 Aurora PostgreSQL を Amazon Bedrock ナレッジベースのベクトルストアとして ワンクリックで簡単に選択できるようにし、サーバーレスの水平スケーリング (シャーディング) 機能である Aurora PostgreSQL Limitless Database をリリースしました。 また、お客様のためにスケーリングを簡素化するため、2020 年 9 月には、最大ストレージ容量を 128 TiB に増加し、多くのアプリケーションを単一のインスタンス内で運用できるようにしました。先月には、 最大ストレージ容量を 256 TiB に倍増 することで、スケーリングをさらに簡素化しました。事前のプロビジョニングは不要で、実際のストレージ使用量に基づく従量制料金でご利用いただけます。これにより、より多くのお客様が、複数のインスタンスを管理する複雑さなしに、高いコスト効率を維持しながら、増大するワークロードを実行できるようになります。 最近では、re:Invent 2024 において、 Amazon Aurora DSQL を発表しました。これは 2025 年 5 月に一般提供が開始されました。Aurora DSQL は、分散 SQL データベースにおける当社の最新のイノベーションを体現しており、アクティブ/アクティブの高可用性とマルチリージョンの強力な一貫性を提供します。これは、常時利用可能なアプリケーションに最適な、極めて高速のサーバーレス分散 SQL データベースであり、インフラストラクチャ管理を一切必要とせず、あらゆるワークロードの需要に合わせて容易にスケールできます。 Aurora DSQL は、ストレージとコンピューティングの分離という当社の独自のアーキテクチャ原則に基づいて構築されており、読み取り、書き込み、コンピューティング、ストレージの独立したスケーリングによってさらに強化されています。単一リージョンで 99.99%、マルチリージョンで 99.999% の可用性を提供し、すべてのリージョンレベルのエンドポイントで強力な一貫性を実現します。 また、6 月には、AI エージェントをデータソースやサービスと統合できるように、 Aurora 向けモデルコンテキストプロトコル (MCP) サーバー をリリースしました。 10 年間のイノベーションをお祝いしましょう 8 月 21 日のライブストリームイベント では、 Swami Sivasubramanian 、 Ganapathy (G2) Krishnamoorthy 、 Yan Leshinsky 、 Grant McAlister 、 Raman Mittal など、Aurora の技術リーダーや立ち上げメンバーの話を聞くことができます。クラウドデータベースにおけるコンピューティングとストレージの分離を先駆的に推進したアーキテクトから直接学び、Aurora のアーキテクチャとスケーリング機能に関する技術的なインサイトを得ることができます。Aurora のエンジニアがビジョンを共有し、お客様のために解決に取り組んでいる複雑な課題について議論するため、データベーステクノロジーの未来を垣間見ることもできます。 イベントでは、主要な特徴量の実装方法を示す実践的なデモンストレーションも提供されます。 pgvector を使用した AI 利用のアプリケーション の構築方法、新しい Aurora DSQL 料金モデルによるコスト最適化の理解、グローバルアプリケーションのためにマルチリージョンの強力な一貫性を実現する方法を学ぶことができます。 インタラクティブな形式で、Aurora のエキスパートとの質疑応答の機会も用意されているため、具体的かつ技術的な質問への回答を得ることができます。また、Aurora の新機能をお試しいただくための AWS クレジットも受け取ることができます。 エージェンティック AI にご興味をお持ちの方は、 MCP サーバー 、 Strands Agents 、 Strands Agents と Aurora DSQL の統合方法 に関するセッションが特に役立つでしょう。これらのセッションでは、データベースアクセスに対するコントロールを維持しながら、AI 機能を Aurora データベースに安全に統合する方法をご紹介します。 ミッションクリティカルなワークロードを実行している場合でも、新しいアプリケーションを構築している場合でも、これらのセッションは、最新の Aurora 特徴量の使用方法を理解するのに役立ちます。 今すぐ登録 して席を確保し、データベースイノベーションを祝うこのイベントにぜひご参加ください。 Aurora イノベーションの次の 10 年へ! – seb 原文は こちら です。

並外れた貢献と技術面でのリーダーシップが認められて AWS ヒーローに新しく加わった仲間たちを皆さんにご紹介したいと思います。さまざまな地域と専門技術を代表するこれらの情熱的な仲間たちは、優れた専門知識と AWS コミュニティ内での知識共有への献身を実証しています。AI と機械学習からサーバーレスアーキテクチャとセキュリティまで、私たちの新たなヒーローたちは、インクルーシブで魅力的なテクニカルコミュニティを育成すると同時に、幅広いクラウドイノベーションを体現しています。クラウドコンピューティングの未来の形成を支援し、次世代 AWS ビルダーのインスピレーションとなっているコミュニティリーダーを私たちと一緒に歓迎しましょう。 Kristine Armiyants 氏 – アルメニア、マシス コミュニティヒーローである Kristine Armiyants 氏は、ソフトウェアエンジニアとクラウドサポートエンジニアの両方を務めています。経営学修士を取得してから独学でソフトウェア開発を学んだ Armiyants 氏は、金融関連の経歴をテクノロジーに移行させました。AWS User Group Armenia の創設者であり、2 年半以上にわたってリーダーを務めている Armiyants 氏は、アルメニア初の AWS Community Day を企画し、参加者数を 320 人から 440 人以上に増やして、アルメニアに国際的な規模のイベントを招致するチームを率いることで現地の技術的環境を変革してきました。Armiyants 氏は、新しいユーザーグループの主催者やキャリアの浅いエンジニアを指導しながら、アルメニア語の技術記事、実践的なワークショップ、ありのままを伝えるブログシリーズを通じて、クラウド知識をより簡単に取得できるようにしています。コミュニティ構築に対する Armiyants 氏の献身的な取り組みにより、アルメニアから 5 人の新しい AWS コミュニティビルダーが誕生しました。これは、AWS コミュニティで学び、成長するためのインクルーシブなスペースの創出に対する Armiyants 氏のコミットメントを実証しています。 Nadia Reyhani 氏 – オーストラリア、パース 機械学習ヒーローである Nadia Reyhani 氏は、機械学習システムに DevOps ベストプラクティスを統合する AI Product Engineer です。かつて AWS コミュニティビルダーであった Reyhani 氏は、AWS イベントで、Amazon SageMaker と Bedrock を使用したスケーラブルな AI ソリューションの構築に関するプレゼンテーションを定期的に行っています。Women in Digital Ambassador として技術的な専門知識とアドボカシーを組み合わせる Reyhani 氏は、クラウドや AI テクノロジーにおけるマイノリティグループのためのインクルーシブなスペースを創り出しています。 Raphael Manke 氏 – ドイツ、カールスルーエ DevTools ヒーローである Raphael Manke 氏は、Dash0 で Senior Product Engineer を務めていますが、AWS re:Invent でのスケジュール作成に使用される非公式 AWS re:Invent プランナーの作成者でもあります。10 年間の AWS 経験を持つ Manke 氏は、クラウド開発を合理化するサーバーレステクノロジーと DevTools を専門としています。AWS User Group in Karlsruhe の主催者であり、以前は AWS コミュニティビルダーでもあった Manke 氏は、講演や AWS サービスチームとの直接的なコラボレーションを通じて製品の機能強化に積極的に取り組んでいます。AWS コミュニティに対する Manke 氏のコミットメントは、現地ユーザーグループのリーダーシップからサービスチームへの貴重なフィードバックの提供まで多岐にわたります。 Rowan Udell 氏 – オーストラリア、ブリスベン セキュリティヒーローである Rowan Udell 氏は、AWS Identity and Access Management (IAM) を専門とする独立系 AWS セキュリティコンサルタントです。Udell 氏は、書籍、ブログ記事、ミートアップ、ワークショップ、カンファレンスでのプレゼンテーションを通じて、AWS セキュリティの専門知識を10 年以上にわたって共有してきました。Udell 氏は多数の AWS コミュニティプログラムに参加しており、AWS コミュニティビルダーを 4 年間務め、AWS Community Day Australia 企画委員会のメンバーでもあります。Sydney Summit やその他のコミュニティミートアップを含めた AWS イベントで頻繁に講演を行っている Udell 氏は、AWS 環境をセキュア化する企業のために、複雑なセキュリティ概念をシンプルかつ実用的で運用可能なソリューションに変換することで知られています。 Sangwoon (Chris) Park 氏 – 韓国、ソウル サーバーレスヒーローである Sangwoon (Chris) Park 氏は、AI 駆動の 3D コンテンツ生成を専門とする AI スタートアップ、RECON Labs で開発を先導しています。かつて AWS コミュニティビルダーを務めていた Park 氏は、「AWS Classroom」YouTube チャンネルの作成者でもあり、サーバーレスアーキテクチャに関する実用的な知識を AWS コミュニティと共有しています。Park 氏は、毎月行われる AWS Classroom Meetup と AWS KRUG Serverless Small Group を主催しており、コミュニティイベントや教育コンテンツを通じてサーバーレステクノロジーを積極的に推進しています。 Toshal Khawale 氏 – インド、プネ コミュニティヒーローである Toshal Khawale 氏は、22 年を超えるエンジニアリングと AWS クラウドテクノロジーの専門知識を備えた熟練のテクノロジーリーダーで、クラウド知識を実証する 12 の AWS 認定を取得しています。数多くの大規模な AWS 移行と生成 AI 実装を主導してきた Khawale 氏は、PwC の Managing Director として、クラウドトランスフォーメーション、デジタルイノベーション、アプリケーションモダナイズといったイニチアチブを通じて組織を導いています。AWS コミュニティビルダーを 6 年間務めた後も、AWS User Group Pune のリーダーとしての活動を続けており、コミュニティエンゲージメントと知識共有を積極的に推進しています。Khawale 氏は、メンター、常連講演者、アドボケイトとしての役割を通じて、組織がクラウドテクノロジートレンドの最先端に立ながら AWS への投資を最大限に活かせるように支援しています。 詳細をご覧ください AWS ヒーロープログラムの詳細を知りたい、またはお近くのヒーローとつながりたい場合は、 AWS ヒーローのウェブページ にアクセスしてください。 – Taylor 原文は こちら です。

2025年1月28日に本稿の更新が行われました: 「ユースケース3: インターネットベースのアプリケーションから AWS にデプロイされたサービスへの接続」において、各アベイラビリティーゾーン内で DNS 解決を実行する必要性が明記されました。 2025年7月24日に本稿の更新が行われました: サービスネットワーク VPC エンドポイントの IP アドレスは変更される可能性があるため、インターネット向け Elastic Load Balancer (ELB) のターゲットとしてプロキシが必要であることが明確になりました。 本稿では、Amazon VPC Lattice を活用し、AWS で最新で安全かつ耐障害性の高い企業ネットワークを構築する方法を探ります。VPC Lattice のすべての AWS コンピューティングサービスとの統合、および幅広いアプリケーションとトランスポートプロトコルのサポートを使用して、ネットワーク接続をモダン化する方法についてより深く掘り下げます。また、オンプレミス環境への VPC Lattice 接続の拡張方法についても説明し、クロスリージョンおよびハイブリッドアクセスの要件を満たす方法も紹介します。 Amazon VPC Lattice は、フルマネージド型のアプリケーションネットワーキングサービスで、サービス間通信のニーズに対してネットワーク接続やセキュリティ、モニタリングを簡素化します。VPC Lattice は現在、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Elastic Kubernetes Service (Amazon EKS) 、 AWS Lambda に加えて、 Amazon Elastic Container Service (Amazon ECS) と AWS Fargate の組み込みサポート を提供しています。また、 HTTP や HTTPS 、 gRPC 、 TLS 、TCP などの最も一般的なタイプのサービスとプロトコルを幅広くサポートしています。VPC リソースとサービスネットワーク VPC エンドポイントのサポートにより、VPC Lattice を使用して、AWS およびオンプレミスのサービスに対して一貫性のある安全なネットワーク接続を構成することができます。 VPC Lattice は、ネットワーク接続性に加えて、信頼性の高い認証とコンテキスト固有の認可により、セキュリティ体制の向上を促進します。 AWS Identity and Access Management (AWS IAM) と統合してサービス間の認証と認可を行い、現在 AWS サービスで使用している馴染みのある認証・認可機能を提供します。これにより、豊富なトラフィック制御とエンドツーエンドの可観測性を備えた、多層防御セキュリティ戦略を実装できます。VPC Lattice の認証ポリシーを活用してワークロード間のアクセスを細かく制御し、ゼロトラストセキュリティの実装を加速することができます。 前提条件 Amazon Virtual Private Cloud (Amazon VPC) や AWS Direct Connect 、 AWS Site-to-site VPN 、 Amazon Route 53 、 AWS PrivateLink 、 AWS Cloud WAN などの AWS のネットワーキング構成に精通していることを前提としています。これらのサービスの定義に焦点を当てるのではなく、それらの機能と、ハイライトされたネットワーク接続シナリオで VPC Lattice を補完するために使用する方法について概説します。また、Amazon VPC Lattice の概念にも精通していることを前提としています。Amazon VPC Lattice の追加の背景情報については、以前の記事「 Build secure multi-account multi-VPC connectivity for your applications with Amazon VPC Lattice 」と、 Amazon VPC Lattice 入門ガイド のリソース集を参照することをお勧めします。 ネットワーク接続シナリオ エンタープライズ向けネットワークでは、複数のトラフィックパターンのための接続基盤を提供します。これには、同一 AWS アカウントやリージョン内の VPC 間接続や、複数の AWS アカウントやリージョン間のVPC 間接続、オンプレミス環境とのハイブリッド接続、そして Amazon Relational Database Service (RDS) などの AWS マネージドサービスへの接続が含まれます。 私たちは、 AWS Well-Architected フレームワーク に沿ったベストプラクティスのアプリケーションデプロイメントオプションとして、マルチアカウントおよびマルチ VPC のアーキテクチャパターンがあると考えています。そのため、アーキテクチャ図にはアカウントの境界を示さず、すべてのリソースが複数のアカウントにわたってデプロイされていると想定しています。次に続くセクションでは、以下のアプリケーション通信のユースケースを取り上げながら、Amazon VPC Lattice を使用して企業のネットワーク接続とセキュリティをモダン化および簡素化する方法について詳しく説明します。 ユースケース1 : 単一の AWS リージョン内のアプリケーション間の接続。 ユースケース2 : AWS とオンプレミスのハイブリッド環境に展開されたアプリケーション間の接続。このユースケースでは、2つの一般的なフローで区別しています。 AWS 上のクライアントがオンプレミスにデプロイされたアプリケーションにアクセスする必要がある場合。 オンプレミス上のクライアントが AWS 上のアプリケーションにアクセスする必要がある場合。 ユースケース3 : インターネット上のアプリケーションから、AWS にデプロイされたアプリケーションへの接続。アプリケーションへのユーザーアクセスには焦点を当てません。アプリケーションへのユーザーアクセスを保護する詳細については、 AWS Verified Access を確認することをお勧めします。 ユースケース4 : 複数 AWS リージョン間でのアプリケーション間の接続。この要件は、リージョン間接続に関する2つの一般的なユースケースに由来しています。 複数リージョンに跨るクライアントが、単一のリージョンにデプロイされたアプリケーションにアクセスする必要がある場合。 クライアントが、複数リージョンにデプロイされたアプリケーションにアクセスするために、リージョン間フェイルオーバー機能を必要とする場合。フェイルオーバーは、サービス所有者またはクライアントによって制御できます。 クライアントやサービス、リソースは、HTTP や HTTPS、gRPC、TLS、TCP などの様々なサポートされたプロトコルを使用し、多様な AWS コンピューティングオプション上にデプロイされたアプリケーションの組み合わせであると考えています。 VPC Lattice の機能と新しい能力 VPC Lattice は、AWS での接続性とネットワークセキュリティを簡素化する新機能を発表しました。VPC リソースを VPC Lattice サービスネットワークに関連付けることができるようになり、AWS またはオンプレミスにデプロイされた TCP サービスやリソースへのアクセスを提供できるようになりました。また、サービスネットワーク VPC エンドポイントを使用して、オンプレミスまたはクロスリージョンからサービスネットワークへのアクセスを設定することもできます。 各新機能の詳細については前述の投稿で確認できますが、以下のセクションで概説するシナリオのネットワーク接続を設計するために使用する構成の概要は次のとおりです。 VPC Lattice サービスネットワーク を使用して、共通の接続性とセキュリティ要件を持つアプリケーションをまとめます。サービスネットワークは、VPC やアカウント間の接続性を可能にし、アプリケーション通信パターンに共通のセキュリティポリシーを適用する方法を簡素化する論理的なグルーピングメカニズムです。アカウント内でサービスネットワークを作成し、 AWS Resource Access Manager (AWS RAM) を使用することで、 AWS Organization 内外の他アカウントと共有することができます。様々なユースケースや事業部門、環境 (例：本番や開発、ステージングなど) に対して複数のサービスネットワークを持つことができます。 クライアントは、サービスネットワーク VPC アソシエーションとサービスネットワーク VPC エンドポイントを使用して、サービスネットワーク内のサービスとリソースにアクセスできます。 サービスネットワーク VPC アソシエーション (SN-A) : VPC にデプロイされたクライアントがサービスネットワークにアクセスできるようにします。サービスネットワークアソシエーションでは、関連付けられた VPC の外部からアクセスすることはできません。VPC は 1 つのサービスネットワークアソシエーションのみを持つことができます。 サービスネットワーク VPC エンドポイント (SN-E) : VPC にデプロイされたクライアントがサービスネットワークにアクセスできるようにします。また、VPC への接続性がある場合、VPC 外のクライアントも対応するサービスネットワークエンドポイントにアクセスできます。例えば、クライアントは AWS Cloud WAN や AWS Transit Gateway を通じてピア接続された VPC、あるいは AWS Direct Connect や Site-to-Site VPN を通じてオンプレミスからサービスネットワーク VPC エンドポイントにアクセスできます。サービスネットワーク VPC エンドポイントは VPC の CIDR ブロックから IP アドレスを使用します。各サービスネットワークに対して SN-E を作成することで、VPC 内で複数のサービスネットワークへの接続を設定できます。サービスネットワークエンドポイントの詳細については、 ドキュメント を確認することをお勧めします。 サービスネットワークでは、VPC Lattice サービスと VPC リソースを関連付けることができます。 VPC Lattice サービス : VPC Lattice サービス は、リスナー (プロトコルとポート番号)や、アプリケーションフローを制御するルーティングルール (例：パス、メソッド、ヘッダーベース、重み付けルーティング)、 アプリケーションインフラストラクチャを定義する 1 つ以上のターゲットグループで構成されています。サービスは様々なクライアント機能に対応するために複数のリスナーを持つことができます。サポートされているプロトコルには、HTTP や HTTPS、gRPC、TLS が含まれます。VPC Lattice サービスを作成すると、AWS RAM を使用して AWS Organization 内外のアカウントと共有することができます。複数のサービスをサービスネットワークに関連付けることができ、1 つのサービスを複数のサービスネットワークに関連付けることも可能です。 VPC リソース : リソースは IP アドレス、ドメイン名 (DNS) ターゲット、または Amazon RDS などの Amazon マネージドリソースです。リソースを他の VPC やアカウントで利用可能にするには、 リソースゲートウェイ と リソースコンフィグレーション を定義します。 リソースゲートウェイは、共有リソースにアクセスするために、リソース所有者の VPC へのイングレストラフィックポイントを提供する新しい VPC の構成概念です。VPC 内に 1 つ以上のリソースゲートウェイを持つことができます。 リソースコンフィグレーションは、共有したいリソースまたはリソースのグループを表します。VPC 内の単一のリソースゲートウェイに複数のリソースコンフィグレーションを関連付けることができます。リソースコンフィグレーションを作成したら、それをサービスネットワークに関連付けることができます。また、AWS RAM を使用して、AWS Organization 内外のアカウントとリソースコンフィグレーションを共有することもできます。 VPC Lattice を使用すると、クライアントやサービス、リソースが重複する IP アドレスを持つことができ、また異なる IP バージョン (IPv4とIPv6) をサポートすることができます。これにより、プライベート IPv4 アドレスが重複している、または不足している環境での接続が容易になり、IPv6 の導入を加速させることができます。 ユースケース1: AWS リージョン内のアプリケーション間の接続 最初に取り上げるユースケースは、VPC Lattice を使用して、AWS リージョン内の複数の VPC やアカウントにわたってデプロイされたアプリケーション間で安全な接続を提供する方法です。アプリケーションは、Amazon EC2 インスタンスや AWS Lambda 関数、Amazon ECS、Amazon EKS、AWS Fargate クラスターなど、さまざまなコンピューティングプラットフォームにわたってデプロイでき、幅広い通信プロトコルをサポートできます。図1は、AWS リージョン内のアプリケーションネットワーキングに関する高レベルアーキテクチャ図を示しています。 図1. AWS リージョン内のアプリケーションネットワーキングの高レベルアーキテクチャ AWS リージョン内でエンタープライズ向けのネットワーク接続アーキテクチャを簡素化およびモダン化するには、次の手順を実行できます。 セグメンテーションモデルに応じて、1 つ以上の VPC Lattice サービスネットワークを作成します。 アプリケーション要件に基づき、VPC Lattice サービスと VPC リソースを作成します。 VPC、サービス、リソースをそれぞれのサービスネットワークに関連付けます オプションとして、サービスネットワークとサービスに認証および認可ポリシーを設定し、アプリケーション間の通信を細かく制御します。 クライアント固有のサービスネットワークやサービス固有のサービスネットワークを作成できます。例えば、事業部門 (BU) ごとにクライアントをグループ化し、BU ごとにサービスネットワークを構成することができます。あるいは、共有サービスなどの機能別にサービスをグループ化し、専用のサービスネットワークに関連付けることもできます。アプリケーションチームは VPC Lattice サービスとリソースを作成し、サービスネットワークを所有するアカウントと共有することができます。特定のアクセス要件を満たすために、サービスとリソースを複数のサービスネットワークに関連付けることができます。セグメンテーションや運用モデルに関わらず、タグを使用して VPCやサービス、リソースをサービスネットワークに自動的に関連付けることができます。自動化のベストプラクティスの詳細については、「 Automating large scale deployments with tags for Amazon VPC Lattice 」を参照することをお勧めします。 サービスディスカバリを容易にするため、VPC Lattice はサービスとリソースのカスタムドメイン名をサポートし、定義した各 VPC Lattice サービスとリソースに対して完全修飾ドメイン名 (FQDN) を維持します。これらの FQDN を Route 53 のプライベートホストゾーン設定で活用し、クライアントがサービスとリソースを発見してアクセスできるようにすることができます。「 複数の VPC と AWS アカウントで Amazon Route 53 プロファイルを使用して DNS 管理を統合する 」を確認することをお勧めします。 図2は一般的なエンタープライズ向けアーキテクチャの例を示しています。本番環境、開発環境、共有サービス環境に特化した3つのサービスネットワークを作成し、それぞれ Prod、Dev、Shared services と名付けています。以下のように関連付けを行いました。 本番環境の VPC やサービス、リソースを Prod サービスネットワークに接続します。 開発環境の VPC やサービス、VPC リソースを Dev サービスネットワークに接続します。 共有サービスと共有 VPC リソース、およびそれらの VPC を Shared Services サービスネットワークに接続します。 共有サービスと共有 VPC リソースを Prod と Dev の両方のサービスネットワークに接続します。これは、本番アプリケーションと開発アプリケーションの両方からアクセスする必要があるためです。 図2. AWS リージョンにおける本番環境、開発環境、共有サービスのアプリケーションネットワークを含む一般的なエンタープライズ向けアーキテクチャ ユースケース2: AWS とオンプレミスにデプロイされたハイブリッド環境で展開されたサービス間の接続 ハイブリッド接続のユースケースでは、クライアントとアプリケーションを AWS とオンプレミスの両方にデプロイできます。以下の2つの一般的なアクセスパターンに対応します。 AWS にデプロイされたクライアントがオンプレミスにデプロイされたアプリケーションにアクセスする必要がある場合 オンプレミスにデプロイされたクライアントが AWS にデプロイされたアプリケーションにアクセスする必要がある場合 両方のユースケースの要件を満たすために、VPC Lattice サービスネットワーク VPC エンドポイント (AWS PrivateLink によって提供) と VPC リソースをどのように活用できるか見ていきましょう。 1. オンプレミスから AWS にデプロイされたアプリケーションへのアクセス : オンプレミス (または AWS 外) にデプロイされたクライアントの場合、AWS Direct Connect または Site-to-Site VPN を使用してオンプレミスからアクセス可能なエントリーポイント用 VPC を作成できます。この VPC 内で、サービスネットワーク VPC エンドポイントを作成し、オンプレミスのクライアントが関連する VPC Lattice サービスとリソースにアクセスできるようにすることができます。また、サービスネットワークエンドポイントのセキュリティグループを使用して、オンプレミスからのトラフィックをフィルタリングすることもできます。ハイブリッド接続には、AWS Direct Connect または AWS Site-to-Site VPN を使用できます。図 3 は、Amazon VPC Lattice サービスネットワーク VPC エンドポイントの高レベルアーキテクチャ図を示しています。 図3. オンプレミスから Amazon VPC Lattice サービスネットワーク VPC エンドポイントへのアクセス 図 4 は一般的なエンタープライズ向けアーキテクチャの例を示しています。リージョン内のすべてのサービスネットワークへのオンプレミスからのアクセスを可能にするために、「Hybrid ingress VPC」を使用しています。各サービスネットワーク (Prod や Dev、Shared Services) に対してサービスネットワークエンドポイントを構成しています。Hybrid ingress VPC へのオンプレミス接続には AWS Direct Connect を使用しました。 図4. オンプレミスから Prod や Dev、Shared Services サービスネットワークへのアクセスのためのサービスネットワークエンドポイントを持つ Hybrid ingress VPC 2. AWS からオンプレミスにデプロイされたアプリケーションへのアクセス : オンプレミス (または AWS 外) にデプロイされたアプリケーションの場合、AWS Direct Connect または Site-to-Site VPN によりオンプレミスへの接続性を持つ出口ポイント用 VPC を作成できます。この VPC でリソースゲートウェイを作成し、オンプレミスアプリケーション用のリソースコンフィグレーションを定義できます。DNS または IP アドレスでリソースを識別し、リソースコンフィグレーションをサービスネットワークに関連付けることができます。 ロードバランシングを必要とするオンプレミスアプリケーションの場合、AWS 上の egress VPC で Network Load Balancer (NLB) を使用できます。サービスネットワークからオンプレミスサービスを表す NLB へのアクセスを設定するために、各 NLB の DNS FQDN を含むリソースコンフィグレーションを定義できます。各リソースコンフィグレーションを 1 つ以上のサービスネットワークに関連付け、オンプレミスのロードバランスされたサービスへのアクセスを提供できます。図 5 は、オンプレミスアプリケーションのリソースコンフィグレーションに関する高レベルアーキテクチャ図を示しています。 図5. オンプレミスから Prod や Dev、Shared Services のサービスネットワークへのアクセスのためのサービスネットワークエンドポイントを持つ Hybrid ingress VPC 図 6 は一般的なエンタープライズ向けアーキテクチャの例を示しています。AWS Direct Connect を通じてオンプレミスのサービスとリソースにアクセスできる「Hybrid egress VPC」を使用しています。リソースゲートウェイを構成し、ロードバランシングを必要としないオンプレミスリソースを表す IP または DNS ベースのリソースコンフィグレーションを定義しました。ロードバランシングを必要とするオンプレミスアプリケーションは、Network Load Balancers (NLBs)を構成し、各 FQDN をリソースコンフィグレーションに追加しました。すべてのリソースコンフィグレーションを 3 つのサービスネットワーク (Prod や Dev、Shared Services) すべてに関連付けることを選択しました。一方で、リソースコンフィグレーションをサービスネットワークのサブセットに関連付けたり、オンプレミスにデプロイされたアプリケーション専用のサービスネットワークを作成したりすることもできます。 図6. オンプレミスアプリケーション用のリソースゲートウェイおよびリソースコンフィグレーションを備えた Hybrid egress VPC ユースケース3: インターネットベースのアプリケーションから AWS にデプロイされたサービスへの接続 インターネットからの通信ニーズに対応するため、インターネット上のアプリケーションが AWS にデプロイされたアプリケーションにアクセスする必要があります。この使用例は一般的に、AWS にデプロイされたアプリケーションのフロントエンドとして、パブリック向けロードバランサーを構成することで対処されます。このシナリオでは、VPC Lattice にて、パブリック向けロードバランサーからバックエンドターゲットへの安全な接続を提供する方法を探ります。実現するために、パブリック向けロードバランサーをデプロイするイングレスポイント用 VPC を作成し、サービスネットワーク VPC エンドポイントをロードバランサーのターゲットとして使用できます。Application Load Balancer を使用する場合、ターゲットは HTTP である必要があります。図7は、インターネットから VPC Lattice へのイングレスに関する高レベルアーキテクチャ図を示しています。 図7. VPC Lattice を介したインターネットイングレスアクセス サービスネットワーク VPC エンドポイントの IP アドレスは変更される可能性があるため、インターネット向けロードバランサーのバックエンドターゲットとしてプロキシを使用することをお勧めします。DNS ルックアップを行うプロキシは、常に最新のサービスネットワーク VPC エンドポイント の IP アドレスを取得することを保証します。VPC Lattice のインターネットイングレスのユースケースでプロキシを使用する方法の詳細については、 こちらのガイダンス をご覧ください。 図 8 は一般的なエンタープライズ向けのアーキテクチャ例を示しています。インターネットイングレス用 VPCと、インターネットクライアントからのアクセスを必要とする VPC Lattice サービスとリソース向けの VPC Lattice サービスネットワークを構成しました。Application Load Balancer と Network Load Balancers の両方を使用し、サービスネットワークの IP アドレスをターゲットとしています。また、セキュリティと運用モデルに基づき、サービスネットワークに直接インターネット接続を提供することも選択できます。サービスネットワーク内のサービスに関連付けられた IP アドレスを取得するには、各アベイラビリティゾーンでサービスネットワークエンドポイントに対してDNS 解決を実行する必要があります。これらの IP アドレスは変更される可能性があるため、定期的に DNS チェックを行うことをお勧めします。 図8. インターネット向けアプリケーションが、VPC Lattice を介し、Application Load Balancer または Network Load Balancer とサービスネットワークエンドポイントを利用し、Prod や Dev、Shared Services サービスアプリケーションにアクセス ユースケース4: 複数 AWS リージョンにわたるアプリケーション間の接続 マルチリージョンでアプリケーションを実行する用途に関わらず、クライアントがサービスやリソースに安全にアクセスでき、かつ回復力と可用性に影響を与えないことを確保することが基本的な要件です。ここでは、アプリケーションへの 2 つの一般的なリージョン間アクセスパターンについて説明します。 複数のリージョンにまたがるクライアントが、特定のリージョンにデプロイされたサービスにアクセスする必要がある場合 クライアントが、複数の AWS リージョンにデプロイされた重要なサービスにアクセスし、リージョン間のフェイルオーバー機能を必要としている場合 両方のアクセスパターンの要件を満たすために、VPC Lattice をどのように使用できるか復習しましょう。 1. 複数のリージョンにまたがるクライアントが、特定のリージョンにデプロイされたサービスにアクセスする必要がある場合 : このユースケースでは、サービスネットワーク VPC エンドポイントと、VPC ピアリングまたは AWS Cloud WAN を使用したクロスリージョン IP の接続性を活用できます。あるいは、VPC Lattice とクロスリージョン接続を可能にするインターフェイス VPC エンドポイント (AWS PrivateLink によって提供) を併用して、クライアントからサービスの場所や IP アドレッシング、フェイルオーバーの決定を抽象化することもできます。ここでは、2 番目のオプションに焦点を当てます。これを実現するには以下の手順を行います。 クロスリージョンのクライアントアクセスが必要なサービスに対して、クロスリージョンの PrivateLink インターフェース VPC エンドポイントを作成します。これにより、リージョン間通信の依存関係をより適切に追跡および管理し、それらが回復力と可用性に影響を与えないようにすることができます。 クロスリージョンの PrivateLink インターフェース VPC エンドポイントを VPC リソースとして VPC Lattice サービスネットワークに組み込みます。各クロスリージョンエンドポイントはサービスを表します。PrivateLink が管理する FQDN を使用して各エンドポイントの VPC リソースを定義し、Route 53 プライベートホストゾーンとプロファイルを使用してカスタム DNS を管理できます。 図 9 は高レベルのアーキテクチャ例を示しています。 図9. VPC Lattice サービスネットワーク VPC エンドポイントと AWS PrivateLink を使用したクロスリージョンサービスアクセス リモートリージョンのサービスネットワークにアクセスするために、サービスネットワーク VPC エンドポイントを設定し、Network Load Balancer をフロントエンドに配置します。その後、リモートリージョンに PrivateLink エンドポイントサービスと、PrivateLink エンドポイントを作成します。クロスリージョン VPC エンドポイントをサービスネットワークに取り込むには、リソースコンフィグレーションまたは VPC Lattice サービスを定義できます。AWS PrivateLink と Amazon VPC Lattice はどちらもクライアントとサービスの IP アドレスと IP バージョンを抽象化するため、すべての VPC で重複する IP スペースを使用できます。 2. 重要なサービスにアクセスし、クライアントがリージョン間のフェイルオーバー機能を必要とする場合 : 複数のリージョンにわたってデプロイされたサービスの場合の、リージョン間接続の一般的なユースケースは、フェイルオーバー状況下でリモートリージョンでクライアントトラフィックを受信できることです。VPC Lattice を使用することで、サービス所有者は以下のことが可能になります。 2つのターゲットグループを持つ VPC Lattice サービスを構成します。1つのターゲットグループはローカルリージョンのアプリケーションを表し、2つ目のターゲットグループには、リモートリージョンのサービスネットワークへのクロスリージョン接続のための AWS PrivateLink IP アドレスが含まれます。 サービスを別のリージョンにフェイルオーバーする必要がある場合、サービス所有者はターゲットグループの重みを変更できます。これにより、クライアントトラフィックをクライアントから VPC Lattice を通じて、クロスリージョンの PrivateLink エンドポイントに流すことが可能になります。 図 10 は高レベルのアーキテクチャ例を示しています。このシナリオでは、フェイルオーバーはサービス所有者によって制御されます。 図10. クロスリージョンのアクティブ-パッシブサービスアクセス構成 このオプションにより、複数リージョン間での直接的な IPv4 および IPv6 接続を設定する必要がなくなり、リージョン間の依存関係を細かく制御できるようになります。VPC Lattice は、サービスへのアクセスパターンの完全な可視性を提供し、モニタリングやサービス依存関係のマッピング作業、およびフェイルオーバー制御の簡素化を支援します。 まとめ 本稿では、Amazon VPC Lattice を活用して、モダンで安全かつ、回復力のあるエンタープライズネットワークを構築する方法を探りました。すべての AWS コンピューティングサービスとの VPC Lattice 統合、および幅広いアプリケーションおよびトランスポートプロトコルのサポートを使用して、ネットワーク接続をモダン化する方法を検討しました。また、リージョン間およびハイブリッドサービスアクセスの要件を満たすために、VPC Lattice の接続をオンプレミス環境に拡張する方法も検討しました。Amazon VPC Lattice の詳細については、 ドキュメント および Amazon VPC Lattice 入門ガイド を参照できます。 本稿は、2024年12月2日に Networking & Content Delivery で公開された “ Amazon VPC Lattice: modernize and simplify your enterprise network architectures ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

本記事は、2025 年 6 月 19 日に公開された Streamline Operational Troubleshooting with Amazon Q Developer CLI を翻訳したものです。 Amazon Q Developer は、開発者が複雑なワークフローを実行するのを支援する、最も高機能な生成 AI を活用した開発アシスタントです。Amazon Q Developer の コマンドラインインターフェイス (CLI) は、対話型 AI と AWS サービスへの直接アクセスを組み合わせることで、アプリケーションの理解、構築、運用をより効果的に行うことができます。 Amazon Q Developer CLI は、コマンドを実行して出力を分析し、ローカルマシン上で利用可能なトラブルシューティングツールとプラットフォームのベストプラクティスに基づいて、コンテキストに応じた推奨事項を提供します。 今日のクラウドネイティブ環境では、本番環境の問題のトラブルシューティングは、複数のターミナルウィンドウを切り替えたり、大量のログファイルを解析したり、数多くの AWS コンソールページを行き来したりする必要があります。このような絶え間ないコンテキストの切り替えは、問題解決を遅らせ、クラウドインフラストラクチャを管理するチームに認知負荷を加えることになります。 このブログ記事では、Amazon Q Developer CLI が対話形式のインタラクションを通じて困難なシナリオを効率化し、トラブルシューティング体験を変革する方法について見ていきます。 従来のトラブルシューティング体験 問題が発生すると、エンジニアは通常、インフラストラクチャの構成や複数のサービスにわたるログを手動で確認し、エラーパターンの分析に何時間も費やします。このプロセスでは、複数のインターフェース間の切り替え、さまざまなソースからの情報の相関付け、AWS に関する深い知識が必要です。この複雑なワークフローにより、問題解決に数時間から数日を要し、インフラストラクチャチームの負担が増加することがよくあります。 ソリューション: Amazon Q Developer CLI Amazon Q Developer CLI は、初期調査から問題解決までのトラブルシューティングプロセス全体を効率化し、シンプルな対話を通じて AWS の複雑なトラブルシューティングを取り組みやすく効率的なものにします。 Amazon Q Developer CLI の仕組み: 自然言語インターフェース: 対話形式のプロンプトを使用して AWS CLI コマンドを実行し、AWS サービスと対話します 自動検出: インフラストラクチャのマッピングと構成の分析を行います 高度なログ分析: 複数のサービスにわたるログの解析、相関付け、分析を行います 根本原因の特定: AI を活用した推論により問題を特定します ガイド付き修復: 最小限の手作業で修正を実施します 検証: ソリューションをテストし、複雑な問題をわかりやすく説明します 図 1 に示すように、Amazon Q Developer CLI の 組み込みツール の 1 つである use_aws は、AWS サービスと自然言語で対話することを可能にします。このツールは、ローカルマシンで設定された AWS CLI のアクセス許可を活用し、AWS リソースへの安全で承認されたアクセスを提供します。 図 1: Amazon Q Developer CLI のツール一覧 実際のトラブルシューティングシナリオ デモ環境のセットアップ このデモは、以下の環境構成で実施されました。 アプリケーションとインフラストラクチャのコードがローカルで利用可能 Amazon Q Developer CLI がインストール済み AWS CLI に demo-profile が設定済み 次の AWS 権限が設定済み: Amazon Elastic Container Service (ECS) 、 Amazon CloudWatch Logs 、 Application Load Balancer (ALB) および AWS Cloud Development Kit (CDK) のデプロイ プロジェクトディレクトリ内で Amazon Q Developer CLI を起動済み この環境には、必要なツールがインストールされたローカル開発マシン、適切な AWS アカウントの権限、およびターミナルアクセスが含まれています。プロジェクトディレクトリで Amazon Q Developer CLI を起動すると、関連するコードと設定ファイルにすぐにアクセスできます。 シナリオ: NGINX の 5xx エラーのトラブルシューティング このシナリオでは、図 2 の Amazon ECS Fargate にデプロイされた多層アプリケーションアーキテクチャのトラブルシューティングを示します。 Application Load Balancer (ALB) がアベイラビリティーゾーン間でトラフィックを分散 NGINX リバースプロキシサービス が受信リクエストを処理 Node.js バックエンドサービス がビジネスロジックを処理 Service Discovery が内部通信を実現 CloudWatch Logs が統合ログ管理を提供 図 2: このブログ記事で使用するアプリケーションの AWS アーキテクチャ図 従来のトラブルシューティング手順 図 2 のアーキテクチャにおいて、502 Gateway Timeout エラーが発生した場合、従来のトラブルシューティングでは以下が必要です。 ALB ターゲットグループのヘルスステータスのチェック 複数のコンソールで ECS サービスステータスの確認 異なるロググループの CloudWatch ログの分析 サービス間のエラーパターンの相関分析 インフラストラクチャコードの設定不具合のレビュー 修正の実装とデプロイ Amazon Q Developer CLI アプローチ ここでは、Amazon Q Developer CLI が体系的に処理する方法を、順を追って見てみましょう。 ステップ 1: 最初の問題報告 図 3 のスクリーンショットに示すように、アプリケーションのプロジェクトディレクトリ内で、Amazon Q Developer CLI に問題の説明として最初のプロンプトが与えられます。Amazon Q Developer が応答して、NGINX アプリケーションの 502 Gateway Timeout エラーを調査すると回答しています。 プロンプト: Our production NGINX application is experiencing 502 Gateway Timeout errors. I have checked out the application and infrastructure code locally and the AWS CLI profile 'demo-profile' is configured with access to the AWS account where the infrastructure and application is deployed to. Can you help investigate and diagnose the issue? ※訳者注: 本番環境の NGINX アプリケーションで 502 Gateway Timeout エラーが発生しています。アプリケーションとインフラストラクチャのコードをローカルに取得しており、AWS CLI プロファイル ‘demo-profile’ にはインフラストラクチャとアプリケーションがデプロイされている AWS アカウントへのアクセス権限が設定されています。この問題の調査と診断を手伝ってもらえますか？ 図 3: 問題の説明を入力した Amazon Q Developer CLI の画面 ステップ 2: 体系的なインフラストラクチャの検出 図 4 のスクリーンショットに示すように、Amazon Q Developer CLI が体系的にインフラストラクチャの検出を開始しました。最初のプロンプトにはアプリケーションが ECS でホストされているという情報は含まれていませんでしたが、Amazon Q Developer CLI はコンテキストを理解し、クラスターとその中のサービスを調べるために AWS CLI を実行します。クラスター内の両方のサービスで ECS タスクが実行されていることを確認しました。両方のサービスが正常なステータス (1/1 の希望数) を示していることから、サービスの可用性には問題がないことが判明します。 図 4: Amazon Q Developer CLI による AWS インフラストラクチャの検出 ステップ 3: 高度なログ分析 Amazon Q Developer CLI は NGINX コンテナから直近の CloudWatch ログを取得して分析し、図 5 のスクリーンショットに示すように、重要なエラーパターンを即座に特定します。Amazon Q Developer は「完璧です！問題が見つかりました。NGINX のログには、アップストリームのタイムアウトメッセージによる 504 gateway timeout が明確に示されています」と応答します。 図 5: Amazon Q Developer CLI による CloudWatch ログの分析 ステップ 4: Amazon Q Developer CLI による分析と根本原因の特定 Amazon Q Developer はバックエンドサービスのログを調査し、図 6 のスクリーンショットに示すように、バックエンドサービスのレスポンス時間と NGINX のタイムアウト設定の不一致を発見しました。 図 6: Amazon Q Developer CLI による根本原因の特定 ステップ 5: Amazon Q Developer CLI の根本原因分析 図 7 のスクリーンショットに示すように、Amazon Q Developer CLI は ECS タスク定義を調べて、設定の不一致を正確に特定します。Amazon Q Developer は以下のことを発見しました。 バックエンドサービスは response_delay=15000 (15 秒) で設定されています NGINX プロキシは proxy_read_timeout 10 秒で設定されています この不一致により、バックエンドのレスポンスが NGINX のタイムアウトしきい値を超えた場合に、504 gateway timeout エラーが発生します。 図 7: Amazon Q Developer CLI による根本原因分析と問題検出 ステップ 6: コードの自動修正 ここで Amazon Q Developer CLI の真価が発揮されます。問題の診断だけでなく、修正も実装してくれます。Amazon Q Developer CLI は ECS タスク定義の CDK コードが定義されているプロジェクト内で起動されているため、図 8 のスクリーンショットに示すように、コードの設定を特定し、修正しました。 図 8: Amazon Q Developer CLI による CDK コードの修正 ステップ 7: デプロイ 図 9 のスクリーンショットに示すように、Amazon Q Developer CLI は、最初のプロンプトで提供された ‘ demo-profile ‘ AWS CLI プロファイルを使用して、 cdk synth と cdk deploy を実行し、修正をビルドしてデプロイします。 図 9: Amazon Q Developer CLI による CDK コードのビルドとデプロイ ステップ 8: 検証 図 10 のスクリーンショットに示すように、Amazon Q Developer CLI は、デプロイが成功した後、ALB エンドポイントに curl リクエストを送信してソリューションを検証します。 図 10: Amazon Q Developer CLI による修正の検証 さらに Amazon Q Developer は、図 11 のスクリーンショットに示すように、修正がデプロイされた後にヘルスチェックエンドポイントにリクエストを送信し、すべてが正常に動作していることを検証します。 図 11: Amazon Q Developer CLI によるヘルスチェックエンドポイントの検証 Amazon Q Developer CLI が成し遂げたこと 対話形式の指示だけで、Amazon Q Developer CLI は完全なトラブルシューティングサイクルを実行しました。 インフラストラクチャの検出: ECS クラスター、サービス、依存関係を自動的にマッピング ログの相関分析: 複数のサービスにわたる多数のログエントリを分析 根本原因分析: NGINX のタイムアウト (10 秒) とバックエンドの応答遅延 (15 秒) における設定の不一致を特定 コードレベルでの診断: CDK インフラストラクチャコード内の問題のあるタイムアウト設定を発見 自動実装: NGINX のタイムアウト値を増やすためにインフラストラクチャコードを修正 エンドツーエンドのデプロイ: 完全なソリューションの構築、デプロイ、検証を実施 包括的なテスト: 修正の有効性とシステム全体の正常性を検証 Amazon Q Developer CLI は、単一の対話型インターフェイスでトラブルシューティングタスクを処理し、複数のツールや AWS CLI コマンドを使用する必要性をなくします。 まとめ Amazon Q Developer CLI は、クラウドインフラストラクチャの問題をトラブルシューティングする方法の大きな進化を示しています。自然言語理解と強力なコマンド実行機能を組み合わせることで、複雑なトラブルシューティングのワークフローを効率的で実践的な対話に変換します。NGINX の 5xx エラーや他の AWS サービスで発生する同様の問題に対処する場合でも、Amazon Q Developer CLI は、自然で直感的な対話型インターフェイスを通じて、問題の診断、修正の実装、解決策の検証を支援します。 次回トラブルシューティングの課題に直面した際は、Amazon Q Developer CLI を試してみてください。運用ワークフローにどのような変化をもたらすか、ぜひ体験してください。 Amazon Q Developer の機能と料金の詳細については、 Amazon Q Developer の製品ページ をご覧ください。 翻訳はパートナーソリューションアーキテクトの田根が担当しました。 著者について Kirankumar Chandrashekar は AWS の生成 AI スペシャリストソリューションアーキテクトで、Amazon Q Developer に注力しています。AWS クラウドサービス、DevOps、モダナイゼーション、Infrastructure as Code に関する深い専門知識を活かし、AI を活用した革新的なソリューションを通じて、お客様の開発サイクルの加速と開発者の生産性向上を支援しています。Amazon Q Developer を活用することで、チームがより迅速にアプリケーションを構築し、定型タスクを自動化して、開発ワークフローを効率化できるようにしています。 Kirankumar は、複雑なお客様の課題を解決しながら開発者の効率性向上に尽力しており、音楽、料理、旅行を趣味としています。

本記事は、2025 年 8 月 6 日に公開された Improve email deliverability with tenant management in Amazon SES を翻訳したものです。翻訳は Solutions Architect の 松岡勝也 が担当しました。 Amazon Simple Email Service (Amazon SES) は、E コマースサービスから金融機関、マーケティングテクノロジー製品プロバイダーまで、さまざまな業界で組織のメールコミュニケーションニーズの管理を支援しています。多くの企業は、自社のメール送信だけでなく、エンドユーザーに代わって、あるいは様々な事業部門にわたってメールを送信する課題に直面しています。このような マルチテナントメール送信プラクティス として知られるシナリオには、慎重なアーキテクチャの検討が必要です。例えば、マーケティングサービスが数百の小売クライアントのプロモーションメールを送信する必要がある場合や、企業の IT チームが複数の事業部門 (BU) 全体のメールコミュニケーションを管理する場合などが該当します。これらのクライアントや BU はテナントとしても識別されます。 Amazon SES でマルチテナンシーを正常に実装するために、顧客は通常、Amazon SES 内でアーキテクチャパターンを開発し、各テナントのメール送信評価を分離しながら、数千のエンドユーザーのメール送信ニーズを効率的に処理するという重要な目標を達成します。この分離は、各顧客のメール配信性能のメトリクスを保護し、あるテナントの問題が他のテナントに影響を与えることを防ぐために重要です。Amazon SES のお客様は、メール送信用の分離された設定セットを通じてマルチテナンシーを実現できますが、従来、評価管理と適用はアカウントレベルで行われていました。これに対応するため、Amazon SES は個々のテナントレベルでのテナント分離と評価管理を可能にするテナント管理機能を提供するようになりました。この新機能により、単一の Amazon SES アカウント内で複数のテナントを管理する組織は、より優れた制御と柔軟性を得られ、各テナントは独自の送信評価を個別に維持できるようになります。 この記事では、 新しくリリースされたテナント管理 機能について説明します。この機能により、個々のテナントのオンボーディングと評価を分離して管理できるようになります。この機能を使用すると、1 つの AWS アカウント内で最大 10,000 個の分離されたテナントを作成・管理できます (明示的なリクエストにより 300,000 個まで増やすことが可能)。各テナントは独立した設定と評価メトリクスを持つことができます。自動化されたテナントレベルの制御、リアルタイムモニタリング、カスタマイズ可能な送信ポリシーを通じて、これらの機能がメール配信品質をどのように維持するかについて説明します。 複数の顧客に代わってメールを送信するサービスプロバイダーであっても、複数の BU や LOB (Line of Business) を統括する企業であっても、この新機能は評価ベースの検出結果を特定し、他のテナントの評価を保護するために個々のテナントの送信を一時停止する高度なワークフローを提供します。これらの機能強化は、 Amazon SES が提供されている AWS リージョン でグローバルに利用可能で、大規模なメール配信管理における大きな進歩を表しています。 ユースケース Amazon SES のテナント管理機能を使用することで、以下のユースケースを簡単に実現できます。 異なるドメインを持つ複数の BU からの複数ブランドの導入 マーケティングとトランザクションのテナントの分離 ISV (独立系ソフトウェアベンダー) の顧客が求める、顧客ごとのメール送信の評価をサポート 設定セットを使用したドメイン管理 個々の顧客のメール送信の評価の追跡とメール送信プロセスの制御 マルチテナントメール運用の課題 メールはビジネスにとって重要なコミュニケーションチャネルです。しかし、複数のテナント (顧客や BU) に対するメール運用の管理には、これまで以下のような大きな課題がありました： 分離の不足: 適切なテナント分離がないと、1 つのテナントの不適切な送信方法が他のテナントのメール配信性能とメール評価に悪影響を及ぼし、メール送信運用全体を危険にさらす可能性がある。 可視性の制限: テナントごとのメールパフォーマンスメトリクスの理解や送信評価の独立した管理が、不可能ではないにしても困難である。 スケーラビリティの制約: 多くの組織が、ID や設定セットなどのリソースに対するアカウントレベルの制限により、メール運用のスケーリングに苦労している。 不十分な制御: テナント固有の制限や設定を行うことができないため、個々のテナントが他のテナントに影響を与えたり、割り当てられたリソースを超過したりすることを防ぐのが困難である。 複雑なモニタリング: テナントのアクティビティを監視するためのカスタムソリューションの構築は、一貫性のない非効率なワークフローにつながることが多くある。 テナント管理機能のメリット Amazon SES のテナント管理機能は、顧客や LOB ( テナント と呼ばれます) に代わって大規模なメール送信を管理する組織向けの包括的なソリューションを提供します。この機能は、Software as a Service (SaaS) プロバイダー、メールサービスプロバイダー、そして複数のクライアントや部門間でメール運用管理を行う企業にとって特に有用で、テナントごとに分離して管理することができます。 テナント管理により、組織はメールの送信フローと評価を独立して効果的に管理し、さまざまなメール運用を監視できます。この新機能により、組織による Amazon SES の使用方法が改善され、以下の主要な機能によってテナントレベルでより優れた制御と可視性を持って、複雑で多面的なメール運用を処理できるようになります。 テナントリソースと評価の分離: テナント管理により、異なる顧客やビジネスラインにわたってメールの評価を保護する、専用のリソース分離が提供されます。各テナント（顧客または LOB ）は、メールボックスプロバイダーが Amazon SES アカウント内で監視する、メール送信用 IP、ドメイン、DomainKeys Identified Mail (DKIM) 署名ヘッダー内の識別子など、独自の専用リソースセットを持ちます。テナント管理により、リソース割り当ての詳細な制御が可能になります。組織の要件に基づいて、テナント固有または共有の送信 ID を割り当てることができます。各テナントは、割り当てられたリソースへの安全なアクセスを提供する、専用の SMTP または API 認証情報を受け取ることができます。送信トラフィックを分離し、各テナントの個別の評価プロファイルを維持するテナントレベルの IP プールを設定できます。テナント管理を使用して、各テナントのメールの処理と追跡方法を定義するテナント固有の設定セットを管理できます。メールテンプレートを特定のテナントに関連付けることができ、ブランド化されたコミュニケーションが適切に分離され制御されることを確認できます。この分離により、1 つのテナントの行動が他のテナントの評価やパフォーマンスに影響を与えないようにします。テナントが配信の問題や評価の問題に遭遇した場合、これらの課題は専用リソース内に限定されます。このアプローチにより、すべてのテナント間の公平性が維持され、メール運用に対する明確な個別の責任所在が確立されます。 テナント固有のメトリクスをリアルタイムでモニタリング : 送信者の評価に直接影響を与える未加工のバウンス率や苦情率など、各テナントの具体的な評価メトリクスにアクセスできます。このシステムを使用して、詳細な追跡と分析のために、テナントにマッピングされた各設定セットを通じてテナントレベルのイベントの送信先を設定できます。これにより、各テナントの パフォーマンスを追跡 し、利用状況とコンプライアンスのメトリクスを個別に把握できる詳細なテナントレベルのイベントにアクセスできます。また、ビジネス要件に合わせて設定可能な閾値に基づいて、自動的な強制ポリシーを確立できます。テナントの評価に関する検出事項が検出された場合や、テナントのステータスが変更された場合、 Amazon EventBridge を通じてリアルタイムのアラートを受け取ることができます。 数十万のテナントまでスケール : このシステムは大規模なスケーリングに対応するように設計されており（アカウントあたり 1 万テナントから開始し、最大 30 万テナントまで増やすことが可能）、インフラストラクチャの制限を気にすることなく、ビジネスを成長させたりメール運用を拡大したりできます。数十から数十万のテナントを管理する場合でも、システムはニーズに適応します。 テナント管理ワークフローの自動化 : 新しいテナントのオンボーディング、ポリシーの適用、テナントのライフサイクル管理のための自動化プロセスを設定できます。このシステムでは、API とコンソールインターフェイスを使用してテナントの作成、変更、削除を行い、必要に応じて送信機能の一時停止や再開を柔軟に行うことができます。この自動化により、すべてのテナントに対して一貫したメール送信基準を適用する際の手動作業を削減できます。 高い配信性能を維持するための対象を絞った強制アクション : 特定のテナントに問題が発生した場合、他のテナントに影響を与えることなく、送信権限の一時停止やより厳格な評価ポリシーの適用など、正確なアクションを取ることができます。この機能により、運用全体の高い配信性能を維持することができます。 これらの機能は、総合的にメール管理機能の進歩を示しており、組織は評価とコンプライアンスを厳格に管理しながら、より高度で、スケーラブルで、信頼性の高いメールサービスをクライアントや社内部門に提供できます。 テナント管理の仕組み Amazon SES のテナント管理機能を使用して、メール送信業務を効果的にセグメント化できます。このシステムを使用すると、1 つの Amazon SES アカウント内に複数のテナントを作成でき、各テナントは独自の専用リソースを持つことができます。これらのリソースには、送信 ID、SMTP 認証情報、設定セット、専用 IP プールなどの重要なコンポーネントが含まれます。このアーキテクチャが特に柔軟なのは、IP プールや設定セットなどの共通リソースをテナント間で共有できることで、運用上の分離を維持しながら最適なリソース利用が可能になります。次の図は、上記の情報を詳しく説明しています。 前提条件 テナント管理を開始するには、以下が必要です： AWS アカウント Amazon SES で検証済みの送信元 ID (ドメインまたはメールアドレス) メール設定用の設定セット ビジネス要件に基づいたテナントの構造の明確な理解 テナント管理の設定方法と主要な考慮事項 Amazon SES でマルチテナントシステムを構築するには、IP プール、ドメイン検証、設定セットという 3 つの重要なコンポーネントを慎重に設定する必要があります。セットアップ手順に従うことで、各テナントは分離されたリソース、適切なトラッキング、モニタリング機能を持つことができます。Amazon SES の AWS Management Console または Amazon SES API を使用することで、各テナントの評価を分離しながら、高い配信性能を維持できる堅牢なメール送信インフラストラクチャを構築できます。 IP プールの設定 IP プールの設定 は、Amazon SES を使用してメール通信を送信するための基本的なステップです。マルチテナントのセットアップを開始するには、設定セットを通じて各顧客専用の専用 IP プールまたはマネージド IP プールを確立します。まず、 Amazon SES コンソール にアクセスし、 専用 IP のセクションに移動します。新しい 標準 IP プール を作成し、顧客を明確に識別できる名前を付けます。AWS Support を通じて、顧客の送信量に基づいて必要な IP アドレスの数をリクエストします。IP がプロビジョニングされたら、適切なプールに割り当てます。その後、IP プールをテナントに紐付けられた設定セットと関連付けます。IP ウォームアップについては、45 日間かけて送信量を徐々に増やす自動ウォームアップスケジュールを有効にするか、それを無効にして独自のカスタムウォームアッププランを実装するかの 2 つのオプションがあります。最適な配信率を確保するために、ウォームアップの進行状況を注意深く監視してください。 ドメイン検証プロセス IP プールの設定後、お客様の送信者識別情報を確立するためにドメインの検証を進めます。Amazon SES コンソールの「 検証済み ID 」(検証済み ID とは、Amazon SES で検証済みのドメインまたはメール ID のこと) セクションに移動し、お客様のドメイン名を使用して新しいドメイン識別情報を作成します。Amazon SES は、ドメインの DNS 設定に追加する必要がある DKIM レコードを提供します。お客様と協力して、これらのレコードを DNS 設定に正しく実装してください。検証プロセスは通常、完了までに 24～72 時間かかります。この間、Amazon SES コンソールで定期的に検証ステータスを確認し、プロセスが正常に完了することを確認してください。 テナントの認証と認可 特定の ID と設定に対するメール送信の制限に加えて、 AWS Identity and Access Management (IAM) のユーザーまたはロールのポリシーを使用して、テナントごとにメール送信権限を制限できます。以下のポリシーでは、テナントの Amazon Resource Name (ARN) が arn:aws:ses:us-east-1:111122223333:tenant/testTenant1/tn-e08a68010000a3e4c67bcd990910 、ID が arn:aws:ses:us-east-1:111122223333:identity/example.com 、設定セットが arn:aws:ses:us-east-1:111122223333:configuration-set/testTenant1. の場合にのみメール送信を許可する制限を示しています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "ses:SendRawEmail", "Resource": [ "arn:aws:ses:us-east-1:111122223333:identity/example.com", "arn:aws:ses:us-east-1:111122223333:configuration-set/TestTenant1" ], "Condition": { "StringEquals": { "ses:TenantName": "testTenant1" } } } ] } 設定セットのセットアップ 最後のステップは、トラッキングとモニタリングを管理する設定セットの作成と構成です。 まず、Amazon SES コンソールの設定セット セクションで新しい 設定セット を作成し、顧客の識別子に合わせて名前を付けます。 カスタムトラッキングドメインを設定し、開封とクリックの適切なトラッキング設定を有効にします。 この設定を、先ほど作成した IP プールにリンクします。 次に、メール配信状況を監視するためのイベントの送信先を設定します。これには Amazon CloudWatch メトリクス、 Amazon Data Firehose 、または Amazon Simple Notification Service (Amazon SNS) トピックを含めることができます。 CloudWatch では、バウンス率 (推奨しきい値: 5%) や苦情率 (推奨しきい値: 0.1%) などの重要なメトリクスに対してアラームを作成します。 これらのしきい値を超えた場合にチームに通知するシステムを設定し、配信の問題に迅速に対応できるようにします。 CLI コマンドの例 テナント管理の利用を開始するには、コンソール、 AWS Command Line Interface (AWS CLI) 、または AWS SDK を使用できます。以下は、 AWS CLI を使用してテナントを作成および設定する 基本的な例です。 以下では、テナントの作成から削除までのテナント管理手順のライフサイクルについて説明します。AWS CLI バージョン 2.28.0 以降を使用していることを確認してください。必要に応じて、 AWS CLI のインストールと更新手順 を参照してください。 新しいテナントの作成 aws sesv2 create-tenant --tenant-name testTenant1 --region us-east-1 “–region” の値はオプションです。 テナントに送信 ID (ドメインまたはメール ID) を割り当てる aws sesv2 create-tenant-resource-association --tenant-name testTenant1 --resource-arn arn:aws:ses:us-east-1:111122223333:identity/example.com テナントに設定セットを追加 aws sesv2 create-tenant-resource-association --tenant-name testTenant1 --resource-arn arn:aws:ses:us-east-1:111122223333:configuration-set/test1 ここでは、選択された設定セットにすでに IP プール が関連付けられていることを前提としています。 get-tenants または list-tenants によるテナント情報の取得 aws sesv2 get-tenant --tenant-name testTenant1 --region us-east-1 aws sesv2 list-tenants --region us-east-1 <List all the tenants with their ARN> get-tenant または list-tenants を使用して、テナントの名前、ID、ARN、作成タイムスタンプ、タグ、送信ステータスなど、特定のテナントに関する情報を取得できます。また、 list-tenants を使用してアカウントに関連付けられているすべてのテナントを一覧表示できます。 テナントのリソース一覧を表示 aws sesv2 list-tenant-resources --tenant-name testTenant1 テナントを使用してメールを送信 aws sesv2 send-email --from-email-address "sender@exanple.com" --destination "ToAddresses=recipient@example.org " --configuration-set-name test1 --content '{"Simple":{"Subject":{"Data":"Your email subject","Charset":"UTF-8"},"Body":{"Text":{"Data":"This is the plain text version.","Charset":"UTF-8"},"Html":{"Data":"<html><body><h1>This is the HTML version</h1><p>With formatted content.</p></body></html>","Charset":"UTF-8"}}}}' --tenant-name testTenant1 デフォルトで適用される標準ポリシーから厳格ポリシーへ 評価ポリシー を変更 aws sesv2 update-reputation-entity-policy --reputation-entity-type RESOURCE --reputation-entity-reference arn:aws:ses:us-east-1: 111122223333:tenant/ testTenant1/tn-145f7885b000074362bfa074ec4e1 --reputation-entity-policy arn:aws:ses:us-east-1:aws:reputation-policy/strict  テナントの送信を無効化 (テナントを一時的に無効化または一時停止) aws sesv2 update-reputation-entity-customer-managed-status —reputation-entity-type RESOURCE —reputation-entity-reference arn:aws:ses:us-east-1:111122223333:tenant/testTenant1/tn-145f7885b000074362bfa074ec4e1 —sending-status DISABLED テナントの削除 (テナントを Amazon SES アカウントから完全に削除) aws sesv2 delete-tenant --tenant-name testTenant1 SMTP を使用したメール送信 X-SES-TENANT ヘッダーは、AWS が複数のテナント間でメールを管理するために使用されます。X-SES-TENANT フィールドにテナント名を指定することができます。このアプローチにより、テナント情報に基づいてメールをより適切に整理およびルーティングすることができます。これを実装するには、SMTP を使用してメールを送信する際に X-SES-TENANT ヘッダーを追加します。以下の Python コードは、メール送信プロセスでこのヘッダーを含める方法を示しています： <Pseudo code> import smtplib from email.mime.text import MIMEText from email.mime.multipart import MIMEMultipart def send_email(smtp_server, port, username, password, from_email, to_email, subject, body, config_set=None): msg = MIMEMultipart() msg['From'] = from_email msg['To'] = to_email msg['Subject'] = subject msg['X-SES-TENANT'] = 'test1' if config_set: msg['X-SES-CONFIGURATION-SET'] = config_set msg.attach(MIMEText(body, 'plain')) with smtplib.SMTP(smtp_server, port) as server: server.starttls() server.login(username, password) server.send_message(msg) # Example usage: send_email('email-smtp.us-east-1.amazonaws.com', 587, 'YOUR_SMTP_USERNAME', 'YOUR_SMTP_PASSWORD','sender@exanple.com', 'recipient@example.org', 'Test Subject', 'Hello World', 'test1') テナントのメールイベントのフィードバックループ管理 メールイベントの受信やフィードバックの仕組みの利用は、テナントのメール送信運用を監視する上で重要です。テナント管理は、マルチテナント環境での評価管理機能を提供し、組織がテナントベース全体のメール送信運用を詳細に制御できるようにします。テナントレベルで評価に基づくポリシーを自動的に監視・適用できるため、1 つのテナントの問題のあるメール送信動作が他のテナントの配信性能に影響を与えることはありません。信頼性の問題が検出された場合、Amazon SES は影響を受けたテナントのメール送信を自動的に一時停止し、他のテナントはメール送信を妨げられることなく継続できます。組織は、配信性能の問題を早期に検出する自動化された評価検出を通じて、正確な制御メカニズムを実装できるようになりました。テナントの分離は、機械学習モデルとシグナルに基づく検出を使用して、メール送信動作の問題のあるパターンを特定します。問題が検出されると、Amazon SES は自動的に親アカウントに通知し、カスタマイズ可能なしきい値に基づいて事前に定義されたアクションをトリガーできます。この詳細な制御により、テナントレベルで問題を分離して対処しながら、メール送信インフラストラクチャ全体で高い配信性能を維持できます。 執行データとパターン 各国の法律が寄せ集めのように適用されている他のコミュニケーションチャネルとは異なり、大量メール配信は少数の大手メールサービスプロバイダーが定める要件に従う必要があります。Google、Yahoo、Microsoft などのプロバイダーが配信性能の目標を設定し、その遵守は送信者や Amazon SES などのサービスプロバイダーに委ねられています。Amazon SES は、マルチテナントプロバイダーを含む直接の顧客に対して、主要な執行シグナルを監視することを期待しています。そして、テナントが不正なメールを送信した場合、AWS の顧客が主要な執行シグナルを監視し、不正なテナントの一時停止や送信の停止などの適切な措置を取ることを想定しています。執行シグナルと信頼指標は、メールの評価管理システムにおいて不可欠な要素となります。これらのシグナルは、メール送信者の信頼性を評価するために監視する様々なデータポイントと行動を指し、これらのシグナルから導き出される信頼指標は、送信者の評価とベストプラクティスの遵守度を示す指標となります。Amazon SES は、送信前のシグナル（アカウントの審査や設定など）と送信後のシグナル（配信成功率、バウンス率、受信者の反応度など）を組み合わせて評価結果を算出します。これらの結果は、自動的な執行アクションと手動レビューに活用され、サービスが高い配信性能基準を維持しながら、不要または悪意のあるメールから受信者を保護することに役立ちます。シグナル分析と執行プロセスを継続的に改善することで、すべてのユーザーにとって信頼性が高く安全なメールエコシステムの構築を目指しています。 テナント分離と評価管理の運用 複数のテナントが SES アカウントを通じてメールを送信する場合、送信動作と評価を監視する必要があります。Amazon SES は、 評価結果 を通じて包括的な監視システムを提供し、テナントが懸念される送信パターンを示した場合に警告を通知します。これらの検出結果はダッシュボードに表示され、 Amazon EventBridge のデフォルトイベントバス を通じてイベントとして配信されるため、問題が発生した際に即座に通知を受けることができます。 メール配信管理者として、日常のモニタリングルーチンには、すべてのテナントのステータスを一目で確認できるテナント管理ダッシュボードの確認を含める必要があります。特に注意が必要なのは、低レベルと高レベルの 2 段階で示される評価結果です。これらの指標は、バウンス率や苦情率などのメトリクスが許容のしきい値を超えた場合に表示されます。 評価ポリシー を設定することで、これらのしきい値を超えた場合にテナントの送信を自動的に一時停止できます。標準的な実施（高レベルの結果で一時停止）または厳格な実施（低レベルの結果で一時停止）のオプションを選択できます。 テナントが自動または手動で一時停止された場合、その原因を調査する必要があります。評価結果には、バウンス率や苦情率の上昇など、一時停止のトリガーとなった詳細な情報が含まれています。テナントの根本的な問題に対処した後、送信を再開することができます。回復中、テナントはメトリクスが正常なレベルに戻ることを確認するためのモニタリングを行いながら、送信が可能になります。メトリクスが改善されると、テナントは自動的に通常の有効なステータスに戻ります。 利用可能なメトリクスとデータポイント これらのコアの評価メトリクスは Amazon SES によって公開され、EventBridge にルーティングできます。イベントフィードバックループにはテナント名と ID が含まれるため、テナント固有のバウンス率を追跡できます。 テナントごとの苦情率 サードパーティ別の苦情率 Spamhaus の IP リスト登録状況 メール量のパターン 継続的な管理においては、テナントのリソースと設定を完全にコントロールすることができます。必要に応じて送信 ID や設定セットの割り当てや削除、評価ポリシーの調整、懸念されるパターンを発見した場合の手動での送信の一時停止などが可能です。この自動化されたモニタリング、明確な評価シグナル、柔軟な管理ツールを組み合わせることで、個々のテナントの問題がアカウント全体の評価に影響を与えることを防ぎながら、テナントを管理することができます。重要なのは、ダッシュボードと評価結果を積極的にモニタリングし、問題が発生した際に迅速に対応することです。 まとめ お客様がテナント管理機能を活用して、メール運用を変革し、効率性を向上させ、ユーザーにより良い利用体験を提供するためにどのように活用されるのかを楽しみにしています。テナント分離を開始するには、 Amazon SES コンソール にアクセスするか、Amazon SES デベロッパーガイドの テナント をご覧ください。料金の詳細については、 Amazon SES の料金ページ でご確認いただけます。お客様のフィードバックとニーズに基づいてテナントの分離と管理を改善することに取り組んでおり、将来的にはさらに強力で柔軟なメール管理機能を提供していく予定です。Amazon SES で マルチテナント管理 を是非試してみてください。 著者について Satya S Tripathy Satyasovan Tripathy works as a Sr Specialist, Solution Architecture at AWS. He is located in Bengaluru, India, and focuses on the AWS business applictions product portfolio. He enjoys reading and travelling outside of work. Nideesh K T Nideesh is an experienced IT professional with expertise in cloud computing and technical support. Nideesh has been working in the technology industry for 9 years. In his current role as a Sr. Cloud Support Engineer, Nideesh provides technical assistance and troubleshooting for cloud infrastructure issues. Outside of work, Nideesh enjoys staying active by going to the gym, playing sports, and spending time outdoors. Tom Gilbert Tom Gilbert is a Senior Product Manager with the Amazon Simple Email Service team at AWS. Tom joined Amazon in May 2021, bringing a breadth of experience delivering enterprise solutions and scaling start-ups across industries. Outside of work, Tom is an avid sports enthusiast and enjoys spending quality time outdoors with his wife and two kids.

本記事は米国時間 8 月 15 日に公開された「 Kiro Pricing Plans Are Now Live 」を翻訳したものです。Kiro の最新情報は、 https://kiro.dev/ をご覧ください。 過去数週間にわたり、Kiro の料金に関するいくつかの重要なアップデート（ Kiro の価格更新 + ウェイトリストへの招待をまもなく開始 、 Kiro の価格設定を理解する：Spec、Vibe、使用量のトラッキング ）を共有してきました。これらのアップデートは、皆さまからのフィードバックに応える形で料金モデルを見直したものです。コミュニティの多くの方々から「プレビュー制限を超えて Kiro を使いたい」という声や、「ウェイトリストから外れて自分で Kiro を試したい」という声をいただいていました。本日（8/15）より料金プランを公開することで、すでにウェイトリストに登録している Kiro 愛用者のオンボーディングを加速し、既存ユーザーにも Kiro の利用に対するより大きなコントロールを提供できるようになります。 あなたにとっての意味 本日（8/15）以降、Amazon Q Developer サブスクリプションを持たない Google、GitHub、または AWS Builder ID アカウントでログインしたユーザーは、新しい料金モデルに移行しました。これらのアカウントは現在「無料（Free）」ティアとなっており、月 50 件の Vibe リクエストと 0 件の Spec リクエストが含まれています。 さらに、すべてのユーザーに対して 100 件の Spec リクエストと 100 件の Vibe リクエストのウェルカムボーナス を提供します。このボーナスは、新しい料金プランで最初のリクエストを行った時点から 14 日間有効です（どのティアであっても適用）。これにより、Kiro のすべての機能を体験し、自分の利用ニーズを把握するための時間を確保できます。 準備が整ったら、以下の 3 つの有料プランを選択できます。 利用状況のモニタリング 月ごとの Vibe / Spec リクエストの利用状況をプラン上限に対して確認でき、オーバー時の追加料金（有効化した場合）も追跡できます。また、サブスクリプションプランの管理も可能です。詳しくは Kiro のドキュメント をご確認ください。 プランのアップグレード アップグレードは簡単です。 Kiro のプロフィールアイコンをクリックし、「Upgrade Plan」を選択 希望のプラン（Pro、Pro+、Power）を選択 支払い情報を入力すると、新しいプランが即時に有効化 アップグレードやダウングレード、請求履歴の閲覧、支払い情報の更新はいつでも可能で、変更は即座に反映されます。 どのプランを選んでいいか分からない方は以下を参考にしてください。 初めて利用する場合： Pro を選び、オーバー分の課金を有効にして柔軟に利用しながら使用パターンを学んでください。 使用パターンが分かっている場合： 通常の月間利用に余裕を持って対応できる最小プランを選択してください。 コストを固定したい場合： 最大利用量をカバーするプランを選び、オーバー分の課金を無効化してください。利用は月の上限に達すると一時停止し、翌月にリセットされます。 重要：v0.2.13 以降にアップグレードして始めましょう 新しい使用状況ダッシュボードにアクセスし、プランを管理するには、 Kiro v0.2.13 以降にアップグレードする 必要があります。Kiro 内の設定アイコンをクリックし、「Check for updates…」を選んでください。 質問とフィードバック 詳細な料金に関する質問については、更新された料金 FAQ や ドキュメント をご覧ください。また、サブスクリプションモデルに関する最近のブログ記事（ Kiro の価格更新 + ウェイトリストへの招待をまもなく開始 、 Kiro の価格設定を理解する：Spec、Vibe、使用量のトラッキング ）も参照できます。フィードバックを共有したり質問したり、他の開発者が Kiro をどのように使っているかを知るために、 Discord コミュニティ にもぜひ参加してください。 Kiro v0.2.13 にアップデートし、使用状況ダッシュボードを確認し、自分の開発ニーズに合ったプランを選んで新しい料金体系を始めましょう。

本記事は米国時間 8 月 13 日に公開された「 Unlock your development productivity with Kiro and Model Context Protocol (MCP) 」の日本語抄訳版です。Kiro の最新情報は、https://kiro.dev/ をご覧ください。 Kiro はその組み込み機能によって、私にとって個人的な開発加速装置となってきました。ファイルの読み書きや Bash スクリプトを実行するツールを使うことで、Kiro は 仕様駆動開発（spec-driven development） 、オートパイロット、 エージェントフック といった機能を通じてアイデアを現実に変えます。しかし、開発チームの一員として作業していると、組み込みのツールだけでは十分でない場面があります。そこで Kiro を次のレベルに引き上げるのが Model Context Protocol（MCP） です。開発チームで作業する際には、次のような追加的なやり取りやデータアクセスが必要になることがよくあります。 社内ナレッジベース統合 — 会社のドキュメント、Wiki、ナレッジリポジトリへの接続 カスタム API アクセス — 内部サービスや組織固有 API とのやり取り プロジェクト管理ツール — Jira、Asana、GitLab などとの統合によるチケット・タスクの文脈提供 データベースアクセス — IDE 内でのデータベースクエリや分析 CI/CD パイプライン統合 — GitLab、GitHub Actions、Jenkins などとの接続によるビルド・デプロイ状況取得 コード品質ツール — SonarQube、Code Climate などへのリンクによるコード品質の洞察 監視システム — Prometheus、Grafana などからのメトリクスやログへのアクセス インフラ管理 — IaC ツールやクラウドリソースとのやり取り Model Context Protocol (MCP) の登場 MCP は Anthropic が提供する画期的なオープンソースプロトコルで、重要な課題を解決します。それは「AI モデルにツールやデータへの安全で一貫したアクセスを与える」ことです。MCP は、Kiro があらゆる開発ツールやサービスとシームレスに通信できるようにする「ユニバーサル翻訳機」と考えることができます。 Kiro + MCP を使い始める Kiro には MCP クライアントが組み込まれており、外部データソースやツールと安全かつ柔軟に通信する機能を拡張できます。 Kiro 内で MCP サーバーを有効化するには以下の手順が必要です。 ローカルマシンに MCP サーバーをセットアップする Kiro 内に MCP サーバーを追加・設定する Kiro のチャットセッション内で MCP サーバーツールを使い始める Kiro は MCP サーバーと標準入出力（stdio）を通じ、シンプルな JSON ベースのリクエスト／レスポンスパターンで通信します。 Kiro の MCP クライアントアーキテクチャ MCP サーバーは Kiro と同じローカルマシン上で動作しますが、PostgreSQL データベースのようなローカルシステムや GitLab のようなリモートサービスとも通信できます。 Kiro における MCP サーバーの利用有効化 MCP サーバーは Kiro 内で 2 つのレベルで設定できます。 ワークスペース — 現在のプロジェクト／ワークスペース固有、.kiro/settings/mcp.json に保存 ユーザー — 全プロジェクト／ワークスペースに適用、ホームディレクトリ（~/.kiro/settings/mcp.json）に保存 ユーザースコープの MCP サーバーを設定する手順は以下のとおりです。 アクティビティバーから Kiro を選択 MCP SERVERS を展開 Workspace または User Config を開く MCP Server のセットアップ GitLab の計画機能を Kiro に持ち込む 開発チームは、共同作業や計画、ソフトウェア管理のために集中型のツールをよく使います。たとえば GitLab は、計画・開発・デリバリーを一体化したオールインワンのツールです。私の開発ワークフローでは、GitLab をコードやビルド管理だけでなく、機能やバグといったタスクの計画にも使っています。 GitLab Issues は製品の機能とバグを表示 例えば、次のような機能を考えてみます。 機能：Products API のコンテナ化 コンテキストスイッチをせずに、Kiro に GitLab の課題を読み込ませて実装してみましょう。 GitLab MCP サーバーの設定 このブログ記事では、オープンソースの GitLab MCP サーバー （ https://gitlab.com/fforster/gitlab-mcp ）を使います。README に設定方法が記載されており、私はソースからバイナリをビルドしました。 GitLab プロフィールから パーソナルアクセストークン を発行した後、Kiro MCP サーバーのユーザー設定に記述します。 { "mcpServers": { "GitLab": { "command": "../gitlab-mcp", "env": { "GITLAB_TOKEN": "gitlab_access_token", "GITLAB_URL": "gitlab_url" } } } } Kiro のユーザー設定は .kiro/settings/mcp.json にあります。 設定が正しければ、Kiro は MCP サーバーから提供される新しいツールを返してきます。 gitlab-mcp server によって提供されるツール ここでは、例えば get_issue や list_project_issues などの便利なツールがいくつかあります。これらの使い方を見ていきましょう。 GitLab イシューと Kiro の仕様駆動開発を同期 GitLab に列挙された課題を実装するために、Kiro のエージェントによる仕様駆動開発を活用したいと考えています。GitLab MCP サーバーが設定できたので、「製品に関連するすべての課題について要件ドキュメントを作成してほしい」と自然言語で説明できます。 Kiro チャットウィンドウで「 Spec 」を選択すると、GitLab イシューを構造的に実装することができます。次のステップは、Kiro に GitLab イシューの仕様を作成するよう指示することです。 gitlab プロジェクト WWSO-Q-DEV-SA/products-api のすべてのイシューに対する仕様を作成する GitLab の issue を Kiro の仕様に同期するための単一のリクエスト list_project_issues のような新しいツールを初めて使う際は、Kiro は実行前に承認を求めてきます。 list_project_issues ツールを使用してプロジェクトの問題を特定 なお、MCP 設定内の autoApprove 設定を使用して、Kiro がユーザーにプロンプトを表示せずにツール実行リクエストを自動的に承認するかどうかを制御することもできます。 { "mcpServers": { "GitLab": { "command": "../gitlab-mcp", "env": { "GITLAB_TOKEN": "gitlab_access_token", "GITLAB_URL": "gitlab_url" }, "autoApprove": [ "list_project_issues" ] } } } イシューが取得されると、Kiro は各 GitLab イシューに対して仕様を作成し始めます。 GitLab イシューの仕様を作成 仕様は専用メニューに保存され、プロジェクトワークスペースの .kiro ディレクトリにも格納されます。 最初に作成されたイシューの要件 ここから、技術的なアーキテクチャ決定、システムコンポーネントの相互作用、データモデルとフロー、API 仕様、セキュリティ検討、性能要件などを含む設計ドキュメントを作成できます。 最終ステップは設計を実行可能なタスクに分解し、明確な「完了の定義」と実装詳細を含めることです。 GitLab イシューの計画が完了すれば、タスクリストに従って構造的に機能を構築できます。 イシューに関する要件、設計、タスクリストの確認 開発を次のレベルへ Kiro の MCP 統合は単なる機能追加ではなく、AI が開発ワークフローに統合される根本的な変化です。Kiro をツールやサービスに直接接続することで、コンテキストスイッチに費やす時間を減らし、より多くの時間を構築に使えるようになります。 無料で Kiro を始めたり、ドキュメントを参照して機能をさらに学んだりしましょう。 MCP ユーザーガイド や MCP Server ページ でリファレンス実装も確認できます。要件に合う MCP サーバーが見つからない場合は、Kiro と一緒に自作することも検討してください。 ぜひつながりましょう — X 、 LinkedIn 、 Instagram では @kirodotdev を、 Bluesky では @kiro.dev をタグ付けし、 #builtwithkiro でシェアしてください。 出典： Unlock your development productivity with Kiro and MCP

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 8 月 22 日に「 AWS 生成 AI アプリ構築実践ガイド 」というLLMの基礎、RAG、AIエージェントを網羅した本が出版されます。基礎知識の習得に加えてハンズオンで実践力を磨くこともできるようになっています。ぜひご覧ください！ 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、8 月 11 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「経済産業省 GENIAC 基盤モデル開発支援事業 (第3期) における採択事業者への支援を開始」を公開 経済産業省と NEDO が実施する GENIAC 基盤モデル開発支援事業の第3期における採択事業者のキックオフが 2025年7月4日に行われました。AWS は採択事業者に対して Amazon EC2 P5/P5en/Trn2 インスタンスや Amazon SageMaker HyperPod などの計算資源、技術支援、開発者コミュニティ支援、事業化支援を提供します。本ブログでは、採択事業者12社の紹介と AWS による包括的な支援内容について紹介しています。 ブログ記事「業界タスク特化型⼤規模⾔語モデルの開発 〜 野村総合研究所様へのインタビュー 〜」を公開 野村総合研究所（NRI）様が AWS の生成 AI 実用化推進プログラムを活用して開発した業界タスク特化型大規模言語モデルについてのインタビュー記事です。専門知識への適用、推論コスト削減、安心・安全なコントロール性という3つの理由から特化型 LLM が求められており、業界知識の継続事前学習とタスク特化のファインチューニングを組み合わせた2段階アプローチによる学習手法や AWS Trainium を活用したコスト効率の改善について紹介しています。 ブログ記事「Reach plc は AWS を活用した AI 駆動の Guten により、インパクトのあるジャーナリズムを提供」を公開 本ブログは、英国最大のニュースパブリッシャー Reach plc が Amazon Bedrock を活用して開発した AI 駆動プロダクト「Guten」についての事例紹介ブログです。Guten の開発背景、機能、AWS アーキテクチャについて解説しています。Guten により、記事タグ追加やコンテンツドラフト作成などのタスクを自動化し、速報ニュースの公開時間を9分から90秒に短縮した効果が紹介されています。 ブログ記事「AI エージェントで制御する IoT ミニ四駆 – AWS Summit Japan 2025 展示の技術的詳細」を公開 AWS Summit Japan 2025 で展示された「AI エージェントで制御する IoT ミニ四駆」の技術的詳細について解説したブログです。Amazon Bedrock Agents を活用してクラウド上の AI エージェントがミニ四駆の制御判断を行う仕組みで、ESP32 マイコンを使用したハードウェア設計から AWS IoT Core を中心としたクラウドアーキテクチャまで、製造業 DX にも応用可能な技術的取り組みを詳しく紹介しています。 サービスアップデート Amazon Q Business がチャットの透明性向上のための Response Events機能 を提供開始 Amazon Q Business に Response Events 機能が追加されました。これまでクエリ処理がブラックボックス状態で、AI がどのように回答を生成したか分からない課題がありました。新機能により、RAG による企業知識の検索やファイル処理、プラグインとのやり取りをリアルタイムで確認できるようになります。処理過程が可視化されることで、回答への信頼性と透明性を向上させることが可能です。 Amazon Q Business が Agentic RAG を開始し、精度と説明可能性を向上 Amazon Q Business で新機能 Agentic RAG が提供開始されました。複雑な質問に対して AI エージェントが質問を自動的に分解して並列処理することで、より正確で詳細な回答を生成できるようになりました。企業データを対象とした複雑な問い合わせでも、データの整合性をチェックしながら包括的な回答を提供します。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock の Anthropic Claude Sonnet 4 でコンテキストウィンドウが拡張 Amazon Bedrock の Claude Sonnet 4 でコンテキストウィンドウが 20 万トークンから 100 万トークンに 5 倍拡張されました。これにより、大規模なコードベース全体の分析や、数百の文書を一度に処理する文書統合、複雑なワークフローを持つ AI エージェントの構築が可能になります。従来は分割して処理する必要があった大容量データも、一回のリクエストで完全な文脈を保ったまま処理できるようになりました。現在パブリックプレビューでオレゴン、バージニア北部、オハイオリージョンで利用可能です。 Amazon SageMaker HyperPod が新しいクラスター設定エクスペリエンスを提供開始 Amazon SageMaker HyperPod で新しいクラスター作成体験が提供開始されました。大規模な AI/ML ワークロード向けのネットワーク、ストレージ、コンピュート、IAM 権限などを数クリックで自動設定できます。従来は手動でこれらのリソースを個別に設定する必要がありましたが、新しい設定により AWS インフラの専門知識がない方でもクラスターを構築しやすくなりました。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod でカスタム AMI がサポート開始 Amazon SageMaker AI で新しい GPU インスタンス P6e-GB200 UltraServers のサポートが開始されました。従来の P5en インスタンスと比較して 20 倍以上のコンピュート性能と 11 倍以上のメモリを提供し、最大 72 の NVIDIA Blackwell GPU を活用できます。これにより兆パラメータ規模の大規模 AI モデルのトレーニングを効率よく取り組むことが可能です。現在はバージニア北部リージョンの Dallas Local Zone で利用可能で、SageMaker Flexible Training Plans を通じて予約できます。詳細は こちらのドキュメント をご参照ください。 SageMaker HyperPod が LLM タスクの Topology Aware Scheduling をサポート SageMaker HyperPod で Topology Aware Scheduling (TAS) が利用可能になりました。大規模言語モデル (LLM) のトレーニングタスクを最適なネットワーク配置で実行できます。従来は複数のインスタンス間でデータ交換する際、ネットワークホップが多く通信遅延が発生していました。今回のアップデートにより、ネットワークトポロジー情報を活用してタスクを自動的に最適な場所にスケジューリングし、インスタンス間通信を削減してトレーニング効率を向上させます。詳細は こちらのドキュメント をご参照ください。 SageMaker HyperPod がコンピュートリソースのきめ細かいクォータ割り当てをサポート SageMaker HyperPod で、コンピュートリソースの細かい quota 割り当てが可能になりました。これまではインスタンス全体を使う必要がありましたが、GPU や vCPU、メモリを必要な分だけチーム間で配分できるようになります。機械学習のトレーニングや推論タスクで、リソースの無駄遣いを防ぎ、コスト効率を向上させることができます。詳細は こちらのドキュメント をご参照ください。 Amazon EC2 シングル GPU P5 インスタンスが一般提供開始 Amazon EC2 P5 インスタンスに、NVIDIA H100 GPU を 1 つ搭載した新しいサイズが一般提供開始されました。従来は大規模な GPU 環境が必要だった機械学習や高性能コンピューティングを、小さく始めてコスト効率的に利用できるようになります。中小規模のチャットボットや翻訳ツール、製薬研究や金融モデリングなどの用途に最適です。東京リージョンを含む複数リージョンで利用可能です。 Amazon OpenSearch Serverless が kNN Byte vector と新しいデータタイプをサポート Amazon OpenSearch Serverless で kNN Byte vector サポートなど複数の新機能が追加されました。従来の kNN vector と比べてメモリとストレージ使用量を削減でき、コスト最適化とパフォーマンス向上が期待できます。さらに radial search や nested fields により、1 つのドキュメント内で複数ベクトルの管理が可能になり、複雑な検索・分析ワークロードにも対応しやすくなりました。詳細は こちらのドキュメント をご参照ください。 Amazon Neptune が GenAI アプリケーションでのグラフネイティブメモリのために Cognee と統合 Amazon Neptune Analytics が Cognee という AI エージェント向けメモリフレームワークと統合されました。この統合により、生成 AI アプリケーションでグラフベースの長期記憶機能を利用できるようになります。AI エージェントが過去のやり取りから学習し、時間の経過とともによりパーソナライズ化され効果的な応答を提供できます。詳細は こちらのドキュメント をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

Amazon Finance Automation (FinAuto) は Amazon Finance Operations (FinOps) の技術組織です。この組織のミッションは、FinOps を活用してAmazon ビジネスの成長と拡大を支えることです。自動化とセルフサービス機能を活用することで業務効率を飛躍的に高めると同時に、支払いと回収を正確かつ遅滞なく行える体制を整えています。FinAuto は、FinOps 全体を俯瞰できる特別な立場にあり、この強みを活かすことで、正確性、一貫性、ガバナンスを備えたデータとサービスを提供し、多様なユースケースに対応したソリューションを展開しています。 本記事では、Amazon Finance Automation チームの取り組みをご紹介します。具体的には、 Amazon DynamoDB 、 Amazon OpenSearch Service や Amazon Neptune などのAWSの特化型データベースと AWS Lambda などのサーバーレスコンピューティングを組み合わせ、運用データストア (ODS) を構築しました。この ODS は財務取引データを保管し、ミリ秒単位の応答速度で FinOps アプリケーションをサポートしており、FinOps ビジネスにとって不可欠な基盤となっています。 (本記事は 2025/04/15 に投稿された How Amazon Finance Automation built an operational data store with AWS purpose built databases to power critical finance applications を翻訳した記事です。) 要件 Amazon では、様々なシステムから財務データが生成され、会計処理のためにそれぞれの補助元帳に保管されていますが、各システムで異なるデータモデルが使用されています。財務アナリストが効率的に業務を行えるよう、これらの補助元帳のデータを統一的に扱える共通のデータモデルが求められています。また、この統合データは、バックエンドおよびフロントエンドの業務アプリケーションから利用できるよう、API 経由でアクセスできる環境を整える必要があります。 データベースサービスを選定するにあたり、以下の主要要件に焦点を当てて検討を行いました： データベースサービスは、大量のトランザクションを処理できるよう、迅速なスケーリングが可能でなければなりません。上流システムでは 1 日に数億件もの財務取引イベントが生成されるため、そうした処理量に応じて適切にスケールできる能力が求められます。 フロントエンドのユーザーアプリケーションを円滑に動作させるため、データ提供用 API はミリ秒レベルの高速なレスポンスを実現する必要があります。また、キーバリューベースでの検索にも対応している必要があります。具体的には、財務アナリストが口座番号を指定して、それに紐づくすべての取引データを瞬時に取得できるような機能が求められます。 データベースには、各補助元帳が持つ独自のデータ属性に対応できるよう、柔軟なスキーマ構造が求められます。 データストアは口座、請求書、クレジットノート、領収書といった財務関連エンティティを横断的に検索できる必要があります。例えば、財務アナリストが口座番号を知らなくても、口座名での検索が可能でなければなりません。 データストアは、口座単位や数千の口座を含むビジネスチャネル単位など、様々な観点からデータを集計できる機能を備えている必要があります。たとえば、財務アナリストが特定の口座に関連する売掛金の総額を把握できるようにする必要があります。 データベースにはアカウント間の関連性を保存できる機能が必要です。これは FinOps ならではの要件で、一人の顧客が複数の Amazon サービスをそれぞれ異なるアカウントで利用するケースに対応するためのものです。顧客への請求書を一本化し、利便性の高いサービスを提供するためには、アカウント間の関連性を正確に記録・管理できるデータベースが必要です。この関連性の情報を活用することで、複数のアカウントで発生した取引を適切にグループ化し、統合的な管理が可能となります。 ソリューション概要 多岐にわたる要件に対応するため、それぞれの要件に特化した AWS の専用データベースを複数組み合わせて利用する方針を定めました。 その中でも、主力となるデータストアとして Amazon DynamoDB を採用しました。採用の決め手となった特長は以下の通りです： まず、キーバリュー方式での読み取りにより、高速なデータアクセスを実現できます。具体的には、特定口座の請求書や領収書の参照、口座名や状態の確認といった操作を迅速に行うことができます。また、Amazon DynamoDB は柔軟なスキーマ構造を持つため、項目ごとに異なる属性を設定できます。これにより、複数の売掛金システムそれぞれが持つ固有の属性データを適切に保存できます。私たちのシステムでは、データの読み取りを行うクライアントが地理的に分散しており、また書き込みワークロードは上流の請求システムの状況に左右されるため、負荷の予測が困難です。そこで、Amazon DynamoDB の オンデマンドキャパシティモード を採用しました。このモードでは、キャパシティの管理を自動化でき、実際の利用量に応じた課金となるため、効率的な運用が可能です。 データの集計に関しては、数千件に及ぶトランザクションを遅延や性能劣化なく集計する必要があるため、事前計算サービスを構築しました。このサービスは、 Amazon DynamoDB Streams 、AWS Lambda、 Amazon Simple Queue Service（Amazon SQS） を組み合わせて実現しています。新しいイベントが発生すると自動的に起動し、非同期で集計処理を行います。このように事前に計算を行っておくことで、ユーザーが必要なときにミリ秒単位の応答速度でデータにアクセスすることが可能となります。 ユーザーからは、複数の属性を使って財務関連データを横断的に検索できる機能が求められていました。また、口座名の入力補完機能や、滞留債権残高が最も高い口座を上位から表示する機能なども必要とされていました。これにより、アナリストはそれらの口座に対する業務計画を立てることができます。これらの要件を満たすため、私たちは Amazon OpenSearch Service を採用しました。事前計算サービスで算出した滞留残高のデータを Amazon OpenSearch Service に保存することで、数千の口座にわたるデータの集計や並び替えを可能としました。 顧客の中には、一つの補助元帳で複数の口座を管理しているケースがあります。このような顧客からは、口座ごとに個別の連絡や請求書が届くのではなく、一元化された形での対応を望む声が寄せられていました。この要望に応えるため、財務アナリストが設定した口座間の関連性を保存し、必要に応じて検索できるシステムが必要でした。口座間の関係性は通常、親口座 “A” の下に子口座 “B” と “C” が属するような、階層構造として表現されます。Amazon Neptune は、高速で信頼性が高い、フルマネージド型のグラフデータベースで、相互に密接に関連したデータの保存と検索に最適化されています。Amazon Neptune は、私たちが作成しようとしている実際の関係性の構造を模倣したグラフ表現を生成します。このように関連データの保存とトラバーサル（データ構造の走査）に特化した機能を持つことから、私たちは Amazon Neptune を採用しました。 ソリューションアーキテクチャ 下図は、使用している各種 AWS サービスを含む、システム全体のアーキテクチャ概要を示しています。 注: 画像をクリックすると、新しいタブで拡大版を開くことができます。 複数の上流システムからのデータは、様々な方法で取り込まれ、変換された後に DynamoDB に保存されています。DynamoDB テーブルにはストリーム機能が有効化されており、複数の AWS Lambda 関数がこれらのストリームメッセージを処理して、Amazon SQS キューに送信します。これらのキューには適切なエラー処理のための デッドレターキュー (DLQ) が設定されています。さらに別の Lambda 関数群が SQS キューからメッセージを読み取り、そのデータをAmazon OpenSearch Service のドメインにインデックス化します。 なお、この解決策は DynamoDB と OpenSearch Service 間のゼロ ETL 統合が導入される以前から本番環境で稼働していました。ゼロ ETL を採用することで、アーキテクチャと運用がより簡素化されたはずであり、可能な場合には将来的にこの統合方式への移行を検討しています。 また、アカウント間の関係性を特定・処理する独立したマイクロサービスが、それらの関係性を Amazon Neptune データベースに格納しています。ビジネスのユースケースに応じて、DynamoDB、OpenSearch Service、もしくは Neptune クラスターを通じて、API を介してデータが提供されています。 Amazon DynamoDB 上流のシステム間に接続性がないため、重複した ID が発生する可能性を防ぐために、異なるエンティティごとに新しい識別子を作成しました。この新しい ID は私たちのシステム内で一意であり、データ利用者が API を呼び出す際に使用する識別子となっています。システムでは UUID version 5 を採用しており、各トランザクションで利用可能な属性の組み合わせを用いて ID を生成しています。 以下の図は、私たちの DynamoDB ベーステーブルのデータモデルを示しています。 ソートキー属性を使用することで、KeyConditionExpression を活用し、特定の（トランザクション）ID に関連するアカウントや請求書で始まる値を検索するクエリを指定することができます。 API の要件によっては、（トランザクション）ID 以外の属性でデータを検索する必要があったため、 グローバルセカンダリインデックス（GSI） を使用しています。GSI はデフォルトでスパースな特性を持っており、GSI に定義されたパーティションキーとソートキーが項目に存在しない場合、その項目は GSI には書き込まれません。このスパースインデックスは、テーブルのデータの一部のみを検索したい場合に特に有用です。上記の例では、marketplace 属性はアカウント項目にのみ存在します。’amzChannel’ を主キー、marketplace をソートキーとして GSI を作成することで、トランザクションの請求書項目を検索することなく、特定の amzChannel と marketplace に属するすべてのアカウントを迅速に検索することが可能になります。 以下の図は、私たちの DynamoDB テーブルに作成した GSI のサンプルを示しています： また、いくつかの並び替えのユースケースにおいて、ローカルセカンダリインデックス（LSI）も活用しています。通常、1つのアカウントには数百件の決済済み請求書（一定期間にわたって作成・支払いが完了した請求書）と少数の未決済請求書が存在します。特定のアカウントの支払期限超過残高を計算する際には、そのアカウントの未決済請求書を確認する必要があります。特定のアカウントの未決済請求書のみを参照する場合、アカウントの請求書を検索し、DynamoDB の FilterExpression を使用して status=OP の請求書をフィルタリングすることも可能です。しかし、フィルター式はクエリ完了後、結果が返される前に適用されるため、同じ量の読み取りキャパシティを消費してしまいます。数千件の請求書を持つアカウントの場合、このようなクエリのレイテンシーは高くなってしまいます。LSI を使用することで、アプリケーションは異なるソートキーを選択できるようになりました。LSI には、ベーステーブルの属性の一部または大部分のコピーが含まれています。LSI 内のデータは、ベーステーブルと同じパーティションキーで整理されますが、異なるソートキーを使用します。invoiceStatus をソートキーとして LSI を作成することで、特定のアカウントの未決済請求書を迅速に検索できるようになりました。この結果、大量の決済済み請求書を持つアカウントにおいて、未決済請求書の検索レイテンシーが 10 倍改善されました。 LSI はテーブル作成時にのみ作成できるため、将来の並び替えユースケースに対応できるよう、sortKey1 や sortKeyN などのプレースホルダー属性を作成しました。 以下は、ベースとなる DynamoDB テーブルとその LSI における属性のサンプル表現です： 運用データストア（ODS）における財務データの取り込みと提供において、最も重要な要件の一つは、正確なデータ品質を保証することです。私たちのサービスは、外部顧客に送付される取引明細書（SOA）の作成に使用されるため、堅牢で信頼性の高い照合サービスが、データの正確性を保証する上で極めて重要となります。この照合ソリューションには、上流システムから提供される真正データ（信頼できる情報源）と、DynamoDB テーブルから変換され Amazon Simple Storage Service（Amazon S3） で利用可能となったデータが必要です。DynamoDB のネイティブ エクスポート 機能を使用して S3 にデータを転送することで、DynamoDB に対するフルテーブルスキャンを回避することができました。また、DynamoDB は増分エクスポートをサポートしているため、前回のエクスポート実行以降に変更されたデータのみをエクスポートするよう設定しました。これにより、テーブルの読み取りキャパシティや可用性に影響を与えることなくデータを転送できています。その後、 Amazon EMR を使用して Spark アプリケーションを実行し、DynamoDB から S3 にエクスポートされたデータと、上流のデータストア（信頼できる情報源）からのエクスポートデータとの照合を行っています。DynamoDB からエクスポートされたデータは、照合システムへの入力としての役割だけでなく、他の下流のデータチームが財務報告を作成する際にも活用されています。 以下の図は、私たちの照合サービスの高レベルアーキテクチャを示しています： Amazon OpenSearch Service 入力途中での検索（サジェスト検索）や集計要件に対しては、Amazon OpenSearch Service を使用しています。DynamoDB の取引データはさらに情報が追加され、Amazon OpenSearch Service に取り込まれます。DynamoDB は AWS Lambda とネイティブに連携しており、DynamoDB ストリームのイベントに応答するトリガーとして Lambda を利用できます。この Lambda 関数がストリームイベントを処理し、エンティティ固有の SQS キューにメッセージを送信します。別の Lambda 関数が SQS のメッセージを処理し、追加情報でデータを拡充した上で、OpenSearch にインデックス化します。要件の一つとして、財務アナリストに割り当てられた全アカウントの売掛金の経過期間別残高を特定する必要があります。これにより、アナリストは担当アカウントの優先順位付けが可能になります。アナリストへのアカウント割り当ては別のデータセットとして管理されており、取引データとは別に保存されています。このデータを照会し、拡充したデータを OpenSearch Service に取り込むことで、クライアントのユースケースに応じた集計クエリをミリ秒単位のレイテンシーで実行することが可能になりました。 入力途中での検索に関して、OpenSearch Service はクエリ時処理とインデックス時処理のオプションを提供しています。クエリ時処理では、クエリ実行時に保存されたフィールドのプレフィックスを検索できるフィルターを指定します。データは通常通り OpenSearch に保存されますが、クエリはプレフィックスを検索します。これは、OpenSearch が既にインデックス化されたデータのプレフィックスをその場で計算して検索を実行するため、負荷の高い処理となります。これは「文字列を含む」という種類の処理に近いものです。一方、インデックス時処理では、インデックス作成時にカスタムトークナイザーを使用して単語をより小さな部分に分割することができます。私たちはデータのインデックス作成時に edge_ngram トークナイザーを使用しました。以下のスクリーンショットは、アカウント名「Amazon」がインデックス時に複数のトークンに分割される例を示しています。これにより、入力途中での検索における検索結果の高速化を実現しました。 Amazon Neptune 前述の通り、顧客アカウント間の関係性を追跡する要件があります。一人の顧客が補助元帳内に複数のアカウントを持つことがあり、顧客からは全アカウントを統合した請求明細書の発行を求められています。また、財務アナリストは顧客の全アカウントにわたる統合された経過期間別残高を確認する必要があります。このため、アカウント間の関係性を特定し、保持する必要が生じています。各事業部門は、顧客の関連アカウントを特定するための独自のルールと属性を定義しています。私たちのシステムは、これらの定義されたルールに基づいてデータ属性を取り込み、また関連アカウントの特定と維持のために、これらの属性の変更も検知しています。グラフデータベースである Amazon Neptune を使用することで、関係性を自然な形でモデル化し、ユースケースに応じた柔軟な走査クエリを実行することが可能になりました。 代替案として、DynamoDB を使用して同様の機能を実現する方法も検討しました。DynamoDB では 隣接関係リスト 設計モデルを使用して関係性を保存することが可能で、ノードに親ノードへの参照やそのノードに関連するエッジを含めることができます。この方法は実現可能ではありますが、データを取得するためのクエリには関係性を辿るための繰り返しの呼び出しが必要となり、ネストされた関係性や分岐する関係性に対してはパフォーマンスが低下してしまいます。一方、Neptune ではデータベース内で走査が行われるため、1回のリクエストで関係性を取得することができます。このため、関係性の保存には Amazon Neptune を採用しました。 初期のユースケースでは、複数の個別アカウントをグループとして集約して作業する機能が必要でした。以下の図は、ノードとエッジの構造を示しています。ノードから HasParent タイプのエッジを走査することで、関連するアカウントを迅速に取得できます。クエリはグループレベルから開始して入力エッジを辿るか、あるいはアカウントレベルから開始して出力エッジを辿り、見つかったグループから入力エッジに戻ることができます。 // If starting from an account to find all related accounts, example account 1 g.V(1) // Follow inbound/outbound edges of type "HasParent" deduping to avoid repetition .repeat(both("HasParent").dedupe()) // Fetch nodes that are of type "Account" .emit(hasLabel("Account")) > [ { id: 1, label: "Account" }, { id: 2, label: "Account" }, { id: 3, label: "Account" } ] より複雑なユースケースに対応するため、新しいマクログループ化を提供できるようスキーマを拡張しています。既存のデータに新しい関係性タイプとメタデータを定義する新しいノード/エッジタイプを追加することができます。これにより、既存のクエリに軽微な修正を加えるだけで、Neptune にシステム内の関連アカウントを見つけるための新しい関係性セットの走査を指示することができます。これを繰り返すことで、同じデータに対して異なるグループ化の視点を提供することが可能です。さらに、ノードに設定されたプロパティによって結果をフィルタリングすることで、返される項目をより詳細に絞り込むことができます。 以下の図は、2 つのビジネスグループが同じ組織に関連付けられている複雑なグループ化の例を示しています。 // If starting from an account to find all related accounts, example account 1 g.V(1) // Follow inbound/outbound edges of type "HasParent" and "SubsidiaryOf", deduping to avoid repitition .repeat(both("HasParent", "SubsidiaryOf").dedupe()) // Fetch nodes that have are of type "Account" .emit(hasLabel("Account")) > [ { id: 1, label: "Account" }, { id: 2, label: "Account" }, { id: 3, label: "Account" }, { id: 4, label: "Account" } ] アカウントが一方の顧客から別の顧客に移動するケースが発生することがあります。その場合、該当するアカウントを元の顧客のグループから切り離し、新しい顧客のグループに移動する必要が生じます。 以下の図は、組織 A のビジネスグループ 1 に属していたアカウント 1 が、新しいグループであるビジネスグループ 3 に移動する例を示しています。 結論として、Amazon Neptune を採用することで、独自のグラフデータベース管理システムを運用する複雑さを回避しながら、アカウント関係性サービスを構築することができました。このモデルにより、アカウント間の関係性を簡単に走査でき、関連アカウントを特定するというユースケースを解決し、ユーザーにより良い体験を提供することができています。グラフは毎日更新され、関係性の変更を特定しています。関係性の取得において、p90（ 90 パーセンタイル値）で 250 ミリ秒未満の応答時間を実現しています。 運用の優位性について Amazon の財務データを扱う上で、100 %のデータ品質を保証する必要があります。複数のコンポーネントを含む分散システムにおいては、信頼性と正確性の維持が重要です。そのため、私たちはフォールトトレランス（障害耐性）を基本原則としてシステムを設計しています。例えば、各 SQS キューには、処理に失敗したメッセージを捕捉するための対応するデッドレターキュー（DLQ）が設定されており、 Amazon CloudWatch によるモニタリングとアラームが構成されています。さらに、API における 5XX エラーとレイテンシーメトリクスのモニタリングには、CloudWatch API Gateway（APIG）メトリクスを活用しています。 また、ビジネスユースケースに応じたカスタムメトリクスを CloudWatch に公開するため、AWS SDK for CloudWatch を使用しています。例えば、ソースシステムでのトランザクションイベント生成から、最終的に運用データストアに取り込まれるまでの所要時間を計算するため、取り込みイベントのレイテンシーメトリクスを公開しています。 まとめ 本記事では、Finance Automation チームが財務部門特有の要件を満たすため、AWS 専用データベース（DynamoDB、OpenSearch Service、Neptune）を活用して、拡張性と信頼性を備えたイベント駆動型の運用データストレージを構築した事例をご紹介しました。 DynamoDB が標準で提供する DynamoDB Streams 、グローバルセカンダリインデックス、ローカルセカンダリインデックス、S3 へのエクスポート機能、柔軟なスキーマ構造といった機能により、開発工数を大幅に削減することができました。 また、Amazon OpenSearch Service の活用により、API のレスポンス時間を維持しながら、検索機能と集計機能の要件を満たすことができました。さらに、Amazon Neptune の採用によって、口座間の関連性の保存、探索、取得処理を簡素化することができました。 加えて、AWS Lambda というサーバーレスコンピューティングを DynamoDB Streams および Amazon SQS と組み合わせることで、システム全体をシンプルな構成としました。SQS の活用により、高い耐障害性を維持しながら、データストア間の疎結合化を実現することができました。 AWS 専用データベースについて詳しく知りたい方は、 Purpose-built databases のページをご覧ください。 作者情報 Nitin Arora は Amazon の Finance Automation 部門のシニアソフトウェア開発マネージャーです。18 年を超えるキャリアの中で、業務に不可欠な、スケーラブルで高性能なソフトウェアの開発に携わってきました。現在は財務部門において、データメッシュの構築をはじめとする、様々なデータ・アナリティクス施策のリーダーを務めています。プライベートでは、音楽鑑賞と読書を趣味としています Pradeep Misra は、AWS のプリンシパルスペシャリストソリューションアーキテクトとして、Amazon 社内の様々な部門で最新の分散分析システムや AI/ML プラットフォームの設計に従事しています。特に、データ、分析、AI/ML を駆使してお客様の課題解決に取り組むことに強い情熱を持っています。プライベートでは家族と過ごす時間を大切にしており、一緒に新しい場所へ出かけたり、さまざまな料理を楽しんだりしています。また、家族でボードゲームやアウトドアゲームを楽しむほか、娘たちと一緒に科学実験を行うことを楽しみにしています。 Kumar Satyen Gaurav は、エンタープライズアプリケーション、ビッグデータソリューション、ソフトウェア開発の分野で18年を超えるキャリアを持つ、経験豊富なソフトウェア開発マネージャーです。 Amazon では、エンジニアチームのリーダーとして、AWS 技術を駆使した製品・サービスの開発を指揮しています。これらの成果は、Amazon の財務運営部門に対して、事業部門を横断する重要な経営判断材料を提供しています。仕事以外では、読書や旅行を楽しむとともに、金融投資や経済の動向について知見を深めることに情熱を注いでいます。 Tarun Gupta は、Amazon のシニアシステム開発エンジニアとして、同社の財務データ基盤を支える重要なビッグデータ処理システムと運用データストアの設計・実装を手がけてきました。その業務は多岐にわたり、Apache Hudi のような Spark ベースの S3 テーブルフォーマット、運用データストアのデータモデリング、そして様々な AWS の NoSQL およびリレーショナルデータストアを活用した複雑なアプリケーションアクセスパターンのサポートなどを含みます。仕事を離れると、熱心なボードゲーム愛好家として知られ、また大工仕事や絵画といった DIY プロジェクトに取り組むことを趣味としています。 Javier Vega は、9 年以上の経験を持つ Amazon のシニアソフトウェア開発エンジニアです。AWS を活用し、Amazon の財務運営を支える大規模で信頼性の高い、イベント駆動型のデータサービスの設計と実装を主導してきました。仕事以外では、オンラインゲームのプレイヤーがゲームの腕を上げるのに役立つよう、プレイデータの分析と可視化に関するプロジェクトに取り組んでいます。

日本最大の “AWS を学ぶイベント” AWS Summit Japan が 6 月 25 日（水）、26 日（木）の二日間で開催されました。今年も業種ごとのブース展示の中で、建設・不動産業界向けのソリューション展示を行いました。大勢のお客様にご来場いただけましたこと、御礼申し上げます。「デジタルの力で、建設・不動産の”当たり前”を革新する」というタイトルで、生成AIの活用による業界課題の解決や業務効率化に向けて３つのソリューションを展示させていただきました。このBlogを通じて展示内容を改めてご紹介します。 生成 AI による書類審査業務の改善 AI 書類審査ソリューション – RAPID（Review & Assesment Powered by Intelligent Documentation） クリック すると説明資料を表示します。 不動産業界において「大量のドキュメント審査/レビューに時間がかかっている」という課題から生まれたソリューションです。ソリューションの開発中に他の業界でも同様の課題が存在することが分かりました。そのため、多くのお客様に試していただけるように AWS Samples でソースコードを公開しています。簡単にデプロイできますので、是非試してみてください！主な機能は以下の３つになります。 構想化されたチェックリストの作成と管理 生成 AI による書類審査のサポート AIによる判断根拠や信頼度を表示し透明性を確保 何らかのルールに基づいて申請書を人がレビューする業務は多いのではないでしょうか？生成　AI を利用して書類審査ができれば、業務負荷の低減や属人的な審査の削減につながるのでは？と期待を持たれる方もいらっしゃると思います。一方で、AIに審査を任せた場合には、精度、妥当性、説明責任などを担保する上での課題が生じます。このソリューションは、Human-in-the-Loop の考えに基づき、利便性と信頼性を両立させたものになっています。最初に審査ルールとなるドキュメントをアップロードすることで、AIがチェックリストを作成します。審査精度を高める工夫として作成されたチェックリストは構造化されており、必要に応じて人間が修正や追加をできるようにしています。次に審査対象のドキュメントをアップロードすることで、AIがチェックリストを参照し、ドキュメントを審査します。ここでは、審査結果に加えて判断根拠や信頼度が表示されるため、AI審査の透明性を確保することができます。他にも信頼度が低い結果だけをフィルタリングして効率的に確認したり、MCPを利用して外部ツールを参照し審査精度を高める機能なども実装されています。詳しくは、是非 AWS Samples にてご確認ください。 実際の画面サンプルやアーキテクチャは以下となります。(画像クリックで大きな画像を表示します） ハウスメーカーがお客様との商談結果を元に議事録を作成。その決定事項と案内しようとしている間取りの条件が合っているかを確認する例 「構造化されたチェックリスト作成」 〜 「書類審査の実行」 チェックリストをアップロードして構造化されたデータへ変換するフロー 書類の審査処理フロー 社内稟議書チェックのサンプル画面 社内稟議書サンプル アーキテクチャ図。AWS Lambda や AWS Step Functions といったサーバレスサービスを中心に構成されており、利用頻度に応じた課金体系が主体となっています。 RAPID Architecture 生成 AI による建設現場 映像活用の推進 生成 AI とカメラが描く建設現場のDX未来像 – CEDIX（Construction/Camera Edge Data/Device Intelligence X ) クリック すると説明資料を表示します。 生成 AI を利用して、建設現場に設置されたカメラの映像をより有効活用したいというニーズに応えるソリューションです。本ソリューションは以下のような特徴で現場カメラの映像活用を推進します。 多様なカメラの統合と映像データの一元管理 安価で拡張可能な保存先を提供 生成 AI 活用による高度な分析と自動化 建設現場では安全管理、防犯、遠隔臨場を目的に現場カメラの導入が進んでいます。一方で、「モニターに映った映像を常時確認するのではなく、何らかの問題が起きた場合だけ通知を受けたい」、「蓄積した映像データから新たな洞察を得たい」など、映像を活用して業務のあり方を変えたいという要望があるのではないでしょうか？また、現場に導入されるカメラのメーカーや仕様もバラバラで、それらを一元管理したいというニーズもあると思われます。CEDIX はカメラの仕様に応じた多様なインターフェースを提供し、収集した映像データを共通の仕組みで管理します。さらに、生成 AI を活用して映像データを分析することができます。例えば、安全管理の観点から、建機の近くに人が立ち入った場合にアラートを上げることができます。また、同じ安全管理の例でも、工事の進捗に応じて確認すべき観点は変わります。高所作業においては、ハーネスの未着用を検出することが必要になります。CEDIX はカメラごとにプロンプトで役割を指示できます。工程の進捗に応じて、「建機と人の位置から危険を判定」という指示から「ヘルメットやハーネスなどの個人用保護具の未着用による危険を判定」という様に柔軟に指示を追加・変更することができます。さらに蓄積された映像データを生成 AI で分析することで、事故につながる可能性のある危険な状況の件数など統計分析をおこないそれをレポートとして出力することが可能です。分かりやすい例として安全管理を挙げましたが、現場での整理整頓・施工状況の把握・ベテラン職人の視点を再現など、どのような指示を与えるかによって現場の QCDSE 向上に寄与できます。導入に向けた検討や発展的なユースケースの相談については、弊社営業担当もしくは AWS 問い合わせ窓口 へお問い合わせください。 実際の画面サンプルやアーキテクチャは以下となります。(画像クリックで大きな画像を表示します） カメラ管理の基本的な機能 – 設置場所別のカメラ一覧、最新映像をまとめてみるLiveビューイング、過去の時系列画像・映像及び生成 AI による検知内容の表示 カメラ管理の基本的な機能 事前設定された内容に加え、生成 AI によって設定されたタグも含めた検索、注意・確認が必要なシーンのブックマーク管理、生成 AI による自由度の高いレポート作成 画像・映像の検索、ブックマークからの一覧表示、レポート作成 カテゴライズ可能な生成 AI 自動タグの設定、カメラごとで組み合わせ可能な AI 検知設定、現場毎に検知したタグを可視化するインサイト分析、設定されたタグでシーンを絞り込める検索機能 生成 AI による自動タグ設定と活用シーン アーキテクチャ図。都度処理を行う部分は Amazon API Gateway や AWS Lambda といったサーバレスサービスを中心に構成。画像収集処理はリアルタイム性などの特性に応じてコンテナやサーバレスを活用 CEDIX Architecture 生成 AI による BIM データ活用 IFC With GraphRAG クリック すると説明資料を表示します。 生成 AI を利用することで、BIM（ Building Information Modeling ）データの活用を広げる方向性を提示するソリューションです。本ソリューションは以下のような機能を持っています。 IFC ( Industry Foundation Classes ) ファイルをAIが扱いやすい形式（RDF ( Resource Description Framework ) グラフ）に変換しグラフデータベースに格納 グラフデータベースに格納された建物の情報にチャットで問い合わせ 問い合わせ結果に関係するオブジェクトをブラウザベースのビューワー上にハイライトして表示 建設業界のデジタル変革が進む中で、BIM の導入が進んでいます。しかし、オペレーターの専門知識の習得に加え、BIM に持たせるべきデータの粒度や工程や企業を跨ったデータ連携の課題など、BIM の活用にはまだ多くの障壁がある状況です。本ソリューションは、生成 AI を利用して自然言語で BIM データ（IFC）にアクセスする機能を持っているため、BIM のソフトウェアライセンスを持たないユーザーや BIM に習熟していないユーザーに対するユースケースを広げることを目的にしています。チャットから「窓の数を教えて」と質問することでオブジェクトの数量を取得したり、「窓の熱貫流率を教えて」と質問することで素材・構造に関係する属性情報を取得したりすることができます。また対象のオブジェクトがビューワー上でハイライトされるため、問い合わせ結果に影響するオブジェクトを直感的に把握することができます。このソリューションを実現する技術的な方法はRAGに該当しますが、寸法や数量に関する情報を正確に取得するために、ナレッジベースにグラフデータベースを利用した GraphRAG を採用しています。IFC ファイルをアップロードするだけでデータベースへの格納まで実行されるので、 GraphRAG の専門知識がなくても始められるのも特徴です。導入に向けた検討や発展的なユースケースの相談については、弊社営業担当もしくは AWS 問い合わせ窓口へお問い合わせください。 実際の画面サンプルやアーキテクチャは以下となります。(画像クリックで大きな画像を表示します） 実装イメージ。IFC ファイルをグラフデータベースに変換・格納し、生成 AI を通じて自然言語で操作を可能にしています。 IFC With GraphRAG 説明 操作例１。オブジェクトを条件指定して簡単に検索したり、オブジェクトの情報を元に自然言語による質問へ回答が可能です。 IFC With GraphRAG Screenshot-1 操作例２。条件を絞らずにシンプルな質問でも回答が可能です。 IFC With GraphRAG Screenshot-2 アーキテクチャ図。IFC ファイルの変換は AWS Batch を中心としたバッチ処理で行います。グラフデータベースはマネージドサービスの Amazon Neptune Serverless を利用しています。 IFC With GraphRAG Architecture まとめ 今回のAWS Summit Japan 2025 建設・不動産向けブース展示では3つのソリューションと、建設不動産における AWS Marketplace のソリューションをご紹介させていただきました。様々な立場のお客様から強い関心とお困りごとについてのディスカッションをさせていただきました。改めて御礼申し上げます。これらの情報はソリューションへの反映等で活用させていただきます。 本ブログの内容や各展示内容の詳細についてご関心持たれましたら、 弊社営業担当もしくは AWS 問い合わせ窓口 へお問い合わせください。 本ブログは、ソリューションアーキテクト 伊藤が担当しました。

この記事は Streamline service-to-service communication during deployments with Amazon ECS Service Connect (記事公開日 : 2025 年 7 月 28 日) の翻訳です。 コンテナ化されたマイクロサービスをデプロイする際、更新中の信頼性の高いサービスディスカバリーと効率的なルーティングを維持することは大きな課題です。従来のブルー/グリーンデプロイアプローチは、トラフィック管理にロードバランサーを大きく依存しており、コンテナベースのサービス間通信を扱う場合に複雑になる可能性があります。この複雑さにより、サービス中断の可能性が高まり、本番トラフィックを新バージョンに向ける前に、新バージョンを分離環境でテストすることが困難になります。 Amazon Elastic Container Service (Amazon ECS) と Amazon ECS Service Connect を使用したブルー/グリーンデプロイの組み合わせは、これらの課題に対する直接的なソリューションを提供します。この統合により、共有名前空間内にテストトラフィックルーティング機能を導入することで、従来のブルー/グリーンデプロイモデルが強化されます。これにより、ほぼゼロのダウンタイムでマイクロサービスの新バージョンをデプロイし、分離環境で徹底的にテストし、必要に応じて迅速にロールバックする能力を維持できます。この記事では、コンテナ化されたアプリケーションのより効率的で回復力のあるデプロイプロセスを作成するために、この強力な組み合わせを実装する方法を説明します。 機能の概要 ブルー/グリーンデプロイは、2つの同一だが別個の環境を維持します：現在の本番バージョン用のブルー環境と新バージョン用のグリーン環境です。ローリングアップデートとは異なり、両方のバージョンが同時に実行され、それらの間でコントロールされたトラフィックシフトが行われ、迅速なロールバックとほぼゼロのダウンタイム移行が可能になります。 ECS Service Connect は、管理されたサービスディスカバリーと自動 サイドカープロキシインジェクション を通じてコンテナ化されたアプリケーション通信を効率化します。これにより、サービスは共有名前空間内で直接的な論理名を使用して簡単に相互を発見し通信できるようになります。 ブルー/グリーンデプロイと ECS Service Connect の組み合わせ は、組み込みのサービスディスカバリーと信頼性の高いルーティングを通じてトラフィック管理を強化します。これにより、チームは改善された信頼性と最小限のサービス中断でデプロイを行うことができます。 図1：ブルー/グリーンデプロイワークフローの Amazon ECS サービス状態 ブルー/グリーンデプロイプロセスは、上図に示すように、安全で制御された移行を支援するために設計された3つの明確な調整フェーズを通じて管理されます： 初期デプロイ状態： 両方の環境は展開されていますが、トラフィックはまだグリーンタスクにルーティングされていません。 進行中のデプロイ状態： テストトラフィックはブルータスクからグリーンタスクにルーティングされます。検証が成功すると、ECS Service Connect Proxy の自動構成変更により、本番トラフィックもグリーンタスクにルーティングされます。 最終的なデプロイ状態： 設定可能なベイク時間中は、必要に応じてすばやくロールバックできるように両方の環境がスケーリングされたままになります。 デプロイワークフローはライフサイクルステージによって管理されます。これはデプロイプロセスの正確なポイントであり、きめ細かい制御と検証を可能にします。各ステージは特定のデプロイイベント（例えば、 POST_TEST_TRAFFIC_SHIFT 、 PRE_PRODUCTION_TRAFFIC_SHIFT ）を表し、関連付けられたライフサイクルフックをトリガーすることができます。これらのフックは検証チェックやカスタムロジックを実行する AWS Lambda 関数です。 例えば、 POST_TEST_TRAFFIC_SHIFT フックは、全ての本番トラフィックを切り替える前にテストトラフィックをシミュレートすることでグリーン環境を検証できます。この検証プロセスは、各フェーズでの品質基準の適合を強制することでデプロイの信頼性を高め、サービス中断のリスクを最小限に抑えます。Amazon ECS ブルー/グリーンライフサイクルステージの詳細については、 AWS ドキュメント を参照してください。 ECS Service Connectによるブルー/グリーンデプロイの理解 ECS Service Connect は、Amazon ECS タスク内に組み込まれたルーティング機能を通じてバージョン移行を管理することで、ブルー/グリーンデプロイを効率化します。DNS 更新とロードバランサーの再構成が必要な従来のアプローチとは異なり、ECS Service Connect はサイドカープロキシを通じてルーティングを処理し、明確な移行を作成します。 ブルー/グリーンデプロイ中、ECS Service Connect はバージョン間の正確なトラフィック制御を可能にするヘッダーベースのルーティングメカニズムを採用します。アプリケーションコードは変更されないままで、インフラストラクチャがバージョンターゲティングを処理します。以下は、特定のヘッダー名（ $HEADER ）とヘッダー値（ $VALUE ）を持つ testTrafficRules を設定する方法の例です。 "serviceConnectConfiguration": { /* ... */ "testTrafficRules": { // グリーンデプロイへのテストトラフィックをルーティング "header": { // テストトラフィック用のヘッダーベースルーティング "name": "$HEADER", // カスタムヘッダー名 "value": { "exact": "$VALUE" // ヘッダー値の完全一致 } } } } 以下は POST_TEST_TRAFFIC_SHIFT ライフサイクルフックの設定例です。利用可能なライフサイクルステージの完全なリストは AWS ドキュメント で確認できます。 "deploymentConfiguration": { "strategy": "BLUE_GREEN", "bakeTimeInMinutes": 2, // ブルー環境の設定可能なベイク時間 "lifecycleHooks": [ // ライフサイクルフック設定 { "hookTargetArn": "$AWS_LAMBDA_FUNCTION", // AWS Lambda関数ARN "roleArn": "$ECS_LAMBDA_INVOKE_ROLE", // Lambda呼び出し用のロール "lifecycleStages": [ "POST_TEST_TRAFFIC_SHIFT" // ライフサイクルステージ ] } ] } ECS Service Connect は、アプリケーションコードをデプロイから分離するのに役立つ組み込みプロキシレイヤーを導入することで、デプロイの仕組みを変更します。開発者はデプロイの懸念事項なしに機能の構築に集中でき、運用チームはアプリケーションコードに触れることなく改善されたリリース戦略を実装できます。この分離により、チーム間で通常必要とされる調整が不要になり、コンテナ化されたアプリケーションのリリースプロセス全体が効率化されます。 ブルー/グリーンテスト戦略 ブルー/グリーンデプロイの重要なフェーズは、本番トラフィックを切り替える前にグリーン環境を検証することです。ECS Service Connect 内では、テストトラフィックは名前空間内でのみルーティングされるため、テストパターンを実装する際に慎重な検討が必要です。このセクションでは、2つの一般的なパターンを調査します： Application Load Balancer を通じたヘッダーベースのテスト ：このアプローチでは、 Application Load Balancer (ALB) のヘッダーパススルー機能を使用します。フロントエンドサービスは特定のヘッダーをバックエンドサービスに転送し、本番トラフィックを分離しながらロードバランサーを通じてグリーン環境を対象としたテストを可能にします。この方法は、トラフィックフローを制御し、サービスの動作を検証するための直接的なメカニズムを提供します。エンドユーザーにテストパスを公開しないようにするために、インターネットに公開されていない専用のロードバランサーを使用し、アプリケーション VPC 内に Lambda 関数をデプロイすることでこのソリューションを強化することをお勧めします。ウォークスルーセクションでは、基本的なヘッダーベースのルーティングアプローチを実装します。 図2：ALBワークフローを通じたヘッダーベースのテスト 専用テストサービスの実装 ：この方法では、名前空間内に専用のテストサービスをデプロイします。以下の図では、 POST_TEST_TRAFFIC_HOOK が名前空間内でテストヘッダーを使用してグリーンデプロイを検証するために Amazon ECS サービスをスケールアップします。テストの結果は Amazon S3 バケットに渡されます。関数内のロジックがこの結果を評価します。このアプローチは包括的な検証機能を提供しながら、アーキテクチャの整合性を維持します。ただし、より多くのAWSリソースが必要です。 図3：専用テストサービス実装ワークフロー これらの検証戦略により、ECS Service Connect のセキュリティと分離の利点を維持しながら、新しいバージョンの徹底的なテストが可能になり、信頼性の高いデプロイプロセスを確保します。 前提条件 このウォークスルーをデプロイするには、リソースを作成するための必要な権限を持つ AWS アカウントへのアクセス、 AWS Command Line Interface (AWS CLI) 、および AWS Cloud Development Kit (AWS CDK) が必要です。 また、AWS CLI のバージョン 2.27.51 以降が必要になります。AWS CLI の最新リリースについては、GitHub の AWS CLI version 2 Changelog を参照してください。 このウォークスルー全体を通じて、ECSクラスターと Amazon Virtual Private Cloud (Amazon VPC) にリソースをデプロイします。これらのステップバイステップのコード例は、サンプル GitHub リポジトリ 内のAWS CDK アプリで見つけることができます。 ウォークスルー ECS Service Connect とそのブルー/グリーンデプロイ戦略の核となるコンセプトを調査しました。実際の実装を通じてこれらの原則を実証できます。 このガイドでは、ECS Service Connect と AWS CLI を使用してブルー/グリーンデプロイでサンプルアプリケーションをデプロイする方法を示します。この設定は AWS CloudFormation 、 AWS Management Console 、または他の Infrastructure as Code（IaC）ツールを通じても実装できます。 1. 環境のセットアップ 環境セットアッププロセスには、必要な AWS インフラストラクチャのデプロイと初期サービスの設定が含まれます。必要なリソースを設定するために、これらの手順に従ってください： GitHub リポジトリをクローンします。 $ git clone https://github.com/aws-samples/sample-amazon-ecs-blue-green-deployment-patterns.git ライフサイクルフックとして設定される Lambda 関数をビルドします。 $ cd sample-amazon-ecs-blue-green-deployment-patterns/ecs-bluegreen-service-connect $ sh build-lambda-zip.sh AWS CDK を利用してコアインフラストラクチャをデプロイします。Amazon VPC、ALB、ECS クラスター、Lambda 関数、関連付けられる AWS Identity and Access Management (IAM) ロールを含むCloud Formation スタックを作成します。 $ npm install $ cdk bootstrap $ cdk deploy インフラストラクチャをデプロイした後、Cloud Formation スタックの出力から環境変数を設定します。 $ source load-env-variables.sh ECS サービスの初期バージョンのデプロイと必要なタスク定義を作成します。 $ sh demo-setup.sh demo-setup.sh スクリプトは、タスク定義とサービス設定のJSONファイルを含む出力ディレクトリを生成します。これらのファイルは、後続のデプロイ手順で使用されます。これらのファイルは、以下のセクションで使用されるブルー/グリーンデプロイ設定のテンプレートとして機能します。 2. 環境の確認 このデプロイは、以下のコンポーネントを持つ ECS Service Connect を使用したブルー/グリーンデプロイをサポートするアーキテクチャを作成します： ALB を主要なエントリポイントとして、外部トラフィックを管理し、 bluegreen-fronend サービスに分散します。 相互接続された2つの Amazon ECS サービス を備えた ECS クラスター ： bluegreen-frontend には、ALB からの受信リクエストを処理し、ヘッダーをそのまま転送する nginx ベースのリバースプロキシが含まれています。本番環境では、このフロントエンドサービスにはアプリケーションロジックが含まれますが、このウォークスルーでは簡単のためにただトラフィックを転送するのみです。 bluegreen-backend はリクエストを処理し、静的な HTML コンテンツを提供します。 ECS Service Connect は、サービスディスカバリーとコンポーネント間のルーティングを行います。 Lambda 関数 はライフサイクルフックを通じてデプロイ検証を実装します。この機能は POST_TEST_TRAFFIC_SHIFT の段階で起動し、テストトラフィックがグリーン環境にルーティングされるときに重要な検証を行い、デプロイの信頼性を高めます。 以下のアーキテクチャ図は、グリーンバージョンの bluegreen-backend サービスをデプロイする前の初期状態を示しています。 図4：グリーンバージョンのアプリケーションをデプロイする前の初期状態 デプロイプロセスでは、 POST_TEST_TRAFFIC_SHIFT ライフサイクルステージにおいて、Lambda 関数を使用してグリーン環境の検証を実装します。この関数は、指定されたテストヘッダー（ x-amzn-ecs-bluegreen-test:test ）を ALB エンドポイント（ $ALB_URL ）に送信することで検証を実行します。 検証結果に基づいて、Lambda 関数は以下の3つの可能な hookStatus 値のいずれかを返し、それぞれが特定のデプロイ動作をトリガーします： SUCCEEDED ：デプロイ開始を許可します FAILED ：ロールバックをトリガーします IN_PROGRESS ：追加の検証リクエストを試みます、試行間隔（デフォルトでは 30 秒）を空けてリトライします 以下の実装コードは、Lambda 関数の検証ロジックを示しています： import requests def lambda_handler(event, context): """ Tests blue/green deployment. """ try: response = requests.get( $ALB_URL, headers={"x-amzn-ecs-bluegreen-test": "test"}, timeout=5 ) if response.status_code == 200 and "Green Version" in response.text: return {"hookStatus": "SUCCEEDED"} else: return {"hookStatus": "FAILED"} except Exception as e: print(f"Error: {str(e)}") return {"hookStatus": "FAILED"} ベースラインアーキテクチャと検証メカニズムを確認しました。グリーンバージョンの実装のために bluegreen-backend サービスの更新を進めます。 3. バックエンドタスクをグリーンバージョンに更新する 環境が設定されたので、グリーンデプロイとして機能する bluegreen-backend サービスの更新バージョンを作成できます。この変更には、背景色をブルーからグリーンに変更する新しいタスク定義の登録が含まれます。新しい背景色によって、デプロイプロセス中のトラフィックルーティングの成功を視覚的に確認できます。 以前に環境セットアップフェーズで生成した JSON ファイルを使用して、新しいタスク定義を登録するために以下のコマンドを実行します： $ aws ecs register-task-definition \ --cli-input-json file://outputs/taskdef_backend_update.json 4. ブルー/グリーン戦略を使用してアプリケーションの新バージョンをデプロイする 新しいタスク定義が登録されたので、ECS Service Connect を使用してブルー/グリーンデプロイを実装できます。このセクションでは、制御されたテストと検証を可能にするテストトラフィックルールとライフサイクルフックのような必要なデプロイ設定パラメータを説明します。 デプロイには、新しいタスク定義と必要なトラフィックルーティングルール（ serviceConnectConfiguration と deploymentConfiguration ）の両方を組み込むために bluegreen-backend サービス設定を更新する必要があります。 serviceConnectConfiguration セクション ：デプロイプロセス中に正確なトラフィックルーティングを定義する testTrafficRules が必要です。これらのルールは、HTTP ヘッダーに基づいてどのリクエストをグリーン環境に向けるべきかを指定し、新バージョンの分離されたテストを可能にします。 "serviceConnectConfiguration": { ... "services": [{ ... "clientAliases": [{ ... "testTrafficRules": { "header": { "name": "x-amzn-ecs-bluegreen-test", "value": { "exact": "test" } } } }] }] }, deploymentConfiguration セクション ：適切な検証制御を持つブルー/グリーンデプロイ戦略を実装するために特定のパラメータが必要です。この設定は、Amazon ECS がデプロイプロセスを管理し、Lambda 関数統合によって各ステージで検証を実施する方法を定義します。 hookTargetArn は検証のための Lambda 関数を指定し、 roleArn は必要なIAM権限を提供し、 POST_TEST_TRAFFIC_SHIFT はデプロイ検証チェックが実行されるタイミングを定義します。 "deploymentConfiguration": { "strategy": "BLUE_GREEN", "bakeTimeInMinutes": 2, "lifecycleHooks": [{ "hookTargetArn": "arn:aws:lambda:us-west-2:1111111111:function:LifeCycleHook", "roleArn": "arn:aws:iam::1111111111:role/EcsLambdaInvokeRole", "lifecycleStages": [ "POST_TEST_TRAFFIC_SHIFT" ]} ] } グリーンバージョンの bluegreen-backend サービスをデプロイするために以下のコマンドを実行します。 $ aws ecs update-service \ --service bluegreen-backend \ --cli-input-json file://outputs/service_backend_update.json 5. デプロイプロセスの理解 ECS Service Connect を使用したブルー/グリーンデプロイ中、Amazon ECSは新しいグリーン環境タスクを作成することでプロセスを開始し、準備ができると POST_TEST_TRAFFIC_SHIFT ライフサイクルフックのタイミングでテストトラフィックが新しい環境に向けられます。検証プロセスでは、Lambda 関数によってテストヘッダーを持つリクエストが ALB に送信され、ALB はそれらのリクエストをフロントエンドサービスに転送し、ECS Service Connect はグリーンバックエンドへのルーティングを行います。デプロイの成功は Lambda 関数の検証結果に依存し、デプロイを進める（SUCCEEDED）かロールバックをトリガーする（FAILED）かが決まります。 図5：ECS Service Connect ブルー/グリーンデプロイステップ この検証メカニズムによって、本番トラフィックの移行が発生する前にグリーン環境が正しく動作していることを確認できます。デプロイプロセスの詳細な仕様と追加の設定オプションについては、 AWS ドキュメント を参照してください。 6. アプリケーションの新バージョンの検証 ブルー/グリーンデプロイが完了した後、以下のコマンドを実行して新しいグリーンバージョンが本番トラフィックを正常に処理していることを確認します： $ curl -s $ALB_DNS | grep "Green Version" このコマンドは（テストヘッダーなしで）ALBエンドポイントにリクエストを送信し、レスポンス内の「Green Version」テキストを検索します。成功したレスポンスは、本番トラフィックがグリーン環境によって提供されていることを示し、デプロイが正常に完了してトラフィック移行が期待通りに発生したことを確認します。 クリーンアップ このウォークスルーを完了した後、継続的な課金を防ぎ、整理されたAWS環境を維持するために、デプロイされたすべてのリソースをクリーンアップする必要があります。未使用のリソースを排除することで、予期しない料金が発生するのを防ぎ、AWS環境が整理された状態に保たれます。 実証セットアップで作成した全てのリソースを削除します。 $ sh demo-teardown.sh AWS CDK でデプロイされたインフラストラクチャコンポーネントを削除します。（削除に失敗した場合は、該当のリソースをコンソール等で削除してください。 $ cdk destroy タスク定義の Amazon Resource Names (ARNs) を取得します。 $ aws ecs list-task-definitions --family-prefix bluegreen-backend \ --query 'taskDefinitionArns[*]' $ aws ecs list-task-definitions --family-prefix bluegreen-frontend \ --query 'taskDefinitionArns[*]' $TASK_DEFINITION_ARN の値をステップ3のコマンドで抽出したARNで置き換え、Amazon ECS タスク定義を削除します。 $ aws ecs deregister-task-definition \ --task-definition $TASK_DEFINITION_ARN $ aws ecs delete-task-definitions \ --task-definitions $TASK_DEFINITION_ARN 結論 Amazon ECS Service Connect とブルー/グリーンデプロイの組み合わせは、サービスディスカバリーの効率化・分離テストの実現・ロールバック機能を備えた信頼性の高いトラフィック移行の提供、によってコンテナ化されたマイクロサービスのデプロイをモダナイズします。この機能がデプロイプロセスをどのように改善し、運用リスクを軽減できるかを楽しみにしています。この機能を Amazon ECS サービスで実装し、この機能をアプリケーションに統合する際のフィードバックを共有してください。詳細については、 AWS ドキュメント をご覧ください。 翻訳はソリューションアーキテクトの林が担当しました。原文は こちら です。