こちらのBlogは、” Join the AWS Genomics Team at Bio-IT World Expo 2024 “を和訳し、一部修正を加えたものです。 2024年4月15日から17日までボストンで開催されるBio-IT World Conference and Expo（※当カンファレンスは閉会しました）のゴールドスポンサーとして、 AWSゲノミクスチーム は、オミクスデータから洞察を得るために特別に設計されたサービスである AWS HealthOmics が、研究を変革し、精密医療の未来を加速させる方法をご紹介することをを心待ちにしています。このプレミアイベントでは、複雑な課題を解決し、科学的なブレークスルーを促進することに尽力するライフサイエンスやテクノロジーの専門家が一堂に会する予定です。 この業界の進化の最前線に立ち、AWSは、サービスとパートナー連携がデータの流動性を高め、R&D ワークフローを再構築し、人工知能(AI)をシームレスに組み込んで、科学的および臨床的な洞察を具体的な患者のアウトカムに変換する方法を実演します。3日間のカンファレンスを通して、AWSのお客様とパートナーは、創薬研究から臨床現場までのイノベーションを推進するためにクラウドを活用した実例を共有します。参加者は、組織がオミクスデータ解析のスケーリング、創薬のための生成AIの展開、国家規模の多様ながん研究プラットフォームの構築に関連するIT上および科学上の障壁を克服するためにAWSを活用している方法を学んでいただけます。 このブログでは、AWSが主催するレセプションに参加する方法や、パートナー主導のデモを体験するためのプライベートデモスイートを訪れる方法など、包括的なBio-ITカンファレンスのアジェンダをまとめています。これらのセッションをブックマークし、デモに参加し、カンファレンス中にAWSゲノミクスチームと個別に会議を設定するためにAWSアカウントチームに連絡することをお勧めします。ボストンでみなさんにお会いできるのを楽しみにしています。 AWS Speaking Sessions Overcoming the Scientific and IT Challenges Associated with Scaling Omics Analysis Tuesday, April 16, 12:25 PM ET | AWS and Basepair | Track: Cloud Computing Discover how a combination of AWS HealthOmics and partner solutions from Basepair can help life sciences organizations maximize productivity, reduce costs, and adhere to IT best practices when scaling omics workflows. Generative AI Distributed Training for Drug Discovery with AWS and NVIDIA Wednesday, April 17, 12:40 PM ET | AWS and NVIDIA | Track: AI for Drug Discovery and Development This session covers deploying NVIDIA’s BioNeMo on AWS ParallelCluster and Amazon SageMaker . Learn how to use BioNeMo’s containers for generative AI and protein structure visualization on these AWS services. Utilizing Generative AI for Drug Discovery in the Cloud Wednesday, April 17, 1:20 PM ET | Luncheon | AWS | Track: AI for Drug Discovery and Development At this session, Evozyne will showcase how they leveraged generative AI on NVIDIA’s BioNeMo platform and AWS to create two new proteins with supernatural function. The developed LLMs outperform traditional protein engineering approaches by enabling the production of functional synthetic molecules with hundreds of mutations in a single round. The role of large, pre-trained models and libraries to unlock such generative design will be reviewed alongside the benefits cloud computing provides in storage, automation, and parallelization. AWS Hosted Reception Bio-IT World 2024 Opening Night Reception Hosted By: Rescale and AWS Program Time: Monday, April 15, 7:30 pm – 8:30 pm ET Location: Abstract Room located on the 3rd floor of the Omni Hotel Seaport (conference center) Bio-IT World 2024 is a marathon, not a sprint! Recharge on day 1 with Rescale and AWS at our opening night networking event and reception, fueled by complimentary cocktails and bites. R&D modernization, from data to drug discovery applications Hosted By: Deloitte, NVIDIA, and AWS Program Time: Tuesday, April 16, 5:00 pm – 7:30 pm ET | Reception: 7:30 pm – 8:30 pm Location: AWS Seaport Offices (BOS21), 55 Pier 4 Blvd., Boston, MA 02210 We are excited to invite you to an insightful event on R&D modernization from data to drug discovery applications, hosted by Deloitte, NVIDIA, and AWS. If you’re attending the Bio-IT World conference or are in the Boston area during the evening of April 16 and are interested in connecting with your peers, we’d love for you to join us! AWS & Tennex BioIT Cocktail Reception　　 Hosted By: Tennex and AWS Program Time: Wednesday, April 17, 5:00 pm – 7:00 pm ET Location: Trillium Brewing – Fort Point, 50 Thompson Place, Boston, MA 02210 Join the AWS Startups Life Sciences Team and Tennex for a BioIT Happy Hour on Wednesday, April 17 from 5pm to 7pm at Trillium! AWS HealthOmics Demo Suite Agenda (Suite-12004) Join us in our demo suite, where AWS partners will showcase cutting-edge solutions and provide hands-on technical guidance to help you build for the future of genomics. To attend, simply reach out to your AWS account team or speak with representatives from the AWS Genomics team onsite at the conference. You can find us at any of the speaking sessions and reception listed above. Don’t miss this opportunity to explore innovative partner demonstrations and connect with AWS genomics experts. Run enterprise-scale Generative AI Models for Drug Discovery using BioNeMo NVIDIA Inference Microservice (NIM) on AWS Tuesday, April 16, 1:00 PM – 1:45 PM ET | Demo Session | NVIDIA NVIDIA BioNeMo is a generative AI platform for machine learning in chemistry and biology. It accelerates drug discovery’s most time-consuming and costly stages by streamlining the development and deployment of AI models. There are two parts of BioNeMo. The BioNeMo Framework is a freely available docker container that provides tools for model training scalable to multiple GPUs and nodes, with integrations for different AWS services. BioNeMo microservices are extensively optimized to scale inference to thousands of GPUs and are packaged as NVIDIA NIMs for easy deployment. As part of the broader cross-domain NVIDIA NIM catalog, each container is standardized by packaging an inference-optimized model with NVIDIA AI Enterprise base image, an NVIDIA triton server, and a cloud API. Users can flexibly compose workflows with multiple NIMs to predict properties of small molecules, proteins, and nucleic acids, predict interactions between some of these modalities, or generate novel molecules. AWS and NVIDIA have joined forces to offer high-performance, low-cost inference for NIMs, which will soon be available on AWS HealthOmics and SageMaker. In this demo we will introduce you to BioNeMo NIMs and example workflow of property-guided small molecule generation. Basepair and AWS HealthOmics: A Point & Click Way of Running a Managed AWS Service Tuesday, April 16, 2:00 PM – 2:45 PM ET | Demo Session | Basepair Wednesday, April 17, 12:00 PM – 12:45 PM ET (Repeat Session) Basepair’s SaaS platform accelerates the migration, deployment, and scaling of AWS HealthOmics workflows in any AWS account, anywhere in the world. Its point and click interface then enables research scientists to perform routine analyses, interactively visualize and explore genomic data on their own so they can collaborate with bioinformaticians on an informed question. Building Custom Genomics and AI/ML Workflows on Amazon HealthOmics Tuesday, April 16, 3:00 PM – 3:45 PM ET | Demo Session | Clovertex Clovertex will showcase how to build custom workflows for genomics and AI/ML analysis using HealthOmics, which enables storing, analyzing, and querying large-scale genomic, transcriptomic, and other omics data. Clovertex will provide guidance on migrating workflows to HealthOmics, optimization strategies, and lessons learnt. Attendees will also learn how to leverage HealthOmics for building AI/ML functionalities for data analysis. Managing Genomics Computing with EPAM CORA for AWS HealthOmics Wednesday, April 17, 10:00 AM – 10:45 AM ET | Demo Session | EPAM Come see how you can democratize access to genomics and other high-compute solutions for your scientists, maintain security and control over costs, and integrate these calculations into larger business workflows. EPAM Collaborative Omics Research Accelerator (EPAM CORA ) for AWS HealthOmics, recently announced by EPAM, will make it easy to leverage AWS HealthOmics using EPAM’s proven Cloud Pipeline framework within your AWS VPC. Intel Open Omics: Ushering in Faster/Cheaper MultiOmics Pipelines on AWS HealthOmics Wednesday, April 17, 11:00 AM – 11:45 AM ET | Demo Session | Intel Intel’s Open Omics Acceleration Framework (in short, Open Omics) is a community-driven full stack high throughput framework for accelerating omics pipelines. This demo will highlight examples of seamlessly realizing industry leading performance for key pipelines on AWS HealthOmics. AWS Partner and Customer Speaking Sessions Application of Quantum Computing to Cyclic-Peptide Docking Monday, April 15, 10:20 AM ET | Chugai Pharmaceutical | Track: Quantum Computing Chugai has developed original mid-size molecular drug discovery technologies, which can generate orally bioavailable cyclic peptides. We are exploring invaluable applications of quantum computing technology to our mid-size molecular research. We are planning and conducting POC studies for examining its potential for enhancing our mid-size molecular research. As a case study, we will introduce a POC study of cyclic-peptide docking simulation using a quantum computing-inspired optimization solution. Using AI and Machine Learning (AI/ML) to Power Predictive Drug Discovery Tuesday, April 16, 10:25 AM ET | Vertex Pharmaceuticals | Track: AI for Drug Discovery and Development In the drug discovery process, testing compound libraries is time-consuming and costly. Join this session to learn how Vertex accelerates compound testing by employing predictive modeling for rapid activity predictions. Discover how they built a modern MLOps platform on AWS services like Amazon SageMaker and AWS Batch to train, deploy, and manage thousands of activity prediction models at scale. Explore how this scalable infrastructure enables daily model retraining, optimizes small molecule testing processes, and fosters collaboration across teams. A First Look at National-Scale Multimodal Cancer Research in Practice Tuesday, April 16, 10:55 AM ET | Genomics England | Track: AI for Oncology, Precision Medicine, and Health Genomics England and its partners are currently building the world’s largest multimodal research platform for cancer. The platform uniquely brings together clinical WGS and healthcare data—from Genomics England’s work enabling the NHS to deliver precision medicine through the Genomic Medicine Service—with hundreds of thousands of matched pathology and radiology images being digitized by the National Pathology Imaging Consortium and made accessible through AWS. Join this session to hear about the progress and challenges of making 100PB of data queryable in the cloud; a first look at the sort of insights this platform can provide; and how industry can use it and partner with Genomics England and its participants to advance new therapy. Scalable Cloud Infrastructure Design Tuesday, April 16, 11:25 AM ET | Vertex Pharmaceuticals | Track: Cloud Computing This talk dives deep into how Vertex Pharmaceuticals modernized its image segmentation platform using AWS Serverless technologies and explains how it benefited scientists in their research & development work. This session will review how Vertex’s legacy system worked and pain points associated with it, discuss the new cloud-based system using AWS Serverless, benefits gained, and lessons learned. Quilt: The Open Solution to Data Chaos Tuesday, April 16, 12:10 PM ET | Quilt Data, Inc. | Track: Data Management The vast majority of Life Sciences companies fail to capture the full value of their data investment due to the organizational friction caused by data silos. We examine the underlying causes of this “data chaos” and explore how an open-source universal data abstraction–data packages–can help organizations rewrite the tradeoff between individual productivity and organizational velocity. Slalom Presents the xCures Platform, Built on AWS Employing AI/ML for Seamless Data Acquisition & Real-Time Access Tuesday, April 16, 1:05 PM ET | Luncheon | Slalom | Track: Data Science and Analytics Technologies Slalom presents the xCures Platform , built on AWS to employ AI/ML technologies that seamlessly acquire, extract, organize, and annotate medical records, providing both longitudinal views and real-time access to the source-verifiable clinical data How to Reliably Run Omics Pipelines on AWS Spot Instances with MMCloud Tuesday, April 16, 1:05 PM ET | Luncheon | MemVerge | Track: Bioinformatics In the rapidly evolving landscape of genomic research, the demand for cost-effective and scalable computational resources is paramount. This talk explores the innovative integration of MMCloud (Memory Machine Cloud) with AWS Spot instances to reliably run omics pipelines, addressing the core challenges of cost, performance, and stability in high-throughput genomic analysis. MMCloud, with its unique SpotSurfer technology, offers a revolutionary approach to utilizing the economic advantages of AWS Spot instances while mitigating the risk of instance termination. We delve into the dynamics of SpotSurfer’s checkpointing mechanism, ensuring seamless pipeline execution by preserving computational states during Spot instance interruptions. Additionally, the talk examines MMCloud’s real-time resource optimization features like WaveRider and WaveWatcher, which dynamically right-size computational resources and provide comprehensive observability, thereby enhancing performance and reducing costs. By harnessing these capabilities, MMCloud emerges as a robust solution for running omics pipelines on AWS, offering researchers and bioinformaticians an unprecedented balance of affordability and reliability in cloud-based genomic computation. This talk not only presents a technical overview but also demonstrates the practical application and benefits through a series of benchmark tests, underlining MMCloud’s potential to transform the landscape of genomic research in the cloud. Life Science Organizations in the Cloud—SNAFUs, FUBARs, and OMG Moments Tuesday, April 16, 2:30 PM ET | Flagship Pioneering | Track: Modern Data Platforms and Storage Infrastructure This talk will provide some balance to the abundance of cloud adoption success stories. We’ll explore real-world examples from start-ups and big pharma of things that didn’t go quite as expected. Some stories may be familiar, some not, but they all contribute to our understanding of how life science organizations can make the best use of the cloud. The experiences presented are with AWS but generalizable to other cloud providers. AION Labs, a Venture Studio Empowering Entrepreneurs to Create or Grow Their Company with Pharma and AWS Tuesday, April 16, 3:00 PM ET | AION Labs | Track: Generative AI AION Labs is an alliance of global pharma companies, Amazon, and venture capital firms that have come together to co-develop and adopt groundbreaking new AI technologies that will transform drug discovery and development. AION Labs provides access to funding, data, validation, and technologies in a co-development model from day one. In this talk, I will share our model for creating or joining AI companies in the drug discovery and development space. We invest significantly in defining articulating the problem to be solved. The speaker will share examples from antibody discovery and optimization challenges that we launched and describe the companies we launched. PANEL DISCUSSION: Digital Leadership Lessons: Reflecting and Correcting Tuesday, April 16, 3:00 PM ET | Panel Discussion | Flagship Pioneering | Track: Modern Data Platforms and Storage Infrastructure This discussion will convene executive leaders to share their experiences about technology, data, and cultural decisions that led to surprising outcomes. From unanticipated obstacles to valuable lessons learned, the panelists delve into the real stories that shaped the journey of start-ups and big companies alike. Join us for a light-hearted conversation about serious topics. こちらのブログはヘルスケア・ライフサイエンス事業開発部 片岡 が翻訳しました。

本ブログでは、2024年3月28日(木)に開催したアマゾン ウェブ サービス(AWS)「物流DXセミナー2024」のサマリーをお届けします。今回は NIPPON EXPRESS ホールディング様、日本梱包運輸倉庫株式会社様/ニッコン情報システム株式会社様、CBcloud 株式会社様にご登壇いただきました。物流を取り巻く様々な課題に、各社様がどのように取り組まれているのか、その中でクラウドのようなテクノロジーがどのように活用されているのかをご紹介いただきました。物流業界を中心に多くのお客様が参加・視聴されましたが、小売業や製造業など物流の重要性が高まっている他業界でもご参考にしていただけるイベントなりました。 AWSオープニングコメント アマゾン ウェブ サービス ジャパン 合同会社 サービス産業営業本部 鈴木博貴 本部長 からオープニングのコメントをさせていただきました。労働環境や世界情勢といった外部環境の大きな変化にさらされる物流業界においてテクノロジーやデータの活用の必要性が増しています。このような困難な状況において、AWS のようなテクノロジー企業と本日登壇いただくような物流事業者様が共に学び、課題解決に向けた取り組みを共有していくことが重要と考えております。 NIPPON EXPRESS ホールディングス：DX 推進の足場固めのためのパブリッククラウド移行 NIPPON EXPRESS ホールディングス株式会社、IT戦略部長 宮本 一厳 様 NXグループは、売上高2兆円を超える総合物流事業者です。グローバルでビジネスを展開する一方、NXグループの主要事業会社である日本通運は、国内では災害時の救援物資の輸送に携わるなど、日本の経済社会を支える重要な役割を担っています。 日本通運は2014年から AWS の活用を始め、さまざまな課題・問題に直面しつつも、ナレッジの蓄積やガイドラインの整備を進め、200を超えるシステムを AWS で稼働させています。本講演ではグローバル WMS やデータ分析基盤など AWS で稼働する重要システムのアーキテクチャや構築・運用の工夫を語っていただきました。 グローバルで活用されている WMS NX-GLOW は各国のビジネスが円滑に行われるよう、拡張性に優れたアーキテクチャとグローバル CoE を中核とした強靭な運用体制を構築しています。 NX Data Station は Amazon Redshift や Amazon QuickSight などのAWSサービスで構成されるデータ分析基盤です。宮本部長みずからが手を動かしてこれらのサービスを学習し、環境構築を指揮してきました。また運用フェーズにおける工夫は、莫大なコストをかけてデータ分析基盤を作ったが実務で利用されないという悩みをもつ多くの企業様に参考にしていただけるものです。 日本通運は指定公共機関であるという責務からディザスター・リカバリー（DR）環境の整備にも真摯に取り組んでいます。200以上あるシステムをその重要度に応じて3つの可用性レベルに分類し、重要システムは別リージョンで復旧し継続運用できる環境と運用手順が整いつつあります。 一方で、AWS の活用が進むにつれて、オンプレミス時代と求められるスキルのギャップに不安を感じるITスタッフが増えてきました。そこで、皆が AWS を学習できるようレベルに応じて受講できる勉強会やトレーニングを実施し、組織全体の技術レベルの向上を図っています。その結果2023年末までに AWS の有資格者が20名を超え、実プロジェクトでもその知見が発揮されるようになってきています。 日本通運はじめNXグループは、物流業界の急速な変化を実感しています。このような状況において、変化に耐えうる柔軟なシステムをスピーディに事業部門に提供できることが重要と考えています。そのためパブリッククラウドのようなテクノロジーを取り入れながら、今後も事業の変革を支えるIT部門でありたいと本講演を締め括られました。 日本梱包運輸倉庫株式会社/ニッコン情報システム株式会社：AWS とサーバーレス技術を活用した物流モダナイズの課題から成果そして未来への旅 日本梱包運輸倉庫株式会社様　デジタル開発課長　新井 智久 様 ニッコン情報システム株式会社様　ソリューショングループ　グループマネージャー　萩原 健介 様 日本梱包運輸倉庫株式会社様は、ニッコンホールディングスの中核事業である国内国際輸送、倉庫、梱包、物流加工などを行う総合物流を担っており、一般的な貨物だけでなく、自動車やオートバイなど混載が難しい長尺長大貨物の輸送を得意としております。従来の WMS は、長年のシステム変更により、荷主の要望に応じたスピード感のある改修が難しく、WMS に不足した機能を属人的な作業で補っているため作業品質に差があるなどの課題がありました。本講演では、荷主の要望に素早く対応するために、AWS のサーバレスサービスを使用したマイクロサービスアーキテクチャによる 新 WMS（システム名称“ CIRRUS”） 開発の取り組みについて紹介いただきました。 まずは業務プロセスにおける作業を、全業務で必要な「全業務標準機能」・業種ごとに共通化している「業務共通機能」・個社ごとにカスタマイズした「個別機能」の３層に分けて部品化しました。できる限り「全業務標準機能」に合わせるために、個別対応処理を荷主別管理マスタで吸収し、後続処理の統一化を図ることで、各荷主のニーズを満たしつつ、柔軟かつ汎用的にシステムを管理できるよう工夫しています。 CIRRUS のアーキテクチャ図についても説明いただきました。ユーザーからのアクセスは、Amazon API Gatewayを経由して、マイクロサービス化されたAmazon ECS の各コンテナによって処理されます。CI/CD 環境には、AWS の Code シリーズを活用いただき、Blue/Green デプロイによるシステムのダウンタイム無しの自動リリースを可能にしました。また、AWS を利用したことで、インフラコスト、メンテナンスコスト、機器調達工数の削減のメリットを享受いただいています。６か月という短期間での開発を実現するために、アジャイル手法を用いた、必要最小限の機能を開発したうえで、ユーザーの反応を検証しながら改善を行うMVP開発を積極的に取り入れられました。 CIRRUS の導入によって、これまで紙や電話を介して実施していた倉庫内での業務が、モバイル端末による情報連携が可能になることで、作業の効率化と作業品質の向上を実現できました。 最後に今後の展望についても語っていただきました。日本梱包運輸倉庫株式会社様では、CIRRUS によって業務プロセスの電子化やデータの蓄積が可能になりました。DX を実現するためには、これらの蓄積したデータを活用して、顧客起点での価値創出を行うための事業やビジネス変革が必要です。今後も品質を向上させながら荷主のニーズに迅速に対応するために、ユーザーとベンダーが連携しながら、最新のテクノロジーを取り入れた改善に取り組んでいきたいと述べられていました。 CBcloud株式会社：開発形態の異なるインフラをスムーズに接続するための工夫 -弊社配送インフラピックゴーと顧客企業の基盤システムのスムーズな接続の舞台裏- CBcloud株式会社 プロダクト本部 営業責任者 伊藤 裕哉 様 CBcloud株式会社 プロダクト本部 プロダクト責任者 徳盛 太一朗 様 CBcloud様は、物流DXを推進する企業として、配送サービスプラットフォーム「ピックゴー」と物流ソフトウェア「スマリュー」を展開しています。同社のビジョンは「届けてくれるにもっと価値を」を掲げ、持続可能な物流の実現を目指しています。原点は「パートナーファースト」の理念にあり、現場のドライバーの労働環境改善を最優先としています。ITの力と人々の力を高めることで、物流に留まらず様々な業界の革新を目指すのが特徴です。IT の活⽤で物流現場の⽣産性向上と労働環境改善に貢献する同社の取り組みを紹介いただきました。 CBcloud様の強みは、57,000台以上の軽貨物ドライバーネットワークと2,000社を超える協力会社による圧倒的な配送力、自社開発ソフトウェアによる現場課題解決力、24時間365日のサポート体制です。大手キャリアと同等以上の配車力を持ち、遠隔地への配送に航空機や鉄道による長距離配送も可能で、配車率は99.2%と高い水準です。ドライバーの皆様には配送に注力できる環境をご提供しています。 システム観点でもともと抱えていた課題と、その課題を解決するための取り組みについてご紹介頂きました。「ピックゴー」や「スマリュー」のような物流企業向けのSaaSサービスにおいて、お客様ごとのカスタマイズ要求によりメンテナンス性が損なわれるリスクがありました。そこで、 DDD の腐敗防止思想を取り入れ、AWS のマネージドサービスを活用し、サーバレスアーキテクチャでシステムを構築しました。物流企業感のデータ連携システムにおいては、 Amazon API Gateway 経由で AWS Lambda に配送データを渡し、Amazon DynamoDB にデータを一時格納し、Amazon EventBridge から AWS Lambda を起動してお客様専用のファイル形式に変換し Amazon S3 にファイルを保管、お客様がファイルを取得して自社システムに取り込むというデータ連携フローにより、お客様連携部分を独立させることで、メンテナンス性と再利用性を確保されています。 AWS Lambda を活用したことでプログラミング言語の選択肢が広がり、実行時間課金によるコスト削減、10万件/分の大量データ処理能力の向上が実現しています。CBcloud 様が AWS を採用した理由は、エンジニア採用の容易さ、サービスの豊富さ、お客様の信頼度の高さによるものと述べられていました。 最後に、CBcloud様からはAWSに対して、今後もスタートアップ支援の強化と社会のイノベーション貢献への期待について語って頂きました。 AWS：技術セッション「物流改善のためのAWS活用」 AWSからは技術セッションとして、物流業界のITシステムでAWSがどのように活用できるのかを特に WMS と TMS、データ分析基盤にフォーカスして紹介しました。 ロボティクスやマテリアル・ハンドリング機器との連携が進む WMS では IoT やエッジサービスの活用事例に加え、閑散期と繁忙期で変動が大きくなる課題に対してAmazon RDS /Amazon Aurora のようなクラウド・ネイティブデータベースの有効性を説明しています。 遠隔地や走行中に利用されることが多いTMSでは、AWS IoT Greengrass の活用に加え、生成AIによる運転アシスタントなどのアイデアをご紹介しています。 データ分析基盤では、Amazon Redshift や Amazon QuickSight などによるデータレイクの構成を紹介しています。また、自社内のデータだけでなく顧客や競合などの他事業者あるいは公共データなど社外ともデータ共有することによって、より効果的な分析が可能になることを説明しています。 物流系ITシステムによくみられる課題に対して、AWSのサービス/技術による改善案を示しましたが、ご紹介した多くはどのようなプラットフォームであっても応用できるものと考えています。重要なことは、デジタル技術の積極的な活用により、労働人口の不足が見込まれる現場の生産性を支え、物流サービスの維持と発展に取り組むべきであるということです。 今後の展望 AWS 物流DXセミナーは2022年11月に続き今回で2回目になります。前回よりもさらに多くのお客様にご参加いただき、物流業界におけるクラウドの活用が広がっていることを実感しております。特に今回後登壇されたお客様からは、マイクロサービスやデータレイクなど新しい理論や技術がビジネスの現場で実際に利用され、関連するさまざまノウハウが蓄積されていっていることが印象的でした。同じように試行錯誤している参加者の皆様にも共感いただける、あるいはヒントにしていただける話題が盛りだくさん出会ったと思われます。AWSはお客様と共にイノベーションを促進していくことが重要なミッションのひとつです。何かお困りのことやご相談などあれば、お客様・パートナー各社様向けの相談の時間帯を随時設けておりますので、ぜひ AWS までご相談ください。 ＊ ＊ ＊ ＊ 本ブログは Solutions Architect の横山、三宅、藤倉が執筆し、シニア事業開発マネージャー 竹川/シニアソリューションアーキテクト藤倉が監修しました。 ＊ ＊ ＊ ＊

