11 月 18 日、 Python および .NET 関数向けの AWS Lambda SnapStart の一般提供の開始を発表しました。これにより、関数の起動パフォーマンスが数秒からわずか 1 秒未満にまで高速化され、通常は Python、C#、F#、Powershell におけるコード変更が最小限またはまったく不要になります。 2022 年 11 月 28 日、 Java 関数向けの Lambda SnapStart をリリース し、起動パフォーマンスを最大 10 倍改善しました。Lambda SnapStart を使用すると、リソースをプロビジョニングしたり、複雑なパフォーマンス最適化の実装に時間を費やしたりすることなく、関数の初期化から生じる異常なレイテンシーを低減できます。 Lambda SnapStart は、1 回限りの初期化コード、または Lambda 関数が最初に呼び出されたときにのみ実行されるコードのスナップショットされたメモリとディスクの状態をキャッシュして再利用することで機能します。Lambda は、初期化された実行環境のメモリとディスクの状態の Firecracker microVM スナップショット を取得し、そのスナップショットを暗号化して、低レイテンシーのアクセスのためにキャッシュします。 関数バージョンを初めて呼び出し、その後呼び出しがスケールアップしていく中で、Lambda は最初から初期化するのではなく、キャッシュされたスナップショットから新しい実行環境を再開し、起動レイテンシーを改善します。Lambda SnapStart では、AWS Lambda を使用して、Python および .NET で高度にスケーラブルで応答性の高いアプリケーションを簡単に構築できます。 Python 関数の場合、初期化コードからの起動レイテンシーは数秒に及ぶ場合があります。これが発生する可能性があるシナリオには、依存関係のロード (LangChain、Numpy、Pandas、DuckDB など) やフレームワークの使用 (Flask や Django など) が含まれます。また、多くの関数は、Lambda を使用して機械学習 (ML) 推論も実行し、初期化中に ML モデルをロードする必要があります。このプロセスには、使用するモデルのサイズに応じて数十秒かかる場合があります。Lambda SnapStart を使用すると、これらのシナリオで起動レイテンシーを数秒からわずか 1 秒未満に低減できます。 .NET 関数の場合、.NET ジャストインタイム (JIT) コンパイルには最大数秒かかるため、ほとんどのユースケースで恩恵を享受できると考えています。Lambda 関数の初期化に関連するレイテンシーの変動性は、長年にわたって、お客様が AWS Lambda で .NET を使用する上での障壁となってきました。SnapStart を使用すると、メモリとディスクの状態のスナップショットをキャッシュすることで、関数を迅速に再開できます。そのため、ほとんどの .NET 関数では、Lambda SnapStart によってレイテンシーの変動性が大幅に改善されます。 Python および .NET 向けの Lambda SnapStart の開始方法 使用を開始するには、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して、Python および .NET 関数向けの SnapStart をアクティブ化、更新、および削除できます。 AWS Lambda コンソール で、 [関数] ページに移動し、Lambda SnapStart を使用する関数を選択します。 [設定] 、 [一般設定] 、 [編集] の順に選択します。 [SnapStart] の設定は、 [基本設定を編集] ページで確認できます。 Python 3.12 以降、および .NET 8 以降のマネージドランタイムを使用して、Lambda 関数をアクティブ化できます。 [公開バージョン] を選択し、 [保存] を選択します。 関数の新しいバージョンを公開すると、Lambda はコードを初期化し、初期化された実行環境のスナップショットを作成してから、低レイテンシーでのアクセスのためにスナップショットをキャッシュします。関数を呼び出して、SnapStart のアクティブ化を確認できます。 update-function-configuration コマンドを --snap-start オプションとともに実行して関数設定を更新する AWS CLI コマンドを次に示します。 aws lambda update-function-configuration \ --function-name lambda-python-snapstart-test \ --snap-start ApplyOn=PublishedVersions publish-version コマンドを使用して関数バージョンを公開します。 aws lambda publish-version \ --function-name lambda-python-snapstart-test get-function-configuration コマンドを実行してバージョン番号を指定することで、関数バージョンのために SnapStart がアクティブ化されていることを確認します。 aws lambda get-function-configuration \ --function-name lambda-python-snapstart-test:1 レスポンスで OptimizationStatus が On で、 State が Active であることが示されている場合、 SnapStart はアクティブ化されており、指定された関数バージョンのスナップショットを使用できます。 "SnapStart": { "ApplyOn": "PublishedVersions", "OptimizationStatus": "On" }, "State": "Active", AWS SDK、 AWS CloudFormation 、 AWS サーバーレスアプリケーションモデル (AWS SAM) 、 AWS Cloud Development Kit (AWS CDK) を使用してスナップショットをアクティブ化、更新、削除する方法の詳細については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart のアクティブ化と管理 」にアクセスしてください。 ランタイムフック ランタイムフックを使用すると、Lambda がスナップショットを作成する前、または Lambda がスナップショットから関数を再開した後に実行されるコードを実行できます。ランタイムフックは、クリーンアップオペレーションやリソース解放オペレーションの実行、設定や他のメタデータの動的な更新、通知の送信や外部状態の更新などの外部サービスやシステムとの統合、依存関係の事前ロードなどの関数の起動シーケンスのファインチューニングに役立ちます。 Python ランタイムフックは、Python マネージドランタイムに含まれるオープンソースの Snapshot Restore for Python ライブラリ の一部として使用できます。このライブラリは、Lambda がスナップショットを作成する前に実行されるデコレーター @register_before_snapshot と、Lambda がスナップショットから関数を再開するときに実行されるデコレーター @register_after_restore の 2 つを提供します。詳細については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart runtime hooks for Python 」にアクセスしてください。 チェックポイント作成前と復元後にコードを実行する方法を示す Python ハンドラーの例を次に示します。 from snapshot_restore_py import register_before_snapshot, register_after_restore def lambda_handler(event, context): # ハンドラーコード @register_before_snapshot def before_checkpoint(): # スナップショットを作成する前に実行されるロジック @register_after_restore def after_restore(): # 復元後に実行されるロジック また、 NuGet の Amazon.Lambda.Core パッケージ (バージョン 2.4 以降) の一部として使用できる .NET ランタイムフックを使用することもできます。このライブラリは、スナップショットの作成前に実行する RegisterBeforeSnapshot() と、スナップショットから関数を再開した後に実行する RegisterAfterRestore() の 2 つのメソッドを提供します。詳細については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart runtime hooks for .NET 」にアクセスしてください。 チェックポイント作成前と復元後にコードを実行する方法を示す C# ハンドラーの例を次に示します。 public class SampleClass { public SampleClass() { Amazon.Lambda.Core.SnapshotRestore.RegisterBeforeSnapshot(BeforeCheckpoint); Amazon.Lambda.Core.SnapshotRestore.RegisterAfterRestore(AfterRestore); } private ValueTask BeforeCheckpoint() { // スナップショットを作成する前に実行されるロジックを追加します return ValueTask.CompletedTask; } private ValueTask AfterRestore() { // スナップショットを復元した後に実行されるロジックを追加します return ValueTask.CompletedTask; } public APIGatewayProxyResponse FunctionHandler(APIGatewayProxyRequest request, ILambdaContext context) { // INSERT business logic return new APIGatewayProxyResponse { StatusCode = 200 }; } } お好みのランタイムのランタイムフックを実装する方法については、「AWS Lambda デベロッパーガイド」の「 Lambda 関数スナップショットの前後のコード実装 」にアクセスしてください。 知っておくべきこと Lambda SnapStart について知っておくべきことをいくつかご紹介します。 一意性の取り扱い – 初期化コードがスナップショットに含まれる一意のコンテンツを生成した場合、複数の実行環境で再利用されると、そのコンテンツは一意ではなくなります。コードが組み込みライブラリに依拠しないカスタム乱数生成を使用したり、初期化中に期限切れになる可能性のある DNS エントリなどの情報をキャッシュしたりする場合などにおいては、SnapStart を使用する際に一意性を維持するには、初期化後に一意のコンテンツを生成する必要があります。一意性を復元する方法については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart での一意性の取り扱い 」にアクセスしてください。 パフォーマンスのチューニング – パフォーマンスが最大限に発揮されるようにするには、関数ハンドラーではなく初期化コードで依存関係を事前ロードし、起動レイテンシーに影響するリソースを初期化することをお勧めします。これにより、大量のクラスロードに関連するレイテンシーが呼び出しパスから外れ、SnapStart による起動パフォーマンスが最適化されます。 ネットワーキングのベストプラクティス – Lambda がスナップショットから関数を再開する場合、初期化フェーズ中に関数が確立する接続の状態は保証されません。ほとんどの場合、AWS SDK が確立したネットワーク接続は自動的に再開されます。他の接続については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart パフォーマンスの最大化 」をご覧ください。 モニタリング関数 – Amazon CloudWatch ログストリーム、 AWS X-Ray アクティブトレース、ならびに Telemetry API 、 Amazon API Gateway 、および関数 URL メトリクスを使用した拡張機能のリアルタイムテレメトリデータへのアクセスを使用して、SnapStart 関数をモニタリングできます。SnapStart 関数の違いの詳細については、「AWS Lambda デベロッパーガイド」の「 Lambda SnapStart のモニタリング 」にアクセスしてください。 今すぐご利用いただけます Python および .NET 関数向けの AWS Lambda SnapStart は、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド)、欧州 (ストックホルム) の AWS リージョンで現在ご利用いただけます。 Python および .NET マネージドランタイムでは、2 種類の SnapStart 料金があります。すなわち、SnapStart を有効にした状態で公開する関数バージョンごとにスナップショットをキャッシュするコストと、関数インスタンスがスナップショットから復元されるたびにかかる復元コストです。そのため、SnapStart キャッシュコストを削減するには、 未使用の関数バージョンを削除 してください。詳細については、 AWS Lambda の料金 ページにアクセスしてください。 AWS Lambda コンソール で Python および .NET 向けの Lambda SnapStart をぜひお試しください。詳細については、 Lambda SnapStart のページ にアクセスしてください。また、 AWS Lambda の AWS re:Post または通常の AWS サポートの連絡先を通じてフィードバックをぜひお寄せください。 – Channy 原文は こちら です。

この記事は Building a Scalable Loss Prevention and Video Intelligence Service using AI and AWS (記事公開日: 2024 年 4 月 2 日) を翻訳したものです。 多くの防犯カメラシステムは、セキュリティインシデントが発生した際にアクセスされ、保険的な役割や予期せぬ事故に対する事後対策として機能します。 Solink は、ビデオ映像とトランザクションデータを組み合わせることで、よりプロアクティブな損失防止ソリューションを提供し、企業がコストを削減するインテリジェントな判断を行うことでリスクを評価し特定することを支援しています。 Solink は、Amazon Web Services (AWS) 上に構築された Video Security-as-a-Service (VSaaS) 製品であり、ビデオアノテーションなどの重要なタスクを自動化するために人工知能 (AI) を活用しています。このソリューションにより、顧客の取引監視能力、インサイトの収集、損失防止が大幅に向上しました。多くの企業にとって、Solink は 3 〜 5 倍の投資収益率をもたらしています。さらに、顧客は Solink のオファリングを利用して在庫ロスを管理し、最終的に削減することで、2 パーセントの利益増加を実現しています。 スケーラブルで安全な損失防止ソリューションを AWS で構築 Solink は、防犯カメラの映像と POS 取引、入退室管理、在庫、その他センサーなどのイベントとの照合を簡単にしています。同社の顧客の多くは小売店、レストラン、金融機関で、以前は防犯カメラの映像へのアクセスが限られており、多くの場合、インシデントが発生した際に事後的に映像を確認するだけでした。そして、最も重要なリスク要因を特定することが強固なセキュリティには不可欠ですが、そのために以前は何時間もの映像を手動で見る必要がありました。そこに Solink はイノベーションの機会を見出しました。 「私たちのアプローチは常にセキュリティを最優先にしており、ソリューションは常時稼働し、常に利用可能である必要があります」と Solink の副社長（セールス担当）である Jim Farrell 氏は述べています。「そして、それらの原則にイノベーションをもたらし、私たちが構築するすべてのものが簡単にアクセスでき、顧客に価値を提供できるようにしています。」 Solink の生み出したイノベーションのひとつが、クラウドベースの SaaS です。同社は、グローバルな顧客基盤にサービスを提供するために、スケーラブルで高可用性かつセキュアな基盤が必要だと認識し、AWS を選択しました。「 2015 年にプラットフォームの設計を始めた時、以前なら自分たちで構築しなければならなかった多くのインフラを AWS のサービスが提供してくれることがわかりました。高可用性とスケーラビリティが組み込まれています。」と Solink の最高技術責任者である Norm Wong 氏は述べています。 また、同社は継続的にデータを取り込んでいます。データの多くは、API やローカル統合を介したセンサー、その他のデバイスから直接送信されます。成長を続ける Solink は現在、40 か国以上にわたる数万の拠点から月間 10 億件のトランザクションを取り込み、関連付けを行っています。このデータをいつでも安全にクラウドで利用可能にすることは、リアルタイムのインサイトを提供するために必要不可欠です。 AI を活用してインテリジェントなセキュリティ監視を実現 Solink は、事実上あらゆるワークロードに対して安全で拡張可能なコンピューティング能力を提供する Amazon Elastic Compute Cloud (Amazon EC2) を使用しています。パイプラインは、ビデオと画像に各取引の時刻や日付、デバイスの場所といったコンテクストを付与し、検索可能にします。顧客がビデオにリモートでアクセスする際は、CDN の動作に似た安全なリレー技術を使用し、AWS リージョン間でビデオを配信することで遅延を最小限に抑え、セキュリティを維持しています。 30 万台以上の接続デバイスからなる現在のネットワークを管理するため、Solink はクラウド上で構造化データの設定、運用、スケーリングを簡単にする Amazon Relational Database Service (Amazon RDS) を使用しています。「 AWS サービスを通じて管理されているため、冗長性やデータベースのバックアップについて心配する必要がありません」と Solink のエンジニアリング部門 VP、Martin Soukup 氏は述べています。Solink の顧客は、ダッシュボードやウィジェットを通じてこのデータへ簡単にアクセスでき、データの表示やフィルタリング、パフォーマンスレポートの生成が可能です。そして、潜在的なセキュリティイベント（販売、ドライブスルー取引、配達など）を詳しく調査し、関連するカメラが撮影したビデオを視聴することができます。 AWS でセキュリティを強化しつつコストを削減 Solink を使用することで、企業は商品損失の削減から内部窃盗の減少まで、複合的な社内メリットを実現できます。「私たちの顧客は、自社のビジネスをよりよく理解できるようになります」と Farrell 氏は言います。「彼らはスタッフをより良くコントロールし、指導やトレーニングを行う能力が向上します。」 企業はまた、他の方法でも節約することができます。Solink のビデオアラームソリューションを使用することで、アラームが人によって引き起こされたかどうか、警察が対応すべきかどうかをより確実に判断できます。このシステムは、Amazon SageMaker を使用してカスタムモデルを構築し、高い信頼性を得ています。これにより、機械学習を用いた画像認識とビデオ分析を自動化し、そのコストを低減、従来の「センサー／パネル」ベースのオファリングを上回る性能を発揮します。結果として、Solink は企業に罰金をもたらす可能性がある誤報の確率を減少させます。そして、警察が呼ばれた際、ビデオ検証によって対応者がよりよく状況を理解できるため、Solink の顧客はしばしば対応時間の短縮を実感します。 さらに、米国の企業は、Solink に接続されたカメラと AI を使用して非常口の潜在的な障害物を特定することで、労働安全衛生管理局（OSHA）の規制遵守状態を改善しています。専用のシステムを購入すると何十万ドルもかかる可能性がありますが、Solink はこの機能を組み込み機能として提供しています。 AWS で Solink の SaaS を継続的に強化 AWS において、Solink は事実上シームレスなスケーラビリティを実現しました。これは、インフラ管理やコストを心配することなく、顧客の需要に応じて成長し続けられることを意味します。同社は、セキュリティにおけるイノベーションの探求を続けており、生成 AI テクノロジーを使用して新しいオファリングを構築しています。その一例が 2023 年に発表された Solink Sidekick AI です。 「私たちのシステムのスケーラビリティは、使用量に基づいて成長します」と Soukup 氏は述べています。「多くのサービスをオンデマンドで利用できるようになったことで、従来よりもはるかに速くソフトウェアを採用し、実装する自由が得られました。」 Solink の詳細はこちらをご覧ください。 著者について Martin Soukup Martin Soukup は Solink Corporation でエンジニアリングと DevSecOps を率いています。現在の彼の焦点は、サイバーセキュリティ、IT/OT の融合、そして SaaS と IoT における AI/ML の経験を VSaaS の世界にもたらすことです。Martin は 25 年以上の R&D 経験を持ち、サイバーセキュリティ分野で 17 年、ビデオ分野で 18 年、AI/ML 分野で 10 年の経験があります。彼は電子設計、組み込みソフトウェア、高性能ネットワーキング、クラウド、データ分析、機械学習産業において大規模なチームを率いてきました。また、約 10 年間倫理的ハッキングチームを率い、10 代の頃に最初のハックを書きました。彼はスタートアップを運営し、世界中のフォーチュン 500 企業や中規模企業でリーダーシップの役割を担ってきました。Martin はリバプール大学で情報技術の修士号（コンピューターセキュリティ）を、カールトン大学で心理学の学士号を取得しています。また、ブリティッシュコロンビア大学、カリフォルニア大学バークレー校、ウォートンスクールオブビジネスでも学んでいます。Martin は様々な業界イベントやフォーラムでサイバーセキュリティトピックや技術トレンドについて講演した経験があり、多数の学術論文や業界出版物を持ち、robots.txt、IETF、IEEE、ITU-T、Java、W3C 規格に貢献しています。また、30 以上の特許を取得または申請中です。 Justin Swagler Justin Swagler は AWS のフィジカルリテールワールドワイドヘッドで、実店舗小売業のグローバル戦略とソートリーダーシップを率いています。Justin は消費財、小売、および戦略分野で 15 年以上の経験を持ち、イノベーション戦略、小売オペレーション、製品開発、エグゼクティブリーダーシップにわたる経験があります。彼は、組織が戦略的にイノベーションを起こし、消費者体験を再創造するよう導くことに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号を、ケロッグ経営大学院で MBA を取得しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

7 月に プレビュー として発表された AWS App Studio は、生成 AI を活用したアプリケーション開発サービスです。ユーザーはこれを利用することで、専門的なソフトウェア開発スキルを必要とせずに、自然言語を使用してアプリケーションを作成できます。その記事では、AWS App Studio が安全でスケーラブルなアプリケーションの構築にどのように役立ち、各アプリケーションを完全に管理することで運用上のオーバーヘッドをどのように排除するのかについて説明しました。 App Studio は、新しいビルダーたちがビジネスアプリケーションを作成できるようにします。IT プロジェクトマネージャー、データエンジニア、エンタープライズアーキテクト、ソリューションアーキテクトのいずれであっても、自然言語で要件を説明するだけで、App Studio は数分以内に、複数ページの UI、データモデル、カスタムビジネスロジックを備えた完全に機能するアプリケーションを生成します。 11 月 18 日、AWS App Studio の一般提供が米国西部 (オレゴン) および欧州 (アイルランド) の AWS リージョンで開始されたことをお知らせします。 プレビューからのフィードバックに基づいて、アプリケーション構築エクスペリエンスを強化するいくつかの新機能を導入しています。 自然言語でアプリケーションを変更する 新しい生成 AI コンポーネントを使用してアプリケーションにインテリジェンスを追加する 自然言語でカスタムビジネスロジックを生成して追加する アプリケーションのテーマとスタイルをカスタマイズする 自然言語でアプリケーションを変更する プレビュー期間中、お客様から、自然言語プロンプトを使用して完全に機能するアプリケーションを生成することを楽しんでおり、このサービスに感謝しているというご意見をいただきました。しかし、開発ジャーニーは通常そこでは終わりません。その後、お客様から、自然言語を使用してアプリケーションを拡張または変更できるかというご質問をいただきました。 現在、App Studio では、自然言語を使用してアプリケーションを変更できます。アプリケーションを生成した後、希望する変更内容を記述すると、アシスタントから更新内容が提案され、それをレビューできるようになりました。確認すると、変更が自動的に行われます。この機能により、アプリケーションのカスタマイズがさらに迅速かつ容易になります。 App Studio を利用して構築した IT 在庫管理アプリケーションで、この機能がどのように動作するのかを見てみましょう。 この新しい機能を使用すると、アシスタントとチャットしてアプリケーションを変更できます。 アプリケーションを変更するために、アプリケーションに別の機能を追加するようにプロンプトを提供できます。ここでは、リクエストされたハードウェアの詳細を取得するためのウェブ URL についての別のテキスト入力を追加し、メモを保存するための別のテキスト領域が必要です。 その後、生成 AI アシスタントは入力を処理して提案を提供します。この提案をレビューし、[確認] を選択して続行できます。 その後、アシスタントは自動的にコンポーネントを追加し、アプリケーションを変更します。 新しい生成 AI コンポーネントを使用してアプリケーションにインテリジェンスを追加する また、テキスト要約、コンテンツ生成、ファイル分析などの生成 AI 機能をアプリケーションにさらに簡単に追加できるように、新しいコンポーネントも導入しています。 この機能を使用する方法は 2 つあります。まず、キャンバスを開いた状態で、 生成 AI コンポーネントを選択し、キャンバスにドラッグアンドドロップします。その後、コンポーネントを選択しながら、アシスタントを使用してカスタマイズできます。 アシスタントを直接使用することもできます。例えば、修理メモを分析して、レビューしやすいように要約を提供する機能が必要だとします。チャットボックスに必要な情報を入力するか、または提案されたプロンプトを使用します。 その後、アシスタントは入力を処理して提案を提供します。提案をレビューし、 [確認] を選択して続行できます。 App Studio は、必要なコンポーネントを自動的に追加します。キャンバスには、オートメーションをトリガーするボタンがあります。基になるプロンプトを変更する必要がある場合は、それぞれのオートメーションにリダイレクトするリンクを選択できます。 内部では、生成 AI コンポーネントは、 生成 AI プロンプト という新しいアクションステップを使用します。この新しいコンポーネントを使用すると、プロンプトと入力パラメータを簡単に変更して、大規模言語モデル (LLM) によって生成される出力をカスタマイズできます。 修理メモを要約する新しく追加された生成 AI 機能を備えた公開済みアプリケーションを次に示します。 自然言語でカスタムビジネスロジックを生成して追加する オートメーションで JavaScript を使用してカスタムビジネスロジックを追加する際に、アシスタントを役立てることもできます。 例えば、修理期間を計算し、関係者に E メールで通知するためのカスタムビジネスロジックが必要だとします。私が作成したマルチステップのオートメーションを次に示します。オートメーションにカスタムロジックを追加するには、 JavaScript コンポーネントを選択し、適切な場所にドラッグアンドドロップします。 次に、アクションを選択し、 [プロパティ] パネルで、 [エディタを展開] アイコンを選択します。 この機能を使用することで、自然言語で JavaScript コードを生成できるようになりました。ここでプロンプトを提供すると、App Studio がコメントとともにソースコードを生成します。生成されたソースコードは、要件に合わせてカスタマイズできる基盤となります。 そして、 [E メールを送信] アクションをオートメーションに追加して、フローを完了する必要があります。 アプリケーションのテーマとスタイルをカスタマイズする [アプリケーションのテーマ] を使用して、アプリケーションのルックアンドフィールをカスタマイズできるようになりました。この機能を使用すると、アプリケーションの外観を、 [ライトモード] または [ダークモード] に変更できます。さらに、会社のブランドに合わせてアプリケーションのカスタムカラーを指定することもできます。この機能を有効にするには、 [カスタマイズ] トグルをオンにする必要があります。 今すぐご利用いただけます App Studio を使用して、安全、インテリジェント、スケーラブルなビジネスアプリケーションの構築を今すぐ開始しましょう。構築は無料で、60 日間 (250 ユーザー時間) の無料トライアルをご利用いただけます。 これらすべての機能や他の機能の詳細については、 AWS App Studio のドキュメント をご覧ください。また、AWS Developers Slack ワークスペースの #aws-app-studio チャネルでぜひ会話にご参加ください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

