本投稿は AWSの Javeed Mohammed、 Rajib S Sarkar と Sumit Kumar による寄稿を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Db2 は、 マルチ AZ デプロイメント を通じて高可用性 (HA) を提供します。マルチ AZ が有効な場合、Amazon RDS は同じ AWS リージョン内にデータの冗長な同期レプリケーションされたスタンバイコピーを維持します。プライマリインスタンスに書き込まれたデータは、ブロックレベルのストレージレプリケーションを介してスタンバイインスタンスに同期的にレプリケーションされます。プライマリインスタンスに問題が発生した場合、Amazon RDS は自動的にスタンバイに切り替わり (通常 60 秒以内)、データの可用性を継続的に確保します。自動フェイルオーバーが発生した場合でも、アプリケーションは裏側で何が起きているかを知る必要はありません。DB インスタンスの CNAME レコードは、新しく昇格したスタンバイを指すように変更されます。エンドポイントは同じままですが、DB インスタンスへの既存の接続を再確立する必要があります。プライマリインスタンスとスタンバイインスタンスは、同一リージョン内の異なるアベイラビリティーゾーンに配置されており、そのためマルチ AZ と呼ばれています。この分離により、両方のインスタンスが同じ障害の影響を受ける可能性が大幅に低減されます。マルチ AZ デプロイメントは RDS DB インスタンスの可用性と耐久性を向上させ、本番環境のワークロードに理想的な選択肢となります。 多くのエンタープライズのお客様にとって、ビジネス継続性を確保するために本番環境を予期せぬ障害から保護することは重要な要件となっています。Amazon RDS は耐障害性の高いマルチ AZ 構成を提供していますが、自然災害、悪意のあるイベント、データベースの破損、ワークロードが劣化状態で動作する原因となるイベントなど、全ての潜在的なリスクを防ぐことができるわけではありません。別のリージョンで実行することが、有効な対策の 1 つとなります。業務を継続的に運用するためには、包括的な災害対策 (DR) 計画を策定し、検証することが不可欠です。このような要件においてはは、別のリージョンへのデータ保存とダウンタイムの削減が必要になるため、RDS for Db2 のスタンバイレプリカ機能が重要になります。この機能により、別の AWS リージョンにデータベースのスタンバイレプリカを維持することができ、リージョン内のマルチ AZ 構成を超えた冗長性の追加レイヤーを提供します。 あるリージョンのデータベースが利用できなくなった場合、データベースのバックアップの復元を待つことなく、別のリージョンのスタンバイレプリカをすぐに昇格させて運用を再開できます。 マルチ AZ 配置とクロスリージョンのスタンバイレプリカを組み合わせることで、高可用性と災害対策のための包括的な対策を提供し、Db2 ワークロードの回復性と応答性を維持し、ミッションクリティカルな要件に対応できます。 詳細については、 Working with replicas for Amazon RDS for Db2 をご参照ください。 この投稿では、RDS for Db2 インスタンスのスタンバイレプリカを構成する方法をご紹介します。 また、スタンバイレプリカのセットアップ、モニタリング、管理に関するベストプラクティスについても説明します。 この機能を使用することで、RDS for Db2 インスタンスを設定して、別のリージョンにスタンバイレプリカを保持することができます。 Amazon RDS は、プライマリからスタンバイレプリカへの変更を自動的に非同期でレプリケートします。 プライマリインスタンスが利用できなくなった場合、1 回の API 呼び出しでスタンバイをスタンドアロンインスタンス (新しいプライマリとして機能) に昇格させることができ、読み取りと書き込みの操作を即座に再開できます。 これにより、災害復旧時のダウンタイムが大幅に削減され、ミッションクリティカルなワークロードに対する追加の耐障害性レイヤーが提供されます。 このクロスリージョンのスタンバイレプリカ機能により、以下が可能になります: 別のリージョンまたはアベイラビリティーゾーンへの非同期データレプリケーション 災害復旧時のスタンバイからプライマリへのシームレスな昇格 目標復旧ポイント (RPO) は通常数秒以内 目標復旧時間 (RTO) は通常数分以内 従来のバックアップおよび復元方式と比較して、より迅速な災害復旧 スタンバイレプリカは、プライマリデータベースの物理コピーであり、IBM Db2 の High Availability Disaster Recovery (HADR) 機能を使用して、 SUPERASYNC モードでプライマリとスタンバイレプリカ間のレプリケーションを行います。 RDS for Db2 のスタンバイレプリカデータベースは、プライマリで生成されスタンバイ DB インスタンスに送信されるログデータを通じて、プライマリデータベースと同期されます。スタンバイデータベースは、常にログを適用して更新を行います。 スタンバイ という用語は、明示的にスタンドアロンのプライマリインスタンスに昇格されない限り、読み取りや書き込み操作に使用できないことを示しています。 DB インスタンスに対して、プライマリと同じリージョン内または異なるリージョンに、最大 3 つのスタンバイレプリカを作成できます。 スタンバイレプリカは昇格されるまで操作できないため、インスタンスサイズに関係なく、レプリカごとに 2 vCPU 分の商用データベースライセンスのみが必要です。（訳注：BYOSLに関するIBMのサイトは こちら です） Db2 Advanced Edition (AE) と Standard Edition (SE) の両方で、Bring Your Own License (BYOL) モデルと AWS Marketplace を通じた Db2 ライセンスモデルの両方において、スタンバイ用のレプリカを作成できます。 Db2 11.5 バージョンはレプリカ DB インスタンスをサポートしています。 次の表は、Amazon RDS for Db2 の各種 HA および DR 機能で達成可能な RPO および RTO メトリクスを示しています。 機能 RPO (概算) RTO (概算) Amazon RDS マルチ AZ 0 1 ～ 2 分 Amazon RDS for Db2 スタンバイレプリカ (リージョン内/リージョン間) 秒単位 分単位 リージョン内の自動バックアップを使用した PITR 5 分 数時間程度 リージョン間の自動バックアップを使用した PITR 25 分 数時間程度 ソリューションの概要 以下の図は、RDS for Db2 のスタンバイレプリカを使用するアーキテクチャを示しています。 DR 状況において 障害復旧の実装 が必要な場合、RDS for Db2 のスタンバイレプリカインスタンスをスタンドアロン (新しいプライマリとして機能) インスタンスに昇格させることができます。 次の図は、レプリカ昇格後の構成を示しています。 この投稿では、US East (N. Virginia) リージョン ( us-east-1 ) にデプロイされたプライマリの RDS for Db2 インスタンスを使用します。 US East (Ohio) リージョン ( us-east-2 ) にスタンバイレプリカを構成する手順について説明します。 前提条件 このブログの手順に従うには、以下の前提条件が必要です。 プライマリ RDS for Db2 インスタンスが必要です (この投稿では、インスタンスは rds-db2-primary という名前で、 us-east-1 にデプロイされています)。 ターゲット (セカンダリ) リージョン (この場合は us-east-2 ) で設定されたカスタム RDS パラメータグループを使用する必要があります。詳細については、 Amazon RDS のパラメータグループ を参照してください。クロスリージョンのスタンバイレプリカのパラメータグループは、プライマリ RDS for Db2 インスタンスとは異なる値を持つことができます。ただし、BYOL ライセンスモデルでは、 customer_id と site_id は引き続き必要であり、セカンダリリージョンのパラメータグループで更新する必要があります。 ソースデータベースが AWS Key Management Service (AWS KMS) の マルチリージョンキー を使用して暗号化されている場合、同じキーを使用してスタンバイレプリカを作成できます。そうでない場合は、セカンダリリージョンで 新しい KMS キーを作成 する必要があります。 レプリカを作成する前に、 データベースの作成、削除、復元、ロールフォワード のための組み込みの rdsadmin ストアドプロシージャを、プライマリ RDS for Db2 DB インスタンスで完了しておく必要があります。 プライマリインスタンスで複数のデータベース を設定している場合、スタンバイレプリカ作成後は、プライマリ RDS for Db2 インスタンスに追加のデータベースを追加できないことに注意してください。データベースを追加するには、まずスタンバイレプリカを削除し、必要に応じてプライマリインスタンスに追加のデータベースを作成してから、スタンバイレプリカを再作成する必要があります。作業を進める前に、プライマリ RDS for Db2 インスタンスに必要なデータベースを作成しておいてください。プライマリインスタンス上のすべてのデータベースは アクティブな状態 である必要があります。 ソース DB インスタンスで 自動バックアップを有効にする 必要があります。 前提条件の詳細については、 RDS for Db2 レプリカの要件と考慮事項 を参照してください。 RDS for Db2 レプリカに関する重要な考慮事項 RDS for Db2 はローカルユーザーをレプリカに複製しますが、マスターユーザーは複製しません。レプリカ上でマスターユーザーを変更することができます。詳細については、 Amazon RDS DB インスタンスの変更 をご参照ください。 RDS for Db2 はデータベース設定をレプリカに複製します。 RDS for Db2 は以下の項目を複製しません： ストレージアクセス。外部テーブルなど、ストレージアクセスに依存するデータに注意してください。 非インライン LOB。 外部ストアドプロシージャ（ C 言語または Java ）のバイナリ。 レプリケーションは LOAD コマンドをサポートしていません。ソース DB インスタンスで LOAD コマンドを実行すると、データはリカバリ不可能モードでロードされます。つまり、データはスタンバイレプリカに複製されません。 Amazon RDS for Db2 でレプリカが作成されると、データベースレベルのパラメータ BLOCKNONLOGGED と LOGINDEXBUILD がプライマリインスタンスで自動的に YES に設定されます。これにより、すべての操作とインデックスの構築がレプリケーションのために完全にログに記録されます。スタンバイレプリカがスタンドアロンインスタンス（レプリカの昇格）になると、Amazon RDS はプライマリインスタンスの値を NO に戻します。 レプリケーションは、RDS for Db2 プライマリ DB インスタンス上のすべてのデータベースに対して Db2 HADR を使用します。 RDS for Db2 のスタンバイレプリカの作成 ソースの RDS for Db2 DB インスタンスからスタンバイレプリカを作成するには、以下の手順を実行します： Amazon RDS コンソールのナビゲーションペインで、 Databases を選択します。 スタンバイレプリカのソースとして使用する RDS for Db2 DB インスタンスを選択します。 Actions ドロップダウンメニューから、 Create replica を選択します。 Replica mode で、 Standby を選択します。 DB instance identifier に、リードレプリカの名前を入力します。 Regions で、スタンバイレプリカを起動するリージョンを選択します。 インスタンスサイズとストレージタイプを選択します。 Multi-AZ deployment で、レプリカのスタンバイインスタンスを作成する場合は、 Create a standby instance を選択します。これにより、別のアベイラビリティーゾーンにスタンバイレプリカのフェイルオーバー用インスタンスが作成されます（オプション）。 その他の設定を必要に応じて選択します。 Create replica を選択します。 ターゲットリージョンの**Databases**ページで、スタンバイレプリカのロールは**Replica**となっています。 プライマリの RDS for Db2 インスタンスの Connectivity & Security タブにある Replication セクションで、レプリカの設定詳細を確認することもできます。 または、以下の AWS Command Line Interface (AWS CLI) コマンドを使用して、RDS for Db2 のスタンバイレプリカを作成することもできます。 aws rds create-db-instance-read-replica \ --db-instance-identifier <name of replica instance> \ --source-db-instance-identifier arn:aws:rds: <source DB region> : <accountnumber> :db:rds-db2-primary \ --db-parameter-group-name <name of parameter group in DR region> \ --replica-mode mounted \ --kms-key-id <KMS Key> \ --region <DR region> RDS for Db2 スタンバイレプリカの昇格 プライマリ DB インスタンスが利用できなくなった場合、スタンバイレプリカをスタンドアロンインスタンスに昇格させ、読み取りと書き込みの操作を再開することができます。 スタンバイレプリカの昇格が開始されると、RDS はアーカイブログから保留中のトランザクションを適用し、スタンバイレプリカをアクティブな状態に移行し、昇格したインスタンスで読み取り/書き込み機能を有効にします。このプロセスでは、プライマリデータベースからスタンバイレプリカへの非同期データレプリケーションが行われることを理解することが重要です。そのため、プライマリデータベースとスタンバイレプリカ間のレプリケーションの遅延に応じてデータ損失が発生する可能性があります。 潜在的なデータの不一致を最小限に抑えるため、レプリカの昇格を開始する前に、このブログ投稿のベストプラクティスセクションで説明されているように、レプリケーションの遅延を確認することを強く推奨します。この遅延を慎重に監視し、その影響を理解することで、災害復旧シナリオにおいて適切な判断を下し、昇格したスタンバイインスタンスで最適なデータ整合性を確保することができます。 RDS for Db2 のスタンバイレプリカを昇格させるには Amazon RDS コンソールのナビゲーションペインで、 Databases を選択します。 ソースとなる RDS for Db2 DB インスタンスを選択します。 スタンバイレプリカを選択します。 Actions ドロップダウンメニューから、 Promote を選択します。 または、以下の AWS CLI コマンドを使用することもできます: aws rds promote-read-replica \ --db-instance-identifier <name of the replica instance> \ --region <DR region> 昇格後の RDS for Db2 スタンバイレプリカに接続します: db2 catalog TCPIP node <node_name> remote <dns_name> server <port> db2 catalog database <database_name> as <dbalias-name> at node <node_name> db2 connect to <database_name> user <master_username> using <master_password> ベストプラクティス このソリューションを実装する際は、以下のベストプラクティスを考慮してください。 パフォーマンスの問題やレプリケーションの遅延を避けるため、一般的に RDS for Db2 のスタンバイレプリカは、プライマリインスタンスと同じインスタンスタイプとサイズで構成することをお勧めします。ただし、インフラストラクチャのコストを最適化するために、スタンバイレプリカに異なるインスタンスタイプとサイズを選択することも可能です。 RDS for Db2 のスタンバイレプリカのバージョンは、プライマリインスタンスのバージョンと同じか、それ以上である必要があります。マイナーバージョンの手動アップグレードを実行する場合は、プライマリインスタンスをアップグレードする前にレプリカインスタンスをアップグレードする必要があります。 Amazon RDS の ReplicaLag メトリクスを Amazon CloudWatch で確認し、レプリケーションの遅延を監視することをお勧めします。レプリケーションの遅延時間の詳細については、 リードレプリケーションのモニタリング および Amazon RDS の Amazon CloudWatch メトリクス をご参照ください。 ReplicaLag メトリクスは、遅延が発生しているデータベースの最大遅延を秒単位で示します。レプリケーションの問題のモニタリングとトラブルシューティングの詳細については、 RDS for Db2 レプリケーションの問題のトラブルシューティング をご参照ください。 ビジネス要件に基づいて、ReplicaLag が定義されたしきい値を超えた場合に通知を受け取るように CloudWatch アラーム を設定できます。 プライマリの RDS for Db2 インスタンスがマルチ AZ で構成され、自動バックアップが有効になっている場合、これらの設定をスタンバイレプリカでも有効にできます。これにより、スタンバイはプライマリインスタンスと同じ構成を維持し、DR シナリオ発生時にスムーズで迅速な移行が可能になります。昇格後は、これらの設定を個別に構成する必要なく、昇格されたインスタンスに接続できます。 昇格時に予期しない動作を避けるため、プライマリインスタンスとスタンバイインスタンスの両方で、同じまたは互換性のある DB パラメータグループとオプショングループを使用してください。 RDS for Db2 レプリカインスタンスのバックアップを作成および復元できます。RDS for Db2 スタンバイレプリカは、自動バックアップと手動スナップショットの両方をサポートしています。RDS for Db2 レプリカは、デフォルトでは自動バックアップが有効になっていません。バックアップ保持期間を 0 より大きい値に設定することで、自動バックアップを有効にできます。RDS for Db2 スタンバイレプリカで自動バックアップを有効にすることで、ポイントインタイムリストアを含む完全な復旧機能を備えた状態で昇格できます。これは、災害復旧、コンプライアンス、必要に応じたスタンドアロンインスタンスへのスムーズな移行に重要です。詳細については、 Working with RDS for Db2 replica backups を参照してください。 アプリケーションエンドポイントを変更せずにトラフィックルーティングの自動化を実装する方法については、 Orchestrate disaster recovery automation using Amazon Route 53 ARC and AWS Step Functions を参照してください。 リソースの削除 RDS for Db2 のスタンバイレプリカを削除するには。 Amazon RDS コンソールのナビゲーションペインで、 Databases を選択します。 ソースとなる RDS for Db2 DB インスタンスを選択します。 スタンバイレプリカを選択します。 アクション ドロップダウンメニューから、 削除 を選択します。 RDS for Db2 のスタンバイレプリカを削除するには、以下の AWS CLI コマンドを使用します: aws rds delete-db-instance --db-instance-identifier <replicaname> \ --skip-final-snapshot | --no-skip-final-snapshot \ --final-db-snapshot-identifier <value> \ --delete-automated-backups | --no-delete-automated-backups \ --region <region> まとめ RDS for Db2 のクロスリージョンスタンバイレプリカを構成することで、可用性と災害対策の両方を強化できます。 セットアップと暗号化に関するベストプラクティスに従うことで、スムーズなフェイルオーバーを実現できます。 このセットアップにより、予期せぬ事態が発生した場合でも、最小限の中断で業務の継続性を維持できます。 この解決策をご自身のユースケースで試していただき、コメントでフィードバックをお寄せください。 翻訳はソリューションアーキテクトの山根 英彦が担当しました。原文は こちら です。 著者について Javeed Mohammed Javeed は AWS のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームに所属し、Oracle や Db2 などの商用データベースエンジンを担当しています。お客様と協力して AWS クラウド上でリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援することに情熱を注いでいます。 Rajib S Sarkar Rajib は Amazon RDS for Db2 のシニア DBE です。20 年以上にわたるソースコードレベルの専門知識を持つ経験豊富な IBM Db2 LUW エキスパートです。技術的な専門性と文学やアウトドア活動への情熱をバランスよく持ち合わせています。データベースの複雑な作業から離れると、良書に没頭したり、クリケットやハイキングを楽しんだりしています。 Sumit Kumar Sumit は AWS のシニアソリューションアーキテクトで、複雑な問題を解決することを得意としています。様々な業界のお客様の AWS クラウド上でのワークロード構築と設計を支援しています。

