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

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

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

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

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

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

Penta Security は、 AWS のデータ暗号化パートナー であり、 27年間の顧客のサイバーセキュリティを担当した企業で、データセキュリティ、ウェブセキュリティ、認証セキュリティの領域で安全なクラウド環境を提供しています。 韓国のデータセキュリティ市場で 15 年間シェア 1 位を守り続けている D’Amo は、グローバル CC 認証および韓国国家情報院の認証を受けた暗号化モジュールを通じて、顧客の重要データを安全に保護し、国内外のプライバシー関連コンプライアンスをすべて遵守しています。 D’Amo は、強力なデータ暗号化技術に基づき、次の機能を提供します。 顧客のビジネス環境に最適化された全システムレイヤーでの暗号化サービスを提供 韓国国家情報院認証の暗号化モジュールを使用した安全な暗号化アルゴリズムの提供 カラム単位の暗号化と DB アクセス制御機能の提供 クラウド環境専用の鍵管理システム D’Amo KMS を用いた暗号鍵、外部鍵、Oracle TDE 鍵など、企業全体の暗号鍵管理 統合された集中管理システム D’Amo Control Center によるインフラ内の暗号化製品とサーバー管理のサポート Amazon RDS Custom での D’Amo による暗号化・復号環境の構築 Amazon RDS Custom は Oracle と Microsoft SQL Server エンジンをサポートしています。 Amazon RDS Custom は、Amazon RDS が提供しているスナップショットやバックアップ、リカバリ機能、パッチ適用サポート、データベースのモニタリング、ログ管理など多くの管理機能を提供します。さらに、SYSDBA および OS レベルのアクセスが可能なため、これまでの Amazon RDS では対応できなかった暗号化ソリューションの導入や、パッケージアプリケーション（例えば、ERP、MES、SCM、HRなど）のデータベースとしても利用できます。 また、Amazon RDS for Oracle がサポートしていない Oracle 12c などのバージョンも利用でき、Oracle RMAN や Data Guard、DB Vault、Flashback といった機能やサードパーティ製ソリューションもインストールして使用することが可能です。 通常の Amazon RDS インスタンスでは OS および SYSDBA へのアクセスができないため、商用データベースセキュリティソリューションの構築が難しい状況でした。しかし、Amazon RDS Custom インスタンスであれば、OS と SYSDBA へのアクセスが可能なため、D’Amo を利用して安全な暗号化・復号環境を構築することができます。 図1 – DB 暗号化ソリューションの観点からの Amazon RDS とAmazon RDS カスタムアーキテクチャの比較 Penta Security は、Amazon RDS Custom インスタンス上で D’Amo が正常に動作することを確認するため、以下の項目について検証を行いました。 D’Amo テスト環境 OS: Oracle Linux DBMS: Oracle Database 19c、12c (64 bit) D’Amo 機能検証リスト 主な検証機能 暗号化ポリシーの管理機能：管理ツールで設定した暗号化ポリシーの正常動作確認 VTI (View/Trigger Interface) モードでカラムの暗号化・復号：管理ツールによるVTI暗号化作業の正常動作確認 API モードでカラムの暗号化・復号：管理ツールによる API 暗号化作業の正常動作確認 図 2 – 暗号化ポリシー管理、VTI 及び API 暗号化・複合の正常動作結果画面 カラムアクセス制御：管理ツールで設定した対象カラムへのアクセス許可・遮断が正常に動作することの確認 ポリシーアクセス制御：管理ツールで設定した対象ポリシーへのアクセス許可・遮断が正常に動作することの確認 暗号化・復号権限制御：管理ツールで設定した権限による暗号化・復号の許可・遮断が正常に動作することの確認 図3 – 暗号化・復号の権限、カラムおよびポリシーへのアクセス制御の正常動作結果画面 追加の動作確認 DB キー管理、カラムインデックスの設定、ストレージ設定などの DBMS 管理機能の正常動作確認 Penta Security は、Amazon RDS Custom 環境で 79 の検証項目が正常に動作することを確認し、D’Amo の Amazon RDS Custom 環境での正式サポートを発表しました。 Amazon RDS Custom での D’Amo の暗号化タイプ D’Amo は、Amazon RDS Custom インスタンスを使用しているお客様向けに、D’Amo DA と DP の両製品を提供しており、企業環境に最適な暗号化方式を選択できます。 D’Amo DA（DBMS Application 暗号化）：D’Amo DA は、DBMS の内部に暗号化・復号 API をインストールして暗号化を行う製品で、DB サーバーの負荷を最小限に抑えて運用できる点が特徴です。また、暗号化対象のテーブル名やカラム名を変更せずに暗号化環境を構築できます。 D’Amo DP（DBMS Pakage 暗号化）：D’Amo DP は、DBMS に暗号化パッケージをインストールして暗号化を行う製品でカラム単位の暗号化、アクセス制御、権限制御など多様な管理機能を提供します。アプリケーションと独立した暗号化方式として動作するため、クエリやコードの変更を最小限に抑えて構築することが可能です。 D’Amo を構築するお客様のための多様なサポート特典 D’Amo は、オンプレミス環境で暗号化を適用していたお客様が Amazon RDS Custom に切り替える際に、既存の RDB 構造を維持します。また、検証済みの暗号モジュールを通じて、アプリケーションを変更せずにお客様のビジネス環境に合わせた暗号化を提供します。なお、Amazon RDS Custom でサポートされている Oracle や Microsoft SQL Server のすべてのバージョンに 100％ 対応しています。 さらに、Penta Security は AWS の公式 ISV パートナーとして、D’Amo を活用するお客様に向けて、さまざまな特典を提供しています。 AWS PoC サポート：既存のインフラストラクチャから AWS への移行や、クラウド環境に不慣れなお客様に対し、カウンセリングおよび技術サポートを提供します。 AWS クレジットの提供：D’Amo のインストールや内部テストのための AWS クレジットを提供することでコスト負担を軽減し、企業のデータベース環境に最適な暗号化ソリューションを構築できます。 トレーニングサポート：クラウドおよびデータ暗号化担当者のデジタルスキル向上のための個別トレーニングをサポートします。 今後、Penta Security は AWS と継続的に協力し、Amazon RDS Custom サービスに合わせたさまざまな機能や特典を拡充していきます。PoC サポート、クレジット提供、トレーニングサポートの詳細については、AWS の担当営業チームまたは Penta Security 営業チーム（cloudbiz@pentasecurity.com）までお問い合わせください。 サマリー 既存のオンプレミス（レガシー）環境やカスタム環境の制約により Amazon RDS の利用が難しかったお客様は、Amazon RDS Custom を活用することで、Amazon RDS の便利な管理機能を利用できます。 Amazon RDS Custom 環境で信頼性が証明されている Penta Security の D’Amo は、企業の重要な情報を安全に保護し、国内外のプライバシーに関するコンプライアンス要件をすべて満たすことができます。 Penta Security の D’Amo を導入する際には、AWS の公式 PoC サポートやテスト用クレジットの提供、トレーニングサポートなど、さまざまな支援を受けることが可能です。 D’Amo の詳細については、 Penta Security の Web サイト を参照してください。 翻訳はソリューションアーキテクト鄭宇鎭（ジョン ウジン）が担当しました。原文は こちら です。

2024年11月1日に、「コンテナ/サーバーレスによるモダン・プロジェクト実践」と題して 3社にご講演いただきました。 コンテナやサーバーレスを利用することで、従来とは異なるランニングコストの構造に移行し、迅速な対応・変更で利用者/お客様のニーズに迅速に対応できるようになります。それを実際にプロジェクトで実践されているお客様のそのままの声をお伝えし、選択のポイントや勘所を理解する機会として、特に従来型の慣れた手法からまだ抜け出せない方・組織の後押しとなるヒントとなるべく、本セミナーは企画されました。 今回は 3社 それぞれ異なる領域のシステムでの経験談をご紹介いただきました。 貴重な実体験をご紹介いただいたのは以下のお客様です。 保険Web申込サービスの顧客体験価値向上のため、4週間ごとの改善リリースを実現 はなさく生命保険株式会社様 Step Functionsで決裁を回そう -内製ワークフロー・チケットシステムの紹介- クックパッド株式会社様 SQSを用いたクレジットカード決済の非同期化 株式会社ZOZO様 各セッションの内容について 保険Web申込サービスの顧客体験価値向上のため、4週間ごとの改善リリースを実現 はなさく生命保険株式会社 / CS戦略部 課長　渡邉 佑亮 様 はなさく生命保険様からは、Web申込サービスのローンチ（2021/09）に際して、どのような思考、優先度でプロジェクトが発足したのか、どのような体制で進められたのかが紹介されました。不確実な新規ビジネスに対し、SIパートナー（開発ベンダー）との共創型のアジャイル開発体制をとることで変化対応力を確保したこと、「当たり前に動く」ことが前提の金融サービスを安定的に支える仕組みとして選択されたアーキテクチャや技術方式についてのご説明がありました。IT システムの開発・運用を開発パートナー企業とともに実施されている企業は日本には多く存在します。モダンな開発スタイルへのチャレンジには、技術的な観点だけではなく、開発パートナー企業とどのように座組みすると良いのかという観点において、参考になる内容が含まれていたように感じました。また、視聴者から、サーバーレス型による運用のため、費用の変動による予算とのブレをどうお考えかという質問がありましたが、そもそも新規のプロジェクトであり、どのくらいアクセスがあるかは不透明だったので、厳密な予算管理を行うことが困難だった。サービスローンチ後は月次でシステム稼働状況と費用の確認を行っているが、オンプレ運用費用との比較においても適性水準であると判断しているとのコメントがありました。これは、サーバーレス型ではよく聞かれる質問の一つですが、実際のお客様の判断が伺えたのは良い機会でした。 資料は こちら です。 Step Functionsで決裁を回そう -内製ワークフロー・チケットシステムの紹介- クックパッド株式会社 / Software Engineer　Shota Nagasaki 様 Head of Corporate Engineering and Security　Sorah Fukumori 様 クックパッド様からは、AWSサーバーレスおよびコンテナサービスをフレームワークとして利用したカスタムの決裁ワークフローのシステム（Fryegg）を構築・展開し、元々お持ちのワークフローシステムから移行された事例をご紹介いただきました。ここでキーとなるAWSサービスが Step Functions です。条件分岐などはもちろん、上長の承認を待つ待機処理や何かシステム上の問題で処理が途中でエラーになってしまった際の再開処理など、ワークフローに求められる機能の大部分が Step Functions の近年の機能アップデートでカバーされ、それが後押しになったとのこと。日本企業の決裁や承認処理は特殊で、多くの場合、企業ごとにカスタマイズが必要、とよく言われますが、複数のシステムや組織をまたがるワークフローをサーバーレス型で実装できれば、ランニングコストの改善への影響は大きいです。しかし、主要メンバー2名で、4ヶ月でやり切るのはすごい。 資料は こちら です。将来的には、この Fryegg をOSSとして公開するビジョンもあるとのことで、個人的にも期待したいです! SQSを用いたクレジットカード決済の非同期化 株式会社ZOZO / EC基盤開発本部 SRE部 カート決済SREブロック　金田 卓巳 様 EC基盤開発本部 カート決済部 カート決済基盤ブロック　林 友貴 様 ZOZOTOWN の、特にセールスキャンペーン時の終了時間直前の決済処理のスパイクに対し、将来のサービス成長を考慮してどう対処すべきなのか、それに対する現時点での対応策がご紹介されました。最終的に SQS を挟んだ非同期型の連携構成までの具体的な検討のポイント・思考フローでは、決済処理という重要機能に対する判断と利用者の利便性を両立させようとする考慮が見えました。負荷の高い部分の処理における非同期アーキテクチャの効果を技術的には理解できても、特に決済に関する処理となると心理的になかなか踏み込みにくいものです。しかし、ZOZOTOWNという日本でも有数のサービスのカード決済部分で実現し、効果があるという話は大きな説得力があります。また、その負荷テストのために使用した EKS上のシステムの紹介も、負荷テストにおけるコンテナ活用の良い一例となりました。 資料は こちら です。なお、負荷テストとしてEKS上で稼働させたツールは こちら であるのことでした。 まとめ 顧客フロントのサイトやカード決済のような業務でも、コンテナやサーバーレス型のサービスを使うことはもう珍しいことではありません。運用の工数を省力化し、その分、機能拡張や改善リリースのサイクルを回す方に力を注ぐことができます。一方、モダンなアーキテクチャの活用の前に、まだ既存の従来型システムが足枷になって、という方が多いのも事実です。全部を一気には変えられませんし、全てを変える必要があるかどうかも疑問です。せめて、新しいプロジェクトでモダンな方式で進めてみて、その体験を実感してから今後の方針を決めるのでも十分良いスタートです。実際、先人の企業の多くは、こうしたアプローチをとった結果、その領域を拡大して今に至っているのです。一歩を進み始めないとその先はありません。 なお、コンテナやサーバーレスをあらためて理解したい方には、自習型の以下のワークショップがあります。ご自分のペースで進めながら来たる次のプロジェクトに備えてはいかがでしょうか。 ECS、EKS を学びたい ECS Workshop Introduction to EKS ひとまずコンテナ化してみる! App2Container サーバーレスをこれから始めるなら… サーバーレス自己学習ガイド サーバーレスの勉強方法を聞いてみた サーバーレス/クラウドネイティブ系 実践力を鍛えるBootcamp – クラウドネイティブ編 サーバーレス事業開発 杉