流通・小売・消費財業界に関わられている方々を主な対象として、2024年11月15日に「流通・小売・消費財業界向け：2024 年 最新ソリューションによるレガシーシステムのクラウド移行」のオンラインセミナーを開催しました。ご参加いただきました皆さまには、この場を借りて御礼申し上げます。本ブログでは、その内容を簡単にご紹介します。 拡大する市場、新たなブランドの台頭、そして日々変化する顧客ニーズ。流通・小売・消費財業界では高まる顧客の期待に応えるために、デジタルテクノロジーを活用するための組織やシステムを常に新しくしていくこと、つまりモダナイズしていくことが求められます。AWS への移行は、インフラストラクチャをクラウドに移行してコストを削減するだけにとどまらず、新サービスや新商品の市場投入までの時間を短縮するなど経営戦略に大きく貢献します。ミッションクリティカルなアプリケーションとデータを AWS へと移行することが変革の基盤となります。今回のセミナーでは、AWS の包括的なサービスとソリューションを活用し、クラウド移行を成功させたお客様 3 社に具体的な事例をお話いただきました。 本ブログでは、セミナーからハイライトをご紹介してまいります。なお、ご登壇 3 社目の企業様については公開範囲のお約束により本ブログでのご紹介ができないため、割愛しておりますことをご理解ください。 1. オープニング AWS 技術統括本部 エンタープライズ技術本部 流通小売・消費財グループ 部長 　五十嵐 建平 資料ダウンロード クラウド移行は企業にとって、時間もコストも必要な大きな意思決定の一つです。移行を決定すると次に、どのように計画すればよいのか、どのような AWS サービス構成、環境へと移行するのが最適なのか、多様な移行手段、ツールの中からどれを選択すればよいのか、プロジェクトをどう進めていくべきなのか…まだまだ考えなくてはならないことがあります。 (1) なんのために移行するのか？ 自社の中期経営計画や事業部戦略、ゴール、こういったビジネスコンテキストに沿った目的を定めることは、クラウド移行の大きなプロジェクトの意思決定、つまり予算上申のためにはとても重要です。移行目的は企業によりその優先順位は違えど、大きく次の 6 つと言われています。 クラウドを移行によって目指すものについて、これら 6 つの主要な領域をカバーできているか、しっかり検証してみるとよいでしょう。企業様の状況によってはすべてをカバーする必要がないこともあるかもしれませんが、今回のセミナーでご登壇いただく各社様とも上記をそれぞれ言及されていました。 (2) 移行をどう計画すればよいのか？ クラウドに移行するにあたり最初に考えるアプローチは、一般的に「リフト＆シフト」と呼ばれるものです。これは、現状のシステムと同じような構成、同じようなアーキテクチャ、同じような運用のまま、クラウド上で動かすことをまずは目指すものです。まずクラウドへと移行してハードウェアの老朽化対応やコスト削減を実現するわけです。こうして時間やコストの余裕を得たうえで、次のステップとしてクラウドに最適化し設計・構築、つまり「クラウドネイティブ」の段階へと進みます。2 社目にご登壇いただいた株式会社三越伊勢丹システム・ソリューションズ様はまさにこの「クラウドネイティブ」のステージへと進んでいらっしゃいます。この 2 つのアプローチは必ず順を追わなくてはならないものではなく、基幹系は「リフト＆シフト」で慎重に移行しつつ、DX 案件などスピードの求められる部分に対しては最初から「クラウドネイティブ」で取り組むことのできる環境を整えていくといった両輪型のアプローチもありえます。1 社目にご登壇いただいたサッポロホールディングス株式会社ではこの両輪型のアプローチを採用することで、時間のかかる基幹移行を待たずにクラウドの価値を享受することに成功されています。 「リフト＆シフト」で移行を行う際には多様な “業務” による分類、レガシーシステム、新規システム、あるいはピークのあるものないものなどの “システム特性” の分類の 2 軸で分類を行うことで、移行メリットとその影響を確認することができます。基幹システムは規模も大きく一度に全システム／アプリケーションを移行することは現実的ではありません。一例ではありますが、移行リスクが低く、かつ、移行メリットが高いと考えられる領域（例えば下図の例であれば「アプリ E」）から移行を始めていこう、そこから経験値を積みつつ順次、リスクの高いものへと挑戦していこう、といった段階を踏むことが可能です。 (3) どんな構成にすればよいのか？ 移行の方式について、AWS では「7R」と呼ばれる分類を提唱しています。R で始まる移行方式が 7 種類あるので、7R です。今回のセミナーでは、下の 3 つについては触れていないため、上の 4 つについて簡単に紹介します。 「Rehost」および「Relocate」は単純移行とも呼ばれ、OS やアプリケーション、データベースなどに代表されるミドルウェアに変更を加えず、できるだけそのままの構成でクラウドへと移行するものです。「Replatform」はその名前の通りプラットフォームを更新するわけですが、「Rehost/Relocate」を一歩進めて、OS をオープンなものに変更する、データベースを Amazon Relational Database Service （RDS）や Amazon Aurora のようなマネージドサービスに変更するといったプラットフォームの変更を取り入れていくものです。商用データベースのライセンスから解放される、運用をマネージドに委ねることで負荷低減するといったメリットを得つつ、アプリケーション側の変更などを極小に留めるアプローチです。ここまでの 3 つの方式はいずれも (2) でご紹介した「リフト＆シフト」に相当します。アプリケーションまで手を加えていこうとするのが「Refactor」で、例えば現行の Web サーバーベースのアプリケーションから、コンテナやサーバーレスといったクラウドネイティブなアプリケーションアーキテクチャへと書き換えることで、クラウド移行のメリットをインフラ、アプリともに最大化することを狙います。効果も大きいですが実際にはなかなか大変です。 この「7R」も、基幹アプリケーション領域は「Rehost」で、例えば業務データ分析（データウェアハウスなど）だけは「Replatform」でといった具合に組み合わせて適用することももちろん可能です。(2) で述べた効果とコストやリスクをトレードオフにかけて検討していきます。この移行方式が決まると、おのずと移行に利用するツールなども絞り込まれてきます。 こういった検討を重ねることで、多数ある基幹システムをどのようにグルーピングしてどの順序で移行していくのが自社にとって最適なのか、現実的な移行プロジェクト計画へと落とし込みができるのです。 ご登壇各社様ともしっかり上記を踏まえたうえで、それぞれ異なるアプローチ、方式を取られていることが紹介されています。 2.お客様事例 (1) IT インフラの変革：サッポログループの AWS 全面移行プロジェクト サッポロホールディングス株式会社 DX・IT 統括本部IT統括部 企画グループリーダー 　伊藤 淳 様 資料ダウンロードリンク サッポロホールディングス様からは、2021 年から来年 2025 年第一四半期まで約 4 年に及ぶ基幹システム移行プロジェクトについてご紹介いただきました。2021 年次期システム更改の検討を開始された際に、現行のプライベートクラウドでのハードウェア更改だけではなく、パブリッククラウドへの移行を一つの選択肢として加えることにされました。これは、ビジネス環境や社会環境が変化し、企業として柔軟に対応できる、効率的な IT 基盤が求められていること、そしてデータとデジタル技術の活用による、いわゆる DX の推進が経営層から強く求められていたことなどを背景としています。このため、単にリフト＆シフトで安全にクラウドへと移行するだけでは不十分で、DX にも対応できる基盤が必要とされるため、基幹システムは「安定重視プラットフォーム」へ移行しつつ、そして新たな DX 案件などのための「チャレンジ重視プラットフォーム」も提供して、ビジネス側からの変革要望にも応えるという両輪のアプローチを採用されました。 100 以上ある基幹システムは、Opening で紹介したような軸で分析を行い、移行方式をパターン化し、移行するグループの整理や、パターンごとの移行ツールの選定を行いました。AWS の提供する移行のためのサービス、 AWS Application Migration Service （MGN）、 AWS Database Migration Service （DMS）を利用して Rehost を中心としつつ、データベースを一部はマネージドサービスである Amazon RDS に移行するなど Replatform も取り込まれています。 基幹移行についてはこれまでに約 7 割前後の移行が完了しており、2025 年には当初計画を前倒しして完了できる見込みとなっています。またチャレンジ重視の領域も、安定重視プラットフォームとセキュアに接続できるようにしておくことで、基幹系のクラウド移行を待たずに推進できるようになっており、すでに AI を利用した取り組みなど事例化できるものも生まれています。サッポロホールディングス様は、基幹移行完了後には、さらにリソースやコストの最適化、クラウドサービス活用、データ活用推進などを進められていくことを計画されています。今後のモダナイゼーションへの道のりに進んで行かれるところを、AWS もお手伝いしてまいります。 3. お客様事例 (2) 三越伊勢丹グループの価値創造に向けた “モダナイズ” への挑戦 株式会社三越伊勢丹システム・ソリューションズ ICT エンジニアサービス部 部長 　竹前 千草 様 資料ダウンロードリンク 日本有数の老舗企業の一つである三越伊勢丹グループ様では、2015年からクラウド利用（リフト&シフトアプローチ）を開始し、次いで 2018 年より段階的機能再配置と呼ぶ、いわゆるモダナイゼーションへの挑戦を開始されました。画一的な構成で実現できていた旧来型のアーキテクチャのモダナイズが進むにつれて、三越伊勢丹システム・ソリューションズ様の中ではアーキテクチャなどへのバラつきや、これまでと異なるチームビルディングへの戸惑いなどの技術・組織両面での課題が見られるようになり、この課題への対策として 2021 年に CCoE を組織化されました。特にバックエンドのモダナイゼーションの投資価値は見えづらく、経営トップの皆様が「モダナイズを宣言」することで、モダナイゼーションが組織のミッションともなり、現場が非常に進めやすくなったとのお話は、モダナイゼーションが IT 部門だけの閉じた活動になりがちな多くのお客様にとって力強いメッセージになったのではないでしょうか。 またモダナイゼーションを進めることで当たる壁のもう一つ、「開発チームはアプリからインフラまで全ての知識を必要とされる。新しく出てくる技術要素も習得しなくてはならない。大変で途中で逃げ出したくなる」というお話にも大きな共感を覚えました。三越伊勢丹システム・ソリューションズ様はそこから逃げ出さず、CCoE による DevOps 基盤の整備で底上げを図る、新たな人事制度やロールを導入するといった根本的な打ち手を続け、自ら保守運用を楽にしていくための仕組みを作り上げられています。Amazon CTO Werner Vogels の「You build it, You run it.」の言葉をまさに実践されている組織ではないでしょうか。 今後も、クラウドへとリフト＆シフトした基幹システムについてコストの最適化やモダナイゼーションの戦略検討を進めつつ、モダナイズした領域についても「一生懸命がんばる」の精神論にならないよう、技術のキャッチアップや品質を安定化させるためのメカニズムの強化、そしてサービス実現のスピードと柔軟性を上げていくために欠かせない「市民開発」の拡大にチャレンジされるとのことです。三越伊勢丹グループ様のモダナイゼーションの道のりはとても長く、まだ四割半ばくらいではないかとのお話でした。ですが、確実に、日本の流通小売業界の基幹システムモダナイゼーションの牽引役を担う一社と言えます。今後の展開も楽しみです。 まとめ クラウド移行を始める・始めてからもいろいろなお悩みがあると思います。実際にその悩みと格闘しながら長いクラウドジャーニーへと踏み出され、着実な成果を出し始めていらっしゃるお客様の事例をご紹介してまいりました。長いクラウドジャーニーのどのステージに位置するのかも異なり、取られているクラウド移行の方式もそれぞれ異なるものでした。 まだ多くの企業において、企業トップや情報システム部門が「クラウド移行するべきか、どう進められるのか」といった迷いを持たれているのではないでしょうか。クラウド移行という選択肢を外して考えることはできない時代ですが、これまでと違う要素に戸惑いを持たれることも多いでしょう。経験不足が気になるお客様もいらっしゃるでしょう。ですが、今日の Opening でご紹介したように、 なぜ移行するのか、目的を定める リフト＆シフト、クラウドネイティブ化といった移行のアプローチと、それぞれのメリット、コスト、リスクをトレードオフして自社の戦略を立てる さらに業務特性とシステム特性を踏まえてグルーピングし、Rehost、Relocate、Replatform、Refactor など移行方式を選択する 移行方式に合う移行ツール、手段を選択する リスクが低く価値の高いところから始め、全体の依存関係を見ながらプロジェクト計画を立てる このステップを踏んでいただくことで、必ず前に進むことができます。ぜひ、早くクラウド移行への挑戦を始め、そして進化を早めて、競争力を加速させていきましょう。私たちがお手伝いします。 イベント案内 12 月にはいよいよ、re:Invent 2024 が開催されます！ぜひご参加ください。 【登録受付中】 re:Invent 2024 2024 年 12 月 2 日 – 12 月 6 日 ラスベガス　＊オンデマンド視聴もあります 登録はこちらから： https://reinvent.awsevents.com/ また re:Invent 2024 における小売消費財業界向けのお薦めセッション等を、以下ブログにてご紹介しております。こちらも合わせてご覧ください。 AWS re:Invent で小売消費財業界のイノベーションを加速 今後も、流通・小売・消費財業界の皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開しております。 流通小売参考情報 [1] AWS ブログ  ”流通小売” カテゴリー [2] AWS ブログ  “消費財” カテゴリー [3]  AWS 消費財・流通・小売業向け ソリューション紹介 ページ [4] インダストリー向け e-Book： スマートストアテクノロジーの力を活用する（ e-Book | 紹介ブログ ） 小売業のデジタルコマースを最適化する 4 つの重要なステップ（ e-Book | 紹介ブログ ） 流通・小売・消費財企業のイノベーションを生成 AI で促進する（ e-Book | 紹介ブログ ） 消費財企業が成長するための極意（ e-Book | 紹介ブログ ） 消費者に愛されるブランドを構築する（ e-Book | 紹介ブログ ） このブログは、ソリューションアーキテクト 杉中 が担当しました。

お客様はアプリケーションのパフォーマンス、スケーラビリティ、耐障害性を向上させるために DynamoDB を選択します。DynamoDBのサーバーレスアーキテクチャでは、ハードウェア、スケーリング、パッチ、保守を抽象化することで運用を簡単にすることができます。DynamoDBにおけるデータアクセスとセキュリティの管理は、インスタンスベースのデータベースソリューションとは異なります。RBDMSソリューションではファイアウォールのルールやパスワード認証、データベース接続管理に依存している一方で、DynamoDBは、 AWS Identity and Access Management (IAM)を使用して、リソースへのアクセスの認証と認可を行います。 このブログではFine-grained Access Control (FGAC) を使用した、信頼できるIAMエンティティへの最小権限アクセス制御を実装する方法について説明します。DynamoDB上で条件ベースのIAMポリシーを使用してFGACを構成する方法を示し、AWSリージョンやタグなどの属性に基づいてDynamoDBへのきめ細かいアクセス制御を行うためのAWS IAM Identity Centerの権限セットのサンプルを提供します。また、DynamoDBとAWS CloudTrailを連携させ、DynamoDBのコントロールプレーンとデータプレーンのAPIアクションをログに記録する方法を紹介します。例えば、CloudTrailのログにDeleteItemイベントを記録し、Amazon CloudWatchのメトリクスフィルタを作成し、CloudWatchアラームを作成することができます。また、これらのリソースの作成を自動化するHashiCorp Terraform infrastructure as code (IaC)テンプレートも提供しています。 DynamoDBにおけるきめ細かいアクセス制御 きめ細かなアクセス制御を実装するステップは以下のようになります。 IAMポリシーにおける条件式やプレフィックスを使用してIAM Identity Centerの許可セットを作成し、最小権限のアクセスを実装する。 IAM Identity CenterでAWSアカウントを選択し、ユーザーとグループを割り当て、許可セットを割り当てる。 DynamoDBはフルマネージドなデータベースサービスであり、ホスティングされたデータベースの運用やスケーリングの管理負荷を軽減することができます。しかし、許可されたユーザーやアプリケーションがDynamoDBのデータを作成・変更できるようにするためには、AWSのサービスを利用して効果的にアクセス制御を実装する必要があります。具体的な内容に入る前に、基本的なことを理解しておくことが重要です。 IAMはAWSセキュリティの基盤です。これにより、AWSリソースに対して誰がどのようなアクションを実行することができるかを制御することができます。IAMユーザーやグループ、ロールに対して許可を拒否または付与することができます。 IAMに加えて、DynamoDBは リソースベースポリシー をサポートしています。リソースベースポリシーにより、各リソースにアクセスできるユーザーと、各リソースで実行できるアクションを指定することで、アクセス権限を定義できます。リソースベースポリシーは、 IAM Access Analyzer および Block Public Access (BPA)機能との統合もサポートします。リソースベースポリシーにより、アカウント間のアクセス制御が大幅に簡素化されます。様々なDynamoDB認証シナリオと、それらを解決するためのリソースベースポリシーの実装方法については、「 Simplify cross-account access control with Amazon DynamoDB using resource-based policies 」を参照してください。 きめ細かいアクセス制御を実装する DynamoDBでは、デーブル内の個々の項目や属性のレベルに至るまで、きめ細やかなアクセス制御を実装できます。以下のステップを完了します。 DynamoDBテーブルにアクセスできるユーザーと、必要なアクセスレベルを特定します。実行する必要がある読み取りおよび書き込み操作を決定します。 DynamoDBへのアクセスを必要とするサービスと個人のIAMユーザー、グループ、またはロールを作成します。 IAMポリシーを作成し、IAMユーザーまたはロールにアタッチします。 以下は TestTable と呼ばれる特定のテーブルからタグを削除する操作を拒否するサンプルポリシーです。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DenyDeleteTag2", "Effect": "Deny", "Action": [ "dynamodb:UntagResource" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/TestTable" ] } ] } 以下のポリシーは TestTable に対して全てのDynamoDBのアクションを許可します。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowedResourcesWithPrefixApp", "Effect": "Allow", "Action": [ "dynamodb:*" ], "Resource": [ "arn:aws:dynamodb:us-east-1:123456789012:table/TestTable*" ] } ] } DynamoDBは、テーブル内のきめ細かなアクセス制御を定義できる条件式をサポートしています。操作が成功するために満たす必要がある条件を指定できます。次のサンプルポリシーでは、パーティションキーの値がテーブルTestTableのユーザーIDと一致する特定の属性にユーザーがアクセスできるようにします。 ${www.amazon.com:user_id} で表記されるIDは変数を代替しています。 { "Version":"2012-10-17", "Statement":[ { "Sid":"AllowAccessToOnlyItemsMatchingUserID", "Effect":"Allow", "Action":[ "dynamodb:GetItem", "dynamodb:BatchGetItem", "dynamodb:Query", "dynamodb:PutItem", "dynamodb:UpdateItem", "dynamodb:DeleteItem", "dynamodb:BatchWriteItem" ], "Resource":[ "arn:aws:dynamodb:us-east-1:123456789012:table/TestTable" ], "Condition":{ "ForAllValues:StringEquals":{ "dynamodb:LeadingKeys":[ "${www.amazon.com:user_id}" ], "dynamodb:Attributes":[ "attribute1", "attribute2", "attribute3" ] }, "StringEqualsIfExists":{ "dynamodb:Select":"SPECIFIC_ATTRIBUTES" } } } ] } DynamoDBの操作とデータプレーンのアクティビティを監視する DynamoDBはCloudTrailと統合されています。証跡を作成することで、DynamoDBコントロールプレーンAPIアクションをイベントとしてCloudTrail ログに記録できます。CloudTrailファイルのデータプレーンAPIアクションのロギングを有効にするには、CloudTrailでデータイベントのロギングを有効にする必要があります。データプレーンイベントをリソースタイプでフィルタリングして、CloudTrailに選択的に記録するDynamoDB API呼び出しを細かく制御できます。 大まかに手順は以下の通りです。 CloudTrailを有効にして、DynamoDB APIオペレーションをログに記録できるようにします。 CloudWatchメトリクスフィルターを使用して目的のAPIオペレーションをキャプチャし、それを数値のCloudWatchメトリクスに変換します。 カスタムメトリクスを使用してCloudWatchアラームを作成します。 Amazon Simple Notification Service (Amazon SNS)を使用して、作成したアラームの状態が変わった時に、登録しているエンドポイントまたはクライアントにEメールを送信します。 次の図は、このアーキテクチャのコンポーネントを示しています。 前提条件 このウォークスルーには以下が必要です。 AWSアカウント 必要な権限を付与したIAMユーザーかロール DynamoDB、CloudTrail、CloudWatch、Amazon SNSへのアクセス CloudTrailを用いてDynamoDB操作をログに記録する このソリューションでは、データイベントを作成して API アクションを CloudWatch ロググループに記録します。 これにより、どの DynamoDB 項目が作成、読み取られ、更新され、削除されたかをすばやく判断し、API 呼び出しのソースを特定できます。 不正な DynamoDB アクティビティを検出した場合、アクセスを制限するアクションをただちに実行することもできます。 次のスクリーンショットは、高度なイベントセレクター設定を使用してデータイベントを作成し、CloudTrail のデータプレーンオペレーション DeleteItem をキャプチャする方法を示しています。 次の例は AWS Command Line Interface (AWS CLI)を用いて高度なイベントセレクターを使用する方法を示しています。 aws cloudtrail put-event-selectors --trail-name TrailName \ --advanced-event-selectors '[ { "name": "findDeleteItems", "fieldSelectors": [ { "field": "eventCategory", "equals": [ "Data" ] }, { "field": "resources.type", "equals": [ "AWS::DynamoDB::Table" ] }, { "field": "eventName", "equals": [ "DeleteItem" ] } ] } ] DynamoDBテーブルに 項目を作成 してから削除することで、このルールをテストできます。これにより、CloudTrailで Delete Item のAPIオペレーションが生成されるはずです。トラフィックが生成されたら、次のスクリーンショットが示すように、CloudWatch Logsコンソールにログインしてロググループを選択し、イベント DeleteItem を検索できます。 以下はCloudWatch Logsコンソールで実行できるクエリのサンプルです。 アクセス拒否された操作を見つける。 filter (errorCode ="AccessDenied" and eventSource="dynamodb.amazonaws.com" and eventName ="DescribeGlobalTable") 権限のない操作を見つける。 filter (errorCode ="UnauthorizedOperation" and eventSource="dynamodb.amazonaws.com" and eventName ="DescribeGlobalTable") CloudWatchメトリクスフィルターの作成 メトリクスフィルターを使用して、ログデータを実用的なメトリクスに変換し、アラームを作成できます。フィルターには、単語、完全一致のフレーズおよび数値を使用できます。正規表現(regex)を使用して独自のフィルターパターンを作成することも、JSONやスペースで区切られたフィルターパターンと組み込むこともできます。 DeleteItem イベントに対するメトリクスフィルターを作成するには、　 ロググループのメトリクスフィルターの作成 を参照してください。 CloudWatchアラームを作成する メトリクスフィルターを作成したら、CloudWatchアラームを作成できます。手順については CloudTrail イベントの CloudWatch アラームの作成: 例 を参照してください。[アクションの設定]ページで[通知]を選択し、次に[アラーム状態]を選択します。これは、しきい値を超えた時にSNSトピックに通知を送信するアクションが実行されることを示します。 SNSトピックを作成する SNSトピックを作成するために、 Amazon SNSトピックの作成 に記載のステップに従ってください。アラームのステートが変化した際、Amazon SNSはサブスクライブされたエンドポイントやクライアントにメールを送信します。 Terraformコード DynamoDB API操作のCloudTrailログ、CloudWatchメトリクスフィルター、CloudWatchアラームの作成を自動化するためのコードが提供されています。その後、お好みの通知チャネルを使用してSNSトピックを作成できます。 DynamoDBの高度なオブザーバビリティ CloudWatch Contributor Insights を使用してログデータを分析し、コントリビューターデータを表示する時系列を作成できます。Contributor Insightsには、DynamoDBのパフォーマンスメトリクスを分析するための組み込みルールが用意されています。Contributor Insightsはパーティションとパーティション+ソートキーの両方について、頻繁にアクセスされるキーとスロットルされたキーを記録します。これにより、最もよく使用されるプライマリキーを見つけて、誰または何がシステムパフォーマンスに影響を与えているのかを理解できます。DynamoDBテーブルのContributor Insightsは明示的に有効にする必要があります。 また Amazon EventBridge ルールを使用して、 CreateTable や DeleteTable 、 UpdateTable といったDynamoDB データ定義言語 (DDL) の操作をモニタリングし、SNSトピックを介して通知を受け取ることもできます。EventBridgeルールは特定の種類のイベントを監視します。一致するイベントが発生すると、そのイベントはルールに関連づけられているターゲットにルーティングされます。 まとめ この投稿では、DynamoDB で条件ベースの IAM ポリシーを使用してきめ細かなアクセス制御を設定する方法に関するガイドラインを提供しました。 また、DynamoDB を CloudTrail と統合し、DynamoDB コントロールおよびデータプレーン API アクションをイベントとして CloudTrail ログに記録し、CloudWatch メトリクスフィルターを作成し、CloudWatch アラームを作成するための Terraform IaC テンプレートも提供しました。 このソリューションでは、予防的モニタリングと事後対応型のモニタリングのベストプラクティスを実装して、DynamoDB に適切なセキュリティ制御を適用できます。 きめ細かなアクセス制御の詳細については、 AmazonDynamoDBにおけるきめ細かなアクセス制御 という動画をご覧ください。 詳細については、 AWS Well-Architected フレームワーク 、 DynamoDB を使用した設計とアーキテクチャの設計に関するベストプラクティス および DynamoDB テーブルのコストの最適化 を参照してください。 著者情報 Arun Chandapillal は、ダイバーシティ＆インクルージョンの推進者であるシニアアーキテクトです。 彼は、ビジネスファーストのクラウド採用戦略を通じてお客様が IT の近代化を加速し、クラウドでアプリケーションとインフラストラクチャをうまく構築、デプロイ、管理できるよう支援することに情熱を注いでいます。 Arun は自動車愛好家であり、熱心な講演者であり、慈善家であり、「与えたものは得られる（返される）」と信じています。 Parag Nagwekar は AWS Proserv のシニアクラウドインフラストラクチャアーキテクトです。 彼は顧客と協力して、クラウドとITの近代化への道のりを支援するソリューションを設計および構築しています。 彼の情熱は、クラウド内のアプリケーションにスケーラブルで可用性の高いサービスを提供することです。 システム管理、DevOps、分散アーキテクチャ、クラウドアーキテクチャなど、複数の分野での経験があります。 （本記事は 2024/05/21に投稿された Enable fine-grained access control and observability for API operations in Amazon DynamoDB を翻訳したものです。）