本ブログは株式会社アイデミー様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です 。 昨今、従来の事業や顧客の課題に関連して、新しくSaaSを開発する企業が増加してきております。SaaS事業を始める為には、市況の変化に応じる為にスピーディー且つ効率良く開発する必要があります。 本記事では、AWSのマネージドサービスを活用し、少人数且つ短期間でマルチテナント型SaaS環境を構築した事例について紹介いたします。 ①お客様の状況と検証に至る経緯 アイデミー様は、AI/DXの人材育成から実運用まで、企業変革の基盤となるDX推進を一気通貫で支援する企業です。 今回ご紹介する「 Lab Bank 」は、Aidemy Solutions(*)が展開するSaaSのひとつです。 研究開発部門のDXを支援する中で、研究データが分散管理されて知見が活用されにくいことや、レポート作成などの付随業務が研究者の負担となっていること、更に過去データの活用不足による実験の非効率性とコスト増大といった課題を発見しました。 *)Aidemy Solutionsは、スモールスタートと社内のAIキーパーソン育成を軸に、企業の現場で活用されるAIの開発・実装を支援する法人向けDX支援サービスです。  これらのデータ基盤を整備し迅速な知見共有を実現するSaaSを開発する必要がありました。 しかし、機密性の高い研究データを扱う為、セキュアな環境を構築する必要性や少人数の自社開発体制におけるリソース制約の問題も抱えていました。 ②ソリューション 研究開発組織が研究にフォーカスする為のデータ活用プラットフォームSaaS をAWS上で構築しました。 研究データを外部DBに保管できない顧客向け環境はこちら Amazon Elastic Container Service (Amazon ECS) と Application Load Balancer を組み合わせてマルチテナント環境を一元管理。 Amazon Aurora for PostgreSQL のRow Level Securityを活用してテナント分離を実装しました。 さらに AWS WAF によるテナント単位のアクセス制限を設定することで、セキュアな運用を実現しています。 ③導入効果 マルチテナント化、サーバーレス構成、マネージドサービスの活用により、コストと運用面での導入障壁を低減しています。 マネージドサービスを活用したことで、少人数の2名の開発チームでも3週間という短期間でインフラ環境を構築することに成功しています。 さらに、機密性の高い研究データを安全に共有できるセキュアな基盤を構築出来ました。 アイデミーの石橋和也氏は「AWSのセキュリティベストプラクティスやサーバーレス/マネージドサービスを活用したことで、少人数の開発チームでも短期間でセキュアな環境を構築することができました」と述べています。 ④今後の展望 これまでの知見を活かし、研究開発（R&D）以外（調達、製造、品質管理、規制対応、顧客対応等）のデータに対しても、 生成AI・機械学習を活用し連携することで、意思決定・実験効率および品質向上を推進していきます。 株式会社アイデミー : 土屋 大地様 （左から 2 番目） 、諸山 将梧様（中央）、石橋 和也様（右から2番目） Amazon Web Services Japan : アカウントマネージャー 藤川 高志朗（左端）、ソリューションアーキテクト 呉 敏禎（右端）

