本稿は、2024 年 11 月 29 日に公開された “ Faster scaling with Amazon EC2 Auto Scaling Target Tracking ” を翻訳したものです。 はじめに AWS クラウドの主な利点の 1 つは弾力性です。これにより、ユーザーは必要なリソース分だけをプロビジョニングして利用できます。ユーザーは弾力性の利点を最大限に活用するために、自動化された幅広く簡単に操作できるメカニズムを必要としていました。 Amazon EC2 Auto Scaling は、変化するワークロードの需要に合わせて Amazon Elastic Compute Cloud (Amazon EC2) インスタンスの数を自動的にスケーリングできるようにすることで、これらの課題を解決できます。また、インスタンスのライフサイクルを管理するための幅広い機能を提供しています。 Auto Scaling グループ（ASG）をスケーリングするには、ユーザーはスケーリングポリシーを作成する必要があります。スケーリングポリシーは、ワークロードの需要に合わせて Amazon EC2 の容量を調整するためのガイドラインを ASG に提供します。スケーリングポリシーにはさまざまな種類があり、それぞれ容量を管理するアプローチが異なります。 ポリシーの 1 つとして ターゲット追跡スケーリングポリシー があります。これは、自動的にスケーリングするためのより簡単で効果的な方法です。これを使用するには、ユーザーは 使用率メトリクス を定義し、維持する目標値を設定する必要があります。たとえば、平均 CPU 使用率 60％ というポリシーを設定すると、ASG は EC2 インスタンス全体にわたってメトリクスをできるだけその値に近づけます。 この投稿では、最近リリースされた ターゲット追跡スケーリング のアップデートについて説明します。また、新機能を使用するターゲット追跡スケーリングポリシーを作成する手順を説明し、新機能がもたらす利点についても説明します。 ターゲット追跡スケーリングポリシーの新機能 ユーザーがアプリケーションをモダナイズするにつれ、私たちは動的な Auto Scaling ソリューションを当初のターゲット追跡スケーリングポリシーの実装を超えて拡張する必要があることを学びました。 まず、ユーザーは、ターゲット追跡スケーリングが需要の急増に対応するのに数分かかると、短期的にパフォーマンスが低下する可能性があることに気付きました。多くのユーザーが、ランニングキャパシティをバッファリングすることでこの課題を軽減しましたが、これはコストの増加につながりました。次に、ワークロードが異なればスケーリング要件も異なります。つまり、ユーザーはワークロードごとに調整されたスケーリングポリシーを作成する必要があります。これは、パフォーマンスとコストを最適化するために、時間がかかり、エラーが発生しやすく、運用上もコストがかかる作業です。 これらのユーザーの課題に対処するために、合理的で応答性の高いターゲット追跡スケーリングポリシーをリリースしました。ターゲット追跡スケーリングは、個々のアプリケーションの固有の使用パターンに合わせて応答性を自動的に調整し、アプリケーションの需要を綿密に監視して、スケーリングの決定をより迅速に行えるようになりました。また、自動チューニングにより、ユーザーはワークロードごとに調整されたスケーリングポリシーを作成しなくても、アプリケーションのパフォーマンスを向上させ、Amazon EC2 リソースの使用率を高く維持してコストを削減できます。ユーザーは維持したい目標使用率を指定するだけで、ターゲット追跡スケーリングは追加設定なしにスケーリングできるようになりました。 自動スケーリングを迅速に行うために、ユーザーは Amazon CloudWatch の高解像度メトリクスを使用してターゲット追跡スケーリングポリシーを設定できます。このきめ細かい監視により、ターゲット追跡スケーリングは変化する需要を分単位ではなく数秒単位で検出して対応します。この機能は、クライアントサービス API、ライブストリーミングサービス、e コマース Web サイト、オンデマンドデータ処理など、需要パターンが不安定なアプリケーションに最適です。 新しいターゲット追跡スケーリングポリシーの始め方 すでにターゲット追跡スケーリングポリシーを使用している場合は、自動的に調整されるターゲット追跡スケーリングにアップグレードするためのアクションは必要ありません。ターゲット追跡スケーリングポリシーは、ターゲットメトリクスの履歴を定期的に分析し、スケールアウトとスケールインを開始するための適切な感度レベルを決定します。さらに、可用性とコスト削減の両方を最適化するために追加または削除する必要がある容量も決めます。これらの決定は、需要の変化の範囲や頻度、使用量の急増が長期的か短期的かなど、アプリケーションの需要パターンの固有の特性によって異なります。ターゲット追跡スケーリングは継続的に学習し、特定のアプリケーションや需要パターンに自動的に適応するように自動的に再評価されます。 ターゲット追跡スケーリングの迅速な応答を有効にする さらに、ターゲット追跡スケーリングポリシーからの迅速な対応を可能にするために、ユーザーは Amazon CloudWatch に 1 分未満の精度で発行されたメトリクス（高解像度メトリクスとも呼ばれます）を追跡できます。ユーザーは、既存のターゲット追跡スケーリングポリシーを更新したり、カスタマイズされたメトリクス（CustomizedMetricSpecification）の一部として高解像度メトリクスを含む新しいポリシーを作成したりできます。ユーザーは、Amazon CloudWatch にメトリクスを発行するときに作成された同じメトリクス名前空間、メトリクス名、および任意のディメンションやユニットを記述する必要があります。また、ターゲット追跡スケーリングがメトリクスを評価するために、メトリクスの粒度を示すメトリクス期間も定義する必要があります。次のステップでは、 AWS マネジメントコンソール で ASG を使う方法を説明します。 ステップ 1: ASG の選択 Amazon EC2 コンソールで ASG の名前を選択します。すると次の図に示すように 詳細 ページに移動します。 図 1: Amazon EC2 コンソールでスケーリングしたい ASG を選択 次の図に示すように オートスケーリング タブを選択してください。 動的スケーリングポリシーを作成する ボタンが表示されます。 図 2: 選択した ASG のオートスケーリングタブ ステップ 2: 動的スケーリングポリシーの作成 ポリシータイプとしてターゲット追跡スケーリングを選択してください。 メトリクスタイプ には、 カスタム CloudWatch メトリクス を選択してください。これは事前に入力された JSON スニペットを示しています。次の図に示すように、CloudWatch メトリクスの発行に使用したターゲット追跡スケーリングポリシーを使用して、スケーリングするメトリクスのメトリクス名、名前空間、ディメンションを編集できます。 図 3: 更新された CustomizedMetricSpecification セクション サポートされている最小期間は 10 秒です。10 秒のメトリクス期間を使用するには、メトリクスは 10 秒以上の解像度、たとえば 1 秒で発行する必要があります。ただし、1 秒間隔で発行すると、CloudWatch のコストが大幅に増加する可能性があります。コストに関する考慮事項については、この記事の後半で説明します。Auto Scaling では、ターゲット追跡スケーリングが使用量の急増を迅速に監視して対応できるように、60 秒の制限を設けています。 この 2 つのステップにより、ターゲット追跡スケーリングを高解像度のメトリクスでスケーリングできるようになります。 より迅速なスケーリングを可能にする 前述の手順により、ASG は使用率の変化をより迅速に検出できるため、需要が急増したときにより多くのインスタンスを追加できます。 次の図は、ターゲット追跡スケーリングポリシーがデフォルトである 60 秒の期間で構成された環境と 10 秒の期間で構成されている環境に対して、同じ負荷テストを実行した結果を示しています。各ポリシーの目標値は 60% の CPU 使用率です。負荷テストでは、需要の急増をシミュレートするために、それぞれ http リクエストを送信するたびに、3 分間で最大 20 スレッドまで増加しています。60 秒のケース（左の図）では、アプリケーションが CPU 使用率の目標である 60％（青い線）を 3 分間上回っていたことがわかります。容量（緑の線）は、システムの CPU 使用率が 100% のピークに達した後にのみ増加しました。これはアプリケーションのパフォーマンスの問題につながる可能性があり、それを回避するには、より多くの容量をプロビジョニングできるように使用率を下げることを目指さなければならず、コストが増加します。しかし、10 秒のケース（右の図）では、アプリケーションへの影響を避けるために迅速にスケーリングが行われました。容量は 1 分後に増加しましたが、その間 CPU 使用率は 60% 近くにとどまり、100% のピークレベルには達しませんでした。これにより、ユーザーはリソース使用レベルをより高くすることができ、アプリケーションのパフォーマンスに影響を与えずにコストを節約できます。 図 4: 60 秒と 10 秒のメトリクス期間で設定されたターゲット追跡スケーリングポリシー 考慮事項 高解像度のカスタムメトリクスを適用する前に、コストに影響する可能性があるため、次の要素を考慮することをお勧めします。 メトリクスタイプ : ターゲット追跡スケーリングは、メトリクスが ASG のインスタンス数に比例して変化することを前提としています。ターゲット追跡スケーリングポリシーを成功させるには、適切なメトリクスを選択することが重要です。詳細については、 ターゲット追跡スケーリングポリシーのドキュメント を参照してください。 料金 : これらの新機能を含め、EC2 Auto Scaling に追加料金はかかりません。ユーザーは、アプリケーションの実行に必要な AWS リソースと CloudWatch モニタリング料金のみを支払います。ただし、これらの機能に関連する CloudWatch の 3 つの請求項目を理解しておく必要があります。 1) 高解像度アラーム 2) API コール 3) カスタムメトリクス ターゲット追跡スケーリングでは、少なくとも 2 つのアラームが生成されます。アラームはそれぞれ、使用率の高い値と低い値を追跡し、それらのしきい値の間にバッファーを配置して変動を減らします。メトリクス期間が 60 秒未満の場合、これらのアラームは高解像度のアラームとして請求されます。この記事を書いている時点で、AWS アジアパシフィック（東京） リージョン の高解像度アラームの価格は、アラームメトリクスあたり 0.30 ドルですが、標準解像度のアラームの価格はアラームメトリクスあたり 0.10 ドルです。 CloudWatch エージェントを使用している場合は、CloudWatch エージェントは metrics_collection_interval の設定値に基づいて各インスタンスから API コールを送信します。各インスタンスは、間隔ごとに 1 回 API コールを Amazon CloudWatch に送信します。Amazon CloudWatch では、メトリクスは名前空間、メトリクス名、ディメンション（オプション）、単位（オプション）のユニークな組み合わせとして定義されます。CloudWatch エージェントからプッシュされたディメンションのユニークな組み合わせは、すべてカスタムメトリックとして請求されます。 以下は、無料利用枠を過ぎて有料利用枠の第 1 段階にあるアカウントで、東京リージョンを利用して予想される月額料金（USD）の例です。この例では、1 つのターゲット追跡スケーリングポリシーで、メトリクスとアラームが 10 秒間隔に設定されている ASG で、1 か月に平均 10 個のインスタンスが実行されていることを前提としています。 1) 高解像度アラーム: 2 つのアラーム * $0.30/アラームメトリクス = $0.60/月 2) API コール: 10 インスタンス * 30 日 * 24 時間 * 3,600 秒 / 10 秒間隔 = 2,592,000 API コール 2,592,000 API コール * $0.01/1,000 リクエスト = $25.92/月 3) カスタムメトリクス: 1 つの ASG に集約されたメトリクス * $0.30/月 = $0.30/月 合計見積もり: $26.82/月（ASG で 10 個のインスタンスを実行する前提） 1 回の PutMetricData API コールで複数のメトリクスをプッシュできます。複数の AutoScalingGroupName メトリクスを発行するように CloudWatch エージェントを設定した場合、API の料金は PutMetricData のサイズ制限に達するまで同じままになり、カスタムメトリクスの料金のみが増加します。 たとえば、ASG が c8g.xlarge インスタンスを実行している場合、これらの機能によって使用率が高くなるため、実行するインスタンスを 1 つ減らすと、東京リージョンでの毎月のコスト削減は次のようになります。 1 個 c8g.xlarge インスタンス $0.15896/時間 * 30 日 * 24 時間 = $114.45/月 CloudWatch の推定コストである月額 26.82 ドルを差し引くと、ASG あたり月額 117.18 ドルの節約になります。この例では、EC2 のコストをほぼ 8% 節約できます。 メトリクスの発行とスケーリングポリシーを更新するテンプレート 高解像度のメトリクスの公開を始めるのに役立つように、 AWS CloudFormation のサンプルテンプレートを用意しました。このテンプレートは、既存の ASG の新しいより速いスケーリング期間を検証するためのサンプルです。これには、CloudWatch エージェントをインストールし、ASG インスタンスの CPU 使用率を高解像度で Amazon CloudWatch に発行することが含まれます。このテンプレートには、この記事で説明されているようにターゲット追跡スケーリングポリシーも含まれています。 デプロイとカスタマイズの要件に関する説明は、AWS Samples リポジトリの Faster Scaling with EC2 Auto Scaling にあります。テンプレートにはお伝えしたいコードスニペットがいくつかあります。 まず、 CloudWatch エージェント をインストールするために、テンプレートは ASG で使用される起動テンプレートの UserData を更新します。 UserData: Fn::Base64: !Sub | #!/bin/bash yum install amazon-cloudwatch-agent -y sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c ssm:/cw-agent-asg-aggregate-cpu -s このコマンドは、Cloudwatch エージェントの設定を保持する AWS Systems Manager のパラメータを参照しています。 AWS Systems Manager のパラメータの次のスニペットは、10 秒間隔で CPU 使用率メトリクスを FasterScalingDemo というカスタム名前空間に報告します。このメトリクスは、Amazon CloudWatch で簡単に参照できるように、ASG の名前をディメンションとして集計されます。 CloudWatchMetricsSSMParameter: Type: AWS::SSM::Parameter Properties: Name: cw-agent-asg-aggregate-cpu Type: String Value: '{"agent":{"metrics_collection_interval":10,"run_as_user":"cwagent"},"metrics":{"force_flush_interval":10,"aggregation_dimensions":[["AutoScalingGroupName"]],"append_dimensions":{"AutoScalingGroupName":"${aws:AutoScalingGroupName}"},"namespace":"FasterScalingDemo","metrics_collected":{"cpu":{"drop_original_metrics":["cpu_usage_active"],"measurement":[{"name":"cpu_usage_active","rename":"CPUUtilization"}]}}}}' Tier: Intelligent-Tiering Description: Custom metric specification for CloudWatch Agent 次に、テンプレートには更新された AWS Identity and Access Management（IAM） の IAM ロールと対応する IAM インスタンスプロファイルも含まれています。このプロファイルには、Amazon CloudWatch への PutMetricData へのアクセス権と、エージェントを設定するために以前に作成した Systems Manager パラメータを取得する権限があります。 IAMInstanceRole: Type: 'AWS::IAM::Role' Properties: AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Principal: Service: - ec2.amazonaws.com Action: - 'sts:AssumeRole' Path: / Policies: - PolicyName: FasterScalingDemo PolicyDocument: Version: "2012-10-17" Statement: - Effect: Allow Action: - cloudwatch:PutMetricData - ec2:DescribeTags - ssm:GetParameter Resource: '*' Tags: - Key: Name Value: !Sub ${EnvironmentName}_IAMROLE 最後に、CloudFormation テンプレートによってデプロイされたアーキテクチャを示します。 図 5: CloudFormation テンプレートによって作成された AWS リソース 選択した ASG に対してでプレートをデプロイしたら、ターゲット追跡スケーリングを高解像度のメトリクスでテストする準備が整っているはずです。負荷テストを実行し、ターゲット追跡スケーリングが動作していることを確認できます。負荷テストがアプリケーションの使用パターンに近いほど、これらの機能の利点を判断するテストの信頼性が高まります。 まとめ このブログでは、お客様の需要と Amazon EC2 の処理能力をより正確に一致させるために、ターゲット追跡スケーリングに追加された新機能の概要を説明しました。具体的には、高解像度の CloudWatch メトリクスをターゲット追跡スケーリングで使用し、需要に合わせて Auto Scaling レートを上げて可用性を向上させ、リソースをより有効に活用できることを示しました。高解像度メトリクスを使ったスケーリングを適用する前にこの機能をテストし、この投稿で概説されている考慮事項を検討することをお勧めします。これらの新機能の詳細については、 ターゲット追跡スケーリングポリシーのドキュメント をご覧ください。 翻訳はソリューションアーキテクトの 阿部 純一郎 が担当しました。