ヘルスケアなどの規制の厳しい業界でモノのインターネット (IoT) アプリケーションの運用が増えるにつれ、IoT セキュリティデバイスの強化が必須となっています。バックエンドシステムの耐障害性を確保することに加えて、 ゼロトラストの原則 に基づいて従来の企業境界外のデバイスを保護するための取り組みが増えています。たとえば、コネクテッド医療機器を扱うデバイス運用事業者は、製品が設計通り機能し、異常な挙動を示さないことを確認する必要があります。デバイスのセキュリティ体制が侵害された場合、一元化されたセキュリティチームがこれらのイベントを効率的に特定、分析、管理して、エンドツーエンドの患者ケアの提供を保護することが重要です。 完全マネージド型のクラウドサービスである AWS IoT Device Defender は、IoT デバイスを継続的に監視して、デバイスの異常な動作を検出し、セキュリティアラートをトリガーし、組み込みの緩和アクションを提供します。このサービスでは、デバイス関連のリソースを AWS IoT セキュリティのベストプラクティスに照らして監査し、デバイス側とクラウド側のメトリクスを事前定義された閾値に照らしてほぼリアルタイムで評価できます。その後、AWS IoT Device Defender が逸脱を検出したときにアラートを受け取ることができます。AWS IoT Device Defender には、メトリクスをほぼリアルタイムでモニタリングし、 機械学習 (ML) アルゴリズムを適用 して異常を検出し、アラートを出す機能もあります。 Splunk などの AWS パートナーは、組織がインシデントをほぼリアルタイムで検出して対応できるようにする Security information and event management (SIEM) ソリューションを提供しています。AWS IoT Device Defender と Splunk Platform を統合するセキュリティソリューションでは、エンドツーエンドの IoT アプリケーションにデータ主導型のサイバーセキュリティを提供することで、組織のセキュリティ体制を強化できます。 このブログでは、AWS IoT Device Defender、 Amazon Data Firehose 、Splunk Platform を使用して、IoT デバイスからセキュリティ関連のメトリクスを一元化された SIEM に取り込む方法を説明します。また、リスクを迅速に特定し、その影響を体系的に計測するセキュリティシステムを構成する方法についても説明します。 ソリューション概要 これは、 AWS IoT Core 、 AWS IoT Device Defender 、 Amazon Data Firehose 、 Splunk Platform で構成される完全なサーバーレスのソリューションです。 図 1: ソリューションアーキテクチャ図 ソリューションの主な対象者: IoT アプリケーション開発者は、新機能を開発してリリースする責任があります。彼らの目標は、ビジネス価値をもたらす堅牢なコードを書くことに最大限の時間をかけることです。セキュリティは最優先事項ですが、セキュリティ専門家がシステム運用を分析するために必要なメトリクスを抽出、処理、送信するカスタムコードの作成には時間をかけたくありません。 セキュリティオペレーションセンター (SOC) のアナリストは、セキュリティの脅威を特定して対応し、事業運営を保護する責任があります。一元化された SIEM ツールを使用して、ほぼリアルタイムでリスクを監視し、情報を収集します。また、組織のセキュリティ体制を強化するために、手動および自動プロセスを導入します。 このソリューションの仕組み この IoT アプリケーションは AWS IoT Device Client を使用して構築されており、サポートされている デバイス側のメトリクス は自動的に送信されます。本 SDK は、これらのメトリクスを AWS IoT Device Defender 専用の AWS IoT Core Message Queuing Telemetry Transport protocol (MQTT) トピックに発行します。サポートされているデバイス側のメトリクスには、確立された TCP 接続数、リスニング TCP ポート、宛先 IP アドレス、および送信パケット数が含まれます。 AWS IoT Device Defender は、デバイス側のメトリクスを クラウド側のメトリクス と一緒に処理します。サポートされているクラウド側のメトリクスには、認証エラーの数、送信元 IP アドレス数、接続試行数、メッセージサイズ、送信メッセージ数、受信メッセージ数、切断数、切断時間などがあります。クラウド側のメトリクスは、デバイス側のメトリクスが存在するかどうかに関係なく生成されます。 AWS IoT Device Defender の検出機能のセキュリティプロファイルは、ユーザー定義の MQTT トピックにメトリクスを発行するように設定されています。この機能を使用して、メトリクスを処理して他のイベントコンシューマーに転送するルールとアクションを AWS IoT Core に設定できます。 次に、AWS IoT Core のルールとアクションが MQTT トピックに設定され、メトリクスが Amazon Data Firehose 配信ストリームに送信されます。この設計では、Firehose はペイロードのバッチ処理、バッファリング、変換が可能なスケーラブルなデータストリーミングパイプラインを提供します。 AWS IoT Device Defender の監査機能では、監査結果を Amazon Simple Notification Service (Amazon SNS) トピックに送信できます。Amazon Data Firehose 配信ストリームは Amazon SNS トピックをサブスクライブし、そのストリームで監査レポートを受け取ります。 サポートされている監査チェック には、過度に権限のあるロール、デバイス証明書の共有、および MQTT クライアント ID の競合の監視が含まれます。 次に、本ソリューションはストリーミングパイプライン内の AWS Lambda 関数を使用して、ソースレコードを SIEM ソリューションが理解できる形式に変換します。この例では、ペイロードに一意の sourcetype キーを追加し、 event キーの下に再構築します。これにより、Splunk の Search Processing Language (SPL) で検索するときに、イベントのインデックス作成と識別が容易になります。Lambda では、ダウンストリームのコンシューマーの要件に合わせてデータ構造を柔軟に変更できます。たとえば、Lambda 関数は構成管理データベース (CMDB) からデバイス所有者情報を取得することで、データをさらに充実させることができます。 Amazon Data Firehose は、 サポートされている宛先 にイベントを送信します。デバイス側とクライアント側のメトリクスの両方、および監査結果は、Amazon Data Firehose 配信ストリームを介して SIEM ソリューションに取り込まれます。 Splunk などの SIEM ソリューションは、他の AWS サービス、クラウドワークロード、オンプレミスワークロードなど、多数のソースからのログの取り込みをサポートしています。このような総合的なデータ集約により、SOC は、アクセスできる部分の情報だけでなく、組織のセキュリティ体制の完全な可視化を可能にします。 SOCアナリストは、包括的な SIEM ソリューションで利用できるさまざまな機能を使用できます。たとえば、Splunk Platform を使用すると、 Enterprise Security と Security Orchestration, Automation and Response (SOAR) を使用して、受信データを調査、分析、対応できます。ダッシュボードを使用して、デバイス側とクラウド側のメトリクスを他のログと一緒に可視化できます。クエリを使用して、メトリクスを集約、強化、および検索できます。プレイブックを使用して対応を自動化することもできます。例えば、ネットワークポートが意図せず開いたままになっている場合、デバイスのセキュリティ体制が弱まっているかどうかを検出できます。そして弱まっている場合は、より広い環境でのリスクを評価できます。 ソリューションのデプロイ AWS サーバーレスアプリケーションモデル (SAM) テンプレートを使用して、このソリューションに必要な全ての AWS リソース (Lambda 関数で使用される Python コードを含む) をデプロイできます。このテンプレートは aws-iot-device-defender-and-splunk の GitHub リポジトリにあります。 必要な前提条件、デプロイ手順、およびソリューションのテスト方法については、 README ファイルを参照してください。 AWS IoT デバイスディフェンダー設定 ソリューションがデプロイされると、AWS IoT Device Defender の設定により、メトリクスと監査レポートを Firehose に簡単に発行できます。 メトリクス AWS IoT コンソールに移動します。ナビゲーションペインの [検出] を展開し、 [セキュリティプロファイル] を選択します。セキュリティプロファイルが用意されていることに注目してください。 [保持する追加のメトリクス] タブには、事前設定されたメトリクスのリストが含まれています。 図 2: 保持する追加のメトリクスの表示 [エクスポートされたメトリクス] タブでは、これらのメトリクスが事前に定義された MQTT トピックにエクスポートされていることも確認できます。 図 3: エクスポートされたメトリクスの表示 監査 [監査] の [設定] ページに移動します。このソリューションではすべての監査チェックが可能になり、結果は指定された SNS トピックに発行されます。 図 4: 監査設定の表示 イベントの分析 セキュリティデータが SIEM ソリューションに取り込まれると、SOC アナリストは環境内に存在するリスクの理解と評価に取り組みます。この例では、Splunk の Search Processing Language (SPL) を使用してこの分析を実行します。 メトリクス ソリューションがデータを生成したら、Splunk コンソールの Search &amp; Reporting Splunk App に移動し、次の SPL クエリを使用します。 index="&lt;YOUR INDEX&gt;" sourcetype="&lt;YOUR SPLUNK SOURCE TYPE&gt;" この検索では、AWS IoT Device Defender によって生成されたクラウド側とクライアント側のメトリクスがすべて返され、選択したインデックスにデータが取り込まれていることが確認できます。 次に、新しい SPL クエリを作成して、デバイス毎に aws:num-listening-tcp-ports 値を継続的に監視します。次のクエリを使用してください。 index="&lt;YOUR INDEX&gt;" sourcetype="&lt;YOUR SPLUNK SOURCE TYPE&gt;" | spath name | search name="aws:num-listening-tcp-ports" | chart max(value.count) as tcp_count over _time by thing このクエリは、1 つのデバイスで開いている TCP ポートの合計数が変化していることを示しています。セキュリティアナリストによる詳細な調査が必要です。 図 5: 開いている TCP ポートの総数の表示 疑わしい動作をしているデバイスの名前を使用して、別の SPL クエリを実行して、どのポートが開いているかを判断します。 index="&lt;YOUR INDEX&gt;" sourcetype="&lt;YOUR SPLUNK SOURCE TYPE&gt;" | where thing="&lt;YOUR THING NAME&gt;" | spath name | search name="aws:listening-tcp-ports" | spath value.ports{} output=open-ports | mvexpand open-ports | chart count(open-ports) over _time by open-ports 図 6: デバイスで開いている TCP ポートの表示 セキュリティアナリストは、 aws:all-packets-out や aws:all-bytes-out &nbsp;等の他のデータポイントを更に調べ、他のデータ漏洩メトリクスがないかを確認できるようになります。これらのデータポイントは、他のデバイス (ネットワークスイッチ、ルーター、ワークステーションなど) からのデータと一緒に評価することで、そのデバイスに何が起こったのか、組織にもたらされたリスクのレベルを包括的に把握できます。 監査 監査はスケジュール設定することも、すぐに実行することもできます。 AWS IoT Core コンソール で、 [監査] 、 [結果] の順に移動し、 [作成] を選択します。 [利用可能なチェック] を選択し、 [スケジュールの設定] で [今すぐ監査を実行 (1回)] を選択し、 [作成] を選択します。 セキュリティアナリストは、次のような SPL を使用して、過去の監査レポートのステータスを継続的にトラックできます。 index="&lt;YOUR INDEX&gt;" sourcetype="&lt;YOUR SPLUNK SOURCE TYPE&gt;" | where isnotnull(checkName) 図 7: 監査レポートの表示 まとめ この投稿では、AWS IoT Device Defender のエクスポートメトリクスと監査機能を、Amazon Data Firehose と Splunk Platform と組み合わせて使用して、IoT デバイスからセキュリティデータを大規模に取り込む方法について説明しました。Splunk Platform などの SIEM ソリューションを使用することで、SOC アナリストは導入された IoT デバイスによるビジネスへのリスクを評価し、事業継続性を最大限に保護する方法について情報に基づいた意思決定を行うことができます。AWS IoT Device Defender を使用して IoT デバイスのセキュリティを管理する方法の詳細については、 AWS IoT Device Defender を参照してください。 著者紹介 Alan Peaty Alan は AWS シニアパートナーソリューションアーキテクトです。Alan は、Global Systems Integrators (GSI) と Global Independent Software Vendors (GISV) が AWS サービスを使用して複雑な顧客の課題を解決できるよう支援しています。AWS に入社する前、Alan は systems integrators でソリューションアーキテクトとしてビジネス要件を技術ソリューションへと変換する業務をおこなっていました。仕事以外では、Alan は Internet of Things (IoT) の愛好家であり、イギリスカントリーサイドの泥だらけのトレイルを走るのが大好きな熱心なランナーです。 Travis Kane Travis Kane(T-REX)は、Splunkのクラウド・テクニカル・ストラテジストです。Travis は、お客様、パートナー、Splunk 社員が、Splunk と AWS を組み合わせてデジタル世界をよりレジリエントなものにする方法を理解できるよう支援します。Travis は IT 業界で23年以上働いています。仕事以外では、Travis はパートタイムのボクサーで、パンチをかわすことに時間を費やしています。 Andre Sacaguti Andre Sacaguti は AWS IoT のテクノロジー担当シニアプロダクトマネージャーです。Andre は、デバイスメーカー、自動車メーカー、IoT の顧客がエッジからクラウドまでデバイスを監視して保護するのに役立つ製品とサービスの構築に注力しています。AWS が登場する前は、Andre は T-Mobile とクアルコムで IoT 製品を構築して発売していました。 Amandeep Singh Amandeep Singh は AWS のソリューションアーキテクトです。Amandeep は、世界中の公共部門の ISV パートナーと協力しています。Amandeep は、データセンターネットワーク、ハイブリッドクラウドソリューション、クラウド移行、デジタルトランスフォーメーションのバックグラウンドを持っています。彼はこの知識を活かして、お客様がクラウドワークロードの移行と最適化を簡素化できるよう支援しています。彼はバージニア州を拠点とし、サッカーが大好きで、余暇のほとんどを猫と過ごしています。 この記事は&nbsp; Use AWS IoT Device Defender and Splunk to monitor the security posture of your IoT application の日本語訳です。IoT Consultant の正村 雄介が翻訳しました。 <!-- '"` -->

本ブログは「 Securing generative AI: data, compliance, and privacy considerations 」を翻訳したものとなります。 生成 AI は世界中の組織や個人の想像力をかき立て、従業員の生産性の向上や顧客体験の変革、さらに多くのことに採用されています。 生成 AI ベースのサービスを使用する場合、アプリケーションに入力した情報が、モデルプロバイダまたはモデルが実行される環境のプロバイダによってどのように保存、処理、共有、使用されるかを理解する必要があります。生成 AI ソリューションを提供する組織は、自社のアプリケーションやモデルの使用方法やトレーニング方法におけるプライバシー、コンプライアンス、セキュリティの検証に役立つように設計された適切な保護手段をユーザーや消費者に対して構築する責任があります。 このブログは、生成 AI をセキュアにするシリーズの続きで、生成 AI ワークロードのデプロイと構築における規制、プライバシー、コンプライアンスの課題に関するガイダンスを提供します。このシリーズの最初のブログ「 生成 AI をセキュアにする：生成 AI セキュリティスコーピングマトリックスの紹介 」を読むことをお勧めします。このブログでは、ブログシリーズの基礎となる生成 AI のユースケースを特定するのに役立つツールである生成 AI スコーピングマトリックスを紹介しています。 図 1 はスコーピングマトリックスを示しています。 図 1 : 生成 AI スコーピングマトリックス 大まかに言えば、スコーピングマトリックスにより、ユースケースを事前に構築された生成 AI アプリケーション（スコープ 1 と 2 ）と自身で構築する生成 AI アプリケーション（スコープ 3 ～ 5 ）の 2 つのカテゴリに分類できます。5 つのスコープすべてにいくつかの一貫した法律、ガバナンス、コンプライアンス要件が適用されますが、各スコープには固有の要件と考慮事項もあります。各スコープの主な考慮事項とベストプラクティスについて説明します。 スコープ 1 : コンシューマアプリケーション コンシューマーアプリケーションは通常、一般ユーザーまたは専門家でないユーザーを対象としており、通常はWeb ブラウザーまたはモバイルアプリからアクセスします。生成 AI で最初に話題になったアプリケーションの多くはこのスコープに該当し、標準のエンドユーザー使用許諾契約 (EULA) を使用して無償または有償で提供されます。これらのアプリケーションは特に企業での利用に向けて構築されていないかもしれませんが、広く普及しています。従業員は個人的な用途でこれらを使用したり、業務に役立つような機能を期待しているかもしれません。 多くの大規模組織は、入力されたデータに何が起こるか、また誰がデータにアクセスできるかをコントロールできないため、これらのアプリケーションをリスクと見なしています。これに対応して、組織はスコープ 1 のアプリケーションの利用を禁止します。リスクの評価にはデューデリジェンスを奨励していますが、全面的な禁止は逆効果になる可能性があります。スコープ 1 のアプリケーションを禁止すると、シャドー IT と同様の意図しない結果が生じる可能性があります。たとえば、従業員が個人用デバイスを使用して利用制限のためのコントロールを回避したり、使用されるアプリケーションの可視性が低下するなどです。組織は生成 AI アプリケーションを禁止するのではなく、組織がコントロールでき組織内で使用が許可されているデータの範囲内で、これらのアプリケーションのうち、従業員が効果的に使用できるものがどれかを検討する必要があります。 生成 AI に関連するリスクと許容される使用方法を従業員が理解できるようにするには、具体的な利用ガイドラインを含む生成 AI ガバナンス戦略を策定し、ユーザーがこれらのポリシーを適切なタイミングで認識していることを確認する必要があります。たとえば、組織が発行および管理するデバイスを使用しWeb ブラウザーで生成 AI ベースのサービスにアクセスするときに、会社で公開されている生成 AI 利用ポリシーへのリンクと、スコープ 1 のサービスにアクセスするたびにポリシーに同意を要求するボタンを提供するよう、プロキシまたはクラウドアクセスセキュリティブローカー（CASB）に制御させることができます。これにより、そのようなサービスを利用する前に、従業員がトレーニングを受け、リスクを理解し、ポリシーに同意していることを確認できます。 スコープ 1 のアプリケーションに関連するいくつかの主要なリスクに対処するには、以下の考慮事項を優先してください。 従業員が現在使用している、または使用しようとしている生成 AI サービスを特定します。 誰がデータにアクセスできるのか、プロンプトや出力などのデータに対して何ができるか、データの使用方法と保存場所など、各サービスのサービスプロバイダの利用規約とプライバシーポリシーを理解します。 モデルプロバイダがモデルのトレーニングに使用するソースデータを理解します。出力が正確で、リクエストに関連していることをどのように知ることができますか？出力が正確でユースケースに関連していることをレビューおよび検証しやすくするために人間ベースのテストプロセスを導入することを検討します。また正確性と関連性についてユーザーからフィードバックを収集して応答を改善するメカニズムを提供します。 受け取った出力の影響や、出力の商業的な利用については、法的ガイダンスを求めてください。スコープ 1 の生成 AI アプリケーションからの出力の所有者を決定したり、(たとえば) 推論中に個人情報や著作権で保護された情報が出力に使用され、その後生成された出力を組織が使用する場合に誰が責任を負うかを決定します。 これらのアプリケーションの EULA とプライバシーポリシーは、最小限の通知で時間の経過とともに変更されます。ライセンス条件の変更は、出力の所有権の変更、データの処理と取り扱いの変更、さらには出力の使用に関する責任の変更が生じる可能性があります。承認された生成 AI アプリケーションのポリシーを監視するための計画 / 戦略 / メカニズムを作成します。変更を確認し、それに応じてアプリケーションの使用を調整してください。 スコープ 1 のアプリケーションでは、入力プロンプトと生成されたコンテンツは公開されているものと考え、これらのアプリケーションでは個人を特定できる情報（PII）、センシティブなデータ、機密データ、独自のデータ、または企業の知的財産（IP）データを使用しないことが最善の方法です。 スコープ 1 のアプリケーションでは、特に従業員が無料または低コストの価格帯で使用している場合、データの所在地と管轄権の観点から見ると、通常選択肢が最も少なくなります。データを保存する国やデータ処理に適用される法律について組織に厳しい要件がある場合、スコープ 1 のアプリケーションは最小限のコントロールしか提供しないため、要件を満たすことができない可能性があります。 スコープ 2 : エンタープライズアプリケーション スコープ 1 とスコープ 2 のアプリケーションの主な違いは、スコープ 2 のアプリケーションでは契約条件を交渉し、正式な組織間（B2B）の関係を確立する機会が提供されることです。サービスレベルアグリーメント（SLA）とライセンス契約条件が定められ、組織のプロフェッショナルな利用を対象としており、通常はエンタープライズ契約または標準的なビジネス契約条件に基づいて料金が支払われます。締結されている企業契約では、通常、特定のタイプ（および機密性）のデータに対して承認された利用に限定されます。 スコープ 1 のほとんどの側面はスコープ 2 にも当てはまります。ただし、スコープ 2 では、独自のデータを意図的に使用し、組織全体でのサービスの広範な使用を奨励します。リスクを評価する際には、追加で次の点を考慮してください。 利用が許可されているスコープ 2 の各アプリケーションで許容されるデータ分類を決定し、それを反映するようにデータ処理ポリシーを更新し、従業員のトレーニングに含めます。 サービスのデータフローを理解してください。プロバイダに、データ、プロンプト、出力をどのように処理および保存するのか、誰がどのような目的でアクセスできるのかをを尋ねてください。彼らが主張する内容の証拠を提供する認証書や証明書はありますか。また、これらは組織の要求と一致していますか。これらの詳細が、あなたまたはあなたの組織が同意する契約条件に含まれていることを確認してください。 （もしあれば）このアプリケーションで使用するデータの種類について、どのようなデータ所在地の要件がありますか。データの保存場所と、それが法的または規制上の義務と整合するかどうかを理解します。 多くの主要な生成 AI ベンダーが米国で事業を展開しています。米国外に拠点を置き、そのサービスを利用する場合、米国との間のデータ転送に関連する法的影響とプライバシー義務を考慮する必要があります。 データ所在地の選択肢を提供するベンダーは、多くの場合、特定の管轄区域でデータを処理するためにユーザーが使用する必要がある特定のメカニズムを用意しています。場合によってはアカウント作成時に指定したり、アカウントを作成した後に特定の種類の処理を選択したり、特定の地域のエンドポイントに接続してサービスにアクセスしたりする必要がある場合があります。 ほとんどのスコープ 2 のプロバイダは、データを使用して基盤モデルの強化とトレーニングを行いたいと考えています。利用規約に同意すると、おそらくデフォルトで同意することになります。そのようなデータの使用が許可できるかどうかを検討してください。データをモデルのトレーニングに使用すると、同じサービスで後に別のユーザーが出力からデータを受け取るリスクがあります。データの再利用を防ぐ必要がある場合は、プロバイダのオプトアウトオプションを探してください。オプトアウトするためのセルフサービスオプションがない場合は、交渉が必要となる場合があります。 エンタープライズ生成 AI ツールを使用する場合、企業によるツールの使用状況は通常 API 呼び出しによって計測されます。つまり、API への特定の呼び出し回数に対して一定の料金を支払うことになります。これらの API 呼び出しは、プロバイダがユーザーに発行する API キーによって認証されます。これらの API キーを保護し、その使用状況を監視するための強力なメカニズムが必要です。API キーが権限のない第三者に漏れた場合、その第三者は API 呼び出しを行うことができ、その呼び出しはユーザーに請求されます。これらの権限のない第三者による使用も組織によるものと見なされ、モデルをトレーニングする可能性があり（同意した場合）、モデルを無関係なデータや悪意のあるデータで汚染することにより、その後のサービスの使用に影響を与える可能性があります。 スコープ 3 : 事前学習済みのモデル 事前構築済みのアプリケーション (スコープ 1 と 2 ) とは対照的に、スコープ 3 のアプリケーションでは、 Amazon Bedrock や Amazon SageMaker JumpStart などのサービスを通じて利用できる事前トレーニング済みの基盤モデルを使用して、独自の生成 AI アプリケーションを構築します。これらのソリューションは、従業員や外部の顧客に使用できます。スコープ 1 と 2 のガイダンスの多くはここでも当てはまりますが、他にも考慮すべき点がいくつかあります。 モデルプロバイダの一般的な機能として、アウトプットが期待と一致しない場合にフィードバックを提供できます。モデルベンダーには、使用できるフィードバックメカニズムがありますか。その場合は、フィードバックを送信する前に、機密コンテンツを削除する仕組みがあることを確認してください。 プロバイダは、商業的に利用するために生成された潜在的な著作権コンテンツに対して法的異議申し立てがあった場合、補償ポリシーをもっていますか。また、それに関する判例はありますか。 プロンプトまたはレスポンスに含まれるデータをモデルプロバイダは使用しますか。もしそうなら、どのような目的で、どの場所で、どのように保護されていますか。また、プロバイダがトレーニングなどの他の目的に使用することをオプトアウトできますか。Amazon では、お客様からのプロンプトやアウトプットを Amazon Bedrock や SageMaker JumpStart の基盤となるモデル (サードパーティ製のモデルを含む) のトレーニングや改善に使用することはなく、人間がそれらをレビューすることもありません。また、お客様のデータをサードパーティのモデルプロバイダと共有することはありません。データはお客様の AWS アカウント内でプライベートに保たれます。 出力検証のプロセス、ガイドライン、およびツールを確立します。ファインチューニングされたモデルに基づいた出力に正しい情報が含まれていることをどのように確認しますか。また、モデルの精度をどのようにテストしますか。例えば : アプリケーションがテキストを生成する場合は、テストと出力の検証プロセスを作成し、生成された出力が期待どおりの結果を生成していることを確認するために、定期的に (たとえば、週に 1 回) 人間によるテストを行います。 別のアプローチとしては、アプリケーションのユーザーが出力の正確性と関連性に関する情報を送信するために使用できるフィードバックメカニズムを実装する方法があります。 プログラミングコードを生成する場合、組織内で他のコードをチェックして検証するのと同じ方法でこれをスキャンして検証する必要があります。 スコープ 4 : ファインチューニングされたモデル スコープ 4 はスコープ 3 の拡張であり、アプリケーションで使用するモデルは、提供されたデータを使用してファインチューニングされ、応答が改善され、ニーズにより具体的に応えられるようになります。スコープ 3 の考慮事項はスコープ 4 にも関連します。さらに、次の点を考慮する必要があります。 モデルのファインチューニングに使用されるデータのソースは何ですか。ファインチューニングに使用されるソースデータの品質、その所有者、使用時に著作権やプライバシーの問題にどのようにつながる可能性があるかを理解します。 ファインチューニングされたモデルは、ファインチューニングに使用するデータを含め、関連するデータ全体のデータ分類を継承することに注意してください。機密データを使用する場合は、使用されるデータと同じ分類のようにモデルと生成されたコンテンツへのアクセスを制限する必要があります。 基本的に、モデルのチューニングに使用するデータには注意が必要です。考えを方を変えると（訳者注 : 再度モデルのチューニングが必要となるため）コストと遅延が増えるからです。PII に基づいてモデルを直接チューニングし、後でそのデータをモデルから削除する必要があると判断した場合、データを直接削除することはできません。現在のテクノロジーでは、モデルがデータの学習を解除する唯一の方法は、モデルを完全に再トレーニングすることです。通常、再トレーニングには多くの時間と費用がかかります。 スコープ 5 : 自身でトレーニングしたモデル スコープ 5 のアプリケーションでは、アプリケーションを構築するだけでなく、収集したりアクセスできるトレーニングデータを使用してモデルをゼロからトレーニングすることもできます。現在、モデルが使用するデータ本体に関する完全な情報を提供する唯一のアプローチです。データは、組織の内部データ、公開データ、またはその両方である可能性があります。トレーニングプロセスのさまざまな側面を制御でき、オプションでファインチューニングプロセスも制御できます。データ量、モデルのサイズと複雑さにもよりますが、スコープ 5 のアプリケーションを構築するには、他のどの種類のAIアプリケーションよりも多くの専門知識、費用、時間が必要です。一部のお客様にはスコープ 5 のアプリケーションを作成したいという明確なニーズがありますが、多くのビルダーがスコープ 3 またはスコープ 4 のソリューションを選択していることがわかります。 スコープ 5 のアプリケーションでは、以下の点を考慮する必要があります。 あなたはモデルプロバイダであり、EULA を通じてデータがどのように使用、保存、および維持されるかをモデルユーザーに明確に伝える責任を負う必要があります。 アプリケーションに必要でない限り、PII や機密性の高いデータでモデルを直接トレーニングすることは避けてください。 トレーニングされたモデルには、ソースとなったトレーニングデータと同じ規制要件がすべて適用されます。規制およびコンプライアンス要件に従って、トレーニングデータとトレーニングされたモデルを管理および保護します。モデルがトレーニングされると、トレーニングされたデータのデータ分類が継承されます。 機密情報漏洩の潜在的なリスクを制限するには、アプリケーションユーザーのデータ（プロンプトと出力）の使用と保存を必要最小限に制限してください。 AI 規制と法律 AI 規制は急速に進化しており、これがお客様や、ワークロードの一部として AI を含む新しいサービスの開発に影響を与える可能性があります。AWS では、責任を持って AI を開発し、教育、科学、お客様を優先する人を中心としたアプローチを採用して、責任ある AI をエンドツーエンドの AI ライフサイクル全体に統合することに全力を注いでいます。詳細については、「 責任ある AI リソース 」をご覧ください。 OECD AI Policy Observatory は、さまざまな AI ポリシーや規制を理解するうえで役立ち、自分自身や顧客に影響を与える可能性のある世界中の AI 政策イニシアチブに関する情報を得るための入り口として最適です。このブログの公開時点で、69 か国以上で 1,000 を超えるイニシアチブがあります。 このセクションでは、 欧州連合（EU）の人工知能（AI）法 （EUAIA）と 人工知能に関する米国大統領令 という2つの異なる提案から規制テーマを検討します。 AI に関する規制と法制化に関する私たちの提言はシンプルです。規制環境を監視し、必要に応じてプロジェクトの範囲を変更する準備をしておくことです。 テーマ 1 : データプライバシー 英国個人情報保護監督機関 （UK ICO）によると、生成 AI の出現によってデータプライバシー法の原則やそれを守る義務が変わることはありません。生成 AI ワークロードで個人データを使用する場合は影響があります。個人データは、モデルの学習時や、入力として AI システムに送信されたり、AI システムによって出力として生成されたりしたときに、モデルに含まれる可能性があります。入力と出力の個人データを使用して、再トレーニングを行うことで、時間の経過とともにモデルの精度を高めることができます。 AI プロジェクトでは、多くのデータプライバシー法により、使用するデータを業務の遂行に厳密に必要な範囲に限定することが義務付けられています。このトピックをさらに詳しく調べるには、英国の ICO が公開している 8 つの質問のフレームワーク をガイドとして使用できます。このフレームワークを AI プロジェクトのデータプライバシーリスクを確認するメカニズムとして使用し、法律顧問またはデータ保護責任者と協力することをお勧めします。 簡単に言うと、プロジェクトでは「不要なデータを記録しない」という原則に従ってください。 テーマ 2 : 透明性と説明可能性 OECD AI Observatory では、AI ワークロードのコンテキストにおける 透明性と説明可能性 を定義しています。まず、AI がいつ使われているかを公開することです。たとえば、ユーザーが AI チャットボットとやり取りする場合は、その旨を伝えます。2 つ目は、AI システムがどのように開発され、トレーニングされ、どのように運用されているかを人々が理解できるようにすることです。たとえば、英国の ICO では、AI システムの仕組みを説明する文書やその他のアーティファクトを提供すべきかについての ガイダンス を提供しています。一般に、透明性は独自のソース、コード、またはデータセットまで開示をする必要はありません。説明可能性とは、AI システムがどのようにして決定に至ったかを影響を受けた人々や規制当局が理解できるようにすることです。たとえば、ユーザーが同意できない出力を受け取った場合、その出力に異議を申し立てることができるようになっている必要があります。 では、これらの法的要件を満たすにはどうすればよいでしょうか。実際には、AI システムの開発と運用のライフサイクル全体にわたって AI 原則をどのように実装したかを文書化したことを規制当局に示す必要があるかもしれません。ICO ガイダンスに加えて、 ISO 42001:2023 に基づく AI 管理システムの実装を検討することもできます。 透明性をさらに掘り下げてみると、データの収集方法やモデルのトレーニング方法に関する証拠を規制当局に示す必要がある場合があります。 データ収集プロセスの透明性は、データに関連するリスクを軽減するために重要です。プロジェクトにおけるデータ収集プロセスの透明性を管理するのに役立つ主要なツールの 1 つは、 Pushkarna と Zaldivar のデータカード（2022）ドキュメントフレームワーク です。データカードツールは、機械学習 (ML) データの構造化された概要を提供し、データソース、データ収集方法、トレーニングと評価の方法、使用目的、モデルのパフォーマンスに影響する決定を記録します。オープンソースまたは公開ソースからデータセットをインポートする場合は、 Data Provenance Explorer イニシアチブを確認してください。このプロジェクトでは、ライセンス、作成者、およびデータの出所について、1,800 を超えるデータセットを監査しました。 説明性、ガバナンス、およびレポート作成に関連するリスクを軽減するには、モデル作成プロセスの透明性が重要です。Amazon SageMaker には モデルカード と呼ばれる機能があります。これを使用すると、ML モデルに関する重要な詳細を 1 か所で文書化し、ガバナンスとレポートを合理化できます。モデルの使用目的、リスク評価、トレーニングの詳細と指標、評価結果と観察結果などの詳細をカタログ化する必要があります。 組織外でトレーニングされたモデルを使用する場合は、 標準契約条項 (SCC) に頼る必要があります。SCC では、特にデータがEU から第三国に転送される場合に、モデルがトレーニングを受けた可能性のあるあらゆる個人情報の共有と転送が可能になります。デューデリジェンスの一環として、モデルのベンダーに連絡して、データカード、モデルカード、データ保護影響評価（ ISO 29134:2023 など）、または移転影響評価（ IAPP など）を依頼する必要があります。そのような文書が存在しない場合は、そのモデルを使用する決定を下す際に、これを独自のリスク評価に織り込む必要があります。自社製品の透明性の確立に取り組んできたサードパーティの AI プロバイダの例としては、Twilio と SalesForce の 2 つがあります。Twilio は、データとモデルを理解しやすくするために、自社製品に AI 栄養成分表示ラベル (AI Nutrition Label) を提供しています。SalesForce は、利用規約を変更することでこの課題に対処しています。 テーマ 3 : 自動化された意思決定と人間による監視 2026 年から施行される EUAIA の最終草案は、AI モデルには人間の介入や上訴権がないため、自動化された意思決定がデータ主体に害を及ぼす可能性があるというリスクに対処しています。モデルからの応答は推論に基づいた確率的な正確性であるため、確実性を高めるために人間の介入をどのように組み込むかを検討する必要があります。これは、人々をプロファイリングしたり、社会的給付の受給について決定を下したりするモデルなど、人々に深刻な社会的および法的影響をもたらす可能性のあるワークロードにとって重要な問題です。AI プロジェクトのビジネスケースを開発する際には、ワークフローのどこに人間による監視を適用すべきかを検討することをおすすめします。 英国の ICO は、ワークロードでどのような具体的対策を講じるべきかについてのガイダンスを提供しています。データの処理に関する情報をユーザーに提供したり、ユーザーが人間の介入を要求したり決定に異議を申し立てたりする簡単な方法を紹介したり、システムが意図したとおりに機能していることを確認するために定期的なチェックを実施したり、AI の決定に異議を唱える権利を個人に与えたりすることができます。 AI に関する米国大統領令には、デリケートな特性に基づく自動的な差別から人々を保護する必要性が記載されています。この命令により、個人の権利が保護され、これらのシステムの成果が公平であることを検証するために、積極的かつ検証可能な措置を講じる責任が AI 製品の開発者に課せられます。 このトピックに関する規範的な指針は、ワークロードのリスク分類を評価し、ワークフローの中で人間のオペレーターが結果を承認または確認する必要があるポイントを特定することです。AI のトレーニングデータまたは意思決定における偏りに対処するには、AI の意思決定を助言として扱う方針を持つことや、それらの偏りを認識してワークフローの一部として手動アクションを実行するように人間のオペレーターを訓練することなどが含まれます。 テーマ 4 : AI システムの規制分類 組織がリスクを管理するためにデータを分類するのと同じように、規制の枠組みの中には AI システムを分類するものもあります。自分に影響を及ぼす可能性のある分類についてよく理解しておくことをお勧めします。EUAIA は、 リスクのピラミッドモデル を使用してワークロードタイプを分類しています。( EUAIA によると) ワークロードに許容できないリスクがある場合、そのワークロードは完全に使用禁止になる可能性があります。 禁止されたワークロード EUAIA は、CCTV や大規模監視システム、公的機関によるソーシャルスコアリングに使用されるシステム、機密特性に基づいてユーザーをプロファイリングするワークロードなど、禁止されている AI ワークロードをいくつか指定しています。 規制当局からの最新情報 を使用して、開発ライフサイクルの早い段階でワークロードの法的評価を行うことをお勧めします。 高リスクワークロード また、データプライバシー法でリスクが高いと見なされるデータ処理活動にはいくつかの種類があります。このカテゴリでワークロードを構築する場合は、規制当局によるより高いレベルの精査を予期し、規制要件を満たすためにプロジェクトのスケジュールに追加のリソースを含める必要があります。幸いなことに、透明性、説明のしやすさ、リスク評価または脅威モデルを文書化するために作成したアーティファクトは、レポート要件を満たすのに役立つ可能性があります。これらのアーティファクトの例については、英国の ICO が公開している AI とデータ保護リスクツールキット をご覧ください。 ハイリスクの処理の例としては、ウェアラブル、自動運転車などの革新的なテクノロジーや、信用調査や保険見積もりなどのユーザーへのサービスを拒否する可能性のあるワークロードなどがあります。AI プロジェクトの早い段階で弁護士に相談して、ワークロードを見直し、どの規制文書を作成して管理する必要があるかをアドバイスを受けることをおすすめします。ハイリスクワークロードのその他の例については、こちらの 英国の ICO サイト でご覧いただけます。 テーマ 5 : プロファイリング EUAIA は、個人をプロファイリングをするワークロードにも特に注意を払っています。英国の ICO では、このワークロードを「個人に関する特定の個人的側面を評価するため、特に自然人の職務遂行能力、経済状況、健康、個人の好み、興味、信頼性、行動、場所、移動に関する側面を分析または予測するために個人データを使用するあらゆる形態の個人データの自動処理」と定義しています。私たちのガイダンスとしては、AI プロジェクトの早い段階で法務チームにレビューを依頼すべきだということです。 プロジェクトが組織のリスクアペタイトの範囲内にあるかどうかを判断しやすくするために、規制審査をタイムラインに組み込むことをお勧めします。法律は急速に変化しているため、法的環境を継続的に監視することをお勧めします。 テーマ 6 : 安全 ISO 42001:2023 では、AI システムの安全性を「人の生命、健康、財産、環境を危険にさらすことなく、どのような状況でも期待どおりに動作するシステム」と定義しています。 米国の AI 権利章典 では、人々には安全でないシステムや効果のないシステムから保護される権利があると述べています。2023 年 10 月、バイデン大統領は 安全、安心、信頼できる人工知能に関する大統領令 を発行しました。これは、AI システムの使用状況を理解し、その使用によって影響を受けるコミュニティの利害関係者を関与させる必要があることを強調しています。大統領令には、AI システムの文書化、統制、テスト、および独立した検証についても記載されており、これは前に説明した説明可能性のテーマと密接に一致しています。ワークロードについては、説明可能性と透明性の要件を満たしていることを確認し、安全性に関する懸念が生じた場合に規制当局に見せるアーティファクトを用意してください。 OECD はここで規範的なガイダンスを提供しており、ワークロードのトレーサビリティとリスク管理に関する ISO 23894:2023 AI ガイダンス などを用いた定期的かつ適切なリスク評価の必要性を強調しています。 結論 生成 AI は組織にとって新しいテクノロジーかもしれませんが、現状他の分野で使用している既存のガバナンス、コンプライアンス、プライバシーのフレームワークの多くは、生成 AI アプリケーションにも適用されます。生成 AI モデル、プロンプト入力、アプリケーションからの出力のトレーニングに使用するデータは、環境内の他のデータと同じように扱い、既存のデータガバナンスとデータ処理ポリシーの範囲内にある必要があります。特に子供や脆弱な人々がワークロードの影響を受ける可能性がある場合は、個人データに関する制限に注意してください。独自のデータを使用してモデルをファインチューニングする場合、使用されているデータを確認し、データの分類、データの保存場所と保護方法と場所、データおよびトレーニングされたモデルにアクセスできるユーザー、エンドユーザーが表示できるデータを把握してください。生成 AI の使用目的、使用方法、遵守すべきデータ保護ポリシーについてユーザーをトレーニングするプログラムを作成してください。第三者から入手したデータについては、それらのサプライヤーのリスク評価を行い、データの出所を確認するのに役立つデータカードを探してください。 通常、規制や法律の策定と制定には時間がかかりますが、生成 AI にはすでに既存の法律が適用されており、AI に関する他の法律も生成 AI を含むように進化しています。担当の弁護士が、これらの変更に関する最新情報を常に把握できるように支援してくれるはずです。独自のアプリケーションを作成するときは、アプリケーションがもたらすリスクに応じて、アプリケーション が制限されたり禁止されたりする可能性があるため、事業を展開する場所にすでに存在する可能性のある他の多くの法律や規制に加えて、草案段階の新しい法律や規制（EU AI 法など）と、それが自分に影響するかどうかを知っておく必要があります。 AWS では、 生成 AI のビジネス価値を組織内でより簡単に実現 できるようにしています。これにより、生成 AI による顧客体験の改革、生産性の向上、成長の加速が可能になります。生成 AI セキュリティのその他の分野について詳しく知りたい場合は、以下に記載する「生成 AI をセキュアにする」シリーズの他の記事をご覧ください。 生成 AI をセキュアにする : 生成 AI セキュリティスコーピングマトリックスの紹介 生成 AI ワークロードにおけるレジリエンス設計 Securing generative AI: Applying relevant security controls (訳者注：現在翻訳作業実施中です) このブログについて質問がある場合は、 Generative AI on AWS re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 Mark Keating Mark は英国を拠点とする AWS セキュリティソリューションアーキテクトで、世界中のヘルスケア、ライフサイエンス、自動車業界のお客様と協力して、セキュリティとコンプライアンスの課題を解決し、リスクを軽減できるよう支援しています。20年以上にわたり、オペレーション、ソリューション、エンタープライズアーキテクチャの分野でテクノロジー関連の仕事に携わってきました。 Samuel Waymouth Samuel は、AWS Industries チームのシニアセキュリティおよびコンプライアンスソリューションアーキテクトです。彼は顧客やパートナーと協力して、規制、IT 標準、リスク管理、統制マッピング、およびこれらを AWS サービス機能に適用する方法を解明する手助けをしています。仕事以外では、テコンドー、オートバイ、旅行、ギター演奏、マイクロコントローラーやIoTの実験、家族との時間を楽しんでいます。 翻訳はプロフェッショナルサービス本部の保里と藤浦が担当しました。