本ブログは株式会社ウィンシステム様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの塩見です 。 昨今、多くのお客様から生成 AI の活用についてご相談いただくようになりました。特にシステム開発事業者様や SaaS 事業者様においては、システム開発に生成 AI を活用することで開発生産性を向上させる取り組みに注目されています。 株式会社ウィンシステム様は、旅行会社向けシステム開発や、企業の出張管理などを主な利用シーンとした自社プロダクト「 Travel Studio 」の開発を主力事業としている企業です。今回は、同社が Amazon Bedrock と AI コーディングエージェント（ Cline ）を組み合わせることで実現した、劇的な開発生産性の向上についてご紹介します。 課題：非効率的な内部業務 ウィンシステム様の社内管理ツールは古く、特定の担当者に依存した Excel 管理などの運用も続けていました。企業成長に伴い業務が複雑化したことで、従来の管理方法では効率が悪く、社内統制も困難な状況となっていました。 内部業務の Web アプリ化による効率化が急務である一方で、顧客向け開発案件へ戦略的に開発リソースを投入する必要がありました。そのため、内部業務の Web アプリ化は最小限の工数で進めるアプローチが求められていました。 解決策と導入効果：AI コーディングエージェントにより開発工数を抑えた内部業務改善の実現 これらの課題に対し、 AI コーディングエージェントの導入により、従来の開発プロセスにおける工数削減を実現しつつ、管理ツールの Webアプリケーション化にチャレンジしました。具体的には、 AI コーディングエージェント と Amazon Bedrock （ Claude 3.7 Sonnet ）を組み合わせた AI 開発環境を構築しています。 AI コーディングエージェントには Cline を利用しています。Cline は、Visual Studio Code で動作する AI 搭載のコーディングアシスタントです。AI によるコード生成を行うだけでなく、プロジェクトの計画段階からコードのテストまで、包括的にサポートします。 上記開発環境により工数削減を実現しながら、企業レベルでの AI 活用における情報セキュリティ要件を Amazon Bedrock で実現しました。以下の導入効果が得られています。 1営業日で Web アプリケーション版の管理ツールが完成 従来手法では技術調査を含め10営業日を要する工程を1営業日で完遂（開発生産性が10倍に向上） 認証機能の実装やアプリケーションに関するドキュメント作成も AI コーディングエージェントが実施 通常なら後回しになりがちなドキュメント作成まで AI コーディングエージェントが自動で行ってくれたおかげで、属人化のリスクなく、早期運用開始を実現 またそのほか以下のような開発でも AI 開発環境を活用し、開発生産性向上ならびに企業価値向上に努めています。 営業提案の高速化 お客様への提案用プロトタイプを数時間で作成し、商談のスピードアップを実現 既存システムの品質向上 マスター画面の自動生成やコードのリファクタリングにより、保守性が改善 グローバル展開の加速 既存サイトの多言語化を短期間で完了 お客様の声 ウィンシステム様 システム部エンジニアの髙橋隼人様は次のように評価されています。 「技術的に実現可能であると分かっていても、実際に開発するには技術調査等で想像以上に時間がかかります。AI コーディングエージェントを活用することで開発生産性は大幅に向上します。また、LLM プロバイダーとして Amazon Bedrock を利用することデータプライバシーやガバナンスを効かせながら開発できます。」 今後の展望 更なる開発生産性向上を目指しつつ、効率的に AI コーディングエージェントを活用するため、次の項目を検討予定です。 バッチ処理など、ロジックは単純だが記述量が多く開発者が敬遠しがちな処理の実装にも活用を拡大 利用者のトークン利用量に応じた最適な AI コーディングエージェントの選定（従量課金制と定額課金制の最適なバランスの模索） プロジェクト固有の制約や自社のコーディング規約などを整理したドキュメントを用意し、AI コーディングエージェントに参照させる仕組みの確立 本事例は、 AI コーディングエージェントを効果的に活用することで、限られたリソースの中でも大幅な生産性向上を実現できることを示しています。特に、Amazon Bedrock のセキュアな環境と、 AI コーディングエージェントの柔軟性を組み合わせることで、企業の開発現場における実践的な AI 活用の好例となっています。