本ブログは 2024 年 11 月 11 日に公開されたBlog “ Maximize your cloud security experience at AWS re:Invent 2024: A comprehensive guide to security sessions ” を翻訳したものです。 AWS re:Invent 2024 は、12 月 2 日から 6 日までラスベガスで開催され、最新のセキュリティイノベーションを学びたいセキュリティの専門家、クラウドアーキテクト、コンプライアンスリーダーにとって有益なセッションが満載です。今年のイベントでは、ゼロトラスト、生成 AI を活用したセキュリティ、アイデンティティとアクセス管理 (IAM)、DevSecOps、ネットワークとインフラストラクチャセキュリティ、データ保護、脅威検出とインシデント対応のベストプラクティスに焦点を当てています。このイベントは、クラウドセキュリティの専門家にとって、貴重な学習とネットワーキングの機会をご提供します。 re:Invent 2024 の豊富なセッションを効果的に活用し、学習効果を最大限に高めるため、 必見のセキュリティセッション のリストを厳選しました。ぜひ 今すぐご登録 いただき、ラスベガスでお会いしましょう！ 基調講演とイノベーショントーク AWS re:Invent 2024 の 基調講演 と イノベーショントーク は、AWS のシニアリーダーから直接、革新的な洞察を得る機会となります。これらのセッションでは、生成 AI、クラウドセキュリティ、そしてアプリケーション開発と AWS クラウドの未来に新たな方向性を示す革新的なアーキテクチャにおける最新のブレークスルーを深く掘り下げます。 KEY002 – CEO Keynote with Matt Garman (Matt Garman による CEO 基調講演) 。基幹サービスの刷新から新しい体験の創造まで、AWS がクラウド全体でどのようにイノベーションを起こし、お客様とパートナーが安全で豊かな未来を構築できるようにしているかをご覧ください。 SEC203-INT – Security insights and innovation from AWS with Chris Betz (Chris Betz による AWS のセキュリティに関する洞察とイノベーション) 。 AWS の CISO である Chris Betz が、セキュリティを統合・自動化し、チームが重要な取り組みに集中できるようにする変革的な戦略を明らかにする中で、革新的なセキュリティ技術と生成 AI が、組織のセキュアなイノベーションの加速をどのように支援するかをご覧ください。 イノベーショントーク の全リストをご確認ください。今年、現地に参加されない方も、基調講演とイノベーショントークはライブ配信でご視聴いただけます。 セッション セッションタイトルのリンクを選択するとセッション情報と時間場所を確認できます。セッションを予約し、AWS re:Invent のお客様のアジェンダにセッションの追加もできます。 高度なアクセス分析による最小権限の実現の加速 攻撃対象範囲を最小限に抑え、ゼロトラストアーキテクチャを実現するために、アイデンティティ管理とアクセス制御のベストプラクティスを学びます。 (訳者注: チョークトーク（Chalk talk）は、少人数の参加者を対象とした 1 時間の双方向性の高いセッションです。特定のトピックを深く掘り下げ、AWS のエキスパートと直接対話し、その場で質問できることもあります。) SEC325 | チョークトーク | A least privilege journey made easier by IAM Access Analyzer (IAM Access Analyzer による最小権限への容易な移行) : 集中管理をしているセキュリティチームと IAM ポリシー作成者が、 IAM Access Analyzer を使用して、未使用や過剰な権限を可視化し、実用的な推奨事項を活用してスケーラブルな最小権限を実現する方法を学びます。 SEC337 | チョークトーク | Scaling IAM: advanced administration and delegation patterns (IAM のスケーリング: 高度な管理と委任パターン) : 組織の拡大に伴うセキュリティと俊敏性のバランスを取りながら、効果的なアクセス管理のための革新的な戦略をご覧ください。実際のシナリオ、ベストプラクティス、最先端のテクニックから、スケーラビリティ、パフォーマンス、将来の成長のための IAM インフラストラクチャの最適化方法を学びます。 SEC202 | ビルダーズセッション | API Authorization with Amazon Cognito and Verified Permissions (Amazon Cognito と Verified Permissions による API 認可) : このセッションでは、AWS 上のマイクロサービスベースのアーキテクチャにおけるモダンな認可について実践的な経験を得られます。 Amazon Cognito による認証の外部化とカスタマイズ、 Amazon Verified Permissions を使用したポリシーベースのアクセス制御による詳細な認可の適用、 Amazon API Gateway で保護された API との統合方法を学びます。参加にはラップトップの持参が必要です。 SEC334 | チョークトーク | Building zero trust architectures with AWS practical guidance (AWS による実践的なゼロトラストアーキテクチャの構築ガイダンス) : このチョークトークでは、AWS サービスを使用したゼロトラストネットワークアーキテクチャの構築について詳しく説明します。ゼロトラストの観点から、ユーザーからアプリケーション、アプリケーション間、その他のアクセスシナリオをセキュアにする方法を学びます。 SEC232 | ブレイクアウトセッション | Secure by design: Enhancing the posture of root with central control (セキュアバイデザイン: 中央管理によるルートのセキュリティポスチャの強化) : このセッションでは、集中管理とガバナンスを維持しながら、AWS 環境全体でルートアクセスを安全に管理する方法を説明します。さらに、多要素認証 (MFA) を実施し、業界の取り組みと連携し、環境を安全に保つための AWS が提供する最新のツールと取り組みについて説明します。 脅威検出とインシデント対応によるセキュリティポスチャの強化 AWS のセキュリティサービスを使用して、セキュリティリスクを継続的に特定し優先順位付けすることで、セキュリティポスチャを強化し、セキュリティ運用を効率化できます。 (訳者注: コードトーク（code talk）は、ソリューションの構築に使用される実際のコードを詳しく見ていき、参加者がアプローチの「理由」を理解し、エラーも含めた開発プロセスを観察できます。参加者は質問をしたり、実際に手を動かしながら学んだりすることが推奨され、より深い実践的な学習体験を得ることができます。) SEC321 | ブレイクアウトセッション | Innovations in AWS detection and response (AWS の検出と対応におけるイノベーション) : このセッションでは、脅威の検出、ワークロードとデータの保護、自動化された継続的な脆弱性管理、一元化されたモニタリング、継続的なクラウドセキュリティポスチャ管理、統合されたセキュリティデータ管理、調査と対応、生成 AI などの実践的なユースケースに焦点を当てます。AWS の検出および対応サービスをシームレスに統合して、ワークロードを大規模に保護し、セキュリティポスチャを強化し、AWS 環境全体でセキュリティ運用を効率化する方法について、より深く理解することができます。 SEC332 | チョークトーク | Anatomy of a ransomware event targeting data within AWS (AWS 上のデータを標的としたランサムウェアイベントの分析) : このチョークトークでは、AWS 上のお客様環境のデータを標的としたランサムウェアイベントの検出、対応、復旧について解説します。環境内のランサムウェアイベントから保護するために使用できる AWS のサービスと機能、およびランサムウェアイベントが発生した場合の調査方法について、より深い理解を得ることができます。 SEC301 | ワークショップ | Threat detection and response using AWS security services (AWS セキュリティサービスを使用した脅威検出と対応) : このワークショップでは、さまざまなリソースと動作にわたる複数のセキュリティイベントをシミュレートします。提供されたサンドボックス環境で、シミュレートされたイベントから得られた検出結果を確認し、対応する実践的な体験ができます。参加にはラップトップの持参が必要です。 SEC219 | ブレイクアウトセッション | Uncovering sophisticated cloud threats with Amazon GuardDuty (Amazon GuardDuty による高度なクラウドの脅威の発見) : Amazon GuardDuty が AWS 環境全体にわたるエンドツーエンドの可視性を提供する、フルマネージド型の脅威検出を実現する方法について学びます。GuardDuty の独自の検出機能は、クラウドの脅威状況に対する AWS の可視性に基づいており、対応者がより迅速に問題に対処し、修復までの平均時間 (MTTR) を最小限に抑え、セキュリティリソースを最適化するのに役立ちます。これにより、チームはセキュリティリスクへの対応に追われる時間を減らし、より多くの時間をイノベーションに費やすことができます。 SEC343 | チョークトーク | Identify a prioritization strategy for security response & remediation (セキュリティ対応と修復のための優先順位付け戦略の見極め) : このチョークトークでは、アカウントのセキュリティ検出結果への対応と修復を自動化するためのフレームワークについて学びます。 AWS Security Hub を基盤として、どの検出結果を自動修復できるか、自動修復アプローチの影響、そして迅速かつ徹底的な対応を実現する方法について検討します。 SEC401 | コードトーク | Inspect and secure your application with generative AI (生成 AI を使用したアプリケーションの検査とセキュリティ確保) : 生成 AI を使用してアプリケーションのセキュリティを向上させる方法を詳しく見ていきます。AI を活用したツールがセキュリティ問題を迅速に特定し、修復を推奨する方法について学びます。 Amazon Inspector がアプリケーションのソフトウェアとコードの脆弱性を検出する方法について学び、統合開発環境 (IDE) で生成 AI を使用してセキュリティ上の問題をスキャンし修復する方法をご確認ください。 新たな脅威に対するエッジの保護 AWS エッジセキュリティサービスを使用して、アプリケーションに対する分散型サービス妨害 (DDoS) 攻撃や脆弱性攻撃から保護し、より一貫性のあるセキュリティポスチャを実現します。 SEC322 | ブレイクアウトセッション | Reduce your risk exposure with least privilege egress controls (最小権限のアウトバウンド通信制御によるリスクの低減) : このセッションでは、アウトバウンド通信制御戦略を最小権限の原則に合わせる方法を学びます。 AWS Network Firewall 、 Amazon Route 53 Resolver DNS Firewall 、その他のセキュリティサービスの最新リリースが、様々なリスクを低減するのにどのように役立つかを学びます。実装を簡素化し、ユースケースに特化したルールの推奨事項を紹介します。セキュリティポリシーが意図したニーズを満たしているという確信を得ることができます。 SEC344 | チョークトーク | Lessons learned from DDoS mitigation (DDoS 対処から学んだ教訓) : AWS Shield Response Team (AWS SRT) の重大インシデントからの洞察：このチョークトークでは、過去の DDoS イベントを掘り下げ、AWS SRT がセキュリティインシデントをどのように対処したかを解説します。この種の侵入に関する洞察を得て、アプリケーションをより DDoS 耐性の高いものにするための緩和戦略を学びます。 SEC327 | チョークトーク | Building secure network designs for generative AI applications (生成 AI アプリケーションのためのセキュアなネットワーク設計戦略の構築) : このチョークトークでは、AWS 上で生成 AI アプリケーションをセキュアに加速し、問題をより迅速に保護、検出、対応するための階層化されたネットワークセキュリティ制御の構築方法を学びます。多層的な防御のネットワーク設計目標を達成するための主要な考慮事項、ベストプラクティス、リファレンスアーキテクチャをご確認ください。 SEC304 | ワークショップ | Mitigate zero-day events and ransomware risks with VPC egress controls (VPC アウトバウンド制御によるゼロデイイベントとランサムウェアリスクの軽減) : このネットワークセキュリティワークショップでは、ソフトウェアサプライチェーンの依存関係、ゼロデイイベント、暗号通貨マイニング、ランサムウェアからのリスクを軽減するための AWS アウトバウンド制御のベストプラクティスの実装方法を学びます。参加にはラップトップの持参が必要です。 SEC317 | ブレイクアウトセッション | How Amazon threat intelligence helps protect your infrastructure (Amazon が脅威インテリジェンスをお客様のインフラストラクチャ保護に役立ててる方法) : AWS の脅威インテリジェンス機能を理解し、 AWS WAF 、AWS Network Firewall、Amazon Route 53 Resolver DNS Firewall などのセキュリティサービスにおいて、マネージドファイアウォールルールとセキュリティ検出結果をどのように強化しているかを学びます。AWS が AWS インフラストラクチャの保護し、新しいセキュリティ機能を開発し、お客様の AWS 上のアプリケーション保護の強化に使用している脅威インテリジェンスについて学びます。 生成 AI 時代における機密データの保護 最新の AI テクノロジーを実装する際に、データの機密性とプライバシーを保護するのに役立つ高度なテクニックと AWS サービスをご紹介します。 SEC323 | ブレイクアウトセッション | The AWS approach to secure generative AI (生成 AI に対する AWS のセキュリティアプローチ) : このセッションでは、AWS が生成 AI スタックの 3 つのレイヤー (インフラストラクチャのボトム層、モデルやツールへのアクセスを提供するミドル層、大規模言語モデル (LLM) やその他の基盤モデル (FM) を活用して作業を効率化するアプリケーションを含むトップ層) にわたるセキュリティをどのように考えているかについて学びます。 SEC310 | ワークショップ | Persona-based access to data for generative AI applications (生成 AI アプリケーションにおけるユーザーの役割に基づいたデータアクセス) : このワークショップでは、組織内の様々なユーザーロールに合わせて調整されたチャットボットアプリケーションによるドキュメントアクセスを管理します。アクセス権限を職務に合わせることで、セキュアな情報配信に関する課題に対処し、効率性とコンプライアンスを向上させる方法を学びます。参加にはラップトップの持参が必要です。 SEC336 | チョークトーク | Security and compliance considerations using Amazon Q Business (Amazon Q Business を使用する際のセキュリティとコンプライアンスの考慮事項) : このチョークトークでは、 Amazon Q Business アプリケーションのセキュリティ確保のためのベストプラクティスについて、アクセスコントロール、データ保護、コンプライアンスの考慮事項を含めて説明します。 生成 AI に焦点を当てたセッションについては、 こちらのブログ もご覧ください。 セキュリティを重視するカルチャーで開発者を支援する DevSecOps の実践にセキュリティをシームレスに統合し、市場への投入時間を短縮してリスクを軽減します。 SEC216 | ブレイクアウトセッション | Build trust in your CI/CD pipeline (CI/CD パイプラインにおける信頼の構築) : スケーラブルなコンテナセキュリティのコード化: このセッションでは、スケーラブルなコンテナのセキュリティとコンプライアンスを自動化する方法を学びます。 Amazon Q Developer 、Amazon Inspector、 Amazon Elastic Compute Cloud (Amazon EC2) Image Builder がどのように連携して、セキュアなコンテナイメージの作成とその Amazon Elastic Container Registry (Amazon ECR) への保存を自動化するのかを探ります。セキュリティを損なうことなく、開発者をサポートし、迅速な開発を可能にする方法を習得することができます。 SEC217 | ブレイクアウトセッション | Building a resilient and effective culture of security (レジリエントで効果的なセキュリティのカルチャーの醸成) : このセッションでは、リーダーシップからのサポート獲得、セキュリティオーナーシップの共有、心理的安全性の定着による信頼、透明性、そしてプロアクティブなセキュリティファーストのマインドセットの構築など、レジリエントで力強いセキュリティのカルチャーの醸成についてのガイダンスを提供します。 SEC218 | ブレイクアウトセッション | Emotionally intelligent security leadership to drive business impact (ビジネスインパクトを生み出す感情知性を備えたセキュリティリーダーシップ) : リーダーシップを向上させ、セキュリティニーズと戦略的なビジネス成果を一致させ、インパクトのある変革を先導し、持続可能なセキュリティのカルチャーを醸成する方法を学びます。AWS とお客様がどのように共感を持ってセキュリティをリードし、セキュリティの目的を結果に変換し、イノベーションを促進し、ポジティブなエスカレーションカルチャーを改善するための関係を育むかについての内部からの視点をご紹介します。的確なリーダーシップを発揮し、セキュリティ目標を意味のあるビジネスインパクトに結びつける技術を習得し、セキュリティが成功とレジリエンスの触媒となる未来へ組織を導く力を身につけることができます。 SEC314 | コードトーク | Accelerate your DevOps pipeline and remain secure with policy as code (policy as code で DevOps パイプラインを加速させながらセキュリティを維持) : このコードトークでは、オープンソースの汎用 policy as code 評価ツールである AWS CloudFormation Guard を使用して、AWS インフラストラクチャのコンプライアンスルールを定義し評価する方法を学びます。既存のデプロイメントパイプラインに自動化されたポリシー検証をシームレスに統合し、DevOps エンジニアが CI/CD パイプラインにポリシー評価ステップを組み込めるようにする方法を学びます。セキュリティ評価者は、堅牢なセキュリティポスチャを維持しながら、合理化されたレビュープロセスを体験できます。 SEC302 | ブレイクアウトセッション | Better together: Protecting data through culture and technology (より良い協力関係: カルチャーとテクノロジーを通じたデータ保護) : このセッションでは、AWS で利用可能なデータ保護機能の全範囲と、ベストプラクティスとカルチャーがこれらの機能を補完してセキュリティ成果を向上させる方法について考察します。組織がすべてのレイヤーにセキュリティを一貫して組み込むことで、データを保護しセキュリティのカルチャーを強化する方法について、多層防御の観点から詳しく学ぶことができます。 Expo の概要 クラウドセキュリティについて AWS のエキスパートと直接話したいですか？ Expo 会場 のセキュリティアクティベーションエリアで、AWS のセキュリティエキスパートと 1 対 1 で会話できるこの機会をお見逃しなく。組織のセキュリティポスチャを強化するお手伝いをします。 以下のような主要なセキュリティ領域について詳しく説明します 検出と対応: 大規模なワークロードを保護するために、セキュリティリスクの検出と対応のテクニックを探ります。 ネットワークとインフラストラクチャのセキュリティ: AWS サービスを使用して、安全なグローバルネットワークを構築および管理する方法を学びます。 アプリケーションセキュリティ: セキュアなソフトウェアを提供し、アプリケーションセキュリティの課題に対処するための戦略を探ります。 アイデンティティとアクセス管理: 最新のクラウドネイティブなアイデンティティソリューションを採用し、最小権限のアクセス制御を適用します。 デジタル主権とデータ保護: データの制御を維持し、AWS クラウドでデータをセキュアに保護し管理する方法を選択できます。 楽しみはまだまだこれから！ 革新的な洞察と深い学習に満ちた刺激的な 1 週間の後、世界的に有名な re:Play パーティー にご参加ください。これは re:Invent のフィナーレを飾るパーティーです！ヘッドライナーアーティストによるライブエンターテイメント、絶品の料理、たっぷりの飲み物に囲まれながら、リラックスし、交流を深め、無限の可能性に満ちた未来に乾杯しましょう。 今すぐ登録 re:Invent 2024 は素晴らしいイベントになることは間違いありません。みなさまにお会いできることを楽しみにしています！ 今すぐ登録 して、参加枠を確保してください。 このブログに関する質問がある場合は、 AWS サポートにお問い合わせ ください。 Apurva More Apurva は AWS セキュリティ、ID、およびコンプライアンスチームのメンバーで、スタートアップから大企業まで、グローバルなプロダクトマーケティングで 13 年の経験を持っています。市場ポジショニング、競合分析、顧客インサイトのエキスパートとして知られ、ターゲット層に響き収益成長を促進する製品を立ち上げてきました。また、製品ビジョンと市場ニーズ、ビジネス目標を連携させるため、部門を超えた協力を行っています。 Justin Criswell Justin は AWS のセキュリティソリューションアーキテクチャのシニアマネージャーです。クラウドセキュリティとカスタマーサクセスを専門とする 12 年を含む、20 年にわたる技術 expertise を持っています。企業の AWS ユーザーがセキュリティサービスを導入・運用し、可視性を高め、リスクを低減し、AWS クラウドでのセキュリティポスチャを強化するために、スペシャリストチームを率いています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

この記事は、“ Orchestrating Clinical Generative AI Workflows Using AWS Step Functions ” を翻訳したものです。 医療分野の急速な進化に伴い、生成 AI を活用することで、患者ケアを革新し、臨床プロセスを合理化する可能性があります。しかし、HIPAA などの規制に準拠しながら、データのセキュリティを確保しつつ、これらの複雑なワークフローを調整することは難しい課題です。一般的なパターンは、ソースデータから始め、生成 AI モデルを選択し、プロンプトを使用して各データレコードに対して特定のタスクを実行することです。このブログ記事では、 AWS Step Functions と他の AWS サービスを組み合わせて、セキュアで拡張性と柔軟性に優れた、臨床生成 AI ワークフローのオーケストレーションソリューションを構築する方法を探ります。 ユースケース例 図 1: アーキテクチャ図 この設計を実証するため、私たちは AWS HealthLake 、 Amazon Bedrock などの生成 AI サービス、および他の AWS コンポーネントを組み合わせて、臨床ノートを要約するヘルスケア特化ソリューションを構築しました。簡単なデプロイと管理のために AWS Cloud Development Kit (CDK) を使用して構築されたこのソリューションは、 GenAIWorkflow と呼ばれる AWS Step Functions ステートマシンによってオーケストレーションされています。以下で、このワークフローの各ステップを確認しましょう。 図 2. GenAIWorkflow ステートマシン まず、 AWS Systems Manager Parameter Store からクエリパラメータを取得します。パラメータには、処理するレコード ID のリストを取得する Amazon Athena クエリと、AWS HealthLake データストアの詳細が含まれます。 Amazon Athena の StartQueryExecution を呼び出して、Athena クエリを実行します。 Amazon Athena の GetQueryResults は、クエリの結果であるレコード ID のリストを取得します。クエリと結果セットによっては、最大数の結果が返されます。追加の結果がある場合は、 NextToken が返され、すべてのレコードを取得するには後続のクエリを実行する必要があることを示します。 分散モードのマップステート は、返されたレコード ID のリストを反復処理し、同時に処理します。デフォルトでは、Step Functions は同時実行数 10 を使用します。 各レコード ID について、Amazon Athena の StartQueryExecution API を呼び出してクエリの実行を開始します。 このステップでは、クエリの結果 (レコード ID に関連付けられたレポートのコンテンツ) を取得します。 Choice State を使用して、このステップでは、処理ロジックを続行する前に結果が返されたかどうかを判断します。 これは、 AWS Lambda 関数を使用して、Athena クエリの結果に必要な書式設定を行うオプションのステップです (例: 複数の列の値を 1 つの値に結合する、またはクエリ結果から JSON レコードを作成する)。 Parameter Store から、特定のタスクのプロンプトテンプレートを取得します。このプロンプトは、ユースケースに合わせてカスタマイズし、呼び出すモデルに最適化する必要があります。 このステップでは、プロンプトテンプレートとレポートコンテンツを組み合わせてプロンプトを作成し、Amazon Bedrock API を呼び出します。ここでは、さまざまな種類の Amazon Bedrock API 呼び出しの例外をキャッチして再試行するメカニズムを設定できます。 別の Lambda 関数を呼び出して、Amazon Bedrock API レスポンスを解析し、出力データを Amazon DynamoDB テーブルに保存できる形式に変換します。 PutItem API を使用して、構造化された出力データを DynamoDB テーブルに保存します。 結果が返されない場合は、反復処理をスキップします。 Choice state を使用して、 NextToken 値の有無を判断します。 NextToken が存在する場合は、Amazon Athena の GetQueryResults API を NextToken とともに再度呼び出して、次のバッチの結果を取得します。 処理するレコードがなくなると、ワークフローが成功します。 メリット AWS Step Functions を使用して生成 AI ワークフローを調整することには、いくつかの利点があります。Step Functions の中核は、さまざまな AWS サービスとシームレスに統合されるビジュアルワークフロー調整ツールであり、複雑な臨床生成 AI ワークフローを管理するのに最適です。このソリューションではセキュリティが最重要で、特に Step Functions が最近 カスタマーマネージドキーのサポート を発表したことで、独自の暗号化キーを使用してワークフロー定義と実行データを暗号化できるようになりました。この強化されたセキュリティは、 AWS KMS Customer Managed Keys (CMKs) を通じて保護された医療情報 (PHI) の堅牢な取り扱いと、遷移中と処理中の両方でコンポーネント全体にわたる包括的な暗号化にも及びます。このアーキテクチャは、Amazon Athena、AWS Lambda、Amazon DynamoDB などのサービスを通じて、セキュアなデータ処理とストレージを活用しています。また、このソリューションは非常に拡張性が高く、SQL クエリと生成 AI プロンプトを AWS Systems Manager Parameter Store のパラメータとして格納しているため、コード変更なしに変更が可能です。さらに、Lambda 関数を更新して、生成 AI ステップの前後にユースケース固有のロジックを組み込むこともできます。 このソリューションは、運用の信頼性とパフォーマンスにも優れています。Step Functions には、組み込みのエラー処理と再試行メカニズムがあり、自動再試行や適切な障害処理を通じてワークフローの回復力を確保します。また、 redrive 機能を使用して、失敗したステップから実行を再開することができます。以下のスクリーンショットは、Step Functions のビジュアルエディタと、堅牢なエラー処理機能を示しています。このアーキテクチャでは、Lambda や Athena などのサーバーレステクノロジーを活用しているため、ワークロードに基づいて自動的にスケーリングされ、必要なリソースのみを消費することで、パフォーマンスとコスト効率の両方を最適化できます。最後に、Step Functions には包括的な監視とログ機能が組み込まれているため、ワークフローの進行状況を追跡し、プロセスの各ステップでの入出力データを検査することができます。 図 3. Step Functions のエラー処理 次のステップ AWS Step Functions やその他の AWS サービスを活用することで、臨床現場での生成 AI ワークフローを実現するための、セキュリティ、拡張性、スケーラビリティに優れたソリューションを構築できます。これにより、医療機関は生成 AI の可能性を最大限に活用しながら、データ保護とコンプライアンスの最高水準を確保できます。 このソリューション を検討し、ご自身の要件に合わせてカスタマイズし、患者ケアと臨床プロセスに新たな可能性を切り開いてください。私たちはコミュニティとの協力を重視しており、 プルリクエスト を送ってソリューションの機能強化に貢献したり、 GitHub の Issue で問題を報告したり、コメント欄で経験や提案を共有したりすることを歓迎します。皆様のフィードバックと参加により、このソリューションを改善し、医療コミュニティのニーズにより良く応えられるよう努めていきます。 Qing Liu Qing Liu はAWSのシニアソリューションアーキテクトです。彼はヘルスケアIT業界で10年以上の経験を持っています。彼はヘルスケアデータを活用してより良い洞察を得て患者の治療成績を改善することに情熱を注いでいます。余暇には、妻や友人とテニスをするのが好きです。 Nick Ragusa Nick Ragusa はAWS教育チームのプリンシパルソリューションアーキテクトで、教育機関や大学病院がクラウド技術を活用して学習体験と患者の治療成績の両方を変革するのを支援しています。クラウドソリューションの設計をしていない時は、3人の子供たちのスポーツイベントで観客席から声援を送ったり、さわやかな秋の朝のランニングで思索しながら長距離を走ったり、あるいは慎重に選んだデザートで甘い物好きの自身を満足させたりしています。 翻訳は Solutions Architect 窪田が担当しました。原文は こちら です。