本記事は 2024 年 7 月 9 日に AWS Cloud Operations Blog で公開された “ Understanding AWS High Availability and Replication for vSphere Administrators ” を翻訳したものです。 はじめに vSphere HA は vSphere の基本的かつ頻繁に使用される機能です。いくつかの障害シナリオのいずれかが発生した場合、仮想マシンを再起動します。障害シナリオは、仮想マシンやホストのクラッシュから、応答しないホスト (例えば、ネットワーク分離や停止) まで多岐にわたります。 vSphere High Availability (HA) をパブリッククラウドに移行することは、複雑なプロセスとなる場合があります。一部の概念 (例えば、仮想マシンの自動再起動や 仮想マシン/ホストの健全性監視など) は非常に類似していますが、他の概念 (例えば、アドミッションコントロールなど) はオンプレミス環境とクラウド環境では同じようには適用されません。この記事は、AWS の採用を始めた経験豊富な VMware 管理者の混乱を軽減することを目的としています。ここでは、堅牢な災害復旧計画の基礎となる高可用性とレプリケーションの両方について説明します。 AWS における高可用性 AWS クラウドにおける高可用性を理解するには、AWS のリージョンとアベイラビリティーゾーン (AZ) の概念を理解する必要があります。AWS リージョンは、低レイテンシー、高スループット、高度な冗長ネットワークで接続された物理的に分離され独立した複数のアベイラビリティーゾーンで構成されています。アベイラビリティーゾーンは、1 つ以上の独立したデータセンターで構成され、それぞれが冗長電源、ネットワーク、接続性を備え、別々の施設に収容されています。 Amazon Elastic Block Store (Amazon EBS) のような多くの AWS サービスは AZ レベルの可用性を提供し、 Amazon Simple Storage Service (Amazon S3) のようなサービスはリージョン全体の可用性を提供します。すべての Amazon Elastic Compute Cloud (Amazon EC2) インスタンスは、Amazon EBS ボリュームをルートとして持ち、追加の Amazon EBS ボリュームを接続することができます。Amazon EC2 インスタンスは、他の形式のストレージ (NFS、CIFS、Amazon S3 バケットなど) も接続できます。Amazon EBS ボリュームはアベイラビリティーゾーン内で耐久性があり、つまりボリュームはアベイラビリティーゾーン内の任意のインスタンスに接続できます。(また、一部の目的では、vSphere の 「マルチライター」モード に類似して、 同時に 複数のインスタンスに接続することもできます。) インスタンスに障害が発生した場合、その Amazon EBS ルートボリュームは起動時に新しいインスタンスに再接続されます。 単一または複数の仮想マシン (インスタンス) の障害が発生した場合、復旧プロセスは非常に似ています。オンプレミスの vSphere 環境であれ、AWS クラウドであれ、同じことが言えます。物理ホストの障害についても同様です。2 つの重要な違いがあります。まず、クラウドでは物理ハードウェアのプロビジョニングが自動的に行われます。次に、いくつかの例外を除いて、AWS サービスはアベイラビリティーゾーン全体で利用可能です。vSAN クラスター (または従来の SAN アレイに基づくデータストア) がデータセンター全体のすべての vSphere ホストにまたがっているような状況を想像してみてください。 パブリッククラウドはオンプレミスのインフラストラクチャとは異なる動作をするため、ステートレスなアプリケーションとステートフルなアプリケーションを区別することが重要です。これは、アプリケーションやサービスの状態によって回復メカニズムが異なるためです。ステートレスなアプリケーションは、ユーザーの過去のインタラクションやセッション状態に関する情報を維持または保存しないアプリケーションです。アプリケーションへの各リクエストは、過去のリクエストやユーザーのコンテキストに関する知識なしに、独立して処理されます。例えば、ロードバランサーの前段にある Apache を実行している VMware 仮想マシンや Amazon EC2 インスタンスのフリートが Web サイトを提供している場合を考えてみましょう。コンピュートインスタンス (仮想マシンであれ Amazon EC2 インスタンスであれ) が何らかの理由でクラッシュした場合、このサービスはステートレスであるため、オンデマンドで再起動できます。ステートレスなアプリケーションの他の例には、RESTful API やサーバーレス関数があります。ステートフルなアプリケーションは、時間の経過とともにユーザーのセッションやインタラクションの状態を維持または「記憶」するアプリケーションです。例としては、Web ブラウザ (cookies、履歴など)、オンラインショッピングカート、電子メールクライアントなどがあります。 ステートフルなアプリケーションの高可用性 まず、ステートフルなケースを考えてみましょう。ステートフルなインスタンスに障害が発生し、 簡易自動復旧 が有効になっている場合、Amazon EC2 は自動的にインスタンスを再起動します (簡易自動復旧はデフォルトで有効です)。これは vSphere VM に対して、vSphere HA を有効にするのと似ています。より細かい制御を行うには、 Amazon CloudWatch アラーム を使用して検出と復旧を行うことができます。ここで注目すべきアラームは 2 つあります。1 つ目は「再起動」です。インスタンスがクラッシュすると、 ステータスチェック に失敗します。 再起動 アクションを設定した CloudWatch アラームを構成すると、同じ物理ホスト上でインスタンスが再起動されます。インスタンスのステータスは、コンソール、CLI および PowerShell から確認できます。 2 つ目のアラームは「復旧」で、ホストの障害時にトリガーされます。パブリッククラウドとオンプレミスインフラストラクチャのもう 1 つの重要な違いは、vSphere HA がアドミッションコントロールの対象となることです。障害が発生したインスタンスを再起動する前に、vSphere はクラスター内のいずれかのホストにインスタンスを起動するのに十分なリソースがあるかどうかを判断する必要があります。十分な容量がない場合、インスタンスを起動できません。クラウドでは、容量がオンデマンドであるため、アドミッションコントロールのような概念はサービス自体で実施されます。AWS は、ホストに障害が発生した際に、インスタンスを再起動するのに十分な容量を持つ物理ホストを自動的に決定します。Amazon EC2 サービスは、そのインスタンスのシステムステータスのチェックは失敗させますが、ヘルスチェックは失敗させません。インスタンスがシステムステータスのチェックに失敗した場合、これはインスタンス自体は動作していた可能性がありますが、基盤となるホストに障害が発生したことを示します。インスタンスを再起動するには、 復旧 アクションを含む CloudWatch アラームを設定します。 図 1 : インスタンスがクラッシュした際にトリガーされる StatusCheckFailed_Instance アラーム；自動再起動後にアラームがクリアされる様子 ステートレスなアプリケーションの高可用性 次にステートレスなアプリケーションの場合について説明しましょう。ステートレスにおいて、AWS で復旧を実装する最も簡単な方法は、Amazon EC2 Auto Scaling グループを使用することです。Auto Scaling グループは、常に特定の数のインスタンスが実行されていることを保証します。負荷が高くなった場合には実行中のインスタンス数を増やし、負荷が減少した場合にはインスタンス数を減らすことができます。基本的な vSphere を置き換えたユースケースでは、Auto Scaling グループの最小、最大、および希望するインスタンス数をすべて 1 に設定できます。これは、Auto Scaling グループが常に 1 つの実行中インスタンスを維持することを意味します。 図 2 : 基本的な 1 台のインスタンスの Auto Scaling グループ インスタンスに障害が発生した場合、Auto Scaling グループは新しいインスタンスを起動しますが、クラッシュした特定のインスタンスを再起動するわけではありません。Auto Scaling グループは、テンプレートと Amazon Machine Image (AMI) から新しいインスタンスを起動します。従来のオンプレミス仮想化の用語で言えば、AMI は vSphere テンプレートのようなもので、Amazon EBS ボリュームは VMDK に似ています。 Apache を実行してウェブサイトを提供するインスタンスのフリートが、ロードバランサーの背後にある前述の例を考えてみましょう。何らかの理由でインスタンスまたは基盤となるホストがクラッシュした場合、新しいインスタンスに置き換えられます。複数のアベイラビリティーゾーンにまたがる Auto Scaling グループを設定することで、ラックやデータセンターの障害から保護されます。複数のアベイラビリティーゾーンに接続されたサブネットで Auto Scaling グループを構成すると、1 つの AZ のインスタンスに障害が発生した場合、Auto Scaling グループは別のアベイラビリティーゾーンで Amazon EC2 インスタンスを再起動します。インスタンスの前段にロードバランサーがあり、 Elastic Load Balancing (ELB) のようなリージョナルサービスである場合、新しいインスタンスは起動してすぐにトラフィックを処理できます。 レプリケーションの概念 私たちは、典型的な「リフト・アンド・シフト」移行のように、vSphere の可用性の概念を Amazon EC2 に直接的に、修正なしで適用することを検討してきました。つまり、オンプレミスの仮想マシンで構成されるワークロードを、クラウドで稼働する同じワークロードを構成する Amazon EC2 インスタンスに 1 対 1 でマッピングするということです。これは、ステートレスなサービスはクラウドでもステートレスのままであり、ステートフルなサービスはステートフルのままであることを意味します。多くのアプリケーションは、簡単な修正によってステートレスにすることができ、それによってスケーラビリティ、パフォーマンス、耐障害性を向上させることができます。アプリケーションをステートレスにする一つの方法は、データベースのようなステートフルなコンポーネントを、可用性の高いクラウドベースのサービスを使用するように変更することです。例えば、 Amazon Relational Database Service（Amazon RDS）for MySQL や Amazon DynamoDB のようなフルマネージドのクラウドデータベースを使用することで、データベースの可用性に関する作業を AWS にオフロードすることができます。これには他にもいくつかの利点があります。例えば、あなたのブログが非常に人気になり、コメント数がインスタンスの MySQL の容量を超えた場合、自己管理型 MySQL から Amazon RDS に切り替えることで自動的なスケーラビリティが可能になります。インスタンスのサイズ変更やデータベースのチューニングに時間と労力を費やす代わりに、Amazon RDS の設定を調整するだけで済みます。あるいは、MySQL は問題なく動作しているが Apache が過負荷になっている場合、同様に二つの選択肢があります。より多くの LAMP サーバーを追加して元の MySQL インスタンスに向けることもできますが、これにはより多くのインフラ作業（「差別化されていない重労働」）が必要です。または、データベースと Web サービスの機能を分離して、よりスケーラブルな設計にすることもできます。 次に、異なる AZ またはリージョンへのレプリケーションと復旧について説明します。これはオンプレミスでは vSphere Replication (VR) によって実現されています。vSphere Replication には主に 2 つのユースケースがあります：1 つのデータセンターから別のデータセンターへのローカルレプリケーション、そして異なる地震帯などへの長距離レプリケーションです。RPO と RTO の目標に応じて、レプリケーションに異なる AWS サービスを選択することができます。 同期レプリケーション (RPO=0) が目標の場合は、 Amazon FSx for NetApp ONTAP を検討してください。RPO が数秒から数分の場合は、 AWS Elastic Disaster Recovery を使用します。より緩やかな RPO と RTO 要件の場合、従来のバックアップと復旧が適しています。 AWS Backup はスケジューリングやデータ保持ポリシーなどの機能に加え、バックアップの 異常検出 などの機能も提供します。AWS Backup は Amazon S3に保存され、これは複数のアベイラビリティーゾーンにまたがるリージョナルリソースです。そのため、AWS Backup でバックアップされたリソースは AZ 障害に対して耐性があります。AWS Backup は クロスリージョンレプリケーション で長距離のユースケースもカバーできます。AWS Backup の最小スケジュール時間は 1 時間で、Amazon EBS の増分スナップショットを使用します。これは vSphere の Changed Block Tracking (CBT) に類似しています。 AWS Marketplace で入手可能なサードパーティーの ISV 製品も、オンプレミスの vSphere 環境から Amazon Virtual Private Cloud (Amazon VPC) へのフェイルオーバーのためのバックアップと災害復旧機能を提供できます。 図 3 : オンデマンドで AWS Backaup を作成 vSphere Replication での復旧では、vSphere 管理者にとってなじみのある「最近の変更を同期する」と「利用可能な最新のデータを使用する」という 2 つのオプションが提供されます。最初のオプションでは、ソース VM の電源をオフにしてソースとターゲットを同期する必要があります。これはデータセンター間のコールド vMotion と表現できます。AWS でこのパターンを模倣する場合、インスタンスをシャットダウンする必要はありません。ただし、実行中のインスタンスは、稼働し続ける場合、その後の変更が発生する可能性が高いです。クロスリージョンの AWS Backup を設定している場合、最新のバックアップが十分に最近のものであれば使用できます。この場合、ターゲットリージョンで利用可能な最新のバックアップから復元するだけで済みます。これは vSphere の「利用可能な最新のデータを使用する」オプションに相当します。クロスリージョンバックアップを有効にしていない場合は、ボールト内の最新のバックアップを選択し、ターゲットリージョンにコピーすることができます。 図 4 : AWS Backup を異なるリージョンへコピー オンプレミスのクロスリージョンレプリケーションジョブは、インターネットや VPN の帯域幅、あるいはダークファイバーの高コストによって制約を受けることが多いです。クラウドレプリケーションはインターネットではなく AWS ネットワーク上で実行され、Amazon S3 のレプリケーションには SLA が提供されています。従来、パッシブなディザスタリカバリサイトは非常にコスト効率の悪いアーキテクチャコンポーネントであり、顧客は 2 つの選択肢を迫られていました。1 つは、すべての重要なビジネスアプリケーションをフェイルオーバーするのに十分なアイドル容量を構成し、その費用を支払うことです。もう 1 つは、重要なワークロードの一部をサポートするのに十分な最小限の容量（アイドル状態のもの）に対して支払いを行うことです。AWS をディザスタリカバリサイトとして使用することの経済的利点は、必要な分のアクティブ容量のみを構成し、アイドル状態のリソースに対して支払う必要がないことです。 バックアップおよびリカバリ製品は、通常、データをその製品のネイティブフォーマットで保存します。たとえば、vSphere VM をバックアップすると、VMDK に含まれるデータのコピーが得られます。しかし、VMDK は AWS インフラストラクチャ上でネイティブに起動したり実行したりすることはできません。AWS における vSphere 環境の迅速な復旧のためには、2 つの選択肢があります。1 つは VMware Cloud on AWS に復元すること、もう 1 つは AWS Elastic Disaster Recovery を使用して AWS インスタンスに継続的にレプリケートすることです。RTO (復旧時間目標) の要件がそれほど厳しくない場合は、AWS Backup (または パートナーのバックアップソリューション ) を使用することを検討してください。これらのソリューションは、 AWS Import/Export を使用して、オンプレミスの仮想マシンを Amazon EC2 インスタンスに変換します。 まとめ 要約すると、vSphere High Availability と Replication は、パブリッククラウドにおいても類似の機能 (簡易自動復旧、CloudWatch アラーム、Auto Scaling グループ）を持っています。主な違いは、リージョナルサービスからの追加の回復力、自動化の利点、そして「従量課金制」モデルです。AWS に移行した後に仮想マシンを保護する方法がわかった今、試してみることをお勧めします。Auto Scaling グループ、スナップショット、スナップショットレプリケーション、および AWS Backup を使用して、クラウド DR アーキテクチャを先行して進めましょう。 翻訳はソリューションアーキテクトの増田雄紀が担当しました。原文は こちら です。

2013 年に当時の同僚である Tim Wagner と会議をしたことを、私はぼんやりと覚えています。サーバーレスという用語は存在していませんでしたが、デベロッパーがインフラストラクチャではなくコードに注力できるようにするさまざまな方法について話し合いました。あるとき、私は両手を上げ、コードを空中に投げて、クラウドに取得、保存、実行させたらクールだと言ったことを覚えています。そのような会議が何度も行われた後、Tim は PRFAQ を書いて、まさにそれを実現するプラットフォームを構築することを提案し、2014 年に私は「 AWS Lambda – Run Code in the Cloud 」を発表することができました。 スタートアップからエンタープライズへ Lambda などの新しいものに最初に挑戦するのが、インストールベースを気にする必要がなく、イノベーションが必要なスタートアップであることがよくあります。確かにそうでしたが、既存の企業 (エンタープライズを含む) も同様にすばやく飛びついたことに私はうれしい驚きを覚えました。少し実験した後、これらの企業はすぐに重要な社内ユースケースをサポートするイベント駆動型アプリケーションを構築する方法を見つけました。私はこれを、Lambda が成功するという初期の兆候として受け止めました。お客様がいかに早く新たな力を感じたのかは容易にわかりました。お客様は、スケーラブルかつ構成可能な方法でシステムを構築しながら、アイデアから実装、そしてそこからビジネス価値の実現へと、これまで以上に迅速に移行できるようになりました。 現在、150 万を超える Lambda ユーザーが、1 か月あたり合計で数十兆回の関数の 呼び出し を実行しています。これらのお客様は、ファイル処理、ストリーム処理 ( Amazon Kinesis および/または Amazon MSK と併用)、ウェブアプリケーション、IoT バックエンド、モバイルバックエンド (多くの場合、 Amazon API Gateway および AWS Amplify を使用) のために Lambda を使用し、他にも多くのユースケースをサポートおよび強化しています。 サーバーレスイノベーションの最初の 10 年 カレンダーを巻き戻して、過去 10 年間の Lambda の重要なリリースをいくつか見てみましょう。 2014 年 – AWS re:Invent 2014 に先駆けて、 Node.js のサポートと、S3 バケット、DynamoDB テーブル、Kinesis ストリームからのイベントトリガーへの応答機能を備えた AWS Lambda のプレビューリリース。 2015 年 – 一般提供の開始 、 Amazon Simple Notification Service (Amazon SNS) 通知のトリガーとしての使用、 Java で記述された Lambda 関数のサポート。 2016 年 – DynamoDB Streams のサポート、 Python のサポート、 関数の実行時間 を 5 分間に増加 (後に 15 分間に増加) 。 VPC 内のリソース へのアクセス、Amazon Aurora ストアドプロシージャから Lambda 関数を呼び出す 機能、 環境変数 、 Serverless Application Model 。この年には、Step Functions も 導入 され、複数の Lambda 関数を組み合わせてより複雑なアプリケーションを構成できるようになりました。 2017 年 – AWS X-Ray のサポート 、 AWS SAM Local と Serverless Application Repository のリリース。 2018 年 – イベントトリガーとしての Amazon SQS のサポート 、 Lambda を利用したマクロで AWS CloudFormation を拡張 する機能、 任意のプログラミング言語で Lambda 関数を記述する 機能。 2019 年 – パフォーマンスをさらに制御できるようにするための、 プロビジョンド同時実行性 のサポート。 2020 年 – 最大 17% 節約 できる Savings Plans へのアクセス、Lambda 関数が 共有ファイルシステムにアクセス する機能、 プライベートネットワーク経由で関数にアクセス するための AWS PrivateLink のサポート、 コード署名 、 1 ミリ秒の粒度 での課金、 最大 10 MB のメモリと 6 vCPU を使用できる関数、 コンテナイメージのサポート 。 2021 年 – S3 から取得されるデータを処理できるようにするための Amazon S3 Object Lambda 、 AWS Lambda 拡張機能 、 Graviton プロセッサでの Lambda 関数の実行 のサポート。 2022 年 – 関数呼び出しごとに最大 10 GB のエフェメラルストレージ 、Lambda 関数の HTTPS エンドポイント 、および関数呼び出しをより高速かつ予測可能にする Lambda SnapStart のサポート。 2023 年 – CloudFront 、 レスポンスストリーミング 、および予測不可能な量のリクエストを処理する際の 12 倍高速な関数スケーリング の、Amazon S3 Object Lambda のサポート。 2024 年 – Lambda 関数のログをより簡単に キャプチャおよび検索 できるようにする新しいコントロール、 ARM64 アーキテクチャを使用する Java 関数 の SnapStart サポート、 再帰ループ検出 、VS Code をベースとする 新しいコンソールエディタ 、および 強化されたローカル IDE エクスペリエンス 。過去 2 回のリリースは、Lambda 関数の構築、テスト、デバッグ、およびデプロイをより容易にすることで、デベロッパーエクスペリエンスを改善することを目的としていました。 繰り返しますが、これは私たちがリリースしたもののほんの一部にすぎません。さらに多くのリリースをご覧になりたい場合は、 Lambda カテゴリ のタグをチェックして、 Lambda の最新情報 を検索してください。 サーバーレスの次の 10 年 当初から、サーバーレスのビジョンは、デベロッパーがアイデアからビジネス価値の実現へとより迅速に移行するのをサポートするということでした。それを念頭に置いて、最初の 10 年間の Lambda の方向性を見ると、私には明らかに見える傾向がいくつかあります。 デフォルトの選択 – サーバーレスモデルは間違いなく定着しており、時間が経過する中でデフォルトの運用モデルになる可能性があります。 コンポーザビリティに向けた継続的なシフト – 時間が経過していく中で、サーバーレスアプリケーションでは、再利用可能な事前構築済みのコンポーネントの使用が増え続けていくだろうと考えています。AI を活用した開発ツールの支援により、多くの新しいコードが、新しい強力な方法で既存のコンポーネントをつなぐことに焦点を当てるようになるでしょう。これにより、アプリケーション全体の一貫性と信頼性も向上していくでしょう。 自動化された AI 最適化インフラストラクチャ 管理 – Lambda によってインフラストラクチャの管理に必要な時間と労力が削減されることは既にご説明しました。今後、機械学習や他の形態の AI は、人的介入を最小限に抑えながら、リソースを最適に割り当てることで、コストとパフォーマンスの最適化に役立つでしょう。アプリケーションは、自動化され、自己修復機能と耐障害性機能を備えたインフラストラクチャ上で実行されることになるでしょう。 拡張性と統合 – 前の 2 つの項目の結果として、アプリケーションはこれまで以上に簡単に成長し、変化する状況に適応できるようになるはずです。 セキュリティ – 自動化されたインフラストラクチャ管理、リアルタイムモニタリング、他の形式の脅威検出、AI 支援による是正が連携して、サーバーレスアプリケーションをさらに安全にするでしょう。 Lambda のリソース 既に Lambda を使用してサーバーレスアプリケーションを構築しているのであれば、それはすばらしいことです。 使用を開始する準備ができたら、次のリソースが役立ちます。 サーバーレストレーニング – 無料の サーバーレスラーニングプラン に登録して、サーバーレスの概念、一般的なパターン、ベストプラクティスについて学習できます。「 Serverless Ramp-Up Guide 」を読み、(トピックと言語の両方で) 幅広い数々の デジタルトレーニングコース と対面の クラスルームトレーニング をご覧ください: 導入事例 – AWS サーバーレスのお客様の導入事例 で、AWS のお客様が Lambda や他のサーバーレステクノロジーを使用してどのように構築し、イノベーションを起こしているのかをご覧ください。 re:Invent 2024 セッション – re:Invent 2024 セッションカタログを参照して、 サーバーレスコンピューティングとコンテナ に焦点を当てた約 200 のセッションを見つけてください。 ポッドキャスト – AWS デベロッパーポッドキャストのエピソード 137 ( AWS Lambda: A Decade of Transformation ) で、 Marc Brooker と Julian Wood が Lambda の起源、進化、影響について語るのをお聴きください。 新しい書籍 – サーバーレス開発とアーキテクチャに関する最新の書籍をいくつかご紹介します。 Serverless Development on AWS: Building Enterprise-Scale Serverless Solutions Advanced AWS Lambda: Comprehensive Guide to Serverless Computing Building Modern Applications with Serverless Event-Driven Architecture with AWS Lambda and SNS Serverless Microservices with AWS Mastering Serverless Architectures with AWS Lambda AWS Lambda の過去、現在、そして未来についての、ある程度詳しい概要をお楽しみいただけたのであれば幸いです。コメントを残して、ぜひご感想をお聞かせください。 – Jeff ; 原文は こちら です。

11 月 15 日、PostgreSQL や MySQL などのデータベースで行われた変更をキャプチャし、その更新を Amazon Simple Storage Service (Amazon S3) 上の Apache Iceberg テーブルにレプリケートする、 Amazon Data Firehose の新機能がプレビューで使用可能になったことをお知らせします。 Apache Iceberg は、ビッグデータ分析を実行するための高性能なオープンソーステーブル形式です。Apache Iceberg は、SQL テーブルの信頼性とシンプルさを S3 データレイクにもたらし、 Apache Spark 、 Apache Flink 、 Trino 、 Apache Hive 、 Apache Impala などのオープンソース分析エンジンが同じデータを同時に使用できるようにします。 この新機能は、データベースアプリケーションのトランザクションパフォーマンスに影響を及ぼすことなく、データベース更新をストリーミングするためのシンプルなエンドツーエンドのソリューションを提供します。数分で Data Firehose ストリームをセットアップして、データベースから 変更データキャプチャ (CDC) の更新を配信できます。今後は、さまざまなデータベースから Amazon S3 上の Iceberg テーブルにデータを簡単にレプリケートし、最新のデータを大規模な分析や機械学習 (ML) アプリケーションのために使用できるようになりました。 一般的な Amazon Web Services (AWS) エンタープライズのお客様は、トランザクションアプリケーションのために数百のデータベースを使用しています。これらのお客様は、最新のデータに対して大規模な分析と ML を実行するために、テーブル内のレコードが挿入、変更、または削除されたときなど、データベースで行われた変更をキャプチャし、Apache Iceberg などのオープンソーステーブル形式でデータウェアハウスまたは Amazon S3 データレイクに更新を配信したいと考えています。 これを実行するために、多くのお客様は、データベースから定期的に読み取る抽出、変換、ロード (ETL) ジョブを開発しています。ただし、ETL リーダーはデータベーストランザクションのパフォーマンスに影響を及ぼし、バッチジョブによって、データが分析に使用できるようになるまでに数時間の遅延が発生する可能性があります。データベーストランザクションのパフォーマンスに対する影響を軽減するために、お客様は、データベースで行われた変更をストリーミングする機能を求めています。このストリームは、変更データキャプチャ (CDC) ストリームと呼ばれます。 私は、 Debezium などのオープンソース分散システムを、一般的なデータベースへのコネクタ、 Apache Kafka Connect クラスター、および Kafka Connect Sink とともに使用して、イベントを読み取って宛先に配信している複数のお客様に会いました。このようなシステムの初期設定とテストには、複数のオープンソースコンポーネントのインストールと設定が含まれます。これには、数日または数週間かかる場合があります。セットアップ後、エンジニアはクラスターをモニタリングおよび管理し、オープンソースの更新を検証して適用する必要があり、これにより運用オーバーヘッドが増加します。 この新しいデータストリーミング機能により、Amazon Data Firehose は、データベースから CDC ストリームを取得して、Amazon S3 上の Apache Iceberg テーブルに継続的にレプリケートできるようになります。ソースと宛先を指定することによって、Data Firehose ストリームをセットアップします。Data Firehose は、最初のデータスナップショットをキャプチャして継続的にレプリケートし、選択したデータベーステーブルに加えられたすべての後続の変更をデータストリームとしてキャプチャします。CDC ストリームを取得するために、Data Firehose はデータベースレプリケーションログを使用します。これにより、データベーストランザクションのパフォーマンスへの影響が軽減されます。データベース更新の量が増減すると、Data Firehose はデータを自動的にパーティショニングし、宛先に配信されるまでレコードを保持します。キャパシティをプロビジョニングしたり、クラスターを管理およびファインチューニングしたりする必要はありません。データ自体に加えて、Data Firehose は、最初の Data Firehose ストリーム作成の一環として、データベーステーブルと同じスキーマを使用して Apache Iceberg テーブルを自動的に作成し、ソーススキーマの変更に基づいて、新しい列の追加など、ターゲットスキーマを自動的に進化させることができます。 Data Firehose はフルマネージドサービスであるため、オープンソースコンポーネントに依拠したり、ソフトウェア更新を適用したりする必要はなく、運用上のオーバーヘッドも発生しません。 Amazon Data Firehose を使用して Amazon S3 上の Apache Iceberg テーブルにデータベースの変更を継続的にレプリケーションすることで、CDC ストリームをデータレイクまたはデータウェアハウスに配信するためのシンプルでスケーラブルなエンドツーエンドのマネージドソリューションが提供され、大規模な分析や ML アプリケーションを実行できます。 新しいパイプラインを設定する方法を見てみましょう 新しい CDC パイプラインを作成する方法を示すために、 AWS マネジメントコンソール を使用して Data Firehose ストリームをセットアップしました。いつものように、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、 AWS CloudFormation 、または Terraform を使用することもできます。 このデモでは、ソースとして Amazon Relational Database Service (Amazon RDS) 上の MySQL データベースを選択します。Data Firehose は、 Amazon Elastic Compute Cloud (Amazon EC2) 上のセルフマネージドデータベースでも機能します。トラフィックをインターネットに公開することなく、データベースがデプロイされている仮想プライベートクラウド (VPC) と、RDS API 間の接続を確立するために、 AWS PrivateLink VPC サービスエンドポイントを作成します。 RDS API の VPC サービスエンドポイントを作成する方法 については、 Amazon RDS ドキュメント の手順に従ってください。 Iceberg テーブルをホストするための S3 バケットもあり、適切な許可で設定されている AWS Identity and Access Management (IAM) ロールもあります。Data Firehose ドキュメントの 前提条件 のリストをご参照いただけます。 使用を開始するには、コンソールを開いて Amazon Data Firehose セクションに移動します。既に作成されたストリームを確認できます。新しいストリームを作成するには、 [Firehose ストリームを作成] を選択します。 [ソース] と [宛先] を選択します。この例では、MySQL データベースと Apache Iceberg テーブルです。ストリームの [Firehose ストリーム名] も入力します。 [データベースエンドポイント] の完全修飾 DNS 名と [データベース VPC エンドポイントサービス名] を入力します。 [SSL を有効にする] がオンになっていることを確認し、 [シークレット名] で、データベースのユーザー名とパスワードが安全に保存されている AWS Secrets Manager のシークレットの名前を選択します。 次に、明示的な名前または正規表現を使用してデータベース、テーブル、列を指定し、特定のデータをキャプチャするように Data Firehose を設定します。 ウォーターマークテーブルを作成する必要があります。このコンテキストでのウォーターマークは、Data Firehose がデータベーステーブルの増分スナップショットの進行状況を追跡するために使用するマーカーです。これは、テーブルのどの部分が既にキャプチャされているか、どの部分がまだ処理される必要があるのかを Data Firehose が識別するのに役立ちます。ウォーターマークテーブルは手動で作成できます。また、Data Firehose に自動的に作成させることもできます。その場合、Data Firehose に渡されるデータベース認証情報には、ソースデータベースにテーブルを作成するための許可が必要です。 次に、使用する S3 バケットの [リージョン] と名前を設定します。Data Firehose は、Iceberg テーブルがまだ存在しない場合、Iceberg テーブルを自動的に作成できます。同様に、データベーススキーマの変更を検出すると、Iceberg テーブルスキーマを更新できます。 最後のステップとして、ストリームの進行状況と最終的なエラーに関するフィードバックを取得するために、 Amazon CloudWatch のエラーログ記録を有効にすることが重要です。ログストレージのコストを削減するために、 CloudWatch ロググループの保持期間を短く設定 できます。 設定を確認したら、 [Firehose ストリームを作成] を選択します。 ストリームが作成されると、データのレプリケーションが開始されます。ストリームのステータスをモニタリングし、最終的なエラーを確認できます。 これで、ストリームをテストする準備が整いました。 データベースへの接続を開き、テーブルに新しい行を挿入します。 その後、宛先として設定された S3 バケットに移動し、テーブルからのデータを保存するためのファイルが作成されていることを確認します。 そのファイルをダウンロードし、 parq コマンドを使用してその内容を検査します (このコマンドは pip install parquet-cli を使用してインストールできます) 当然ながら、 Parquet ファイルのダウンロードと検査は、デモのためにのみ行います。実際には、 AWS Glue と Amazon Athena を使用して、 データカタログ を管理し、データに対して SQL クエリ を実行します。 知っておくべきこと 他にも知っておくべきことがいくつかあります。 この新しい機能は、Amazon EC2 上のセルフマネージド PostgreSQL および MySQL データベースと、Amazon RDS 上の次のデータベースをサポートします: Amazon RDS for PostgreSQL 、 Amazon Aurora PostgreSQL 互換エディション Amazon RDS for MySQL 、 Amazon Aurora MySQL 互換エディション チームは、プレビュー期間中および一般提供の開始後も、データベースのサポートを継続的にさらに追加していく予定です。SQL Server、Oracle、および MongoDB データベースのサポートに既に取り組んでいる旨をチームから聞いています。 Data Firehose は、 AWS PrivateLink を使用して、 Amazon Virtual Private Cloud (Amazon VPC) 内のデータベースに接続します。 Amazon Data Firehose 配信ストリームを設定する場合、特定のテーブルと列を指定するか、ワイルドカードを使用してテーブルと列のクラスを指定できます。ワイルドカードを使用すると、Data Firehose ストリームの作成後に新しいテーブルと列がデータベースに追加され、それらがワイルドカードと一致する場合、Data Firehose は宛先にそれらのテーブルと列を自動的に作成します。 料金と利用可能なリージョン 新しいデータストリーミング機能は、中国リージョン、AWS GovCloud (米国) リージョン、アジアパシフィック (マレーシア) リージョンを除くすべての AWS リージョンで現在ご利用いただけます。この新しい機能を評価し、フィードバックをぜひお寄せください。プレビューの開始時には、使用料はかかりません。将来的に、読み取りおよび配信されたバイト数など、実際の使用量に基づいて料金が決定されます。一定量の使用の確約や先行投資はありません。必ず料金ページで詳細をお読みください。 Amazon S3 上の Apache Iceberg テーブルへの 最初の継続的なデータベースレプリケーションを設定 し、 http://aws.amazon.com/firehose にアクセスしましょう。 — seb 原文は こちら です。

AWS Identity and Access Management (IAM) は、セキュリティチームが AWS Organizations のメンバーアカウントの ルートアクセスを一元管理 できるようにする新しい機能をリリースします。これにより、ルート認証情報を簡単に管理し、高度な特権が必要なアクションを実行できるようになりました。 ルートユーザー認証情報の大規模な管理 長い間、 Amazon Web Services (AWS) アカウントは、アカウントに対する無制限のアクセスを持つ高度な特権が付与されたルートユーザー認証情報を使用してプロビジョニングされていました。このルートアクセスは強力である一方で、重大なセキュリティリスクをもたらすものでもありました。各 AWS アカウントのルートユーザーは、多要素認証 (MFA) などの保護レイヤーを追加することによって保護する必要がありました。セキュリティチームは、これらのルート認証情報を手動で管理および保護する必要がありました。このプロセスでは、認証情報を定期的にローテーションし、安全に保管して、認証情報がセキュリティポリシーに準拠していることを確認する必要がありました。 お客様が AWS 環境を拡張するにつれて、この手動アプローチは煩雑になり、エラーが発生しやすくなりました。例えば、数百または数千のメンバーアカウントを運用している大企業は、すべてのアカウントで一貫性をもってルートアクセスを保護するのに苦労していました。手動での介入は運用上のオーバーヘッドを増やすだけでなく、アカウントのプロビジョニングに遅れを生じさせ、完全なオートメーションを妨げ、セキュリティリスクを増大させます。ルートアクセスは、適切に保護されていない場合、アカウントの乗っ取りや機密リソースへの不正アクセスにつながる可能性があります。 さらに、 Amazon Simple Storage Service (Amazon S3) バケットポリシー または Amazon Simple Queue Service (Amazon SQS) リソースポリシー のロック解除などの特定のルートアクションが必要な場合、セキュリティチームはルート認証情報を取得して使用する必要があり、これはアタックサーフェスを拡大させます。厳密なモニタリングと強力なセキュリティポリシーがあっても、ルート認証情報を長期間にわたって維持すると、管理上のミス、コンプライアンスリスク、および人的エラーが発生する可能性が生じます。 セキュリティチームは、より自動化されたスケーラブルなソリューションを求め始めました。ルート認証情報の管理を一元化するだけでなく、そもそも長期的な認証情報を必要とせずにルートアクセスをプログラムで管理する方法を必要としていました。 ルートアクセスを一元管理する ルートアクセスを一元管理する新しい機能により、複数のアカウントにわたるルート認証情報の管理という長年の課題に対処できます。この新しい機能では、 ルート認証情報の一元管理 と ルートセッション という 2 つの重要な機能が導入されています。これらを組み合わせることで、セキュリティチームは AWS Organizations のメンバーアカウント全体でルートアクセスを管理するための安全かつスケーラブルでコンプライアンスに準拠した方法を利用できるようになります。 まず、 ルート認証情報の 一元管理 について説明しましょう。この機能により、AWS Organizations のすべてのアカウントで特権ルート認証情報を一元管理および保護できるようになりました。ルート認証情報管理により、次が可能になります。 長期ルート認証情報を削除する – セキュリティチームは、メンバーアカウントからルートユーザー認証情報をプログラムで削除できるようになりました。これにより、長期の特権認証情報が悪用される脆弱性を排除できます。 認証情報をリカバリできないようにする – 認証情報を削除するだけでなく、リカバリも防止し、将来における意図しないまたは不正なルートアクセスから保護します。 セキュアバイデフォルトアカウントをプロビジョニングする – 最初からルート認証情報なしでメンバーアカウントを作成できるようになったため、アカウントのプロビジョニング後に MFA などの追加のセキュリティ対策を適用する必要がなくなりました。アカウントはセキュアバイデフォルトであるため、長期的なルートアクセスに関連するセキュリティリスクが大幅に軽減され、プロビジョニングプロセス全体が簡素化されます。 コンプライアンス状態の維持をサポートする – ルート認証情報の管理により、セキュリティチームは、すべてのメンバーアカウントのルート認証情報のステータスを一元的に検出およびモニタリングすることでコンプライアンスを実証できます。この自動化された可視性により、長期的なルート認証情報が存在しなくなるため、セキュリティポリシーと規制要件を満たしやすくなります。 しかし、アカウントで選択したルートアクションを実行できることをどのように確認すればよいでしょうか。 ここで、11 月 15 日にリリースした 2 番目の機能、 ルートセッション をご紹介します。これは、長期的なルートアクセスを維持する安全な代替手段を提供します。セキュリティチームは、特権アクションが必要なときにいつでも手動でルート認証情報にアクセスする代わりに、メンバーアカウントに対する、タスクの範囲に限定された短期ルートアクセスを取得できるようになりました。この機能により、S3 バケットポリシーや SQS キューポリシーのロック解除などのアクションを、長期ルート認証情報を必要とせずに安全に実行できるようになります。 ルートセッションの主な利点には次が含まれます。 タスクの範囲に限定されたルートアクセス – AWS は、最小特権のベストプラクティスに準拠して、特定のアクションのための短期ルートアクセスを有効にします。これにより、実行できるアクションの範囲が制限されるとともに、アクセス期間が最小限に抑えられ、潜在的なリスクが軽減されます。 一元管理 – 各メンバーアカウントに個別にログインすることなく、中心的なアカウントから特権ルートアクションを実行できるようになりました。これにより、プロセスが合理化されるとともに、セキュリティチームの運用上の負担が軽減され、より高度なタスクに注力できるようになります。 AWS のベストプラクティスとの整合 – 短期認証情報を使用することで、組織は AWS セキュリティのベストプラクティスと整合できます。このベストプラクティスでは、最小特権の原則と、可能な場合は短期の一時アクセスの使用が重視されています。 この新しい機能は、フルルートアクセスを付与しません。以下の 5 つの特定のアクションのいずれかを実行するための一時的な認証情報を提供します。最初の 3 つのアクションは、ルートアカウントの中央管理で可能です。最後の 2 つは、ルートセッションを有効にすると可能になります。 ルートユーザー認証情報の監査 – ルートユーザー情報を確認するための読み取り専用アクセス アカウントリカバリの再有効化 – ルート認証情報なしでのアカウントリカバリの再アクティブ化 ルートユーザー認証情報の削除 – コンソールパスワード、アクセスキー、署名証明書、および MFA デバイスの削除 S3 バケットポリシーのロック解除 – すべてのプリンシパルを拒否する S3 バケットポリシーの編集または削除 SQS キューポリシーのロック解除 – すべてのプリンシパルを拒否する Amazon SQS リソースポリシーの編集または削除 メンバーアカウントでルート認証情報を取得する方法 このデモでは、管理アカウントを準備し、ルート認証情報なしでメンバーアカウントを作成して、そのメンバーアカウントで 5 つの承認済み API コールのいずれかを実行するために一時的なルート認証情報を取得する方法を説明します。組織は既に作成されているものとします。 まず、メンバーアカウントを作成します。 aws organizations create-account \ --email stormacq+rootaccountdemo@amazon.com \ --account-name 'Root Accounts Demo account' { "CreateAccountStatus": { "Id": "car-695abd4ee1ca4b85a34e5dcdcd1b944f", "AccountName": "Root Accounts Demo account", "State": "IN_PROGRESS", "RequestedTimestamp": "2024-09-04T20:04:09.960000+00:00" } } その後、管理アカウントで 2 つの新しい機能を有効にします。心配しないでください。これらのコマンドは、新しい機能の使用を有効にする以外に、アカウントの動作を変更することはありません。 ➜ aws organizations enable-aws-service-access \ --service-principal iam.amazonaws.com ➜ aws iam enable-organizations-root-credentials-management { "OrganizationId": "o-rlrup7z3ao", "EnabledFeatures": [ "RootCredentialsManagement" ] } ➜ aws iam enable-organizations-root-sessions { "OrganizationId": "o-rlrup7z3ao", "EnabledFeatures": [ "RootSessions", "RootCredentialsManagement" ] } あるいは、管理アカウントのコンソールを使用することもできます。 [アクセス管理] で、 [アカウントの設定] を選択します。 これで、一時的なルート認証情報を取得するためのリクエストを実行する準備ができました。認証情報の範囲を特定のアクションに絞り込むには、5 つのマネージド IAM ポリシーのうち、1 つを渡す必要があります。 ➜ aws sts assume-root \ --target-principal <my member account id> \ --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy { "Credentials": { "AccessKeyId": "AS....XIG", "SecretAccessKey": "ao...QxG", "SessionToken": "IQ...SS", "Expiration": "2024-09-23T17:44:50+00:00" } } アクセスキー ID、シークレットアクセスキー、セッショントークンを取得したら、いつもどおり AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK で使用します。 例えば、これらの 3 つの値を環境変数として渡すことができます。 $ export AWS_ACCESS_KEY_ID=ASIA356SJWJITG32xxx $ export AWS_SECRET_ACCESS_KEY=JFZzOAWWLocoq2of5Exxx $ export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2VjEMb//////////wEaCXVxxxx 一時的な認証情報を受け取ったので、メンバーアカウントでルートとして制限された API コールを実行できます。まず、ルート認証情報があることを検証します。 [Arn] フィールドでは、ルートアカウントを使用していることを確認できます。 # get Caller Identity を呼び出し、メンバーアカウントで自分がルートであることを確認します $ aws sts get-caller-identity { "UserId": "012345678901", "Account": "012345678901", "Arn": "arn:aws:iam::012345678901:root" } その後、S3 の delete-bucket-policy を使用して、バケットに適用されている誤ったポリシーを削除します。無効なポリシーにより、あらゆるユーザーのすべてのバケットアクセスが削除されました。このようなポリシーを削除するには、ルート認証情報が必要です。 aws s3api delete-bucket-policy --bucket my_bucket_with_incorrect_policy 出力がないことは、オペレーションが成功したことを意味します。これで、このバケットに正しいアクセスポリシーを適用できます。 認証情報は 15 分間のみ有効です。認証情報を JSON として取得して、正しい環境変数をエクスポートし、ルートとして実行するコマンドを発行する プロセスを自動化する短いシェルスクリプトを記述しました 。 利用可能なリージョン ルートアクセスの一元管理は、ルートアカウントがない AWS GovCloud (米国) および AWS 中国リージョンを除くすべての AWS リージョン で追加料金なしでご利用いただけます。ルートセッションはどこでもご利用いただけます。 IAM コンソール、AWS CLI、または AWS SDK を通じて使用を開始できます。詳細については、ドキュメントの「 AWS アカウントのルートユーザー 」にアクセスし、AWS アカウントを保護するためのベストプラクティスに従ってください。 — seb 原文は こちら です。

11 月 18 日週、 ブラジル で 2024 年最後のラテンアメリカ Amazon Web Services (AWS) Community Day が開催されました。また、これに並行して複数のイベントも開催されました。ゴイアニアでは、Senior Developer Advocate の Marcelo Palladino と AWS コミュニティビルダーの Marcelo Paiva 氏が基調講演を行いました。フロリアノポリスでは Senior Developer Advocate の Ana Cunha が出演しました。 チリのサンティアゴ では私も AWS コンテナヒーローの Rossana Suarez 氏とともに基調講演を行うことができて光栄でした。これらのイベントは、コミュニティによってコミュニティのために開催されるもので、ネットワークを築き、何か新しいことを学び、コミュニティに没頭する機会を提供します。コミュニティでは、誰もが共に成長し、取り残される人は 1 人もいません。 AWS Lambda は 10 周年を迎えました 。AWS Lambda は、私が AWS と出会うきっかけとなったサービスで、今でも私のお気に入りです。顧客のニーズから生まれ、サーバー管理なしでコードを実行できるようにすることで、クラウドコンピューティングに革命をもたらしました。誕生以来、Amazon.com の Chief Technology Officer である Dr. Werner Vogels のこの LinkedIn 投稿 にて、オリジナルの PR/FAQ 文書を通じて進捗が記録されています。このサービスは飛躍的に成長し、1 ミリ秒の請求精度や 10GB メモリのサポートなどの機能が導入されました。ありがとう、 AWS Lambda 。今後もたくさんの記念日を迎えられますように。 Amazon は、Trainium チップを使用する大学での AI 研究を支援するために 1 億 1,000 万 USD を投資しています。 このイニシアチブでは、AWS Trainium チップを使用するコンピューティングリソースを提供し、研究者が新しい AI アーキテクチャと機械学習のイノベーションを開発できるよう支援します。これらの開発内容は、より広範な進歩に向けてオープンソース化される予定です。AWS の CEO である Matt Garman による Linkedin の投稿 をご覧ください。 11 月11 日週のリリース re:Invent 2024 での AWS BuilderCards 第 2 エディション – re:Invent 2024 で、 Jeff Barr は AWS BuilderCards 第 2 エディションの発売を発表しました。デザインとゲームの仕組みの改善に加えて、生成 AI の新しいアドオンパックが含まれています。これまでのイベントでは 15,000 セット以上が配布され、ユーザーからの素晴らしいフィードバックも寄せられています。re:Invent 以降はオンラインで購入できるようになります。 Amazon EventBridge がイベントバスのエンドツーエンドのレイテンシーを最大 94% 改善したことを発表 – Amazon EventBridge はイベントバスのエンドツーエンドのレイテンシーを最大 94% 改善し、平均レイテンシーを 2,235.23 ミリ秒 (2023 年 1 月に測定) から 129.33 ミリ秒 (2024 年 8 月に P99 で測定) に短縮しました。この機能強化により、Amazon EventBridge が利用可能なすべての AWS リージョン (AWS GovCloud (米国) リージョンを含む) で、不正検知、産業オートメーション、ゲームなどの速度が重要視されるアプリケーションの処理を、追加料金なしで高速化できるようになります。 AWS Organizations の新しいタイプの認可ポリシーであるリソースコントロールポリシー (RCP) のご紹介 – リソースコントロールポリシー (RCP) は、 AWS Organizations の新しい認可ポリシーです。RCP を使用すると、プリンシパルの権限を制御するサービスコントロールポリシー (SCP) を補完して、リソースに付与される最大のアクセス許可を一元的に制御できます。RCP では、 Amazon Simple Storage Service (Amazon S3) バケット などのリソースへの外部アクセスを制限して、組織全体にデータ境界を適用することが可能です。 Amazon Data Firehose を使用して、データベースから Apache Iceberg テーブルに変更をレプリケート (プレビュー) – データベースの変更をキャプチャして Amazon S3 の Apache Iceberg テーブルにレプリケートする、 Amazon Data Firehose の新しいプレビュー機能です。この機能は PostgreSQL および MySQL データベースをサポートし、パフォーマンスに影響を与えることなくデータベースの更新をストリーミングするシンプルなソリューションを提供します。データの分割とスキーマの進化を自動的に処理するため、複雑な ETL プロセスが不要になります。 Amazon S3 が AWS アカウントあたり最大 100 万バケットのサポートを開始 – Amazon S3 は、デフォルトのバケットクォータを AWS アカウントあたり 100 から 10,000 に増やしました。お客様は最大 100 万バケットまでの増加をリクエストできるようになりました。最初の 2,000 バケットは無料で、それ以降は追加のバケットに少額の月額料金がかかります。 Amazon Keyspaces (Apache Cassandra 向け) が価格を最大 75% 引き下げ – Amazon Keyspaces (Apache Cassandra 向け) は最大 75% の大幅な値下げを発表しました。このサービスにより、オンデマンドモードの料金が、単一リージョンの場合は最大 56%、マルチリージョンの場合は最大 65% 引き下げられます。有効期限 (TTL) の削除料金も 75% 削減されました。 AWS Organizations を使用するお客様のためのルートアクセスの一元管理 – AWS Identity and Access Management (IAM) は、 AWS Organizations のルートアクセスを一元管理する新機能をリリースしました。この機能により、セキュリティチームはメンバーアカウントから長期的なルート認証情報を削除し、特定のアクションでタスクを対象とする一時的なルートセッションを使用できるようになります。このソリューションは、必要な特権操作を実行する機能を維持しながら永続的なルート認証情報を削除することで、セキュリティを強化します。 Amazon DynamoDB がオンデマンドスループットとグローバルテーブルの料金を値下げ – Amazon DynamoDB は、 オンデマンドモード のスループットコストを 50%、グローバルテーブルを最大 67% 削減するという大幅な値下げを発表しました。マルチリージョンのレプリケートされた書き込みが単一リージョンの料金と一致するようになりました。これらの変更により、ほとんどの DynamoDB ワークロードではオンデマンドモードが推奨されるようになります。 Datadog と Wiz 用の Amazon Q Developer プラグインの一般提供を開始 – Amazon Q Developer は、 Datadog と Wiz サービス用のプラグインの提供を開始し、ユーザーは AWS コンソール から直接これらのパートナー機能にアクセスできるようになりました。ユーザーは @datadog や @wiz などの自然言語コマンドを使用して情報をクエリし、リアルタイムの最新情報やセキュリティに関するインサイトを得ることができます。 その他の AWS ブログ記事 その他の興味深いプロジェクトとブログ記事をいくつかご紹介します。 Amazon SageMaker JumpStart の Stable Diffusion 3.5 Large のご紹介 – このパワフルな 81 億個のパラメータモデルにより、テキストプロンプトから写真のようにリアルで高品質な画像を生成できるようになりました。お客様はモデルを Amazon SageMaker JumpStart にシームレスにデプロイして使用し、Amazon SageMaker のセキュリティおよび機械学習オペレーション (MLOps) 機能の利点を活用することができます。 AWS AI と生成 AI サービスを使用した、ブラウザでのライブストリームの文字起こし、翻訳、要約 – このブログ記事では、AI サービスを使用してライブストリーミング体験を強化する Chrome 拡張機能を開発した経緯をご紹介します。この拡張機能は、 Amazon Transcribe 、 Amazon Translate 、 Amazon Bedrock を使用して、ライブストリームのリアルタイムの文字起こし、翻訳、要約をブラウザで直接提供します。文字起こしでは 50 言語以上、翻訳では 75 言語以上をサポートしているため、世界中からコンテンツにアクセスできるようになります。 Amazon Bedrock とベクトルデータベースによる自動車の損傷処理の簡素化 – このブログ記事では、 Amazon Bedrock とベクトルデータベースを組み合わせて自動車の損傷評価を合理化するソリューションをご紹介します。このシステムは、AI を使用して車両の損傷画像を分析し、費用を見積もり、既存のデータセットの類似事例と照合します。 Anthropic の Claude 3 と Amazon Titan Multimodal Embeddings を使用して、効率的で正確な処理を実現します。 Amazon Bedrock と Amazon Location Service で旅行計画に革命を – Amazon Bedrock と Amazon OpenSearch Service のベクトルデータベースを組み合わせ、AI を使用して画像を分析し、履歴データと照合して正確な修理見積もりを行うことで、自動車の損傷評価を自動化します。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Community Day  – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供されるコミュニティ主導のカンファレンスに参加しましょう。今後予定されている AWS Community Day は、 インドネシア (11 月 23 日) と、 インド、コーチ (12 月 14 日) です。 AWS re:Invent 2024 – ラスベガスで私たちと一緒に AWS のすべてを学びましょう。1 年に 1 度のカンファレンスは、スキルを伸ばすための最良かつ最速の方法です。直接参加できない場合は、オンラインで Watch re:Invent に登録して、バーチャルでご参加いただけます。 今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と、 デベロッパー向けのイベント をご覧ください。 AWS ビルダー ID を作成 し、エイリアスをご予約ください。ビルダー ID はユニバーサルログイン認証情報で、ユーザーは AWS マネジメントコンソールだけでなく、600 以上の無料トレーニングコース、コミュニティ機能、Amazon Q Developer をはじめとするデベロッパーツールなどの AWS ツールやリソースにアクセスできます。 11 月 18 日週のニュースは以上です。11 月 25 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! チリの AWS コミュニティの写真を提供してくれた Odina Jacobs に感謝します。 – Eli この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

この記事は、 AWS Payment Cryptography is PCI PIN and P2PE certified を翻訳したものです。 Amazon Web Services (AWS) は、 AWS Payment Cryptography (*1) がPayment Card Industry PIN Security Requirements Version 3.1 および PCI Point-to-Point Encryption (P2PE) Version 3.1 Decryption Componentに準拠したことを発表します。 Payment Cryptography を使用することで、PCI PIN Transaction Security (PTS) HSM認定を受け、AWSによって完全に管理されているPCI PIN / P2PEに準拠した鍵管理を備えたペイメントハードウェアセキュリティモジュール (HSM) を、決済業務アプリケーションで使用できます。これらの準拠により、コンプライアンス準拠のオーバーヘッドを削減しながら、準拠対象のワークロードを柔軟に展開することができます。 PCI P2PE Decryption Componentは、PCI P2PEソリューションが、AWSを使用して決済端末からのクレジットカードトランザクションを復号化することを可能にし、PCI PIN認証はPINベースのトランザクションを処理するアプリケーションでの利用に必要です。PCI SSCによると、「PCI P2PE ソリューションを使用することで、加盟店は決済業務で PCI DSS が適用される場所や方法を減らすことができ、PCI DSS への準拠を簡素化しながら顧客データのセキュリティを高めることができる」とあります。 サードパーティのQualified PIN Assessor (QPA) およびQualified Security Assessor (QSA) であるCoalfireが、Payment Cryptographyを評価しました。顧客は、 AWS Artifact を通じてPCI PIN Attestation of Compliance (AOC) レポート、PCI PIN Shared Responsibility Summary、PCI P2PE Attestation of Validationにアクセスできます。 AWSのPCIプログラムやその他のコンプライアンス、セキュリティプログラムの詳細については、 AWSコンプライアンスプログラム のページをご覧ください。AWSコンプライアンスチームへのお問い合わせは、 お問い合わせページ からお願いいたします。 この投稿に関するフィードバックがある場合は、以下のコメント欄にコメントをお寄せください。この投稿に関するご質問は、 AWS サポート までお問い合わせください。 (*1) AWS Payment Cryptographyに関しての AWSブログ もご参照ください。 本稿はソリューションアーキテクト畑が翻訳を担当しました。

この記事は Improving deployment visibility for Amazon ECS services (記事公開日 : 2024 年 11 月 7 日) の翻訳です。 ソフトウェアをデプロイする際、デプロイメントプロセスのすべてのステップを可視化することは非常に重要です。安全で信頼性の高いリリースプロセスを実現するためには、進行中のデプロイメントの状況を把握し、問題が発生した際にはトラブルシューティングを行い、過去のデプロイメントの監査証跡を保持しておく必要があります。これらのニーズに対応するために、 Amazon Elastic Container Service (Amazon ECS) は、強化された可視性とトレーサビリティの機能を提供開始しました。新しく導入されたサービスデプロイメント (サービスデプロイ) とサービスリビジョンを活用することで、Amazon ECS におけるアプリケーションデプロイメントについて、より深い洞察を得ることができます。 Amazon ECS において、 ECS サービス は長時間実行されるアプリケーションを管理するリソースであり、同一の ECSタスクのグループが Amazon ECS によってデプロイ、管理、スケーリングされます。新しいバージョンのソフトウェアをリリースする際は、Amazon ECS がデプロイメントプロセスを管理し、古いタスクを新しいタスクに 段階的に置き換えます 。Amazon ECS では、安全なソフトウェアリリースを実現するためのビルトインの保護機能を提供しており、例えば ECS deployment circuit breaker を用いると、新しいデプロイメントが失敗した際に、自動的に前のバージョンのサービスにロールバックさせることが可能です。今回のリリースでは、Amazon ECS の 2 つの新しいリソース (サービスリビジョン、サービスデプロイメント) と新しい API ( listServiceDeployments 、 describeServiceRevisions 、 describeServiceDeployments ) が導入され、デプロイメントプロセスの可視性が向上しました。 まず、サービスリビジョンは、Amazon ECS がデプロイするワークロードの設定を記録します。これには、タスク定義、コンテナイメージ、サービスレベルのパラメーター ( Amazon Elastic Block Store (Amazon EBS) ボリュームやロードバランサー、 ECS Service Connect の設定など) が含まれます。 また、サービスデプロイメント (サービスデプロイ) は、進行中または以前のサービスリビジョンのデプロイメントに関する包括的な視点を提供します。ここでは、デプロイメントの開始点 (ソースリビジョン)、どのデプロイメントがロールアウトされているのか (ターゲットリビジョン)、設定したサーキットブレイカーや Amazon CloudWatch アラーム を含むデプロイメントの状況を確認することができます。 これまで、Amazon ECS のデプロイメントの履歴を追跡することは困難でした。今回のリリースにより、成功したかどうかに関わらず、各サービスデプロイメントは 90 日間保持され、Amazon ECS コンソールまたは listServiceDeployments API を通じて確認できるようになりました。これにより、Amazon ECS サービスのデプロイメントの履歴を確認し、各ロールアウトでどのサービスリビジョンが使用されたかを把握することができます。 Amazon ECS は、これらの強化された可視性とトレーサビリティの機能を提供することで、アプリケーションデプロイメントに関するより優れた監視、トラブルシューティング、管理を可能にし、より信頼性と透明性の高いリリースプロセスを実現します。以下の図は、既存の Amazon ECS リソースと、新しく導入されたサービスデプロイメントおよびサービスリビジョンの関係を示します。 図 1 : サービスリビジョンとサービスデプロイメントの関係 ソリューション概要 このセクションでは、Amazon ECS にソフトウェアをデプロイする際に、サービスリビジョンとサービスデプロイメントがどのように可視性を向上させるのか、ハンズオン形式で説明していきます。この例では、まず新しいサービスを作成し、安定するまで待ちます。次に、既知のバグを含むリビジョンを作成し、エラーのトラブルシューティングやサーキットブレイカーの状態の管理において、新しく導入されたサービスデプロイメント API と Amazon ECS コンソールの「デプロイ」タブがどのように役立つかを確認していきます。 前提条件 このウォークスルーを完了するには、以下の前提条件が必要です。 Amazon ECS リソースを作成するための適切な権限を持った AWS CLI (新しく導入された API を利用するため、必要に応じて AWS CLI のバージョンを更新してください。) 既存の ECS クラスター 既存の ECS タスク実行ロール 既存の VPC サブネット と セキュリティグループ (このセキュリティグループには、インバウンドルールは不要です。) ウォークスルー 1. まず、このウォークスルー全体で使用する環境変数を設定 (export) します。これらのリソースが自身の AWS アカウントに存在することを確認し、自身のリソースの値に置き換えてください。 export AWS_REGION=ap-northeast-1 export ECS_EXECUTION_ROLE="arn:aws:iam::111222333444:role/ecsTaskExecutionRole" export ECS_CLUSTER="your-cluster-name" export VPC_SUBNET_ONE="subnet-07bd4d10ea848a008" export VPC_SUBNET_TWO="subnet-0ebc3139ba5dcf871" export VPC_SECURITY_GROUP="sg-003bf5ba3cb1a1168" 2. 無限にスリープする単一のコンテナで構成された、新しい ECS タスク定義を登録します。 cat <<EOF >>taskdefinition_one.json { "family": "deployment-demo", "executionRoleArn": "${ECS_EXECUTION_ROLE}", "networkMode": "awsvpc", "containerDefinitions": [ { "name": "demo", "image": "public.ecr.aws/amazonlinux/amazonlinux:2023-minimal", "command": [ "/bin/bash", "-c", "echo 'sleeping' && sleep infinity" ] } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "256", "memory": "512" } EOF aws ecs register-task-definition \ --cli-input-json file://taskdefinition_one.json 3. タスク定義を登録したら、既存の VPC サブネットとセキュリティグループを使用して、 AWS Fargate 上で実行するように設定した ECS サービスを作成します。 cat <<EOF >>service.json { "cluster": "${ECS_CLUSTER}", "serviceName": "deployment-demo", "taskDefinition": "deployment-demo", "desiredCount": 1, "launchType": "FARGATE", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": true, "rollback": true } }, "networkConfiguration": { "awsvpcConfiguration": { "subnets": [ "${VPC_SUBNET_ONE}", "${VPC_SUBNET_TWO}" ], "securityGroups": [ "${VPC_SECURITY_GROUP}" ], "assignPublicIp": "ENABLED" } } } EOF aws ecs create-service \ --cli-input-json file://service.json 4. 新しく導入された listServiceDeployments API を使用すると、作成したサービスに関連するサービスデプロイメントの一覧を確認することができます。(訳註 : もしエラーが出た場合は、AWS CLI のバージョンが十分新しいか、確認してください。) aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" このサービスは作成されたばかりなので、サービスデプロイメントは 1 つのみです。このサービスデプロイメントでは、ステータスが IN_PROGRESS (進行中) であり、ターゲットサービスリビジョンは 1544415738210471021 であることを確認できます。(これらの値はあくまで例で、実行する環境によって異なります。) { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/zKMCwZeZGjT20CtLyq9X9", "serviceArn": "arn:aws:ecs:ap-northeast-1:111222333444:service/default/deployment-demo", "clusterArn": "arn:aws:ecs:ap-northeast-1:111222333444:cluster/default", "startedAt": "2024-11-20T10:46:40.661000+09:00", "createdAt": "2024-11-20T10:46:36.612000+09:00", "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "status": "IN_PROGRESS" } ] } サービスデプロイメントの一覧は、Amazon ECS コンソールの「デプロイ」タブでも確認できます。 5. 新しく導入された describeServiceDeployments API を使用すると、特定のサービスデプロイメントに関して、そのリビジョンの希望タスク数やサーキットブレイカーの状況などの詳細情報を確認できます。 DEPLOYMENT_ARN=$(aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" \ --query "serviceDeployments[0].serviceDeploymentArn" \ --output text) aws ecs describe-service-deployments \ --service-deployment-arns $DEPLOYMENT_ARN ここで、出力の sourceServiceRevisions キーが空になっていることを確認できます。これは、このデプロイメントが、このサービスの最初のデプロイメントであることを示しています。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/zKMCwZeZGjT20CtLyq9X9", ... "sourceServiceRevisions": [], "targetServiceRevision": { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "requestedTaskCount": 1, "runningTaskCount": 1, "pendingTaskCount": 0 }, "status": "IN_PROGRESS", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": true, "rollback": true }, "maximumPercent": 200, "minimumHealthyPercent": 100 }, "deploymentCircuitBreaker": { "status": "MONITORING", "failureCount": 0, "threshold": 3 }, "alarms": { "status": "DISABLED" } } ], "failures": [] } サービスデプロイメントは、コンソール画面からも確認できます。 6. describeServiceRevisions API を使用すると、デプロイされているリソース (サービスリビジョン) に関するより詳細な情報を確認できます。 REVISION_ARN=$(aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" \ --query serviceDeployments[0].targetServiceRevisionArn \ --output text) aws ecs describe-service-revisions \ --service-revision-arns $REVISION_ARN この情報は、タスク定義リビジョンとサービスレベルのパラメーターで構成されています。 { "serviceRevisions": [ { "serviceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "serviceArn": "arn:aws:ecs:ap-northeast-1:111222333444:service/default/deployment-demo", "clusterArn": "arn:aws:ecs:ap-northeast-1:111222333444:cluster/default", "taskDefinition": "arn:aws:ecs:ap-northeast-1:111222333444:task-definition/deployment-demo:3", "launchType": "FARGATE", "platformVersion": "1.4.0", "platformFamily": "Linux", "networkConfiguration": {...}, "containerImages": [ { "containerName": "demo", "imageDigest": "sha256:96bbe031e236f8e767a358f6ba2e05a378508ae6227a814848a1c8a7833b5850", "image": "public.ecr.aws/amazonlinux/amazonlinux:2023-minimal" } ], "guardDutyEnabled": false, "createdAt": "2024-11-20T10:46:26.169000+09:00" } ], "failures": [] } 7. 次のステップに進む前に、デプロイメントが SUCCESSFUL になるのを待ちます。これには数分かかる可能性があります。以下のコマンドを実行して、デプロイメントの状態を確認してください。 aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" \ --query "serviceDeployments[0].status" \ --output text 8. 次に、不正な設定 (bash で exit 1 コマンドを実行) を含む新しいサービスリビジョンをロールアウトします。そのために、まず 2 つ目のタスク定義を登録します。 cat <<EOF >>taskdefinition_two.json { "family": "deployment-demo", "executionRoleArn": "${ECS_EXECUTION_ROLE}", "networkMode": "awsvpc", "containerDefinitions": [ { "name": "demo", "image": "public.ecr.aws/amazonlinux/amazonlinux:2023-minimal", "command": [ "/bin/bash", "-c", "echo 'sleeping' && sleep 15 && echo 'exiting' && exit 1" ] } ], "requiresCompatibilities": [ "FARGATE" ], "cpu": "256", "memory": "512" } EOF aws ecs register-task-definition \ --cli-input-json file://taskdefinition_two.json update-service コマンドを実行し、新しいサービスリビジョンを作成してデプロイメントを開始します。 cat <<EOF >>updateservice.json { "cluster": "${ECS_CLUSTER}", "service": "deployment-demo", "desiredCount": 1, "taskDefinition": "deployment-demo" } EOF aws ecs update-service \ --cli-input-json file://updateservice.json 9. listServiceDeployments API を使用して、再度このサービスに関連するサービスデプロイメントの一覧を確認しましょう。 aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" このサービスには、現在 2 つのデプロイメントが存在していることを確認できます。1 つは最初に完了したデプロイメント、もう 1 つは新しく開始した IN_PROGRESS (進行中) のデプロイメントです。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/WX4k57j4mYvJeZ3xc6Dli", ... "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/7111358678511081979", "status": "IN_PROGRESS" }, { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/zKMCwZeZGjT20CtLyq9X9", ... "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "status": "SUCCESSFUL" } ] } この一覧は、ECS コンソール「デプロイ」タブの「サービスデプロイ」からも確認できます。 10. 新しいサービスデプロイメントの詳細を確認すると、2 つの異なるサービスリビジョン間で ECS サービスを遷移させていることを確認できます。 DEPLOYMENT_ARN=$(aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" \ --query "serviceDeployments[0].serviceDeploymentArn" \ --output text) aws ecs describe-service-deployments \ --service-deployment-arns $DEPLOYMENT_ARN この例では、ソースリビジョンの ID は 1544415738210471021 で、ターゲットリビジョンの ID は 7111358678511081979 となっています。また、ロールアウトが進行中のため、サーキットブレイカーが MONITORING (監視中) の状態であることが分かります。さらに、このデプロイメントにおいて失敗したタスクの数 (failureCount) と、ロールバックをトリガーするためのしきい値 (threshold) を確認できます。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/WX4k57j4mYvJeZ3xc6Dli", ... "sourceServiceRevisions": [ { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "requestedTaskCount": 0, "runningTaskCount": 1, "pendingTaskCount": 0 } ], "targetServiceRevision": { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/7111358678511081979", "requestedTaskCount": 1, "runningTaskCount": 0, "pendingTaskCount": 1 }, "status": "IN_PROGRESS", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": true, "rollback": true }, "maximumPercent": 200, "minimumHealthyPercent": 100 }, "deploymentCircuitBreaker": { "status": "MONITORING", "failureCount": 2, "threshold": 3 }, "alarms": { "status": "DISABLED" } } ], "failures": [] } Amazon ECS コンソールの「デプロイ」タブでは、サービスリビジョンを比較するための画面が新しく導入されています。ここでは、異なるサービスリビジョン間の違いを視覚的に確認することができます。 11. 再度  describeServiceDeployments API を使用して、このデプロイメントの詳細を確認しましょう。 aws ecs describe-service-deployments \ --service-deployment-arns $DEPLOYMENT_ARN 時間の経過とともに、タスクが失敗し、 deploymentCircuitBreaker キーの下の failureCount が増加していきます。最終的に、サーキットブレイカーが TRIGGERED になり、ECS サービスは以前のサービスリビジョンにロールバックされます。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/WX4k57j4mYvJeZ3xc6Dli", ... "sourceServiceRevisions": [ { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "requestedTaskCount": 1, "runningTaskCount": 1, "pendingTaskCount": 0 } ], "targetServiceRevision": { "arn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/7111358678511081979", "requestedTaskCount": 0, "runningTaskCount": 0, "pendingTaskCount": 0 }, "status": "ROLLBACK_SUCCESSFUL", "statusReason": "Service deployment rolled back because the circuit breaker threshold was exceeded.", "deploymentConfiguration": { "deploymentCircuitBreaker": { "enable": true, "rollback": true }, "maximumPercent": 200, "minimumHealthyPercent": 100 }, "rollback": { "reason": "Service deployment rolled back because the circuit breaker threshold was exceeded.", "startedAt": "2024-11-20T10:57:06.840000+09:00", "serviceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021" }, "deploymentCircuitBreaker": { "status": "TRIGGERED", "failureCount": 3, "threshold": 3 }, "alarms": { "status": "DISABLED" } } ], "failures": [] } 12. 最後に、 listServiceDeployments API を使用して、すべてのサービスデプロイメントを確認しましょう。 aws ecs list-service-deployments \ --service deployment-demo \ --cluster "${ECS_CLUSTER}" 最初のデプロイメントと失敗したデプロイメントの両方が表示されていることを確認できます。 { "serviceDeployments": [ { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/WX4k57j4mYvJeZ3xc6Dli", ... "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/7111358678511081979", "status": "ROLLBACK_SUCCESSFUL", "statusReason": "Service deployment rolled back because the circuit breaker threshold was exceeded." }, { "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-deployment/default/deployment-demo/zKMCwZeZGjT20CtLyq9X9", ... "targetServiceRevisionArn": "arn:aws:ecs:ap-northeast-1:111222333444:service-revision/default/deployment-demo/1544415738210471021", "status": "SUCCESSFUL" } ] } 後片付け 以下のコマンドを実行すると、このウォークスルーで作成したサービスとタスク定義を削除できます。このウォークスルーを実施するために ECS クラスターや VPC を作成した場合は、それらのリソースも削除してください。 aws ecs delete-service \ --cluster "${ECS_CLUSTER}" \ --service "deployment-demo" \ --force TASK_DEFS=$(aws ecs list-task-definitions \ --family-prefix "deployment-demo" \ --query taskDefinitionArns \ --output text) for TASK_DEF in $TASK_DEFS do aws ecs deregister-task-definition --task-definition "${TASK_DEF}" done まとめ この記事では、新しく導入された Amazon ECS のサービスデプロイメントとサービスリビジョンの機能について深掘りしました。これらの機能により、ソフトウェアリリースプロセスの可視性とトレーサビリティが向上し、より自信を持ってデプロイできるようになります。サービスデプロイメントとサービスリビジョンを使用すると、進行中のロールアウトの状況を深く把握、問題をより効率的にトラブルシューティングし、過去のデプロイメントの履歴を確認できます。この強化された可視性は、より信頼性と透明性の高いソフトウェアリリースライフサイクルを実現するのに役立つでしょう。 Amazon ECS の各機能の詳細については、 Amazon ECS 開発者ガイド を確認することをおすすめします。実際に手を動かしながら学びたい場合は、より実践的なガイドと例を含む、 Amazon ECS ワークショップ もぜひ活用してみてください。

現代のクラウド中心のビジネス環境では、データが複数のクラウドやオンプレミスのシステムに分散していることが多くあります。この断片化は、お客様が機械学習 (ML) イニシアチブとして、データを統合し、分析する作業を複雑にしています。 本稿では、さまざまなクラウド環境の中でも Google Cloud Platform (GCP) BigQueryに焦点を当て、データソースを移動することなく、データを直接抽出するアプローチをご紹介します。これにより、クラウド環境間でデータ移動の際に発生する複雑さとオーバーヘッドを最小限に抑えることができるため、組織は ML プロジェクトで様々なデータ資産にアクセスし、活用できるようになります。 今回焦点を当てるのは、 Amazon Athena Federated Query を使用して、GCP BigQuery からデータを抽出し、 Amazon SageMaker Data Wrangler を使用してデータ準備を行い、準備されたデータをノーコードの ML インターフェースである Amazon SageMaker Canvas で ML モデルを構築する、という一連のプロセスです。 SageMaker Canvas では、ビジネスアナリストは、コーディングや幅広い機械学習の経験がなくても、50 を超えるソースのデータにアクセスしてインポートし、自然言語と 300 を超える組み込みの変換を使用してデータを準備し、高精度のモデルを構築してトレーニングし、予測を生成し、モデルを本番環境にデプロイすることができます。また、コネクタとして用意されていない場合も、Amazon Athena などのサービスを通じて、データを活用することもできます。今回は、コネクタを通じて利用できる Amazon Athena を活用して、GCP BigQuery へライブクエリを行う方法についてご紹介します。 ソリューション概要 ソリューションでの、主なステップは以下の 2 点です。 CGP BigQuery から Federated Query を Amazon Athena でセットアップし、Athena から直接 GCP BigQuery でライブクエリを実行できるようにします。 Athena を中継し、BigQuery から SageMaker Canvas にデータをインポートします。 データソースのクエリ結果が SageMaker Canvas へインポートされた後は、ノーコードのインターフェースを使用して ML モデルを構築し、インポートされたデータに基づいて予測を生成できるようになります。 SageMaker Canvas を使用すると、コードを書かずに初期データ準備のルーチンを作り、正確な予測を生成することができます。ただし、ML の要件が進化したり、より高度なカスタマイズが必要になった場合は、ノーコード環境からコードファーストのアプローチに移行しなくてはならなくなる可能性があります。SageMaker Canvas と Amazon SageMaker Studio を統合すると、本番規模のデプロイのための、データ準備ルーチンの運用を実現できます。詳細については、「 Seamlessly transition between no-code and code-first machine learning with Amazon SageMaker Canvas and Amazon SageMaker Studio 」を参照してください。 以下のアーキテクチャ概要は、AWS サービスを使用して GCP BigQuery データウェアハウスにシームレスにアクセスし、SageMaker Canvas に統合して ML モデルを構築およびデプロイする方法を示しています。 ワークフローには以下のステップが含まれています。 SageMaker Canvas インターフェース上で、ユーザーは GCP BigQuery データウェアハウスに対して実行する SQL クエリを作成します。SageMaker Canvas はこのクエリを Athena に受け渡します。Athena は 中継として機能し、SageMaker Canvas と BigQuery 間の通信を促します。 Athena は、 Athena Google BigQuery connector を使用します。 Athena Federated Query は、 AWS Lambda 関数を利用してデータソースに接続し、クエリを実行する機能です。この Lambda 関数は、GUI 上で構成が可能です。また、必要な BigQuery の認証情報 (service account private key ) を取得します。 認証後は、Lambda 関数は、取得した認証情報を使用して BigQuery へクエリし、目的の結果セットを取得します。さらにこの結果セットをパースし、Athena に返送します。 Athena は、BigQuery からクエリされたデータを SageMaker Canvas へ返します。ノーコードインターフェース上で、ML モデルの学習や開発にそのデータを利用することができるようになります。 このソリューションには、次のメリットがあります。 シームレスな統合 – SageMaker Canvas を使用すると、BigQuery などのクラウド データウェアハウスを含む、様々なソースからのデータを、ノーコードの ML 環境へ直接統合し、使用できるようになります。この統合で、追加のデータ移動や複雑な統合が不要になります。データエンジニアリング タスクのオーバーヘッドがなくなるため、ML モデルの構築とデプロイに集中できるようになります。 セキュアなアクセス – Secrets Manager を使用すると、BigQuery の認証情報を安全に保存し、アクセスできるようになるため、ソリューション全体のセキュリティが強化されます。 スケーラビリティ – Lambda 関数のサーバレスの性質と、Athena の大規模データセットを処理する能力により、増大するデータ量に対応できるようになります。さらに、複数のクエリを使って、データをソースに対して並列に、パーティション分割することができます。 次のセクションでは、技術的な実装の詳細を詳しく説明し、このソリューションを順に説明します。 データセット 本稿では、ノーコード ML を行うために SageMaker Canvas にデータをインポートする方法の例を示しています。この例では、GCP BigQuery から Athena を介して、データをインポートする方法を示しています。 データセットとしては、通信携帯電話キャリアのデータセット ( synthetic dataset ) を使用します。このサンプルデータセットは、5,000 件のレコードが含まれ、各レコードでは、顧客プロファイルとして 21 個の属性を使用しています。データセットの Churn 列は、顧客が解約したかどうか (true/false) を示します。この Churn 属性は、ML モデルが予測するターゲット変数です。 前提条件 以下の前提条件のステップを完了させてください。 GCP の service account と service account key を作成します。 private key を JSON ファイルでダウンロードします。 JSON ファイルを Secrets Manager へ保存します。 Secrets Manager コンソール上で、ナビゲーションペインの「シークレット」を選択し、「新しいシークレットを保存する」を選択します。 シークレットのタイプは「その他のシークレットのタイプ」を選択します。 JSON ファイルの内容をコピーし、「キー/値のペア」の「プレーンテキスト」タブへ入力します。 SageMaker ドメインをまだ作成していない場合、ユーザープロファイルと共に作成してください。手順については「 Quick setup to Amazon SageMaker 」を参照してください。 以下のリソースに対して、SageMaker ドメインのユーザープロファイルの AWS Identity and Access Management (IAM) ロールに、 glue:GetDatabase と athena:GetDataCatalog の権限が付与され、Athena を呼び出せるようになっていることを確認します。既定では以下の権限は付与されていないため、必要に応じて付与してください。設定には、次の例を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "glue:GetDatabase", "athena:GetDataCatalog" ], "Resource": [ "arn:aws:glue:*: <AWS account id> :catalog", "arn:aws:glue:*: <AWS account id> :database/*", "arn:aws:athena:*: <AWS account id> :datacatalog/*" ] } ] } Athena データソースコネクタを登録する 以下の Athena data source connector のセットアップを完了させてください。 Athena コンソール上で、ナビゲーションペインの「データソース」を選択します。 「データソースの作成」を選択します。 「データソースを選択」ページで、「Google BigQuery」を選択し、「次へ」を選択します。 「データソースの詳細を入力」ページで、以下の情報を入力します。 「データソース名」で、任意の名前を入力します。 「説明」で、オプションとして説明を入力します。 「Lambda 関数」で、接続の設定を行うために「Lambda 関数の作成」をクリックします。  Lambda 関数の作成画面の「アプリケーションの設定」で、以下の情報を入力します。 「SpillBucket」で、Lambda 関数のレスポンスサイズ制限を超えるデータを保存するための、アカウント内の S3 バケットの名前を入力します。 「GCPProjectID」で、GCP の project ID を入力します。 「LambdaFunctionName」で、作成した Lambda 関数の名前を入力します。 「SecretNamePrefix」で、Secrets Manager で保存した GCP 認証情報が含まれるシークレットの名前を入力します。 「デプロイ」を選択します。「データソースの詳細を入力」ページに戻ります。 「接続の詳細」セクションで、「Lambda 関数」で更新アイコンを押します。 先ほど作成した Lambda 関数を選択します。Lambda 関数の ARN が表示されます。 オプションとして、「タグ」で、データソースに紐づける「キー/値」のペアを追加します。タグについて詳細は「 Tagging Athena resources 」を参照してください。 「次へ」を選択します。 「確認と作成」ページで、データソースの詳細を確認し「データソースを作成」を選択します。 データソースのページでの「データソースの詳細」セクションでは、新しいコネクタの情報が表示されます。Athena クエリで、そのコネクタを利用することができます。クエリでのデータコネクタを利用する事について、詳細は「 Running federated queries 」を参照してください。 Athena から クエリするには、Athena SQL エディタを開き、先ほど作成したデータソースを選択してください。BigQuery のデータセットに対して、ライブクエリを行うことができます。 Athena をデータソースとして SageMaker Canvas に接続する Athena からデータをインポートするために、以下のステップを完了させてください。 SageMaker Canvas コンソールで、ナビゲーションペインの「Data Wrangler」を選択します。 「Import data and prepare」を選択します。 「Tabular」を選択します。 データソースとして、「Athena」を選択します。 SageMaker Canvas の SageMaker Data Wrangler では、データの準備、特徴量エンジニアリング、分析を行うことができます。コーディングをほとんど使わず、またはノーコードで、 SageMaker Data Wrangler データ準備フローを ML ワークフローに統合することができます。データの前処理、特徴量エンジニアリングを簡素化し、合理化します。 左ペインの AWSDataCatalog で Athena テーブルを選択し、テーブルを右ペインへ ドラッグ ＆ ドロップ します。 「Edit in SQL」を選択し、次の SQL クエリを入力します。 SELECT state, account_length, area_code, phone, intl_plan, vmail_plan, vmail_message, day_mins, day_calls, day_charge, eve_mins, eve_calls, eve_charge, night_mins, night_calls, night_charge, intl_mins, intl_calls, intl_charge, custserv_calls, churn FROM " bigquery "." athenabigquery "." customer_churn " order by random() limit 50 ; 上記のクエリでは、 bigquery は Athena で作成されたデータソース名、 athenabigquery はデータベース名、 customer_churn はテーブル名です。 データセットの準備のため「Run SQL」を選択します。データが十分であれば、「Import」を選択します。 ML を使用する場合、データセットをランダム化、またはシャッフルすることが重要です。数百万または数十億のデータポイントにアクセスできる場合でも、データセットの全量が必要ない場合は、ランダムにサンプリングすることで、学習用のサブセットを作成できます。データをシャッフルして準備したら、データの準備、特徴量評価、モデルの学習、学習済みモデルのホスティングという、反復的なプロセスを開始できます。 SageMaker Data Wrangler を使うと、データを処理したり、ML ワークフローに適した場所にエクスポートできます。例えば、変換されたデータを、SageMaker Canvas データセットとしてエクスポートし、そこから ML モデルを作成できます。 また、ML モデル作成に利用する学習用のデータセットと別に、推論評価用のデータセットを分けて保存しておくことをお勧めします。その場合、SageMaker Data Wrangler の組み込みのデータ変換「Split data」を Steps の一つとして追加すると、容易に分割を行うことができます。 データをエクスポートした後、「Create model」を選択して、データから ML モデルを作成します。 データは、Athena の特定のテーブルからデータセットとして SageMaker Canvas にインポートされます。これで、このデータセットを使用してモデルを作成できます。 モデルの学習 データがインポートされると、SageMaker Canvas の「Datasets」ページに表示されます。この段階になると、モデルを構築することができます。そのためには、次の手順を行ってください。 データセットを選択してから、「Create a model」を選択します。 「Model name」で、任意のモデル名を入力してください。(本稿では my_first_model )SageMaker Canvas では、予測分析、画像分析、テキスト分析のモデルを作成できます。 今回は顧客が解約したかどうかを分類したいため、「Problem type」で「Predictive analysis」を選択します。 「Create」を選択します。 「Build」ページで、欠損値の割合やデータのモードなど、データセットに関する統計情報を確認できます。 「Target column」で、予測したい列を選択します。(本稿では churn )SageMaker Canvas では、予測を生成するために、2 種類のモデルが提供され。Quick build は、制度よりも速度が優先され、2 〜 15 分でモデルが提供されます。Standard build では、速度よりも精度が優先され、30 分 〜 2 時間でモデルが提供されます。 この例では、「Quick build」を選択します。 モデルの学習後は、モデルの精度を分析できます。 「Overview」タブでは、列の影響、つまり、ターゲット列を予測する時の、各列の推定重要度が表示されます。この例では、 Night_calls 列が顧客が解約するかどうかを予測する上で最も大きな影響を与えています。この情報は、マーケティングチームが顧客離れを減らすための対策を講じる際の、洞察を得るのに役に立ちます。例えば、 CustServ_Calls が低い場合も高い場合も、顧客離れの可能性が高いことがわかります。マーケティングチームは、これらの学びに基づいて、顧客離れを防ぐための対策を講じることができます。例えば、Web サイトに詳細な FAQ を作成して、カスタマーサービスへの問い合わせを減らしたり、FAQ に関する顧客向け教育キャンペーンを実施してエンゲージメントを維持することが挙げられます。 予測を生成する 「Predict」タブでは、バッチ予測と単一予測の両方を生成できます。バッチ予測を生成するには、以下の手順を実施します。 予測を生成するために、サンプルの inference dataset をダウンロードします。 バッチ予測のテストを行うために、「Batch prediction」を選択します。SageMaker Canvas を使用すると、手動で、またはスケジュールに従って自動的にバッチ予測を生成できます。スケジュールに従って、バッチ予測を自動化する方法は、「 Manage automations 」を参照してください。 本稿では、「Manual」を選択します。 先ほどダウンロードしたファイルをアップロードします。 「Generate prediction」を選択します。 数秒後に予測が完了すると、「View」を選択して、予測を確認することができます。 必要に応じて、「Download」を選択して、すべてのアウトプットを含む CSV ファイルをダウンロードすることができます。SageMaker Canvas は、データの各行の予測と、予測が正しい確率を返します。 オプションとして、モデルをエンドポイントにデプロイして予測をこなうことができます。詳細については「 Deploy your models to an endpoint 」を参照してください。 クリーンアップ 将来の不要な請求を避けるために、SageMaker Canvas で作業が完了したら、Canvas アプリケーションからログアウトしてインスタンスを終了するか、ワークスペースインスタンスを自動終了するようにアプリケーションを設定することをお勧めします。詳細な情報は、「 log out of SageMaker Canvas 」を参照してください。 SageMaker Canvas からのログアウト Canvas からログアウトしても、モデルとデータセットは影響を受けませんが、クイックビルドタスクをキャンセルできます。ログアウトすると、Canvas は別のタブで再起動するよう指示します。クイックビルド実行中の場合は、アプリケーション再起動が完了するまで、ビルドが中断される可能性があります。ログアウトしても、標準ビルドは続行されます。 Canvas アプリケーションからログアウトするには、「Log out」アイコンを選択してください。 SageMaker Canvas を自動的にシャットダウンする アクティブな Canvas アプリケーションをシャットダウンするスケジュールを作成するか、アイドル状態になったらすぐにシャットダウンするオートメーションを作成することができます。ソリューションの詳細は、ブログ「 自動シャットダウンソリューションを使ってAmazon SageMaker Canvas のコストを最適化する方法 」を参照してください。 まとめ 本稿では、Athena Federated Query とサンプルデータセットを使用して、BigQueryからデータを抽出するソリューションを紹介しました。次に、抽出したデータを使用して、ノーコードで SageMaker Canvas で ML モデルを構築し、解約リスクがある顧客を予測しました。SageMaker Canvas を使用すると、ビジネスアナリストはノーコードのインターフェースを通じて ML モデルを簡単に構築、およびデプロイできるため、組織全体で ML を民主化することができます。これにより、高度な分析と ML の力を活用して、専門的な技術スキルの必要なく、ビジネスインサイトとイノベーションを推進できます。 より詳しい情報は、「 Query any data source with Amazon Athena’s new federated query 」と「 Import data from over 40 data sources for no-code machine learning with Amazon SageMaker Canvas 」を参照してください。もし、SsageMaker Canvas についてよく知らない場合は、「 Build, Share, Deploy: how business analysts and data scientists achieve faster time-to-market using no-code ML and Amazon SageMaker Canvas 」を参照してください。 本稿は、 Import data from Google Cloud Platform BigQuery for no-code machine learning with Amazon SageMaker Canvas の翻訳となります。 翻訳は、ソリューションアーキテクト 加藤 菜々美が担当しました。 著書について Amit Gautam Amit Gautam は、英国のエンタープライズ顧客のクラウド導入をサポートする AWS シニアソリューションアーキテクトであり、ビジネス成果の達成に役立つアーキテクチャに関するアドバイスやガイダンスを提供しています。 Sujata Singh Sujata Singh は、英国のエンタープライズ顧客のクラウド導入をサポートする AWS シニアソリューションアーキテクトであり、ビジネス成果の達成に役立つアーキテクチャに関するアドバイスやガイダンスを提供しています。