この記事は Baris Furtinalar（プリンシパルソリューションアーキテクト）、Ondrej Stavinoha（シニアスペシャリストソリューションアーキテクト）と Andy Ward（シニアスペシャリストソリューションアーキテクト）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 ワークロードをクラウドへ移行するお客様は、移行に伴うアプリケーションコードの変更や新しいデータ管理手法の習得を回避したいと考えています。理想としては、従来のオンプレミス環境と変わらない機能と管理ができるクラウドサービスを求めています。運用と管理のスキルを再学習することなく、クラウドへの移行とデプロイを加速することを目標としています。 2021 年 9 月のリリース以来、 Amazon FSx for NetApp ONTAP (FSx for ONTAP) ストレージは様々なユースケースで数多くの企業に導入されています。これによりワークロードを AWS にシームレスに移行できるだけでなく、データ管理に関しても慣れ親しんだ一貫した体験を実現しています。私たちは、クラスタリングされたワークロードを実行する基盤に FSx for ONTAP を活用しているエンタープライズ企業に対して、支援を提供する多くの機会があります。特に Windows Server Failover Cluster (WSFC) をデプロイする場合です。FSx for ONTAP を活用するメリットの 1 つは、iSCSI 経由で共有ブロックストレージを提供できることです。この共有ブロックストレージを従来の WSFC クラスターストレージ、または Cluster Shared Volumes (CSV) として構成できます。 本記事では、FSx for ONTAP のボリュームと LUN で実行できるさまざまな操作について説明します。お客様の支援を通じて、最も頻繁にガイダンスを求められる 3 つの一般的なシナリオがあることがわかりました。1) ディスクの拡張、2) ディスクやボリュームの新規作成、3) LUN の別ボリュームへの移動です。この記事では、これらの 3 つのシナリオについて詳しく説明していきます。 前提条件 ウォークスルーを進めるためには、FSx for ONTAP と iSCSI で接続された Windows サーバーが少なくとも 1 つ必要です。必要な環境がない場合、または新しいテスト環境を簡単に構築したい場合は、 Amazon FSx for NetApp ONTAP を共有ストレージとして使用する SQL Server Always On フェイルオーバークラスターインスタンス を設定するための以前のブログ記事に従って設定できます。このブログでは、Quorum 用 LUN、Data 用 LUN、Logs 用 LUN の 3 つの LUN を含む単一の ONTAP ボリュームをデプロイするための手順を説明しています。 このブログでは、 先述のブログ記事 に従ってデプロイされた各種オブジェクト (FSx for ONTAP ストレージ仮想マシン、イニシエータグループ、SQL Server クラスターリソース) を参照する多数のスクリプトとコマンドを使用しています。独自の環境にカスタマイズする必要のあるパラメータは、コマンドとスクリプトの中で 太字斜体 で示されています。 シナリオ 1 – 既存ディスクの拡張 このシナリオでは、 図 1 のように、既存のボリューム、LUN、ディスクを拡張する方法を説明します。これは、ディスク領域が不足している状況で役立ちます。ONTAP 9.12.1P2 以降を実行している FSx for ONTAP システムの最大 LUN サイズは 128 TB です。以前の ONTAP バージョンでサポートされる最大 LUN サイズは 16 TB です。 図 1 : ディスク領域の不足時における既存の LUN/OS ディスクの拡張 まず、対象のディスクを特定するために、 Amazon EC2 の Windows サーバーに接続します。次に、SSH 経由で FSx for ONTAP の CLI に切り替え、必要なストレージコマンドを実行します。最後に、EC2 の Windows サーバーに戻り、ウォークスルーの手順を最後まで実行します。 ステップ：既存のディスクの拡張 1. リモートデスクトップ (RDP) を使用して、 EC2 Windows インスタンスに接続 します。 2. 以下の PowerShell スクリプトを管理者権限で実行して、 図 2 に示すように、接続された NetApp LUN のドライブレターと対応するディスクのシリアル番号を一覧表示します。 $disklist =@{} get-disk | ForEach-Object {$disklist.Add($_.DiskNumber, $_.SerialNumber)} $partitions = get-disk | Where-Object {$_.FriendlyName -eq 'NETAPP LUN C-MODE'} | foreach { Get-Partition -disknumber $_.Number |?{$_.Type -eq 'Basic' -OR $_.type -eq 'IFS'}} | select DiskNumber, Driveletter foreach($partition in $partitions){$disklist.GetEnumerator() | ForEach-Object { if($partition.DiskNumber -eq $_.Key){Write-Output "Drive Letter $($partition.Driveletter): Disk Serial Number: $($_.value)"}}} 図 2 : 接続された NetApp LUN のドライブレターとディスクシリアル番号を一覧表示する PowerShell コマンド出力 拡張するディスクのシリアル番号をメモに控えます。 3. FSx for ONTAP システムに SSH で接続 します (例 : PowerShell から ssh fsxadmin@x.x.x.x)。ファイルシステムにアクセスできない場合は、 こちらの Amazon FSx の手順 に従ってください。 4. 拡張可能な LUN サイズの上限は、ONTAP のバージョンによって 異なります 。LUN のサイズを 16 TB を超えて拡張する必要がある場合は、ONTAP 9.12.1P2 以降のバージョンを実行しているかどうかを確認してください。FSx for ONTAP の SSH セッションから、次のコマンドを使用して、現在の FSx for ONTAP システムのバージョンを表示します。 version 5. 図 3 に示すように、ステップ 2 で控えたシリアル番号と一致する既存の LUN を一覧表示します。 lun show -serial lWB0k$TDzEXX -fields lun,volume,size 図 3 : FSx for ONTAP システムの現行バージョンを表示する「lun show」コマンドの出力 6. ぞれぞれの環境に固有のシリアル番号を使用するようにコマンドを変更してください。また、ステップ 5 で特定した LUN のサイズを 10 GB 拡張してください。 lun resize -vserver sql-svm01 -path /vol/SQLCluster01/sqldata1 -size +10g 7. RDP で EC2 インスタンスに再接続 します。 8. 次の PowerShell スクリプトを実行 (管理者権限で実行) して、Windows の OS ディスク (この例では S: ドライブ) を拡張してください。 Resize-Partition -Driveletter S -Size (Get-PartitionSupportedSize -Driveletter S).SizeMax 図 4 は、S: ドライブ拡張前の Windows サーバーにおけるディスクの管理 GUI 上の表示例を示しています。 図 4 : ディスク拡張前の Windows サーバーにおけるディスクの管理 GUI 図 5 に示すように、拡張後は S: ドライブのサイズが 10 GB 増加しました。 図 5 : ディスク拡張後の Windows サーバーにおけるディスクの管理 GUI シナリオ 2 – ディスク/ボリュームの新規作成 次のシナリオでは、 図 6 に示すように、FSx for ONTAP ファイルシステムで新しいボリュームと LUN を作成し、作成した新しい LUN を Windows サーバーの新しいディスクとして追加する手順を説明します。この操作を実行する前に、FSx for ONTAP ファイルシステムに十分な空き領域があることを確認してください。 複数の LUN を含む単一の ONTAP ボリュームを使用する構成は、共有 iSCSI ストレージを利用するほとんどの WSFC のデプロイシナリオで適切に機能する有効な設計上の選択です。ただし、すべての状況において単一の設計が絶対的な最良の選択であることはまれであり、設計の一部として複数の ONTAP ボリュームをデプロイすることでメリットを得られるさまざまなユースケースがあります。 FSx for ONTAP を使用する場合に複数のボリュームをデプロイする主な理由は、NetApp のストレージ操作の大部分 (重複排除、スナップショット、クローニング、レプリケーション、インテリジェントティアリングなど) がボリューム単位で行われ、LUN レベルでは設定できないためです。標準的な SQL Server FCI デプロイシナリオでは、これは問題になる可能性は低いですが、より複雑なシナリオでは、複数の ONTAP ボリュームを使用することで得られる柔軟性が重要になる可能性があります。 たとえば、より複雑なシナリオでは、単一の SQL Server FCI を使用して複数のテナントまたは複数のアプリケーションをサポートする場合があります。各テナント/アプリケーションデータベースに独自の ONTAP ボリュームと LUN の組み合わせを提供することで、単一の ONTAP ボリュームでは不可能なレベルの詳細な制御が可能になります。たとえば、各テナント/アプリケーションは、個々の要件に応じて、ONTAP ボリューム上に個別のストレージ階層化ポリシーやレプリケーションスケジュールを設定できます。 1 つの ONTAP ボリュームだけでは不十分な理由の例としては、次のようなものがあります。 I/O 集中型のクエリを含むデータベースを異なるボリュームに分離する 大規模なデータベース、または最小限の RTO 要件を持つデータベースを別々のボリュームに配置し、より迅速な復旧を可能にする SQL トランザクションログファイル (.ldf) を SQL データファイルとは別のボリュームに配置し、独立したバックアップスケジュールを作成できるようにする 前述の例など多くの理由から、デプロイ時に特定の構成でストレージをプロビジョニングしておくか、もしくはデプロイ後に既存ストレージシステムとそれに接続されている Windows サーバーに変更を加える必要があります。 図 6 : ONTAP ボリューム/LUN/OS ディスクの新規作成 FSx for ONTAP の CLI に SSH で接続し、必要なストレージコマンドを実行します。その後、アクティブな SQL Server クラスターノードに切り替えて、ウォークスルーの手順を最後まで実行します。 ステップ：ディスク/ボリュームの新規作成 1. FSx for ONTAP システムに SSH で接続 します (例 : PowerShell から ssh fsxadmin@x.x.x.x)。ファイルシステムにアクセスできない場合は、 こちらの Amazon FSx の手順 に従ってください。 2. FSx for ONTAP の SSH セッションから、以下のコマンドを使用して新しいボリューム (この例では 50 GiB のサイズ) を作成します。前回のブログ記事と同じコマンドを使用しています。 volume create -vserver sql-svm01 -volume newvolume -aggregate aggr1 -size 50G -state online -tiering-policy snapshot-only -percent-snapshot-space 0 -autosize-mode grow -snapshot-policy none volume modify -vserver sql-svm01 -volume newvolume -fractional-reserve 0 volume modify -vserver sql-svm01 -volume newvolume -space-mgmt-try-first snap_delete volume snapshot autodelete modify -vserver sql-svm01 -volume newvolume -delete-order oldest_first -enabled true 3. 新しく作成したボリューム内に新しい LUN (サイズは 50GB) を作成し、その LUN を既存の iGroup にマップします。既存の iGroup の名前がわからない場合は、 igroup show コマンドを使って、iGroup のリストを取得してください。 lun create -vserver sql-svm01 -volume newvolume -lun newdisk -size 50G -ostype windows_2008 lun map -vserver sql-svm01 -volume newvolume -lun newdisk -igroup SQLCluster01-IG 4. RDP で Windows EC2 インスタンスに接続 します。 5. Windows のディスクの管理ツール (diskmgmt.msc を実行) に移動し、新しい iSCSI ディスクを初期化してフォーマットするか、以下の PowerShell スクリプトを実行 (管理者として実行) して、新しく追加されたディスクを初期化してフォーマットし、ドライブレター「N」を割り当ててください。 #Retrieve a list of added LUNs from FSxN $disklist = Get-Disk | Where-Object {$_.FriendlyName -eq 'NETAPP LUN C-MODE' -and ($_.OperationalStatus -eq 'Offline')} | Sort-Object -Property Size #Create a list of drive letters $driveletters=@("N") #Initiate, create and format volumes from the list of available FSx for ONTAP disks foreach($dk in $disklist) { if(($dk).IsOffline -eq $True){ Set-Disk -Number ($dk).Number -IsOffline $False } if(($dk).PartitionStyle -eq 'RAW'){ Initialize-Disk -Number ($dk).Number -PartitionStyle GPT -ErrorAction SilentlyContinue } if($dk.IsReadOnly -eq $True){ Set-Disk -Number ($dk).Number -IsReadOnly $False } } New-Partition -DiskNumber ($disklist[0]).Number -UseMaximumSize -DriveLetter $driveletters[0] | Format-Volume -FileSystem NTFS -Force -NewFileSystemLabel NewDisk WSFC を使用している場合は、次の 3 つの追加手順を実行する必要があります。 1. フェールオーバークラスターマネージャーに移動し、ディスクをクラスターディスクとして追加するか、次の PowerShell スクリプト (管理者として実行) を実行してください。 Get-ClusterAvailableDisk | Add-ClusterDisk ; start-sleep 05 ; Get-ClusterResource | ?{$_.ResourceType -eq "Physical Disk" -and $_.Name -like "Cluster *"}| %{$_.Name = "newdisk"} 2. フェールオーバークラスターマネージャーで、クラスターディスクを SQL Server ロールに割り当てるか、以下の PowerShell スクリプトを実行 (管理者として実行) します。 Move-ClusterResource -Name "newdisk" -Group "SQL Server (MSSQLSERVER)" 3. 最後のステップとして、SQL Server リソース内に新しく追加されたクラスターディスクの依存関係を追加します。これにより、SQL Server リソースの前にディスクがオンラインになります。これは、フェールオーバークラスターマネージャーから行うか、以下の PowerShell スクリプト (管理者として実行) を通じて実行できます。 Add-ClusterResourceDependency -Resource "SQL Server" -Provider "newdisk" これら 3 つの追加手順を実行した場合は、クラスターのフェールオーバーをテストして、すべてが適切に構成され、別のノードにフェールオーバーできることを確認することをお勧めします。 シナリオ 3 – 既存の LUN を別の NetAPP ONTAP ボリュームに移動 シナリオ 3 では、 図 7 に示すように、既存の LUN を新しい ONTAP ボリュームに移動する手順を説明します。これは、既存の LUN を個別の ONTAP ボリューム上に移動し、前のシナリオで詳しく説明したように、特定の LUN に対してさまざまな ONTAP ボリュームレベルの設定を使用するために実行します。 図 7 : LUN の別の ONTAP ボリュームへの移動 ストレージ仮想マシン (SVM) 内の ONTAP ボリューム間で移動される LUN は、接続を失うことなく即座に移動されます。移動先のボリュームは、移動する LUN のサイズより大きくなければなりません。FSx ONTAP CLI に SSH で接続して、必要なストレージの手順を実行します。Windows サーバーでの追加の手順は必要ありません。 ステップ：既存の LUN を別の NetAPP ONTAP ボリュームに移動 1. FSx for ONTAP システムに SSH で接続 します (例 : PowerShell から ssh fsxadmin@x.x.x.x)。ファイルシステムにアクセスできない場合は、 こちらの Amazon FSx の手順 に従ってください。 2. 新しいボリュームをまだ作成していない場合、そして LUN の移動先となる既存のボリュームがない場合は、前のシナリオのステップ 2 を参照して、新しい ONTAP ボリュームを作成する方法を確認してください。 3. 図 8 に示すように、次のコマンドを使用して、移動対象の LUN とそのサイズを特定します。 lun show 図 8 : 「lun show」コマンドの出力 4. 移動対象の LUN を別のボリュームに移動します。 lun move start -vserver sql-svm01 -source-path /vol/SQLCluster01/sqllog -destination-path /vol/newvolume/sqllog 5. 図 9 に示すように、LUN の移動の進捗状況を確認します。 lun move show 図 9 : ディスク拡張後の「lun move show」コマンドの出力 クリーンアップ ウォークスルーの実行中にリソースをプロビジョニングした場合は、意図しない料金が発生しないように、不要になったリソースを削除することをお勧めします。 ウォークスルーの完了後は、 Amazon FSx for NetApp ONTAP のリソースをクリーンアップし、AWS アカウントを保護する 手順に従ってください。 ウォークスルーで作成した他のリソースは、これらのリンクの手順に従ってクリーンアップできます。 Amazon EC2 インスタンスを削除または終了する Amazon EBS ボリュームを削除する まとめ このブログ記事では、iSCSI ストレージを介して Amazon FSx for NetApp ONTAP ファイルシステムに接続された Amazon EC2 Windows サーバーに対して、3 つの一般的なストレージ管理タスクを実行する方法について説明しました。1) ディスクの拡張、2) ディスクやボリュームの新規作成、3) LUN の別ボリュームへの移動です。これらの 3 つのシナリオは、FSx for ONTAP に新規に移行したお客様から、最も頻繁にガイダンスを求められる一般的なタスクです。FSx for ONTAP の詳細については、「 リソース 」ページを参照してください。 この記事を読んでいただきありがとうございました。 翻訳はソリューションアーキテクトの宮城が担当しました。 Baris Furtinalar Baris Furtinalar は、AWS のプリンシパルソリューションアーキテクトであり、Microsoft アーキテクチャ チームのスペシャリストの一員です。彼はクラウドコンピューティングに情熱を持っており、クラウドへの移行が企業のビジネスの変革、俊敏性の向上、運用の応答性の向上に役立つと信じています。彼は、SQL データベース管理、仮想化、システムセキュリティなど、さまざまな背景を持っています。2000 年以来、Windows/SQL サーバーの導入を設計、実装、サポートしてきました。 Ondrej Stavinoha Ondrej Stavinoha は、AWS のシニアスペシャリストソリューションアーキテクトであり、AWS における Microsoft ワークロードにフォーカスしています。彼は、企業顧客にアーキテクチャに関するガイダンスと技術支援を提供し、クラウド導入を促進することに情熱を注いでいます。Ondrej は、Wintel、仮想化、ストレージ、データセンターの移行などのインフラストラクチャに関して 17 年以上の技術経験を持っています。 Andy Ward Andy Ward は、AWS のシニアスペシャリストソリューションアーキテクトであり、Microsoft ワークロードにフォーカスしています。Andy は 20 年以上にわたって Microsoft テクノロジーに取り組んでおり、顧客やパートナーが AWS 上で Microsoft ワークロードを実行、変換、最適化できるよう支援しています。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週火曜日に出た 週刊AWS に、「次回はゴールデンウイーク明けに」と書かれていましたが、出した直後から多くのアップデート・新機能がリリースされたため、予定を変更して4/22（月）～4/25（木）の週刊AWSをお届けします。 それでは、今週発表された主なアップデートについて振り返っていきましょう。 2024年4月22日週の主要なアップデート 4/22(月) Meta Llama 3 now available in Amazon Bedrock Meta 社の LLM である Llama 3 が Amazon Bedrock で利用可能になりました Llama 3 8B と Llama 3 70B の二種類の LLM が利用可能になっています。 Guardrails for Amazon Bedrock is generally available with new safety and privacy controls Guardrails for Amazon Bedrock が一般提供開始（GA）になりました。Guardlails for Amazon Bedrock は有害なコンテンツ、個人を特定できる情報、機密情報などをフィルタリングするための包括的な安全機構を提供するもので、この機能により一貫したユーザー体験と、生成AIアプリケーションの安全対策の標準化が可能になります。現在US East (N. Virginia) と US West (Oregon) リージョンで利用可能です。 Amazon Titan Image Generator model in Amazon Bedrock now generally available Amazon Titan Image Generator が Amazon Bedrock 上で利用可能（GA）になりました。Titan Image Generator は自然言語を使って高品質な画像を低コストで効率的に生成することができる基盤モデルを提供します。生成する画像のサイズを指定したり、自社のデータを使ってカスタマイズしてブランドスタイルに合った画像を生成するといったことにも対応しています。現在US-East (N.Virginia)リージョンで利用可能です。 Agents for Amazon Bedrock add support for Anthropic Claude 3 Haiku and Sonnet Agents for Amazon Bedrock で Anthropic社の Claude 3 Haiku と Claude 3 Sonnet をサポートしました。これらの新しいモデルは従来のClaude 2に比べて高速・高精度であり、必要な精度やレイテンシに応じてモデルを選択することでよりニーズに即したエージェントを構築できます。 Custom Model Import for Amazon Bedrock Amazon Bedrock で、カスタマイズされたモデルをインポートできる Custom Model Import のプレビューを開始しました。この機能により、LLama、Mistral、Flan T5などの対応アーキテクチャでカスタマイズしたモデルを、Amazon Bedrock にインポートし、既存モデルと同様にフルマネージドで利用できます。 Amazon Time Sync Service expands Microsecond-Accurate time to 87 additonal EC2 instance types Amazon Time Sync Service であたらに87種類のAmazon EC2インスタンスタイプ(C7i、M7i、R7i、C7a、M7a、R7a、M7gなど)で、UTC比較で数マイクロ秒以内の高精度な時刻の同期を提供開始しました。AWSのネットワークインフラとAWS Nitro Systemを活用することで、インスタンスに対してGPSで校正された高精度のリファレンスクロックが提供されます。 Amazon Inspector agentless vulnerability assessments for Amazon EC2 are now Generally Available (GA) Amazon Inspector は、ソフトウェアの脆弱性や意図しないネットワークのエクスポージャーがないかを継続的にスキャンする脆弱性管理サービスです。従来はシステムマネージャーエージェントの導入が必要でしたが、今回新たにハイブリッドスキャンモードが追加されました。これは、EC2のスナップショットからソフトウェアインベントリを収集し、脆弱性評価を実現するもので、エージェントの導入が不要です。新規利用時にはハイブリッドモードがデフォルトの設定になっています。また、既存の利用環境からも簡単に移行可能です。 4/23(火) Amazon RDS Performance Insights provides execution plan for RDS SQL Server Amazon RDS for SQL Server での Performance Insights に新しい機能としてリソースを多く消費するSQLクエリの実行計画を収集・保存する機能が追加されました。この機能により、パフォーマンス低下の原因が実行計画の変化によるものかを迅速に特定できるようになります。 4/24(水) AWS Direct Connect adds 25 Gbps hosted connection capacities AWS への専用線接続を提供する AWS Direct Connect では、Dedicated Connection と AWS Direct Connect サービスデリバリパートナーによる Hosted Connection が選択できますが、今回 Hosted Connection で 25 Gbps 接続のサポートを開始しました。Direct Connect ロケーションで 100 Gbps が利用可能な場合に提供可能です。詳しくは ロケーション別のDirect Connectパートナー までお問い合わせください。 AWS CodeBuild now supports managed GitHub Action runners AWS CodeBuild で マネージドの GitHub Action runner が利用可能になりました。これによりGitHub ActionsからCodeBuild経由で AWS Lambda や EC2 GPUインスタンスを活用したアクションの実行が可能になります。 4/25(木) Amazon SageMaker Clarify now supports foundation model evaluations Foundation model evaluations with SageMaker Clarify (基盤モデル評価機能)が一般提供開始（GA）になりました。この機能は、データサイエンティストやML エンジニアが様々な条件で基盤モデルを評価、比較、選択することを支援する機能です。 AWS supports dynamically removing and adding auto assigned public IPv4 address Amazon EC2 で、インスタンスに自動割り当てられたパブリック IPv4 アドレスを動的に削除・追加できる機能が追加されました。従来は割り当てられたパブリックIPv4アドレスはEC2インスタンスの存続期間中は削除できませんでしたが、この機能により不要になった場合には削除でき、IPv4アドレスのコストの節約が可能です。詳細は こちらのドキュメントを参照してください 。 Local time zone support for Amazon RDS for Db2 Amazon Relational Database Service (Amazon RDS) for Db2 でローカルタイムゾーンの設定が可能になりました。これによりRDS for Db2内の時刻をたとえば日本標準時に設定することが可能になります。 最後に１つ、イベントを紹介させてください。2024年5月13日-5月17日の間、期間限定で AWS 大阪オフィスで Startup Loft Osaka Pop-Up を開催します。期間中は、東京と同じく 10:00-18:00 まで無料でコワーキングスペースの提供、AWS の技術的な質問をしていただける Ask an Expert コーナー、VCの方と1:1で壁打ちなどができる VC メンタリング、その他様々なテクニカルセッションやハンズオンなどを開催予定です。 関西エリアのスタートアップの方、スタートアップ業界に興味のある方、関西を盛り上げたいエンジニア及びデベロッパー、そして学生の方などのお越しもお待ちしております。詳しくは以下のブログをご覧ください。 – 期間限定！大阪で AWS Startup Loft Osaka Pop-Up を開催します 週刊AWSの次号はゴールデンウイーク明けの予定です。みなさま良いゴールデンウイークをおすごしください。 ソリューションアーキテクト 下佐粉 昭 (X/twitter – @simosako )