このブログは、2024 年 11 月 14 日に AWS Cloud Operations Blog で公開された “ Operations re:Imagined – Know Before You Go – AWS re:Invent 2024 ” を翻訳したものです。 12 月 2 日から 12 月 6 日にかけて毎年恒例のクラウドコンピューティングカンファレンス、 AWS re:Invent 2024 がラスベガスで開催されます。このカンファレンスでは、刺激的な基調講演に参加し、サービスを深く掘り下げて学び、クラウド利用に熱意のあるユーザー同士で交流する機会が得られます。初心者からエキスパートまで、全ての参加者に合わせたセッションやイベントをご用意しています。 学習するサービスが多数あるため、オペレーションに関するセッションを事前に検討しておくことをおすすめします。AWS でのノードやアプリケーションの管理は複雑になりがちですが、ハイブリッド環境やマルチクラウド環境でも同様です。特に新しい技術が絶えず登場する中で、一元的な運用によりノードやアプリケーションの運用面での洞察を得ることができます。AWS Systems Manager、Amazon CloudWatch、AWS Resource Explorer などのサービスは、AWS とそのお客様の両方に利益をもたらすベストプラクティスを適用するよう設計されています。大量なリソースの管理とタグ付けから、運用データに基づいて改善を促す洞察の提供まで、AWSにおける運用のベストプラクティスを強化する最新機能をご覧いただけます。 AWS re:Invent では、参加者のスキルレベルに合わせて様々な形式のセッションをご用意しています。セッション ID によってレベルが示されています。re:Invent のセッションタイプの詳細は こちら をご覧ください。 このブログでは、AWS クラウド運用をさらに活用するための、AWS re:Invent 2024 の一元的な運用に関するセッションをいくつか紹介します。 筆者のおすすめ マルチアカウント環境の構築に取り組む際、タグポリシーの実装や、アカウントにまたがって展開されたリソースの管理に関する課題に直面することがあります。タグ付けとリソース管理は、クラウド基盤構築の重要な要素ですが、組織にとって適した戦略を考案するのは時間がかかる作業です。そこで、AWS エキスパートが異なるお客様向けに実践してきた様々な戦略について議論するセッションをご紹介します。ここでの洞察が、タグ付けとリソース管理の戦略立案や、既存の取り組みの改善の一助となれば幸いです。 COP351 | Effective multi-account tagging and resource discovery strategies – Chalk Talk 数千ものリソースを複数のアプリケーションや AWS アカウントにまたがって管理する際は、適切なタグ付けとリソース管理の戦略を立案し、実行に移すのは時間がかかり、非常に複雑な作業となります。このセッションでは、未タグ付けのリソースを検出し、アプリケーションごとにリソースを整理する方法、および AWS Organizations を使ったアプリケーションの管理方法について学びます。さらに、リソースとアプリケーションを大規模に管理する方法について、AWS エキスパートに質問する機会も設けられています。 その他の運用管理セッション COP321 | Centralize Multicloud Management using AWS – Breakout Session マルチクラウド環境で運用する場合、オペレーションの複雑さが増す可能性があります。このセッションでは、AWS Systems Manager を使ってインスタンスの管理を簡素化する方法を学びます。Amazon CloudWatch と Amazon Managed Grafana を活用すれば、あらゆるデータソースからのメトリクスとログを単一のダッシュボードで把握できます。これらのサービスを使えば、AWS やオンプレミス、他のクラウドにまたがるワークロードの日々のタスクを簡素化し、コントロールを維持しつつリソースを最適化できます。マルチクラウドの複雑さを解消し、ビジネスに集中できるようサポートします。 COP325 | Operating your fleet of resources at scale is easier than you think! – Breakout Session これまでは、大規模な組織全体にまたがった AWS リソース、マルチクラウド、オンプレミスのリソースを運用するには多数のツールと手動プロセスが必要でした。AWS では自動化によって効率を高め、コストを削減できます。このセッションでは、AWS Systems Manager、Amazon CloudWatch などのサービスを使って、コンピューティングリソースの一括パッチ適用、アプリの展開、インシデントの解決など、さまざまな運用タスクを自動化する方法を学びます。数多くのお客様が、数百万ものリソースを AWS、マルチクラウド、オンプレミス、IoT にわたって管理するのに、これらのサービスを活用しています。今回、それらのサービスがさらに簡単に使えるようになりました。 COP328 | Streamlining application management on AWS – Breakout Session 開発チームとオペレーションチームには、リソースを効率的に管理・監視できる一元的な方法が必要です。このセッションでは、AWS myApplications を使ったアプリケーションの管理と監視のベストプラクティスを考察します。リソースを論理的なアプリケーション単位で整理する方法や、単一のダッシュボードからアプリケーションポートフォリオの可視化、コスト、セキュリティ、パフォーマンスの重要指標の把握、標準化された方法でのアプリケーションの展開と拡張を加速する方法について説明します。 COP337 | All things patching: Manage and monitor at scale – Chalk Talk このセッションでは、AWS Organization に属する EC2、オンプレミス、マルチクラウドのインスタンスの最新のオペレーティングシステムセキュリティパッチを確実に適用する、一元的なパッチ管理アプローチについて学びます。管理アカウントでポリシーを定め、アカウントやアプリケーションのコンプライアンス状況を把握する方法を習得します。さらに、組織全体のインスタンスからどのパッチが不足しているかを素早く特定する方法も学びます。これにより、セキュリティ脆弱性への対応時間を短縮し、組織全体のセキュリティポスチャーを高めることができます。 COP339 | Adopt AWS’s Ops management culture on your team – Chalk Talk AWS は、サービスの信頼性がお客様の重要な要件であることを認識しています。このセッションでは、非中央集権組織において、重要なプロセスであるインシデント管理を Amazon がどのように文化的・技術的な仕組みを用いて効果的に運用しているかについて学びます。重大度判断、優先順位付け、インシデント対応と緩和に使われる当社のメカニズムとツールを掘り下げて説明し、それらを支える Amazon の企業文化についても探ります。日々のオペレーション負荷を軽減し、インシデントの平均解決時間 (MTTR) を短縮するために、Amazon が使っている実践的な手法とツールについて解説します。 COP346 | Centralize audit data for hybrid and multicloud environments – Chalk Talk お客様がクラウドへの移行を加速し、事業変革を遂げる中で、ハイブリッド環境の IT 運用を管理しなければならない状況に直面することがあります。これにお困りではありませんか？このセッションでは、AWS CloudTrail Lake を有効にし、過去の CloudTrail ログをインポートし、パートナー製品との統合、カスタムソリューション、多数の AWS リソースからの監査ログを集約する方法を説明します。また、調査分析とセキュリティ目的でこのデータをクエリする方法についても扱います。 まとめ このブログでは、AWS クラウド運用に関連するいくつかのセッションをご紹介しました。re:Invent の当日は、AWS ビレッジのクラウド運用ブースにお立ち寄りいただき、さらに詳しいお話をお聞きいただければと思います。セッションの詳細は、re:Invent の イベントセッションサイト をご確認ください 筆者について Tiffany Chen Tiffany は、ヘルスケアとライフサイエンス業界を担当する AWS のソリューションアーキテクトです。デプロイメント業務のサポートを行い、現在はエンタープライズ顧客と協力して、Well-Architected にコスト最適化されたソリューションの構築に取り組んでいます。趣味は旅行、園芸、お菓子作り、バスケットボールの観戦です。 Winnie Chen Winnie は AWS のソリューションアーキテクトで、金融サービス業界の新規顧客を支援しています。AWS上でのインフラストラクチャの移行と構築を支援しています。趣味は旅行、ハイキング、自転車、岩登りなどのアウトドア活動です。

この記事は Amazon EKS and Kubernetes sessions at AWS re:Invent 2024 (記事公開日: 2024 年 11 月 16 日) を翻訳したものです。 イントロダクション Amazon Web Services の年次イベントである AWS re:Invent 2024 が近づいています。今年のイベントでは、Kubernetes やその他のクラウドネイティブ技術に焦点を当てたセッションのフルトラックを含みます。広大なセッションカタログを簡単に参照できるよう、Kubernetes とクラウドネイティブ関連トピックのセッションリストを作成しました。 コアトピックごとにまとまっており、re:Invent セッションカタログのセッション詳細へのリンクもあります。 さぁ、参加者ポータルのカタログで、今すぐセッションを予約し始めましょう。 興味のあるセッションの予約席を確保できない場合は、ほとんどのセッションタイプで Walk-up 席が利用できます。 注目すべきセッションの 1 つに、 KUB201: Kubernetes on AWS の未来 があります。ここでは、 AWS の Kubernetes Head of Product である Nathan Taber 氏 と、 Snowflake の Princilal Software Engineer である Hyungtae Kim 氏 が登壇します。このセッションでは、EKS の最新のイノベーションと、Snowflake の次世代 AI/ML プラットフォームの洞察について学ぶことができます。 必ず聞くべきセッションの 1 つに、 CMP215: あらゆるアプリケーションのためのコンピューティング・イノベーション があります。こちらは、 AWS の VP & Distinguished Engineer, Compute & Networking, Amazon EC2 である Anthony Liguori と、 AWS の VP Serverless Compute である Holly Mesrobia によるセッションです。 このセッションでは、AWS のインフラとソリューションに対する革新の取り組みが紹介されます。これによりお客様は、クラウドだけでなくオンプレミスやエッジでもアプリケーションのビルド、実行、スケーリングが可能になります。 是非ご参加いただき、これらの AWS のイノベーションがコンピューティングの世界をどのように変革しているか、内部からの視点をご覧ください。 さまざまなセッション形式の詳細な説明は re:Invent ラーニングフォーマット をご確認ください。 Kubernetes によるプラットフォームの構築 Amazon EKS – Kubernetes とコンテナによって構築されたアプリケーションや開発者プラットフォームの最新のイノベーションを探索しましょう。今年の re:Invent のラインナップには、コンテナ化が初めての方でも、既にあるワークフローを改善したい方であっても、Kubernetes のスキルを向上させるのに最適なセッションが用意されています。 AWS のエキスパートや同じ考えを持つプロフェッショナルと協力して、Kubernetes の管理を簡素化し、あらゆる規模のチームにとっての可能性を解き放つ、最新の戦略を探ってください。 KUB308 | IDP ファストトラック: エンタープライズ DevOps のための CNOE を活用したデプロイレース(ワークショップ) KUB301 | Amazon EKS を用いた、スケーラブルなプラットフォームの構築 (ブレイクアウト) PEX402-R | Amazon Q を用いた AWS におけるモダンなエンジニアリング技術の取り入れ (ワークショップ) KUB102-S | Zesty における最適化されたプラットフォームによる Kubernetes 管理の革新 (ライトニングトーク) KUB402-R | Amazon EKS: Infrastructure as code、GitOps、CI/CD (チョークトーク) KUB306-R | Amazon EKS へのアプリケーションデプロイの簡素化 (ビルダーセッション) KUB307-R | 組織における Kubernetes のスケールの基礎 (ワークショップ) SAS311-R | Amazon EKS でのマルチテナント SaaS アーキテクチャの最適化 (チョークトーク) データ、機械学習、生成 AI これらのセッションに参加して、AWS 上のデータ処理、機械学習、Kubernetes が交差する領域を探索してください。これらのセッションは、EKS を分析のためのデータプラットフォームとして活用することから、生成 AI モデルのデプロイとスケーリング、責任ある AI のプラクティスの採用まで、EKS のスケールとパフォーマンスを、データ処理、機械学習、生成 AI と組み合わせるうえでの、貴重な洞察を提供します。 KUB405 | 分析のためのデータプラットフォームとしての Amazon EKS (ブレイクアウト) KUB313 | Amazon EKS 上の MLOps のためのアーキテクチャパターン (チョークトーク) KUB401 | Amazon EKS におけるデータと生成 AI (ワークショップ) KUB314 | Amazon EKS におけるハイパフォーマンスな生成 AI (ブレイクアウト) KUB316 | Amazon EKS への最適化された推論パイプラインのデプロイ (チョークトーク) KUB403 | Amazon EKS における高性能な LLM 推論のスケーリング (チョークトーク) KUB320-R | Amazon EKS でのモダンなデータ処理パイプラインの構築 (チョークトーク) OPN309-R | オープンソースと共に実現する責任ある生成 AI の実践 (チョークトーク) DAT202-S | チャットボットを超えて: AI がリアルタイムにビジネスクリティカルな意思決定をおこなう方法 (ブレイクアウト) STG406-R | Amazon S3 と Amazon EKS での AI/ML ワークロードのオンボーディングと最適化 (ワークショップ) ANT410 | Amazon EMR on EKS でデータパフォーマンスを最大化する (チョークトーク) コスト最適化とパフォーマンス Amazon EKS での Kubernetes 環境における、クラスター効率の最大化、無駄の削減、イノベーションの解放のための最新の戦略を発見するために、ご参加ください。 これらのセッションでは、クラスターを動的にスケーリングする方法、Kubernetes のコストをビジネス価値と整合させる FinOps アプローチを採用する方法、クラウドコスト最適化のベストプラクティスを探索する方法についての知識を身につけることができます。 KUB312 | Amazon EKS と Karpenter による自動化されたクラスターインフラストラクチャー (ブレイクアウト) KUB309-R | Karpenter: Amazon EKS のベストプラクティスとクラウドコストの最適化 (ワークショップ) KUB311-R | Kubernetes を採用する FinOps :ビジネス革新のためのコスト最適化 (チョークトーク) セキュリティ AWS で Kubernetes ワークロードを実行しているお客様にとって、セキュリティは最も重要です。これらのセッションに参加して、Kubernetes のセキュリティの重要な領域を探索し、EKS 環境の保護に役立つ重要なツールとベストプラクティスを理解しましょう。これらのセッションでは、Kubernetes ワークロードの保護を深く掘り下げ、ソフトウェアサプライチェーンを最適化し、セキュリティと可観測性が交差する領域を調査し、Policy as Code で Kubernetes のセキュリティを強化する方法を学ぶことができます。 KUB319 | Amazon ECR を使用したソフトウェアサプライチェーンのセキュリティ強化と最適化 (チョークトーク) KUB315 | Amazon EKS における Kubernetes ワークロードのセキュリティ対策 (ブレイクアウト) KUB305-R | Amazon EKS クラスターのセキュリティ対策と監視 (ビルダーズセッション) KUB302-R | セキュアなコンテナ環境の戦略とベストプラクティス (チョークトーク) OPN306-R | Kyvernoを使った Policy as Code によるKubernetes セキュリティ強化 (チョークトーク) ストレージ Amazon EKS 上のコンテナ化アプリケーションのストレージを効果的に管理および最適化する方法を知ることができます。 ステートフルワークロード向けに AWS ストレージサービスを活用する方法と、コンテナ化アプリケーションのデプロイにおけるベストプラクティスを探求します。 KUB324 | AWS のストレージサービスを活用した、Amazon EKS でのステートフルなワークロードの実現 (ライトニングトーク) STG331 | Amazon EBS でのコンテナ化されたアプリケーションのデプロイ (チョークトーク) 運用、デプロイ、可観測生 re:Invent 2024 で、EKS の効率的な運用、堅牢な可観測性、効果的なデプロイ戦略に深く踏み込む包括的なセッションを披露できることを楽しみにしています。参加者の皆様は、生成 AI を活用して EKS 運用を最適化する方法、可観測性のベストプラクティス、Kubernetes とサーバーレスコンピューティングが交差する領域、Kubernetes API を介したインフラストラクチャの管理の最新動向を探索する機会が得られます。手を動かしたい方向けに「Amazon EKS フリート管理への Dive Deep」ワークショップでは、Kubernetes 環境の効果的な管理とスケーリングの実践的な体験を提供します。 KUB321 | 生成 AI で Amazon EKS の運用を効率化する(コードトーク) KUB323 | Amazon EKS ワークロードにおける可観測性戦略 (ライトニングトーク) KUB101-S | Amazon EKS ワークロードにおける可観測性のデータコストと複雑さの制御 (ライトニングトーク) KUB303-R | Amazon EKS フリート管理への Dive Deep (ワークショップ) KUB203-S | プロダクトカルチャーの再構築: Smarsh による AWS でのスケーリングと移行 (ライトニングトーク) KUB202-S | 生成 AI のスケーリング: Kubernetes での運用課題の対処 (ブレイクアウト) KUB304-R | Cloud-native Java on AWS (ビルダーズセッション) API308 | Kubernetes が出会う Serverless: Kubernetes API で EDA をデプロイする (ブレイクアウト) OPN312 | Infrastructure as Kubernetes API (ブレイクアウト) OPN202 | AWS Controllers for Kubernetes による API 経由のインフラストラクチャ管理 (ライトニングトーク) SAS404 | Kubernetes DevOps ツールを活用した SaaS プロビジョニングとデプロイの自動化 (ワークショップ) スケーラビリティ、レジリエンシー、接続性 AWS に Kubernetes をデプロイするにあたって、アプリケーションのスケーラビリティ、レジリエンス、接続性を確保する必要があります。最新の戦略とイノベーションを探索し、本番グレードのアーキテクチャ構築、クラスターパフォーマンスの最適化、機械学習ワークフローの効率化の方法を学びましょう。 ネットワーク戦略やサービスメッシュから、コスト効果の高い ML トレーニングやエッジデプロイまで、 AWS 上での Kubernetes のポテンシャルを最大限に引き出すためのベストプラクティスとツールについて深掘りします。 KUB404 | Amazon EKS での本番グレードのレジリエンスアーキテクチャの構築 (ブレイクアウト) KUB406 | Kubernetes のネットワーク戦略 (ブレイクアウト) KUB310 | エッジおよびハイブリッドなユースケースのための Amazon EKS (ブレイクアウト) KUB322-R | Amazon EKS で回復力のあるアプリケーションを構築する (チョークトーク) KUB318-R | Karpenter による Kubernetes クラスターのスケール、最適化、アップグレード (チョークトーク) NET315 | Kubernetes のネットワーク戦略 (チョークトーク) OPN307 | Kubernetes の接続性: サービスメッシュから未来へ (チョークトーク) CMP403 | Amazon EKS と AWS Batch を活用したスケーラブルかつコスト効率な MLトレーニング (チョークトーク) AWS Village の Kubernetes kiosk や、Developer Pavilion の Modern Apps と Open Source Zone を訪れるため、 Expo Hall にお立ち寄りください。AWS 上でのモダンアプリケーション構築について専門家に質問したり、デモを見たり、オープンソースチームと会ったりできます。 立ち寄って挨拶をして、楽しんで、スナックをつまんで、クレーンゲームから商品をゲットしましょう！ re:Invent に直接参加できない場合も問題ありません！バーチャルパスを 登録 することで、Keynote と Leadership Session のライブ配信に参加できます。 また、ブレイクアウトセッションをお見逃しなく！イベント後に AWS Events YouTube でオンデマンド視聴できます。 これらのセッションや、AWS の専門知識があなたの組織にどのように役立つかについて、さらに詳しく知りたいですか？詳細は AWS アカウントチームにお問い合わせください。 あなたの組織で Kubernetes を最大限に活用する方法の詳細については、 Amazon EKS のウェブページをご覧ください。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