本稿は、2024 年 10 月 29 日に AWS Cloud Enterprise Strategy Blog で公開された “ How Executives Can Avoid Being Disrupted by Emerging Technologies ” を翻訳したものです。 経営幹部は、ビジネスをますます破壊する急速なテクノロジーの変化を予測し、新たな市場と提携の機会を見つけなければなりません。経済、社会、地政学、気候、消費者、テクノロジーの変化を数値化したアクセンチュア社の グローバル・ディスラプション・インデックス によると、破壊の速度はわずか 5 年前と比較して 50 倍に加速しています。経営幹部はどのようにして時代の先端を行くことができるでしょうか？ テクノロジーのトレンドを予測することは重要 破壊的なテクノロジーを予測し、それらを活用する体制を整えることで、先見の明のある経営陣は、事業の陳腐化を防ぎ、成長、効率性、イノベーションの新たな道筋を発見することができます。企業は、テクノロジーを早期に特定し、採用することで、生産性を向上させ、ワークフローを合理化し、顧客体験をパーソナライズし、戦略的意思決定に役立つデータ主導の洞察を引き出すことができます。 Amazon は、eコマースの分野で早期に事業を展開し、オンラインインフラとロジスティクスに多額の投資を行い、業界のリーダーとなりました。Apple は 2007 年に iPhone を発売し、タッチスクリーン技術、モバイルアプリ、洗練されたユーザーエクスペリエンスにより、携帯電話業界に革命をもたらしました。Netflix はビデオオンデマンドを導入することで従来のケーブルテレビや DVD レンタルのビジネスモデルを破壊し、Uber はアプリベースのライドシェアリングによりタクシーやリムジン業界を一変させました。これらの企業は、新興技術を特定し活用することで、新たなビジネスチャンスを生み出し、市場シェアを獲得し、収益を増加させ、革新的なリーダーとしての評価を確固たるものにしてきました。 あなたは「テクノロジーの予言者」になれるか 新たなテクノロジーは、コストや使いやすさ、使いやすさに対する知覚価値、新たな標準規格など、さまざまな要因により、予測が難しいことで知られています（訳者注：知覚価値とは、顧客が製品やサービスに対して抱く総合的な価値のことであり、お金に限らず健康の増進や様々な経験の向上なども含まれます）。新型コロナウイルス (COVID-19) のパンデミックのような予期せぬ混乱は、入念に練られた予測を一夜にして時代遅れにしてしまう可能性があります。 また、アーリーアダプターは、入手しやすい情報を過信しすぎたり、もはや実行不可能な投資をあきらめられないという問題にも直面します。テクノロジーの成功は、それを支えるインフラや補完的な製品に左右されますが、それらの製品は相互依存のウェブを形成しており、予測が困難です。経営陣は、新たなテクノロジーに関する情報を常に把握し、最も重要なテクノロジーを積極的に採用する必要があります。 テクノロジーのトレンドを特定する方法 絶対確実な「テクノロジーの予言者」になることはできませんが、学習、適応、革新に適した組織の生態系を育成することは可能です。そのためには、テクノロジーに対する認識、関与、機敏性を企業の組織構造に組み込む多面的な戦略が必要です。経営陣がテクノロジーのトレンドを特定するために、次の4つの能力を開発することをお勧めします。 1. テクノロジーのモニタリングと調査を行う これは、業界トレンドの何気ない観察を越えたものであり、テクノロジーの現状を調査するための体系的なアプローチを必要とします。有望なイノベーションを特定し、ビジネスへの潜在的な影響を評価し、それらを迅速に試す専任のテクノロジー調査チームを編成することができます。このチームには、自社にとって最も重要なトレンドを迅速に絞り込むための使命と仕組みが求められます。また、研究機関や最先端のスタートアップ企業と提携し、現在および将来のビジネス上の問題の解決に役立つ新たなテクノロジーへの直接的なパイプラインを確保すべきでしょう。業界レポートやアナリストの見解を読んだり、テクノロジー関連のカンファレンスに参加したり、パートナー企業とネットワークを築くなど、業界におけるテクノロジーの進化の最新情報を入手し把握してください。 ヒント： 新たなテクノロジーとそれが自社のビジネスに与える影響について、ブリーフィングを実施しましょう。 これらのテクノロジーを活用してビジネス上の問題を解決するボランティアを募ります。 これにより、指導者的なグループが構築され、事業部門に必要なテクノロジースキルが身に付きます。 ヒント： テクノロジー・スカウトチームは、目新しさだけを求めて新たなテクノロジーを探求するのではなく、具体的なビジネス価値の提供に重点を置かなければなりません。製品、業務、または顧客体験への影響についてチームに説明責任を負わせるための KPI を設定します。 ヒント： 専任のテクノロジー・スカウトチームの設置が現実的でない場合は、組織内のリーダーで構成されるバーチャルなスカウトチームを編成するという賢明な代替策があります。異なる事業部門の利害関係者の多様な視点や専門知識を活用することで、新たなテクノロジーとその潜在的な影響をより深く理解することができます。 2. 好奇心と実験の文化を創り出す この文化の変化には、従業員に情報を入手し続けるよう促す以上のことが必要です。革新的な思考が報われ、リスクを冒すことが奨励される環境を作りましょう。組織が従業員の集合知と創造性を活用することが目標です。 ヒント： CoE (Center of Engagement) を設置する。 ここでいう CoE とは、Center of Excellence ではなく、Center of Engagement (エンゲージメントの中心) のことです。 この CoE では、技術者とビジネスユーザーの全員が新たなテクノロジーを試し、その結果を報告することが奨励されます。CoE は小規模で迅速に運営され、現場での迅速なトレーニングを奨励し、成功と失敗を共有します。実験とコラボレーションを推進することで、どの新たなテクノロジーを組織全体でより迅速に採用すべきかを決定することができます。 ヒント： 社内ハッカソンを開催し、テクノロジープロバイダーに参加を呼びかけましょう。これにより、スタッフがテクノロジーと全社的な実験に信頼を寄せるのに役立ちます。また、NASA が開発した測定システムである、 Technology Readiness Level で評価することもできます。 3. テクノロジーロードマップ作成とシナリオプランニングにテクノロジーを活用する 洗練されたテクノロジーロードマップ作成とシナリオプランニングを行うには、複数の結果を想定し、対応策を準備する必要があります。技術的専門知識とビジネス感覚を兼ね備えた、小規模で多様な部門横断チームを編成します。これらのチームは、ダイナミックで順応性のあるップを作成するために、モデリング技術とデータ分析を使用します。これらのロードマップは、技術の急速な変化に対応できるよう、定期的に見直し、更新されます。 各テクノロジーについて、以下を検討します。 従業員がそれを受け入れるだろうか？ ビジネス上の問題を解決できるか？ ビジネスユーザーに説明できるか？ 導入にコストをかけられるか？ ヒント： 興味のある新たなテクノロジーについて、1 ページのポジションペーパーを作成する。 その技術に対する現在のアクション (つまり、観察、評価、テスト、積極的な実験、運用、または廃止など) をリストアップする。 その技術が自社ビジネスにどう関連するのかについて、パラグラフを追加する。 各技術について、どの事業部門が恩恵を受けられるか、また関係する人々やパートナーについて、セクションを追加する。 半年ごとにポジションを更新する。 この簡潔なポジションペーパーを、協力関係を築きたいサプライヤー、パートナー、顧客と共有することを検討しましょう。「X というテクノロジーについて、あなたはどの程度ご存知ですか？」と尋ねる従業員に、このペーパーはインパクトを与えるでしょう。 4. 外部パートナーシップを結ぶ どんなに規模が大きく、資金力のある組織であっても、すべてのテクノロジー開発に遅れずについていくことは不可能です。パートナーの多様なネットワーク (実績のあるテクノロジーベンダーから、柔軟な対応力を持つ新興企業、学術機関から業界の同業者まで) と関わることで、洞察力を得たり、最先端のイノベーションにアクセスしたりすることができます。こうしたパートナーシップには、正式な研究協力から、業界コンソーシアムへの参加、新たなテクノロジーに焦点を当てたベンチャーキャピタルファンドへの投資など、さまざまな形態があります。 ヒント： プロバイダーのロードマップについて話し合い、新たなテクノロジーのテストを申し出てください。実際のビジネス上の問題の解決に役立つのであれば、パートナーとしての優先順位が上がり、正式採用が加速するでしょう。さらに良いことに、そのテクノロジーのメンテナンスはテクノロジーパートナーが行うため、自社でメンテナンスを行う必要はありません。 ヒント： 社外のイノベーションを評価し、統合するための正式なプロセスを確立しましょう。そのプロセスには、潜在的な技術提携や買収を評価する専門チームの編成が含まれるかもしれません。このような取り組みを行う企業は、社外のイノベーションと社内の能力を組み合わせるメリットを享受することができます。 今すぐ始めましょう。今なら間に合います。昨日ならもっと良かったのですが。 デジタル革命は、リーダーが技術革新に遅れずについていくことを要求しています。AI 、 IoT 、クラウド、サイバーセキュリティ、サステナビリティなど、破壊的なトレンドに遅れずについていくために、テクノロジーのモニタリング、実験、ロードマップ作成、外部パートナーシップを活用することができるのです。 Tom Soderstrom トム・ソダーストロームは 2020 年に AWS に入社し、AWS パブリックセクターのチーフテクノロジスト組織を構築し率いた後、2023 年に AWS エンタープライズ戦略チームに入社しました。AWS 入社前は、2006 年から 2020 年まで、NASA のジェット推進研究所 (JPL) で IT Chief Technology and Innovation Officer を務めていました。クラウドの初期のパイオニアとして、 JPL 、 NASA 、米国連邦政府でクラウドコンピューティングを導入し、指導しました。 Tom Godden トム・ゴッデンは、Amazon Web Services (AWS) のエンタープライズストラテジスト兼エバンジェリストです。AWS 入社前は、Foundation Medicine の最高情報責任者 (CIO) として、FDA の規制下にある世界トップクラスの癌ゲノム診断、研究、患者治療結果のプラットフォームの構築に携わり、治療結果の改善と次世代の精密医療の実現に貢献しました。それ以前は、Alphen aan den Rijn Netherlands にある Wolters Kluwer で複数の上級技術リーダー職を歴任し、ヘルスケアおよび生命科学業界での経験は 17 年以上に及びます。トムはアリゾナ州立大学で学士号を取得しています。