Amazon Titan Image Generator G1 は、 Amazon Bedrock から入手できる最先端の text-to-image モデルです。さまざまなコンテキストで複数のオブジェクトを説明するプロンプトを理解し、生成する画像にこれらの関連情報を取り込むことができます。 米国東部 (バージニア北部) と米国西部 (オレゴン) の AWS リージョンで利用でき、スマートクロッピング、インペイント、背景の変更などの高度な画像編集タスクを実行できます。ただし、ユーザーは、モデルがまだ学習していないカスタムデータセットの特性に合わせてモデルを調整させたいと考えています。カスタムデータセットには、ブランドガイドラインや以前のキャンペーンなどの特定のスタイルと一致する、非常に独自性の高いデータを含めることができます。このようなユースケースに対応し、完全にパーソナライズされた画像を生成するには、 Amazon Bedrock のカスタムモデル を使用して独自のデータで Amazon Titan Image Generator をファインチューニングできます。 画像の生成から編集まで、text-to-image モデルは業界全体で幅広い用途があります。テキストによる説明だけで、従業員の創造性を高め、新しい可能性を想像できるようになります。たとえば、さまざまなデザインを手作業で作成しなくても視覚化できるため、建築家のデザインやフロアプランニングに役立ち、イノベーションを加速できます。同様に、グラフィックやイラストの生成を効率化することで、製造、小売業のファッションデザイン、ゲームデザインなど、さまざまな業界のデザインにも役立ちます。text-to-image モデルでは、パーソナライズされた広告だけでなく、メディアやエンターテインメントのユースケースにおけるインタラクティブで没入感のあるビジュアルチャットボットも可能にすることで、顧客体験を向上させます。 この投稿では、Amazon Titan Image Generator モデルをファインチューニングして、お気に入りのペットである「Ron the dog」と「Smila the cat」という2つの新しいカテゴリを学習させるプロセスをご紹介します。モデルのファインチューニングタスクのためにデータを準備する方法と、Amazon Bedrock でモデルカスタマイズジョブを作成する方法について説明します。最後に、ファインチューニングしたモデルを プロビジョンドスループット でテストして、デプロイする方法を示します。 Ron the dog Smila the cat ファインチューニングジョブを実行する前に、モデルの機能を評価する 基盤モデルは大量のデータでトレーニングされているため、そのモデルはそのままでも十分に機能する可能性があります。そのため、実際にユースケースに合わせてモデルをファインチューニングする必要があるのか、それともプロンプトエンジニアリングで十分なのかを確認するのが得策です。次のスクリーンショットに示すように、Amazon Titan Image Generator のベースモデルを使用して、Ron the dog と Smila the cat の画像を生成してみましょう。 予想通り、そのままのモデルではまだ Ron と Smila を認識しておらず、生成された出力には異なる犬と猫が写っています。プロンプトエンジニアリングを行うことで、お気に入りのペットの見た目に近づくための詳細情報を提供できます。 プロンプトエンジニアリングを用いることで、より Ron や Smila に似た画像が生成されましたが、完全に類似した画像の作成は、このモデルでは不可能であるように見えます。では、Ron と Smila の写真を使ってファインチューニングジョブを開始し、一貫性のある、パーソナライズされた出力が得られるようにしましょう。 Amazon Titan Image Generator のファインチューニング Amazon Bedrock では、Amazon Titan Image Generator のモデルのファインチューニングをサーバーレスで利用可能です。データを準備してハイパーパラメータを選択するだけで、面倒な作業は AWS が代わりに処理します。 Amazon Titan Image Generator のモデルを使用してファインチューニングを行うと、AWS が所有・管理するモデル開発用 AWS アカウントにこのモデルのコピーが作成され、モデルのカスタマイズジョブが作成されます。このジョブは VPC を通じてファインチューニング用のデータにアクセスし、Amazon Titan のモデルの重みが更新されます。新しいモデルは、事前学習済みモデルと同じモデル開発アカウントにある Amazon Simple Storage Service (Amazon S3) に保存されます。これで、お客様のアカウントでのみ推論に使用できるようになり、他の AWS アカウントと共有されることはありません。推論を実行する際は、 プロビジョニングされたコンピュートキャパシティ を介してこのモデルにアクセスするか、 Amazon Bedrock のバッチ推論 を使用して直接アクセスします。選択した推論方法に関わらず、データはお客様のアカウントに残り、AWS が所有するアカウントにコピーされたり、Amazon Titan Image Generator のモデルの改善に使用されたりすることはありません。 次の図は、このワークフローを示しています。 データプライバシーとネットワークセキュリティ プロンプトやカスタムモデルなどのファインチューニングに使用されたデータは、お客様の AWS アカウントで非公開のまま保存されます。これらはモデルのトレーニングやサービス向上のために共有または使用されることはなく、サードパーティのモデルプロバイダーと共有されることもありません。ファインチューニングに使用されるすべてのデータは、転送中も保存中も暗号化され、API コールが処理されたのと同じリージョンに残ります。また、 AWS PrivateLink を使用して、データが存在する AWS アカウントと VPC との間にプライベート接続を作成することもできます。 データの準備 モデルカスタマイズジョブを作成する前に、 トレーニング用のデータセットを準備する 必要があります。トレーニング用のデータセットの形式は、作成するカスタマイズジョブの種類 (ファインチューニングまたは継続的な事前トレーニング) とデータのモダリティ (text-to-text、text-to-image、または text-to-embedding) によって異なります。Amazon Titan Image Generator のモデルでは、ファインチューニングに使用する画像と各画像のキャプションを提供する必要があります。Amazon Bedrock では、画像は Amazon S3 に保存され、画像とキャプションの組み合わせは複数の JSON の行を含む JSONL 形式で提供されることを想定しています。 JSON の各行は、image-ref（画像の S3 URI）、と画像のテキストプロンプトを含むキャプションが含まれたサンプルです。画像は JPEG または PNG 形式である必要があります。次のコードはフォーマットの例を示しています。 {"image-ref": "s3://bucket/path/to/image001.png", "caption": " &lt;prompt text&gt; "} {"image-ref": "s3://bucket/path/to/image002.png", "caption": " &lt;prompt text&gt; "} {"image-ref": "s3://bucket/path/to/image003.png", "caption": " &lt;prompt text&gt; "} 「Ron」と「Smila」は人の名前など、他の文脈でも使用できる名前なので、モデルをファインチューニングするためのプロンプトを作成するときに「Ron the dog」と「Smila the cat」という識別子を追加します。これはファインチューニングのワークフローの要件ではありませんが、この追加情報により、新しいクラスにカスタマイズする際に、モデルの文脈がより明確になり、「Ron the dog」と Ron という人物を、「Smila the cat」をウクライナの Smila という都市と混同することがなくなります。このロジックを使用して、以下の画像はトレーニングデータセットのサンプルを示しています。 Ron the dog laying on a white dog bed Ron the dog sitting on a tile floor Ron the dog laying on a car seat Smila the cat lying on a couch Smila the cat staring at the camera laying on a couch Smila the cat laying in a pet carrier カスタマイズジョブで想定される形式にデータを変換すると、次のサンプル構造が得られます。 {"image-ref": " &lt;S3_BUCKET_URL&gt; /ron_01.jpg", "caption": "Ron the dog laying on a white dog bed"} {"image-ref": " &lt;S3_BUCKET_URL&gt; /ron_02.jpg", "caption": "Ron the dog sitting on a tile floor"} {"image-ref": " &lt;S3_BUCKET_URL&gt; /ron_03.jpg", "caption": "Ron the dog laying on a car seat"} {"image-ref": " &lt;S3_BUCKET_URL&gt; /smila_01.jpg", "caption": "Smila the cat lying on a couch"} {"image-ref": " &lt;S3_BUCKET_URL&gt; /smila_02.jpg", "caption": "Smila the cat sitting next to the window next to a statue cat"} {"image-ref": " &lt;S3_BUCKET_URL&gt; /smila_03.jpg", "caption": "Smila the cat lying on a pet carrier"} JSONL ファイルを作成したら、カスタマイズジョブを開始するために S3 バケットに保存する必要があります。Amazon Titan Image Generator G1 のファインチューニングジョブは、5 ～ 10,000 枚の画像を処理できます。この投稿で説明する例では、60 枚の画像を使用します。30 枚は Ron the dog、30 枚は Smila the cat です。一般的に、学習したいスタイルやクラスの種類を増やせば、ファインチューニングしたモデルの精度が向上します。ただし、ファインチューニングに使用する画像が多いほど、ファインチューニング作業が完了するまでにかかる時間が長くなります。使用する画像の数は、ファインチューニングするジョブの価格にも影響します。詳細については、 Amazon Bedrock の料金 を参照してください。 Amazon Titan Image Generator のファインチューニング トレーニングデータの準備ができたので、新しいカスタマイズ作業を開始できます。このプロセスは Amazon Bedrock のコンソールまたは API のどちらからでも実行できます。Amazon Bedrock コンソールを使用するには、以下の手順を実行します。 Amazon Bedrock コンソールのナビゲーションペインで カスタムモデル を選択します。 モデルをカスタマイズ メニューで、 ファインチューニングジョブを作成 を選択します。 ファインチューニングされたモデル名 に、新しいモデルの名前を入力します。 ジョブの設定 には、トレーニングジョブの名前を入力します。 入力データ には、入力データの S3 パスを入力します。 ハイパーパラメーター セクションで、以下の値を指定します。 ステップ数 — モデルが各バッチに公開される回数。 バッチサイズ — モデルのパラメーターを更新する前に処理されたサンプルの数。 学習率 — 各バッチ後にモデルパラメーターが更新される割合。これらのパラメーターの選択は、特定のデータセットによって異なります。一般的なガイドラインとして、まずバッチサイズを 8 に、学習率を 1e-5 に固定し、次の表に示すように、使用する画像の数に応じてステップ数を設定することをお勧めします。 提供された画像の数 8 32 64 1,000 10,000 推奨ステップ数 1,000 4,000 8,000 10,000 12,000 ファインチューニングジョブの結果が満足のいくものでない時は、生成された画像にスタイルの兆候が見られない場合はステップ数を増やし、生成された画像にアーティファクトやぼやけがあるスタイルが見られる場合はステップ数を減らすことを検討してください。ファインチューニングしたモデルが 40,000 ステップを踏んでもデータセット内の独自のスタイルを学習できない場合は、バッチサイズまたは学習率を上げることを検討してください。 出力データ セクションに、定期的に記録される検証の損失と精度メトリクスを含む検証の出力が保存される S3 の出力パスを入力します。 サービスアクセス セクションで、新しい AWS Identity and Access Management （IAM）ロールを生成するか、S3 バケットにアクセスするために必要な権限を持つ既存の IAM ロールを選択します。 この認証により、Amazon Bedrock は指定されたバケットから入力データセットと検証データセットを取得し、検証の出力を S3 バケットにシームレスに保存できます。 モデルをファインチューニング を選択してください。 正しい構成が設定されたら、Amazon Bedrock がカスタムモデルをトレーニングします。 プロビジョニンドスループットでファインチューニングされた Amazon Titan Image Generatorをデプロイする カスタムモデルを作成したら、プロビジョンドスループットを使用して、カスタムモデルにあらかじめ決められた固定レートの処理能力を割り当てることができます。この割り当てにより、ワークロードを処理するための一貫したパフォーマンスと容量が提供されるため、本番環境のワークロードのパフォーマンスが向上します。プロビジョンドスループットの 2 つ目の利点はコスト管理です。オンデマンド推論モードによる標準的なトークンベースの価格設定では、大規模になるとコストの予測が難しくなることがあります。 モデルのファインチューニングが完了すると、そのモデルが Amazon Bedrock のコンソールの カスタムモデル ページに表示されます。 プロビジョンドスループットを購入するには、ファインチューニングしたカスタムモデルを選択し、 プロビジョンドスループットを購入 を選択します。 これにより、プロビジョンドスループットの購入対象として選択したモデルがあらかじめ入力されます。デプロイ前にファインチューニングしたモデルをテストするには、モデルユニットの値を 1 に設定し、コミットメント期間を コミットメントなし に設定します。これにより、カスタムプロンプトを使用してモデルのテストをすぐに開始し、トレーニングが適切かどうかを確認できます。さらに、新しいファインチューニングモデルや新しいバージョンが利用可能になった場合、同じモデルの他のバージョンで更新する場合に限り、プロビジョニングされたスループットを更新できます。 結果をファインチューニングする Ron the dog と Smila the cat のモデルカスタマイズのタスクでは、実験の結果、5,000 ステップ、バッチサイズ 8、学習率 1e-5 が最適なハイパーパラメータであることがわかりました。 カスタマイズしたモデルによって生成された画像の例を以下に示します。 Ron the dog wearing a superhero cape Ron the dog on the moon Ron the dog in a swimming pool with sunglasses Smila the cat on the snow Smila the cat in black and white staring at the camera Smila the cat wearing a Christmas hat 結論 この投稿では、高品質な画像を生成するために、プロンプトエンジニアリングの代わりにファインチューニングを使用する例を説明しました。Amazon Titan Image Generator のモデルをファインチューニングし、そのカスタムモデルを Amazon Bedrock にデプロイする方法を示しました。また、ファインチューニング用のデータを準備する方法や、より正確なモデルのカスタマイズのための最適なハイパーパラメータを設定する一般的なガイドラインも提供しました。 こちらの事例 をご自身のユースケースに活用することで、Amazon Titan Image Generator を使用し、ハイパーパーソナライズされた画像を生成できます。 翻訳はソリューションアーキテクト菊地が担当しました。 原文 はこちらです。 著者について Maira Ladeira Tanke は AWS のシニア生成 AI データサイエンティストです。機械学習のバックグラウンドを持ち、さまざまな業界の顧客を対象に AI アプリケーションの設計と構築に 10 年以上携わってきました。テクニカルリーダーとして、Amazon Bedrock の生成 AI ソリューションを通じて、顧客がビジネス価値の達成を加速できるよう支援しています。余暇には、Maira は旅行をしたり、猫の Smila と遊んだり、暖かい場所で家族と過ごす時間を楽しんでいます。 Dani Mitchell Dani Mitchell は、AWS の AI/ML スペシャリストソリューションアーキテクトです。コンピュータービジョンのユースケースに注力し、EMEA 全域のお客様が ML ジャーニーを加速できるよう支援しています。 Bharathi Srinivasan は AWS のプロフェッショナルサービスのデータサイエンティストで、Amazon Bedrock でクールなものを構築することが大好きです。彼女は責任ある AI に重点を置いて、機械学習アプリケーションからビジネス価値を引き出すことに情熱を注いでいます。Bharathi は、顧客向けの新しい AI 体験を構築すること以外にも、SF 小説を書いたり、持久力スポーツに挑戦したりすることが大好きです。 Achin Jain は、Amazon Artificial General Intelligence（AGI）チームの応用科学者です。彼はテキストから画像への変換モデルに関する専門知識を持ち、Amazon Titan Image Generator の構築に注力しています。

この投稿では、 生成AI 技術を従来の物理ベースの 計算流体力学 (CFD)シミュレーションと組み合わせることで、自動車、モータースポーツ、航空宇宙分野の新しい設計コンセプトをたった1枚の画像から探索できる迅速な概念設計プロセスを作成できることを示します。 AWS Batch などの AWS サービスとオープンソースの TwinGraph を使用することで、 AWS 上のイベント駆動型ワークフローに組み込むことができ、数百万のシナリオを検討できるように拡張できます。TwinGraph は、予測モデリング、シミュレーション、 Level 4 Digital Twin ワークフローを大規模にデプロイできるオープンソースの TwinFlow framework 内のモデルオーケストレーションモジュールです。 機械学習 (ML) アルゴリズムの生成能力は、さまざまな業界で大きな可能性を秘めています。生成 AI 手法は、大量のデータで事前にトレーニングされた大規模な機械学習モデルによって強化されます。これらのモデルの影響は、自然言語処理用のトランスフォーマーモデル、画像操作用の Stable Diffusion のようなテキストを画像変換するモデル、ゼロショット分類用の敵対的生成ネットワーク（GAN）など、いくつかの分野で見られています。 なぜこれが重要なのか？ 現在では、Stable Diffusion のような AI 画像生成サービスを使用して、自動車、飛行機、その他の乗り物の概念設計ができます。ただし、これらの方法では、基礎となる物理法則や、騒音レベルやそれによって費やされる余分なエネルギー使用量などの設計上の制約が考慮されていないため、空力抵抗などの性能要因を理解するための基礎が欠けています。エネルギー効率と持続可能性がますます重視される時代にあって、概念設計はスタイルガイドラインに従うだけでは不十分です。 過去数十年にわたって、CFD 主導型の設計最適化は、多くの業界で大きく発展してきました。一般的なワークフローでは、通常、従来の物理ベースのソルバーを使用してさまざまな個別パラメーター (翼の弦の長さ、リアウィンドウの角度など) に対して複雑な形状をシミュレートし、パラメータ空間全体にわたって最適な設定を見つけます。 これらのソルバーは高い精度を提供しますが、計算量が多く時間がかかるため、設計のペースが遅くなります。これらの計算上の課題を克服するために、従来の CFD モデルと ML アプローチを組み合わせることへの関心が高まっています。設計プロセスに生成 AI を使用すると、検討中のシステムの物理的に意味のある設計構成に基づいて、ノンパラメトリックな方法でパラメータ空間を効率的に探索できます。 生成 AI を設計の最適化にどのように適用できるかをお見せしたいと思います。このブログでは、車両の空気抵抗を低減するためのより優れたソリューションを見つける際の効果に焦点を当てます。このアプローチは、初期設計段階の生成 AI と、車両の空気抵抗の評価のための OpenFOAM CFD シミュレーションを組み合わせたものです。 このプロセスを通じて、ユーザーがノンパラメトリック設計最適化問題を、堅牢なインフラストラクチャを備えた AWS での大規模な実行に適したアルゴリズムとして定義できるワークフローを開発しました。これは、動的なタスク オーケストレーション、来歴情報の収集、およびスケーリングという、ワークフローに必要な面倒なタスクを引き受けてくれる&nbsp; Twingraph によって支えられています。 図1:&nbsp;生成 AI 技術と数値流体力学シミュレーションを組み合わせた、自動車の空気力学の反復設計最適化のための全体的なワークフロー Stable Diffusion によるデザインの繰り返し Stable Diffusion は、テキスト主導型の操作による画像生成を可能にする生成 AI モデルです。Stable Diffusion の基盤となるアーキテクチャは、次の 3 つの主要な要素で構成されています。 画像に描かれている物体や人物の意味を捉える、画像の潜在的な表現を取得する この表現にガウスノイズを段階的に追加する ノイズを除去して画像を再構築すると、テキストプロンプトのセマンティクスを反映した、元の画像の修正されたバリアントが得られる 例として、図 2 では、Stable Diffusion を使用して自動車設計を変更した結果を示しています。まず、セダンのストックイメージから始めて、スポーティな空力設計に変換します。これにより、元の画像から変更された画像への一連の変換が行われました。 この例では、事前トレーニングされた Stable Diffusion モデルが画像生成に使用されましたが、これは個々の自動車メーカーの設計思想に合わせて微調整できます。 図2 : Stable Diffusion v2.1 の image-to-image のパイプラインを使用して、空気力学を改善し、車をよりスポーティにするための適切なプロンプトが与えられた場合の自動車デザインの連続的な変換 しかし、この変換は基礎となる物理特性に基づくものではなく、Stable Diffusion アルゴリズム内の画像の凝縮された数学的表現である潜在空間埋め込みと並行してプロンプトを解釈したものです。一方、この解釈は、公開されたスポーツカーのトレーニングデータに基づいたモデルのため、類似した外観のデザインになりがちです。変換パスが車両の空気力学を改善するかどうかを正確に評価するには、画像を高精度の CFD シミュレーションに使用できる 3D 表現に変換するのが自然な手順です。 NeRF を用いた点群の生成 Neural Radiance Fields (NeRF) は、1つ以上の画像を完全な 3D 表現に変換するうえで非常に有望なアルゴリズムです。 ブートストラップされた NeRF と敵対的生成ネットワーク (GAN) を組み合わせることで、オブジェクトの複数のポーズを再構築して予測を強化および改善できます。 これを機能させるには、自動車の画像を NeRF に入力して符号付き距離関数 (SDF) を取得し、図 3 に示すような点群表現を構築します。3D オブジェクト再構成用に Pascal3D データセットを使用して NeRF モデルを微調整しました。 図 3 : NeRF を使用して取得した車の点群 (下) をベース画像 (上) を使用して取得し、その画像を自動車を表す 3D 構造に変換 点群からの表面トポロジーの再構築 点群表現には、車両周囲の空気の流れの挙動を理解するために必要な、重要な接続性や表面トポロジ情報が不足しています。 点群から表面を再構築するために、最初に非構造化多角形アルファ形状メッシュ (非凸包の場合) を生成しました。これは、 Open3D ライブラリを使用した粗いドロネー三角形分割によって実現しました。この計算幾何学的手法は、NeRF から生成された点群内に表示される点を含む包含表面を識別します。 メッシュをさらに改良するために、アルファ形状から推定された法線とともに、表面上に生成された点 (初期三角形分割のノード) を抽出しました。 この表面点群は、まばらなデータから高速に表面再構成を実行できる機械学習手法である ニューラルカーネル表面再構成 (NKSR) アルゴリズムに取り込まれます。最終結果を図 4 に示します。この手法では表面の詳細はキャプチャされませんが、生成されたメッシュによって車の全体的な形状がほぼモデル化されます。 図 4: NKSR を使用して生成された表面メッシュ。元の点群 (上) と三角形メッシュ (下) は一般的な地形的特徴において良好な一致を示しています。 OpenFOAM で CFD シミュレーションを実行する OpenFOAM を使用して車両の周囲の流れ場を計算しました。 前のステップで生成した .obj ファイルの blockMesh と SnappyHexMesh を使用して、角柱状の境界層セルを持つ非構造化ヘキサ主体メッシュを構築します。 この投稿では、業界で通常採用されているレベルよりもはるかに低い洗練レベルを意図的に選択しました (必要に応じてこれらのレベルを上げることができます)。 メッシュ数は平均して約 100 万セルでした。これはジオメトリ自体によって若干変化します。 プロセスの CFD 部分を高速化するために、k-omega SST モデルを使用した定常状態の RANS シミュレーションに限定しました (産業アプリケーションの場合は、これを拡張して、より忠実度の高いハイブリッド RANS-LES または WMLES メソッドを使用できます)。 最後に、今回のセットアップでは、圧力結合方程式の半陰解法 (SIMPLE) アルゴリズムに基づく simpleFoam ソルバーを使用しました。 表 1 にパラメータを示します。 表 1: 数値流体力学シミュレーションに使用される定数 図 5 の画像は、初期の自動車設計における流線と表面圧力を示しています。 このシミュレーション例では、メッシュに 425,045 個のセルを使用しました。 図 5: 生成された自動車メッシュの周囲の流れ場を視覚化した流線 – これらは流体速度を示し、自動車表面の色は表面圧力の大きさを示します。 後処理中に抗力係数 (Cd) 値を計算するために、初期設計に基づいて基準ホイールベース長と前面表面積を導き出しました。これらの基準値はすべての観測にわたって比較的一定のままです。 パイプラインの最終的な抗力係数 (Cd) 値を使用して、生成された設計オプションを評価およびランク付けし、最適な中間選択肢を見つけました。 AWS のシミュレーションガイド付き設計ワークフローへの統合 全体的なワークフローには、画像生成、Stable Diffusion、NeRF による点群、Open3d と NKSR によるメッシュ生成、そして最後に OpenFOAM CFD シミュレーションという 5 つの主要なコンポーネントがあります。 これらはそれぞれ、 TwinFlow フレームワーク 内の TwinGraph オーケストレーション モジュールによってコンテナ化され、オーケストレーションされます。 このワークフローは AWS Batch を使用してデプロイし、必要に応じてスケーリングして最適な設計を見つけました。各ワークフローコンポーネントの特定の要件に応じて、CPU と GPU の両方のアーキテクチャを活用することで、必要な規模を実現しました。 図 6: リモート クライアントとの接続から、TwinGraph でのアルゴリズム パイプラインの起動、AWS Batch でのジョブの実行、結果の視覚化までの実行ワークフローの AWS アーキテクチャ図。 生成された多数の画像に対して複数のサイクルにわたって実験を繰り返し、各実験の結果を Amazon Simple Storage Service (Amazon S3) に自動的にアップロードしました。 これにより、結果が永続的に保存されるようになりました。 各実験で必要なメタデータの出所情報は、その後の分析に備えて Amazon Neptune グラフ データベースに自動的にアップロードされました。 結果が生成されると、GPU インスタンスを使用して Amazon S3 から関心のある特定の結果を取得できます。 NICE DCV (AWS 製品) と呼ばれる高性能リモートデスクトッププロトコルを使用して可視化インターフェイスを実行しました。 全体として、 TwinGraph は非同期方法でタスクを調整します。つまり、AWS Batch を使用して複数の実験を同時に大規模に実行できます。 結果 数値実験の一環として、一般的なセダンを使用して、図 1 と同じ初期化を使用して、Stable Diffusion の image-to-image 生成、表面再構成、および CFD シミュレーションの 10 の異なるインスタンス (10 種類) を実行しました。 次の画像生成シーケンスサイクルのシードには、最も低い抗力係数 (Cd) 値に対応するバリアント画像を使用しました。設計の反復プロセスをきめ細かく導くため、図1と比較して、画像から画像への変化の強度を大幅に減らしました。 このサイクルを20回 (または20世代) 繰り返し、その結果を図7に世代ごとの最小抗力係数 (Cd) として、図8に生成された各設計の抗力係数 (Cd) 値のヒートマップとしてプロットしています。 次の画像生成シーケンス サイクルのシードとして、最も低い抗力係数 (Cd) 値に対応するバリアント画像を使用しました。 設計の反復プロセスを細かいレベルでガイドするために、図 1 と比較して、 image-to-image の変更の強度を大幅に低減しました。 このサイクルを 20 回 (または 20 世代) 繰り返しました。結果は、世代ごとの最小抗力係数 (Cd) として図 7 にプロットされ、生成された各設計の抗力係数 (Cd) 値のヒートマップとして図 8 にプロットされています。 図 7: 世代ごとの最小抗力係数。後続の世代のバリアントの作成に使用される画像バリアントに対応します。 一般的な下降傾向は、車両の中間構成により単調ではありませんが、パイプラインが世代を通じて最良のバリアントの抗力性能を向上させていることを示しています。 図 7 は、平均抗力係数 (Cd) が初期値 0.46 から約 0.4 まで徐々に減少することを示しています。 連続した世代の間、減少は非単調です。 これは、最適化手順のノンパラメトリックかつ非線形の性質によるもので、画像生成プロセスで抗力を減らすという最終目標に向かって自動車のデザインを任意に変形させることができます。 さらに、中間設計構成には不完全なコンポーネントが含まれているため、画像生成プロセスで特徴が解決されるまで、数世代にわたって抗力が増加します。 これを、図 8 に示す 20 世代の各バリアントに対応する抗力係数を通じてさらに調査しました。平均抗力係数 (Cd) は中間世代でわずかに増加しますが、20 世代の終わりに向かって徐々に減少します。 図 8: 各世代 (横軸、画像生成、メッシュ再構築、およびシミュレーションからなるシーケンス) 中の 10 のバリアントのそれぞれ (縦軸) に関連付けられた抗力係数の図。 青色の領域は抗力が低いことを示しており、世代が進むにつれて青色の領域が増加する傾向が観察できます。 図 9 : 抗力係数の最適なバリアントの世代間の遷移シーケンス。車のボンネットが滑らかになり、フロントガラスの角度が減少することを示しています。 図 9 は、世代を超えた自動車設計の進化についての洞察を示しています。 車のボンネットは、材料を大幅に除去して曲面形状に適応します。 また、水平線に対するフロントガラスの角度が減少し、車の後部セクションの曲率がわずかに変化します。 全体的に見ると、これらは生成 AI プロセスによって引き起こされる微妙ではあるが重要な変化であり、自動化された物理情報に基づいたパイプラインを通じて情報に基づいた設計の選択を導く可能性を示しています。 制限事項と今後の取り組み ここで紹介するアプローチは、美的感覚と持続可能性に焦点を当てたノンパラメトリック設計の最適化を加速させる可能性を秘めています。しかし、各段階には克服すべき限界があります。 事前にトレーニングされた Stable Diffusion ネットワークの重みが (さらなるトレーニングにより) 変化および進化すると、予測不可能な形で変化するため、再現性が問題になります。 また、この方法を使用して表面トポロジーと粗さを正確にキャプチャすることは、フル解像度のコンピュータ支援設計 (CAD) メッシュと比較して、点群からの損失の多い再構成により複雑になります。 これは正確な抗力計算にとって重要です。 ただし、生成 AI アルゴリズムの改善により、機械学習と古典的な物理ベースのシミュレーションを組み合わせたワークフローが実用的なメリットをもたらすことが期待できます。 複数のコンポーネントを単一のアルゴリズム パイプラインに統合し、基盤となるインフラストラクチャ、コンピューター アーキテクチャ、プログラミング モデルの選択に依存せずに拡張できます。 これにより、将来の設計最適化コンセプトを複数のドメインにわたってより簡単かつ確実に展開するためのテンプレートが提供されます。 結論 この投稿では、生成 AI 技術と物理ベースの CFD シミュレーションを統合する可能性について説明しました。 CFD シミュレーションを使用して、物理学に基づいた抗力係数 (Cd) を使用して画像生成プロセスをガイドする機能を備えた方法論を示しました。 また、これらの画像を 3D メッシュに変換する方法も紹介しました。これらのメッシュはCFDシミュレーションに使用されましたが、CADプログラムにインポートして実際の設計プロセスで使用することもできます。 何よりも、 AWS Batch と TwinGraph のおかげで、これを単一のイベント駆動型のワークフローに統合しました。これにより、機械学習とシミュレーションのタスクをスケールアウトできます。 この作業は生成 AI モデルを使用した推論の実行に重点を置いていますが、 Amazon Bedrock と Amazon SageMaker JumpStart を使用してモデルを微調整する際の開発者エクスペリエンスを向上させることもできます。 Amazon Bedrock は、API を介して主要な AI スタートアップ企業 (および Amazon 自体) の基盤モデルを提供するフルマネージド サービスです。 Bedrock を使用すると、AWS の安全で信頼性の高いインフラストラクチャを使用してプライベートにカスタマイズおよび拡張できる生成 AI アプリケーションの開発をスピードアップできます。 SageMaker Jumpstart は、管理された環境でこれらの基礎モデルをトレーニングし、微調整する機能を提供します。 このアプローチを産業界に適用するにはまださらなる開発が必要ですが、生成 AI 技術と物理ベースのシミュレーションを統合できる可能性を示しています。この可能性は自動車のCFD設計だけにとどまらず、他の多くの科学・工学分野にも応用できると期待されています。 &nbsp; Dr. Vidyasagar Ananthan Vidyasagar は、産業および学術環境におけるハイパフォーマンスコンピューティング、数値シミュレーション、最適化手法、ソフトウェア開発を専門としています。AWS では、Vidyasagar は予測モデルとシミュレーション技術を開発するシニアソリューションアーキテクトです。 &nbsp; &nbsp; Satheesh Maheswaran Satheesh は科学計算の分野で18年以上の経験があり、特に産業環境と学術環境におけるシミュレーションとデータ分析に重点を置いてきました。AWS では、Satheesh はシニアソリューションアーキテクトとして、予測シミュレーションと HPC と機械学習アプローチの融合に重点を置いています。 &nbsp; &nbsp; Neil Ashton Neil は元 F1 および NASA のエンジニアで、乱流モデリング、ディープラーニング、高性能コンピューティングに特に重点を置いた最先端の計算流体力学手法の開発を専門としています。アドバンスト・コンピューティング・アンド・シミュレーション製品チームのプリンシパル・コンピュテーショナル・エンジニアリング・スペシャリストです。 &nbsp; &nbsp; Srinivas Tadepalli Srinivas は、AWS の HPC 市場開拓のグローバル責任者であり、商業部門と公共部門の顧客の両方を対象とするさまざまな HPC およびアクセラレーテッドコンピューティングワークロードを対象とした包括的な GTM 戦略の構築を担当しています。以前はダッソー・システムズに勤務し、生物医学工学の博士号を取得しています。 &nbsp; 翻訳はソリューションアーキテクトの 山田航司 が担当しました。原文は こちら です。