本記事は米国時間 2025 年 8 月 28 日に公開された Use Kiro for free until September 15 を翻訳したものです。Kiro の最新情報は、 Kiro の公式ドキュメント をご覧ください。 8 月 22 日の価格更新 に続き、9 月 1 日を超えて 9 月 15 日まで、Kiro の無料使用を延長いたします。 9 月 15 日まで引き続き Kiro を無料で使用できることとなります。9 月分の請求については全額返金いたしますので、引き続き無料で Kiro をご利用いただけます。使用制限は、通常のサブスクリプションサイクルの一部として、9 月 1 日にご利用制限がプランの上限までリセットされます。 さらに、お客様がご利用中の有料プランに関係なく、超過料金を有効にして、9 月 15 日まで追加で 1,000 回の vibe リクエストと 200 回の spec リクエストを無料でご利用いただけます。詳細については、以下の FAQ をご覧ください。 また、すべての払い戻しが処理されています。そして、今週初めにシステムの改善を行うため、制限をリセットしました。これにより、有意義な仕事ができるようになることを願っています。 お客様のフィードバックに耳を傾けており、Kiro の価格モデルをどのように進化させるかを決定する上で非常に貴重な情報となっています。お客様のご意見に基づき、今後数週間で価格変更を発表し、9 月 15 日以降に新しい価格を展開する予定です。新しい価格変更を展開する前に、お客様が適切に計画できるよう、今後の変更についてお知らせいたします。 これらの変更は、価格モデルにお客様のフィードバックを反映させながら、現在の体験をより長く皆様にお楽しみいただくために行っています。改めて皆様のサポートに感謝いたします。 Discord コミュニティ にご参加いただき、引き続きフィードバックをお寄せください。 FAQ お客様への返金はいつ、どのように行われますか？ Kiro のアクティブなサブスクリプションをお持ちの場合、9 月 1 日に 9 月分の使用料がクレジットカードに請求されます。9 月 15 日までに金額を返金いたします。 超過料金も返金されますか？ 8 月にすでに超過料金が発生している場合は、それらも返金いたします。 超過料金 は 9 月中、一時的に 1,000 回の vibe リクエストと 200 回の spec リクエストに制限されます。超過料金がクレジットカードに請求された場合、9 月末に返金いたします。 お客様の使用制限はいつ、どのようにリセットされますか？ 月間プランの制限は 9 月 1 日にリセットされます。 今日サブスクリプションを購入した場合、9 月 15 日まで無料ですか？ 9 月 14 日までにサブスクリプションを購入された場合、9 月 14 日まで無料でご利用いただけます。クレジットカードに請求されますが、9 月 15 日までに返金いたします。9 月 15 日まで、購入されたプランの月間制限の上限までご利用いただけます。 9 月は Kiro を無料で使用できますか？ すでに有料プランをご利用の場合、月間制限は 9 月 1 日にリセットされ、9 月 15 日まで完全な月間制限内で引き続き Kiro を無料でご利用いただけます。 9 月 14 日までに有料プランを購入される場合、有効なクレジットカードを提供していただく必要があり、購入されたプランの価格と適用される税金および手数料が請求されます。その後、購入から数日以内の 9 月 15 日までに返金いたします。アップグレードした完全な月間プラン制限内で無料で Kiro をご利用いただけます。未使用のリクエストは翌月や更新されたプランに繰り越されません。お客様のニーズにより適合するよう既存の価格プランの調整を行っており、今後数週間で更新を展開する準備が整い次第、サブスクリプションをキャンセルしない限り、新しいプランに移行していただきます。9 月後半により詳細をお伝えいたします。 9 月中に超過料金を無料で有効にできますか？ はい、超過料金を有効にできます。 超過料金 は 9 月 15 日まで一時的に 1,000 回の vibe リクエストと 200 回の spec リクエストに制限されます。9 月 15 日までに発生した超過料金がクレジットカードに請求された場合、9 月末に返金いたします。 今後数週間でどのような価格更新が期待できますか？ 一般的な開発タスクで Kiro を使用する際に優れた効果を得られるよう、spec リクエストと vibe リクエストの動作方法を変更することを検討しています。価格を展開する前に更新をお伝えし、変更がお客様に適しているかどうかを判断していただく機会を提供いたします。 日割り請求はどのように機能しますか？ 月が 30 日ある場合、20 日目にサインアップすると、その月の残り 10 日分が請求され、それに応じて月間制限をご利用いただけます。例えば、9 月 5 日に Kiro Plus にサブスクライブした場合、9 月は 30 日あるため、25/30 × $20（Kiro Plus のコスト）= $16.67 が請求され、25/30 × 225 = 187 回の vibe リクエストと 25/30 × 125 = 104 回の spec リクエストをご利用いただけます。 Kiro ハッカソンに参加していますが、これらの変更は私にどのような影響を与えますか？ ハッカソン の提出期限は 9 月 15 日であり、この発表で説明されているのと同じ条件で、その日まで無料で Kiro をご利用いただけます。

