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

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

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

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

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

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

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

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

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

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

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

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

AWS Cloud Development Kit (CDK) を使って既存のリレーショナルデータベース上にスケーラブルでセキュアな GraphQL インタフェースを簡単に構築できる機能を発表しました。AWS Systems Manager Parameter Store に SecureString として安全に保存されたデータベースの認証情報と共に AWS Amplify GraphQL API CDK コンストラクトを提供し、SQL ステートメントを実行する GraphQL API の構築を開始します。この新機能は、 Amazon Relational Database Service (Amazon RDS) 上の MySQL および PostgreSQL データベース、または外部でホストされている MySQL および PostgreSQL データベースで動作します。 2023 年 10 月に、DynamoDB データベースの作成と接続をサポートする Amplify GraphQL API の新しい L3 CDKコンストラクトを発表しました 。L3 CDK コンストラクトにより、お客様は AWS Lambda 関数を作成し、追加のデータソースに接続することができます。お客様は AWS Lambda を使用する柔軟性を楽しんでいるが、データベース接続、SQL 文の実行、ネットワーク設定を管理するためのカスタムコードを手作業で構築するための価値を生みづらい重労働を取り除くために、MySQL と PostgreSQL データベースに対するよりファーストクラスのサポートを求めていました。 既存の MySQL および PostgreSQL データベース用の新しい GraphQL API を 5 つのステップで作成してみましょう。 前提条件 始めるには以下が必要です。 npm 経由の CDK CLI がインストールされていること このガイドでは、Amazon RDS で デプロイされた MySQL と PostgreSQL データベースがあることを前提に説明しますが、この機能は一般にアクセス可能などのデータベースでも動作します。 Step1 – データベースの認証情報を Systems Manager に保存 データベース接続情報 (ホスト名、ユーザ名、パスワード、ポート、データベース名) を、Systems Manager に SecureString として格納します。 Systems Manager コンソールに移動し、 Parameter Store に移動して、 Create Parameter をクリックします。データベースサーバのホスト名、接続するユーザ名とパスワード、データベースポート、およびデータベース名にそれぞれ 1 つずつ、合計 5 つの異なる SecureString を作成します。 Systems Manager 構成は以下のようになります。 Step 2 – 新しい AWS CDK プロジェクトをセットアップし、Amplify GraphQL コンストラクトをインストール 新しい AWS CDK アプリケーションを作成し、ターミナルで以下の AWS CDK CLI コマンドを実行して、AWS Amplify GraphQL コンストラクトの依存関係をインストールします。 mkdir sql-api cd sql-api cdk init app --language=typescript 次にプロジェクトを開き、 npm install @aws-amplify/graphql-api-construct を実行して、GraphQL API コンストラクトを依存関係に追加します。 Step 3 – GraphQL スキーマで Query と Mutation を定義 AWS CDK アプリの lib/ フォルダ内に、公開したい API を含む新しい schema.graphql ファイルを作成します。公開したい API に合わせて、GraphQL オブジェクト型、Query、Mutation を定義します。例えば、データベーステーブルのオブジェクト型、それらのテーブルからデータを取得する Query、それらのテーブルを変更する Mutation を定義します。 type Meal { id: Int! name: String! } type Query { listMeals(contains: String!): [Meal] @sql(statement: "SELECT * FROM Meals WHERE name LIKE CONCAT('%', :contains, '%');") @auth(rules: [{ allow: public }]) } Queryリクエストから引数を参照するには、 :notation を使用できます。Amplify の GraphQL API は、デフォルトで拒否ベースで動作します。 { allow: public } ルールでは、API キーを使用している人であれば誰でもこの Queryを呼び出せるように指定しています。API キー、Amazon Cognito User Pool、OpenID Connect、AWS Identity and Access Management (IAM)、またはカスタム Lambda 関数に基づいて、これらの Query や Mutation へのアクセスを制限するために Authorization ルール を確認してください。 Step 4 – GraphQL API コンストラクトと、VPC 設定を構成 データベース内の SSM パスを参照する、AWS CDK スタック内の GraphQL API CDK コンストラクトの新しいインスタンスを作成します。このコンストラクトを sql-api-stack.ts ファイルにインポートします。 import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; AWS CDK スタックコードで、 GraphqlApi のインスタンスを作成します。データベースの認証情報への SSM パラメータパスを props として渡します。また、 .graphql スキーマファイルを指すように schema プロパティを設定します。 export class RdsStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { databaseNameSsmPath: '/rds-test/database', hostnameSsmPath: '/rds-test/host', passwordSsmPath: '/rds-test/password', portSsmPath: '/rds-test/port', usernameSsmPath: '/rds-test/username', }, }, ), authorizationModes: { // We recommend to only use API key authorization for development purposes. defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) } } }) } } 今回は、MySQL データベースは Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon RDS 上にデプロイされているため、データベースの VPC 情報も GraphQL API に提供する必要があります。 GraphqlApi コンストラクトで、Amazon VPC、アベイラビリティゾーン、セキュリティグループ ID を指すように vpcConfiguration プロパティを構成します。 const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { ... }, // Place all VPC Configuration in here. If your database is // publicly reachable over the Internet, you can skip this config. vpcConfiguration: { // (1) Set the security group ID securityGroupIds: ['sg-08XXXXXXX'], // (2) Set the VPC ID vpcId: 'vpc-c3XXXXXX', // (3) Set the available subnet + availability zone config subnetAvailabilityZoneConfig: [{ availabilityZone: 'us-east-1b', subnetId: 'subnet-5bXXXXXXX' }] }, }), authorizationModes: { ... } }) Step 5 – GraphQL API のデプロイ 次に AWS CDK アプリをデプロイします。 cdk deploy を実行して、スキーマから接続されたデータベースで GraphQL API スタックを起動します。これで、AWS AppSync コンソールに移動し、GraphQL Query と Mutation の実行を開始できます。 ボーナス：インライン SQL ステートメントをファイル参照にリファクタリング SQL ステートメントを GraphQL API と一緒にインラインで記述することは、特に API が大きくなるにつれて管理が難しくなる可能性があります。これらの Query や Mutation を管理しやすくするには、SQL ステートメントを別の .sql ファイルで作成し、GraphQL スキーマに参照として追加します。まず、新しい lib/sql-statements フォルダーを作成し、SQL ステートメントを含む listMeals.sql ファイルを追加してみましょう。 lib/sql-statments/listMeals.sql ファイルは以下のようになります。 SELECT * FROM Meals; lib/sql-api-stack.ts ファイルで、 sql-statements/ フォルダーから読み取り、カスタム SQL ステートメントとして Amplify GraphQL API に追加します。 // ...Other imports import * as fs from 'fs'; import * as path from 'path'; import { AmplifyGraphqlApi, AmplifyGraphqlDefinition, SQLLambdaModelDataSourceStrategyFactory } from '@aws-amplify/graphql-api-construct'; export class RdsStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); // Define custom SQL statements folder path const sqlStatementsPath = path.join(__dirname, 'sql-statements') // Use the Factory to define the SQL data source strategy const sqlStrategy = SQLLambdaModelDataSourceStrategyFactory.fromCustomSqlFiles( // File paths to all SQL statements fs.readdirSync(sqlStatementsPath).map(file => path.join(sqlStatementsPath, file)), // Move your connection information and VPC config into here { dbType: 'MYSQL', name: 'MySQLSchemaDefinition', dbConnectionConfig: { ... }, vpcConfiguration: { ... }, } ) const amplifyApi = new AmplifyGraphqlApi(this, "AmplifyApi", { definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( path.join(__dirname, "schema.graphql"), sqlStrategy ), authorizationModes: { defaultAuthorizationMode: 'API_KEY', apiKeyConfig: { expires: cdk.Duration.days(30) } } }) } } 次に、カスタム SQL ステートメントを参照するように GraphQL スキーマを更新します。カスタム SQL ステートメントは、ファイルのベースネーム (拡張子「.sql」を除いたファイル名) に基づいて参照できます。 type Meal { id: Int! name: String! } type Query { #- listMeals(contains: String!): [Meal] @sql(statement: "SELECT * FROM Meals WHERE name LIKE :contains") @auth(rules: [{ allow: public }]) listMeals(contains: String!): [Meal] @sql(reference: "listMeals") @auth(rules: [{ allow: public }]) } これで、API を反復処理するスピードが格段に速くなりました。例えば、GraphQL スキーマに以下の内容を追加して、食事を作成する新しい Mutation を追加してみましょう。 type Mutation { createMeal(id: Int!, name: String!): AWSJSON @sql(reference: "createMeal") @auth(rules: [{ allow: public }]) } 注：MySQL から生のレスポンスを取得する手っ取り早い方法として、AWSJSON 型を返します。これは、オプトインできる追加の型安全性を提供しません。同じリクエスト内で変更または作成されたアイテムを返す方法については、ドキュメントを参照してください。 次に、新しい lib/sql-statements/createMeal.sql ファイルを以下の内容で作成します。 INSERT INTO Meals (id, name) VALUES ( :id, :name ); これで、AWS CDK アプリを再度デプロイすることができ、新しい Mutation を持つ API が利用可能になります。 cdk deploy クリーンアップ 生成されたリソースをすべてクリーンアップします。ターミナルで以下の AWS CDK CLI コマンドを実行します。 cdk destroy まとめ このガイドでは、AWS CDK を使用して新しい GraphQL API を作成し、SQL ステートメントを実行する Query とMutation を作成し、それらを認可ルールで保護しました。Amplify GraphQL API の MySQL や PostgreSQL データベースとの統合の詳細については、 既存の MySQL や PostgreSQL データベースへの API の接続に関するドキュメント を確認してください。 本記事は「 Create a GraphQL API for any existing MySQL and PostgreSQL database 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を中心に技術支援を行っています。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

この記事は “ Highlights from the AWS Healthcare and Life Sciences Executive Symposium 2023 at re:Invent ” を翻訳したものです。 re:Invent 2023 の初日11月27日にラスベガスで AWS Healthcare and Life Sciences Executive Symposium 2023 を開催しました。この半日の対面イベントには、180の組織から300人以上のリーダーが参加し、データ、分析、機械学習（ML）、生成AIを活用してイノベーションを加速するための各社の取り組みが発表されました。 今年のシンポジウムは、生成AIの可能性によってもたらされた業界の変革的な転換のため、昨年のシンポジウムとは内容が明らかに異なっていました。それは、研究開発の活性化やビジネスのオペレーションの改善、従業員の満足度向上や患者体験の向上など、様々な側面での影響をもたらしました。今年のシンポジウムの主な目的は、これらのユースケースを掘り下げるだけでなく、ビジネス上大きなインパクトをもたらすMLや生成AIアプリケーションを構築する鍵は高品質なデータへの柔軟なアクセスにあることを強調することでした。 以下は、セッションからの主なハイライトと注目すべきインサイトです。 オープニング基調講演のハイライト シンポジウムは、AWSと Merck による共同の基調講演で開始されました。基調講演で語られた重要な点は、 生成AIにとってお客様自身が保有するデータが差別化要因になる ということです。組織を本当に変革することができる強力な生成AIアプリケーションを構築することに成功する企業は、堅牢でエンドツーエンドのデータ戦略から始める企業です。 この概念を具体的に示すために、MerckのCIOであるデイブ・ウィリアムス氏がステージに登場し、クラウド上でデータを活用して自分たち自身を再発明し、AI/MLを活用して再先端の科学を支えるためにAWS上でデータ基盤を構築している方法を紹介しました。彼らのセッションで強調されていたポイントは、CEO主導のデジタル変革プログラムがあったこと、BlueSkyと呼ばれるクラウド推進プログラムがこの変革を進めるための重要な役割を果たしていたことです。さらに、彼らは、組織全体でデータがスムーズに流れるようにするためのOne Merck Data戦略を紹介し、この戦略的アプローチによって促進される影響度の高いAI/MLの利用事例を出席者に紹介しました。MerckのAWSとの連携について詳しくは こちら をご覧ください。 基調講演では、この後に続くセッションを大きく二つのパートに分けて紹介しました。 シンポジウムの第1部では、エンドツーエンドのデータ戦略の概要と、 AWSの包括的なヘルスデータポートフォリオ が組織がその堅牢なデータ基盤を構築し、MLと生成AIの可能性を最大限に解き放つ支援方法に焦点を当てました。 シンポジウムの第2部では、 AWS上でMLと生成AIのブレイクスルーを解き放つ アプローチにフォーカスしました。このパートで、すぐにでも活用できる関連するユースケースと、MLと生成AIを責任を持って活用したアプリケーションを構築するための確率されたガイドラインを探求しました。 第1部のハイライト：データと分析を活用してイノベーションをスケールさせる オープニングのAWS主導のデータセッションでは、エンドツーエンドのデータ戦略が何を含むかについて包括的な概要を出席者に提供しました。組織内のサイロを超えた横断的なデータの統合から、サードパーティやリアルワールドのデータセットへの安全でシームレスなアクセスの促進、マルチモーダルデータからの洞察を抽出するための能力の開発まで、このプレゼンテーションでは、これらの異なる要素が堅牢なデータのバックボーンとして調和して統合される必要があることが説明されました。 ※[社内データサイロを取り除く/適切なユースケースに重要なデータクラスの識別と検索性/サードパーティ・リアルワールドデートへのアクセス・シームレスな統合/外部組織とのデータ連携のためのセキュアでプライバシーを保護する環境/患者の病歴や研究データからインサイトを得るためにマルチモーダルデータを解析するケーパビリティ/データを実行可能なインサイトに変換する包括的な分析、機械学習、生成AIのケーパビリティ] セッションはまた、具体的な「how」の実践的な側面にも踏み込みました。参加者は、AWSの包括的なヘルスデータポートフォリオが組織がイノベーションのハブを作成するのにどのように役立つかについて、 AWS HealthOmics 、 AWS HealthImaging 、 AWS HealthLake 、 AWS HealthScribe など、パーパスビルドなソリューションを通して理解することができました。セッションでは、 AWS Data Exchange 、 AWS Clean Rooms 、 Amazon DataZone など、内部および外部のデータにアクセスして共同作業するための適切なソリューションについてもトップレベルの視点を提供しました。 参加者は、AWS上でエンドツーエンドのデータ戦略のさまざまな要素を積極的に構築している同業者から学ぶ機会を得て、情報をより実践的かつ適用可能にするための貴重な洞察を得ることができました。 Genomics England は、AWSを使用してマルチモーダルデータの保存、検索、ガバナンスを変革している方法について共有しました。セッションでは、 AWS上でがんのための世界最大のマルチモーダルデータプラットフォーム の構築方法について説明しました。 Bristol Myers Squibb は、AWSを活用することで 社内のデータサイロを打破し 、データを利用可能な状態にする方法について紹介しました。参加者は、彼らが構築したデータメッシュアーキテクチャに触れ、組織全体でデータへのアクセスや新薬発見を改善するために、いかに Amazon DataZone を活用する予定かを学びました。 Inovalon のセッションでは、 AWSを使用して外部データコラボレーションを推進する方法 について述べ、Inovalon ONE Platformがヘルスケア・ライフサイエンスの組織がプロプライエタリなデータセットにアクセスし、患者体験を向上させるためによりよい判断を下すための支援方法について説明しました。 プレスリリースはこちら。 Boehringer Ingelheim は、彼らのRWE Center of Excellenceを紹介しながら、リアルワールドデータ（RWD）を活用してイノベーションを加速する方法について共有しました。このセッションでは、新しい世界中のRWDを発見、評価し、エンタープライズレベルのRWDコラボレーションを促進し、リアルタイムに近いデータセットの統合を通してインサイトの創出を加速させるために、A mazon Data Exchange の利用を詳しく説明しました。 最後に、 Stanford Health Care のデータリーダーらを迎えた「MLと生成AIを活用するためのデータの解放」に関するパネルディスカッションが開催され、生成AI利用をProof of Concept段階から全社的な利用につなげるために活用したデータ基盤について議論しました。このセッションはシンポジウムの前半を見事に締めくくり、さまざまな要素が調和してデータ駆動型の組織を作り上げ、MLと生成AIの力を十分に解放する方法を示しました。 第2部のハイライト：ヘルスケア・ライフサイエンスにおけるMLと生成AI イベントの第2部は、AWS主導のセッションで始まりました。このセッションでは、ヘルスケア・ライフサイエンスの企業、組織がAWS上で簡単にMLと生成AIを始める方法に焦点を当てました。セッションでは、AWSの包括的なAI/MLのサービス群がお客様に対してビジネスに応じた適切なツールを構築、購入、カスタマイズできる柔軟性を提供しており、より簡便に、最適なコストで、そして実務上使える状態で、テクノロジーを利用する方法を、説明しました。 参加者は、 Amazon Bedrock の新機能を学びました。これにより、ビルダーはAI21 Labs、Anthropic、Cohere、Meta、Stability AIなどの主要なAI企業の最新の基盤モデルを選択して、生成AIアプリケーションを責任を持って、簡単に作成およびスケールができるようになりました。また、このセッションでは、Amazon Bedrockの簡単な概要を説明し、数クリックでAgents for Amazon Bedrockが基盤モデルを構成し、マニュアルのコードは不要でタスクを自動で分解しオーケストレートします。 実用性を高めるために、現在利用可能なさまざまな関連する生成AI利用事例のクイックデモを紹介しました。これには、公衆衛生と腫瘍学のためのRAGベースのチャットボット、製薬マーケティングコンテンツ生成、新薬探索ワークベンチ、医薬品製造のコンプライアンス監査、およびエンタープライズシステムとデータソースを使用してタスクを実行するエージェントが含まれています。 セッションでは、 NVIDIA BioNemo on AWS でサポートすることも発表されました。これにより、生成AIを使用して先進的な治療法の研究開発を加速するためのR&Dが可能になります。NVIDIA BioNemoは、新薬探索用の生成AIプラットフォームであり、現在 AWS ParallelCluster経由でAmazon SageMaker上 やNVIDIA DGX Cloud on AWS上で利用可能です。これにより、製薬企業の研究者や開発者は、自社のプロプライエタリデータを使用して基盤モデルのトレーニングを簡素化し、加速化することで、新薬探索を容易に速く進めることができます。 AWS上でMLと生成AIアプリケーションを構築する話題は、その後の一連の顧客向けライトニングトークにも続きました。 ライフサイエンス分野では、 Genentech（Roche） が、コマーシャルバリューチェーン内の3つのユースケースで生成AIをAWS上でどのように使用しているかを共有しました。それは、1/個別化された顧客エンゲージメント、2/実行可能な顧客ニーズの検知、および3/測定の自動化と収益シミュレーションです。参加者は、これらのユースケースを実現するためのAWSベースの技術スタックを垣間見るだけでなく、OneRoche Responsible AI Frameworkの仕組みも知ることができました。このフレームワークは、Genentechがエンタープライズレベルのセキュリティを備えた、責任あるソリューションの構築を支援しています。 ヘルスケア分野では、国内最大の放射線診断を行なっている Radiology Partners は、AWSのAWS HealthImagingなどの目的に特化したサービスが、彼らのAIオーケストレーションプラットフォームであるRPX AIを支えている方法を紹介しました。これにより、彼らがサービスする3600人以上の医師と3300以上の医療施設のニーズに応えるために、病院や医療システム向けのAI医療画像ツールを迅速に展開することが可能となります。 MLと生成AIの急速な拡大は革新的なブレイクスルーを確固たるものとしますが、同時に、プライバシー、セキュリティ、ガバナンス、公正性などの新たな課題が提起されています。この日の最後のセッションでは、Anthropic、Baxter、Deloitteのリーダーとの「責任ある安全な生成AIの構築」に関するファイアサイドチャットを開催しました。このセッションでは、各組織が「責任あるAI」をどのように定義し、この急速に変化する状況に対処するための独自のアプローチを概説しました。聴衆は、データセキュリティ、プライバシー、IP保護、および信頼性に関する貴重な知識を得て、AIを組織内で真の善の力として促進するために、複雑さをうまく乗り越えることができるようになりました。 私たちが17年前にAWSを立ち上げたときから、ヘルスケア・ライフサイエンスのお客様は最前線でクラウド利用を進められました。そして、このシンポジウムでMLと生成AIを使用して個別化医療や精密医療に向けて大きな一歩を踏み出す業界のリーダー企業を目の当たりにして感銘を受けました。これは、いわゆる「可能性の範囲内で最善を実現する」をまさに表している取り組みでした。 私たちの包括的なデータ、ML、生成AI提供について詳しくは、 AWS for Healthcare and Life Sciences のウェブサイトをご覧ください。 re:InventでのHCLSの他の発表やハイライトについては、 ブログ をご覧ください。 このブログはヘルスケア・ライフサイエンス事業開発 片岡が翻訳しました。

Amazon Web Services (AWS) は、AWSとして初となる AWS Education Accelerator に参加するスタートアップ企業 15 社を選出したことを発表しました。2023 年 10 月に発表された AWS Education Accelerator は、教育・学習体験を向上させ、教育成果を改善するためにイノベーションを起こす教育テクノロジー (EdTech) のスタートアップ企業を支援します。 教育が進化し続ける中、これまでの教育や学習の慣習にとらわれることなく、生徒が新しい可能性を切り開くためには データドリブンな意思決定が鍵となります。 これは、スタートアップ企業が教育の未来を変える可能性につながり、データ、アナリティクス、人工知能 (AI) を思慮深くかつ公平に活用することで、以下のような大きな教育課題の解決に役立ちます。 参加する EdTech スタートアップ企業は、幼稚園から高校までの教育機関、高等教育機関、人材育成のお客様向けの幅広いソリューションに注力しています。AWS を活用して次世代の EdTech ソリューションを開発することで、これらのスタートアップ企業は、学生のエンゲージメント、金融リテラシー、学生の健康と福祉、スキルアップ、業務の非効率性などの教育課題に対処することを目指しています。 10 週間のアクセラレータープログラムは、シアトルの Amazon 本社で 2024 年 1 月からスタートしています。参加するスタートアップ企業はそれぞれ、最大 10 万ドルの AWS コンピューティングクレジット、ハンズオン、ワークショップ、個別のカリキュラムが用意され、ビジネス指導や技術指導、Amazon のリーダーやチームからのインサイト、潜在的な投資家や顧客とのネットワーキングの機会、継続的なアドバイザリーサポートを受けることができます。プログラムの最後には、教育関係の顧客からの認知度を高めるために、 OMNIA Partners とのコラボレーションによるバーチャルでの Emerging Technology Showcase が開催されます。 本プログラムによって、最終的に EdTech の創業者達が新規顧客の開拓、パートナーネットワークの拡大、資金調達、自らの EdTech スタートアップを急速に成長させる準備が整っている状態を目指します。 プログラムに参加するスタートアップ企業の紹介 今回のプロジェクトに選出されたスタートアップ企業を発表します。採択企業は何千もの応募から、AWS のスタートアップと教育の専門家からなる委員会によって、アイデア力、技術的な準備状況、そして多岐にわたる申請および面接プロセスに基づいて選ばれました。 AWS Education Acceleratorに選ばれた15社のスタートアップは、幼稚園から高校までの教育機関、高等教育機関、人材育成機関向けの幅広いソリューションにフォーカスしています。 各スタートアップの概要と、取り組んでいる課題はこちらをご覧ください： Augmental Learning Inc County of Sussex, DE Augmental は、次世代のパーソナライズされた学習、インテリジェントなコンテンツ作成、データドリブンな分析を提供し、教育コンテンツの作成者を強力にサポートする AI を搭載した学習プラットフォームを提供しています。 Blackbullion London, UK Blackbullion は、学生に金融スキルを身につけさせる金融福祉プラットフォームとアプリケーションです。このプラットフォームは、学生向けのイギリス最大規模の支援基金、奨学金、助成金のハブを有しています。 enlightenAI San Francisco, CA EnlightenAI は、AI を搭載したパーソナライズされた教師用アシスタントを開発しています。採点やフィードバックなど、教育者の仕事をより持続可能なものにしながら、教育者の影響力を高めることを目的としています。 Hilight New Orleans, LA Hilight は、教師や学校スタッフがハイライトを投稿し、学校や地区で毎日起きている多くの小さな成功を共有することを支援します。Hilight は、よく見落とされがちな意味ある瞬間をユーザーが見つけることを助け、教育者の満足度、幸福感、教師の集団効力感 (collective teacher efficacy)、そして勤務継続率を高めます。 Infini‑D Learning Provo, UT Infini-D Learning は、学生が実世界の課題に取り組めるように、ストーリーに基づいた物語と共同での問題解決を組み合わせることで、教室での学習を変える没入型プラットフォームを開発しました。 Lessonbee Mount Vernon, NY Lessonbee は、基準に沿った健康教育の公平なアクセスを学生に提供します。また、学校における健康格差を減らし、公平性を促進するためのツールとリソースを教師に提供しています。Lessonbee の学校全体に向けたウェルネスソリューションは、教師が学生の自己効力感と幸福感を向上させるために役立つデータを提供します。 Listening San Francisco, CA Listening は学生や研究者のために設計されたモバイルアプリケーションを提供します。教科書や研究論文を音声に変換することで、外出先でのインサイトの提供やメモ機能を提供し、研究プロセスの効率化を支援します。 Oblio, Inc. Murrieta, CA Oblio は、入試担当者、教員、スタッフ、コーチによるパーソナライズしたメールの送信、コミュニケーションの効率化、多言語対応を支援するように設計された革新的なAIツールで、大学の入試プロセスを改善しています。 OneRange New York, NY OneRange は、企業による個別学習予算管理の自動化を支援しています。このプラットフォームは、コース、書籍、カンファレンスなど、あらゆる形式の学習リソースに関するデータを活用することで、各個人に適したリソースの発見とアクセスを可能にします。 Perlego London, UK Perlego は、100 万冊以上の学術書をオンラインで購読できるサービスです。出版社と提携することで、印刷、流通、小売にかかるコストを排除し、世界中の学習者により手頃で持続可能なソリューションを提供することを目的としています。 Praxis AI Sacramento, CA Praxis AI は、生成 AI を活用したデジタル教育・研究企業です。いつでも、どこでも利用できるこのソリューションは、学生と教師のやり取りをパーソナライズした指導、評価、サポートと組み合わせて提供しています。 Quizard AI, Inc. Dover, DE Quizard は、テストや小テストの勉強を支援するために設計された大学向けのアプリです。多言語で利用可能な Quizard は、世界中の学生がパーソナライズされた学習にアクセスできるようにしています。 SchoolBI San Francisco, CA SchoolBI は、データドリブンなインサイトを得るのに役立つ、使いやすさを重視したプラットフォームです。このプラットフォームは、従来の非効率性、時間的制約、ボトルネックを削減し、部門横断的に結果を簡単に報告する能力を向上させるように設計されています。 Sown To Grow Oakland, CA Sown To Grow は、簡単で魅力的なプロセスを用いた学生による振り返りと、教師からのフィードバックのプロセスを通じて、学生の社会的、感情的、学問的な幸福度を向上させるために学校を支援するプラットフォームです。Sown To Grow は元教育者のチームによって設計され、米国教育省、米国国立科学財団、Digital Promise、New Schools Venture Fundから資金提供を受けています。 The Juice Miami, FL The Juice は、楽しく魅力的なオリジナルコンテンツを使って、児童の読解力、クリティカルシンキング、情報・メディアリテラシーのスキル、公民の知識を伸ばすためにデザインされたインタラクティブな学習プラットフォームです。 データに基づいた教育における AWS クラウドの理解をさらに深める AWS がどのように EdTech イノベーションを 支援し、学習成果を向上させ、学生のデータを保護するか をご覧ください。さらに、 AWS Education Competency Partners からのサポートや、 AWS Marketplace の教育・学習ソリューション、信頼できる技術プロバイダー、教育機関に様々なクラウドベースのソリューションを提供するコンサルティングの専門家についてもご紹介します。 TAGS: AWS Public Sector , EdTech , education , education technology , higher education , K-12 , learning , startups , teaching Kim Majerus Kim Majerusは、Amazon Web Services (AWS) において、グローバル教育および米国の州政府・地方政府を統括しています。彼女の営業組織には、教育テクノロジー (EdTech) と政府テクノロジー (GovTech)、独立系ソフトウェアベンダー (ISV) 、医療・福祉サービス、司法・公安、交通、州・地方政府顧客向けの IoT にフォーカスするソリューション・バーティカル戦略リーダーが含まれます。 日本の教育機関の皆様へのご支援は こちら をご覧ください。 本ブログはソリューションアーキテクトの山下一樹が翻訳しました。原文は こちら です。

AWS SaaS Factory シニアパートナーソリューションアーキテクト Peter Yang 氏、AWS SaaS Factory プリンシパルパートナーソリューションアーキテクト Ranjith Raman 氏による投稿 Amazon Web Services (AWS) のサービスを使用してデータ取り込みアーキテクチャを設計および実装する方法はいくつかあります。 マルチテナントの Software as a Service (SaaS) 構成でデータを取り込む場合、ソリューションに組み込むべき追加の考慮事項、課題、トレードオフがあります。 SaaS の場合、テナントの詳細を取得し、取り込みプロセス全体で伝達されるようにする必要があります。これは、テナントのペルソナに基づいてデータを分離し、ワークロードとストレージを分割する方法に直接影響します。 マルチテナントデータ取り込みプロセスを実装する際に使用できる戦略は複数あります。専用 (サイロ型) メカニズムを使用するものと、共有 (プール型) 取り込みモデルを使用するものがあります。どちらも完全に有効で、両方を混在させることができますが、この投稿では、プール型モデルでのデータ取り込みの実装の細部に焦点を当て、テナントが取り込みリソースを共有する際に考慮すべきさまざまな点を取り上げます。 この投稿には、コードの実際に動作するサンプルソリューションが付属しています。このソリューションをデプロイするための手順は、 GitHub から参照できます。 マルチテナントデータ取り込みの設計上の考慮事項 ソリューションの技術アーキテクチャについて詳しく見ていく前に、マルチテナントデータ取り込みプロセスを設計する際の主な考慮事項を見ていきましょう。以下は、このようなソリューションを構築する際に SaaS プロバイダーが検討する一般的な要素のリストです: スケーリングとパフォーマンス: 大量のリクエストを処理し、シームレスに数千のテナントにスケールできる能力 セキュリティと隔離: テナントのイベントが認証されていることを保証するためのコントロールを実装し、そのコントロールを使用したデータのパーティショニングと隔離の判断 リソース管理: 突発的で予測が困難なトラフィックを処理するシームレスな容量管理 運用効率: 運用と管理のオーバーヘッドを削減 ソリューションアーキテクチャ この投稿では、データ (EC サイトや POS アプリケーションなどを想定) を収集および集計し、このデータをテナント / 顧客固有の属性で処理 (エンリッチおよび変換) してバックエンドデータストアに格納するサンプルソリューションをもとに説明を行います。 これらのアプリケーションは通常、「注文の合計」や「購入された商品のカテゴリー」などのクリックストリームデータやイベントを追跡し、データからトレンドを特定したり、重要な洞察を導き出すことを目的としています。 任意の瞬間にアクティブなユーザー数によっては、1 秒間に生成されるデータは大量になる可能性があります。 そのようなビジネスやユースケースをサポートするには、非常にスケーラブルでパフォーマンスが高く、イベントを非常に低いレイテンシーで処理できるアーキテクチャが必要です。 次の図は、ソリューションのアーキテクチャを示しています。 図 1 – ハイレベルアーキテクチャ リクエストフロー このアーキテクチャの詳細に入る前に、サンプルソリューションで採用されているハイレベルな要素を見て見ましょう。 以下が、このソリューションの一部であるいくつかのステップです: このソリューションのフローは、図 1 の左側から開始します。テナントは、 Amazon API Gateway が提供する REST API を使用して、SaaS 環境にメッセージやイベントを送信します。これは、ストリーミングイベントのエントリポイントであり、各テナントからのイベントの認証を担当します。 Amazon API Gateway は、 Amazon Cognito を使用してJSON Web Token (JWT) を検証する Lambda オーソライザー を利用します。Lambda オーソライザーは、 Amazon Kinesis Data Streams への入力として使用できるように、Amazon API Gateway のコンテキストに tenantId を追加します。 Amazon API Gateway はプロキシとして機能し、Kinesis Data Streams にテナントイベントをプッシュします。Kinesis Data Streams は、あらゆる規模でデータストリームをキャプチャ、処理、保存するのに適した、サーバレスなストリーミングデータサービスです。この例では、Kinesis Data Streams が異なるテナントからのストリーミングデータを収集するデータインジェストストリームになります。 Amazon Kinesis Data Streams はデータを Amazon Managed Service for Apache Flink  にプッシュします。このソリューションでは Amazon Kinesis Data Analytics for Apache Flink がデータの処理を行い、tenantId とtimestamp の追加に利用されます。これらの値は Amazon Data Firehose がストレージとして利用される Amazon Simple Storage Service (Amazon S3) のプレフィックスの作成に使用します。 Amazon Kinesis Data Analytics for Apache Flink はテナントイベントを Amazon Data Firehose にプッシュします。Amazon Data Firehose は、リアルタイムのストリーミングデータを直接 S3 に配信し、ストレージとさらなる処理のために使用されます。S3 には、マルチテナントデータを効率的に保存および整理するためのいくつかのメカニズムがあります。 より深い考察は、S3 を使用したマルチテナンシー実装のさまざまな戦略が議論されているこの AWS ブログ投稿 をチェックしてください。 これでハイレベルなアーキテクチャを理解したので、ソリューションの各コンポーネントについてより詳しく見ていきましょう。 リクエストの認証と認可 Amazon API Gateway は、このソリューションのフロントドアとして機能し、テナントアプリケーションからのデータストリームをスケーラブルな方法で取り込むための、セキュアなエントリーポイントを提供します。API Gateway を使用することで、テナントコンテキストを抽出し、受信リクエストを認証する Lambda オーソライザー を導入することもできます。 このテナント情報は、テナントが Amazon Cognito によって認証されたときに生成された エンコード済み JSON Web トークン (JWT) を介して渡されます。このコンテキストは、インジェストされたデータを個々のテナントに関連付けることをこのソリューションが可能にするために不可欠です。 API Gateway によって処理される各リクエストは、JWT からテナントコンテキストを抽出し、リクエストのアクセス範囲を設定する AWS Identity and Access Management (IAM) ポリシーを返す Lambda オーソライザーを呼び出します。 ポリシーとともに、リクエストのコンテキストにテナント ID ( tenantId ) も導入します。フローの後半で、このコンテキスト値の利用方法を見ていきます。以下のコード例は、コンテキストの一部として tenantId を設定する方法を示しています。 policy = AuthPolicy(principalId, awsAccountId) policy.restApiId = apiGatewayArnTmp[0] policy.region = tmp[3] policy.stage = apiGatewayArnTmp[1] policy.allowAllMethods() authResponse = policy.build() context = { 'tenantId': tenantId, } authResponse['context'] = context return authResponse Kinesis Data Streams へのデータのルーティング リクエストが正常に処理された後に、メッセージが Amazon API Gateway から Amazon Kinesis Data Streams に転送されるように設定します。これは、テナントデータのストリームを収集および処理します。以下の 図 2 は、設定手順を示しています。 ここでは、統合リクエストの統合タイプを AWS サービスに設定しています。つまり、リクエストを AWS サービス (この例では Kinesis Data Streams) に転送しているということです。 図 2 – Amazon API Gateway の統合リクエスト値 リクエストがストリームに転送される前に、API Gateway で変換を適用して、Kinesis Data Stream が期待している形式にリクエストを変換します。 Amazon API Gateway ではマッピングテンプレートを使用して、メソッドリクエストのペイロードを対応する統合リクエストにマップできます。 ソリューションでは、図 3 に示すように、テンプレートを使用して StreamName、Data、 および PartitionKey の値を設定しています。 Lambda オーソライザー によって設定された コンテキスト の一部として受信した tenantId フィールド を使用して、Kinesis Data Streams で必要な属性である PartitionKey の値を設定しています。 このテンプレートにより、ダウンストリームのサービスに渡されるすべてのリクエストが、そのリクエストを行うテナントとの関連付けがされていることを確認します。 図 3 – Amazon API Gateway マッピングテンプレート Amazon Managed Service for Apache Flink によるストリーミングデータの処理 前のセクションで説明したように、データストリームに送信するすべてのメッセージには、tenantId というパーティションキーがあります。このパーティションキーの値は、メッセージを処理するシャードに影響を与えます。 各 Kinesis ストリームには1つ以上のシャードがあり、シャード数は Kinesis が処理できるデータ量 に直接影響します。 パーティションキーによってはホットシャードを引き起こし、ストリームのパフォーマンスに影響を与える可能性があることに気を付けてください。 データストリームによってメッセージが処理されると、Amazon Managed Service for Apache Flink を使用して、データのさらなる分析を行います。このサービスを使用すると、Java のようなプログラミング言語を使用して、ストリーミングデータを処理および分析できます。 サンプルソリューションでは、データが次のサービスに転送される前に、Flink ジョブを使用してメッセージを追加のフィールドで拡張しています。 図 4 の実装で見られるように、Flink ジョブには inputStreamName があり、これはデータの送信元を示しています。今回の場合は Kinesis Data Stream です。 上述のとおり、Flink ジョブはメッセージを Amazon Data Firehose 配信ストリームにプッシュする前に、tenantId の追加属性とタイムスタンプフィールドも追加します。 図 4 – Amazon Managed Service for Apache Flink – InputStream と FirehoseOutputStream の設定 また、下記の図 5 のコードに示すように、TenantId フィールドはメッセージが Amazon S3 のどのパスに配置されるかを示すために使用され、タイムスタンプは Flink ジョブがメッセージを処理した正確な時刻を反映します。 図 5 – Flink ジョブでのtenantId の設定 Amazon Data Firehose を使用したデータ配信 サンプルソリューションでは、サービスごとのテナント分割モデルを使用してスケールを向上させるために、Amazon Data Firehose を利用してメッセージを S3 に配信しています。これは特に、SaaS システムに多数のテナントがある場合に効果的です。 Flink では、Flink ジョブから直接メッセージを S3 に配信できます。 しかし、データを Amazon Data Firehose に送信することで、このソリューションを将来的に拡張できる柔軟性が得られます。例えば、 Amazon Redshift 、 Amazon OpenSearch Service などの その他の送信先 や、その他のモニタリングソリューションをサポートできるようになります。 図 6 – Amazon Kinesis Data Firehose デリバリーストリーム 図 6 に示すように、配信ストリーム delivery-multi-tenant-firehose-stream は動的パーティショニング機能を利用しています。これにより、データ内のキーを使用して、Data Firehose のストリーミングデータをパーティション分割することができます。 図 7 – tenantId と timestamp を使用した動的パーティショニング キーは、対応するテナントの S3 プレフィックス位置に配信される前のデータのグループ化に用いられます。図 7 に示すように、動的パーティショニングを実装するために、入力メッセージの一部であったフィールド tenantId と timestamp を使用しました。S3 プレフィックスの一部として tenantId があることで、データの消費時に S3 のテナント分離戦略の一部として使用できる IAM ポリシー を作成できます。 最後に、S3 へのデータ配信のために、Amazon Data Firehose は、配信ストリームのバッファリング設定に基づいて、複数の入力レコードを連結します。 S3 へのデータ配信の頻度は、配信ストリームの S3 バッファサイズとバッファ間隔の値によって決まります。 こちらの詳細は、 AWS ドキュメント で確認できます。 結論 この投稿では、AWS のサービスを使用してマルチテナントのデータ取り込みと処理エンジンを構築する方法を探りました。 このデータパイプラインの各コンポーネントと、SaaS のマルチテナントデータ取り込みプロセスの設計アプローチに影響を与える可能性のあるいくつかの主な考慮事項を検討しました。 また、AWS サービスを使用して、マルチテナントのストリーミングデータをどのようにインジェスト、変換、ストレージできるかを確認しました。その際、データの安全な処理を保証するために、パイプラインに構築物が組み込まれていることも確認しました。 ここで紹介したサンプルアプリケーションを掘り下げていくと、AWS 上に完全な実働ソリューションを構築する上でのエンドツーエンドの全体的な体験がよりよく理解できるようになるでしょう。 これにより、SaaS データ取り込みプロセスのニーズと整合性のあるポリシーの周りを形作ることができる一方で、良い出発点を提供するはずです。 このソリューションのより詳細な概要については、環境のすべての動的な要素を理解するのに役立つ段階的なデプロイ手順が記載されている GitHub リポジトリをご覧いただければと思います。 AWS SaaS ファクトリーについて AWS SaaS Factory は、SaaSの旅路にあるどの段階の組織でも支援します。新しい製品の構築、既存アプリケーションの移行、AWS 上での SaaS ソリューションの最適化など、様々なニーズに対応できます。より多くの技術的、ビジネス的なコンテンツやベストプラクティスを知るには、 AWS SaaS Factory Insights Hub をご覧ください。 SaaS ビルダーは、エンゲージメントモデルについて問い合わせたり、AWS SaaS Factory チームと連携するために、アカウント担当者に連絡することをお勧めします。 こちらに 登録して、 AWS 上の最新の SaaS のニュース、リソース、イベントについて通知を受け取ることができます。 翻訳はソリューションアーキテクトの福本が担当しました。原文は こちら です。 なお、翻訳版では Amazon Kinesis Data Analytics と Amazon Kinesis Data Firehose の名前変更に伴い、それぞれ Amazon Managed Service for Apache Flink、Amazon Data Firehose と表記しています。 https://aws.amazon.com/jp/about-aws/whats-new/2023/08/amazon-managed-service-apache-flink/ https://aws.amazon.com/jp/about-aws/whats-new/2024/02/amazon-data-firehose-formerly-kinesis-data-firehose/

レジリエンスは、あらゆるワークロードの開発において重要な役割を果たしており、 生成 AI ワークロードも例外ではありません。生成 AI ワークロードを開発する際には、レジリエンスの観点における独自の考慮事項があります。組織の可用性と事業継続性の要件を満たすためには、レジリエンスを理解し、優先順位を付けて対応することが不可欠です。本ブログ記事では、生成 AI ワークロードを構成する各スタックとそれらの考慮事項について説明します。 生成 AI ワークロードを構成するスタック 生成 AI の魅力の多くがモデルに焦点を当てていますが、完全なソリューションには複数分野の人材、スキル、ツールが必要です。次の図は、 a16z （Andreessen Horowitz）が公開している大規模言語モデル (LLM) を利用した新しいアプリケーションスタックを AWS の視点で捉えたものです。 従来の AI や機械学習 (ML) を中心としたソリューションと比較すると、生成 AI ソリューションには以下が含まれていることが分かります。 新しいロール – モデルチューナーだけでなく、モデルの開発元やモデルインテグレーターの役割も考慮する必要があります 新しいツール – 従来の MLOps スタックは、プロンプトエンジニアリングやエージェント（他のシステムと対話するツールを呼び出す）に必要な実験の追跡やオブザーバビリティに対応していません 検索拡張生成 (RAG) 従来の AI モデルとは異なり、RAG は外部ナレッジソースを統合することで、より正確でコンテキストに関連したレスポンスを可能にします。RAG を使用する際の考慮事項は以下のとおりです。 外部ナレッジソースからのデータ取得に適切なタイムアウトを設定することは、顧客体験にとって重要です。チャットの最中に切断されることほど、ユーザー体験を損なうものはありません。 プロンプトへの入力データが、利用するモデルのトークン数制限内であることを検証してください。 プロンプトを信頼できるデータストアに保存してください。万が一プロンプトを紛失した場合やディザスタリカバリ戦略の一環として、プロンプトを保護できます。 データパイプライン RAG パターンを使用して基盤モデルにコンテキストデータを提供する場合、ソースデータを取り込み、埋め込みベクトルに変換し、ベクトルデータベースに保存できるデータパイプラインが必要です。コンテキストデータを事前に準備している場合はバッチパイプラインになります。新しいコンテキストデータを逐次取り込む場合は低レイテンシパイプラインとなります。バッチパイプラインの場合、一般的なデータパイプラインと比較して、いくつかの課題があります。 データソースには、ファイルシステム上の PDF ドキュメント、CRM ツールのような SaaS (Software as a Service) からのデータ、既存の Wiki やナレッジベースなどが考えられます。これらのソースからの取り込みは、 Amazon S3 (Amazon Simple Storage Service) 上のログデータやリレーショナルデータベースにある構造化データなどの一般的なデータソースからの取り込みとは異なり、並列処理のレベルがソースシステムによって制限される可能性があるため、スロットリングを考慮し、バックオフ手法を使用する必要があります。また、ソースシステムの一時的な障害等に備えて、エラー処理とリトライロジックを組み込む必要があります。 埋め込みモデルは、パイプライン内でローカルに実行するか外部モデルを呼び出すかに関わらず、パフォーマンスのボトルネックになる可能性があります。埋め込みモデルは主に GPU 上で実行される基盤モデルであり、そのキャパシティは有限です。モデルをローカルで実行する場合は、GPU 容量に基づいてタスクを割り当てる必要があります。モデルを外部で実行する場合は、外部モデルが飽和状態にならないようにする必要があります。いずれの場合も、達成できる並列度は、バッチパイプラインが利用できる CPU や RAM の量ではなく、埋め込みモデルによって決定されます。 低レイテンシパイプラインの場合、埋め込みベクトルの生成時間を考慮してください。アプリケーションは低レイテンシパイプラインを非同期で呼び出す必要があります。 ベクトルデータベース ベクトルデータベースには 2 つの機能があります。埋め込みベクトルの保存および、あるベクトルに対して最も近い k 個のマッチングを見つける類似検索を実行することです。また、ベクトルデータベースには大きく分けて次の 3 つのタイプがあります。 Pinecone 等のベクトルデータベース専用 SaaS 製品やサービスに組み込まれたベクトルデータベース機能（ Amazon OpenSearch Service や Amazon Aurora などの AWS サービスも含まれる） 一時データに使用できるインメモリデータベース（低レイテンシが要求されるシナリオ） 本ブログ記事では、類似性検索機能の詳細については説明しません。これらは重要ですが、システムの機能的な側面であり、レジリエンスに直接影響を与えないためです。その代わり、ストレージシステムとしてのベクトルデータベースのレジリエンスの側面に焦点を当てます。 レイテンシ – 高負荷や予測不可能な負荷に対してもパフォーマンスを発揮できますか。そうでない場合、アプリケーションはレート制限やバックオフ、リトライ処理を行う必要があります。 スケーラビリティ – いくつベクトルを保持できますか。ベクトルデータベースの容量を超える場合、シャーディングや他のソリューションを検討する必要があります。 高可用性とディザスタリカバリ – ベクトルデータベースは、単一のリージョンで高可用性を実現していますか。別のリージョンにデータをレプリケートして災害復旧目的で使用できますか。埋め込みベクトルは貴重なデータであり、再生成にはコストがかかります。 アプリケーション 生成 AI ソリューションの統合において、アプリケーションには、3 つの固有の考慮事項があります。 高いレイテンシの可能性 – 基盤モデルは大きな GPU インスタンス上で実行されることが多いため、GPU 容量が確保できない可能性があります。レート制限、バックオフとリトライ、負荷制限のベストプラクティスを使用してください。高いレイテンシがアプリケーションのメインインターフェースに干渉しないように、非同期処理を利用した設計にします。 セキュリティ態勢 – エージェント、ツール、プラグイン、その他の方法を使用してモデルを他のシステムに接続している場合は、セキュリティ態勢に特に注意を払います。モデルはこれらのシステムと予想外の方法でやりとりしようとする可能性があります。たとえば、他のシステムからのプロンプトの受信を制限するなど、標準的なプラクティスである最小特権のアクセス許可に従ってください。 急速に進化するフレームワーク – LangChain のようなオープンソースフレームワークは急速に進化しています。このような成熟度の低いフレームワークから他のコンポーネントを分離するために、マイクロサービスアプローチを使用します。 キャパシティ キャパシティは、推論とトレーニングモデルのデータパイプラインという 2 つのコンテキストで考えることができます。組織が独自のパイプラインを構築する際にキャパシティが考慮事項となります。ワークロードを実行するインスタンスを選択する際、CPU とメモリが最大の要件の 2 つです。 生成 AI ワークロードをサポートできるインスタンスは、汎用インスタンスタイプよりも入手が難しい場合があります。インスタンスの柔軟性は、キャパシティとキャパシティプランニングに役立ちます。使用可能なインスタンスタイプはリージョンによって異なります。 重要なユーザージャーニーの場合、インスタンスタイプを予約または事前プロビジョニングし、必要なときに利用できるよう検討してください。このパターンにより、レジリエンスのベストプラクティスである静的に安定したアーキテクチャが実現できます。AWS Well-Architected Framework の信頼性の柱における静的安定性の詳細については、 静的安定性を使用してバイモーダル動作を防止する を参照してください。 オブザーバビリティ Amazon SageMaker や Amazon Elastic Compute Cloud (Amazon EC2) 上でモデルをホストする場合は、通常収集するリソースメトリクスである CPU や RAM の使用率に加えて GPU の使用率も注意深く監視します。基盤モデルや入力データが変更されると、GPU 使用率が予期せず変化する可能性があります。GPU メモリが不足するとシステムが不安定な状態になる可能性があります。 スタックの上位では、システム内の呼び出しの流れをトレースして、エージェントとツール間の対話をキャプチャすることも重要です。エージェントとツール間のインターフェースは API コントラクトほど正式に定義されていないため、パフォーマンスのみならず、新しいエラーシナリオを捉えるためにもこれらのトレースを監視する必要があります。モデルやエージェントのセキュリティリスクや脅威を監視するために、 Amazon GuardDuty などのツールを使用できます。 埋め込みベクトル、プロンプト、コンテキスト、出力のベースラインとこれらの間の相互作用もキャプチャする必要があります。これらが時間とともに変化する場合、ユーザーがシステムを新しい方法で使用している、コンテキストに渡す参照データが想定問答をカバーできていない、またはモデルの出力が突然変化したことを示している可能性があります。 ディザスタリカバリ 事業継続計画とディザスタリカバリ戦略を策定することは、どのワークロードにとっても必須です。生成 AI ワークロードも例外ではありません。ワークロードに適用可能な障害モードを理解することで、戦略の指針となります。 Amazon Bedrock や SageMaker などの AWS マネージドサービスを使用している場合は、そのサービスが復旧用の AWS リージョンで利用可能であることを確認してください。本ブログ記事の執筆時点では、これらの AWS サービスはリージョン間のデータレプリケーションをネイティブでサポートしていないため、ディザスタリカバリのためのデータ管理戦略を検討する必要があります。また、災害時にファインチューニングされたカスタムモデルを利用したい場合、複数のリージョンにおいてファインチューニングを行っておく必要があります。 まとめ 本ブログ記事では、生成 AI ソリューションを構築する際にレジリエンスを考慮する方法について説明しました。生成 AI アプリケーションにはいくつか興味深いニュアンスがありますが、既存のレジリエンスパターンとベストプラクティスは依然として適用できます。あとは、生成 AI アプリケーションの各スタックを評価し、関連するベストプラクティスを適用することが重要です。 生成 AI と AWS サービスでのその利用に関する詳細は、次のリソースを参照してください。 Securing generative AI: An introduction to the Generative AI Security Scoping Matrix Guardrails for Amazon Bedrock は、お客様のユースケースと責任ある AI ポリシーに合わせてカスタマイズされたセーフガードの実装に役立ちます (プレビュー版) Llama Guard is now available in Amazon SageMaker JumpStart 著者について Jennifer Moran は、ニューヨークを拠点とする AWS シニアレジリエンシーソリューションアーキテクトです。ソフトウェア開発、アジャイルリーダーシップ、DevOps など、多岐にわたる技術分野で働いた経験を持っています。顧客のレジリエンス向上とその重要性について公に発信することを楽しんでいます。 Randy DeFauw は、AWS シニアプリンシパルソリューションアーキテクトです。ミシガン大学で自動運転車両のコンピュータビジョンについて研究し、電気電子工学の修士号を取得しています。また、コロラド州立大学で MBA を取得しています。Randy はソフトウェアエンジニアリングから製品管理まで、テクノロジー分野のさまざまなポジションを歴任してきました。2013 年にビッグデータ分野に参入し、その分野を探索し続けています。機械学習分野のプロジェクトに積極的に取り組んでおり、Strata や GlueCon など、数多くのカンファレンスでプレゼンテーションを行っています。 翻訳は Solutions Architect 北川が担当しました。原文は こちら です。

多くの AWS のお客様は、アーキテクチャをモダナイズし、オープンソースデータベースに移行し始めています。 Babelfish for Aurora PostgreSQL を使用すると、SQL Server から Amazon Aurora PostgreSQL Compatible エディション へのアプリケーションの移行が容易になります。Babelfish では、Aurora PostgreSQL Compatible は一般的に使用される T-SQL 言語とセマンティクスをサポートするため、アプリケーション内のデータベース呼び出しに関連するコード変更の量を減らすことができます。 この投稿では、 AWS Database Migration Service (AWS DMS) を使用したデータ移行を含め、Microsoft SQL Server データベースを Babelfish に移行する方法を示し、移行には SQL Server Northwind サンプルデータベース を使用します。さらに、いくつかの一般的な問題とその解決方法についても検討します。 Babelfish 概要 段階的な移行プロセスを説明する前に、Babelfish のアーキテクチャを見てみましょう。Babelfish は、T-SQL コードやクライアントの接続ドライバーへの変更を最小限に抑えて SQL Server アプリケーションを Aurora PostgreSQL Compatible に移行するための移行アクセラレーターです。これにより、ライセンスを取得した独自のオンプレミスデータベースマネージメントシステム (DBMS) からクラウド内のオープンソース DBMS への移行が可能になり、モダナイゼーションへの道が開けます。 Babelfishは、PostgreSQL が SQL Server 用に作成されたアプリケーションからのクエリを理解する機能を提供します。Babelfish は SQL Server ワイヤプロトコルと SQL Server のクエリ言語である T-SQL を理解しているので、データベースドライバを切り替えたり、アプリケーションクエリをすべて書き直したりする必要はありません。次の図に示すように、SQL Server 接続ライブラリを使った TDS 接続と標準の PostgreSQL 接続を作成できます。 Babelfish の利点は次のとおりです。 既存のクエリを保持 – 言語拡張により Aurora PostgreSQL Compatible で T-SQL と連携できるようになります。 移行を加速 – 移行をより早く完了できるため、数か月から数年の作業を節約できます。 イノベーションの自由 – T-SQL コードをオープンソースの機能と並行して実行し、使い慣れたツールを使用して開発を続けることができます。 ソリューション概要 Babelfish へのマイグレーションの大まかな手順は次のとおりです。 DDL を生成し、 Babelfish Compass ツールを使用して分析を実行します。DDL は次のオプションを使用して生成できます。 SQL Server Management Studio (SSMS) を使用してデータベーススキーマをエクスポートする。 Babelfish Compass v.2023-08 以降では、分析が必要な SQL Server データベースの DDL 生成を Compass がオプションで直接実行することも可能。 Babelfish extension を使用して Aurora PostgreSQL インスタンスを作成します。 ポート 1433 に対して DDL スクリプトを実行して、Babelfish のスキーマを再作成します。 AWS DMS を使用して SQL Server から Babelfish にデータを移行し、SQL Server ではなく Babelfish TDS ポートに接続するようにクライアントアプリケーションを再設定します。 バックエンドが Babelfish である .NET アプリケーションの場合、アプリケーションコードを変更する必要はほとんどありません。 Babelfish でサポートされていない機能 については、アプリケーションコードを変更する必要があります。 以下のセクションでは、SQL Server から Babelfish for Aurora PostgreSQL に移行するためのステップバイステップの詳細を説明します。 Babelfish Compass アセスメントツール Babelfish Compass は、Windows、Mac、Linuxで動作し、Babelfish との互換性を評価するスタンドアロンツールです。このツールは DDL コードと SQL コードを調べ、サポートされている機能とサポートされていない機能をすべて一覧表示した詳細なレポートを提供します。 Babelfish Compass をインストールして実行するには、次の手順を実行してください。 Babelfish Compass の最新バージョン (.zip ファイル) を GitHub からダウンロードしてください。 ファイルを必要なフォルダに解凍します。このフォルダーには 3 つの zip ファイルがあります。 BabelfishCompass_V.2023-08.zip というファイルを解凍する必要があります。 Babelfish Compass には 64 ビット Java/JRE 8 以降が必要です。Compass レポートを実行する前にインストールする必要があります。 CMD (Windows) を開き、zip ファイルを解凍したパスに移動します。 インストールを確認するには、 -help オプションを指定して BabelfishCompass を実行します。 BabelfishCompass -help Bash Northwind データベースの Compass レポートの生成 Compass ツール機能を使用して、Compass v.2023-08 以降で DDL を生成します。このオプションは、SQL Server に多数の SQL Server インスタンスまたはデータベースが存在する場合に便利です。Compass に DDL 生成を実行させるには、次のコマンドラインオプションを指定する必要があります。その後、Compass は SQL Server に接続して DDL ファイルを生成し、生成されたファイルに対して Compass 解析を実行します。 -sqlendpoint – SQL Server のホスト名または IP アドレス。オプションでポート番号を指定することもできます (たとえば、10.123.45.67,1433 や mybigbox,1433)。 -sqllogin – SQL Server に接続するためのログイン名。DDL を生成する権限を得るには、通常、このログインが sysadmin ロールのメンバーである必要があります。 -sqlpasswd – 対応するパスワード。 -sqldblist – これはオプションです。省略するか、all を指定すると、サーバー内のすべてのユーザーデータベースに DDL が生成されます。あるいは、データベース名をコンマで区切ったリストを指定することもできます。 DDL 生成の速度は、SQL Server とのネットワーク上の距離に大きく依存します。時間がかかりすぎる場合は、 CTRL+C を使用してプロセスをキャンセルし、SSMS を使用して手動で DDL 生成を行うと、処理が速くなる場合があります。 BabelfishCompass Northwind-report5 -sqlendpoint < endpoint > -sqllogin < login > -sqlpasswd < password > -sqldblist Northwind -optimistic -reportoptions xref -rewrite Bash 上記のスクリプトは、Babelfish compass レポートを生成し、デフォルトではユーザーの Documents\\ BabelfishCompass フォルダーに保存されます。また、このスクリプトは、指定したデータベースごとに個別の DDL ファイルを生成し、以下のスクリーンショットのようにコンピュータの TEMP ディレクトリに保存します。 compass レポートを生成する他のオプションは、最初に SSMS を使用して DDL を生成し、Babelfish compass コマンドを実行してレポートを生成することです。詳細については、「 Babelfish Compass を Deep Dive する 」を参照してください。 結果の分析 移行作業全体を評価するには、最初にレポートの上部にある概要セクションを確認することです。このセクションには、オブジェクトの数と SQL コードの行数が報告されています。これにより、アプリケーションがどれほど大きく、どれだけの労力が必要かがひと目でわかります。 --- Report Setup --------------------------------------------------------------- BabelfishFeatures.cfg file : v.3.2.0, Jun-2023 Target Babelfish version : v.3.2.0 (PG 15.3) Command line arguments : Northwind-report SMOTest -sqlendpoint ****** -sqllogin **** -sqlpasswd ******** -sqldblist Northwind DDL input files : Northwind_SMO_DDL_2023-Aug-10.sql DDL input files location : C:\Users\ADMINI~1\AppData\Local\Temp\2\CompassAutoDDL-2023-Aug-10-01.36.40 User .cfg file (overrides) : C:\Users\Administrator\Documents\BabelfishCompass\BabelfishCompassUser.cfg Report name : Northwind-report This report : C:\Users\Administrator\Documents\BabelfishCompass\Northwind-report\report-Northwind-report-bbf.3.2.0-2023-Aug-10-01.37.18.html Session log : log\session-log-Northwind-report-bbf.3.2.0-2023-Aug-10-01.36.40.html ================================================================================ -------------------------------------------------------------------------------- --- Executive Summary for Babelfish v.3.2.0 ------------------------------------ -------------------------------------------------------------------------------- Total #lines of SQL/DDL: 1272 #Procedures/functions/triggers/views: 23 #Tables: 13 SQL features not supported by Babelfish : 127 Estimated complexity of not-supported features: medium:127 -------------------------------------------------------------------------------- -------------------------------------------------------------------------------- --- Applications Analyzed (1) -------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents Northwind (1272 lines SQL) -------------------------------------------------------------------------------- --- Assessment Summary --------------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents #applications : 1 #input files : 1 #SQL batches : 350 #lines SQL/DDL processed : 1272 #lines SQL in objects : 208 (procedures/functions/triggers/views) total #SQL features : 1208 Supported : 750 Not Supported : 0 Review Semantics : 45 Ignored : 413 Overridden by user .cfg file (C:\Users\Administrator\Documents\BabelfishCompass\BabelfishCompassUser.Optimistic.cfg): Ignored (was: Not Supported) : 129 -------------------------------------------------------------------------------- --- Object Count --------------------------------------------------------------- -------------------------------------------------------------------------------- Back to Table of Contents DATABASE : 1 LOGIN : 51 PROCEDURE : 7 (72 lines SQL) without issues: 7 of 7: list TABLE : 13 (144 columns) without issues: 13 of 13: list VIEW : 16 (136 lines SQL) without issues: 16 of 16: list constraint CHECK : 8 constraint FOREIGN KEY : 13 constraint PRIMARY KEY : 13 index : 26 user-defined datatype (UDD), scalar : 3 HTML 次に、「Not Supported（サポート対象外）」、「Review Manually（手動レビュー）」、「Review Semantics(セマンティクスの確認）」、「Review Performance（パフォーマンスの確認）」、「Ignored（無視）」の「SQL 機能の概要」セクションに着目します。 問題に基づいて、考えられる回避策を開発するか、移行されたアプリケーションに必要のない機能をスケールダウンして移行のスコープを狭めます。移行のスコープを狭めるには、開発者とアプリケーションオーナーの協力が必要です。コマンドで Optimistic オプションを使用すると、一部のコマンドが Not Supported ではなく Ignored の下に一覧表示されます。 Optimistic オプションなしでレポートを生成すると、以下の機能はサポート対象外としてレポートされます。最適化オプションで無視された機能は、アプリケーションを移行する目的では通常は無視できます。 Optimistic オプションを使用して Northwind スキーマの compass レポートを生成する場合、サポートされていない機能はないことに注意してください。 -------------------------------------------------------------------------------- --- SQL features 'Ignored' in Babelfish v.3.2.0 --- (total=413) ---------------- -------------------------------------------------------------------------------- Back to Table of Contents DDL (286/14) Option ALLOW_PAGE_LOCKS=ON, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ALLOW_PAGE_LOCKS=ON, Index, in CREATE INDEX : 26 Option ALLOW_ROW_LOCKS=ON, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ALLOW_ROW_LOCKS=ON, Index, in CREATE INDEX : 26 Option DROP_EXISTING=OFF, Index, in CREATE INDEX : 26 Option IGNORE_DUP_KEY=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option ONLINE=OFF, Index, in CREATE INDEX : 26 Option OPTIMIZE_FOR_SEQUENTIAL_KEY=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option OPTIMIZE_FOR_SEQUENTIAL_KEY=OFF, Index, in CREATE INDEX : 26 Option PAD_INDEX=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option PAD_INDEX=OFF, Index, in CREATE INDEX : 26 Option SORT_IN_TEMPDB=OFF, Index, in CREATE INDEX : 26 Option STATISTICS_NORECOMPUTE=OFF, constraint PRIMARY KEY, in CREATE TABLE : 13 Option STATISTICS_NORECOMPUTE=OFF, Index, in CREATE INDEX : 26 Permissions (39/2) ALTER AUTHORIZATION ON object TO SCHEMA OWNER : 36 ALTER AUTHORIZATION ON TYPE TO SCHEMA OWNER : 3 Users (88/4) ALTER SERVER ROLE processadmin ADD MEMBER : 1 ALTER SERVER ROLE setupadmin ADD MEMBER : 1 Login option CHECK_EXPIRATION, in CREATE LOGIN : 43 Login option CHECK_POLICY, in CREATE LOGIN : 43 HTML Babelfish for Aurora PostgreSQL クラスターの生成 Babelfish クラスターの作成は Aurora PostgreSQL クラスターの作成とほぼ同じです。Babelfish for Aurora PostgreSQL は Aurora PostgreSQL バージョン 13.4 以降でサポートされているため、サポートされているバージョンを選択して Babelfish の設定セクションで「Babelfish をオンにする」にチェックします。 Babelfish クラスターを作成するときは、移行された単一の T-SQL ユーザーデータベースを使用するか、移行した複数の T-SQL ユーザーデータベースを一緒に使用するかを選択します。 single-db を指定した場合、Babelfish では 1 つの T-SQL データベースしか作成できず、T-SQL スキーマは Babelfish データベースでは通常の PostgreSQL スキーマとして作成されます。マルチデータベースモードでは、PostgreSQL からアクセスすると、ユーザーデータベースのスキーマ名は dbname_schemaname になります。T-SQL からアクセスするとスキーマ名は同じままです。詳細については、「 1 つのデータベースまたは複数のデータベースでの babelfish の使用 」を参照してください。 Babelfish クラスター内の複数の T-SQL ユーザーデータベースがサポートされるため、移行モードには multi-db を使用することをお勧めします。クラスターの作成後にこの値を変更することはできないため、最初は T-SQL ユーザーデータベースが 1 つしか必要ない場合でも柔軟性を持たせたほうがよいです。 SQL Server に近い状態にしておくために、プライマリユーザー名として sa を選択できます。 Babelfish クラスターを作成すると、リーダーとライターという 2 つのエンドポイントが提供され、異なるポートで PostgreSQL と T-SQL の両方がサポートされます。 Babelfish クラスターへの接続 次のステップは、Babelfish クラスターとの接続を確立し、SQL Server Management Studio (SSMS) を使用して新しいデータベースにスキーマを作成することです。SSMS は SQL Server に接続するための GUI ベースのクライアントツールで、オブジェクトエクスプローラーによるオブジェクトの表示とスクリプト作成は限定的にサポートされています。 Babelfish エンドポイントクラスターと認証情報を入力し、[接続] を選択します。 SSMS で DDL スクリプトを実行する Babelfish のスキーマの再作成 Babelfish でスキーマを再作成するには、以下の手順に従ってください。 次のクエリを使用して、Babelfish と Aurora PostgreSQL のバージョンを確認してください。 -- Check your version SELECT SERVERPROPERTY ( 'babelfishversion' ) AS BabelfishVersion , aurora_version ( ) AS AuroraPostgreSQLVersion , @ @VERSION AS ClassicSQLServerVersion GO SQL Babelfish のエスケープハッチを無視するように設定 – Babelfish は可能な限り、制御フローとトランザクション状態の SQL 動作を模倣します。Babelfish はエラーに遭遇すると、SQL Server のエラーコードと同様のエラーコードを返します。失敗する可能性のあるステートメントを処理するために、Babelfish ではエスケープハッチと呼ばれる特定のオプションを定義しています。エスケープハッチは、サポートされていない機能や構文に遭遇したときの Babelfish の動作を指定するオプションです。以下のステートメントを使用して、すべてのエスケープハッチが厳密な動作を無視するように設定します。 EXECUTE sp_babelfish_configure '%' , 'ignore' , 'server' ; GO SQL Northwind データベースを作成し、T-SQL カタログビューを使用して検証します。 -- T-SQL catalog views to display databases SELECT * FROM sys . databases ; GO SQL -- T-SQL catalog views to display databases SELECT * FROM sys . databases ; GO SQL Babelfish と PostgreSQL 間のスキーママッピングを確認してください。この情報は、データロード用の DMS タスクを作成するのに役立ちます。 SELECT pg . dbname AS BabelfishDBName , be . orig_name AS SchemaName , pg . nspname AS PGSchemaNameForDMS , pg . oid , SCHEMA_ID ( be . orig_name ) AS MapsToPGOID FROM sys . pg_namespace_ext AS pg INNER JOIN sys . babelfish_namespace_ext AS be ON pg . nspname = be . nspname WHERE dbname = DB_NAME ( ) ORDER BY SchemaName ; SQL Babelfish クラスターに選択した multi-db または single-db 構成に応じて、異なる結果が表示されます。これは、PostgreSQL がこれらのオプションごとにデータベース名とスキーマ名を内部的に異なる方法でマッピングするためです。 multi-db の Babelfish クラスターの結果: single-db の Babelfish クラスターの結果: 完成したスクリプトを実行して、Babelfish でスキーマオブジェクトを作成します。 Babelfish は現在、DMS での BYTEA データ型を使用したバイナリ、VARBINARY、および IMAGE データ型の移行をサポートしています。Northwind データベーススクリプトを変更して、任意の IMAGE データ型を BYTEA に変更してください。元の Northwind データベースでは、カテゴリテーブルの Picture 列は IMAGE データ型を使用し、Employee テーブルの Photo 列は IMAGE データ型を使用します。最後のスクリプトでは、以下のように検索して置換します。 [ image ] with [ bytea ] /* [ image ] */ Bash テーブルにプライマリキーとユニークキーのみを使用してスクリプトを実行すると、データロードプロセスが高速化され、データロードプロセスが終了したら追加のインデックスと制約を作成できます。 以下のスクリプトを使用して、前のステップで作成したテーブルを検証します。 --using T-SQL view SELECT * FROM sys . tables ; SQL AWS DMS を使用した SQL Server から Babelfish へのデータ移行 AWS DMS バージョン 3.5.1 では、Babelfish マイナーバージョン 14.8 および 15.3 以降の Aurora PostgreSQL のサポートデータタイプのサポートが強化されています。SQL Server ソースエンドポイントと Aurora PostgreSQL ターゲットエンドポイントで DMS の使用を開始する方法は次のとおりです。 AWS DMS コンソールで、ワークロードに応じてインスタンスのサイズを選択して レプリケーションインスタンスを作成 します。 ソースエンドポイントとターゲットエンドポイント を作成します。 ソースエンドポイント – ソースエンドポイントは SQL Server を指している必要があります。 ターゲットエンドポイント – Aurora PostgreSQL ターゲットエンドポイント は Babelfish にデータを移行するための推奨方法です。AWS DMS コンソール、API、または CLI コマンドを使用して AWS DMS ターゲットエンドポイントを作成するときは、次の点に注意してください。 ターゲットエンジンを Amazon Aurora PostgreSQL として指定します。 データベースに babelfish_db という名前を付けます。 エンドポイント設定セクションで、 DatabaseMode を Babelfish に、 BabelfishDatabaseName をターゲットの Babelfish T-SQL データベースの名前に指定した設定を追加します。マイナーバージョン 15.3 および 14.8 より前の Aurora PostgreSQL で Babelfish を使用している場合は、これらのエンドポイント設定を使用しないでください。 レプリケーションタスクを作成 して開始し、ターゲットデータベースに指定されたテーブルのデータをロードします。AWS DMS エンドポイントとしての Babelfish の詳細については、「 AWS Database Migration Service のターゲットとしての Babelfish の使用 」を参照してください。 Northwind データベースを移行するためのタスク設定は次のとおりです。 ターゲットテーブルの準備 -「何もしない」。このモードでは、AWS DMS はターゲットデータベースを変更しません。Babelfish 3.2.0 および 2.5.0 リリースの DMS 3.5.1 の新機能を活用するには、フル LOB モードを選択する必要があります。 テーブルマッピングルール – スキーマ名が ‘dbo’、ソーステーブル名が ‘%’ のような dbo スキーマのすべてのテーブル、またはソース SQL Server データベースの特定のテーブルを含めるには、次のルールを追加します。 変換ルール – multi-db または single-db 構成に応じて必要な変換ルールは次のとおりです。 multi-db モードを使用する場合は、お使いの PostgreSQL スキーマである northwind_dbo と一致するように dbo スキーマの名前を変更してください。 どちらのモードでも、テーブルの名前を小文字に変更します。以下のスクリーンショットは変換ルールを示しています。 テーブル統計を確認して、データのロードを確認します。DMS レプリケーションタスクが正常に完了すると、テーブル統計を表示できます。 あるいは、データベースにクエリを実行してデータを検証することもできます。 SELECT TOP 10 * FROM categories ORDER BY [ CategoryID ] SQL BYTEA データ型を IMAGE に戻す – ほとんどのアプリケーションは BYTEA で正常に動作しますが、IMAGE に戻す必要がある場合は、以下のスクリプトを使用して IMAGE データ型の新しい列を追加、その列にデータをコピーしてから元の列を削除し、最後に元の列名と一致するように名前を変更します。 ALTER TABLE [ dbo ] . [ Categories ] ADD [ PictureImage ] IMAGE NULL ; UPDATE [ dbo ] . [ Categories ] SET [ PictureImage ] = [ Picture ] ; SELECT [ CategoryID ] , CASE WHEN CAST ( [ Picture ] AS Image ) = [ PictureImage ] THEN 'Match' ELSE 'No Match' END AS [ Compare ] FROM [ dbo ] . [ Categories ] ; ALTER TABLE [ dbo ] . [ Categories ] DROP COLUMN [ Picture ] ; -- Rename column EXEC sp_rename 'categories.pictureimage' , 'Picture' , 'COLUMN' ; SQL DMS からデータを読み込んだ後、IDENTITY 列をリセットします。SQL Server では、IDENTITY 列を主キーに使用したり、値の自動インクリメントが必要なその他の列を使用したりするのが一般的です。IDENTITY 列または SERIAL データ型を使用するテーブルを含むデータを移行したら、以下のスクリプトを使用して列の最大値に基づいて PostgreSQL ベースのシーケンスオブジェクトをリセットします。 -- following T-SQL query to generate statements to seed the associated sequence object. USE Northwind ; GO DECLARE @schema_prefix NVARCHAR ( 200 ) = '' IF current_setting ( 'babelfishpg_tsql.migration_mode' ) = 'multi-db' SET @schema_prefix = db_name ( ) + '_' SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + schema_name ( tables . schema_id ) + '.' + tables . name + ''', ''' + columns . name + ''') ,(select max(' + columns . name + ') from ' + schema_name ( tables . schema_id ) + '.' + tables . name + '));' FROM sys . tables tables JOIN sys . columns columns ON tables . object_id = columns . object_id WHERE columns . is_identity = 1 UNION ALL SELECT 'SELECT setval(pg_get_serial_sequence(''' + @schema_prefix + table_schema + '.' + table_name + ''', ''' + column_name + '''),(select max(' + column_name + ') from ' + table_schema + '.' + table_name + '));' FROM information_schema . columns WHERE column_default LIKE 'nextval(%' ; SQL 次のステートメントは、前のクエリによって生成されます。Northwind データベースに対して実行してください。 -- Generated statements SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.categories' , 'categoryid' ) , ( select max ( categoryid ) from dbo . categories ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.employees' , 'employeeid' ) , ( select max ( employeeid ) from dbo . employees ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.orders' , 'orderid' ) , ( select max ( orderid ) from dbo . orders ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.products' , 'productid' ) , ( select max ( productid ) from dbo . products ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.shippers' , 'shipperid' ) , ( select max ( shipperid ) from dbo . shippers ) ) ; SELECT setval ( pg_get_serial_sequence ( 'northwind_dbo.suppliers' , 'supplierid' ) , ( select max ( supplierid ) from dbo . suppliers ) ) ; SQL SSMS のスクリプト生成ウィザードを使用して、次のように作成スクリプトを再生成します。 データベーステーブルだけのスクリプトを作成して、チェック制約、インデックス、トリガーなどを別のファイルに含めます。テーブルはすでに移行されているので、テーブル作成セクションをコメントアウトしてください。最終的なスクリプトには、インデックス、制約、トリガーのみを含める必要があります。Babelfish クラスター内の Northwind データベースに対してスクリプトを実行します。 ビューだけのスクリプトを作成し、Babelfish クラスターの Northwind データベースに対して実行します。 ストアドプロシージャだけのスクリプトを作成し、サポートされていない機能を修正して、Babelfish クラスターの Northwind データベースに対して実行します。 移行の問題と解決策 このセクションでは、以前の移行作業でお客様に見られた、バージョン 3.2 の Babelfish の問題点と考えられる解決策について説明します。 ストアド・プロシージャおよびストアド・ファンクションでサポートされていない機能 アプリケーションのテストをより早く開始するための方法の 1 つは、サポートされていないストアドプロシージャ本体をコメントアウトし、例外を投げたりエラーを発生させたりすることです。ストアドプロシージャのシグネチャ (名前、入力、出力) は引き続き維持されます。理論的には、パラメータ化された正規表現 (グループキャプチャ付き) を書いてこれを行うことができます。以下に例を挙げます。 これにより、サポートされていない機能のサブセットが原因で、解決に時間がかかる可能性がある一部のテスト作業を中断することなく、サポートされていない問題を切り分け、個別にリリースして修正することができます。 トラブルシューティングクエリ これは、Babelfish への移行後に最もよく発生する問題です。これらの問題の多くは、SQL Server と PostgreSQL の間で異なるインデックス戦略が原因であることが多く、PostgreSQL 側の EXPLAIN ANALYZE または SET BABELFISH_STATISTICS PROFILE を使用して診断できます。 よくある問題は、述語 (predicate) の列に式がある場合でも SQL Server はインデックス付き列を使用できるが、PostgreSQL では使用できないというものです。解決策は、PostgreSQL で述語式と一致する式インデックスを作成することです。クエリを分析したら、インデックスと JOIN 条件が適切であることを確認して、考えられる修正を適用してください。次のコードを使用してください。 SET BABELFISH_STATISTICS PROFILE {ON|OFF} を使用して、ステートメントの実行に使用されたクエリプランを表示します SET BABELFISH_SHOWPLAN_ALL {ON|OFF} を使用すると、コマンドを実行せずにステートメントの推定説明プランを表示できます。 次の例では、 BABELFISH_SHOWPLAN_ALL がアクセスパス、インデックススキャン（存在する場合）、および操作のコストの詳細を提供し、パフォーマンスチューニングに役立ちます。 SET BABELFISH_STATISTICS PROFILE ON GO SELECT * FROM test a JOIN test2 b ON a . a = b . a WHERE b . c = 'A926' SQL この例では、パフォーマンスを向上させるために、列 c の test2 にインデックスを作成します。これは実行計画に反映され、操作のコストも削減されます。 CREATE INDEX ix_test_1 ON test2 ( c ) ; SQL 詳細については、「 クエリプランのレビュー 」を参照してください。 統計情報の更新 データベースオブジェクトの統計情報は、クエリのパフォーマンスにとって重要です。データベースオプティマイザーは、これらの統計情報を使用して最適な実行プランを決定し、それをデータ取得に使用します。 この記事の執筆時点では、Babelfish では統計情報の収集と更新はサポートされていません。回避策として、PostgreSQL の機能を使用してテーブルの統計情報を取得してください。 SQL Server command – UPDATE STATISTICS PostgreSQL command – ANALYZE 詳細については、 ANALYZE を参照してください。 テーブルインデックスの再構築 インデックスはクエリのパフォーマンスにとって重要です。T-SQL では、インデックスの再作成に DBCC コマンドまたは ALTER INDEX コマンドのいずれかを使用します。 DBCC DBREINDEX ( 'northwind . dbo . employees’ ) ; ALTER INDEX ALL ON northwind . dbo . employees REBUILD ; SQL これらのコマンドは Babelfish ではサポートされていません。代わりに、PostgreSQL 接続から PostgreSQL ステートメント REINDEX TABLE を使用できます。 REINDEX TABLE dbo . employees’ ; SQL 詳細については、「 テーブルインデックスの再構築 」を参照してください。 Babelfishではサポートされていないコード機能 Babelfish 関数またはコード構文と SQL Server にはいくつかの違いがあります。次の表は、回避策の例をいくつか示しています。 SQL Feature Babelfish Workaround MERGE 文 Compass レポート書き換えオプションを使用すると、MERGE ステートメントの回避策が生成されます。 -MERGE を UPDATE に置き換え、必要に応じて挿入を追加します。 UPDATE LOCATIONS SET LocationName=S.LocationName FROM Locations T, Locations_stage S WHERE T.LocationID=S.LocationID AND ( T.LocationID =3 ) EOMONTH () などの日付関数 サポートされていない日付関数のほとんどは、DATEADD や DATEPART などを使用する Compass rewrite オプションで書き換えられます。 PIVOT clause SUM (WHEN…) 句を使用してステートメントを書き直します。 UPDATE, WITH (Common Table Expression) as target このステートメントは Babelfish ではサポートされていません。必要なすべての条件を WHERE 句に入力して、もとになるテーブルに対して UPDATE ステートメントを手動で書き換えます。 DBCC commands DBCC は、データベースメンテナンスのための SQL Server ネイティブコマンドです。Babelfish の基盤となるデータベースである PostgreSQL データベースエンジンは DBCC をサポートしていないため、Babelfish の場合は PostgreSQL コマンドを特定の目的に使用してください。 DEFAULT パラメータ値を使用したプロシージャまたは関数を呼び出し Babelfishは、プロシージャまたは関数呼び出しでの DEFAULT キーワードをサポートしていません。Compass は、DEFAULT キーワードの代わりに実際のデフォルトパラメータ値を使用して呼び出しを書き換えます。次に例を示します。 –Before rewrite dbo.stored_procedure_1( @variable1, parameter_value, DEFAULT, DEFAULT, DEFAULT) –After Babelfish Compass rewrite dbo.stored_procedure_1( @variable1, parameter_value, /*REWRITTEN*/ 'N/A' /*DEFAULT*/, /*REWRITTEN*/ NULL /*DEFAULT*/, /*REWRITTEN*/ 0 /*DEFAULT*/) まとめ この投稿では、Babelfish Compass ツールと AWS DMS の使用を含め、SQL Server アプリケーションを Babelfish for Aurora PostgreSQL に移行する手順を示しました。サポートされていない機能の詳細を知るために、Babelfish Compass レポートで注目すべきセクションについて説明しました。また、AWS DMS を使用して Babelfish クラスターにデータをロードする方法の詳細も示しました。最後に、Babelfish の移行を加速させるのに役立つ一般的な移行問題と、考えられる解決策について説明しました。 AWS Babelfish チームは、製品を継続的に改善し、定期的に新機能を追加しています。 最新の改善点 については、四半期ごとにリリースされる Babelfish for Aurora PostgreSQL のアップデートを確認してください。 Babelfish for Aurora PostgreSQL の詳細については、「 Babelfish for Aurora PostgreSQL 」を参照してください。 翻訳はソリューションアーキテクトのYoshinori Sawada が担当しました。 原文 はこちらです。 著者について Amit Arora は、AWS でデータベースと分析を専門とするソリューションアーキテクトです。金融テクノロジー、世界のエネルギー分野のお客様、AWS 認定パートナーと協力して、クラウド移行プロジェクトに関する技術支援や顧客ソリューションの設計を行い、お客様が既存のデータベースを AWS クラウドに移行して近代化できるよう支援しています。

みなさん、こんにちは。ソリューションアーキテクトの下佐粉です。 今週も 週刊AWS をお届けします。 今週木曜に AWS Innovate AI/ML and Data Edition が開催されます。オンライン開催で「生成AI 」「AI/MLプラットフォーム」「ビジネスユースケース」のトラックが用意されていますので、ぜひご興味のあるセッションに参加ください。 – AWS Innovate AI/ML and Data Edition 2024 年 2 月 22 日 (木) また、3月2日の JAWS DAYS 2024 も近づいてきましたね。そろそろ残席が少なくなってきているようなので、早めの申し込みをお勧めします。 – JAWS DAYS 2024 – LEAP BEYOND それでは、先週の主なアップデートについて振り返っていきましょう。 2024年2月12日週の主要なアップデート 2/12(月) AWS Wickr now allows you to try premium features for free AWS Wickr で、StandardプランとPremiumプランの機能を最大3ヶ月間無料で試すことができる拡張フリートライアル体験(enhanced free trial experience)が利用可能になりました。Wickrはエンドツーエンドの暗号化されたメッセージングとコラボレーションを支援するサービスです。 Amazon DocumentDB (with MongoDB compatibility) now supports text search Amazon DocumentDB (MongoDB互換性) で、テキスト検索がサポートされました。フィールドにインデックスを作成しておくことで高速なテキスト検索を実現します。Amazon DocumentDB 5.0以降で利用可能であり、現時点では英語のみのサポートです。 Amazon DocumentDB (with MongoDB compatibility) now supports maintenance notifications Amazon DocumentDB にメンテナンス通知の機能が追加されました。これにより、AWS Health DashboardやEメールを通じて、スケジュールされたメンテナンスアクティビティについて通知を受け取ることができるようになります。 AWS AppSync introduces 12 new Amazon CloudWatch metrics for enhanced monitoring AWS AppSync で使用状況とパフォーマンスのより詳細な可視化を実現するために、より多くのメトリクスが提供されるようになりました。利用者のメトリクスの拡張として、リクエストとエラーのカウント、レイテンシー、キャッシュヒット/ミスの詳細なビューといった新しいオプションを含むようになりました。また、ネットワーク/CPUスループットの問題を診断する際に役立つ2つのキャッシュメトリクスも追加されました。詳細は こちらのドキュメント をご覧ください。 2/13(火) Amazon EMR on EC2 now supports retrieval of 10,000 steps completed within last 7 days Amazon EMR Step(ENRのジョブ管理の単位)のAPIであるDescribeStepとListStepで、過去7日間に完了した最大10,000ステップの取得をサポートするようになりました（以前は1,000ステップまででした）。 Amazon Redshift announces support for the INTERVAL data type and Continue Handler statements in stored procedure Amazon Redshiftで INTERVAL データ型がサポートされました。これは期間（レンジ）を表現するための型です。例えば12時間、6週間、1ヶ月などを定義できます。詳細は こちらのドキュメントをご覧ください 。 2/14(水) Amazon OpenSearch Service now lets you update cluster volume without blue/green Amazon OpenSearch Service でブルー/グリーンデプロイメント(Blue/Green deployment)を必要とせずに、クラスターのボリュームサイズ、ボリュームタイプ、IOPS、スループットを変更できるようになりました。ブルー/グリーンデプロイメントの場合、別クラスターを新しい設定で平行して起動してから移行しますが、こういった手間や時間をかけることなく変更が可能になりました。 Amazon OpenSearch Serverless now supports TLS 1.3 and perfect forward secrecy Amazon OpenSearch Serverless で TLS 1.3 が利用可能になり、合わせて perfect forward secrecy もサポートされるようになりました。これは暗号化プロトコルの仕様として、仮に秘密キーが漏洩した場合でも、以前のセッションで暗号化されたデータの安全性を守るように鍵を利用する手法であり、外部からのアタックに対してより堅牢な通信を実現します。 2/15(木) API Gateway now supports TLS 1.3 API Gatewayが TLS 1.3 をサポートしました。これによりラウンドトリップ(1-RTT)の TLS ハンドシェイクを使うことによるパフォーマンスを最適化と、前述の OpenSearch Service と同様に perfect forward secrecy をサポートする暗号のみを使うことで、セキュリティの強化を提供します。 Amazon RDS for Db2 now supports audit logging Amazon Relational Database Service (Amazon RDS) for Db2 がデータベースの監査ログをサポートするようになりました。これを有効化することで、 IBM Db2 ネイティブの監査機能が利用可能になります。監査ログは Amazon S3 に格納されます。詳細は こちらのドキュメントを参照 してください。 2/16(金) Amazon MSK now supports in-place version upgrades for Tiered Storage enabled clusters Amazon MSK がTiered Storage対応クラスターにおいて、インプレースバージョンアップグレードをサポートしました、v2.8.2.tieredを使用しているクラスターは、最新のApache Kafka 3.6.0にアップグレードできるようになりました。v3.6.0はTiered Storageの本番環境グレード(production-grade Tiere)での稼働サポートが含まれています。 Amazon Data Firehose enables selecting a time zone for bucket prefixes when delivering streams to Amazon S3 Amazon Data Firehose (※Amazon Kinesis Data Firehoseから改名されました) で、Amazon S3バケットへのストリーム配信時に、タイムゾーンを選択したバケットプレフィックスの作成が可能になりました。これまでは日本時刻でPrefixを作成する場合にはLambdaとの組み合わせ等が必要でしたら、今回の改善で設定のみで利用可能になりました。詳細は こちらのドキュメントをご覧 ください。 最後に、ちょっと気が早いですが今年のAWS Summitの開催日程が決まりましたので、ご案内します。今年は 2024 年 6 月 20 日（木）～21日（金）の2日間、幕張メッセでの開催です。以下のサイトでEメールアドレスを登録しておいていただくと、申し込み開始時に通知が届きます。 – AWS Summit Japan それでは、また来週！ ソリューションアーキテクト 下佐粉 昭 (X/Twitter – @simosako )

Amazon QuickSight Community は、AWS が提供する Business Intelligence(BI) サービスの QuickSight に関する様々な情報がまとまっており、QuickSight を利用時に出てきた疑問点を質問できるコミュニティです。その QuickSight Community において、2024年2月19日より日本語で質疑応答ができるようになりました。これにより、日本の QuickSight ユーザ間でネットワークを作り、スキルの向上を図ることができるようになります。Amazon QuickSight Community では、様々な学習に役立つコンテンツや、最新の情報などを提供しており、日本語のリソースも Japanese タグにて検索し、参照できるようになっています。 このブログでは、Amazon QuickSight Community の機能について紹介し、Japanese タグの日本語リソース確認方法、Community へのサインアップ方法、日本語での質問の投稿や返答、解決や通知方法について紹介します。 QuickSight Communityとは QuickSight Community にアクセスすると、以下のようなホーム画面が表示されます。 上部メニューバーは、各種リソースにすばやくアクセスできるようにそのリンクを提供しています。（一番左にある Q&A から Japanese（日本語） を選択することにより、以下で紹介する 日本語で質問｜Q&A カテゴリーに直接アクセスすることができます） その時点での注目イベントやアナウンスメントを大きく紹介し、イベントのリンクや、新機能に関する情報をすばやくアクセスできるようになっています。 カテゴリー (Categories)の一覧です。そして、このカテゴリーに 日本語で質問｜Q&A が追加されました！ Question & Answer (英語による質疑応答の一覧。検索も可能） Learning Center (動画やウェビナー、ワークショップなどスキル向上に必要なリソースを集約） What’s New / Blog (最新の製品アップデートやアナウンスメントとブログ) Events (週次・月次ウェビナーやオフラインイベントのサインアップ） Gallery (Arenaで作成したダッシュボードの公開ページ） 日本語で質問｜Q&A (日本語による質疑応答の一覧、検索も可能） 日本語で質問｜Q&A に入ると、日本語で投稿された質問の一覧が表示され、質問のタイトル(TOPIC)、返答数(REPLIES)、View数(VIEWS)、質問に対する最新アクティビティ日付(ACTIVITY)を確認できます。（質問の方法については、次の章で詳しく解説します） Learning Center に入ると、コンテンツのタイプによりさらにサブカテゴリー化されています。その中に 動画 | Japanese Videos というサブカテゴリーがあります。 その中に入ると、2023年に実施した QuickSight RoadShow in 東京のセッションを視聴することができるようになっています。 同じく、今度は Learning Center 内の Getting Started に入り、 Japaneseタグ で検索します。 日本語のコンテンツが表示されます。 How-to Video や Article も同様に Japaneseタグ にて、日本語コンテンツを参照することができます。 また、 What’s new / Blog に入り、同様に Japanese タグ で検索すると、日本語で提供されているブログを参照することができます。 今度は、 Events （イベント）にアクセスします。 同様に Japanese タグ で検索すると、現在日本語で開催予定にしているイベントの一覧を確認することができます。 日本語 Leaning Series の第一回を、3月27日12時から開催予定にしており、昨年末にリリースされた２つの新機能についてデモを交えながら紹介させていただきます。登録リンク先などの詳細情報は このトピック をクリックいただくことで、参照することができます。ぜひご登録ください。QuickSight に関わる日本語のイベントは今後この一覧にて通知する予定です。 実施した日本語Learning Seriesは録画され、 Learning Center 内の Learning Series Videos にアップロードされ、いつでも視聴することができるようになります。 QuickSight Community に参加する QuickSight Community ではログインしない場合でも、提供されているコンテンツをブラウズしたり検索することができますが、アカウントを作成いただくことで、質問をしたり、投稿への返答、コンテンツや返答にLikeをマークすることができるようになります。当 Community はパプリックコミュニティになるので、機密事項や個人情報に関わる情報については記載しないようお願いします。 Community へのサインアップ サインアップするには、以下のステップを実施します。 ホームページの右上にある Sign Up ボタンをクリックします。 既存の Amazon アカウント(米国 amazon.com のアカウント）を使用するか、EメールをIDに新しいアカウントを作成するかを選択します。EメールをIDに新しいアカウントを作成する場合は、Eメールアドレス、ユーザ名、パスワードを設定し、Create your account ボタンをクリックします。 新規にアカウントを作成した場合は、入力したEメールアドレスにアクティベンーションリンクが送られるので、それをクリックするだけで、アカウントの作成が完了します。 日本語で質問を投稿する ログインいただくことで、質問が投稿できるようになります。まず、質問を投稿する前に、検索にて同様の問い合わせが既に投稿されていないかを確認しましょう。 質問を投稿する手順は以下の通りです。 日本語で質問｜Q&A に入り、 ？ New Question  ボタンをクリックします。 投稿する質問内容について、タイトルを入力すると、その内容に基づき、既存の質問の中から類似した質問が右にリスト表示されます。同様の問い合わせがないようなら、投稿する前にタグを設定して下さい。タグを設定することにより、検索がしやすくなり似たような質問を見つけやすくなります。タグは最低２つ設定する必要があります。まず、ドロップダウンに表示されている author , developer , admin の中から該当するものを選択します（ビジュアル作成に関わる場合は author 、API やSDK 等に関する問い合わせの場合は developer 、ユーザやアセット、SPICE、サブスクリプションなどの管理面に関する問い合わせの場合は admin になります） その他のタグは、該当するタグを検索することにより、選択することができます。必ず、 Japanese タグを追加するようにしましょう。  タグの設定が完了したら、質問の内容について記述します。マークダウン記法をサポートする形で、テキスト入力だけでなく、ハイパーリンクやコードなどフォーマット済みテキストの入力、blockquote <引用タグ>の利用も可能で、入力すると、右にプレビュー表示がされるので入力と同時に確認することができます。 イメージのスクリーンショットもコピー＆ペーストで可能です。 質問内容の入力が完了したら、その下にある + New Quetion ボタンをクリックします。 日本語の質問に応答する ログインいただくことで、既に投稿されている質問に応答することができます。遠慮せずに積極的に返答をしたり、 (like this post)マークを提供し、Community を盛り上げていきましょう！ 返答は、 Reply ボタンをクリックします。 画面下に、返答入力用のフォームが提示されるので、返答内容を入力し、 Reply ボタンをクリックします。 特定の返答に対して応答するには、各返答下にある Reply アイコンをクリックすることで応答することができます。 また、気に入った返答に対しては、 (like this post)マークをクリックしましょう 日本語で投稿した質問への対応 投稿した質問に対しては、通知設定をすることができます。投稿した質問下にある (通知ベル)表示をみると、デフォルトでは Normal 設定となっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。クリックすることで、以下のような通知設定に変更することができます。 Watching ：全ての返答が新規にあった場合に通知され、その返答数がリスト上に明示されます Tracking ：返答数がリスト上に明示され、Normal設定と同様名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知されます Muted ：何も通知はされなくなり、最新リストからも表示されなくなります また、質問を投稿し、もらった返答により解決した場合、その返答に Solution マークを付与することができ、今後同じような質問をしたいユーザに対して的確な回答を明示することができます。ぜひ、積極的に Solution マークを付与しましょう！ 自分が投稿した質問に対して、的確な返答があった場合は、その返答下にある Solution マークをクリックします。 以下のように Solution マークが変わります。 さらに最初の質問内に、その返答内容が明記され、解決したことが一目で分かるようになります。 “日本語で質問｜Q&A” や “Japanese”タグに通知設定する 特定のトピック（質問）だけでなく、カテゴリー自体や特定のタグに対しても通知設定をすることができます。 カテゴリー自体に通知設定をする場合は、 日本語で質問｜Q&A に入り、画面右に表示される （通知ベル）アイコンをクリックします。デフォルトは Normal になっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。必要に応じて通知設定を変更します。 Watching ：このカテゴリーにトピックス（質問）が新規に投稿されると通知され、そのトピックスに対する返信についても全て通知されます。また、新規の返答があった場合、その数がリスト上に明示されます。 Tracking ：名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知され、新規の返答があった場合、その数がリスト上に明示されます。 Watching First Post ：トピックス（質問）が新規に投稿されると通知されますが、その返答に対しては通知されません。 Muted ：何も通知はされなくなり、最新リストからも表示されなくなります。 Japanese タグに対して通知設定をする場合は、以下の手順で設定できます。 右上にあるプロファイルアイコンの左にあるアイコンをクリックし、 All tags を選択します。 タグの一覧が表示されているので、対象とする Japanese を選択します。 表示された画面の右にある （通知ベル）アイコンをクリックします。デフォルトは Normal になっており、名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知を受けることができます。必要に応じて通知設定を変更します。 Watching ：このタグにトピックス（質問）が新規に投稿されると通知され、そのトピックスに対する返信についても全て通知されます。また、新規の返答があった場合、その数がリスト上に明示されます Tracking ：名前がメンションされたとき、もしくは自分の投稿に対して返答があった場合に通知され、新規の返答があった場合、その数がリスト上に明示されます Watching First Post ：トピックス（質問）が新規に投稿されると通知されますが、その返答に対しては通知されません Muted ：何も通知はされなくなり、最新リストからも表示されなくなります まとめ このブログでは、Amazon QuickSight Community について紹介し、サインアップの方法、日本語での質疑応答の方法、質問に対する解決設定方法、各種通知設定方法について紹介しました。QuickSight Community は、QuickSight を学習する上で必要な情報を集約しており、さらに日本語で利用することにより、日本での QuickSigh tユーザ間でネットワークを構築できる場となります。今後さらに日本語によるリソースを増強し、日本語 Learning Series についても定期的に開催していく予定です。ぜひ、この QuickSight Community を積極的にご活用ください。 ３月：日本語Learning Series 登録ページ