株式会社リクルートは、日本国内のHR・販促事業及びグローバル斡旋・販促事業をおこなう事業会社です。リクルートでは、『スタディサプリ』というスマートフォンアプリ、パソコンで利用可能なオンライン学習サービスのデータベースとして Amazon Aurora PostgreSQL を採用しています。 2023 年 5 月にこの Aurora PostgreSQL を Aurora Serverless v2 に変更しました。採用検討から 1.5 ヶ月と短期間で導入を決定しましたが、入念な検証の結果 Aurora の運用負荷を大幅に削減し、サービスの安定運用も実現しています。本ブログは、『スタディサプリ』の Aurora PostgreSQL を Aurora Serverless v2 に変更した時の検討から移行後の効果や課題についてご紹介します。 アーキテクチャ 以下は、Aurora Serverless v2 採用前のアーキテクチャです。データベースとしては、Aurora PostgreSQL をご利用されています。システムは下記右側の図に示すようなマイクロサービスアーキテクチャ (2023/03 時点) で構成されており、本番・開発環境含めて 26 の Aurora クラスタを利用しておられました。また、各クラスタは冗長化のためマルチ AZ 構成を採用していました。 Aurora Serverless v2 採用前の課題 『スタディサプリ』では、中学・高校の授業が始まる前の朝 8 時ごろにアクセスが集中する傾向にありました。このアクセス増による負荷は、この時間帯のみの一時的なものであり、その他の時間帯はこの時間帯と比較して約 1/3 程度とリソースとして余裕がある状況でした。そして、この負荷の高い時間帯を基準としながら、受験シーズンなど季節的な要因や今後のユーザー数の増加、機能追加などによる処理量を考慮してデータベースをサイジングする必要があったため、インスタンスサイズを大きめにサイジングする必要があり、これが結果的にコスト増になっていました。そしてさらに、コロナ禍によるユーザー数の増加でデータベースへの処理量も増加しました。これによるサービスへの影響なども懸念されたため、アクセスが集中する 8 時台の状況を注視する状況が続いていました。 この状況を改善するため、Aurora に Reader インスタンスを追加して負荷を分散させる案も検討されましたが、アプリケーションの特性として Write 処理が支配的であった為、Reader インスタンスの追加や Auto Scaling などでは負荷分散が限定的になってしまうことがわかりました。 Aurora Serverless v2 の導入 このような状況から、 Aurora Serverless v2 の検討が進められました。Aurora Serverless v2 は負荷に応じてシームレスにスケールアップ・ダウンすることができる Aurora の機能の一つです。Aurora Serverless v2 は Writer インスタンスにも適用できるため、今回の『スタディサプリ』というアプリケーションの特性に合った機能でした。 Aurora Serverless v2 採用に向けた検討のポイントとしては大きく 3 つありました。 1 つ目はコスト、 2 つ目は性能影響、 3 つ目は移行性です。 コスト 検討ポイントの 1 つ目はコストです。今回のように特定の時間帯だけ負荷が増大するようなケースだと、通常の Provisioned インスタンスの場合ではピークに合わせたサイジングが必要となり、ピーク時間帯以外は過剰なインスタンスサイズとなってしまいます。また、ピークは最も処理量が多いケースでもリソースが不足しないようサイジングするため、実際にピークで使用されるリソース以上のインスタンスサイズが必要となります。さらに、障害を考慮してマルチ AZ 配置 を採用する場合、 Reader インスタンスも Writer インスタンスと同じインスタンスサイズで構成する必要があります。一方、Aurora Serverless v2 の場合、アプリケーションのワークロードに合わせてインスタンスのリソースが動的に変更されます。この為、今回のような特定の時間帯だけリソースを使うようなワークロードの場合、Aurora Serverless v2 だと特定の時間帯だけリソースを大きくしてその他の時間帯は小さくするといった運用を実現し、リソースを有効に使用できます。また、今回のケースのように障害時に備えて Reader インスタンスを構成している場合、Aurora Serverless v2 の Reader インスタンスの昇格階層を 2 〜 15 に設定することで指定された Aurora Capacity Unit(ACU) の最小値までスケールダウンして運用することができます。これにより、 Reader インスタンスのコストを大幅に削減することが可能になり、結果的に Provisioned の時と比較してほぼ同程度のコストで運用可能であると確認することができました。 性能影響 2 つ目が性能影響です。リクルート様では、本番の負荷が発生した際のレイテンシーやスループット、スケーリングについて Provisioned インスタンスと Aurora Serverless v2 で比較検証されました。検証の結果、レイテンシーについては、 Provisioned インスタンスとほぼ同程度の結果となり、問題ないことを確認することができました。スケーリングについては、スケーリング時の性能影響は問題ありませんでしたが、 MinACU が小さい状態で急激に処理量が増加したときにフェイルオーバーが発生することがありました。 ACU とは Aurora Capacity Unit の略で Aurora Serverless v2 のキャパシティの単位であり、ワークロードのトラフィックに応じてインスタンスの ACU が増減します。 MinACU は負荷がおさまってスケールインする際の ACU の最小値を意味します。今回の場合、 2 分の間に 10 倍の負荷が増加するワークロードを想定してテストしていましたが、 MinACU を小さく設定しすぎていたため、スケールアップ処理が完了する前に耐え切れないほど IO が増加してしまい、結果としてフェイルオーバーを引き起こしていることがわかりました。この為、このような処理量の増加を想定して MinACU もある程度大きく設定することで、フェイルオーバーの問題も回避することができました。以上の結果、Aurora Serverless v2 移行による性能面への影響は許容可能であるということを確認することができました。 移行性 3 つ目が移行性です。インスタンスを Provisioned インスタンスから Aurora Serverless v2 に変更する場合、Aurora Serverless v2 の Reader インスタンスを追加してフェイルオーバーするだけで、Provisioned インスタンスから Aurora Serverless v2 に簡単に切り替えることができます。この為、万が一、本番で Aurora Serverless v2 を起因した問題が発生した場合、再度フェイルオーバーすることで元の Provisioned インスタンスに切り戻すことが簡単にできます。また、アプリケーションとしても、Design for Failure にもとづき DB のフェイルオーバーがビジネス的に問題にならないよう障害を考慮した設計されていました。このように、Aurora Serverless v2 への切り替えや Provisioned への切り戻しが容易であるということで、本番トラブル時の切り戻しを考慮する必要がなくなり、本番導入への心理的な負担も抑えることができたことは短期間で採用することができた要因でした。 本番への導入 以上、 3 つのポイントについて検討、検証した結果、Aurora Serverless v2 の本番導入が決定されました。Aurora Serverless v2 の検討開始から本番への導入は、 1.5 ヶ月という短期間で実施することができました。導入は、 26 クラスタの中から数クラスタに対して変更を実施して問題がないことを確認した後で、その他のクラスタへの適用を進めました。Aurora Serverless v2 を採用してから 2024 年 3 月現在まで、導入後約 1 年近くが経過しましたが、導入当初は細かい事象が発生していたものの、現在は安定して運用することができています。 Aurora Serverless v2 導入効果と課題 今回、Aurora Serverless v2 を導入したことで気づいた点も何点かありました。導入して得られた効果については大きく 3 つでした。 想定外の負荷でも対処不要に Provisioned インスタンスの時は、負荷を考慮したインスタンスサイズが割り当てられていましたが、それでも想定外に負荷が増加した場合はデータベースサーバーのリソースが不足する可能性があり、パフォーマンスへの影響調査や障害対応などの作業が発生していました。Aurora Serverless v2 に変更したことで、想定外の負荷でも動的にスケールアップ/ダウンされるため、負荷が増加した時のリソース不足の懸念がなく、 8 時台の状況を注視するような運用負荷を削減することができています。 Provisioned インスタンスの時と同程度のパフォーマンス 検証ではパフォーマンスについて確認していたものの、本番導入後のパフォーマンスについては心配もありましたが、Aurora Serverless v2 に変更したことによる大きな問題はありませんでした。 Aurora Serverless v2 でのコスト削減 Aurora Serverless v2 のコストは一般的に Provisioned インスタンスと比較して高くなることもありますが、『スタディサプリ』ではピーク時のインスタンスサイズを常時確保する必要がなくなったことと、Reader インスタンスのサイズを抑えられることができたため、結果として僅かですが Provisioned インスタンスの時よりコストを削減することができています。 Aurora Serverless v2 導入後の課題や気づき 一方、 Aurora Serverless v2 導入による課題や気づきもありました。 MinACU が小さいことによるフェイルオーバー MinACU が小さいことでフェイルオーバーする事象が発生しました。MinACU が小さいと Aurora の CPU やメモリなどのリソースも小さい状態になるため、ディスク I/O が上昇してスケーリングが間に合わずにエラーになることがありました。Aurora のフェイルオーバーの時間は数十秒であり、アプリケーションとしても、エラー後に再接続するような処理になっていたため、ユーザーへの影響は極小化することができていましたが、再発防止のため、 MinACU を大きくしてリソースが小さくなりすぎないよう制御することで問題を解消することができています。また、Performance Insights を使用している場合、Reader インスタンスの MinACU の最小値は 2 ( 参考ドキュメント ) である為、Reader インスタンス側の MinACU の値も変更されました。 Aurora Serverless v2 のコスト 今回のシステムの多くの Aurora クラスタでは、ワークロードの特性から Provisioned インスタンスと同程度で運用することができていますが、その他一部の Aurora クラスタでは Aurora Serverless v2 の方がコストが高いケースがあるため、特性を見定めて Aurora Serverless v2 を採用している状況です。Aurora Serverless v2 の料金がもう少し下がると他システムでの採用もしやすくなると考えています。 まとめ 今回のブログでは、Aurora Serverless v2 の導入により、短期間で Aurora の運用課題を改善した事例をご紹介しました。リクルートでは、今回の Aurora Serverless v2 導入のように、新しい機能やサービスも採用しています。 AWS の SA や Sales と連携し、新しい技術採用に関しても相談しながらシステム開発を進めることができている点も、今回のように Aurora Serverless v2 を短期間で導入することができた要因の一つと言えそうです。 今後も、リクルートでは AWS の新しい機能やサービスを利用しながら、システムの安定化やコスト最適化、サービス向上などを実現していく予定です。

世界のパブリック・クラウド市場は、今後数年間で大幅な成長が見込まれており、「エンドユーザーの支出額は2024 年に6790 億ドルに達すると予測されています[ 1 ]」。この急成長は、企業による既存ワークロードの継続的な移行、新しいクラウドネイティブアプリケーションの開発、そして生成AI のような革新的なユースケースの出現によって促進されています。 AWS のクラウドエコノミクスチームは、コスト削減、スタッフの生産性、オペレーショナルレジリエンス、ビジネスの俊敏性、サステナビリティなど、さまざまな柱にわたってクラウド・コンピューティングのビジネス価値を訴求するクラウドバリューフレームワーク（CVF）を開発しました。私たちは、組織と密接に協力し、変革の道のりに寄り添いながら、CVF の柱に沿って成果を定量化することで、5 年間の包括的な総所有コスト（TCO）予測を提供しています。しかし、ビジネス状況の変化に応じて進捗状況を追跡し、ROI (Return on Investment, 投資対効果)の進捗状況を追跡し確実にすることは、極めて大事なことです。 そこで重要な役割を果たすのが、主要業績評価指標（key performance indicators, KPIs）です。KPI は、インプットに基づく標準化された手法を提供し、テクノロジーとビジネスの側面から組織のクラウド成熟度を評価します。このブログでは、テクノロジー分野のKPI について詳しく説明し、後続にリリースするブログではビジネス分野のKPI について説明していきます。 KPI を理解する KPI は、特定の目標や目的に対する組織のパフォーマンスを評価するための貴重なツールです。ユニットメトリクス（訳注：単位あたりの経済性や採算性）は、特定の活動をきめ細かく測定し、コスト削減イニシアチブの影響を測定するのに有用なのに対し、KPI は、包括的な視点を提供し、組織が戦略的優先事項に集中することを可能にし、全体的な影響についてより広い視野を提供することができます。その重要性と複数の利害関係者からのインプットが必要であることを考えると、KPI の導入は非常に困難を伴います。とはいえその重要性は、そこに必要な労力を正当化するのに十分だといえるでしょう。これらの指標を活用することで、組織は、継続的な改善や是正措置の必要性について、十分な情報に基づいた意思決定を行い、戦略を軌道に乗せることができます。 適切なKPI を選択する 適切なKPI を選択するには、慎重な検討が必要です。以下にいくつかのガイドラインを示します。 簡潔にする： ステークホルダーを圧倒しないよう、KPI は5 つ以内にする。 SMART 基準を使用する： KPI は目標設定のフレームワークであるSMART（具体的（Specific）、測定可能（Measurable）、達成可能（Attainable）、経営目標に関連した（Relevant）、時間制約がある（Time-Bound))を基準にする。 実行可能なものにする： 特定のアクションの影響を測定するために、インプットパラメータとアウトプットとの相関関係に焦点を当てる。 どのKPI を追跡するかを決定する際には、社内の調整、データ収集の合理化、ガバナンスの確立に重点を置くべきです。KPI は、関連する経営幹部や利害関係者によってレビューされるべきであり、データ収集は標準化されるべきであり、報告と是正措置のプロセスが確率されるべきです。また、選択した KPI が時間の経過とともに有効であるかどうかを評価する、継続的な回顧的メ カニズムを検討することも重要となります。 ビジネス価値の柱ごとにみるKPI の例 ビジネス価値を測定するためのKPI の選定は、顧客満足度、業務効率、収益成長などへの影響を直接測定する分野に焦点を当てるべきです。万能のアプローチは存在しませんが、事例をとおしていくつかの共通テーマが見いだせてきています。以下は、ビジネス価値の柱ごとにみるKPI の例になります。 コスト削減 コスト削減のトレンド分析 では、クラウドのコスト増がオンプレミスのコスト減よりも低い割合で増加しており、クラウドのコストが正しい方向にトレンドしているかどうかを測定する。 クラウド効率 とは、クラウド費用を売上高で割ったものである。これは、クラウド費用のコスト効率と、時間経過による収益の変化を測定し比較するものである。 インフラの平均利用率 は、AWS のコンピュート、データベース、データウェアハウスのサービスがどれだけ効率的に利用されているかを測定する。組織の成熟度が高まるにつれて、リソースの利用率は上昇傾向になる。 生成AIのトレーニングやファインチューニングのコスト は、企業がROI を計算するための基本的な部分として、計算リソース、データ取得、人間のアノテーション作業など、生成AIに関連するコストを測定することを可能にする。 スタッフの生産性 新しいアカウントとインフラストラクチャコンポーネントの展開にかかるリードタイム は、組織の財務、セキュリティ、およびアーキテクチャのガイドラインを満たす一般的なインフラストラクチャコンポーネントで新しいアカウントをプロビジョニングする時間を測定する。さらに、コンピュート、データベース、ストレージなどの導入時間を測定することもできる。 管理者一人あたりが管理する仮想マシンの数 は、管理者の責任範囲の縮小による運用効率の向上を測定する。この KPI を成功させるためには、企業は組織変更管理のための追加的な対策を実施する必要がある。 欠陥密度（コード単位当たりの欠陥数を測定） は、コード単位当たりに発見された欠陥の数を測定する。コード単位とは、特定の関数やコード行などを指す。 生成AIによるコスト回避 は、チャットサポート、要約、一般的なコンテンツ生成、反復的なソフトウェアコードや単体テストなど、以前は手作業や従来の方法によって行われていたタスクやプロセスを自動化することによって達成されるコスト削減を測定する。 オペレーショナルレジリエンス ダウンタイムの総量（またはインシデントごとの平均ダウンタイム） は、インシデントごとの計画外ダウンタイムまたは計画外ダウンタイムの総量を測定する。自動化された検知・監視メカニズムを採用することで、インシデント発生後の対応の迅速性を測定することができる。 設定ミスに起因するセキュリティインシデントの件数 は、リソースの設定ミスやセキュリティ態勢の脆弱性に起因するセキュリティインシデントの件数を測定する。 平均解決時間 は、組織がクラウドネイティブメカニズムを使用してより迅速な復旧・対応時間を開発するにつれて、平均修復時間が短縮されるかどうかを測定する。 平均検出・対応時間 は、プロアクティブな通知・対応メカニズムによってインシデント対応時間が短縮されるかどうかを測定する。 SLA 違反ペナルティ （顧客との契約や規制上の義務の一部として SLA が定義されている組織の場合）は、SLA 違反ペナルティの合計を顧客総数で割った値が、さまざまなセキュリティと回復力のメカニズムによって時間の経過とともに減少するかどうかを測定する。 ビジネスの俊敏性 リリースの頻度と、リリースごとの新しい更新/機能の平均数 は、特定の期間における新しいリリースの数と、リリースごとに導入された新機能の数を測定する。 リリースごとのコードレビューの回数と、コードレビューごとに費やされる平均時間 は、リリースごとの手作業によるコードレビューの削減と、コードレビュー会議ごとのスタッフの効率改善を測定する。 マイクロサービスアーキテクチャを使用するアプリケーションの数 は、相互依存性を排除するためにモノリシックアーキテクチャからマイクロサービスアーキテクチャに移行するアプリケーションの数を測定する。 生成AIを使用したイノベーション率 は、ビジネスチャンスや競争上の優位性につながる、生成AIによって生み出された新しいアイデア、コンセプト、ソリューションの数を追跡する。 サステナビリティ グリーンコンピューティングイニシアチブ は、オンプレミスのIT オペレーションの削減、再生可能エネルギーの使用とクラウドのインフラ効率の組み合わせ、およびマネージドサービスの使用によって節約できるカーボンフットプリントの削減を測定する。 廃棄物削減の指標 は、オンプレミスのインフラストラクチャの廃棄物のうち、リサイクルされたものの割合や、埋立による処分ではなく環境に優しい方法で処分されたものの割合を測定する。 ガバナンスと結論 KPI のガバナンスには、経営陣との連携、一貫したデータ収集プロセス、ネガティブな傾向が発生した場合の是正措置が求められます。トレンド分析と定期的な改善に注力することで、組織はクラウド導入のペースを正確に把握し、効率を最適化し、利害関係者に具体的なメリットを強調することができます。 クラウド移行のビジネス価値を測るために適切なKPI を選択するには、熟慮することが必要です。インフラのフットプリントを最適化し、クラウドでコスト削減を実現することは必須ですが、クラウド移行の進捗状況や、社内関係者や社外顧客への影響を追跡することも、競争力を高めることにつながります。業種を問わず、5 つの価値の柱を中心に共通のKPI があると考えられます。一方で、各組織独自の状況や優先事項を加味することによって、組織ごとの最適なKPI が導出されます。成功のためには、利害関係者と連携し、一貫したデータ収集を体系化することが不可欠です。 状況が変化するにつれて、既存のKPI を定期的に再評価し、改良する必要があります。トレンド分析は、単独のデータポイントで判断するよりも有意義な洞察をもたらします。最終的に、適切なKPI は、その組織のデジタルトランスフォーメーションが戦略的目標のために進んでいるかどうか、また長期にわたって差別化されたビジネス価値をもたらすかどうかを示します。 KPI は、デジタルトランスフォーメーションの健全性をユニークに測定し、成功の積み重ねを可能にします。 [ 1 ] Gartner® Press Release, Gartner Forecasts Worldwide Public Cloud End-User Spending to Reach $679 Billion in 2024, November 13, 2023, https://www.gartner.com/en/newsroom/press-releases/11-13-2023-gartner-forecasts-worldwide-public-cloud-end-user-spending-to-reach-679-billion-in-20240.GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved. 著者について Chris Hennesey hris Hennesey はAWS のエンタープライズファイナンスストラテジストです。エンタープライズファイナンスストラテジストとして、世界中の企業幹部と連携し、クラウドを活用することでスピードと俊敏性を向上させ、顧客により多くのリソースを割けるようにするための財務管理経験や戦略を共有している。AWS 入社以前は、Capital One で複数のシニア・テクノロジー・ファイナンスを担当。ファイナンスの理学士号と経営学の修士号を取得している。 Bhavin Desai Bhavin Desai はAWS のプライベート・エクイティ・チームのバリュークリエイションストラテジストです。プライベート・エクイティ企業やその投資先企業と協働し、プリスクリプティブアプローチを用いてクラウドの価値を理解、創造、測定することを支援している。AWS 入社以前は、クラウド・センター・オブ・エクセレンス（CCoE）の構築を主導し、ナスダックの長期クラウド戦略策定チームの中核を担った。過去15 年にわたり、さまざまなデジタルトランスフォーメーションや買収統合イニシアチブでチームを率いてきた。ペンシルベニア州立大学で電気工学の学士号を、リーハイ大学でMBA を取得。 この記事は、ソリューションアーキテクトの平岩梨果が翻訳を担当しました。原文は こちら です。

2017 年のローンチ以降、 VMware Cloud on AWS を利用することで Amazon Web Services (AWS) のお客様はネイティブの VMware 仮想マシン (VM) を AWS グローバルインフラストラクチャ上で稼働させることができるようになりました。 VMware Cloud on AWS をすでに運用している、または利用する予定がある場合、セキュリティ上の特別な考慮事項があるかどうかを気にされるかもしれません。この記事では、 AWS クラウド導入フレームワーク （AWS CAF） を VMware Cloud on AWS に適用する方法について説明し、セキュリティとコンプライアンスの要件を満たすために各目的をレビューし、関連する機能を適用するのに役立ちます。 VMware Cloud on AWS は、現在オンプレミスで使用されているのと同じ VMware ソフトウェアをクラウドで提供します。これにより、ワークロードを迅速に AWS にリフト＆シフトできますが、セキュリティ、コンプライアンス、およびガバナンスに対する新しい視点も提示されます。VMware Cloud on AWS を使用してリフト＆シフトを行うお客様には、このフレームワークを新たなインフラストラクチャに適用するための手助けが必要です。 AWS CAF は、その機能をビジネス、人、ガバナンス、プラットフォーム、セキュリティ、オペレーションの 6 つの視点でグループ化しています。それぞれは、クラウドジャーニーにおいて、機能的に関連するステークホルダーが所有または管理する一連の機能で構成されています。 CAF のセキュリティの観点では、AWS ワークロードのセキュリティ機能を構築し、ベストプラクティスを採用する際のガイドとして使用されます。以下に示すこれらの機能を使用して、クラウドセキュリティ、コンプライアンス、ガバナンスを評価し、クラウドワークロードの機密性、完全性、可用性の実現を支援することができます。 VMware Cloud on AWS では、VMware と AWS の両方のセキュリティとコンプライアンスのスコープを適用するため、より注意が必要となります。 図 1: AWS CAF のセキュリティの観点の機能 お客様の観点 AWS におけるデプロイメントに関して、 セキュリティのベストプラクティス やパターンについてのリソースは多数存在しますが、VMware Cloud on AWS では考慮すべき新たな側面があります。例えば、 Amazon GuardDuty や Amazon Inspector （エージェントレス） などのサービスとは統合されていません。 VMware Cloud on AWS は、VMware が管理する仮想プライベートクラウド （VPC） 上で VMware によって運用される マネージドサービス であるため、監視と構成管理にはクラウドとオンプレミスのハイブリッドアプローチを適用することになります。また、マネージド VPC の監視やベースとなるサービスコンポーネントのセキュリティ保護など、セキュリティとコンプライアンスの一部は VMware の責任範囲 となります。 AWS に移行する場合、VMware Cloud on AWS ではオンプレミスのデータセンターと同じ VMware のツールとプロセスを維持することができるため、速度の向上とリスクの軽減が可能になります。規制の厳しい業界では、セキュリティとコンプライアンスが極めて重要であり、新たな考慮が必要な基盤技術を追加導入することで移行時間が長くなる可能性があります。 VMware Cloud on AWS は、AWS のネイティブサービスと統合されています。セキュリティとコンプライアンスの環境には、Amazon Inspector、 AWS Config 、 Amazon EventBridge 、または AWS Security Hub に調査結果を集約できる多数のサービスが含まれる可能性があります。通常、セキュリティとガバナンスのためのソリューションはすでにオンプレミスにありますが、これらを AWS Security Hub と統合するか、2 つの異なるシステムを運用する必要があります。 CAF のセキュリティの観点の VMware Cloud on AWS への適用 AWS CAF の セキュリティの観点 は、9 つの機能で構成されています。ここでは、AWS ネイティブワークロード、VMware Cloud on AWS ワークロード、およびオンプレミスシステムのハイブリッド環境において、これらの機能をどのように適用するかを学びます。この総体的なアプローチにより、セキュリティ体制の信頼性を高めながら、移行とモダナイゼーションを迅速に行うことができます。 セキュリティガバナンス セキュリティガバナンスには、セキュリティを定義し周知する役割と責任が含まれます。ポリシー、プロセス、手順を作成し、説明責任の所在を明確にします。遵守すべき法律や規制を適用し、継続的に更新する必要があります。 以下の図 2 では、VMware、AWS、お客様の間で責任を共有しています。お客様は、Software-Defined Data Center （SDDC） 内のワークロードの構成、VMware ファイアウォールルール、およびその他の SDDC の構成に対して責任を負います。 緑色の部分を見ますと、SDDC だけでなくマネージド仮想プライベートクラウド （VPC） や関連する AWS リソースに対しても VMware が責任を負っていることが分かります。一方、AWS はグローバルインフラストラクチャと基盤サービスを担当しています。 図 2: VMware Cloud on AWS の責任共有モデル SDDC や VMware ファイアウォールなど、セキュリティやコンプライアンスを考慮する必要のある新しい構成が存在します。これらの構成の一部は VMware によって管理されていますが、お客様で変更することも可能です。 セキュリティ保証 セキュリティ保証については、クラウドベンダーのレポートやコンプライアンス証明書をレビューして実施されているコントロールを理解するだけでなく、継続的な改善を適用しながらセキュリティメカニズムを監視、評価、管理します。お客様は、どのコンプライアンスフレームワークを適用するかを決定し、VMware のコントロールをそれらの要件にマッピングする責任を負います。 VMware は、コンプライアンス文書を提供し、それぞれの管理を実施する責任があります。VMware のスコープに関する詳細については、 VMware Trust Center を参照してください。これは、AWS のセキュリティおよびコンプライアンス情報が掲載されている AWS Artifact と組み合わせて使用できます。 アイデンティティとアクセス管理 Identity and Access Management （IAM） を使用することで、アイデンティティ・プロバイダの集中管理と多要素認証 （MFA） を使用して最小特権アクセスを実装できます。 VMware は SDDC をプロビジョニングする前に、お客様の身元証明でもある有効な AWS アカウントを持っていることを顧客に要求します。 サービス説明 のページでは、VMware がどのようにクラウドサービスポータル （CSP） を保護し、MFA との統合をサポートしているかについての詳細情報を提供しています。 アイデンティティ・プロバイダ （既存のアイデンティティ・プロバイダとのフェデレーションを推奨） と同様に、SDDC 内の仮想マシンの認証を管理する責任はお客様にあります。VMware Cloud on AWS のアイデンティティとアクセス管理については 規範ガイダンス を参照してください。 脅威検出 この機能には、様々なデータソースと相関性のある脆弱性のスキャンと修復の発見が含まれ、修復とその結果の状況をステークホルダーに伝えます。ユーザアクティビティ、ネットワークアクティビティ、アプリケーションアクティビティのログの記録など、SDDC 内の仮想マシンの脅威検出はお客様の責任となります。 ユーザーアクティビティのログ記録には、CSP や API アクションを含む SDDC 内で実行された管理アクティビティを記録する Aria Operations for Logs を利用できます。ネットワークアクティビティのログ記録には、SDDC ネットワーク上のパケットキャプチャが含まれ、SDDC ではこのトラフィックを調査するために ポートミラーリング を有効化することができます。 さらに、IP Flow Information Export (IPFIX) ログは、ネットワークトラフィックを要約するためにコレクターに送ることができます。アプリケーションログは、 CloudWatch Logs Agent を使用して Amazon CloudWatch に転送することができ、セキュリティ情報イベント管理 （SIEM） やその他のログ収集ソリューションにログのコピーを送信することで ログを転送 することができます。 VMware は サービス概要 に記載されているとおり、サービスを提供しているシステムの脅威の検出、分類、エスカレーション、および修復に責任を負います。 脆弱性の管理 脆弱性管理機能には、SDDC 内の VM だけでなく、VMware Cloud on AWS サービスを提供するために使用されるシステムのスキャンとパッチ適用が含まれます。SDDC 内のワークロードのスキャンとパッチ適用はお客様責任となりますが、 AWS Systems Manager を利用することができます。 VMware は、 Service Lifecycle ガイドに記載されているように、SDDC と基盤となるサービスコンポーネントのスキャンとパッチを管理します。 インフラストラクチャの保護 この機能には、深層防御を活用してセキュリティのレイヤーを提供する一方で、システムをグループ化するためのネットワークゾーンを定義し、必要に応じてトラフィックの検査とフィルタリングを実装することが含まれます。SDDC ファイアウォールを設定してアクセス制御リスト （ACL） を作成し、トラフィックを許可するだけでなく、ルーティングを設定してトラフィックフローを確立します。 さらに、VPC ルートテーブル、セキュリティグループ、ネットワーク ACL （NACL） を管理し、SDDC から VPC に流れるトラフィックを制御します。よりセンシティブなシステムを保護する場合は、 ゼロトラスト アプローチを検討してください。 VMware は SDDC ファイアウォールとルーターのコンポーネントのパッチ適用を管理し、稼働時間を確保します。 アプリケーションのセキュリティ この機能では、ソフトウェア開発プロセス中に脆弱性を検出して対処することで、本番環境に投入されるコードのセキュリティを強化します。コードのスキャンとセキュリティ問題のパッチ適用を自動化することで、人手による作業を最小限に抑える必要があります。 VMware は、VMware Cloud on AWS サービスに関連するコードのセキュリティを確保する責任を負います。 インシデント対応 インシデント対応には、インシデントと問題の管理が含まれ、実行計画に従ってタイムリーに対応します。GameDay 演習を通してセキュリティイベントをシミュレートし、継続的に対応を改善することができます。また、インシデントの事後分析を実施して根本原因を特定し、発見から学ぶこともできます。 VMware は、VMware Cloud on AWS サービスに関するインシデントおよび問題管理 （検出、分類、記録、エスカレーション、サービス復帰） に責任を持ちます。 まとめ 企業は VMware Cloud on AWS を活用して、AWS へのクラウド移行を簡素化し、加速しています。この戦略は、自社データセンターとの運用上の一貫性を提供しますが、セキュリティとコンプライアンスの観点からは AWS 上で実行される VMware ワークロードならではの追加の知見が必要であることを理解することが重要です。 本稿では、AWS クラウド導入フレームワーク （CAF） のセキュリティの観点を VMware Cloud on AWS で評価し適用する方法を解説しました。また AWS の責任共有モデル を紹介し、VMware、AWS、お客様の間でどのように責任を分担するかについても説明しました。 参考文献 AWS Artifact AWS Identity and Access Management AWS Cloud Adoption Framework Security Perspective VMware Cloud on AWS Enterprise Federation VMware Cloud on AWS Service Description VMware Trust Center 翻訳は SA 太田が担当しました。原文は こちら です。

多数のアカウントと Amazon Virtual Private Cloud (Amazon VPC) リソースを管理している場合、多くの DNS リソースを共有して各 VPC に関連付けるのは大きな負担となることがあります。共有と関連付けに関する制限にしばしば悩まされ、アカウントと VPC 全体に DNS 設定を伝播するために独自のオーケストレーションレイヤーを構築するまでに至ったお客様もいらっしゃるかもしれません。 4月22日、 Amazon Route 53 プロファイルを発表します。これは、組織のすべてのアカウントと VPC における DNS の管理を統合する機能を提供します。Route 53 プロファイルを使用することで、Route 53 プライベートホストゾーン (PHZ) の関連付け、Resolver 転送ルール、Route 53 Resolver DNS ファイアウォールルールグループなどの標準 DNS 設定を定義し、その設定を同じ AWS リージョン内の複数の VPC に適用できます。プロファイルを使用すると、個別の Route 53 リソースを処理するという複雑さに煩わされることなく、簡単な操作で、すべての VPC が同じ DNS 設定を持つようにできます。多数の VPC にわたる DNS の管理が、単一の VPC のそれらの同じ設定を管理するのと同じ程度にシンプルになりました。 プロファイルは AWS Resource Access Manager (RAM) とネイティブに統合されるため、アカウント間で、または AWS Organizations アカウントと、プロファイルを共有できます。プロファイルは、アカウント間で共有される際に組織がこれらの同じ設定にアクセスできるようにするため、既存のプライベートホストゾーンを作成してプロファイルに追加することを可能にすることによって、Route 53 プライベートホストゾーンとシームレスに統合します。 AWS CloudFormation を利用すると、アカウントが新しくプロビジョニングされる際に、プロファイルを使用して VPC の DNS 設定を一貫して行うことができます。4月22日のリリースでは、マルチアカウント環境の DNS 設定をより適切に管理できるようになりました。 Route 53 プロファイルの仕組み Route 53 プロファイルの使用を開始するには、Route 53 の AWS マネジメントコンソール に移動します。ここでプロファイルを作成し、そのプロファイルにリソースを追加して、VPC に関連付けることができます。その後、AWS RAM を使用して、作成したプロファイルを別のアカウントと共有します。 Route 53 コンソールのナビゲーションペインで、 [プロファイル] を選択し、次に [プロファイルを作成] を選択してプロファイルを設定します。 プロファイルの設定に MyFirstRoute53Profile などのわかりやすい名前を付け、必要に応じてタグを追加します。 DNS ファイアウォールルールグループ、プライベートホストゾーン、Resolver ルールの設定の構成や、アカウント内に既に存在しているそれらの設定の追加は、すべてプロファイルコンソールページ内で実行できます。 [VPC] を選択して、VPC をプロファイルに関連付けます。タグを追加できるほか、再帰的 DNSSEC 検証や、VPC に関連付けられた DNS ファイアウォールの障害モードの設定を行うこともできます。また、DNS 評価の順序を制御することもできます。最初に VPC DNS、次にプロファイル DNS としたり、または最初にプロファイル DNS、次に VPC DNS としたりできます。 VPC ごとに 1 個のプロファイルを関連付けることができ、最大 5,000 個の VPC を 1 個のプロファイルに関連付けることができます。 プロファイルを使用すると、組織内のアカウント全体で VPC の設定を管理できます。VPC ごとに逆引き DNS ルールを設定するのではなく、プロファイルが関連付けられている VPC ごとに逆引き DNS ルールを無効にできます。Route 53 Resolver は、逆引き DNS ルックアップのルールを自動的に作成して、さまざまなサービスが IP アドレスからホスト名を簡単に解決できるようにします。 DNS ファイアウォール を使用する場合、ファイアウォール用に設定を通じて障害モードを選択して、フェールオープンまたはフェールクローズを選択できます。また、Route 53 (または他のプロバイダー) で DNSSEC 署名を使用せずに、プロファイルに関連付けられた VPC 用に再帰的 DNSSEC 検証を有効にするかどうかを指定することもできます。 プロファイルを VPC に関連付けるとします。VPC に直接関連付けられているリゾルバールールまたは PHZ と、VPC のプロファイルに関連付けられているリゾルバールールまたは PHZ の両方に、クエリが正確に一致するとどうなるでしょうか? プロファイルとローカル VPC のどちらの DNS 設定が優先されるのでしょうか? 例えば、VPC が example.com の PHZ に関連付けられており、プロファイルに example.com の PHZ が含まれている場合、その VPC のローカル DNS 設定がプロファイルよりも優先されます。競合するドメイン名についてクエリが実行された場合 (例えば、プロファイルに infra.example.com の PHZ が含まれており、VPC が account1.infra.example.com という名前の PHZ に関連付けられている場合)、最も具体的な名前が優先されます。 AWS RAM を利用してアカウント間で Route 53 プロファイルを共有する AWS Resource Access Manager (RAM) を利用して、前のセクションで作成したプロファイルを他のアカウントと共有します。 [プロファイルの詳細] ページで [プロファイルを共有] オプションを選択するか、または AWS RAM コンソールページに移動して [リソース共有を作成] を選択します。 リソース共有の名前を入力し、 [リソース] セクションで「Route 53 Profiles」を検索します。 [選択されたリソース] でプロファイルを選択します。タグを追加することもできます。その後、 [次へ] を選択します。 プロファイルは RAM マネージド許可を利用するため、各リソースタイプに異なる許可をアタッチできます。デフォルトでは、プロファイルの所有者 (ネットワーク管理者) のみがプロファイル内のリソースを変更できます。プロファイルの受信者 (VPC の所有者) は、プロファイルの内容のみを表示できます (ReadOnly モード)。プロファイルの受信者が PHZ または他のリソースをそのプロファイルに追加することを許可するには、プロファイルの所有者は、必要な許可をリソースにアタッチする必要があります。受信者は、プロファイルの所有者によって共有リソースに追加されたリソースを編集または削除できません。 デフォルトの選択をそのままにして、 [次へ] を選択し、他のアカウントにアクセスを付与します。 次のページで、 [すべてのユーザーとの共有を許可] を選択し、他のアカウントの ID を入力して、 [追加] を選択します。その後、 [選択されたプリンシパル] セクションでそのアカウント ID を選択し、 [次へ] を選択します。 [確認と作成] ページで、 [リソース共有を作成] を選択します。リソース共有が正常に作成されました。 次に、プロファイルを共有する別のアカウントに切り替えて、RAM コンソールに移動します。ナビゲーションメニューで、 [リソース共有] に移動し、最初のアカウントで作成したリソース名を選択します。 [リソース共有を承認] を選択して招待を受け入れます。 これで完了です。 ここで Route 53 プロファイルページに移動し、共有されているプロファイルを選択します。 共有されたプロファイルの DNS ファイアウォールルールグループ、プライベートホストゾーン、および Resolver ルールにアクセスできます。このアカウントの VPC をこのプロファイルに関連付けることができます。リソースを編集または削除することはできません。プロファイルはリージョンレベルのリソースであり、リージョン間で共有することはできません。 今すぐご利用いただけます Route 53 プロファイルは、 AWS マネジメントコンソール 、 Route 53 API 、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS CloudFormation 、および AWS SDK を使用して簡単に開始できます。 Route 53 プロファイルは、カナダ西部 (カルガリー)、AWS GovCloud (米国) リージョン、および Amazon Web Services の中国リージョンを除くすべての AWS リージョンで利用可能になる予定です。 料金の詳細については、 Route 53 の料金 ページにアクセスしてください。 今すぐ プロファイル の使用を開始して、通常の AWS サポートのお問い合わせ先や、Amazon Route 53 の AWS re:Post を通じてフィードバックをぜひお寄せください。 – Esra 原文は こちら です。