この記事は、2025 年 7 月 22 日に Chester Manuel によって執筆された「 Transform your Machine Learning career through AWS Jam 」を翻訳したものです。 理論的な 機械学習 (ML) 知識に加えて、雇用主が積極的に求めている実践的なスキルを身につける準備はできていますか ? ML エンジニア、DevOps 専門家、開発者のいずれであっても、身につけた知識を本番対応のソリューションに変えるには、ハンズオン体験が必要です。 ここで AWS Jam の出番です。集中的なクラスルームトレーニングとゲーム化されたハンズオンチャレンジを組み合わせることで、AWS Jam は ML ソリューションを大規模に実装するために必要となる実践的な経験を提供します。本番と同様のツールを使用し、実世界のシナリオに取り組み、実際のビジネス環境で ML ソリューションをデプロイする能力に自信をつけます。 このブログでは、構造化された学習と実践的な応用のユニークな組み合わせを通じて、AWS Jam があなたの ML エンジニアリング能力をどのように変革できるかを紹介します。2 つの柔軟な学習パスを発見し、取り組む 8 つの実世界のチャレンジを理解し、Jam 体験が ML エンジニアリングでのキャリア成長をどのように加速できるかを学びます。 AWS Jam の紹介 AWS Jam は、参加者が AWS マネジメントコンソール などからアクセスするサンドボックス環境内で、シミュレートされた実世界のシナリオに没頭するクラウド学習への革新的なアプローチを提供します。様々な AWS サービスを使用して終わりのない問題を解決することで、実践的な Amazon Web Services (AWS) スキルを習得するのに役立つように設計されています。各チャレンジ中、探究と実験を繰り返しながら、困難な問題を解決できるヒントにアクセスできます。 AWS Jam の体験は、安全にテストされたソリューションと、結果から学ぶことができる制御された環境で行われます。このハンズオンアプローチは、理論的知識と実践的応用の間のギャップを埋めるのに役立ち、AWS ソリューションの実装に自信をつけることができます。また、ポイントとリーダーボードを含む競争要素は、知識の定着と問題解決スキルを向上させる魅力的な学習環境を作り出します。 ML 専門家への 2 つの学習パス 私たちは異なる専門家が異なる学習ニーズを持っていることを理解しています。そのため、2 つの異なる AWS Jam 体験を提供しています。 Machine Learning Engineering on AWS with AWS Jam は、3日間のインストラクター主導トレーニングと AWS Jam チャレンジに専念する4日目を組み合わせた包括的な学習機会を提供します。トレーニング部分では、ML エンジニアリングの実践と AWS サービスの強固な基盤を構築します。Jam では、この知識を実践的なシナリオで即座に適用し、ハンズオンによる課題解決を通じて学習効果を最大化します。 すでに十分な ML 基礎知識を持つ専門家の方向けには、AWS Jam – Machine Learning Engineering on AWS を 1 日のトレーニングコースとしても提供しています。この集中的な形式は純粋にハンズオンチャレンジに焦点を当て、実践的な応用を通じて既存の知識を検証し、拡張できます。 実環境をシミュレートした 8 つの Jam チャレンジ AWS Jam 中に参加者が取り組む 8 つのチャレンジを紹介します (2025 年 8 月時点) : チャレンジ 1 – LLM ファインチューニングチャレンジは、 大規模言語モデル (LLM) のデプロイとカスタマイズが参加者に求めらます。 Amazon SageMaker ノートブックと AWS Lambda 関数を使用して、エンジニアは特定のビジネスニーズに向けた AI モデルのカスタマイズに直接適用されるモデル最適化のベストプラクティスを学びます。 チャレンジ 2 – ML パイプライン自動化チャレンジでは、参加者は SageMaker でエンドツーエンド ML パイプラインを構築します。モデルトレーニングと評価プロセスを自動化し、スケーラブルで再現可能な ML プロセスを作成するモデル登録ワークフローを実装することを学びます。 チャレンジ 3 – データラングリングマスタリーチャレンジは、顧客満足度 (CSAT) データ処理のための Amazon SageMaker Data Wrangler の使用に焦点を当てています。参加者は欠損データと外れ値を処理し、データ変換パイプラインを実装します。分析のための顧客フィードバックデータの準備に不可欠なスキルです。 チャレンジ 4 – A/B テスト実装チャレンジでは、エンジニアは SageMaker で A/B テストを設計し、実行します。テスト結果を分析し、データ駆動の決定を行い、モデルパフォーマンスを最適化するための統計的有意性測定を実装します。 チャレンジ 5 – 予測分析チャレンジは、結果を予測するモデルの構築を含みます。参加者はSageMaker エンドポイントを使用してモデルをデプロイし、監視とログ記録を実装し、リアルタイム決定のための予測システムの作成経験を積みます。 チャレンジ 6 – 責任ある AI 実装チャレンジでは、参加者はバイアス検出と軽減を実装しながら信用リスク予測モデルを開発します。このチャレンジは金融サービスにおける倫理的 AI システムの構築を強調し、モデルの公平性と透明性を確保します。 チャレンジ 7 – 従業員定着モデリングチャレンジは、参加者に XGBoost を使用した離職予測モデルの作成を課します。人事 (HR) データの特徴エンジニアリングを実装し、リアルタイム予測のためのモデルをデプロイし、ML で HR 意思決定をサポートします。 チャレンジ 8 – ノーコード ML 開発チャレンジは、モデル作成のための Amazon SageMaker Canvas を紹介します。参加者はコーディングなしで ML ソリューションを実装し、チーム間でモデルを共有およびデプロイする方法を学び、組織全体での ML の民主化をサポートします。 競争を通じた学習効果 AWS Jam の特徴的な部分として、チームベース環境で実世界シナリオへ挑戦する点があります。各チャレンジに取り組む際、安全で制御された環境で AWS ベストプラクティスを適用します。このアプローチにより、開発するスキルが ML エンジニアとしての日常業務に直接還元されることを保証します。チームベース形式は、専門的環境で不可欠なスキルである協力と知識共有を促します。 AWS Jam を完了すると、本番同様の ML ツールのハンズオン体験と実践的な課題解決スキルが身につきます。AWS の ML サービスとベストプラクティスの高い親和性、そして大規模に ML ソリューションを実装する自信を得ます。この実践的な経験は、実世界のシナリオへの転用と組み合わされて、ML エンジニアで雇用主が求める価値ある専門知識を提供します。 次のステップ ML エンジニアリングキャリアを向上させる準備はできましたか ? Machine Learning Engineering on AWS の今後のクラス日程を確認し、次のクラスに今すぐ登録して時間を確保してください。AWS Jam でのハンズオン体験を通じて未来を築いている ML エンジニアの成長するコミュニティに参加してください。 さらに、コース更新情報については AWSトレーニングと認定ブログ をフォローし、最新のトレーニング提供については AWS Skill Builder を確認してください。 翻訳は Technical Instructor の 西村 諄 が担当しました。