この記事は、2025 年 8 月 19 日に Jeremiah Flom, Rudy Jaurequi, Connor Sparkman, Vivian Bui によって執筆された「 The AWS Tech U survival guide 」を翻訳したものです。 訳注: 本ブログでは、AWS の新卒研修プログラムである Tech U について、 AWS の若手社員が実際に参加した目線でプログラムを紹介し、若手キャリアの形成に必要な経験と成功のヒントを紹介しています。AWS Tech U は現在パブリック提供されていませんが、研修を計画する教育担当の方や、新卒研修に参加する若手エンジニアの方は、ぜひ参考にしてください。 今後のキャリアを決定づける瞬間を想像してみてください：AWS Tech U の初日。何を期待すべきでしょうか ? 今後数ヶ月間を最大限に活用するにはどうすればよいでしょうか ? このブログは、AWS Tech U に参加する若手の技術者や、クラウドテクノロジーでのキャリアを追求するために独自の学習を開始する方のためのガイドです。AWS Tech U は、新しく採用された若手人材が、AWS での技術ロールで成功に向けた準備をする、キャリア開発プログラムです。技術的な深さと専門スキルの両方の学習モジュールを提供しています。このブログでは、AWS Tech U のコアカリキュラム、 AWS 認定 の価値、そして Tech U を超えてキャリアを向上させる方法について説明します。 AWS Tech U コアカリキュラム AWS Tech Uは、職業的背景に関係なく、 Amazon Web Services (AWS) での技術的キャリアに向けて準備することを目的としています。プログラムは、技術トレーニングと ProSkills (専門スキル) トレーニングに分かれた包括的なカリキュラムで構成されています。プログラムは技術的創造性と実世界の問題解決を優先し、インストラクター主導および同僚同士の学習によって促進されます。 技術トレーニングは、オンラインのインストラクター主導セッション、ハンズオンラボ、およびコースの進行に合わせた、重要なクラウド概念を強化する自己学習モジュールで構成されています。インストラクター主導セッションでは、自己学習モジュールの内容を補完し、理解を深めるために実施されます。ネットワーク、高可用性 Web アプリケーション、データ分析、コンプライアンス、 人工知能と機械学習 (AI/ML) を含む幅広いトピックに触れることになります。 ProSkills トレーニングでは、専門的なロールで成功するために必要な非技術的スキルを学びます。これらのセッションには通常、自己学習モジュールと、同僚と一緒に実施する、ファシリテーター主導のグループワークやディスカッションが含まれます。ProSkills セッションで学ぶことが期待されるトピックには、協力的なブレインストーミングと課題解決スキル、執筆スキル、プレゼンテーションスキル、そして曖昧さの処理、時間管理、異なる性格スタイルの理解といった対人スキルがあります。 AWS 認定 AWS 認定 は、AWS での学習の重要な要素です。これらの認定を取得することで、あなたのクラウド専門知識が検証され、業界で認められた資格が提供されます。あなたのロールに応じて、プログラムでは認定の取得が求められます。例えば、ソリューションアーキテクトは最低要件として AWS Certified Cloud Practitioner と AWS Certified Solutions Architect – Associate を取得する必要があります。これらの基礎認定は、AWS サービスとアーキテクチャに関する原則の確実な理解を提供するように設計されています。生成 AI の台頭により、 AWS Certified AI Practitioner の取得も推奨されています。 最低認定要件を満たすことは不可欠ですが、追加の認定を取得することで技術的基盤を大幅に強化できます。 AWS Certified SysOps Administrator – Associate は、監視、自動化、セキュリティ実装、パフォーマンス最適化を含むシステム運用の知識を深めます。この認定は、クラウドコンピューティングの運用面に興味がある方にとって特に価値があります。 AWS Certified Developer – Associate 認定は、クラウドアプリケーションの構築と保守に焦点を当て、サーバーレスアーキテクチャ、継続的インテグレーションと継続的デリバリー (CI/CD) パイプライン、 API 開発、マイクロサービス設計などの重要なトピックをカバーしています。この認定は、クラウド環境でのアプリケーション開発スキルを強化したい方に理想的です。 認定取得で成功するために： AWS トレーニングリソースを活用する AWS 公式試験問題で練習する 一貫した学習スケジュールを維持する 学習を強化するために個人プロジェクトを構築する AWS Certified Cloud Practitioner と AWS Certified Solutions Architect – Associate が主要な目標であることを覚えておいてください。また、追加の認定を取得することで、AWS サービスのより深い知識を習得し、全体的なクラウドコンピューティングの専門知識を強化できます。 Learn and Be Curious Tech U プログラム中で、共通の興味と専門知識に基づいて AWS ビルダーを結集する専門グループである Technical Field Communities (TFC) について学ぶことになります。TFC は、それぞれが特定のドメインに焦点を当てた AWS 内の専門組織として機能します。各 TFC で利用可能な厳選されたトレーニングを通じて、あなたの興味を引く分野を探求する最適な道筋を提供します。これらのコミュニティは、技術スキルを中心としたものと特定の業界に特化したものの 2 つのカテゴリに構造化されています。 技術重視の TFC の例： データと分析 AI/ML セキュリティとコンプライアンス サーバーレスコンピューティング コンテナと Kubernetes 業界重視の TFC の例： 金融サービス ヘルスケアとライフサイエンス 製造業と産業 メディアとエンターテインメント 通信 Tech U プログラムは TFC への参加よりも優先されます。プログラムはあなたの重要な基盤を提供し、Tech U 期間中の広範な TFC 参加はあなたのコア学習に影響を与える可能性があります。これらのコミュニティを戦略的に探求するために空き時間を活用してください。内部イベント中に TFC メンバーと繋がったり、TFC の wiki ページを確認して彼らの仕事を理解したりできます。TFC メンバーは、彼らが専門とする技術や業界分野に基づくソリューションに興味を持つ顧客向けのデモンストレーションや、概念実証の構築を支援する意欲的なメンバーを歓迎することが多く、彼らの専門的な仕事への直接的な洞察を提供します。データと分析や金融サービス業界など、興味のある分野を特定したら、その TFC のアンバサダー向け学習パスを進めて専門化要件を理解してください。 TFC を補完的な学習機会として参加することで、その価値を最大化できます。Tech U の空き時間に、技術的な Deep Dive セッションに参加することで、将来のキャリア決定に役立ちます。また、 TFC メンバーと会話し専門的な繋がりを構築することで、Tech U を主要な焦点として維持しつつ専門化パスへの洞察を提供します。 TFC はあなたの AWS キャリア全体を通じて利用可能です。まず Tech U カリキュラムの完了に焦点を当て、その後時間が許す限り興味のある技術ドメインや業界を探求してください。この構造化されたアプローチにより、Tech U プログラムに集中しながら、専門化について情報に基づいた決定を可能にします。 シャドーイング機会 AWS Tech U プログラムを通じて、顧客会議中のスピーキングスキルを向上させる定期的な機会があります。専門的成長をさらに向上させるために、積極的にシャドーイング機会を探すことが推奨されます。これらの価値ある学習体験を見つける積極性を示すことで、専門的発展への取り組みを探究し、プログラムを自身でカスタマイズできます。 機会を見つけるためには、同僚、メンター、アドバイザーなど、あなたのネットワーク内のより経験豊富なソリューションアーキテクトと話してください。また、最近の AWS Tech U 卒業生にも連絡を取ってください。会議をシャドーイングする際は、将来の顧客会議で一人前の AWS 社員になる意図を持って準備し、参加することが重要です。そのためには、会議の準備に必要な作業を自身で行い、会議をリードしているかのように議論を積極的に聞いてください。 これらのガイドラインに従うことが重要です： 顧客を調査して会議の準備をする。会議をリードする人は、顧客または需要創出代表者 (DGR) からの紹介メールを提供すべきです。この情報を使用して以下を調べてください： 彼らのビジネスはどのようにお金を稼いでいるか ? 類似のビジネスは現在 AWS を使用しているか、どのように使用しているか ? 顧客は持続的または繰り返し発生する問題について言及しているか ? 会議後、DGR とソリューションアーキテクトに感謝し、会議について議論するための短い振り返り時間を作ってください。彼らが重要だと思ったことを聞き、あなたのメモと比較してください。ここで彼らの思考プロセスと要点への最も多くの気づきを得ることができ、あなたが見逃したかもしれない項目を理解できます。 会議のシャドウイングは、真に成長できる方法の一つです。AWS Tech U で行う作業のほとんどは基本的な要件であり、例外的な場面は要件を超えて冒険することによってのみ起こります。 さらなる成長機会 コアカリキュラムと認定を終えると、AWS Tech U は追加の専門的発展のための多数の機会を提供します。プログラムは AWS Skill Builder コース、ドキュメントの Deep Dive、ハンズオンワークショップを通じた自己学習を推奨しています。 AWS トレーニングと認定 ポータルなどの内部 AWS リソースを探して、豊富な自己学習資料、ウェビナー、バーチャルイベントを活用してください。 コミュニティエンゲージメントは、AWS でのあなたの発展において重要な役割を果たします。 AWS User Groups への参加、 AWS re:Invent や AWS Summit などの主要イベントへの参加、内部ディスカッションフォーラムへの貢献など、複数の機会があります。これらのイベントは業界の同僚と交流する良い機会であり、最新の AWS 知識を維持するために活用できます。 技術的成長は実践的な経験と知識共有を通じて得られます。個人プロジェクトの構築は、将来の機会に向けてあなたのスキルと創造性を育てます。さらに、あなたの学習を文書化し、ベストプラクティスを共有することで内部 AWS 知識ベースに貢献することは、あなたの成長と同僚の発展の両方に役立ちます。 AWS での成長は自己主導であり、これらの追加機会を探求する積極性を取ることで、AWS Tech U 体験と将来のキャリア見通しを大幅に向上させることができることを覚えておいてください。 成功のためのヒント 自分自身に目標を設定する あなたの期待が達成可能であることは良いことですが、大きく考えることを恐れないでください。AWS Tech U のような機会は稀であり、あなたにとって最適な方法で運営する柔軟性が与えられます。期間中に焦点を失わないように、AWS Tech U の開始時に少なくとも一つの主要な目標を立て、常に一貫した目標を持つようにしてください。この目標は追加の AWS 認定の取得、毎週の会議シャドーイング、または TFC での活躍かもしれませんが、何を達成したいにしても、それが実現不可能または努力に値しないと他人に説得されるという罠に陥らないでください。 類似の目標を持つ友人を作る AWS の誰もが、あなたの成長に役立つ独自の背景と知識を持っています。ここで提案しているのは、あなたと同じ道を歩む他の人々と学び、成長することです。私の友人グループは認定取得という共通の目標を共有していたため、お互いが勉強や試験を受ける日があることを明確に理解していました。困難を共有することで、困難がより簡単に感じられます。 あなたのやり方を見つける 勉強や新しいソリューションの構築のためにカレンダーで時間をブロックしてください。1 時間おきに会議があると、自己学習を進めることは不可能です。スケジュールを計画する際、どの会議があなたにとって必須かを決定し、会議主催者やマネージャーと欠席できる会議について話し合ってください。例えば、同僚、アドバイザー、メンターとの会議はすべてあなたの都合に合わせることができます。プロジェクトや目標で遅れを感じている場合は、彼らに知らせて会議を移動またはキャンセルする方が良いでしょう。多忙と感じることは一般的な経験であり、彼らはあなたと協力して解決策を見つけます。 時間を積み重ねる 長期間にわたる小さな努力は大きな結果を生み出すことができます。あなたの目標を心に留めておいてください。道に迷っていることに気づいたら、目標をより小さく、管理可能で測定可能な目標に分解してください。小さな達成はあなたの目標の目的を思い出させることができますが、私たちは皆失敗、疲労、フラストレーションに直面することを覚えておいてください。休憩が必要な時を認識し、それを適切に取ってください。 終わりに AWS Tech U プログラムでの学習は独特であることを覚えておいてください。一部の人は早期に認定で優秀な成績を収めるかもしれませんが、他の人は会議のシャドーイングや TFC への貢献で成長機会を見つけるかもしれません。重要なのは適応性と回復力を保ち、挑戦と時折の挫折が学習プロセスの自然な部分であることを理解することです。 このガイドで共有された戦略とアドバイスは、この道を歩んだ人々の実際の経験から来ています。効果的な時間管理、意味のある繋がりの構築、追加の成長機会の追求など、これらの洞察はあなたの AWS Tech U 体験を最大化に役立つことを意図しています。しかし、これらは厳格なルールではなく、ガイドラインとして見るべきです。あなたの個人的な学習スタイルとキャリア目標に合わせて適応させてください。 意図、熱意、成長マインドセットを持って AWS Tech U プログラムに参加することで、AWS およびより広い技術業界で通用するキャリアのスタートラインに立つことができます。 翻訳は Technical Instructor の 西村 諄 が担当しました。

こんにちは！AWS のソリューションアーキテクトの志村です。9 月 18 日 (木) に開催される「 AWS Innovate: Migrate and Modernize 」の見どころをご紹介します。 今回の AWS Innovate は、AI ネイティブな未来を見据えたクラウドへのマイグレーションとモダナイゼーションがテーマです。多くの企業では、オンプレミス環境で稼働する基幹システムやレガシーアプリケーションへの対応に、頭を悩ませているのではないでしょうか。また一方で、生成 AI をはじめとする最新テクノロジーを積極的に活用することで、どのように生産性を高めていけるか検討もしているかと思います。本イベントでは、AWS のエキスパートが実践的な移行手法とベストプラクティスを解説します。さらに、クラウド活用でビジネス価値の創出に成功したお客様の事例も紹介します。クラウドへの第一歩を踏み出そうとしている方から、すでに移行を進めている方まで、次のステップに向けた具体的なヒントが得られる内容となっています。今回は特に、AWS が実際のプロジェクトで得た知見に基づいて、生成 AI を活用した移行手法や将来の AI 活用を見据えた基盤作りについて深く掘り下げます。AWS が提供する豊富な移行支援ツールやパートナーエコシステムの活用方法、さらには効率的なマイグレーションとモダナイゼーションの実現方法まで、実践的な内容をお届けします。 なぜ今、クラウド移行に取り組むべきなのか 企業の IT 部門では、日々の運用保守に忙殺され、新しい取り組みになかなか着手できない状況が続いています。特に、レガシーワークロードの維持管理が、イノベーションの足かせとなっているケースが多く見られます。一方で、生成 AI の急速な発展により、企業の戦略において AI 技術の活用が必須となってきました。特に注目すべきは、エージェンティック AI の台頭です。今後多くの企業において、アプリケーションに AI エージェントが組み込まれ、日常業務の意思決定が AI で行えるようになると期待されています。実際、Amazon でもシステム開発において AI エージェントを活用することで、 年間 260 億 US ドルにおよぶ移行コスト削減 を達成しています。 このような変化に対応し、AI の恩恵を最大限に受けるためには、既存システムのクラウドへのマイグレーションとモダナイゼーションが不可欠です。マイグレーションとモダナイゼーションには、様々なアプローチが存在します。システムをそのままクラウドに移行する「リホスト」から、プラットフォームの最適化を行う「リプラットフォーム」、アプリケーションを刷新する「リファクタリング」まで、ビジネスニーズと技術ニーズの双方を考慮して戦略を選択します。一般的に、まずは現状のアセスメントを行い、システムの依存関係や制約を把握します。その上で、段階的な移行計画を立て、リスクを最小限に抑えながら実行していきます。特に重要なのは、単なるマイグレーションではなく、クラウドのメリットを活かした最適化を同時に検討することです。これにより、将来の変化に柔軟に対応できる基盤を整えることができます。 今回の AWS Innovate では、これらの背景や課題を噛み砕いて説明し、AWS が提供するソリューションやベストプラクティスをオープニングセッションと 6 つのトラックで紹介していきます。 セッションと見どころの紹介 オープニングセッション: AI 時代の移行戦略 オープニングセッションでは 2 つのパートに分かれています。前半では AI エージェントがもたらすマイグレーションとモダナイゼーションの革新について解説するとともに、AWS における実績も併せてご紹介します。また後半では、AWS クラウドの活用を「AI 技術を活用し、大きなビジネス価値を生み出すための布石」と位置づけ、AWS が長年の経験から得た知見と、なぜ今がクラウド移行のタイミングなのか、その背景と具体的なアプローチを示します。特に、AWS を活用することで得られる多くのベネフィット、移行のためのベストプラクティスおよび、それを支援するためさまざまな支援プログラムについても詳しく解説します。 実践知が詰まった 6 つのトラック 今回のイベントでは、以下の 6 つのトラックをご用意しています: Microsoft トラック : Windows Server、SQL Server、.NET アプリケーションなどの運用最適化について、セキュリティ強化やコスト最適化を含む包括的な方法論を解説します。AWS Transform for .NET による生成 AI を活用した革新的なアプローチも紹介し、デジタルトランスフォーメーションを成功に導くための知見をお届けします。 VMware トラック : 先日 一般提供を開始 した Amazon EVS による迅速なマイグレーション手法から、AWS Transform for VMware を活用した革新的アプローチ、コンテナ化によるモダナイゼーションまで、包括的なソリューションを提供します。特化したツールや移行プログラムを活用し、コストとリスクを最小限に抑えた確実な移行方法を学べます。 SAP トラック : 数千を超えるお客様が AWS で SAP ワークロードを実行している理由と、ミッションクリティカルなワークロードの運用方法を解説します。SAP のマイグレーションにおける実績のあるアプローチ方法、SAP データ分析のためのモダンアーキテクチャや生成 AI 活用のアプローチなど、SAP システムの価値を最大化する方法を学べます。 Oracle トラック : ミッションクリティカルな Oracle 環境のマイグレーションについて、Amazon RDS、Amazon Aurora、Amazon EC2、Oracle Database@AWS など、多様な選択肢から最適な移行戦略を学べます。AWS の強力なインフラを活用し、セキュリティとスケーラビリティを確保しながらコスト効率を実現する具体的な方法を紹介します。 AWS テクノロジートラック : マルチアカウント環境でのガバナンスや、オブザーバビリティ（監視）、生成 AI による開発プロセスの改善など、実際の開発・運用現場で使える実践的な技術を紹介します。人の活動を支えるサービスにフォーカスを当て、Amazon Q Developer を活用した効率的な開発・運用方法を提供します。 お客様事例トラック : Microsoft や VMware、SAP、Oracle など、AWS への大規模なマイグレーションを成功させた実例から、推進体制の構築やセキュアな移行の実現方法を学べます。将来を見据えたモダナイゼーション戦略まで、実際の経験に基づく実践的な知見を得られます。 明日のイノベーションは、今日の一歩から テクノロジーの変化が加速する中、「変化への対応」と「イノベーションの実現」は避けて通れない課題となっています。AWS Innovate は、その解決の糸口を見つけられる絶好の機会です。一般的に組織の変化はテクノロジーの変化に比べてゆっくりとしか進みません。だからこそ、今から準備を始めることが重要です。より有意義な時間となるよう、自身や自社のマイグレーションおよびモダナイゼーションの状況を棚おろししていただくと同時に、実際に AWS のコンソール からサービスを立ち上げて触ってみていただけると、当日の理解がより深まると思います。 本ブログを通じて、 AWS Innovate: Migrate and Modernize に少しでも興味を持っていただけた方は、ぜひ イベントページ から登録いただけると幸いです。当日はチャット形式のライブ Q＆A も実施しますので、具体的なクラウド移行やモダナイゼーションの戦略、AWS サービス等についての疑問点、お悩みなどもお気軽にお寄せください。みなさまと会話できることを楽しみにしております！ ソリューションアーキテクト 志村