本ブログは 2024 年 11 月 15 日に公開された Blog “ Secure by Design: AWS enhances centralized security controls as MFA requirements expand ” を翻訳したものです。 Amazon Web Services (AWS) は、Day 1 (創業当初) からセキュア・バイ・デザインの原則に基づいてサービスを開発してきました。初期状態でもお客様のセキュリティポスチャが高い基準に設定されている特徴があります。強力な認証は、アカウントセキュリティ全体の基礎となる要素であり、多要素認証 (MFA) の使用はシステムやデータへの不正アクセスを防ぐための最もシンプルで効果的な方法の 1 つです。MFA を有効にすることで、パスワードを狙った攻撃の 99% 以上を防止できることがわかっています。本日は、MFA の要件拡大について、 最初に発表してから の過去 1 年間の進捗状況をお伝えします。2023 年 10 月の発表では、AWS Management Console のルートユーザーに MFA の使用を必須とすることで、お客様のデフォルトのセキュリティポスチャを向上させることを要件としました。 近年、一般的な職場環境は大きく変化しています。ハイブリッドワークや BYOD (私用デバイスの業務利用) ポリシーなどの導入が増加し、セキュリティ境界の定義はより複雑になりました。ほとんどの組織は、アイデンティティベースの統制を重視するようにセキュリティ境界を調整しましたが、これによってユーザーパスワードが境界における新たな弱点となりました。ユーザーは使いやすさを重視して複雑さの低いパスワードを選択したり、複数のウェブサイトで同じ複雑なパスワードを再利用したりすることがあり、あるウェブサイトでデータ漏洩が発生した場合に大きなリスクとなります。 このようなリスクに対するお客様のレジリエンスを向上させるため、私たちは多くの対策を講じています。例えば、漏洩した認証情報をオンラインソースでモニタリングし、それらが AWS で悪用されることを防いでいます。また、脆弱なパスワードが設定されることを防止し、ユーザーにデフォルトのパスワードを設定することは決してありません。さらに、MFA をまだ有効にしていないお客様に対して異常なサインイン活動を検出した場合、プライマリメールアドレスにワンタイム PIN を送信して検証を行います。これらの対策にもかかわらず、パスワードのみの認証には本質的なリスクが残ります。 状況を改善するために、2 つの重要な改善機会を認識しました。1 つ目は、お客様の MFA 採用を加速し、高い権限を持つユーザーに MFA を要求することで、AWS のデフォルトのセキュリティポスチャを強化することです。2024 年 5 月、大規模な環境のユーザーから始めて、 AWS Organizations 管理アカウントのルートユーザーに MFA を要求するようになりました。そして 6 月には、MFA 方式として FIDO2 パスキーのサポートして、お客様のセキュリティ要件を満たし、非常に安全性が高くありながらユーザーフレンドリーな新たな選択肢も追加しました。同時に、 MFA 要件を拡大し 、スタンドアロンアカウントのルートユーザーも含めることを発表しました。 AWS Identity and Access Management (IAM) が 2024 年 6 月に FIDO2 パスキーのサポートを開始して以降、フィッシング攻撃に強い MFA の登録率は 100% 以上増加しました。2024 年 4 月から 10 月の間に、75 万以上の AWS ルートユーザーが MFA を有効にしました。 2 つ目に認識したのは、不要なパスワードを完全に排除することです。パスワードのセキュリティ上の問題に加えて、パスワードベースの認証を保護しようとすると、特に大規模に運用しているお客様や、規制要件によって定期的なパスワードのローテーションが必要なお客様にとって、運用上のオーバーヘッドが発生します。本日、AWS Organizations で管理されているアカウントのルートアクセスを一元管理する 新機能 を発表しました。この機能により、ルートプリンシパルの使用に対する強力な統制を維持しながら、管理が必要なパスワードの数を大幅に削減できます。お客様は、IAM コンソールまたは AWS CLI を通じた簡単な設定変更で一元化されたルートアクセスを有効にできるようになりました。この手順の詳細は こちらのブログ で説明されています。その後、組織内のメンバーアカウントのルートユーザーの長期的な認証情報（パスワードや長期的なアクセスキーを含む）を削除できます。これにより、運用の負担を軽減しながら、お客様のセキュリティポスチャを改善することができます。 Organizations 利用のお客様には、これらのメリットを体験していただくため、集中管理されたルートアクセス機能を今すぐ有効にすることを強くお勧めします。ただし、お客様が引き続きルートユーザーを維持する場合、高い権限を持つこれらの認証情報を適切に保護することが不可欠です。大規模運用をされているお客様へのサポート強化と、パスキーなどの追加機能により、AWS Organizations のメンバーアカウントに対する MFA 要件を拡大しています。2025 年春より、ルートアクセスの集中管理を有効にしていないお客様は、AWS マネジメントコンソールにアクセスするために、AWS Organizations のメンバーアカウントのルートユーザーに対して MFA を登録する必要があります。管理アカウントやスタンドアロンアカウントへの以前の適用拡大と同様に、この変更は段階的に展開され、対応が必要なお客様には事前に個別に通知を行い、日常業務への影響を最小限に抑えながら新しい要件に準拠できるようサポートします。 ルートアクセスを一元管理する新機能の詳細については IAM ユーザーガイド を、AWS での MFA の使用については IAM ユーザーガイドの AWS MFA をご参照ください。 Arynn Crow Arynn Crow は AWS Identity のアカウント保護担当プリンシパルプロダクトマネージャーです。2012 年にカスタマーサービスエージェントとして Amazon に入社し、2017 年にセキュリティとアイデンティティの分野で自分の居場所を見つけるまで、何年もの間さまざまな役割に挑戦してきました。Arynn は、アカウント保護、規制と標準、セキュアバイデザインの取り組みに焦点を当てています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 6 月 11 日に公開された Blog “ Passkeys enhance security and usability as AWS expands MFA requirements ” を翻訳したものです。 Amazon Web Services (AWS) は、お客様のワークロードを実行するための最も安全なインフラストラクチャとなるように設計されています。クラウドにおける「セキュア・バイ・デザイン」と「セキュア・バイ・デフォルト」の実践を、AWS は Day 1 (創業当初) から先駆的に実践してきました。本日 (2024 年 6 月 11 日)、AWS は MFA 機能の拡張の一環として、多要素認証 (MFA) の方法として FIDO2 パスキーのサポートを開始しました。お客様の強力な認証のオプションをさらに強化する取り組みです。パスキーは、多くのお客様に対して、高度に安全でユーザーフレンドリーな MFA オプションを提供します。 変更点 2023 年 10 月、AWS は AWS アカウントで最も特権を持つユーザーに対して MFA を必須とする ことを最初に発表しました。これは AWS Organizations の管理アカウントのルートユーザーから始まり、その後他のユースケースに拡大されます。2024 年 7 月から、独立したアカウント (AWS Organizations で管理されていないアカウント) のルートユーザーは、AWS マネジメントコンソールにログインする際に MFA の使用が必須となります。管理アカウントと同様に、この変更は少数のお客様から始まり、数ヶ月かけて段階的に拡大していきます。お客様には MFA を有効にするための猶予期間が設けられ、ログイン時にお知らせとして表示されます。この変更は、AWS Organizations のメンバーアカウントのルートユーザーには適用されません。メンバーアカウントなど、残りのルートユーザーのユースケースに対する MFA 要件については、2024 年後半に詳細な情報を共有する予定です。これは、より多くのユーザーに対して大規模に MFA を管理するための追加機能の開発を進めながら行います。 今後、数ヶ月間でこのプログラム拡大の準備を進める中、本日、FIDO2 パスキーを MFA 方式としてサポートすることを発表します。これにより、お客様は MFA 要件に準拠し、基本的なセキュリティポスチャを強化できるようになります。パスキーはすでに世界中の何十億ものコンピューターやモバイルデバイスに使われており、デバイスに組み込まれている指紋、顔スキャン、PIN などのセキュリティメカニズムのみが使用されています。パスキーを使用する例として、iPhone の Apple Touch ID や、ラップトップの Windows Hello を認証機能として設定し、同じパスキーを MFA 方式として使用して、お使いの様々なデバイスから AWS コンソールにサインインすることができます。 この 1 年間、業界ではパスキーについて多くの議論がありました。そこで、このブログでは、パスキーに関するよくある質問に回答し、セキュリティ戦略にどのように組み込めるかについての考察を共有します。 そもそもパスキーとは何か？ パスキーは、なじみのある技術に付けられた新しい名前です。パスキーは FIDO2 クレデンシャルであり、公開鍵暗号を使用して強力でフィッシング耐性のある認証を提供します。パスキーは同期機能を持ち、Apple、1Password、Google、Dashlane、Microsoft などのクレデンシャル管理サービスによる FIDO2 実装の進化形です。これにより、FIDO キーは USB ベースのキーなどの物理デバイスに保存される代わりに、デバイスやオペレーティングシステム間でバックアップや同期が可能になります。 これらの進化は、利便性とアカウントの復旧を重視するお客様にとって大幅な改善となります。しかし、FIDO2 を構成する仕様に変更を加える必要はありませんでした。パスキーは、FIDO2 が当初から備えていた、暗号技術的に安全でフィッシング耐性のある基本的な特性を同じように備えています。FIDO アライアンスのメンバー企業として、AWS は FIDO と協力して強力な認証技術の進化と成長をサポートし続けており、利便性と強力なセキュリティのバランスが取れた FIDO 技術の新しい利用体験を実現できたことを大変喜ばしく思います。 パスキーの利用対象者は？ パスキーを利用すべき人について説明する前に、 どのような タイプの MFA でも、MFA を全く使用しないよりは良いということを強調しておきます。MFA は、アカウントに適用できる最もシンプルで効果的なセキュリティ管理策の 1 つであり、誰もが 何らかの タイプの MFA を使用すべきです。しかし、個人で使用するものや会社で導入するものを決める際には、MFA のタイプ間の主な違いを理解しておくことが有用です。 フィッシング耐性のある MFA タイプとして、パスキーや他の FIDO2 認証器 (Authenticator) を推奨します。近年、認証情報を狙った攻撃が増加するにつれ、ワンタイム PIN (OTP) を MFA に使用するユーザーを標的としたフィッシングやソーシャルエンジニアリングの攻撃も増加しています。例えば、OTP デバイスのユーザーは、デバイスから PIN を読み取って手動で入力する必要があるため、悪意のある攻撃者が、無自覚なユーザーに OTP を読み上げさせようとし、MFA の効果を無効化しようとする可能性があります。パスキーは、他の MFA と同様にパスワードのみの認証よりも明らかに改善されています。さらに多くの場合、OTP ベースの MFA よりもユーザーフレンドリーで安全です。これが、パスキーがセキュア・バイ・デザイン戦略において重要なツールである理由です。効果的なセキュリティには、使いやすいセキュリティが不可欠です。このため、パスキーは多くの人にとって、ユーザー体験とセキュリティのバランスを取るための優れたオプションです。より安全でありながら使いやすいセキュリティメカニズムを見つけるのは常に容易ではありませんが、OTP ベースの MFA と比較すると、パスキーはそのような好ましい例外の 1 つです。 同期機能のない FIDO2 ハードウェアセキュリティキーや認証アプリなど、他のタイプの MFA をすでに使用している場合、同期可能なパスキーに移行すべきかどうかは、お客様や組織の用途や要件によって異なります。FIDO2 セキュリティキーは、作成したデバイスにのみクレデンシャルが紐付けられているため、 FIPS 認証 デバイスなど、最も強力な認証形式を必要とする規制やセキュリティ要件を持つお客様に対して、最高レベルのセキュリティ保証を提供します。また、パスキープロバイダーのセキュリティモデルを理解することも重要です。例えば、鍵保管庫へのアクセスや回復のためにプロバイダーが設定する要件などが、今後どのような種類の MFA を導入または使用するかを決定する際の全体的なセキュリティモデルにおいて重要な考慮事項となります。 MFA の利用拡大 2024 年 5 月の RSA カンファレンスで、AWS は 米国サイバーセキュリティ・インフラセキュリティー庁 (CISA) のセキュア・バイ・デザインの誓約 に署名することを決定しました。これは CISA のセキュア・バイ・デザイン原則に沿った、エンタープライズソフトウェア製品およびサービスのための自主的な誓約です。この誓約の重要な要素の 1 つは、アカウントセキュリティを強化する最もシンプルで効果的な方法の 1 つである、多要素認証 (MFA) の利用を促進することです。 MFA として使用される場合、パスキーはユーザーフレンドリーな方法で認証のセキュリティを強化します。AWS コンソールアクセスのセキュリティを強化するために、今すぐパスキーを登録して使用できます。これにより、2024 年 7 月から多くのお客様に展開される AWS のデフォルト MFA セキュリティ要件に準拠するのに役立ちます。セキュア・バイ・デザインの取り組みの他の要素に関する状況と進捗については、今後のお知らせでさらに詳しくお伝えします。それまでの間、サインインを行うすべてのサービスで何らかのタイプの MFA を採用することを強くお勧めします。特に、FIDO2 パスキーによって強化されたフィッシング耐性のある MFA の採用をお勧めします。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Arynn Crow Arynn は、AWS Identity のユーザー認証製品のシニアマネージャーです。Arynn は 2012 年に Amazon のカスタマーサービスエージェントとしてキャリアをスタートし、その後何年もの間さまざまな役割を経験しました。2017 年にセキュリティとアイデンティティの分野で自分の居場所を見つけました。現在、Arynn はユーザー認証サービスの開発を担当する製品チームを率いています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2023 年 10 月 3 日に公開された Blog “ Secure by Design: AWS to enhance MFA requirements in 2024 ” を翻訳したものです。 Amazon Web Services (AWS) では、セキュリティが最優先事項です。多要素認証 (MFA) の使用を必須とすることで、お客様の環境のデフォルトのセキュリティポスチャをさらに強化していくことをお知らせします。これは、アカウント内の最も権限の高いユーザーから始めます。MFA は、アカウントのセキュリティを強化する最もシンプルで効果的な方法の 1 つであり、システムやデータへの不正アクセスを防ぐための追加の保護層を提供します。 2024 年半ばより、 AWS Organizations の管理アカウントのルートユーザーで AWS マネジメントコンソールにサインインするお客様は、MFA を有効化する必要があります。MFA の有効化が必要なお客様には、コンソールへのサインイン時のプロンプトを含む複数のチャネルを通じて、この変更について事前に通知されます。 2024 年を通じて、AWS Organizations 外のスタンドアロンアカウントなど、さらに多くのシナリオにこのプログラムを拡大していく予定です。このために、MFA の導入と大規模な管理がさらに容易になる機能をリリースしていきます。ただし、MFA のメリットを活用するために 2024 年を待つ必要はありません。 AWS Identity and Access Management (IAM) ユーザーガイド にアクセスして、AWS での MFA の有効化方法を確認できます。また、対象となるお客様は、 注文ポータル から無料のセキュリティキーをリクエストすることができます。 (※訳者注: 2024 年 11 月時点では、過去 3 か月間に 300 USD 以上を消費した、米国を拠点とするルートアカウント所有者が、無料の MFA セキュリティキー受け取りの対象者となります) AWS で最も特権を持つユーザーが MFA で保護されていることを確認することは、AWS のお客様のセキュリティポスチャを継続的に強化するという私たちの取り組みの最新のステップです。より多くのお客様が MFA の導入を開始できるよう、2021 年秋には、米国の対象となる AWS アカウント所有者に無料の MFA セキュリティキーの提供を開始しました。そして 2022 年 11 月には、AWS のアカウントルートユーザーまたは IAM ユーザーごとに最大 8 つの MFA デバイスを登録できるようにサポートを開始し、MFA 戦略に柔軟性と強靭性を追加しました。 すべてのユーザーに何らかの形式の MFA を採用することをお勧めしており、さらにセキュリティキーなどのフィッシング耐性のある MFA の形式を選択することをお勧めしています。Organizations の管理アカウントのルートユーザーに対する MFA の有効化要件は 2024 年に導入される予定ですが、ルートユーザーだけでなく、環境内のすべてのユーザータイプに対して MFA を有効にすることを、ぜひ今すぐに開始することをお勧めします。例えば、AWS IAM Identity Center では、パスキーや認証アプリケーションなど、複数の MFA オプションを有効にすることができます。詳細については、 AWS IAM Identity Center の MFA ユーザーガイドをご覧ください。 このブログに関するご質問は、 AWS Support までお問い合わせください。 AWS のセキュリティに関する最新情報をもっと知りたいですか？ X でフォローしてください。 Steve Schmidt Steve Schmidt は 2008 年 2 月に Amazon に入社し、現在 Amazon のチーフセキュリティオフィサーを務めています。情報セキュリティ、物理セキュリティ、セキュリティエンジニアリング、規制プログラムのチームを統括しています。2010 年から 2022 年まで、Amazon Web Services (AWS) のチーフ・インフォメーション・セキュリティ・オフィサーを務めました。Amazon 入社前は FBI で幅広いキャリアを積み、上級幹部として勤務。FBI では、技術的な情報収集・分析の開発・運用を監督する暫定チーフテクノロジーオフィサーや、コンピュータおよびネットワーク侵入の技術調査を担当する FBI サイバー部門のセクションチーフなどを歴任しました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

