本ブログは 2024 年 10 月 2 日に公開された「 Enhancing data privacy with layered authorization for Amazon Bedrock Agents 」を翻訳したものとなります。 お客様は、自社のアプリケーション内で生成 AI を使用することにいくつかの利点を見出しています。ただし、生成 AI を使用すると、アプリケーションの脅威モデルを検討する際に新たな考慮事項が追加されます。これは生成 AI の利用が、オペレーション効率を高めるために顧客体験を向上させるためであっても、よりカスタマイズされた特定の結果を生成するためであっても、その他の理由であっても同様です。 生成 AI モデルは本質的に非決定論的です。つまり、同じ入力が与えられても、モデルの確率的性質により、生成される出力は異なる場合があります。 Amazon Bedrock などのマネージドサービスをワークロードで使用する場合、Amazon Bedrock がアクセスするデータの保護を確実にするのに役立つ追加のセキュリティ上の考慮事項があります。 本ブログでは、生成 AI サービスを使用する際のデータのコントロールで直面する可能性のある現在の課題と、Amazon Bedrock 内のネイティブソリューションと階層化された認可を使用してそれらを克服する方法について説明します。 定義 まず始めに、いくつかの言葉の定義を確認してみましょう。 Amazon Bedrock エージェント: Amazon Bedrock エージェント を使用すると、企業のシステムやデータソースにわたる複数ステップのタスクを自律的に完了できます。エージェントは、入力データを充実させてより正確な結果を得ることや、繰り返しの多いタスクの自動化に使用できます。生成 AI エージェントは、エージェントがアクセスできる入力と環境のデータに基づいて意思決定を行うことができます。 階層化された認可: 階層化された認可とは、初めにアクセスされるポイントからアプリケーションコンポーネント間で複数の認可チェックを実装する手法です。これには、サービス間の認可、アプリケーションコンポーネント全体で真のエンドユーザーのアイデンティティを伝達すること、そしてサービスの認可に加えて各操作にエンドユーザーの認可を追加することが含まれます。 信頼できるアイデンティティの伝搬: 信頼できるアイデンティティを伝搬することで、AWS リソースへのユーザーアクセスの定義、付与、およびログ記録がより簡単になります。信頼できるアイデンティティの伝播は OAuth 2.0 の認可フレームワークに基づいて構築されているため、アプリケーションはパスワードを共有しなくてもユーザーデータに安全にアクセスして共有できます。 Amazon Verified Permissions: Amazon Verified Permissions は、証明可能な正しい Cedar ポリシー 言語を使用するフルマネージド型の認可サービスであり、より安全なアプリケーションを構築できます。 チャレンジ AWS で構築する場合、データやお客様の情報を安全に保つのに役立ついくつかのサービスや機能があります。これには、 Amazon Simple Storage Service (Amazon S3) のデフォルト暗号化や AWS Key Management Service (AWS KMS) キーによる保存時の暗号化、または Amazon S3 のプレフィックスや Amazon DynamoDB のパーティションキーを使用してテナントのデータを分離することが含まれます。これらのメカニズムは、保存中のデータの処理やデータパーティションの分離には優れています。しかし生成 AI を搭載したアプリケーションがユーザーの入力に基づいてさまざまなデータ（異なるタイプの機微データ、複数のテナントのデータなど）にアクセスできるようになると、機微データが漏洩するリスクが高まります（AWS のデータプライバシーの詳細については、 データプライバシーに関するよくある質問 を参照してください）。これは、データへのアクセスが、ワークロードのなかで呼び出し元のプリンシパルに代わって信頼できないアイデンティティ (モデル) に渡されるためです。 多くのお客様が、ユーザーの入力に追加情報を付加して応答を改善するために、アーキテクチャに Amazon Bedrock エージェント を使用しています。またエージェントは、反復的なタスクを自動化し、ワークフローを効率化するためにも使用されます。たとえば、チャットボットは、医療提供者向けに患者の検査結果をまとめるなど、ユーザーエクスペリエンスを向上させるための便利なツールになります。ただし、チャットボットソリューションを実装する際には、潜在的なセキュリティリスクと緩和戦略を理解することが重要です。 一般的な生成 AI アプリケーションのアーキテクチャには、 Amazon API Gateway を介してチャットボットエージェントを呼び出すものがあります。API Gateway は Amazon Cognito または AWS Lambda オーソライザーを使用して API 呼び出しを検証し、その後チャットボットエージェントにリクエストを渡してその機能を実行します。 チャットボットエージェントにユーザーが入力プロンプトを提供できる場合、潜在的なリスクが生じます。この入力により、プロンプトインジェクション（ OWASP LLM:01 ）または機微情報の漏出（ OWASP LLM:06 ）の脆弱性につながる可能性があります。根本的な原因は、チャットボットエージェントがその機能を果たすために、さまざまなデータストア (S3 バケットやデータベースなど) へのアクセス権を持つ AWS Identity and Access Management (IAM) サービスロール による広範なアクセス権限を必要とすることです。適切なセキュリティコントロールがない場合、あるテナントの脅威アクターが、別のテナントに属するデータにアクセスしたり操作したりする可能性があります。 解決策 すべてのリスクを軽減できる単一のソリューションはありませんが、コンシューマーアプリケーションの適切な脅威モデルを用意してリスク (データへの不正アクセスなど) を特定することは重要です。AWS では、適切な脅威モデルを作成するのに役立つ、いくつかの生成 AI セキュリティ戦略を提供しています。本ブログでは、コンシューマーアプリケーションをサポートするソリューションを中心に、アプリケーション全体にわたる階層化された認可に注目します。 注 : これは、ワークフォースアプリケーション向けの Trusted identity propagation (TIP) と Amazon S3 Access Grants を使用して実現することもできます。 コンシューマー向けの OpenID Connect (OIDC) アイデンティティプロバイダー (IdP) などの強力な認証プロセスを多要素認証 (MFA) と組み合わせて使用することで、API Gateway でエージェントを呼び出すためのアクセスを統制できます。図 1 に示すように、リクエストのヘッダーにある JWT トークンを使用して、エージェントにカスタムパラメーターを渡すことをお勧めします。このような構成では、エージェントが記述された機能を実行する前に、 Amazon Verified Permissions を使用して isAuthorized リクエストを評価し、呼び出しユーザーが要求されたデータにアクセスできることを確認します。このアーキテクチャを図 1 に示します。 図 1: 認可アーキテクチャ アーキテクチャの手順は次のとおりです。 クライアントはアプリケーションフロントエンドに接続します。 クライアントは、認証のための Amazon Cognito ユーザープール UI へリダイレクトされます。 クライアントは Amazon Cognito から JWT トークンを受け取ります。 アプリケーションフロントエンドは、クライアントから提示された JWT トークンを使用して Amazon Bedrock エージェントへのリクエストを認可します。アプリケーションフロントエンドは、 InvokeAgent API 呼び出しに JWT トークンを追加します。 エージェントはリクエストを確認し、必要に応じてナレッジベースを呼び出たり、Lambda 関数を呼び出したりします。エージェントは、アプリケーションフロントエンドから提供された JWT トークンを Lambda 呼び出しコンテキストに含めます。 Lambda 関数は JWT トークンの詳細を使用して、Verified Permissions を使用して DynamoDB テーブルへの以降の呼び出しを認可します(6a)。呼び出しが認可された場合のみ DynamoDB テーブルを呼び出します (6b)。 ディープダイブ Amazon Bedrock エージェントをトリガーする API Gateway の背後にあるアプリケーションを設計する場合を考えます。このとき、 AssumeRole により Amazon Bedrock へのアクセス権を付与する信頼ポリシーを使用して、エージェント用の IAM サービスロールを作成する必要があります。このロールにより、Amazon Bedrock はエージェントアクショングループの Lambda 関数用 OpenAPI スキーマを S3 バケットから取得でき、指定されたモデルへの bedrock:InvokeModel アクションが可能になります。エージェントのセッションデータを暗号化するためにデフォルトの KMS キーを選択しなかった場合は、カスタマー管理の KMS キーにアクセスするための権限を IAM サービスロールに付与する必要があります。ポリシーと信頼関係の例を次に示します。 次のポリシーは、Amazon Bedrock モデルを呼び出す権限をエージェントに付与します。“Resource“ では、承認された基盤モデル(FM)を対象としています。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentBedrockFoundationModelPolicy", "Effect": "Allow", "Action": "bedrock:InvokeModel", "Resource": [ "arn:aws:bedrock:us-west-2::foundation-model/your_chosen_model" ] } ] } Plain text 次に、Amazon Bedrock エージェントに s3:GetObject へのアクセスを許可するポリシーステートメントを追加します。このステートメントでは、アカウント番号が組織内のアカウント番号と一致する S3 バケットを対象とします。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentDataStorePolicy", "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::S3BucketName/*" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "Account_Number" } } } ] } Plain text 最後に、定義されたロールを引き受ける権限を Amazon Bedrock に付与する信頼ポリシーを追加します。また、 混乱する代理問題 を防ぐため、サービスがアカウントに代わって呼び出していることを確認するための条件も追加しました。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AmazonBedrockAgentTrustPolicy", "Effect": "Allow", "Principal": { "Service": "bedrock.amazonaws.com" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "aws:SourceAccount": "Account_Number" }, "ArnLike": { "aws:SourceArn": "arn:aws:bedrock:us-west-2:Account_Number:agent/*" } } } ] } Plain text Amazon Bedrock エージェントはサービスロールを使用しており 、一般には利用者のアイデンティティを伝搬しません。これは、テナントのデータを保護する上での潜在的な問題につながる可能性があります。エージェントが未分類のデータ（訳者注: 保護の必要ないデータ）にアクセスしている場合、認可の呼び出し元に基づいてアクセスをさらに分離する必要がないため、階層化された認可を追加する必要はありません。ただし、アプリケーションが機微データにアクセスできる場合は、認可をエージェントの機能の処理に加える必要があります。 そのためには、エージェントを呼び出してトリガーされる Lambda 関数に認可の階層を追加します。まず、エージェントを初期化して、 Verified Permissions への isAuthorized 呼び出しを行います。 Allow 応答があった場合にのみ、エージェントは残りの機能を実行します。Verified Permissions からの応答が Deny の場合、エージェントはステータス 403 またはわかりやすいエラーメッセージをユーザーに返す必要があります。 Verified Permissions には、データへのアクセス時にどのように認可を行うかを規定するポリシーがあらかじめ組み込まれている必要があります。たとえば、呼び出し元のプリンシパルが医師の場合に、患者の記録へのアクセスを許可する次のようなポリシーがあるかもしれません。 permit( principal in Group::"doctor", action == Action::"view", resource ) when { resource.fileType == Sensitive && resource.patient == doctor.patient }; Plain text この例では、この決定を処理する認可ロジックはエージェントから呼ばれる Lambda 内にあります。そのために、Lambda 関数はまず、Amazon Bedrock エージェントにカスタムパラメータとして渡された JWT をデコードしてエンティティ構造を構築し、呼び出し元のプリンシパルのアクセスを評価します。リクエストされたデータには isAuthorized 呼び出しも含める必要があります。このデータが Verified Permissions に渡されると、提供されたコンテキストとポリシーストア内のポリシーを評価しアクセス可否を決定します。ポリシー決定ポイント (Policy Decision Point: PDP) として、許可または拒否の決定はアプリケーションレベルで実施する必要があることに注意します。この決定に基づいて、データへのアクセスが許可または拒否されます。アクセスされるリソースは、アプリケーションがアクセス制御を評価しやすいように分類する必要があります。たとえば、データが DynamoDB に保存されている場合、患者は Verified Permissions スキーマで定義された階層的に参照されるパーティションキーで区切ることも考えられます。 結論 本ブログでは、AWS ネイティブサービスを使用して Amazon Bedrock エージェントを使用するコンシューマーアプリケーション全体に階層化された認可を適用することで、データ保護を向上させる方法を学びました。また、 アイデンティティプロセスを通じてアクセス制御の適用を改善する手順を説明しました。これは Amazon Bedrock エージェントを使用してアプリケーションを構築するのに役立ち、データの強力な分離を維持することで意図しない機密データの漏洩を防ぐことができます。 Verified Permissions と Amazon Bedrock エージェントを使用してアプリケーション全体に階層化された認可を適用する方法について詳しく学ぶには、「 Secure Generative AI Solutions using OWASP Framework 」ワークショップをお勧めします。 本ブログについて質問がある場合は、 AWS サポートにお問い合わせください 。 Jeremy Ware Jeremy は、生成 AI ワークロードの ID アクセス管理とセキュリティを専門とするシニアセキュリティスペシャリストソリューションアーキテクトです。Jeremy と彼のチームは、AWS のお客様が高度でスケーラブルで安全なワークロードを実装してビジネス上の課題を解決できるよう支援しています。Jeremy は長年にわたり、多くのグローバル企業でセキュリティの成熟度を向上させてきました。自由時間には、Jeremy は家族と一緒にアウトドアを楽しんでいます。 Yuri Duchovny Yuri はニューヨークを拠点とするプリンシパルソリューションアーキテクトで、クラウドセキュリティ、アイデンティティ、コンプライアンスを専門としています。Yuri は大企業のクラウド変革を支援し、企業が最適なテクノロジーと組織的な意思決定を行えるよう支援しています。AWS での職務に就く前は、アプリケーションとネットワークのセキュリティ、DoS、不正防止に注力をしていました。仕事以外では、スキー、セーリング、世界中への旅行を楽しんでいます。 Jason Garman Jason は、バージニア州北部に拠点を置く AWS のプリンシパルセキュリティスペシャリストソリューションアーキテクトです。Jason は、世界の大手組織が重大なセキュリティ課題を解決できるよう支援しています。AWS に入社する前にはサイバーセキュリティ業界で、スタートアップを含む官民を問わないさまざまな役割を果たしていました。彼は出版作家で、サイバーセキュリティ技術に関する特許を保有しており、家族と一緒に旅行するのが大好きです。 翻訳はプロフェッショナルサービス本部の池澤、藤浦が担当しました。

Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture on the theme of “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post reports on the contents of the lecture, following up on the previous post. The job titles are as of the day of event. Panel Discussion: A History of Digital Transformation Forged with AWS Shimpei Otani, Group Executive Officer (CTO & CSO), Digital Business Transformation Services, Fast Retailing Co., Ltd. Shigeru Horikawa, Director (Infrastructure), Digital Business Transformation Services, Fast Retailing Co., Ltd. Yasuhiro Kitaguchi, Director (SCM & Integration Engineering), Digital Business Transformation Services, Fast Retailing Co., Ltd. Yuichi Murata, Director (Core Engineering), Digital Business Transformation Services, Fast Retailing Co., Ltd. Kempei Igarashi, Senior Manager, Retail, Consumer Goods & Services Business Group, Amazon Web Services Japan G.K. Career and Responsibilities of the Panelists First, the panelists talked about their own careers. Mr. Otani joined Fast Retailing in 2016 with a mission of internalizing engineering and embedding technology in the business. Currently he is the Chief Technology Officer and also in charge of security. Regarding the relationship with AWS, almost all Fast Retailing services run on AWS, leveraging it for over 12 years. He also shared the facts that he was actually an AWS Solutions Architect in his previous role and had visited Fast Retailing as a service provider during that time. Since joining in 2012, Mr. Horikawa has experienced shifting from on-premises to cloud, with 12 years of experience working with AWS. Entering a company like Fast Retailing meant a major shift in his goals as an engineer, from system implementation to business results themselves. Since joining in 2018, Mr. Kitaguchi has been responsible for developing common platforms and the data integration platform. Currently his focus is on logistics process reform and preparing digital tools. His AWS involvement began after joining Fast Retailing, consulting with AWS product teams when building new systems to determine optimal architectures. Mr. Murata joined in 2017 and experienced the Ariake Project from launch. Starting with developing back-end systems for e-commerce, he went through roles in infrastructure and quality assurance before becoming department manager overseeing in-house development (his current role). E-commerce heavily utilizes AWS with ongoing support. He also introduced a new initiative leveraging Amazon Connect to reform call center operations. Dawn Period – Fostering Culture The discussion began with the theme “Dawn Period – Fostering Culture”. Mr. Horikawa, with the longest tenure, looked back on episodes from when he joined. He learned AWS through seminars and vendor support. Before deciding to use AWS, he gained experience while receiving support from AWS Solutions Architects and others. Initially there were no architecture review processes, and failures like system outages due to lack of quality assurance occurred. Architecture reviews were born by learning from such failures. Mr. Otani shared stories about the Ariake automated warehouse project, which unlike IT projects, had physical constraints like installing the warehouse hardware, giving him a taste of the pains unique to an apparel company. The project was still chaotic then without a clear picture, but consistently recruiting talented people has created an environment conducive to exchanging wisdom. Addressing critical issues collaboratively naturally fostered the current culture. Mr. Horikawa also talked about negotiating with AWS over a 4TB database instance for an SAP implementation. At the time he believed it could only be done on-premises, but looking ahead to future growth, he negotiated with AWS and made it happen. This experience taught him that even seemingly impossible things could be achieved through proper negotiation. As described above, Fast Retailing fostered their current culture by overcoming various failures and challenges with AWS from the dawn period of adoption. Unafraid to challenge and collaborate to solve issues formed the foundation of their culture. Closely cooperating with AWS to nurture this new culture was a major factor enabling Fast Retailing’s digital transformation. Transition Period – Architectural Changes The next theme was the transition period when the team at Fast Retailing implemented many architectural changes. Mr. Murata discussed shifting from the conventional monolithic EC package to a headless platform architecture, achieving microservices, immutable infrastructure adoption, multi-region deployment, leveraging open source and managed services, and standardizing technology. He reflected on the complexity of business logic and challenges with performance and scalability. Mr. Kitaguchi explained how they initially started by just lifting and shifting their on-premise applications onto the cloud, and then gradually moved towards containerization and building CI/CD pipelines with global deployment in mind. Cost-conscious tool provision and close collaboration with business departments for cost awareness were also covered. Mr. Otani talked about standardization initiatives. The background of adopting Amazon Aurora and Amazon ElastiCache as a standard and establishing criteria for programming languages and frameworks was introduced. The struggles with proliferating tools seem to have driven the perception that some standardization is essential. On the other hand, Mr. Otani also pointed out the importance of maintaining appropriate flexibility in technology selection. Excessive standardization causes loss of flexibility, so preserving suitable options for engineers is also important. These standardization efforts occurred during large-scale concurrent development. Architectural transformation was carried out in stages looking ahead to global expansion, achieving a break-down into platforms and microservices, achieving standardization, etc. Expansion Period – Globalization Regarding globalization challenges, Mr. Murata talked about local considerations. They operate multiple brands across roughly 30 markets, requiring a global platform while also addressing needs from each country. Proper prioritization and efficiency are important, but a “global-solution” does not necessarily fit all regions. Aspects like delivery methods and data privacy handling require localization. Mr. Otani added that technical issues cannot always be decided solely by engineers, sometimes requiring management judgment considering geopolitical risks. Mr. Horikawa talked about network optimization changes. Initially all store communication concentrated to Tokyo, but now leveraging the AWS network fully, connecting each country directly to the nearest AWS Region improved speed and availability by utilizing the AWS backbone network. Mr. Kitaguchi said based on the characteristics of location-based systems with high customization and requirements variation, they take an approach of building global core aspects like consistent inventory management and streamlining shipping/receiving workflows, then adding localized custom wrappers. Cultural alignment is also important in multinational teams. Shared values represented in the mission statement foster decision-making and unity in diverse teams. Building an inclusive environment through mission sharing offers something to learn for any organization driving a cloud journey. Security Mr. Otani, also CSO, commented on security. Information systems today especially require enterprise-wide security uplift. Security encompasses many aspects beyond just technology, like executive awareness and physical measures. In addition to IT security, operational measures are indispensable for protecting customer information. Fast Retailing aims not just to meet IT security standards, but exceed them. He emphasized holistically addressing security aligned to corporate mission and ingraining appropriate standards into organizational culture. However, excessive security rigidness risks losing the creativity and added value that IT brings. Striking the right balance between security and IT flexibility is key, with an important security team role being to maintain that balance. Summary Closing comments by members are summarized as follows: Selecting cloud and platform products should consider not just current capabilities, but future evolution based on organizational culture. AWS was initially established to address the business challenges of Amazon, a company rooted in retail. AWS shares a customer-centric culture with Fast Retailing in many ways. Fast Retailing evaluated AWS as a company that continues to evolve in order to address customer needs. Reflecting on their 12-year collaboration, Fast Retailing aims to strengthen strategic partnership with AWS for global expansion. Finally, they concluded the panel discussion with a heartfelt message inviting engineers from diverse backgrounds to join them and grow the team. Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail

Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture on the theme of “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post reports on the contents of the lecture, following up on the previous post. The job titles are as of the day of event. The AWS Infrastructure Supporting Fast Retailing’s IT Shigeru Horikawa, Director, Infrastructure, Digital Business Transformation Services, Fast Retailing Co., Ltd. Mr. Horikawa from the Infrastructure team spoke about Fast Retailing’s history and the current status of AWS cloud utilization, as well as the ingenuity involved in operating a large-scale cloud environment with a small team. Fast Retailing needs to connect over 3,500 stores globally, support an ecommerce (EC) business in around 30 markets, and help sustain the entire supply chain, including warehouses and factories worldwide. To keep up with the rapid business expansion, instead of building data centers for each business, a cloud that can scale globally and procure infrastructure quickly became essential. A major reason for cloud adoption was the 2017 EC site downtime. Experiencing 3 days of downtime and facing issues like difficulty in on-premises capacity expansion and traffic control made them understand the need for cloud adoption. Fast Retailing’s cloud journey began around 2012 with the use of AWS for some campaign sites. In 2013, a cloud adoption project was launched in parallel with another initiative to modernize the existing legacy core systems. From 2016 to 2017, large-scale migration (lift & shift) from on-premises to cloud was carried out through the “Ariake Project” Around 2021, global expansion was accelerated further and AWS utilization expanded even more. The benefits of cloud adoption included: Scalability and capacity assurance: Easy scaling up and capacity expansion as needed Architecture modernization: Shift from legacy systems to modern architectures like microservices Securing engineers: Easier hiring of cloud engineers and improved acquisition of partners and developers Availability assurance: Establishment of cost-efficient backup sites across Availability Zones and regions for disaster recovery Infrastructure cost optimization: Adjust resources between peak and off-peak times to optimize infrastructure costs Current AWS usage includes over 60 accounts, 15+ regions, 13,000+ VMs, 3,000+ databases, and 120,000+ containers operated by a team of around 20 members. Various measures are taken to manage this large-scale infrastructure with a small team. Main initiatives include: Architecture reviews: Three review boards, Commerce, Enterprise, and CTO, review projects from planning to operational requirements and security from diverse perspectives Automation and codification: Adoption of Infrastructure as Code (IaC), cost management automation, standardized automated AWS account creation, etc. Self-service: Application teams can independently build, test, and deploy code with full responsibility on their part. Cost management: Visualize cost trends by system using tag-based cost allocation for application teams to manage costs with full responsibility on their part. Unified system monitoring platform: Consolidated disparate monitoring platforms so all the members can centrally view metrics and application behavior, reducing troubleshooting time Security measures: Leverage AWS security solutions for integrated multi-account security management. Aggregate security information into a security account integrated with a SIEM platform to enable early vulnerability detection and response Future initiatives include broader use of Kubernetes beyond ECS containers for more granular self-service parameter control, strengthening regional infrastructure teams to accelerate global expansion and achieve follow-the-sun operations, and building a global project promotion system. Through various measures like automation, self-service, and centralized monitoring, they have achieved large-scale cloud operations with a small team. Mr. Horikawa shared how companies accelerating global expansion can efficiently operate large-scale cloud environments using AWS. A Look Behind the Scenes of UNIQLO and GU’s E-Commerce Apps Shunsuke Akimoto, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Daisuke Sano, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, members of the Core Engineering team gave us a behind-the-scenes look at UNIQLO and GU’s e-commerce (EC) apps. First, Mr. Akimoto talked about a case of significant performance improvements and cost reductions in the cart function of the EC site. The cart function plays an important role when selecting and purchasing items on GU and UNIQLO apps and web services. The previous architecture had Application Load Balancer on top, with Amazon Elastic Container Service (Amazon ECS) below that, and the Amazon ECS API Service reading data from Amazon Aurora . However, with this configuration, the database became a bottleneck during traffic surges like popular item sales, causing response times to deteriorate significantly. There was also the issue that upgrading database instances increased costs, putting pressure on the infrastructure budget. To solve these issues, they decided to adopt Redis, a NoSQL database, as the main database. By using Amazon ElastiCache , they achieved major performance improvements while ensuring high scalability. The new architecture has the API Service directly reading and writing data to Amazon ElastiCache, with asynchronous data synchronization between Amazon ElastiCache and Amazon Aurora. This maximized the performance of Redis. Implementation ingenuity included creation of their own locking mechanism using Lua scripts and efficient extraction of updated carts using Redis Sorted Sets. Data migration was done with zero downtime, gradually migrating data to Redis while continuing operations. As a result, even with over double the traffic that previously caused issues, no performance degradation was observed. Response time improved significantly from over 10 seconds at p95 to 160ms, with potential for handling much larger traffic increases. Costs were also greatly reduced, with additional optimization through Amazon ElastiCache for Redis’ Data Tiering feature. Ultimately, database costs were reduced by over 60% with scalability assured for the next 10 years. They demonstrated how effectively leveraging cloud services can achieve both performance improvements and cost reductions simultaneously. Next, Mr. Sano talked about the search platform. Fast Retailing’s systems comprise interconnected microservices for each business function, with a data integration platform and API integration. The search platform is a microservice providing search functionality, utilizing inventory, pricing, product, and other information from other platforms. Main functions include keyword search, creating product lists for category pages, keyword suggestions, similar product listings, in-store inventory search, etc. Amazon OpenSearch Service is currently used by some platforms including the search platform. Three main features of Amazon OpenSearch Service are: Enabling registration of large amounts of data with flexible structures Enabling keyword search and flexible queries Fully managed service that easily scales in/out based on request volume Advantages of Amazon OpenSearch Service include high performance and scalability for read-heavy applications, and reducing development by having typical e-commerce search features built-in. Key requirements for global digital commerce search are efficiently supporting multiple brands, countries/regions, and language capabilities. These key requirements included: Functionality: Since building language-specific parsing in-house is difficult and inefficient, having built-in features like syntax analysis and normalization is important Ease of deployment: Adopting architecture where data automatically flows into Amazon OpenSearch Service Scalability: Easy scaling in/out Operability: Developing efficient tools for registering words and synonyms Future challenges include reducing operational costs of registering words and synonyms. Leveraging machine learning-based technologies (large language models, vector search, semantic search, etc.) are being considered to address future challenges. Other challenges are developing features to improve user experience beyond keyword search, and expanding to new regions in parallel with improving the search platform. Application Development Using Amazon ECS to Achieve Execution Control of Data Integration Infrastructure Kei Sakamoto, Integration Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Hirohito Yoshimoto, Integration Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, Mr. Sakamoto from the Integration Engineering Team introduced their data integration platform initiatives. The Integration Engineering Teams’ responsibilities include improving system development efficiency, as well as the development, management, and operational excellence of the data integration platform at Fast Retailing. As a digital consumer retailing company investing in end-to-end processes, data integration and batch processing became complex at large-scale. This required streamlining data, preparing tools for data utilization, and achieving high-speed processing to handle increasing data volumes after multi-brand launch and multinational expansion. They are addressing these challenges with two main concepts. First is preparing the batch processing framework, with a system that can control process dependencies and parallel distribution, organizing complex dependencies into more manageable forms. Second is preparing the data integration platform, building a cloud-native hub-and-spoke model platform to centrally manage all information and streamline data. Key features are easy routing control by definition, distributed deployment tailored to business domain characteristics, and covering various protocols and data formats. Four key requirements for this platform are: Stability: High stability required as it supports the business core Performance: Ability to plan for performance and capacity to withstand business fluctuations Portability: Easy distributed deployment Integration with diverse applications: Seamless integration with various applications Afterwards Mr. Yoshimoto introduced the specific architecture of the data integration platform, as well as challenges and ingenuity during development. The data integration platform is designed as a hub-and-spoke model system to efficiently integrate data between business domains, currently operating as 10 services across 2 clouds and 6 regions. Its development history began in 2015 as a batch processing platform, gradually expanding functionality to evolve into a data integration platform. Containerization and infrastructure codification were implemented in 2019, with enhanced multi-cloud support in 2021. Key considerations in development and operation include environmental reproducibility, scalability, ease of customization, cloud vendor independence, etc. Regarding task execution management using Amazon ECS, they independently implemented solutions to address issues like rate limits on API calls per time unit and difficulty with synchronous task status management. Specifically, the team wraps worker applications with a wrapper to operate as part of the overall framework, implementing a mechanism to synchronously grasp task status via heartbeats and callbacks. This avoids frequent polling queries to the ECS cluster for status checks, enabling more timely application execution monitoring and management. Three future challenges are: Further streamlining and self-service in deployment: Enabling business application teams to easily construct data integration mechanisms Enhancing integration with new services: Achieving stable integration with new digital reform services Promoting data utilization: Further integrating with data accumulation/analysis processes to create business value In closing, the speakers introduced how this initiative aimed to contribute to the business by consolidating complex data integration and batch processing, appropriately leveraging cloud services, and packaging as a solution. (To be continued in Part 3 ) Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail

Amazon Web Services Japan G.K. hosted Fast Retailing Co., Ltd. on July 24, 2024 for its 4.5 hour lecture titled “Engineers Weaving Fast Retailing’s Digital Transformation: A Global Challenge”. This blog post will report on the contents in three parts. The job titles are as of the day of event. Opening: Business transformation and digital initiatives at Fast Retailing Shimpei Otani, Group Executive Officer (CTO and CSO), Digital Business Transformation Services, Fast Retailing Co., Ltd. First, Mr. Otani explained Fast Retailing’s business concept and the “Ariake Project” aimed at digital transformation. Under the mission statement “Changing clothes. Changing conventional wisdom. Change the world.”, Fast Retailing operates 8 brands including UNIQLO, GU, PLST, Theory, COMPTOIR DES COTONNIERS, and PRINCESSE tam tam. With around 3,600 stores in about 30 countries and regions, it has grown into one of the world’s largest apparel retailers with 2.7 trillion yen (as of August 2023 period) in revenue. UNIQLO in particular leads overseas operations, accounting for 60% of revenue. Aiming to provide “LifeWear” as the ultimate everyday clothes to enrich everyone’s lives and delivering high-quality clothes at affordable prices is the company’s concept. Through “PEACE FOR ALL” initiatives, Fast Retailing also focuses on social contribution, donating profits from collaboration T-shirts with well-known personalities and companies wishing for peace for people affected by conflict and discrimination. As part of digital transformation efforts, Fast Retailing is promoting the Ariake Project. Its aim is to shift from a manufacturing retailer to a “digital consumer retailing company” transforming operations to deliver only what customers truly want. Based on the insights from customers—customer voices—the goal is to connect planning, manufacturing/logistics, and sales digitally to deliver the right products in the right amounts at the right time. Around 110,000 employees worldwide work as one team, leveraging data to accurately grasp customer needs and respond swiftly. By visualizing and optimizing the entire process from planning to sales with data, the aim is to eliminate waste while improving customer satisfaction and reducing costs. Engineers play the core role, and as the name Digital Business Transformation Services suggests, the focus is not just on IT but on transforming how work is done. Specific initiatives include introducing RFID-based self-checkout systems to enable seamless shopping experiences across stores and e-commerce. Fast Retailing is also promoting logistics automation and efficiency through introducing autonomous delivery robots, showing a wide range of software and hardware initiatives. The Ariake Project aims to maximize digital capabilities to achieve its business transformation and shift to a “digital consumer retailing company”, while adopting cutting-edge technologies. The goal is to build an optimal platform on AWS and realize value provision to customers through this large-scale challenge. Through digital transformation, Fast Retailing seeks to fulfill its mission of “Changing clothes. Changing conventional wisdom. Change the world.”. Evolution of In-house Development at Fast Retailing Yuichi Murata, Director, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, Mr. Murata from the Core Engineering team that promotes in-house development at Fast Retailing introduced the company’s history of digital transformation and efforts in their in-house development. The company has long recognized the importance of incorporating digital technologies into operations, beginning with the introduction of a POS system in 1988, and started digital processing of product and sales information in-house in the 1990s. In the 2000s, an online store was opened, leading advancements of various digital transformations such as operations by store staff using digital devices in the 2010s. With the Ariake Project, a company-wide reform project that started in 2016, in-house engineering was formally launched. Through these in-house development efforts, reforms such as RFID-based self-checkout and inventory management, and building an e-commerce platform for global expansion have been realized. The background for bringing development in-house includes the strategy to fully shift from a manufacturing retailer to an information retailer by leveraging information. To achieve this, it was necessary to build platforms in-house. In addition, with the mindset “business = systems” deeply understanding operations, building simple and clear complete systems, and constructing systems that align with the future direction were considered important. When promoting in-house development, the company started with e-commerce, gradually expanding functions by establishing a membership base, opening a catalog site, and enhancing online store capabilities. Beginning such mechanisms with the country where they have newly launched business operations and expanding scope to both Japan and global markets were also key approaches. The organization has hired global talent, adopted English as the main language, and taken various other steps to promote a global environment. A hybrid system has also been adopted where full-time employees and partner companies form single scrum teams. For engineer talent development, the focus is on strategically nurturing senior engineers who understand the business and can reflect their views onto technical decisions. Specifically, an architecture review board has been established for training in breaking down various business requirements into system designs. Rotating board members enables continuous talent development. Major achievements of in-house development include improved speed in resolving issues and gaining control over systems. Since the company built the systems itself, it’s easy to identify problem areas and respond swiftly. Being able to make important decisions quickly, such as technology selection and understanding business logic, has also been a major result. Challenges include bridging the original apparel retailer culture and IT engineering culture, Japanese and global cultures, and handling global scale. Going forward, with a goal of 10 trillion yen in annual revenue, the aim is to build the world’s top level global engineering organization from Japan. To achieve this, continuously developing senior engineers who understand the business and who can make technical decisions will be indispensable. The company aims to provide the most rewarding workplace in the world for engineers, offering valuable opportunities to take on world-class business challenges and fostering an environment where engineers can grow the most by overcoming difficulties. Microservices Platform Supporting Global Expansion, Store and EC Integration, and Business Growth to 10 Trillion Yen Revenue Xiao She, Manager, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Natsuki Inoue, Core Engineering, Digital Business Transformation Services, Fast Retailing Co., Ltd. Next, members of the Fast Retailing Core Engineering team introduced the microservices platform supporting global expansion, and initiatives to integrate e-commerce (EC) and brick-and-mortar stores. First, Mr. She gave an overview of past initiatives. Previously, different EC systems were used for each brand and region, resulting in high costs for function development and operations, as well as inefficiencies. Therefore, in 2017, renewal of EC was undertaken to provide one global EC solution worldwide. In 2020, the global EC package was released in Japan, followed by the US in 2021 and Korea in 2024. The new EC platform is unified not only in design but functionality as well. The basic policy for deploying the global EC platform is supporting multiple brands and accommodating different languages, payment methods, and legal systems in each country while achieving both global standardization and localization. Going forward, continuous rollout to regions across the world is planned in line with Fast Retailing’s business expansion. A key characteristic of Fast Retailing’s EC is integration with brick-and-mortar stores. In addition to common EC functions like purchase history, notifications, and chatbots, the system incorporates O2O (Online to Offline, Offline to Online) capabilities for integrating EC and brick-and-mortar stores. O2O services include: “store pickup” to have EC purchased items delivered to a store, “ORDER & PICK” to order inventory originally in a store via EC, and “store shipping” for direct shipping from store inventory to home. These realize benefits like free shipping, shorter delivery times, driving customers to stores, and optimizing warehouse capacity. Next, Mr. Inoue explained the system configuration and architecture of the EC platform. Fast Retailing develops and operates the EC system as a global platform, clearly separating front-end and back-end responsibilities. The back-end consists of microservices covering different business domains in a cross-brand manner, while front-ends are developed specifically for each brand. In terms of request flow, the structure is configured as follows: user device -> front-end client -> BFF (Backend for Frontend) -> back-end microservices. The BFF role is to aggregate data by calling multiple microservices and returning the response in a format convenient for the client. It also handles data caching and authentication/authorization. The back-end provides independent APIs as microservices covering specific business domains. For example, when a user purchases a product, microservices for shopping cart, product information, amount calculation, coupons, inventory, payment, order management, etc., receive the requests, execute the required logic, and return the results. The front-end consists of a responsive web SPA (Single Page Application) and native mobile apps. The SPA utilizes a common design system and internationalization to enable localization while maintaining unified architecture. Mobile apps also use some native Android/iOS code while building a common codebase with Flutter. As a tech stack, standardization is emphasized across infrastructure, middleware, programming languages, and frameworks. Go, Java, Spring Boot, Node.js, TypeScript etc. are adopted for back-end, while React for front-end, and Kotlin and Swift for mobile. Going forward, global expansion will be accelerated. Rollout will be gradual while addressing various requirements like local languages, payment methods, logistics, and regulations. To achieve the goal of 10 trillion yen annual revenue, handling increased traffic is an issue. Efforts will focus on end-to-end performance measurement and improvement to ensure scalability. O2O initiatives integrating EC and stores are also important. The goal is to enable purchasing desired products anytime, anywhere through seamless linkage between stores and EC. Convenience for customers will be pursued by advancing systems and leveraging the strength of the store network. (To be continued in Part 2 ) Original blog writers from AWS Japan: Mariko Anan, SA, Retail Yuto Miyoshi, SA, Retail

AWS は、2024 年 11 月 13 日 ( 水 ) 〜 2024 年 11 月 15 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2024 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4203 )。 AWS 展示ブースでは、「Create. Deliver. Monetize.」をテーマに、メディア制作から視聴者へ届けるまでのエンドツーエンドにおける 5 つのワークロード『生成 AI』『Direct to Consumer & ストリーミング』『コンテンツ制作』『 放送 – ライブクラウドプロダクション』『放送 – クラウドプレイアウト』の各分野において、他の AWS のサービスやサードパーティーのアプリケーションと組み合わせ、高度にスケーラブルで伸縮自在かつセキュアなクラウドメディアソリューションを実演してご紹介します。 本ブログでは、AWS 展示の概要をブースセミナーでの展示紹介セッションと共にご紹介します。 AWS 展示コーナーの概要 展示ブースは、5つのソリューションエリアで構成されています。『生成 AI』『 放送 – ライブクラウドプロダクション』『放送 – クラウドプレイアウト』の3つは、 INTER BEE AWARD ノミネート作品です。 生成 AI このブースでは、AWS の生成 AI ソリューションでメディアと AI の融合を体感できます。例えば、 動画のメタデータ生成・抽出、要約・検索 、 シーン切り出し 、 スポーツデータ強化 、 ニュース自動要約・検索 、 動画セマンティック検索 、 広告自動生成 など、 AI が映像コンテンツを理解し新しい価値を生み出す先進的な機能をご覧いただくことができます。 展示するソリューションはカスタマイズが容易で、映像の検索や検索拡張生成（RAG）、コンテキスト広告や Shoppable Video の生成などの際にこのワークフローを活用することが可能です。なお、メタデータ等の保存と管理には、容量無制限で柔軟性の高いクラウドストレージの Amazon S3 と高い検索性を有する複数の目的別データベースを使用しています。 Direct to Consumer & ストリーミング このブースでは、クラウドの柔軟性と拡張性を生かした先進的な映像配信の実例を紹介します。デジタル時代のオンデマンドメディアに対応する、 オンデマンド配信 、 ライブ配信 、 パーソナライズド配信 、 動的広告挿入 などの機能を実演します。 例えば上の図は、メディアプレーヤーのリアルタイムログを収集/可視化するシステムのアーキテクチャ図です。OTT サービス事業者や消費者向けサービス事業者は、タイムリーな監視データを使った分析を行う必要があり、本ブースでは Amazon CloudFront のリアルタイムログや Amazon QuickSight を組み合わせてこれを実現しています。また、 Amazon Q を使った Generative BI 機能により、 自然言語による実践的なデータの洞察も可能です。 コンテンツ制作 このブースでは、AWS を活用した スケーラブルなコンテンツ制作環境 や クラウドレンダリング をご紹介します。 AWS Deadline Cloud の簡単なセットアップや CG のクラウドレンダリングのデモ、また Amazon DCV 経由のクラウドワークステーションでのコンテンツ制作ツールの使用感、Wacom Bridge を組み合わせたタブレットの操作感などを体験いただけます。 AWS Deadline Cloud は、カンタンな構築とコスト監視、柔軟な拡張性が特徴の新しいクラウドレンダリングのサービスです。このサービスを利用することで、大規模なクラウドレンダリングを従来の煩雑な管理を大幅に低減しながら実行できるようになるので、クリエイティブな作業に注力することができます。また本デモは、ブースに設置の NetApp ONTAP FlexCache とクラウドストレージの Amazon FSx for NetApp ONTAP を併用したハイブリッドストレージ構成となっており、高頻度データアクセスの高速化やネットワーク負荷の低減効果によって、オンプレミスのスタジオとクラウドをつないだ柔軟な制作環境を提供しています。 放送 – ライブクラウドプロダクション ライブクラウドプロダクションのブースでは、多種多様な映像伝送プロトコルを集約し、さまざまなソリューションを組み合わせてニュースのライブ映像を制作可能なワークフローを展示します。入力信号の1つには、AWS Elemental MediaLive の機能を持ち管理にクラウドを利用しながらも、オンプレミスでライブ動画エンコードを実行できる AWS Elemental MediaLive Anywhere を利用しており、稼働している実機を見ることもできます。 NRCS（Newsroom Compute System）のソリューションを組み合わせることで、 ニュース項目の生成や更新を効率的に実施する運用 や、映像信号のモニタリング環境も同時に展示します。 本ブースはまさに、 放送局の「回線センター」や「報道サブ」で必要な機能をクラウド上で実現した展示 となります。 本展示は、AP、Aximmetry Technologies、LiveU、Sony、Vizrt、Waves Audioなどの専門的なパートナーソリューションや複数のオープンソース、AWSのマネージドサービスを組み合わせて実現しています。また、各映像ソースの信号出力経路、コーデック、パフォーマンス等をリアルタイムに可視化するダッシュボードの展示も行なっています。 放送 – クラウドプレイアウト ユニゾンシステムズ、 Amagi、Ateme などの専門的なパートナーソリューションを組み合わせることで、営放システムと連携したクラウドプレイアウトシステムを展示します。クラウドを用いることで柔軟で効率的なワークフローを構築することができるため、急速な技術の進化に対応することが可能です。 オンプレミス上のマスターシステムを、多様な機能を持つこのクラウドプレイアウトシステムに移行することで、システムの柔軟性と効率性を向上させることが可能となります。また、地理的な場所に関係なく放送配信運行ができたり、さまざまなデータをダッシュボード上に可視化することも可能となっています。 終わりに 今回は、Inter BEE 2024 の AWS 展示についてご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2024 の 公式サイト からご確認ください。 また、AWS ブースセミナーや出展者セミナー、 AWS スポンサー展示等に関する情報は、下記のブログからもご確認いただけます。皆様にお会いできるのを楽しみにしています。 AWS ブースセミナー、出展者セミナーの概要については こちら AWS スポンサー展示、AWS ブースツアーの概要については こちら まとめ 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 小南英司が担当しました。

AWS は、2024 年 11 月 13 日 ( 水 ) 〜 2024 年 11 月 15 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2024 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4203 )。 AWS 展示ブースでは、「Create. Deliver. Monetize.」をテーマに、メディア制作から視聴者へ届けるまでのエンドツーエンドにおける 5 つのワークロード『生成 AI』『Direct to Consumer & ストリーミング』『コンテンツ制作』『 放送 – ライブクラウドプロダクション』『放送 – クラウドプレイアウト』の各分野において、他の AWS のサービスやサードパーティーのアプリケーションと組み合わせ、高度にスケーラブルで伸縮自在かつセキュアなクラウドメディアソリューションを実演してご紹介します。 本ブログでは、AWS スポンサー展示の概要を中心にご紹介します。 AWS スポンサー展示コーナーの概要 AWS ブースでは、AWS を利用したメディアソリューションをパートナー 12 社とともにご紹介します。 スポンサー各社の展示概要: 1: ATEME ATEME ( アテメ ) が提供する、集信、3D 映像にも対応した各種エンコード、OTT、DAI から CDN までエンドツーエンドで対応した多機能集配信ソリューションを展示します。オンプレ、クラウドなど、プラットフォームに依存せずに使用できます。 2: 株式会社フォトロン スポーツコンテンツのクラウド上の制作に必要な、 映像の入出力、それらの収録と編集システムをパッケージでサービス提供します。規模のスケール、監視 などオペレーションを含めた総合的な環境をご用意します。 3: Evergent Technologies, Inc. Evergent マネタイズプラットフォームは、最新の技術と AI により、迅速な新規獲得、より良いエンゲージメント、より長いリテンションを実現します。AI を活用し最適な顧客体験を届け、解約率低減、売上最大化を可能にします。 4: 株式会社トラフィック・シム クラウドマスターでご活用いただけるマルチビュー / 同録 / アナライズや電流モニタリングなど、「難しいをひも解く」トラフィック・シムのクラウドサービスを展示します。 5: ソニーマーケティング株式会社 SaaS 型クラウドスイッチャー M2 Live をご紹介します。AI による映像解析サービス A2 Production では業務の DX 化をご提案します。 6: Amagi Amagi は、クラウド放送と広告ソリューションを提供する企業で、世界 150 カ国でコンテンツの配信・収益化をサポートし、24 時間 365 日の管理サービスを展開しています。 7: 株式会社 PLAY 動画や画像、字幕などのファイルや、配信プラットフォームへの入稿までを一括管理できる「KRONOSDRIVE」を展示し、ブラウザ上での動画や字幕の編集、AI を活用した機能などをご紹介します。 8: BytePlus Pte. Ltd. BytePlus Recommend による AutoML や Deep Retrieval など高度な機械学習技術を活用した業界でも定評あるレコメンデーション技術をご紹介します。様々なインサイトを活用し、顧客エンゲージメントを高めユーザー満足度を大きく向上させるソリューションやデモをご覧ください。 9: Datadog Japan 合同会社 世界中の動画配信事業者の皆様から支持されている、AWS でホストされたインフラとアプリケーション環境に統合的なオブザーバビリティとセキュリティを提供する Datadog の機能についてデモを交えてご紹介します。 10: New Relic 株式会社 放送業界の IT システムは、安定稼働だけでなく、顧客体験の向上や迅速な開発など様々な要件が求められます。高度な監視機能によって要件に応えるソリューションを、実ユーザーの活用事例に基づくデモを交えてご紹介します。 11: 株式会社ユニゾンシステムズ 営放システム（編成、営業、CM、放送）のクラウド化と、考査、番組入稿などの開発事例展示。クラウドで共通化されたメディアワークフローと、AI の活用事例についてご紹介します。 12: イノテック株式会社 ワークフローの自動化・省力化・マネタイズに貢献する最先端の海外ソフトウェア＆サービスをご紹介！ # AI 吹き替え # 自動字幕生成 # ファイル QC # リアルタイム配信品質監視 # 視聴動向分析 # リモート編集 # DAI AWS プレゼンテーションステージについて ブース内ミニステージでは、AWS スポンサーおよび AWS によるプレゼンテーションをはじめ、お客様から現場運用でのクラウド活用について発表いただく予定です。各セッションのスケジュールについては以下を参照いただき、是非ご参加ください。 (登録不要) AWS ブースツアーについて AWS 展示ブースにお越しの皆様に AWS クラウドの活用シーンを深くご理解いただくべく、AWS スポンサーのサービスをはじめ AWS 各展示の見どころをご紹介するツアーを行います。 日付: 2024 年 11 月 13 日（水）、14 日（木）、15 日（金） 時間: 11:00 / 14:00 / 16:00 (各回所要時間約 45 分間を予定) 定員: 各会 12 名まで (登録制) 各回、以下のいずれかのテーマでツアーをご提供しますので、ご興味のある回およびご都合のよろしい時間を選んで お申し込み ください。 Create : コンテンツプロダクション、ライブプロダクションを巡るツアー Monetize : 生成 AI や分析システムを生かしたマネタイズソリューションを巡るツアー Deliver : コンテンツ配信・クラウドプレイアウトのソリューションを巡るツアー 是非 こちら よりご応募ください。 終わりに 今回は、Inter BEE 2024 の AWS スポンサーをご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2024 の 公式サイト からご確認ください。 また、AWSブース展示や、ブースセミナー、出展者セミナーに関する情報は下記のブログからもご確認いただけます。 AWS ブース展示の概要については こちら AWS ブースセミナー、出展者セミナーの概要については こちら 皆様にお会いできるのを楽しみにしています！ 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 石井 悠太が担当しました。

AWS は、2024 年 11 月 13 日 ( 水 ) 〜 2024 年 11 月 15 日 ( 金 ) にわたって幕張メッセで開催される Inter BEE 2024 に出展します。 ( 幕張メッセ 展示ホール 4 小間番号：4203 )。 AWS 展示ブースではブースセミナーが開催され、「Create. Deliver. Monetize.」をテーマに、メディア & エンターテインメント業界の客様講演を予定しております。また、幕張メッセ国際会議場では「コンテンツ制作・配信・収益化の最前線 ～ AWS クラウドで実現するイノベーション事例」と題し、メディア & エンターテインメント業界向けの最新動向、及びお客様事例登壇の登録制セミナーを予定しております。 本ブログでは、AWS ブースセミナー、AWS 出展者セミナーのご紹介をします。 AWS ブースセミナーの概要 AWSブース内ミニステージではお客様講演をはじめ、AWS スポンサーおよび AWS によるプレゼンテーションを予定しております。各セッションのスケジュールについては以下を参照いただき、是非ご参加ください。 (登録不要) 次にお客様講演の概要を記します。 日本テレビ放送網株式会社：テレビ番組 画像生成 AI で「遊べる」web 開発 日本テレビ様の音楽番組「バズリズム 02」ではバカリズムがゲストとのトークを受けてイラストを描いており、その数は約400 点に上ります。この講演では、そのイラストを独自に学習させたモデルを活用した生成 AI の Web サービス開発の取り組みを紹介いただきます。安定したクオリティの確保、ユーザーにストレスない低遅延な画像生成、コンプライアンス面でセキュアなサービス提供といった特有の課題を解決されてゆきました。 株式会社 TBS テレビ：TBS テレビで広がる生成 AI / LLM の活用と未来展望 後日、更新致します。 株式会社 NTT ドコモ：AWS メディアサービスとマルチ CDN を活用した数百万同時視聴ライブの実現方法 NTT ドコモ様において、映像配信サービス『Lemino』の開始にあわせて配信基盤を再構築し、数百万規模の同時視聴ライブ配信を実現した取り組みについて、AWS メディアサービスとCDNを中心にお伝いただきます。スケーラブルなAWS サービスを活用し通常ライブの運用と変わらずに大規模ライブ配信を実現した内容など、ライブ配信を検討している全ての方に参考となる内容です。 株式会社 AbemaTV：ABEMA のニュースコンテンツ制作における生成 AI 活用事例 ABEMA様 では、ニュースの配信ビジネスにおいて、インターネットを活用したマーケティング施策の強化に取り組んでおり、AI を含む最新技術の導入を進めています。本セッションでは、ABEMA TIMES を代表とするニュースオウンドメディアにおける AI 活用戦略を、具体的な事例とともにご紹介いただきます。 AWS 出展社セミナーの概要（2024年 11月 14日 12:00 – 13:30） 幕張メッセ国際会議場 1F「103」において「コンテンツ制作・配信・収益化の最前線 ～ AWS クラウドで実現するイノベーション事例」と題し、3 社のお客様より先進的な具体事例のご紹介、及び AWS から最新ソリューションのご紹介をします。AWS 出展社セミナーの聴講には InterBEE 公式サイトからの お申込み が必要となります。 講演概要は下記の通りとなります（以下、講演順）。 Amazon Web Services, Inc. / アマゾン ウェブ サービス ジャパン合同会社 テレビ局・動画配信・制作・コンテンツプロバイダーなどのメディア・エンターテイメント企業は、変化の激しい市場環境の中、既存の仕組みにとらわれないビジネス改革が求められています。本セッションでは「Create. Deliver. Monetize.」をテーマに AWS から最新のソリューションをご紹介します。 株式会社フジテレビジョン：大規模国際スポーツイベントにおけるクラウド制作 PoC について フジテレビ様は今回フランス・パリにて行われた大規模国際スポーツイベント環境の中でクラウド制作 PoC を行いました。海外での大型中継における現地制作環境と同様の環境を、AWS クラウド上に構築し、プログラム制作から中継まで、全てをクラウド上にて行う事を本 PoC の一つの目標とされました。クラウド制作環境の構成から、クラウド化によるメリット／デメリット、今後の課題と展望についてご紹介いただきます。 株式会社 NHK テクノロジーズ：SRT を用いたスポーツ大会中継の配信 NHK テクノロジーズ様は AWS を活用し、国際スポーツ大会の海外中継を SRT プロトコルで行いました。「AWS Elemental MediaConnect」を用いて低遅延・高品質な配信を行い、東京リージョンから各地域へAWS内のネットワークを経由し配信することで、安定性とコスト効率を両立されました。映像制作と伝送の一気通貫に弊社で対応することで、放送技術と IT 融合の事例をご紹介いただきます。 日本テレビ放送網株式会社：テレビ広告を進化させる Ad Reach Max (アドリーチマックス)プラットフォーム 内製化開発の取り組みと課題 Ad Reach MAX はアドテクノロジー、新技術の活用によりテレビ広告の概念を一新します。リードタイムが大幅に短縮され放送当日の直前までの発注・クリエイティブ変更が可能で全てがウェブ上で完結される本プラットフォームは内製で作られております。本セッションでは Ad Reach MAX が描く将来像、スケーラブルでサーバレスな内部構成実現にむけた内製エンジニア達の実体像を紹介いただきます。 終わりに 今回は、Inter BEE 2024 の AWS ブースセミナー、出展者セミナーについてご紹介させていただきました。基調講演や特別講演、会社ごとのブースに関する情報は Inter BEE 2024 の 公式サイト からご確認ください。 また、AWSブース展示やAWSスポンサー展示等に関する情報は下記のブログからもご確認いただけます。皆様にお会いできるのを楽しみにしています。 AWS ブース展示の概要については こちら AWS スポンサー展示、AWS ブースツアーの概要については こちら 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメールマガジンをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 この記事は SA 金目 健二が担当しました。

この記事は Secure Cross-Cluster Communication in EKS with VPC Lattice and Pod Identity IAM Session Tags (記事公開日: 2024 年 9 月 18 日) を翻訳したものです。 ソリューション概要 アプリケーションを開発し、内部向けに API エンドポイントを公開したい場合は、 AWS Lambda 、 Amazon Elastic Container Service(ECS) 、 Amazon Elastic Kubernetes Service(Amazon EKS) などのさまざまなコンピューティングオプションを使用して、マイクロサービスを構築できます。そして、アプリケーションを複数の AWS アカウントと複数の Amazon Virtual Private Cloud(VPC) にまたがってデプロイできますが、それらをセキュアに接続する方法が必要です。 Amazon VPC Lattice はアカウント間の East-West トラフィック通信を可能にし、サービスディスカバリ・トラフィック管理・アクセス制御といった機能を提供します。Amazon EKS で取り組む場合、Amazon VPC Lattice には Kubernetes Gateway API を実装した AWS Gateway API Controller を利用します。 このアーキテクチャ全体のトラフィックは、通信の暗号化により保護できます。また、Amazon VPC Lattice の各 Service できめ細やかな AWS Identity and Access Management(IAM) による認可を有効にできます。暗号化のためには、プライベートドメインを管理する AWS Private Certificate Authority(CA) と、各サービスの証明書を作成する AWS Certificate Manager(ACM) を利用できます。認可のためには、Amazon VPC Lattice の IAM 認証ポリシー機能と、クラスター管理者が Kubernetes アプリケーションを設定して IAM アクセス許可を取得する方法をシンプルに実現する EKS Pod Identity を利用できます。これらのアクセス許可は、Amazon EKS コンソール、API、CLI を通じて、より少ないステップで直接設定できるようになりました。EKS Pod Identity を使用すると、IAM ロールを複数のクラスター間で再利用でき、ポリシー管理がシンプルになります。 以下の API を使用して、IAM ロールをPod の ServiceAccount に関連付けることができます。 aws eks create-pod-identity-association \ --cluster-name $CLUSTER_NAME \ --namespace $NAMESPACE \ --service-account $SERVICE_ACCOUNT \ --role-arn arn:aws:iam:: $AWS_ACCOUNT :role/ $POD_ROLE_NAME Bash Amazon EKS が使用できるようにするため、IAM ロール $POD_ROLE_NAME には、以下の信頼ポリシーが必要です。 { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Principal" : { "Service" : "pods.eks.amazonaws.com" } , "Action" : [ "sts:AssumeRole" , "sts:TagSession" ] } ] } Bash EKS Pod Identity が IAM ロールを引き受けると、IAM セッションにセッションタグを設定します。 これらのタグには、 eks-cluster-name 、 kubernetes-namespace 、 kubernetes-pod-name などの情報が含まれており、属性ベースのアクセス制御 (ABAC) に使用できます。 ABAC を使用すると、特定の Kubernetes Pod や、特定の EKS クラスター内の特定の Namespace 内からのみ、AWS リソースへのアクセスを許可できます。 この機能は、IAM 認証を有効にした場合に Amazon VPC Lattice サービスにアクセスするときにも使用でき、Amazon EKS 内または異なる EKS クラスター間のマイクロサービスに対して直接的かつ豊富なアクセス制御の仕組みを提供します。 Amazon VPC Lattice サービスにアクセスするために、 IAM 認証ポリシー を有効にした場合、アプリケーションのリクエストは AWS Sigv4 アルゴリズム (またはクロスリージョンの場合は Sigv4A )で署名する必要があります。これは、他の AWS サービスで使用されているのと同じ機能です。 アプリケーションコード内の AWS SDK を使用してリクエスト署名を実装できます( サンプル を参照)。これは推奨される方法ですが、アプリケーションコードを変更する必要があります。そこで、私たちは別のソリューションを提案します。関連する Amazon EKS Blueprints パターンは、アプリケーションコードを変更せず、サイドカープロキシを使用する異なるアプローチを示しています。 このプロキシは、Amazon VPC Lattice サービスをターゲットとするリクエストの Sigv4 署名を自動的に処理します。 Kubernetes クラスター内から AWS サービスとのシームレスな統合を可能にする、EKS Pod Identity と AWS Sigv4 署名機能をサポートする、幅広く採用されているプロキシとして、 Envoy を使用します。 さらに、Pod 間通信の暗号化のために、Amazon VPC Lattice サービスを HTTPS リスナーで設定できます。 アプリケーションコンテナが HTTPS リクエストの TLS 暗号化をサポートできない場合は、Sigv4 署名とともにこれを Envoy サイドカープロキシにオフロードできます。このセットアップでは、HTTPS として設定された Amazon VPC Lattice サービスへの HTTP リクエストをアプリケーションが生成し、リクエストは Envoy サイドカープロキシにルーティングされ、Envoy はクライアントとして Amazon VPC Lattice に署名された HTTPS リクエストを発行します。 アプリケーションが Amazon VPC Lattice サービスへの HTTP リクエストを行うと、リクエストは自動的にローカルの iptables ルールで Envoy サイドカーにルーティングされます。 そこから、Envoy はこのリクエストの Sigv4 署名を作成し、HTTPS で Amazon VPC Lattice にリクエストを転送します。また ACM によって発行されたプライベートドメイン証明書を検証するために、AWS Private CA を利用します。 プロキシの利用を簡単にするために、このパターンは Deployment の Annotations に依存しています。これにより、 Kyverno クラスターポリシーがトリガーされ、アプリケーション Pod 内に Envoy サイドカープロキシが自動的に注入されます。 ウォークスルー このソリューションは、 EKS Blueprints for Terraform に依存しています。EKS Blueprints は、Amazon EKS やその他の AWS サービスの具体的な使用法を示すパターンのコレクションです。ここでは、 network/cross-cluster-pod-communication を使用します。 このパターンは、以下の図にも示すように、3 つの Terraform スタックに分割されています。 1. 次の 2 つのスタックは、クラスターディレクトリの同じ Terraform コードを使用してデプロイされます。 Terraform の workspace 機能を使用して、クラスタースタックを 2 回インスタンス化し、2 つの EKS クラスター (cluster1 と cluster2) を作成します。 Amazon Route 53 のプライベートホストゾーンである example.com を、ダミーのプライベート VPC (プライベートホストゾーンを持つためだけにこの段階で作成) にアタッチします。 プライベートドメインを管理する AWS Private CA から、後ほど Amazon VPC Lattice サービスにアタッチするワイルドカードの ACM 証明書を作成します。 EKS Pod Identity によってアプリケーションで使用する IAM ロールも作成します。このロールは Amazon VPC Lattice サービスを呼び出す権限と、アプリケーションがプライベートドメインを信頼できるように AWS Private CA のルート証明書をダウンロードする権限を持っています。 2. 次の 2 つのスタックは、クラスターディレクトリの同じ Terraform コードを使用してデプロイされます。 Terraform の workspace 機能を使用して、クラスタースタックを 2 回インスタンス化し、2 つの EKS クラスター (cluster1 と cluster2) を作成します。 まず、スタックは専用 VPC (正確に同じ設定なのでオーバーラップする CIDR を持つ) を作成します。 そして、スタックは専用のマネージドノードグループを用いて EKS クラスターを作成します。 次に、いくつかの Amazon EKS と Kubernetes のアドオンをインストールします。 HTTPRoute および IAMAuthPolicy の定義から Amazon VPC Lattice オブジェクトの作成を管理するGateway API Controller カスタムドメイン名を含む HTTPRoute オブジェクトに基づいて、Route53 プライベートホストゾーンにレコードを作成する責務を持つ ExternalDNS そして最後に、アプリケーション Pod 内に Envoy プロキシを注入する責務を持つ Kyverno をデプロイします 次に、2 つの Helm チャートをインストールします。1 つ目のplatform という名前のチャートは、Amazon VPC Latticeサービスネットワークを作成する GatewayClass およびGateway オブジェクトを作成し、アプリケーションに Envoy プロキシを注入するために使用される Kyverno クラスターポリシーを作成します。2 つ目の Helm チャートである demo は、以下の図に示すように、最初のクラスターでは demo-cluster1、2 つ目のクラスタでは demo-cluster2 と名付けられたデモ用のアプリケーションをデプロイします。 Gateway API Controller が platform Helm チャートから作成された Gateway オブジェクトを検知すると、VPC と VPC Lattice サービスネットワークの間に VPC との関連付けを作成します。VPC との関連付けには、サービスネットワークへのインバウンドリクエストを許可する VPC 内の対象を定義するセキュリティグループを含めることができます。さまざまな条件を用いて、ネットワークを利用できる対象を制限することができます。たとえば、VPC 識別子によって制限することもできます。 単純化のため、このパターンは同じ AWS アカウントに閉じていますが、Amazon VPC Lattice は AWS Resource Access Manager(AWS RAM) を用いることで、クロスアカウントで使用できます。 Amazon VPC Lattice ターゲットグループのヘルスチェックは、Amazon VPC Lattice サービスからリクエストされます。Amazon VPC Lattice には、Terraform の定義によって EKS クラスターのセキュリティグループで許可する必要がある、特定の マネージドプレフィックスリスト があります。Amazon EKS アプリケーションがサービスネットワークに接続する必要がある場合は、適切なポートでノードグループのセキュリティグループからのインバウンドトラフィックを許可するために、VPC への関連付けのセキュリティグループも更新する必要があります。こちらについても Terraform で設定されます。 デモ用の Helm チャートは、デモサービスの定義を含むHTTPRoute オブジェクトを作成し、 カスタムドメイン名 を使用します。 apiVersion: gateway.networking.k8s.io/v1beta1 kind: HTTPRoute metadata: name: demo-cluster2 namespace: apps spec: hostnames: - demo-cluster2.example.com parentRefs: - group: gateway.networking.k8s.io kind: Gateway name: lattice-gateway namespace: lattice-gateway sectionName: http-listener - group: gateway.networking.k8s.io kind: Gateway name: lattice-gateway namespace: lattice-gateway sectionName: https-listener-with-custom-domain rules: - backendRefs: - group: "" kind: Service name: demo-cluster2-v1 port: 80 weight: 1 matches: - path: type: PathPrefix value: / Bash Gateway API Controller は、関連する Amazon VPC Lattice リソース (サービス、リスナー、ターゲットグループ) を作成します。 このデプロイでは、各リスナー上の各サービスに対して TLS 終端を有効にします。これにより、トラフィックは各サービスに定義されたルートを尊重して、関連するターゲットグループに転送されます。 ターゲットグループは IP タイプとして設定されており、直接ターゲットとなる Kubernetes Service に関連づけられた Pod に転送します。 Amazon VPC Lattice サービスは、異なるクラスターから、ターゲットに対するリクエストを分散するように設定できます。 カスタムドメイン名を定義したため、Gateway API Controller は Kubernetes の DNSEndpoint オブジェクトも作成します。 kind: DNSEndpoint metadata: name: demo-cluster1-dns namespace: apps ownerReferences: - apiVersion: gateway.networking.k8s.io/v1beta1 blockOwnerDeletion: true controller: true kind: HTTPRoute name: app4 spec: endpoints: - dnsName: demo-cluster1.example.com recordTTL: 300 recordType: CNAME targets: - demo-cluster1-apps-082dc3111b7018633.7d67968.vpc-lattice-svcs.eu-west-1.on.aws status: observedGeneration: 1 Bash ExternalDNS は CRD による拡張を用いて、このオブジェクトを監視します。 以下を設定することで、ExternalDNS が DNSEndpoint カスタムリソース定義から読み取れるように構成します。 --source=crd --crd-source-apiversion=externaldns.k8s.io/v1alpha1 --crd-source-kind=DNSEndpoint API Gateway HTTPRoute をカスタムドメインを指定して作成すると、Amazon VPC Lattice はそのエントリの DNS エンドポイントを作成します。 この設定により、ExternalDNS はプライベートホストゾーンに専用の Route53 CNAME レコードを作成できるため、カスタムドメイン名からのトラフィックを Amazon VPC Lattice サービスのエンドポイントにルーティングできます。 これにより、内部サービスは内部ドメイン名を使用して検出およびアクセスできます。 Kubernetes Gateway オブジェクトには、Amazon VPC Lattice がリクエストの TLS セッションを終了するために使用する ACM 証明書の Amazon リソースネーム (ARN) も含まれています。 デモ用の Helm チャートは、HTTPRoute に関連付けられたIAMAuthPolicy オブジェクトもデプロイします。これは、各リクエストに Sigv4 アルゴリズムでの署名が必要であることと、demo-cluster2 のアプリケーションの場合、cluster1 EKS クラスターの apps Namespace からのリクエストのみが許可される ABAC ルールを定義しています。そして、demo-cluster1 のアプリケーションの場合は、cluster2 EKSクラスターの apps Namespace からのリクエストのみを受け入れます。 Amazon VPC Lattice サービスへのすべてのリクエストをログに記録するために、アクセスログのサブスクリプションを設定することもできます。ログは Amazon CloudWatch のロググループに記録されます。 デプロイ 関連する EKS Blueprints のパターンにあるデプロイ手順に従うことができます。 簡単なセットアップとして、以下のコマンドで実行できます。 # Clone EKS Blueprint repository git clone https://github.com/aws-ia/terraform-aws-eks-blueprints.git cd patterns/vpc-lattice/cross-cluster-pod-communication # Deploy the environment cd environment terraform init terraform apply --auto-approve # Deploy cluster 1 cd .. /cluster ./deploy.sh cluster1 eval ` terraform output -raw configure_kubectl ` # Deploy cluster 2 cd .. /cluster ./deploy.sh cluster2 eval ` terraform output -raw configure_kubectl ` Bash 3 つのスタックが正常にデプロイされると、クラスター間通信が意図したとおりに機能していることを検証するために、次のコマンドを実行できます。 これを実現するために、Pod 内に exec して HTTP でサービスをターゲットにする cURL コマンドを実行します。すでに説明したように、リクエストは HTTP で Envoy サイドカーにルーティングされ、AWS Private CA 証明書を使用して HTTPS で署名され転送されます。 1. cluster1 の app1 から、cluster2 の app2 を呼び出す→ 成功 $ kubectl --context eks-cluster1 exec -ti -n apps deployments/demo-cluster1-v1 \ -c demo-cluster1-v1 -- curl demo-cluster2.example.com Requesting to Pod ( demo-cluster2-v1-c99c7bb69-2gm5f ) : Hello from demo-cluster2-v1 Bash 2. cluster2 の app2 から、cluster1 の app1 を呼び出す → 成功 $ kubectl --context eks-cluster2 exec -ti -n apps deployments/demo-cluster2-v1 \ -c demo-cluster2-v1 -- curl demo-cluster1.example.com Requesting to Pod ( demo-cluster1-v1-6d7558f5b4-zk5cg ) : Hello from demo-cluster1-v1 Bash 前のコマンドのように認証フローを使用しない場合、Amazon VPC Lattice が未認証のリクエストを拒否することがわかります。 3. cluster1 app1 から、cluster1 app1 を呼び出し → 禁止 $ kubectl --context eks-cluster1 exec -ti -n apps deployments/demo-cluster1-v1 \ -c demo-cluster1-v1 -- curl demo-cluster1.example.com AccessDeniedException: User: arn:aws:sts::12345678910:assumed-role/vpc-lattice-sigv4-client/eks-eks-cluste-demo-clust-1b575f8d-fb77-486a-8a13-af5a2a0f78ae is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:eu-west-1:12345678910:service/svc-002349360ddc5a463/ because no service-based policy allows the vpc-lattice-svcs:Invoke action Bash 4. cluster2 app2 から、cluster2 app2 を呼び出し → 禁止 $ kubectl --context eks-cluster2 exec -ti -n apps deployments/demo-cluster2-v1 \ -c demo-cluster2-v1 -- curl demo-cluster2.example.com AccessDeniedException: User: arn:aws:sts::12345678910:assumed-role/vpc-lattice-sigv4-client/eks-eks-cluste-demo-clust-a5c2432b-b84a-492f-8cbc-16f1fa5053eb is not authorized to perform: vpc-lattice-svcs:Invoke on resource: arn:aws:vpc-lattice:eu-west-1:12345678910:service/svc-00b57f32ed0a7b7c3/ because no service-based policy allows the vpc-lattice-svcs:Invoke action Bash demo-cluster1 アプリケーションで IAMAuthPolicy がどのように定義されているかを確認できます。 kubectl --context eks-cluster1 get IAMAuthPolicy -n apps demo-cluster1-iam-auth-policy -o json | jq ".spec.policy | fromjson" { "Version" : "2012-10-17" , "Statement" : [ { "Effect" : "Allow" , "Principal" : { "AWS" : "arn:aws:iam::12345678910:root" } , "Action" : "vpc-lattice-svcs:Invoke" , "Resource" : "*" , "Condition" : { "StringEquals" : { "aws:PrincipalTag/eks-cluster-name" : "eks-cluster2" , "aws:PrincipalTag/kubernetes-namespace" : "apps" } } } ] } Bash eks-cluster2 クラスターから apps Namespace に発信されるリクエストのみが許可されていることを確認できます。 クリーンアップ 将来的な課金を回避するために、EKS Blueprints パターンのクリーンアップセクションに従ってリソースを削除するか、次のスニペットを実行してください。 cluster2 Terraform スタックを削除することから始めます。 Kubernetes のコントローラーが、別のコントローラーや Kubernetes Node を削除する前に、外部リソースをクリーンアップできるよう、順番に処理する必要があることに注意してください。 ./destroy.sh cluster2 次に、cluster1 の Terraform スタックを削除できます。 ./destroy.sh cluster1 最後に、environment Terraform スタックを削除します。 cd ../environment terraform destroy -auto-approve まとめ このソリューションでは、Amazon VPC Lattice を使用して 独自のマイクロサービスアプリケーションに適用可能な EKS クラスター間のアプリケーション通信を保護する方法を、自動化されたサンプルを用いて、デモンストレーションしました。 このアプローチの主なメリットは以下のとおりです。 セキュアな通信： Amazon VPC Lattice を使用することで、EKS クラスター間の通信の転送中の暗号化、きめ細やかな IAM 認可ポリシーによる保護を実現できます。これにより、クラスターやアカウント間の転送であっても、アプリケーションデータのセキュリティと整合性を維持できます。 サービスディスカバリの簡素化： Gateway API Controller と ExternalDNS の統合により、カスタムドメイン名を使用してサービスを公開できるため、他のサービスがそれらを見つけて通信するのがより簡単になります。 スケーラビリティと柔軟性： Amazon VPC Lattice を使用することでアプリケーションを複数の VPC とアカウントに分散できるため、コンポーネント間のセキュアな接続性を維持しながら必要に応じてインフラストラクチャをスケールできます。 自動デプロイ： Terraform 用 EKS Blueprints を使用することで、EKS クラスター、Amazon VPC Lattice リソース、その他のサービスのデプロイと設定を自動化できるため、手動による誤りのリスクを減らし、一貫したデプロイを実現できます。 再利用性： このソリューションは、アプリケーションコードを変更することなく、EKS Pod Identity と Envoy プロキシを使用してセキュアな通信を可能にする方法を示しています。このアプローチは他のアプリケーションにも適用できるため、同じパターンとベストプラクティスを組織全体で再利用できます。 可観測性とモニタリング： Amazon VPC Lattice サービスのアクセスログを設定することで、クラスター間を流れるトラフィックの貴重な洞察を得られるため、問題をより効果的に監視およびトラブルシューティングできます。 全体として、このソリューションは Amazon VPC Lattice やその他の AWS サービスの力を利用して、Amazon EKS ベースのアプリケーションのクラスター間通信を包括的かつセキュアに実現するアプローチを提供します。この例で示されているパターンとベストプラクティスに従うことで、スケーラブルでセキュアな高可用性のマイクロサービスアーキテクチャを構築でき、これによりモダンなクラウドネイティブアプリケーションの要求を満たすことができます。 翻訳はソリューションアーキテクトの後藤が担当しました。原文は こちら です。

Amazon Bedrock でモデルの推論をするには、はじめにモデルアクセスの有効化が必要です。また、デフォルトで割り当てられた制限を超えて推論等を行う場合は Quotas と呼ばれる制限値を引き上げる必要があります。デフォルトの制限値は サービスの適正な利用とパフォーマンスの維持向上を図るため継続的に調整が行われており 、その中であなたの AWS アカウントのモデルアクセスの有効化や推論等の制限値に影響が発生する場合があります。影響を受けた際、どのように対応すればよいのかを示すのが本記事の目的です。 生成 AI の注目が高まるにつれ、生成 AI 、Amazon Bedrock をきっかけに初めて AWS を利用する方もいらっしゃると思います。そうした場合、想定外の影響を受けたとき AWS でどのように対応や問い合わせをすればよいのか戸惑うことも多いと理解しています。本記事はその戸惑いを解消するためにあり、生成 AI で AWS を活用いただく誰もが、詰まることなく影響を解消するための手順を説明します。はじめに Amazon Bedrock を利用するための基本的な手順をおさらいし、その後影響が発生した際の対応手順を示します。 モデルアクセスの有効化をする方法 Amazon Bedrock は複数の基盤モデルに対し統一された API でのアクセスを提供します。「複数」の中のどのモデルを利用するかは、Amazon Bedrock の「モデルアクセス」で設定します。最小特権の原則に基づき利用できるモデルを明示的に選択する方式で、会社や開発組織の規約や性能要件に合致したモデルのみアクセスを許可できます。 Amazon Bedrock で「モデルアクセス」を有効化する方法は、“ Amazon Bedrock のはじめ方 ” の「1. Amazon Bedrock の準備」にまとめています。手順が不案内な場合は、こちらの記事を参照ください。注意点として、手順を進める前に、Amazon Bedrock を利用するリージョンを選択していることを確認してください。リージョンとはデータセンターが集積されている物理的ロケーションをさし、AWS Console の右上で設定できます。利用可能なリージョンは、 こちらのページで確認できます 。利用可能なモデルはリージョンごとに異なり、 Model support by AWS Region にて確認ができます。 制限値を引き上げする方法 Amazon Bedrock のモデルに対し送信および受信できるトークン数の上限は、制限がかけられています。デフォルトの制限値は “ Amazon Bedrock endpoints and quotas ” を参照ください。これは予想外の利用が発生して使用料金が急増するリスクの対処に役立つ一方、頻繁な実験や一定の使用量が必要なユースケースの実現には制限値を超えた利用を申請しておく必要があります。 制限値の上限緩和を申請する場合は、AWS Console から “quotas” と検索し、“Service Quotas” を選択してください。 この操作をする場合も、Amazon Bedrock を利用するリージョンを選択していることを確認してください。 設定値はリージョンごとに設定されています。 “Service Quotas” の画面に遷移したら、AWS のサービスとして “Amazon Bedrock” を選択し、「クォータの表示」を押下します。 概ね、“On-demand” の requests per minute が問題となると思います。該当モデルの制限値を選択し、遷移後に「アカウントレベルでの引き上げをリクエスト」することで新しい上限値をリクエストできます。必要な設定値は、ユースケース等からの見積りを基に算出ください。 トラブルへの対処方法 上記でご説明したモデルアクセスの有効化や制限値の引き上げは通常時の方法です。ここから本題として、通常の手順通りではできなくなってしまった場合の対応方法を説明します。 モデルアクセスの有効化ができない場合 モデルアクセスの有効化ができない場合、モデルのチェックボックスがグレーアウトされて選択できなくなっているか、そもそもモデルが有効化のページに表示されないケースがあり得ます。 まず、利用可能なモデルはリージョンごとに異なるため、現在 AWS Console で選択しているリージョンと、 Model support by AWS Region を見比べモデルのアクセスが該当リージョンで提供されているかご確認をお願いいたします。 モデルが提供されているにもかかわらず、グレーアウトあるいは表示されていない場合、「サポートセンター」から「ケースの起票」をお願いいたします。サポートセンターは、AWS Console の右上の のアイコンからアクセスできます。 サポートセンターの画面から「ケースの作成」を押下してください。 Enterprise および Business, Developer など、サポート契約されている場合は「技術」が選択できますので、そこから Amazon Bedrock のサービスを指定してケース起票をお願いいたします。サポート契約されていない方は、下図のように「アカウントと請求」「一般情報及び使用開始に当たって」「AWS および各種サービスの利用」を選択しケースの作成をしてください。 件名と説明を例示します ( ※この通りに書かないといけないというわけではありません )。本番稼働予定など、早急に解消が必要な背景はぜひ追記ください。 件名 Amazon Bedrock でモデルアクセスの有効化ができない 説明 Amazon Bedrock で XXX のリージョンで YYY のモデルを利用するためにモデルアクセスの有効化を行おうとしたところ、チェックボックスがグレーアウトされている/リストに表示されておらず、有効化ができませんでした。該当リージョンでモデルが提供されていることは Model support by AWS Region で確認済みです。 本番環境での稼働を x/x に予定しており、検証をスケジュールに沿い進めるため有効化が行えるよう対応いただいてもよろしいでしょうか ? 制限値未満の利用にもかかわらずエラーが出る場合 Amazon Bedrock のモデルの利用制限は “ Amazon Bedrock endpoints and quotas ” に記載されていますが、ここで記載されている Quotas 未満の使用にも関わらず上限を超えた旨のエラーが発生する場合があります。 初手の対応方法として、クロスリージョン推論の利用を検討ください。Amazon Bedrock のリソース及び Quota はリージョンごとに設定されているため、複数リージョンの Quotas を有効に活用するのが効果的です。Amazon Bedrock は特定リージョンで推論に必要なリソースが枯渇していた場合、他のリージョンに推論をオフロードする “ クロスリージョン推論 ” が実装されています。こちらの機能を実装することで、よりリソースを冗長化した推論を行うことが出来ます。詳細は “ Amazon Bedrock の Cross Region Inference を試す ” などをご参照ください。 クロスリージョン推論を試してもエラーが発生する、あるいは国内にとどめる必要があるなどオフロードできない要件がある場合、上記同様にサポートセンターからケースの起票をお願いいたします。本番稼働予定など、早急に解消が必要な背景はぜひ追記ください。 件名 Amazon Bedrock で Quotas 未満にもかかわらずエラーが発生する 説明 Amazon Bedrock で XXX のリージョンで YYY のモデルを Quotas 未満で利用しているにもかかわらず、ThrottlingExceptionが発生します。デフォルトの Quotas は “ Amazon Bedrock endpoints and quotas ” で確認済みです。クロスリージョン推論はすでに試していますが、エラーの発生頻度はお客様向けの提供に問題がないレベルには至っていません or アプリケーションの要件として ZZ のリージョンに閉じる必要があり、クロスリージョン推論は利用できません。本番環境での稼働を x/x に予定しており、検証をスケジュールに沿い進めるため有効化が行えるよう対応いただいてもよろしいでしょうか ? 制限値の引き上げができない場合 Quotas のラジオボタンがグレーアウトされている場合、“Service Quotas” の画面から制限値の引き上げを行うことが出来ません。「調整可能ではない」と記載されている場合は引き上げができません。 この場合、上限緩和したいクォータ名のリンクにアクセスすると Support Center に問い合わせるよう誘導があります。それに従い、モデルアクセスと同様にケースを作成し上限の緩和を申請します。なお、申請は必ず認可されるわけではない点はご了承ください。 件名と説明を例示します ( ※この通りに書かないといけないというわけではありません )。Quota の名前は適宜変更してください。本番稼働予定など、早急に解消が必要な背景はぜひ追記ください。 件名 Amazon Bedrock で “ On-demand InvokeModel requests per minute for Anthropic Claude 3 Haiku ” の Quotas 変更ができない 説明 Amazon Bedrock で XXX のリージョンで件名のモデルの Quotas 上限を引き上げようとしたところ、アカウントレベルでの調整ができなかったためケースを起票させていただきました。現在、プロジェクトの検証のため・・・(以下、個別事情と希望する制限値について記載ください) おわりに 生成 AI のポテンシャルをすべてのデベロッパーの方に届けるため、AWS では日々リソースの最適化に努めています。その過程で意図しない影響が発生した際は、本手順に沿い解決を頂ければ幸いです。

みなさん、こんにちは。AWS ソリューションアーキテクトの小林です。 10月31日に開催したAWS AI Dayですが、たくさんのお客様にご来場を頂きました。この場を借りて御礼申し上げます。残念ながら参加できなかったという方もいらっしゃると思います。アーカイブ配信もありますので、ぜひご覧ください。「 AWSジャパン生成AI実用化推進プログラム 」の参加企業に登壇いただくライトニングトーク形式のセッションも開催し、各社さんのチャレンジをご紹介しています。我こそは、という方もまだ間に合います。ご応募をお待ちしています。 それでは、10 月 28 日週の生成AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「【開催報告&資料公開】 流通小売・消費財・EC 企業向け：クラウドと生成AI によるオペレーション改革」を公開 AWSではお客様の業界や、具体的な課題に特化した生成AIの活用例を集めて公開するとともに、お客様の新たな取り組みのヒントになる情報発信にも力を入れています。このセミナーもその活動の一環で、流通小売・消費財・EC企業とは切っても切り離せない「オペレーション」の改革をテーマにしています。お客様登壇の録画や、資料がまとまっていますので、ピンと来た方はぜひご一読ください。 ブログ記事「Enel が Amazon Bedrock を活用してスタッフの生産性を向上」を公開 海外事例記事の日本語訳です。Enelは32カ国でビジネスを行う大手総合電力会社です。そのお客様数は7,600万人に及び、サービス提供には多くの従業員が関わっています。その生産性工場は従来からの課題になっており、今回生成AIを活用することでITサービスデスクにおけるケース(問い合わせ)解決時間が1日から2分未満に短縮できたという事例です。 ブログ記事「Llama 3.x モデルのファインチューニングを Amazon SageMaker Pipelines の新しいビジュアルデザイナーで自動化する」を公開 Amazon SageMaker Pipelinesにはビジュアルデザイナーという機能があり、トレーニング・ファインチューニング・評価・デプロイといった一連のワークフローをグラフィカルに作成できます。この記事では、Meta社のLlama 3.xを題材にファインチューニングを行うパイプラインを構築する例をご紹介しています。この種のパイプラインは継続的なモデル改善という観点では必要不可欠ですので、参考にしていただけるケースは多いのではないでしょうか。 ブログ記事「社内に導入した生成 AI ツールの利用率伸び悩みを打破する : 先行事例に学ぶ 4 つのユースケース」を公開 上の方でも書きましたが、AWSではお客様のご協力を頂き、実務に根ざしたAI活用事例の公開に力を入れています。この記事では、「生成AIツールを導入したがあまり利用されていない」という悩みを抱えた方のヒントになりそうな事例をピックアップしてご紹介しています。 ブログ記事「生成 AI でサービスのトップラインを伸ばす！ : 業務効率化から進み、売上や利用の拡大を実現した事例 4 件に学ぶ」を公開 この記事はひとつ上の「先行事例に学ぶ4つのユースケース」と同じコンセプトの事例まとめですが、成約率向上などビジネス成果に直結する事例をピックアップしてご紹介しています。 ブログ記事「生成 AI を活用する鍵は組織横断のチームにあり : ML Enablement Workshop を活用した 4 つの事例から学ぶ」を公開 こちらも同様です。この記事ではML Enablement Workshopを活用して、生成AIを活用しビジネスを変革するために社内のチームや組織が有効に機能した事例を取り上げています。 サービスアップデート Meta社のLlama 3.1 8Bと70BがAmazon Bedrockでファインチューニング可能に 学習済みの基盤モデルに対して、ラベル付きデータを与えて目的とするタスクに特化させる手法がファインチューニングです。今回、Amazon Bedrockで動作するMeta社のLlama 3.1 8Bと70Bについて、ファインチューニングを実行できるようになりました。独自にインフラ環境を構築する必要がなくなり、ファインチューニングによるタスク特化型モデルの作成がこれまでよりも容易になるアップデートです。 Amazon BedrockでAnthropic Claude 3 Haikuのファインチューニングが可能に Amazon BedrockがAnthropic Claude 3 Haikuのファインチューニングに対応しました。独自のタスクに関するトレーニングデータセットを利用して、特定用途に対する精度や品質向上のためのカスタマイズを行うことによって目的に対する最適化が行えます。 Amazon Bedrockでコスト配分タグが利用可能に Amazon Bedrockでオンデマンドで基盤モデルを利用しているケースで、コスト配分タグを利用したコスト追跡が可能になりました。Bedrockで推論を行った際に、コストが発生した部門・プロジェクト・用途を特定しやすくなります。 Amazon Q Developerが開発者エクスペリエンスを向上させるインラインチャットをサポート Amazon Q Developerでインラインチャットという機能が利用できるようになりました。この機能ではエディタ内で対象となるコードを選択し、チャットを開始することで「コードを最適化する」「コメントを追加する」「テストを書く」などの作業をAmazon Q Developerに依頼することができます。なおこの機能は最新のAnthropic Claude 3.5 Sonnetを活用しています。 Amazon Redshift Serverless向けのAIによるスケーリングと最適化機能を発表 Amazon Redshift Serverlessで、スケーリングと最適化をAIで自動化できる機能が発表されました。データ量の変化やユーザ数、クエリの複雑度などを判断し、あらかじめ設定されたコストとパフォーマンスの優先度合いに従って自動的にスケーリングを行います。この機能は1日を通じたワークロードの傾向を学習しリソース管理を行うため、特に負荷の変動があるワークロードにおいて高いコストとパフォーマンスの最適化効果が見込めます。 Amazon RedshiftとAmazon Bedrockのインテグレーションを発表 Amazon RedshiftとAmazon Bedrockのインテグレーションが発表され、SQLのコマンドと利用してRedshiftに蓄えられたデータをAmazon Bedrockで動作する基盤モデルで活用できるようになりました。この機能を利用するとAmazon Redshiftのデータに対して、基盤モデルによる翻訳・テキスト生成・要約・分類・感情分析などを容易に実行できます。SQLで基盤モデルを呼び出すことができるので、既存のワークフローに組み込むことが容易だという点もポイントです。 Amazon SageMaker Notebook InstancesでJupyterLab 4 notebooksをサポート Amazon SageMakerのノートブックインスタンスでJupyterLab 4がご利用頂けるようになりました。パフォーマンスの高速化や、ノートブックのウィンドウ化などJupyterLab 4の最新機能や改善を利用できるようになります。 AWS GovCloud(米国西部)のAmazon BedrockでAnthropic Calude 3.5 SonnetとCalude 3 Haikuが利用可能に AWS GovCloud(米国西部)リージョンのAmazon BedrockでもAnthropicのClaude 3.5 SonnetとClaude 3 Haikuがご利用頂けるようになりました。 著者について 小林 正人(Masato Kobayashi) 2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

バリデーターは、Ethereum のようなProof of Stake (PoS) ブロックチェーンプロトコルの基本的な構成要素です。バリデーターはチェーンの履歴を維持し、分散型金融アプリケーションから NFT コレクティブルまで、複雑な分散型アプリケーションを可能にするコンセンサスプロトコルを実行します。 プロトコルに参加するために、バリデーターは担保として資産を提供します。これにより、コンセンサスを形成する際に正しく動作することが保証されます。残念ながら、プロトコルは悪意のあるバリデーターと単なる過失を区別できないため、運用上のミスやバリデーターのクライアントソフトウェアのバグにより資産がリスクにさらされています。最良のケースでは小さな経済的なペナルティに、最悪の場合は資金全額が失われることにつながります。 このポストでは、Ethereum バリデータオペレーターを内部の脅威、バリデーターへの侵害、運用上のミス、クライアントのバグから守るために設計されたセキュアな鍵管理プラットフォームのハイレベルなアーキテクチャについて説明します。 以下のトピックについても扱います。 Ethereum のバリデーターを実行する際の課題と、関連するセキュリティおよびスラッシングリスク。 ※スラッシングとは、バリデーターの不正行為に対する罰金のことです。 リモート鍵管理ソリューションを使ってこれらの課題に取り組む考え方と、リスクを実質的に軽減するためにキーマネージャーが構築される必要がある根本的な目標。 Cubist の CubeSigner のハイレベル設計。CubeSigner は AWS Nitro Enclaves 上に構築された、セキュアな鍵管理プラットフォームで、エンドユーザーのウォレットからトレーディング、チームや運用のための鍵管理まで、ステーキングやその他のアプリケーションをサポートしています。 Ethereum バリデーターを実行する際の運用上の落とし穴 Ethereum の PoS プロトコルは、数十万のバリデーターにより実行されるコンセンサスプロトコルです。数秒おきにバリデーターは Ethereum のトランザクションを実行し、無作為に選ばれたバリデーターが提案した状態の変化と結果が一致する場合、これらのトランザクションをブロックチェーンに追加し、バリデーションメッセージに署名することでそれを証明します。バリデーターに、正直にチェーンの状態を報告するインセンティブを与えるため、このプロトコルではバリデーターに 32 ETH のステーキングを求めています。バリデーターが期待どおり振る舞う (トランザクションを改ざんしたりチェーンの状態を偽ったりしない) と、ステークされた資産に対して報酬が得られます。そうでない場合、ステークの一部が失われます。 バリデーターがチェーンの状態を改ざんしていた場合、ネットワークの安全性を損なったとしてスラッシュと呼ばれるペナルティが課されます。スラッシュされるとかなりの金銭的ペナルティを受け、プロトコルから締め出されます。また、オフラインになったり、署名が非常に遅くなったバリデーターにも、プロトコルの可用性を危険にさらしているので、軽い制裁が課されます。 残念ながら、検証ノード (ノード運営者) のミスと故意の不正行為を区別することはできません。検証ノードがブロックチェーンの状態に関して 2 つの矛盾するレポートを提出した場合、その矛盾が意図的な不正行為に起因するものなのか、検証ノードソフトウェアのバグによるものなのかを判別するのは不可能です。その結果、セキュリティ、正確性、またはパフォーマンスに関する様々な種類のミスをしたオペレーターは、スラッシング (ペナルティ) によって直接的に金銭的損失を被ることになります。これらのミスを防ぐには、深刻な課題があります。 セキュリティ – 1 つのバリデーターのステーキングキーは通常 32 ETH (執筆時点で約 8 万米ドル) を保護します。ただし、このような貴重なバリデーターのステーキングキーは、数分ごとに検証メッセージに署名する必要があるため、コールドストレージに保管できません。そのため、ノード運用者は ホットキーをシステム侵入から保護する必要があります。オープンソースのバリデータークライアント、ノードを 24 時間 365 日稼働させる運用要件、不正な運用者やソーシャルエンジニアリングなどの内部の脅威ベクトルがある複雑な環境において、これは特に困難です。 目標 – 攻撃者や悪意のある内部者から秘密の署名キーを盗まれたり、悪用されるのを防ぐキーマネージャーを作成する。 正確性 – 2 つの異なる競合するメッセージに署名したバリデーターは、競合する署名が誤りでも不正とみなされ、罰金 (スラッシング) が科されます。過去には、正直な運用者がバグのあるバリデータークライアントソフトウェア、マシン間でのバリデーターの移行エラー、バリデーターソフトウェアの更新ミスなどによって罰金を科されたこともあります。 目標 – 運用者がスラッシングから守られ、Beacon チェーンプロトコル仕様に従った正しい動作が保証されるキーマネージャーを作成する。 可用性 – 署名しなかったり遅れて署名した (たとえば 12 秒のスロット時間に応答しなかった) バリデーターは、報酬が減額されるか支払われません。そのため、ノード運用者は高可用性と信頼性のあるソリューションを設計し、低レイテンシー (通常は署名時の上限を 500 ミリ秒に設定) で応答する必要があります。 目標 – このようなレイテンシー、信頼性、可用性の目標を達成するのに役立つキーマネージャーを作成する。 リモートでの署名は、バグや運用ミスによるリスクを軽減 Ethereum の PoS Beacon チェーンに参加するために、ノードオペレーターは Lighthouse や Prysm などのバリデーター クライアントを使用します。バリデーター クライアントは、任意の数のバリデーターキーペアを含みます。各ペアは 1 つのバリデーターに対応しており、公開鍵がバリデーターの識別子、秘密鍵がバリデーター クライアントがそのバリデーターに代わってメッセージに署名するために使用されます。バリデーター クライアントはその後、これらの署名済みメッセージをビーコンチェーンネットワークに放送し、本質的にバリデーターのチェーン状態の見解を主張します。 Validator クライアントは、所有のマシン上で Validator キーを保持してローカルに署名することができます。または、リモートサイナーを使用することができます。リモートサイナーは、キーをリモートに保持し、Validator クライアントに対して署名 API を公開します。各エポックで、Validator クライアントは署名リクエストをリモートサイナーに送信し、サイナーから署名済みの Validation メッセージを受け取ります。ネットワーク経由のリモート署名はローカル署名より遅くなります。しかし、以下の理由から、オペレーターはリモートサイナーを使用しています。 セキュリティ– リモートサイナーを使用することで、バリデーター鍵を以下から隔離できます。 バリデーターのクライアント – これは外部の不信な環境 (他のビーコンチェーンノード) と対話し、信頼されない Ethereum Virtual Machine (EVM) コードを実行します。 インサイダー脅威 – ここにはノードの稼働状態を維持する運用者が含まれますが、彼らにはバリデーターの秘密鍵へのアクセスは不要です。 正確性– リモートサイナーを使用することで、 参照モニター (アンチスラッシングデータベースと連携したサイナー) を実装し、鍵がスラッシングを引き起こすようなメッセージに署名することを回避できます。 可用性– すべてのバリデーター鍵を処理するリモートサイナーを使用することで、ノード運用者がバリデーターのクライアントを自動的にスケールし、クラッシュ時に新たにスピンアップできるようになります。 リモートサイナーは、これらの特性を考慮して設計される必要があります。Web3Signer のような一般的なサイナーを単純に使用しただけでは、これらの特性を得られません。例えば、リモートサイナーは、キーにアクセスできるユーザーを制限する必要があります。つまり、承認されたユーザー (およびバリデータクライアント) のみにアクセスを制限し、キーをサイナー自体に封印します。そして、キーで何ができるのかを制限する必要があります。そうしないと、侵害やインサイダー脅威がキーの盗難につながる可能性があります。 リモートサイナー自体は、高可用性で耐障害性がある必要があり、グローバルで高可用性のスラッシング防止データベースを使用する必要があります。そうしないと、サイナーや OS の更新、マシン障害、ネットワーク障害がスラッシングイベントの原因となる可能性があります。 最後に、リモートサイナーはローカル (安全ではない) 署名ほど高速である必要はありませんが、バリデータの待機時間は重要です。遅すぎる (一般的に 1 秒以上) と、バリデータがメッセージ署名が遅れ、オペレーターに金銭的損失が発生します。 以下のセクションでは、Nitro Enclaves ベースの CubeSigner リモート署名ソリューションを実装することで、セキュリティ、正確性、および可用性のゴールを達成した方法について詳しく説明します。 Cubist CubeSigner – Architecture overview 前述の、正確性、セキュリティ、パフォーマンスと信頼性の課題に対処するために、私たちは AWS Key Management Service (AWS KMS)、 Amazon DynamoDB 、そして Nitro Enclaves を利用した、新しいリモート署名サービス CubeSigner を構築しました。 検証クライアントからのメッセージを処理するためにサイナーが実行する手順は次のとおりです。 Amazon API Gateway 上の HTTP インターフェース経由で、検証メッセージを受け入れます。 DynamoDB に保存された署名履歴を使用して、そのメッセージがスラッシングするかどうかを確認します。 スラッシングしない場合は、AWS KMS とセキュアなキーを使用して署名します。 次の図は、このソリューションアーキテクチャを示しています。 次のセクションでは、これらの 3 つのステップを詳しく説明します。 認証されたハイレベルの署名 API 署名者は、Lighthouse や Prysm などの検証クライアントがそのまま使える API を公開する必要があります。シンプルながら低レベルの署名エンドポイントを公開する AWS KMS API とは異なり、この API はイーサリアム Beacon チェーン特有のハイレベルのバリデーター メッセージを処理する必要があります。このハイレベル API は必須です。なぜなら、メッセージの内容に基づいて、バリデーター メッセージに対してスラッシング防止ポリシーを適用できるからです。代わりにメッセージの生ハッシュを受け取って署名するだけでは、特定のメッセージがスラッシングの対象となる可能性があるかどうかを判断することはできません。 スラッシングを防ぐだけでなく、このハイレベルの API は、検証要求が認証済みの検証ノードから来たものであることも保証する必要があります。そうしないと、単一のクライアントが侵害されれば、すべての検証ノードとすべてのキーが侵害されてしまいます。CubeSigner はさらに進んで、細かい権限範囲による認証を使用しています。権限範囲は認証セッションを制限して、特定のアクション (例えば検証) のみを実行できるようにします。検証ノードに検証の権限範囲のみを与えることで、ノードオペレーターはそれらの検証ノードが、例えば Exit メッセージに署名したり、検証プロトコルから出ることを防ぐことができます。これにより、オペレーターが誤って検証ノードを出ることを防ぎ、代わりに出ようとする攻撃者からオペレーターが報酬を失うのを防ぎます。 CubeSigner は、発信者のアイデンティティを判別するためのカスタム認証スキームを実装した AWS Lambda authorizersと API Gateway を利用しています。各許可された署名リクエストは、CubeSigner の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスに送信され、まず許可されたスコープがリクエストを許可しているかを確認します。次に、署名者がメッセージの署名ルートハッシュを計算し、そのハッシュの署名がスラッシングを引き起こさないようにアンチスラッシングポリシーを適用して署名を行い、署名をバリデーター クライアントに返します。次に、アンチスラッシングと署名そのものについて説明します。 スラッシング対策 CubeSigner はポリシーエンジンであり、アンチスラッシングを実装しています。署名要求を承認した後、CubeSigner は Ethereum の組み込みアンチスラッシングを含む複数のポリシーを適用します。アンチスラッシングポリシーは EIP-3076 に従い、バリデーター がすでにコミットした Chain 履歴と矛盾するメッセージに署名しないことを保証します。つまり、ポリシーには状態を保存する必要があります。CubeSigner は DynamoDB をデータベースとしてこのポリシーを適用します。すべてのバリデーター 鍵に対して、署名したメッセージを原子的かつ条件付きで記録し、ある特定のスロット番号に対して複数の署名が生成されないことを保証します。 DynamoDB は、あらゆるスケールのハイパフォーマンスアプリケーションを実行するために設計された、フルマネージド、サーバーレスのキーバリューの NoSQL データベースです。DynamoDB には、組み込みのセキュリティ、継続的なバックアップ、自動マルチリージョンレプリケーション、インメモリキャッシュ、そしてデータのインポートおよびエクスポートツールが備わっています。可用性と一貫したパフォーマンスは、ブロックチェーンバリデーターの実行時に特に重要です。これらが停止したり、レイテンシーやデータ不整合が発生すると、直接的な金銭的損失につながる可能性があるためです。これらの要件を踏まえると、DynamoDB は、単一ミリ秒で一貫したパフォーマンスと 99.999 % の可用性を備えている点で適しています。DynamoDB のパフォーマンス、コスト、スケーラビリティ機能の詳細については、 Amazon DynamoDB 機能 を参照してください。 安全な署名 3 つ目の層は、CubeSigner 仮想ハードウェアセキュリティモジュール (vHSM) です。この層は、キーを攻撃者から守るために、ハードウェアセキュリティモジュール(HSM)内で AWS KMS を利用してバリデーションメッセージに署名を付けます。 HSM と AWS KMS 銀行業務やドメイン証明書の管理など、セキュリティが重要な業務分野では、鍵管理に関するタスク (キーの保管や署名など) を HSM に外部委託することが一般的です。HSM は、暗号化の秘密鍵を物理的ハードウェアに紐付けた専用のデバイスです。このため、非常に盗難が難しくなっています。たとえば標準的な HSM では鍵の抽出攻撃を行うには電子顕微鏡のある研究室が必要です。そうしない場合、盗難を検知すると自己破壊します。 ただし、HSM 単独での利用は比較的難しくなります。高水準言語で記述されたアプリケーション内から HSM にアクセスするには、通常、ベンダー固有の SDK が必要となり、アプリケーション自体が PKCS11 API 標準に準拠している必要があります。AWS では、アクセス可能な HSM ベースの鍵管理サービスである AWS KMS を提供しています。AWS KMS は、 FIPS 140-2 セキュリティレベル 3 に分類される HSM で保護された暗号化キーを作成/管理できるフルマネージドサービスです。さらに、標準の AWS SDK (例えば、Rust 向けの aws-sdk-kms )から利用できます。 AWS KMS を単独で使用しない理由 AWS KMS だけでは、バリデーターに対して安全な鍵管理ソリューションを構築するには不十分です。1つ目の課題は技術的なものです。 Ethereum バリデーターは Boneh-Lynn-Shacham (BLS) 署名スキームを使用して署名する必要がありますが、HSM はまだ National Institute of Standards and Technology (NIST) との規制の整合性の課題により、BLS をサポートしていません。HSM は主に、ブロックチェーン業界外で普及している RSA や Elliptic Curve Digital Signature Algorithm (ECDSA) などの暗号化署名スキームの提供に重点を置いています。新しい署名スキームのサポートを拡張するには、通常、HSM 自体のローレベルのファームウェアアップグレードが必要になります。 たとえ HSM が BLS 署名を生成できたとしても、次のような課題に直面するでしょう。待ち時間と処理能力です。Ethereum ノードオペレーターは数百から数千の承認者を実行していますが、すべての承認者が約 1 秒 (暗号化処理とネットワーク往復を含む) で署名を生成する必要があります。ほとんどの HSM はパブリックキー暗号化処理のバッチ処理に最適化されていません (例えば、KMS での 100 件の ECDSA 署名処理のレイテンシ合計では、1 秒制限を超えてしまいます)。さらに、HSM は一般的に処理能力に制限があります (デフォルトでは、AWS KMS は 1 秒間に 300 件の楕円曲線非対称暗号化処理しかできません)。AWS KMS HSM と Nitro Enclave を組み合わせることで、セキュリティを確保したまま、これらの問題を解決できる vHSM を実装できます。 Nitro Enclaves は分離された、堅牢な制約のある仮想化コンピューティング環境です。AWS Nitro Systemは専用ハードウェアと軽量のハイパーバイザによって、強固な分離、Nitro Security Moduleによるハードウェア生成エントロピー、暗号認証といった機能を提供します。これにより、Enclaves の信頼性を検証し、許可されたコードのみが実行されることを確認できます。 Nitro Enclavesと AWS KMS を利用する CubeSigner の仕組み CubeSigner vHSM は、BLS などの主要な署名方式をソフトウェアで実装し、このコードを Nitro Enclave 上で実行します。これにより、任意の署名スキームをサポートでき、HSM よりもはるかに高速に署名を行うことができます。 vHSM はすべての署名キーを AWS KMS ベースのラッピングキーを使って暗号化します。トランザクションの署名要求を受けると、暗号化された署名キーとラッピングキーをEnclaves に取り込み、署名キーを復号化し、トランザクションに署名して、ユーザーに返します。vHSM での署名処理は、検証に十分な速度で行われ、パフォーマンスに影響を与えることはありません。その理由はネットワーク遅延を含めても 500ms 以下の時間しかかからないためです。 メッセージの署名には単一の署名キーの復号化が必要ですが、HSM は対称暗号化操作に最適化されています。例えば、AWS KMS では、デフォルトで毎秒 50,000 回の対称暗号化/復号化操作を実行できます。Nitro Enclave は、高速で非対称暗号操作 (例えば、署名の生成) を行えます。CubeSigner は、すべての暗号化された署名鍵 (この例では BLS バリデーター鍵ですが、一般的には任意の署名スキームの鍵) を DynamoDB に保存します。これにより、鍵のレプリケーション、バックアップ、DynamoDB のスケーラビリティとパフォーマンスの活用が可能になります。 ラッピングキーは AWS KMS を使用して保存および管理され、ノードオペレーターごとに 1 つのラッピングキーがあります。この鍵はEnclaves 内の vHSM にシールされ、AWS ルートユーザーからはアクセスできなくなっています。つまり、誰もラッピングキーを使用または抽出できません。KMS キーをEnclaves にシールすることは極めて強力な基本操作です。これにより、vHSM がオペレーターの署名キーを復号化できる唯一のコンポーネントであることが保証され、ソフトウェア上で HSM のようなハードウェア抽象化を実装することが可能になります。 Enclaves 内のコードだけがシークレットキーにアクセスできるため、キーを安全に保つには、Enclaves 内のコードを安全に保つことに尽きます。この目的で、コードは次の機能を備えています。 Rust で実装 – コードが秘密情報をメモリやサイドチャネルから漏洩しないように、低レベルで秘密情報の扱い方を制御できるため、Rust で開発しました。また、Rust を使用すれば、Enclaves 内で実行されるコードの安全性を証明する検証技術を簡単に使えます。 少ない依存関係 – cargo vet を使って依存関係を管理し、Rust の使用により、マッシブな実行時システム (JVM など)、複雑な Just-In-Time コンパイラ (JavaScript エンジンなど)、そして、それらに付随する大規模なサプライチェーンから解放されます。 最小権限 – Enclaves 内で実行されるコードのインターフェースが攻撃対象の表面積となります。当社の vHSM は、vsock 通信チャネルを使い、小さくタイプ安全なインターフェースを実装しています。 これは、他のサイナーとは異なり、Enclaves の境界を越えて任意のネットワーク要求をプロキシするようなものではありません。 接続先の制限 – vHSM から外部に通信できるのは、AWS KMS への安全な通信経路のみです。詳細については、 How AWS Nitro Enclaves uses AWS KMS を参照してください。しかし、ここでもサイナーはチャネルが侵害される可能性があると想定し、特定のEnclavesに関連付けられた一時的な秘密鍵と公開鍵を使用して、AWS KMS からの結果を証明書内の公開鍵で暗号化します。このようにすれば、AWS KMS の復号要求が発せられたEnclaves内でのみ、その復号結果を読み取ることができます。 おわりに このポストでは、Ethereum のバリデーターノードを運用する際の運用上の落とし穴やトラップについて説明し、特にノードオペレーターが日々直面する安全性、正確性、可用性の課題のバランスについて取り上げました。ノードにローカルでキーを管理することに対し、リモートに署名することにより、これらの課題に対処できます。しかし、リモートサイナーの設計が重要です。そのため、Nitro Enclave に基づくリモートシグニングソリューション CubeSigner の設計を詳しく説明し、CubeSigner がオペレーターが直面する安全性とペナルティの課題に対処するだけでなく、運用コストを大幅に削減でき、高可用性のバリデータークラスターを実行するのにも役立つことを示しました。 Cubist のCubeSigner サンドボックスアカウントに登録し、AWS Blockchain Node Runners テンプレートを使用して イーサリアムのバリデーターを起動し、独自のイーサリアムのバリデーターノードを実行することをお勧めします。 本記事は、 Use AWS Nitro Enclaves to build Cubist CubeSigner, a secure and highly reliable key management platform for Ethereum validators and beyond を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津 颯騎 が担当しました。 著者について フレイザー・ブラウン は、Cubistの共同創設者兼最高技術責任者（CTO）です。また、カーネギーメロン大学コンピューターサイエンス学部の助教授でもあります。彼女の研究は、セキュリティとプログラムの正確性に焦点を当てており、実運用システムの（一部の）検証から、実際のコードベースにおける悪用可能なバグの自動検出まで幅広く取り組んでいます。例えば、彼女が開発したツールは、人気のあるChromeやFirefoxブラウザにおいて、多くのゼロデイ脆弱性や報奨金対象のバグ、そしてCVE（共通脆弱性識別子）を発見しています。 デイアン・ステファン は、Cubistの共同創設者兼チーフサイエンティストです。また、カリフォルニア大学サンディエゴ校のコンピューターサイエンス・エンジニアリング学科の准教授でもあります。彼の研究は、セキュリティとプログラミング言語の交差点に位置し、特に実運用環境で展開される安全なシステムの構築に重点を置いています。2019年にVMwareに買収された、ランタイムセキュリティのスタートアップ企業Intrinsicの共同創設者でもありました。 デイビッド-ポール・ドーンザイファー は、AWSのブロックチェーン開発アーキテクトです。彼は顧客がエンドツーエンドのブロックチェーンソリューションを設計、開発、スケーリングするのを支援することに注力しています。彼の主な専門分野はデジタル資産のカストディと鍵管理ソリューションです。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今期から 週刊 AWS を担当させていただくことになり、わくわくしております。これからよろしくお願いいたします。 11 月 7 日 (木) 10:00 – 12:00 に データガバナンス事例祭り が開催されます。企業内のさまざまなデータを AWS サービスと最新のアプローチを活用して実現しているお客様より、具体的な取り組みについてお話しいただく予定でおります。私自身もデータ分析案件でお客様を支援させていただくことが多く、こちらのイベントを楽しみにしています。ぜひ、ご都合があえばご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年10月28日週の主要なアップデート 10/28(月) Meta の Llama 3.1 8B および 70B モデルが Amazon Bedrock で ファインチューニング が可能に Amazon Bedrock は、Meta 社の Llama 3.1 70B および Llama 3.1 8B モデルのファインチューニングをサポートするようになり、企業がこれらの生成 AI モデルを自社のデータでカスタマイズが可能になりました。Llama 3.1 モデルは、128K のコンテキスト長さ (Llama 3 の 16 倍) など、以前のバージョンに比べて大幅な改善が施されており、長いテキストから大量の情報にアクセスして処理することができるようになっています。また、ファインチューニングを使用すると、Llama 3.1 モデルを特定のドメインのタスクに適合させ、特殊な使用例におけるモデルのパフォーマンス向上が期待できます。 AWS Trust & Safety Center が AWS re:Post で利用可能に AWS Trust & Safety Centerでは、AWS のお客様が、不正利用が疑われる AWS 上のアクティビティやコンテンツを報告する方法や、AWS Trust & Safety から送信される不正利用通知の対処方法に関する情報を提供します。 さらに、お客様がアプリケーションを保護するために使用できる AWS サービスや、デジタルメッセージングのベストプラクティスについても詳しく説明しています。 たとえば、お客様が AWS ネットワーク上で不審なアクティビティを検出した場合、Abuse Reporting FAQs を参照し、AWS サービスの禁止された使用方法、Abuse Report の提出方法、AWS Trust & Safety に連絡するタイミングについての情報を得ることができます。 10/29(火) AWS CodeBuild がビルドの自動リトライをサポート AWS CodeBuild は、ソースコードをコンパイルし、テストを実行し、デプロイ準備の整ったソフトウェアパッケージを生成する、フルマネージドの継続的インテグレーションサービスです。 この新機能により、CodeBuild プロジェクトに再試行の上限を設定することができ、CodeBuild はその上限まで失敗したビルドを自動的に再試行します。 これにより、断続的な障害による中断を回避し、手動でビルドを監視してリトライするためのインフラストラクチャを追加する必要がなくなります。 AWS Clean Rooms がコンピュートサイズを設定可能な Spark SQL をサポート AWS Clean Rooms Spark SQL を提供開始し、お客様は Spark SQL を使ってカスタムクエリを実行できるようになりました。これにより、これにより、Spark エンジンを使ったAWS Clean Rooms コラボレーションが作成できます。Spark SQL 実行時に様々なインスタンスタイプを設定することができ、ワークロードをサポート可能です。Spark SQL の構文を使って大規模データセットにクエリが実行でき、パフォーマンス、スケール、コストに応じてリソースをカスタマイズできます。詳細は、 AWS Clean Rooms をご覧ください。 10/30(水) AWS DataSync データ転送のパフォーマンスとスケーラビリティを向上 Amazon S3 ロケーション間のデータ転送において、パフォーマンス、スケーラビリティ、オブザーバビリティを改善しました。AWS DataSync は、安全かつ確実にネットワーク経由でファイルを移動する高速データ転送サービスです。 追加された新機能では、DataSync タスクを Basic モードまたは Enhanced モードで実行するように設定できるようになりました。 特に、Enhanced モードでは、データの準備、転送、検証を並行して行うことで、データ転送プロセスを最適化および合理化し、ほとんどのワークロードで Basic モードよりも高速に実行できます。 詳細は AWS DataSync のドキュメント をご覧ください。 Amazon CloudWatch がプロビジョニングされたパフォーマンスを超える EBS ボリュームを監視可能に アプリケーションが Amazon EBS ボリュームのプロビジョニングされたパフォーマンスを超えようとしている場合に確認できる新しい 2 つの Amazon CloudWatch メトリクスが追加されました。2 つのメトリクスである Volume IOPS Exceeded Check と Volume Throughput Exceeded Check は、駆動された IOPS またはスループットが EBS ボリュームのプロビジョニングされたパフォーマンスを超えているかどうかを監視します。これにより、プロビジョニング不足の EBS ボリュームに起因する待ち時間の問題を迅速に特定し、対応することができます。 AI によるスケーリングと最適化を備えた Amazon Redshift Serverless を発表 Amazon Redshift Serverlessは、クラウドデータウェアハウスにおける AI 主導の次世代スケーリングと最適化をリリースしました。AI が活用されることにより、データ量の変化、同時ユーザー数、クエリの複雑さなど、すべての主要な次元にわたってワークロードの変化に合わせて自動的にスケーリングし、価格性能目標を達成・維持されます。 手動による介入なしに、変動するワークロードに対して最大 10 倍の価格パフォーマンスを提供できることが、 Amazon 内部のテストで実証されています。AI 主導のスケーリングと最適化により、パフォーマンスとコストを合理化しながら運用のオーバーヘッドを削減し、Amazon Redshift Serverless をよりスマートで効率的な活用が可能になります。 AWS Blog もご覧ください。 10/31(木) Amazon Aurora オペレーティングシステムのアップグレードのためのローリングアップグレードをサポート Amazon Aurora は、OS のアップグレードをローリングアップグレードでサポートしました。Aurora は、Aurora クラスターエンドポイントまたはリーダーエンドポイントを使用する際、データへの読み取りアクセスを維持しながら、Aurora データベースクラスターのオペレーティングシステムバージョンをシームレスにアップグレードします。 この機能により、データベースが 1 つ以上のリーダーインスタンスを持つクラスターの読み取りトラフィックに対応しつつ、一度に数個のリーダーインスタンスにアップグレードを自動的に適用します。Aurora クラスターのオペレーティングシステムをアップグレードする方法の詳細については、 技術ドキュメント をご覧ください。 11/1(金) Amazon Bedrock での Anthropic の Claude 3 Haiku の ファインチューニング を提供開始 Amazon BedrockでAnthropic の Claude 3 Haiku モデル の ファインチューニング が可能になりました。 Claude 3 Haikuは、Anthropic の 最もコンパクトなモデルであり、Anthropic によれば、そのインテリジェンスカテゴリーでは市場で最も手頃な価格で最速のオプションの一つです。 独自のタスクに特化したトレーニングデータセットを提供することで、Claude 3 Haiku をファインチューニングおよびカスタマイズし、モデルの精度、品質、一貫性を向上させ、生成 AI をさらにビジネス向けにカスタマイズすることができます。詳細は、 ローンチブログ 、 テクニカルブログ 、また ドキュメント をご覧ください。 Amazon WorkSpaces WSP は TCP/UDP ポート 443 経由のデスクトップ トラフィックが利用可能に Amazon WorkSpaces Amazon DCV 対応デスクトップ・トラフィックは、ポート 443 上の TCP と UDP の両方をサポートしました。 この機能は自動的に使用され、設定の変更は必要ありません。 また、ポート 4195 をご利用のお客様は、引き続きご利用いただけます。たとえば、WorkSpaces を管理する組織は、ユーザーが WorkSpaces に接続するクライアントネットワークを管理する組織と同じとは限らず、各ネットワークは独立して管理されているため、管理上の課題、遅延、またはアウトバウンドのアクセスルールを変更するための障害が発生します。追加された新機能により、WorkSpaces クライアントアプリケーションは、最適なパフォーマンスのために UDP（QUIC）を優先しますが、UDP がブロックされた場合は TCP にフォールバックされ、お客様は固有の TCP/UDP 4195 のユニークポートを開放する必要がなくなりました。詳細は、 Amazon WorkSpaces Administration Guide をご覧ください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

2024 年 10 月 30 日、AWS AppSync に AWS AppSync Events の機能が追加されました。この機能を使うと、開発者は安全で高性能なサーバーレス WebSocket API を使って、リアルタイムのイベントデータを数人または数百万人のサブスクライバーに簡単にブロードキャストできます。AWS AppSync Events を使えば、開発者はもう WebSocket インフラストラクチャの構築、コネクション状態の管理、ファンアウトの実装を心配する必要がありません。開発者は単に API を作成し、WebSocket 接続が行われているクライアントにサブスクライブされるイベントをパブリッシュするだけです。 AWS AppSync Event API はサーバーレスなので、すぐに始められ、自動的にスケーリングされ、利用した分だけ支払えばよいというメリットがあります。このブログでは、AWS AppSync Events および、AWS AppSync Event API とは何かを説明し、開発者がどのように始められるかを説明します。 リアルタイムのイベント更新は現在のアプリの重要な機能であり、ユーザーに差別化された経験を提供します。ライブスポーツのスコア、グループチャットメッセージ、価格レベル、または位置情報の更新など、開発者は最新の情報をリアルタイムに提供するアプリを構築したいと考えています。しかし、この機能を実装するのは簡単ではなく、スケーリングが難しくなります。これが AWS AppSync Events によって変わります。AWS AppSync Event API は簡単に設定でき、開発者はすぐに作業を開始し、標準の Web API を使用して WebSocket エンドポイントに接続できます。AWS AppSync Event API はサーバーレスで、接続されている数百万のクライアントにリアルタイムの更新をパブリッシュできるようスケールします。イベントドリブンアーキテクチャに投資してきた組織向けに、AWS AppSync Events は HTTP エンドポイントによるパブリッシュをサポートしています。これにより、 Amazon EventBridge などの一般的なサービスとの統合が簡単になり、バックエンドから生成されたイベントを Web およびモバイルアプリに簡単にパブリッシュできます。 AWS AppSync Events では、最初に API を作成し、どの認証モードがサポートされているかなどの基本的な設定を定義します。次に、名前空間に名前を割り当てることによりチャネル名前空間を作成します。これは、その名前空間内のすべてのチャネルの接頭辞にもなります。チャネル名前空間は、そのチャネルの機能を定義します。 たとえば、名前が messages のチャネル名前空間では、 /messages で始まるチャネルを公開およびサブスクライブできます。名前空間内のチャネルは一時的なものであり、必要に応じて作成されます。たとえば、必要に応じて /messages/group/admin または /messages/user/JohnDoe にイベントを公開できます。特定のチャネル /messages/user/JohnDoe のイベントをサブスクライブすることも、チャネルパスの最後にワイルドカードを使用して /messages/* または /messages/user/* のようなサブセットをサブスクライブすることもできます。 コンソールを使ってはじめる 始めるには、 AWS AppSync Console にアクセスしてください。そこで [Create API (API を作成)] を選択し、[Event API] を選んでください。API に名前を付け、[Create (作成)] を選択します。数秒で API が作成され、使用できる状態になります。コンソールでは、サービスがイベント API、デフォルトの名前空間、API キーを作成します。同じ結果を AWS CLI、AWS SDK、AWS CloudFormation、AWS CDK でも実現できます。 次に、 Pub/Sub エディタ に移動します。このエディタでは、コンソールから直接公開とサブスクライブを簡単に行えます。アイデアをすばやくテストし、機能を確認するのに最適なツールです。エディタを使用して、HTTP 経由でイベントを公開し、WebSocket 接続でサブスクリプションを設定できます。イベントを受信するには、[Subscribe] セクションで [Connect]、次に [Subscribe] を選択します。あとはチャネルに公開されたイベントを受信できる状態になります。HTTP エンドポイントでは、最大 5 件のイベントをまとめて公開できます。コンソールから公開するには、JSON オブジェクトの配列を入力するだけです。 例えば、Publish セクションに以下の値を入力してください。 [ { "message": "hello world!" }, "New WebSocket API!", true, 100, ["L", "G", "T", "M"] ] 5 イベントを Subscribe セクションで受信しました！ アプリケーションとの統合 AWS AppSync Events を使用するアプリケーションを構築するのは簡単です。 AppSync Events 用の AWS Amplify クライアント を使用でき、API の構成情報はコンソールの Integrations (統合) タブにあります。 Web ブラウザから API に接続するための外部依存関係はありません。以下の JavaScript のコード例は、ブラウザの Web API WebSocket を使ってエンドポイントに接続する方法を示しています。このコードを使用するには、Event API Settings (設定) ページから HTTP および リアルタイム DNS 名を取得し、API キーをコピーします。次に、ページの開発者コンソールを開きます。スニペットの値を指定し、スニペットを開発者コンソールのエディタに貼り付け、コードを実行します。 const REALTIME_DOMAIN = '' const HTTP_DOMAIN = '' const API_KEY = '' const authorization = { 'x-api-key': API_KEY, host: HTTP_DOMAIN } function getAuthProtocol() { const header = btoa(JSON.stringify(authorization)) .replace(/\+/g, '-') // Convert '+' to '-' .replace(/\//g, '_') // Convert '/' to '_' .replace(/=+$/, '') // Remove padding `=` return `header-${header}` } const socket = await new Promise((resolve, reject) => { const socket = new WebSocket( `wss://${REALTIME_DOMAIN}/event/realtime`, ['aws-appsync-event-ws', getAuthProtocol()]) socket.onopen = () => { socket.send(JSON.stringify({ type: 'connection_init' })) resolve(socket) } socket.onclose = (evt) => reject(new Error(evt.reason)) socket.onmessage = (event) => console.log('=>', JSON.parse(event.data)) }) socket.send(JSON.stringify({ type: 'subscribe', id: crypto.randomUUID(), channel: '/default/*', authorization })) ブラウザの Web API  fetch メソッドを使用してイベントを送信できます。 たとえば、開発者コンソールで次のように実行します。 const event = { "channel": "/default/introductions", "events": [ JSON.stringify({message:'Hello World! Introducing AWS AppSync Events!'}) ] } const response = await fetch(`https://${HTTP_DOMAIN}/event`, { method: 'POST', headers: authorization, body: JSON.stringify(event) }) console.log(response) 接続、承認、WebSocket の使用についてより詳しく知るには、 ドキュメント を参照してください。 イベントハンドラの操作 AWS AppSync Events を使用すると、発行したイベントが処理されたときや、クライアントがチャネルをサブスクライブしようとしたときにビジネスロジックを定義できます。これは、チャネル名前空間内に定義された関数であるイベントハンドラーで行われます。イベントハンドラーはオプションであり、チャネル名前空間の範囲内にあります。AWS AppSync Events は onPublish ハンドラと onSubscribe ハンドラの 2 種類のハンドラをサポートしています。onPublish ハンドラーは、イベントが受信されたときに呼び出され、接続されているクライアントにイベントがブロードキャストされる前に実行されます。onPublish ハンドラから、イベントペイロードの形状を変換したり、イベントをフィルタリングしたり、発行されたイベントを拒否したりできます。ハンドラーは APPSYNC_JS ランタイムで実行されるため、JavaScript を記述するだけです。たとえば、イベントを変換するには、 map をイベント配列に適用し、イベントの id とイベントの payload を返すようにします。 export function onPublish(ctx) { return ctx.events.map(event => ({ id: event.id, payload: { ...event.payload, message: event.payload.message.toUpperCase() } })) } 特定のイベントを除外し、サブスクライブしているクライアントにブロードキャストされないようにするためには、リストからフィルタリングし、ブロードキャストしたい部分だけを返します。たとえば、イベントの配列に対して filter を呼び出すことができます。 勝率が 90 % を超えるゲームのイベントのみをブロードキャストしたい場合を想像してみましょう。 export function onPublish(ctx) { return ctx.events.filter(event => event.payload.odds > 0.9) } フィルタリングを使えば、イベントをサイレントに破棄できますが、イベントを破棄するときにパブリッシャーにエラーを返すこともできます。 たとえば、イベントに必ず挨拶メッセージが含まれるようにして、パブリッシャーにエラーを返す場合は以下のようになります。 export function onPublish(ctx) { return ctx.events.map(event => { if (!event.payload.message) { return { ...event, error: 'You should always included a greeting.' } } return event }) } クライアントがサブスクリプションを確立しようとするときに、onSubscribe ハンドラが呼び出されます。 util.unauthorized() を呼び出すことでサブスクリプションを拒否できます。 Amazon Cognito User Pools で認証されたユーザーを自分のチャネルのみに制限したい場合は以下のようになります。 export function onSubscribe(ctx) { if (ctx.info.channel.path !== `/messages/inbox/${ctx.identity.username}`) { console.error(`user ${ctx.identity.username} tried connecting to wrong channel: ${ctx.info.channel.path}`) util.unauthorized() } } クライアントは、パターン /messages/inbox/<username> に一致するチャネルにのみサブスクライブできるようになりました。 イベントドリブンアーキテクチャ AWS AppSync Events は、イベントドリブンアーキテクチャパターンにシームレスに組み込むことができます。Amazon EventBridge を使えば、API の送信先を設定して、イベントを AWS AppSync Events の HTTPS エンドポイントに転送できます。 EventBridge コンソールで、新しい接続を作成し、認証タイプは [API Key]を選択します。 API キー名 には x-api-key と入力し、 Value にはあなたの API キーの値を入力します。次に、新しい API destination を作成します。 API destination endpoint には https://<HTTP_DOMAIN>/event という形式を使用します。ここで <HTTP_DOMAIN> は、前に控えた HTTP ドメインです。 HTTP メソッド は POST に設定します。 Connctions type は、新しく作成した接続を選択し、を作成します。これで、この宛先をターゲットに設定したルールを作成できます。ターゲットの入力パス (InputPath) には "$.detail" を指定すれば、イベントの詳細全体が Event API に転送されます。 AWS AppSync Events にイベントを転送できるようになりました。たとえば、次の イベントの詳細 を使用して EventBridge に発行できます。 { "channel": "/default/introductions", "events": [ "{\"message\":\"Hello from EventBridge!\"}" ] } API の機能の探索 API に複数の認証モードを設定し、それぞれのチャネル名前空間で異なる認証動作を設定することができます。API にカスタムドメインを関連付けて、さらなる保護のために AWS Web Application Firewall を付加できます。また、 Amazon CloudWatch メトリクス および Amazon CloudWatch Logs との統合もサポートされているため、API のパフォーマンスを完全に把握できます。 今後の展開 このブログでは、AWS AppSync Events を紹介し、AWS AppSync Event API を始める方法を説明しました。チャネル名前空間、チャネル、ハンドラ、Amazon EventBridge との統合方法についても説明しました。 AWS AppSync Events のリリースは重要なマイルストーンとなりますが、これはスタートに過ぎません。間もなく、双方向の WebSocket とデータソースのサポートを追加する予定です。これにより、カスタムデータソースと送信先を作成でき、Amazon DynamoDB や Amazon Aurora などのデータソースを使用してイベントを拡張または永続化できるようになります。ハンドラーの代替として AWS Lambda 関数のサポートも予定しています。また、型の形状を簡単に共有および適用できるようにするため、スキーマのバリデーションをサポートする予定です。乞うご期待ください。 まとめ AWS AppSync Events は、AWS AppSync が利用可能なすべてのリージョンで利用できるようになりました。最初のイベント API を作成するには、AWS AppSync コンソールにアクセスしてください。AWS AppSync Events はサーバーレスで、AWS AppSync Event API 操作と実際のリアルタイム接続時間に対してのみ料金が発生します。毎月 25 万回の無料のリアルタイム Event API 操作をご利用いただけます。AWS AppSync Events の詳細については、 ドキュメント をご覧ください。価格に関する詳細は、 価格 ページをご確認ください。 AWS AppSync を使えば、アプリケーションをイベント、データ、AI モデルに簡単に接続できます。AWS AppSync Events を利用すれば、任意のイベントソースから発行された更新を、サーバーレス WebSockets 経由でサブスクライブしているクライアントに送信し、リアルタイムの体験を実現できます。また、AWS AppSync GraphQL では、単一の GraphQL API エンドポイントを使って、アプリケーションを複数のデータベース、マイクロサービス、AI モデルに接続できます。 本記事は「 Announcing AWS AppSync Events: serverless WebSocket APIs to power real-time web and mobile experiences at any scale 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

この記事は、2024 年 10 月 15 日に Tarush Gupta によって執筆された「 Enhance your real-world skills with AWS Cloud Quest and AWS Jam 」を翻訳したものです。 今日の急速に進化するテクノロジー環境では、実践的な経験とスキルを身につけることが重要であり、キャリア形成に役立ちます。AWS はこのニーズを認識しており、AWS Cloud Quest や AWS Jam などの魅力的でインタラクティブな学習リソースを提供しています。これらの学習体験は技術的な概念を教えるだけでなく、実践的なスキルを身につけるための没入感のある環境を提供します。AWS が提供するこれらの学習に関する取り組みが、プロフェッショナルな環境で役立つ、実践的なスキルを身につけるのを助ける方法を探ってみましょう。 AWS Cloud Quest とは AWS Cloud Quest はゲームベースの学習体験で、AWS サービスの使い方を楽しく、やりがいのあるものにするために設計されています。学習者は一連の課題、クエスト、パズルを通じて旅に出ることになり、そこでは実際のシナリオを解決するために AWS サービスの知識を適用する必要があります。学習者はタスクを完了することでレベルを上げ、新しいコンテンツを利用できるようになり、ダイナミックで魅力的な方法で AWS の概念に対する理解を深めることができます。クエストの課題をすべて完了するとデジタルバッジが授与され、スキルの習熟度を示すことができます。現在利用可能な AWS Cloud Quest には複数のバージョン (訳者注: カテゴリ、ロールを表します) が用意されており、いくつか例を挙げると、 AWS Cloud Quest: Cloud Practitioner (無料でプレイ可能) 、 AWS Cloud Quest: Solutions Architect 、 AWS Cloud Quest: Generative AI 、 AWS Cloud Quest: Security Specialty などがあり、AWS Skill Builder のサブスクリプションに登録することにより利用可能です。ヘルスケア、金融サービス、自動車および製造向けの AWS ソリューションを深く知りたい方は AWS Industry Quest もあわせてご覧ください。 訳者補足: 2024 年 11 月現在、日本語で学習可能な AWS Cloud Quest のロールは下記の通りです。なお、Cloud Quest 日本語版に関しては こちらの記事 もあわせてご参照ください。 Cloud Practitioner Solutions Architect Machine Learning Generative AI AWS Jam Journey と チーム向け Jam について AWS Jam は、 AWS のサービスとソリューションを実験するためのシミュレーション環境を提供する、もう 1 つの実践的な学習オプションです。これには個人、またはチームの一員として参加可能です。指定された時間枠内で AWS のツールとテクノロジーを使用し、現実世界の課題を解決するための実践的な経験と自信を得ることができます。個人で取り組みたい場合は、機械学習、セキュリティ、DevOps など、12 以上の種類が用意されている AWS Jam Journey をチェックしてください。チーム向けの AWS Jam では、実際のユースケースやシナリオを取り上げたイベントが用意されており、参加者は、AWS のサービスがビジネス上の課題にどのように対処し、イノベーションを推進できるかについて、実践的な洞察を得ることができます。どちらも AWS Skill Builder のサブスクリプションで利用可能です。 特徴 1: ハンズオンによる実践的な学習 AWS Cloud Quest と AWS Jam の主な特徴の 1 つは「実践的な学習を重視していること」です。学習者は情報を受け身で消費するのではなく、シミュレーション環境で AWS のサービスを自ら操作していきます。この実践的なアプローチにより、学習者は実際のシナリオで遭遇する可能性のある課題に対して、実験したり、ミスをしたりしながら、自らの経験から学習することができます。実践的な演習やシナリオに取り組むことで、学習者は実際のプロジェクトや環境で自分のスキルを適用するために必要な自信を身につけ、習熟度を高めます。AWS Jam では、行き詰まった場合に手がかりを求めることも可能ですが、ゲーム内では「ヒントに頼らない問題解決や探索」が奨励されます。学習者が求めるヒントやガイダンスが少ないほど、最後に得られる得点が高くなります！ 特徴 2: 現実世界で役立つ、実用的なスキルの構築 AWS Cloud Quest と AWS Jam は、共に「実際の能力の構築に重点を置いている部分」が従来のトレーニング方法と異なる部分です。AWS Cloud Quest では、リーダーボード、実績、ソーシャル要素などのゲーミフィケーション要素が、学習者が習得と卓越性を目指して努力する動機付けとなります。現実世界の課題とシナリオをシミュレートすることで、学習者は問題解決スキル、批判的思考能力、情報に基づいた意思決定能力を身に付けることができます。これらはすべて、現代のテクノロジー業界で成功するために不可欠な能力です。AWS Jamでは、チームとして協力する機会があり、業務環境で不可欠なコラボレーション、コミュニケーション、チームワークのスキルを育むのに役立ちます。AWS Jam イベントでは、学習者が同僚、メンター、業界の専門家と交流し、ネットワークを広げる機会があります。これらの人脈は、貴重な洞察、キャリアの機会、そしてイベントを超えた協力関係につながる可能性があります。 最後に AWS Cloud Quest と AWS Jam は、AWS のクラウドコンピューティングの技術的スキルを高め、実社会での能力を高めたいと考えている個人にとって非常に貴重なリソースです。これらのプラットフォームは、ゲーミフィケーション要素、実践的な学習体験、現実世界のシナリオを組み合わせることで、学習者がプロフェッショナルな環境で成功するための準備を整える、ユニークで効果的な学習アプローチを提供します。経験豊富な IT プロフェッショナルの方にも、クラウドの旅を始めたばかりの方にも、AWS Cloud Quest と AWS Jam は、絶え間なく変化するクラウドテクノロジーの世界で学び、成長し、優れた能力を身につける機会を提供します。 翻訳は Technical Instructor の 室橋 が担当しました。

これは 2015 年のブログ記事「 Amazon SES Best Practices: Top 5 Best Practices for List Management 」の 2024 年更新版です。効果的なメーリングリスト管理の基本原則は依然として先のブログが参考になりますが、この 9 年間で状況は大きく進化しました。更新された本ブログは、 Amazon Simple Email Service (SES)の顧客に最新のベストプラクティスと洞察を提供し、高い配信率を確保し、強力な送信者の評価を維持することを目的としています。 2024 年版で含まれる主な変更点と更新点は次のとおりです。 悪意を持つ者やボットによる登録を防ぐため、CAPTCHA を使って登録フォームを保護するためのガイダンス 複数のメールボックスプロバイダ (MBP) による 新しい要件 のため、メール配信のバウンス率、苦情率、遅延を監視することの重要性が高まっている Amazon SES の Virtual Deliverability Manager (VDM) ツールの紹介と、それが配信性の問題を特定するのに役立つ簡単な説明 不活性の購読者を積極的に削除することを含む、エンゲージドサブスクライバーリストを維持するための更新された推奨事項 業界全体でワンクリック解除 (one-click unsubscribe) 機能の採用が必須となり、その利点への重点 メールリストを自然に育てる必要性を強調し、購入したリストや同意を得ていないリストの使用を避けること この更新されたガイドラインで紹介されたベストプラクティスに従うことで、Amazon SES のお客様はメールキャンペーンが受信トレイに届く可能性を最大にできます。これらのベストプラクティスに従うことで、購読者の信頼も得られ、メールマーケティングへの投資に対するより高いリターンが得られます。 このブログでは、メール送信の強力な評判を維持し、高い配信率を確保するために役立つ、以下の最新のベスト プラクティスについて説明します。 確認付きオプトイン (ダブルオプトイン) を使用する バウンス、苦情、配信遅延を慎重に監視する 関心が薄れた購読者を削除して、エンゲージメントの高い購読者リストを維持する 簡単に解除できるようにして、クリーンで適切なリストを維持する 自然な方法でリストを育てることで信頼を築く 確認付きオプトイン (ダブルオプトイン) の利用 アクティブで関与するユーザーにターゲットを絞ることは、強力な送信者の評価を維持する上で最も効果的な方法の一つです。この効果が実証されているベストプラクティスは、確認済みオプトイン(ダブルオプトインとも呼ばれる)として知られています。この方法は簡単に実装でき、大変効果的です。ユーザーがウェブサイト上のフォームを使ってメールアドレスで受信登録やスペシャルオファーの申し込みを行った場合、受信の確認メールをリクエストされたアドレスに送信し、メール配信を承諾するリンクをクリックするよう依頼する必要があります。このリンクをクリックすることで、メールアドレスの所有者が明示的にメール受信に同意したことになります。受信者がリクエストを確認後、そのメールアドレスをアクティブな配信リストに追加します。現在ほとんどのユーザーはこのタイプの確認プロセスに慣れており、正当なユーザーは問題なく自身の関心を確認することができます。 オンラインのボットやその他の自動化ツールや不正行為が増えたことで、確認済みオプトインに関する当社の指針は進化を遂げました。高い送信者評価を維持するため、現在はウェブ上の登録フォームを CAPTCHA (またはそれに類する仕組み) で保護することを推奨しています。こうすれば、配信リストへの参加リクエストが実在する人間からのものであり、ボットや不正な自動化ツールではないことが保証されます。リクエストの送信者が人間であることを証明できた後に、初めてそのメールアドレスを受領し、確認メールを送信します。この追加の保護層により、ボットや不正な送信者がユーザーに無断で登録することを防ぎます。 CAPTCHA はダブルオプトインプロセスの基盤となる要素になりました。登録プロセスを CAPTCHA で保護することで、ユーザーに送信されるオプトイン確認メッセージの無作為な送信を最小限に抑えられ、その結果、メールボックスプロバイダーがこうしたメッセージをスパムとしてブロックするリスクが軽減されます。確認メッセージがブロックされてしまえば、ダブルオプトインのプロセスそのものが機能しないためです。 Figure 1: AWS WAF CAPTCHA examples. 確認済みオプトインにより、メール受信者の正当性を事前に検証することで、偽のメールアドレス、タイプミス、ボットや悪意のある送信者による不正な登録などに起因するバウンスの数を削減できます。このような無効なアドレスは送信者評価に悪影響を及ぼすため、非常に重要な対策です。 Figure 2: A diagram showing the ideal confirmed opt-in architecture to limit risk of bot abuse. ウェブ登録フォームに CAPTCHA を追加することで、人間がプロセスに関与していることを証明できます。 リンクをクリックすることにより、メールボックスにアクセスできる人物またはアプリケーションが存在することを証明できます。 受信者が正しいワンタイムパスコード (OTP) をウェブフォームに入力する必要があることで、登録を要求した人物が確認の人物と同一であることを証明できます バウンス、苦情、配信遅延などのイベントを監視することで、メールアドレスが有効で、受信者が確認メッセージをスパムとしてマークしていないことが証明できます。 ウェブフォームの不正使用の兆候がある場合に、確認メッセージを送信する際にサブドメインを使用して、配信性に対する評判への影響を軽減します。 ウェブフォームの不正使用の兆候がある場合は、受信者がメッセージをスパムとしてマークしないように、不正使用を報告する簡単なオプションを受信者に提供します。 確認済みオプトインにより、メッセージを明示的に受信に同意した購読者のみに送信できるようになるため、苦情の発生リスクが更に低減されます。簡単なワンクリック解除のオプションを受信者に提供することで、受信者のコミュニケーション設定を尊重する姿勢を示せます。 多くの成功した送信者は、この確認のタイミングでウェルカムメールを直ちに送信し、以下の 2 つの重要なメリットを得ています。 エンゲージメントを高める: 新規の購読者に温かい歓迎の言葉を伝えながら、うまく再エンゲージメントを促し、ブランドが新鮮な印象を与え続けます。 二重の確認: このようなメールには、受信者の同意を二重に確認し、メール受信の意思を確認するための呼びかけ(CTA: call-to-action) が含まれていることが多いです。 ブランドの信頼性を高める: 受信者が簡単に購読を解除できる方法を提供することで、いつでも購読解除できる自信を持ってもらえます。 バウンス、クレーム、配信遅延を注意深く監視する 更新情報: メールボックス プロバイダによる最近の変更により、これらのメトリクスを監視することがさらに重要になりました。2024 年 2 月以降、Google、Yahoo、Microsoft などのメールボックス プロバイダは、すべての大量送信者に 0.3%以下のスパム苦情率を維持することを求めています。これらのメールボックス プロバイダは、低いスパム苦情率を維持することで、配信率の向上、送信者の評価の維持、受信者の受信トレイの使用体験向上につながると説明しています。 最新の業界基準と要件を完全に理解するために、次のことをお勧めします: 概要を読む : 主要なコンプライアンス ガイドラインを把握する ウェビナーを視聴する : AWS チームと Gmail チームによって提示された詳細な内容とベストプラクティスについて掘り下げましょう。 Amazon SES では、 バウンスとクレーム 、 配信遅延イベント に関する実際のフィードバックを イベント配信機能 を通じて入手できます。これにより、問題のあるメールアドレスを素早く特定して削除し、健全な購読者リストを維持することができます。 ハードバウンスやクレームを受け取った場合は、そのメールアドレスをリストから削除し、根本原因を調査することが不可欠です。例えば、新規登録でのバウンスやクレーム率の急増は、フェイクの登録が原因かもしれません。そのような場合は、確認付きオプトイン(メーリングリスト構築におけるベストプラクティス)を活用することで、この問題を軽減できます。サインアップと OTP に別のドメインを使用すれば、マーケティングやプロモーション向けメッセージとは別に、サインアップやその他のトランザクション メッセージのバウンスやクレームを区別できます。詳細は こちら をご覧ください。 Amazon SES の Virtual Deliverability Manager (VDM)は、追加のダッシュボードを構築する必要がなく、配信可能性のトレンドと潜在的な問題を特定できる機能です。VDM は、送信データに関する深い洞察を提供し、配信率の向上に役立つアクションを示してくれます。VDM を使えば、バウンス率、クレーム率、その他の主要な指標(KPI)を監視し、メール配信の成功指標を把握できます。VDM を活用すれば、アカウント レベルの統計情報からメッセージレベルまでドリルダウンし、配信可能性の問題を特定できます。これにより、すべての配信率データの中から問題のあるメールを見つける必要がなくなります。主な機能は次のとおりです: バウンスの詳細 : VDM を使えば、受信者のメールアドレス、タイムスタンプ、メールボックスプロバイダから直接受け取る SMTP レスポンスコードごとにバウンスしたメールを特定できます。バウンスの種類 (永続的/一時的) や受信者のドメインごとにメールをグループ化して分析し、メッセージの遅延が大きな問題に発展する前に適切な対処ができます。 苦情 : メールをスパムとしてマークした受信者を特定し、アクティブなメーリングリストから削除できます。 注意点: Gmail の受信者向けの指標追跡に関しては、 Google Postmaster Tools も監視し、スパム苦情率を低く抑える必要があります。 配信メトリクス : 配信の試行、再試行、成功を監視し、リアルタイムのデータに基づいて配信率の向上に向けた意思決定ができます。 VDM は、送信者の評価や配信率を損なうおそれのあるバウンスや苦情などの潜在的な問題を事前に警告してくれます。早期に対処することで、メールが必ず受信トレイに届くよう配信率を持続的に改善できます。 VDM は有料サービスですが、Amazon SES ユーザー向けに 無料でテストできる仕組み があります。 詳しくは次のリソースを参照してください: Explore the Improve Email Deliverability with VDM : VDM の機能と利点について学ぶリソース Amazon QuickSight を使用して AWS Console の外部から VDM と DMARC レポートにアクセスする方法を確認する Amazon SES のバウンスや苦情の監視に関する追加のガイダンスは、次のリソースを参照してください: Amazon SES ドキュメンテーション: Amazon SES の送信アクティビティの監視 Amazon SES におけるメール配信可能性の理解 Amazon SES ブログ記事: Analyzing Amazon SES event data with AWS Analytics Services Handling Bounces and Complaints Improve email delivery rates with email delivery and engagement history for every email Amazon SES – How to track email deliverability to domain level with CloudWatch 非アクティブな受信者を削除して熱心な購読者リストを維持 メールマーケティング担当者は、購読者がメールを開封していない場合、またはメール内の行動を促す呼びかけ (CTA) に対応していない場合、送信したコンテンツにはもう関心がないという前提のもとで運営する必要があります。このカテゴリに該当する購読者は、定期的にメーリングリストから削除して、購読者リストが健全で興味をそそられるようにする必要があります。次の 2 つのアプローチで購読リストを定期的に見直して更新することで、キャンペーンの成功と配信率を高めましょう。 Amazon SES による購読者のエンゲージメントのトラッキング Amazon SES には、イベント、メトリックス、統計を使用して送信アクティビティをモニタリングする方法が用意されています。これらのモニタリング方法を使用して、送信したメールに対する顧客のエンゲージの割合を測定できます。たとえば、 SES のドキュメント で説明されている設定セットでカスタムメールドメインの使用を設定する場合、SES のイベントパブリッシングを利用することで、全体的な開封率とクリックスルー率を確認できます。 Figure 3: Serverless Architecture to Analyze Amazon SES events E メール送信アクティビティを詳細なレベルでトラックするには、AWS ブログ記事「 Analyzing Amazon SES event data with AWS Analytics Services 」を参照してください。 エンゲージメントがない購読者を積極的に削除 購読者がメーリングリストに登録しても、メッセージの開封やクリックを行わずエンゲージしていないシナリオを想像してみてください。このアクティビティの欠如は、購読者の関心がなくなっていることを示している可能性があります。これに対処するには、業界標準に基づいて適切なエンゲージメント期間（たとえば、開封やクリックがない期間が 6 か月間）を設定することをおすすめします。ただし、購読者にメールを送信する頻度によっては、この期間を調整する必要がある場合があります。たとえば、毎日ニュースレターを送信する場合、操作がない期間が 6 か月間で購読者を削除というのは長すぎる可能性があります。逆に、毎月のアップデートのみを送信する場合は、6 か月の期間を設定することは適切な場合があります。重要なのは、適切なバランスを見つけることです。明らかに興味を失った購読者は削除しますが、通常のメール頻度ほど頻繁に反応しない購読者は急いでリストを選別しないでください。特定のメール頻度に合わせてエンゲージメント期間を調整することで、購読者リストをアクティブでエンゲージメントの高い状態に保つことができます。 「ウィンバック」メールキャンペーンの検討 完全に非アクティブな購読者をリストから削除する前に、特別な「ウィンバック」メールを送信することを検討してください。再エンゲージメントを図るこの最後の試みは、貴重な購読者を取り戻すための効果的な戦略となり得ます。ウィンバックメールには、受信者が送信したメッセージに再び関心を持ってもらえるよう、明確で説得力のある行動を促す呼びかけ (CTA) を記載する必要があります。これには、ユーザーの設定を更新したり、メッセージに関心を示したことを確認したりすることが含まれる場合があります。これらの購読者にもう一度チャンスを与えることで、リストの一部を再度有効にしても、それらの受信者を維持できる場合があります。ただし、ウィンバックメールでも返答が得られない場合は、アクティブなメーリングリストからそれらのアドレスを削除して、健全で熱心な購読者ベースを維持するのが最善です。 確認済みのダブルオプトインプロセスを経て最初にオプトインした購読者であっても、時間が経つと非アクティブになる可能性があります。これらのメールアドレスは破棄され、ドメイン所有者によってスパムトラップに変換されることがあります。スパムトラップは、リスト作成や長期的なリストハイジーンに関するベストプラクティスに従っていない可能性のある送信者を特定するために組織が使用するメールアドレスです。これらの使用頻度の低いアドレスに電子メールを送信し続けると、いくつかの悪影響が発生する可能性があります。そのドメインがメールボックスプロバイダーでの評判が悪くなったり、リアルタイムのブロックリストに載ったりして、複数のメールボックスプロバイダーへの配信に影響を与える可能性があります。場合によっては、Amazon SES サービスが停止されることがあります。 これらの潜在的な落とし穴を回避し、送信者の評判を維持するには、エンゲージメントのない購読者を積極的に削除することが唯一の方法です。 このトピックの詳細については、次のリソースを参照してください。 Analyzing Amazon SES event data with AWS Analytics Services Amazon SES 送信アクティビティのモニタリング So You’ve Hit a Spamtrap? メールに反応しない購読者を積極的に削除すると、購読者ベースを新鮮で魅力的な状態に保ち、全体的な配信率とキャンペーンの成功率を向上させることができます。追加の利点として、非アクティブな購読者を排除することで、真に関心のある購読者にのみ連絡できるため、メール送信コストが削減され、メールキャンペーンの投資収益率が向上します。 非アクティブな購読者を削除することは、確認済みのオプトインプラクティスを効果的に補完するものであり、健全でパフォーマンスの高いメーリングリストを維持するのに役立ちます。 登録解除を簡単にし、クリーンで規制に準拠したリストを維持できるようにする 更新:主要なメールプロバイダーによる 最近の変更 により、受信者に明確で使いやすい登録解除オプションを提供することがさらに重要になっています。 2024年2月の時点で、GoogleとYahooはすべてのメールの一括送信者に対し、メッセージ内に目立つ購読解除リンクを含めることを義務付けています。2024年6月には、 ワンクリック購読解除ヘッダー （ RFC 2369 および RFC 8058 で定義）の実装も業界全体で義務付けられました。 Figure 4: A diagram of one-click unsubscribe flow. 業界全体を対象とした新しい一括送信者要件は、最終的に送信者と受信者の両方に次のメリットをもたらします。 スパム苦情の軽減 — 簡単に登録解除できるオプションにより、不満を抱いている受信者がメールをスパムとしてマークする可能性が低くなります。これにより、送信者の評判が好調に保たれます。 送信者評価の向上 — 購読者がエンゲージし、同意を得たクリーンなメールリストを作成することで、送信者の評価が健全に保たれ、メッセージがスパムフォルダではなく受信トレイに確実に届きます。 メール送信に関する購読者の希望を尊重することが重要です。受信者にコミュニケーション設定を管理するためのわかりやすく簡単な登録解除方法を提供することで、メーリングリストをクリーンでコンプライアンスに準拠したものに保ち、送信者の評判を維持するのに役立ちます。 米国 、 カナダ 、ヨーロッパやアジアの一部を含む多くの地域では、送信者に明確でアクセスしやすい登録解除メカニズムを提供することを義務付ける法律が採用されています。これらの規制に従うことで、送信やローカルメッセージングの法律に関連する潜在的な法的問題を回避できます。 Amazon SES には ドキュメント に記載されている一括送信者要件をサポートする基本的なサブスクリプション管理機能があります。SESのお客様の中には、エンドユーザーからの登録解除要求を処理するために、より包括的な独自のシステムを開発および導入することを選択しているお客様もいます。このトピックの詳細については、AWS ブログ記事「 Using one-click unsubscribe with Amazon SES 」を参照してください。 リストを自然に育てて信頼を築く 近道の誘惑を避ける ブローカーから購入したメーリングリストを使用するなど、近道を取りたくなるかもしれません。ただし、これらの「オプトイン」アドレスは、多くの場合、あなたのものではなく、ブローカーのリストにサインアップした受信者のものです。これらの自然ではないリストに頼ると、悲惨な結果につながる可能性があります。 スパムの苦情: メールの受信に同意しない受信者は、メールをスパムとしてマークし、送信者の評判を傷つける可能性がはるかに高くなります。 法的問題: 多くの国で、特に新しい 0.3% 未満のスパム率要件では、同意のないメーリングリストの使用を禁止する厳しい法律が制定されています。 登録解除と信頼の喪失: 求められていないメールを送信すると、登録解除率が高くなり、ブランドの評判が損なわれる可能性があります。 リストを自然に構築することに焦点を当てる ブローカーからリストを取得する代わりに、確認付きオプトインや簡単な登録解除のオプションなど、これまでに説明したベストプラクティスに従って、自然にメーリングリストを作成することに集中してください。これにより、コンテンツを真に受け取りたいと思っている熱心な購読者を引き付けて維持することができ、送信者と受信者の良好な関係と信頼を築くことができます。 個人の好みを尊重する 組織内であっても、各受信者のコミュニケーションの好みを尊重することが重要です。ブランド A からのメールにサインアップした場合、ブランド A とブランド B が同じ会社のものであってもブランド B からのメッセージを受け取りたいとは限りません。このような種類のブランド間の迷惑メールを送信すると、評判が悪くなり、スパムの苦情につながる可能性があります。このよくある落とし穴を避けるには、ブランドごとに個別のメーリングリストを作成します。これにより、受信者は明示的にオプトインしたコンテンツのみを受け取ることができ、信頼とエンゲージメントが高まります。 自然に成長し、エンゲージメントの高いメーリングリストがもたらす長期的なメリットは十分に文書化されており、配信率の向上、開封/クリック率の向上、メールマーケティングへの投資収益の向上などがあります。 スパムフォルダではなく受信ボックスに振り分ける：リスト管理の効率化がもたらすメリット この最新ガイドでは、Amazon SES のお客様が送信者の高い評判を維持し、高い配信率を確保するのに役立つ、E メールリスト管理の 5 つの重要なベストプラクティスを探ってきました。 最初に、確認済みオプトイン（ダブルオプトイン）の重要性と、CAPTCHA を組み込むことがボットや悪意のあるユーザーの登録を防ぐための基本的な要素になった経緯について説明しました。購読者の正当性を事前に検証することで、無効なアドレスによる影響を最小限に抑え、フォームの不正使用による苦情の可能性を減らすことができます。 次に、バウンス、苦情、配信遅延などの主要な指標を注意深く監視する必要性が高まっていることを強調しました。E メールプログラムの配信可能性に関する重要なインサイトを提供できる Amazon SES Virtual Deliverability Manager のような E メール管理ツールや機能について説明しました。送信者の評判を維持し、メッセージが受信トレイに流れ続けるためには、配信性の問題に早期に対処することが重要です。 また、非アクティブな受信者を積極的に削除したり、ターゲットを絞った「ウィンバック」キャンペーンを検討したりするなど、エンゲージメントの高い購読者リストを維持するための戦略についても説明しました。リストを新鮮で応答性の高い状態に保つことで、受信ボックスへの配置やキャンペーンのパフォーマンスが向上するという形で成果が得られます。 受信者が簡単に登録解除できるようにすることは、コンプライアンスのためだけでなく、信頼を築き、スパム苦情を減らすためにも同様に不可欠となっています。メールボックスプロバイダーが現在求めているワンクリック購読解除の標準は、送信者と受信者の両方にメリットをもたらします。 最後に、購入したメーリングリストのような近道よりも、自然にリストを成長させることの重要性を強調しました。自社のブランド内であっても、個人の好みを尊重することで、コンテンツに真に関心を持つ購読者を引き付け、維持することができます。 メーリングリスト管理の5つのベストプラクティスを実践することで、顧客やエンドユーザーとの長期的なコミュニケーション手段となるメールリスト形式のマーケティング資産を構築して維持できるようになります。 ご不明な点がある場合や詳細なガイダンスが必要な場合は、 SESフォーラム でお気軽にお問い合わせください。私たちは、お客様が進化するEメール環境に対応し、Amazon SESへの投資の可能性を最大限に引き出すお手伝いをします。 著者について Brett Ezell is your friendly neighborhood Solutions Architect at AWS, where he specializes in helping customers optimize their SMS and email campaigns using Amazon Pinpoint and Amazon Simple Email Service. As a former US Navy veteran, Brett brings a unique perspective to his work, ensuring customers receive tailored solutions to meet their needs. In his free time, Brett enjoys live music, collecting vinyl, and the challenges of a good workout. And, as a self-proclaimed comic book aficionado, he can often be found combing through his local shop for new books to add to his collection. Zip is an Amazon Pinpoint and Amazon Simple Email Service Sr. Specialist Solutions Architect at AWS. Outside of work he enjoys time with his family, cooking, mountain biking and plogging. Jesse Thompson is an Email Deliverability Manager with the Amazon Simple Email Service team. His background is in enterprise development and operations, with a focus on email abuse mitigation and encouragement of authenticity practices with open standard protocols. Jesse ’ s favorite activity outside of technology is recreational curling. 翻訳はソリューションアーキテクトの松岡勝也が担当しました。原文は こちら です。

AWS Amplify ホスティング と Amazon Simple Storage Service (Amazon S3) の統合を発表します。これにより、数回クリックするだけで、S3 バケットに保存されたコンテンツを使用して静的ウェブサイトをデプロイし、コンテンツ配信ネットワーク (CDN) 経由で配信できるようになりました。 AWS Amplify ホスティングは、静的サイトをホスティングするためのフルマネージド型サービスで、ウェブサイトのデプロイのさまざまな側面に対応しています。また、SSL を使用したカスタムドメイン設定、リダイレクト、カスタムヘッダー、 Amazon CloudFront を活用したグローバルで利用可能な CDN へのデプロイなどの利点があります。 静的ウェブサイトをデプロイするとき、Amplify は S3 バケットとデプロイされたウェブサイトとの接続を記憶しているため、S3 バケット内のウェブサイトコンテンツに変更を加えた場合でも、ワンクリックで簡単にウェブサイトを更新できます。静的ウェブサイトホスティングには AWS Amplify ホスティングの使用をお勧めします。大規模なセットアップをすることなく、より合理的かつ迅速にデプロイできるからです。 Amazon S3 コンソール から開始する統合の仕組みは次のとおりです。 Amazon S3 コンソールを使用して静的ウェブサイトをデプロイする この新しい統合を使用して、私の S3 バケットから直接個人ウェブサイトをホストしてみましょう。 はじめに、Amazon S3 コンソールのバケットに移動します。この S3 バケットのすべてのコンテンツのリストを次に示します。 AWS Amplify ホスティングとの新しい統合を使用するには、 [プロパティ] セクションに移動し、下にスクロールして [静的ウェブサイトホスティング] を見つけ、 [Amplify アプリを作成] を選択します。 すると、Amplify ページにリダイレクトされ、S3 バケットの詳細が入力されます。ここでは、 [アプリ名] と [ブランチ名] を設定します。次に、 [保存してデプロイ] を選択します。 数秒以内に AWS Amplify が静的ウェブサイトをデプロイします。 [デプロイされた URL にアクセス] を選択してサイトにアクセスできます。静的ウェブサイトの S3 バケットに、さらに変更を加えた場合は、 [アップデートをデプロイ] ボタンを選択して、Amplify コンソールにアプリケーションを再デプロイする必要があります。 プログラムによるデプロイでは AWS コマンドラインインターフェイス (AWS CLI) を使用することもできます。そのためには、AWS Amplify ダッシュボードから APP_ID や BRANCH_NAME などの必須パラメータの値を取得する必要があります。デプロイに使用するコマンドは次のとおりです。 aws amplify start-deployment --appId APP_ID --branchName BRANCH_NAME --sourceUrlType=BUCKET_PREFIX --sourceUrl s3://S3_BUCKET/S3_PREFIX Amplify ホスティングがウェブサイトの URL を生成したら、オプションで静的ウェブサイト用のカスタムドメインを設定できます。そのためには、AWS Amplify のアプリに移動し、ナビゲーションペインで [カスタムドメイン] を選択します。次に、 [ドメインを追加] を選択して、静的ウェブサイトのカスタムドメインの設定を開始します。カスタムドメインの設定について詳しくは、 Amplify ホスティングユーザーガイド をご覧ください。 次のスクリーンショットでは、カスタムドメインを使用して静的ウェブサイトを設定しています。Amplify は、私のドメイン用の SSL/TLS 証明書も発行して、すべてのトラフィックが HTTPS で保護されるようにします。 これで、静的サイトの準備が整いました。 https://donnie.id で確認できます。 知っておくべきこと より多くの利用可能な機能 – AWS Amplify ホスティングには、静的ウェブサイトに使用できる機能が他にもあります。詳細については、 AWS Amplify 製品ページ をご覧ください。 デプロイオプション – Amplify ホスティングコンソール 、 AWS CLI 、または AWS SDK を使用して、Amazon S3 から静的ウェブサイトのデプロイを開始できます。 料金 – 料金情報については、 Amazon S3 の料金ページ と AWS Amplify の料金ページ をご覧ください。 可用性 – Amplify ホスティングと Amazon S3 の統合を、 Amplify ホスティングが利用可能な AWS リージョン でご利用いただけるようになりました。 この新しいインテグレーションで、静的ウェブサイトの構築を始めましょう。AWS Amplify を使用した Amazon S3 静的ウェブサイトホスティングの詳細については、 AWS Amplify ホスティングユーザーガイド をご覧ください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

パブリックセクター 澤です。AWS の高等教育機関向けの教育プログラムである AWS Academy で、データセンターの技術職のキャリアにつながるコースの日本語版が新たにリリースされましたので詳細をご紹介します。 現在、日本で展開しているAWSの無料の教育プログラムには 、16 歳以上の方ならどなたでも無料で参加できるセルフラーニング型の AWS Educate と高等教育機関（大学、専門学校、高専、公的な職業訓練機関）でのクラウドスキル習得のための授業を支援するための AWS Academy のふたつがあります。 AWS Academy は 2018 年にスタートした高等教育機関でのクラウドスキル教育の授業を支援する無償の教育プログラムです。AWS Academy はクラウドスキル教育を担う教員をAWSが支援することで、より多くの学生がクラウドの授業の受講の機会を得ることができる教育の仕組みを構築していただくためのプログラムです。現在、世界で 7,500 以上、日本では 200 以上の高等教育機関が加盟し、授業で活用されています。AWS Academy に加盟した機関の教員は自身のスキル習得の他にメンバーポータルから授業を登録し、AWS Academy のコース教材を使った授業を行うことができます。メンバーの教員は以下のようなリソースが提供されます。 教員向けのクラウドや指導方法に関するトレーニング（対面あるいはオンラインでAWSの講師が実施） 授業の受講者向けのラボ環境であるLearnerLab という実際に AWS を利用する演習県境 授業用のオンライン教材 教員メンバー向けの情報交換のためのオンラインフォーラム 教員メンバーの交流の機会 AWS Academy は以下のような流れで利用します。 機関代表者を決めて教育機関として加盟する。（機関代表者は加盟後に変更可能です。） 機関代表者が教員メンバーを募り希望者をノミネートする。（専用のLMS上で簡単な作業を行うだけの簡単な作業です。） ノミネートされた教員はメンバーになり、自身でクラウドを教えるためのリソース（教材、教員メンバーが参加するフォーラムへのアクセス、教員向けワークショップ）などが利用できるようになる。 教員メンバーLMS内でクラスを作り受講する学生を招待する。 招待された学生がクラスに参加し、教材や演習環境にアクセスする。 設定されたクラスの終了後一定期間で演習環境は削除される。（学生はクラス退出等特に何もする必要がなくリソースが残るといった心配はない。） 2024年11月1日現在、以下のコースが提供されていて、このたび新たにデータセンターの技術者を目指す学生の方に必要な知識を身に着けていただくことができる「AWS Academy Data Center Technician」と「AWS Academy Engineering Operations Technician」の日本語での提供がはじまりました。 図：AWS Academy で提供されているコースと日本語版のリリース状況 (図中の Foundation は初級 Associate は中級を意味します。時間は目安です。) 「AWS Academy Data Center Technician」提供の背景として、世界的な計算ニーズの増大化に伴うデータセンターの増設で、国内外でデータセンターを運営する人材のさらなる育成が急務になっていることがあります。 コースカリキュラムの学習内容は、AWS のデータセンターにだけ特化したものではなく、広く一般的にデータセンターで業務に初めて就こうとされている方々を想定したものです。そのため他の AWS Academy のクラウドスキル習得のためのカリキュラムと異なり、サーバの仕組み、ネットワークの仕組みなどといった、ハードウェアの基本事項を中心にその構造や仕組みを学習できるようになっています。もちろん、CPU や メモリといった内部の動作についても学習することができます。また、OS、ブラウザやコマンドといった実際に操作して作業をする対象となるソフトウェアやアプリケーション、ツールの一般的な役割や仕組みについてもトピックとして取り上げられています。その中には興味深いことに、Microsoft Office なども含まれています。 このような内容ですので、カリキュラムの目的はデータセンターエンジニアですが、コンピュータのハードウェアレベルの基本を学習したい方々にもご活用いただけます。 このコースの受講にあたり、前提のスキルや知識は特に設定されていません。日本でいえば、IT パスポートや基本情報レベルの知識があれば、より理解が深まったり、よりスピーディーに学習が進むかもしれませんが、コースの受講者には IT に関する前提知識がなくても学習を進められる内容になっています。そのため、情報系以外の学部学科やコースの方でも学習いただけます。 英語版での授業をすでに開始されている神田外語学院デジタル情報コース講師　山岸明倫様から次のようなコメントをいただきました。 “神田外語学院では、国籍や文化など多様な背景を持つ学生が集い、それぞれの個性を伸ばす環境が整っています。英語が苦手な学生も、入学後には飛躍的に成長し、多くが英語版Data Center Technicianコースを修了しました。他に類を見ないAWS Academyの高品質な教材でITスキルを磨き、ぜひDCエンジニアというキャリアに挑戦してほしいです。” また新しい日本語コースでの教育を計画されている福岡デザイン＆テクノロジー専門学校／神戸・甲陽デザイン＆テクノロジー専門学校　教務部長　大西貫士様からは以下のようなご期待をお寄せいただきました。 “ クラウドの利活用が急増する中で、データセンターエンジニアは業界から求められる人材であると捉え、今後育成に注力する予定でした。AWS Academy Datacenter Technicianコースは、インフラスキルを学ぶ本校学生が、さらに高い専門性を身に付けることができる教育コンテンツとして、非常に期待しています。また本コースはベンダーに寄らず、汎用的にデータセンターエンジニアとしての知識・スキルが学べるので、学生にとっても新たなキャリアへチャレンジできる機会と考えています。” AWSのデータセンターについて、少しご紹介します。AWSのデータセンターはリージョンがある東京一円のエリア、大阪一円のエリアに複数の場所にあり、東京リージョン、大阪リージョンの安定したサービスを提供するため様々な職種の多くの人が働いています。データセンター内のクラウドサービスが稼働するサーバやネットワーク機器の設置・管理・運用をするサーバーエンジニアの他にも、機械や電気設備の運用や保守を担うファシリティエンジニア、データセンターの設計を担うエンジニア、保守を担うエンジニア、建物を管理するエンジニア といった多様な職種の方がデータセンターの運営に携わっています。女性の技術者も多く活躍していて、ジェンダーダイバーシティを大切にするカルチャーも強く根付いています。英語を使う機会も多く、働きながらグローバル人材として必要なコミュニケーションスキルを身に着けたり、もちろんクラウドスキルそのものを学ぶ機会もありますので、ご自身で長期的なキャリアをデザインしていくことが可能です。 データセンターで働く若手技術者の声： ”データセンター内での業務では、サーバーやネットワーク機器などのハードウェアの設置やメンテナンスを行うほか、これらの機器にトラブルが発生した際には、問題の特定と解決を行うトラブルシューティングも担当しています。これらのトラブルはお客様の業務に大きな影響を与える可能性があるため、迅速かつ的確な問題解決が求められます。緊張感のある仕事ではありますが、多様なトラブルに対して試行錯誤を重ねながら自ら解決できたときには、大きなやりがいを感じます。 現在、ネットワーク化は日本国内にとどまらず、世界中で進んでおり、データセンターは重要なインフラとして社会を支える存在となっています。私もこの流れに乗り続けるため、将来は海外のデータセンターで働き、常に学びを深めていきたいと考えています。” データセンター オペレーションズ 　サーバーエンジニア　小林　仁美　(入社2年目) AWS の教育プログラムがクラウド人材だけではなく日本国内でのデータセンター人材育成を加速できるよう、高等教育機関と連携をはかりたいと考えています。また、データセンターの技術者という職業を知らないという学生も多いかと思いますので、クラウドに関わるキャリアの多様さについての理解促進にも努めたいと思います。 本投稿はインフラストラクチャーオペレーションズ　プログラムマネージャー菊池、トレーニングサービス本部AWS Academy 担当平賀の協力を得てパブリックセクター高等教育・研究担当DXアドボケート澤が執筆しました。 問い合わせ　aws-jpps-er@amazon.com 　(AWS高等教育機関　相談窓口)

10 月 28 日、私たちは Amazon Elastic Container Service (ECS) の 10 周年と、クラウドで可能なことの限界を押し広げてきたそのすばらしいジャーニーをお祝いしたいと思います! Amazon Web Services (AWS) で Docker コンテナの実行を効率化するソリューションとして始まったものが、シームレスなコンテナオーケストレーションを実現する AWS Fargate を使用したサーバーレスオプションなど、優れたパフォーマンスと運用のシンプルさの両方を提供する基盤テクノロジーへと進化しました。 過去 10 年間で、Amazon ECS は数え切れないほどの組織にとって信頼できるソリューションとなり、インフラストラクチャの課題に悩まされることなく運用を強化するために SmugMug などのお客様が頼りにする信頼性とパフォーマンスを提供してきました。 SmugMug の Principal Engineer である Andrew Shieh 氏は、Amazon ECS が、AWS にシームレスに移行したり、PB 規模の写真を Amazon Simple Storage Service (Amazon S3) に移行するなど、膨大なデータの操作を効率的に処理したりする際に「縁の下の力持ち」として役立ってくれたと述べています。「コンテナのスピンアップが驚くほど速いため、お客様にすばらしいエクスペリエンスを提供できます」と同氏は付け加えます。このような信頼できるサポートのおかげで、Amazon ECS はデベロッパーやプラットフォームチームに好まれ、長年にわたってソリューションのスケールとイノベーションに役立っています。 2010 年代初頭、Docker などのコンテナ化されたサービスが普及するにつれて、デベロッパーは、この新しいパラダイムでアプリケーションを管理およびスケールする効率的な方法を探し始めました。従来のインフラストラクチャは扱いにくく、コンテナの大規模な管理は困難でした。Amazon ECS は 2014 年に登場しました。これはまさに、デベロッパーがコンテナの大規模な導入を検討していた時期でした。Amazon ECS は、AWS でのコンテナオーケストレーションを合理化する、信頼性の高いフルマネージドソリューションを提供しました。チームは、クラスターや複雑なインフラストラクチャの管理のオーバーヘッドなしでアプリケーションの構築とデプロイに注力でき、クラウドネイティブ開発の新しい時代を切り拓きました。 Amazon ECS チームがサービスの構築に着手したとき、そのビジョンは明確でした。Amazon ECS を立ち上げた Product Manager であり、現在は VP of Next Generation Developer Experience を務める Deepak Singh は当時、「当社のお客様は、AWS と深く統合され、大規模に機能し、成長に合わせて拡張できるソリューションを求めていました」と述べていました。 Amazon ECS は、スケーラビリティ、可用性、回復力、セキュリティなど、AWS が提供する最高の機能を使用して、お客様が安心して本番環境でアプリケーションを実行できるように設計されました。 進化 Amazon ECS は、過去 10 年間、お客様のために一貫してイノベーションを続けてきました。これは AWS におけるコンテナイノベーションジャーニーの始まりであり、企業がアプリケーションを構築および管理する方法を変革した、コンテナ関連サービスのより広範なエコシステムへの道を開きました。 Smartsheet は、Amazon ECS、特に AWS Fargate がこれまでに同社のビジネスにもたらした大きな影響を誇らしげに称賛します。「当社のチームは、より頻繁にデプロイし、スループットを増大させ、デプロイにかかるエンジニアリング時間を数時間から数分に短縮できます。週 1 回だったデプロイは、1 日に複数回行われるようになりました。また、以前は少なくとも 2 人のエンジニアを要し、何時間もかかっていた作業が、数分にまで短縮されました」と Smartsheet の Distinguished Engineer である Skylar Graika 氏は述べています。 「この 1 年で、キャパシティを 50 倍にスケールアウトできたほか、AWS サービス間の緊密な統合を活用することで、効率性を高め、セキュリティとコンプライアンスのプロセスを簡素化できました。さらに、Fargate デプロイで AWS Graviton を採用することで、コストを 20% 削減できました」。 Amazon ECS は、AWS における 10 年間のコンテナ進化の出発点として極めて重要な役割を果たしました。そして今日でも、極めてスケーラブルで信頼性の高いコンテナオーケストレーションソリューションの 1 つとして、 Amazon が 7,724 万もの ECS タスク を立ち上げた Prime Day 2024、 Amazon ECS をコアアーキテクチャの一部として使用する、生成 AI を利用したショッピングアシスタントエクスペリエンスである Rufus など、大規模な運用を支えています。 Instrumental の ML Engineering Manager であり、AWS Machine Learning Hero でもある Rustem Feyzkhanov 氏は、このサービスを導入することで得られる効率性の向上をすぐに認識しました。「Amazon ECS は、私たちの仕事に欠かせないツールとなりました」と Rastem 氏は述べています。「過去数年にわたって、コンテナ管理とサービスのスケーリングが簡素化され、インフラストラクチャではなく開発に注力できるようになりました。このサービスにより、アプリケーションコードチームがインフラストラクチャを共同所有できるようになり、開発プロセスがスピードアップします」。 タイムライン ECS の進化を形作った重要なマイルストーンのいくつかを見てみましょう。これらは、お客様が AWS でコンテナの力を活用する方法を変えた重要な瞬間です。 2014 年 – Amazon EC2 Container Service をリリースしました ! – ECS のプレビューモードでのリリースを記念した、懐かしいブログ記事をご覧ください。この記事を読むと、サービスの提供開始時からいかに多くの機能が提供され、最初から大きな影響をもたらしているのかがわかります。 お客様は既に、組み込みのリソース管理とタスクスケジューリングを使用して、 Amazon Elastic Compute Cloud (EC2) インスタンスのクラスターで Docker コンテナを実行、停止、管理することができました。2015 年 4 月 9 日に一般提供が開始されました。 2015 年 – Amazon ECS 自動スケーリング – より多くの Amazon CloudWatch メトリクスのサポートが追加され、お客様は、クラスター内の CPU とメモリの使用状況をモニタリングして自動スケーリングのしきい値を設定することで、クラスターを自動的にスケールインおよびスケールアウトできるようになりました。これは、一見控えめなリリースが、お客様に大きな影響をもたらし得ることを示すすばらしい例だと思います。もう 1 つのインパクトのあるリリースは、コンテナのストレージとデプロイを効率化するフルマネージドコンテナレジストリである Amazon ECR の提供開始 です。 2016 年 – ECS 向け Application Load Balancer (ALB) – ECS 向け ALB の提供開始により、コンテナ化されたアプリケーションのために高度なルーティング機能が提供されました。ALB により、マイクロサービス間の負荷分散がより効率的になり、ECS ワークロードのトラフィック管理とスケーラビリティが改善されました。また、この年には、いくつかの AMI による Windows Server 2016 のサポート の追加や、 Windows Server Containers のベータサポート など、Windows ユーザーはさまざまなリリースの恩恵を享受しました。 2017 年 – AWS Fargate の提供を開始しました ! – Fargate は、基盤となるインフラストラクチャを管理せずにコンテナを実行できるという大きな前進となり、お客様の運用が大幅に効率化されました。デベロッパーは、コンテナが実行される EC2 インスタンスのプロビジョニング、スケール、またはメンテナンスについて心配する必要がなくなり、アプリケーションロジックに完全に注力し、その他を AWS に任せることができるようになりました。これは、デベロッパーがより迅速にスケールしてより自由にイノベーションを行うのに役立ち、クラウド中心のジャーニーが加速され、コンテナ化されたアプリケーションに対するアプローチが変革されました。 2018 年 – AWS Auto Scaling – このリリースにより、チームは Amazon ECS タスクのスケーリングプランを簡単に構築できるようになりました。また、この年には、 Amazon ECR を Amazon ECS コンソール外の独自のコンソールエクスペリエンスに移行する 、 Amazon ECS と AWS Cloud Map を統合する など、多くの改善もリリースされました。さらに、AWS Fargate の採用は世界中のリージョンで拡大し続けました。 2019 年 – Amazon ECS で使用可能な Arm ベースの Graviton2 インスタンス – AWS Graviton2 は、多くの企業が持続可能性の目標の優先順位付けの見直しに目を向けていた時期にリリースされました。Graviton2 を搭載し、パフォーマンスの改善と電力使用量の削減に重点を置いた EC2 インスタンスは、リリース初日から Amazon ECS でサポートされました。お客様は、クラウド向けに特別に構築されたこの画期的なカスタムチップセットを最大限に活用できました。この年のもう 1 つの大きなハイライトは、 AWS Fargate Spot のリリースです。これは、お客様が大幅なコスト削減を実現するのに役立ちました。 2020 年 – Bottlerocket – コンテナの実行に最適化されたオープンソースの Linux ベースのオペレーティングシステム。セキュリティの強化と更新の簡素化を目的として設計された Bottlerocket は、Amazon ECS ユーザーがコンテナ化されたワークロードの管理において、より高い効率性と安定性を実現するのに役立ちました。 2021 年 – ECS Exec – Amazon ECS は 2021 年 3 月に ECS Exec の提供を開始しました。これにより、お客様は、Amazon EC2 または AWS Fargate で実行中のコンテナ内で直接コマンドを実行できるようになりました。この機能は、コンテナの変更や再デプロイを必要とせずに、強化されたトラブルシューティングとデバッグ機能を提供し、運用ワークフローが合理化されました。また、この年には、 Amazon ECS Windows コンテナ がリリースされ、クラスターでコンテナを実行しているユーザーのオペレーションが合理化されました。 2022 年 – Amazon ECS が Service Connect の提供を開始 – ECS Service Connect のリリースは、サービス間ネットワークに伴う複雑さの多くを抽象化したため、Amazon ECS でマイクロサービスアーキテクチャを実行している組織にとって極めて重要な瞬間となりました。これにより、サービス間の通信の管理が大幅に効率化されました。ネイティブのサービス検出とサービスメッシュ機能により、デベロッパーは、サービスがシームレスにインタラクションする方法を定義および管理できるようになり、カスタムネットワークやロードバランサーを管理することなく、オブザーバビリティや回復力を高め、セキュリティを強化できました。 2023 年 – Amazon GuardDuty ECS ランタイムモニタリング – 昨年、Amazon GuardDuty は AWS Fargate 向けの ECS ランタイムモニタリングの提供を開始し、実行中のコンテナ内の潜在的な脅威を検出することでセキュリティを強化しました。この機能により、コンテナワークロードの継続的な可視性が提供され、追加のパフォーマンスオーバーヘッドなしでセキュリティ体制が強化されます。 2024 年 – Amazon ECS Fargate と EBS の統合 – 今年 1 月、Amazon ECS と AWS Fargate は Amazon EBS ボリュームのサポートを追加し、コンテナの永続ストレージを実現しました。この統合により、ユーザーは EBS ボリュームを Fargate タスクにアタッチできるため、ストレージのデプロイや大量のデータを取り扱うアプリケーションのサポートがはるかに簡単になります。 現状 Amazon ECS は現在、イノベーションを続けながら新規および既存のお客様の両方に大きな価値を提供することを可能にする成熟度に達しており、エキサイティングな状況にあります。今年はサービスに多くの改善が加えられ、ますます安全でコスト効率が高く、使いやすくなっています。 これには、 Service Connect での TLS を使用した自動トラフィック暗号化のサポート 、 タスクの停止エラーメッセージの強化 (タスクの起動失敗のトラブルシューティングが簡単になります)、 タスクを再起動せずにコンテナを再起動 する機能などのリリースが含まれます。 AWS Fargate Spot を使用した Graviton2 ベースのインスタンスの提供開始 は、お客様にとって、コスト削減額を倍増させる絶好の機会となります。 AWS ではいつものことですが、Amazon ECS チームはお客様の満足に非常に力を入れています。「Amazon ECS と AWS Fargate を使用すると、AWS が提供する強力なすべてのコンピューティングを、管理することなく活用しながら、差別化されたビジネスロジックに注力することが非常に簡単になります」と Director of Product and Science, Serverless Compute である Nick Coult は述べています。「これらのサービスについての当社のビジョンは、インフラストラクチャ管理を最小限に抑え、作成するコードを減らし、拡張性を考慮して設計して、高いパフォーマンス、回復力、セキュリティを推進できるようにすることでした。そして、それは現在でも変わっていません。また、当社はこの目標を念頭に置いて、過去 10 年間、これらの領域で継続的にイノベーションを起こしてきました。Amazon ECS では、セキュリティを損なうことなく俊敏性を提供し、デベロッパーに優れたエクスペリエンスを提供するとともに、より幅広くシンプルな統合を実現して、生成 AI などの新しいワークロードの新たな可能性を生み出すというコミットメントを堅持しています」。 まとめ その歴史を振り返ると、ECS はお客様のニーズから逆算する AWS のアプローチの証であることは明らかです。コンテナオーケストレーションの合理化に取り組んでいた初期の頃から、Fargate と Service Connect の革新的な提供開始まで、ECS はデベロッパーと企業の両方の障壁を取り除くために一貫して進化してきました。 将来を見据えると、ECS は限界を押し広げ続け、さらに革新的でスケーラブルなソリューションを実現していくと思います。ECS が提供するものを引き続き探求し、新しい構築方法を発見して、プラットフォームの可能性を最大限に引き出すことを、あらゆるお客様にお勧めします。今後もさらに多くのことが予定されており、このジャーニーが私たちをどこへ連れて行ってくれるのか楽しみにしています。 学習リソース Amazon ECS を初めてご利用になる場合は、包括的でわかりやすい「 Amazon ECS の開始方法 」ガイドを読むことをお勧めします。 いくつかの実践的な無料トレーニングでスキルを磨く準備ができたら、この記事で言及した機能の多くを含む、サービスの多くの側面をカバーするこのセルフペースの Amazon ECS ワークショップ を試すことをお勧めします。 Amazon ECS に感謝します。また、このサービスを使用し、引き続きサービスの改善にご協力くださるすべての皆様にも感謝します。コンテナイノベーションの次の 10 年もすばらしいものとなりますように! 原文は こちら です。

2 週間前、私はグローバルな 24 Hours of Amazon Q ライブストリームイベントで、アジアパシフィック全体から内容領域専門家をお招きするすばらしい機会に恵まれました。ユースケース、製品デモ、質疑応答セッションを特色とするこの 24 時間連続のストリームでは、 Amazon Q Developer と Amazon Q Business に関する AWS エキスパートのインサイトが提供されました。 私にとってのハイライトは、これらのエキスパートから多くのことを学んだことです。それ以来、私は Amazon Q Business を自分のワークフローに統合しようと努めてきました。Amazon Q でできることについてご関心がおありの場合は、 Twitch でオンデマンドリプレイをご覧ください。 10 月 21 日週のリリース 10 月 21 日週の AWS のリリースのうち、私の目に留まったものを以下にまとめました。 AWS Lambda コンソールが、Code-OSS (VS Code – オープンソース) をベースとした新しいコードエディタを導入 – AWS Lambda は、人気の Code-OSS である Visual Studio Code Open Source コードエディタをベースとする、AWS コンソールでの新しいコード編集エクスペリエンスを導入します。Lambda コンソールでは、好みのコーディング環境とツールを使用できます。 Amazon Bedrock カスタムモデルインポートの一般提供を開始 – Amazon Bedrock では、単一の統合 API を通じて、カスタマイズされたモデルを既存の基盤モデルと一緒にインポートして使用できるようになりました。この機能により、インフラストラクチャやモデルライフサイクルタスクを管理することなく、人気のオープンソースアーキテクチャに基づいて、ファインチューニングされたモデルを活用したり、独自のモデルを開発したりできます。 EC2 Image Builder で macOS イメージの構築とテストのサポートを開始 – EC2 Image Builder は、既存の Windows および Linux サポートに加えて、macOS ワークロードのマシンイメージの作成と管理のサポートを追加しました。これにより、イメージ管理プロセスを合理化し、macOS イメージを維持するための運用オーバーヘッドを削減できます。 Amazon Bedrock で、Anthropic の Claude 3.5 Sonnet (現在利用可能)、コンピュータ使用 (パブリックベータ)、Claude 3.5 Haiku (近日公開予定) がアップグレード – Amazon Bedrock の Anthropic の Claude 3.5 モデルファミリーは、Claude 3.5 Sonnet 向けの改善されたインテリジェンスや、パブリックベータでの新しいコンピュータ使用機能など、大幅なアップグレードを受け取ります。これらの機能強化は、さまざまなユースケースのためのより高度な AI アプリケーションの構築、複雑なタスクの自動化、改善された推論機能の活用をサポートします。 Amazon Connect が画面共有の提供を開始 – Amazon Connect は、エージェント向けの画面共有機能の提供を開始しました。この機能は複数のリージョンで使用可能で、既存の音声通話およびビデオ通話設定に簡単に統合できます。この機能により、カスタマーエクスペリエンスをパーソナライズして改善できます。 Amazon Aurora がグローバルデータベースライターエンドポイントをリリース – Amazon Aurora は、可用性の高いフルマネージドグローバルデータベースライターエンドポイントをサポートするようになりました。この機能により、アプリケーションのルーティングが簡素化され、クロスリージョングローバルデータベーススイッチオーバーまたはフェイルオーバーオペレーションを開始した後でアプリケーションコードを変更する必要がなくなります。 新しい分析と会話のインサイトにより、Amazon Q Business に関するより深いインサイトを取得 – Amazon Q Business は、分析ダッシュボードと Amazon CloudWatch Logs との統合を提供するようになりました。Amazon Q Business アプリケーション環境と Amazon Q Apps の使用状況に関する包括的なインサイトが得られるようになり、使用状況のモニタリング、分析、最適化が容易になりました。 myApplications の新しい Resiliency ウィジェットの発表 – AWS は、アプリケーションの回復力に関する可視性とコントロールを強化した、myApplications の新しい Resiliency ウィジェットの提供を開始しました。myApplications ダッシュボードから直接、回復力評価を開始し、実用的なインサイトを得ることができます。 community.aws からの情報 community.aws から、私が個人的に最も気に入っている 5 つの記事をご紹介します。 Setting Up Microsoft Entra ID SAML 2.0 Federation with Amazon WorkSpaces Pools (著者: Dzung Nguyen 氏 )。 Getting Started with Rust: A Beginner’s Guide (著者: Matheus Guimaraes )。 Deploying AWS Infrastructure with GitOps and CloudFormation (著者: Jason Wood 氏 )。 Instrumenting applications on AWS ECS and AWS Fargate with AWS X-Ray (著者: Paulo Siecola 氏 )。 Becoming an AWS Cloud Captain: My Experience (著者: Rashi Dashore 氏 )。 今後の AWS イベント カレンダーを確認して、今後の AWS およびコミュニティのイベントにサインアップしましょう。 AWS GenAI Lofts – AWS GenAI Lofts で深いインサイトを得て、質問に答えてもらい、次のイノベーションの構築を開始するために知る必要のあるすべてのことを学びましょう: ソウル (10 月 30 日～11 月 6 日)、 サンパウロ (11 月 20 日まで)、 パリ (11 月 25 日まで)。 AWS Community Days – 技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とするコミュニティ主導のカンファレンスに参加しましょう。今後の AWS Community Day は、 マルタ (11 月 8 日)、 マレーシア 、 チリ (11 月 9 日)、 インドネシア (11 月 23 日)、 コチ (インド) (12 月 14 日) に開催されます。 AWS re:Invent – 12 月 2〜6 日にラスベガスで開催される、毎年恒例のテックイベントへの 登録 が開始されました。話題になること間違いなしの 5 つの基調講演で、新製品のリリースについて学び、デモを見て、舞台裏のインサイトを入手しましょう。 近日開催されるすべての 対面イベント と 仮想イベント を閲覧できます。 10 月 28 日週のニュースは以上です。11 月 4 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Donnie この記事は、 Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

そろそろ re:Invent も近づいてきましたが、日本でもまだまだイベントが続きます。流通・小売・消費財業界に関わられている方々を主な対象として、2024 年 10 月 24 日に「流通・小売・消費財業界向け：クラウドと生成 AI によるオペレーション改革」のオンラインセミナーを開催しました。ご参加いただきました皆さまには、この場を借りて御礼申し上げます。本ブログでは、その内容を簡単にご紹介します。またブログ最後に近く予定されているイベントのご紹介もしていますので、ぜひそちらもご参加を検討ください。 在庫管理、発注管理、物流配送、店舗設計、販促…小売業界における皆様の日々の業務、つまりオペレーションにおける改善・改革は常に企業のニーズとして存在してきました。テクノロジーで変革を支援、加速することのできるオペレーションもたくさんあり、急速に私たちの日常にも浸透しつつある生成 AI はそのテクノロジーの筆頭です。 生成AI を用いて蓄積された社内ナレッジを検索、再利用する、コンテンツを生成したり、解釈を手伝ってもらう – 今回のセミナーでは生成 AI を業務オペレーション改革に応用したお客様 5 社の、具体的な成功事例をお話いただきました。 1. オープニング AWS 技術統括本部 エンタープライズ技術本部 流通小売・消費財グループ 部長 　五十嵐 建平 資料ダウンロード 企業はオペレーション改革に対して、当該業務そのものをスマートに見直すこと、あるいは熟練性の伝達による属人性を排除することによる効率化、それらによりもたらされる時間やコストの削減や、より価値のある業務への集中などの期待を持っています。生成 AI をオペレーション改革に適用する試みは昨年から活発化し、今年に入り具体的な成果が次々と検証されています。その生成AIのユースケースは大きく 3 つのフェーズで進化していると考えられます。 (1) 既存ナレッジの検索 生成 AI で企業の既存ナレッジを検索しやすくすることなどにより、対応スキルの底上げや、チャットボットなどに代表されるアシスタントが各業務を支援するフェーズです。多くのお客様がまずここからスタートし、徐々に高難度なタスクへと挑戦していっています。 (2) データ読み取りや作成 最初のフェーズが進み始めると、より多様な業務に適用を進めるために、さらに幅広く企業内のデータを利用したくなります。データは構造化されるほど扱いやすくなります。データの種類も増やしたくなります。こういったデータを豊かにすることそのものに、生成 AI を利用します。 (3) コンテンツ監査 より重要な判断についての支援を生成 AI から得るために、コンテンツを高精度に監査する、そこにまた生成 AI の活用が見出されています。 今回の事例でご登壇いただく 5 社様、それぞれが異なるフェーズのお話になっています。そしていずれも今回ご紹介いただく「成功事例」のさらに次の挑戦、適用範囲の拡大や高度化が計画されています。業務ごと、適用フェーズごとに適切な生成 AI 技術を選択し、オペレーション改革そのものを継続させている、そんな点を念頭に各お客様事例を聞いていただければ、皆様のクラウド、そして生成AIによるオペレーション改革を実現するための手がかりを掴めるはずです。 2.お客様事例 (1) 生成AIを組み込んだ入札契約業務オペレーション改革 三井物産株式会社 デジタル総合戦略部 デジタルテクノロジー戦略室 Product Manager 伊藤 友貴様 資料ダウンロードリンク 三井物産株式会社様、そしてそのグループ内では、多くの国際入札に参加しています。入札業務においては短期間で 100 ページを超すような入札説明書を読み込まなくてはならないようなケースがあり、商材や契約実務に関する専門知識・業界知識が必要とされるために、熟練者でも40時間以上かかることがあります。そこで、生成 AI により入札説明書を解析するアプリを開発しました。まず、「AI 要旨項目抽出」機能が、入札説明書の構成単語を抽出・分類します。続いて「AI 重要単熟語着色」機能がこれらの単語をラベリングし、色分けします。最後に「要旨生成」機能がその入札説明書の要旨を生成します。担当者はアプリを使って分類、色分けされた情報を参照しつつ、訂正などを行い、最後に要旨を作成することができます。この一連の処理のデモを、講演の中でご紹介いただいています。実証実験では、熟練者で約 12 時間、新人では約 51 時間の業務時間削減効果が確認されました。さらに、新人の業務成功率も33% から100% に向上したとのこと。 技術的には、識別式モデル（BERT）による系列ラベリングと、 Amazon Bedrock の提供する LLM による修正を組み合わせて構築されています。当初ルールベースで構築していた部分をLLMに切り替えることで、ルールの保守運用から開放されました。LLM に切り替えた後も、利用するモデルを初期は Jurassic-2 Ultra から、その後、新しい Claude 3.5 Sonnetへと、継続的なアップデートを図られています。こういったモデルのアップデートを容易に実現できる点で、Amazon Bedrock を評価していただいています。アプリ開発の裏話として、単にモデルの選択や精度を追求するのではなく、開発サイドとユーザーサイドが協力し合って UI/UX を改善していったことで、より使ってもらえるサービスとなっていった点にも触れられていました。 現在、このアプリは三井物産グループ内で展開が進んでおり、今後は社外提供も計画されているそうです。 3. お客様事例 (2) Amazon Bedrock と Lambda を活用したホームページ制作支援システム 株式会社ペライチ カスタマーリレーション部 プロダクトマネージャー 藤代 康太 様 資料ダウンロードリンク ペライチ様は「テクノロジーをすべての人が使える世界に」をビジョンに掲げ、ホームページ作成にあたってユーザーの抱える「ページ構成を決められない」「社内にノウハウがなく負担が大きい」という課題を解決するために、専門知識がなくても簡単にホームページを制作できるサービスを提供されています。ノーコードでホームページを作れるように様々なユースケースに合わせたテンプレートや、組み合わせて使うことのできるビルディングブロックを提供されているのですが、それでもユーザーからは「どのテンプレートを選べばよいか分からない」といった声がありました。そこで、Amazon Bedrock と AWS Lambda を活用し、AI アシスタントによる、ページ自動生成システムを開発しました。通常は担当者が行うホームページの移行や制作準備の作業を、生成 AI が既存サイトを読み込み解析することで支援します。さらに、テンプレートからページを制作する作業も、テンプレートの選択や画像の再配置、キャッチコピーの生成などを生成 AI が手伝います。ご講演の中で実際に既存のウェブサイトの URL から新たなホームページを生成するまでの一連の流れをデモでご紹介いただいています。画像など既存サイトのアセットを有効活用しつつ、テンプレートに沿った新しいページが生成されていきます。生成 AI により生成されるコンテンツにはムラがあるので、生成したものをそのまま使うのではなく、いったんユーザーが確認、編集するステップを置くことでより納得感のある制作ステップを提供できるようにもなっています。 ユーザーのページ制作の効率化と品質向上を目指すこの新機能は、現在はベータ版として提供中で、80名のモニターユーザーから好評を得ているとのことでした。今後は、このシステムの効果を測定しつつ、既存サービスの改善や他の課題解決への応用を検討していくとのことです。 4. お客様事例 (3) Amazon Bedrock × Kendra で実現する、生成 AI による組織ナレッジの継承と効率化 ライオン株式会社 デジタル戦略部 データサイエンティスト 百合 祐樹 様 資料ダウンロードリンク ライオン様からは、研究開発部門が直面していた知識管理と情報共有の課題に対し、生成AIを活用したソリューションを導入した事例をご紹介いただきました。研究の分野では、長い商品研究の歴史の中で「新しい実験のアイデアを思いついたと思ったが、実はかなり以前にすでに実験済みだった」ということが実際に起っているそうです。長く在籍された研究者の方であれば蓄積された情報の所在を理解していることもありますが、それを次の世代の研究者へと伝えていくことも大変です。こういった過去に遡った大量データからの知見の活用というユースケースは、まさに生成 AI、その中でも RAG（Retrieval-Augmented Generation、検索拡張生成）の得意とするところです。 そこで「これまでの研究活動において培った技術知見を高度に活用できる仕組みを整備し、新たな顧客価値創造・イノベーション創出を加速する」ことを目標に、ナレッジ検索システムを開発されました。このシステムは、特に大規模なデータでの RAG で、技術的には Amazon Bedrockと Amazon Kendra を組み合わせて実現されています。この仕組みによって、情報検索時間は最大5分の1に短縮され、これまで見つけにくかった情報の発見や、若手や日本語を母国語としない海外出身の研究員の理解促進にも貢献しているとのことです。 ライオン様は、このシステムを研究集約知のフレームワーク確率への第一歩として、今後も、データの追加や改善を継続して対応するユースケースを増やし、より高度な組織ナレッジの活用を目指されているそうです。 5. お客様事例 (4) SaaS 事業者の生成 AI 活用パターン ～新機能開発から業務効率化まで～ ナビプラス株式会社 事業企画部 2グループ グループマネージャー 白石 卓也 様 資料ダウンロードリンク ナビプラス様は、EC サイト向けマーケティングツール、具体的には EC サイト内における、サイト内検索やレコメンデーションといった EC サイトに必要とされる機能を SaaS で提供されています。ナビプラス様では、生成 AI 導入の選択肢として、LLM だけでなく、LLM よりも精度や汎用性には劣るもののより手軽に利用できる、小規模言語モデル（SLM）にも注目しており、ユースケースを探りながらいろいろな生成 AI の選択肢を拡げているところだそうです。ご講演の中で、LLM と SML の比較実験をとてもわかりやすいサンプルでご紹介いただいています。 具体的な生成 AI活用事例としてはまず、社内 Slack ボットが取り上げられました。Amazon Bedrock と Amazon Kendra を組み合わせた、社内情報を活用した RAG を導入し、文章の要約・翻訳から、カスタマージャーニー作成まで、幅広い業務オペレーションで利用されています。もう一つの活用事例は、ナビプラス様の提供するサービスそのものへの生成 AI 適用事例です。ナビプラスシリーズにはいくつかのサービスがありますが、今回は EC サイトにおけるユーザーレビュー管理のためのサービス、ナビプラスレビューに、ユーザーが商品レビューを投稿する際のアシスト機能を組み込みました。ここでも Amazon Bedrock を利用し、商品ごとに適切な質問を投げかける生成 AI、そしてその質問に対するユーザーの回答からレビューコメントを下書きする生成 AI が活躍しています。この機能は約 3 ヶ月でリリースされたそうです。 「生成AIの進化は日進月歩で、私たちの想像を超えるスピードで新しい可能性が生まれています。まずは小さな一歩から始め、実践を通じて活用領域を広げていきましょう。顧客接点の革新とオペレーション改革で、皆様のビジネスの競争力向上につながることを願っています。」という、ご講演スライドから生成 AI によって作成されたメッセージで講演を締めくくっていただきました。 6. お客様事例 (5) 業務効率化のため取り込んだ新たな生成 AI 活用術 株式会社ファミリーマート システム本部 IT基盤部 クラウド推進グループ 朴 明振 様 ※資料ダウンロードは当日ご視聴いただいた方のみとなっております。 ファミリーマート様では、様々な業務オペレーションの補助手段として、生成 AI を積極的に検討されています。店舗管理業務、全社共通ツールなどそれぞれに適切なモデルでの検討が進んでいるそうですが、今回の講演では IT 部門のエンジニア向けのユースケースをご紹介いただきました。例えば AWS サポートへの問い合わせ履歴やマニュアルを効率的に検索、参照したい、といったとても身近な課題への対応です。実現には、AWS の GenU（Generative AI Use Case JP） を活用されています。GenU とは、生成 AI を安全に業務活用するための、ビジネスユースケース集を備えたアプリケーションの実装サンプル集で、Amazon Bedrock を使用した実装コードを AWS が公開しています。IaC で簡単に、完成度の高いシステムをデプロイすることができ、すぐに試せる点を評価いただきました。 これをさらに一歩進め、Amazon Kendra のドキュメント相互参照機能を活用し、複数のドキュメント間でルール違反がないかを確認するなど、より高度な分析を実現することに挑戦されました。これにより、“ある提案書が社内マニュアルのルールに準拠しているかどうかを確認する”（提案書やマニュアルはそれぞれ異なるドキュメント）といったことが可能になっています。具体的には、まず生成 AI に社内マニュアルから必要なルールを抜粋するように指示し、その抜粋されたルールを次の質問（プロンプト）に渡します。続けて、提案書がそのルールに準拠しているかどうかをチェックして、という指示を出します。この 2 つ目の指示を出す際に、先に抜粋されたルールが渡されているため、相互参照が可能になる、という仕組みです。ファミリーマート様ではこの機能の提供により、チームメンバー間のノウハウ共有や過去の知見の活用が促進され、プロジェクト管理の質が向上しており、さらなる機能拡張も計画されているそうです。 最後に「ドキュメントの相互参照をぜひお試しください」という力強い推薦メッセージをいただきました。 まとめ オープニングで紹介した、生成 AI のユースケース進化の 3 つのフェーズに照らし合わせると、ライオン様やファミリーマート様ではフェーズ (1) において、Amazon Kendra の特性を活かしてオペレーション改善を実現した事例と言えます。ナビプラス様のナビプラスレビューのレビューコメント生成は、さらなるデータの拡張を狙っている段階に進んでおり、フェーズ (2) のユースケース事例です。ペライチ様では、テキスト、画像を組み合わせるマルチモーダルでホームページ制作の半自動化が実現されています。三井物産様では BERT と LLM の組み合わせでの高度な入札業務の効率化を実施されています。これらの 2 社はフェーズ (3) の事例と言えるでしょう。 5 社の事例から、生成 AI の活用において オペレーションが実際にどれだけ改善されたのか、効果を定量的に計測している 小規模なチームで実験を繰り返し進化させている 1-3 ヶ月の短期間で本番稼働させ、それをさらに拡張・高度化させている という点が共通的な成功要素であることが見えてきます。 特に一点目の効果測定は非常に重要な要素です。生成 AI に限らず、DX のトレンドの中で、データ利活用に取り組む企業の 50% 近くは成果を測定していない（ DX 白書 2023 より）と言われています。成果が具体的に語れないと、そもそも成功しているか評価できず、それ以上の進化のための投資も難しくなってしまいます。 今回の成功事例から、技術的な仕組みだけでなくこういった側面からも学んでいただけると思います。 多くの企業において、企業トップや事業部で「生成 AI を使っていこう」という大きなモメンタムがあります。これは業務オペレーションそのものの変革に取り組んでいく絶好の機会です。ぜひ、早く進化を始め、そして進化を早めて、競争力を加速させていきましょう。私たちがお手伝いします。 今後のイベント 11 月にも、流通・小売・消費財業界の皆さまに向けたイベントを予定しています。ぜひご参加ください。 AWS Retail CPG Expo 2024: カスタマーエンゲージメントからスマートストアまで – 5つの戦略的イノベーションが牽引する次世代小売 リテール業界固有の課題と機会に応える、ソリューションプロバイダーのサービスやベストプラクティスを一挙紹介 2024 年 11 月 12 日 13:30 – 18:30 お申し込みはこちらから： https://aws-retail-expo-2024.splashthat.com/ イベントコンテンツの紹介ブログ も参照ください。 流通小売/消費財企業向け：2024 年 最新ソリューションによるレガシーシステムのクラウド移行 2024 年 11 月 15 日 (金) 10:00 – 11:10 お申し込みはこちらから： https://pages.awscloud.com/eib-cpg-241115-reg.html 今後も、流通・小売・消費財業界の皆さまに向けたイベントを企画し、情報発信を継続していきます。ブログやコンテンツも公開しておりますのでご覧ください。 流通小売参考情報 [1] AWS ブログ ”流通小売” カテゴリー [2] AWS ブログ “消費財” カテゴリー [3] AWS 消費財・流通・小売業向け ソリューション紹介 ページ [4] インダストリー向け e-Book： スマートストアテクノロジーの力を活用する（ e-Book | 紹介ブログ ） 小売業のデジタルコマースを最適化する 4 つの重要なステップ（ e-Book | 紹介ブログ ） 流通・小売・消費財企業のイノベーションを生成 AI で促進する（ e-Book | 紹介ブログ ） 消費財企業が成長するための極意（ e-Book | 紹介ブログ ） 消費者に愛されるブランドを構築する（ e-Book | 紹介ブログ ） このブログは、ソリューションアーキテクト 杉中 が担当しました。