本記事は KINTO テクノロジーズ (KTC) の AI ファースト Group による寄稿です。 はじめに KINTO テクノロジーズ (以下 KTC) は、クルマのサブスクリプションサービス「KINTO」をはじめとするさまざまなモビリティサービスを展開している トヨタ関連グループ会社です。近年、生成 AI の急速な発展により、ビジネスプロセスの自動化や顧客体験の向上が可能になってきました。KTC でもこの技術革新の波に乗り、 Amazon Bedrock を活用した AI エージェント開発・共有基盤「KTC Agent Store」を構築しました。 本記事では、KTC Agent Store の概要、技術的特徴、そして実際の活用事例について紹介します。 KTC Agent Store とは KTC Agent Store は、AI エージェントを開発・共有するためのプラットフォームです。このプラットフォームにより、開発チームは以下のことが可能になります。 主な機能 AI エージェントの新規開発とデプロイ ：AI エージェントを効率的に開発し、AWS クラウド環境にデプロイできる AI エージェントテンプレートの公開・共有 ：開発された AI エージェントのテンプレートを社内で公開・共有できる AI エージェントテンプレートの再利用 ：公開・共有された AI エージェントテンプレートをダウンロードし、新たなプロジェクトで再利用できる 業務面での価値 KTC では、AI エージェントを大きく 2 種類に分類しています。 パーソナライズ系エージェント は個人作業向けで、Excel 処理やメール作成など日常業務の効率化に役立ちます。Microsoft Copilot などの個人アシスタントも利用しますが、特定業務に特化した専門の AI エージェントを併用することで、業務の生産性をさらに向上できます。 業務システム系エージェント は業務向けでバックエンドで動作し、顧客対応や内部業務処理の自動化、データ分析や意思決定支援などの機能を提供します。 KTC Agent Store により、このような様々なタイプの AI エージェントを開発・利用するための基盤が整いました。これらのエージェントをKTC Agent Store で効率的に開発・共有することで、様々な業務シーンでの AI 活用が可能になります。 例えば、以下のようなユースケースに対応できます。 「私は 40 代、年収 xxx、お勧めの車プランを教えてください」 このような顧客からの問い合わせに対して、パーソナライズされた回答を提供する AI エージェントを簡単に構築できるようになります。 KTC Agent Store v1.0 の開発 KTC Agent Store v1.0 として、 Amazon Bedrock Agents を活用して AI エージェントを開発・共有するプラットフォームを開発しました。 狙う効果 KTC Agent Store v1.0 の導入により、以下の効果を狙っています。 開発期間の短縮 ：従来は数週間かかっていたエージェント開発が、数日で完了できます。 再利用性の向上 ：共有テンプレートを活用することで、類似機能の実装時間が大幅に削減されます。 運用コストの削減 ：Amazon Bedrock の従量課金モデルにより、必要な時に必要なだけリソースを使用します。 なぜ Amazon Bedrock を選んだのか？ AI エージェント開発基盤の構築にあたり、Amazon Bedrock を選択した主な理由は以下の通りです。 ローコード開発の実現 ：Amazon Bedrock Agents の機能により、複雑な AI エージェントの作法と AI モデルの知識がなくても、ビジネスロジックに集中してエージェントを開発できます。 セキュリティとガバナンス ：Amazon Bedrock に組み込まれた Guardrails 機能により、AI エージェントへの入力と出力を制御し、企業のセキュリティポリシーに準拠した運用が可能です。 既存 AWS インフラとの統合 ：KTC ではすでに多くのシステムを AWS 上で運用しており、Amazon Bedrock を活用することで既存システムとの連携が容易になります。 スケーラビリティ ：Amazon Bedrock の従量課金モデルにより、利用量に応じた柔軟なスケーリングが可能です。 KTC Agent Store v1.0 のアーキテクチャ KTC Agent Store v1.0 は、以下のサービスを組み合わせて構築されています。 Amazon Bedrock ：基盤となる AI エージェントプラットフォーム AWS Lambda ：エージェントの処理ロジックを実装 Amazon Elastic Container Registry ：Docker イメージのリポジトリ AWS CloudFormation, AWS Serverless Application Model (SAM) ：インフラストラクチャのコード化 Amazon S3 ：インフラストラクチャのスタック管理 GitHub リポジトリ ：ソースコードとエージェントテンプレートの保存 GitHub Actions ：CI/CD パイプライン 利用イメージ 社内のだれでも Agent の新規作成とリリースができる 開発者は Agent Store 上で AI エージェントの Base テンプレートを取得する。 取得した Base テンプレートをカスタマイズし、必要な lambda を作成する。 GitHub Actions を実行し、Bedrock Agents をデプロイする。 社内のだれでも作成した Agent を公開できる 開発者は開発した AI エージェントのテンプレートファイルを作成し、Github 上の Agent Store に Pull Request する。 Agent Store の管理者は、PR を承認し、マージする。 社内のだれでも Agent を取得し再利用できる 開発者は Agent Store 上に公開された AI エージェントテンプレートを取得する。 開発者は取得した AI エージェントテンプレートをベースに編集と加筆する。 GitHub Actions を実行し、Bedrock Agents をデプロイする。 メリット 簡単な AI エージェント作成 Amazon Bedrock Agents をベースにしているため、ローコードかつローコストで AI エージェントを実装できます。専門的な AI 知識がなくても、テンプレート機能により、ビジネス部門のメンバーや一般的な開発スキルを持つエンジニアでも、短時間でエージェントの作成から展開までを完結できます。 # エージェント定義の例 (簡略化) AWSTemplateFormatVersion: '2010-09-09' Transform: AWS::Serverless-2016-10-31 Resources: SuperAgentResource: Type: AWS::Bedrock::Agent Properties: AgentName: !Ref SuperAgentName FoundationModel: "anthropic.claude-3-5-sonnet-20240620-v1:0" Instruction: "あなたは人事面談結果をラベリングし、レポートを作成するエージェントです。入力された人事面談結果の Excel ファイルパスに基づき、人事面談結果をラベリングするエージェントを呼び出し、ラベリングされたファイルパスをレポートを作成するエージェントに渡し、レポートを作成する" Description: "人事面談の結果を処理するスーパーバイザーエージェントです。" AgentCollaboration: "SUPERVISOR" AgentResourceRoleArn: !Ref SuperAgentRole GuardrailConfiguration: GuardrailIdentifier: !Ref CommonGuardrail GuardrailVersion: !Ref CommonGuardrailVersion AgentCollaborators: - AgentDescriptor: AliasArn: !GetAtt HumanLabelingAgentRelease.AgentAliasArn CollaborationInstruction: "人事面談結果をラベリングする。具体的にラベリング、課題抽出と解決策を出力する。出力されたファイルパスを返す。" CollaboratorName: "labelingagent" - AgentDescriptor: AliasArn: !GetAtt HumanReportAgentRelease.AgentAliasArn CollaborationInstruction: "人事面談結果のレポートを作成するエージェントです。入力された人事面談結果を、ラベリングされたファイルパスに基づいて、グループごとの課題と解決策のレポートを作成する。" CollaboratorName: "reportagent" GuardrailConfiguration: GuardrailIdentifier: !Ref CommonGuardrail GuardrailVersion: !Ref CommonGuardrailVersion Tags: AgentStoreTemplate: "supervisor-agent" SuperAgentRelease: Type: AWS::Bedrock::AgentAlias Properties: AgentAliasName: "human-supervisor-agent" AgentId: !Ref SuperAgentResource Description: "人事面談結果を処理するスーパーバイザーエージェントバージョン1です。" 以上のように、マルチエージェントのオーケストレーション部分は Python 等でのコーディングを必要とせず、定義を記述するだけで実装できます。開発チームは、Lambda 関数で実装するビジネスロジックに集中することができます。 このアプローチによって、AI エージェント開発の民主化を実現し、専門知識を持たないチームメンバーでも開発に参加できるようになりました。その結果、組織全体での AI 活用が加速し、専門チームへの依存度が低下したことで、アイデア構想から実装までのリードタイムを短縮することに成功しています。 簡単なデプロイとプロビジョニング CI/CD とプロビジョニングには、KTC で標準で利用している GitHub Actions、AWS SAM を利用しています。これにより、開発チームは既存の知識を活かしながら、容易にキャッチアップして実装できます。 # GitHub Actions ワークフローの例 (簡略化) name: Deploy_Agent run-name: ${{ github.workflow }} / deploy (${{ inputs.env }}) on: workflow_dispatch: inputs: env: description: "デプロイ環境(dev/stg/prod)" required: true default: "dev" type: choice options: - dev - stg - prod working_directory: description: 'directory to run sam deploy' required: false default: './sam' sam_version: description: 'sam version' required: false default: '1.134.0' jobs: Deploy: runs-on: ubuntu-latest timeout-minutes: 15 environment: ${{ github.event.inputs.env }} defaults: run: working-directory: ${{ github.event.inputs.working_directory }} steps: - name: Checkout uses: actions/checkout@v4 - name: Setup Python uses: actions/setup-python@v3 - name: Setup SAM uses: aws-actions/setup-sam@v2 with: sam-cli-version: ${{ inputs.sam_version }} - name: Setup AWS Credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ secrets.AWS_ASSUME_ROLE_ARN }} aws-region: ${{ vars.AWS_REGION }} - name: SAM Build shell: bash run: sam build - name: SAM Deploy shell: bash run: sam deploy --config-env ${{ github.event.inputs.env }} --no-confirm-changeset --no-fail-on-empty-changeset 既存システムとの容易な統合 AWS 上で作成したエージェントは、既存システムの AWS バックエンドから簡単に呼び出すことができます。これにより、段階的な導入や既存サービスの強化が可能になります。 # AWS SDK を使用したエージェント呼び出しの例 import boto3 from botocore.config import Config config=Config(read_timeout=1000) if __name__ == "__main__": agent_id = "YOUR_AGENT_ID" agent_alias_id = "YOUR_AGENT_ALIAS_ID" user_input = "人事面談結果ファイル\"人事ダミーデータ.xlsx\" に対して、ラベリングして、レポートを作成してください" bedrock_agent_runtime = boto3.client('bedrock-agent-runtime', config=config) response = bedrock_agent_runtime.invoke_agent( agentId=agent_id, agentAliasId=agent_alias_id, sessionId='session-' + str(hash(user_input))[:8], inputText=user_input ) event_stream = response['completion'] for event in event_stream: if 'chunk' in event: data = event['chunk']['bytes'].decode('utf-8') print(data) 責任ある AI KTC の Security CoE グループと Cloud Infra グループにより、Bedrock Guardrails を活用した「CommonGuardrail」が提供されています。この標準ガードレールは、KTC セキュリティ基準を満たしており、エージェント作成時にデフォルトで適用されます。これにより開発チームは、セキュリティの専門知識がなくてもガードレールを適用するだけで、企業のセキュリティポリシーに準拠した安全な AI エージェントを構築することができます。 # Guardrails 設定の例 (簡略化) Resources: SuperAgentResource: Type: AWS::Bedrock::Agent Properties: AgentName: !Ref SuperAgentName FoundationModel: "anthropic.claude-3-5-sonnet-20240620-v1:0" Instruction: "あなたは人事面談結果をラベリングし、レポートを作成するエージェントです。入力された人事面談結果の Excel ファイルパスに基づき、人事面談結果をラベリングするエージェントを呼び出し、ラベリングされたファイルパスをレポートを作成するエージェントに渡し、レポートを作成する" Description: "人事面談の結果を処理するスーパーバイザーエージェントです。" AgentCollaboration: "SUPERVISOR" AgentResourceRoleArn: !Ref SuperAgentRole GuardrailConfiguration: GuardrailIdentifier: !Ref CommonGuardrail GuardrailVersion: !Ref CommonGuardrailVersion AgentCollaborators: - AgentDescriptor: AliasArn: !GetAtt HumanLabelingAgentRelease.AgentAliasArn CollaborationInstruction: "人事面談結果をラベリングする。具体的にラベリング、課題抽出と解決策を出力する。出力されたファイルパスを返す。" CollaboratorName: "labelingagent" - AgentDescriptor: AliasArn: !GetAtt HumanReportAgentRelease.AgentAliasArn CollaborationInstruction: "人事面談結果のレポートを作成するエージェントです。入力された人事面談結果を、ラベリングされたファイルパスに基づいて、グループごとの課題と解決策のレポートを作成する。" CollaboratorName: "reportagent" Tags: AgentStoreTemplate: "supervisor-agent" 実際の活用事例 KTC では、Agent Store v1.0 を活用して、1 週間で以下の AIO エージェントを開発・展開しました。 AIO エージェント 生成 AI 時代の到来により、従来の SEO 戦略では限界が見えてきました。ChatGPT や Claude 等の生成 AI が検索行動を変化させ、ユーザーは直接 AI に質問して答えを得るようになっています。この新しい検索パラダイムに対応するため、 AIO (AI Optimization) という新たな最適化手法が求められています。 企業が早期に AIO 対応を始める際の課題 企業が AIO 対応を始める際に、現状では以下のような課題があります。 AIO (AI 最適化) 手法の未確立: どうすれば自社の情報を生成 AI に引用されやすくなるのか、確立された具体的な手法が存在しない 効率的な分析: ユーザーの検索行動はキーワード (点) ベースからトピック (面) ベースに変わるため、トピックを全てカバーしようとすると調査分析のコストが激増 AIO-Agent は、上記の生成 AI 時代の SEO 課題に対応すべく開発された、マーケティング・SEO 分析自動化エージェントです。 AI エージェントによる統合分析体験 4 つの Lambda 関数が連携する統合型エージェントとして、プロンプト生成から分析結果の解釈・アドバイスまでをエージェントが一貫して実行します。従来膨大な時間がかかると思われる SEO/AIO 分析業務を、自然言語での指示だけで数分で完了し、エージェント自身が結果を読み込んで具体的なアドバイスを提供します。 トピックごとのプロンプトを生成 AI で素早く作成 GPT などにプロンプトを自動に送信 回答文について再度生成 AI で AIO の観点で評価し、示唆も同時に生成 ( LLM-as-a-Judge を参考) 分析結果を表形式で Amazon S3 に格納 AI エージェントが過去の分析結果を読み込み、AIO についてのアドバイスを自然言語で提示 シームレスな分析体験を提供 実際の利用時には、ユーザーは自然な会話形式で AIO エージェントと対話するだけで、複雑な分析プロセスを意識せず、価値のあるインサイトを得ることができます。 ユーザー : 「AIO 分析をお願いします」 AIO-Agent : 「分析が完了しました。アピール度は 6.2 点、競合優位性は 4.8 点でした。特に料金面での競合優位性に課題があります。詳しい改善提案を聞きたいですか？」 ユーザー : 「料金面の改善について詳しく教えてください」 AIO-Agent : 「分析結果によると、月額料金の訴求が不十分です。具体的には…」 AIO エージェントの処理の流れ 1 AIO エージェントの処理の流れ 2 今後のロードマップ 私たちは段階的に KTC Agent Store の機能を拡張していく予定です。 現在 (v1.0) Single-Agent と Multi-Agent 対応 基本的なエージェント開発・デプロイ機能 次期バージョン (v2.0) フルプロビジョニング IAM Permission Boundary を使った IAM 権限管理 Agent Store OSS 版 Amazon Bedrock AgentCore に基づく OSS 版 AI エージェントの対応 認証認可 Observability Bedrock Agents + Bedrock Knowledge Base ナレッジデータベースとの連携強化 将来計画 (v3.0) MCP と A2A への対応 Model Context Protocol 対応と Agent-to-Agent 通信の実現 まとめ KTC Agent Store v1.0 は、Amazon Bedrock を活用した AI エージェント開発・共有プラットフォームとして、開発効率の向上、再利用性の促進、責任ある AI を実現しています。このプラットフォームにより、当社は AI エージェントの開発・展開を加速し、ビジネス価値の創出を期待できます。 Amazon Bedrock の柔軟性と拡張性を活かした KTC Agent Store v1.0 は、今後の AI 活用の基盤として、さらなる進化を続けていきます。私たちは、このプラットフォームを通じて、KTC のサービスをより魅力的で効率的なものにし、お客様により良い体験を提供できることを楽しみにしています。 本記事は、AWS プリンシパル ソリューション アーキテクトの國政が担当しました。