本ブログは “ Upgrade Amazon DocumentDB 4.0 to 5.0 with near-zero downtime ” を翻訳したものです。 Amazon DocumentDB (MongoDB 互換) は、MongoDB ワークロードをサポートする、高速でスケーラブルで可用性の高いフルマネージド型のドキュメントデータベースサービスです。基盤となるインフラストラクチャの管理について心配することなく、同じ MongoDB 3.6、4.0、5.0 アプリケーションコード、ドライバ、およびツールを使用して、Amazon DocumentDB でワークロードを実行、管理、およびスケーリングできます。Amazon DocumentDB はドキュメントデータベースであるため、JSON データの格納、クエリ、インデックス作成が行えます。 Amazon DocumentDB バージョン 5.0 のリリースにより、Amazon DocumentDB クラスターのバージョン 3.6 および 4.0 から 5.0 へのメジャーバージョンアップグレードを実行して、 複数の拡張機能 を活用できるようになりました。Amazon DocumentDB 5.0 は、ベクター検索、ドキュメント圧縮、I/O 最適化ストレージ、インデックス構築ステータスによる高速インデックス作成、クライアント側 Field Level Encryption (FLE) などをサポートしています。 この投稿では、 メジャーバージョンのインプレースアップグレード 、 Amazon DocumentDB ボリュームクローニング 、 AWS Database Migration Service (AWS DMS) を使用して、Amazon DocumentDB 4.0 から 5.0 へのダウンタイムをほとんど発生させずにアップグレードする方法を記載します。 既存のアップグレードオプション 現在、Amazon DocumentDB 4.0 のユーザーは、以下の方法を使用して Amazon DocumentDB 5.0 へのメジャーバージョンアップグレードを実行できます。 mongodump と mongorestore — mongodump や mongorestore などのコマンドラインユーティリティを使用して Amazon DocumentDB データベースのバイナリバックアップを作成し、それらを新しい Amazon DocumentDB 5.0 クラスターに復元できます。この方法では、アップグレード中に Amazon DocumentDB クラスターがオフラインになるため、ダウンタイムに耐えられるワークロードに最適です。 AWS DMS — AWS DMS を使用して、既存のクラスターから新しい Amazon DocumentDB 5.0 クラスターにデータを移行することができます。AWS DMS はマネージド型サービスで、サポートされているソースやターゲット間で既存のデータを移行するために使用できます。この方法では、追加の DocumentDB I/O 料金と AWS DMS の使用料が発生します。詳細については、「 AWS データベース移行サービスを使用した Amazon DocumentDB クラスターのアップグレード 」を参照してください。 インプレース メジャーバージョン アップグレード — この機能を使用すると、データの移行やエンドポイントを変更したりする必要なく、Amazon DocumentDB クラスターのインプレースアップグレードを実行できますが、ダウンタイムが必要となり、ダウンタイムの長さはコレクション、データベース、コレクション、インデックスの数によって異なります。詳細については、 インプレース メジャーバージョン アップグレードのドキュメント を参照してください。 ソリューション概要 この記事では、メジャーバージョンのインプレースアップグレード、ボリュームクローニング、AWS DMS を使用して、ダウンタイムをほとんど発生させずにメジャーバージョンアップグレードを実行するハイブリッドアプローチについて説明します。このアプローチでは、クラスターデータ全体を新しいエンドポイントに移行する際に通常かかる I/O コストとアップグレードに要する時間を最小限に抑えることもできます。この手法は下記の流れで実施します。 Amazon DocumentDB クラスターで変更ストリームを有効にする Amazon DocumentDB クラスターのクローンを作成します クローンしたクラスターでインプレースメジャーバージョンアップグレードを実行します AWS DMS を使用して Amazon DocumentDB クラスターからクローンクラスターに変更データキャプチャ (CDC) を複製します レプリケーションが終了したら、アプリケーションエンドポイントをクローンクラスターに変更します アップグレード後のクリーンアップを実行します 前提条件 さらに進めるには、AWS DMS、 インプレースメジャーバージョンアップグレード 、および ボリュームクローニング について高いレベルで理解している必要があります。このソリューションを利用すると、Amazon DocumentDB 変更ストリーム、AWS DMS レプリケーションインスタンス、その他のリソースに関連して、アカウントで発生するコストを最小限に抑えることができます。 AWS Pricing Calculator ツールを使用すると、設定に基づいてコストを見積もることができます。 Amazon DocumentDB クラスターをより高いバージョンにアップグレードする場合は、廃止された機能や演算子、または使用方法の変更がないか確認してください。アプリケーションを新しいバージョンに対して実行し、アプリケーションに意図的な変更がない限り、動作とパフォーマンスが以前のバージョンと同じであることを確認します。 エンドポイントの切り替え時に、ある程度のダウンタイムが発生することに注意してください。実稼働環境で試す前に、検証環境でこのアプローチを複数回ドライランすることを強くお勧めします。 Amazon DocumentDB クラスターで変更ストリームを有効にする Amazon DocumentDB クラスターのメジャーバージョンアップグレードを最小限のダウンタイムで実行するには、クラスターで 変更ストリーム を有効にする必要があります。変更ストリームは、Amazon DocumentDB クラスター内で発生する更新イベントを時系列で提供します。 CDC でトランザクション漏れが発生しないように、変更ストリームログの保持期間を設定する必要があります。変更ストリームログのデフォルトの保持期間は 3 時間です。この期間は 1 時間から 7 日の間の任意の値に設定できます。この属性は 24 時間以上に設定することをおすすめします。 次の AWS コマンドラインインターフェイス では、保持期間が 24 時間に延長されます。 aws docdb modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name <parameter group name> \ --parameters "ParameterName=change_stream_log_retention_duration, ParameterValue=86400,ApplyMethod=immediate" Amazon DocumentDB コンソール から変更ストリームを有効にすることもできます。 すべてのデータベースで変更ストリームを有効にするには、Amazon DocumentDB クラスターに接続し、次のコマンドを使用して変更ストリームを有効にします。 db.adminCommand({modifyChangeStreams: 1,database :"",enable: true}); 変更ストリームの作成を確認するには、 $listChangeStreams アグリゲーションパイプラインステージを使用して、クラスターで有効になっているすべての変更ストリームを一覧表示します。詳細については、「 変更ストリームの有効化 」を参照してください。 Amazon DocumentDB クラスターのクローン Amazon DocumentDB のクローニングでは、お使いの Amazon DocumentDB プロダクションクラスターと同じ Amazon DocumentDB クラスターボリュームを使用し、同じデータを持つ新しいクローンクラスターを作成できます。クローンの作成は、スナップショットの復元などの他の手法を使用してデータを物理的にコピーするよりも高速で、スペース効率も高くなります。 Amazon DocumentDB プロダクションクラスターのクローンを作成するには、以下のステップを実行します。 Amazon DocumentDB コンソールのナビゲーションペインで、[クラスター] を選択します。 Amazon DocumentDB プロダクションクラスターを選択し、[アクション] メニューで [クローンの作成] を選択します。 [クラスター識別子] に、クローンされた Amazon DocumentDB クラスターに付ける名前を入力します (たとえば、 cloned-docdb-cluster など)。 [インスタンス]、[構成]、[ネットワーク設定]、[保存時の暗号化]、[ログのエクスポート]、[ポート]、[削除保護] では、Amazon DocumentDB クラスターと同じ設定を選択します。Amazon DocumentDB クラスターとインスタンスの設定の詳細については、Amazon DocumentDB クラスターの管理を参照してください。 [クローンを作成] を選択して、選択した Amazon DocumentDB クラスターのクローンを起動します。クローンが作成されると、他の Amazon DocumentDB クラスターとともに [クラスター] ページに表示され、現在の状態が表示されます。状態が Available になると、クローンは使用できる状態になります。 クラスターページで、クローンクラスターを選択し、構成タブに移動して、クラスターの作成時間をメモします。 クローンされたクラスターでインプレースメジャーバージョンアップグレードを実行する このステップでは、データを移行したりエンドポイントを変更したりせずに、複製された Amazon DocumentDB 4.0 クラスターを 5.0 にアップグレードします。クローンされたクラスターでメジャーバージョンのインプレースアップグレードを実行しても、追加料金は発生しません。 インプレースメジャーバージョンアップグレードを実行する前に、前提条件となるステップをすべて完了していることを確認してください。詳細については、 Amazon DocumentDB インプレースメジャーバージョンアップグレード を参照してください。 Amazon DocumentDB イベントのサブスクライブ の手順に従って、クローンクラスターのメンテナンスイベントをサブスクライブします。次に、以下のステップを実行してクラスターをアップグレードします。 Amazon DocumentDB コンソールのクラスターページでクローンクラスターを選択し、アクションメニューで [変更] を選択します。 [クラスター識別子] に、クラスターの名前を入力します。 [エンジンバージョン] には 5.0.0 を選択します。 VPC セキュリティグループを指定します。 クラスターオプションセクションで、適切なデフォルトまたはカスタムクラスターパラメータグループを選択し、[Continue] を選択します。 「変更のスケジュール設定」セクションで、「すぐに適用」を選択します。 [Modify cluster] を選択して、クラスターのインプレースアップグレードを開始します。これで、クラスターのステータスが Upgrade に変わります。アップグレードが完了すると、クラスターのステータスが Available に戻り、「データベースクラスターのメジャーバージョンがアップグレードされました」というイベントが表示されます。イベントページを監視することで、アップグレードの進行状況を追跡できます。 インプレースメジャーバージョンアップグレードが完了したら、サニティチェックを実行して、アップグレードしたクローンが機能していて、すべてのデータとインデックスが損なわれていないことを確認します。 注:データの不整合が発生する可能性があるため、複製したクラスターのデータを変更しないように注意してください。 AWS DMS を使用して、ソースクラスターからクローンクラスターに CDC をレプリケートする このステップでは、クローンの作成後に行われたすべてのデータベース変更をレプリケートすることで、クローンクラスターを Amazon DocumentDB ソースクラスターと同期させます。AWS DMS レプリケーションインスタンスは、Amazon DocumentDB プロダクションクラスターに接続してデータを読み取り、それをターゲットのクローンクラスターに書き込むことで CDC を実行します。 AWS DMS レプリケーションインスタンスを作成する レプリケーションインスタンスを作成するには、以下のステップを実行します。 AWS DMS コンソールで [レプリケーションインスタンスを作成] を選択します。 名前 ( docdb40todocdb50 など) とオプションの説明を入力します。 インスタンスクラスでは、必要に応じてサイズを選択します。 [エンジンバージョン] で [3.5.1] を選択します。 Amazon VPC の場合は、ソースとターゲットの Amazon DocumentDB クラスターを収容する VPC を選択してください。 [割り当て済みストレージ] には、デフォルトの 50 GiB を使用します。書き込みスループットのワークロードが高い場合は、ワークロードに合わせてこの値を増やしてください。 マルチ AZ では、高可用性とフェイルオーバーサポートが必要な場合は [はい] を選択してください。 パブリックにアクセスできるようにするには、このオプションを有効にします。 [レプリケーションインスタンスを作成] を選択します。 AWS DMS のソースエンドポイントとターゲットエンドポイントの作成 ソースエンドポイントを作成するには、以下のステップを実行します。 AWS DMS コンソールのナビゲーションペインで [Endpoints] を選択します。 [エンドポイントの作成] を選択します。 [エンドポイントタイプ] で [ソース] を選択します。 [エンドポイント識別子] には、覚えやすい名前 ( docdb40-source など) を入力します。 [ソースエンジン] には [Amazon DocumentDB] を選択します。 [サーバー名] には、Amazon DocumentDB プロダクションクラスターの DNS 名を入力します。 ポートには、Amazon DocumentDB プロダクションクラスターのポート番号を入力します。 SSL モードの場合は、[すべてを確認] を選択します。 CA 証明書の場合は、「新しい CA 証明書の追加」を選択し、次の手順を実行します。 新しい CA 証明書をダウンロードして TLS 接続バンドルを作成します。 「証明書の識別子」には、 global-bundle.pem と入力します。 [新しい CA 証明書の追加] で [ファイルを選択] を選択し、ダウンロードした.pem ファイルに移動します。 ファイルを選択して開きます。 [証明書のインポート] を選択し、[証明書の選択] ドロップダウンメニューで global-bundle.pem を選択します。 [ユーザー名] には、ソースクラスターのプライマリユーザー名を入力します。 Password には、ソースクラスターのプライマリパスワードを入力します。 Amazon DocumentDB クラスターのすべてのデータベースから CDC を複製する場合は、[データベース名] を空白のままにします。または、テーブルマッピングを使用して特定のデータベースを指定することもできます。 エンドポイント接続をテストし、接続が機能することを確認します [エンドポイントの作成] を選択します。 2 つ目のエンドポイントを作成し、エンドポイントタイプに Target を選択し、クローンしたクラスターの詳細を指定します。 AWS DMS 移行タスクを作成する AWS DMS タスクはレプリケーションインスタンスをソースインスタンスおよびターゲットインスタンス関連付けます。移行タスクを作成するときは、ソースエンドポイント、ターゲットエンドポイント、レプリケーションインスタンス、および必要な移行設定を指定します。AWS DMS タスクには、「既存のデータを移行する」、「既存のデータを移行して、継続的な変更をレプリケートする」、「データ変更のみをレプリケートする」の 3 つの移行タイプがあります。 クラスター作成の開始までにすべてのデータを含むボリュームクローンを使用してターゲットクラスターを作成した場合は、クラスター作成後にソースで発生した差分変更をコピーするだけでよいので、AWS DMS の「データ変更のみをレプリケートする」移行タイプを使用します。このオプションを使用すると、AWS DMS はソースクラスターの動作を維持したまま、変更内容をクラスターからクローンクラスターにレプリケートします。最終的に、ソースデータベースとターゲットデータベースは同期され、移行のダウンタイムはほぼゼロになります。 次の手順を実行して移行タスクを作成します。 AWS DMS コンソールのナビゲーションペインで [Tasks] を選択します。 [タスクを作成] を選択します。 [タスク識別子] に、名前 ( mvu-cdc-task など) を入力します。 [レプリケーションインスタンス] で、作成したレプリケーションインスタンスを選択します。 [ソースデータベースエンドポイント] で、作成したソースエンドポイントを選択します。 [ターゲットデータベースエンドポイント] で、作成したターゲットエンドポイントを選択します。 [移行タイプ] で [データ変更のみをレプリケート] を選択します。 「タスク設定」セクションで、「ウィザード」を選択し、「カスタム CDC 開始モードを有効にする」を選択します。 開始時間を、先ほど書き留めたクローンクラスターの作成時間の 2 分早く指定してください。 [ターゲットテーブル準備モード] で [何もしない] を選択します。 LOB 列の設定では、デフォルトの最大 LOB サイズ (32) で制限付き LOB モードを選択します。 [CloudWatch ログの有効化] を選択します。 詳細タスク設定はデフォルト設定のままにします。 テーブルマッピングでは、[ウィザード] を選択します。 「選択ルール」で、スキーマには「EnterSchema」、ソース名には「%」、ターゲット名には「%」、「アクション」には「include」を選択します。 [タスクを作成] を選択します。 監視と検証 これで、AWS DMS はソース Amazon DocumentDB クラスターからターゲット Amazon DocumentDB クラスターへの CDC のレプリケーションを開始します。タスクステータスが [開始] から [レプリケーション中] に変わるはずです。AWS DMS コンソールのタスクページで進捗状況をモニタリングできます。変更内容によっては、数分から数時間かかることがあります。DMS タスクに 並列スレッドを追加 することで、CDC のスループットを向上させることができます。 最終的に、ソースとターゲットは同期されます。コレクションで count () 操作を実行してすべての変更イベントが移行されたことを確認することで、両者が同期しているかどうかを確認できます。 Amazon DocumentDB DataDiffer ツール を使用してデータ検証を実行することもできます。 レプリケーションが追いついたら、アプリケーションエンドポイントを 5.0 クラスターに変更 新しい Amazon DocumentDB 5.0 クラスターが同期され、すべてのチェックに合格したことを確認したら。これで、アプリケーションのデータベース接続エンドポイントを Amazon DocumentDB クラスターから Amazon DocumentDB 5.0 クラスターに変更する準備が整いました。 アップグレード後のクリーンアップを実行 以下の手順を実行してリソースをクリーンアップできます。 Amazon DocumentDB クラスターを削除 します。 Amazon DocumentDB 5.0 プロダクションクラスターの変更ストリームを無効にします。 必要に応じて AWS DMS インスタンス、レプリケーションタスク、エンドポイントをすべて削除 します。 Amazon DocumentDB 5.0 クラスターにインスタンスを追加して Amazon DocumentDB プロダクションクラスターに一致させるには、Amazon DocumentDB コンソールのクラスターページでクローンクラスターを選択し、アクションメニューで [インスタンスを追加] を選択します。 Amazon DocumentDB 4.0 クラスターにあったモニタリングとアラートをコピーまたは設定します。 結論 この投稿では、インプレースメジャーバージョンアップグレードと AWS DMS を使用して、Amazon DocumentDB 4.0 から 5.0 にアップグレードする方法と、ダウンタイムをほぼゼロに抑える方法を紹介しました。 Amazon DocumentDB 5.0 は、ベクター検索、ドキュメント圧縮、I/O 最適化ストレージ、インデックス構築ステータスによるインデックス作成の高速化、クライアント側 FLE などをサポートしています。Amazon DocumentDB クラスターのバージョン 3.6 と 4.0 から 5.0 へのメジャーバージョンアップグレードを実行することで、複数の拡張機能を活用できます。詳細については、 ドキュメントを参照 してください。 著者について Kunal Agarwal は、アマゾンウェブサービスのシニアプロダクトマネージャーです。Kunal はデータに情熱を傾け、顧客の問題を解決するスケーラブルな製品を構築することが大好きです。AWS に入社する前、Kunal はテクノロジー業界で製品管理と戦略に 12 年間携わっていました。 Anshu Vajpayee は、アマゾンウェブサービス (AWS) のシニア DocumentDB スペシャリストソリューションアーキテクトです。彼は、お客様が NoSQL データベースを採用し、Amazon DocumentDB を活用したアプリケーションをモダナイズできるよう支援してきました。AWS に入社する前は、リレーショナルデータベースと NoSQL データベースを幅広く扱っていました。 本ブログの翻訳はソリューション アーキテクトの大井が担当しました。