This article is a contribution from Mr. Eiji Natsuaki, Executive Officer and Head of the Business Creation Division of Osaka Gas Co., Ltd., regarding our company’s efforts to use generative AI for a carbon credit evaluation system. It is the second part of a two-part series. This is the second part of the article. The first part can be found here: “ Introduction to the Carbon Credit Evaluation System Using Generative AI by Osaka Gas Co., Ltd. (First half) ” 1. Approach to the Carbon Credit Domain Our company aims to achieve carbon neutrality by 2050 and plans to contribute to a reduction of 10 million tons of carbon dioxide emissions by 2030. To achieve this goal, our company sees carbon credits as an effective means. Currently, we are providing carbon credits bundled with gas and electricity, delivering carbon-neutral energy to customers. Going forward, our company is also considering the standalone sale of carbon credits, expanding opportunities for more people to contribute to carbon neutrality. Figure 1: Image of our carbon credit offerings Interviews with customers revealed that the three key factors they look for in carbon credits are quality, variety, and price. Therefore, our company is considering handling high-quality, diverse, and affordable carbon credits (Figure 2). Figure 2: Example of a carbon credit portfolio The quality of carbon credits is crucial, as low-quality ones could harm the customer’s reputation. Therefore, we will continuously improve the generative AI-based quality evaluation system developed this time to provide customers with carbon credits they can purchase with confidence. 2. Screening of Carbon Credit Projects Using Generative AI Carbon credit projects are diverse, and their quality varies. Therefore, careful selection is necessary when considering investment. We conduct a detailed risk assessment by comparing with similar existing projects. This method allows us to selectively handle only high-quality credits. Figure 3: Example of carbon credit project screening As shown in Figure 3, by evaluating on the same axes as existing similar projects and visualizing the relative quality and risks, we believe it can lead to appropriate and unbiased screening. 3. Future Development Direction The focus of future development is on increasing diversity and improving accuracy. Carbon credit projects include a variety of types, such as nature-based, emission reduction, and CO2 removal. As new projects and rules are expected to emerge, we aim to develop a system that can flexibly adapt to them. We will also continue to work on improving the accuracy of the generative AI. While perfection is difficult, the goal is to get as close to 100% as possible. In this way, we will continue to develop a more accurate evaluation system while adapting to the ever-changing environment. 4. System Development Using AWS We have maximized the use of AWS services in developing this system. The scalable infrastructure and advanced generative AI services of AWS enable agile and flexible development. The AWS infrastructure services allow efficient system development and operation by flexibly adjusting resources according to the project scale. Additionally, AWS security features provide “assurance” for the carbon credit evaluation process, which handles highly confidential data. Furthermore, by leveraging the wealth of AWS services, the training and deployment of generative AI models can be done quickly, enabling development that responds to market needs. 5. Conclusion The carbon credit quality evaluation system developed by us is believed to play an important role in climate change mitigation. However, we do not intend to monopolize this technology, but rather to share it widely and utilize it in collaboration with many others. Climate change is a global issue that requires a rapid response. Therefore, we prioritize cooperation over competition, aiming to contribute to the sound development of the market as a whole through this technology. Improving the reliability and transparency of the carbon credit market is the key to maximizing its impact. We plan to further enhance the accuracy and reliability of this system through collaboration with others. By incorporating feedback from various industries and regions, a more fair and inclusive system can be built, contributing to the overall market benefit and accelerating climate change mitigation. Ultimately, we hope to make this system a common platform for climate change countermeasures. To this end, we will emphasize cooperation with others and aim for the healthy development of the carbon credit market. Time is of the essence in addressing climate change, so cooperation beyond a single company, across the industry and globally, is essential. We will contribute to the realization of a sustainable future through this initiative. Author Eiji Natsuaki Eiji Natsuaki Executive Officer and Head of Business Creation Division, Osaka Gas Co., Ltd. Eiji Natsuaki joined Osaka Gas Co., Ltd. in 1992 after completing his master’s course at Kyoto University Faculty of Engineering. He has served in positions such as General Manager of the Business Strategy Department in the Energy Business Division, General Manager of the Overseas Business Development Department in the Resources & International Business Division, and Head of the Innovation Headquarters. Since April 2024, he has held his current position as Head of the Business Creation Division, overseeing R&D, including Methanation technology, as well as new business development and M&A for the Daigas Group. This article was translated by AWS Professional Services Riho Matsui, and Solutions Architect Satoshi Aoyama.

