このブログ記事では、AWS Outposts ラックを複数のワークロードで利用する際の Amazon Elastic Compute Cloud (Amazon EC2) のキャパシティプランニングと、その管理の方法を紹介します。これにより、お客様は Outposts ラック上で稼働するワークロードに求められる可用性を維持しながら、効率的に Outposts ラックのリソースを利用できます。 株式会社野村総合研究所では、 このキャパシティ管理戦略を用いて、Outposts で稼働するワークロードに求められる可用性を維持しながら、効率的に Outposts のリソースを利用しています。 AWS Outposts の特徴 Outposts は、フルマネージド型の AWS インフラストラクチャ、ネイティブな AWS のサービス、API、およびツールを、お客様のオンプレミス施設で提供します。これにより、今までクラウドへの移行が困難であった低遅延ネットワーク要件のワークロードや、特定のロケーションでデータを保存する、データレジデンシーの要件があるワークロードを稼働させることができます。Outpostsは、オンプレミスのインフラストラクチャの調達、管理、アップグレードのために必要なお客様の作業を取り除きます。 AWS Outposts ラックの注文 Outposts ラックを注文する際は、Amazon EC2 のインスタンスタイプのうち、汎用 (M5)、コンピューティング最適化(C5)、高速コンピューティング (G4dn)、メモリ最適化 (R5)、ストレージ最適化 (I3en) の中から、必要なインスタンス数を算出し、それに見合った Outposts ラック上のサーバーの台数を指定して注文します。サーバー1台は、24xlarge のインスタンスサイズに相当します。 AWS Outposts のキャパシティプランニング Outposts は、物理的に接続された 1 つ以上の Outposts ラックを 1 つの論理 Outpost (以下 Outpost) として管理できます。これにより、コンピューティング容量とストレージ容量のプールを提供します。 Outpost は、単一の目的のワークロードだけでなく、特性の異なる複数のワークロードを集約することができます。Outposts 活用のユースケースとして、オンプレミスのリソースとの低遅延接続、データレジデンシーに留まらず、その周辺ワークロードを含めた、ハイブリッドワークロードにおける中継環境、クラウドへの段階的移行のための環境など、複数のニーズに応えることができます。 AWS リージョンにおける Amazon EC2 の容量は限りがないように見えますが、Outpost の容量には限りがあり、注文したコンピューティング容量の合計によって制約されます。 Outpost で高可用性の設計とする場合、N+M 可用性モデルをサポートするのに十分なコンピューティングキャパシティを注文する必要があります。N は必要なサーバー数、M はサーバー障害に対応するためにプロビジョニングされたスペアサーバーの数です。N+1 と N+2 が最も一般的な可用性レベルです。 Outpost では、各サーバー (C5 、 M5 、 R5 など) は、単一ファミリーの Amazon EC2 インスタンスをサポートします。Amazon EC2 でインスタンスを起動する前に、各サーバーが提供する Amazon EC2 インスタンスサイズを指定するスロッティングレイアウトを準備する必要があります。スロッティングレイアウトの例として、m5.large インスタンスを 48 台起動できる単一インスタンスサイズのレイアウトや、m5.large が 4 台、m5.xlarge が 4 台、m5.2xlarge が 3 台、m5.4xlarge が 1 台、m5.8xlarge が 1 台起動できるサイズ混在のレイアウトが挙げられます。 Outpost で N + M 可用性モデルを実現するためには、各サーバーごとにスロッティングレイアウトを設定し、インスタンスサイズ別に Amazon EC2 の容量プールとして管理します。例えば、サーバーが 4 台あった場合、Amazon EC2 のキャパシティ容量は 4 × 24xlarge です。すべて m5.xlarge を割り当てた場合は合計 96 台の m5.xlarge インスタンスが起動ができます。ただし、全ての Amazon EC2 容量プールを消費する形でインスタンスを起動してしまうと、⼀つのサーバーで障害が発⽣した際に、別のサーバーでインスタンスを再起動することができなくなってしまいます。そのため、Amazon EC2 容量プールで N + M サーバーの可⽤性を考慮する場合は、容量プールの使⽤率が 100 % にならないように設計します。例えば N + 1 可用性の場合、4 台のサーバーの内、 1 台のサーバーを余剰リソースとして確保することになるため、実際に利用できる Amazon EC2 のキャパシティ容量は 3 × 24xlarge となります。 このような設計は、単一のワークロードや必要なリソース量の変化が激しくない場合には難しくはないと考えられます。しかし、複数のワークロードを Outpost で稼働させる場合、リソースへの要求が重複したり、他のワークロードが過剰にリソースを消費してしまう可能性を考慮しなくてはなりません。そこで、Outpost ではキャパシティ予約とリソース共有を使うことで、ワークロードごとのリソースを確保する仕組みを作る事ができます。 Outpost でのキャパシティ予約とリソース共有 AWS Organizations を利用すると、1 つの Outpost のリソースを複数の AWS アカウントで利用することができます。Outpost のオーナーアカウントである Organizations の管理アカウントと、メンバーアカウントの間で、Outpost のリソースを共有できます。Organizations の管理アカウントでは、Outpost でのキャパシティ予約を利用して、メンバーアカウントに配分するリソースのプールを作成します。 この Outpost でのキャパシティ予約を、リソース共有機能を使って、Organizations のメンバーアカウントに割り振ることができます。これにより、特定の AWS アカウントで意図しない Amazon EC2 インスタンスの過剰な消費が発生しても、該当のワークロードで割り当てているキャパシティ予約済みのリソースを保護できます。 Outpost オーナーアカウントである Organizations 管理アカウントで、Outpost 上の全てのリソースのキャパシティ予約を作成すれば、共有先のメンバーアカウントでは一切割り当てた分以上のインスタンスを起動させない、厳密な管理も可能です。しかし、リソース割り当て量を増減したり、キャパシティ予約では管理されない Elastic Load Balancing (ELB) や Amazon Relational Database Service (Amazon RDS) のインスタンスを起動したい場合は、その都度全てのキャパシティ予約を変更する必要があり、運用が煩雑になります。そのため、メンバーアカウントに割り当てるキャパシティ予約は本番環境のみとしたり、最低限確保したい容量のみとして、予約されないリソースをバッファとして用意しておくこともできます。その場合、意図しないリソース消費が発生した際は、そのバッファ分の Amazon EC2 インスタンスは起動できるため、これを Amazon CloudWatch で監視するといった工夫をすることも必要でしょう。 このように、Outpost 全体のキャパシティへの影響の考慮が必要なユースケースとして、例えば本番環境と開発環境を同じ Outpost 上に展開しても、ワークロードごとの影響を抑えることができます。 本ブログの著者について Yuki Taniguchi Yuki は AWS のソリューションアーキテクトとして、日本の金融業界を担当しています。2011年から銀行システムの設計・開発・プロジェクトマネジメントに携わる。2019年から現職。

2024年2月に、アマゾン ウェブ サービス ジャパン合同会社 目黒オフィス17階にある AWS Startup Loft の一角に AWS Outposts servers lab Tokyo がオープンしました。 これによりお客様やパートナー様が AWS Outposts サーバー の実機をご覧いただけるだけで無く、自社のアプリケーションや自社製品をテストすることも可能になりました。 AWS Outposts サーバーを発注する前のフィジビリティスタディや使用感の確認、運用方法の検討等にご利用いただけます。 現在ラボには AWS Outposts サーバーの 2U モデル（インテル社製 CPU 搭載モデル）と 1U モデル（AWS Graviton2 搭載モデル）が各1台設置してあります。 AWS のマネジメントコンソールをからこの環境を操作して、ワークロードを構築し、検証することが可能です。 設置されているAWS Outpostsサーバー1Uおよび2Uの写真 また AWS Outposts の特徴であるオンプレミスネットワークとのダイレクトな接続も体験いただけます。 こちらのラボでは、利用者が持ち込んだ機器を LAN 経由で Outpost サーバーと接続することで、実際の利用シーンに即したテストなど様々な検証を行うことが可能です。 例としては図1のような構成でテストが可能です。 図1　アクセス遅延の比較検証 この環境ではオンプレミスの LAN 上に存在する機器 Outpost サーバー上に作られたワークロードが直接通信するようなシステム環境を再現することができます。 実際にお客様がお持ちの IoT 機器やセンサー等のデータをオンプレミスにあるワークロードで処理することで効率的なシステムが構築可能かどうかを実体験することができます。 もちろん AWS データセンターで提供される AWS の様々なマネージドサービスとのシームレスな連携もテストすることが可能です。 ラボの利用に当たっては、営業担当に連絡していただくか、 こちら から AWS Outposts のスペシャリストへ直接コンタクトしてください。 是非この機会に、皆様がお持ちのワークロードを AWS Outposts サーバー上で稼動させることを検討してみませんか？ 検証を行うことで製品を AWS Outposts servers Ready な状態にすることが可能です。是非ご利用お待ちしております。