この投稿では、 AWS Network Load Balancer (NLB) の Transmission Control Protocol (TCP) フローのアイドルタイムアウトを設定する手順を説明します。 NLB は Open Systems Interconnection (OSI) モデルのレイヤー 4 で動作する Amazon Web Services (AWS) の Elastic Load Balancing ファミリの一部で、TCP または User Datagram Protocol (UDP) でクライアント接続を管理し、それらをロードバランサーのターゲットに分散します。 NLB は接続の確立から、非アクティブ (アイドルタイムアウト) による閉鎖またはタイムアウトまでを追跡します。 デフォルトでは、TCP 接続のアイドルタイムアウトは 350 秒、UDP 接続のタイムアウトは 120 秒です。 新しく TCP のアイドルタイムアウトが設定可能になったため、既存および新規の NLB TCP リスナーでこの属性を変更できるようになり、NLB が非アクティブな接続を終了するまでの時間を決められるようになりました。 TCP 接続確率の手順の理解 始める前に、TCP プロトコルの動作の概要を説明します。より深く理解するには、 TCP の RFC(RFC 9293) を参照してください。 図 1. TCP 接続確立の段階 TCP 接続には確立、データ転送、正常なクローズなどのいくつかの段階があります。 ハーフオープン : クライアントが SYN を送信し、サーバーが応答しますが、まだクライアントがハンドシェイクを完了していない状態。 接続確立 : 3 ウェイハンドシェイクが完了した状態。 データ転送 : ハンドシェイク後、クライアントとサーバーの間でデータを交換している状態。この図の部分は、読みやすくするために簡略化されています。 クローズ : クライアントが FIN パケットを送信し、正常にクローズされます。 NLB の TCP 接続処理 NLB は、レイヤー 4 プロキシとして動作し、確立された各接続をフローテーブルで追跡します。 ハーフオープン、正常にクローズした接続、またはクライアントまたはサーバーでリセットされた接続は追跡されません。 単一の接続は 5 つの属性の組み合わせ (5 タプル) によって定義され、プロトコル (TCP)、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポートからなります。 図 2. NLB デプロイのサンプルアーキテクチャ デフォルトでは、クライアントとターゲット間でトラフィックがない状態が 350 秒続くと、NLB のフローテーブルからその接続が削除されます。 接続が追跡されなくなった後にクライアントがトラフィックを送信しようとすると、NLB は新しい接続を確立する必要があることを示す TCP RST を返します。 多くのアプリケーションでは、接続がタイムアウトしても問題ありません。 しかし、一部の場合は問題となることがあります。 例えば、定期的にデータを送信する IoT (Internet of Things) デバイスは、それぞれの送信時で少量のデータしか転送しません。 そのたびにデータが送信されるごとに、特に暗号化された接続を再度開くと、リソースを大量に消費し、コストがかかります。 接続がタイムアウトしないように、TCP キープアライブを設定して、確立された接続に対して決められた間隔でプローブ(※1)を送信することができます。このプローブにはデータは含まれていませんが、NLB などの中継システムでのアイドルタイマーをリセットすることができます。TCP キープアライブの設定方法の詳細については、以前の記事” Implementing long-running TCP Connections within VPC networking “を参照してください。 アプリケーションで長期間持続する永続的な TCP 接続が必要で、TCP キープアライブを使用できない場合は、NLB の TCP アイドルタイムアウトを変更できます。 TCP アイドルタイムアウトの更新時の考慮事項 各 NLB TCP リスナーのアイドル タイムアウト値は 60 ～ 6000 秒の範囲内で調整できます。 この変更はすでに進行中の接続には影響せず、新しい TCP 接続にのみ影響します。 その他のリスナの種類 (TLS、UDP など) では、現時点でアイドル タイムアウト値の調整はサポートされていません。 アイドルタイムアウト値を設定する前に、アプリケーションのニーズを理解し、TCP キープアライブが代替手段になり得るかを検討してください。 NLB の TCP アイドルタイムアウトは、アプリケーションの TCP アイドルタイムアウトよりも長く設定するのが適切です。 つまり、NLB ではなく、アプリケーションが接続管理とタイムアウトを処理することになります。 アイドルタイムアウトを高すぎる値に設定すると、フローテーブルがいっぱいになるリスクが高まります。テーブルがいっぱいになると、NLB が新しい接続を暗黙に拒否するようになります。 Amazon CloudWatch の新しいメトリクス (監視セクションで説明) を使って、接続拒否を監視する必要があります。 接続が拒否された場合は、TCP アイドルタイムアウトの値を小さくする必要があります。 TCP アイドルタイムアウトを AWS API/CLI で設定する手順 AWS は TCP アイドルタイムアウト機能を Network Load Balancer に導入するにあたり、新しい API を公開しました。以下の例は API の動作を示しています。 TCP アイドルタイムアウトの現在の値を確認するための、NLB リスナーについて説明します。 入力: aws elbv2 describe-listener-attributes \ --listener-arn arn:aws:elasticloadbalancing:us-east-1:000011112222:listener/network/NLBTest/123/123 出力: { "Attributes": [ { "Value": "350", "Key": "tcp.idle_timeout.seconds" } ] } TCP アイドルタイムアウトの値を変更する 入力: aws elbv2 modify-listener-attributes \ --listener-arn arn:aws:elasticloadbalancing:us-east-1:000011112222:listener/network/NLBTest/123/123 \ --attributes \ Key = tcp.idle_timeout.seconds,Value = 600 出力: { "Attributes": [ { "Value": "600", "Key": "tcp.idle_timeout.seconds" } ] } TCP アイドルタイムアウトを AWS マネジメントコンソールで設定する手順 次の手順では、 AWS マネジメントコンソール でタイムアウト値を変更する方法を示します。 1. NLB の TCP リスナーを見つけます。 図 3. NLB TCP リスナー 2. Attributes セクションで現在の TCP アイドルタイムアウト の値を確認します。 図 4. NLB リスナーの Attributes 3. リスナー属性の編集 セクションで、新しい TCP アイドルタイムアウト 値を入力します。 図 5. アイドルタイムアウトの設定 監視 Network Load Balancer の TCP アイドルタイムアウトの導入により、2 つの新しいメトリクス RejectedFlowCount (フローテーブルがいっぱいで拒否されたフロー数の合計) と RejectedFlowCount_TCP (同じ理由で拒否された TCP フロー数) が追加されました。 これらのメトリクスを使って、アイドルタイムアウト設定の影響を監視できます。 NLB がフローの受け入れを拒否し始めたときにあなたに通知を受け取れるように、 CloudWatch アラーム をセットアップすることをお勧めします。 RejectedFlowCount の増加は、タイムアウトを短縮する必要があることを示していて、より早くフローを削除し、フローテーブルが一杯になるのを防ぐことができます。 既存の NLB メトリクス (NewFlowCount、NewFlowCount_TCP、ActiveFlowCount、ActiveFlowCount_TCP など) は変更されません。 結論 NLB での TCP アイドルタイムアウトを設定すると、長時間接続するアプリケーションなどで特に接続管理をより詳細に制御できます。アイドルタイムアウトを調整し関連するメトリクスを監視することで、NLB のパフォーマンスを最適化し接続の問題を防ぐことができます。 本稿は、2024年9月3日に Networking & Content Delivery で公開された “ Introducing NLB TCP configurable idle timeout ” を翻訳したものです。翻訳は Solutions Architect の長屋が担当しました。

こんにちは。AWS ソリューションアーキテクトの木村です。 みなさん、Rufus（ルーファス）という単語を聞いたことがありますでしょうか？ Rufus（ルーファス）とは、生成 AI を搭載した Amazon の新たな対話型ショッピングアシスタントの名前です。Amazon.co.jp で「登山に必要なものは？」「5歳児と雨の日に遊べるゲーム」「この商品の耐久性はどう？」「電気カミソリの種類を比較して」などの質問に対応することができ、商品を見つけやすくなるようお客様をサポートします。 先日、ベータ版の日本への導入を発表 し、一部のお客様向けにリリースされています。買い物体験が変わると思うとワクワクしますね。ぜひアプリやサイトをチェックしてみてください！ 11 月に入り AWS 公式ウェブマガジン、builders.flash の記事が公開されていますので生成 AI に関係するものをピックアップしてみます。承認・検索・エージェントなど色々なシーンで生成 AI が活用されておりユースケースの参考になりますね。 生成AI(Claude3.5 Sonnet)による次世代型レビュー承認システムの実現 (DMM.com合同会社様) 日本一のポイントモールへとグロースさせるための「生成AIを用いた検索体験向上」チャレンジ (株式会社オズビジョン様) AWS IoTと生成AIを使って自宅の消費電力を測定・予測してみよう AWS Summit Japan 2024 Game Industry Booth の舞台裏 また最近、SNS 等で AWS re:Invent 2024 に関する投稿が増えてきているように感じます。今年も楽しみですね。12 月 6 日(金) の 12:00-13:00 に毎年恒例の「 新サービス・新機能の全てを1時間でサクッとお伝えするWebinar 」を開催しますので、ぜひご参加ください。 「 AWSジャパン生成AI実用化推進プログラム 」のお申し込みも募集しています。11 月 22 日が締め切りになりますので、検討されている方はお早めに意思表明をお願いします。 それでは、11 月 11 日週の生成AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社ペライチ様、Amazon Bedrock を使用したホームページ自動生成サービスを開発 株式会社ペライチ様は、ホームページ作成サービス「ペライチ」を運営しています。ペライチは、誰でも簡単にホームページを作って運用できるように豊富なテンプレートが用意されていますが、イメージをホームページの形に落とし込むのが難しく公開まで至らないユーザーが存在するといった課題がありました。そこで、ユーザーが任意のサイトのURLを入力すると、そのサイトの特徴や用途に応じた情報を生成 AI が抽出し、それに基づいた最適なテンプレートを選択しサンプルのホームページを生成して提案する「ペライチクリエイトアシスタント」を開発しました。入力された URL 情報から WEB ページの情報抽出・説明・要約する処理は、AWS Step Functions と AWS Lambda そしてAmazon Bedrock を活用しています。現在、 無料モニターを受け付けています 。この取り組みは、ペライチ様に AWS ジャパン生成 AI 実用化推進プログラム に参加いただき、企画ワークショップ、 プロトタイピングプログラム による実装支援を AWS から提供しています。 AWS生成AI国内事例ブログ: 株式会社 JPX 総研様、生成 AI を活用したタグ付により適時開示資料・銘柄検索における検索性の向上を実現 JPX 総研様は、JPX グループ等が保有するデータを網羅的にカタログ化するポータルサイト「 JPxData Portal 」の提供を行っています。200 種類を超える幅広いデータを提供する一方で、データの種類が多すぎて探しにくいといった課題を抱えていました。そこで、全ての適時開⽰資料の PDF をAmazon Bedrock に連携し、⽣成 AI ( Claude ) を活⽤してファイル内の文章からタグを生成して、キーワードを付与する取り組みを行いました。その結果、ユーザーは「持続可能性」や「グッドデザイン」といったタグ情報を利用して検索することができるようになり、目的の開示情報を容易に探せるようになりました。また AWS Lake Formation によるアクセス管理を導入したことで、生成されたタグ情報の他システムへの容易な連携や、運用の効率化といったメリットも享受されています。 AWS生成AI国内事例ブログ: IQVIAサービシーズ ジャパン合同会社様、社内 RAG チャットシステムの構築により検索・調査に費やしていた時間を 93 % 削減 IQVIA 様は、ヘルスケアや人々の健康の進展に取り組むお客様を支援するグローバルリーディングカンパニーです。臨床試験などの業務においては、規制等が書かれているドキュメントを都度確認する必要があり、この検索・調査に費やす時間が多大にかかっているという課題がありました。そこで Amazon Bedrock のナレッジベースを用いた RAG ベースの AI チャット問い合わせ対応ソリューションを構築しました。この RAG チャットソリューションを IQVIA 様 全体に導入し、約 2 ヶ月で社内ユーザー 321 人の利用を達成。月あたりの検索・調査に費やしていた時間を 93 % 削減することができたそうです。また、RAG ソリューションの検証と構築は、担当者 １ 名のみで実施し、約 2 ヶ月という短期間で実現されました。フルサーバレスな構成を採用することで、開発・運用コストの最適化も実現されています。 AWS生成AI国内事例ブログ: 株式会社アーベルソフト様、 災害監視用の自社開発モデルの代わりとして Amazon Bedrock を活用することで、 約45 %の精度向上・年間コスト約 260 時間削減を達成 アーベルソフト様は、災害写真情報サービス「 ビューちゃんねる（防災 DX） 」を開発しており、複数の自治体に向けてサービスを提供しています。その中で自社で開発した画像認識モデルを用いて、冠水を自動判定する Web サービスを提供しているのですが、機械学習モデルの作成や精度改善にかかるコストに課題を抱えていました。そこで、Amazon Bedrock 上で利用可能なマルチモーダルモデルである Claude 3.5 Sonnet の導入を行いました。その結果、精度が従来から約 45 %向上、開発・運用コストが年間約 260 時間削減、さらに交通事故や火災などのこれまで行なっていないユースケースに対応することが可能になった、といった効果を得ることができました。削減できたコストはお客様に還元することを検討しており、最終的には約 40 %低減させた価格で提供できる見込みとなっているようです。 ブログ記事「製造業における技能継承への生成 AI・音声・映像の活用とサンプルソースのご紹介」を公開 製造業における技能継承は、日本のモノづくりの競争力を維持する上で非常に重要な課題となっています。本ブログでは、生成 AI や音声・映像技術を活用した技能伝承支援ソリューションを紹介しています。Amazon Bedrock が過去のデータや膨大な資料から効率的に解決策を推測し、Amazon Chime の Chime SDK を利用してベテランエンジニアがリモートから映像や音声を通じて若手を支援するソリューションとなっています。こちらは GitHub にて公開しています。 ブログ記事「Amazon Bedrock 上で基盤モデルのコストと利用状況を追跡できる社内 SaaS サービスを構築する」を公開 この記事では、マルチテナント環境で Amazon Bedrock を使用して基盤モデルにアクセスする社内 SaaS プラットフォームの構築方法について紹介しています。特に、テナントごとの使用量とコストの追跡、およびテナントごとの使用量制限などのコントロールに焦点を当てています。ソリューションは GitHub にて公開しています。社内で生成 AI の管理をされている方は是非ご覧ください。 ブログ記事「AWS Supply Chain と Amazon Q を活用して製造業における運用の優秀性（オペレーショナルエクセレンス）を推進」を公開 製造業の企業は、生産計画や材料管理から可視性やデータ統合に至るまで、サプライチェーン業務全体でさまざまな課題に直面しています。このブログでは、 AWS Supply Chain と Amazon Q を連携させ、サプライチェーンの課題に対する解決策をどのように提供するのかを紹介しています。 ブログ記事「【開催報告 & 資料公開】今から始める！Publisher 向け生成 AI」を公開 2024 年 10 月 10 日に、新聞・出版・メディア業界のお客様向けに、「AWS Media Seminar 2024 – 今から始める！Publisher 向け生成 AI」というテーマでセミナーを開催しました。このブログは、セミナーの開催報告記事です。コネヒト株式会社様からは mamari での生成 AI 活用による検索機能向上、株式会社朝日新聞社様からはコンテンツ制作支援サービス ALOFA における生成 AI 活用について登壇いただいています。資料と動画を公開していますのでぜひご覧ください。 ブログ記事「Amazon Bedrock Guardrails を使用したモデルに依存しない安全対策を実装する」を公開 Amazon Bedrock Guardrails は現在、Amazon Bedrock 外で利用可能な LLM のユーザー入力とモデル応答を評価するための ApplyGuardrail API をサポートしています。この記事では、一般的な生成 AI アーキテクチャで ApplyGuardrail API を使用する方法について紹介しています。 ブログ記事「IoT@Loft #25 進化するIoTカメラソリューション – 生成AIで拓く新時代」を公開 こちらは、2024 年 10 月 30 日に開催された 「IoT@Loft #25 進化する IoT カメラソリューション – 生成 AI で拓く新時代」の開催報告記事です。 AI/IoT ネイティブカメラを扱っているi-PRO 株式会社様の生成AI活用の取り組み、株式会社 USEN 様による店舗 DX をテーマにした IoT×AI カメラソリューションなどが紹介されています。また当日のデモ展示の様子も書かれています。 サービスアップデート Amazon Q Developer で、Datadog および Wiz 向けプラグインが一般提供開始 AWS マネジメントコンソールで Amazon Q とチャットする際、お客様は自然言語を使用して Datadog と Wiz サービスの情報にアクセスできるようになりました。例えば、「@datadog アクティブなアラートはありますか？」や「@wiz 今日のトップ3のセキュリティ問題は何ですか？」といった質問を投げかけることで情報をより速く見つけ、作業の高速化を図ることが可能です。詳細は ブログ を参照ください。 Amazon Q Developer Pro にて、ユーザーアクティビティの閲覧が可能に Amazon Q Developer Pro ティアで、管理者がサブスクリプションユーザーのアクティビティをより詳細に把握できるようになりました。管理者はユーザーの最終アクティビティ情報を閲覧することが可能です。これにより非アクティブなサブスクリプションを簡単に特定できるようになります。また送信メッセージ数や AI が生成したコード行数などが記載されたユーザー別アクティビティレポートも作成できるようになりました。 Amazon Q Developerにて以下の新機能が追加されました ・Java 8/11 から 17 へのコード変換機能がエージェンティックワークフローにより強化されました ・Q Developer が全ての YAML ファイルと JSON ファイルに対してのコード提案をサポートするようになりました ・Ruby、Scala、SQL に対してより長い複数行のインラインコード提案をサポートするようになりました ・Dart、Lua、R、Swift、SystemVerilog、PowerShell、Vue に対してのインラインコード提案をサポートするようになりました AWS B2B Data Interchangeにて生成AIベースのEDIマッピング機能を提供 AWS B2B Data Interchange は、EDI 規格のデータの変換をフルマネージドで行うサービスです。今回、AWS B2B Data Interchange にて生成 AI を使用した EDI マッピングコードを生成する機能が提供されました。この新機能により、双方向の EDI マッピングの作成とテストのプロセスが迅速化され、EDI ワークロードを AWS に移行する際の時間、労力、コストが削減されます。 AWS CloudTrail Lake にて AI 機能で強化されたログ分析が可能に AWS CloudTrail Lake は、アクティビティログや AWS Config の設定項目を保存し分析するためのデータレイクサービスです。今回、AWS CloudTrail Lakeに 2 つの AI 機能が追加されました。1 つは、自然言語によるクエリ生成機能です。この機能により「先週、権限不足で失敗したAPIイベントは何？」といったような質問で AWS アクティビティに関する情報が得られるようになりました。2 つ目は、クエリ結果要約機能です。この機能により、AWSアクティビティログから意味のあるインサイトを得るために必要な時間と労力が大幅に削減できるようになりました。現時点では英語のみのサポートとなっています。 SageMaker Model Registry がモデルのリネージをサポートし、モデルガバナンスを向上 Amazon SageMaker Model Registry が機械学習モデルのリネージ追跡をサポートするようになりました。これにより、データ準備やトレーニングからモデル登録、デプロイメントまで、ML ワークフローの各ステップに関する情報を自動的に取得し保持することが可能になります。これによりモデルライフサイクル全体の可視性が向上し、モデルガバナンスが改善されます。 Amazon SageMaker Model Registryが機械学習モデルのライフサイクルステージをサポート Amazon SageMaker Model Registry が ML モデルのライフサイクルステージをサポートするようになりました。今回のリリースにより、モデルレジストリ内の ML モデルに対して、開発、テスト、本番環境などのカスタムステージを定義できるようになりました。これにより、トレーニングから推論まで、ライフサイクルの異なるステージ間でのモデルの遷移を簡単に追跡および管理できます。 Amazon SageMaker ノートブックインスタンスが Trainium1 および Inferentia 2 ベースのインスタンスをサポート Amazon SageMaker ノートブックインスタンスで、Trainium1 (Trn1) および Inferentia2 (Inf2) ベースの EC2 インスタンスの一般提供を開始しました。Trn1 は生成 AI モデルのトレーニング、Inf2 は 推論において低いコストで高いパフォーマンスを実現します。Amazon SageMaker 上で、コスト効率良く LLM などを扱うことができるようになりました。 Amazon EC2 キャパシティブロックが新しいリージョンに拡大 EC2 キャパシティブロックとは、需要の高い GPU インスタンスを、必要な時間分予約することができる機能です。今回、P5 インスタンスの EC2 キャパシティブロックが 2 つの新しいリージョン（オレゴンおよび東京）で利用可能になりました。EC2 キャパシティブロックを使用すると、1〜64 インスタンス（512 GPU）のサイズで、最大 8 週間前から最大 28 日間の GPU キャパシティを予約することができます。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