ガバメントクラウドの利用が進むにつれ、さまざまな検討をしているかと思います。 「ガバメントクラウド活用のヒント」シリーズでは、ガバメントクラウドでの業務システム構築を支援する中でよくご質問をいただく項目について深掘りして情報をまとめています。過去の記事はこちらになります。 ガバメントクラウド活用のヒント『共同利用方式におけるコスト・ セキュリティ管理について』 ガバメントクラウド活用のヒント『見積もりで注意すべきポイント』 ガバメントクラウド活用のヒント『ガバメントクラウド上で CIDR 重複を起こさないために！』(本ブログ) ガバメントクラウドの基本的な情報を知りたい方は ガバメントクラウドの道案内『自治体職員編』 をはじめとする「ガバメントクラウドの道案内」シリーズをご覧ください。 本ブログでは、ガバメントクラウド上での全体のネットワーク設計の肝である CIDR 設計に関して扱っていきます。ガバメントクラウド特有の制限ではなく、オンプレミスとAWS 環境をハイブリッドに構成するネットワーク設計では一般的な内容です。 ガバメントクラウドのネットワーク設計で生じうる課題 地方公共団体がガバメントクラウドで AWS を利用する場合、AWS 上で使用する IP アドレス範囲はお客様側で自由に決定が可能です。一方で、AWS とオンプレミス (庁舎など) は L3 レベルで接続されるため、AWS に割り当てる IP アドレスは オンプレミスで使用していない IP アドレス である必要があります。 そこで、ガバメントクラウドを利用するにあたってはオンプレミスで使用していない IP アドレス範囲を確認し、各利用領域に割り当てる必要があります。理由としては、IP アドレス範囲すなわち CIDR が重複してしまうと、通信に不具合が生じてしまうからです。また VPC の CIDR ブロックは 1 度作成すると変更することが困難 のため、CIDR 設計は、十分な検討が必要不可欠です。 どの事業者がネットワークの全体設計を考えるのか ガバメントクラウド上では誰がこの役割を担うべきなのかという点ですが、庁内ネットワークを管轄している事業者やネットワーク構築運用補助者が想定されます。ネットワーク構築運用補助者の詳細については、こちらの ブログ でご確認ください。 Amazon VPC の CIDR ブロック VPC を作成するときは、 RFC 1918 に指定されているように、プライベート IPv4 アドレス範囲からの CIDR ブロックを指定することをお勧めします。 VPC の CIDR ブロックは/16 から/28 の範囲で選択できます。 十分な数の IP アドレスを確保するため、/16から/20程度の CIDR ブロックを選択することが一般的です。 将来の拡張性を考慮した、大きな CIDR ブロックを選択することをお勧めします。 CIDR の重複を回避するには ネットワーク設計時に使用する CIDR を慎重に選定し、重複がないことを確認する CIDR の割り当てを一元的に管理し、重複を防止する ネットワーク変更時には、既存の CIDR との重複がないかを必ず確認する 万が一 CIDR 重複してしまった場合には、オンプレミス側で NAT 変換するという方法がありますが、ネットワーク設計が複雑となります。さらに高価な機器が必要になる場合もあり、デメリットがあります。また、 AWS PrivateLink を用いて接続する方法がありますが、アプリケーション側が AWS PrivateLink での接続に対応していない場合があります。そのため、重複を回避する十分な検討が必要不可欠です。 ネットワーク全体設計のポイント 以下の情報を整理して、全体の CIDR 設計を考える必要があります。そしてすべての IP アドレス範囲が重複しない形で全体ネットワークを考慮する必要があります。(共同利用方式のアプリケーション分離方式で提供される場合は除く) オンプレミス (庁舎など) で利用している IP アドレス 各 ASP 事業者の接続先のアプリケーション VPC の IP アドレス 単独利用方式、共同利用方式問わずすべての接続先 共通機能 VPC や運用管理 VPC を含む 東京リージョン、大阪リージョンを含む 他のクラウドサービスプロバイダで利用するシステムの IP アドレスを含む 将来の拡張性を踏まえたシステム用の VPC の IP アドレス ガバメントクラウド上のシステムの追加用の IP アドレス 各 ASP 事業者の接続先の VPC の IP アドレスに関してですが、オンプレミスと重複しない IP アドレス帯で ASP 事業者の VPC が構築されれば問題ありません。しかし、自由に ASP 事業者が各地方公共団体の環境を作成する場合は、CIDR 重複が起こる可能性が極めて高いと考えます。そういったことを防ぐために、全体の CIDR 設計をまず一番最初に行い、 オンプレミスや他 VPC と重複しない IP アドレスで単独利用方式及び共同利用方式の ASP 事業者に対して VPC を作成いただくような調整 が必要不可欠です。 全体設計の具体的なイメージ例 クラス B ( 172.16.0.0 – 172.31.255.255) の中からオンプレミスと AWS 上で利用する IP アドレスを考えた場合、どのようにネットワーク範囲を考えれば良いかのサンプル例を示します。(もちろん特定のクラスに絞る必要はございません。AWS 上で利用できる IP アドレス範囲は こちら です。) 一番最初に考えることとして、AWS 以外で利用する CIDR と AWS 上で利用する CIDR を適切に区切ることです。オンプレミスと重複しない AWS 上で利用するアドレス帯を決めます。これでオンプレミスと AWS 上の IP アドレスは重複しない設計になります。 オンプレミス: 172.20.0.0/14 172.20.0.0 – 172.23.255.255 AWS : 172.24.0.0/14, 172.28.0.0/15 172.24.0.0 – 172.27.255.255 172.28.0.0 – 172.29.255.255 その他クラウドサービスプロバイダ: 172.30.0.0/15 172.30.0.0 – 172.31.255.255 その上で、AWS 用に区切って用意しておいた CIDR から、ASP 事業者との調整の中で都度 IP アドレスを割り振るような形で全体設計を進めていきます。そうすることで ASP 事業者側も、指定された IP アドレス帯でシステムの構築ができます。ASP 事業者側で作成できる CIDR に制約がある場合もあると思いますので、複数の IP アドレス帯を用意しておくと良いと思います。 例えば、アプリケーションベンダー A に対して、172.25.0.0/16の IP アドレス範囲を利用して AWS 上にアプリケーションの構築を委託するイメージです。地方公共団体とアプリケーションベンダー A で合意の上、アプリケーションベンダー A は指定された IP アドレス範囲でシステム構築を行います。 オンプレミス: 172.20.0.0/16 ネットワークアカウント: 172.24.0.0/16 アプリケーションベンダーA: 172.25.0.0/16 アプリケーションベンダーB: 172.26.0.0/16 アプリケーションベンダーC: 172.27.0.0/16 また、IP アドレスの一元管理ですが、既存の管理方法があればその方法をご利用頂ければと思います。AWS のサービスとしては、 Amazon VPC IP Address Manager (IPAM) があります。AWS ワークロードの IP アドレスを計画、追跡、監視する機能があります。IPAM を使用して、IP アドレスを効率的に管理できます。AWS の Amazon VPC IP Address Manager (IPAM) の知識を深めたい方は [AWS Black Belt Online Seminar] Amazon VPC IP Address Manager (IPAM) をご覧ください。 まとめ 本ブログでは、ガバメントクラウド上での全体のネットワーク設計の肝である CIDR 設計で検討すべきポイントをご紹介しました。重要なポイントとしては、以下の 3 点です。 現在使用している IP アドレスを把握しておくこと。 AWS に割り当てる IP アドレス範囲を決定すること。 ASP 事業者と調整を行い、適切なネットワーク設計を行うこと 地方公共団体に所属している方、または関連するベンダーパートナーの方でこのブログに関して追記した方がいいことやご不明点などございましたらお気軽に担当のソリューションアーキテクトまたは末尾のお問い合わせ窓口へお気軽にご連絡ください。 免責事項 本ブログや添付資料の内容はできる限り正確な情報を提供するように努めておりますが、正確性や安全性を保証するものではありません。 本ブログや添付資料はあくまで一例であり、すべての作業内容を充足するものではありません。 本ブログや添付資料はガバメントクラウドの新しい情報や AWS サービスの変更・追加などにより今後修正される場合があります。 本ブログや添付資料の利用によって生じた損害等の責任は利用者が負うものとし、アマゾン ウェブ サービス ジャパン は一切の責任を負いかねますことご了承ください。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けています。 本記事で紹介したタスクリストに関するお問い合わせのほか、ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/

AWS Summit は、世界中のさまざまな場所でイベントが開催されるなど、世界を揺るがし続けています。AWS Summit London（4月24日）は4月最後の開催で、5月には AWS Summit Berlin （5月15-16日）、 AWS Summit Los Angeles （5月22日）、 AWS Summit Dubai （5月29日）など9つの開催が予定されています。つながり、コラボレーション、そして AWS について学ぶために参加してください！ どのサミットに参加するかを決めるにあたり、4月15日週の新しい発表を見てみましょう。 4月15日週のリリース 4月15日週は、人工知能 (AI) の世界でもまた忙しい週でした。私が注目したリリースを以下に記載しました。 Anthropic’s Claude 3 Opus が Amazon Bedrock で入手可能になりました – Claude 3 Sonnet と Claude 3 Haiku の後、Anthropic’s Claude 3 の3つの最新モデルのうちの2つ、Opus が Amazon Bedrock で入手可能になりました。Cluade 3 Opus は生成 AI の最前線に立ち、人間に近いレベルの複雑なタスクに対する理解と流暢さを示しています。他の Claude 3 ファミリーと同様に、Opus は画像を処理してテキスト出力を返すことができます。Claude 3 Opus では、難しいオープンエンドの質問に関して、Claude 2.1 に比べて推定 2 倍の精度の向上を実現しています。これにより、誤った応答の可能性が低減されます。 Meta Llama 3 が Amazon SageMaker JumpStart で利用できるようになりました — Meta Llama 3 は、ML ジャーニーを加速するのに役立つ機械学習 (ML) ハブである Amazon SageMaker JumpStart で利用できるようになりました。Llama 3 基盤モデル (FM) は、 Amazon SageMaker Studio でいくつかの手順を実行するか、 Amazon SageMaker Python SDK を使用してプログラムでデプロイして使用できます。Llama には、8B と 70B の 2 つのパラメーターサイズがあり、推論、コード生成、命令フォローが改善され、幅広いユースケースをサポートできます。モデルはお客様の VPC 管理下にある AWS の安全な環境にデプロイされ、データセキュリティの確保に役立ちます。 Amazon SageMaker Studio ノートブックに組み込まれた SQL 拡張機能 — SageMaker Studio の JupyterLab には、SQL と Python を使用してノートブック内で直接、さまざまなソースからのデータを検出、検索、変換するための組み込み SQL 拡張機能が組み込まれました。一般的なデータサービスにシームレスに接続し、データベース、スキーマ、テーブル、ビューを簡単に参照および検索できるようになりました。ノートブックインターフェイスでデータをプレビューすることもできます。SQL コマンド補完、コードフォーマット支援、構文強調などの新機能により、開発者の生産性が向上します。詳細については、「 データを簡単に探索：Amazon SageMaker Studio Jupyter Notebook で SQL と Text-to-SQL を使用 」と「 SageMaker Developer Guide 」を参照してください。 AWS Split Cost Allocation Data for Amazon EKS – AWS Cost and Usage Reports (CUR) で Amazon Elastic Kubernetes Service (Amazon EKS) の詳細なコストを可視化し、Kubernetes アプリケーションのコストと使用量を分析、最適化、チャージバックできるようになりました。Kubernetes アプリケーションが共有されている Amazon EC2 CPU およびメモリリソースをどのように消費するかに基づいて、アプリケーションコストを個々のビジネスユニットやチームに割り当てることができます。これらのコストをクラスター、名前空間、その他の Kubernetes プリミティブごとに集計して、個々のビジネスユニットまたはチームにコストを割り当てることができます。これらの費用の詳細は、オプトインしてから24時間後にCURに表示されます。 Containers Cost Allocation ダッシュボード を使用して Amazon QuickSight でコストを可視化し、 CUR クエリライブラリ を使用してAmazon Athenaでコストをクエリできます。 AWS KMS の自動キーローテーションの強化 – AWS Key Management Service (AWS KMS) は、自動対称キーローテーションのためのより高速なオプションを導入します。90 日から 7 年の間でローテーション頻度をカスタマイズしたり、顧客が管理する AWS KMS キーのキーローテーションをオンデマンドで呼び出したり、ローテーションされた任意の AWS KMS キーのローテーション履歴を表示したりできるようになりました。 セキュリティブログには、暗号化に関するちょっとした歴史など、この機能の詳細を知ることができる素晴らしい投稿 があります。 Amazon Personalize の自動ソリューショントレーニング – Amazon Personalize では、ソリューションの自動トレーニングが提供されるようになりました。自動トレーニングでは、データセットグループの最新データを使用して自動的に再トレーニングするように Amazon Personalize ソリューションのスケジュールを設定できます。このプロセスにより、新しくトレーニングされた機械学習 (ML) モデル (ソリューションバージョンとも呼ばれます) が作成され、エンドユーザー向けの Amazon Personalize の推奨事項の関連性が維持されます。自動トレーニングによりモデルのドリフトが軽減され、ユーザーの行動や好みの変化に合わせて推奨事項が確実に反映されます。Amazon Personalizeを使用すると、Amazonが使用しているのと同じ機械学習技術を使用して、ウェブサイト、アプリ、広告、電子メールなどをパーソナライズすることができます。Amazon Personalize の利用を開始するには、 弊社のドキュメント をご覧ください。 AWS のお知らせの詳細なリストについては、「AWS の最新情報」ページをご覧ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました。 Amazon RDS for Oracle は、x2iedn のサポートをアジアパシフィック (ハイデラバード、ジャカルタ、大阪)、ヨーロッパ (ミラノとパリ)、米国西部 (北カリフォルニア)、AWS GovCloud (米国東部)、および AWS GovCloud (米国西部) で拡張しています 。X2IEDN インスタンスは、高い計算能力（最大 128 vCPU）、大容量メモリ（最大 4 TB）、およびストレージスループット要件（最大 256,000 IOPS）を備え、メモリと vCPU の比率が 32:1 のエンタープライズクラスの高性能データベースを対象としています。 Amazon MSK がカナダ西部 (カルガリー) リージョンで利用できるようになりました 。 Amazon Managed Streaming for Apache Kafka (Amazon MSK) は、Apache Kafka と Kafka Connect 向けのフルマネージド型サービスです。これにより、Apache Kafka をデータストアとして使用するアプリケーションの構築と実行が容易になります。 Amazon Cognito が欧州 (スペイン) リージョンで利用できるようになりました 。 Amazon Cognito を使用すると、Apple、Facebook、Google、Amazon などのソーシャル ID プロバイダーや、SAML 2.0 や OpenID Connect などの標準によるエンタープライズ ID プロバイダーへのサインインをサポートするウェブアプリやモバイルアプリに、認証、承認、ユーザー管理を簡単に追加できます。 AWS Network Manager がAWS イスラエル (テルアビブ) リージョンで利用できるようになりました 。AWS Network Manager は、プライベートネットワークのグローバルビューを 1 つにまとめることで、AWS とオンプレミスのロケーションにわたるグローバルネットワークの管理に伴う運用上の複雑さを軽減します。 AWS Storage Gateway が AWS カナダ西部 (カルガリー) リージョンで利用できるようになりました 。 AWS Storage Gateway は、オンプレミスのアプリケーションにクラウド上の事実上無制限のストレージへのアクセスを提供するハイブリッドクラウドストレージサービスです。 Amazon SQS は、AWS GovCloud (米国) リージョンでの FIFO デッドレターキューリドライブのサポートを発表しました 。デッドレターキューのリドライブは、 Amazon Simple Queue Service (Amazon SQS) のお客様のデッドレターキュー管理エクスペリエンスを向上させるための拡張機能です。 Amazon EC2 R6gd インスタンス が欧州 (チューリッヒ) リージョンで利用可能になりました 。R6gd インスタンスは AWS Graviton2 プロセッサを搭載し、AWS Nitro System 上に構築されています。これらのインスタンスは、最大 25 Gbps のネットワーク帯域幅を、 Amazon Elastic Block Store (Amazon EBS) に最大 19 Gbps の帯域幅、最大 512 GiB の RAM、最大 3.8 TB の NVMe SSD ローカルインスタンスストレージを提供します。 Amazon Simple Email Service が AWS GovCloud (米国東部) リージョンで利用できるようになりました 。 Amazon Simple Email Service (SES) は、スケーラブルで費用対効果の高い、柔軟なクラウドベースの E メールサービスで、マーケティング、通知、トランザクションに関する E メールを任意のアプリケーション内から送信できます。詳細については、 Amazon SES ページにアクセスしてください。 AWS Glue Studio Notebooks は現在、中東 (UAE)、アジアパシフィック (ハイデラバード)、アジアパシフィック (メルボルン)、イスラエル (テルアビブ)、欧州 (スペイン)、欧州 (チューリッヒ) の各リージョンでご利用いただけます 。AWS Glue Studio Notebooks では、AWS Glue でインタラクティブなジョブオーサリングが可能なため、データ統合ジョブの開発プロセスを簡素化できます。詳細については、 AWS Glue Studio ノートブックでのコードのオーサリング をご覧ください。 Amazon S3 Access Grants は現在、中東 (UAE)、アジアパシフィック (メルボルン)、アジアパシフィック (ハイデラバード)、欧州 (スペイン) の各リージョンでご利用いただけます 。 Amazon Simple Storage Service (Amazon S3) のアクセス権限付与は、Microsoft Entra ID や AWS Identity and Access Management (IAM) プリンシパルなどのディレクトリ内の ID を S3 内のデータセットにマップします。これにより、企業のアイデンティティに基づいてエンドユーザーにS3アクセスを自動的に付与することで、データ権限を大規模に管理できます。詳細については、 Amazon S3 アクセス権限 のページをご覧ください。 その他の AWS ニュース 興味深いと思われるその他のニュースをいくつかご紹介いたします。 PartyRock Generative AI Hackathon&nbsp;の受賞者 – PartyRock Generative AI Hackathon は、7,650 人以上の登録者が 4 つのチャレンジカテゴリーにわたって 1,200 のプロジェクトを提出し、 Parable Rhythm – The Interactive Crime Thriller 、 Faith – Manga Creation Tools 、 Arghhhh! のような上位入賞者を擁し、幕を閉じた Zombie 。参加者は驚異的な創造性と技術力を発揮し、賞金総額は 60,000 USD の AWS クレジットを獲得しました。 娘のAryaが作り上げたストーリーやアイデアを使って、Faith — Manga Creation Toolsアプリを試してみましたが、その結果は非常に印象的でした。 アプリを自分で試す方法の詳細については、 Jeff Barr の投稿 をご覧ください。 AWS オープンソースのニュースと更新 &nbsp;– 同僚の Ricardo は、AWS コミュニティのオープンソースプロジェクト、ツール、イベントについて書いています。 Ricardo のページ で最新情報をチェックしてください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summits – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。お近くの都市、 シンガポール (5月7日)、 ソウル (5月16日～17日)、 香港 (5月22日)、 ミラノ (5月23日)、 ストックホルム (6月4日)、 マドリード (6月5日) で登録してください。 AWS re:Inforce – 6 月 10～12 日に米国ペンシルバニア州で開催される、ビジネスイニシアティブの推進を支援するように設計された 2 日半の没入型クラウドセキュリティ学習のための AWS re:Inforce で、生成 AI 時代のクラウドセキュリティに関する知識を深めましょう。 AWS Community Days &nbsp;– トルコ (5 月 18 日 )、 中西部 | コロンバス (6 月 13 日)、 スリランカ (6 月 27 日)、 カメルーン (7 月 13 日)、 ナイジェリア (8 月 24 日)、 ニューヨーク (8 月 28 日) のエキスパートによる、専門的な AWS ユーザーや業界リーダーによるコミュニティ主導のカンファレンスに参加しましょう。 こちらでは、近日開催される AWS 主導の対面および仮想イベント と デベロッパーに焦点を合わせたイベント のすべてを閲覧できます。 4月22日週のニュースは以上です。4月29日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup &nbsp;シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

画像生成 AI は、テキストからリアルな画像を生成できる革新的な AI モデルです。Diffusion モデルによる技術的なブレイクスルーにより注目を集め、派生技術や関連技術の研究開発が活発化し、日進月歩で新たな技術が生まれています。画像生成 AI を利用するには、現状いくつかの方法があります。 Adobe や Canva のようなアプリケーションに組み込まれている生成 AI 機能で利用する方法もあれば、 Amazon Bedrocks の Amazon Titan Image Generator や、 Stable Diffusion のように、API を経由してモデルをシステムに組み込んで利用する方法もあります。さらに OSS モデルや OSS アプリケーションをローカルやクラウドにデプロイして利用することもできます。 OSS アプリケーション/モデルには、利用できる派生モデルの種類が豊富で、カスタマイズ性が高く、OSS コミュニティが開発した新機能を素早く活用できるというメリットがあります。しかし、OSS モデルの推論やファインチューニングには、GPU などの計算リソースが必要となります。ローカルやオンプレミスのハードウェアリソースには限界があるため、小規模な PoC を超えて制作スタジオ等で複数人で大規模に利用する場合はクラウドのスケーラブルなコンピューティングリソースを活用することで、OSS モデルのワークロードをより効率的に実行できます。 AWS では、 Extension for Stable Diffusion on AWS というソリューションを提供しています。このソリューションは OSS の Stable Diffusion Web UI の拡張機能で、モデルのファインチューニングと推論をクラウド上のリソースにオフロードすることで、複数ユーザーによる大規模な利用を可能にします。この拡張機能を使用すると、お客様は UI 上から Amazon SageMaker による Stable Diffusion のモデルトレーニング、ファインチューニング、推論を簡単に実行できます。SageMaker のマネージドな分散学習と高性能の GPU インスタンスを活用することで、必要な時だけ高パフォーマンスのリソースを利用できます。また、 CloudFormation テンプレートを使ってリソースをプロビジョニングすることで、手動設定に伴う複雑さやミスを回避できます。 本記事では、Extension for Stable Diffusion on AWS の概要、アーキテクチャ、主要機能、導入手順について詳しく解説します。 使い方 ソリューションのデプロイ 本ソリューションは「バックエンドの API を提供するミドルウェア」部分と「フロントエンドとなる Extension for Stable Diffusion on AWS 拡張機能をインストールした Stable Diffusion Web UI 」の二つのコンポーネントに分かれています。それぞれ CloudFormation でデプロイし拡張機能の画面からバックエンド API の URL を登録することで設定することができます。詳細なデプロイ手順は ドキュメント および レポジトリ をご確認ください。 ユーザーの管理 Stable Diffusion Web UI はシングルユーザー向けのアプリケーションですが、拡張機能を利用することで複数のユーザーを管理することが可能です。ロールでの権限管理が可能で、学習・チェックポイントのアップロード・推論・エンドポイントの立ち上げ・ユーザーの変更・ロールの変更などのアクションごとに権限を設定することが可能です。 モデルとエンドポイントの管理 画像生成モデルは多くのモデルが出ており、またモデルをカスタマイズできる LoRA などのモデルも多数存在します。拡張機能を利用することで、Web UI の組み込みのモデル、ローカルのチェックポイント、URL から複数のモデルをアップロードし利用することが可能です。アップロードされたモデルは S3 に配置され、必要に応じてバックエンドの SageMaker に読み込まれいつでも呼び出しが可能です。 バックエンドの SageMaker のエンドポイントも拡張機能で管理することが可能です。リアルタイムエンドポイントと非同期エンドポイントに対応しており、オートスケーリングを設定することができます。非同期エンドポイントの場合は、使わない時は自動で 0 にスケールダウンしコストを抑えて利用することが可能です。 モデルの推論 モデルの呼び出しを行ってみましょう。txt2img ページの下部に拡張機能で追加された Amazon SageMaker Inference セクションがあります。モデルを指定してリクエストを送ることでバックエンドで指定したモデルで推論が実行され生成された結果が表示されます。 また、生成されたモデルは S3 に保存されており後から見返すことが可能です。 ControlNet も利用することが可能です。以下の例では国土交通省が公開している都市 3D データ PLATEAU （CC-BY-4.0） を使用し街並みを生成しています。 Stable Diffusion Turbo や Stable Diffusion LCM などの高速化技術も利用可能です。 モデルの学習 また、データセットを登録し LoRA でファインチューニングすることが可能です。まずは、Dataset Management ページでローカルから画像をアップロードしデータセットを作成します。以下の例では AWS のプロダクションチームが作成した CG アニメーション の背景を学習させています。 Train Management ページでモデルと作成されたデータセットを指定しモデルのファインチューニングジョブを作成することができます。学習は裏側では SageMaker Training ジョブで OSS ライブラリの kohya-ss/sd-scripts を使用しています。パラメータなども指定することが可能です。 学習結果および途中のチェックポイントは S3 に自動でアップロードされ、推論で利用することができます。Amazon SageMaker Inference セクションの LoRA のドロップダウンで選択すると反映されます。以下の例では、学習させた CG アニメーション風のスタイルで生成されていることが確認できます。 まとめ この記事では AWS が開発している Stable Diffusion Web UI の拡張機能 Extension for Stable Diffusion on AWS について紹介しました。このソリューションにより、複数ユーザーによる大規模な利用が可能になり、必要な時だけ高パフォーマンスのリソースを活用してモデルの学習、推論で利用することが可能です。ロールベースのアクセス権限管理、複数モデルの管理、リアルタイムおよび非同期の推論エンドポイント作成、ControlNet や LCM 等の高度な生成オプション、データセットの登録とLoRAによる転移学習などクリエイター向けに必要な機能と複数ユーザーで利用するための機能を備えており、これからも継続的な開発により新たな機能が追加されていく予定です。 ぜひ実際に Extension for Stable Diffusion on AWS をデプロイし、様々な機能を試してみてください。まずは小規模な環境で評価し、本番環境での運用を検討するとよいでしょう。このブログで紹介した Extension for Stable Diffusion on AWS の レポジトリ と ドキュメント なども参考にしてください。 著者プロフィール 前川 泰毅 (Taiki Maekawa) は AWS Japan のソリューションアーキテクトでメディア領域のお客様中心にアーキテクチャ設計や構築を支援しています。機械学習領域を得意としておりソリューションやサンプルコードの作成を行っています。