もし組織の AWS 支出を管理していて、2024 re:Invent に時間を割いてAWS のコストと使用量のより良い管理方法や最適化に役立つソリューションについて学ぶ計画があれば、少し立ち止まってこのブログポストを読んでください。コスト配分、計画、コスト管理などのように一般的な Cloud Financial Management トピックに焦点を当てた様々なセッションやワークショップのラインナップを確認できます。これらのセッションを調べて、re:Invent 登録サイトの参加者ポータルから席を予約できます。もしくは、 AWS Event モバイルアプリから場所を確保できます。 ブレイクアウトセッション くつろいでこれらのプレゼンテーションを楽しみ、最新のソリューション機能強化や実用的なアプリケーションの最新情報を入手してください。AWS のエキスパートとゲストスピーカーが価値のあるインサイトと実際の事例を共有します。 COP203 | Control the cost of your generative AI services（生成 AI サービスのコスト管理） Wednesday (Dec.4) 11:30AM – 12:30PM PT | Mandalay Bay | Level 2 South | Ballroom L Alex Head, Sr. Manager OPTICS, AWS Adam Richter, Senior Optimization Solutions Architect, AWS Brent Segner, Distinguished Engineer | Director, Capital One COP218 | Best practices and new tools for cost reporting and estimation（コストのレポートと見積もりのベストプラクティスと新しいツール） Thursday (Dec.5) 12:30PM – 1:30PM PT | Venetian | Level 2 | Summit Showroom Bowen Wang, Principal Product Marketing Manager, AWS Matt Berk, Principal TAM, AWS Corey Quinn, Chief Cloud Economist, Duckbill Group COP204 | What’s new with AWS cost optimization（AWS コスト最適化の新機能） Thursday (Dec.5) 2:00PM – 3:00PM PT | Wynn | Convention Promenade | Latour 2 Letian Feng, Principal Product Manager-Tech, AWS Rick Ochs, Senior Manager of Cost Optimization, AWS チョークトークセッション AWS のスピーカーが冒頭で短い説明をし、議論の場を設けます。質問を投げかけたり、AWS のエキスパートや他のお客様と一緒にトピックを深く掘り下げましょう。 COP348 | Simplifying cost reporting with Amazon Q and Data Exports（Amazon Q と Data Exports によるコストレポートの簡易化） Monday (Dec.2) 3:00-4:00PM PT | MGM | Level 1 | 105 Liam Greenamyre, Senior Product Manager, AWS Zach Erdman, Senior Product Manager, AWS COP217 | Cost allocation strategies to improve accountability（アカウンタビリティー向上のためのコスト配分戦略） Tuesday (Dec.3) 12:00-1:00PM PT | Caesar’s Form | Level 1 | Academy 414 Marina Vitale, Senior Product Manager, Amazon Rich Roscoe, Senior Technical Account Manager, Amazon COP347| Proactive cost control strategies for AWS Workloads（AWS ワークロードのプロアクティブなコスト管理戦略） Tuesday (Dec.3) 1:30-2:30PM PT | MGM | Level 3 | 302 Repeat Thursday (Dec.5) 11:00AM – 12:00PM PT: MGM | Level 1 | Boulevard 158 Fredrik Tunvall, Senior Product Manager, AWS Shlomo Dubrowin, Sr Technical Account Manager COP212| Creating effective FinOps KPIs（効果的な FinOps KPI の作成） Thursday (Dec.5) 11:00-12:00PM PT | Wynn | Convention Promenade | Lafite 1 Repeat Thursday (Dec.5) 3:30-4:30PM PT | Caesars Forum | Level 1 | Academy 416 Marcelo Lucchesi, BRA Partner Migrations Program, AWS Tony Griffiths, Senior Technical Account Manager, AWS COP354 | Estimating your AWS costs using AWS Pricing Calculator（AWS Pricing Calculator を利用した AWS コスト見積もり方法） Thursday (Dec.5) 12:30PM-1:30PM PT |Wynn | Convention Promenade | Lafite 1 Jeremiah Myers, Senior Product Manager , AWS Meredith Holborn, Sr Technical Account Manager, AWS COP213 | Optimize savings through a tailored AWS purchase strategy（状況に合わせた AWS 購入戦略による節約最適化） Thursday (Dec.5), 2:00PM – 3:00 PM PT |Wynn | Convention Promenade | Lafite 1 Mary Nachimov, Senior Product Manager, AWS Wade Piehl, FinOps Success Manager, AWS コードトークセッション チョークトークに似ていますが、ユースケースを通じて説明する代わりに、スピーカーはデモコードサンプルを用いてライブで紹介します。実際のコードを見て、一般的なコスト分析の疑問を解決するためにどのように適用するのか学びましょう。 COP403 | Advanced analytics with AWS Cost and Usage Reports（AWS Cost and Usage Reports による高度な分析方法） Thursday (Dec.5), 11:00AM-12:00PM PT| Wynn | Convention Promenade | Margaux 1 Steph Gooch, Sr. Optimization SA Advocate, AWS Justin Marks, Sr. TAM, AWS ハンズオンワークショップとビルダーズセッション AWS のスピーカーが、課題に取り組むためのユースケースとツールを紹介します。インストラクションに従い、タスクを完了させ、各機能のさらなる理解を持ち帰ってください。 COP306| Elevate your cost allocation strategy with AWS Cost Categories (Builder’s session)（AWS Cost Categories を用いたコスト配分戦略の強化、ビルダーズセッション） Monday (Dec.2) 10:30-11:30AM PT | Mandalay Bay | Level 2 South | Surf E Repeat Thursday (Dec.5) 2:30-3:30PM PT | Mandalay Bay | Level 2 South | Surf E Savanna Jensen, Sr. FinOps Success Manager, AWS Shubir Kapoor, Principal Product Manager, AWS Scottie Enriquez, Senior Solutions Developer, Amazon Web Services Connor Murphy, Sr. FinOps Success Manager, Amazon Web Services Alok Verma, Principal PMT, Amazon Web Services COP410 | Advanced cost allocation for AWS containerized workloads (Workshop)（コンテナ化された AWS ワークロードの高度なコスト配分、ワークショップ） Tuesday (Dec.3) 12:30-2:30PM PT | Mandalay Bay | Level 2 South | Oceanside D Nataliya Godunok, Cloud Optimization Success Solutions Architect, AWS Chris Strzelczyk, Sr. Technical Account Manager, AWS COP309 | Visualize and optimize cloud cost efficiency (Workshop)（クラウドのコスト効率の可視化と最適化、ワークショップ） Tuesday (Dec.3) 4:30 – 6:30PM PT | Mandalay Bay |Lower Level North | South Pacific F Judith Lehner, Senior Technical Account Manager, AWS Yuriy Prykhodko, Principal Technologist | Head of Cloud Intelligence Dashboards, AWS FinOps Foundation のネットワーキングイベントに参加しましょう FinOps Foundation は今年の re:Invent で火曜日 (12/3) にいくつかの活動をスポンサーします。1日を通して、プロダクトのフィードバックセッション (11:00AM-12:30PM PT と 2:30-4:00PM PT)、ランチパネルディスカッション (1:00-2:30PM PT) や夜のレセプションパーティー (4:30-8:00PM PT) が開催されます。AWS CFM チームのプロダクトリードやエンジニアリングリード、FinOps Foundation チームや他の同じ意見を持つプロフェッショナルと RockHouse で会いましょう。 こちら から夜のネットワーキングレセプションに登録してください。また、日中( 火曜日 2024/12/3) のプロダクションディスカッショングループやパネルディスカッションへの参加に興味があれば、アカウントチームに連絡してください。 画像 1. FinOps Foundation social event at re:Invent Cloud Financial Management のブースで AWS のエキスパートに会いましょう AWS Village Expo Hall にある Cloud Financial Management ブースを訪れて、質問したり、ソリューションを探したり、限定プレゼントのために立ち寄ってください。Larry Im (Sr Solutions Architect, AWS)、Roy Wolman (Sr. Manager of Cost Reporting, AWS)、 Yin Lei (Sr. TAM, AWS) と Chris Geiger (Sr Solutions Architect, AWS) がお手伝いします。セッションのスピーカーも週を通して交代してブースにいます。 結論 このブログポストが 2024 re:Invet の CFM セッションのアジェンダ作成の参考になることを願っています。Vegas でお会いできるのを楽しみにしています。 翻訳はテクニカルアカウントマネージャーの加須屋 悠己が担当しました。原文は こちら です。 Bowen Wang Bowen は AWS Billing and Cost Management services のプリンシパルプロダクトマーケティングマネージャーです。財務やビジネスのリーダーがクラウドの価値と Cloud Financial Management を最適化する方法をより理解できるようにすることに重点を置いています。以前のキャリアでは、テックスタートアップの中国市場参入を支援していました。