生成 AI は企業の業務効率化やイノベーション創出の鍵として注目を集めています。生成 AI は単体で利用することも可能ですが、企業が保有する多様なデータと組み合わせることで生成 AI の真価が発揮されます。このため、企業内の重要文書やデータを適切に管理し、AI 環境と連携させることが重要となっています。 日本において、クラウドストレージサービスとして Box が広く利用されています。 株式会社アイ・ティ・アール の調査によると、Box は国内コンテンツ・コラボレーション市場のベンダー別売上金額シェアで2年連続1位を獲得しています。さらに2023年度の業種別市場シェア予測では、製造、金融、通信、サービス、建設、公共・公益という主要6業種でシェア1位を達成しています。 企業データと生成 AI を組み合わせるにはいくつかアプローチがありますが、代表的な手法として RAG (Retrieval Augmented Generation; 検索拡張生成) があります。実際、筆者がお客様とお話しする中でも、Box 内のドキュメントを RAG で活用したいという相談をいただくことがあります。 AWS のインテリジェントエンタープライズサーチサービスの Amazon Kendra や、生成 AI アシスタントアプリケーションの Amazon Q Business はさまざまなデータソースに接続できるコネクターを用意しており、それぞれ Box コネクターを準備しています。一方、Box 内のドキュメントを RAG のために利用可能な形で AWS に取り込むことに特化したソリューションとして、 アクロクエストテクノロジー株式会社 が開発した DocCollector が注目されています。DocCollector は、Box に保存されているドキュメントを、そのアクセス権限を保持したまま AWS 環境に同期することができます。 本記事では、Box 内のデータを DocCollector を利用して AWS に取り込み、生成 AI アプリケーション開発のためのサービスである Amazon Bedrock を活用した RAG システムを構築する具体的な方法について解説します。なお、本記事の執筆に当たってアクロクエストテクノロジーの鈴木貴典様と古賀匠様のご協力もいただいています。 DocCollector とは 「DocCollector」とは、外部クラウドストレージのドキュメントを AWS に連携させ、生成 AI と組み合わせた RAG 構成をすばやく構築させるためのドキュメント同期ソリューションです。 Amazon Kendra と同期させた場合の構成 Amazon Bedrock Knowledge Basesと同期させた場合の構成 現在 Box に対応しており、RAG の検索エンジンとしての Amazon Kendra や、RAG システム構築のマネージドサービスである Amazon Bedrock Knowledge Bases との連携が可能です。Box とのドキュメント同期を、効率よく実施できるようにするため、以下のような機能を備えています。 同期対象のファイル一覧出力 ファイル全体同期 ファイル差分同期 ユーザー指定での同期 同期対象のフィルタリング 外部共有ファイルの同期有無の指定 ユーザー権限同期 グループ権限同期 これらの機能により、Box に大量のドキュメントが登録されている場合でも、必要なファイルのみに絞って効率的に同期することが可能です。また、アクセス権限を同期させることも可能なため、RAG で検索処理が行われた際に、Box 上のアクセス権限を元に、表示させるドキュメントを制限することも可能です。 加えて、お客様の AWS アカウント内に本ソリューションを構築して動作するため、ドキュメントが外部の環境を経由したり、保持されたりすることがないため、セキュアに運用することができます。 DocCollector はアクロクエストテクノロジーが支援した 大阪市高速電気軌道株式会社 (Osaka Metro) 様の事例 でも活用されています。 DocCollector と Amazon Bedrock を利用した RAG システムの構築 DocCollector を利用して Box のドキュメントを Amazon Kendra に同期させ、さらに、Amazon Bedrock を利用した RAG システムの構築例を説明します。 今回は、単にドキュメントを同期するだけではなく、Box のアクセス権限 (Access Control List; ACL) も同期し、RAG で利用されるドキュメントを、ユーザー毎にアクセス制御できるようにします。RAG でのドキュメントのアクセス制御は、企業内ではニーズが多い内容であり、DocCollector を利用することで、そのようなことも実現可能となります。 前提条件 Boxからドキュメント同期を行うには、以下の内容が必要となります。 Box Enterprise 以上のプラン Box の開発者コンソールにおける Box アプリの作成、および、その JWT 認証ファイル RAG システム構築の流れ 以下のような流れで、DocCollector でドキュメントを同期し、Amazon Kendra と Amazon Bedrock を組み合わせた RAG システムの構築を行います。 Box のファイル準備 Amazon Kendra のインデックス作成／カスタムデータソースの登録 DocCollector の構築 DocCollector での Box ドキュメント同期 Amazon Kendra でのドキュメント同期結果の確認 Amazon Bedrock を利用した RAG 処理の実現 1. Box のファイル準備 最初に、サンプルとして、以下のような構成で Box にドキュメントが登録されているとします。アクセス権限の確認をするために、フォルダによってアクセスできるユーザーを設定しています。 Box 内のファイル構成 Box 内のファイル構成 (DX 推進部門) Box 内のファイル構成 (開発部門) 2. Amazon Kendra のインデックス作成／カスタムデータソースの登録 Amazon Kendra のインデックスを作成し、それに対して、カスタムデータソースを登録します。DocCollector の構築の際に、このカスタムデータソースに DocCollector を紐づけることで、Box 内のドキュメントを Amazon Kendra に同期できるようになります。 Amazon Kendra インデックス作成 Amazon Kendra カスタムデータソース登録 3. DocCollector の構築 まず、DocCollector を自社の AWS アカウントにセットアップします。DocCollector は、アクロクエストテクノロジーから提供されます。DocCollector の AWS Batch の構成は、 AWS Cloud Development Kit (CDK) で自動構築されます。 DocCollector の構築 AWS Batch のジョブとして DocCollector を登録した様子は以下の通りです。 DocCollector の AWS Batch ジョブ登録 ※ Box への接続情報は、AWS Batch のパラメータとして指定します。 4. DocCollector での Box ドキュメント同期 DocCollector を用いて Box 上のドキュメントを AWS に同期させます。 同期処理は、先ほど構築した AWS Batch のジョブを実行するだけです。ジョブが正常に終了したら、ドキュメントの同期が完了しています。同期処理の詳細については、 Amazon CloudWatch Logs から確認できます。 DocCollector の AWS Batch ジョブ実行の結果 5. Amazon Kendraでのドキュメント同期結果の確認 Amazon Kendra のインデックスやデータソースの詳細を見ると、正常に同期が完了し、9個のファイルがすべて同期できたことが確認できます。 Amazon Kendra インデックス (同期後) Amazon Kendra データソース (同期後) また、Amazon Kendra の検索コンソールから、検索を行ってみます。ここでは、それぞれのドキュメントが適切に同期されているかを確認するため、管理者権限のもとで検索します。ユーザーのアクセス権限による影響の差分は次のセクションで確認します。 Amazon Kendra 検索コンソール (開発部門のドキュメント) Amazon Kendra 検索コンソール (DX 推進部門のドキュメント) アクセス権限が指定されている、「開発部門」フォルダ内のドキュメントも、「DX推進部門」フォルダ内のドキュメントも、どちらの内容も検索できていることが確認できました。 定期的に、DocCollector のバッチジョブを実行することで、ドキュメントの内容は最新化されます。 Amazon EventBridge Scheduler などを利用して、定期実行されるようにしておくと良いでしょう。 6. Amazon Bedrock を利用した RAG 処理の実現 Amazon Bedrock と Amazon Kendra を組み合わせた RAG システムの場合、以下のような処理の流れになります。 RAG の処理の流れ AWS が OSS として公開している「 Generative AI Use Cases JP (GenU) 」でも、上記の構成で RAG システムを構築できますが、今回、Box のアクセス権限に基づいたドキュメント検索を確認するため、アクロクエストテクノロジー社が提供している、エンタープライズ向け生成 AI アシスタントである「 AcroChatAI 」を利用して、動作確認を行います。ここでは、以下のような制御が正常に行われているかを確認します。 userA に対しては、「DX 推進部門」のドキュメントだけが検索に利用され、「開発部門」のドキュメントは検索に利用されない。 userB に対しては、「開発部門」のドキュメントだけが検索に利用され、「DX 推進部門」のドキュメントは検索に利用されない。 userC に対しては、「DX 推進部門」のドキュメントも「開発部門」のドキュメントも検索に利用される。 まずは (1) の「userA」での操作を確認します。「DX 推進部門」のドキュメントを元にした情報は問合せできていますが、「開発部門」のドキュメントを元にした情報は問合せ結果が出力されません。 DX 推進部門所属の userA の検索結果 (1) DX 推進部門所属の userA の検索結果 (2) 次に (2) の「userB」での操作を確認します。「開発部門」のドキュメントを元にした情報は問合せできていますが、「DX 推進部門」のドキュメントを元にした情報は問合せ結果が出力されません。 開発部門所属の userB の検索結果 (1) 開発部門所属の userB の検索結果 (2) 最後に (3) の「userC」での操作を確認します。今度は、どちらのドキュメントの内容も問合せできています。 両方のフォルダにアクセスできる userC の検索結果 (1) 両方のフォルダにアクセスできる userC の検索結果 (2) このように、DocCollector を利用すると、Boxのドキュメントを同期させるだけではなく、Amazon Kendra のアクセス制御機能とも連携し、RAG で利用されるドキュメントを、ユーザー毎に制御することが可能になることが確認できました。 今回は、シンプルな Box の構成でしたが、一部のドキュメントに限定して同期したり、ファイル差分で同期したりと、DocCollector には、効率よく Box のドキュメントを同期できる機能が備わっています。 まとめ 本記事では、アクロクエストテクノロジーが提供する DocCollector を利用して、Box のドキュメントとアクセス権限を Amazon Kendra に同期させ、そこから Amazon Bedrock を利用した RAG システムを実現しました。 これにより、企業は、クラウドストレージサービスとして Box を利用しつつ、その内容を、AWS 上で RAG システムとして活用することができるようになります。 また、今回は Amazon Kendra との連携でしたが、DocCollector は、Amazon Bedrock Knowledge Bases との連携にも対応しています。また、生成 AI アシスタントの Amazon Q Business にも今後対応する予定です。DocCollector を活用することで、Box と連携可能な RAG システムを簡単に構築できるようになります。 参考情報 RAG 向けドキュメント同期ソリューション 「DocCollector」 エンタープライズ向け生成 AI アシスタント「AcroChatAI」   著者について 本橋 和貴 (Kazuki Motohashi / @kmotohas ) は、AWS Japan の機械学習スペシャリストソリューションアーキテクトです。AWS の AI/ML サービスのお客様に対する技術的な支援を行いながら市場開拓を推進しています。好きなサービスは Amazon Bedrock と Amazon SageMaker です。週末は子供と屋内遊園地で遊ぶのが習慣になっています。博士 (理学)。 鈴木貴典 (Takanori Suzuki / @takanorig ) は、アクロクエストテクノロジー株式会社のシニアテクニカルアーキテクトです。お客様へのクラウドを活用したシステムのご提案や、開発・構築などのコンサルティングを実施しています。サーバーレス・アーキテクチャ推しなので、Amazon Bedrock はもちろん、AWS Lambda 他、サーバーレス系サービスを多用しています。こう見えて (?)、甘党なんですが、最近は健康を意識して控えめにしています。 古賀匠 (Takumi Koga) は、アクロクエストテクノロジー株式会社のクラウド開発エンジニアです。主に、AI/ML サービスを活用したクラウドシステムの開発・構築を得意としています。特に最近は LLMOps に興味があり、生成 AI をどう活用／運用するかを考えています。趣味はサッカープレミアリーグ観戦で、応援しているチームが勝つと、週明けはテンションが高くなります。

2023 年 12 月 22 日、Amazon CloudWatch Network Monitor の提供を発表しました。これは AWS 上のハイブリッドネットワーク接続の可視化を容易にする CloudWatch の機能です。CloudWatch Network Monitor は現在、AWS Direct Connect と AWS Site-to-Site VPN で構築されたネットワーク用のハイブリッドモニターをサポートしています。Amazon CloudWatch Network Monitor は Amazon CloudWatch のコンソール上で利用することが可能です。 この記事では、CloudWatch Network Monitor (CWNM) を使用してハイブリッドネットワークのパフォーマンスを測定し、MTTR ( 平均復旧時間 ) を短縮する方法について説明します。 ハイブリッド接続とグレー障害 Advanced Multi-AZ Resilience Patterns Whitepaper では、グレー障害を異なるエンティティが異なる視点で障害を検知することと定義しております。グレー障害は、原因特定と解決が難しい場合があります。ネットワークドメインでのグレー障害の例としては、特定のネットワークリンクでの断続的なパケットロスやレイテンシーの変動などがあります。 このような状況が発生すると、あるエンティティ ( ルーティングコントロールプレーン ) では低下による影響は見られないのに対して、別のエンティティ ( お客様 ) ではスループットの低下やレイテンシーの増加のような形で影響が見られます。 Border Gateway Protocol (BGP) は、AWS Direct Connect と AWS Site-to-Site VPN で使用されるダイナミックルーティングプロトコルで、TCP のトランスポートプロトコルで動作しています。TCP は、再送信やスライディングウィンドウなどのメカニズムによって、ある程度のネットワーク低下を許容することができます。さらに、TCP セッションは、お客様のルーターと AWS Direct Connect ルーターとの間で確立されます。そのため、VPC とオンプレミスネットワーク間のどこかでネットワーク障害が発生しても、BGP では必ずしも低下の兆候に気づけないかもしれません。 Direct Connect (DX) または Site-to-Site VPN によるハイブリッド接続を必要とする AWS のお客様は、グレー障害が発生したら直ちに検知し、問題が起きている経路からトラフィックを回避するオプションを用意する必要があります。これまでの経験から、ネットワークに問題が発生すると、ネットワークエンジニアは問題の特定に相当な時間を費やすことがわかっています。パフォーマンス低下がお客様管理のネットワーク部分で発生したのか、それとも AWS 責任範囲内のネットワーク部分で発生したのかを迅速に把握することは、MTTR の短縮に役立ちます。 野村総合研究所は Direct Connect のパートナーです。当社にとって、ネットワークのグレー障害を検出・特定し、その影響を軽減するまでの時間を短縮することは長年の課題でした。 CloudWatch Network Monitor のおかげで、エンドツーエンドのパフォーマンスの低下や停止が発生と同時に検知できるようになりました。CloudWatch アラームでしきい値を設定し、CloudWatch Network Monitor を Lambda や SNS などの他の AWS サービスと統合するのは簡単でした。 上記により、ネットワークイベントが検出された際に事前に定義したアクションを実行することで、これまで以上に多くのネットワーク障害の影響を自動的に軽減できると期待しています。 株式会社野村総合研究所 シニア・アソシエイト 藤原 和樹 氏 Amazon CloudWatch Network Monitor の紹介 Network Monitor を使用する以前は、ハイブリッドアーキテクチャを採用しているお客様は、既製のソリューションを使用するか、独自のツールを開発したアクティブ監視手法を実装することで、ネットワークのグレー障害の問題に対処してきました。 CloudWatch Network Monitor は、フルマネージド型のエージェントレスソリューションで簡単に実現します。 モニター は、Direct Connect または Site-to-Site VPN 経由で到達可能な IPv4 または IPv6 宛先への ICMP または TCP トラフィックをテストするために使用できます。送信元サブネット、宛先 IP、 パケットサイズ、およびプロトコル/ポートの各組み合わせは、 プローブ と呼ばれます。 Amazon VPC で モニター を作成すると、AWS はバックグラウンドで RTT (Round-Trip Time) とパケットロスの測定を実行するために必要なすべてのインフラストラクチャを作成します。 プローブ で設定されたポートとプロトコルでモニタリングトラフィックに応答するように監視ターゲット （プローブの宛先） を設定するだけで済みます。 Direct Connect と併用する場合、 モニター はモニターがデプロイされた VPC から DX 接続を終端する Direct Connect ロケーションまでの、AWS が管理するネットワーク経路の状態を可視化します。これは Network Health Indicator (NHI) と呼ばれ、問題が AWS のネットワークにあるのか、お客様が管理するネットワークにあるのか原因特定のスピードアップに役立ちます。 モニター によって生成されたメトリクスは Amazon CloudWatch に公開され、ダッシュボードとアラームを設定して、通知や軽減アクションを実施することができます。 シナリオ Direct Connect High Resiliency モデルを実装する一般的なお客様のシナリオを以下に説明します。この設計に焦点を当てて、Network Monitor の設定と使用方法を示します。Network Monitor は他のシナリオでも使用することができます。 図 1. Direct Connect High Resiliency 構成を利用のお客様 こちらのお客様では各 Direct Connect ロケーションにルーターを設置しています。各ルーターは、DX 専用接続を介して AWS ルーターに接続されます。 2 つの Transit VIF (T-VIF) が、Direct Connect Gateway (DXGW) に関連付けられた AWS Transit Gateway との間でトラフィックを転送するように設定されています。お客様のルーターは、両方の T-VIF 上で eBGP を介して DXGW とルーティング情報を交換します。これは、AWS の ドキュメント 、ブログ記事、および ハイブリッド接続ホワイトペーパー などのリソースで扱われている一般的なアーキテクチャです。 お客様は、複数のプライベートサブネットにワークロードを所持しており、アプリケーションの可用性を最大化するために、異なるアベイラビリティゾーン (AZ) に分散しています。図を見やすくするために、ここでは 2 つだけ表示することにします。これらのワークロードには、オンプレミス LAN 上のクライアントがアクセスします。 お客様は、等コストマルチパス (ECMP) を使用して、両方の DX 接続間でネットワークフローの負荷分散を行っています。LAN（ 172.16.0.0/24 - 2001:DB8::/48 ） には、AWS から両方の T-VIF 経由で到達が可能です。同様に下の図が示すように VPC にも、LAN から両方の T-VIF を経由して到達可能です。 図 2. 両方のトランジット VIF から LAN に到達可能 プライベートサブネット内のワークロードはレイテンシーにセンシティブです。お客様は、どちらかの経路に障害が発生した場合にも対処できるように、両方の経路のネットワークパフォーマンスを可視化したいと考えています。 AWS リージョン内のアベイラビリティーゾーンは独立した障害ドメインとして設計されている ため、異なる AZ の異なるサブネットからの可視性を提供する必要があります。 モニタリング アーキテクチャ ユーザーのペルソナによって、モニタリングの目的は異なる可能性があります。例えば、アプリケーションオーナーは、ネットワークがアプリケーショントラフィックをどのようにルーティングするかに関係なく、エンドツーエンドのレイテンシーとパケットロスがエンドユーザーのエクスペリエンスに影響を与えないことを確認したいと考えるかもしれません。 アプリケーション開発者は、ワークロードと同じサブネットに モニター を設定し、オンプレミスの LAN に対してプローブを送信します。いずれかのワークロードのサブネットからのモニタリングトラフィックは、オンプレミスのモニタリング宛先に到達するために、利用可能なすべての経路を使用します。 図 3. モニタリングアーキテクチャ (アプリケーションオーナー) 一方、ネットワーク・エンジニアは各ネットワーク経路を重視するため、各 プローブ のトラフィックが特定の経路をたどって宛先に到達するようにモニターを構成します。 図 4 に示す 2 つ目のアーキテクチャでは、ネットワークエンジニアが各モニタリングサブネットにプローブを作成しました。各プローブは、緑色または赤色の DX 接続を経由してのみ到達可能な宛先に設定されています。同様に、モニターの宛先は、緑色または赤色の DX 接続を経由してのみ、図の左側にある対応するプローブに到達できます。例としては VRF-Lite をお客様のルーター上で構成することで実現できます。 図 4. モニタリングアーキテクチャ (ネットワークエンジニア) 執筆時点では、同一 モニター 内に IPv4 と IPv6 の両方の宛先に対する プローブ を作成することはできません。IPv6 宛先への プローブ を設定したい場合は、別の IPv6 モニター を作成してください。 次に、2 つ目のアーキテクチャについて説明し、AWS コンソール内での設定方法を示します。CloudWatch Network Monitor は、サービス API、AWS SDK、AWS CloudFormation、CDK を使用して設定することもできます。ここでは IPv4 のみのモニターを作成する方法を示しております。IPv6 のみのモニターを作成したい場合も同じ手順に従ってください。 Amazon CloudWatch Network Monitor のセットアップ 2 つ目のリファレンスアーキテクチャを実装するために、 monitor-us-east-1-ipv4 という名前の モニター を作成します。これを行うには、Network Monitor コンソールを開き、 モニターを作成 を選択します。 図 5. Network Monitor コンソールでのモニター作成 集計期間 は、 Network Monitor のプローブが生成したメトリクスを CloudWatch に送信する間隔を表します。 この値は 30 秒（デフォルト）のままにします。これは Network Monitor によって生成されるメトリクスに依存しており、自動化されたアクションを使用して障害のあるネットワークパスを迅速に回避するためです。 図 6. 新しいモニターの作成 次に、 プローブ をデプロイするソースとして、 monitor-subnet-us-east-1a と monitor-subnet-us-east-1b のサブネットを選択します。最後に、 172.16.100.1 と 172.16.200.1 を宛先として設定します。コンソールを使用して作成された プローブ は、デフォルトで 56 バイトサイズの ICMP エコーパケットを送信します。これを図 7 に示します。 図 7. モニターの送信元サブネットと宛先IPを指定 ステップ順に従うと、すべてのリソースがデプロイされ、 プローブ が先ほど設定した集計間隔ごとに CloudWatch にメトリクスを送信開始するまで、 モニター と プローブ は Pending 状態になります。 Network Monitor ダッシュボード CloudWatch Network Monitor は モニター 毎にダッシュボードを作成します。これは、Network Monitor ダッシュボードで モニター 名をクリックすることでアクセスできます。 左上には、 モニター がデプロイされているリージョンの AWS ネットワークのステータスが表示されます。 この情報は接続が複数のネットワーク ( 例：AWS ネットワーク、Direct Connect Partner バックボーン、オンプレミスデータセンターネットワークなど ) を経由する場合に、モニターされたパケットロスや増加したレイテンシーの原因を調査するのに役立ちます。 右上には、アラーム状態の プローブ 数、平均パケットロス、選択した時間範囲の RTT など プローブ のステータスの概要が表示されます。 図 8 では、AWS Network Health Indicator メトリクスの履歴と、各 プローブ のパケットロスと RTT を示す折れ線グラフが表示されます ( 図 9)。この情報を使用して、AWS Network Health Indicator とモニターされたパケットロス/レイテンシーを相関することで、ネットワークの問題をさらにトラブルシューティングできます。 図 8. モニターのサマリー表示 図 9. Network Monitor メトリクスのサマリー表示 CloudWatch メトリクス AWS Network Monitor は、CloudWatch メトリクスを名前空間内に “AWS/NetworkMonitor” として公開しています。各プローブには 3 つのメトリクスがあります。 HealthIndicator: 測定時に AWS ネットワークが正常であれば 0、低下している場合は 100 です。 PacketLoss: パケットロスをパーセント値で表します。 RTT: ラウンドトリップ時間をマイクロ秒単位で表します。 図 10. NetworkMonitor CloudWatch メトリクス (RTT) Metrics math 複数のメトリクスを数式と組み合わせると便利な場合があります。 例えば、複数の プローブ が物理リンクを共有している場合、集約期間中 （ この場合は 30 秒）にすべての プローブ のパケットロスの平均を取得することができます。取得するには、関連するメトリクスを選択し、「数式を追加」オプションを使用してください。次に、図 11 と図 12 に示すように、適切な関数  ( 平均を表す “AVG” など ) を選択します。 図 11. CloudWatch メトリクスの数式追加 図 12. CloudWatch メトリクスに数式を追加した結果 (RTT) アラームの作成 シナリオに最も適したメトリクスを特定したら、アクションセクションの小さなベルのリンクアイコンをクリックして、必要なアラームと アクション を設定できます。 最もシンプルなタイプのアラームとして、静的なしきい値を使用します。例えば、パケットロスの平均値が 1% を超えた場合に通知するアラームを作成できます。ほとんどのアプリケーションでは、1% のパケットロスは許容範囲内と考えられます。 図 13. パケットロスに関する CloudWatch アラームの設定 事前に妥当なメトリクス値が分からない、または日中に何らかの変動が予想されるため ( ラウンドトリップタイムなど ) 静的なしきい値を設定したくない場合は、 CloudWatch 異常検出 を使用してアラーム設定ができます。 異常検出 は予想される帯域の値を計算し、実際の値がその帯域より大きい場合や低い場合、または帯域外である場合にアラートを発します。プローブが失敗した場合 （ パケットロス = 100%）、RTT は 0 ミリ秒と報告されるため、予想よりも低い値や高い値を検出するように異常検出を設定することは合理的です。 図 14. CloudWatch 異常検出の設定 フェイルオーバーの自動化 Amazon Simple Notification Service (SNS) を使用してアラートを送信する以外に、障害検出時の際に Direct Connect リンクのフェールオーバーを自動化することも可能です。そのためには、 Amazon EventBridge によって呼び出される Lambda 関数を使用します。サンプルの Lambda 関数は AWS Samples GitHub リポジトリ で提供されています。詳細とベストプラクティスについては、ブログ記事「 AWS Direct Connect monitoring and failover with Anomaly Detection 」 を参照してください。 また、実際の障害シナリオが発生した際に期待通りに機能することを確認するため、フェイルオーバーの自動化を定期的にテストすることもベストプラクティスです。 リソースの削除 Network Monitor をテスト後は、想定していない料金の発生を避けるため、すべてのモニターとプローブ、この機能をテストするために作成したその他のリソースを削除して、テスト環境をクリーンアップしてください。 まとめ この投稿では、ハイブリッドネットワークのモニタリングを容易にするフルマネージド型でエージェントレス機能である Amazon CloudWatch Network Monitor を紹介しました。Network Monitor を使用することで、ネットワークの問題をより迅速にトラブルシューティングと修復を行うことができるため、カスタマーエクスペリエンスへの影響を最小限に抑えることができます。 Network Monitor の料金の詳細については、 こちら の CloudWatch 料金表ページをご覧ください。この機能の設定方法と使用方法に関する技術的なガイダンスについては、 AWS Documentation をご覧ください。 本稿は、2023 年 12 月 22 日に Networking & Content Delivery で公開された “ Monitor hybrid connectivity with Amazon CloudWatch Network Monitor ” を翻訳したものです。翻訳はテクニカルアカウントマネージャーの安藤 彰が担当しました。