企業は、よくある質問 (FAQ) やナレッジ記事などのセルフサービス機能をウェブサイトやモバイルアプリに公開し、顧客の疑問の解決を支援しています。 このとき、解決しなかった疑問について顧客がエージェントに問い合わせると、ウェブサイトやアプリで入力または閲覧した内容を、再度尋ねられることがよくあります。 このため、企業はサードパーティのウェブ通話、画面共有、またはビデオ通話アプリケーションを導入し、顧客がウェブサイトやモバイル機器から電話をかけられるようにしています。 その結果、エージェントは従来の電話とウェブベースの通話をサポートするために、さまざまなアプリケーション間を行き来しなければなりません。さらに企業は、平均処理時間などの基本的なカスタマーサービス指標を把握するために、さまざまなデータソースを集計する必要があります。 Amazon Connect では、ウェブサイトやモバイルアプリケーションからパーソナライズされた音声およびビデオエクスペリエンスを提供できる アプリ内通話、ウェブ通話、ビデオ通話 の機能が提供されました。 この機能は、 マネージド通信ウィジェット または ソフトウェア開発キット (SDK) を使って簡単に実装できます。 顧客は、ウェブサイトやモバイルアプリを切り替えることなく、エージェントと通話を開始できます。 また、 コンテキスト情報 をエージェントのソフトフォンに渡すこともできます。 これを利用し、顧客の情報、認証ステータス、アプリ内の過去のアクションなどの属性に基づいて、顧客体験をカスタマイズできます。この結果、エージェントの処理時間の短縮と顧客満足度の向上が期待できます。 このブログ記事では、お客様がウェブページからウェブ通話とビデオ通話を開始する場合のサンプルユースケースを順に説明します。また、Amazon Connect の アプリ内通話、ウェブ通話、ビデオ通話 を使用して、顧客情報をエージェントに転送する方法を示します。 ソリューションの概要 図 1 . フォームを備えたウェブサイトとAmazon Connect のアプリ内通話、ウェブ通話、ビデオ通話を統合したソリューションのアーキテクチャ このソリューションでは、サンプルウェブサイトを Amazon CloudFront でホストし、静的なウェブサイトのコンテンツを Amazon S3 に格納します。 顧客がウェブサイトのフォームを送信すると、属性が Amazon API Gateway 経由で AWS Lambda に送信されます。 その後、 AWS Lambda は新しいリクエストに対して JSON Web トークン (JWT) を発行し、認証資格情報を AWS Systems Manager パラメータから取得します。 コミュニケーションウィジェットの JavaScript がウェブサイトに読み込まれ、Amazon Connect へ通話を開始します。 これにより、顧客とエージェントが音声とビデオでシームレスにつながります。 前提条件 このハンズオンチュートリアルでは、読者が次のリソースについて理解し、アクセスできることを前提としています。 Amazon Connect、Amazon API Gateway、AWS Lambda、AWS CloudFormation、Amazon CloudFront に管理者権限のある AWS アカウントを利用できること Amazon Connect インスタンス が構築済みであること ローカル環境に AWS CLI がインストールされ設定済みであること AWS Cloud Development Kit (CDK) 環境がインストール済みであること。インストールされていない場合は Step 1の構築手順を実行してください。また、AWS Cloud9 を利用することもできます。 ウォークスルー Step 1: 準備 AWS CDK をインストール (すでにインストール済みの場合はスキップ) し、CDK 環境を構築してください。 npm -g install typescript npm -g install aws-cdk cdk bootstrap aws://ACCOUNT_ID/AWS_REGION Git を利用して、GitHub からリポジトリをクローンしてください。 git clone https://github.com/aws-samples/web-voice-video-calling-blog CDK プロジェクトと AWS Lambda 関数の依存関係をインストールします。 cd web-voice-video-calling-blog mkdir -p lambda-layers/jwt-layer/nodejs npm install jsonwebtoken --prefix lambda-layers/jwt-layer/nodejs npm install AWS CLI プロファイルを使って CDK プロジェクトをデプロイします。 これにより、プロジェクトに必要な Amazon CloudFront、Amazon API Gateway、AWS Lambda、AWS Systems Manager のリソースがデプロイされます。 cdk deploy Do you wish to deploy these changes (y/n)? には y を入力します。 (このプロジェクトでは cdk バージョン 2.127.0 を使用しています。アップグレードが必要な場合は、 npm install -g aws-cdk —force を実行してください) CDK のデプロイが完了したら、このスタックの `出力` タブを開き、Amazon API Gateway エンドポイントと Amazon CloudFront ウェブサイトの URL の値を書き留めてください。 AcWebCallingStack.Endpoint8024A810 = https://aaaaaaaa.execute-api..amazonaws.com/prod/ (あなたの Amazon API Gateway) AcWebCallingStack.websiteURL = https://aaaaaa.cloudfront.net (あなたの Amazon CloudFront ウェブサイトの URL) Step 2: コミュニケーションウィジェットの設定 Amazon Connect インスタンス を開き、チャネル &gt; コミュニケーションウィジェット に移動します。 ウィジェットを追加をクリックします。 名前に「ac_widget_webcalling」と入力し、説明フィールドに「Widget for web and video calling」と入力してください。 コミュニケーションのオプションの 「チャットを追加」のチェックを外します。 図 2 . Amazon Connect コミュニケーションウィジェット作成画面 ウェブ通話コンタクトフロー で、「 Sample inbound flow (first contact experience) 」を選択します。 保存して続行 をクリックします。 次の画面のオプションはすべてデフォルトのまま下までスクロールして、 保存して続行 をクリックしてください。 コミュニケーションウィジェットに必要なドメインを追加する において、Step 1.5 でメモしておいた Amazon CloudFront ウェブサイトの URL のドメインを記入します。 新しいコミュニケーションウィジェットのリクエストにセキュリティを追加するは「 はい 」を選択してから、 保存して続行 をクリックしてください。 &nbsp;次の画面のウィジェットのスクリプトで スクリプトをコピー をクリックして、テキストエディタにコピーしてください。 コピーされたスクリプトから widgetId を控えておいてください。この widgetId は後のStep 4.5 で使用します。widgetId を見つけるには、 コミュニケーションウィジェットスクリプトの例 （リンク先のアンダーライン部分）を参照してください。 キーをコピー をクリックし、テキストエディタに保存します。これは後のStep 4.3 で使用します。 Step 3: index.html の API エンドポイントとウィジェットスクリプトの値を編集 Step 1.2 でクローンしたフォルダ内の「website」フォルダにある index.html ファイルを編集します。 127 行目の apiEndpoint を自分の環境の Amazon API Gateway Endpoint の値で更新します (Step 1.5 を参照) 図 3 . index.html の更新 index.html の 115 行と 123 行の間に、手順 2.10 (コミュニケーションウィジェット設定) でコピーした スクリプト を追加し、ファイルを保存します。 重要 :コピーしたスクリプトから 最初の行の&lt;/script&gt;および最後の行の&lt;script&gt;を削除してください。 AWS CLI から、CDK プロジェクトを再デプロイしてください。これにより、リソースの変更が反映されます。 cdk .. cdk deploy Step 4: AWS Systems Manager のセキュリティキーと Widget ID の更新 AWS マネジメントコンソール にログインし、 AWS Systems Manager に移動して、メニューから アプリケーション管理 の下にある パラメータストア をクリックしてください。 一覧から /Blog/AcWebCalling/AmazonConnect/ConnectSecret をクリックし、 編集 をクリックしてください。 値 フィールドに、Step 2.12 (コミュニケーションウィジェットの設定) で保存したセキュリティキーを入力し、 変更を保存 をクリックします。 図 4 . パラメータストア内のセキュリティキーの更新 /Blog/AcWebCalling/AmazonConnect/WidgetId をクリックし、 編集 をクリックしてください。 値 フィールドに、Step 2.11 で保存した widgetId を入力し、 変更を保存 をクリックしてください。 Step 5: Amazon Connect ステップバイステップガイドの設定 Amazon Connect ステップバイステップガイド を使用すると、ウェブサイトから渡された属性をエージェントワークスペースで確認できます。今回は、以下に記載する 2 種類のフローをインポートして設定します。 5.1 ステップバイステップガイドのビューフローの作成: ac_webcalling_SBSguide_view フロー をダウンロードします。リンク先の git ページから raw ファイルをダウンロードしてください。 Amazon Connect インスタンス を開き、 ルーティング &gt; フロー を選択し、 フローを作成 を選択してください。 右上のドロップダウンの矢印を押して インポート (ベータ) を選択し、Step 5.1.1 でダウンロードしたフローをインポートします。 公開 をクリックします。 5.2 着信コールフローの作成 ac_webcalling_SBSguide_handler フロー をダウンロードしてください。リンク先の git ページから raw ファイルをダウンロードしてください。 Amazon Connect インスタンス を開き、 ルーティング &gt; フロー を選択し、 フローを作成 を選択してください。 右上のドロップダウンの矢印を押して インポート (ベータ) を選択し、Step 5.2.1 でダウンロードしたフローをインポートします。 公開 をクリックします。 5.3 着信コールフローとステップバイステップフローの更新 Step 5.1 で作成した ac_webcalling_SBSguide_view フローを開きます。 フローエディタの左下にある 追加のフロー情報を表示 をクリックして展開します。 作成した ac_webcalling_SBSguide_view フローの フロー ID をコピーします。 Step 5.2 で作成した ac_webcalling_SBSguide_handler フローを開きます。 コンタクト属性の設定 ブロックを開きます。 図 5 . 着信コールフローの更新 Step 5.3.3 でコピーしたフロー ID を DefaultFlowForAgentUI の値に設定します。この属性は、通話がエージェントにルーティングされたときに、エージェントに表示されるステップバイステップのガイドを指定します。注: 「ENTER ac_webcalling_SBSguide_view FLOW ID HERE」を ac_webcalling_SBSguide_view のフロー ID に置き換えてください。 コンタクト属性の設定ブロックを 保存 して閉じます。 作業キューの設定 ブロックを開きます。 このブロックでは、ソリューションのテスト中に使用するキューを設定します。既存のコンタクトセンターの運用に影響を与えないキューを選択することをお勧めします。 作業キューの設定 ブロックを保存して閉じ、 公開 をクリックして更新したフローを発行します。 Step 6: コミュニケーションウィジェットの更新 Amazon Connect インスタンス を開き、 チャネル &gt; コミュニケーションウィジェット を選択します。 ac_widget_webcalling をクリックし、詳細セクションで 編集 をクリックしてください。 ウェブ通話コンタクトフローで、フローを ac_webcalling_SBSguide_handler に変更し、 保存して続行 をクリックしてください。 図 6 . Amazon Connect のコミュニケーションウィジェットの更新 保存して続行 をクリックします。 保存して続行 をクリックします。 Step 7: Amazon Connect セキュリティプロファイルの更新 エージェントがビデオ通話とステップバイステップのガイドを利用できるようにするには、セキュリティプロファイルにコンタクトコントロールパネル (CCP) とエージェントワークスペースの権限を追加する必要があります。権限の追加には次の手順を実行します。 Amazon Connect インスタンス を開き、 ユーザー &gt; セキュリティプロファイル を選択します ステップバイステップガイドの作成とアクセスを許可するセキュリティプロファイルをクリックします。 数字とフロー をクリックして展開します。 ビュー の横にある「 すべて 」のチェックボックスをクリックします。 エージェントアプリケーション をクリックして展開します。 カスタムビュー の横にある「 すべて 」のチェックボックスをクリックします。 コンタクトコントロールパネル (CCP) をクリックします。 ビデオ通話 の横にある「 アクセス 」のチェックボックスをクリックします。 図 8 . セキュリティプロファイルのコンタクトコントロールパネル設定 右上の 保存 をクリックします。 テスト 上記のステップで設定したセキュリティプロファイルを使用したエージェントとして Amazon Connect エージェントワークスペース にログインします。 ブラウザで Amazon CloudFront の URL (Step 1.5 参照) を開き、Contact Us フォームに任意の情報を入力・選択します。 Submit をクリックしてください。 図 9 . Amazon Connect in-app, web, and video callingの通話開始デモ画面 画面右下の電話アイコンをクリックするとエージェントとの通話が開始します。ビデオ通話を開始するには、 Start Video アイコンをクリックしてください。 通話がエージェントワークスペースに着信したら、通話を受信 をクリックします。エージェント側でもビデオを有効にします。ウェブサイトで入力・選択した値がエージェントワークスペースにビデオや音声通話とともに表示されます。 図 10 . Amazon Connect in-app, web, and video callingのエージェント側画面 ウェブサイト上では、顧客はエージェントとビデオや音声で対話ができます。 図 11 . Amazon Connect in-app, web, and video calling の顧客側デモ画面 クリーンアップ AWS CLI から、web-voice-video-calling-blog ディレクトリに移動してください。 cd web-voice-video-calling-blog 「cdk destroy」を実行すると、Amazon CloudFront、Amazon API Gateway、AWS Lambda、AWS Systems Manager にインストールされたリソースが削除されます。 cdk destroy &nbsp;[ オプション ] ac_webcalling_SBSguide_handler フローと ac_webcalling_SBSguide_view フローの両方について、 delete-contact-flow コマンドを実行します。 結論 このブログ記事では、新しい Amazon Connect のアプリ内通話、ウェブ通話、ビデオ通話機能 について説明しました。 完全にマネージドされたコミュニケーションウィジェット を使用することで、企業はウェブサイトやモバイルアプリケーションにこの機能を数クリックで実装できます。 顧客が接続されると、顧客情報 (VIP 会員など) や他の情報 (ウェブサイトのページなど) に基づいて顧客体験をパーソナライズできるようになります。 これにより、コンタクトに優先順位を付けたり、可能な場合は自動的に解決したり、必要な場合は最適なエージェントにルーティングすることができます。 著者について​ Pavan Dusanapudi &nbsp;は、イギリスのマンチェスターを拠点とするアマゾン ウェブ サービスの AWS アプリケーションセールスに所属するスペシャリストソリューションアーキテクトです。彼は、カスタマーエクスペリエンスソリューションとデジタルトランスフォーメーションを通じて、顧客がビジネス成果を達成できるよう支援しています。余暇には、家族でのハイキング、クロスフィットワークアウトを楽しみ、心の平穏を見つけています。 Prabhakar Rajasekar は、ドイツのアーヘンを拠点とするアマゾン ウェブ サービスの AWSI アプリケーションセールスに所属するスペシャリストソリューションアーキテクトです。顧客のデジタルトランスフォーメーションを支援する傍らで、庭や森の中で子供たちと時間を過ごすことを楽しんでいます。 翻訳は Amazon Connect スペシャリストソリューションアーキテクト清水が担当しました。原文は こちら です。

はじめに クラウドガバナンスに生成 AI を組み込むことで、AWS アカウントの管理をより自動化された効率的なプロセスに変えることができます。 Amazon Bedrock &nbsp;の生成 AI 機能と、 AWS Control Tower や&nbsp; Account Factory for Terraform (AFT) などのツールを活用することで、お客様は AWS アカウントのセットアップと管理プロセスを迅速化し、ベストプラクティスを守りながら開発工数を最小限に抑えることができます。 お客様は、AWS アカウントをプロビジョニングする際に、様々な組織の要件と AWS のベストプラクティスを考慮して設定を行う必要があります。そのため、AWS アカウントのカスタマイズに少なからず開発工数を費やすこととなります。 本ブログでは、AWS アカウント作成プロセスのオーケストレーションにおける&nbsp; Agents for Amazon Bedrock の優秀性について解説します。Agents for Amazon Bedrock は、新しい AWS アカウントの作成リクエストやアカウントカスタマイズ用コードの作成など、お客様から要求されたタスクのオーケストレーションを自動化し、そのためのプロンプトを自動的に作成します。さらに、エージェントが Knowledge Bases for Amazon Bedrock &nbsp;で作成されたナレッジベースに接続されている場合は、ナレッジベースから取得した情報（例: お客様固有の情報）をプロンプトに追加し、お客様に自然言語で応答するための API を呼び出します。また、AWS アカウントをプロビジョニングする際には AFT も利用します。AFT は Terraform パイプラインを設定し、AWS Control Tower 内で AWS アカウント作成とカスタマイズを行います。AFT を使用するには、お客様は Terraform 設定ファイルに AWS アカウントの作成で 必要となる情報 を記載し、リポジトリにコミットする必要があります。リポジトリにコミットされると Account Factory ワークフローが自動的に実行され AWS アカウントが作成されます。Account Factory ワークフローの完了後に追加のカスタマイズのステップを自動的に実行します。 次のセクションでは、Agents for Amazon Bedrock と基盤モデル ( Claude 2.1 ) を使用し、 AWS セキュリティリファレンスアーキテクチャ (SRA) における「 セキュリティツールアカウント 」をプロビジョニングするユースケースにおいて IaC を加速させる方法について詳しく説明します。最後に、Amazon Bedrock から生成された IaC コードをデプロイする方法と、AFT を通じてインフラストラクチャのデプロイをスケールする方法を学びます。 ソリューションの概要 訳者注: 本ソリューションは、非 IT 技術者がチャットインタフェースを通して AWS アカウントを作成するような Agents for Amazon Bedrock の社内利用におけるユースケースのサンプルとして捉えていただければと思います。本ブログではセキュリティツールアカウントのプロビジョニングに焦点を当てておりますが、AWS のセキュリティサービスは Organizations と連携することで、個々の AWS アカウントでセキュリティサービスを有効化することなく複数のメンバーアカウントに対して一括で有効化することも可能です。 ソリューションのデプロイ方法について詳しく説明する前に、本ブログで構築する図 1 のアーキテクチャにおける各処理について見ていきましょう。 図1：AFT と Amazon Bedrock を利用した「セキュリティツールアカウント」作成の例 ユーザーは Agents for Amazon Bedrock&nbsp;のマネジメントコンソールにあるチャットを利用して、作成する AWS アカウントの要件を入力します。例えば、「セキュリティツール用の AWS アカウントを作成する」と入力します。エージェントには、AFT を利用して AWS アカウントを作成・カスタマイズするためのプロンプトと Knowledge Bases for Amazon Bedrock の設定が行われています。 上記例のような入力を受け取ると、エージェントは、セキュリティツール用の AWS アカウントに推奨される AWS セキュリティサービスをナレッジベースから取得します。エージェントは、推奨される AWS サービスをユーザーに提示します。ユーザーは提示された AWS サービスから、AWS アカウント作成時に有効化しておきたい AWS サービスの名前を入力します。 次に、エージェントはアカウント作成に必要な情報をユーザーの入力から収集します。ユーザーが選択した AWS サービスに基づき、エージェントは AWS サービスの情報をアクショングループに渡し、 AWS Lambda 関数を呼び出します。Lambda 関数は、Terraform モジュールとパラメータをナレッジベースから取得し Terraform 設定ファイルを作成します。作成したコードを AFT アカウントカスタマイズリポジトリ ( learn-terraform-aft-account-customizations &nbsp;からクローンした自身のリポジトリ) にプッシュします。次のアカウント作成のステップに進む前に、エージェントはユーザーに AFT アカウントカスタマイズリポジトリにプッシュした Terraform 設定ファイルで問題ないかを確認します。 ユーザーから「確認」の入力を受け取ると、エージェントは AFT による AWS アカウント作成用の Terraform 設定ファイルを作成し、AFT アカウントリクエストリポジトリ ( learn-terraform-aft-account-request &nbsp;からクローンした自身のリポジトリ) にプッシュする Lambda 関数を呼び出します。リポジトリにプッシュされると&nbsp; AWS Control Tower Account Factory for Terraform (AFT) パイプラインがトリガーされます。 次に、AFT パイプラインはサービスカタログ製品を呼び出します。この製品により、特定の OU に AWS アカウントが登録され、 AWS Control Tower と AWS Organizations を利用したガードレールが適用されます。 最後に、セキュリティツール用の新しい AWS アカウントがプロビジョニングされ、Security OU に登録されます。プロビジョニングされた AWS アカウントでは、ユーザが入力した AWS セキュリティサービスが有効化されています。 前提条件 1. このワークフローを使用して AWS アカウントを管理するには、Organizations 管理アカウントの Admin 権限、AWS アカウント設定を行うための Terraform の知識、および適切な AWS Identity and Access Management (IAM) の権限が必要です。また、AWS Control Tower と AFT が設定されており、AFT リポジトリと AWS Control Tower のマルチアカウント環境における役割を理解している必要があります。 2. 以下の理解も必要になります。 Agents for Amazon Bedrock 、 プロンプト 、 Knowledge Bases for Amazon Bedrock AFT モジュールのサンプル および チュートリアル learn-terraform-aft-account-request &nbsp;リポジトリ learn-terraform-aft-account-customizations &nbsp;リポジトリ デプロイ手順 このソリューションは、 AWS セキュリティリファレンスアーキテクチャ (SRA) に従い、セキュリティツール用、インフラストラクチャ用、ワークロード用などの各種 AWS アカウントを作成し、それぞれに対応する AWS サービスをデプロイするのに活用できます。本ブログでは、セキュリティツール用アカウントの作成と、推奨される AWS セキュリティサービスのデプロイにフォーカスして説明します。このソリューションをデプロイするには、以下の 4 つのステップを実施します。 ステップ 1 : ナレッジベースを設定する: &nbsp;ナレッジベースを設定することで、エージェントが AWS アカウントのプロビジョニングに必要な情報にアクセスできるようになります。ナレッジベースを設定するには、次の手順に従います。 Amazon Bedrock コンソール を開き、左側のナビゲーションパネルで [ナレッジベース] を選択し、 [ナレッジベースを作成] を選択します。 [ナレッジベース名] &nbsp;にナレッジベースの名前を入力します。「AWS-Account-Setup-Knowledge-Base」のように、ナレッジベースの目的を明確に表す名前にすることを推奨します。 [IAM 許可] &nbsp;では IAM ロールを選択します。 [既存のサービスロールを使用] &nbsp;から必要な権限を有する既存の IAM ロールを選択することもできますが、 [新しいサービスロールを作成して使用] &nbsp;を選択し、適切な権限を有する IAM ロールを作成するのが推奨されます。 [データソースを設定] &nbsp;では、データソースを定義します。セキュリティのため、暗号化を有効にした Amazon Simple Storage Service (Amazon S3) &nbsp;バケットを作成し、 [S3 URI] に指定します。Amazon S3 バケットには、AWS サービスと対応する Terraform モジュールのリストが記載されている JSON ファイルをアップロードします。JSON ファイルの構造については、リポジトリで提供されている サンプル を参照してください。 訳者注：利用する際は、ModuleSource などをお客様が利用している実際のモジュールにあわせて変更してください [埋め込みモデル] &nbsp;では、埋め込みモデルとして&nbsp; [Titan &nbsp;Embeddings G1 – Text] を選択します。 [ベクトルデータベース] &nbsp;では、ベクトルストアを選択します。ここでは、 [新しいベクトルストアをクイック作成 – 推奨] を選択し、Amazon Bedrock に Amazon OpenSearch Service &nbsp;を利用したベクトルストアの作成と管理を任せます。 レビューして最終確認をします。入力した全ての情報を正確性の観点から確認します。特に Amazon S3 バケット URI と IAM ロールを注意深く確認してください。問題なければ [ナレッジベースを作成] を選択します。 以下のバナーが表示されたら、 [同期] を選択します。&nbsp; ステップ 2 : エージェントを設定する: Amazon Bedrock コンソール を開き、左側のナビゲーションパネルで [ エージェント] を選択し、 [エージェントを作成] を選択します。 [エージェント名] 、 [エージェントの説明 – オプション ] などのエージェントの詳細を入力します。 [IAM 許可] &nbsp;では IAM ロールを選択します。 [既存のサービスロールを使用] &nbsp;から必要な権限を有する既存の IAM ロールを選択することもできますが、 [新しいサービスロールを作成して使用] &nbsp;を選択し、適切な権限を有する IAM ロールを作成するのが推奨されます。これにより、エージェントに AWS Lambda などの必要なサービスへのアクセス権が与えられます。 [モデルの詳細] から [Anthropic] 、 [Claude V2.1] を選択します エージェントを介して AFT を実行するために、以下のプロンプトを [エージェント向けの指示] に入力します “ Assist users in creating AWS accounts based on account type. Ask user which AWS account type(customization name) they would like to create: Security or Infrastructure AWS account. Ask user which AWS services they would like to deploy for their chosen account type. DO NOT assume AWS services for account type, ask user. Query the knowledge base for the approved AWS services list for the selected AWS account type. Present the AWS services to the user for service selection. Collect required user details for the account creation, for e.g.; “Please provide first name, last name, organization unit, account email and name”. Upon AWS services selection, invoke the account customization Lambda to generate the appropriate Terraform code. After successful execution of account customization lambda provide users repository link and ask for user confirmation of terraform code before triggering the AWS account creation lambda. Ask user to update code if needed. DO NOT trigger account creation lambda unless you receive confirmation from user. After user confirmation, initiate the account creation Lambda. Let the user know the account has been created with the customization. “ ステップ 3 : アクショングループを設定する: &nbsp;AFT による AWS アカウント作成とカスタマイズを可能にするために、エージェントに 2 つのアクションを追加します。 アカウントカスタマイズ用のアクショングループ: &nbsp;アカウントカスタマイズ用の Terraform 設定ファイルを生成する Lambda 関数（Lambda 関数を作成するには こちら の手順を参照）にリンクされたアクショングループを作成します。このアクショングループは、AWS アカウントにプロビジョニングする必要がある AWS サービスをユーザーが入力した後、エージェントによって呼び出されます。Terraform 設定ファイルは「learn-terraform-aft-account-customizations」リポジトリにプッシュされます。AFT はこのリポジトリを使用して、新しく作成された AWS アカウントに特定の設定を適用します。Lambda 関数のコードは、 こちら のリポジトリを参照してください。 アカウント作成用のアクショングループ: AFT を使用して AWS アカウントを作成する Lambda 関数にリンクされたアクショングループを作成します。このアクショングループは、ユーザーが Terraform 設定ファイルを確認し、「確認」と入力した後に呼び出されます。Lambda 関数のコードは、 こちら のリポジトリを参照してください。 ステップ 4 : アクショングループをエージェントに追加する: [アクショングループ名を入力] にアクショングループ名を入力し、 [説明 – オプション] に各アクションの動作の説明を記述します。 [ Lambda 関数を選択] では、適切な Lambda 関数を選択します。Lambda 関数は、アクションの呼び出し時に実行されるビジネスロジックを提供します。 [関数のバージョン] から使用する関数のバージョンを選択します。詳細については、「 Amazon Bedrock でエージェントのアクショングループの Lambda 関数を定義する 」をご覧ください。 [API スキーマを選択] では、アクショングループの API の説明、構造とパラメータが定義された OpenAPI スキーマの Amazon S3 URI へのリンクを定義します。API はユーザーの入力を受け取り、アカウント作成とカスタマイズの Lambda 関数を呼び出すロジックを管理します。API は、ユーザー入力値の検証、Terraform 設定ファイルの作成プロセスの開始、アカウントプロビジョニングのステータス監視など、さまざまなタスクを処理できるよう設計する必要があります。詳細については、「 Amazon Bedrock でエージェントのアクショングループの OpenAPI スキーマを定義する 」をご覧ください。 [別のアクショングループを追加]&nbsp; を選択して、もう 1 つのアクショングループを設定します。アカウントカスタマイズ用およびアカウント作成用のアクショングループを追加後、 [次へ] &nbsp;を選択します。 [ナレッジベースを追加 – オプション] では、 [エージェント向けのナレッジベースの指示] に「Retrieve AWS services for AWS Account type such as Security or Infrastructure」と入力します。 エージェントの作成完了後、 [テスト] と表示されたウィンドウよりエージェントの動作確認を行うことができます。 図 2 は、Amazon Bedrock を使ってユーザーが「セキュリティツール用アカウント」を払い出すときの操作画面のスクリーンショットです。 図 2 : AFT を利用した「セキュリティツール用アカウント」作成における Amazon Bedrock とユーザの対話例 クリーンアップ 不必要な課金を避けるために、テスト中に作成したリソースを削除してください。リソースをクリーンアップするには、以下の順序どおりに手順を実行します。 ナレッジベースの削除 エージェントから関連付けられているナレッジベースを削除するには、次の手順を実行します。 Amazon Bedrock コンソール を開きます。 左側のナビゲーションペインから [エージェント] を選択します。 ナレッジベースを削除したいエージェントの [名前] を選択します。 [Edit in Agent Builder]&nbsp; を選択します。 &nbsp; 削除するナレッジベースの横にあるラジオボタンを選択し、 [Delete] &nbsp;を選択します。 削除の確認画面が表示されるため、「delete」と入力し [Delete]&nbsp; を選択します。 左側のナビゲーションペインから [ナレッジベース] を選択します。 削除したいナレッジベースの [名前] を選択します。 データソースを削除するには、データソースの横にあるラジオボタンを選択して [削除] を選択します。 データソースの削除に関する警告を確認します。これらの条件に同意する場合は、入力欄に「削除」と入力し、 [削除] を選択して確定します。 削除するナレッジベースの横にあるラジオボタンを選択し、 [削除] &nbsp;を選択します。 ナレッジベースの削除に関する警告を確認します。これらの条件に同意する場合は、入力欄に「削除」と入力し、 [削除] を選択して確定します。 訳者注:&nbsp;翻訳時点では、警告に記載の「削除」ではなく「delete」と入力することで削除可能です。 Amazon OpenSearch Service コンソール より、Amazon OpenSearch Serverless&nbsp;のコレクションを削除します。 訳者注: 原文にはございませんが、コレクションを削除しない限り 料金 が発生し続けてしまいますのでご注意ください。&nbsp; 次の「エージェントの削除」手順を実行する前に、エージェントから関連付けられているナレッジベースを削除していることを改めて確認してください。 エージェントの削除 Amazon Bedrock コンソール を開きます。 左側のナビゲーションペインから [エージェント] を選択します。 削除するエージェントの横にあるラジオボタンを選択します。 エージェントの削除に関する警告を確認します。これらの条件に同意する場合は、入力欄に「delete」と入力し、 [Delete] を選択して確定します。 エージェントが削除されていることを知らせる青色のバナーが表示されます。削除が完了すると、成功を知らせる緑色のバナーが表示されます。 その他すべてのリソースを削除 これには AWS Lambda 関数と AFT が利用している AWS サービスが含まれます。 まとめ 生成 AI の統合により、AWS アカウント管理がより自動化され、効率的なプロセスに変革します。 Amazon Bedrock の生成 AI 機能と、AWS Control Tower や Account Factory for Terraform (AFT) などのツールを活用することで、組織は開発工数を最小限に抑えつつ、ベストプラクティスに沿った AWS アカウントのセットアップと管理を迅速に行えるようになります。このアプローチは、単に運用を効率化するだけでなく、AWS 環境の構築において、セキュリティとコンプライアンスを開発のあらゆるフェーズに埋め込むことができます。 本ブログのソリューションは、AWS のベストプラクティスに従ってクラウドリソースを効率的かつ安全にプロビジョニングするための Amazon Bedrock と AFT を組み合わせたアーキテクチャ、デプロイメントコード、プロンプトをお客様の組織に提供しています。 著者について Shiva Vaidyanathan Shiva Vaidyanathan&nbsp;は AWS のプリンシパルクラウドアーキテクトです。AWS での成功を確実にするため、技術ガイダンスを提供し、お客様への実装プロジェクトの設計と指導を行っています。クラウドネットワーキングを誰にとってもシンプルなものにするために尽力しています。AWS に入社する前は、パブリッククラウドインフラストラクチャにおける安全なコンピューティングの実行に関する NSF の資金提供を受けた複数の研究イニシアチブに携わってきました。ラトガーズ大学でコンピューターサイエンスの修士号を、ニューヨーク大学で電気工学の修士号を取得しています。 Ebbey Thomas Ebbey Thomas は、生成 AI を活用してクラウドインフラストラクチャの自動化を強化することに重点を置いたカスタム AWS ランディングゾーンの戦略立案と開発を専門としています。AWS プロフェッショナルサービスでは、クラウドの導入を効率化し、AWS ユーザーに安全で効率的な運用フレームワークを提供するソリューションを設計する上で、Ebbey の専門知識が中心となっています。彼はクラウドの課題に対する革新的なアプローチと、クラウドサービスの機能をさらに発展させることへの取り組みで知られています。 翻訳は Solutions Architect 北川が担当しました。原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 この1,2週、寒暖差のせいか周りに体調を崩す人が増えているように思います。みなさんもお気をつけください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2024年4月15日週の主要なアップデート 4/15(月) AWS PrivateLink now supports Amazon QuickSight AWS PrivateLinkがAmazon QuickSightをサポートしました。これにより多くのトラフィックをパブリックインターネットに公開することなくアクセスすることや、VPCエンドポイントポリシーを使用して承認されていないQuickSightアカウントへのアクセスを制限することができます。注意点として、静的コンテンツの取得には引き続きcloudfrontへのアクセスは必要になります。この新機能は、Amazon QuickSightとAWS PrivateLinkが利用できるすべてのAWSリージョンで利用いただけます。 Amazon QuickSight now supports account instances of IAM Identity Center Amazon QuickSightがIAM Identity Centerのアカウントインスタンスをサポートしました。これまではIAM Identity Centerの組織インスタンスが必要でしたが、今回のアップデートによりスタンドアロンのAWSアカウントや組織のメンバーアカウントでもIAM Identity Center経由の管理が可能になります。すでにアカウントインスタンスを利用の場合、Redshift、Lake Formation、Athena、EMR、CodeCatalystなどその他の対応アプリケーションと管理を合わせることができます。この新機能は、Amazon QuickSightとIAM アイデンティティセンターが利用できるすべてのAWSリージョンで利用可能です。 Amazon RDS for Oracle extends support for x2iedn in additional AWS regions 大阪リージョンを含む8のリージョンで新たにAmazon RDS for OracleのX2iednインスタンスをご利用いただけるようになりました。Amazon RDS for Oracle X2iedn は、高い計算能力 (最大128vCPU)、大容量メモリ (最大4TB)、およびストレージスループット要件 (最大256,000IOPS)を備え、 大量のデータセットをメモリで処理するワークロードに高速なパフォーマンスを提供するように設計されています。 Amazon RDS Custom for Oracle now supports Oracle Database Standard Edition 2 Amazon RDS Custom for OracleがOracle Database Standard Edition 2 (SE2)をサポートしました。Amazon RDS Custom for Oracle は、Oracle データベースエンタープライズエディション (EE) に加え、今回SE2をサポートしましたが、EE、SE2ともBring Your Own Media （BYOM）モデルでのみ使用できます。詳細については Amazon RDS Custom for Oracle ユーザーガイド をご確認ください。 4/16(火) Anthropic’s Claude 3 Opus model now available on Amazon Bedrock Anthropic社の最も先進的で高性能なモデルであるClaude 3 OpusがAmazon Bedrockで利用可能になりました。これによりAnthropic社の最先端モデルのClaude 3 ファミリー(Claude 3 Opus, Claude 3 Sonnet, and Claude 3 Haiku)が全てAmazon Bedrock経由でご利用いただけます。Claude 3 Opusは米国西部 (オレゴン) リージョンでご利用可能です。詳細については ドキュメント の他、 ブログ もご確認ください。 Monitor internet outage using the weather map in CloudWatch Internet Monitor Amazon CloudWatch Internet Monitorでインターネットウェザーマップを無料でご利用いただけるようになりました。インターネットウェザーマップでは、インターネットのレイテンシーと可用性の停止に関する 24時間のグローバルスナップショットを共有しています。このマップでは、特定の都市やサービスプロバイダーを含む、世界中の最近のインターネット問題を一目で確認できます。詳細については ドキュメント と、こちらの ブログ もご確認ください。 Amazon MWAA adds larger environment sizes Amazon Managed Workflows for Apache Airflow (MWAA)でより大きな環境サイズが提供されました。これまではsmall, medium, largeの中から選択可能でした。これらに加えてlargeの2倍のXL, 及びlargeの4倍の2XLが新たに追加されました。新規の作成もしくはアップグレードで選択可能です。このアップデートはすべてのAmazon MWAA提供リージョンで利用可能です。詳細についてはこちらの ブログ をご確認ください。 AWS CloudFormation ChangeSets now offer enhanced change visibility for deployments AWS CloudFormationの変更セットが強化され、デプロイ時に実行されるアクションの詳細をプレビューできるようになりました。これによりデプロイによって実行中のリソースに意図しない変更が発生するかどうかを評価しやすくなります。今回の強化では!Refや!GetAtt などによる参照やAWS Secrets Manager and Parameter Store、Systems Managerの動的参照もプレビューすることができるようになります。変更セットの強化は、コンソールのほか、AWS CLIまたはSDKからの場合は、DescribeChangeSet APIの呼び出し時に–include-property-valuesパラメータを含めてください。このアップデートはCloudFormationが利用可能なAWSリージョンでご利用いただけます。 Amazon Athena announces federated query pass-through Amazon Athenaのfederated query pass-throughが発表されました。Athenaには従来からfederated queryというAmazon Redshift、Amazon DynamoDBなどのデータソースのデータを抽出する機能がありました。今回のリリースではこの機能が強化され、SQLをデータソースにパスし、データソース独自のSQLが実行できるようになりました。federated query pass-throughはAthenaが利用可能なすべてのAWS リージョンで利用できます。詳細については ドキュメント をご確認ください。 4/17(水) AWS launches Split Cost Allocation Data for Amazon EKS AWS コストと使用状況レポート (CUR) でAmazon EKSのコストを詳細に把握できるようになりました。Amazon EKS の分割コスト配分データを使用すると、コンピューティングとメモリの使用率に基づいてポッドレベルのコストをきめ細かく把握できるので、これらのコストをクラスタ、名前空間、その他の Kubernetes プリミティブごとに集計して、個々のビジネスユニットやチームにコストを割り当てることができます。加えてお客様は未使用のCPUまたはメモリリソースを特定できるため、クラスター構成を最適化して非効率性を最小限に抑えることができます。これらのコストデータは設定後24時間以内にAWS CURで利用できるようになります。このアップデートは中国を除くすべてのAWS商用リージョンで利用できます。詳細については こちらのブログ をご確認ください。 Amazon SageMaker Studio Notebooks supports interactive data exploration and SQL query execution Amazon SageMaker StudioのJupyterLab ノートブックに拡張機能が組み込まれました。これによりノートブックからSQLとPythonを使用して複数データソースを検索、調査、変換することが可能になります。今回の拡張機能によりAWS Glue 接続を介して Amazon Athena、Amazon Redshift、Snowflake などの一般的なデータサービスにシームレスに接続できるようになりました。機械学習をノートブックの統一されたユーザーインターフェイスに統合することで、分析や機械学習のタスクに取り組む際にツールを切り替える必要性を減らし、時間を大幅に節約し、生産性を向上させることができます。この機能は、SageMaker Studio が利用可能なすべての商用 AWS リージョンで利用できます。詳細については、 ブログ もご確認ください。 Announcing Accessibility Conformance Reports (ACRs) in AWS Artifact Announcing Accessibility Conformance Reports (ACRs)がAWS Artifactで利用できるようになりました。ACRは AWSサービスのアクセシビリティを実証する文書で、ITI自主製品アクセシビリティテンプレート (VPAT®) を利用し、セクション 508 (米国)、EN 301 549 (EU)、ウェブコンテンツアクセシビリティガイドライン (WCAG) などのさまざまなアクセシビリティ基準を参照しています。 4/18(木) Meta Llama 3 foundation models now available on AWS Meta社の最新世代のファンデーションモデルであるLlama 3がAmazon SageMaker JumpStartで利用いただけるようになりました。東京を含む5つのリージョンでご利用いただけます。このアップデートの詳細は ブログ も出ているのでそちらもご確認ください。 AWS Neuron introduces speculative decoding and vLLM support AWS Neuronの２．１８がリリースされました。NeuronはAmazon EC2 Inferentia and TrainiumのためのSDKで、PyTorch や TensorFlow などの一般的なMLフレームワークと統合されています。またTrn1 インスタンスと Inf2 インスタンスでのジェネレーティブ AI モデルの高性能トレーニングと推論をサポートするコンパイラ、ランタイム、ツール、およびライブラリが含まれています。Neuron 2.18ではPyTorch 2.1のベータが外れた他、vLLMサポートによる継続的バッチ処理などが追加されています。詳細は リリースノート をご確認ください。 Amazon WorkSpaces helps simplify Bring Your Own License (BYOL) account management Amazon WorkSpacesで、同じリージョン内のAWSアカウントをリンクするAPIが提供されました。リンクされたアカウントは同じ専用のインフラストラクチャを使用できるため、Bring Your Own License (BYOL) WorkSpacesの管理が簡素化されます。詳細に関しては APIのリファレンス をご確認ください。 AWS IAM Identity Center adds independent 90-days session duration for Amazon CodeWhisperer AWS IAM Identity CenterでAmazon CodeWhispererのセッション期間を独立して設定できるようになりました。セッション時間は15分から90日の間で設定可能ですが、以前はAWSアクセスや他のアプリケーションと同様の時間が設定されるためにIDE経由で使う際も頻繁な再認証を求められることがありました。一方で、Amazon CodeWhispererに関しては同じ頻度の再認証が必ずしも必要ではないケースもあり、今回のアップデートで個別に設定できることで、開発者体験の柔軟性が増します。 4/19(金) AWS Elastic Disaster Recovery now supports AWS Outposts Racks AWS Elastic Disaster Recovery (AWS DRS) がAWS Outposts ラックに対応しました。これまではOutposts ラックのレプリケーションを取る際、またはリカバリ先として利用する際はCloudEndure Disaster Recoverを使う必要がありました。今回のアップデートはAWS DRSが利用可能なすべてのAWSリージョンでご利用いただけます。 Amazon Personalize now offers automatic solution training Amazon Personalizeでソリューションのトレーニングを自動で行うスケジュール設定をできるようになりました。より簡単にデータセットの情報をもとにユーザーの行動や好みの変化に合わせたリコメンデーションが可能になります。新しく作成されたソリューションは7日に1回自動的にトレーニングされる設定がされ、頻度の変更や設定の削除が可能です。また、アップデート前に作成された既存のソリューションは影響を受けず、自動で変更されません。詳細は ドキュメント をご確認ください。 Amazon EMR on EKS now supports Apache Livy Amazon EMR on Amazon EKSでApache Livyがサポートされました。Apache LivyはRESTインターフェイスを介してSparkクラスターと簡単にやり取りできるようにするサービスです。Amazon EMR on Amazon EKSではこれまでもStartJobRun APIおよびインタラクティブエンドポイント経由でRESTでのワークロードの実行ができましたが、より簡単に、アプリケーションの変更なく利用できるようになります。また、Kerberos、Custom AuthなどのサポートされるプロトコルでLivyエンドポイントへのアクセス制御も可能です。Apache Livyを搭載したAmazon EMR on Amazon EKSは現在サービスが利用可能なリージョンのEMR 7.1リリース以降でご利用いただけます。詳細は ドキュメント もご確認ください。 GW前後のAWSのイベントのアナウンスが出ています。AI関連が多いですが、よかったらぜひご登録ください。 ——————– ◆2024 年 4 月 25 日 (木) 10:00 – 11:15 生成 AI の業務活用に向けて考える “責任ある AI” ◆2024 年 5 月 9 日 (木) 10:00 – 11:10 流通・小売・消費財業界向け：クラウドと生成 AI による顧客接点改革 ◆2024 年 5 月 16 日 (木) 10:00 – 12:00 生成 AI の価値を最大限に引き出すためのデータ基盤 ◆2024 年 5 月 17 日 (木) 10:00 – 12:00 AWS メディアセミナー ～ NAB 2024 の recap と最新事例のご紹介 ～ ——————– 週刊AWSの更新ですが、次週はお休みして次回はGW明けになります。 それでは、また次回！ ソリューションアーキテクト 根本 裕規 (twitter – @rr250r_smr )