生成 AI は組織の想像力をかき立て、世界中のあらゆる規模の業界で顧客体験を変革しています。数十億パラメーターの大規模言語モデル (LLM) とトランスフォーマーによって促進された AI 機能の飛躍的な進歩により、新たな生産性の向上や創造的な能力などへの扉を開きました (訳者注 : トランスフォーマーについては以降本記事では扱いませんが、詳しく知りたい方は、 人工知能におけるトランスフォーマーとは何ですか? をご確認ください) 。 組織が従業員や顧客のために生成 AI を評価して採用するにあたり、サイバーセキュリティ担当者は、この進化するテクノロジーのリスク、ガバナンス、コントロールを迅速に評価する必要があります。アマゾン ウェブ サービス (AWS) の最大かつ最も複雑な顧客を扱うセキュリティリーダーとして、私たちは生成 AI のトレンド、ベストプラクティス、急速に進化する生成 AI の状況、および関連するセキュリティとプライバシーへの影響について定期的に相談を受けています。その精神のもと、生成 AI セキュリティへの取り組みを加速させるために利用できる主要な戦略を紹介したいと思います。 この記事は、生成 AI のセキュリティ保護に関するシリーズの第 1 回目であり、導入する生成 AI ワークロードのタイプに基づいて、リスクとセキュリティの影響へのアプローチに役立つメンタルモデルを確立します。そして、生成 AI ワークロードを保護する際にセキュリティリーダーと実務者が優先すべき重要な考慮事項について説明します。続く記事では、顧客のセキュリティ要件を満たす生成 AI ソリューションの開発、生成 AI アプリケーションの脅威モデリングのベストプラクティス、コンプライアンスとプライバシーに関する考慮事項を評価するためのアプローチについて詳しく説明し、生成 AI を使用して自社のサイバーセキュリティ運用を改善する方法を探ります。 どこから始めるか あらゆる新しいテクノロジーと同様に、関連する範囲、リスク、セキュリティ、コンプライアンス要件を理解するには、そのテクノロジーの基礎をしっかりと理解することが重要です。生成 AI の基礎について詳しく知るには、まず 生成 AI とは何か 、その独特の用語やニュアンスについて学び、 組織が顧客にイノベーションを起こすためにどのように生成 AI を活用しているのか事例 を調べることから始めることをお勧めします。 生成 AI の調査や採用を始めたばかりの方は、まったく新しいセキュリティの規律が必要になることを想像するかもしれません。セキュリティに関する独自の考慮事項はありますが、幸いなことに、生成 AI ワークロードは、本質的にはデータ駆動型コンピューティングワークロードの一つであり、同じセキュリティ対策の多くを継承しています。実際に、長年にわたってクラウドサイバーセキュリティのベストプラクティスに投資したり、 Top 10 security items to improve in your AWS account 、 AWS Well-Architected Framework のセキュリティの柱 、 AWS Well-Architected Framework Machine Learning Lens などの情報源からの規範的なアドバイスを取り入れてきているのであれば、順調に進んでいると言えるでしょう。 ID とアクセス管理、データ保護、プライバシーとコンプライアンス、アプリケーションセキュリティ、脅威モデリングなどの中核的なセキュリティ領域は、他のワークロードと同様に、生成 AI ワークロードにとっても依然として非常に重要です。たとえば、生成 AI アプリケーションがデータベースにアクセスする場合、データベースのデータ分類とは何か、そのデータを保護する方法、脅威を監視する方法、アクセスを管理する方法を知る必要があります。しかし、長年にわたるセキュリティプラクティスを強調するだけでなく、生成 AI ワークロードがもたらす固有のリスクと追加のセキュリティ上の考慮事項を理解することが重要です。この記事では、新しいものからよく馴染みのあるものまで、考慮すべきセキュリティ要素について説明します。 これを念頭に置いて、最初のステップであるスコーピングについて説明しましょう。 スコープの決定 あなたの組織は、生成 AI ソリューションの推進を決定しました。では、セキュリティリーダーまたはセキュリティ実務者として何をすべきでしょうか？どのようなセキュリティ対策でもそうであるように、セキュリティ保護の範囲を理解する必要があります。ユースケースに応じて、サービスプロバイダーがサービスとモデルの管理に対してより多くの責任を負うマネージドサービスを選択するか、独自のサービスとモデルを構築するかを選択できます。 AWS クラウドでさまざまな生成 AI ソリューションをどのように使用できるかを見てみましょう。AWS では、セキュリティは最優先事項であり、お客様に業務に適したツールを提供することが重要であると考えています。たとえば、AI21 Labs、Anthropic、Cohere、Meta、stability.ai、 Amazon Titan が提供する、使いやすい事前学習済みの基盤モデル (FM) をサーバーレスで API 駆動の Amazon Bedrock で使用できます。 Amazon SageMaker JumpStart では、事前学習済みの FM を使用しながらもさらなる柔軟性を提供し、AI ジャーニーを安全に加速できます。 Amazon SageMaker で独自のモデルを構築してトレーニングすることもできます。チャットボットなどの Web インターフェースや API を介してコンシューマー向けの生成 AI アプリケーションを利用したり、組織で調達した商用のエンタープライズアプリケーションへ生成 AI 機能を組み込むなどの予定があるかもしれません。これらのサービスはそれぞれ、インフラストラクチャ、ソフトウェア、アクセス、データモデルが異なるため、セキュリティに関する考慮事項も異なります。一貫性を確立するために、これらのサービスを論理的に分類し、「スコープ」と名付けました。 セキュリティスコーピングの取り組みを簡素化するために、選択する生成 AI ソリューションに応じて考慮すべき主要なセキュリティ領域をまとめたマトリックスを作成しました。これを生成 AI セキュリティスコーピングマトリックスと呼んでいます (図 1 参照) 。 　図 1 : 生成 AI セキュリティスコーピングマトリックス 最初のステップは、ユースケースがどのスコープに収まるかを判断することです。スコープには 1 ～ 5 の番号が付けられており、所有権が最も小さいものから大きいものまでが示されています。 生成 AI の購入利用 : スコープ 1 : コンシューマーアプリ — あなたのビジネスは、無料または有料で、パブリックなサードパーティの生成 AI のサービスを利用しています。このスコープでは、トレーニングデータやモデルを所有したり表示したりすることはできず、変更や拡張もできません。プロバイダーの利用規約に従って、API を呼び出すか、アプリケーションを直接使用します。 例 : ある従業員が生成 AI チャットアプリケーションを操作して、今後のマーケティングキャンペーンのアイデアを生み出します。 スコープ 2 : エンタープライズアプリ — あなたのビジネスは、生成 AI 機能が組み込まれたサードパーティのエンタープライズアプリケーションを使用しており、組織とベンダーの間にビジネス関係が確立されています。 例 : 会議の議題の作成に役立つ生成 AI 機能が組み込まれたサードパーティのエンタープライズスケジューリングアプリケーションを使用します。 生成 AI の構築 : スコープ 3 : 事前学習済みのモデル — あなたのビジネスは、既存のサードパーティの生成 AI 基盤モデルを使用して独自のアプリケーションを構築します。API を介してワークロードと直接統合します。 例 : Amazon Bedrock API による Anthropic Claude 基盤モデルを使用するカスタマーサポートチャットボットを作成するアプリケーションを構築します。 スコープ 4 : ファインチューニングされたモデル — あなたのビジネスは、ビジネス特有のデータを使用して既存のサードパーティ生成 AI 基盤モデルをファインチューニングし、ワークロードに特化して新しく拡張されたモデルを生成することで、ビジネスにさらに磨きをかけています。 例 : API を使用して基盤モデルにアクセスし、マーケティングチームが製品やサービス固有のマーケティング資料を作成できるようにするアプリケーションを構築します。 スコープ 5 : 自身でトレーニングしたモデル — あなたのビジネスは、所有しているまたは取得したデータを使用して、生成 AI モデルをゼロから構築し、トレーニングします。あなたはモデルのあらゆる側面を所有しています。 例 : 業界特有の深いデータのみに基づいてトレーニングされたモデルを作成し、その業界の企業にライセンスを供与して、まったく新しい LLM を作成したいと考えています。 生成 AI セキュリティスコーピングマトリックスでは、さまざまなタイプの生成 AI ソリューションにまたがる 5 つのセキュリティ領域を特定しています。各セキュリティ領域の固有の要件は、生成 AI アプリケーションのスコープによって異なる場合があります。どの生成 AI スコープが導入されているかを判断することで、セキュリティチームは迅速にフォーカスの優先順位を決め、各セキュリティ領域の範囲を評価できます。 それぞれのセキュリティ領域を調べて、スコーピングがセキュリティ要件にどのように影響するかを考えてみましょう。 ガバナンスとコンプライアンス — リスクを最小限に抑えながらビジネスを強化するために必要なポリシー、手順、報告。 法律とプライバシー — 生成 AI ソリューションを使用または作成するための特定の規制、法律、およびプライバシー要件。 リスク管理 — 生成 AI ソリューションに対する潜在的な脅威と推奨される緩和策の特定。 コントロール — リスクを軽減するために使用されるセキュリティコントロールの実装。 レジリエンス — 可用性を維持しビジネスの SLA を満たす生成 AI ソリューションを設計する方法。 「生成 AI をセキュアにする」ブログシリーズでは、生成 AI セキュリティスコーピングマトリックスを参考にして、AI 導入の範囲に応じてさまざまなセキュリティ要件と推奨事項がどのように変化するかを理解しやすくしています。調達、評価、セキュリティアーキテクチャのスコーピングなどの社内プロセスで、生成 AI セキュリティスコーピングマトリックスを採用して参照することをお勧めします。 何を優先すべきか ワークロードのスコープが特定されたので、今こそビジネスを迅速かつ安全に前進させる必要があります。優先すべき機会の例をいくつか見てみましょう。 ガバナンスとコンプライアンス、法律とプライバシー 　図 2 : ガバナンスとコンプライアンス コンシューマー向け市販アプリ (スコープ 1) とエンタープライズ向け市販アプリ (スコープ 2) では、利用規約、ライセンス、データ主権、その他の法的開示に特に注意する必要があります。組織のデータ管理要件に関する重要な考慮事項を概説し、組織に法務部門と調達部門がある場合は、必ずそれらの部門と緊密に連携してください。これらの要件がスコープ 1 または 2 のアプリケーションにどのように適用されるかを評価してください。データガバナンスは重要であり、既存の強力なデータガバナンス戦略を活用して、生成 AI ワークロードに拡張することができます。組織のリスクアペタイトとスコープ 1 とスコープ 2 のアプリケーションで達成したいセキュリティ態勢の概要を説明し、適切なデータタイプとデータ分類のみを使用するように指定するポリシーを実装します。たとえば、スコープ 1 のアプリケーションを使用する際に、個人を特定できる情報 (PII)、機密データ、または専有データの使用を禁止するポリシーを作成することを選択できます。 サードパーティモデルに必要なデータと機能がすべて揃っている場合は、スコープ 1 とスコープ 2 のアプリケーションが要件を満たす可能性があります。ただし、自社のビジネスデータを集約、関連づけ、解析したり、新しい洞察を得たり、反復作業を自動化したりすることが重要な場合は、スコープ 3、4、または 5 のアプリケーションをデプロイする必要があります。たとえば、組織では事前学習されたモデルを使用することを選択するかもしれません (スコープ 3) 。さらに一歩進んで、組織のデータを含む Amazon Titan などのサードパーティモデルのバージョンを作成したいと思うかもしれません。これをファインチューニングと呼びます (スコープ 4) 。あるいは、提供したデータでトレーニングした、まったく新しいファーストパーティモデルをゼロから作成することもできます (スコープ 5) 。 スコープ 3、4、5 では、データをモデルのトレーニングやファインチューニングに使用したり、出力の一部として使用したりできます。ソリューションがアクセスできる資産のデータ分類とデータタイプを理解する必要があります。スコープ 3 のソリューションでは、たとえばプロンプトへの入力として、 Agents for Amazon Bedrock の支援を受けて 検索拡張生成 (RAG : Retrieval Augmented Generation) を通じて提供されたデータに対してフィルタリングメカニズムを使用する場合があります。RAG はクエリされたデータをプロンプトの一部として利用することにより、トレーニングやファインチューニングの代わりに使用できます。これにより、LLM のコンテキストが拡張され、ファインチューニングやトレーニングによってデータをモデル自体に直接埋め込むのではなく、ビジネスデータを応答の一部として使用できる生成と応答が提供されます。図 3 は、RAG による生成 AI のプロンプトと応答で顧客データをどのように使用できるかを示すデータフロー図の例です。 　図 3 : 検索拡張生成 (RAG) 一方、スコープ 4 と 5 では、修正されたモデルを、モデルのファインチューニングやトレーニングに使用される最も機密性の高いレベルのデータ分類に分類する必要があります。モデルはトレーニング対象のデータのデータ分類を反映します。たとえば、モデルのファインチューニングまたはトレーニングに PII を提供した場合、新しいモデルには PII が含まれることになります。現在、承認に基づいてモデルの出力を簡単にフィルタリングするメカニズムはなく、ユーザーが他の方法では表示する権限がないデータを取得する可能性があります。これは重要なポイントです。モデルの周囲にアプリケーションを構築し、RAG データフローの一部としてビジネスデータにフィルタリング制御を実装できます。これにより、機密データをモデル内に直接配置することなく、データセキュリティの細分性を高めることができます。 図 4 : 法律とプライバシー 法的な観点から、サービスプロバイダーのエンドユーザー使用許諾契約 (EULA)、サービス条件 (TOS)、およびスコープ 1 から 4 でサービスを使用するために必要なその他の契約上の合意の全てを理解することが重要です。スコープ 5 については、法務チームがモデルの外部使用について独自の契約上の利用規約を定める必要があります。また、スコープ 3 とスコープ 4 については、サービスプロバイダーのサービス利用に関する法的条件と、そのサービス内でのモデルの利用に関するモデルプロバイダーの法的条件の両方を必ず確認してください。 さらに、 欧州連合 (EU) の一般データ保護規則 (GDPR) の「消去の権利」または「忘れられる権利」の要件がビジネスに適用される場合は、プライバシーに関する懸念も考慮してください。要求に応じて削除する必要のあるデータを使用してモデルをトレーニングまたはファインチューニングすることによる影響を慎重に検討してください。モデルからデータを削除する唯一の完全に効果的な方法は、トレーニング用データセットからデータを削除し、新しいバージョンのモデルをトレーニングすることです。データの削除がトレーニングデータ全体のほんの一部である場合、これは現実的ではなく、モデルのサイズによっては非常にコストがかかる可能性があります。 リスク管理 　図 5 : リスク管理 AI 対応アプリケーションは AI 非対応アプリケーションのような振る舞い、見た目、使用感がありますが、LLM とのやりとりが自由形式であるため、さらなる精査とガードレールが必要になります。生成 AI ワークロードにはどのようなリスクが当てはまるか、またそれらを軽減するにはどうすればよいかを特定することが重要です。 リスクを特定する方法はたくさんありますが、一般的なメカニズムはリスク評価と脅威モデリングの 2 つです。スコープ 1 とスコープ 2 では、サードパーティプロバイダーのリスクを評価して、そのサービスから発生する可能性のあるリスクと、そのプロバイダーが責任を負うリスクをどのように軽減または管理するかを理解します。同様に、そのサービスの利用者としてのリスク管理責任が何であるかを理解する必要があります。 スコープ 3、4、5 については脅威モデリングを実装することです。特定の脅威と生成 AI アプリケーションの脅威モデリング手法については今後のブログ記事で詳しく説明しますが、LLM に固有の脅威の例を挙げてみましょう。脅威アクターは、プロンプトインジェクションなどの手法を使用する可能性があります。これは、LLMに予期しない、または望ましくない方法で応答させるために、慎重に作成された入力です。この脅威は、特徴量の抽出（特徴量とは、機械学習（ML）モデルのトレーニングに使用されるデータの特性または性質のこと）、名誉毀損、内部システムへのアクセスなどに使用できます。ここ数ヶ月、 NIST 、 MITRE 、 OWASP は、AI および LLM ソリューションのセキュリティ保護に関するガイダンスを公開しています。MITRE と OWASP が公開しているアプローチのどちらでも、最初に挙げられる脅威はプロンプトインジェクション（モデルへの回避攻撃）です。プロンプトインジェクションの脅威は新しいように聞こえるかもしれませんが、多くのサイバーセキュリティ専門家には馴染み深いものです。これは本質的に、SQL インジェクション、JSON または XML インジェクション、コマンドラインインジェクションなどのインジェクション攻撃を進化させたもので、多くの実務者が対処に慣れています。 生成 AI ワークロードの新たな脅威ベクトルは、脅威モデリングと全体的なリスク管理の実践に新たなフロンティアを生み出します。前述のように、既存のサイバーセキュリティ対策がここでも適用されますが、この分野特有の脅威を考慮して適応する必要があります。組織内で生成 AI アプリケーションを作成している開発チームやその他の主要な利害関係者と深く連携するには、微妙な違いを理解し、脅威を適切にモデル化し、ベストプラクティスを定義する必要があります。 コントロール 　図 6 : コントロール コントロールは、リスクを軽減するためにコンプライアンス、ポリシー、およびセキュリティ要件を実施するのに役立ちます。優先順位の高いセキュリティコントロールの例である ID とアクセス管理について詳しく見ていきましょう。いくつかの背景を述べると、推論（入力に基づいて出力を生成するモデルのプロセス）の間、ファーストパーティまたはサードパーティの基盤モデル（スコープ 3 ～ 5 ）は不変です。モデルの API は入力を受け入れ、出力を返します。モデルはバージョン管理され、リリース後は静的です。モデル自体では、新しいデータを保存したり、時間の経過とともに結果を調整したり、外部データソースを直接組み込んだりすることはできません。モデルの外部にあるデータ処理機能の介入がなければ、モデルは新しいデータを保存したり変化したりしません。 最新のデータベースと基盤モデルのどちらにも、クエリを行うエンティティの ID を使用するという概念があります。従来のデータベースには、テーブルレベル、行レベル、列レベル、さらには要素レベルのセキュリティ制御があります。一方、基盤モデルでは、現在のところ、含まれている可能性のある特定のエンベディングにきめ細かくアクセスすることはできません。LLM におけるエンベディングとは、単語、音、グラフィックなどの各オブジェクトを表現するためにモデルがトレーニング中に作成する数学的表現であり、オブジェクトのコンテキストや他のオブジェクトとの関係を説明するのに役立ちます。エンティティは、モデル全体とそれが生成する推論へのアクセスを許可されるか、まったくアクセスできないかのどちらかです。つまり、従来のデータベースでは、各エンティティが行、列、テーブル、またはセルレベルでデータベース内のどのデータにアクセスできるか制御できる一方で、現世代の FM では、学習データのエンべディングが一度モデルに組み込まれると、どのオブジェクト由来のエンべディングであるかを区別してアクセス制御することはできないということです（訳者注 : 原文ではベクトルデータベース内の特定のエンベディングに関する記載がありますが、こちらの翻訳では執筆者に意図を確認し補足説明を加えた内容を記載しています）。言い換えると、今日のテクノロジーでは、エンティティにモデルへの直接アクセス権を付与すると、そのモデルがトレーニングされたデータすべてに対する権限をエンティティに付与することになります。アクセス時には、情報は 2 つの方向に流れます。プロンプトとコンテキストがユーザーからアプリケーションを介してモデルに流れ、生成された出力がモデルからアプリケーションに戻ってユーザーに推論応答を提供します。モデルへのアクセスを許可すると、これらのデータフローの両方の実行を暗黙的に承認することになり、これらのデータフローのどちらかまたは両方に機密データが含まれる可能性があります。 たとえば、あなたのビジネスが Amazon Bedrock 上でアプリケーションを構築したとします。スコープ 4 では基盤モデルをファインチューニングし、スコープ 5 では独自のビジネスデータに基づいてモデルをトレーニングしたとします。 AWS Identity and Access Management (IAM) ポリシーは、特定のモデルを呼び出す権限をアプリケーションに付与します。ポリシーでは、モデル内のデータのサブセットへのアクセスを制限することはできません。IAM では、モデルを直接操作する場合、モデルへのアクセスに制限されます。 { "Version": "2012-10-17", "Statement": { "Sid": "AllowInference", "Effect": "Allow", "Action": [ "bedrock:InvokeModel" ], "Resource": "arn:aws:bedrock:*:: <foundation-model> / <model-id-of-model-to-allow> } } この場合、最小権限を実装するにはどうすればよいでしょうか。ほとんどのシナリオでは、アプリケーションレイヤーが Amazon Bedrock エンドポイントを呼び出してモデルと対話します。このフロントエンドアプリケーションでは、 Amazon Cognito や AWS IAM Identity Center などの ID ソリューションを使用してユーザーを認証および承認し、ロール、属性、ユーザーコミュニティに基づいて特定のアクションと特定のデータへのアクセスを適宜制限できます。たとえば、アプリケーションはユーザーの権限に基づいてモデルを選択できます。あるいは、アプリケーションが Amazon Kendra や Amazon OpenSearch Serverless などのサービスを使って、外部データソースにクエリを実行して、生成的な AI レスポンス用のジャストインタイムデータを提供することで RAG を使用する場合もあります。その場合は、認可レイヤーを使用して、ユーザーの役割と資格に基づいて特定のコンテンツへのアクセスをフィルタリングします。ご覧のように、ID とアクセス管理の原則は組織が開発する他のアプリケーションと同じですが、生成 AI ワークロードの固有の機能とアーキテクチャ上の考慮事項を考慮する必要があります。 レジリエンス 　図 7 : レジリエンス 最後に、 CIA のトライアド で指摘されているように、可用性はセキュリティの重要な要素です。レジリエントなアプリケーションを構築することは、組織の可用性と事業継続性の要件を満たすために不可欠です。スコープ 1 とスコープ 2 については、プロバイダーの可用性が組織のニーズと期待にどのように合っているかを理解する必要があります。基盤となるモデル、API、またはプレゼンテーション層が利用できなくなった場合の混乱が、ビジネスにどのような影響を与える可能性があるかを慎重に検討してください。さらに、複雑なプロンプトや生成された出力がクォータの使用量にどのように影響するか、またはアプリケーションの課金にどのような影響を与えるかを検討してください。 スコープ 3、4、5 では、複雑なプロンプトやコンプリーションを考慮して適切なタイムアウトを設定してください。また、モデルで定義されている割り当てられた文字制限のプロンプト入力サイズを確認することもできます。また、期待するユーザーエクスペリエンスを実現するために、 バックオフや再試行 、 サーキットブレーカーのパターン など、レジリエントな設計に関する既存のベストプラクティスを検討してください。ベクトルデータベースを使用する場合、さまざまな障害モードに対する回復力を高めるために、高可用性構成と災害復旧計画を立てることをお勧めします。 推論モデルパイプラインとトレーニングモデルパイプラインの両方におけるインスタンスの柔軟性は、きわめてクリティカルなワークロードのためにコンピューティングを確保したり事前にプロビジョニングしたりすることに加えて、アーキテクチャ上の重要な考慮事項です。Amazon Bedrock や SageMaker などのマネージドサービスを使用する場合、マルチリージョンデプロイ戦略を実装する際には、AWS リージョンの可用性と機能の同等性を検証する必要があります。同様に、スコープ 4 と 5 のワークロードをマルチリージョンでサポートする場合、リージョン全体でファインチューニング用データまたはトレーニング用データが利用できることを考慮する必要があります。SageMaker を使用してスコープ 5 のモデルをトレーニングする場合は、 チェックポイント を使用してモデルをトレーニングしながら進行状況を保存してください。これにより、必要に応じて最後に保存したチェックポイントからトレーニングを再開できます。 AWS Resilience Hub および Well Architected Framework の「 信頼性の柱 」と「 オペレーショナルエクセレンスの柱 」で確立されている、既存のアプリケーションレジリエンスのベストプラクティスを必ず確認して実装してください。 結論 この記事では、確立されたクラウドセキュリティの原則が、生成 AI ソリューションを保護するための強固な基盤をどのように提供するかを概説しました。既存のセキュリティ手法やパターンの多くを使用しますが、生成 AI の基礎と、対処しなければならない独自の脅威とセキュリティ上の考慮事項についても学ぶ必要があります。生成 AI のセキュリティスコーピングマトリックスを使用すると、生成 AI ワークロードの範囲と、適用される関連するセキュリティ範囲を判断するのに役立ちます。対象範囲が決まったら、重要なセキュリティ要件の解決に優先順位を付け、ビジネスで生成 AI ワークロードを安全に使用できるようにします。 「生成 AI をセキュアにする」シリーズの今後の記事では、これらのトピックやその他のセキュリティトピックを引き続き探っていきますので、是非ご覧ください。 この記事についてご質問がある場合は、 AWS サポートにお問い合わせください 。 著者について Matt Saner Matt は AWS のセキュリティスペシャリストを率いるシニアマネージャーです。彼と彼のチームは、世界最大かつ最も複雑な組織が重大なセキュリティ課題を解決するのを支援し、セキュリティチームがビジネスのイネーブラーになるのを支援しています。AWS に入社する前、Matt はファイナンスサービス業界で 20 年近く働き、テクノロジー、セキュリティ、リスク、コンプライアンスのさまざまな課題を解決してきました。彼は生涯学習（セキュリティは決して静的ではない）を重視し、ニューヨーク大学でサイバーセキュリティの修士号を取得しています。おもしろいことに、彼は一般航空機の操縦を楽しむパイロットでもあります。 Mike Lapidakis Mike はセキュリティとコンプライアンス、移行とモダナイゼーション、ネットワーキング、レジリエンスの各ドメインで構成される AWS インダストリースペシャリスト SA チームを率いています。このチームは、技術的支援、教育、顧客支援、経営陣との連携を通じて、地球上で最大の顧客がビジネスを変革するための強固な基盤を確立できるよう支援しています。Mike は、10 年以上にわたり、さまざまなアーキテクチャやコンサルティングの役割において、組織のクラウド上でのモダナイゼーションを支援してきました。 翻訳はプロフェッショナルサービス本部の藤浦が担当しました。 原文はこちら です。 「AWS Security and Risk Management Forum  ～レジリエントな未来：生成AIなどの最新技術を活用したセキュリティ・リスクマネージメント～」 のご案内 2024 年 3 月 19 日に東京にて表題のイベントが開催されます。本イベントでは、生成 AI の活用やクラウドの活用の最新動向および生成 AI の押さえるべきポイント、AWS 内の取り組みについて米国セキュリティ部門のディレクターが直接解説します。また、有識者や外部ゲストを迎え、クラウドにおけるセキュリティ、リスクマネジメントに焦点を当てた各種対策を具体的に解説します。ご希望の方は、 こちらから ご登録をお願いいたします。

画像や動画などのコンテンツを自社サービスのユーザーに共有・公開するとき、肌の露出が多い画像や暴力的な画像など、不適切なものを取り除きたい場面は多くあります。特に、ユーザーが生成したコンテンツを他のユーザーに公開するときや、生成 AI が作成したコンテンツを広く公開するときには、コンテンツの品質を担保することは重要です。しかし、画像や動画の確認を全て人力で行うのは、コンテンツの量が膨大になるほど時間がかかってしまいます。そんなときに、Amazon Rekognition のモデレーション機能を使えば、不適切なコンテンツを検出できます。 このブログでは、Amazon Rekognition カスタムモデレーションを用いて、モデレーション機能を自身のワークロードにカスタマイズする方法をご紹介します。ユースケースやカスタムモデレーション機能の利用方法、実際に試してみた際の精度をご紹介します。 Amazon Rekognition のカスタムモデレーションとは？ Amazon Rekognition は、機械学習を使用して画像や動画の分析を行えるサービスです。物体やシーンの検出、人の顔の検出や比較、動画におけるシーンや動線の分析など、様々な分析にお使いいただけます。そのなかでもモデレーション機能は、画像や動画に含まれる不適切なコンテンツを検出するものです。 こちらのページ にあるように、検出対象となるのは肌の露出や暴力などのカテゴリーです。検出時にはカテゴリーのタグが付加されるので、ニーズに応じて不適切なカテゴリーのコンテンツを選択的に検出できます。 なお、Amazon Rekognition のモデレーション機能には、2024 年 2 月に アップデート がありました。新しい検出対象のラベルが追加されたほか、モデルの精度が向上し、アニメーションやイラスト付きのコンテンツを識別する新しい機能が導入されました。2024 年 2 月時点では、新しい検出対象のラベルは 英語版のドキュメント にまとめられています。 Amazon Rekognition の基本的な機能は、自身でモデルを用意しなくても分析対象のデータさえ用意すれば利用できます。しかし、追加学習用のデータを用意すれば、自身のワークロードのためのカスタマイズもできます。そのなかでもカスタムモデレーションは、不適切なコンテンツの検出を自身でカスタマイズできる機能です。 Amazon Rekognition ユースケース Amazon Rekognition のカスタムモデレーションが使えるユースケースとして、管理者が直接作成したものでない画像が広く公開されるアプリケーションが考えられます。具体的には下記のような例が挙げられます。 ユーザーが投稿した画像を他のユーザーが閲覧できる ソーシャルネットワーキングサービスの投稿 ユーザー登録時のアイコン 生成 AI が生成した大量の画像をユーザーに公開・配布する 生成 AI を利用したゲームやエンターテインメント AI による画像変換プラットフォーム このようなときに、広くユーザーに公開されるのが望ましくないコンテンツには下記のような例があるでしょう。もちろん、何を公開していいかはユースケースにも依存します。 有名キャラクターなど著作権・肖像権を侵害するコンテンツ 性的なコンテンツや暴力的なコンテンツ タバコやアルコールなど対象年齢や見せ方によっては倫理的に不適切となりうるコンテンツ 競合他社のロゴなど自社製品として望ましくないコンテンツ ここからは、このそれぞれについて、Amazon Rekognition をどのように利用できるか紹介していきます。 性的なコンテンツや暴力的なコンテンツ このようなコンテンツは、Amazon Rekognition のデフォルトのモデレーション機能を用いれば検出できます。しかし、デフォルメされたイラストや、独特なタッチで描かれたイラストなど、コンテンツによっては Amazon Rekognition が十分な精度で検出できないかもしれません。この場合の対応策は大きく 2 種類考えられます。1 つ目は、検出のしきい値を下げる方法です。Amazon Rekognition のモデレーションでは、モデルがどれくらいの確度で不適切なコンテンツだと予想した場合にラベルを付与するかのしきい値を、自身で決めることができます。このしきい値を下げたうえで、検出されたコンテンツは人力で二重に確認するという方法が取れます。そして 2 つ目の方法が、カスタムモデレーションの利用です。デフォルトの機能でうまく検出できなかった画像を入力して学習させることで、モデルをカスタマイズできます。 タバコやアルコールなど対象年齢や見せ方によっては倫理的に不適切となりうるコンテンツ タバコやアルコールも Amazon Rekognition のデフォルトのモデレーション機能の検出対象に含まれます。しかし、場合によっては常に対象のコンテンツを規制したくないこともあるでしょう。その場合には、デフォルトのモデルを利用しつつ、モデレーション機能の検出のしきい値を上げることが解決策になることもあるでしょう。しかし、低いしきい値で検出されるものが規制したいものであるとは限りません。そのような場合には、特定のケースだけを規制するために、カスタムモデレーションによるモデルのカスタマイズが使えます。 有名キャラクターなど著作権・肖像権を侵害するコンテンツ 不特定のコンテンツの著作権侵害に対応したい場合は、Amazon Rekognition のモデレーション機能では対処できません。ただし、具体的なユースケースによっては Amazon Rekognition の他の機能が使える可能性はあります。例えば、特定のキャラクターを検出して公開を防止したい場合は、Amazon Rekognition のカスタムラベル機能を用いれば解決できます。これは、検出対象オブジェクトのラベル付き画像を用意して、Amazon Rekognition の物体検出機能をカスタマイズするものです。また、肖像権の侵害を防ぎたい場合には、Amazon Rekognition の顔検出機能を用いることができます。さらに、有名人の顔検出をしたい場合は、Amazon Rekognition の 有名人認識機能 が役に立ちます。 なお、Amazon Bedrock 上のモデル Amazon Titan Image Generator が生成した画像で著作権の請求が生じた場合は、 Amazon は上限なしの知的財産補償を提供します 。Amazon Rekognition とは直接関係ないですが、Amazon Titan Image Generator を利用する場合は参考にしてください。 競合他社のロゴなど自社製品として望ましくないコンテンツ この例は、有名キャラクターの映り込みを防ぐ例と似ています。不特定のコンテンツの検出は難しいですが、対象となるコンテンツを絞れば検出は可能です。ロゴなど特定のオブジェクトを検出したい場合はカスタムラベルを利用すれば検出でき、風景など画像全体にわたって検出したい場合はカスタムモデレーションが利用できます。 Amazon Rekognition カスタムモデレーションを使ってみる この章では、Amazon Rekognition カスタムモデレーションの使い方をご紹介すると同時に、実際に使ってみた際の精度を確認します。今回は架空のシナリオとして、A 国におけるギャンブル規制を想定してみます。A 国では違法なギャンブルとして、「ゆで玉子を見せてそれが固茹でか半熟か当てる」という「たまごギャンブル」が流行っています。そこで、A 国のあるサービスでは、このギャンブルを想起させる画像は規制したいと考えています。もちろん一般的にはそのようなギャンブルは存在しないので、Amazon Rekognition のデフォルトのモデレーション機能では「たまごギャンブル」は規制対象になっていません。そこで、このブログでは Amazon Rekognition カスタムモデレーションを利用して「たまごギャンブル」を検出することにします。 今回は「たまごギャンブル」に関係する画像として、ゆでたまごを不適切なコンテンツとして検出します。ゆでている途中や殻を剥く前の生玉子も、今回の検出の対象となります。一方で、割った生玉子や目玉焼きなど、「たまごギャンブル」とは直接関係ない画像は、検出対象ではありません。実際の画像の例は、このあとの「画像の準備」の項でお見せします。 画像の準備 まずは画像を準備します。用意する画像についての推奨事項は Amazon Rekognition のデベロッパーガイド に書かれています。モデレーション機能をカスタマイズする前に、Amazon Rekognition のカスタマイズしていないデフォルトのモデレーション機能を用い、検出精度を確認してください。このとき、本当は検出対象としたいのにデフォルトの機能では検出できなかった画像を、「偽陰性」の画像と呼びます。逆に、本当は検出してほしくないのにデフォルトの機能で検出されてしまった画像を、「偽陽性」の画像と呼びます。高い精度を得るためには、偽陽性と偽陰性の画像を含めて、下記の条件を満たすような画像データセットを準備することが推奨されています。 デフォルトで偽陽性が出る画像をトレーニング用に 20 枚以上 デフォルトで偽陰性が出る画像をトレーニング用に 50 枚以上 テスト用の画像を 20 枚以上 デフォルトで誤った予測が出る画像だけでなく正しい予測が出る画像も用意する 今回は、デフォルトでは不適切なコンテンツの検出に失敗する偽陰性の画像に焦点を当てます。そのため、デフォルトで偽陰性が出るような「たまごギャンブル」関係の画像 70 枚以上と、ギャンブルと関係ないただの玉子の画像を登録しておきます。一方で、今回の「たまごギャンブル」のシナリオでは、デフォルトで偽陽性の画像は存在しません。そのため、偽陽性の画像は用意しません。 用意した画像の登録方法は複数ありますが、今回は Amazon S3 にバケットを作成してデータを入れておきます。下記は検出対象の画像例です。 ギャンブルに使われるゆで玉子を作っている画像 ディーラーがゆで玉子を取り出している画像 一方で、割った生玉子や目玉焼きは、今回のギャンブルとは関係ありません。下記が関係ない画像の例です。 生玉子 目玉焼き プロジェクトの作成 Amazon Rekognition カスタムモデレーションでは、カスタム内容ごとに「アダプター」を定義します。そして、複数のアダプターは 1 つのプロジェクト内で管理できます。したがって、まずはプロジェクトを作成します。Amazon Rekognition カスタムモデレーションの画面において、下の画像の「プロジェクトを作成」をクリックします。 続いて、プロジェクト名とアダプター名を決めます。 その後、モデルのカスタマイズに利用する画像をアダプターに登録します。今回は、先ほど Amazon S3 にアップロードした画像を利用します。「S3 バケットから画像をインポートする」を選択したあと、該当バケットの URI を入力します。 最後に、テストデータの提供方法を選びます。「自動分割」を選択すると、アップロードした画像を自動でトレーニングデータとテストデータに分けてくれます。今回はこちらの自動分割を選択します。ここまでできたら、「プロジェクトを作成」をクリックします。 画像のラベルづけ 続いて、画像にモデレーションのためのラベルを付加します。この作業は Amazon Rekognition の UI 上で進められます。今回は、ゆでたまごに関係する画像にはすべて「Gambling」のタグをつけていきます。 一方で、ゆでたまごには関係ない画像には「Safe」の画像をつけていきます。今回、割った生玉子は規制の対象外です。 モデルのトレーニング 上記で登録したラベルは、ドラフト状態になっている間は保存されていません。「ドラフトを保存」をクリックして 保存します。その後、「アダプターをトレーニング」をクリックします。 遷移後の画面で再度「アダプターをトレーニング」を押し、トレーニングを開始します。なお、この画面でトレーニングの際の「信頼度のしきい値」を変更することもできます。信頼度のしきい値を高く設定してトレーニングすると、不適切な画像を敏感に検出する代わりに、適切な画像も誤って検出してしまう可能性が上がります。つまり、トレーニング後の偽陰性が減り、代わりに偽陽性が増えやすくなります。今回はデフォルトの 50 のままで進めます。今回は、130 枚の画像を登録して 22 分でトレーニングが終了しました。 アダプターの精度確認 トレーニングが終わったら、アダプターの精度を確認してみましょう。アダプターの詳細画面で、あらかじめ登録したテスト画像に対する精度を確認できます。 この画面では、偽陽性と偽陰性それぞれの改善率が書かれています。この改善率は、カスタムしていないデフォルトのモデレーション機能による検出精度と比較した際のものです。今回のアダプター作成の目的は、Rekognition のベースモデルで偽陰性が出る「たまごギャンブル」の画像を陽性として検出したいというものでした。ですので、偽陽性は元々存在せず、偽陽性の改善率が 0% なのは問題ありません。一方、偽陰性の改善率が 5% と低くなっていることは問題です。「ラベルごとのパフォーマンス」の欄を見ると、ギャンブルのラベルがついている画像 21 枚のうち 20 枚は検出できていません。 このように精度が低い際の解決策として、画像をより多く用意し再度トレーニングすることが考えられます。しかし、場合によっては、このアダプターのままでも精度を上げられる方法があります。それは、信頼度のしきい値の変更です。今回は偽陰性を検出したいので、トレーニングの際の信頼度のしきい値を上げるか、テストの際の信頼度のしきい値を下げることによって、偽陰性となる画像をより敏感に検出できます。試しにアダプターの詳細画面で信頼度のしきい値を 45% に下げると、「偽陰性の改善」の項が一気に上がります。なお、これでも偽陰性が改善されていない画像は残っています。また、現実的な問題では、アダプターにより偽陽性のデータが増えることもあるかもしれません。そのような場合は、適切に予測できなかった画像のデータを重点的に増やしてトレーニングし直せば精度が上がると考えられます。 アダプターの利用 学習したアダプターは、CLI や SDK 経由で利用できます。利用方法は ブログ「Announcing Rekogniton Custom Moderation: Enhance accuracy of pre-trained Rekognition moderation models with your data」 や Amazon Rekognition のドキュメントの DetectModerationLabels の項 を参考にしてください。今回は、撮影した画像をランダムに 2 つに分け、それぞれアダプターに入力する画像と入力しない画像としています。前者の画像が 130 枚あるのに対して後者の画像は 52 枚です。この後者の画像で精度を確認してみます。下記は、検出する際の信頼度のしきい値を 45% とした際の結果です。基本的にはうまく分類できていますが、一部、ギャンブルに関するのにアダプターによって関係ないと判定されている画像があります。このような場合は、信頼度のしきい値の変更もしくはアダプターの再学習で対応します。 本ブログでは、Amazon Rekognition のカスタムモデレーション機能についてご紹介してきました。本機能の使い道について議論したうえで、「たまごギャンブル」という架空のシナリオに基づいて実際にカスタムモデレーション機能を利用する方法をご紹介しました。なお、今回の「たまごギャンブルのシナリオ」はひとつの例で、データセットの特性や実際の状況などによって精度は変わります。ユーザーや生成 AI が生成したコンテンツをサービスに組み込むことが増えている昨今、コンテンツのモデレーション機能の必要性は高まっていると考えられます。ぜひ皆様も本機能を試していただけますと幸いです。

2023 年 11 月 27 日 – 12 月 1 日 にラスベガス開催された AWS re:Invent では、 メディア＆エンターテインメント業領域における最新動向、最先端の AWS 活用事例、新サービス・新機能を紹介しました。また、2023年 11 月 15  日 – 11 月 17 日 に幕張メッセで開催された、Inter BEE では、 Create. Deliver. Monetize をテーマに、AWS ブースでコンテンツ制作、放送、メディアサプライチェーン＆アーカイブ、Direct-to-Consumer ＆ ストリーミング、データ活用 ＆ AIML の 5 つのソリューション分野での展示を行い、ブース内シアターや同時開催の 主催者セミナーでは、様々なお客様に最新事例を発表頂きました。 本セミナーでは、上記 2 つのイベントのハイライトを、メディア & エンターテインメント業界のお客様向けにご紹介しました。 セミナーのアジェンダ: AWS re:Invent 2023 メディア業界向けサービス紹介および活用事例紹介 Recap: InterBEE 2023 AWS re:Invent 2023 メディア業界向けサービス紹介および活用事例紹介 アマゾン ウェブ サービス ジャパン合同会社　ソリューションアーキテクト , 小役丸 達也  [ 資料 ] AWS re:Invent 2023 で発表されたサービスアップデートの紹介をメディア & エンターテイメント業界に関連するものを中心に行いました。加えて、メディア & エンターテイメント業界向けのセッションから重要な事例をピックアップして詳しく紹介しました。 Recap: InterBEE 2023 アマゾン ウェブ サービス ジャパン合同会社　ソリューションアーキテクト , 井村 紀彦 [ 資料 ] 2023 年 11 月 15 日〜 17日にかけて幕張メッセで開催された Inter BEE では、 Create. Deliver. Monetize をテーマに、AWS ブースでコンテンツ制作、放送、メディアサプライチェーン＆アーカイブ、Direct-to-Consumer＆ストリーミング、データ活用＆AIML の 5 つのソリューション分野での展示を行いました。ブース内シアターや同時開催の 出展者セミナーでは、様々なお客様に最新事例を発表頂きました。Inter BEE における発表のハイライトを要約してご紹介しました。 InterBEE 2023 については以下ポストもご参照ください。 【 Inter BEE 2023 ※情報更新】AWS 展示のご紹介 【 Inter BEE 2023 ※情報更新】AWS スポンサーのご紹介 【開催報告&資料公開】Inter BEE 2023 AWS 出展者セミナー 【開催報告&資料公開】Inter BEE 2023 AWS ブースセミナー スペシャルセッション おわりに 本ブログでは、2024 年 2 月 1 日に開催されたメディア業界のお客様向けの AWS re:Invent Recap セミナーを紹介しました。今回セミナーに参加いただいた皆さま誠にありがとうございました。引き続き業界の皆様に役立つ情報を、セミナーやブログで発信していきます。どうぞよろしくお願い致します。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 このブログは BD 山口が担当いたしました。

これまでのブログ投稿で、Well-Architected Framework Review(WAFR) を実行するための最初の 2 つのフェーズについて説明しました。 最初のフェーズは 準備 で、2 番目のフェーズは レビュー を実施することです。 このブログ投稿では、3 番目のフェーズである 改善 について詳しく説明します。 図1 – WAFR のフェーズ 改善フェーズ ワークロードのアーキテクチャを AWS のベストプラクティスと照らし合わせてレビューしているこの時点で、 以前 説明した通り、レビューのための必要な準備を行い、 こちらの推奨事項 に従って実際のレビューを完了させたはずです。その結果、レビュー中に収集した回答に基づいて、アーキテクチャのリスクを特定したはずです。これらのリスクを、 高リスクの問題 (High Risk Issues, HRI) と中リスクの問題 (Medium Risk Issues, MRI) と呼びます （詳細は後ほど説明します）。改善フェーズでは、改善計画（時には対応計画 (Treatment Plan) と呼ばれる）の作成を開始します。つまり、これらのリスクのリストを作成し、ビジネスへの影響を理解し、ソリューションを見つけ、最後に組織の優先事項に従ってこれらのソリューションを実装していきます。 以下のサイクルは、WAFR の改善フェーズに含まれる主なステップを示しています。各ステップの詳細について説明します。 1- リスクの特定 （別名：改善機会） [所要時間: 1日] WAFR の文脈上で使用されるリスクには 2 つのカテゴリがあります。高リスクの問題 ( HRI ) と中リスクの問題 ( MRI ) です。 HRI はビジネスに重大な悪影響を及ぼす可能性のあるアーキテクチャと運用の選択肢です。組織の業務、資産、個人に影響を与える可能性があります。セキュリティの柱における HRI の例は、AWS アカウントを保護していないことです。 MRI もビジネスに悪影響を与える可能性がありますが、その影響度は HRI ほどではありません。セキュリティの柱における MRI の例は、定期的に認証情報の監査とローテーションを行っていないことです。 HRI/MRI レポートの生成 HRI/MRI を視覚的に特定する最初のステップは、確認した各ワークロードのリスクを示すレポートを生成することです。 AWS Well-Architected Tool (AWS WA Tool) の ダッシュボード から、ワークロードとそれに関連する HRI および MRI にアクセスできます。 また、共有されたワークロードも含めることができます。 ダッシュボードを使用すると、ワークロード、柱、または重要度（高または中）で問題をフィルタリングできます。 この図は、いくつかのサンプルワークロードを含むダッシュボードの例を示しています。 下にスクロールさせると、HRI/MRI のリストが表示されます。柱または重要度でフィルタリングできます。例えば、これは信頼性の柱で発見された HRI/MRI のリストです。改善項目を選択すると、Well-Architected Framework からそれに関連するベストプラクティスに直接移動します。そこから、問題を修復するために必要な推奨アクションと必要なリソースについて読むことができます。 これらの全ての結果を 1 つのレポートにまとめるには、WA Tool のダッシュボードから [レポートの生成] を選択します。 このレポートを組織内のレビューチームと共有することを推奨します。通常、私はお客様に対して、次のステップに備えるために、実施した内容、主な調査結果、改善案をまとめた要約メールをお送りしています。 2- リスクの理解 [所要時間: 2-3 週間] リスクに対処する前に、ビジネスに対するその潜在的な重大性と影響、組織にもたらす価値、およびその改善を実装するためのチームの労力を理解することが重要です。HRI と MRI の定義に基づいてビジネスに対するリスクのレベルを評価する際には、次の質問を考えてみましょう。 リスクが影響を及ぼす可能性はどの程度か？ お客様への影響は何か？ 結果としてのビジネスへの影響は何か？ リスクを完全に排除できるか、それとも軽減するのみか？ 誰がリスクを負っているか？ 誰がリスクの排除や軽減のための改善作業を担うか? 主要なステークホルダーやビジネスオーナーにこれらの質問に答えてもらうことで、焦点を当てるべき最も重要なリスクのリストの作成と、それらに対処するための時間を予測するのに役立ちます。 架空のワークロードを使用して、例を示しましょう。 HRI/MRI やビジネスにもたらすリスクについてチームと話し合った後、対処が必要な次の HRI を特定しました。 3- 規範的なソリューションの決定 [所要時間: 4-5 週間] 組織のコンテキスト上でリスクと改善の機会を理解したら、チームと協力して、リスクに対する適切で規範的なソリューションを決定する必要があります。このフェーズでは、各チームが自分の領域で発見された HRI に取り組み、HRI に対処するための規範的なソリューションを決定する必要があります。このステップでは、追加の調査、ディスカッション、概念実証の構築が必要になる場合があります。このフェーズでは、ソリューションの実装の詳細に急がないことが重要です。次のステップで説明するように、質問に含まれている HRI がワークロードの優先事項であると決まった際に、後でそれを行います。このステップの目的は、ソリューションの複雑さと必要なリソースを理解することで、ステップ 4 の優先順位リストの作成時にそれらを考慮できるようにすることです。 今回の例では、3 つの HRI について次のソリューションを決定しました。 4- 実装と追跡 [所要時間: 3-6 ヶ月] まず優先順位をつけましょう。無制限の時間とリソースを持っている組織は存在しません。WAFR の結果として特定された全ての HRI/MRI に同時に取り組もうとするのは、WAFR から最大限のメリットを得る正しい方法とは限りません。私はいつもお客様に、ビジネスへの影響が大きく、実装がそれほど難しくない HRI/MRI の数を選んで始めることを推奨しています。ソリューションを実装します。改善を追跡し、そのアプローチを反復します。 しかし、実装する上で最も重要な項目に優先順位を付けるにはどうしたらよいでしょうか? ソリューションの優先順位を可視化するのに役立つツールの 1 つが、 アイゼンハワースタイルのプロット です。このツールを使用する方法は様々です。評価する際には、改善の重要性（ビジネスにもたらす価値の大きさ）と改善を実装するための労力（必要な時間、実装の複雑さ、人数など）の両方を考慮してください。 分析を行うと、ビジネスに最も影響を与えるリスクのセットが得られます。同時に、これらのリスクは実装が複雑ではありません。これらは、最初の反復で実装を開始するのに適した候補となります。 このモデルを今回の例に適用してみましょう。 今回の例で特定された HRI をレビューした結果、次のことが判明しました。 これはプロットを使用した分析の様子です。REL1、COST1、OPS4 を優先順位として決定した後、実装を開始し、次の HRI/MRI のセットについてこのプロセスを繰り返します。 図 9 – 影響度/複雑さを考慮したソリューションの優先順位付け ソリューションの特性 特定されたリスクに対するソリューションを選択する際には、次の点を考慮してください。 S.M.A.R.T : ソリューションを SMART の観点から考えましょう。良いソリューションは、具体的な (Specific) アウトプットがあるもので、測定可能 (Measurable) で、達成可能 (Achievable) で、問題と関連性があり (Relevant) 、期限が設定されている (Time-bound) べきです。 オーナー: 全てのソリューションについて、オーナーを特定しましょう。 シンプルで複雑でない: 複雑なソリューションは機能しますが、改善をより困難で長期化させます。常に複雑性よりもシンプルさを選択しましょう。 Two-way Door ソリューション: ソリューションは拡張可能で、時間とともに改善・進化するように設計されるべきです。可能であれば、アーキテクチャが発展しても適応できない静的なソリューションは避けてください。 パターンベース: コード化、再利用、再共有できるソリューションを目指しましょう。車輪の再発明は避けましょう。 いくつかの例 をチェックしてください。 タイムライン 「これらのステップを実行していくための典型的なタイムラインはどのようなものか」と疑問に思われるかもしれません。それに対する一概に決まった答えはありません。組織はそれぞれ異なり、独自の課題があるからです。しかし、多くのお客様との成功した WAFR の事例から見る限り、このフェーズには 90-180 日かけることを推奨します。この期間がより長くなるような HRI/MRI のリストである場合は、優先順位を付けて短いリストを取り出すことを推奨します。そうすれば、プロセスの実践を始めて改善を図ることができます。その後、残りの項目に対して繰り返し実施できます。 まとめ このブログ投稿では、WAFR の結果として特定されたアーキテクチャの HRI/MRI に対処するための改善計画を策定する際に踏むステップについて順を追って説明しました。改善計画を策定する前に、リスクを理解して分析し、優先順位を付け、そのソリューションを見極め、最も影響力のあるリスクを対象に優先的なアプローチを決定する必要があります。それを達成するのに役立ついくつかのツールとリソースを紹介しました。また、優れたソリューションを生み出す特性についてもいくつか紹介しました。皆さんの次のステップは、組織にある 2,3 のワークロードに対して Well-Architected Framework Review(WAFR) を実施することの重要性についてチームと話し合うことです。 著者について Ebrahim (EB) Khiyami Ebrahim (EB) Khiyami は AWS のシニアソリューションアーキテクトです。 彼は AWS Well-Architected Framework のスペシャリストであり、移行と災害復旧に関する専門家 (Subject Matter Expert, SME) でもあります。仕事以外の時間は、サッカーをしたり、観戦したり、コーチをしたりすることがよくあります。 翻訳はソリューションアーキテクトの安藤が担当しました。原文は こちら です。

Well-Architected Framework Review (WAFR) を成功させるには、準備、レビュー、改善の 3 つのフェーズがあります。このブログシリーズの パート 1 では、準備フェーズについて説明しました。このパートでは、第 2 フェーズ、つまり実際のレビューにおけるベストプラクティスについて詳しく説明します。 図 1 – WAFR のフェーズ 準備フェーズ の推奨事項に従っていると仮定すると、この時点で、レビューしたいワークロードを特定し、スポンサーを特定し、レビューする柱とその優先順位を決定し、使用する レンズ （ある場合）とレビューセッションの形式を決定しているはずです。また、レビューの質問に答えるために、ワークロードに関する必要なデータも収集しているはずです。 WAFR のゴール WAFR の成功のためのいくつかの推奨事項について深く掘り下げる前に、レビューの最終目標はシステムアーキテクチャを 改善 して、これらのシステムがビジネスニーズをより良くサポートできるようにすることであることを再確認しておくことが重要です。アーキテクチャ改善プロセスは、現在のアーキテクチャをレビューし、ベストプラクティスと比較することから始まります。レビューの質問に回答することでこれを行います。各柱に対し質問のセットがあります。回答に基づいて、改善領域、つまり 高リスクの問題 (High-Risk-Issues, HRI) および 中リスクの問題 (Medium-Risk-Issues, MRI) を特定します。次に、優先順位に基づいたアプローチを使用して、これらのリスクを改善するための対応計画の作成に取り組みます。 WAFR のベストプラクティス 1- 期待値を設定します。 WAFR は全ての参加者にとって大きなコミットメントです。メインのステークホルダーと事前にこの話し合いを行い、レビューの前・最中・後の期待値と役割を明確にします。彼らのサポートが得られることを確認しましょう。 2- 監査ではなく対話であることを意識します。 WAFR セッションで最も良い結果を出すのは、チェックリストや採点の機会としてではなく、対話の機会としてステークホルダーが捉える場合です。これにより、ベストプラクティスの見逃しを責められることなく、全てのチームメンバーがシステムについて自由に話すことを促します。これはアーキテクチャリスクの発見に役立ちます。 3- チームスポーツの精神を持って、チームの全員が役割を果たすべきです。 例えば、柱のスポンサーはその柱内のすべての質問に正しく答えるべきです。スポンサーは、レビュー中に特定されたリスクの改善計画を所有する必要があります。これはレビューの改善フェーズで異なるチーム間で特定されたリスクの優先順位付けと解決策を見つける必要がある場合に、より重要になります。これはこのブログシリーズの パート 3 で議論されています。 4- 1 回きりのチェックではなく、継続的なチェックが必要です。 物事は常に変化するので、その変化を放っておかないようにすべきです。組織内で WAFR（またはそのカスタマイズバージョン）を定期的に実施することを習慣化させる、もしくは、テストから本番への移行など、ワークロードのライフサイクルの大きなマイルストーンごとに合わせて実施することを推奨します。 5- より早いうちに実施することが望ましいです。 本番ではなく設計段階にあるうちは、意思決定に影響を与え変更を促進することがより容易であるからです。 6- AWS Well-Architected Tool (AWS WA Tool) を使用します。 WAFR の質問は ホワイトペーパー として利用できます。しかし、レビューには AWS WA Tool を使用することを推奨します。このツールを使用することで、質問を追跡したり、メモを取ったり、様々なマイルストーンを作成したり、質問のコンテキストを理解したり、実証済みのベストプラクティスを理解したり、ブログ、re:Invent トーク、ドキュメントなどの質問に含まれているベストプラクティスに対する追加リソースを検索したりできます。 AWS WA Tool の使用は、カスタムレンズを作成することにも役立ちます。カスタムレンズを使用することで、独自の柱、質問、ベストプラクティスを作成できます。カスタムレンズの質問は、特定のテクノロジーに合わせてカスタマイズできるため、組織内のガバナンスニーズを満たすのに役立ちます。 こちらの例をご覧ください: カスタムレンズと AWS Well-Architected Tool を使用した Well-Architected Review のカスタマイズ 組織における AWS Well-Architected カスタムレンズライフサイクルの実装 カスタムレンズライフサイクルのベストプラクティス: 計画と実装 カスタムレンズライフサイクルのベストプラクティス: 測定と改善 レビューフェーズでは、特定のベストプラクティスが実装されているかどうかを説明するために必要なメモを取ることが重要です。実装されている場合は、質問のチェックボックスにチェックを入れます。実装されていない場合は、なぜ実装されていないのかを説明するためにメモ欄にメモを取ります。「ロードマップ上にあるか？」「他の要件と競合しているか？」「単に見落とされただけか？」これらの質問への回答は、チームが後で改善計画を作成する場合に役立ち、他のレビュアーにとってもチームと所有者が変更される場合に役に立ちます。 マイルストーン は私がお勧めするもう 1 つの機能です。マイルストーンは特定の時点でのワークロードの状態を記録します。複数のセッションを実施する場合や、改善項目に取り組む場合に、マイルストーンを保存して進捗を測定できます。 7- 時間を有効活用します。 WAFR は短時間で完了し、数日ではなく数時間で終わらせるべきです。 レビュープロセスを簡潔に保つために、ベストプラクティスを検証するためのフォローアップ質問をすることと、質問のコンテキスト内に留め、技術的な深い議論に時間をかけすぎずに、バランスを保つことが重要です。 例えば、モニタリングは 6 つの柱全てにわたって取り上げられるトピックです。しかし、コンテキストは柱ごとに異なります。運用上の優秀性の柱をレビューする際のモニタリングは、可観測性についてであり、メトリクスと KPI を設定することにより、ワークロードの健全性を理解することです。セキュリティの柱では、モニタリングのコンテキストは、環境の監査、悪意のあるアクティビティの追跡、不正な動作の理解などにシフトします。 もう 1 つ注意点としては、レビュー中に技術的な議論に深入りしすぎないことです。例えば、サービスの設定の詳細を調べる場合などです。また、解決策の部分に飛び込むことも避けてください。レビュー中に正しいソリューションをその場で推奨するのに十分な時間と必要な詳細がないからです。代わりにメモを取り、 パート 3 でみていくように、改善フェーズの一環としてこのトピックをフォローアップしてください。 8- 「多分」は「違う」と捉えるようにします。 場合によっては、ベストプラクティスが実装されているかどうかチームで確信が持てないことがあります。その場合は、実装されていないベストプラクティスを考慮し、WA Tool のメモにそのことを文書化する必要があります。このようにすることで、改善フェーズの一環として、ソリューション（またはさらなる検証）をフォローアップとして含めることができます。 9- 必要に応じてスケールさせ、自動化を図ります。 大規模な組織で多数のワークロードがある場合は、ワークロードをレビューし、リスクを特定し、それらを修正するための自動化された拡張性のあるプロセスを構築することを検討してください。 ここに私の同僚が作成した、組織に WAFR を統合する方法の例がいくつかあります。組織に合わせて、これらのソリューションを調整および再利用できます。 AWS CloudFormation を使用した Well-Architected Review の作成と更新 (Lab) Well-Architected Review のカスタムレポートの構築 (Lab) : AWS Well-Architected Tool APIを使用して、AWS Well-Architected のデータを集中化されたレポーティングツールに統合する例です。 エンタープライズ全体での Well-Architected Review のスケーリング（re:Invent 2022セッション） : ワークロードのレビューとスケーラブルなアーキテクチャヘルスレポーティングの構築のための標準化された一貫したアプローチの作成例です。 Trusted Advisor および AWS Well-Architected Tool によるクラウド最適化（re:Invent 2022セッション） : このセッションでは、クラウド最適化の機会を特定するために、AWS Well-Architected Framework、AWS Well-Architected Tool、AWS Trusted Advisor を統合する方法を紹介します。 AWS Well-Architected Framework のベストプラクティスに沿った AWS 上の DevOps（re:invent 2022セッション） : 組織の DevOps プラクティスを AWS Well-Architected Framework の柱に整合させる例です。 統合された AWS Trusted Advisor インサイトを使用した Well-Architected Framework Reviews の加速（ブログ投稿） まとめ このブログ記事では、様々な業界のお客様と実施した多数の Well-Architected Framework Reviews から得た教訓の一部を紹介しました。WAFR の最終目的は、アーキテクチャのリスクを特定し、対処することです。そこに辿り着くには、まずワークロードアーキテクチャを AWS のベストプラクティスと照らし合わせてレビューする必要があります。WAFR を実施する際、いくつかの推奨事項に従い、回避すべきアンチパターンがあります。レビューは会話形式で、正直であり、文書化されており、週ではなく日単位で完了する必要があります。複数のワークロードのレビューを実施する場合は、組織のベストプラクティスに従ってプロセスを自動化およびスケールする必要があります。SA やお客様からのリソースの例をいくつか示し、その方法を紹介しました。次のステップでは、リスクを特定した後、それらに対処するための改善計画を作成する必要があります。これは パート 3 でカバーされます。 著者について Ebrahim (EB) Khiyami Ebrahim (EB) Khiyami は AWS のシニアソリューションアーキテクトです。 彼は AWS Well-Architected Framework のスペシャリストであり、移行と災害復旧に関する専門家 (Subject Matter Expert, SME) でもあります。仕事以外の時間は、サッカーをしたり、観戦したり、コーチをしたりすることがよくあります。 翻訳はソリューションアーキテクトの安藤が担当しました。原文は こちら です。

「私のワークロードは “Well-Architected” だと言えますか？私のチームはクラウドのベストプラクティスに従っていますか？他のお客様はソリューション X をどのように実装していますか？サービス Y を構成する最適な方法は何ですか？」 これらは、お客様のアーキテクチャが AWS のベストプラクティスに沿っているかどうかを検証したいというお客様から普段いただく質問の例です。その答えの内容はお客様の技術ドメインの種類によって異なりますが、一般的にお客様が従う確立された設計原則があり、これらに従うことで、システムが期待通りに機能する可能性が高まります。これらの設計原則とベストプラクティスは、 AWS Well-Architected Framework の中核をなしており、運用上の優位性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性の 6 本の柱 に渡っています。 AWS では、あらゆるものにベストプラクティスがあり、ワークロードに対して実施する Well-Architected Framework Review(WAFR) も例外ではありません。チームの経験、ワークロードの複雑さ、レビューする柱、後に取り上げるその他の要因など、複数の要因によって、WAFR は大掛かりな取り組みになる可能性があります。これらのベストプラクティスを認識していることは、チームがレビューに投資している時間がアーキテクチャのリスクを特定し、それらに対処するという期待される結果につながることを確実にするための鍵となります。この 3 部構成のブログシリーズでは、AWS がお客様と多数の WAFR を実施した際に学んだ教訓のいくつかを共有します。パート 1 では、レビューの準備方法をお話しします。 パート 2 では実施方法をカバーし、 パート 3 ではアーキテクチャのリスクを特定し、それらを修正するための計画を作成する方法をカバーしています。 WAFR とは何か テクノロジーシステムを構築することは、他の製品を構築することと変わりません。製品を業界の標準に沿って構築するためには、守るべき プラクティス (practices) と規範があります。しかし、プラクティスを整備するだけでは不十分です。チームがこれらのプラクティスを 認識 (aware) し、 準拠 (follow) していることを確認するための 仕組み (mechanism) を実装する必要があります。 AWS のベストプラクティスを 学習 (Learn) し、アーキテクチャをこれらのベストプラクティスと照らし合わせて 計測 (Measure) し、アーキテクチャのリスクを特定して、それらに対処するための 改善 (Improve) 計画を作成する 一貫したプロセス (Consistent process) が、AWS Well-Architected Framework Review(WAFR) と呼ばれるものです。 図 1 – Well-Architected Framework Review サイクル WAFR の目的は何か？なぜ必要なのか？ WAFR の最終的な目標は、システムアーキテクチャを 改善 することで、そのシステムがビジネスニーズをより適切にサポートできるようにすることです。アーキテクチャの改善プロセスは、現在のアーキテクチャをレビューし、ベストプラクティスと照らして比較することから始まります。これを実現するために、レビューの質問に回答します。各柱に対して質問のセットがあります。これらの質問は、特定のベストプラクティスがアーキテクチャに実装されているかどうかを検証します。回答に基づき、AWS Well-Architected Tool (AWS WA Tool) の支援を受けて、アーキテクチャ内で高リスク、中リスク、低リスクの領域を特定します（後ほど詳しく説明します）。次のステップは、これらのリスクの影響の高いものを特定することにより、優先順位に基づいたアプローチでリスクの解決に取り組み始めることです。その後、それらに対処するための改善計画を作成します。今回の投稿と本シリーズの次の投稿で、これらの各ステップの詳細を説明します。 WAFR のフェーズ WAFR には、準備 (Prepare), レビュー (Review), 改善 (Improve) の 3 つのフェーズがあります。以降のセクションでは、各フェーズについて詳しく説明し、そこから最大限のメリットを引き出すためのベストプラクティスを紹介します。 図 2 – Well-Architected Framework Review のフェーズ 準備 WAFR の準備は、平均して実際のレビュー日の約 3 週間前から開始されます。 これは、レビューチームの結成にかかる時間、レビューする柱の数、組織によってレビューを完了することに与えられた優先順位などの要因に左右されます。 このフェーズでは、レビューセッションに招待するチーム、レビューする作業量、レビューセッションの形式を決定します。 また、レビューの質問に答えるのに役立つアーキテクチャに関する必要なデータを収集する必要があります。 それぞれをより詳しく見ていきましょう。 1- ワークロードを定義する WAFR の準備の最初のステップは、レビューしたいワークロードを特定することです。ワークロードとは、組織にビジネス価値を提供するコンポーネント（テクノロジー、人、プロセス）の集合です。これは、リーダーがコミュニケーションするビジネスとテクノロジーのレベルです。例えば、お客様が注文およびそれを追跡できるウェブサイトと、そのバックエンドをサポートするインフラストラクチャおよびプロセスは、ワークロードです。 2- コアチーム（スポンサー）を定義する WAFR を成功させるための重要な要素は、最初から適切な人に参加してもらうことです。 レビューするワークロードを特定した後、ワークロードの所有者を特定する必要があります。時にスポンサーと呼ばれることもあります。ワークロードのスポンサーとは、そのワークロードの成功（または失敗）に最終的に責任を持つ個人（またはチーム）のことです。この人物は、レビューの結果として特定されたアーキテクチャ上のリスクに対処するための影響力と行動をとる適切な権限を持っている必要があります。例えば、チームの優先事項を変更したり、外部委託したりすることが考えられます。 各柱についてスポンサーを特定する必要があります。組織の構造や規模によっては、1 人が複数の柱を担当したり、1 つの柱を複数のチームが担当したり、あるいはその両方の場合があります。ここでの目的は、各柱についてレビューの質問に答える適任者がいることを確認し、後に対応計画の一環としてその柱で特定されたリスクに対処できるようにすることです。 レビュー対象の柱をより全体的に俯瞰するために、異なるチームから個人を招待する必要があるかもしれません。例えば、信頼性の柱をレビューする場合、データベース、ネットワーク、セキュリティ、運用の専門家 (Subject Matter Expert, SME) を含める必要があるかもしれません。運用上の優秀性の柱をレビューする場合は、エンタープライズアーキテクトやアプリケーション開発部門、ビジネス/ファイナンス部門などを含める必要があるかもしれません。 3- 柱とレンズを決定する 6 つの柱の視点からワークロードを包括的に見ることが最も理想的です。しかし、特定の柱にだけ焦点を当てる必要がある状況もあるかもしれません。例えば、セキュリティの慣行を変更した場合、ベストプラクティスとの整合性を確認したいと考えるかもしれません。この場合、セキュリティの柱のみをレビューすることを選択する可能性があります。 Well-Architected Framework に記載されている通りの柱の順序に従うことを推奨します。運用上の優秀性の柱から始めて、持続可能性の柱で終わるようにします。しかし、組織の優先事項は異なる可能性があります。このフェーズでは、レビューする柱の順序を決定する必要があります。 レビューする際に検討するもう1つの点は、 AWS Well-Architected レンズ を使用するかどうかです。このレンズは Well-Architected のガイダンスを特定の業界や技術領域に特化して拡張したものです。例えば、ワークロードが主にサーバーレスを利用している場合は、 サーバーレスアプリケーションレンズ に対してレビューする必要があるかもしれません。データ分析ワークロードを実行している場合は、レビューに データ分析レンズ を含める必要があるでしょう。このように業界や領域に応じてレンズを選択します。利用可能なレンズの一覧は こちら から確認できます。 4- セッションのタイプを決定する 選択した柱とチームの参加可能性に応じて、レビューセッションの形式を決定する必要があります。選択肢としては、6 つの柱の 1 日レビュー、または選択されたいくつかの柱について数日かけて複数のセッションを実施する方法があります。1 日レビューを実施することは通常、スケジュール設定が難しいですが、すべてのステークホルダーがベストプラクティスを議論するために集まることができるので、最も価値があります。通常、この形式は最も改善の機会を明らかにするのに役立ちます。複数のセッションは、地理的に分散したチーム、または大規模なチームがあり、同時に集まることが困難な場合の良い選択肢です。このアプローチは維持しやすいですが、異なるマイルストーンで異なるチームに更新するために、少し余分な作業が必要になる場合があります。 レビュー中のチーム間のコミュニケーションが重要です。なぜなら、質問への回答や問題の特定を集団で行うのに役立つからです。そのため、AWS WA Tool の質問にチームで回答する際は、非同期的ではなく、ライブセッションとして WAFR を実施し、回答をその場で共有することを推奨します。 5- レビューに必要なデータを収集する レビューセッションを実施する前に、レビュー対象のワークロードについての詳細な情報を収集することを推奨します。例えば、システムの主要コンポーネント、バックエンド、運用を担当する主要なプロセスとチームを説明しているアーキテクチャ図やドキュメントを確認します。 より複雑なワークロードの場合は、 AWS Trusted Advisor におけるベストプラクティスに対する 自動評価を行うチェック機能 を利用できます。これには、コスト最適化、パフォーマンス、セキュリティ、耐障害性、サービス制限が含まれます（訳注：2024 年 2 月 26 日翻訳時点で運用上の優秀性も含みます）。Trusted Advisor を有効にして、 AWS Organizations のすべてのアカウントをチェックできます。 詳細は こちら をご確認ください。そして、Trusted Advisor の推奨アクションを利用して、ベストプラクティスへの準拠状況をより深く理解し、レビューや後の対応計画の策定にこれらの詳細を取り入れることができます。 AWS Well Architected と AWS Trusted Advisor を利用したデータドリブンなコスト最適化の達成方法 の例もご参照ください。 まとめ このブログ記事では、Well-Architected Framework Review の最初のフェーズである「準備フェーズ」について詳しく取り上げました。 お客様とレビューを実施する中で学んだステップと教訓の一部をご紹介しました。 これらの推奨事項により、レビューがよりスムーズに進み、参加者の時間を最大限に活用できるようになります。 ステップには、レビュー対象のワークロードの定義、適切なコアチームとスポンサーの特定、 柱とセッションタイプの選択、そして事前に必要なデータの収集が含まれます。 これらのステップにより、レビュー日の準備が整います。 このブログシリーズの パート 2 と パート 3 で、WAFR についてさらに詳しく取り上げます。 著者について Ebrahim (EB) Khiyami Ebrahim (EB) Khiyami は AWS のシニアソリューションアーキテクトです。 彼は AWS Well-Architected Framework のスペシャリストであり、移行と災害復旧に関する専門家 (Subject Matter Expert, SME) でもあります。仕事以外の時間は、サッカーをしたり、観戦したり、コーチをしたりすることがよくあります。 翻訳はソリューションアーキテクトの安藤が担当しました。原文は こちら です。

アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクトの陳です。 テレコム業界に携わるお客様やパートナー様、5G やエッジ等の最新技術の動向にご興味のある方々を主な対象として、2024 年 1 月 31 日に「AWS re:Invent Recap インダストリー編 – テレコム業界向け」をウェビナーで開催しました。 本記事では、当日の内容・動画を皆様にご紹介します。 ウェビナー開催の背景 世界中の AWS ユーザーが集まり、ベストプラクティスや最新情報を学ぶための年次カンファレンス「AWS re:Invent」が 2023年11月ラスベガスで開催されました。本イベントでは、AWS re:Invent の 発表内容より、テレコム業界領域における最新動向、AI を駆使した事例、モバイルネットワークのクラウドアーキテクチャー、クラウドへの移行で直面する課題と解決法等の内容をお届けしました。 下記は発表内容をセッションごとのサマリとなります。 サマリは Amazon Bedrock による生成された内容をベースに加工しました。 1. テレコム業界の AWS re:Invent ハイライト 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第二ソリューション部 ソリューションアーキテクト　陳　誠 動画アーカイブリンク 資料は こちらからダウンロード 頂けます。 このセッションでは、AWS のテレコム業界向けの最新動向とお客様の事例を紹介しました。AWS はクラウドインフラ、テレコムワークロード、付加価値サービス、デベロッパープラットフォームの4つのレイヤーで通信事業者の変革を支援しています。 インフラ面では、33 のリージョンをカバーするグローバルな展開力で通信事業者を支援します。ローカルゾーンの提供によりエッジまで一貫性のある管理が実現できます。コンピューティング能力に関しては、新世代プロセッサー AWS Graviton 4 により大幅な性能向上が図れます。 付加価値サービスとして、メキシコの Smartlite 様がAR/VRソリューションを活用し、収益化に成功した事例を紹介しました。ITプラットフォームでは、Dish 様がコンタクトセンターをクラウド化した結果、エージェントの生産性が25%向上しました。 5G 関連では、ハワイの MVNO である Mobi 様が、5Gコアネットワークを1週間以内で稼働できた事例が発表されました。韓国のLGU+様では、災害対策としてのクラウド活用が進められています。 AI 活用の面では、ネットワーク運用業務の効率化が期待できます。ケーブルテレビ大手の Cox Communications 様がその好例として取り上げられていました。 AWS は通信事業者と協力し、こうした先進的な取り組みを通じて、クラウドを活用した次世代のテレコムの実現を目指しています。 2. 通信事業者のための生成系 AI の活用方法 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 ソリューションアーキテクト　菊地　貴彰 動画アーカイブリンク 資料は こちらからダウンロード 頂けます。 このセッションでは、AWS と Altman Solon 社の調査をもとに通信事業者の生成 AI の動向を紹介した後に、AWS re:Invent で発表された生成 AI の活用事例を紹介しました。Allied Market Research 社の調査によると、2026 年までに 95 % の通信事業者がデータ、分析、AI の取り組みを導入する見込みと言われています。すでに先進的な通信事業者は生成 AI を活用してビジネスに高い付加価値をもたらしていますが、世界的に見ても生成 AI の導入はまだ初期段階にあります。 生成 AI の導入初期段階で多いユースケースは、カスタマーサービスの顧客向けチャットボットです。従来のルールベースから、生成 AI ベースのチャットボットに移行し、会話の質を高めてコンタクトセンターでのやり取りを減らすなどの効果が期待されています。その次に多いユースケースは、従業員生産性向上を目指したガイド付き支援です。 生成 AI 活用における課題は、データのセキュリティやプライバシー、データガバナンスへの懸念、技術的リソース不足、生成 AI の出力の信頼性への懸念などが挙げられています。技術的リソース不足も背景にあって独自に基盤モデルを構築することよりも、既存のマネージドサービス活用を望む声が大きいことがわかっています。 AWS の生成 AI サービスとして、Amazon Bedrock が注目されています。主要な基盤モデルからニーズに合わせて選択可能であり、基盤モデルのカスタマイズもできます。検索拡張生成（RAG）や一連のタスクの自動化ができるエージェントのマネージドサービスも提供しており、生成 AI をお客様のアプリケーションに簡単に組み込めます。 生成 AI の活用事例として、Cox Communications 様のガイド付き従業員支援と Globe Telecommunications 様のパーソナライゼーションを紹介しました。生成 AI の活用により、前者はネットワーク問題の発見、診断、解決にかかる時間を大幅に短縮でき、後者は顧客体験の向上に貢献したことが確認できました。通信事業者における生成 AI は今後拡大すると見込まれるため、その動向に注視する必要があると考えられます。 3. テレコム業界におけるクラウドアーキテクチャのご紹介 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 ソリューションアーキテクト　宮崎　友貴 動画アーカイブリンク 資料は こちらからダウンロード 頂けます。 このセッションでは、通信事業者の主要な 5つのワークロード (ビジネスソリューション、カスタマーエクスペリエンス、OSS/BSS、5Gコア/IMS、5G RAN) について、それぞれの現在の課題と AWS クラウド上での参考アーキテクチャーを紹介しました。 具体的には、TMフォーラムの ODA に準拠した AWS 独自のクラウドネイティブなビジネスソリューションフレームワーク、コネクテッドカスタマージャーニーと 生成 AI によるカスタマーエクスペリエンスの向上、コスト最適化と低レイテンシーを考慮した OSS/BSS のモダナイゼーション、AWS Local Zones や AWS Outposts を活用した 5Gコア/IMS のリファレンスアーキテクチャ、数千拠点に展開可能な Amazon EKS Anywhere や AWS Outposts を使用した O-RAN リファレンスアーキテクチャー等について解説がありました。 事例として、Smart Home を提供している TELUS 様の例が紹介され、デバイス、ネットワーク、AWSサービス、CSPサービス、アプリケーションからなる層構造の論理アーキテクチャが説明されました。また、Liberty Latin America 様は、複数の国やデータセンターにまたがるモノリシックなプラットフォームを統合し、アジャイルな方法で最新のアプリケーションを短期間で導入できるようになったBSSのマイグレーション実績が紹介されました。さらに、Telefónica Germany 様による 5G コアを AWS上で実装され、優れたネットワーク品質とカスタマーエクスペリエンスの向上につなげられた事例が紹介されました。 4. 通信事業者における大規模ワークロード移行のクラウドジャーニー 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 ソリューションアーキテクト　加藤　知愛 動画アーカイブリンク 資料は こちらからダウンロード 頂けます。 このセッションでは、LG U+ 様のクラウド移行の事例を紹介しました。LG U+ 様は韓国 3 位のキャリアで、2007 年から LG エレクトロニクスのセットトップボックスを使った VOD サービスを開始しました。現在のこのサービスの加入者数は 500 万人規模です。15 年以上サービス提供しており、チャンネル数が増え、日々 1.3 億のデータが更新されるなど、バックエンドが複雑化していました。 硬直化したアーキテクチャからくるサービス品質低下を解消するため、AWS へのクラウドマイグレーションを決定しました。1 年の準備期間で、アプリケーションのマイクロサービス化、CI/CD パイプライン構築、IaC（Infrastructure as Code）導入などを行いました。マイグレーションでは、サービスを無停止で移行する方針を打ち出し、AWS Database Migration Service (AWS DMS) を使ったデータベースの移行、API の Strangler パターンの採用、マイクロサービス化を段階的に実施しました。 マイクロサービス化では 78% の API をモダナイズしました。コンテナ基盤の Amazon Elastic Kubernetes Service (Amazon EKS) 上でマイクロサービスを展開し、データベースも Amazon Aurora に移行しました。CI/CD パイプラインと IaC により、ソフトウェアのリリースのスピードが向上しました。また、Amazon Aurora のスケーラビリティにより、負荷増時の対応力が向上しました。 準備に 1 年、移行に 1 年の計 2 年で、サービスを止めることなくマイグレーションを完了しています。自社主導の着実な準備と段階的な移行が成功の鍵でした。AWS によりビジネスの成長と継続的なプラットフォーム革新が可能になりました。 クラウドマイグレーションには長期的視点が重要です。丁寧な準備と段階的な移行で既存サービスを維持しながら、マイクロサービス化と CI/CD 等のアジャイル手法を取り入れ、サービス品質とスピードを両立させることができました。大規模システムの移行には時間がかかりますが、LG U+ 様の事例はその道筋を示しています。 まとめ 2024 年 1 月 31 日に開催した「AWS re:Invent Recap インダストリー編 – テレコム業界向け」の振り返りとして、開催概要や発表の見どころ紹介、お客様事例をご紹介いたしました。セミナーにご参加いただいた方、誠にありがとうございました。参加頂けなかった方も、このブログから動画や資料を参照いただき、今後の AWS 活用の参考になりましたら幸いです。内容に関して、ご質問やご要望がございましたら、お問い合わせページ、もしくは担当営業までご連絡をお願いします。 このブログの著者 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第二ソリューション部 陳　誠 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 菊地　貴彰 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 宮崎　友貴 技術統括本部 ストラテジックインダストリー技術本部 通信グループ 通信第一ソリューション部 加藤　知愛

この記事は Secure Amazon Elastic Container Service workloads with Amazon ECS Service Connect (記事公開日 : 2024 年 1 月 30 日) の翻訳です。 導入 先日発表されたアップデート によって、 Amazon Elastic Container Service (Amazon ECS) は AWS Private Certificate Authority (Private CA) と統合し、証明書の発行や配布、ローテーションのプロセスを自動化できるようになりました。 Amazon ECS Service Connect をご利用のお客様は、アプリケーションコードを変更することなく、また余分なネットワークインフラストラクチャやサービスメッシュソリューションを運用することなく、サービス間通信を TLS で暗号化できます。 既存の Service Connect 名前空間において、Service Connect を使用するサービス単位でトラフィックを暗号化できます。まず、使用する Private CA を AWS マネジメントコンソール 上で選択するか、あるいは Private CA の ARN を AWS CLI で指定します。このとき、既存の、あるいは新規に作成した Private CA を利用できます。この CA は証明書に署名する際に使用され、信頼のルートとしても使用されます。デフォルトでは、Amazon ECS は AWS 管理の対称暗号鍵 (共通鍵) を使用して、秘密鍵をお客様の AWS Secrets Manager に保管します。このとき、コンプライアンス上の理由などにより、独自の共通鍵を提供することもできます。 ソリューション概要 それでは、TLS 証明書を使用してトラフィックを暗号化することで、Amazon ECS Service Connect を使用している既存の Amazon ECS ワークロードを保護する方法を確認しましょう。 まず、証明書と暗号鍵をどのように管理するか、決める必要があります。 推奨される方法は、AWS Private CA の有効期限の短い証明書モードを使用することです。Service Connect が発行する証明書の有効期限はデフォルトで 7 日間であり、5 日ごとにローテーションされます。AWS Private CA の有効期限の短い証明書モードを使用すると、汎用モードを使用した場合に比べて大幅なコスト削減を実現できます。また、Service Connect は証明書の失効をサポートしておらず、代わりに有効期限の短い証明書を利用して頻繁に証明書をローテーションするため、このモードはほとんどのユースケースにおいて効果的に機能します。Amazon ECS は 7 日間の有効期限を持つ証明書を発行し、5 日ごとに自動ローテーションを実施するため、有効期限やローテーションの頻度を設定する必要もありません。 別の選択肢として、既存の下位 CA を使用するか、オンプレミスの CA を使用して AWS Private CA に新しい下位 CA を作成、設定する こともできます。また、独自のキーマテリアルを提供することも可能で、 AWS Key Management Service (AWS KMS) を通じて外部のキーストアを使用することもできます。独自のキーを使用する場合は、AWS KMS にインポートした後、Amazon ECS Service Connect でそのキーの ARN を指定します。 証明書と暗号鍵の管理方法を決定すれば、Service Connect で TLS を有効化するのは簡単です。ここではシンプルさと一貫性のために、Amazon ECS Service Connect が re:Invent 2022 で発表された際に Channy Yun が書いた人気記事 ( Secure Amazon Elastic Container Service workloads with Amazon ECS Service Connect ) をベースにお話しします。 ウォークスルー 1. トラフィックを暗号化したいサービスにおいて、Service Connect 名前空間を選択します。この例では、クラスター作成時に service-connect という名前の名前空間を作成しているので、これを選択し、保護したいサービスを配置します。 2. 次に、トラフィックを暗号化したいサービスの Service Connect 設定において、「トラフィックの暗号化を有効にする」にチェックを入れます。 3. Service Connect の TLS ロールでは、既存のロールを選択するか、新しいロールを作成します。Amazon ECS は、証明書の発行に必要な一連の権限の大枠を定義した、マネージド型の IAM ポリシーを提供します。この新しいポリシーの詳細については、 Amazon ECS の AWS マネージドポリシーに関するドキュメント を参照してください。 4. Signer CA (署名者認証機関) では、既存の CA を使用するか、新しい CA を作成します。 5. AWS KMS キーの選択では、AWS が所有・管理するキーを選択するか、別のキーを選択できます。必要に応じて、この画面から新しくキーを作成することもできます。 6. 別の方法として、 AWS CLI から直接 TLS 暗号化を有効化できます。このとき必要なのは、証明書の ARN (awsPcaAuthorityArn)、KMS キー (kmsKey)、 AWS IAM ロールの ARN (roleArn) を JSON ペイロードに追加することだけです。 前提条件 トラフィックを TLS 暗号化するための唯一の前提条件は、サービス間通信に Service Connect を使用していることです。他の接続方法を使用しているサービスでは、上記の方法で TLS 暗号化することはできません。 まとめ この記事では、Service Connect を使用している既存の Amazon ECS サービスを TLS 暗号化により保護する方法を紹介しました。コンプライアンスや規制上の理由から追加の暗号化レイヤーを必要とするお客様にとって、Amazon ECS Service Connect における TLS 暗号化サポートは重要なアップデートです。一部のお客様は、アプリケーションコードに変更を加えることなく、プロキシレベルでトラフィックを暗号化する AWS App Mesh のようなサービスメッシュを好みます。あるいは、アプリケーションコード内に直接 TLS を実装するお客様もいます。サービスメッシュは、通常ツールや技術者への多大な投資を必要とするため、お客様のアプリケーションの総所有コスト (TCO) が増加します。一方で TLS を直接実装するのは、手作業による証明書の発行、配布、ローテーションが複雑になり、開発スピードが損なわれてしまいます。また、Elastic Load Balancing (ELB) を使用すると、サービス間通信のためのインフラストラクチャの複雑さが増加します。Amazon ECS Service Connect の TLS 暗号化サポートの詳細については、 ドキュメント を確認し、 今回のリリース記事 をお読みください。 Amazon ECS Service Connect は、Amazon ECS および AWS Private CA が利用可能なすべての AWS リージョンで利用可能です。また、 AWS CloudFormation 、 AWS CDK 、 AWS Copilot 、および AWS Proton で完全にサポートされており、これらを用いたインフラストラクチャのプロビジョニング、コードデプロイ、サービス監視を実現できます。詳細については、 Amazon ECS Service Connect 開発者ガイド を参照してください。 ぜひ一度試してみてください。フィードバックも受け付けてますので、 AWS re:Post (Amazon ECS) や AWS サポート窓口までお願いします。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 先週は、暖かくなったと思ったら週末にかけ気温が下がりましたね。みなさんも体調にお気をつけていただければと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。 2/19（月）はアメリカは祝日だったため、週の前半はWhat’s newが少なく、後半に増えてくる形になります。 2024年2月19日週の主要なアップデート 2/19(月) Amazon RDS for SQL Server reduces prices on R5 and R6i Standard Edition in Asia Pacific (Osaka) 大阪リージョンのAmazon RDS for SQL Server (スタンダードエディション)を20%値下げしました。対象はR5、R6iインスタンスのオンデマンドDBインスタンス、リザーブドDBインスタンスです。この値下げは2024年2月1日以降の利用分に適用されます。また、2024年1月31日より後に購入のリザーブドDBインスタンスの価格も更新されます。 Amazon DocumentDB now supports vector search with HNSW index Amazon DocumentDB (MongoDB 互換)がHNSWインデックスによるベクトル検索をサポートしました。ベクトルは非構造化データを数値で表現したもので、機械学習モデルから検索することで、意味の把握に利用されるものです。これまでサポートされていたフラット圧縮 (IVFFlat ) インデックス以外の選択肢が追加された形です。詳細は ドキュメント もご確認ください。 2/20(火) AWS Amplify Hosting announces support for custom SSL certificates/TLS AWS Amplify Hostingで、カスタムドメインのカスタムSSL証明書がサポートされました。東京リージョンを含む19のリージョンでご利用いただけます。 2/21(水) Amazon Location Service Maps SDK now supports Metal-based rendering for iOS applications Amazon Location ServiceのMaps SDKがiOSデバイスでサポートされるコンピュータグラフィックスAPIのMetalによるレンダリングをサポートしました。これによりiOSユーザーにスムーズなマップ体験を提供できるようになります。このサポートはMapLibreオープンソースコミュニティとの協力で実現されているので、MapLibreの リリースノート もご確認ください。 AWS Incident Detection and Response now offers five minute response time for critical incidents AWS Incident Detection and Responseの重大なインシデントへの対応が5分以内に短縮されました。AWS Incident Detection and ResponseはAWS Enterprise Supportに加入するお客様の重要なワークロードにプロアクティブな対応を提供するサービスです。これまで重大なインシデントには15分以内の対応をしていましたが、今回1/3の時間になりました。 Amazon DocumentDB (with MongoDB compatibility) now supports Partial Indexes Amazon DocumentDB (MongoDB 互換)がPartial Indexes(部分インデックス)をサポートしました。部分インデックスは特定のフィルター条件を満たすドキュメントのサブセットにインデックスを作成するので必要なストレージが少なく、メモリやストレージ効率よくクエリ実行時間を短縮することができます。詳細は ドキュメント もご確認ください。 2/22(木) AWS announces Amazon Neptune I/O-Optimized Amazon Neptune I/O-Optimizedの一般提供が発表されました。これまでAmazon Neptune (Standard) ではI/O操作に応じた課金が発生しましたがNeptune I/O Optimizedはデータベースインスタンスとストレージの使用量に対しての料金は上がりますがI/O料金が内包されます。これによりI/O料金がNeptuneデータベースの総額の25%を超えるI/O負荷の高いアプリケーションにおいては最大40%のコスト削減を実現できます。詳細については 料金ページ もご確認ください。 Amazon Neptune announces support for data APIs in the AWS SDK Amazon Neptuneがdata APIをサポートしました。 クライアントや curlなどのコマンドを使用せずに、AWS SDKを使用してNeptuneの40以上のデータプレーンAPIにアクセスすることが可能です。詳細は ドキュメント をご確認ください。 Amazon RDS for PostgreSQL supports minor versions 16.2, 15.6, 14.11, 13.14, and 12.18 Amazon Relational Database Service (RDS) for PostgreSQLがPostgreSQL 16.2、15.6、14.11、13.14、12.18 の最新マイナーバージョンをサポートするようになりました。このマイナーバージョンにはセキュリティ対応やバグ修正、パフォーマンス向上等のアップデートが含まれています。 AWS Systems Manager Parameter Store now supports cross-account sharing AWS Systems Managerの機能として設定データを安全に保管できるParameter Storeが、アドバンストパラメータ階層を他のアカウントと共有できるようになりました。これまでは設定データを共有する際は複製し同期する必要がありました。今回のアップデートにより単一の情報源を参照できるため、その手間や同期漏れなどのリスクをなくすことができます。詳細は ドキュメント もご確認ください。 2/23(金) Amazon CloudFront announces availability of Embedded Points of Presence Amazon CloudFrontのEmbedded PoPについて改めて紹介しています。Embedded PoPはインターネットサービスプロバイダーやモバイルネットワーク事業者のネットワーク内で、ISPエンドビューワーに最も近い場所にデプロイされる新しいタイプのCloudFrontのインフラストラクチャです。ISP/MNOが申請できるこのインフラストラクチャは現在、CloudFrontは世界200以上の都市に600以上を導入しています。Embedded PoPについての解説がCloudFrontの よくある質問 （執筆時点：2024/2/25 で英語のみ）に記載されたのでそちらもご確認ください。 Amazon Connect now provides time zone support for agent shift profiles Amazon Connectのシフトプロファイルがタイムゾーン設定をサポートしました。これによりUTCを元にシフト時間を考える必要がなくなります。 Amazon MWAA now supports Apache Airflow version 2.8 Amazon Managed Workflows for Apache Airflow (MWAA)でApache Airflow version 2.8がサポートされました。Airflow version 2.8の詳細は リリースノート をご確認ください。 Amazon DocumentDB (with MongoDB compatibility) Elastic Clusters supports readable secondaries, and start and stop clusters Amazon DocumentDB (MongoDB 互換) Elastic Clustersが読み取り可能なセカンダリ、シャードインスタンス数の設定、クラスターの開始と停止がサポートしました。読み取りのワークロードでの効率的なリソース使用と開始・停止によるコスト最適化が可能です。停止は最大7日間となります。詳細は ドキュメント もご確認ください。 Amazon DocumentDB (with MongoDB compatibility) Elastic Clusters now support automatic backups and snapshot copying Amazon DocumentDB (MongoDB 互換) Elastic Clustersが自動バックアップとスナップショットのコピーをサポートしました。自動バックアップは1~35日の保持が可能です。また、バックアップは手動のものも含め同じアカウントの同じリージョン内でコピーが可能なので、バックアップからの新しいクラスターのリストアも容易です。 What’s newは執筆時点で出ていないようですが、Amazon BedrockでのAnthropic Claude Instantの価格がこれまでUSリージョンとそれ以外で違いましたが、USリージョンと同じ価格に統一されたようです。USリージョン以外は値下げになりますので、ご活用頂きやすくなります。詳細は 料金ページ をご確認ください。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

AWS AppSync が、 Data API で構成された Amazon Aurora クラスタ上で稼働している既存の MySQL や PostgreSQL データベースのテーブルに基づいて、GraphQL API を簡単に作成できるようになりました。既存のデータベース用の API を構築する場合、開発者は通常、テーブルを正確に表現するインターフェースを構築しなければなりませんが、これには時間がかかり、エラーが発生しやすいプロセスです。AppSync は、データベースを検出し、それに一致する GraphQL 型を生成できる新しいイントロスペクション機能によってこの問題を解決します。AppSync コンソールでは、この新機能を使用して、コードを記述することなく、わずか数ステップでデータベースからすぐに使用できる GraphQL API を生成できます。さらに、Amazon Relational Database Service (RDS) 用の JavaScript リゾルバにも改良が加えられており、新しい SQL タグ付きテンプレートと SQL ヘルパー関数により、リゾルバで SQL ステートメントを簡単に記述できるようになっています。 本記事では、API を即座に構築するために AWS コンソールでこの機能を使い始める方法を紹介し、JavaScript リゾルバで新しい RDS ユーティリティライブラリを使用する方法を紹介します。 注：このブログの機能は、RDS Data API をサポートする Amazon RDSデータベースを使用しています。Data API をサポートしていない MySQLや PostgreSQL データベースに接続するには、「 既存の MySQL と PostgreSQL データベース用の GraphQL API の作成 」を参照してください。 AppSync コンソールでの設定 AppSync の新しいイントロスペクション機能は、Data API で構成された Amazon Aurora クラスターで実行されている既存のデータベースで使用できます。例えば、以下のテーブルが定義された MySQL データベースがあり、API を提供したいとします。 CREATE TABLE conversations ( id INT NOT NULL PRIMARY KEY, name VARCHAR(255) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE messages ( id VARCHAR(36) PRIMARY KEY, conversation_id INT NOT NULL, sub VARCHAR(36) NOT NULL, body TEXT NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (conversation_id) REFERENCES conversations(id) ); CREATE TABLE conversation_participants ( conversation_id INT NOT NULL, sub varchar(36) NOT NULL, last_read_at DATETIME, PRIMARY KEY (conversation_id, sub), FOREIGN KEY (conversation_id) REFERENCES conversations(id) ); AWS AppSync コンソールで、 Create API をクリックし、GraphQL API で Start with an Amazon Aurora cluster を選択します。 Next をクリックし、API に名前を付け、次の画面でデータベース情報を入力してイントロスペクションを開始します。 Aurora クラスタに Data API を設定し、データベースユーザーの認証情報を AWS Secrets Manager に保存しておく必要があります。このユーザーには、データベース、スキーマ、テーブルの設定を読み取る権限が必要です。設定の詳細については、 Data API ドキュメント を参照してください。Secrets Manager のシークレットに対して GetSecretValue 、クラスタに対して ExecuteStatement を実行する権限が必要です。また、自分のリソースでアクセスするために AppSync の権限を付与する必要があります。コンソールでロールを作成することもできますし、自分で用意することもできます。 Import をクリックして、イントロスペクション処理を開始します。完了すると、検出されたテーブルは以下のように表示されます。 デフォルトでは、型名はテーブル名と同じですが、カスタマイズすることもできます。生成されるスキーマからテーブルを除外することもできます。以下のように型名を変更してください。 Conversation_Participants → Participant Conversations → Conversation Messages → Message Next をクリックし、 Create queries, mutations, and subscriptions for all models を選択します。 Next をクリックし、変更内容を確認して、 Create API をクリックします。スキーマの作成を開始し、リゾルバをフィールドにアタッチします。これで、クエリエディタからデータベースとやり取りしたり、GraphQL API に接続するクライアントアプリケーションを構築したりできるようになります。API を使用するには、クエリエディタに向かいます。左側のメニューから Queries を選択します。まずは新しい会話 (Conversation) を作成しましょう。 mutation CreateConvo { createConversation(input: {id: 1, name: "stand up meeting"}) { created_at id name } } これでデータベースに会話が追加されます。次にメッセージを追加しましょう。 mutation CreateMsg { createMessage(input: {body: "Hello world! Things are looking good.", conversation_id: 1, id: "new-message", sub: "johndoe"}) { body conversation_id created_at id sub } } AppSync のリアルタイム機能はすぐに使用できます。例えば、会話で新しいメッセージを聞くには、新しいタブまたはウィンドウでクエリエディタを開き、フォローサブスクリプションを入力します。 subscription OnCreate { onCreateMessage(conversation_id: 1) { body conversation_id created_at id sub } } 元の Queries タブで、別のメッセージを送信します。 mutation CreateMsg { createMessage(input: {body: "Hello again. Nothing to report", conversation_id: 1, id: "2nd-message", sub: "johndoe"}) { body conversation_id created_at id sub } } 2 つめのクエリエディタにサブスクリプションがトリガーされたことが表示されます。 自動生成されたリゾルバを編集し、必要に応じてカスタマイズすることができます。例えば、新しいメッセージが作成されるたびに API が ID を自動生成するように変更してみます。 createMessage リゾルバを以下のように更新します。 import { util } from '@aws-appsync/utils'; import { insert, select, createMySQLStatement, toJsonObject } from '@aws-appsync/utils/rds'; export function request(ctx) { const { input: values } = ctx.args; values.id = util.autoUlid() // <<< set the ULID const doInsert = insert({ table: 'messages', values }); const doSelect = select({ table: 'messages', columns: '*', where: { id: { eq: values.id } }, limit: 1, }); return createMySQLStatement(doInsert, doSelect); } export function response(ctx) { const { error, result } = ctx; if (error) { return util.appendError(error.message, error.type, result); } return toJsonObject(result)[1][0]; } 上のコードでは、2 つのリクエストをデータベースに送っています。1 つめは、指定された ULID (Universally Unique Lexicographically Sortable Identifier) で新しいメッセージを作成します。2 つめは挿入された行をフェッチしてデータベースからデータを返します。これは、MySQL を使用して作成されたばかりの行 (自動生成されたカラムと値を含む) を取得するときに便利なパターンです。レスポンスから 2つめのオブジェクト (インデックス1) を取得します。これは、私が送信した 2 つめのステートメント ( doSelect ) の結果に対応します。 次に、スキーマの CreateMessageInput Input を更新して、 id フィールドを削除します。 input CreateMessageInput { # id: String! # << comment out or remove conversation_id: Int! sub: String! body: String! created_at: String } 新しいメッセージを送信します。 query ListMsgs { listMessages(filter: {conversation_id: {eq: 1}, created_at: {ge: "2023-11-13", lt: "2023-11-13 22:23"}, sub: {ne: "john"}}) { items { id created_at body sub } } } 生成されたIDでレスポンスが返ってきます。 { "data": { "createMessage": { "body": "up and up", "conversation_id": 1, "created_at": "2023-11-13 23:24:06", "id": "01HF5FZNM3M9PEYC1234567890", "sub": "john" } } } いくつかのメッセージを追加したところで、会話メッセージをすべて選択してみましょう。例えば、ここでは created_at タイムスタンプと sub 値でフィルタリングしています。 query ListMsgs { listMessages(filter: {conversation_id: {eq: 1}, created_at: {ge: "2023-11-13", lt: "2023-11-13 22:23"}, sub: {ne: "john"}}) { items { id created_at body sub } } } RDS の新しいユーティリティ関数の使用 RDS の新しいユーティリティを使用して、データベーステーブルを操作することができます。 Conversation 型を変更して、 participants フィールドを追加してみましょう。このフィールドは、最近読まれたメッセージ ( last_read_at ) に基づいて、最近アクティブになった会話参加者の ID を返します。 type Conversation { id: Int! name: String! created_at: String participants: [String] } 次に、 @aws-appsync/utils/rds が提供する select ユーティリティ関数を使ってカスタム select 文を書くために、 getConversation リゾルバを更新します。 import { util } from '@aws-appsync/utils'; import { select, createMySQLStatement, toJsonObject, } from '@aws-appsync/utils/rds'; export function request(ctx) { const { id } = ctx.args; const doSelect = select({ table: 'conversations', columns: '*', where: { id: { eq: id } };, limit: 1, }); const doGetLatest = select({ table: 'conversation_participants', columns: ['sub'], where: { conversation_id: { eq: id } }, orderBy: [{ column: 'last_read_at', dir: 'DESC' }], limit: 10, }); return createMySQLStatement(doSelect, doGetLatest); } export function response(ctx) { const { error, result } = ctx; if (error) { return util.appendError(error.message, error.type, result); } const res = toJsonObject(result); const convo = res[0][0]; if (convo) { convo.participants = (res[1] ?? []).map((p) => p.sub); } return convo; } リゾルバでは、最大 2 つのステートメントをデータベースに送信することができるので、1 回の実行で会話 (Conversation) とその参加者を取得することができます。 createMySQLStatement 関数は、MySQL ステートメントを適切にエスケープし、引用符で囲むリクエストを作成します。変更してみましょう。クエリエディタでクエリを実行します。 query get { getConversation(id: 1) { id participants } } 以下の結果が返ってきます。 { "data": { "getConversation": { "id": 1, "participants": [ "John", "Sarah" ] } } } カスタム SQL 文の作成 新しい SQL タグ付きテンプレート を使って独自の SQL 文を書くことができます。タグ付きテンプレートを使うと、テンプレート式を通して実行時に動的な値を受け入れる静的な SQL 文を書くことができます。会話要約クエリをスキーマに追加し、新しい Summary 型を追加してみましょう。 type Query { getConversationSummary(id: Int!, since: AWSDate!): Summary } type Summary { id: Int! total_messages: Int total_words: Int total_participants: Int } 次に、 getConversationSummary にリゾルバをアタッチします。 import { sql, createMySQLStatement, toJsonObject, typeHint, } from '@aws-appsync/utils/rds'; export function request(ctx) { const query = sql` SELECT c.id AS id, COUNT(DISTINCT m.id) AS total_messages, COUNT(DISTINCT cp.sub) AS total_participants, SUM(LENGTH(m.body) - LENGTH(REPLACE(m.body, ' ', '')) + 1) AS total_words FROM conversations c LEFT JOIN messages m ON c.id = m.conversation_id LEFT JOIN conversation_participants cp ON c.id = cp.conversation_id WHERE c.id = ${ctx.args.id} AND m.created_at >= ${typeHint.DATE(ctx.args.since)} GROUP BY c.id, c.name; `; return createMySQLStatement(query); } export function response(ctx) { return toJsonObject(ctx.result)[0][0]; } ここでは、 sql タグ付きテンプレートを使って SQL 文を書いています。SQL タグ付きテンプレートを使うと、式によって動的な値のみを受け付ける静的なステートメントを書くことができます。式を通して渡された値は、プレースホルダを通して自動的にデータベースエンジンに送られます。また、 since 引数がデータベースエンジンによって DATE 型として扱われることを示すために、 型ヒント を使用しています。 変更を保存し、クエリを実行します。 query get { getConversationSummary(id: 1, since: "2023-01-01") { id total_messages total_participants total_words } } 以下の結果が返ってきます。 { "data": { "getConversationSummary": { "id": 1, "total_messages": 9, "total_participants": 2, "total_words": 66 } } } まとめ Aurora クラスターで稼働している既存の MySQL データベースから AppSync GraphQL API を作成する手順を紹介しました。この記事では MySQL に焦点を当てましたが、PostgreSQL データベースでも同じことができます。ご自身のデータベースで始めるには、 AppSync ドキュメント で Data API による RDS イントロスペクションの詳細をご覧ください。RDS 用の JavaScript リゾルバの新しいユーティリティの詳細については、 JavaScript リゾルバのリファレンス を参照してください。ガイド付きの導入については、 Aurora PostgreSQL with Data API のチュートリアル を参照してください。独自の JavaScript リゾルバを書き始めるには、 @aws-appsync/utils パッケージの最新版をダウンロードまたは更新してください。 本記事は「 Build a GraphQL API for your Amazon Aurora MySQL database using AWS AppSync and the RDS Data API 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

開発者はしばしば、 AWS Amplify Hosting にデプロイされた Next.js アプリケーションから、 Amazon Virtual Private Cloud (Amazon VPC) 内にデプロイされたリソースにアクセスする必要があります。 Amazon VPC を使用すると、お客様は隔離された仮想ネットワークでリソースを起動できます。しかし、開発者は、複雑なネットワークアクセス制御とセキュリティグループのために、Amazon VPC 内で API とデータベースを呼び出すためにフロントエンドアプリケーションを接続することが困難であると感じるかもしれません。 この投稿では、AWS Amplify Hosting 上で動作する Next.js サーバーサイドレンダリング (SSR) アプリケーションから、 Amazon Relational Database Service (Amazon RDS) や AWS Lambda などのリソースや VPC 内のリソースにアクセスするためのソリューションを実装します。 ソリューションの概要 まず、 AWS Cloud Development Kit (AWS CDK) を使って、Amazon VPC 内に Lambda 関数をビルドしてデプロイします。 次に、Pages Router を使用した Next.js API Routes を通じて Amazon VPC 内のデータにアクセスする Next.js アプリを作成し、AWS Amplify Hosting 上でホストされた React UI にアクセスします。 AWS Systems Manager Parameter Store を利用した API キーやその他の設定データのデモを行います。 その結果、エンドユーザーが Amazon VPC 内からデータを表示するためにアクセスできる Next.js アプリが作成されます。 前提条件 このチュートリアルでは以下のものが必要です。 AWS アカウント NPM でインストールされた Node.js VPC スタックでの Lambda 関数の作成 Next.js アプリケーションがアクセスできる保護された Amazon VPC リソースを説明するために、Lambda 関数が動作する Amazon VPC を作成します。 まず、AWS CDK をインストールします。前提条件の詳細は AWS CDK の開始方法 を参照してください。 $ npm install -g aws-cdk 次に、アプリ用の新しいディレクトリを作成します。 $ mkdir lambda-in-a-vpc $cd lambda-in-a-vpc 次に、以下のコマンドを実行して AWS CDK アプリケーションを作成します。 $ cdk init app —language=typescript 生成したら、 lib/lambda-in-a-vpc-stack.ts の内容を以下のコードに置き換えます。 AWS CDK Stack は、パブリック、プライベート、隔離されたサブネットを持つ Amazon VPC、セキュリティグループ、Amazon VPC の隔離されたサブネットに配置される Lambda 関数 (Node.js) を作成します。 Lambda 関数をセキュリティグループ付きのプライベートサブネットに配置することで、Amazon VPC 内で関数を分離します。 これにより、パブリックインターネットから分離された Lambda 関数のセキュアなネットワーク環境が提供されますが、プライベートサブネット内のデータベースのような Amazon VPC 内のリソースにアクセスすることができます。 // lib/lambda-in-a-vpc-stack.ts import { CfnOutput, Duration, Stack, StackProps, aws_ec2 as ec2, aws_lambda as lambda, } from "aws-cdk-lib"; import { NodejsFunction } from "aws-cdk-lib/aws-lambda-nodejs"; import { Construct } from "constructs"; import path = require("path"); export class LambdaInAVpcStack extends Stack { constructor(scope: Construct, id: string, props?: StackProps) { super(scope, id, props); const vpc = new ec2.Vpc(this, "LambdaVpc", { subnetConfiguration: [ { name: "Isolated", subnetType: ec2.SubnetType.PRIVATE_ISOLATED, }, { name: "Private", subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS, }, { name: "Public", subnetType: ec2.SubnetType.PUBLIC, }, ], }); // Create a security group to be used on the lambda functions const lambdaSecurityGroup = new ec2.SecurityGroup( this, "Lambda Security Group", { vpc, } ); const getDataLambda: NodejsFunction = new NodejsFunction( this, id + "-getDataLambda", { memorySize: 1024, timeout: Duration.seconds(5), runtime: lambda.Runtime.NODEJS_18_X, handler: "handler", entry: path.join(__dirname, "../lambda/getData.ts"), vpc: vpc, vpcSubnets: { subnetType: ec2.SubnetType.PRIVATE_ISOLATED }, securityGroups: [lambdaSecurityGroup], } ); new CfnOutput(this, "getDataLambdaArn", { value: getDataLambda.functionArn, exportName: "getDataLambdaArn", }); } } Lambda 関数 (Node.js) の内部では、Amazon RDS インスタンスような Amazon VPC 内のリソースや、Amazon S3 バケット、その他の保護されたリソース、または外部のサードパーティ API など任意のリソースからデータを取得することができます。 次に、 lambda ディレクトリを作成し、その下に getData.ts を作成します。 説明のためにデータはハードコードされていますが、この Lambda 関数は Amazon RDS やその他のデータソースから地理データを取得し、それを返す前に検証や変換を行うことができます。 // lambda/getData.ts import { APIGatewayProxyResultV2 } from "aws-lambda"; const geoData = [ { name: "United States", states: [ "Alabama", "Alaska", "Arizona", //... ], }, { name: "Canada", states: [ "Alberta", "British Columbia", "Manitoba", // ... ], }, { name: "Mexico", states: [ "Jalisco", "Mexico City", "Oaxaca", // ... ], }, ]; exports.handler = async function (): Promise<APIGatewayProxyResultV2> { try { return { statusCode: 200, headers: { "Content-Type": "application/json" }, body: JSON.stringify(geoData, null, 2), }; } catch (error) { console.error("Unable to return data:", error); return { statusCode: 500, headers: { "Content-Type": "application/json" }, body: JSON.stringify(error), }; } }; cdk deploy を実行して AWS CDK スタックをデプロイし、次のセクションで Next.js アプリケーションで使用するために返されるアウトプットをメモします。 $ cdk deploy [+] Building 92.4s (14/14) FINISHED 8.4s WARNING: The requested image's platform (linux/amd64) does not match the detected host platform (linux/arm64/v8) and no specific platform was requested asset-output/index.js 831b ⚡ Done in 102ms ✨ Synthesis time: 97.21s LambdaInAVpcStack: deploying... [1/1] LambdaInAVpcStack: creating CloudFormation changeset... ✅ LambdaInAVpcStack ✨ Deployment time: 33.99s Outputs: LambdaInAVpcStack.getDataLambdaArn = arn:aws:lambda:us-east-1:074128318641:function:LambdaInAVpcStack-LambdaInAVpcStackgetDataLambda1E-33sG563OFj2H Stack ARN: arn:aws:cloudformation:us-east-1:074128318641:stack/LambdaInAVpcStack/1fbc2790-2a57-11ee-9757-0ecf5ea19ac5 ✨ Total time: 131.2s LambdaInAVpcStack.getDataLambdaArn の末尾にある Lambda 関数名 (この場合は LambdaInAVpcStack-LambdaInAVpcStackgetDataLambda1E-33sG563OFj2H ) に注意してください。 Next.js Amplify アプリの作成 次に、Pages Router を使って Next.js アプリケーションを作成します。 $ npx create-next-app@latest geo-web-app ✔ Would you like to use TypeScript? … No / `_Yes_` ✔ Would you like to use ESLint? … `_No_` / Yes ✔ Would you like to use Tailwind CSS? … No / `_Yes_` ✔ Would you like to use `src/` directory? … No / `_Yes_` ✔ Would you like to use App Router? (recommended) … `_No_` / Yes ✔ Would you like to customize the default import alias (@/*)? … `_No_` / Yes` AWS Amplify JavaScript、AWS Amplify UI ライブラリをインストールします。 これらの依存関係はオプションですが、本記事では Next.js アプリケーションの UI を構築するために使用します。 $ npm i aws-amplify @aws-amplify/ui-react 以下のインポートで pages/_app.tsx を更新して、 Amplify UI のスタイルを設定します。 // Import Amplify UI styles import "@aws-amplify/ui-react/styles.css"; import type { AppProps } from "next/app"; export default function App({ Component, pageProps }: AppProps) { return <Component {...pageProps} />; } 更新を Git にコミットし、Git プロバイダにプッシュします。 Next.js アプリの Amplify へのデプロイ アプリを Git プロバイダにプッシュしたら、Amplify Hosting にデプロイする準備ができました。 まず Amplify コンソール にアクセスしてください。Amplify アプリを作成したことがない場合は、ページを一番下までスクロールし、 Amplify Hosting > Host your web app > Get started を選択します。アプリを作成したことがある場合は、 New app > Host web app を選択します。 Git リポジトリのホスティングプロバイダを選択し、 Continue を選択します。 Git プロバイダーによっては、Amplify Hosting にリポジトリへのアクセスを許可するようプロンプトが表示されます。認証に成功したら、 Recently updated repositories リストからこのアプリのリポジトリを選択し、 Next を選択します。 Build settings ページで、Amplify は自動的に正しいビルド設定を検出するので、設定を変更する必要はありません。デフォルトのまま Next を選択します。 Review ページで、 Save and deploy を選択します。 アプリが作成され、Amplify Hosting コンソールのアプリのページに移動します。Amplify Hosting は、プロジェクト用に分離されたビルドとホスティング環境をプロビジョニングし、デプロイします。このプロセスには 2 ~ 3 分かかります。以下のように、 Provision 、 Build 、または Deploy リンクを選択することで、進行状況を確認できます。 パラメータストアでシークレットを手動で作成 Next.js の API Routes では、AWS SDK が Amazon VPC 内の Lambda 関数を呼び出すために、シークレットにアクセスする必要があります。 シークレットは、設定データ管理とシークレット管理のためのセキュアで階層的なストレージを提供する Parameter Store に格納します。 Amplify Hosting コンソールで、 App Settings: General に移動し、 App ARN を取得します。 最後のスラッシュ (/) の後の値が App ID で、Parameter Store にキーを保存するときに使用されます。 VPC スタックの CDK アウトプットから取得した VPC_AWS_REGION 、 VPC_LAMBDA_FUNCTION_NAME のためのシークレットを作成する必要があります。 Next.js の API Routes と Amazon VPC の AWS Lambda の間の統合ポイントは、VPC Lambda 関数を呼び出すアクセス権を持つ IAM ユーザーまたはロールによって実現されます。 このユーザーまたはロールには、 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY 、および VPC Lambda 関数を呼び出す権限が必要です。 IAM ユーザーの作成 、 IAM ユーザーのアクセスキーの作成 、および 共有責任モデル を使用したアクセススコープのベストプラクティスを参照してください。 これらのシークレットは、AWS コンソールの Parameter Store に移動して手動で設定できます。 Amplify Hostingドキュメントの 環境変数 のページの指示に従って、パラメータ名は以下の形式に従ってください。 今回のケースでは Amplify バックエンドを持っていないので、ブランチ名は main にします。 /amplify/{your_app_id}/{your_backend_environment_name}/{your_parameter_name} 完了すると、Parameter Store で以下のように表示されます。 パラメータストアでのシークレット作成の自動化 オプションとして、以下の .env.local テンプレートと Bash スクリプト sync-ssm-params.sh を利用して、プロジェクト内の .env.local ファイルから Parameter Store に直接シークレットを保存することもできます。 このスクリプトは、ローカル開発環境に AWS CLI と jq が Amplify アプリ ID と一緒にインストールされている必要があります。 .env.local に VPC_AWS_REGION と VPC_AWS_REGION 、 VPC_LAMBDA_FUNCTION_NAME を設定し、 AWS_PROFILE に AWS CLI で設定した使用したいプロファイルを設定します。 AWS_ACCESS_KEY_ID と AWS_SECRET_ACCESS_KEY は、 AWS CLI を使用してスクリプトが取得します。 # .env.local AWS_APP_ID=<Copy from Amplify Hosting Console> AWS_PROFILE=default VPC_AWS_REGION= VPC_LAMBDA_FUNCTION_NAME= #!/bin/bash # sync-ssm-params.sh # Allow list of parameters allowlist=( AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY VPC_AWS_REGION VPC_LAMBDA_FUNCTION_NAME ) # Get the name of the current branch APP_BRANCH=$(git rev-parse --abbrev-ref HEAD) # Load .env into environment export $(cat .env.local | grep -v '^#' | xargs) # Get AWS access keys from AWS CLI profile AWS_ACCESS_KEY_ID=$(aws configure get aws_access_key_id --profile $AWS_PROFILE) AWS_SECRET_ACCESS_KEY=$(aws configure get aws_secret_access_key --profile $AWS_PROFILE) for key in "${allowlist[@]}"; do aws ssm put-parameter --name "/amplify/$AWS_APP_ID/$APP_BRANCH/$key" --value "${!key}" --type SecureString --overwrite done カスタムポリシーで Amplify Hosting のサービスロールの更新 Parameter Store に保存されたシークレットにアクセスする前に、アプリケーションのデプロイ時に Amplify Hosting が作成した Service Role を更新して、このアプリケーションの Parameter Store からの読み取り権限を持たせる必要があります。 Amplify Hosting コンソールに移動し、アプリケーションに移動して、 App Settings: General に移動し、 Service Role に注目してください。 AWS コンソール の IAM に移動し、Service Role を検索します。 Add permissions > Attach policy を選択して、インラインポリシー AllowAmplifySSMCalls をロールに追加します。 以下のポリシーを Amplify アプリ ID で更新し、JSON エディタに貼り付けます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowAmplifySSMCalls", "Effect": "Allow", "Action": [ "ssm:GetParametersByPath", "ssm:GetParameters", "ssm:GetParameter" ], "Resource": [ "arn:aws:ssm:*:*:parameter/amplify/<AMPLIFY_APP_ID>/*" ] } ] } ポリシーが保存されると、 Permissions policies の下に他のポリシーと一緒に表示されます。 パラメータストアからシークレットをロードするための Amplify ビルドのカスタマイズ 最後に、Amplify CI のビルド設定ファイル amplify.yml を更新して、Parameter Store から Next.js がビルド処理中に参照する環境ファイル ( .env ) にシークレットをロードする必要があります。 プロジェクトに amplify.yml ファイルを追加して、 jq ユーティリティ ( $secrets の値を解析するのに必要) をインストールし、ビルド中に Parameter Store からシークレットを .env にロードするための以下のコマンドを追加します。 jq の使用はオプションであり、 環境変数をサーバー側のランタイムからアクセスできるようにするためのガイダンス に従って grep や他のユーティリティを使用しても構いません。 echo $secrets | jq -r 'to_entries|map("\(.key)=\(.value)")|.[]' >> .env 以下は、完全な amplify.yml ファイルです。 version: 1 frontend: phases: preBuild: commands: - yum -y install jq - jq --version - npm ci build: commands: - echo $secrets | jq -r 'to_entries|map("\(.key)=\(.value)")|.[]' >> .env - npm run build artifacts: baseDirectory: .next files: - "**/*" cache: paths: - node_modules/**/* ファイルを Git にコミットし、Git プロバイダーにプッシュしてデプロイを開始します。 Amazon VPC Lambda 関数のデータで Next.js アプリを更新 シークレットを Parameter Store に格納したら、Next.js アプリから Amazon VPC 内のデータにアクセスできるようになります。 AWS SDK に依存するので、次のコマンドでインストールします。 $ npm install aws-sdk page/api の下に Next.js API Routes getGeoData.ts を作成し、AWS SDK を初期化して Amazon VPC Lambda 関数を呼び出す次のコードを記述します。 // pages/api/getGeoData.ts import { Lambda } from "aws-sdk"; import { NextApiRequest, NextApiResponse } from "next"; const lambda = new Lambda({ region: process.env.VPC_AWS_REGION, accessKeyId: process.env.AWS_ACCESS_KEY_ID, secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY, }); export default async (req: NextApiRequest, res: NextApiResponse) => { lambda.invoke( { FunctionName: process.env.VPC_LAMBDA_FUNCTION_NAME!, Payload: JSON.stringify({}), }, (err, data) => { if (err) { console.log(err); res.status(500).json({ error: err }); } else { res.status(200).json({ data }); } } ); }; 次に、データにアクセスするフロントエンドのコードを記述します。 pages/index.ts を、 pages/api/getGeoData への API コールを行い、 AWS Amplify UI を使用して結果を表に表示する以下のコードに置き換えます。 // pages/index.tsx import { Heading, Table, TableBody, TableCell, TableHead, TableRow, View, } from "@aws-amplify/ui-react"; import { useEffect, useState } from "react"; type Country = { name: string; states: string[]; }; export default function Home() { const [geoData, setGeoData] = useState<Country[]>([]); useEffect(() => { fetch("/api/getGeoData") .then((res) => res.json()) .then((data) => { const payload = JSON.parse(data.data.Payload); const body = JSON.parse(payload.body); setGeoData(body); }); }, []); return ( <View padding="1rem"> <Heading level={2} marginBottom={25}> Countries and States </Heading> <br /> {geoData.length === 0 && <div>Loading...</div>} {geoData.length > 0 && ( <Table width={500}> <TableHead> <TableRow> <TableCell as="th">Country</TableCell> <TableCell as="th">States</TableCell> </TableRow> </TableHead> <TableBody> {geoData.map((country) => ( <TableRow key={country.name}> <TableCell>{country.name}</TableCell> <TableCell> {country.states.map((state) => ( <div key={state}>{state}</div> ))} </TableCell> </TableRow> ))} </TableBody> </Table> )} </View> ); } ファイルを Git にコミットし、Git プロバイダーにプッシュして最終的なデプロイを開始します。 デプロイ後、プロジェクトの URL に移動すると、Amazon VPC の Lambda 関数からデータがロードされます。 クリーンアップ AWS CDK スタックのリソースを削除するには、 lambda-in-a-vpc CDK プロジェクトのルートから cdk destroy を実行します。 Next.js Amplify アプリを削除するには、Amplify Hosting でアプリに移動し、 Actions > Delete app を選択します。 まとめ 本記事では、AWS CDK を使用して Amazon VPC 内で関数を分離するために、セキュリティグループ付きのプライベートサブネットに Lambda 関数を構築してデプロイしました。 次に Next.js アプリを作成し、Next.js の API Routes を通して Amazon VPC 内のデータにアクセスし、AWS Amplify Hosting にホストされデプロイされた React UI にアクセスしました。 パラメータストアを使用して APIキーやその他の設定データを安全に保存し、アクセスするためのベストプラクティスを紹介しました。 カスタムドメイン の設定や、 プルリクエスト用の Web プレビュー 、 機能ブランチ (feature branch) など、Amplify Hosting の機能についての詳細は、 AWS Amplify Hosting ドキュメント をご覧ください。 本記事は「 Accessing resources in a Amazon Virtual Private Cloud (Amazon VPC) from Next.js API Routes 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

CTO として、あなたはエンジニアリングチームの技術戦略を監督し、フレームワーク、アーキテクチャ、インフラストラクチャに関する決定を導く責任があります。開発者の生産性を最大限に高めながら、堅牢でスケーラブルなアプリケーションを構築するためには、適切な技術スタックを選択することが極めて重要です。本記事では、 AWS Amplify の新しいコードファースト開発者体験 (Gen 2) でフルスタックアプリケーションを構築することが、Web 開発スタックの中核であるべき理由を説明します。 Amplify Gen 2 は、現代の Web 開発者の要件を満たすために、AWS 上でフルスタックアプリケーションを構築する開発者体験を再構築しました。TypeScript と AWS Cloud Development Kit (AWS CDK) のようなコードファーストの開発者体験ソリューションを活用することで、Amplify は AWS 上でインフラストラクチャをプロビジョニングするための設定ではなく、コードを書く能力を開発者に提供します。 TypeScript のメリット TypeScript は静的型付けされた JavaScript のスーパーセットで、プレーンな JavaScript にコンパイルされます。フロントエンドとバックエンドの Web 開発に TypeScript を使用すると、いくつかの重要な利点があります。 エラーの早期発見 : TypeScript の静的型付けは、実行時にしか現れないような、コンパイル時に発生するさまざまなエラーを検出します。これにより、より堅牢なコードとなり、実運用でのバグが少なくなります。 開発者の生産性の向上 : 型付けは、Visual Studio Code のような統合開発環境 (IDE) で、インテリセンス、オートコンプリート、インラインドキュメントを提供します。これにより、開発者の生産性が向上します。 より簡単なリファクタリング : 型システムは、互換性のない変更を即座に開発者に警告することで、大規模なリファクタリングをより安全にします。 コードの自己文書化 : 明示的な型は、バニラ JavaScript に比べてコードをより自己文書化します。そのため、新しいチームメンバーも素早く立ち上がることができます。 将来性のあるコード ： TypeScript を使用すると、ロジックとフレームワークを切り離すことができるため、React Hooks のような新しいフレームワークやパラダイムへの移行が容易になります。 つまり、TypeScript を使用することで、バグが少なく保守が容易なコードを作成しながら、開発者の幸福度と生産性を向上させることができます。 AWS CDK によるコードファーストの開発者体験 インフラストラクチャを手動で管理するのは時間がかかり、エラーが発生しやすく、環境間で正確に再現するのが困難です。AWS CDK のようなコードファーストのソリューションでは、TypeScript のような実際のプログラミング言語を使用して、宣言的な方法ですべてのインフラストラクチャを定義できます。これらの機能により、アプリケーションとインフラストラクチャのニーズが進化するにつれて、AWS サービスの幅とパワーを活用した拡張性が可能になります。 AWS CDK を使用してインフラストラクチャをコードとして管理する主な利点は以下のとおりです。 ベストプラクティスの成文化 : コードとしてアーキテクチャを定義し、セキュリティ、信頼性、およびコンプライアンスのベストプラクティスを成文化します。 迅速な環境プロビジョニング : アプリケーションの開発環境、テスト環境、ステージング環境を数分で構築できます。環境の破棄と再作成もすばやく行えます。 効率的なアップデート : コードを通じて、すべての環境でスタックのアップデートを迅速に実行できます。 コストの最適化 : AWS CDK は、スポットインスタンスや自動スケーリングなどのコスト最適化サービスを簡単に活用できます。 インフラテスト : AWS CDK を使用してインフラストラクチャの単体テストと統合テストを記述し、デプロイ前のエラーを防止します。 AWS CDK は、アプリケーションコードと同様に、インフラストラクチャをバージョン管理し、CI/CD パイプラインの一部としてデプロイすることを可能にします。これは開発者の生産性とビジネスの俊敏性を大きく向上させます。 AWS Amplify とコードファースト開発者体験 AWS Amplify Gen 2 の登場は、特にフロントエンドチームのニーズに応えるフルスタックアプリケーション開発の次世代を示します。 この強力なツールキットは、開発者が堅牢でスケーラブルなアプリケーションを、スピードを維持し、複雑さを軽減しながら構築できるようにします。ここでは、AWS Amplify Gen 2 がフルスタック開発の領域でゲームチェンジャーとなる理由と方法を説明します。 開発者のスピードと効率性 AWS Amplify Gen 2 は、TypeScript ベースのコードファーストなアプローチを導入し、開発者体験を大幅に強化します。このシフトにより、フロントエンド開発者は TypeScript で直接バックエンドを定義できるようになり、開発プロセスが効率化されます。アプリのデータモデル、ビジネスロジック、認証、認可ルールを TypeScript で表現することで、開発者は基盤となる AWS サービスを手動で設定する手間をかけずにクラウドインフラストラクチャを導入できます。その結果、さまざまなサービスをつなぎ合わせる必要がなくなり、開発速度が飛躍的に向上します。 より少ないコード、より多くのパワー AWS Amplify Gen 2 で採用されているファイルベースの規約は、”設定よりも規約 (convention over configuration)” という原則を遵守しています。これは、開発者が定型的なコードを書く時間を減らし、機能構築に集中する時間を増やすことを意味します。認証用とデータ用といったように、リソースがタイプごとに別々のファイルにまとめられているため、構造が直感的で管理しやすくなっています。さらに、TypeScript を使用すると、Visual Studio Code などの IDE で厳密な型付けとインテリセンスがサポートされるため、エラーが減り、開発プロセスがさらに高速化されます。 フルスタック機能でフロントエンドチームを強化 AWS Amplify Gen 2 により、フロントエンドチームは、記録的なスピードで、より少ない摩擦で、フルスタックを構築する力を得ました。より高速なイテレーションのために最適化された開発者ごとのクラウドサンドボックス環境の提供により、個々のチームメンバーはお互いの作業を妨げることなく、独立してフルスタック機能に取り組むことができます。この並行開発機能は、新機能の市場投入までの時間を短縮する上で極めて重要です。 さらに、フルスタックの Git ベースの環境は、最新の開発ワークフローとシームレスに連携します。各エフェメラル環境は Git ブランチに直接対応しているため、新機能のテストや統合が簡単に行えます。プルリクエストや機能ブランチは、本番環境にマージする前にプレビューできます。コードファーストのアプローチを採用しているため、すべてのバックエンドリソースはコードとして定義され、ブランチ間での再現性と移植性を実現しています。この Git を中心としたアプローチによって、リポジトリが常に単一のソースであり続けることが保証され、開発環境から本番環境への機能の移行が単純化されます。 まとめ AWS Amplify Gen 2 は、フロントエンドチームが TypeScript と AWS CDK を使ってコードファーストの開発者体験でフルスタック開発に取り組む方法を根本的に変えます。開発者のスピードを重視し、過剰なコードの必要性を減らし、堅牢なフルスタック機能を提供することで、チームは他のソリューションよりも効率的かつ効果的に構築することができます。これらの機能により、開発コストを削減し、新製品や新機能の市場投入までの時間を短縮することができます。 AWS Amplify の新しいコードファーストの開発者体験 (Gen 2) を 使用して 、 AWS 上でのモダンアプリケーションの構築の詳細 をご覧ください。 本記事は「 The CTO’s Guide to building fullstack applications with AWS Amplify 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

現在、400 を超える組織が 2040 年までに温室効果ガス排出量実質ゼロを達成することを公約した The Climate Pledge に署名しています。 明示的な気候目標を設定する背景には、顧客の需要、現在および予測される政府関係、従業員の需要、投資家の需要、競争優位性としてのサステナビリティなどがあります。 AWS の顧客からも、サステナビリティへの取り組みを推進する方法についてますます関心が高まっています。 このブログでは、 Amazon Simple Storage Service (S3) と標準 SQL を使用したデータ分析を簡単に行えるサーバーレスの対話型分析サービスである Amazon Athena を使用して、企業の既存データからスコープ 1 のカーボンフットプリントをよりよく理解し、推定する方法を解説します。 温室効果ガスプロトコル 温室効果ガスプロトコル (GHGP) は、組織の事業およびバリューチェーンからの地球温暖化への影響を測定および管理するための標準を提供しています。 GHGP が対象とする温室効果ガスは、 国連気候変動枠組条約/京都議定書 (しばしば「Kyoto Basket」と呼ばれる) で要求されている 7 つの気体です。これらの気体は、二酸化炭素 (CO2)、メタン (CH4)、一酸化二窒素 (N2O)、フロンガスと呼ばれる F ガス (ハイドロフルオロカーボンとパーフルオロカーボン)、六ふッ化硫黄 (SF6)、三ふッ化窒素 (NF3) です。 温室効果ガスは、それぞれ温室効果と大気中の寿命によって決定される地球温暖化係数 (GWP) によって特徴づけられます。二酸化炭素 (CO2) が 人為的な温室効果ガス排出量の約 76% を占めるため、温室効果ガスの地球温暖化係数は CO2 を基準に測定され、CO2 換算値 (CO2e) で表されます。GHGP は、組織の排出量を 3 つの主要なスコープに分類しています。 スコープ 1 – 直接的な温室効果ガスの排出 (例えば化石燃料の燃焼からの排出) スコープ 2 – 購入したエネルギーからの間接的な排出 (典型的には電力) スコープ 3 – サプライチェーン全体 (サプライヤーや顧客を含む) からの間接的な排出 温室効果ガスの排出量の推定方法 GHG 排出量を推定する方法には、連続排出モニタリングシステム (CEMS) 手法、支出ベース手法、消費ベース手法などがあります。 直接測定 – CEMS 手法 組織は、CEMS を用いて炭素排出量を直接測定することで、固定燃焼源からのカーボンフットプリントを推定できます。この手法を実現するためには、排出源から排出される排ガス中の物質を連続的に測定するためにガスアナライザー、ガスサンプラー、ガスコンディショニング機器 (微粒子、水蒸気、その他の汚染物質を除去する)、配管、駆動弁、プログラマブルロジックコントローラー (PLC)、その他の制御ソフトウェアやハードウェアなどの機器が必要です。このアプローチは有用な結果をもたらす可能性がありますが、CEMS は測定対象となる温室効果ガスごとに特定のセンシング機器およびハードウェアとソフトウェアのサポートが必要であり、多くの場合は中央集約型の排出源に対する環境保健安全の取り組みに適しています。CEMS の詳しい情報は こちら を参照ください。 支出ベース手法 財務会計機能は成熟しており、すでに監査を受けていることが多いため、多くの組織が財務コントロールを炭素会計の基盤として利用することを選択しています。Economic Input-Output Life Cycle Assessment (EIO LCA) 手法は、支出データと金額ベースの排出係数を組み合わせた支出ベースの方法で、推定される排出量を算出します。排出係数は、米国環境保護庁 (EPA) や他の査読付きの学術機関や政府機関によって公表されています。この方法を用いることで、事業活動に費やされた金額に排出係数を乗じることで、その活動から推定されるカーボンフットプリントを算出することができます。 たとえば、自社のトラック輸送にかかるコストを、下記のように推定される二酸化炭素換算値 (CO2e) のキログラム (KG) に換算することができます。 推定されるカーボンフットプリント = トラック輸送に費やされた金額 * 排出係数 [ 1 ] これらの計算は、総勘定元帳やその他の財務記録から非常に簡単に行うことができますが、温室効果ガスの少量発生源を報告するための初期見積もりに最も有用です。ユーザーが入力する情報は、活動に費やした金額のみなので、EIO LCA 手法は効率性の改善をモデル化するのには適していません。 これは、EIO で計算された排出量を削減する唯一の方法は支出を削減することであるためです。 したがって、企業がそのカーボンフットプリントの効率を継続的に改善していくにつれて、カーボンフットプリントを推定するためには、他の方法の方がより望ましいことが多くあります。 消費ベース手法 報告期間中に組織が調達した燃料の量は、ERP (Enterprise Resource Planning) システムや燃料代の電子コピーから容易に判断できます。燃料ベースの排出係数は、米国環境保護庁や商用ライセンスのデータベースなど、さまざまなソースから入手できます。調達した燃料の量に排出係数を乗じると、燃焼に伴う CO2e の推定排出量を導き出せます。この方法は、固定排出源 (データセンターのバックアップ発電機や工業プロセスの化石燃料炉など) のカーボンフットプリントを推定するためによく用いられます。 特定の月に、企業が固定燃焼用に一定量のガソリンを消費した場合、ガソリンの燃焼に伴うスコープ 1 CO2e フットプリントは次のように推定できます。 推定されるカーボンフットプリント = 消費された燃料の量 * 固定燃焼の排出係数 [ 2 ] 組織は、燃料や電気料金の請求書、ERP データなどの既存のデータと、関連する排出係数を使用して自社の炭素排出量を推定し、それらをデータレイクに統合することができます。Amazon Athena や Amazon QuickSight などの既存の分析ツールを使用することで、組織は推定されたカーボンフットプリントに関する洞察を得ることができます。 以下のデータアーキテクチャ図は、AWS のサービスを使用して組織の推定されるカーボンフットプリントを算出および可視化する例を示しています。 お客様は、ユースケースに基づいて、データパイプラインの各段階でサービスを選択する柔軟性を持ちます。たとえば、データ取り込みフェーズでは、既存のデータ要件に応じて、 AWS Command Line Interface (CLI) 、 AWS DataSync 、 AWS Database Migration Service などを使用してデータレイクにデータを取り込むための多くのオプションがあります。 AWS サービスを使用したスコープ 1 の固定発生源排出量の計算例 100 標準立方フィート (scf) の天然ガスをオーブンで燃焼させたとします。 米国 EPA の固定発生源の排出係数 を使用すると、燃焼に関連するカーボンフットプリントを推定できます。 この場合、排出係数は 0.05449555 Kg CO2e /scf です。 [3] 実質的に無制限の拡張性と高い耐久性を備えている Amazon S3 は、AWS でデータレイクを構築して異種データソースを 1 つのリポジトリに格納するのに理想的です。サーバーレスの対話型クエリサービスである Athena を使用すると、データを Athena にロードしたり、複雑な抽出、変換、ロード (ETL) プロセスを実行したりすることなく、標準的な SQL を使用して直接 Amazon S3 からデータを分析できます。Amazon QuickSight は、Amazon S3 や Athena を含むさまざまなデータソースのビジュアライゼーションを作成したり、カスタム SQL を使用することで柔軟にデータのサブセットを抽出できます。QuickSight ダッシュボードを活用すると、会社の推定されるカーボンフットプリントなどの洞察をすばやく得ることができ、ビジネスとサステナビリティのユーザー向けに標準化されたレポートを生成する機能も提供します。 この例では、次のアーキテクチャ図に示すように、ファイルシステムに保存されている サンプルデータ を AWS Command Line Interface(CLI) を使用して Amazon S3 にアップロードします。AWS では、 セキュリティ、アイデンティティ、コンプライアンスに関するベストプラクティス のガイダンスに従って、AWS リソースを作成し、CLI アクセスを管理することをおすすめします。 以下の AWS CLI コマンドは、サンプルデータのフォルダを S3 のターゲットの場所にアップロードする方法を示しています。 aws s3 cp /path/to/local/file s3://bucket-name/path/to/destination S3 コンソールのスナップショットは、ファイルが含まれる 2 つの新しく追加されたフォルダーを示しています。 新しいテーブルスキーマを作成するために、まず Athena クエリエディタで Hive DDL を使用してガス利用テーブル用に以下のスクリプトを実行します。このスクリプトは、データフォーマット、列の詳細、テーブルプロパティ、そして S3 のデータの場所を定義します。 CREATE EXTERNAL TABLE `gasutilization`( `fuel_id` int, `month` string, `year` int, `usage_therms` float, `usage_scf` float, `g-nr1_schedule_charge` float, `accountfee` float, `gas_ppps` float, `netcharge` float, `taxpercentage` float, `totalcharge` float) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3:///Scope 1 Sample Data/gasutilization' TBLPROPERTIES ( 'classification'='csv', 'skip.header.line.count'='1') 以下のスクリプトは、Hive DDL を使用してガス排出係数データのテーブルスキーマを生成するもう 1 つの例を示しています。 CREATE EXTERNAL TABLE `gas_emission_factor`( `fuel_id` int, `gas_name` string, `emission_factor` float) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat' OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat' LOCATION 's3:///Scope 1 Sample Data/gas_emission_factor' TBLPROPERTIES ( 'classification'='csv', 'skip.header.line.count'='1') Athena でテーブルスキーマを作成した後、2020 年のガス利用量とガス公共目的プログラム付加料金 (PPPS) や税引き後の請求額などの関連請求額を示すために、ガス料金の詳細を含むガス利用テーブルに対して、以下のクエリを実行します。 SELECT * FROM "gasutilization" where year = 2020; スクリーンショットに示すように、さまざまな燃料タイプとそれに対応する CO2e 排出量の排出係数データを分析することもできます。 以下のクエリを実行し、ガス利用データと排出係数を使用することで、スコープ 1 の推定カーボンフットプリントとその他の詳細情報を取得できます。このクエリでは、ガス利用テーブルとガス排出係数テーブルを燃料 ID でジョインし、標準立方フィート (scf) で測定されたガス使用量に排出係数を乗じて、推定 CO2e インパクトを算出しました。また、顧客にとって関心のある属性である月、年、請求総額、熱量と scf で測定されたガス使用量も選択しました。 SELECT "gasutilization"."usage_scf" * "gas_emission_factor"."emission_factor" AS "estimated_CO2e_impact", "gasutilization"."month", "gasutilization"."year", "gasutilization"."totalcharge", "gasutilization"."usage_therms", "gasutilization"."usage_scf" FROM "gasutilization" JOIN "gas_emission_factor" on "gasutilization"."fuel_id"="gas_emission_factor"."fuel_id"; 最後に、Amazon QuickSight は、Amazon S3 や Athena を含むさまざまなデータソースのビジュアライゼーションを作成したり、カスタム SQL を使用することで柔軟にデータのサブセットを抽出できます。以下は、年別のガス利用量、ガス料金、推定されたカーボンフットプリントを示す QuickSight ダッシュボードの例です。 ここでは、1 つの固定燃焼源について、スコープ 1 のカーボンフットプリントを推定しました。 すべての固定および移動排出源 (異なる排出係数を使用) について同じプロセスを行い、結果を足し合わせることができれば、ネイティブ AWS サービスと自社データのみを利用して、事業全体のスコープ 1 の炭素排出量の正確な推定値を算出することができます。同様のプロセスにより、スコープ 1 の排出係数の代わりに電力系統の炭素強度を用いて、スコープ 2 の排出量の推定値が得られます。 まとめ このブログでは、組織が異なるソースに存在するデータを使用して、スコープ 1 の温室効果ガス排出量の可視性を向上するためのデータアーキテクチャを構築する方法について説明しました。 Athena、S3、QuickSight を使用することで、組織は消費ベースの方法を適用して燃料利用量を推定されたカーボンフットプリントに変換することにより、固定排出源からのカーボンフットプリントを繰り返し測定可能な方法で推定できるようになりました。 AWS で利用可能なその他のアプローチは、 Carbon Accounting on AWS 、 Sustainability Insights Framework 、 Carbon Data Lake on AWS 、および AWS Carbon Accounting ページ を参照ください。 AWS を活用して組織のカーボンフットプリントの推定する方法について関心がある場合は、AWS アカウント担当に連絡を取り、 AWS Sustainability Solutions をご確認ください。 参考文献 Amazon’s Carbon Methodology ドキュメント の 4 ページ目の例は、この概念を示しています。 トラック輸送にかかる費用: $100,000ドル EPA 排出係数: トラック輸送 1 ドルあたり 1.556 kg CO2e 推定 CO2e 排出量: トラック輸送 $100,000ドル * 1.556 kg CO2e/トラック輸送 1 ドル = 155,600 kg の CO2e ↑ 例えば、 ガソリン消費量: 1,000 US ガロン EPA 排出係数: ガソリン 1 ガロンあたり 8.81 kg の CO2e 推定 CO2e 排出量 = 1,000 USガロン * ガソリン 1 ガロンあたり 8.81 kg のCO2e = 8,810 kg の CO2e。 ガソリンの固定排出源に対するEPA排出係数 は、8.78 kg の CO2 に CH4 が 0.38 グラム、N2O が 0.08 グラムを加えたもの。 これらの排出係数を、各ガスの 100 年地球温暖化係数 (CH4:25、N2O:298) を用いて組み合わせると、合計排出係数 = 8.78 kg + 25 × 0.00038 kg + 298 × 0.00008 kg = ガソリン 1 ガロンあたり 8.81 kgの CO2e となる。 ↑ 1 scf あたりの排出係数は、CO2 が 0.05444 kg、CH4 が 0.00103 g、N2O が 0.0001 g。これを CO2e で表すには、他の 2 つのガスの排出係数にそれぞれの地球温暖化係数 (GWP) を乗じる必要がある。CH4 と N2O の 100 年 GWP はそれぞれ 25 と 298。排出係数と GWP は、 米国 EPAのウェブサイト から得られる。↑ 著者について Thomas Burns は、 SCR 、 CISSP の資格を持ち、Amazon Web Services でサステナビリティ戦略とプリンシパルソリューションアーキテクトを務めています。トーマス氏は、世界中の製造業や工業分野のお客様をサポートしています。トーマス氏は、クラウドを利用して、IT 内外の両方で企業の環境への影響を低減することに注力しています。   Aileen Zheng は、Amazon Web Services (AWS) の米国連邦政府民間科学のお客様を支援するソリューションアーキテクトです。彼女は、エンタープライズクラウドの採用と戦略について技術的なガイダンスを提供し、適切に設計されたソリューションの構築を支援するパートナーです。データアナリティクスと機械学習についても情熱があります。余暇の時間には、ピラティスをしたり、犬のムムを連れてハイキングに出かけたり、おいしい食べ物の場所を探し回ったりしています。また、多様性とテクノロジー分野の女性を支援するプロジェクトにも貢献しています。   この記事は 2023 年 8 月 2 日に Thomas Burns と Aileen Zheng によって投稿された「 Estimating Scope 1 Carbon Footprint with Amazon Athena 」をソリューションアーキテクト佐藤が翻訳したものです。 ※本稿は英語版ブログの翻訳となります。翻訳版にご不明な点がある場合は英語版ブログの内容を正としてください。

3 部構成の本ブログシリーズの 第 1 部 では、Organizations 内のある組織から別の組織にアカウントを移動する際に、ガイダンスと考慮が必要な AWS Organizations のさまざまな機能を確認しました。具体的には、Organizations のポリシー、 AWS Resource Access Manager（AWS RAM） による共有、 AWS グローバル条件コンテキストキーに焦点を当てました。 第 2 部 では、Organizations と連携する AWS サービスの委任管理者として登録されているアカウントを移動したい場合に行うべきこと、確認すべきことについて見てきました。 本ブログでは、現在の組織と移行先組織で AWS サービスに対する信頼されたアクセスが有効化されている場合に、当該組織間で AWS アカウントを移行する際に行うべきこと、確認すべきことを見ていきます。 第 1 部と同様に、 組織からメンバーアカウントを削除 し、 移行先 組織で AWS アカウントを招待 するための Organizations ユーザーガイドで提供される情報を整理していきます。 組織間でアカウントを移動するには、当該 AWS アカウントを現行の組織から削除し、AWS アカウントをスタンドアロンにしてから、移行先の組織への招待を受け入れる必要があります。 組織からアカウントを削除する前に、組織で AWS サービスに対する信頼されたアクセスが有効化されているかどうかを確認することをお勧めします。 本ブログには AWS Command Line Interface (AWS CLI) を利用したコマンド実行例を記載します。実行例を利用するには AWS CLI のインストールと設定を行う必要があります。詳細については、「 AWS CLI の最新バージョンを使用してインストールまたは更新を行う 」を参照してください。 AWS Organizations の信頼されたアクセス 互換性のある AWS サービスにおいて信頼されたアクセスを有効化すると、そのサービスは、組織内のすべての AWS アカウントでドキュメントに記載されている操作を実行できます。 AWS アカウントを削除すると、信頼されたサービスはそのアカウントで操作を実行できなくなります。 組織からアカウントを削除して別の組織に移行する前に、信頼されたサービスに関連する AWS アカウントへの影響を理解し、考慮すべきアクションを把握しておく必要があります。 現在、信頼されたアクセスをサポートしている AWS サービスのリストを本ブログに記載しています。AWS サービスの名前またはサービスのプリンシパル名で検索することができます。AWS サービスの名前または サービスのプリンシパル 名で AWS サービスを見つけることができます。サービスのプリンシパル名は、AWS CLI の list-aws-service-access-for-organization コマンドを使用して取得することが可能です。 以下の AWS CLI の例では、お客様の組織において信頼されたアクセスが有効化されている AWS サービスのリストを取得します。 PROMPT> aws organizations list-aws-service-access-for-organization 現在の組織と移行先組織において信頼されたアクセスが有効化された AWS サービスのリストを取得した後、組織間で 1 つ以上のアカウントを移動する場合に必要なアクションを計画することができます。 アカウントを別の組織に移動する際には、信頼されたアクセスが有効になっている AWS サービスと連携するためにアカウントを設定する必要があるかどうかを確認してください。ほとんどの場合、アカウントや AWS サービスを再構成する必要はありません。以下に提示する現在 Organizations の信頼されたアクセスをサポートしている AWS サービスのリストにおいてそのためのガイダンスを提供します。 トでアカウントに代わって自動的に契約を受諾することはできなくなります。削除されたアカウントは、 組織によって受諾 された AWS Artifact 組織契約にアクセスできなくなり、その対象から外れることになります。管理アカウントは AWS Artifact コンソールの「契約」メニュー内の「組織契約」で組織契約のリストを表示できます。 組織からアカウントを削除する前に、スタンドアロンアカウントや移行先組織で新しい契約を締結する必要があるかを、法務、プライバシー、コンプライアンス等の適切なチームの支援を得て判断してください。移行先組織の複数のアカウントにわたって契約が必要な場合、 AWS Artifact で信頼されたアクセスを有効 にして、必要な契約を受諾したことを確認してください。 AWS Audit Manager: auditmanager.amazonaws.com AWS Audit Manager で 信頼されたアクセス を有効にすると、組織内の複数の AWS アカウントを評価の範囲に含めることで、より幅広いソースから証拠を収集することができます。組織からアカウントを削除すると、 評価 範囲の一部としてそのアカウントから証拠を収集することができなくなります。Audit Manager は、削除に関する通知を受け取り、既存のあらゆる評価の範囲からそのアカウントを自動的に削除します。 アカウントが移行先組織に参加すると、そのアカウントは既存の Audit Manager の評価範囲に自動的には追加されません。既存の評価範囲を見直し、必要に応じてアカウントをリストに追加してください。 AWS CloudFormation StackSets: member.org.stacksets.cloudformation.amazonaws.com AWS CloudFormation StackSets で 信頼されたアクセスを 有効にすると、管理者または委任管理者アカウントは、組織のスタックセットを作成および管理する権限を持っています。組織からアカウントを削除すると、 CloudFormation StackSets は、アカウントに関連する権限を持つサービスリンクロールを使用して、そのアカウントにスタックインスタンスをデプロイできなくなります。 アカウント内に StackSet の一部であるスタックがあり、そのスタックを保持したい場合、移行先組織または組織単位（OU）からアカウントを削除するときの StackSet のアカウント削除動作が「スタックを保持」と設定されていることを確認してください。AWS CLI の describe-stack-set コマンドを使用して RetainStacksOnAccountRemoval の値で削除動作を確認します。true に設定されている場合、アカウントが移行先組織または OU から削除されたときにスタックリソースが保持され、false に設定されている場合、スタックリソースは削除されます。 移行先組織の StackSet に引き続きスタックを含める予定の場合、 StackSet にスタックをインポート できます。移行先組織では、移行元組織の StackSet に使用されたものと同じテンプレートを使用して新しい StackSet を作成します。StackSet を作成するときは、アカウントが配置される OU を含めるようにします。 アカウントを移行先組織に参加させる前に、StackSet 自動デプロイメントの設定を一時的に無効にしましょう。アカウントが組織に参加した時に、インポート対象と同じ内容のスタックが自動でデプロイされてしまうことを防ぐためです。アカウントが移行先組織に参加すると、作成した StackSet にスタックをインポートできます。 インポート後、アカウント内でスタックにステータス「FAILED」の変更セットが含まれていることに気づくでしょう。これはこのインポートで期待されるステータスであり、「The submitted information didn’t contain changes. Submit different information to create a change set」という理由が添えられています。移行先組織の StackSet に参加してもスタックがすでに存在していたためデプロイされず、その後の変更も必要ないためスタックはデプロイされません。 AWS CloudTrail: cloudtrail.amazonaws.com AWS CloudTrail の 信頼されたアクセス を有効にすると、その組織内のすべての AWS アカウントのすべてのイベントを記録する 組織の証跡 を作成できます。組織からアカウントを削除すると、組織の証跡には該当アカウントのイベントが保存されなくなります。そのため、組織から離れる前に アカウントの証跡 をセットアップし、イベントのログを取得できるようにします。移行先組織で組織の証跡が有効になっている場合は、イベントは自動的に組織の証跡に含まれるようになるため、移行先組織に参加した後にアカウントでセットアップした証跡を削除することを検討してください。 AWS Compute Optimizer：compute-optimizer.amazonaws.com AWS Compute Optimizer の 信頼されたアクセス を有効にすると、組織の Compute Optimizer の推奨事項にアクセスし管理することができます。組織からアカウントを削除すると、Compute Optimizer は管理者または委任管理者アカウントから、そのアカウントの推奨事項にアクセスまたは管理できなくなります。アカウントのオプトインのステータスは、組織の一部であったときの設定が保持されます。 アカウントが移行先組織に参加すると、移行先組織の管理者または委任管理者アカウントの Compute Optimizer は、そのアカウントの推奨事項にアクセスし管理することができます。 AWS Config：config.amazonaws.com AWS Config の 信頼されたアクセス を有効にすると、Config アグリゲータ は組織内のアカウントから Config 設定データとコンプライアンスデータを収集できます。組織からアカウントを削除すると、そのアカウントが組織アグリゲータの一部である場合、アグリゲータはそのアカウントから Config 設定データとコンプライアンスデータを収集できなくなります。データは削除される前にアグリゲータアカウントに最大 24 時間保持されます。アカウントに展開された Config ルールやコンフォーマンスパックは削除されます。 AWS Config では、個別アカウントアグリゲータを作成し、1 つ以上のアカウントから Config 設定データおよびコンプライアンスデータを収集する 権限をアカウントに付与 することができます。 当該権限が付与された AWS アカウントを組織から削除しても、他のアカウントから Config 設定データおよびコンプライアンスデータを収集する権限は変更されません。 アカウントが移行先組織に参加すると、既存の Config 組織アグリゲータに含まれるように、アカウントで Config を有効にする必要があります。アカウントが既存の組織の Config ルールおよびコンフォーマンスパックと連携するためには、Config 設定レコーダ が有効になっていることを確認する必要があります。 既存の組織ルールおよびコンフォーマンスパックの展開は、レコーダが使用できない場合、アカウントが移行先組織に追加されてから 7 時間だけ再試行されます。 AWS Control Tower：controltower.amazonaws.com アカウントが AWS Control Tower に登録されている場合、組織からアカウントを削除する前に、Account Factory から 該当アカウントの管理を解除する か、Account Factory for Terraform（AFT）から アカウントを削除 してください。 アカウントがスタンドアロンで組織の一部でなくなっている間に、IAM ロール AWSControlTowerExecution の信頼関係を更新します。ロールの信頼ポリシーのプリンシパルを移行先組織の管理アカウント ID に変更する必要があります。 アカウントが移行先組織に参加し、AWS Control Tower にアカウントを登録する場合、 既存の AWS アカウントを AWS Control Tower に登録するプロセス に従ってください。 Amazon Detective：detective.amazonaws.com Amazon Detective で 信頼されたアクセス を有効にすると、組織 動作グラフ は、組織内のすべてのアカウントのアクティビティを可視化することができます。 組織から削除するアカウントが組織動作グラフのメンバーである場合、そのアカウントはグラフのメンバーとしても削除されます。これは、組織に参加する前に組織動作グラフに招待を受けた場合および組織に参加した後にグラフのメンバーになった場合、いずれの場合も対象となります。招待によってグラフに追加されたアカウントの場合は、そのアカウントがグラフのメンバーであり続けることも、グラフのアカウントメンバーシップを無効にすることも選択することができます。組織動作グラフのメンバーを確認するには、AWS CLI の list-members コマンドを使用してメンバーの一覧を取得したり、組織動作グラフの Amazon リソース名（ARN） を取得するために AWS CLI の list-graphs コマンドを使用できます。どちらのコマンドも、組織の管理アカウントまたは Detective の委任管理者アカウントの資格情報のいずれかを使用する必要があります。 アカウントがグラフのメンバーから削除されると、Detective はデータの取り込みを停止しますが、アカウントから取得した既存のデータはグラフに残ります。 招待による別の組織のグラフへのメンバーシップは、組織に参加または離脱しても影響を受けません。たとえば、アカウントが移行先組織のグラフのメンバーである場合、移行元組織を離れると、そのアカウントは移行元組織のグラフのメンバーではなくなりますが、移行先組織のグラフのメンバーのままとなります。組織からアカウントを削除する際、Detective がアカウントで有効になっている場合、Detective は有効なままで、アカウントの動作グラフの内容と設定はすべて保持されます。 組織間の移動中に組織からアカウントの可視性を保持するには、組織からアカウントを削除する前に、移行先組織のグラフに招待によってアカウントをメンバーとして追加することを検討します。アカウントが動作グラフのメンバーになると、初回の抽出の場合、データは通常 24 時間以内にグラフで利用可能になります。 移行先組織において Detective が新しい組織のアカウントを組織動作グラフのメンバーアカウントとして 自動的に有効化 にするように構成されている場合、アカウントが組織に参加するとアカウントは「By organization」グラフの有効なメンバーとなります。アカウントが招待によってグラフのメンバーだった場合、アカウントのメンバーシップは保持され、メンバーシップの種類は「By invitation」から「By organization」に変更されます。 アカウントが組織グラフのメンバーとして設定されていない場合、グラフにアカウントを招待することができ、同じ組織の一部であればアカウントは自動的に招待を受け入れます。 Amazon DevOps Guru: devops-guru.amazonaws.com Amazon DevOps Guru の 信頼されたアクセス を有効にすると、組織全体にわたってインサイトを管理することができます。アカウントが組織を離れ、そのアカウントで DevOps Guru が有効にされている場合、組織の管理アカウントまたは DevOps Guru 委任管理者は、アカウント内のすべての監視対象アプリケーションの健全性に関する全体的なビューを作成するために、アカウントからのインサイトを表示、並べ替え、フィルタリングすることができなくなります。 アカウントが移行先組織に参加し、アカウントで DevOps Guru が有効にされている場合、管理アカウントまたは DevOps Guru 委任管理者は、自動的にアカウントを組織で監視する対象に含めます。 AWS Directory Service：ds.amazonaws.com AWS Directory Service の 信頼されたアクセス を有効にすると、 AWS Managed Microsoft Active Directory（AD） ディレクトリを複数のアカウントでシームレスに共有することができます。1 つのディレクトリを同じ組織内の他の信頼済み AWS アカウントと共有したり、組織外の他の AWS アカウントとディレクトリを共有したりできます。 AWS Organizations またはハンドシェイクのいずれの 共有方法 でもディレクトリの利用者であるアカウントが組織から削除された場合、ディレクトリは引き続きそのアカウントと共有されています。 アカウントが、1 つ以上の AWS Managed Microsoft AD ディレクトリを持つ移行先組織に参加するとき、ディレクトリは自動的にアカウントと共有されません。AWS Directory Services コンソールまたは AWS CLI の share-directory コマンドのいずれかを使用して、アカウントとディレクトリを共有することができます。 AWS Firewall Manager：fms.amazonaws.com AWS Firewall Manager の 信頼されたアクセス を有効にすると、Firewall Manager 管理者 アカウントを使用して、AWS Organizations 内のすべての Firewall Manager セキュリティポリシーを管理することができます。アカウントが組織を離れると、Firewall Manager はアカウント内でサポートされている操作を実行できなくなります。 アカウントが Firewall Manager ポリシー の範囲内にあった場合、アカウントはポリシーと関連付けられなくなり、Firewall Manager 管理者アカウントにコンプライアンスステータスが表示されなくなります。 組織からアカウントを削除する前に、Firewall Manager の ポリシーの範囲 がアカウント内のリソースや保護を保持するように構成されていることの確認をお勧めします。アカウントが組織から離れると、ポリシーの範囲から離れ、管理されなくなりますが、Firewall Manager が自動的に保護を削除したり、Firewall Manager が管理するリソースを削除しないように設定することができます。 このオプションは「 Resource cleanup 」で設定を行いますが、保護を保持するためには「 Automatically remove protections from resources that leave the policy scope. 」を無効にする必要があります。このオプションは、 DNS Firewall 、 Network Firewall 、 セキュリティグループ （共通）、 WAF などのサポートするポリシータイプで Firewall Manager コンソールから確認できます。 ポリシータイプ WAF Classic、および Shield Advanced には、このオプションはありません。デフォルトでは、リソースに関連付けられている WAF の Web ACL は保持され、リソースを含まない Web ACL は削除されます。 アカウントで Shield Advanced ポリシーが有効化されている場合、そのアカウントが組織を離れると、そのアカウントは Shield Advanced 用に構成された Firewall Manager ポリシーの対象外となります。アカウントで Shield Advanced を サブスクライブ している場合、スコープ内のリソースは引き続き保護されます。組織を離れた後、アカウントは組織の一括請求の対象外となり、Shield Advanced のサブスクリプション料金の日割り料金がアカウントで引き続き発生します。移行元組織のサブスクリプション料金を引き続き支払い、アカウントが移行先組織に参加したときには新規または既存のサブスクリプション料金を支払うことになります。移行元組織を削除する予定がある場合、AWS サポートケースを作成して、移行先組織において Shield Advanced サブスクリプションを統合することができます。 Network Firewall または DNS Firewall ポリシーが設定されている場合、Firewall Manager は AWS Resource Access Manager (AWS RAM) を使用して Network Firewall および DNS Firewall ポリシーで設定されたルールグループを組織全体のアカウントと共有します。 アカウントが組織を離れると、ポリシーで設定したルールグループはそのアカウントと共有されなくなります。Network Firewall または DNS Firewall のポリシー範囲の設定における「 Resource cleanup 」オプションで「 Automatically remove protections from resources that leave the policy scope. 」が無効に設定されている場合、ポリシールールグループの ID と設定は、 AWS Network Firewall または Amazon Virtual Private Cloud (VPC) のいずれかの対応するリソースに関連付けられたままとなります。ただし、AWS RAM 共有とアカウントとの関連付けが解除されると、ルールグループを表示する権限が削除されるため、アカウントでルールグループを表示することはできなくなります。 アカウントを移行先組織に移動する前に、移動元組織で特定した各ポリシータイプごとに、移動するアカウントに適用される同等の Firewall Manager ポリシーが作成または更新されていることを確認してください。移行先組織では、WAF および WAF Classic ポリシータイプを設定して、ポリシーの範囲内のリソースに現在関連付けられている既存の Web ACL を置き換えるポリシーアクションを使用することができます。このオプションを使用して移行元組織のポリシーによって適用された Web ACL を置き換えることができます。既存の関連づけられた Web ACL を置き換えることを選択した場合、Firewall Manager は別のアクティブな Firewall Manager ポリシーによって管理されていない Web ACL をポリシーの範囲内のリソースから関連付け解除します。DNS Firewall ポリシー タイプを設定する場合、ルールグループの優先度を移行元組織のポリシーと異なるように設定します。ルールグループの優先度が一致している場合、ルールの優先度が競合するため、移行先組織ポリシーをアカウント内の Amazon VPC に適用することはできません。 移動するアカウントにおいて、移行元と移行先組織のポリシーで作成されたリソースと保護を受け入れるための AWS サービスの クォータ を確認する必要もあります。 移行元組織によってアカウントに設定されている現在のポリシー適用リソースや保護の現在の数の少なくとも 2 倍を許容するために、リージョンごとにアカウントの調整可能なクォータを一時的に増やすことを計画します。そのためにはアカウントの現在の使用状況を考慮する必要があり、それには、Network Firewall（ 調整可能なクォータ ）、Amazon VPC（サブネットのクォータ）、セキュリティグループ（AWS リージョンごとの VPC セキュリティグループとネットワークインターフェースごとのセキュリティグループの クォータ ）、WAF（Web ACL とルールグループの クォータ ）、WAF Classic（Web ACL とルールグループのクォータ）、Shield Advanced（ 調整可能なクォータ ）、Route 53 Resolver DNS Firewall （ 調整可能なクォータ ）などの AWS サービスが含まれます。クォータの増加により、移行元組織のポリシーで作成された既存のリソースや保護、および移行先組織のポリシーで新たに作成されたリソースや保護が共存できるようになります。 移行元組織のポリシー範囲の設定で「 Resource cleanup 」オプションで「 Automatically remove protections from resources that leave the policy scope. 」を無効に設定した場合、移行元組織のポリシーにより作成されたリソースと保護は組織から離脱後も残ります。移行元組織のポリシーによって作成されたリソースが、移行先組織で適用されるポリシーで再利用されることはありません。 アカウントを移行元組織に再度参加させ、Firewall Manager 委任管理者となり、アカウントが移行元組織を離れてから Firewall Manager のポリシーが変更されていない場合、そのポリシーはアカウントが以前組織に所属していたときに作成された既存のリソースを再利用します。 移行先組織のポリシーが移行元組織によって提供されたポリシーリソース構成を複製する場合、移行元組織のポリシーによって作成されたリソースまたは関連する保護を削除することを選択できます。移行元組織のポリシーによって作成されたリソースや保護を発見するには、ポリシーの適用範囲となっているリージョンで、ポリシータイプに適用可能なリソースや保護を確認する必要があります。Firewall Manager ポリシーによって作成されたリソースは、各ポリシータイプごとに特定の命名規則を使用します。これにはプレフィックス「 FMManaged 」が含まれ、ポリシータイプに応じてポリシー名またはポリシー ID、またはその両方を含むことがあります。 ポリシー名 (PolicyName) とポリシー ID (PolicyId) などのポリシーメタデータは、移行元組織の Firewall Manager 管理者アカウントで AWS CLI の list-policies コマンドを使用してポリシーをリストアップし確認することができます。 移行元組織の Firewall Manager ポリシーによって作成されたリソースや保護を削除する前に、同等の移行先組織のポリシーがアカウントに適用されていることを確認してください。ポリシーが移行元組織のセキュリティ設定と一致し、アカウントの Firewall Manager ポリシーの 準拠ステータス が「 Compliant 」であることを確認してください。これは、ポリシー範囲に該当するアカウントのすべてのリソースにポリシーが正常に適用されていることを意味します。AWS CLI の list-compliance-status コマンドを使用して、指定したポリシーによって保護されているメンバーアカウントとその準拠ステータスの概要を取得できます。 アカウントが移行元組織の Firewall Manager 管理者の管理下から完全に解除され、移行先組織の Firewall Manager 管理者によって完全に管理されるまで最大 5 時間かかる場合があります。 ポリシーによって作成されたリソースや保護の関連付けを識別するために、サポートされているポリシータイプごとに、ポリシーによって作成されたリソースの命名規則と、アカウント内の適用可能なリソースや関連付けのリストを取得するための AWS CLI コマンドを以下にリストアップしました。 AWS Network Firewall ポリシータイプ ポリシーによって、FMManagedNetworkFirewall <policy-name><policy-id><vpc-id> の命名規則でファイアウォールが作成されます。 <policy-name> 、 <policy-id> を移行元組織の AWS Network Firewall タイプのポリシーのポリシー名とポリシー ID に置き換えます。アカウント内のファイアウォールの情報は AWS CLI の list-firewalls コマンドを使用して取得できます。 ファイアウォールポリシーは FMManagedNetworkFirewallPolicy <policy-name><policy-id><vpc-id> の命名規則でポリシーによって作成されます。移行元組織の AWS Network Firewall タイプのポリシーのポリシー名とポリシー ID で <policy-name> 、 <policy-id> を置き換えます。AWS CLI の list-firewall-policies コマンドを使用して、ファイアウォールポリシーの情報を取得できます。AWS Network Firewall ポリシータイプが適用されると、設定されている場合 Network Firewall が使用する VPC エンドポイントを含む Amazon VPC のサブネットが作成されます。サブネットは、AWSFirewallManagerManagedResource を含む命名規則で作成されます。AWS CLI の describe-firewall コマンドを使用して、Network Firewall に関連付けられた 1 つ以上のサブネットを含むファイアウォールの情報を取得することができます。 WAF ポリシータイプ WAF Web ACL は、FMManagedWebACLV2- <policy-name> の命名規則でポリシーによって作成されます。 <policy-name> を移行元組織の WAF タイプのポリシーのポリシー名に置き換えます。AWS CLI の list-web-acls コマンドを使用して、アカウント内の WAF Web ACL を取得することができます。 WAF Classic ポリシータイプ WAF Classic Web ACL は、FMManagedWebACL <policy-id> の命名規則でポリシーによって作成されます。 <policy-id> を移行元組織の WAF Classic タイプのポリシーのポリシー ID に置き換えます。AWS CLI の list-web-acls コマンドを使用して、アカウント内の WAF Classic Web ACL を取得することができます。 Security group – common ポリシータイプ セキュリティグループは、FMManagedSecurityGroup <policy-id><security-group-id><vpc-id> の命名規則でポリシーによって作成されます。 <policy-id> を移行元組織の Security group – common タイプのポリシーのポリシー ID に置き換えます。AWS CLI の describe-security-groups コマンドを使用して、アカウント内のセキュリティグループを取得することができます。セキュリティグループを削除する前に、リソースからセキュリティグループの関連付けを解除しておく必要があります。 Shield Advanced ポリシータイプ Shield Advanced の保護は、FMManagedShieldProtection <policy-id> の命名規則でポリシーによって作成されます。 <policy-id> を移行元組織の Shield Advanced タイプのポリシーのポリシー ID に置き換えます。AWS CLI の list-protections コマンドを使用して、アカウント内の保護を取得することができます。 DNS Firewall ポリシータイプ ポリシーに関連する DNS Firewall ルールグループは AWS RAM を使用して共有されており、アカウントが組織から離脱する際に削除されます。AWS CLI の list-firewall-rule-group-associations コマンドを使用して Amazon VPC との DNS Firewall ルールグループの関連付けをリストアップすることにより、移行元組織の DNS Firewall ルールグループを特定できます。DNS Firewall ルールグループの CreatorRequestId を移行元組織の DNS Firewall ポリシーのポリシー ID と照合します。その後、発見した DNS Firewall グループの関連 ID を使用し、AWS CLI の disassociate-firewall-rule-group コマンドで移行元組織のルールグループとの関連付けを解除できます。 Amazon GuardDuty：guardduty.amazonaws.com Amazon GuardDuty の 信頼されたアクセス を有効にすると、AWS Organizations を使用して組織内のすべてのアカウントの GuardDuty を管理することにより管理を簡素化することができます。GuardDuty 管理者に関連付けられたアカウントが組織を離れると、関連付けられた各リージョンの管理者から自動的に関連付けが解除されます。GuardDuty 管理者アカウントはもうそれらのアカウントを管理できませんが、各アカウントの GuardDuty のステータスは管理者によって設定されたままとなります。また、各アカウントの GuardDuty の調査結果や使用データは、GuardDuty 管理者アカウントには含まれなくなります。 アカウントが移行先組織に参加する場合、組織の GuardDuty を有効にし、GuardDuty の 自動有効化 機能を設定した各リージョンで、アカウントは自動的に GuardDuty 管理者のメンバーアカウントとして関連付けられます。アカウントで GuardDuty が有効になり、ソースの設定および S3 Protection や Kubernetes Audit Logs Monitoring のオプションが設定されます。アカウントがメンバーアカウントとして関連付けられていない場合、GuardDuty コンソールや AWS CLI の create-members コマンドを使用して、必要な各リージョンにおいて管理者アカウントから 手動でメンバーアカウントとして追加 することができます。 追加されたアカウントにおいて AWS CLI の get-administrator-account コマンドを使用し、アカウントの GuardDuty 管理者アカウントの詳細を確認したり、AWS CLI の list-detectors コマンドを使用して GuardDuty の Finding ID を見つけることができます。アカウントがリージョンにおける管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID や関連のステータスが「有効」として表示されません。 AWS Health：health.amazonaws.com AWS Health の 信頼されたアクセス を有効にすると、組織内のすべてのアカウントで AWS Health のイベントを集約できます。Health の組織ビューを設定している場合、アカウントが組織を離れると、アカウントからの新しいイベントは組織ビューに含まれなくなります。ただし既存のイベントは 90 日の制限まで照会できるように、組織ビューに残ります。アカウントが移行先組織に参加すると、アカウントからのイベントは有効な Health の組織ビューに含まれるようになります。 AWS IAM Access Analyzer：access-analyzer.amazonaws.com AWS Identity and Access Management Access Analyzer (IAM Access Analyzer) の 信頼されたアクセス を有効にしている場合、組織全体でリソースベースのポリシーを分析し、信頼ゾーン外のプリンシパルへのアクセスを許可するポリシーを特定できます。アカウントが IAM Access Analyzer の組織における信頼ゾーンの一部である場合、組織を離れると、組織の信頼ゾーンでの調査結果は生成されなくなります。組織の移行中、信頼ゾーンとしてスタンドアロンのアカウントを使用して アナライザーを作成 することもできます。アカウントが移行先組織に参加すると、組織を信頼ゾーンとして設定したアナライザーが既に作成されている場合、アカウントは分析されるリソースのセットに含まれます。 AWS IAM Identity Center（AWS Single Sign-On の後継）： sso.amazonaws.com AWS IAM Identity Center （AWS Single Sign-On の後継）の 信頼されたアクセス を有効にすると、ユーザーがシングルサインオン (SSO) で AWS アカウントやクラウドアプリケーションにアクセスする複数の AWS アカウントを選択できます。アカウントが組織を離れると、IAM Identity Center の使用可能なアカウントのリストに含まれなくなり、共通の権限セットをデプロイしたり、管理アカウントまたは委任管理者アカウントからアクセスを管理することができなくなります。IAM Identity Center は、アカウント内の IAM Identity Center のサービスリンクロールを含むアカウントのメタデータやリソースを自動的にクリーンアップします。アカウントは IAM Identity Center とは連携しなくなり、設定されたアイデンティティソース用の AWS アクセスポータルを使用してアカウントにアクセスすることはできなくなります。 アカウントが移行先組織に参加する場合、アカウントの IAM Identity Center でユーザーやグループに対して必要な権限や割り当てを設定する必要があります。 Amazon Inspector：inspector2.amazonaws.com Amazon Inspector の 信頼されたアクセス を有効にすると、組織でアカウントを管理し、組織を代表してタスクを実行することができます。このタスクには、メンバーアカウントのスキャンの有効化または無効化、組織全体で集約された検出結果データの表示、抑制ルールの作成と管理が含まれます。Inspector 管理者に関連付けられたアカウントが組織を離れると、関連付けられた各リージョンの管理者から自動的に関連付けが解除されます。Inspector の管理者アカウントは、アカウントを管理することはできなくなりますが、スキャン設定を含むアカウント内の Inspector のステータスは、管理者によって設定されたままとなります。アカウントの Inspector の検出結果は、Inspector の管理者アカウントには含まれなくなります。 アカウントが移行先組織に参加する場合、組織で Inspector を有効にしてスキャンの 自動有効化 を設定している各リージョンごとに、アカウントは自動的に Inspector のメンバーアカウントとして関連付けられます。アカウントで Inspector が有効になり、設定されていれば、EC2 のスキャンや ECR のコンテナのスキャンの有効化を含む選択されたスキャンの設定が適用されます。アカウントが関連付けられていない場合、管理者アカウントと各リージョンで Inspector のコンソールや AWS CLI の associate-member コマンドを使用して 手動でメンバーアカウントとして登録 することができます。追加されたアカウントの権限を使用して、AWS CLI の get-delegated-admin-account コマンドを使用してアカウントに関連づけられた Inspector の管理者アカウントの詳細を確認することができます。アカウントがリージョンの管理者に関連付けられていない場合、コマンドの出力は管理者のアカウント ID や「有効」という関係ステータスを表示しません。 AWS License Manager : license-manager.amazonaws.com , license-manager.member-account.amazonaws.com AWS License Manager の 信頼されたアクセス を有効にすると、組織全体でのライセンス使用とリソース検出を管理するために、 クロスアカウントのリソース検出 を有効にできます。 アカウントが組織を離れると、License Manager はアカウントのライセンス使用を管理するためのリソース検出を行うことができなくなります。License Manager のセルフマネージドライセンスをアカウントと共有している場合、License Manager によって設定された AWS Resource Access Manager（AWS RAM） の共有は、自動的にアカウントから解除されます。 セルフマネージドライセンス は、当該アカウントと共有されなくなります。必要に応じて、License Manager による AWS RAM 共有の設定を変更し、削除されたアカウントを追加してセルフマネージドライセンスの共有を継続することができますが、削除されたアカウントで License Manager の共有の招待を受け入れる必要があります。 アカウントが移行先組織に参加する場合、組織の全アカウントのライセンス使用を管理するために、License Manager のクロスアカウントのリソース検出を有効にした各 AWS リージョンで、アカウントは自動的にリソース検出の範囲に含まれます。組織でセルフマネージドライセンスを共有しており移行したアカウントと共有したい場合、アカウントを含めるために License Manager による AWS RAM 共有の設定を変更する必要があるかもしれません。アカウントは組織のメンバーとして、License Manager の AWS RAM 共有に参加する招待を自動的に受け入れます。このブログシリーズの第 1 部では、オーナーアカウントとコンシューマーアカウントの両方で、組織間の移動時の考慮事項と AWS RAM リソース共有について取り上げています。本ブログでは AWS Marketplace セクションで、License Manager を使用して組織と ライセンス許諾 を配布する方法についても取り上げています。 Amazon Macie：macie.amazonaws.com Amazon Macie の 信頼されたアクセス を有効にすると、組織内のアカウントの Macie を有効化し集中管理することができます。Macie 管理者 として関連づけられたアカウントが組織を離れると、各 AWS リージョンにおいて管理者から自動的に 関連付けが解除 されます。また、 Macie 管理者アカウント は、アカウントの管理を行ったり、特定の Macie の設定、データ、リソースにアクセスすることはできなくなります。アカウントの Macie のステータスは、管理者によって以前に設定されたまま保持されます。アカウントの Macie サマリーと所見は、Macie 管理者アカウントには含まれなくなります。 アカウントが移行先組織に参加する場合、組織の Macie を有効にし、 自動有効化 を設定した各 AWS リージョンで、Macie はアカウントで有効になり、自動的に Macie 管理者メンバーアカウントとして関連付けられます。アカウントが関連付けられていない場合、管理者アカウントで必要な各 AWS リージョンを使用し、Macie コンソールまたは AWS CLI の create-member コマンドを使用して 手動でメンバーアカウントとして追加 できます。 追加されたアカウントの権限で AWS CLI の get-administrator-account コマンドを使用し、Macie 管理者アカウントの詳細を確認できます。アカウントが AWS リージョンの管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID やステータス「Enabled」は含まれません。 AWS Marketplace : license-management.marketplace.amazonaws.com AWS Marketplace の 信頼されたアクセス を有効にすると、 Marketplace 製品サブスクリプションの 付与されたライセンス を組織のメンバーアカウント間で配布することができます。Marketplace の付与されたライセンスは、使用権、つまりエンタイトルメントを配布するために AWS License Manager を使用して組織と共有されます。 アカウントが組織を離れる際、そのアカウントが License Manager で共有された Marketplace 製品から付与されたライセンスエンタイトルメントの受領者である場合、そのエンタイトルメントはアカウントで利用できなくなります。関連する Marketplace サブスクリプションは、組織を離れたアカウントで製品を起動するために使用することはできなくなります。組織または組織単位 (OU) の一部としてアカウントにライセンスが配布された場合、そのアカウントのライセンス付与ステータスは「削除済み」 (付与者によって削除) と表示されます。個々のアカウント ID を使用して配布された場合は、ライセンス付与ステータスは「無効」（使用するためにアクティブ化されていない）と表示されます。サブスクリプションを使用して起動した製品は、Amazon Machine Image（AMI）、コンテナ、機械学習、データ製品に関連する AWS リソースを含めアカウントに残ります。 アカウントが移行先組織に参加すると、License Manager の共有エンタイトルメントが配布され、組織または OU の Marketplace 製品の使用権がアカウントに設定されます。組織の一部として、付与は自動的に受け入れられ、アカウントによって使用されるためにアクティブ化されます。 Marketplace 製品のサブスクライバーアカウントを移行先組織に移動し、License Manager を使用して組織のメンバーアカウントにエンタイトルメントを配布している場合、受領者アカウントが組織から削除されると、ライセンスは受領者アカウントに配布されなくなります。受領者アカウントでライセンスを使用できる能力を示すグラントステータスは「無効」（使用のためにアクティブ化されていない）と表示されます。サブスクライバーと同じ移行先組織にグラントの受領者アカウントを移動する場合、まず受領者アカウントで License Manager を使用してサブスクライバーアカウントからのグラントステータスを確認します。グラントステータスが「無効」であれば、ライセンスをアクティブ化することを選択できます。グラントステータスが「削除済み」であれば、グラントの受領者アカウントに付与するためにサブスクライバーアカウントで新たなグラントを作成することができます。 移行先組織に移動するアカウントが License Manager 委任管理者 アカウントである場合、そのアカウントが組織を離れる前に License Manager の委任管理者を解除する必要があります。委任管理者を解除すると、アカウント間のリソース検出とライセンス管理は削除されます。アカウントが Marketplace のサブスクライバーアカウントで、License Manager のグラントを使用して組織、OU、または個々のアカウントにエンタイトルメントを配布している場合、受領者アカウントのグラントステータスは「無効」（使用するためにアクティブ化されていない）と表示されます。アカウントが移行先組織に参加し、License Manager の委任管理者が設定されていない場合、そのアカウントを委任管理者として登録することを選択できます。アカウントを登録すると、組織全体、OU または個々のアカウントに Marketplace ライセンスのエンタイトルメントを配布するためのグラントを作成できます。アカウントを委任管理者に登録しない場合は、組織内の必要な個々のアカウントに対して 1 つ以上のグラントを作成できます。 AWS Network Manager：networkmanager.amazonaws.com AWS Network Manager の 信頼されたアクセス を有効にすると、任意の AWS アカウントに対して単一のグローバルネットワークを作成し、1 つまたは複数のアカウントから 1 つ以上の AWS Transit Gateway を登録することができます。アカウントが組織を離れると、Network Manager はそのアカウント内のネットワークリソースを一元的に管理、監視、可視化することができなくなります。Network Manager のグローバルネットワークから登録された Transit Gateway は、登録解除されます。Transit Gateway アタッチメント（ VPC、VPN 接続、AWS Direct Connect Gateway など）は、グローバルネットワークに含まれなくなります。 アカウントが移行先組織に参加する場合、Network Manager のグローバルネットワークにアカウントが保持する 1 つまたは複数の Transit Gateway を含めるには、各 Transit Gateway を登録する必要があります。 AWS Security Hub：securityhub.amazonaws.com AWS Security Hub の 信頼されたアクセス を有効にすると、組織のすべてのアカウントで自動的に Security Hub を有効にし、Security Hub のチェックと検出結果の対象範囲を拡大することができます。Security Hub 管理者に関連付けられているアカウントが組織を離れると、それぞれの AWS リージョンで管理者から自動的に関連づけが解除されます。 Security Hub 管理者アカウント は組織を離れたアカウントを管理できなくなりますが、有効にされた標準やコントロールは管理者が以前に設定したままとなります。アカウントの Security Hub 検出結果やデータは、Security Hub 管理者アカウントに含まれなくなります。 アカウントが移行先組織に参加すると、その組織で Security Hub を有効にし、 自動有効化 を設定した各 AWS リージョンについて、そのアカウントは自動的に Security Hub 管理者のメンバーアカウントとして関連付けられます。Security Hub はアカウントで有効にされ、設定されている場合は選択された標準とコントロールが有効になります。メンバーアカウントとして関連付けられていない場合は、必要な各 AWS リージョンについて、管理者アカウントの Security Hub コンソールを使用して、 手動でメンバーアカウントとして追加 することができます。 参加したアカウントの認証情報で AWS CLI の get-administrator-account コマンドを使用して、アカウントの Security Hub 管理者アカウントの詳細を確認できます。 アカウントが AWS リージョンの管理者と関連付けられていない場合、コマンドの出力には管理者のアカウント ID やメンバーステータス「 Enabled 」は含まれません。 Amazon S3 Storage Lens: storage-lens.s3.amazonaws.com Amazon S3 Storage Lens の 信頼されたアクセス を有効にすると、組織内のすべての AWS アカウントでストレージ、使用状況、アクティビティのメトリクスを収集および分析できます。 アカウントが組織を離れると、組織のスコープで作成した ダッシュボード はそのアカウントからのデータは更新されなくなりますが、Amazon S3 Storage Lens の 保持期間 に従って過去のデータが参照可能です。アカウントのデフォルトダッシュボードは、アカウントのデータによって引き続き更新されます。 アカウントが移行先組織に参加すると、ダッシュボードのスコープに組織内の全アカウントが含まれる場合、そのアカウントは自動的に S3 Storage Lens ダッシュボードに含まれるようになります。 AWS Service Catalog：servicecatalog.amazonaws.com AWS Service Catalog の 信頼されたアクセス を有効にすると、組織全体で ポートフォリオ の共有や 製品 のコピーを簡単に行うことができます。 移行元組織で Service Catalog 共有ポートフォリオ を利用している場合、アカウントが組織を離れてもプロビジョニングされた製品は保持されます。組織のエンティティ（組織のルート、組織単位（ OU ）、または組織アカウントなど）を使用して共有された Service Catalog ポートフォリオは、そのアカウントから自動的に共有解除されます。組織からアカウントを削除した後、そのアカウントでプロビジョニングされた Service Catalog 製品の管理を続ける必要がある場合、個別のアカウント用にポートフォリオ共有を作成できます。共有されたアカウントでは、ポートフォリオをインポートし、アカウント内のプリンシパルで製品に対する権限を更新する必要があります。このブログシリーズの第 2 部では、Service Catalog 共有製品を別の組織に移行する方法について説明しています。 Service Catalog AppRegistry は、AWS Resource Access Manager (AWS RAM) を使用してアプリケーションと属性グループを共有します。アカウントが組織を離れると、組織エンティティを使用して共有された Service Catalog AppRegistry リソースは、そのアカウントから共有解除されます。共有アプリケーションに追加されたアカウントの関連リソースコレクションや属性グループはすべて削除されます。このブログシリーズの第 1 部では、所有者と消費者アカウントの両方に対して、組織間で移動する際の AWS RAM リソース共有と考慮事項について説明しています。 アカウントが移行先組織に参加すると、組織ルート、組織単位、組織アカウントなどの組織エンティティを使用して共有されている Service Catalog ポートフォリオ、AppRegistry アプリケーション、属性グループリソースは自動的にアカウントに共有されます。 Service Quotas：servicequotas.amazonaws.com Service Quotas の 信頼されたアクセス を有効にすると、アカウント作成時に自動的にクォータ増加をリクエストするためのクォータリクエストテンプレートを作成することができます。アカウントが組織を離れた場合、クォータリクエストテンプレートから適用されたクォータリクエストは影響を受けません。クォータリクエストテンプレートは、組織内で新しく作成されたアカウントにのみ適用されます。 アカウントが移行先組織に参加した場合、既存のアカウントのクォータは影響を受けません。 AWS Systems Manager: ssm.amazonaws.com , opsdatasync.ssm.amazonaws.com AWS Systems Manager の 信頼されたアクセス を有効にすると、組織内のすべての AWS アカウントで Systems Manager Explorer 、 Change Manager 、 OpsCenter の機能を使用できます。 複数のアカウントからデータを収集するために、Systems Manager Explorer リソースデータ同期 を作成した場合、アカウントが組織を離れると、そのアカウントはリソースデータ同期の対象から除外され、Systems Manager Explorer ダッシュボードに同期される運用データに含まれなくなります。アカウントが移行先組織に参加すると、そのアカウントの Change Manager 変更要求は Systems Manager Explorer の既存のリソースデータ同期に含まれるようになります。 Systems Manager Change Manager を設定した場合、複数の AWS アカウントおよび AWS リージョン全体で変更を管理できます。アカウントが組織を離れると、そのアカウントに対する変更管理フレームワークを使用することはできなくなり、アプリケーションの設定やインフラストラクチャへの運用変更のリクエスト、承認、実装、報告ができなくなります。承認された後すぐに、またはスケジュールされた時間に実行されるよう設定された既存の変更リクエストは、そのアカウントを対象としなくなります。アカウントが対象の組織に参加すると、アカウント ID が指定されているか、変更リクエストで指定された組織単位（OU）の一部である場合に、Change Manager の変更リクエストはスケジュール通り、または承認されたとおりに実行されます。 組織メンバーアカウント間で OpsCenter を使用して OpsItems を操作するための Systems Manager OpsCenter を設定した場合、アカウントが組織を離れると、OpsCenter はそのアカウントの OpsItems を作成、表示、更新したり、OpsItems で指定された AWS リソースの詳細情報を表示したり、 Systems Manager Automation ランブックを開始することはできなくなります。 アカウント間で OpsItems を操作するための権限を設定し、 AWS Systems Manager ユーザーガイド にある アカウント間で OpsItems を操作するためのアクセスと権限を設定する ガイドに従った場合、アカウント間で OpsItems を操作するための権限は AWS CloudFormation スタックセットを使用して設定され、アカウント間で OpsItems を操作するためのアクセス許可をユーザーに与える OpsItemGroup リソースポリシーと IAM 実行ロールを作成します。スタックセットは組織管理アカウントで作成され、各組織メンバーアカウントにポリシー OpsItemCrossAccountResourcePolicy を持つ OpsItemCrossAccountExecutionRole が作成されます。 組織からアカウントを削除する前に、組織管理アカウントを使用して AWS CloudFormation コンソールで StackSet の自動デプロイ設定を確認し、必要に応じて「アカウント削除動作」を「スタックの削除」に設定します。これにより、組織からアカウントが削除された場合、アカウント内のスタックインスタンスが削除されます。これにより、組織管理アカウントと設定済みの Systems Manager 委任管理者アカウントで操作するために設定された OpsItemGroup リソースポリシー、および構成された Systems Manager 委任管理者アカウントが削除されます。 アカウントが対象組織に参加すると、Systems Manager ガイドに従っている場合、StackSet はアカウント ID がスコープ内であれば自動的にデプロイされ、移行先組織の管理アカウントおよび Systems Manager 委任管理者アカウントで操作するために、 OpsItemGroup リソースポリシーと IAM 実行ロールが設定されます。 Systems Manager ガイド（ アカウント間で OpsItems を操作するためのアクセスと権限を設定する ）を使用せずにアカウント間で OpsItems を操作する権限を設定した場合、アカウント間で OpsItems を操作する権限を更新する必要があります。これには、作成された AWS IAM ロールと OpsItemGroup リソースポリシーが含まれます。 アカウントが組織の一部でなくなった場合、IAM ロールの信頼関係を更新し、信頼されたエンティティの プリンシパル および 条件 を移行先組織の管理アカウント ID、および設定されている場合は委任管理者アカウント ID に設定します。また、AWS アカウントが OpsCenter の運用作業項目（OpsItems）を表示および操作できるようにする OpsItemGroup リソースポリシーも更新する必要があります。リソースベースの JSON ポリシー内のプリンシパル要素を変更し、移行先組織アカウント ID および設定されている場合は Systems Manager 委任管理者アカウント ID を指定します。AWS CLI の get-resource-policies コマンドを使用して OpsItemGroup リソースポリシーを表示し、 put-resource-policy コマンドを使用してリソースポリシーを作成または更新できます。両方のコマンドで、 OpsItemGroup リソースポリシーの Amazon リソースネーム（ARN） を指定します。これは、arn:aws:ssm: <region>:<account-ID> :opsitemgroup/default の形式で、<region> はポリシーを適用する OpsItemGroup リソースの AWS リージョン、<account-ID> はリソースポリシーを更新する AWS アカウント ID です。Systems Manager OpsCenter で OpsItemGroup リソースポリシーをサポートする各 AWS リージョンでリソースポリシーを更新する必要があります。 アカウントが移行先組織に参加すると、アカウント間で OpsItems を操作する権限を設定した場合、管理アカウントまたは Systems Manager 委任管理者アカウントは、アカウント内の OpsItems を操作するために IAM ロールとリソースポリシーを設定できます。 AWS Trusted Advisor：reporting.trustedadvisor.amazonaws.com AWS Trusted Advisor の 信頼されたアクセス を有効にすると、組織内のすべてのアカウントの Trusted Advisor の チェック 結果を受け取り、チェックの概要と影響を受けるリソースを確認するためのレポートをダウンロードすることができます。組織ビューを有効にしている場合、組織からアカウントを削除すると、Trusted Advisor はそのアカウントのチェックを表示または報告できなくなります。アカウントが移行先組織に参加すると、そのアカウントは有効な Trusted Advisor 組織ビューに含まれます。 AWS Well-Architected Tool：wellarchitected.amazonaws.com AWS Well-Architected Tool の 信頼されたアクセス を有効にすると、AWS Well-Architected Tool リソースを組織の他のメンバーと共有するプロセスを簡単にすることができます。 ワークロード または カスタムレンズ に対して Well-Architected Tool 組織または OU 共有を作成した場合、アカウントが組織を離れると、ワークロードまたはカスタムレンズはそのアカウントとの共有が解除されます。ワークロードまたはカスタムレンズをアカウントと共有し続ける必要がある場合は、対象の AWS アカウント ID またはアカウントの IAM ユーザーを使用して共有を作成できます。ワークロードまたはカスタムレンズを共有しているアカウントが組織を離れると、そのワークロードまたはカスタムレンズは組織または OU との共有が解除されます。組織メンバーアカウントとの共有を継続する必要がある場合は、対象の AWS アカウント ID またはアカウントの IAM ユーザーを使用して共有を作成できます。 個々の AWS アカウントや IAM ユーザーに対して作成されたワークロードまたはカスタムレンズの共有は、共有アカウントが組織を離れても削除されません。 アカウントが移行先組織に参加すると、組織または該当する OU に対して作成された既存のワークロードまたはカスタムレンズ共有に含まれるようになります。 Amazon VPC IP Address Manager（IPAM）： ipam.amazonaws.com Amazon VPC IP Address Manager (IPAM) の 信頼されたアクセス を有効にすると、組織全体で IP アドレス使用状況を監視し、メンバーアカウント間で IP アドレスプールを共有することができます。組織メンバーアカウントからのデータレプリケーションを許可するオプションを使用して IPAM を作成した場合、アカウントが組織を離れると、IPAM はそのアカウント内の IP 使用量を監視できなくなります。 アカウントリソースは IPAM スコープに含まれなくなりますが、IPAM プールからの CIDR 割当はアカウントリソースに割り当てられたままであり、IPAM プールによって使用されます。組織からアカウントを削除する前に、必要に応じて、IPAM コンソールまたは AWS CLI release-ipam-pool-allocation コマンドを使用して、IPAM プールから CIDR 割り当てを削除できます。アカウントが組織に属していない場合、プールから CIDR 割り当てを削除することはできません。IPAM プールから CIDR 割り当てを削除しても、アカウントリソースに割り当てられた CIDR は削除されません。組織間の移行中は、 IP 使用状況を継続して監視するためにスタンドアロンアカウントに IPAM を作成 できます。 アカウントが移行先組織に参加すると、組織メンバーアカウントからのデータレプリケーションを許可するために作成された IPAM によって、アカウントは自動的に IP アドレス使用状況の監視対象となります。組織にアカウントを移動する前に、IPAM プールの IPAM CIDR 管理が「自動的に発見されたリソースをインポートする」に設定されていることを確認します。組織に追加するアカウントの発見されたリソースをインポートするために、自動インポートを許可することをお勧めします。リソースに対する重複しない CIDR は IPAM プールから割り当てられますが、アカウント内のリソースの CIDR は変更されません。アカウントリソースの CIDR が IPAM プールからプロビジョニングされていないか割り当てられていない場合、CIDR の IPAM コンプライアンスステータスは管理されていない状態になります。このブログシリーズの第 2 部では、IPAM の委任管理者アカウントと、これがアカウントリソースの IPAM プール割り当て CIDR にどのように影響するか議論します。 結論 本ブログでは、AWS Organizations の信頼されたアクセスをサポートする AWS サービスについて説明しました。1 つ以上の互換性のある AWS サービスが、組織で信頼されたサービスとして構成されているかどうかを識別する方法を学びました。また、組織からアカウントを削除し、別の組織に追加する場合、信頼されたアクセスを有効にした AWS サービスに関して、考慮すべき点とアクションを学びました。 このブログシリーズでは、Organizations のさまざまな機能を順を追って説明し、Organizations を使用して AWS アカウントをある組織から別の組織に移動する場合のガイダンスと考慮事項を提供します。 シリーズの 第 1 部 では、Organizations のさまざまな機能を説明し、Organizations を使用して AWS アカウントを組織から別の組織に移動する場合のガイダンスと考慮事項を提供しました。 シリーズの 第 2 部 では、AWS Organizations の委任管理者を特定し、1 つ以上の互換性のある AWS サービスの委任管理者として登録されているアカウントを移動したい場合の影響とアクションについて説明しました。 ブログ著者について : Karl Schween Karl Schween は、Amazon Web Services のプリンシパル・ソリューション・アーキテクトです。顧客のビジネス課題に対応する、拡張性、柔軟性、耐障害性の高いクラウドアーキテクチャの構築を支援しています。 Deepa Pahuja Deepa Pahujaは、Amazon Web Services のシニアソリューションアーキテクトです。クラウドネイティブサービスを利用してビジネス上の問題を解決するためのアーキテクチャを構築することを楽しんでいます。仕事以外では、Deepa は新しい場所の探索、ハイキング、ダンスを楽しんでいます。 翻訳はプロフェッショナルサービス本部の野田が担当しました。原文は こちら です。

はじめに 本日 (2024 年 2 月 21 日)、 AWS Amplify Hosting のカスタム SSL 証明書の一般提供を発表できることを嬉しく思います。この機能を使うことで AWS Certificate Manager (ACM) から独自の SSL 証明書を Amplify ドメインに設定することができます。 Amplify はお客様に代わって SSL/TLS 証明書を管理し、アプリのユーザー数が 100 人であろうと 10 万人であろうと、HTTPS で お客様のドメインに安全にトラフィックを提供します 。Amplify Hosting が生成した SSL 証明書は、ほとんどのお客様のユースケースに適していますが、一部のお客様からは、独自の証明書をドメインに関連付ける機能を要望されていました。カスタム SSL 証明書機能は、お客様の Amplify ドメインで以下のユースケースを可能にしますが、これに限定されるものではありません。 サードパーティの認証局 (CA) が発行した証明書を使用したい場合 セキュリティ強度を高めるために、証明書の TLS バージョンと公開鍵暗号化アルゴリズムを設定したい場合 www.example.com、www.example.ne など、複数の完全修飾ドメイン名 (FQDN) で証明書を共有したい場合 ウォークスルー 本記事では、IT コンプライアンスのニーズを満たすために、ACM 証明書をリクエストまたはインポートし、Amplify ドメインに関連付ける方法を説明します。 前提条件 このウォークスルーを始める前に、以下のステップを実施しておく必要があります。 Amplify Hosting に Web アプリをデプロイする。Web アプリの構築、デプロイ、ホスティングの詳細については、 AWS Amplify Hosting ユーザーガイド を参照してください。 カスタムドメインを作成する。所有権を確認するプロセスを簡素化するために、Amazon Route 53 で作成したドメインを使用することをお勧めします。 カスタムドメインを Amplify アプリに関連付ける。Amplify Hosting でカスタムドメインを設定する方法は カスタムドメインのセットアップ をご覧ください。 us-east-1 で ACM 証明書をプロビジョニングする Amplify で使用する ACM 証明書をプロビジョニングするには、2 つのオプションがあります。 ACM で新規の証明書をリクエストする サードパーティの認証局から発行された既存の証明書をインポートする 米国東部 (バージニア北部、us-east-1) リージョンで証明書をプロビジョニングする必要があります。詳細は Amazon CloudFront Developer Guide を参照してください。 新規の証明書のリクエスト ACM コンソール (us-east-1) にアクセスし、 Request a certificate を選択します。 Request a public certificate を選択し、 Next を選択します。プライベート証明書は Amplify ドメインではサポートされていません。 Fully qualified domain name の下に、ルートドメイン名 ( example.com など) とワイルドカードサブドメイン名 ( *.example.com など) の両方を入力します。 ワイルドカードサブドメイン名は、Amplifyドメインに設定したサブドメインで証明書を使用するために必要です。 Validation method 、 Key algorithm 、 Tags に必要な設定を入力し、 Request を選択します。 ACM 証明書がプロビジョニングされました。バナーの View certificate を選択すると、ドメインの所有権を確認するための次のステップが表示されます。 カスタムドメインが同じ AWS アカウントの Route 53 で作成されている場合は、 Create records in Route 53 を選択します。 Create records を選択します。これにより、カスタムドメインの Route 53 ホストゾーンに CNAME レコードが作成され、ACM はあなたがドメインを所有していることを確認することができます。 ドメインが Route 53 ではなくサードパーティのドメインレジストラで作成された場合、これらの CNAME レコードを手動で追加する必要があります。詳細については、登録しているドメインレジストラのドキュメントを参照してください。 しばらくすると、証明書が発行され、ドメインの検証に成功したことが表示されます。 既存の証明書のインポート サードパーティ CA が発行した証明書をすでにお持ちの場合は、 Import a certificate を選択します。 サードパーティ証明書には、ルートドメイン名 ( example.com など) とワイルドカードサブドメイン名 ( *.example.com  など) の両方を指定する必要があります。ワイルドカードサブドメイン名は、Amplify ドメインに設定したサブドメインで証明書が動作するために必要です。 Certificate body 、 Certificate private key 、 Certificate chain (オプション) を入力し、 Next を選択します。このステップでタグを追加することもできます。 Import を選択します。 インポートされた証明書が ACM でプロビジョニングされます。 Amplify ドメインで ACM 証明書を使用する Amplify ドメインの管理ページで、カスタムドメインを見つけ、 Manage domain を選択します。 Choose your certificate で Custom SSL certificate を選択し、ドロップダウンメニューから証明書を選択し、 Update を選択します。証明書 ID が、このウォークスルー用に ACM でプロビジョニングした証明書に対応していることを確認します。 Amplify は、ACM 証明書をドメインに関連付けるプロセスを開始し、関連付けのステータスを表示します。 クリーンアップ Amplify ドメインで Amplify が管理する証明書を使用 カスタム SSL 証明書の代わりに、Amplify が管理する証明書を使用するように切り替えることができます。Amplify ドメイン管理ページで、カスタムドメインを見つけ、ドメインの管理を選択します。 AWS Amplify Hosting のドメイン管理ページでカスタムドメイン ( olileung.people.aws.dev ) ボックスの右上に Manage domain ボタンがあります。 Choose your certificate で Amplify managed certificate を選択し、 Update を選択します。 Amplify は、ドメイン上で ACM 証明書を Amplify が管理する証明書に置き換えるプロセスを開始し、更新のステータスを表示します。 ACM 証明書の削除 ACM 証明書を削除することもできます。証明書の ACM ページで、証明書が使用されていないことを確認し、 Delete を選択します。 ポップアップで「delete」と入力し、 Delete を選択します。これで証明書は ACM から削除されます。 まとめ 本記事では、ACM 証明書をリクエストまたはインポートし、Amplify ドメインに関連付ける方法を紹介しました。これにより、ドメインと IT コンプライアンスのニーズをより詳細に管理できるようになります。 サードパーティの証明書プロバイダから証明書をインポートした場合は、有効期限が切れる前に証明書を再インポートする必要があります。詳細については、証明書の再インポートに関する ACM ユーザーガイド を参照してください。 Amplify ドメインに関連付けられた証明書は、そのサブドメインを保護します。詳細については、 サブドメインの管理に関する Amplify Hosting ユーザーガイド を参照してください。 最後に、Next.js, Nuxt, React, Angular, Vue、またはその他のフロントエンドアプリを Amplify Hosting にデプロイして、コミュニティの Discord に参加して感想を聞かせてください！ 本記事は 「 Bring your own SSL certificate to AWS Amplify Hosting 」 を翻訳したものです。 著者について Oliver Leung, Software Development Engineer, Amplify Hosting Oliver Leung は AWS Amplify Hosting の Software Development Engineer (SDE) です。Oliver は、AWS の信頼性と利便性に裏打ちされたフロントエンドの Web アプリケーションを、顧客がより簡単にホストできるようにする機能を構築しています。余暇には Amazon Jazz Band でアルトサックスを演奏したり、和太鼓を演奏しています。 Matt Auerbach, Senior Product Manager, Amplify Hosting Matt Auerbach はニューヨークを拠点とする AWS Amplify チームのプロダクトマネージャーです。彼は、プロダクトとオファリングに関して開発者を教育し、支援とフィードバックのための主要な窓口として活動しています。Matt は温厚なプログラマーで、テクノロジーを使って問題を解決し、人々の生活を便利にすることを楽しんでいます。しかし、夜は…ほとんど同じことをしています。Matt の X アカウントは @mauerbac です。以前は Twitch, Optimizely, Twilio でデベロッパーリレーションを担当していました。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

ビデオゲームの制作は、プロジェクトのさまざまな側面にわたって多様なチームが協力することを必要とする複雑なプロセスです。近年発生した世界的な出来事により、開発環境はますますハイブリッド化しています。チームメンバーは現在、仮想ワークステーションを採用するだけでなく、自宅とオフィスの両方の場所から業務を行っています。大規模で没入感のあるゲームの開発において、効率的なアセット取得とパフォーマンス最適化を確実にするために、キャッシングは不可欠です。例えば、Unreal Engine はこの目的のために派生データキャッシュ (Derived Data Cache (DDC)) と呼ばれるメカニズムを使用します。クラウドで共有 DDC を構成すると、仮想ワークステーションをより高速な応答時間とより効率的な開発プロセスで補完します。 Unreal Engine の DDC は、生成に計算コストがかかるデータのストレージメカニズムとして機能します。このデータは保持され、変更が発生しない限りは再生成の必要はありません。 DDC には、エンジンがロード時に迅速にアクセスできるテクスチャ圧縮、シェーダコンパイル、ジオメトリ変換など、処理済みの派生アセットデータを格納します。これは特に大規模なチームとプロジェクトにとって重要であり、頻繁なアセットの再コンパイルの必要性を減らし、時間と計算リソースを節約します。 DDC は単一のユーザーのローカルに置くことも、開発パイプラインの効率を向上させるためネットワーク経由でチーム全体で共有することもできます。クラウドベースの共有 DDC を設定すると、Unreal Engine プロジェクトのスケーラビリティが向上します。 AWS ストレージサービスを活用することで、どこからでもキャッシュされたデータを簡単に共有およびアクセスできます。この記事では Amazon FSx for OpenZFS での共有 DDC に焦点を当てます。 Amazon FSx for OpenZFS は、人気の高い OpenZFS ファイルシステム上に構築されたフルマネージドな共有ストレージです。これは AWS 上でトップクラスの価格 / パフォーマンスを提供する、シンプルで強力な共有 NFS ファイルストレージです。 それぞれの Amazon FSx for OpenZFS には、高速なインメモリキャッシュを備えたファイルサーバーがあります。 インメモリキャッシュに加え、Single-AZ 2 ファイルシステムは、大きな DDC を格納してより高速な応答時間を実現するために使用できる、追加の NVMe キャッシュを提供します。Amazon FSx for OpenZFS は OpenZFS ファイルシステムの ARC と L2ARC を活用して、インメモリと NVMe キャッシュからのデータアクセスを強化し、より高速なデータアクセスとパフォーマンスの向上を実現します。 Amazon FSx for OpenZFS はマルチ AZ への展開が可能ですが、代わりに Single-AZ 2 を使用して Unreal Engine の DDC のコストを最適化できます。DDC は重要ではなく簡単に再生成できるため、Single-AZ が適しています。 DDC の取得には、高いリクエストレートの時間帯とアイドル時間が長い時間帯があります。 Amazon FSx for OpenZFS にはベースライン速度を超えてバーストする機能があります。 これはネットワーク I/O およびディスク I/O 操作の両方を、 I/O クレジットのメカニズムの助けを借りて処理します。 Amazon FSx for OpenZFS のパフォーマンスの詳細は、 ユーザードキュメント で確認できます。 Amazon FSx for OpenZFS を Unreal Engine の DDC として設定する このブログでは、クライアントとして Windows Server 2019 を実行する Amazon WorkSpaces を使用し、DDC を作るのに Lyra を使用します ( Lyra は Epic Games の作ったモジュラー式のサンプルゲームプロジェクトです ) 。 ステップ 1: Amazon FSx for OpenZFS ファイルシステムの作成と構成 AWS マネジメントコンソールで Amazon FSx に移動し、「ファイルシステムを作成」をクリックします。「ファイルシステムタイプを選択」で「 Amazon FSx for OpenZFS 」を選択します。次に「スタンダード作成」を選びます。 Amazon VPC とサブネットを選択し、デプロイタイプ「 Single-AZ 2 」でファイルシステムを作成します。このタイプは NVMe をサポートしています。 Amazon FSx for OpenZFS ファイルシステムを作成するための構成は次のとおりです。 ステップ 2: ネットワークアクセスの構成 Amazon FSx for OpenZFS ファイルシステムとワークステーション間の通信を許可するには、適切なネットワーク構成が不可欠です。 AWS コンソールの「ネットワークとセキュリティ」タブで、Amazon FSx for OpenZFS ファイルシステムに関連付けられた Elastic Network Interface (ENI) を見つけます。 これは、ファイルシステムのトラフィックを処理するネットワークインターフェースです。 NFS プロトコルを介した適切な通信のため、Amazon FSx for OpenZFS で必要なポートを設定する必要があります。 ファイルシステムのアクセス制御に関する詳細は こちら をご参照ください。 WorkSpaces のセキュリティグループからのアクセスを許可するため、Amazon FSx for OpenZFS の ENI のセキュリティグループにインバウンドルールを追加します。 ステップ 3: ワークステーションへの Amazon FSx for OpenZFS のマウント Amazon FSx for OpenZFS ファイルシステムとワークスペース間の通信を容易にする為、設定した Amazon FSx for OpenZFS ファイルシステムをワークスペースにマウントします。 Amazon FSx for OpenZFS ファイルシステムをクリックし、「 アタッチ 」をクリックすると、ファイルシステムをワークステーションにマウントするための手順が表示されます。 この記事では Windows ベースの WorkSpaces を使用し、ファイルシステムを Z ドライブとしてマウントしています。 Windows クライアントへの OpenZFS ボリュームのマウントには NFS v3 プロトコルを利用します。 そのためにまず　 NFS クライアントをインストール する必要があります。 ワークステーションで PowerShell を管理者として開き、NFS　クライアントをインストールします。 Install-WindowsFeature -Name NFS-Client コマンドプロンプトを開き次のコマンドを実行します。ファイルシステム ID を実際のものに置き換えてください (「 Z: 」を別の使用可能なドライブレターに置き換えることもできます )。 mount \\<filesystemID>.fsx.<region>.amazonaws.com\fsx\ Z : ステップ 4: Unreal Engine エディタの DDC に Amazon FSx for OpenZFS を設定する ファイルシステムが準備できてワークステーションにマウントされたので、Unreal Engine エディタで Amazon FSx for OpenZFS を DDC として認識するように設定できます。 Unreal Engine エディタで 編集 、 エディタの環境設定 の順に移動します。 Unreal Engine エディタの設定で、「 Global Shared DDC Path 」を探します。 ここに、設定した Amazon FSx for OpenZFS のマウントパスを入力します。 ステップ 5: 構成の検証 すべてが正しく設定されていることを確認するには、DDC を再計算されたゲームデータで満たす必要があります。 ビルドのクックを開始すると、マウントされた Amazon FSx for OpenZFS のパスに DDC が入るのがわかります。 実行する必要のあるコマンドは次のとおりです。プレースホルダーをエディタとプロジェクトへの実際のパスに置き換えてください。 "<path to Editor>\UnrealEditor.exe" "<Path to project>\LyraStarterGame" -run=DerivedDataCache -fill 共有キャッシュとしてマウントされた Amazon FSx for OpenZFS に、派生データが入力されているのがわかります。 クリーンアップ プロジェクト完了後の追加コストを避けるために、クリーンアッププロセスに取り組むことが重要です。 まず、エンジンが DDC にアクセスしないように、Unreal Engine エディタの設定から Amazon FSx for OpenZFS のパスを削除してください。 次に「 net use Z: /delete 」コマンドを実行して、Amazon FSx for OpenZFS ファイルシステムのマウントを解除します (「 Z: 」を実際に使用したドライブレターに置き換えてください)。 マウントを解除したら、AWS マネジメントコンソールからファイルシステムを削除します。AWS マネジメントコンソールで FSx に移動し、Amazon FSx for OpenZFS ファイルシステムを選択します。 「ファイルシステムの削除」を選択し、すべてのデータが削除されるようにプロンプトに従ってください。 クリーンアップする際に、ネットワーク構成に加えた変更も元に戻すことが重要です。Amazon FSx for OpenZFS の ENI のセキュリティグループからインバウンドルールを削除して、ネットワーク構成を再度保護してください。 Terraform テンプレートを使用して DDC を設定したユーザーの場合は、関連インフラをデプロビジョンするために「 terraform destroy 」コマンドを実行してください。 まとめ 私たちは Unreal Engine 用の派生データキャッシュ (DDC) として、Amazon FSx for OpenZFS を設定するためのステップバイステップのガイドを提供しました。 Amazon FSx for OpenZFS は、フルマネージドでセキュアかつスケーラブルなファイルストレージを提供するため、特に共有開発環境で Unreal Engine の DDC として構成するのに最適です。 Infrastructure as Code (IaC) のアプローチを好む人の為に、セットアッププロセスを簡素化する Terraform のテンプレートを公開しています。 Terraform のテンプレートは AWS GitHub リポジトリの aws-samples/unreal-engine-ddc にあります。 このリポジトリには Amazon FSx for OpenZFS を使用した Unreal Engine の派生データキャッシュ (DDC) を設定するために必要なすべてのコードと手順が含まれています。 翻訳はソリューションアーキテクトの長田が担当しました。原文は こちら です。

チップ形状の微細化が進むにつれ、先端ノード技術を使用してチップ製造を成功させることは難しくなっています。電子設計自動化 (EDA) は、より多くのコンピュート、ストレージ、時間を消費します。設計と検証の段階で、エンジニアが反復してバグを発見する時間を増やすことは、何百万もの不具合による再設計や収益の損失を防ぐことにつながります。チップ設計プロセスをさらに複雑にしているのは、半導体市場が人材不足に陥っていることです。既存エンジニアの生産性を向上させることで、この人材不足を解消し、市場投入までの時間を改善することができます。このブログでは、柔軟なコンピュートオプションを使用して最大 40% のパフォーマンス向上を示す 2 つの環境について説明します。これらの環境は、Cadence 社と Synopsys 社のバッチツールとインタラクティブツールにまたがり、結果が出るまでの時間とジョブコストを比較しています。 選択肢が重要な理由 それぞれの EDA ツールの性能は、様々な要因の影響を受けます。CPU のクロック速度が速いものや、特定の CPU 命令セットを使っているものは、その恩恵を受けます。他のツールは、より大きな L3 キャッシュ、メモリ帯域幅、またはネットワークスループットの恩恵を受けます。AWS 上で実行することで、顧客は最適化しようとしている特定の CAD (Computer Aided Design) フローに合わせて、コンピュートインスタンスを適切なサイズに設定することができます。CAD フロー全体において、結果までの時間が 10 ～ 40% 短縮され、全プロセスが 1 時間で完了しました。これは、CAD フローを変更する労力を掛けることなく、このようなパフォーマンスの改善を得るための方法です。 影響の定量化 この最適化の影響を定量化するために、2 つの単純化したシナリオ (最適化／非最適化) を比較してみます。 ジョブは 2 つのライセンスタイプで半々に分けられます ライセンス A は CPU プロバイダー A で 15% 遅く動作します ライセンス B は CPU プロバイダー B で 15% 遅く動作します 月間 1,000,000 ジョブ、2 つのオプションのうち最速で実行した場合の平均ジョブ時間は 1 分です どちらのコンピュートタイプも 1 時間あたり 0.1 ドルです (シンプルにするため) ライセンスコストはコンピュートコストの 3 倍です (0.3ドル) 顧客がクラスタ用に 1 つの CPU プロバイダだけを選択した場合、500,000 分 * 100% * $(0.1+0.3) / 60 + 500,000 分 * 115% * $(0.1+0.3) / 60 = $7,166 を支払うことになります。 一方、同じ顧客が各ジョブを最適な CPU で実行することを選択した場合、500,000 分 * 100% * $(0.1+0.3) / 60 + 500,000 分 * 100% * $(0.1+0.3) / 60 = $6,666 を支払うことになります。 この計算では、結果を 15% 早く得ることによるビジネス上のメリット (エンジニアリングの生産性、市場投入までの時間) を無視し、直接的な節約だけが強調されています。また、よりコストの低いインスタンスもあり、それらを選択することでさらなる節約を達成できるという事実も無視されています。結果を共有する前に、どのようにベンチマークを実行したかを説明します。 方法論 AWS オレゴンリージョンの AWS インフラを使用して、このベンチマークを実行しました。各ベンチマークには以下の要素が含まれます。 Intel、AMD、ARM ベースの AWS Graviton プロセッサ の 3 つのサーバ・アーキテクチャ テスト時の 2 世代のコンピュート (現行世代と旧世代) 合計 13種類 のインスタンスタイプ (Intel 5種類、AMD 4種類、Graviton 4種類) 各インスタンスのコア数は同じで、より多くのメモリを提供するインスタンスもありました。これにより、それぞれの EDA ツールについて、各 CPU タイプのコスト／パフォーマンスを評価することができました。また、CPU の世代を比較することで、経年変化を確認することもできました。各ツールには、同じ EDA ベンダー (Cadence / Synopsys) の IP ブロックを使用しました。複数のツールで同じユースケースを実行したわけではありません。Cadence と Synopsys を比較したのではなく、ツールごとに異なるコンピュートタイプを比較したのです。同様のアプローチは Siemens 社も取っており、同社の クラウド・フライトプラン の発表で述べられているように、AWS 上でより高速に実行するための最もよく知られた方法を取り入れています。注：結果はしばしば設計に依存します。Intel が Tool X で高速だったとしても、あなたの設計では必ずしもそうではないでしょう。あなたの設計でこのテストを繰り返す必要があります。例えば、あるツールが L3 キャッシュのサイズに敏感であるにもかかわらず、テストケースが小さすぎて L3 キャッシュにストレスを与えられなかったような場合です。あなたの設計は、その違いを体験するのに十分な大きさかもしれません。言い換えれば、あなたの燃費は異なるので、自身でテストしてください。コスト分析にあたっては、3 つの仮定を置きました。 各ライセンスのコストは 2,500 ドルと仮定しました。すべてのライセンスに単一のコストがあるわけではありませんが、ランタイムが全体のコストに与える影響を示すための「プラグナンバー」が必要でした。EDA ライセンスは通常、実行に使用するコンピュートよりも数倍高いです ( Intel の場合 は 4 倍)。私たちは、コンピュートだけのコストではなく、全体的なコストを最適化しています。 私たちは生産性を示しているわけではありません。私たち自身のシリコン開発では、エンジニアのコストは新製品の開発コストの 50% にも上ります。次のコストシミュレーションには、そのようなコストは含まれていません。もしそれを含めれば、長時間ジョブの影響は 2 倍以上になるでしょう。 各ジョブには、オレゴンリージョンの Amazon Elastic Compute Cloud (Amazon EC2) の オンデマンド 価格を使用しました。オンデマンドホストは、 リザーブドインスタンス 、 Savings plans による割引を享受できません。これは「最悪のシナリオ」の計算です。 シミュレーションを使用した AWS 上の電子設計自動化のコスト予測 をお読みいただき、コスト削減を実施するための当社の支援方法をご確認ください。 このブログは 2023 年夏に実施されたテストのデータに基づいています。それ以来、Intel ベースの r7iz や Graviton 4 インスタンスなど、新しいインスタンスが発表されています。しかし、このブログでは時間の経過に伴うパフォーマンスの最適化について見ています。新しいインスタンスタイプでの再テストは、AWS 上で EDA パフォーマンスを繰り返し継続的に向上する方法の完璧な例です。 結果 : Cadence グラフ 1 は、Cadence Spectre の結果を示しています。グラフ上の各ドットは、特定のコンピュートインスタンスタイプを表しています。 X 軸はランタイム (秒) を示します Y 軸は 1 つのジョブの総コスト (実行された時間のコンピュート + EDA ライセンス) を示します 理想的なサーバーは、より低く (費用対効果が高く)、より左にあります (結果が出るまでの時間が早い) グラフ 1 – Spectre のコスト／パフォーマンス分析 (ジョブあたり)。Graviton インスタンスは x86 インスタンスより 40% 以上高速で、コストは 40% 以上低い。 グラフ 1 では、ジョブの実行時間が長いほど、ジョブ全体のコストが高くなることがわかります。データポイントが斜めに広がっているのはこのためです。 c7g / m7g (第 3 世代 Graviton プロセッサ) は、現世代の Intel インスタンス ( c6i / m6i ) や AMD ( c6a / m6a ) と比べて 40% 以上高速であることがわかります。Spectre は浮動小数点演算に依存しており、第 3 世代 Graviton プロセッサは x86 よりも高速に実行します。Graviton はクロック速度が低いにもかかわらず、浮動小数点演算ではより高速です。これは些細なことではないので、インスタンスのスペックに頼らずテストすることをお勧めします。次のツールに移る前に、これらのインスタンスファミリーを世代間で比較し、Time-to-Results が時間とともにどのように変化するかを見ることができます。 グラフ 2 – コンピュート世代間の Spectre パフォーマンス。Graviton と AMD (M-family) はどちらも以前は Intel より遅かったが、現在の世代では速くなりました。 グラフ 2 は、新しい世代におけるすべてのコンピュートファミリーのランタイムの向上を示しています。前の世代では AMD が最速でしたが、現在の世代では ARM が最速です。これは、新しい世代が出るたびに、コンピュートの選択を再評価する必要性を示しています。先に説明したように、このテストには 1 時間かかりました。このラボでは、すべてのコンピュートノードで設計を並列実行し、性能を評価しました。ライセンスの縛りがある場合は、 これらのテストを連続的に実行するか 今日は、とある 1種類の CPU タイプで、明日は別の CPU タイプでリグレッションテストを実行します 同じデータを Xcelium で比較してみます。 グラフ 3 – Xcelium のコスト／パフォーマンス分析。AMD は Intel より 11%、ARM ベースのインスタンスより 14% 高速でした。 グラフ 3 は、AMD ベースのインスタンスが同スペックの Intel よりも 11％ 高速に動作し、Graviton ベースのインスタンスよりも 14% 高速に動作していることを示しています。Spectre と比較した結果の変化は、結果までの時間を短縮するためには、多様なコンピュートタイプが必要であることを浮き彫りにしています。コンピュート世代を比較すると (グラフ 4)、AMD は Intel よりも遅かったが、より速くなりました。AWS の顧客は各コンピュート世代で各フローに最適なものを柔軟にテストできます。そして、インスタンスタイプを組み合わせて使うことができます。 グラフ 4 – コンピュート世代間の Xcelium パフォーマンス。AMD (M-family) は以前は Intel より遅かったが、現在の世代では速くなりました。 結果 : Synopsys Synopsys VCS のテストでも同様のアプローチを取りましたが、今回は同じツールを 2 種類のクイックスタートキット (XBUS と Bitcoin) でテストしました。これにより、特定の設計が CPU の選択に与える影響が浮き彫りになりました。Synopsys の XBUS クイックスタートキットを使用した場合、Intel は AMD より 10%、Graviton より ～ 14% 高速でした (グラフ 5)。 グラフ 5 – VCS (XBUS) のコスト／パフォーマンス分析。Intel は AMD より 11%、Arm ベースのインスタンスより 14% 高速でした。 コンピュート世代を比較すると (グラフ 6)、現在の世代では Intel が最速であることがわかります。しかし、前の世代を比較すると、これらがどのように変化するかに注目してください。 グラフ 6 – コンピュート世代間の VCS (XBUS) 性能、Intel が両世代で最速。 Synopsys の Bitcoin クイックスタートキットを使って同じテストを繰り返すと (グラフ 7)、結果が変化するのがわかります。AMD は Intel より 25% 速く、Graviton より 20% 速いです。これは、結果がいかに設計に依存するか、そしてなぜ自分でテストする必要があるかを示しています。 グラフ 7 – VCS (Bitcoin) のコスト／パフォーマンス分析。AMD は Intel より 30% 速く、Graviton より 25% 速い。 コンピュート世代を比較すると (グラフ 8)、AMD がこの特定の設計で最も遅いものから最も速いものへと変化しており、時間の経過とともに状況が変化していることがわかります。 グラフ 8 – コンピュート世代間の VCS (Bitcoin) のパフォーマンス。 まとめ 新しい世代が出るたびに、CPU プロバイダは、EDA のコスト／パフォーマンスにおいて、互いにしのぎを削るようになるかもしれません。これにより、新たな改善の機会が生まれます。AWS の顧客は、より高速な結果を得るために、特定の EDA フロー用にコンピュートインスタンスをカスタマイズすることができます。これは、たまたま利用可能なノードでジョブが実行されるオンプレミスとは対照的です。これにより、既存のエンジニアリングチームの生産性が向上し、カバレッジが拡大し、市場投入までの時間が短縮されます。しかも、既存のフローを変更する必要がありません。このパフォーマンス最適化プロセスで EDA フローを実行してみませんか？AWS アカウントチームまたは AWS 担当者 にご連絡いただき、半導体のスペシャリストにご相談ください。お客様のテストを喜んでサポートいたします。 さらに読む EDA ライセンス時間を最大 20% 削減する方法の詳細については、 EDA on AWS ライセンスコスト最適化の経済学 をお読みください。 NXP Semiconductors のビデオでは、EDA フローを加速するためのベンチマークを紹介しています。 翻訳はソリューションアーキテクトの 吉廣 理 が担当しました。原文は こちら です。 Eran Brown Eran Brown は、シニア半導体スペシャリスト・ソリューション・アーキテクトです。半導体企業で 7 年間、HPC ストレージインフラの設計に携わり、1 平方インチのシリコンで何ができるかに驚きを隠せません。

この 1 週間も、AWS のサービスチームは引き続きお客様に代わってイノベーションを進めており、 Amazon Web Services (AWS) の世界でも、皆さんにお話ししたいたくさんのことがありました。世界各地で開催されている、あらゆる AWS コミュニティ イベントやイニシアティブについてもお伝えしたいと思います。 では、早速見ていきましょう! 2月12日週のリリース 2月12日週のリリースの中から、私の目に留まったリリースをいくつかご紹介します。 AWS Control Tower が組織単位を登録するための API を導入 – これらの新しい API では、API を使用してガバナンスを組織単位 (OU) に拡張し、OU プロビジョニングワークフローを自動化することができます。API は、既に AWS Control Tower ガバナンスの対象となっている OU を、ランディングゾーンの更新後に再登録するためにも使用できます。これらの API には AWS CloudFormation サポートが含まれているため、お客様は Infrastructure as Code (IaC) を使用して OU を管理することができます。 API Gateway が TLS 1.3 のサポートを開始 – TLS 1.3 を実装した API Gateway を一元化されたコントロールポイントとして使用することにより、開発者はクライアントとゲートウェイ間のコミュニケーションをセキュア化し、API トラフィックの機密性、整合性、信頼性を維持して、TLS を使用して SSL 証明書を一元的にデプロイするための AWS Certificate Manager (ACM) との API Gateway の統合からメリットを得ることができます。 Amazon OpenSearch Service でブルー/グリーンなしでのクラスターボリュームの更新が可能に – ブルー/グリーンデプロイは、デプロイがドメインで追加のリソースを使用することによるクラスターの中断を避けるためのものですが、ブルー/グリーンはトラフィックが少ない期間に実行することが推奨されます。これからは、ブルー/グリーンデプロイを必要とすることなくボリューム関連のクラスター設定を更新できるようになるため、オンライントラフィックへのパフォーマンス影響を最小限に抑えるとともに、クラスター動作が中断される可能性も回避できます。 Amazon GuardDuty Runtime Monitoring が共有 VPC で実行されるクラスターを保護 – このリリースに伴い、GuardDuty で既に自動エージェント管理にオプトインしているお客様は、GuardDuty Runtime Monitoring の新たな 30 日トライアルを活用することができるようになります。このトライアルでは、共有 VPC セットアップにデプロイされているリソース (クラスター) の監視が自動的に開始されます。お客様には、エージェントを手動で管理して、共有 VPC 環境に仮想プライベートクラウド (VPC) エンドポイントをプロビジョニングするオプションもあります。 AWS Marketplace が OU の Private Marketplace カタログ管理のサポートを開始 – この機能は、ビジネスユニットまたは開発環境ごとに個別の製品カタログをサポートするため、組織は特定のニーズに合わせてソフトウェア調達を調整することができます。さらに、お客様は Private Marketplace 管理の委任管理者として信頼できるメンバーアカウントを指定することもできるので、マネジメントアカウント管理者の業務上の負担が軽減されます。このサポートの開始により、組織は、異なるビジネスニーズやユーザーニーズの全体に調達ガバナンスをスケールするために必要となる俊敏なコントロールを管理者に提供することによって、調達を迅速化することが可能になります。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS ニュース AWS Cloud Clubs Captains に参加しましょう – AWS Cloud Club Captains の C3 コホートへの参加申し込み受付は、2024 年 2 月 5 日から 23 日の午後 5 時 (米国東部標準時) までとなっています。 AWS のオープンソースに関するニュースと最新情報 – 私の同僚である Ricardo が、AWS コミュニティの新しいオープンソースプロジェクト、ツール、およびデモに焦点を当てた、こちらの Open Source Newsletter を毎週執筆しています。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 Building with Generative AI on AWS using PartyRock, Amazon Bedrock and Amazon Q – プロンプトエンジニアリングと Amazon Bedrock API の使用におけるスキルを習得します。ナレッジベース、RAG (Retrieval Augmented Generation)、埋め込み、エージェントを通じて「ドキュメントとチャット」する方法も検証していきます。また、コーディングとデバッグを支援するために、次世代の開発者ツールである Amazon Q と Amazon CodeWhisperer も使用します。 会場 : AWS Skills Center, 1550-G Crystal Drive, Arlington, VA (米国) AI/ML security – 人工知能と機械学習 (AI/ML)、そして特に生成 AI は、多くの組織の最優先事項になってはいるものの、この新しい変革的なテクノロジーで前進したいと考えている企業でさえも、ためらいを感じています。こういった企業は、構築するものがセキュアであることを確実にする方法を必ずしも理解しているわけではありません。このウェビナーでは、その実現方法を説明します。 AWS Jam Session – Canada Edition – AWS JAM は、遊び、学んで、AWS スキルを検証するための、ゲーム化された学習プラットフォームです。午前は、セキュリティ、サーバーレス、AI/ML、分析など、さまざまな技術分野にまたがる課題を織り交ぜたものになっています。午後は、毎月異なる専門分野に焦点を当てます。課題を解決するために、最大 4 名のチームを結成できます。上位 3 チームには賞品が贈られます。 お住まいの地域が南北アメリカ、アジア太平洋、日本、または EMEA 地域であるかにかかわらず、 皆さんのタイムゾーンにぴったりな AWS Innovate Online イベント が予定されています。Innovate Online イベントは無料のオンラインイベントで、AWS に関するインスピレーションを得て、知識を深めてもらうことを目的としています。 AWS Summit は、クラウドコンピューティングコミュニティが一堂に集まって交流し、コラボレートして、AWS について学ぶことができる無料のオンラインおよび対面イベントです。これらのイベントは、AWS の製品とサービスについて学び、インフラストラクチャとアプリケーションを構築、デプロイ、および運用するために必要なスキルを身に付けることができるように設計されています。 お近くの AWS Summit を検索 して登録するか、関心のある AWS Summit の登録受付開始時に通知を受ける設定を行ってください。 AWS コミュニティ re:Invent re:Cap  – 世界中の AWS ユーザーグループと AWS クラウドクラブのボランティアが主催する コミュニティ re:Cap イベントに参加して、AWS re:Invent からの最新の発表について学びましょう。 近日開催されるすべての対面イベントと仮想イベントを閲覧することができます 。 2月19日週のニュースは以上です。2月26日週の Weekly Roundup もお楽しみに! – Irshad この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。