はじめに AWS Billing and Cost Management Model Context Protocol（MCP）サーバー の導入により、モダンなクラウドチームで FinOps 機能を活用するのがさらに簡単になりました。これにより、お好みの AI アシスタントやチャットボットが高度なコスト分析と最適化機能を直接利用できるようになります。MCP サーバーは、自然言語クエリ、安全なローカル認証情報や AWS アカウントのコストと使用状況データへのリアルタイムアクセスを統合することで、複雑なコンソールを操作したり、カスタムスクリプトを作成したりすることなく、インタラクティブにコストを分析し、節約の機会を特定し、詳細な FinOps 監査を実行できるようにします。先月の最も支出の多いサービスについて尋ねる場合でも、リソースを最適化するための実行可能な推奨事項を探す場合でも、これらの機能はコストの透明性と運用効率性を合理化し、クラウドの財務管理をより迅速かつ簡単にします。 Billing and Cost Management MCP サーバーの仕組み Billing and Cost Management MCP サーバー（billing-cost-management-mcp-server）は、AI エージェントがリアルタイムにデータソースに接続するための標準化された方法を提供します。これは、AI アシスタントとAWS Cost Explorer、AWS Cost Optimization Hub、AWS Compute Optimizer、Savings Plans、AWS Budgets、Amazon S3 Storage Lens や AWS Cost Anomaly Detection との架け橋となることで機能します。MCP サーバーは、自然言語による質問を変換し、要件を解析し、関連サービスへ問い合わせ、複数のサービスからの出力を処理して、わかりやすい回答をまとめて提供します。 なぜ使うのか？ クラウドコストを管理していて、より少ない労力でよりスマートな財務上の意思決定を行うことを目指しているなら、Billing and Cost Management MCP サーバーは生産性を向上させるために必要なツールです。このツールを使うことで、お好みの AI アシスタントやチャットボットを通じて、AWS のコスト分析および最適化機能に直接アクセスできます。つまり、コンソールを操作したり、カスタムスクリプトを書いたりすることなく、自然言語で尋ねるだけで複雑なコストクエリを実行できるということです。あなたがクラウド財務アナリスト、クラウドアーキテクト、DevOps エンジニア、または FinOps チームの一員であるかどうかにかかわらず、支出を監視し、節約の機会を特定し、そしてクラウドリソースを効率的に運用し続けることが容易になります。AWS の財務データへのリアルタイムアクセス、予算の使用状況に対する透明性の向上、またはすぐに実践できる実用的な洞察などのメリットがあります。Billing and Cost Management MCP サーバーは、ワークフローを合理化し、詳細なコスト分析をより迅速かつ利用しやすくすることで、クラウドの財務管理をコントロールできるようにします。 開始方法 Amazon Q Developer CLI、Claude Desktop、Kiro やその他の MCP 互換ツールなどさまざまな MCP ホストが billing-cost-management-mcp-server を利用できます。この投稿では、Amazon Q Developer CLI の例に焦点を当てます。 前提条件 AWS アカウントで Cost Explorer が有効になっていること AWS Command Line Interface (AWS CLI) をインストールし、AWS CLI で AWS アカウントへ アクセスできる こと AWS Identity and Access Management (IAM) ユーザー がこのブログに記載されているサービスの権限をもっていること IAM 権限に 最小権限の原則 を適用していること （オプション） Amazon Q for command line がインストールされていること。インストール前に、 サポートされているコマンドライン環境 を参照してください Astral か GitHub README から uv をインストールしていること uv python install 3.12 を使用して Python をインストールしていること 必要なサービスにアクセスできるように AWS クレデンシャルを設定していること MCP クライアントの設定に MCP サーバーを追加していること Storage Lens Storage Lens のデータを使用する MCP ツールの呼び出しでは、以下も必要です。 エクスポートが有効化された Storage Lens ダッシュボード： Storage Lens ダッシュボードの設定がメトリクスのエクスポートを有効にしていること エクスポートは、CSV または Parquet フォーマットで S3 バケットに書き込めるように設定されていること AWS 権限： マニフェストとデータファイルを読み取るための S3 権限 データベースおよびテーブルの作成とクエリ実行できる Athena 権限 Athena カタログのための Glue 権限 MCP クライアントの設定で MCP サーバーの設定をしてください。Amazon Q Developer CLI では ~/.aws/amazonq/mcp.json ファイルに追加します。 For Linux/MacOS Users: { "mcpServers": { "awslabs.billing-cost-management-mcp-server": { "command": "uvx", "args": [ "awslabs.billing-cost-management-mcp-server@latest" ], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_PROFILE": "your-aws-profile", "AWS_REGION": "us-east-1" }, "disabled": false, "autoApprove": [] } } } JSON For Windows Users: { "mcpServers": { "awslabs.billing-cost-management-mcp-server": { "command": "uvx", "args": [ "--from", "awslabs.billing-cost-management-mcp-server@latest", "awslabs.billing-cost-management-mcp-server.exe" ], "env": { "FASTMCP_LOG_LEVEL": "ERROR", "AWS_PROFILE": "your-aws-profile", "AWS_REGION": "us-east-1" }, "disabled": false, "autoApprove": [] } } } JSON その他 Docker デプロイメントやチーム用の IDE については、AWS MCP Servers GitHub リポジトリのインストールガイドを参照してください。 コストに関する考慮事項 AWS サービスの API では、リクエストごとに料金が発生します。この MCP サーバーによって行われる各 API 呼び出しは、AWS アカウントに請求されます。最新の価格情報については、それぞれのサービス API 料金を確認してください。 例 現在の AWS サービスのコスト使用状況はどうなっていますか？ 図 1：現在の AWS サービスのコスト使用状況を示す MCP の応答 コスト最適化の推奨事項を取得して、最も節約できる推奨事項の詳細を表示してください 図 2：最も節約できる最適化の推奨事項を示す MCP の応答 すべての AWS リージョンの支出を比較してください 図 3： AWSリージョン全体での支出を示す MCP の応答 AWS 支出に大きな変化や変動がないかを特定、定量化するために、2025 年 6 月から 7 月のコストを比較分析してください 図 4：2025 年 6 月から 7 月までのコストを比較した MCP の応答 既存の AWS ワークロードを Graviton ベースのインスタンスへ移行した場合のコスト節約の可能性を評価してください 図 5：Graviton コストに関する MCP の応答 2025 年 7 月にコストが増加した理由を見極めるために分析を実施し、根本原因を特定してください 図 6：コスト増加原因を示す MCP の応答 過去 6 か月間の S3 ストレージの GB/月あたりのコストを教えてください 図 7：GB/月あたりの S3 のコストを示す MCP の応答 最も容量の大きい S3 バケットについて、関連するコストの詳細な内訳を含む包括的なコスト分析を生成してください 図 8：S3 の包括的な分析結果を示す MCP の応答 図 9：S3 の包括的な分析結果を示す MCP の応答 以下の例では、MCP クライアント内での詳細なツールの使用方法を示しており、さまざまな連携した機能がどのように包括的な対応を生み出すかを示しています。さらに、Claude Desktop を通じて MCP サーバーを活用すると、結果をより視覚的にわかりやすく表現できるようになり、AWS サービスを利用する開発者へよりリッチなインタラクティブ体験を提供できます。 過去数か月間のコストデータを分析してナラティブにまとめてください、IT および財務のリーダーシップ向けの 2 つのパラグラフのレポートを準備します。レポートには、コスト傾向、大きな変化の原因、コストの異常、予算に対する追跡方法およびコストを最適化して削減できる機会について含める必要があります 図 10：ナラティブレポート作成のための詳細なツール呼び出しを示す MCP プロンプトと応答 図 11：MCP の追加のツール呼び出し応答 Claude Desktop（Sonnet 4 利用） 先月の vCPU 時間あたりの EC2 コストはいくらでしたか？ 図 12：vCPU 時間を示す Claude Desktop からの MCP の応答 Pricing ツールを使って、これらの vCPU 数をダブルチェックできますか？ 図 13：vCPU の料金を含む Claude Desktop からの MCP の応答 いいですね、この分析を過去 6 か月間分繰り返しできますか？ 図 14：6 か月の期間を分析した Claude Desktop からの MCP の応答 素晴らしいです、これを折れ線グラフにできますか？ 図 15：vCPU 時間あたりのコストグラフを示す Claude Desktop からの MCP の応答 結論 AWS Billing and Cost Management MCP サーバーは、クラウド財務管理を大きく進歩させるものです。AWS の強力なコスト分析および最適化ツールと自然言語 AI アシスタントを結びつけます。これにより、複雑なコストクエリが簡単になり、FinOps ワークフローがスピードアップします。また、コストの透明性も向上し、リアルタイムのインサイトや実用的な推奨事項に簡単にアクセスできるようになります。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトです。この役職では、Adam は AI コスト最適化と FinOps プラクティスを専門としています。Amazon Q Business や Amazon Q Developer などの顧客向け機能の作成に貢献したほか、AWS re:Invent やその他の業界イベントで講演者として専門知識を頻繁に共有しています。Adam はまた、FinOps Foundation の AI ワーキンググループで AWS を代表して、AI における財務業務に関する幅広い議論に貢献しています。 Aneesh Varghese Aneesh Vargheseは、情報技術業界で 19 年以上の経験を持つ AWS のシニアテクニカルアカウントマネージャーです。Aneeshは、コスト最適化戦略、クラウド運用、MLOps について企業顧客をサポートし、AWS のベストプラクティスを利用したソリューションの計画と構築に役立つ提言や戦略的技術ガイダンスを提供します。仕事以外では、Aneesh は家族と時間を過ごしたり、バスケットボールやバドミントンをしたりするのが好きです。

本記事は、2025 年 8 月 26 日に公開された Zero-ETL: How AWS is tackling data integration challenges を翻訳したものです。翻訳は Solutions Architect の下佐粉が担当しました。 このブログ投稿では、 Amazon Web Services (AWS) がZero-ETL によってデータ統合をシンプルにしつつ、パフォーマンスの向上とコスト最適化を実現する方法をご紹介します。組織がアナリティクスと AI のためにデータを収集する中で、従来のデータ統合の中心である抽出、変換、ロード (ETL)のパイプラインは複雑化しています。これらのパイプラインの構築と維持は、イノベーションに費やすべき貴重なスタッフの時間とリソースを消費する、コスト要因にもなっています。AWS では Zero-ETL 統合を提供することによって、企業のデータ統合の取り扱いをシンプルなるよう支援します。Zero-ETL は、運用データベースとデータウェアハウス、データレイク、そしてこれらを組み合わせたレイクハウスなどの分析環境との間のシームレスなデータフローを維持しながら、データパイプライン維持の負担を軽減することができます。 数千もの AWS のお客様が、ペタバイト規模のデータを zero-ETL で処理しています。AWS のお客様は、 Amazon Aurora 、 Amazon Relational Database Service (Amazon RDS) 、 Amazon Redshift 、 Amazon DynamoDB 、 Amazon SageMaker などのサービスとの Zero-ETL 統合、およびサードパーティー SaaS アプリケーションとの Zero-ETL を活用しています。これら Zero-ETL による統合によって、データ統合は技術的な負担ではなく戦略的な強みとなり、企業はデータから実用的なインサイトを導き出すことに注力できるようになります。 データ統合の進化と課題 従来、組織は運用データベースと分析システム間のデータ移動に ETL パイプラインを構築してきました。この手法は機能的ではありますが、組織がデータからタイムリーな洞察を得ることを妨げる、いくつかの重要な課題があります。 ETL パイプラインの構築と保守には多大なエンジニアリングリソースが必要で、多くの場合、人材がコアビジネスの施策から離れざるを得なくなります。これらのパイプラインは、継続的なモニタリング、更新、最適化が必要で、運用の負担が続きます。データ量が増加し、更新が頻繁になり、スキーマが進化するにつれて、これらのパイプラインの複雑さは指数関数的に増大します。 パイプラインの障害はデータの可用性に遅延を引き起こし、意思決定プロセスに影響を与える可能性があります。パイプラインが障害を起こした場合、問題の診断と修正に数時間から数日かかることがあり、その間、重要なビジネス上の意思決定が古い情報に基づいて行われる可能性があります。このデータ作成から分析可能になるまでのタイムラグは、変化の激しい業界において大きな競争上の不利となる可能性があります。 複雑なデータ変換は潜在的な障害ポイントを生み出し、データの不整合が発生するリスクを高めます。各変換ステップは、変換ロジックのバグやデータの予期せぬエッジケース（滅多に発生しない状態）により、エラーが発生する可能性があります。これらの変換全体でデータの品質と一貫性を確保するには、厳密なテストと検証プロセスが必要です。 さらに、組織が新しいデータソースを追加するにつれて、複数のパイプラインを管理する運用オーバーヘッドは急激に増加します。通常、新しいソースごとに、抽出、変換、ロードのためのカスタムロジックを備えた独自のパイプラインが必要になります。このようなパイプラインの増加は、すぐに管理が困難になり、組織全体で一貫したデータ戦略を維持することを難しくします。 Zero-ETL によるデータ分析の実現 AWS zero-ETL 統合は、AWS サービスとサードパーティアプリケーションの両方から、AWS のデータウェアハウス、データレイク、レイクハウスへのデータレプリケーションを、自動化された完全マネージド型で提供し、カスタムパイプラインの開発を不要にします。この新たなアプローチは、複数の重要な領域にわたって多くのメリットを提供し、組織のデータ統合へのアプローチを根本的に変革します。 データアーキテクチャの簡素化 Zero-ETL 統合は、ローコードまたはノーコードのセットアップを提供するため、組織は専門的な知識がなくても迅速にデータアクセスとフローを確立できます。このデータ統合の民主化により、組織全体のチームが独自のデータ統合を設定・管理できるようになり、インサイト獲得までの時間が短縮されます。 Zero-ETL 統合は、データ定義言語 (DDL)、スキーマの変更、データ型のマッピングを自動的に処理するため、分析ストア内のデータが正確かつ完全な状態に保たれます。このデータはビジネスでの利用にすぐに使用でき、ソースシステムとターゲットシステム間の一貫性を確保するのに役立ちます。この自動マッピングにより、手動マッピングプロセスで発生する可能性のあるエラーのリスクが大幅に軽減され、システム間でデータ型と構造が正しく変換されることが保証されます。 組み込みのモニタリングとエラー処理機能により、レプリケーションプロセスの状況を把握できるようになり、データの整合性維持に役立ちます。管理者は、レプリケーションの遅延や転送の失敗などの特定の条件に対してアラートを設定でき、データ統合プロセスの予防的な管理が可能になります。 Zero-ETL 統合は、フルロードと CDC (Change Data Capture) による継続的な変更を自動的に処理し、最新のデータへの迅速なアクセスを実現します。組織はこの二重の機能を活用して、既存のデータを移行しながら、新しいデータが継続的にレプリケートされることを確認でき、新しい統合モデルへのシームレスな移行を実現できます。 ニア・リアルタイム分析 Zero-ETL 統合では、通常、ソースシステムの更新から数秒または数分以内にターゲットシステムでデータを利用できるようになります。このほぼリアルタイムの機能は、大量のトランザクションワークロードにも対応し、急速に変化するビジネスにタイムリーなインサイトを提供します。例えば、E コマース企業は購買パターンをほぼ即座に分析でき、リアルタイムの在庫管理やパーソナライズされたレコメンデーションを実現できます。 このソリューションは、データ量が増加しても性能を低下させることなく、一貫したパフォーマンスを維持します。ビジネスが成長しデータ量が増加しても、Zero-ETL 統合は自動的にスケールすることで、システムへの要求が増加に対応します。 組み込みのフォールトトレランスと回復メカニズムにより、高可用性とデータの一貫性を確保します。レプリケーション中に問題が発生した場合、失敗した操作の手動または自動リトライにより、最後の正常地点から再開することで、データ損失を最小限に抑え、ソースシステムとターゲットシステム間の一貫性を確保できます。 運用負荷の削減 カスタムパイプラインのメンテナンスが不要になることで、Zero-ETL 統合は貴重なエンジニアリングリソースを解放します。データエンジニアは、定期的なパイプラインのメンテナンスに時間を費やすのではなく、データモデリング、高度な分析、機械学習などのより価値の高いタスクに集中できます。 追加のインフラストラクチャを管理する必要がないため、複雑さとコストが削減されます。Zero-ETL 統合は AWS が管理するインフラストラクチャ上で実行されるため、データ統合のためにサーバー、ストレージ、ネットワークコンポーネントをプロビジョニングおよび管理する必要がありません。 システムは、スキーマの変更を自動的に処理し、人の介入なしでデータ構造の変化に対応します。例えば、ソーステーブルに新しいカラムが追加された場合、Zero-ETL 統合は自動的にこの変更を検出し、それに応じてターゲットスキーマを更新し、データの同期を維持します。 AWS のセキュリティ機能との統合により、レプリケーションプロセス全体を通じてデータを保護することができます。これには、保管時および転送時の暗号化のサポート、さらに各種規制基準に準拠するための AWS Key Management Service (AWS KMS) との統合が含まれます。 Zero-ETL によるお客様の成功事例 ローンチ以来、Zero-ETL 統合は急速に採用が進んでいます。Zero-ETL 統合の汎用性とメリットは、様々な業界における顧客の導入事例を通じて実証されています。 大手グローバル決済ソリューションプロバイダーである MassPay のペイメントシステムアーキテクチャ部門ディレクターの Yossi Shlomo 氏は、次のように述べています。「Zero-ETL は MassPay のチームに変革をもたらしました。 Amazon Aurora MySQL 互換エディション と Amazon Redshift の zero-ETL 統合を使用することで、コアペイメントシステムから不正検出、コンプライアンスケース管理、ビジネスインサイトに使用される分析環境へのデータフローを効率化しました。この移行によりレイテンシーが 90% 以上削減され、チームはプロセスと意思決定を最適化するための重要なデータにほぼ瞬時にアクセスできるようになりました」。このデータの鮮度と可用性の劇的な改善により、MassPay はより迅速で十分な情報に基づいた意思決定を行うことができ、顧客へのサービスと市場での競争力を向上させています。 Zero-ETL で統合可能な AWS サービス AWS は現在、人気の AWS データベースサービスと、フルマネージド型データウェアハウスサービスの Amazon Redshift をシームレスに接続するためのZero-ETL 統合を提供しています。これには、Amazon Aurora MySQL 互換エディション、Amazon Aurora PostgreSQL 互換エディション、Amazon RDS for MySQL、Amazon RDS for Oracle 、Amazon DynamoDB が含まれます。つまり、組織は各サービスの強み（ Aurora と Amazon RDS のトランザクション機能、DynamoDB の柔軟性、Amazon Redshift の分析能力）を活用しながら、これらのシステム間のデータ移動の複雑さを最小限に抑えることができます。 サードパーティ統合のサポート Zero-ETL 統合は AWS サービスを超えて、幅広いサードパーティのデータもサポートするようになりました。AWS は、SAP OData、Salesforce、Salesforce Marketing Cloud Account Engagement、ServiceNow、Zendesk、Zoho CRM、さらに Facebook Ads や Instagram Ads などのソースと Zero-ETL 統合 を提供しています。ターゲットには、Amazon Redshift や Amazon SageMaker を使用したレイクハウス が含まれます。 最近の更新内容は以下の通りです: AWS Glue が Amazon DynamoDB と 8 つの SaaS アプリケーションから Amazon S3 テーブルへのZero-ETL 統合をサポート開始 Amazon Aurora MySQL と Amazon RDS for MySQL の Amazon SageMaker との統合が利用可能に さまざまなベンダーの従来のリレーショナルデータベースも、Zero-ETL 統合を通じてレイクハウスに連携できます。この包括的なサポートにより、組織はカスタム統合パイプラインを構築することなく、多様なソースからのデータを AWS 分析環境に統合できます。Zero-ETL を使用して、複数のベンダーソリューション間のデータサイロを解消し、データ統合プロセスを簡素化することで、組織は複雑なデータパイプラインの管理ではなく、インサイトの導出に注力できます。 より多くの AWS サービスとデータソースをサポートするための追加の統合機能が開発中であり、エコシステムをさらに拡大する予定です。AWS は、お客様のニーズとデータ環境の進化に対応して、Zero-ETL 統合の範囲を継続的に拡大することにコミットしています。 Zero-ETL の高度な機能 AWS のZero-ETL 機能には、高度な機能が含まれています。例えば、更新間隔コントロールを使用することで、データの同期頻度をカスタマイズでき、各ユースケースに必要な最新のデータに基づいて分析を行うことができます。一方、履歴モードではデータの過去のバージョンを保持し、トレンド分析、インサイトに富んだダッシュボード作成、監査要件への対応を可能にします。また、Amazon Redshift で Slowly Changing Dimension (SCD) Type 2 テーブルを作成することもできます。 データフィルタリング機能を使用して、特定のオブジェクトやデータサブセットを選択的にレプリケートし、ストレージの使用を最適化し、関連性の高いデータに焦点を当てることができます。包括的なロギングとモニタリング機能により、データの移動状況とシステムの状態を可視化できるため、管理者は問題を迅速に特定して対処できます。 2 つの主要な統合アプローチを組み合わせることもできます。Zero-ETL は包括的な分析のために完全なデータレプリケーション (移動) を提供し、一方でフェデレーションも提供しており、これはソースデータへのリアルタイムアクセスが重要な場合にデータをその場で照会することを可能にします。この柔軟性を活用して、組織固有のニーズとユースケースに合わせてデータ統合戦略を決めることが可能になります。 Zero-ETL の使用開始 Zero-ETL 統合の利用を開始するには、まずソースデータベースとターゲットの分析サービスを特定する必要があります。これには、現在のデータアーキテクチャを評価し、Zero-ETL アプローチが最も効果的なデータフローを判断することが含まれます。 次に、必要な権限とネットワーク要件を設定する必要があります。これには通常、 AWS Identity and Access Management (IAM) の設定、または AWS IAM Identity Center を使用したシングルサインオンの設定、そしてソースとターゲットのサービスが安全に通信できることを確認することが含まれます。 前提条件が整っていれば、次の画像に示すように、AWS 管理コンソール 内で簡単に Zero-ETL 統合を作成できます。直感的なインターフェイスがプロセスをガイドし、ソースとターゲットの詳細の指定、レプリケーション対象のテーブルの選択、追加オプションの設定を促します。 セットアップ後は、円滑な運用を確保するために、レプリケーションのステータスとパフォーマンスを監視できます。AWS は、Zero-ETL 統合の健全性とパフォーマンスを追跡するために、詳細なメトリクスとログを提供します。 詳細なセットアップ手順については、各サポートされている統合のステップバイストップガイドを提供している zero-ETL 統合の AWS ドキュメント をご覧ください。 Zero-ETL の今後の展望 AWS は、追加の AWS サービスとデータソースのサポートに向けたロードマップを積極的に取り組んでおり、Zero-ETL 統合の範囲を拡大することで、より多くのお客様がより広範なユースケースでシンプルなデータ統合のメリットを享受できるようにします。 Zero-ETL 統合は、組織がデータ統合にアプローチする方法の根本的な変化です。ETL パイプラインの複雑さがないため、お客様はインフラストラクチャの管理ではなく、データから価値を引き出すことに集中できます。このアプローチは、クラウド運用を簡素化し、お客様がより迅速なイノベーションを可能にするという AWS のコミットメントに沿っています。 Zero-ETL 統合の詳細と、そのメリットについては、以下のトピックをご覧ください。 Aurora のZero-ETL 統合については、Zero-ETL 統合の 利点 、 主要な概念 、 制限事項 、 クォータ 、 サポートされているリージョン をご覧ください Amazon RDS のZero-ETL 統合については、Zero-ETL の 利点 、 主要な概念 、 制限事項 、 クォータ 、 サポートされているリージョン をご覧ください DynamoDB のZero-ETL 統合については、 DynamoDB と Amazon Redshift のZero-ETL 統合 をご覧ください アプリケーションとのZero-ETL 統合については、 Zero-ETL 統合 をご覧ください AWS のZero-ETL 統合を使用して、データ運用を効率化し、データの可能性を最大限に引き出す方法を、今すぐ始めてみましょう。 Nikki Rouda は AWS のプロダクトマーケティングに従事しています。IT インフラストラクチャ、ストレージ、ネットワーキング、セキュリティ、IoT、アナリティクス、モダンアプリケーションなど、幅広い分野で長年の経験を持っています。

エンタープライズのコンタクトセンターでは、独立した IT および運用チームを持つ複数の事業部門 (LOB) をサポートするのに苦労しています。特にビジネスプロセスアウトソーサー (BPO) では、独自の要件を持つ数百の顧客を管理するため、この複雑さがさらに増大します。コンタクトセンターの移行パターンにより、これらの課題に対処し、デプロイメントを加速し、運用を簡素化することができます。 この投稿では、中規模から大規模なコンタクトセンターの移行において堅牢な基盤を構築する、実証済みの 5 つのパターンについて説明します。これらのパターンの実装には初期投資が必要ですが、全体的な移行スケジュールを加速させるでしょう。 移行の困難さ 架空の企業 AnyCompany で考えてみましょう。この会社は 7 つの LOB を運営しています。4 つの LOB はあるレガシープラットフォーム上で稼働していますが、最近の合併により取得した 3 つの LOB は異なるシステム上で運営されています。同社のサポート体制は 2 つの IT チームと 3 つの運営チームにまたがっており、それぞれがそれぞれのレガシープラットフォームを専門としています。 AnyCompany は、レガシープラットフォームのコストを削減し、安全でスケーラブルなクラウドベースのコンタクトセンターで改善された顧客体験を提供するため、7 つの LOB すべてを Amazon Connect に移行することを決定しました。同社は多くの組織で直面する優先順位付けのジレンマに直面しています。スピードと完璧さ、変革と基本的な移行のバランスを取り、特定のレガシーコンポーネントを維持するか、新規に構築するかを決定する必要があります。 AnyCompany は、まず小規模な LOB の 1 つから移行することを選択しました。移行初期では、各リージョンにおける開発、テスト、ステージング、本番環境全体で設定、フロー、統合を管理するためのパターンを確立する必要があります。レガシープラットフォームの 1 つは独自技術を使用しているので、サポートチームは移行後のコンタクトセンターをサポートするためスキルアップが必要です。 移行を加速するアクセラレーターパターン アクセラレーターパターンは、3つの基本的な原則に基づきます。 再発明よりも再利用を：再利用可能なコンポーネントを構築することで、チームは機能を一度開発すれば、コンタクトセンターの複数の領域にそれを適用できます。これは、開発時間を短縮し、一貫性を推進できます。 モノリスよりもモジュール性を：モジュラー設計により、複雑なシステムを管理可能な部品に分割し、チームが独立してそれぞれを実装および保守できるようにします。このアプローチは俊敏性を向上させ、移行プロセス中のリスクを軽減します。 カスタマイズではなく設定を：テンプレートベースの設計により、固有のケースを処理するためにコードではなく設定を定義して、全体的な作業を削減します。このアプローチは柔軟性を維持しながら、カスタム開発を最小限に抑えます。 パターン #1 – 設定可能な CX インターフェース Amazon Connect は、企業が重要なコンタクトセンターコンポーネントを設定できる包括的なネイティブユーザーインターフェースを提供します。これには、 キュー 、 ルーティングプロファイル 、 ユーザー管理 、 セキュリティ 設定、および自動化された フロー からエージェントとのやり取りまで、顧客体験を構築するための直感的なドラッグアンドドロップインターフェースが含まれます。エンタープライズ規模のコンタクトセンターでは、通常、フロー内に複数のエントリーポイントが実装されます。言語選択、顧客識別、認証、意図の取得、ルーティングなどのコアコンポーネントは、類似するパターンに従います。ただし、各体験は、問い合わせ属性と Amazon DynamoDB に保存されたデータを使用して動的にパーソナライズされます。またデプロイ後も、ビジネスチームは、緊急アナウンス、特別メッセージ、言語更新など、フロー動作に対して稼働中に変更を行う俊敏性を必要とします。組織はまた、開発、テスト、ステージング、本番環境全体にわたる堅牢な設定管理も必要とします。 パターン #2 – エージェント体験のインターフェース Amazon Connect には、 エージェントワークスペース と呼ばれるすぐに使えるエージェント用の問い合わせ処理機能(機能統合されたエージェントアプリケーション)があります。この統合されたデスクトップインターフェースにより、エージェントは単一のインターフェースから顧客プロファイル、やり取りの履歴、ナレッジベースにアクセスしながら、音声、チャット、タスクにわたる顧客とのやり取りを管理できます。このシステムには、コラボレーションツール、多言語サポート、リアルタイムパフォーマンスダッシュボードが含まれています。 ほとんどの企業顧客は、要件を満たすためにこのエージェントワークスペースを設定します。しかし、企業は Amazon Connect SDK と API を使用してカスタムコントロールパネルを構築することもできます。このオプションを選択する顧客は、エージェントワークスペースでネイティブに準備された機能を再構築する必要があります。エージェント体験を極度にパーソナライズする必要がある一部の顧客にとってはこの重い作業が必要になる場合もあり、このパターンではマイクロアプリケーションアーキテクチャを使用して異なる LOB 間で再利用できるように構築します。各機能を独立したマイクロアプリケーションとして機能し、分離された開発を可能にします。組織は、ニーズに基づいて特定の機能をデプロイし、コード変更ではなく設定を通じてそれらをカスタマイズします。 このアクセラレーターパターンは、自動デプロイメントを通じてカスタマイズされたエージェントインターフェースの開発時間を数か月短縮します。これにより LOB 間で一貫したエージェント体験が可能になり、大幅な再トレーニングなしにエージェントや担当者の共有が可能になります。モジュラー設計により、デスクトップ、ネットワーク、サーバーサイドの問題に対して単一のアプリケーションフットプリントを提供することで、トラブルシューティングも簡素化されます。このパターンを使用する組織は、時間の経過とともに機能を追加する柔軟性を維持しながら、より高速な機能開発サイクルとゼロダウンタイムを実現しました。 パターン #3 – コンタクトセンターの開発・運用・セキュリティ (DevSecOps) グローバル企業のコンタクトセンターでは複数の リージョン が必要な場合や、また複数の環境（開発、テスト、ステージング、本番）のプロビジョニングが必要な場合があります。コンタクトセンターのワークロードでは、Amazon Connect と併せて 10 以上の AWS サービスを使用することがあります。複数のインスタンスとサービスにわたって迅速にイノベーションを行うため、組織は自動化されたデプロイメントプロセスと一貫した環境設定を計画します。他のクラウドアプリケーションと同様に、標準化された DevSecOps アプローチ により、設定のドリフトやセキュリティ脆弱性のリスクを軽減しつつ、新機能の導入までの時間を改善できます。 このパターンでは、Amazon Connect デプロイメント向けに設計された DevSecOps フレームワークを実装します。 AWS Cloud Development Kit (CDK) などのデプロイメントツールを使用した Infrastructure as Code テンプレートを提供します。また、Amazon Connect インスタンス、フロー、 AWS Lambda 関数、および関連する AWS サービスのデプロイメントと設定を自動化する事前構築済みパイプラインも含まれています。このパターンは、デプロイメントパイプラインのすべての段階にセキュリティコントロール、テスト戦略、および自動検証を組み込みます。このパターンの主要コンポーネントには、Amazon Connect インスタンス管理、設定、および環境固有のインフラのデプロイ用のモジュラーコードリポジトリが含まれます。このパターンは、環境間での一貫した配信を確保するブランチング戦略、コードプロモーションワークフロー、および開発者ガイドラインも提供します。（これはレガシー技術でしばしば問題となっていた）環境間でのコードと設定の伝播をカバーし、品質とセキュリティコンプライアンスを向上させながら、LOB 実装あたりの技術基盤構築時間を数週間短縮します。 このアクセラレーターパターンは、組織が環境間での一貫性を維持しながら、機能デプロイメントを加速し、人的エラーを削減することを可能にします。モジュラー設計により、チームは既存のツールと成熟度レベルに基づいて、コンポーネントを段階的に採用できます。組織が複数の事業部門にわたって Amazon Connect フットプリントを拡張する際に効果的にスケールする、反復可能なフレームワークを提供します。 パターン #4 – モニタリングと運用の自動化 AWS サービスは、メトリクスとログを Amazon CloudWatch に公開します。このデータを表示および分析して、重要な運用メトリクスを監視し、アラームを設定できます。大規模なコンタクトセンターでは、サービス、インスタンス、リージョン全体にわたる監視が運用上の優秀性を維持するために必要です。従来のプラットフォームでは、コンタクトセンターのインフラストラクチャ全体の可視性に苦労することが多く、対症療法的な問題解決と長い解決時間につながっていました。企業は、顧客体験に影響を与える前に潜在的な問題を事前に特定しながら、複数の事業部門にわたってサービスレベル契約 (SLA) を維持する必要があります。 このパターンでは、コンタクトセンターインフラストラクチャ全体の可視性を提供する設定ベースの監視・アラート基盤を実装します。Amazon CloudWatch を基盤として使用し、カスタムメトリクスと Amazon Simple Notification Service を通じた自動アラートで機能を強化します。このパターンには、ヘルスメトリクス、ビジネスメトリクス、カスタマーエクスペリエンス指標の高レベルビューと詳細ビューの両方を提供する事前構築されたダッシュボードが含まれます。設定可能な通知チャネル（メール、SMS、Slack）を使用したしきい値ベースのアラート機能をサポートし、重要な問題に対するエスカレーション管理システムが含まれています。主要コンポーネントを AWS Cloud Development Kit(CDK) などの Infrastructure as Code としてパッケージ化し、環境やリージョン間での一貫したデプロイメントを可能にします。ビジネスチームは、長い待機時間、キューのあふれ、またはカスタマーエクスペリエンスに影響を与えるエラーを監視するためにこれらを使用できます。IT チームは、AWS Lambda 関数の障害、API レイテンシ、音声品質スコア、バックエンド接続エラーなどのシステムレベルメトリクスを監視し、異常を検出および予測するために使用できます。 このパターンで、監視機能を確立するために必要な時間を短縮し、通常は実装あたり数週間の開発工数を節約できます。プロアクティブな問題検出と解決を可能にし、すべての事業部門で高いサービスレベルを維持するのに役立ちます。このソリューションのモジュラー設計により、組織は必要最小限の監視設定から開始し、音声品質監視やサードパーティのチケットシステムとの統合などの高度な機能を段階的に追加できます。組織が追加の事業部門を Amazon Connect に移行する際に効果的にスケールする標準化された監視アプローチを提供できるのも重要な点です。 パターン #5 – 音声およびチャットのチューニングと最適化 セルフサービスのユースケースで 会話型 AI を実装するコンタクトセンターは、音声およびチャット実装が最適なパフォーマンスを維持できるよう管理する必要があります。チャットボットの実装では、効率的な顧客体験を推進し、ライブエージェントへのエスカレーションを回避するために、十分なサンプル発話、重複しないインテント、適切なエラーハンドリングが必要です。専門家による会話インターフェースの手動最適化は、専門家にとって付加価値の低い作業となる可能性があり、組織が最適なパフォーマンスを維持することがコスト的に困難になります。 このパターンでは、チャットおよび音声セルフサービス体験の分析とチューニングを自動化する最適化フレームワーク（多くの場合、 生成 AI を活用 ）を実装します。このソリューションは、AWS の専門知識と実世界の実装から得られたベストプラクティスの厳選されたナレッジベースを使ってボットの設定を分析するため、基盤モデルを活用します。インテント、サンプル発話、スロット設定、エラーハンドリング戦略の自動分析が含まれます。インタラクティブな Web インターフェースと既存の CI/CD パイプラインとの統合の両方を通じて実用的な推奨事項を提供します。継続的な最適化フェーズで、ボットの定義や設定を処理します。 このパターンによって、ボットの最適化時間を数日から数分に短縮し、高品質を維持しながら長時間の専門コンサルテーションの必要性やコストを最小限に抑えます。組織が深い技術的専門知識を必要とせずに最適なパフォーマンスを維持できるようにしながら、すべての会話インターフェースでベストプラクティスの一貫した適用を可能にします。インテントの混乱、不十分なトレーニングデータ、不適切なエラーハンドリングなどの一般的な問題を防ぐのに役立ちます。このパターンを使用している組織では、セルフサービスのパフォーマンスの向上とセルフサービスでの解決率の増加を確認し、同時にエージェントへのエスカレーションを削減しました。 考慮事項とアイデア 前のセクションで挙げた各パターンについて、その価値と必要な投資を評価することをお勧めします。すべてのアクセラレーターパターンがあらゆる組織に適合したり、必要になったりするとは限りません。アクセラレーターが適合する場合、組織には以下の選択肢があります : AWS Professional Services と連携して、数百の組織のコンタクトセンター変革のために提供される事前構築済みアクセラレーターを実装する。これは、追加の継続的なコストなしに、これらのアクセラレーターを社内で所有、保守、拡張する意欲と専門知識を持つ顧客に適しています。 月額継続コストで利用できる Software as a Service モデルを使用して、類似のアクセラレーターパターンを提供する Amazon Connect パートナーを探す。このオプションは、社内でのソフトウェア開発と保守の専門知識が限られている顧客に適しています。 社内で構築する。Amazon Connect は他の AWS サービスとともに、この拡張性を促進する豊富な API セットを提供します。 他にもアクセラレーターパターンのアイデアとして、自動化された機能テストおよび負荷テストツール、ルーティング設定変更の影響を検証するルーティングシミュレーションツール、復旧運用の自動化、生成 AI ベースのフローのドキュメント化などがあります。コンタクトセンターのクラウドへの移行を設計する際に、追加のパターンを特定する可能性があります。 結論 この投稿では、5 つの移行パターンについて説明しました。設定可能な CX インターフェース、エージェントエクスペリエンス インターフェース、DevSecOps、監視と運用の自動化、音声とチャットのチューニングです。再利用性、モジュール性、設定駆動型アプローチに焦点を当てることで、AnyCompany は移行の複雑さを軽減し、後続の事業部門での価値実現までの時間を短縮しました。チームのスキル、予算、目標に適したアプローチを選択しましょう。これらのパターンは、クラウドネイティブなコンタクトセンターにおける継続的な改善とイノベーションの基盤を築き、技術の進歩に AnyCompany が適応し、優れた成果を上げられるようになりました。 Amazon Connect では、使用した分だけお支払いいただきます。初期費用、長期契約、最低月額料金はありません。セットアップにサポートが必要な場合は、 AWS Professional Services からサポートを受けることができます。また、世界中で利用可能な  Amazon Connect パートナー からサポートを求めることもできます。 Amazon Connect でカスタマーサービス体験を変革する準備はできていますか？ お問い合わせください 。 筆者について Parind Poi は AWS プロフェッショナルサービスのシニアプラクティスリーダーです。彼は AWS のカスタマーエクスペリエンス (CX) に関する深い専門知識を持ち、専門業務をリードしています。Parind は、お客様がクラウド上でカスタマーエンゲージメントワークロードを最新化できるよう支援することに情熱を注いでいます。 Prashant Desai は AWS プロフェッショナルサービスのプリンシパルコンサルタントです。彼は大規模なコンタクトセンターの設計とクラウドへの移行の経験があります。25 年を超えるレガシー、クラウド両方のコンタクトセンターの経験があります。Prashant は、顧客体験をシンプルで革新的にする方法を常に模索しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

この記事は、2025 年 8 月 4 日に Raghava Kumar Vemu によって執筆された「 Begin your AWS journey with new free AWS Builder Labs learning plan on AWS Skill Builder 」を翻訳したものです。 実践的な Amazon Web Services (AWS) スキルをハンズオンで学習したいとお考えですか ? 本日、10 個の基礎レベルのハンズオンラボが含まれた、新しい学習プランである Introduction to AWS Cloud: Builder Labs Learning Plan (日本語版) の無料提供を発表します。AWS クラウド学習の旅を開始する準備をしましょう。 ※ こちらの無料学習プランは 2025 年 11 月 2 日までの期間限定アクセスです。 クラウド専門家にとって、AWS サービスでの実践経験は成功の鍵となります。理論的な知識も大切ですが、実際の AWS 環境でのハンズオン体験に勝るものはありません。この新しい学習プランは、基本的な AWS サービスをカバーするガイド付きハンズオン体験を提供し、AWS クラウドのインフラストラクチャ基盤、セキュリティとアイデンティティ管理、モダンアプリケーション開発の知識を強化することで、このニーズに応えています。これらのコースは、業界で重要視されている基本的な AWS スキルの習得に役立ちます。 無料学習プランに含まれる内容 Introduction to AWS Cloud: Builder Labs Learning Plan (日本語版) 学習プランは、基本的な AWS サービスを使った 10 のハンズオンラボで構成されており、様々な概念の理解を深めることができます。実際の AWS 環境でステップバイステップの手順に従いながら、実践的なスキルを身につけ、ソリューションを構築・テストします。 Introduction to Amazon Virtual Private Cloud (VPC) (日本語): このラボでは Amazon Virtual Private Cloud (Amazon VPC) を紹介します。このラボでは、Amazon VPC ウィザードを使用して VPC を作成し、インターネットゲートウェイをアタッチし、サブネットを追加し、サブネットとインターネットゲートウェイ間でトラフィックが流れるように VPC にルーティングを定義します。 Introduction to Amazon Simple Storage Service (S3) (日本語): Amazon Simple Storage Service (Amazon S3) は、業界をリードするスケーラビリティ、データ可用性、セキュリティ、パフォーマンスを提供するオブジェクトストレージサービスです。このラボでは、AWS マネジメントコンソールを使用して Amazon S3 の基本的な機能について学習します。 Introduction to Amazon EC2 (日本語): このラボでは、Amazon EC2 インスタンスの起動、サイズ変更、管理、モニタリングの概要を学習します。Amazon Elastic Compute Cloud (Amazon EC2) は、クラウド内でコンピューティング性能を変更できるウェブサービスです。Amazon EC2 を使用すると、開発者は高いスケール性を持ったクラウドコンピューティングを簡単に利用できるようになります。 Introduction to AWS Identity and Access Management (IAM) (日本語): AWS Identity and Access Management (IAM) は、お客様が AWS にアクセスできるユーザーと、そのユーザーのアクセス許可を管理できるウェブサービスです。IAM を使用すると、ユーザー、アクセスキーなどのセキュリティ認証情報、およびユーザーがどの AWS リソースにアクセスできるかをコントロールするアクセス許可を一元的に管理できます。 Introduction to AWS Key Management Service (日本語): このラボでは、AWS Key Management Service (AWS KMS) を学習します。AWS KMS の使用を開始するために必要な基本ステップを学習し、キーの作成、キーの管理と使用権限の割り当て、データの暗号化、キーのアクセスと使用のモニタリングを行います。 Performing a Basic Audit of your AWS Environment (日本語): このラボでは、主要な AWS リソースに基本的な監査を実行します。AWS マネジメントコンソールを使って複数の AWS サービス (Amazon EC2、Amazon VPC、Amazon IAM、Amazon Security Groups、AWS CloudTrail、Amazon CloudWatch など) を監査する方法を学習します。 Introduction to Amazon DynamoDB (日本語): Amazon DynamoDB は、1 桁ミリ秒台の一貫したレイテンシーを必要とする、あらゆる規模のアプリケーションに対応した、高速かつ柔軟な NoSQL データベースサービスです。このラボでは、Amazon DynamoDB にテーブルを作成し、音楽ライブラリに関する情報を保存します。 Introduction to Amazon CloudFront (日本語): このラボでは、Amazon CloudFront の基本について学習します。URL に CloudFront ドメイン名を使用して Amazon Simple Storage Service (Amazon S3) バケットに保存されているパブリックアクセス可能な画像ファイルを配信する、Amazon CloudFront ディストリビューションを作成します。 Introduction to AWS Lambda (日本語): このラボでは、イベント駆動型の環境で Lambda 関数を作成するために必要なステップを学習します。AWS Lambda は、イベントに応じてコードを実行し、コンピューティングリソースを自動的に管理するサーバーレスコンピューティングサービスです。 Introduction to Amazon API Gateway (日本語): このラボでは、シンプルな FAQ マイクロサービスを作成します。このマイクロサービスでは、AWS Lambda 関数を呼び出す Amazon API Gateway エンドポイントを使用して、ランダムな質問と回答のペアを含む JSON オブジェクトが返されます。 自分のペースで学習できます 実践的なクラウドスキルを構築したい場合でも、ハンズオン学習で AWS 認定対策をしたい場合でも、これらの基礎的なラボで着実に経験を積むことで、実際の開発・運用に向けた準備に役立ちます。学習プランは柔軟性を重視して設計されており、以下のことが可能です : 興味に応じて好きな順序でラボを完了 自分のペースで実践 ラボを繰り返し再試行および再実行 カリキュラムを通じて進捗を追跡 開始方法 ハンズオンで AWS 学習を始めてみませんか ? 無料の Introduction to AWS Cloud: Builder Labs Learning Plan (日本語版) にアクセスして、いますぐ実践的なクラウドスキルの学習を開始しましょう。AWS Builder Labs でのハンズオン学習を通じて、クラウドスキルを向上させている何千人もの学習者の仲間入りを果たしましょう。 ハンズオンおよび体験学習をさらに推進するために、 AWS Skill Builder の個人またはチームサブスクリプションに登録し、200 の Builder Labs 、200 の SimuLearns 、17 の Jam Journeys の完全なカタログにアクセスしてください。 (2025 年 8 月 27 日現在) 翻訳は Technical Instructor の 西村 諄 が担当しました。

本記事は米国時間 8 月 22 日に公開された「 Important Kiro pricing updates 」を翻訳したものです。Kiro の最新情報は、 https://kiro.dev/ をご覧ください。 価格設定についてお知らせがあります。 リクエストが誤ってカウントされる計測バグを修正しました まず、多くの人が、リクエストの消費の早さに驚かれていることをお聞きしました。私たちも驚きました！Kiro で価格設定を展開した際に、一部のタスクが不正確に複数のリクエストを消費するバグを導入していたことが判明しました。多くの方が経験された予期しない使用量の急増を引き起こしていた計測問題の修正をデプロイしました。 8 月の制限をリセットしました また、現在の制限では有意義な作業を行うのに十分な余裕がないという懸念もお聞きしました。これの多くは、ユーザーが意図したよりも早く制限を使い切ってしまう原因となっていた計測問題から来ていると考えています。そのため、プランに含まれる制限もリセットしました。Kiro をどのように使用されているか、現在のプランがどの程度機能しているかを理解したいと思います。 システムを注意深く監視しています。新しいバグが発生した場合は、引き続き調整を行い、必要に応じて制限をリセットします。 8 月に発生した料金を返金します バグによって生じた混乱を考慮し、8 月分の料金は請求しないことに決定しました。返金は 8 月 25 日（月）から順次実施されます。以下は返金、制限、8月の無料使用に関する FAQ です。追加のご質問がございましたら、 Discord でのディスカッションにご参加ください 。 サポートとフィードバックをありがとうございます ここ数日がスムーズではなかったことを承知しており、これを軽く考えていません。私たちの最優先事項は、価格設定だけでなく、実際の有意義な作業に頼れる Kiro を構築することです。私たちと共に歩み、フィードバックを共有し続けてくださりありがとうございます。お試しいただく際のご意見をお聞かせください。 FAQ お客様への返金はいつ、どのように行われますか？ サブスクリプション料金の返金は 8 月 25 日（月）から順次実施されます。 超過料金も返金されますか？ 既に超過料金が発生している場合は、それらも返金いたします。 お客様の使用量はいつ、どのようにリセットされますか？ 無料プランと有料プランの両方の使用制限がリセットされました。無料プランユーザーは 100 vibeリクエストと 100 specリクエストにリセットされます。有料プランユーザーは購入したプランの日割り制限にリセットされます。 今日サブスクリプションを購入した場合、9 月 1 日まで無料になりますか？ 8 月 31 日より前にサブスクリプションを購入した場合、8 月 31 日まで無料で使用でき、月末までにサブスクリプション料金を返金いたします。 「8 月無料」はどのように機能しますか？ 既に有料プランをご利用の場合、制限がリセットされ、8 月 31 日まで日割り制限内で Kiro を無料で使用し続けることができます。 現在から 8 月 31 日までの間に有料プランを購入する場合、有効なクレジットカードを提供する必要があり、購入したプランの価格と適用される税金および手数料が請求されます。その後、購入から数日以内に 8 月 31 日までに返金いたします。アップグレードした日割りプラン制限内（例：Pro+ の場合、日割りで 450 vibeリクエストと 250 specリクエスト）で Kiro を無料で使用できます。未使用のリクエストは翌月に繰り越されません。 8 月中は、プランの制限を超えて（追加料金なしで）使用することは可能ですか？ はい、 超過料金 を有効にできます。超過料金は一時的に 1,000  vibeリクエストと 200  specリクエストに制限されています。超過料金でクレジットカードに請求された場合、8 月末に返金いたします。 Kiro の使用で既に請求されている有料顧客として、外国為替手数料で損失を出さないよう、既存の 8 月の支払いを 9 月の前払いとして使用することを選択できますか？ 現在これは不可能です。8 月分は返金されます。 まだ存在する既知の計測問題は何ですか？ 以下は、私たちが認識し積極的に対処している既知の請求の不一致です。より迅速にブロックを解除するため、現在制限をリセットしましたが、今後数日でこれらのケースに対処する際に、これらの誤カウントされたリクエストがリクエストプールにクレジットバックされることを保証します。これらの変更を行う際にお知らせします。 tasks.md ファイルで実際に「Start task」をクリックするのではなく、チャットウィンドウで「Execute task X」と入力すると、spec リクエストに加えて追加の vibe リクエストが請求されます。 サブタスクを持つタスク（例：タスク 2 にサブタスク 2.1 と 2.2 がある場合）で、親タスク（例：タスク 2）をクリックすると、追加の vibe と追加のspec リクエストが請求されます。現在の回避策として、代わりにサブタスクをクリックできます。 エージェントが連続してツール呼び出しに失敗した場合（独自のツールまたは MCP ツール）、追加の vibe リクエストが請求されます。

本投稿は 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 技術を実用的なビジネスチャンスへと変換することに情熱を注いでいます。