デジタルトランスフォーメーションとは、デジタル技術を活用した戦略的なビジネス施策であり、ビジネスの成果を最大化することを目的としています。このブログでは、デジタルトランスフォーメーションへの反復的アプローチ、すなわちデジタルトランスフォーメーション・フライホイールを紹介します。Stellantis社との協業（ 2022年のアマゾンのプレスリリース を参照）の中から厳選した事例は、このフレームワークが Stellantis のデータドリブンかつソフトウェアにフォーカスしたモビリティ企業への変革をどのように可能にしたかを示しています（ 2024年のStellantis社 デア・フォワード2023 を参照）。 一般に、組織がデジタルトランスフォーメーションを必要とする背景には、いくつかのコンペリングイベント (差し迫った理由) があります。例えば、1/前年比の収益成長を促進する、2/変化のスピードや業界からのプレッシャーに対応するために事業ポートフォリオを最適化する、3/新しいデジタル製品やサービスを追加することによって事業やオペレーティングモデルを刷新する [2023年のHBRの記事 などを参照]、4/製品開発を加速するためにビジネスの俊敏性とスピードを向上させる[ 2008年のHBRの記事 などを参照] などがあります。このデジタルトランスフォーメーションで成功するために極めて重要な鍵は、長期におよぶトランスフォーメーションの戦略のための枠組み (ガードレール) を提供し、経営陣からのトップダウンに基づくデジタルトランスフォーメーションのためのビジネスケースを形成する企業のリーダーシップによる経営ビジョンです。 アマゾンが1994年に書籍のオンライン販売を開始し、2006年にクラウドサービスを提供して以来、デジタルトランスフォーメーションは私たちのDay 1 文化の中心であり [ 2024年 AWS Executive Insights を参照]、お客様を第一に考えることは不変の信念です。そのため、私たちはそれぞれの顧客のイニシアチブ (取り組み) を “Why？(なぜ？)”という質問から始めます。「Right thing (正しいもの) 」を構築することは、「Popular thing(人気のあるもの)」を構築することよりも重要だからです。デジタルトランスフォーメーションの枠組みの中では、デジタル変革の原動力となるコンペリングイベントを明確に理解しなければなりません。そのために、我々は以下の5つの質問に答えることを目的とした、一連のお客様から逆算するワークショップを実施しました [ 2021年 Working Backwards at AWS を参照] 。： お客様は誰か？ お客様の問題や機会は何か？ 最も重要なお客様の利益は何か？ お客様は何を望んでいるのか？ お客様の体験とはどのようなものか？ このお客様から逆算する方法論に裏打ちされた反復的な製品開発は、一つの円として循環し、一巡ごとにビジネス成果の価値をスケールアップさせます。アマゾンでは、この効果をフライホイールまたは好循環と呼んでおり[ 2012年 Youtube を参照]、アマゾンのイノベーション文化の最も古いコンセプトの一つです[ 2020年 Youtube を参照]。このコンセプトは、もともとジェフ・ベゾスがナプキンの上で考案したもので、お客様の体験を継続的に改善しながら顧客に執拗にこだわることで、企業の成長を実現するために用いられました。今日に至るまで AWS のイノベーション文化の一部であり続けています。 一般的にフライホイールという用語は、各構成要素がエネルギーを加えることで加速しながら回転する閉じたループのプロセスを指します。例えば、最初のループで顧客がウェブページ上で商品を返品できるようにした場合、2回目のループでは顧客が返品状況を追跡できるようにし、3回目のループでは顧客がオンラインで購入した商品をより良く評価できるようにするかもしれません。その結果、顧客返品プロセスは時間の経過とともに、より多くの機能によってより豊かになり、将来的には返品の数を減らすこともあるでしょう。 デジタルトランスフォーメーションそのものを反復的な変革プロセスとして捉えれば、同じ反復的なプロセスを継続的に適用することができます。ここでは、規模の大きな企業に対してデジタルトランスフォーメーションを開始し加速させるために、構築によって変革を進めるアプローチ (a transform-by-build approach)として「デジタルトランスフォーメーション・フライホイール」を紹介します。この新しいアプローチを図 1 に示します。デジタルトランスフォーメーション・フライホイールは、デジタルトランスフォーメーションを6つの相互に補強し合う連続した構成要素としてまとめられてます： 1/ 戦略的OKR (Objectives and Key Results 目標と主要な成果）、2/デジタル製品とサービスをスケールさせる、3/ビジネスプロセスを改善する、4/関係者をエンパワーメントする、5/組織を再構築する、6/イノベーション文化を醸成する。 図1：デジタルトランスフォーメーション・フライホイールは、戦略的OKR から始まる6つの相互に補強し合うドメインに沿ってデジタルトランスフォーメーションを説明します 01｜ 戦略的OKR (Objectives and Key Results 目標と主要な成果） フライホイールは、戦略的 OKR から始まります。戦略的 OKR とは、企業の経営層がデジタルトランスフォーメーションによって達成したいと考えるビジネス成果です。すでに述べてきたように、デジタルトランスフォーメーションは2020年のコロナウイルスの大流行による自動車サプライチェーンの混乱など、いくつかのコンペリングイベントによって引き起こされることもあります。テクノロジーを活用したデジタルトランスフォーメーションはそれ自体が目的ではなく、むしろ具体的なビジネス成果を実現するものだからです。そのためビジネス成果は組織のビジネスモデルと密接に結びついており、ビジネスモデルは顧客と従業員のために価値を創造する方法を定義しています。なお、ビジネス成果につながる活動にはインパクトの大きな活動とそうではない活動があるため、コスト削減の可能性やその他のKPIなどビジネスへのインパクトに応じて優先順位をつけることが重要です。 Stellantis との協業が始まった当初、私たちはエグゼクティブ ビジョニング ワークショップを開催し、説得力のある目指すべきビジョン (North star) のナラティブを作りました。それは Stellantis のデジタル化のミッションに対して、ビジネス成果のリストと優先順位で説明し、AWSがどのように支援できるかを説明しています。代表的なビジネス成果の1つは、 Stellantis の VEW (Virtual Engineering Workbench 仮想エンジニアリング ワークベンチ) と呼ばれる仮想シミュレーション環境を提供することで、自動車の製品開発を加速させることがあげられます。VEW は、オープンで自動化されスケーラブルなエンドツーエンドの開発者ツールとツールチェーンのまとまりから成り立ちます。そして、それらは自動車のハードウェアとソフトウェアのコンポーネントに対する仮想シミュレーション、テスト、検証、妥当性確認、機能統合のために使用されています [ 2024年 AWS Blogの投稿 , 2023年 AWS Blogの投稿 , 2023年 Youtube を参照]。もう一つの代表的なビジネス成果は、Stellantis の DIA (Data Infrastructure Architecture データ基盤のアーキテクチャ)を通して、Stellantis にコネクテッドビークルのデータの可視性を与えることです。DIA は、一元的に管理され、高いセキュリティを備えたスケーラブルなクラウド環境のことであり、コネクテッドビークルから生じるデータを Stellantis とそのパートナーやサプライヤー間で保存、処理、分析、共有するために設計されました。それによって、データの収益化を含む新しいビジネスのユースケースの実現を支援します [ 2022年 AWS Blogの投稿 を参照]。 目指すべきビジョンのナラティブを土台として、 Stellantis のデジタルビジョンを実現するために VEW と DIA を構築するロードマップに落とし込んだ PR/FAQ [ 2006年 Working Backwards を参照] を作成しました。この PR/FAQ は顧客のニーズ、ベネフィットおよびお客様の体験を説明するプレスリリース（PR） と呼ばれるセクションと、VEW と DIA のユーザーが考える可能性のあるよくある質問（FAQ）から成り立ちます。この特徴ある PR/FAQ の構造によって、私たちは考えのギャップを認識することができます。さらにエンドユーザーの課題に対応しながら、経営層が思い描くビジネス成果を実現するための技術的なソリューションを開発する優れた土台となりました。 02｜デジタル製品・サービスをスケールする このPR/FAQの作成で得られたインサイトに基づき、最初のプロトタイプを開発しました。そのプロトタイプによって、双方のメンバーが最適なテクノロジーのスタックを選択し、選択したクラウドのアーキテクチャが望ましいビジネス成果を提供できることを検証しました。この時点では、まだ図 1 に示すデジタルトランスフォーメーション・フライホイールのグレー部分のループにいます。プロトタイプは Stellantis からのフィードバックに基づき、価値を提供する最小限の製品（MVP）として構築され、受け入れ基準が満たされるまでフェイルファストで反復的に改良されました。独立してデプロイでき、要求に基づいて自動的に規模を拡大できるように、各プロトタイプはモノリシックなサービスではなく、セルフサービスのポータルと使いやすいAPIを備えた分散型のマイクロサービスから構成されています。デジタルトランスフォーメーション・フライホイールのこのフェーズは 「デジタル製品・サービスをスケールする」と呼ばれ、顧客中心の製品開発サイクルを完結させました [ 2024年 AWS Executive Insights を参照]。 本番環境へのデプロイ後、私たちは Stellantis のユーザーから選ばれたベータテスターに MVP を利用していただき、ユーザーからのフィードバックの収集を開始しました。このフィードバックは、パフォーマンスやユーザビリティなどの製品改良に反映されました。さらに新しい機能の開発にインスピレーションを与え、その機能がバックログに追加され、その後に実装されました。それぞれの主要なビルドや改良のステップは、Stellantis と AWS のチームによってハッカソンと呼ばれる 1 週間のスプリントのような共同のワークショップで実施されました。これによってチーム内の連携を強化し、社内外に VEW と DIA に対する熱意を伝えました [ 2023年 Stellantis 社のプレスリリース を参照]。また、AWS のブログ「 Hackathons for Accelerated Vehicle Software Development at Stellantis 」[2023年]もご参照ください。 03 | ビジネスプロセスを改善する アジャイル開発の方法論を使ってデジタル製品やサービスを開発し本番環境にデプロイすることは、開発をサポートするさまざまなプロセス変更への圧力となりました。例えば、VEW のデプロイを成功させるために、関連するStellantis のオペレーションチームはユーザーからのフィードバックを収集し、タイムリーかつフレキシブルに対応するためにチケットシステムを導入する必要がありました。このようにチーム間の効果的なコラボレーションには、常に効率的なビジネスプロセスによってサポートされるべきです。そして効率的なビジネスプロセスとは、意思決定を行い組織のリソース（人材、予算などを含む）を配置し、合意されたビジネス成果を提供するための構造化された活動や（自動化された）ワークフローのことです。このようなプロセスは、組織内の責任や役割がデジタルトランスフォーメーションのジャーニーに沿って変化するにつれて、継続的に見直され、改善される必要があることにも注目すべきでしょう。このように効率的なビジネスプロセスを確立することは、デジタルトランスフォーメーション・フライホイールのもう1つの核となる要素です。これは、デジタル技術を活用したプロセスの合理化によってオペレーショナルエクセレンス (運用上の優秀性) を達成するために、組織のオペレーティングモデルを見直す、として表現されることもあります。 04 | 関係者をエンパワーメントする ビジネスプロセスの改善に加えて、デジタルトランスフォーメーション・フライホイールのもう1つの重要な要素は、継続的なトレーニングと能力開発による社員の能力強化です。最終的には人が変化を起こすので、この意味は計り知れません。例えば、Stellantisの VEW と DIA が提供するサービスを利用するためには、自動車開発者やエンジニアが AWS クラウドの基本的なスキルを習得するだけでなく、AWS Cloud Adoption Framework（CAF）、Scaled Agile Framework (SAFe)、スクラム [ AWS Website など参照] などのアジャイルな働き方、オープンイノベーションやコラボレーションを促進する方法論に関する知識も必要となります。これらの分野で従業員を効果的にトレーニングをするために、Stellantis は AWS のトレーニングの担当チーム (AWS Training and Certification) と共同で TechXelerateと呼ばれるトレーニングプログラムを開始しました [ 2023年 AWS Training and Certification の投稿 を参照]。このプログラムは、2024年までに5,000人以上のStellantisの開発者とエンジニアのスキルアップとリスキルを目指し、Stellantisのデータドリブンかつソフトウェアにフォーカスした企業への変革を加速させることを目指すものです [ 2022年 Stellantis Press Release を参照]。 05 | 組織を再構築する ミラーリング仮説（コンウェイの法則としても知られています）によれば、組織のコラボレーションやコミュニケーションの構造は、その製品やサービスのアーキテクチャに反映します［ 2016年 HBR記事 を参照］。言い換えれば、組織を横断して相互に関連するようなタスクは、エンドツーエンドのユースケースに焦点を当てた組織横断のチームによって実装されるのが最適ということになります。そのタスクには、例えば VEW における自動車ソフトウェア開発のためのエンドツーエンドのツール間連携の実装や、DIA におけるコネクテッドビークルのデータ用の自動 ETL (抽出-変換-ロード) パイプラインの構築があげられます。したがってデジタルトランスフォーメーションの成功には、ユースケースに焦点を当てたコラボレーションを確立するために組織を再構築することが必要です。革新的な VEW と DIA の機能を開発するために Stellantis と AWS の両組織の技術専門家を集めた様々な組織横断的プロジェクトチームを設立しました。これには、例えば Stellantis のSoftware Driven Experience, Global Analytics &amp; Data Products, Information Communication &amp; Technology, Global Security Operations、AWSプロフェッショナルサービス（AWS ProServe）のメンバーが含まれます。多くのチームは革新的な製品やサービスを迅速に立ち上げ、マイクロサービスのアーキテクチャが提供する俊敏性とスピードを最大限に活用するために、ピザ 2 枚チームの小規模な組織横断のチームで編成されています [ 2024年 AWS Executive Insights を参照]。 06｜イノベーション文化を醸成する デジタルトランスフォーメーションを成功させるためには、組織全体でアジャイルなコラボレーションに基づくオープンイノベーション文化を確立することが極めて重要であり、それはフライホイールのもうひとつの中核的な要素です。この文脈においてイノベーション文化とは、顧客と従業員のために価値を創造する組織の能力を指します。ハーバード・ビジネス・スクールのクレイトン・クリステンセンはかつて、あらゆる組織に不可欠なこの文化の部分を次のように定義しました： 「文化とは、共通の目標に向かって協力し合う方法であり、それが常に守られ、成功しているため、人々は別の方法で物事を進めようとは考えようともしません。文化が形成されていれば、人々は成功するために必要なことを自律的に行うようになります」［2012年 C. M. クリステンセン他『 How Will You Measure Your Life 』ハーパー・ビジネス社を参照］。 Stellantis と AWSは、さらに外部パートナーも含めた自動車のエンジニアリングチームとのハッカソンを頻繁に開催することで、オープンイノベーションの文化を醸成してきました。協業の開始時に作成された目指すべきビジョンのナラティブとPR/FAQは、エグゼクティブとの Think Big ワークショップで定期的に見直され、さまざまなチーム間のコラボレーションを戦略的OKRに整合させています。また、カンファレンス [ re:Invent 2022 や Automobil Elektronik Kongress 2023 などを参照] やその他の業界イベントにおいてサードパーティの開発者、サプライヤー、独立系ソフトウェアベンダー、 AWSパートナーネットワーク（APN） の外部コンサルティングやテクノロジーパートナーとも関わっています。このようにして私たちは、デジタルトランスフォーメーション・フライホイールの次の反復のための基礎となる新しいデジタル製品、サービス、機能、能力のアイデアを継続的に開発しています。 まとめ Stellantis との協業から得られた事例は、AWS が VEW や DIA のようなクラウドネイティブの製品やサービスを構築することで、よりデータドリブンかつソフトウェアにフォーカスした組織へのデジタルトランスフォーメーションを支援していることを示しています。また、デジタルトランスフォーメーションは、1つの反復から次の反復へと加速する好循環と見なすことができることも実証しています。本ブログで紹介するデジタルトランスフォーメーション・フライホイールは、アマゾンのイノベーション文化に着想を得ており、その好循環を大規模な企業に対しても役立てることができます。また、デジタルトランスフォーメーションに対する全体的、構造的、反復的なアプローチを提供し、より現代的なデータドリブンかつソフトウェアにフォーカスした組織になるためのデジタルトランスフォーメーションのジャーニーを示しています。 本ブログはAWS Blog の “ The Digital Transformation Flywheel: How AWS Helps Accelerate the Digital Transformation of Stellantis ” をソリューションアーキテクトの藤井が翻訳しました。 Volker Lang Volker Lang は、アマゾン ウェブ サービス（AWSプロフェッショナルサービス）のストラテジック プログラム リーダーです。シングルスレッド リーダーとして、彼自身、彼の顧客対応チーム、デリバリーチームは世界中の自動車業界で、私たちの最も戦略的なお客様のデジタルトランスフォーメーションの実現を可能にします。AWS入社以前は、ドイツの自動車業界において、電動化とデジタル化に焦点を当てた様々な大規模なビジネス変革をリードしてきました。オックスフォード大学で量子物理学の博士号を取得し、著書「Digital Fluency」を出版しました。 John Valent John Valent は、エンタープライズの変革のエキスパートであり、EMEA (ヨーロッパ、中東およびアフリカ) における AWS プロフェッショナルサービス（ProServe）のオートモーティブ・プラクティスをリードしています。自動車業界に関する深い専門知識を持ち、さまざまなOEMと密接に連携してデジタルトランスフォーメーションによる課題の克服に取り組み、企業全体のビジネス成果を加速させています。ジョンは2018年7月に AWS に入社し、以前は Teradata Germany でプロフェッショナルサービス（自動車）のディレクターを務めていました。

インターネットには、ハードウェア側のルーター、スイッチ、ハブ、地上/海底ケーブル、コネクタ、そしてソフトウェア側の複雑なプロトコルスタックや設定といった、多数の可動部分があります。お客様に影響を及ぼす形でインターネットを減速または停止させる問題が発生したときには、可能な限り早急に問題の場所を特定して理解できるようにしておく必要があります。 新しい天気図 そんなときに役に立つのが、Amazon CloudWatch の新しいインターネット天気図です! AWS が運営する一群のグローバルモニター上に構築されたこの天気図は、インターネット気象の広範なグローバルビューとともに、特定の都市に影響を及ぼすパフォーマンス問題や可用性問題をクローズアップして理解する機能を提供します。天気図にアクセスするには、CloudWatch コンソールを開き、左側にある [ネットワークモニタリング] を展開して、 [インターネットモニター] をクリックします。世界中の気象が反映された天気図が表示されます。 赤と黄色の円はそれぞれ、可用性またはパフォーマンスに影響を及ぼす現行のアクティブな問題を示しています。灰色の円は過去 24 時間内に解決された問題を表し、青いひし形は AWS リージョン を表しています。天気図を画面に表示したままにしておくと、15 分ごとに自動更新されます。 各問題は特定の都市ネットワークに影響を及ぼし、クライアントが AWS リソースにアクセスする場所と、AWS リソースへのアクセスに使用された AS 番号 (ASN) の組み合わせを表しています。ASN は通常、個別のインターネットサービスプロバイダー (ISP) を表します。 天気図の右側にあるリストには、最上部にアクティブなイベントが表示され、その下に最近解決されたイベントが 24 時間前までさかのぼって表示されます。 インジケーターのいずれかにカーソルを合わせることで、その地域内の都市ネットワークのリストを確認できます。 1～2 回ズームインすると、これらの都市ネットワークが米国全土に展開されていることがわかります。 さらにズームインして、単一の都市ネットワークを表示することもできます。 この情報は、プログラム的に利用することも可能です。新しい ListInternetEvents 関数は、1 コールあたり最大 100 件のパフォーマンスまたは可用性イベントを返し、オプションで時間範囲、ステータス ( ACTIVE または RESOLVED )、タイプ ( PERFORMANCE または AVAILABILITY ) によるフィルタリングを使用できます。各イベントには、緯度や経度などの詳細情報が含まれています。 新しい天気図はすべての AWS リージョンからアクセスでき、使用料金はかかりません。将来に向けて、ロードマップでは皆さんのフィードバックに基づく優先順位に従った多数の強力な追加機能が計画されています。現在は、以下を検討中です。 DDoS 攻撃、BGP ルートリーク、ルートの相互接続問題など、特定の障害タイプの原因の表示。 選択された ISP に固有のビューの追加。 パブリック SaaS アプリケーションに対する影響の表示。 この機能に関するフィードバックは、いつでも internet-monitor@amazon.com までお寄せください。 CloudWatch Internet Monitor 天気図内の情報は、AWS 上に構築されたアプリケーションを使用するすべての人を対象としています。インターネット気象が特定の AWS アプリケーションにどう影響するかを理解し、 ヘルスイベント通知 や トラフィックインサイト などのその他機能を利用したいという場合は、CloudWatch Internet Monitor を活用できます。2022 年後半に この機能がリリース されたとき、私の同僚である Sébastien はこのように言いました。 インターネットに接続するアプリケーションを監視するときの課題のひとつは、AWS 外のデータを収集して、地理的に離れた複数のインターネットプロバイダーに接続する顧客に対してアプリケーションがどのように動作するかに関する実態を把握することだというご意見をいただいています。インターネットトラフィックがインフラストラクチャに到達する前に、そのデータをキャプチャして監視することは難しく、そうでなくとも非常に高いコストがかかります。 天気図を確認したら、 [モニターを作成] をクリックして、CloudWatch Internet Monitor の使用を開始できます。 その後、モニターの名前を入力し、監視する AWS リソース (VPC、CloudFront ディストリビューション、Network Load Balancer、Amazon WorkSpace ディレクトリ) を選択してから、監視するインターネット接続トラフィックのパーセンテージを選択します。モニターは数分内で監視を開始し、VPC フローログ、CloudFront アクセスログ、およびその他テレメトリからの入力を使用して、最も関連性の高い都市ネットワークを特定します。 以下は、この機能の詳細を学ぶために役立つリソースです。 Amazon CloudWatch Internet Monitor プレビュー – アプリケーションのインターネットパフォーマンスをエンドツーエンドで可視化 Amazon CloudWatch Internet Monitor の紹介 Easily set up Amazon CloudWatch Internet Monitor Using Amazon CloudWatch Internet Monitor for enhanced internet observability Use Amazon CloudWatch Internet Monitor for greater visibility into online experiences ドキュメント: Amazon CloudWatch Internet Monitor の使用 動画: Amazon CloudWatch Internet Monitor その他の質問やコメントについては、internet-monitor@amazon.com までご連絡ください。 – Jeff ; 原文は こちら です。