本記事は、2024 年 7 ⽉ 3 ⽇に公開された ” Does Your People Strategy Match Your Transformation Objectives? “を翻訳したものです。 なぜ多くの企業のイノベーションプログラムは失敗するのでしょうか。 その答えは、組織の複雑さと同じぐらい複雑です。厳格すぎるガバナンスモデル、縦割りのチーム、厳しい規制環境、官僚的な意思決定などが主な原因として指摘されることがありますが、見過ごされがちな領域が 1 つあります。それは人材戦略です。 人材プロセスは、イノベーションを支援するか、それとも阻害するかのどちらかです。中間地点はありません。 私は最近、同僚の Mark Schwartz が書いた「 Adaptive Ethics for Digital Transformation 」という本を読みました。この思考を刺激する挑戦的な本の内容を要約しようとは思いません ( 特に帽子、食べ物、神話上の怪物の例え話に惹かれる方には )。その代わりに、本の中の1つの引用について考えを述べたいと思います。これは本の主要なテーマではないので、 Mark の著作権を侵害しているわけではありません (ぜひその本を読んでみてください。素晴らしい本です)。 エンロンの崩壊の話の途中で、Mark は次のような言葉を述べています: 「文化は、従業員を成功に導くものを中心に形成される」 Mark は、エンロンの掲げた価値観が、組織内での個人の成功や昇進につながるものとは全く異なっていたことを示しています。価値観自体が問題だったのではなく、現実との乖離が問題だったのです。 私はアマゾンでの 11年間 ( AWSとAmazon.comの両方 ) において、人材と企業文化に焦点を当ててきました。私は企業文化の専門家で、常に「文化が最も重要なもの」という視点で世界を見ています。そして、地球上で最も顧客中心主義の企業になるというミッションを果たすために、意図的に企業文化を進化させてきた組織で働いています。しかし、Mark の言葉は他の組織にも当てはまるのでしょうか ? 私はそう考えており、多くの組織変革が頓挫するのは、組織が掲げる文化的価値観を従業員の育成、業績評価、そして報酬にまで反映させることに失敗した時だと強く思います。 過去 5 年間で、私はほぼすべての業界にわたる世界中の 1,000 人以上の組織リーダーたちと対話を重ねてきました。その中で、ある会話が特に印象に残っています。それは、組織変革を追求する際には 人材戦略も見直す必要性 を示すものでした。 数年前、私はある世界的な大手石油・ガス会社のイノベーション責任者 (仮にザビエルと呼びます) と時間を過ごす機会がありました。エネルギー業界の多くの既存組織と同様に、ザビエルの会社も自社を変革し、よりイノベーティブになる緊急の必要性を感じていました。その従来の持続可能で収益性の高いビジネスモデルでは、枯渇する天然資源と高まるエネルギー需要への対応ができなくなっていたのです。 会話の中で、ザビエルは会社全体で イノベーションを推進するための方法 について話してくれました。それには、経営陣からの高水準なイノベーション目標、各組織へのイノベーション予算、特定の課題に取り組む小規模チーム、ハッカソン、表彰や賞与など、あらゆる手段でした。 彼は言いました。「このプログラムを1年半実施しています。そして、社内にはうまくいっている部署もあります。しかし、私達が期待していたほどには浸透していません。私たちは実験をしているわけではありません。私たちは依然として官僚的で、意思決定が遅いのです。人々は革新的なプロジェクトに参加しようとしません。私の何が間違っているのでしょうか ? 」 ザビエルの計画は、組織のイノベーションを推進するための教科書的なアプローチとほぼ一致していました。正直なところ、彼が何を見落としているのか思い当たりませんでした。1 時間後、私たちは昼食を取りながら、 アマゾンのリーダーシップ原則 とその報酬哲学へ話題を移しました。アマゾンは長年にわたり、各従業員の全体的な報酬の重要な一部として会社の株式を含めてきました。この方法は、私たちのリーダーシップ原則のオーナーシップと一致しています。 リーダーはオーナーです。リーダーは長期的視点で考え、短期的な結果のために、長期的な価値を犠牲にしません。リーダーは自分のチームだけでなく、会社全体のために行動します。リーダーは「それは私の仕事ではありません」とは決して口にしません。 ここで言う「リーダー」とは、肩書や役職に関わらず組織内のすべての従業員を指します。誰もが周囲の人々の行動に影響を与える事ができるので、責任あるリーダーの心構えで仕事に取り組む必要があります。そしてAWSでは、「リーダーはオーナーです」というのは文字通りの意味があります。役割と結果に対する責任を持つことに加えて、各従業員がそれぞれ会社の一部を所有し、組織の長期的な成功から利益を得られます。株式を全従業員に付与することで、個人の動機づけと組織の目標を一致させているのです。 このオーナーシップの考え方は、私がザビエルと会話していたイノベーションの課題とどのように関連しているのでしょうか? 私が報酬哲学の詳細を共有すると、ザビエルは私を遮って言いました。「待ってください、全員に株が支給されているのですか ? 」 「そうです。もちろん、ジョブレベルや仕事のパフォーマンスに基づいて付与される量は異なります。パフォーマンスが良くない人は株を受け取れないこともあります。ただ、それ以外の従業員全員に、毎年の報酬の一部として株が支給されるのです」 「へぇ」と彼は言いました。「うちの経営陣は成果主義を信じています。私たちも株を与えていますが、10人いるチームのうち上位2人しか対象にしていません。それは大きな報酬で、年俸の30%にもなることがあります。」 経営陣が株式報酬を厳しく審査し、それを受け取った人々は通常、その年の完璧な結果を出していました。全ての目標と目的を達成していたのです。そのような環境で、わずかでも失敗のリスクのあるプロジェクトに手を挙げる人がいるでしょうか? 私にも共感できる部分があります。私は大学生の子供が 3 人います。アメリカでは、それは子供たちの教育に多額のお金をかけているということです。私なら、ザビエルの会社のモデルに従って 30% の昇給を得られれば、確実に達成可能な目標を設定し、それらの目標を他の何よりも綿密かつ容赦なく追及するでしょう。すべての人がお金に動機づけられるわけではありませんが、完璧な実行を報酬とする文化は、実験とイノベーションに逆行するものです。経営陣は「素早く失敗せよ！」と言うかもしれませんが、報酬と是正のシステムは逆のことを伝えています。 私がザビエルと話した1年後、彼の会社はAWSのデジタルイノベーションチームと提携し、5 つの重要な実験に取り組み、従来の 3 分の 1 の期間で実行しました。それらの実験のうち 2 つは現在も本番環境で稼働しています。私たちの会話がザビエルの会話の変化どの程度関係していたかは分かりませんが、昨年、同じ組織のリーダーシップの方々とも会話する機会がありました。彼らは会社の報酬アプローチを改訂し、すべての従業員に対して株式を提供するようになっていたのです。 ここでの変革の教訓は「ただ従業員への報酬の与え方を変えればいい」というわけではありません。どんな大規模な組織の変革にも、それによって生じる課題を解決する万能薬はありません。しかし、自分の組織のあらゆる側面、特に人材に関する実践、を見直す意思のあるリーダーは、より持続的な変革を導く可能性が高いのです。 私からいくつかのアイデアを提案しましたが、より良いアイデアがあればお聞かせください。 – Stephen 本記事は、カスタマーソリューションマネージャーの宮本雅勝が翻訳を担当しました。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 12月2日からの AWS re:Invent 関連の情報が少しづつ出てきますね。去年同様、色々なセッションがオンライン中継もされる予定ですので、視聴したい方は こちらのレジストレーション をお忘れなく。 時差の関係で、日本から視聴するのは難しいものも多いのですが、録画も公開される予定ですし、最初の キーノート である現地月曜夜のPeter DeSantisキーノートは、日本時間だと火曜のお昼12時半ごろ開始予定なので、ライブで見やすいかと思います。 それでは、先週の主なアップデートについて振り返っていきましょう。今週はいつもに増して新発表が多かったので、各項目の説明はできるだけシンプルにしています。詳細はリンク先のWhat’s new等でご確認ください。 2024年11月11日週の主要なアップデート 11/11(月) Amazon OpenSearch Ingestion adds support for ingesting data from Amazon Kinesis Data Streams – AWS Amazon OpenSearch Ingestion では、Amazon Kinesis Data Streams から直接レコードを取り込むことができるようになりました。これにより、追加の工数が不要で、KinesisからのストリーミングデータをOpenSearch Serviceでインデックスできるようになりました。 Get x-ray vision into AWS CloudFormation deployments with a timeline view – AWS AWS CloudFormation で Deploy timeline view (デプロイタイムラインビュー)が提供されるようになりました。この機能は、CloudFormationのスタックで実行する一連のアクションを視覚化してくれるため、スタックでのリソースプロビジョニングアクションの順序やかかった時間を把握しやすくなります。 11/12(火) Amazon SageMaker Model Registry now supports defining machine learning model lifecycle stages – AWS Amazon SageMaker Model Registry でカスタムの機械学習モデルのライフサイクルステージがサポートされました。この機能により、トレーニングから推論まで、モデルライフサイクルのさまざまな段階でのトラックと管理が容易になります。また、承認待ち、承認済み、却下などの段階承認ステータスをトラックして、モデルが次の段階に進む準備ができているかどうかを確認することもできます。 Amazon Managed Service for Apache Flink now supports Amazon DynamoDB Streams as a source – AWS Amazon DynamoDB 用の新しい Apache Flink コネクタが利用可能になりました。これは AWS が Apache Flink プロジェクトにコントリビューションした 新しいコネクタ であり、Apache Flink のソースとして Amazon DynamoDB ストリームを追加し、変更データを順次 Flink に流すことが容易になります。 Amazon EC2 Capacity Blocks expands to new regions – AWS アジアパシフィック (東京)、米国西部 (オレゴン) の2つのリージョンにおいて、 P5 インスタンスで Amazon EC2 の機械学習用キャパシティブロックが利用可能になりました。キャパシティブロックを使用すると、1 ～ 64 インスタンス (512 GPU) のクラスターサイズで、最大 8 週間前まで GPU 容量を最大 28 日間予約できるため、機械学習ワークロードをより確実に実行できるようインフラを準備することが可能になります。 Amazon EventBridge announces up to 94% improvement in end-to-end latency for Event Buses – AWS Amazon EventBridgeで、2023年1月以降の改善によりイベントバスのエンドツーエンドのレイテンシーが最大 94% 改善されたことを発表しました。2023年1月時点では、2235.23ms (P99)であったレイテンシが、2024年8月には129.33ms (P99)まで短縮しています。これにより、よりミッションクリティカルな領域でも利用が可能になります。 Amazon EBS now supports detailed performance statistics on EBS volume health – AWS Amazon Elastic Block Store (EBS) ボリュームで、詳細なパフォーマンス統計が利用可能になりました。この新機能により、1秒未満の精度で 11 のメトリックスにアクセスし、 EBS ボリュームの入出力 (I/O) 統計をリアルタイムにモニタリングできます。 11/13(水) Amazon OpenSearch Service now supports 4th generation Intel (C7i, M7i, R7i) instances – AWS Amazon OpenSearch Service で、第4世代インテル Xeon スケーラブルプロセッサーベースのコンピューティング最適化インスタンス (C7i)、汎用 (M7i) インスタンス、およびメモリ最適化インスタンス (R7i) を利用可能になりました。これらはC6i、M6i、R6i の各インスタンスよりもそれぞれ最大 15% 価格性能比を実現します。 Introducing resource control policies (RCPs) to centrally restrict access to AWS resources – AWS AWS Organizations で Resource Control Policy (RCP) が利用可能になりました。これは、組織内のAWSリソースへのアクセスを一元的に制御できる機能で、外部IDによる内部リソースへのアクセス防止や、通信のTLS強制といった用途に利用が可能です。現時点では、Amazon S3, AWS STS, AWS KMS, Amazon SQS, AWS Secrets Manager に適用が可能です。 Amazon DynamoDB introduces warm throughput for tables and indexes – AWS Amazon DynamoDB では、新しく warm throughput (ウォームスループット)値と、DynamoDB テーブルとインデックスを簡単にPre warming (事前ウォーミング)できる機能が追加されました。ウォームスループット値を参照すると、テーブルが処理できる読み取り/書き込みオペレーションの数が可視化されます。今後のイベントにおける性能不足に気付いた場合には、事前ウォーミングにより性能値を増やすことができます。詳細は こちらのブログ をご覧ください。 AWS Glue Data Catalog now supports scheduled generation of column level statistics – AWS AWS Glue Data Catalog で、Apache Iceberg 表と Parquet、JSON、CSV、XML、ORC、ION などのファイル形式のデータにおいて、列レベルの統計のスケジュール生成がサポートされました。これにより、統計の生成を簡略化および自動化できます。統計情報は Amazon Redshift Spectrum および Amazon Athena のコストベースオプティマイザー (CBO) と統合されているため、クエリのパフォーマンスが向上し、コスト削減が期待できます。 11/14(木) AWS Backup now supports Amazon Neptune in three new Regions – AWS AWS Backup による、 Amazon Neptuneのバックアップが利用可能なリージョンが拡張され、新たに大阪、ジャカルタ、ケープタウン)リージョンで利用可能になりました。 Amazon DynamoDB reduces prices for on-demand throughput and global tables – AWS Amazon DynamoDB の料金改定がアナウンスされました。オンデマンドスループットの価格は最大50%、グローバルテーブルの価格は最大67%引き下げます。この料金は11月1日からの利用分に適用されます。詳細は こちらのブログをご覧ください 。 Amazon Keyspaces (for Apache Cassandra) reduces prices by up to 75% – AWS Amazon Keyspaces for Apache Cassandra は、スケーラブルでサーバーレスの Apache Cassandra 互換データベースサービスです。今回オンデマンドモードの料金を単一リージョンで最大56%、マルチリージョンで最大65%引き下げました。また、プロビジョニングモードの料金は、単一リージョンで最大13%、マルチリージョンで最大20%引き下げられました。また、Keyspacesは有効期限（TTL）の削除料金を75%引き下げました。この変更により、以前のようにスパイクがあるワークロードだけでなく、大半のワークロードでオンデマンドモードの利用が推奨されます。 AWS Transit Gateway and AWS Cloud WAN enhance visibility metrics and Path MTU support – AWS AWS Transit Gateway と AWS Cloud WAN enhance において、アベイラビリティーゾーン (AZ) 単位のメトリクスをCloudWatchに送信可能になりました。AZ単位のメトリクスにより、AZ単位で詳細可視化できるようになり、AZ単位の障害を迅速にトラブルシューティングできるようになります。あわせて、パス最大伝送ユニット検出（PMTUD）をサポートするようになりました。 Amazon RDS for PostgreSQL now supports major version 17 – AWS Amazon RDS for PostgreSQL において PostgreSQL バージョン 17.1 が利用可能になりました。あわせて、最新のマイナーバージョンである、16.5、15.9、14.14、13.17、12.21の利用も可能になっています。 Amazon S3 now supports up to 1 million buckets per AWS account – AWS Amazon S3 で、AWS アカウントあたりのデフォルトバケット数のクォータ（上限値）を 100 から 10,000 に引き上げました。また、最大100万バケットまでクォータの増加をリクエスト可能になりました。この変更は自動的に適用されるため、ユーザー側のよる操作は必要ありません。最初の 2,000 バケットは無料で作成できますが、2,000 バケットを超えると、少額の月額料金がかかる点に注意してください。詳細は S3の料金ページ をご覧ください。 Amazon RDS for Oracle now M7i and R7i instances types – AWS Amazon RDS for Oracle で、M7iおよびR7iデータベースインスタンスタイプが利用可能になりました。新しい最大インスタンスサイズは 48xlarge になり、M6iやR6iインスタンスと比較して50%多い最大vCPUとメモリを利用可能になりました。M7i および R7i インスタンスは、Oracle Database エンタープライズエディション（EE）とスタンダードエディション 2（SE2）の両方のエディションで、Bring Your Own ライセンスモデルで利用できます。 11/15(金) Introducing Amazon Route 53 Resolver DNS Firewall Advanced – AWS Amazon Route 53 Resolver DNS Firewall Advanced がリリースされました。これは Route 53 Resolver DNS ファイアウォールの新しい機能で、DNS トンネリングやドメイン生成アルゴリズム (DGA) などの高度な DNS 脅威に関連する、疑わしいDNSトラフィックを監視およびブロックできます。詳細は こちらのドキュメンテーション をご覧ください。 Amazon Data Firehose supports continuous replication of database changes to Apache Iceberg Tables in Amazon S3 – AWS Amazon Data Firehose で RDS、Aurora、もしくはEC2上で稼働する MySQL もしくは PostgreSQL のトランザクションログから更新データを読み取り、Amazon S3上のApache Iceberg表に差分反映させる機能がPreview提供開始になりました。サーバーレスのサービスを利用して、より容易に、RDBからS3への差分レプリケーションが実現可能になります。東京・大阪リージョンでもPreviewが利用可能です。詳細は こちらのブログ をご覧ください。 Centrally manage root access in AWS Identity and Access Management (IAM) – AWS AWS Identity and Access Management (IAM) に、AWS Organizations 管理化のAWSメンバーアカウントにルート(root)権限でアクセス可能な機能が追加されました。これまで個々のメンバーアカウントごとにrootユーザーが必要で、これをセキュアに管理していく必要がありましたが、この機能により集中的にroot権限を管理できるようになります。 詳細はこちらのブログ をご覧ください。 先週もご案内しましたが、恒例の「1時間でre:Inventの発表まとめをしゃべりきる日本語Webinar」が 12 月 6 日 (金) 12:00~13:00 に開催されます。新発表内容をいっきに振り返る内容なので、ぜひこちらもご覧ください。今回はYoutube Liveでの放送予定ですので、事前に「通知を受け取る」ボタンをクリックしておいてください。 – AWS Black Belt Online Seminar 2024 年 AWS re:Invent 速報 それでは、また来週！ 著者について 下佐粉 昭(Akira Shimosako) @simosako 2015年より AWS Japan のソリューションアーキテクトとして、主に製造業・金融業のお客様に対し、クラウド活用の技術支援を行ってきました。その後、アナリティクス領域を専門とする部門に異動し、現在はデータレイク・データウェアハウスを専門としてお客様のデータをクラウドで活用することを支援しています。少年時代は 8 Bit パソコンと共に育ったため、その時代の本やアイテムを見かけると、ついつい買ってしまいます。