2025 年 8 月 22 日、AWS Startup Loft Tokyo にて「AWS JumpStart Zero For FSI」を開催いたしました。本イベントは、金融業界の若手エンジニアの方に AWS JumpStart 本編への準備を含めてクラウド利活用のはじめの一歩を踏み出していただくことを目標に開催し、20社を超える金融機関から 80 名以上の方にご参加いただきました。本記事では、イベントのハイライトと参加されたエンジニアの皆様の声をお届けします。 本イベントは、AWS JumpStart への参加を検討中の金融エンジニアの方を対象に、AWS JumpStart へのステップとなる知識を獲得できる準備イベントとして開催しました。AWS JumpStart にご興味のある方は こちらのブログ よりお申し込みください。 AWS 目黒オフィスにお越しいただいた様子 イベント概要 開催日時： 2025 年 8 月 22 日（木） 14:00–18:00 会場： AWS Startup Loft Tokyo 参加者数： 84 名（金融機関の若手エンジニア） 参加企業： 銀行、証券会社、保険会社、信用金庫、フィンテック企業など 20 社以上 プログラム実施報告 ① クラウド基礎概念の理解 イベントの冒頭では、フィナンシャルサービスインダストリ技術本部のソリューションアーキテクト、菅原太樹がクラウドコンピューティングの基本概念について解説いたしました。基本的なサービスである Amazon EC2 と Amazon RDS を中心に、クラウドサービスのメリットをご紹介しました。 冒頭 AWS を触ったことがある方をお伺いしたところ、半数ほどの方がまだ未体験でした。 次に、このイベント以後どのように AWS を学べば良いかをお伝えするセッションを行いました。実際に AWS の新卒社員が実際に用いている AWS 学習方法を参考に、実践的かつ身に付く知識の身につけ方をお伝えしました。本イベントや AWS JumpStart に参加いただいた後も、自主的にクラウドサービスを学ぶための道筋になったと考えています。 イベントにてご紹介した AWS の学習方法から抜粋 グループワークでは、6–7 名のテーブルに分かれて自己紹介、アイスブレイクと共にクラウドへの期待や不安を共有していただきました。他社ではありながらも同じ業界の仲間同士ということもあり、規制要件への対応や既存システムとの連携など、共通の課題について活発な議論が行われました。 あえて同じ会社ではなく、他社から参加された方同士でテーブルを囲んでいただきました。 参加された方からは、「AWS の初回無料枠について初めて知ることができた。テーブルで話した皆様が資格を取ろうとしていることがわかり、私もクラウドプラクティショナーを取ろうと思った。AWS 無料枠とハンズオン資料をもとに、手を動かして開発したい。」といったお声をいただきました。 ② アーキテクチャホワイトボーディング 本セッションでは、AWS JumpStart 本編で実際に行うホワイトボーディングの入門編を体験していただきました。まずは、広域事業統括本部ソリューションアーキテクトの深澤真愛が、基礎的なシステムを題材に、アークテクティングのコツからグループワークにおける活動方法をご紹介しました。 クラウドアーキテクチャの基礎を学んでいる様子 セッション内では、Amazon EC2 で構成される基本的な Web 三層構造のアーキテクチャを改善するワークショップを行いました。参加された方は会社を超えてグループワークで協力し、分担して調べながらアーキテクティングを行いました。 グループに与えられたお題 グループワークの開始前には、アーキテクティングのコツをご紹介しました。アーキテクティングのコツに興味がございましたら、下記ブログをご参照ください。 AWS のアーキテクチャ図を描きたい ! でもどうすれば良いの ? https://aws.amazon.com/jp/builders-flash/202204/way-to-draw-architecture/ また、新卒の方も多くいらっしゃったため、AWS JumpStart はもちろん普段の業務にも活せる、グループワークそのもののコツについてもお伝えしました。AWS の経験の有無や業務の内容など、さまざまな方がいる中で、スムーズに安心してディスカッションができました。 AWS の講師よりグループワークのコツやマナーをお伝えしている様子 各グループの発表では、AWS よりご提示したお題を超えて、可観測性や開発環境などの観点を盛り込んだ設計が多く見られ、参加者の皆様の高い意識を感じることができました。アーキテクチャを書き終えた後は、グループ同士で発表とレビューを行い、知見の輪を広げることができました。 アーキテクチャをグループで検討し、他のグループに発表している様子 実際に参加された方が書かれたアーキテクチャの例 最後に AWS 社員の考えたアーキテクチャの一例を解説し、振り返りを行いました。クラウドの設計方針として押さえるべきポイントをお伝えし、参加された方にお考えいただいたアーキテクチャと比較をしていただきました。 AWS の社員が考えたアーキテクチャのスライドより抜粋 本ホワイトボーディングをご体験いただいた方から、多くのお声を頂戴しました。 AWS を普段から業務でご利用されている方からは、「AWS には本当にたくさんのサービスがあって、どれを選べばいいのか迷っていました。今回のワークショップで、各サービスをどうつなぎ合わせてアーキテクチャを構成するかがよく理解できました。特にグループワークで他の参加者の方々と議論しながら進められたのが良かったです。」というお声をいただきました。 また、AWS 未経験のお客様からは、「正直、難しい部分もあり、理解できなかったところもありました。でも、今まで点でしか見えていなかった AWS のサービスが、今回のセッションを通じて少しずつ線でつながってきた感覚があります。これからも学習を続けて、点と点をつなげていきたいと思います。」というお声もいただいています。 ③ 金融業界でのクラウド活用実践 金融業界の IT の未来を担う参加者に向け、現状のクラウド活用事例と、AWS のサービスを紹介させていただきました。前半のセッションでクラウドの基礎を学習した後で、金融業界に特化したお話をさせていただきました。 クラウド活用事例紹介のトピックでは、金融で求められるセキュリティと可用性に関するベストプラクティスを提供するフレームワーク、「 金融リファレンスアーキテクチャ日本版 」をもとに、勘定系のシステムやコンタクトセンターのシステムのアーキテクチャをご紹介しました。 コンタクトセンターのリファレンスアーキテクチャのご紹介 コンタクトセンターのリファレンスアーキテクチャのご紹介 参加した方からは、「実際に案件で AWS を触っているので深掘りするきっかけができた。前半のセッションでアーキテクチャ図の見方がわかるようになったので嬉しい」というお声をいただいています。 サービス紹介のトピックでは、メインフレームで動くシステムをモダナイズすることができる AWS Transform for Mainflame を説明いたしました。Transform for Mainframe は メインフレームワークロードを大規模にモダナイズするためのエージェント型 AI サービスとなっています。 こちらのセッションは予想以上に新卒の参加者からも高評価をいただきました。ある新卒の参加者の方は、「現在自社のシステムをメインフレームからモダナイズする案件が動いている。これを使えば自分の知らない COBOL プログラムを簡単にリファクタリングできそうなので、ぜひ活用したい」と嬉しそうに語っていました。 ④ 懇親会・ネットワーキング イベント終了後の懇親会では、軽食を囲みながら参加者同士の交流が深まりました。名刺交換も活発に行われ、業界を超えた人脈形成の場となりました。学びの共有も行うことができ、その後参加者同士で二次会に行かれる方もいらっしゃいました。 まとめ 今回のイベントでは、金融業界の若手エンジニアの方の学習意欲の高さと、業界特有の課題に対する真摯な取り組み姿勢を強く感じることができました。参加者のうちアンケートにお答えいただいた 76 人中 75 名の方に、イベントに対して満足しているとお答えいただきました。 アンケートでは「AWSについて学びたいけどよくわからない…という状態からなんとなくわかる状態になることができました。グループワークも積極的に話し合えてよかったです」「知り合いにインフラ系エンジニアが少なかったため、他社の若手社員と知り合うことができありがたかったです。」といった声を多数いただき、イベントの目的を達成できたと考えております。 本イベントは、AWS が日本社会・経済の安定した基盤を提供するための取り組み「Vison 2030」に定義されている、イノベーション人財の育成の一環として行われました。これからも様々な形でイベントを開催いたしますので、ご参加いただけますと幸いです。 今後の展開 AWS JumpStart 本編への参加 今回の参加者のうち、89% の方が AWS JumpStart 本編への参加を予定されています。AWS JumpStart Zero For FSI で築いた知見を活かして、より実践的な学習を進めていただけることを期待しております。 AWS JumpStart 本編については こちら からお申し込みください。 継続的なコミュニティ活動 参加者された方からのご要望を受け、金融業界向けの若手 AWS ユーザーコミュニティの立ち上げを検討しております。定期的な勉強会や情報交換の場を提供し、金融業界で働く次世代クラウド人財のコミュニティ活動を始動していきます。 著者 / イベントスピーカー 菅原 太樹 (Taiki Sugawara) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト 2024年に新卒で入社した 2 年目 SA。主に保険業界のお客様を担当している。 技術の得意領域はサーバーレス。AWS Summit Japan 2025 のブレイクアウトセッションに日本史上最若手登壇を行う ( YouTube ) など、各種発表にも力を入れている。 X: @taikis_tech LinkedIn: https://www.linkedin.com/in/taikis/ 深澤 真愛 (Mana Fukasawa) アマゾンウェブサービスジャパン合同会社 広域事業統括本部 ソリューションアーキテクト 2025年4月入社。幅広い業界でのイベントにサポーターやスピーカーとして多数参加。IoT 技術に強い関心を持っている。 inkedIn:  https://www.linkedin.com/in/manafukasawa/ 関連リンク AWS JumpStart 2025 について AWS 金融サービス リソース

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊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 にアップデートし、使用状況ダッシュボードを確認し、自分の開発ニーズに合ったプランを選んで新しい料金体系を始めましょう。