AWS re:Invent 2024 で皆様をお迎えできることを、私たちは大変楽しみにしています。このイベントは、12 月 2 日から 12 月 6 日までラスベガスで開催されます。AWS re:Invent では、世界中からクラウド愛好家が集まり、互いに協力し学び合う機会があります。AWS の専門家と会談したり、技術セッションに参加したり、コミュニティイベントを探索したりと、様々な経験ができます。 このブログでは、クラウドガバナンスとコンプライアンスに焦点を当てたセッションを紹介します。これらはクラウド運用における 2 つのソリューションの分野で、セキュリティ、運用、コンプライアンス、コスト基準を遵守しながら、組織がより迅速に動けるようにするものです。クラウドガバナンスとコンプライアンスにより、統制の効いたワークロードのプロビジョニングを加速し、動的な規制が適用される状況でも運用を行い、合併・買収を効率化し、開発者の生産性を向上させることができます。 AWS re:Invent では、様々な形式とレベルの学習セッションを提供しており、自分のペースで知識を広げ、スキルを向上させることができます。レベルはセッション ID で示されています。re:Invent のセッションタイプについては、 こちら をご覧ください。 お客様のクラウドガバナンスとコンプライアンスがどんなレベルにいるかによって変わるとは思いますが、いくつかの役立ちそうなセッションを紹介いたします。 著者のおすすめ クラウド環境のコントロールを設定することは、適切に設計されたクラウド基盤を作る上で重要なステップです。著者のおすすめは、COP342 の Chalk Talk です。これは、AWS サービスを活用して堅牢なセキュリティのコントロールを実現し、コンプライアンス目標を達成する方法についての洞察を提供します。ジャーニーのどの段階にいても、適切に設計され、強力なセキュリティ態勢を維持することが最優先事項です。これは、金融サービスやヘルスケアなど、私たちがサポートする高度に規制された業界の顧客と関わる際に重要です。この Chalk Talk では、AWS サービスを使用して環境全体にわたってポリシーを一元的に定義し、適用し、監視する方法について説明します。 COP342 | Top controls for a secure, well-architected environment – Chalk Talk タイトルの参考和訳「安全で適切に設計された環境に必要なコントロールとは」 あらゆる規模の組織は、リスクを軽減し、適切に設計された環境を運用するために堅牢なコントロールを実装する必要があります。ガバナンス、コンプライアンス、セキュリティの目標達成に役立つ推奨コントロールを見つけましょう。 AWS Organizations 、 AWS Control Tower 、 AWS Config 、 AWS Security Hub などの AWS サービスを活用して、環境全体にわたってポリシーを一元的に定義し、適用し、監視する方法を学びます。包括的なアクセスコントロールを確立し、設定ミスを防ぎ、セキュリティ態勢の可視性を獲得するための戦略を探ります。新たな脅威や変化するビジネス要件に対応しながら、環境の進化に合わせてコントロールを適応させる方法を理解します。 参加すべきその他のガバナンスとコンプライアンスのセッション COP326 | Unlocking business insights with AWS Config ft. Itaú Unibanco – Breakout Session タイトルの参考和訳「AWS Config を活用したビジネスインサイトの解放 ft. Itaú Unibanco」 AWS 上で複雑かつ多岐にわたる IT 環境を大規模に運用している組織は、何千もの個別のパイプライン、リソース、サービスから設定メタデータ、バージョニング、コンプライアンスを抽出するという課題に直面しています。 AWS Config をリソースメタデータのソースとして使用することで、顧客はアカウントと AWS リージョン全体でコンプライアンス監視、変更追跡、リソース関係の可視性を得ることができます。このセッションでは、Itaú Unibanco が AWS Config を活用して何千ものアカウントの何百万ものリソースのコスト非効率、停止の原因、旧バージョンの技術、コンプライアンスの問題を特定するためのメタデータ一元化を行った方法を紹介します。 COP327 | Accelerating auditing and compliance for generative AI on AWS – Breakout Session タイトルの参考和訳「AWS 上の生成 AI の監査とコンプライアンスの加速」 生成 AI はエキサイティングな新しいイノベーションをもたらしますが、一方で、責任ある使用とコンプライアンスに関する新たな課題が発生します。このセッションでは、 Amazon Bedrock とその他の関連サービスである、 Amazon Simple Storage Service (Amazon S3) 、 AWS Lambda 、 Amazon Virtual Private Cloud (Amazon VPC) に対して、コンプライアンスとガバナンスのベストプラクティスに従っていることを可視化する方法をどのように提供できるかを説明します。AWS Organizations、 AWS Audit Manager 、 AWS CloudTrail などの AWS ガバナンスおよびコンプライアンスサービスを探索し、これらのサービスが生成 AI インフラストラクチャを継続的に監査する際にどのように役立つかを学びます。これらのサービスが証跡の収集を自動化し、コンプライアンスと監査のニーズを満たす監査準備レポートを提供する方法を学びます。 COP383 | Achieving governance at scale – Breakout Session タイトルの参考和訳「スケールするガバナンスの実現」 企業がクラウド運用をスケールアップするにつれて、ポリシーと標準の一貫した適用を維持することがますます複雑になります。このブレイクアウトセッションでは、 AWS Control Tower 、 AWS Config 、 AWS Organizations の強力な機能を掘り下げ、大規模な状況でもガバナンスを実現する方法についての包括的な理解を参加者に提供します。 AWS サービスを統合してガバナンスプロセスを自動化し、インシデント対応を効率化し、 AWS 環境全体でセキュリティのベストプラクティスを適用する方法を学びます。また、顧客から AWS 上でのガバナンスのジャーニーについて話を聞くこともできます。 COP402 | Dive deep on AWS Cloud Governance – Breakout Session タイトルの参考和訳「AWS クラウドガバナンス Dive Deep」 組織が急速にクラウドコンピューティングを採用する中で、効果的なガバナンスはますます重要になっています。この Dive Deep セッションでは、 AWS 上で堅牢なクラウドガバナンスを実装するための高度な戦略と基盤となる AWS サービスを探ります。アカウント設計、セキュリティコントロール、監査レポート、自動化に焦点を当てて、環境にガバナンスを適用するための AWS サービスと戦略について学びます。 COP338 | Architecting AWS Accounts for Scale – Chalk Talk  タイトルの参考和訳「スケールに向けた AWS アカウントの設計」 このセッションでは、アカウント構成やドメインのコントロールに加え、AWS アカウント、AWS Organizations、AWS Control Tower を通じたセキュリティ境界の確立など、アカウント管理のベストプラクティスに焦点を当てます。これにより、ビジネスアプリケーションとデータをより簡単に管理し、コストを最適化しながら運用の優位性、セキュリティ、信頼性を達成できます。 COP343 | Best practices for cloud governance – Chalk Talk  タイトルの参考和訳「クラウドガバナンスのベストプラクティス」 企業のクラウド導入が進むにつれ、クラウドガバナンスがますます重要かつ複雑な課題として浮上してきています。クラウドの利用を始めたばかりの企業でも、すでに十分な経験を持つ企業でも、俊敏性と統制のトレードオフをナビゲートすることは困難な場合があります。この Chalk Talk では、 AWS の専門家が、権限管理、セキュアなワークロードのデプロイメント、ガバナンスの戦略を含む、効果的でスケーラブルなクラウドガバナンス基盤を構築するための戦略を共有します。 AWS や他の参加者と共に、クラウドを成功裏に採用した組織からの洞察を共有し学びましょう。 COP346 | Centralize audit data for hybrid and multicloud environments – Chalk Talk  タイトルの参考和訳「ハイブリッドおよびマルチクラウド環境の監査データの一元化」 顧客がクラウドへの移行を加速しビジネスを変革する中で、ハイブリッド環境で IT 運用を管理しなければならない状況に直面する場合があります。これはあなたにも当てはまりますか？この Chalk Talk では、 AWS CloudTrail Lake の有効化、過去の CloudTrail ログのインポート、パートナー統合、カスタムソリューション、多くの AWS リソースからの監査ログの集約方法をご紹介します。また、調査分析やセキュリティ目的でこのデータをクエリする方法についても説明します。 COP349 | Implement controls faster with generative AI – Chalk Talk タイトルの参考和訳「生成 AI を活用したコントロールの迅速な実装」 コンプライアンスの管理は面倒なプロセスですが、監査の準備には必要不可欠です。イノベーションのためのリソースを解放するために、 AWS Config や AWS CloudTrail などのサービスを Amazon Q と組み合わせて、カスタムコンプライアンスルールを迅速に構築できます。監査の時期が来たら、生成 AI を使用して CloudTrail の証跡や AWS Config での AWS リソースの現在の構成状態をクエリすることもできます。この Chalk Talk に参加して、 AWS 上の生成 AI がコンプライアンスと監査プロセスをより迅速かつ効率的にする方法を学びましょう。 COP405 | Coding for account customizations with AWS Control Tower – Code Talk  タイトルの参考和訳「AWS Control Tower を使用したアカウントのカスタマイズのコーディング」 ライブコーディングとインタラクティブなディスカッションを通じて、マルチアカウント AWS 環境全体にベースライン構成とアカウントのカスタマイズを大規模に適用する方法をデモンストレーションします。このセッションでは、いくつかの実際の例を深く掘り下げ、数百から数千にわたるアカウントを安全にカスタマイズする方法を探ります。さらに、Amazon Q が Instrastructure as Code を可能にし、カスタマイズを迅速に実装するのに役立つ方法もお見せします。 COP311 | Simplify and automate continuous compliance with AWS – Workshop タイトルの参考和訳「AWS を使用した継続的なコンプライアンスの簡素化と自動化」 このハンズオンワークショップに参加して、 AWS サービスを使用して AWS リージョンとアカウント全体で継続的な監査とコンプライアンスプロセスを効率化する方法を学びましょう。 AWS Config と AWS Systems Manager Explorer を使用して、複数のリージョンならびに複数のアカウントからコンプライアンスデータを集約し可視化します。 AWS Config 適合パックと AWS Systems Manager Automation ドキュメントを使用して、非準拠リソースの修復を自動化する方法を探ります。また、 AWS Config の生成 AI を活用した自然言語クエリ生成を使用して、 AWS リソース構成とコンプライアンスメタデータの調査と検索を簡素化する方法も学びます。参加にはラップトップを持参する必要があります。 まとめ このブログでは、参加をお勧めするいくつかのクラウドガバナンスとコンプライアンスセッションを紹介しました！これらのセッションでお会いできることを楽しみにしています。さらに質問がある場合や、より深く掘り下げたい場合は、ベネチアンの Expo にある AWS Village のクラウドガバナンスとコンプライアンスのキオスクにお立ち寄りください。セッションについて詳しく知りたい場合は、 re:Invent イベントセッションページ をご覧ください。 著者 Tiffany Chen Tiffany Chen は AWS の CSC チームのソリューションアーキテクトで、ヘルスケアとライフサイエンス業界にフォーカスしています。お客様のデプロイメントワークロードをサポートし、現在はエンタープライズの顧客と協力して、コスト最適化されたソリューションを構築しています。趣味は旅行、ガーデニング、お菓子作り、バスケットボール観戦です。 Winnie Chen Winnie Chen は AWS のソリューションアーキテクトで、金融サービス業界を中心にエンタープライズグリーンフィールドの顧客をサポートしています。AWS へのインフラ移行や構築を支援していて、趣味は旅行とハイキング、サイクリング、ロッククライミングなどのアウトドアです。 このブログの翻訳はソリューションアーキテクトの桂井が担当しました。原文は こちら です。