お客様は通常、SQL Server データベースを Babelfish for Aurora PostgreSQL に移行するために AWS Database Migration Service (AWS DMS) を選択します。AWS DMS は、フルロードの移行は、すべてのエディションの SQL Server をサポートしています。ただし、継続的なレプリケーションと進行中の変更の場合、ソースとなる SQL Server は トランザクションレプリケーション または 変更データキャプチャ (CDC) を有効にする必要があります。これにより、AWS DMS はデータベースのトランザクションログファイルまたはトランザクションログバックアップから変更を読み取り、ターゲットデータベースにレプリケートすることができます。 Enterprise、Standard、Developer などの SQL Server エディションには、トランザクションレプリケーションと CDC 機能が付属しています。したがって、これらのエディションでは Babelfish for Aurora PostgreSQL への継続的なレプリケーションを実装できます。ただし、SQL Server Web エディションを使用している場合や Azure SQL 上で SQL Server ワークロードを実行している場合は、トランザクションレプリケーションと CDC のいずれもサポートされていません。そのような場合は、継続的なレプリケーションなしでフルロードのみを実行できます。 この制限を回避するには、 リンクサーバー と併せて 変更トラッキング を使用するワークアラウンドがあります。このアプローチでは、Azure SQL または SQL Server Web Edition での変更をトラッキングし、対象データベースに効果的にレプリケーションできます。 この投稿では、SQL Server Web Edition (ソース) の変更トラッキング機能と、Babelfish for Aurora PostgreSQL (ターゲット) のリンクサーバー機能を使用して、進行中の変更をレプリケーションする手順を提供します。 ソリューション概要 変更トラッキングはデータベース内のデータ変更をトラッキングするメカニズムです。テーブルで変更トラッキングが有効になると、SQL Server は内部的に別の内部テーブルで変更(挿入、更新、または削除)をトラッキングします。この内部テーブルにはテーブルの主キー列が含まれています。 トラッキングが有効になってからの変更はすべて、CHANGETABLE という関数を使用して取得できます。変更トラッキングの詳細については、「 変更トラッキングの操作 (SQL Server) 」を参照してください。 次の図は、ソリューションアーキテクチャを示しています。 このソリューションを実装するには、次の設定手順を完了してください。 ソースサーバーでデータベースとテーブルレベルの変更トラッキングを有効にします。 AWS DMS を使用して、ソースデータベースの初期フルロードをターゲットに対して行います。 ターゲットにソース SQL サーバーへのリンクサーバーを作成します。 ターゲットにアンカーテーブルを作成します。 ソースから変更されたデータを抽出し、ターゲットテーブルにロードします。 前提条件 このソリューションを試すには、次の前提条件が必要です。 ソースとなる SQL Server または Azure SQL インスタンス SQL Server 上の Northwind データベース バージョン 4.0 または以降の Babelfish for Aurora PostgreSQL インスタンス SQL Server と PostgreSQL のファンクションに関する知識 SQL Server に接続するための SQL Server Management Studio (SSMS) または他のクライアントツール このソリューションには、新しい AWS リソースの作成と利用が伴います。したがって、アカウントに料金が発生します。詳細については、 AWS 料金ぺージ をご確認ください。本番環境にこのソリューションを実装する前に、非本番インスタンスでセットアップを行い、エンドツーエンドの検証を実行することを強くお勧めします。 ソースデータベスでの変更トラッキング有効化 ソースサーバーで変更トラッキングを有効にするには、次の手順に従ってください。 SSMS を使用して SQLServer インスタンスに接続します。 Northwind データベースを選択し、[新しいクエリ] を選択します。 次のコマンドを使用してデータベースレベルで変更トラッキングを有効にします。 ALTER DATABASE NORTHWIND SET CHANGE_TRACKING = ON ( CHANGE_RETENTION = 5 DAYS , AUTO_CLEANUP = OFF ) SQL 継続的レプリケーションのターゲットの一部として含めたいテーブルで変更トラッキングを有効にします。ここでは、次のコマンドを使用して顧客テーブルで変更トラッキングを有効にします。 ALTER TABLE DBO . CUSTOMERS ENABLE CHANGE_TRACKING SQL 次のコマンドを実行して、テーブルで変更トラッキングが有効になっていることを確認してください。 SELECT schema_name ( T . schema_id ) as SCH_NAME , T . NAME , CT . min_valid_version , ct . * FROM northwind . sys . tables T LEFT OUTER JOIN sys . change_tracking_tables CT on T . object_id = CT . object_id WHERE min_valid_version is not null SQL 変更トラッキングが更新された行をどのように取得するかをテストするには、次のコマンドを実行します。 関数 CHANGE_TRACKING_CURRENT_VERSION() を使用して、現在の変更トラッキングバージョンを確認します。この値が 26 であると仮定しましょう。 customers テーブルの行を更新します。 customers テーブルのどの行が更新されたかを確認するには、バージョン番号 (この例では 26) をパラメーターとして CHANGETABLE 関数を使用します。 DECLARE @CTCV INT ; SELECT @CTCV = CHANGE_TRACKING_CURRENT_VERSION ( ) ; -- In this example , the current value is 26 SELECT @CTCV -- update a record in customer table UPDATE dbo . CUSTOMERS SET CompanyName = 'camilo2' where CUSTOMERID = 'ALFKI' -- Get all the changes that are made after version 26 in this example. SELECT P . * , '--' , CT . * FROM customers AS P JOIN CHANGETABLE ( CHANGES northwind . dbo . customers , @CTCV ) AS CT ON P . customerid = CT . customerid ; SQL AWS DMS を使ってフルロードを開始する前に、継続的なレプリケーションが必要なテーブルで変更トラッキングを有効にすることが不可欠です。これにより、システムはフルロードの開始時点から指定されたテーブルに対するすべてのデータ変更操作 (DML) を追跡できるようになります。 AWS DMS を使用して初回のフルロードでソースデータベースをターゲットデータベースに移行 ターゲットにフルロードを使用してソースデータベースを AWS DMS で移行するには、次の手順を実行します。「 Compass ツールと AWS DMS を使用した SQL Server の Babelfish for Aurora PostgreSQL への移行 」を参照し、Babelfish for Aurora PostgreSQL クラスターを作成して接続します。投稿では、AWS DMS を使用して SQL Server から Babelfish にデータを移行する手順も概説されています。 ターゲットサーバーで、Northwind データベースのスキーマを作成してください。Northwind サンプルスキーマは、 GitHub リポジトリ からダウンロードできます。 AWS DMSのフルロード設定を使用して、ソースからターゲットにデータを移行します。手順については、「 AWS Database Migration Service のターゲットとしての Babelfish for Aurora PostgreSQL の使用 」を参照してください。 ソース SQL Server に対するリンクサーバーをターゲットに作成 Babelfish for Aurora PostgreSQL でリンクサーバーを構成するには、「 Babelfish は、リンクサーバーをサポートしています 」を参照してください。次の手順を完了してください。 SSMS または SQLCMD を使用してターゲットのデータベースインスタンスに接続し、次のコマンドを実行します。ここでは、SQLCMD を使用して Babelfish for Aurora PostgreSQL インスタンスに接続します。適切な値でパラメーターを置き換えてください。 sqlcmd - S your - DB - instance . aws - region . rds . amazonaws . com - U test - P password SQL tds_fdw 拡張機能をインストールします。 EXEC sp_execute_postgresql N 'CREATE EXTENSION tds_fdw' ; SQL ターゲットインスタンスで次のコマンドを使用してリンクサーバーを作成します。@datasrc、@rmtuser、および @rmtpassword パラメーターを適切な値に置き換えてください。 Use Northwind ; GO EXEC master . dbo . sp_addlinkedserver @server = N 'ls_northwind' , @srvproduct = N '' , @provider = N 'SQLNCLI' , @datasrc = N 'myserver.xxxxx.US-WEST-2.RDS.AMAZONAWS.COM' , @catalog = 'northwind' ; GO EXEC master . dbo . sp_addlinkedsrvlogin @rmtsrvname = N ' ls_northwind' , @useself = N 'False' , @locallogin = NULL , @rmtuser = N 'username' , @rmtpassword = 'password' ; SQL リモートサーバー上のテーブル、ビュー、またはその他のサポートされているオブジェクトを参照するには、次のコードに示されているように OPENQUERY() T-SQL を使用するか、標準の 4 部構成の名前付け規則を使用します。 SELECT * FROM OPENQUERY ( ls_northwind , 'SELECT * FROM customers' ) ; SQL 初期の変更トラッキングバージョン (この例では 0 を使用) に基づいて customers テーブルの変更されたレコードを取得するには、次のコマンドを実行します。 SELECT * FROM OPENQUERY ( ls_northwind , 'SELECT C.* FROM customers AS C JOIN CHANGETABLE(CHANGES northwind.dbo.customers,0 ) AS CT ON C.customerid = CT.customerid' ) ; SQL 次のスクリーンショットは私たちの出力結果です。 変更トラッキングバージョンに基づいて、ソースの変更済みレコードを正常にクエリしました。ソリューションを自動化するには、変更トラッキングバージョンを保存する必要があります。変更トラッキングバージョンをアンカーテーブルと呼ばれる別のテーブルに保存できます。これにより、前回の同期以降の変更のみを取得できます。 ターゲットにアンカーテーブルを作成 リンクサーバーを使用してソースのレコードを照会した後、ターゲットにアンカーテーブルを作成します。ここでは、次のコマンドを使用して Northwind データベース内に CT_ANCHOR_NORTHWIND という名前のテーブルを作成します。このテーブルはアンカーとして機能し、データがレプリケーションされるたびに変更トラッキングバージョン番号を保持します。 CREATE TABLE ct_anchor_northwind ( sch_name varchar ( 256 ) , tbl_name varchar ( 256 ) , ct_fetched_ver int , -- 0 during first execution ct_next_ver int -- current version at the source database , to fetch next version of the records ) SQL アンカーテーブルを作成した後、追跡する各テーブルの行を挿入します。ここでは、Northwind データベースの customers テーブルのスキーマ名、顧客名、取得した変更追跡バージョン、次の変更トラッキングバージョンの値を挿入します。 insert into ct_anchor_northwind ( sch_name , tbl_name , ct_fetched_ver , ct_next_ver ) values ( 'dbo' , 'customers' , 0 , 0 ) SQL 次のスクリーンショットは私たちの出力結果です。 各レプリケーションでは、CT_NEXT_VER カラムを手動またはスクリプトを使用して変更トラッキングテーブルの現在のバージョン ID で更新する必要があります。この値を使用して、次の変更されたレコードのセットを取得できます。 次の図は、各同期中にバージョン番号を維持する方法を説明しています。 ソースからデータの変更部分を抽出してターゲットテーブルにロード ソースの SQL Server とターゲットの Babelfish for Aurora PostgreSQL 間でデータを同期するには、次の手順を実行します。これらの手順はスケジュールに従って実行することもできます。 ターゲットデータベースに接続し、アンカーテーブル (ct_northwind_anchor) から ct_next_ver( 次にレコードを取得するバージョン ) の値を @ct_next_ver という変数に取得します。 declare @ct_next_ver varchar ( 9 ) SELECT @ct_next_ver = ct_next_ver FROM ct_anchor_northwind WHERE sch_name = 'dbo' and tbl_name = 'customers' print @ct_next_ver -- result: 0 SQL 変数 @ct_src_current_ver にソースからの現在の変更トラッキングバージョンを取得します。ターゲットでリンクサーバーのクエリを使用して値を取得できます。 declare @ct_src_current_ver varchar ( 9 ) SELECT @ct_src_current_ver = src_current_ver FROM OPENQUERY ( ls_northwind , 'select change_tracking_current_version () as src_current_ver from northwind.sys.change_tracking_tables' ) print @ct_src_current_ver -- result: 10 SQL ソーステーブルの変更された行の主キー値に一致するターゲットのレコードを、特定の変更トラッキングバージョン (@ct_next_ver) に基づいて削除します。 DELETE FROM [dbo].[customers] from [dbo].[customers] x JOIN ( SELECT * from openquery(ls_northwind,'select x.[customerid] FROM [northwind].[dbo].[customers] x JOIN changetable(changes [northwind].[dbo].[customers],0) as y on x.[customerid]=y.[customerid] ')) y on x.[customerid]=y.[customerid] ; -- result : 2 rows affected SQL 特定の変更トラッキングバージョン (@ct_next_ver) に基づいて、ソースから新しいレコードを抽出し、それらの宛先に配置します。 INSERT INTO [dbo].[customers]([customerid],[companyname],[contactname],[contacttitle],[address],[city],[region],[postalcode],[country],[phone],[fax]) SELECT * FROM OPENQUERY(ls_northwind,'select x.[customerid], x.[companyname], x.[contactname], x.[contacttitle], x.[address], x.[city], x.[region], x.[postalcode], x.[country], x.[phone], x.[fax] from [northwind].[dbo].[customers] x join changetable(changes [northwind].[dbo].[customers],0) as y on x.[customerid]=y.[customerid] ') -- result: 2 rows affected SQL アンカーテーブルの列の値を適切な値で更新してください。これらの値は次の実行時に次のセットを取得するために使用されます。 UPDATE ct_anchor_northwind SET ct_fetched_ver = @ct_next_ver , ct_next_ver = @ct_src_current_ver WHERE sch_name = 'dbo' and tbl_name = 'customers' SQL ターゲットテーブルの値をソースと照合して、同期を確認してください。 SELECT * FROM customers WHERE customerid = 'alfki' SQL クリーンアップ 今後の課金を避け、このユースケースのテスト中に作成されたコンポーネントを削除するには、以下の手順を実行してください。 SSMS を使用して、ソースの SQL Server インスタンスに接続します。 マスターデータベースを選択し、[新しいクエリ] を選択します。 次のコマンドを実行してください。 Drop database Northwind GO SQL まとめ この投稿では、リンクサーバーを使用した変更トラッキングによって、SQL Server データベースを Babelfish for Aurora PostgreSQL に移行する方法を示しました。この構成により、最小のダウンタイムで SQL Server ワークロードを Babelfish for Aurora PostgreSQL に移行できます。このソリューションは、スクリプトをスケジュールされたジョブとして実行することで自動化できます。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Chandra Pathivada は、アマゾン ウェブ サービスのシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのオープンソースデータベースエンジンを中心に Amazon RDS チームで働いています。AWS 上でリレーショナルデータベースワークロードを設計、デプロイ、最適化するお客様をサポートすることを楽しんでいます。 Minesh Chande は、アマゾン ウェブ サービスのシニアデータベーススペシャリストソリューションアーキテクトです。彼は様々な業界のお客様が SQL Server のワークロードを Amazon RDS、Amazon RDS Custom、Babelfish for Aurora PostgreSQL などのマネージドデータベースプラットフォームに設計、移行、最適化するのを支援しています。