AWS は、11 月 16 日に Inter BEE 2023 への出展に合わせて、幕張メッセ国際会議場で 「AWS メディアセミナー」を開催しました。セミナーでは、「Create, Deliver, Monetize」をテーマにメディア & エンターテインメント業界向けの最新動向とクラウド活用の成果をいち早く出されているお客様から 3 つの事例を紹介いただきました。本ブログでは、セミナーの内容と資料をご紹介します。 セミナーアジェンダ アマゾン ウェブ サービス ジャパン合同会社 : AWS for Media & Entertainment ～ AWS クラウドで実現する放送・配信ワークフロー ～ 株式会社 WOWOW / 株式会社 TBS テレビ : ライブ制作の未来を変える！遅延なしの次世代型クラウドプロダクション 朝日放送グループホールディングス株式会社 : 1 日最大 150 球場超！大規模配信を支えるバーチャル高校野球ライブ配信の舞台裏 株式会社ソニー・ミュージックマーケティングユナイテッド/ 株式会社 DataCurrent : GROOVEFORCE ENGAGEMENT で扱うデータ活用事例 AWS for Media & Entertainment ～ AWS クラウドで実現する放送・配信ワークフロー ～ アマゾン ウェブ サービス ジャパン合同会社 執行役員 通信・メディア・戦略事業統括本部 統括本部長 恒松 幹彦 アマゾン ウェブ サービス ジャパン合同会社 インダストリー事業開発マネージャー 山口 賢人 こちらのセッションでは、AWS から、メディア業界の最新動向、AWS クラウドを活用したメディア業界向けソリューションや Inter BEE 2023 での見どころをご紹介しました。AWS ではメディア業界を『コンテンツ制作』『メディアサプライチェーン & アーカイブ』『Direct-to-Consumer & ストリーミング』『放送』『データ活用 & 分析』の 5 領域で、AWS サービスやソリューション、サポートを提供することで、コンテンツ制作から放送・配信まで幅広くお客様のビジネスを支援しています。本セッションでは、「Create, Deliver, Monetize」 の 3 つのテーマで、お客様が直面している主な課題と挑戦、最新事例などを中心に、なぜ、メディア業界のお客様は AWS を選ぶのか？という理由などについてご紹介させていただきました。また、セッション後半では、AWS の生成系 AI への取り組みにおいて、 API を通じて主要な基盤モデルを利用できるようにするフルマネージド型サービス、 Amazon Bedrock も紹介しました。 資料のダウンロードは こちら 【Create】ライブ制作の未来を変える！遅延なしの次世代型クラウドプロダクション 株式会社 WOWOW 技術センター技術推進ユニット 馬詰 真実 様 株式会社 TBS テレビ メディアテクノロジー局 未来技術設計部 原 拓 様 近年盛り上がりを見せるクラウドリモートプロダクションは、リソースを中継現場に持ち込む必要がないため、機材の運搬、スタッフや設営にかかる費用、時間的コストを最小限に抑えることが可能な反面、遅延や制御などの課題がありました。TBS テレビ様及び WOWOW 様はそういった現状を打破すべく、AWS を基盤に、共同開発された双方向型超低遅延プロトコル Live Multi Studio (LMS) とノードベースのビジュアルプログラミングツール TouchDesigner で構築した独自アプリを掛け合わせ、軽量化・コスト削減と映像のクオリティの両立を目指し、クラウドプロダクションを実現されました。 この仕組みは、現場から要求されるライブ映像制作に必要な機能を実装し、リモート環境からのカメラ制御、スイッチング、リプレイ、CG、スコア表記運用を可能にし、実際の番組制作での活用も進んでいます。実例として、全国選抜高校テニス大会でのオールクラウドプロダクション、男子テニス国別対抗戦デビスカップでの有料配信番組での利用、全日本高等学校女子サッカー選手権大会での複数会場での制作効率化についての取り組みを紹介いただきました。 事例: 全国選抜高校テニス大会 事例: 全日本高等学校女子サッカー選手権大会 資料のダウンロードは こちら 【Deliver】1 日最大 150 球場超！大規模配信を支えるバーチャル高校野球ライブ配信技術の舞台裏 朝日放送グループホールディングス株式会社 DX・メディアデザイン局 村中 貴彦 様 全国高校野球選手権大会の地方大会は 1 日に最大 150 以上の球場で試合が実施されており、バーチャル高校野球では全試合配信を目指して配信規模を年々拡大されてきました。そして、今年地方大会全  3,434  試合のライブ配信を実現されています。この大規模なライブ配信を行う上で必要不可欠な配信基盤および運用サポートツールのシステムを AWS で構築いただいています。本セッションでは、2015  年から積み上げてきた高校野球ライブ配信の舞台裏をお話いただきました。 配信数拡大に伴う課題として、スケーラブルな配信の仕組み、技術レベルに差のある運用者のスキルに依存しないエンコーダーの提供、配信・機材ステータスや試合情報を共有するためのコミュニケーションの複雑化がありました。 そこで、朝日放送グループホールディングス様では、フルマネージドなライブエンコードサービス AWS Elemental MediaLive を活用し、スケーラブルな配信基盤を構築し、Standard チャンネルの冗長化により、本線・予備のストリームを自動的に切り替える仕組みを導入されました。また、一部球場で AWS Elemental Link エンコーダーを導入し、配信設備側の担当がエンコーダの設定まで管理することで、現場担当者の負担やエンコーダー起因のトラブルを軽減されました。また、ステータス情報管理をシステム化し、スケジュールやステータスの管理を効率的に行い、各所とのコミュニケーションをシステム上で共有、これによりコミュニケーションコストが削減され、効率的な運用を実現されました。 資料のダウンロードは こちら 【Monetize】GROOVEFORCE ENGAGEMENT で扱うデータ活用事例 株式会社ソニー・ミュージックマーケティングユナイテッド アナリティクス本部 課長 長田 洋 様 株式会社 DataCurrent 取締役 COO 古田 誠 様 本セッションでは、ソニーミュージックグループで活用している分析基盤である「GROOVEFORCE」シリーズの中で、ファン層を可視化し分析する事を目的とする GROOVEFORCE ENGAGEMENT で扱っているデータ活用事例を紹介いただきました。「GROOVEFORCE」は、レーベル・宣伝・マーケティング現場のユーザーが求められるデータを可視化し、ダッシュボードとして提供することで、データドリブンな意思決定をサポートしています。また複数の 1st パーティ、3rd パーティデータソースからのデータ取得を一元管理することでデータ取得コストを最適化しています。これにより、ファンの関心に基づくエンゲージメント向上施策や、最新トレンドや過去のヒット傾向からの楽曲制作支援、ファンの特性を捉えた効果的なプロモーション、分析作業の標準化・効率化を実現されました。 セッションでは、GROOVEFORCE ENGAGEMENT を活用した分析・施策の実例として、ストリーミングデータからアーティストのピーク月を抽出し、リリースタイミングを設定する施策や、プロモーション露出タイミングの最適化についてお話いただきました。また、アーティストのファン層が、どのようなテレビジャンルに興味を持っているかなどの分析も、デモを交えてご紹介いただきました。 終わりに 今回は、Inter BEE 2023 の AWS セミナーの概要を紹介しました。 AWS 展示の概要については こちら AWS スポンサー展示の概要については こちら AWS ブースセッションの概要については こちら を参照ください。 参考リンク AWS Media Services AWS Media & Entertainment Blog　(日本語) AWS Media & Entertainment Blog　(英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本ブログは BD 山口が担当しました。

はじめに 多くの企業が屋内外の空間を監視してセキュリティを向上させるために、何百台ものインターネット・プロトコル (IP) カメラを設置しています。これは、自動車、商業、石油・ガス、公安、農業技術など、さまざまな業界に共通するニーズです。企業はカメラをクラウドに接続することで、サイロ化されたデータを一元管理し、デジタルツイン機能を追加することができます。この記事では、AWS IoT Greengrass V2 コンポーネントを使用して、ライブストリーミング、オンデマンドビデオアップロード、そしてローカルキャッシュが可能な Amazon Kinesis Video Streams  stream uploader をパッケージ化し、デプロイする方法について説明します。 Kinesis Video Streams は、デバイスから AWS へのライブビデオのストリーミング、リアルタイムビデオ処理のためのアプリケーションの構築、ビデオのバッチ分析などに使用できるフルマネージドな AWS サービスです。Kinesis Video Streams サービスを使用して、スマートフォン、セキュリティカメラ、ウェブカメラ、ドローン、赤外線画像、音声など、さまざまなソースからビデオや非ビデオデータを取り込むことができます。最近、 AWS IoT Greengrass component for Kinesis Video Streams がリリースされ、既存のデバイスからメディアをストリーミングできるようになりました。Kinesis Video Streams コンポーネントのエッジコネクタ (aws.iot.EdgeConnectorForKVS) は、Real Time Streaming Protocol (RTSP) を使用してローカル IP カメラからビデオフィードを読み取り、Kinesis Video Streams エンドポイントにストリームをパブリッシュします。 ソリューション概要 スマートビルディングソリューションを開発するある企業は、ビルの入口、入退室管理エリア、セキュリティゲートから数百のビデオストリームを取り込むアプリケーションの構築に興味を持っています。同社は、 AWS IoT TwinMaker を使用してデジタルツインアプリケーションにビデオフィードを組み込み、 AWS IoT TwinMaker application plugin for Grafana dashboard を使用してビデオのアップロードを行い、過去のビデオタイムラインを確認することを検討しています。 既存のカメラを改修してエンドポイントにストリーミングするのは難しい場合があります。代わりに、AWS IoT Greengrass を利用して、 エッジゲートウェイと Kinesis Video Streams 向けのエッジコネクタコンポーネントをデプロイすることで、既存のカメラからデータを取り込むことができます。このコンポーネントは同じネットワーク内の IP カメラに接続し、ビデオフィードを Kinesis Video Streams にストリーミングします。取り込み側では、アプリケーションを使用して Kinesis Video Streams のエンドポイントからデータを読み取り、クライアントとして利用可能です。このコンポーネントはエッジ上で動作し、ビデオのキャッシュ、スケジュールされた録画・アップロード、ライブストリーミング、Kinesis Video Streams への過去のビデオのアップロードなどの機能をサポートします。エッジコネクタコンポーネントは、ニーズに応じて調整可能な AWS IoT Greengrass V2 コンポーネントで、ビデオの取り込みをカスタマイズできます。 AWS IoT Greengrass ハブごとにこのコンポーネントへ接続できるカメラの数は、ベースとなるハードウェアの計算能力、ネットワーク帯域幅、およびコネクタの設定を保存するために使用される  AWS IoT SiteWise  の子アセットに依存します。(現在この制限は 2000 です。子アセットのクオータに関する詳細については こちら を参照してください。) このアーキテクチャは、AWS IoT Greengrass デバイスと AWS の間に安定したネットワーク接続があり、メディアのストリーミングに十分な帯域幅があることを前提としています。 図1： AWS IoT Greengrass v2 コンポーネントを使用した IP カメラからのビデオフィードの取り込み エッジデバイスへの AWS IoT Greengrass Core のデプロイ。このデバイスはエッジコネクタの実行とカメラとの接続を担います。Greengrass Core ソフトウェアは、Raspberry Pi などの Linux デバイスまたは Windows デバイスにデプロイすることができます。このデバイスは最終的にエッジコネクタの Kinesis Video Streams コンポーネントを実行します。 AWS IoT Greengrass のセットアップ方法 の詳細については、ドキュメントを参照してください。 GStreamer バージョン 1.18.4 以降をエッジデバイスにインストールします。 エッジデバイスのセットアップが完了したら、AWS IoT Greengrass サービスを使用して Kinesis Video Streams コンポーネントのエッジコネクタをデプロイします。デプロイ固有の詳細で設定ページを編集してください。 AWS IoT Greengrass へのコンポーネントのデプロイ方法 の詳細については、ドキュメントを参照してください。 Kinesis Video Streams コンポーネントのエッジコネクタがデプロイされると、コンポーネントの構成は AWS IoT SiteWise と AWS Secrets Manager に保存されます。AWS IoT SiteWise には 2 種類のアセットが格納されます。 theEdgeConnectorForKVSHub アセットには、コネクタが実行されている固有のハブを識別するアセット名が格納され、EdgeConnectorForKVSCamera には、ストリーミングや録画を開始する cron 式 のようなカメラ固有のプロパティが格納されます。詳細については、このサービスに 必要な設定パラメータ に関する GitHub ページを参照してください。 Kinesis Video Streams のエッジコネクタは、カメラフィードからデータを取り込みます。Kinesis Video Streams エンドポイントにストリームするだけでなく、ローカルストレージを追加するオプションもあります。 クライアント側では、Kinesis Video Streams エンドポイントからデータを消費する独自のカスタムアプリケーションを構築できます。例として、動きを検出したときにライブストリーミングビデオを再生させることができます。 このアーキテクチャと上記のステップを実装するための詳細な手順については、 github を参照してください。 エッジアーキテクチャの詳細 図2： Amazon Kinesis Video Streams で IP ビデオカメラのフィードを取り込むためのアーキテクチャ エッジアーキテクチャには、コントローラ、ビデオレコーダ、ビデオアップローダの 3 つのモジュールがあります (前の図を参照) 。Kinesis Video Streams コネクタコンポーネントのデフォルト設定はビデオのストリーミングですが、オプション機能としてローカルストレージのファイルシステムにビデオを録画する機能もあります。 コントローラは、レコーダとアップローダの仲介役を果たし、両者の間の通信をサポートします。コントローラはまず、接続された入力ストリームオブジェクトと出力ストリームオブジェクトのペアを初期化します。ビデオレコーダはカメラからストリームデータを取得し、そのデータを接続された出力ストリームに格納します。最後に、ビデオアップローダが接続された入力ストリームからストリームデータを取得し、そのデータを Kinesis Video Streams にアップロードします。 ソリューションのスケーリングについて 次に、このソリューションがどのようにスケーリングするのか、サイジングと制限について見ていきます。アーキテクチャ上、Kinesis Video Streams コンポーネントのエッジコネクタと Greengrass Core にはスケーリングの制限はありません。このソリューションでは AWS IoT SiteWise を使用して RTSP カメラ構成を管理するため、唯一のハードリミットは AWS IoT SiteWise の子アセットクォータにより、親アセットあたりの子アセットが 2000 未満であることです。エッジデバイス/ハブがサポートできるカメラの数は、そのハードウェア構成にのみ依存します。十分なネットワーク帯域幅とハードウェア容量があれば、AWS IoT Greengrass デバイスはより多くのカメラをサポートすることができます。内部で行った テストでは、同じエッジデバイスに接続された 10 台以上のカメラからのフィードを問題なく取り込むことができました。詳細については、 Kinesis Video Streams API の制限とクォータ のドキュメントを参照してください。 以下に、エッジデバイスの構成例と、最適なパフォーマンスでサポートできるビデオストリーム数を示します。 2GB RAM と 16GB SSD を搭載した小型インスタンス ( Raspberry Pi 4 Model B など) は、100 MBPS のネットワーク速度で同時に最大 2 台の1080p HD RTSP カメラをクラウドにアップロードできます。 4GB RAM と 16GB SSD を搭載した中インスタンス ( NVIDIA Jetson Nano Developer Kit など) は、100 MBPS のネットワーク速度で 同時に最大 4 台の1080p HD RTSP カメラをクラウドにアップロードできます。 25GB RAM と 1TB SSD を搭載した大型インスタンス ( Intel NUC など) では、最大 24 台の1080p HD RTSP カメラを 600 MBPS のネットワーク速度で同時にクラウドにアップロードできます。 このソリューションは主にメモリに依存するため、CPU や GPU のタイプや容量などの計算リソースはあまり関係ありません。 クリーンアップ GitHub のリンクを使用してこのアーキテクチャを実装した場合、コストが発生しないように以下の手順でリソースをクリーンアップしてください。 エッジデバイスから Greengrass コアソフトウェアを アンインストール する。 Kinesis Video Streams を削除する Kinesis Video Streams コンソール を開きます。 左側のメニューから「ビデオストリーム」を選択し、ビデオストリームを選択します。 画面右上の「ビデオストリームを削除」を選択します。 確認画面が表示されます。フィールドに「削除」と入力し、削除を選択します。 まとめ 本ブログでは、 AWS IoT Greengrass component for Kinesis Video Streams  の概要、デプロイ可能なユースケース、このコネクタをデプロイする手順の GitHub リンクを紹介しました。 AWS が提供する他の Greengrass コンポーネント と同様にこの機能を利用し、既存のデバイスに対して  Kinesis Video Streams を有効にできます。デプロイ手順を含むこのソリューションの詳細については、この github リポジトリ を参照してください。 著者について Aditi Gupta Aditi Gupta は Amazon Web Services のシニア IoT スペシャリストソリューションアーキテクトです。 18 年以上にわたり、多くの政府機関や大規模企業向けに高いスケーラビリティと信頼性を備えたシステムを設計および開発してきました。ビッグデータ、人工知能、および機械学習に関心があります。 Harish Rajagopalan Harish Rajagopala は  Amazon Web Services のシニアソリューションアーキテクトです。エンタープライズのお客様と協力し、クラウドへの移行をサポートしています。 翻訳者について 大久保 裕太 AWS Japan のソリューションアーキテクトです。週末はバスケットボールをしています。

はじめに Amazon Connect は使いやすいクラウドコンタクトセンターで、あらゆる規模の企業が優れたカスタマーサービスを低コストで提供できるよう支援します。コンタクトセンターの分野において、企業は運用コストについてより深い洞察を求めています。お客様は、事業部門や複数のブランドなど、コンタクトセンターのワークロード用に異なるコストセンターを持っている可能性があります。今日、このような企業は AWS の請求書を受け取った後、Amazon Connect のコストを該当するコストセンターに手作業で割り当てる必要があります。 お客様はまた、コンタクトセンター内の特定のコンタクトタイプ（サポート、セールスなど）やコンタクトワークロード（アウトバウンドキャンペーン、一時的なイベントベースのサポートなど）に関連するコストを把握したいと考えています。このようなユースケースを可能にするデータの取得は、以前は非常に手間のかかるプロセスであったり、不可能であったりしました。 今回の新機能で以下のようなことが可能になりました。例えば、コンタクトが転送される際にキューへの転送フローが起動されると、2 番目のコンタクトが作成されます。この場合に、キューへの転送フローでコンタクトに “Department: Support” とタグ付けし、コンタクトの最初のセグメントでは “Department: Sales” とタグ付けすることができます。その後、請求とコスト管理コンソールでコスト割り当てタグとして “Department” を選択すると、Cost Explorer およびコストと使用状況レポートで、これらのセグメントの料金を部門別に区分できます。 コンタクトには、インスタンス ID やシステム・エンドポイント（インバウンドコールとアウトバウンドコールのそれぞれについて、着信番号（DNIS）とシステム発信者番号）などのシステムタグが自動的に付けられますが、もちろん、お客様が独自のタグを作成して管理したい場合もあるでしょう。例えば、事業部門やブランド別のタグ付けなど、顧客の意図を理解すれば簡単にタグ付けできるユースケースもありますが、より複雑なユースケースや、これまでのレガシーテクノロジーでは不可能または非現実的だったユースケースでは、直感的なタグ付けが難しい場合があります。このブログの残りの部分では、タグ付けに関するお客様のさまざまなユースケースとその適用方法について説明します。 部門を跨ぐ転送 顧客がサポートの問題なのにセールスの電話番号に電話してしまったのか、それとも別の部門（サポート部門）で対応する追加ニーズがあったのかにかかわらず、これまでは部門を横断する転送に関連するコストを適切な事業部門に割り当てることが困難でした。現在では、コンタクトのタグ付け機能により、コンテンツの各セグメントを個別にタグ付けすることができ、その結果、各コンタクトセグメントの使用料を適切な部門に請求することができます。 上記の例では、顧客は “sales” コンタクトとして入電し、コンタクトは “Department: Sales” とタグ付けされます。その後、コンタクトは Sales キューを通過し、顧客はセールス部門のエージェントと会話し、注文をします。その後、顧客は別の製品のサポートに関する質問をします。セールス部門のエージェントは、この質問はサポート部門が処理するのが最適であると認識し、クイック接続を使用してコンタクトをサポート部門に転送します。 コンタクトが転送されると、キューへの転送フローが起動され2 番目のコンタクトが作成されます。キューへの転送フローで、コンタクトは “Department: Support” とタグ付けされます。コンタクトの最初のセグメントは “Department: Sales” とタグ付けされ、2 番目のセグメントは “Department: Support” とタグ付けされました。請求とコスト管理コンソールで コスト配分タグ として “Department” を選択すると、Cost Explorer およびコストと使用状況レポートで、これらのセグメントの料金を部門別に区別できるようになります。 注: “Department: Support” タグが 2 つ目のコンタクトセグメントに適用されていない場合、“Department: Sales” が（他のタグで上書きされるまで）そのコンタクトのタグとして使用されます。 上記の例のようなウォーム転送の場合、転送後にセールス部門のエージェントは一定時間通話にとどまります（申し送りのため）。このコンタクトが重なる期間のサービスおよびテレフォニー料金は、最初のコンタクト（セールス）と2番目のコンタクト（サポート）の間で分割されます。 セールス: 5 分間の電話料金およびサービス利用料金 セールスとサポート: 2 分間の電話料金およびサービス利用料（セールスとサポートで折半） サポート: 8 分間の電話料金およびサービス利用料金 通話タイプ 顧客からの問い合わせの種類に応じたコンタクトセンターのコストを把握することは、顧客エンゲージメントオプションを改善し、コストを削減するための将来の投資分野について情報を提供する上で有効です。タグを使用して顧客からのさまざまな問い合わせ理由を表すことで、問い合わせの種類別に Amazon Connect の使用量と電話料金を確認できます。 上記のフローでは、コンタクトが着信すると、顧客の意図を識別し、 “OrderStatus” と “CancelOrder” のセルフサービス操作を提供するためにバーチャルアシスタントが反応します。コンタクトタイプ（この場合はユーザーの意図）が決定されると、コンタクトはそれぞれのコンタクトタイプでタグ付けされ、エージェントとの通話で継続されるか、または終了されます。 コンタクトがフロー内のどこでタグ付けされるかに関係なく、タグはコンタクト全体に適用されます。つまり、上記の例でPlaceOrder コンタクトタイプの場合、このコンタクトに対する Amazon Connect の使用料と電話料金は、コンタクトの開始から終了までタグ付けされます。 特定のコンタクトタイプにコストが割り当てられるようになった今、お客様はそのデータを使って、FAQ、デジタルセルフサービス、その他の情報資産のようなデジタル付随サービスを通じて顧客の問題解決を支援するための投資や、より費用対効果の高いチャネルへの拡大に役立てることができます。 アウトバウンドキャンペーン アウトバウンドキャンペーンを利用する場合、企業は各キャンペーンに関連するコスト、つまり TMC（トータルマーケティングコスト）を知りたいと思うでしょう。コンタクトセンターを通じてこれらのキャンペーンを実行する際に、コンタクトタグを使用することができます。 上記の例では、キャンペーンのセグメントから顧客が特定されます。ダイヤラーが特定された顧客とのコンタクトを開始すると、そのコンタクトにはキャンペーン ID、顧客の所在地、（顧客セグメントデータに基づく）顧客のロイヤルティレベルがタグ付けされます。 上記のコンタクトタグは顧客のロケーションとロイヤルティレベルを指定するために使用されましたが、同じロジックを顧客セグメントデータの一部として任意のカテゴリデータに適用することができます。コンタクトフロー内でコンタクトタグを使用することで、企業は様々なキャンペーンのコストや、各キャンペーン、または顧客のセグメンテーションごとの収益率を比較することができます。 アウトバウンドキャンペーンの投資収益率（ROI）とリード単価（CPL）を計算するために、企業は生成された総マーケティングコスト（TMC）と総収入（TR）、生成されたリードのデータを活用することができます。 結論 コンタクトセンターの費用を理解することは、投資分野の理解に役立ち、自動化、デジタル資料、セルフサービス、エージェントトレーニング、エージェントツールなどのビジネスケースを構築するのに役立ちます。Amazon Connect のコンタクトタギングときめ細かな請求により、コンタクトセンターの運用コストをこれまで以上に把握することができます。このブログでは、きめ細かな請求を使ってコンタクトセンターのコストを把握する 3 つの例を紹介しました。これらのユースケースは、ほんの一例を紹介したに過ぎず、皆様がどのようなユースケースを思いつくか楽しみです！下記の関連リンクもぜひご覧ください！ What’s New ブログ記事: https://aws.amazon.com/about-aws/whats-new/2023/12/amazon-connect-granular-billing/ Amazon Connect 管理者ガイド: https://docs.aws.amazon.com/connect/latest/adminguide/granular-billing.html AWS Tagging guidance: https://aws.amazon.com/solutions/guidance/tagging-on-aws/ TAGS: Amazon Connect , Billing , Contact Center 翻訳はソリューションアーキテクトの坂田が担当しました。原文は こちら です。

AWS re:Invent 2023 では、生成系 AI によって形作られる未来に向けた最も有望なイノベーションとコンセプトのいくつかが紹介されました。AWS のサービスはその未来の中心であり続け、それをサポートするために進化しています。 re:Invent 2023 では、Amazon Connect に直接統合された新しい生成系 AI 機能コミュニケーションチャンネルを発表しました。これらの機能は開発を必要としないため、お客様は迅速にイノベーションを起こすことができます。さらに私たちは、Amazon Connect とこれらの新機能を活用してビジネスに利益をもたらしている Amazon Connect のお客様（DISH、Capital One、NatWest、Adobe、John Hancock）を紹介しました。このブログ記事では、これらの発表と顧客事例のいくつかについてまとめます。 Amazon Connect における生成系 AI とコミュニケーションイノベーション Amazon Connect に統合された新しい生成系 AI 機能は、企業がカスタマーエクスペリエンスを再構築し、顧客の成果を向上させ、コンタクトセンターのエージェントの効率を改善するのに役立ちます。 以下の新機能 は、エージェントの強化やトレンドを理解するための会話分析の強化、より良い顧客プロファイル情報など、顧客のセルフサービス体験を向上させるワンストップ・ソリューションを提供します。 Amazon Q は業務用に設計され、特定のビジネスニーズに合わせることができる生成系 AI 搭載アシスタントであり、 Amazon Connect 内で直接利用できる ようになりました。これは、リアルタイムの応答とアクションの推奨によりコンタクトセンターのエージェントを支援します。その結果、エージェントは顧客からの問い合わせに迅速に対応し、顧客満足度のスコアを向上させることができます。AWS re:Invent 2023 の 基調講演 で、AWS のアダム・セリプスキー CEOがAmazon Q in Connect の価値について説明していますのでぜひご視聴ください。 Amazon Connect Contact Lens は、 生成系 AI によるコンタクトの要約機能 の改善を発表しました（プレビュー）。これにより、エージェントがメモを取る労力を削減し、管理者がコンタクトを分析する時間を最小限に抑えることができます。この新機能はスーパーバイザーに、問題がどのように対処されたかやフォローアップ項目など、顧客との会話の主要な側面を簡潔に説明する、ハイレベルで生成的な AI 要約を提供します。 Amazon Connect Customer Profiles は、 生成系 AI によって顧客データを自動的に集約しマッピング することで、顧客にパーソナライズされた顧客体験を提供するために必要な時間と労力を削減します。 チャットボットによる顧客セルフサービス体験の設定と管理も生成系 AI によって強化され、顧客にとって効果的で魅力的なセルフサービス体験の構築が容易になりました。例えば、 ユーザーの発話に含まれるスロット値をより高い精度で解決 できるようになりました。つまり、顧客が「土曜日と日曜日」にホテルの部屋を予約したいと言った場合、セルフサービス・システムはその応答を「2 泊」と正しく解釈します。これは、精度を向上させ、より良い顧客体験を提供する大規模言語モデル（LLM）の高度な推論機能によるものです。カスタマー・セルフサービス体験のための新しい機能強化の詳細については、 こちら をご覧ください。 Amazon Connect はまた、 双方向 SMS 、 ビデオサポート付きアプリ内およびウェブ音声通話 を含む、すぐに使えるオムニチャネル機能を追加しました。これらの新しいビルトインコミュニケーションチャネルにより、顧客が好むチャネル全体で、統合されパーソナライズされた体験を、セルフサービスでもエージェントとの対話でも顧客に提供することができます。 脚光を浴びている Amazon Connect のビジネスインパクト 顧客の成功事例を紹介することは、re:Invent 2023 の重要な要素でした。これらのストーリーは、世界有数の企業が Amazon Connect を活用してどのようにビジネスを推進しているかを示すものです。(以下の各企業のリンクをクリックすると、プレゼンテーションが表示されます。） DISH は、15,000 人のコンタクトセンターのエージェントを 2 週間かけて Amazon Connect に移行したことを紹介しました。 これにより、複雑で困難な顧客からの問い合わせの解決が改善され、エージェントの効率も向上しました。 Capital One は、 Amazon Connect アウトバウンドキャンペーン の力を活用し、コンタクトセンターをモダナイズし、大規模にサービスを向上させていることを明らかにしました。 NatWest は、アプリ内、ウェブ、ビデオ通話を含む Amazon Connect のオムニチャネル機能について語りました。さらに、顧客満足度をプロアクティブかつコスト効率よく向上させる方法についても紹介しました。 AWSの顧客である Adobe と John Hancock も登壇し、Amazon Connect でどのように成果を上げているかを紹介しました。Adobe は、チャットや音声チャネルでパーソナライズされた自動化されたインタラクションを構築し、顧客に一貫した体験を提供しています。一方、John Hancock は、Amazon Connect の アナリティクスと最適化機能 を活用してコンタクトセンターの効率を高めています。 将来を見据える 皆さんの組織では Amazon Connect をどのように活用して、顧客に対する価値を創造しますか？ Amazon Connect の最新機能がビジネスの未来を形作るためにどのように役立つかをご覧ください。詳しくは、 Amazon Connect のページをご確認ください。 TAGS: agents , Artificial Intelligence , CCaaS , Connect , Contact Center , customer , cx , experience , launch , reinvent 翻訳はソリューションアーキテクトの坂田が担当しました。原文は こちら です。

AWS では、何十万ものお客様がサーバーレスデータ統合サービスである AWS Glue を使用して、アナリティクスや機械学習のためにデータを発見、結合、準備をしています。複雑なデータセットや負荷の高い Apache Spark ワークロードを使用している場合、Spark ジョブの実行中にパフォーマンスのボトルネックやエラーが発生することがあります。このような問題のトラブルシューティングは難しく、本番環境でのジョブの実行を遅らせる可能性があります。 Apache Spark Web UI は、オープンソースの Apache Spark に含まれる人気のあるデバッグツールで、問題の修正やジョブパフォーマンスの最適化に役立ちます。AWS Glue は 2 つの異なる方法で Spark UI をサポートしていますが、自身でセットアップする必要があります。そのため、ネットワークや EC2 インスタンスの管理に時間と労力を費やしたり、Docker コンテナを使って試行錯誤する必要があります。 本日、AWS Glue コンソールに組み込まれたサーバーレス Spark UI を発表します。Spark UI は AWS Glue コンソールに組み込まれており、ジョブ実行の詳細を確認する際にワンクリックでアクセスできるため、Spark UI を簡単に使用できるようになりました。インフラストラクチャの構築や破棄は不要です。AWS Glue のサーバーレス Spark UI は、完全に管理されたサーバーレスで提供され、通常数秒で起動します。サーバーレス Spark UI は、ジョブ実行に関する低レベルな詳細にすぐにアクセスできるため、本番環境でのジョブの実行を大幅に迅速かつ容易にします。 このブログでは、AWS Glue サーバーレス Spark UI が、AWS Glue ジョブの実行の監視とトラブルシューティングにどのように役立つかを説明します。 サーバーレス Spark UI の開始方法 AWS Glue コンソールのジョブページから、実行した AWS Glue ジョブのサーバーレス Spark UI にアクセスできます。 AWS Glue コンソールで、 ETL jobs を選択します。 確認したいジョブを選択します。 Runs タブを選択します。 調査したいジョブを選択し、 Spark UI を選択します。 以下の画面キャプチャのように、下部ペインに Spark UI が表示されます： もしくは、AWS Glue の Job run monitoring からナビゲートすることで、特定のジョブ実行のサーバーレス Spark UI にアクセスすることができます。 AWS Glue コンソールで、ETL jobs の下にある Job run monitoring を選択します。 ジョブを選択し、 View run details を選択します。 ジョブの Spark UI を表示するには、下までスクロールします。 前提条件 以下の前提条件を満たす必要があります。 ジョブ実行時に Spark UI のイベントログを有効にします 。Glue コンソールではデフォルトで有効になっており、有効化するとジョブの実行中に Spark イベントログファイルが作成され、S3 バケットに保存されます。サーバーレス Spark UI は、S3 バケットに生成された Spark イベントログファイルを解析し、実行中と完了したジョブの詳細情報を可視化します。プログレスバーには、解析完了までのパーセンテージが表示され、標準的な解析時間は 1 分未満です。 ログが解析されると、組み込みの Spark UI を使用してジョブのデバッグ、トラブルシューティング、最適化を行うことができます。 Apache Spark UI の詳細については、 Apache Spark の Web UI を参照してください。 サーバーレス Spark UI を使った監視とトラブルシューティング AWS Glue for Apache Spark ジョブの典型的なワークロードは、リレーショナルデータベースから S3 ベースのデータレイクへのデータのロードです。このセクションでは、サーバーレス Spark UI を使用して、上記のワークロードに対して実行されるジョブの例を監視し、トラブルシューティングする方法を示します。サンプルジョブは MySQL データベースからデータを読み込み、Parquet 形式で S3 に書き込みます。ソーステーブルには約 7,000 万レコードがあります。 以下の画面は、AWS Glue Studio のビジュアルエディタで作成したビジュアルジョブのサンプルです。この例では、ソースとなる MySQL テーブルはあらかじめ AWS Glue データカタログに登録されています。登録は AWS Glue クローラーまたは AWS Glue カタログ API から行います。詳しくは AWS Glue のデータカタログとクローラ を参照してください。 いよいよジョブの実行です！最初のジョブは 30 分 10 秒で終了しました： Spark UI を使って、このジョブ実行のパフォーマンスを最適化してみましょう。 Job runs ページの Spark UI タブを開きます。Stages にドリルダウンして Duration カラムを表示すると、Stage Id = 0 がジョブの実行に 27.41 分を費やしており、 Tasks:Succeeded / Total カラムに Spark タスクが 1 つしかないことがわかります。これは、ソースの MySQL データベースからデータをロードするための並列処理が行われなかったことを意味します。 データのロードを最適化するには、ソーステーブル定義に hashfield と hashpartitions というパラメータを導入します。詳細については、 JDBC テーブルからの並列読み取り を参照してください。引き続き、Glue カタログテーブルの、テーブルプロパティに hashfield = emp_no と hashpartitions = 18 の 2 つのプロパティを追加します。 これは、新しいジョブがソース MySQL テーブルからのデータロードを並列で実行することを意味します。 同じジョブをもう一度実行してみましょう！今回は 9 分 9 秒で終了しました。前回のジョブ実行から 21 分も短縮されました。 ベストプラクティスとして、Spark UI を表示し、最適化の前後を比較してみてください。Completed stages まで掘り下げると、1 つのタスクの代わりに 1 つのステージと 18 のタスクがあったことに気がつくでしょう。 最初のジョブ実行ではタスク数が少なすぎたため、書き込み先に書き込む前に AWS Glue が複数のエグゼキュータ間でデータを自動的にシャッフルしました。一方で 2 回目のジョブ実行では、余分なシャッフルを行う必要がなかったためステージは 1 つだけになり、ソース MySQL データベースから並列にデータをロードするタスクは 18 個になりました。 考慮事項 以下の点に留意してください： サーバーレス Spark UI は、AWS Glue 3.0 以降でサポートされます サーバーレス Spark UIは 、AWS Glue の Spark ログの出力と保存方法の変更に伴い、2023 年 11 月 20 日以降に実行されたジョブで利用可能になります サーバーレス Spark UI は、最大 1GB までの Spark イベントログを可視化することができます サーバーレス Spark UI は、S3 バケット上の Spark イベントログファイルをスキャンするため、保持に制限はありません VPC からのみアクセス可能な S3 バケットに保存された Spark イベントログでは、サーバーレス Spark UI は利用できません AWS Glue コンソールの Spark UI は、ストリーミングジョブでデフォルトで生成されるようなローリングログをサポートしていません。追加設定を行うことで、ストリーミングジョブのローリングログをオフにすることができます。非常に大きなログファイルは、維持することに多くのコストがかかる可能性があることに注意してください。ローリングログをオフにするには、以下の 2 つのジョブパラメータを指定します： Key – --spark-ui-event-logs-path , Value – true Key – --conf , Value – spark.eventLog.rolling.enabled=false さいごに このブログでは、AWS Glue サーバーレス Spark UI が AWS Glue ジョブの監視とトラブルシューティングにどのように役立つのかを説明しました。AWS マネジメントコンソール内で直接 Spark UI にアクセスすることで、ジョブ実行に関する低レベルな詳細を調査し、問題を特定して解決することができます。サーバーレス Spark UI では、管理するインフラストラクチャはありません。この合理化された体験により、Spark UI を手動で起動する場合と比べて、時間と労力を節約できます。 サーバーレス Spark UI を今すぐお試しください。パフォーマンスを最適化し、エラーのトラブルシューティングを迅速に行うための重要なツールであることがお分かりいただけると思います。今後も AWS Glue のコンソール体験を向上させていくために、皆様のフィードバックをお待ちしております。 著者について Noritaka Sekiyama は、AWS Glue チームのプリンシパル ビッグデータ アーキテクトです。東京を拠点に活動。顧客支援のためのソフトウェアアーティファクトの構築を担当。趣味はロードバイクでのサイクリング。 Alexandra Tello は、ニューヨークの AWS Glue チームのシニアフロントエンドエンジニアです。ユーザビリティとアクセシビリティの熱烈な支持者。時間があるときにはエスプレッソ愛好家であり、メカニカルキーボードの制作を楽しんでいます。 Matt Sampson は、 AWS Glue チームのソフトウェア開発マネージャーです。他の Glue チームメンバーと協力し、お客様の役に立つサービスを作るのが好き。仕事以外では、釣りをしたり、カラオケを歌ったりしています。 Matt Su は、AWS Glue チームのシニアプロダクトマネージャーです。彼は AWS Analytic サービスを使って顧客がインサイトを発見し、データを使ってより良い意思決定をするのを支援することを楽しんでいます。趣味はスキーとガーデニング。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

閉会です！ NRF 2023 が終了しました。今年、NRF 2023 に参加された皆様、本当にありがとうございました！NRF 2023 を見逃した方は、ぜひこの記事をご覧ください。 出展者によるビッグアイディア( Exhibitor Big Ideas )スピーキングセッションから得た重要なポイント 今年は、AWS 主催の出展者によるビッグアイディアセッションで、 Chico’s と AWS パートナーである fabric 、 Carter’s 、 Neiman Marcus Group 、 Compass Digital と Just Walk Out technology by Amazon の話を聞きました。各セッションの録画はこちらからご覧いただけます。 コンポーザブルコマースにより、Chico’s はシームレスなブランド体験を提供する モバイル POS と RFID ソリューションを AWS で構築し展開する Neiman Marcus による、AWS で高級小売店を変革するクラウドジャーニー Amazon の Just Walk Out テクノロジーがカスタマージャーニーをどう進化させるか お立ち寄りいただけましたでしょうか 注目のデモからRetail TechTalks まで、私達のブースは AWS パートナー、小売業界のお客様、Amazon 、そして AWS のエキスパートと関わる機会で溢れていました。 NRF 2023 での体験を振り返るプロモーションビデオをご覧いただくか、RIS ニュースの記事「 Best of NRF 2023 :トップ 10 の収穫 」にて詳細をご覧ください。 お客様からの声をお聞きください NRF で AWS のお客様を取材し、小売業界を支える AWS のテクノロジーについてお聞きしました。 AWS を活用した Pilot Company のデジタルトランスフォーメーションについてご紹介します。 Vijay Karthik 氏による AWS を活用した Neiman Marcus Group のデジタルトランスフォーメーションについてご紹介します。 Sriram Vaidyanathan 氏による AWS を活用した Neiman Marcus Group の デジタルトランスフォーメーションについてご紹介します。 ALDO と Fluent Commerce の AWS を活用したオムニチャネルソリューションについてご紹介します。 NRF 2023 での注目デモ ユニファイドコマースの実践 NRF Big Show は終了しましたが、展示されたテクノロジーの詳細は当社のウェブサイトでご覧いただけますし、当社のスペシャリストに質問することもできます。 Just Walk Out Amazon の Just Walk Out テクノロジーで小売体験を向上させる フリクションレスチェックアウトは最新の実店舗テクノロジーです。何千人ものカンファレンス参加者が AWS のブースに立ち寄り、 Just Walk Out by Amazon 、 Dash Cart 、 Amazon One のテクノロジーを見学しました。 実店舗での手間のかからない購買体験に関して言えば、Amazon による Just Walk Out テクノロジーは、 Amazon Go 、 Amazon Fresh 、 Whole Foods Market の店舗でのニュースタンダードを確立し、米国とヨーロッパの小売企業にも支持されています。詳しくは、最新のブログ「 Retail’s Big Showが再び開催：NRF 2023 の 3 つのポイント 」をお読みください。 イマーシブコマース デジタル顧客体験の進化を理解する デジタルコマースは、消費者がより幅広い品揃えと、いつでもどこでも低価格で買い物ができることを求める世界でデジタルコマースが加速しています。デジタルチャネルは、実店舗よりも先に訪れる場所となっており、オンライン消費者は、ボイスコマース、インタラクティブなライブストリームビデオ、AR /バーチャルリアリティ（ VR ）、ML を活用したパーソナライゼーションなど、新鮮で魅力的な体験を求めています。AWS は、Amazon.com での経験を活かしてデジタルコマースの未来を再定義し、小売企業が業界のイノベーションを取り入れ続けることに役立ちます。 展示会では、ビルダーとバイヤーの両方にとってわくわくするエキサイティングな新しいテクノロジーソリューションの数々を小売企業に紹介しました。以下はその概要です。 小売企業におけるパーソナライズ 小売企業には、パーソナライズを使用することで、消費者への製品レコメンドを改善し、コンバージョンを増やす機会が得られます。 また、 Amazon Personalize では、 パーソナライズされたレコメンドがビジネス目標の達成にどのように役立つ かを測定することができます 。 Goodbye, generic shopping：顧客の小売体験をパーソナライズする 3 つの方法 、または、 最新のeBook「 How to supercharge your retail personalization capability for boosted sales and deeper insights（小売業界のパーソナライゼーション能力を強化し、売上を増やし深い洞察力を高める方法） 」をご覧ください。 ライブストリームコマース Amazon Interactive Video Service ( Amazon IVS ) を利用して、小売企業は VTEX , eStreamly , Firework , StreamShop のような企業の技術を取り入れ、何百万人もの顧客を魅了し、購入に導いています。最近のブログ「 Experience immersive commerce at NRF 2023 」や、 AWS 上のライブストリーミングコマースの寸評については最新の資料 をご覧ください。 3D プロダクトビジュアライゼーションとイマーシブ OS イマーシブコマースのデモエリアでは、複数の AWS パートナーソリューションが紹介されました。その中には、Hexa のリアルで見事な AR を駆使した 3D プロダクトビジュアライゼーションがあり、消費者は購入前に、プロダクトが自宅や体、顔にどのようにフィットし、どのように見えるかを確認することができます。 また、 Hexa は 、 商品を素敵に見せながら、サステナビリティの目標を達成 するのにも役立ちます。デモのリクエストは こちらから 。 バーチャルストア AWS パートナーの Obsess は 、AR を使用してウェブ上に 360 度の 3D デジタルストアを生成し、買い物客が実店舗にいるかのように商品を閲覧できる、体験型 e コマースのためのバーチャルストアを紹介しました。強化された顧客体験がどのようにコンバージョンを増加させるかについては、 Sainsbury’s , Zappos , Morrisons などのブランドがどのように AWS を使用して前例のない顧客とのつながりを提供しているかについて深く掘り下げるため、この最新のeBook「 Navigating the new world of digital commerce in retail 」をご覧ください。 デジタルコマース もうひとつの人気デモでは、 Buy with Prime が紹介されました。 Buy with Prime は、direct-to-consumer（ DTC ）ビジネスを成長させる新しい方法を提供しながら、 買い物客のコンバージョンを平均 25 ％増加させること が示されており、あなたのサイトに Buy with Prime を追加する方法も紹介されました。Buy with Prime は、米国の数百万人のプライム会員が、Amazon に期待する信頼性の高い体験で、加盟店のオンラインストアから直接買い物をすることができます。2023 年 1 月 31 日までに、Buy with Prime は招待制ではなくなり、より多くの米国の加盟店が利用できるようになる予定です。詳細は こちら をご覧ください。 e コマースの成長を促進するためのトレンドと投資についてもっと知りたい方は、NRF の Retail TechTalk に選ばれた 40 セッションの 1 つを、AWS パートナーである VTEX と VTEX のレジデンスアナリストと共に紹介したこの 新しいレポート をお読み下さい このレポートでは、大手ブランドや小売企業が、顧客獲得、フルフィルメント、在庫、新しい顧客エンゲージメントモデルよりも顧客維持に投資している分野を取り上げています。 カスタマーインサイト 物理チャネルとデジタルチャネルを横断して顧客を知る 小売企業は長い間、オンラインにおける顧客の行動情報は収集できていましたが、実店舗における情報収集が課題でした。現在、AWS は滞留時間、ヒートマップ、購入までの経路に関する重要なインサイトを明らかにするために、カメラと AI/ML 技術を使用して、店舗での顧客の行動を記録し、デジタル化するのに役立ちます。 店舗分析の恩恵を理解する上で、店舗内の洞察を深め、分析能力を高めることが期待される エッジコンピュータビジョンソリューション 、 AWS Panorama の能力を紹介しました。詳しくはこちらのブログ「 AWS shows why physical stores more matter than ever at NRF 2023 」をご覧ください。 オンラインでは、閲覧できる選択肢や発見できるプロダクトは非常に多く、消費者が直線的に買い物をしないことは周知の事実です。その代わりに、ソーシャルメディアやウェブサイト、E メールキャンペーンやターゲティング広告、実店舗でのショッピングなど、消費者はさまざまなチャネルを利用しています。カスタマーデータプラットフォーム（ CDP ）は、小売企業が顧客の 360 度ビューを構築するのに役立ちます。 ActionIQ のような AWS 上の CDP は、カスタマーエクスペリエンス、デジタルトランスフォーメーション、そして中核的な企業資産としての顧客データの価値についてのブランドの考え方に革命をもたらします。 オンデマンドの ActionIQ デモ を見るか、「 なぜ小売企業は顧客 360 戦略を強化するために CDP が必要なのか 」についてのこのブログを読み、AWS を活用してエンタープライズレベルの CDP を提供する AWS パートナーをお探し下さい。 リテールオペレーション 計画からラストワンマイルまでの小売バリューチェーンの最適化 リテールプランニングとオペレーションのデモエリアでは、AWS がどのように小売業界が最初の予測から注文の配送までオペレーションを推進するのに役立つかを紹介しました。このデモでは、 Amazon Forecast のような AWS サービスが、 Amazon.com が何百万もの商品を予測するために使用しているのと同じテクノロジーをどのように使用しているかについて掘り下げています。Amazon Forecast は時系列予測サービスであり、機械学習を使って小売店の在庫をプレシーズンから店舗/ SKU の詳細まで予測します。私たちは、 Amazon Supply Chain が小売企業のフルフィルメントニーズを大規模に処理する方法を紹介しました。小売企業は Amazon Supply Chain を利用することで、97 %以上の納期遵守率で最短 1 日で注文を届けることができます。また、 AWS Supply Chain は、リプラットフォーム、前払いライセンス料、長期契約なしで、小売企業が既存の ERP やサプライチェーン管理システムに接続できることも紹介しました。 AWS Supply Chain のデータレイク、インサイト、需要計画などを どのように 利用できるかをご覧ください。 AWS と MACH アライアンス Retail’s Big Show の期間中、私たちは MACH アライアンス が主催する MACH Haus を訪れ、パートナーやお客様（ fabric 、 Constructor.io 、 VTEX 、 Fluent Commerce 、 Pivotree 、 commermeretools など）と交流し、コンポーザブルコマースの採用やモノリシックアーキテクチャとの決別について話し合うことができました。MACH を採用することで、絶え間ないリプラットフォームのサイクルから脱却し、アップグレードの手間をかけずに、市場投入のスピード向上、リスクの低減、シームレスなカスタマイズへの道筋を提供する最善の戦略を活用することができます。 AWS Partners in MACH のインフォグラフィックをダウンロード >> 2023 年 6 月 13 日～ 14 日に アムステルダムで開催される MACH Two カンファレンス に AWS が参加します。 Retail for Good AWS は、最大手の小売とテクノロジー分野のエグゼクティブが一堂に会してネットワーキングを行う RetailROI（Retail Orphan Initiative）の SuperSaturday イベントのスポンサーも務めました。しかし、このイベントの究極の目的は、世界中の孤児や里親制度の子どもたちを支援するための資金調達と解決策の創出でした。私たちは、このイベントで $384,000 の寄付金を集めることができたことを嬉しく思っています。イベントの詳細は こちら をご覧ください。 来年までに 今年の NRF チャプターは終了しましたが、だからといって楽しみや学びが終わるわけではありません。AWS のサービスや機能にご興味がある方は、 AWS for Retail を、ご覧いただき、小売業界のイノベーションを加速させる革新的なテクノロジーをご覧ください。 著者について Renata Melnyk Renata Melnyk は、AWS で消費財および小売業界のパートナーマーケティングにおけるグローバルリーダーであり、AWS 業界のビジネスリーダーと AWS パートナーと共に戦略的な市場開拓イニシアチブをグローバル規模で計画、構築、実行できるよう支援しています。Renata Melnyk の AWS での経験は 10 年近くに渡り、AWS ワールドワイドパブリックセクター、AWS スタートアップ、AWS パートナー、AWS プロダクトマーケティング、AWS パートナーマーケティング組織などの中核となるビジネス分野で働いてきました。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

AWS スマートストアソリューションでイノベーションを加速するための主な質問と戦略 小売の世界では、e コマースの台頭や、ショッピング体験におけるデジタル機器の普及が進み、デジタル変革が続いています。さらに、Covid-19 の大流行は、小売のデジタルツール、エクスペリエンス、テクノロジーの採用を加速させました。店舗が再開され、世界がニューノーマルに移行した今も実店舗は依然として重要な役割を果たすと考えられます。 新たな顧客ニーズに対応するため、小売企業はデジタルトランスフォーメーションのメリットを実店舗にもたらす方法を模索しています。実店舗がすぐに無くなるわけではありません。実際、実店舗は今や一層重要になっています。なぜなら店舗は、買い物客にとって、商品を発見し、リサーチし、見て、手にとって、購入するための人気の場所であり続けているからです。依然として実店舗が 小売売上全体の売上の約 80 ％ を占めているのは、驚くべきことではありません。 アマゾン ウェブ サービス（ AWS ）の スマートストアソリューション は、クラウドベースのテクノロジーを活用し、顧客と小売企業双方の店舗体験を向上させる次世代の実店舗イノベーションです。 NRF 2023 のブログ記事で紹介したように、AWS は実店舗における小売企業を支援する方法に改めてフォーカスしています。 ソリューションの選択肢はたくさんあり、どこから始めればいいのか、どこに焦点を当てればいいのか、圧倒されるかもしれません。そこで AWS がお役に立ちます。このブログでは、小売企業がクラウドジャーニーを歩んでいるのか、あるいはまだ歩みを始めたばかりなのかに関わらず、スマートストアの取り組みを評価し、優先順位をつけるために取るべき重要な質問と戦略を紹介します。 深く掘りさげることから始めましょう スマートストアソリューションの導入に向け、小売企業はまず既存のインフラストラクチャ、オペレーション、顧客体験、データ能力について深く掘り下げることから始める必要があります。この深掘りする段階では、スマートストアソリューションから恩恵を受ける可能性のあるビジネス領域を特定するのに役立つだけでなく、重要な質問に対する洞察も得ることができます。 インフラストラクチャ に関しては、小売企業は現在のシステムを評価し、システムの限界や改善すべき点を特定する必要があります。これには、POS システム、在庫管理ツール、その他のバックエンドシステムの評価も含まれます。主な質問は以下の通りです： システムは統合されており、拡張可能ですか？ システム間でデータを収集、共有できていますか？ 店舗で利用可能な帯域幅は十分に確保されていますか？サービス品質に関する制限はありますか？ 取り扱う SKU の数と取引量はどのくらいありますか？ 店舗サーバーを廃止しますか？それともハードウェアを再利用しますか？ 深掘りのプロセスにおいて、 オペレーション は小売企業にとって非常に重要な分野です。これには、人員配置、トレーニング、ワークフローなど、店舗運営の現状を評価し、改善点を特定することが含まれます。主な質問は以下の通りです： コスト削減と効率化のために、どのオペレーションを合理化できますか？ 店舗のスタッフは、スマートストアテクノロジーを支えるために必要なデジタルツールやプラットフォームを備えていますか？ 在庫管理と在庫補充のための、最適化されたビューとプロセスを持っていますか？ すべての機器の故障を監視できますか？ 顧客や従業員に対する安全対策はどうなっていますか？ 棚割り計画の検証、スケジューリング、コミュニケーション、トレーニングなどのタスクを自動化していますか？ 小売企業は、自社の データ能力 を評価し、データをどのように活用すれば、洞察と改善を促進できるかを判断する必要があります。これには、現在のデータ収集、分析ツールの評価だけでなく、新たな機能への投資が必要と思われる分野の特定も含まれます。主な質問は以下の通りです： 現在、どのようなデータを収集し、どのように分析していますか？ 店舗運営を最適化し、顧客体験を向上させるために、どのようにデータを活用し、統合していますか？ データプライバシーに関する、どのような懸念を考慮する必要がありますか？ データビューにて顧客を360度把握できていますか？ 最後に、 顧客体験 について、小売企業は、顧客が店舗とどのように接しているかを調査し、課題点や改善の機会を特定すべきです。これには、店舗のレイアウト、看板やディスプレイの効果、接客の質などを評価することも含まれます。主な質問は以下の通りです： 顧客一人ひとりのショッピング体験をパーソナライズするにはどうすればよいですか？ 顧客の購入に至るまでの道のりや、彼らがどこに住んでいるのかを知っていますか？ 店内で顧客にマーケティングができていますか？ チェックアウトと支払いプロセスは合理化されていますか？ 在庫数は正確ですか？在庫切れは頻繁に発生しますか？ これらの分野を深く掘り下げ、重要な質問を投げかけることで、小売企業は自社の現状をより深く理解し、スマートストアソリューションが最大の効果を発揮できる分野を特定することができます。これにより、取り組みに優先順位をつけ、スマートストアを目指すための明確なロードマップを策定することができます。 お客様にこだわる 前のセクションでは、顧客体験について考慮すべき重要な質問をいくつか取り上げました。顧客体験を最適化するもう一つの方法は、エンド・ツー・エンドのカスタマージャーニーを全体的に捉えることです。これには、ジャーニーの各ステップを特定し、各タッチポイントでの体験を向上させるために、どのスマートストアソリューションを活用できるかを判断することが含まれます。 このプロセスの最初のステップは、ブランドに対する最初の認識から購入後のサポートまで、カスタマージャーニーをマッピングすることです。この際、ジャーニーをオンラインでの閲覧、実店舗への来店、購入、カスタマーサポートへの問い合わせなど、個別のステップや接点に分解することが必要になります。ジャーニーをこれらのステップに分解することで、小売企業は各ステージにおける課題や改善の機会を特定することができます。図 1 と図 2 は、ファッションとコンビニエンスストアセグメントの例です。 図 1 – ファッション小売業の消費者ジャーニーにおける Amazon と AWS のソリューション連携 図 2 – コンビニエンスストアの消費者ジャーニーにおける Amazon と AWS のソリューション連携 カスタマージャーニーがマッピングされると、小売企業は、各接点での体験を向上させるために導入できるスマートストアソリューションの可能性を評価することができます。例えば、ジャーニーの前段階では、 Hexa や Matterport など AWS リテールコンピテンシーパートナーの イマーシブリテールやバーチャル試着の技術 を導入し、顧客が自身の環境で商品をイメージできるようにすることが考えられます。 実店舗の段階では、小売企業は AWS Panorama コンピュータビジョンテクノロジーを使って、 消費者行動の分析と洞察 を得たいと思うかもしれなません。これにより、小売企業は顧客が店内を移動する際に、 パーソナライズされたオファーやレコメンデーション を送ることができます。 購入の段階では、小売企業は POS /コマースプラットフォーム（ AWS Retail コンピテンシーパートナーの NewStore 、 XY Retail 、 VTEX 、 Spryker ）やチェックアウトソリューション（ Just Walk Out 、 Dash Cart 、 Amazon One ）を強化することで、待ち時間を減らして全体的なチェックアウト体験を改善したいと考えるかもしれません。最後に、購入後の段階では、小売企業はチャットボットを導入したり、 Amazon Personalize を使用してパーソナライズされたカスタマーサポートや広告を提供したりするとよいかもしれません。 小売企業は、スマートストアの導入に段階的なアプローチを取ることで、カスタマージャーニーの中でスマートストアソリューションが最も大きな効果を発揮できる領域を特定し、導入に向けた明確なロードマップを策定することができます。これにより、顧客がシームレスでパーソナライズされたショッピング体験を提供する小売店に再び来店する可能性が高くなるため、顧客体験を向上させるだけでなく売上とロイヤルティの向上にもつながります。 ジャーニー全体にわたってこれらのソリューションを統合することで、小売企業はあらゆるステップでデータ、分析、洞察を得ることできるようになります。 データを取得することで、顧客の行動や嗜好を理解し、マーケティングキャンペーンの効果を追跡、在庫管理を最適化、新たな成長機会を特定することができるため、小売企業は計り知れない価値を引き出すことができます。スマートストアソリューションがカスタマージャーニーのあらゆるステップ毎にデータを取得することで、より良い顧客体験、売上増加、業績向上につながるデータ駆動形の意思決定を行うことができます。 すべてを一つにまとめる 深く掘り下げることを終え、カスタマージャーニーを評価した後、小売企業はスマートストアソリューションが最も効果を発揮する分野に優先順位をつけます。これには、人流を最適化するための店舗レイアウトの改善、顧客データに基づくパーソナライズされたレコメンデーションの導入、在庫管理の改善のためのデータ活用などが考えられます。 優先順位のつけ方については、潜在的な影響と導入のしやすさの組み合わせに基づくべきです。小売企業は、顧客体験と売上に最も大きな影響を与え、かつ既存のインフラストラクチャやリソースの範囲内で導入可能なソリューションに焦点を当てるべきです。 AWS スマートストア は、クラウドベースのテクノロジーを活用し、顧客と小売企業の双方にとっての店舗体験を向上させる次世代の実店舗ソリューションです。発見と深掘りを完了し、影響度と実現可能性に基づいて優先順位をつけ、クラウド変革のジャーニーに乗り出すことで、小売企業は AWS スマートストアソリューションのメリットを享受し始めることができます。適切なテクノロジーと戦略によって、実店舗は今後も小売業界において重要な役割を果たし続けることができるはずです。 AWS と AWS リテールコンピテンシーパートナー がスマートストアソリューションで小売業の変革をどのようにサポートできるかをご覧ください。詳細は aws.amazon.com/retail/ をご覧ください。 さらに読む 小売業務を効率化する7つのスマートな店舗戦略 スマートストアの実現：小売業が体験を向上させ、効率的に運営し、ITアジリティを実現する方法 よりスマートな小売店舗を構築するための3つの戦略 著者について Justin Swagler Justin Swagler は、AWS のワールドワイド・フィジカルリテール部門の責任者として、フィジカルリテールに関するグローバル戦略とソートリーダーシップをリードしています。Justin は、イノベーション戦略、リテールオペレーション、プロダクト開発、エグゼクティブリーダーシップ、消費財、小売、戦略分野で15年以上の経験を持っています。組織を戦略的に革新し、消費者体験を再発明することに情熱を注いでいます。イリノイ大学アーバナ・シャンペーン校で学士号、ケロッグ経営大学院でMBAを取得。 翻訳は Solutions Architect 圓山が担当しました。原文は こちら です。

今年 1 年間で極めて大きな AWS イベントである re:Invent 2023 で熱気に包まれるラスベガスへようこそ! 11 月 27 日から 12 月 1 日にかけて開催される re:Invent 2023 では、基調講演、トレーニング、イノベーショントーク、AWS Builder Labs などを提供するほか、クラウドジャーニーのきっかけとなるさまざまなイベントを催しています。 現地参加が難しい場合もご安心ください。 基調講演のライブストリームをご視聴いただけます。また、このページでは、極めて興味深い製品のリリースに関する最新情報を毎日提供しています。 あらゆる情報を見逃すことがないように、他にも情報を取得するための方法をいくつかご用意しています。 AWS ニュースブログ 最新情報 公式 AWS ポッドキャスト AWS On Air (この記事の最終更新日時:2023 年 11 月 26 日午後 5 時 5 分 (PST)) Use natural language to query Amazon CloudWatch logs and metrics (preview) 運用データの操作を容易にするために、Amazon CloudWatch は、Logs および Metrics Insights 用の自然言語クエリ生成を導入します。 Increase collaboration and securely share cloud knowledge with AWS re:Post Private re:Post Private には、組織のメンバーと AWS アカウントチームのためのプライベートディスカッションやコラボレーションフォーラムとともに、組織のユースケースに合わせて特別にカスタマイズされたコンテンツが含まれています。 Use anomaly detection with AWS Glue to improve data quality (preview) この新機能は、機械学習を使用して統計的な異常や、異常なパターンを検出することにより、データ品質を改善するのに役立ちます。 Mutual authentication for Application Load Balancer reliably verifies certificate-based client identities この新機能を使用することで、Application Load Balancer にクライアント認証をオフロードできるようになりました。これにより、信頼されたクライアントのみがバックエンドアプリケーションと通信する状況を確実に実現できます。 Check your AWS Free Tier usage programmatically with a new API API は AWS コマンドラインインターフェイスで直接使用することも、AWS SDK を使用してアプリケーションに統合することもできます。 Use Amazon CloudWatch to consolidate hybrid, multicloud, and on-premises metrics Amazon CloudWatch を利用して、ハイブリッド、マルチクラウド、オンプレミスのデータソースから得られたメトリクスを統合し、一貫性のある統一された態様で処理できるようになりました。 Announcing cross-region data replication for Amazon WorkSpaces スナップショットは 12 時間ごとに作成され、目的のターゲットリージョンにレプリケートされます。このスナップショットは、12～24 時間のリカバリポイント目標を提供するために使用されます。 Amazon Transcribe Call Analytics adds new generative AI-powered call summaries (preview) Amazon Bedrock を利用するこの機能は、カスタマーサービスへの電話を自動的に要約することで、企業がカスタマーエクスペリエンスを改善し、エージェントとスーパーバイザーの生産性を高めるのをサポートします。 Build generative AI apps using AWS Step Functions and Amazon Bedrock Step Functions は、Amazon Bedrock 向けに最適化された 2 つの新しい API アクションである InvokeModel および CreateModelCustomizationJob を提供します。 New Cost Optimization Hub centralizes recommended actions to save you money この新しい AWS Billing and Cost Management 機能により、AWS のコスト最適化に関するレコメンデーションを簡単に特定、フィルタリング、集計、定量化できます。 Amazon CloudWatch Logs now offers automated pattern analytics and anomaly detection Amazon CloudWatch は、ログレコードのパターンを自動的に認識してクラスター化し、注目すべきコンテンツや傾向を抽出して、高度な機械学習アルゴリズムを使用して異常を通知できるようになりました。 Amazon Managed Service for Prometheus collector provides agentless metric collection for Amazon EKS この新機能は、Amazon Elastic Kubernetes Service (Amazon EKS) から Prometheus メトリクスをエージェントなしで自動的に検出および収集します。 Optimize your storage costs for rarely-accessed files with Amazon EFS Archive ほとんどアクセスされない長期保存データ向けに最適化された、Amazon Elastic File System の新しいストレージクラスが追加されました。 New Amazon CloudWatch log class for infrequent access logs at a reduced price この新しいログクラスは、アクセス頻度の低いログ用にカスタマイズされた機能セットを低コストで提供するため、お客様は費用対効果の高い方法ですべてのログを 1 か所にまとめることができます。 原文は こちら です。

12月21日、 Amazon Aurora および Amazon Relational Database Service (Amazon RDS) で実行されている MySQL 5.7 と PostgreSQL 11 のデータベースインスタンスが、2024 年 2 月 29 日から Amazon RDS 延長サポートに自動登録されることが発表されました。 このサポートは、新しいメジャーバージョンへの自動アップグレードによって発生する可能性のある予定外のダウンタイムや互換性問題の回避に役立ちます。また、データベースのメジャーバージョンにアップグレードするタイミングをよりよく制御できるようにもなります。 RDS 延長サポートの開始時には、この自動登録によって料金請求額が割高になる可能性があります。これは、RDS 延長サポートの開始前にデータベースを新しい DB バージョンにアップグレードすることで回避できます。 Amazon RDS 延長サポートとは? 2023 年 9 月、 Amazon RDS 延長サポートが発表 されました。このサポートでは、追加料金を支払うことによって、RDS 標準サポート終了日を過ぎてからも、メジャーエンジンバージョンを使用するデータベースを Amazon Aurora または Amazon RDS で引き続き実行することができます。 コミュニティサポート終了 (EOL) までは、MySQL と PostgreSQL のオープンソースコミュニティがそれぞれのエンジンの CVE (Common Vulnerabilities and Exposures: 共通脆弱性識別子)、パッチ生成、およびバグ修正を管理します。コミュニティは、データベースのメジャーバージョンがコミュニティサポート終了になるまで、これらのセキュリティパッチとバグ修正が含まれた新しいマイナーバージョンを四半期ごとにリリースします。コミュニティサポート終了日が過ぎると、CVE パッチやバグ修正が利用できなくなり、コミュニティはこれらのエンジンをサポート対象外と見なします。例えば、MySQL 5.7 と PostgreSQL 11 は、それぞれ 2023 年 10 月および 11 月の時点でコミュニティのサポート対象外になっています。コミュニティには、これらのメジャーバージョンの継続的なサポートと、最新メジャーバージョンへの移行に対する透過的なプロセスとタイムラインについて、大変感謝しています。 RDS 延長サポートでは、メジャーバージョンのコミュニティ EOL 以降の最大 3 年間、Amazon Aurora と RDS が重要な CVE パッチとバグ修正のエンジニアリングを引き受けます。この 3 年間は、Amazon Aurora と RDS がエンジン内の CVE とバグを特定し、パッチを生成して、可能な限り早急にリリースするように努めます。RDS 延長サポートでは、オープンソースコミュニティがエンジンのメジャーバージョンのサポートを終了しても、アプリケーションが重大なセキュリティ脆弱性や未解決のバグにさらされることがないように、AWS がサポートの提供を継続します。 AWS が RDS 延長サポートを RDS サービスの一環として提供するのではなく、料金を請求するのはなぜかと思うかもしれません。それは、コミュニティ EOL エンジンのセキュリティと機能を維持するためのエンジニアリング作業では、AWS が重要な CVE パッチとバグ修正に開発者リソースを投じる必要があるからです。このため、RDS 延長サポートは、コミュニティ EOL 日を過ぎたバージョンを利用し続ける追加の柔軟性が必要なお客様のみに料金を請求します。 特定のプラグインやカスタム機能との互換性など、特定の MySQL または PostgreSQL メジャーバージョンに対する依存関係があるときは、アプリケーションのビジネス要件を満たすうえで RDS 延長サポートが役に立つ場合があります。オンプレミスデータベースサーバー、またはセルフマネージド Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを現在実行しているという場合は、コミュニティ EOL 日以降に Amazon Aurora MySQL-Compatible Edition 、 Amazon Aurora PostgreSQL-Compatible Edition 、 Amazon RDS for MySQL 、 Amazon RDS for PostgreSQL に移行して、マネージドサービスのメリットを活かしながら、RDS 延長サポートでこれらのバージョンを引き続き使用することができます。多数のデータベースを移行する必要がある場合でも、RDS 延長サポートを利用して移行を複数のフェーズに分割することで、IT リソースに負担をかけすぎないスムーズな移行を確保できます。 RDS 延長サポートは、2024 年に RDS for MySQL メジャーバージョン 5.7 以降、RDS for PostgreSQL メジャーバージョン 11 以降、Aurora MySQL 互換バージョン 2 以上、および Aurora PostgreSQL 互換バージョン 11 以降で利用可能になります。将来サポートされるすべてのバージョンのリストについては、AWS ドキュメントで「 Amazon RDS でサポートされている MySQL のメジャーバージョン 」と「 Amazon Aurora メジャーバージョン 」を参照してください。 コミュニティメジャーバージョン RDS/Aurora バージョン コミュニティ EOL 日 RDS 標準サポートの終了日 RDS 延長サポート料金の開始日 RDS 延長サポートの終了日 MySQL 5.7 RDS for MySQL 5.7 2023 年 10 月 2024 年 2 月 29 日 2024 年 3 月 1 日 2027 年 2 月 28 日 Aurora MySQL 2 2024 年 10 月 31 日 2024 年 12 月 1 日 PostgreSQL 11 RDS for PostgreSQL 11 2023 年 11 月 2024 年 3 月 31 日 2024 年 4 月 1 日 2027 年 3 月 31 日 Aurora PostgreSQL 11 2024 年 2 月 29 日 RDS 延長サポートの料金は、1 時間あたりの vCPU 単位で設定されています。RDS 延長サポートの料金の詳細とタイムラインについては、 Amazon Aurora の料金 、 RDS for MySQL の料金 、および RDS for PostgreSQL の料金 を参照してください。詳細については、AWS データベースブログで MySQL および PostgreSQL データベースの Amazon RDS 延長サポート に関するブログ記事を参照してください。 すべてのデータベースが Amazon RDS 延長サポートに自動登録される理由 AWS は当初、RDS 延長サポートが 2023 年 12 月にオプトイン API とコンソール機能を提供すると 発表 していました。その発表では、データベースの RDS 延長サポートへの登録にオプトインしない場合は、2024 年 3 月 1 日から新しいエンジンバージョンに自動アップグレードされるとお伝えしました。例えば、Aurora MySQL 2 または RDS for MySQL 5.7 は Aurora MySQL 3 または RDS for MySQL 8.0 に、Aurora PostgreSQL 11 または RDS for PostgreSQL 11 は Aurora PostgreSQL 15 または RDS for PostgreSQL 15 にアップグレードされるという具合です。 しかし、このような自動アップグレードが、コミュニティ DB エンジンのメジャーバージョン間でアプリケーションに破壊的変更やその他予想外の動作を発生させる可能性があるという多数のフィードバックがお客様から寄せられました。例えば、アプリケーションが MySQL 8.0 または PostgreSQL 15 にまだ対応できない場合、予定外のメジャーバージョンアップグレードは互換性問題やダウンタイムを引き起こす可能性があります。 RDS 延長サポートへの自動登録により、データベースアップグレードの編成、計画、およびテストを行う時間が増え、それらを自分のタイムラインに合わせて細かく制御できるようになるので、引き続き AWS から重要なセキュリティとバグ修正を受け取りながら、新しいメジャーバージョンに移行するタイミングにおける柔軟性が得られます。 RDS 延長サポートへの自動登録によるコスト増加に関する懸念がある場合は、RDS 標準サポートが終了する前にアップグレードすることで、RDS 延長サポートと関連する料金を回避できます。 データベースをアップグレードして RDS 延長サポート料金を回避する方法 RDS 延長サポートは、自分のタイムラインに合わせてアップグレードをスケジュールするために役立ちますが、古いバージョンを無限に使い続けると、データベースワークロードに対して最高のコストパフォーマンスを実現する機会を逃すだけでなく、RDS 延長サポートで追加料金が発生することにもなります。 Aurora MySQL 3 としても知られる MySQL 8.0 on Aurora MySQL は、 Global Database 、 Amazon RDS Proxy 、 Performance Insights 、 Parallel Query 、および Serverless v2 デプロイなどの人気のある Aurora 機能のサポートを可能にします。RDS for MySQL 8.0 にアップグレードすることで、 マルチ AZ クラスター配置 、 Optimized Reads 、 Optimized Writes 、および AWS Graviton2 と Graviton3 ベースのインスタンス などの機能が提供され、MySQL 5.7 と比べて最大 3 倍 高いパフォーマンスが実現します。 PostgreSQL 15 on Aurora PostgreSQL は、 Aurora I/O 最適化設定 、 Aurora Serverless v2 、 Babelfish for Aurora PostgreSQL 、 pgvector 拡張機能 、 Trusted Language Extensions for PostgreSQL (TLE)、および AWS Graviton3 ベースのインスタンス に加えて、 コミュニティ拡張機能 もサポートします。RDS for PostgreSQL 15 にアップグレードすることで、 マルチ AZ DB クラスター配置 、 RDS Optimized Reads 、 HypoPG 拡張機能 、 pgvector 拡張機能 、 TLEs for PostgreSQL 、および AWS Graviton3 ベースのインスタンス が提供されます。 メジャーバージョンアップグレードでは、既存のアプリケーションとの下位互換性がないデータベース変更が行われる可能性があります。メジャーバージョンにアップグレードするには、データベースインスタンスを手動で変更する必要があります。メジャーバージョンアップグレードは、本番インスタンスに適用する前に非本番インスタンスで十分にテストを行って、アプリケーションとの互換性を確認することを強くお勧めします。MySQL 5.7 から 8.0 へのインプレースアップグレードの詳細については、これら 2 つのバージョン間における 非互換性 と、AWS ドキュメントの「 メジャーバージョンの Aurora MySQL インプレースアップグレード 」および「 RDS for MySQL のアップグレード 」を参照してください。PostgreSQL 11 から 15 へのインプレースアップグレードには、 pg_upgrade メソッドを使用できます。 アップグレード中のダウンタイムを最小限に抑えるため、 Amazon Aurora と Amazon RDS でのフルマネージド型ブルー/グリーンデプロイ の使用をお勧めします。ほんの数ステップで、Amazon RDS のブルー/グリーンデプロイを使用して、本番環境を反映する、個別の同期化されたフルマネージドステージング環境を作成できます。これには、本番データベースの下位バージョンの上位バージョンレプリカで並列グリーン環境を起動することが含まれます。グリーン環境を検証したら、トラフィックをその環境にシフトすることができます。その後、ブルー環境を廃棄することができます。詳細については、AWS ドキュメントで Aurora MySQL と Aurora PostgreSQL のブルー/グリーンデプロイ 、または RDS for MySQL と RDS for PostgreSQL のブルー/グリーンデプロイ を参照してください。多くの場合、ブルー/グリーンデプロイはダウンタイムを短縮するための最適なオプションです ( Amazon Aurora または Amazon RDS における限定的な状況を除く)。 各 DB エンジンでのメジャーバージョンアップグレードの実行に関する詳細については、AWS ドキュメントで以下のガイドを参照してください。 Amazon RDS 用 MySQL DB エンジンのアップグレード Amazon RDS 用 PostgreSQL DB エンジンのアップグレード Amazon Aurora MySQL DB クラスターのアップグレード Amazon Aurora PostgreSQL DB クラスターのアップグレード 今すぐご利用いただけます Amazon RDS 延長サポートは、2024 年の標準サポート終了日以降、AWS GovCloud (米国) リージョンを含めた AWS リージョンで、MySQL 5.7 および PostgreSQL 11 以降のメジャーバージョンを使用して Amazon Aurora および Amazon RDS インスタンスを実行しているすべてのお客様にご利用いただけます。RDS 延長サポートにオプトインする必要はなく、データベースをアップグレードする柔軟性を得るとともに、最大 3 年間の継続的なサポートを受けることができます。 RDS 延長サポートの詳細については、「 Amazon Aurora ユーザーガイド 」と「 Amazon RDS ユーザーガイド 」を参照してください。RDS 延長サポートの料金の詳細とタイムラインについては、「 Amazon Aurora の料金 」、「 RDS for MySQL の料金 」、および「 RDS for PostgreSQL の料金 」を参照してください。 フィードバックは、 Amazon RDS と Amazon Aurora の AWS re:Post 、または通常の AWS サポート連絡先を通じてお送りください。 – Channy 原文は こちら です。

12月20日より、 Amazon Route 53 Resolver は、インバウンドとアウトバウンドの両方の Resolver エンドポイントのために DNS over HTTPS (DoH) プロトコルの使用をサポートします。その名前が示すように、DoH は、ドメインネームシステム (DNS) 解決のために交換されるデータを暗号化することを目的として、TLS 経由で HTTP または HTTP/2 をサポートします。 DoH は、TLS 暗号化を使用して、DoH クライアントと DoH ベースの DNS リゾルバー間で交換される DNS データの盗聴や操作を防止し、プライバシーとセキュリティを強化します。 これは、ゼロトラストアーキテクチャを実装するのに役立ちます。ゼロトラストアーキテクチャでは、セキュリティ境界の内外で動作するいかなるアクター、システム、ネットワーク、またはサービスも信頼されず、すべてのネットワークトラフィックが暗号化されます。DoH の使用は、 US Office of Management and Budget (OMB) のこの覚書 に記載されているような推奨事項に従うのにも役立ちます。 Amazon Route 53 Resolver での DNS over HTTPS のサポート Amazon Route 53 Resolver を利用して、ハイブリッドクラウド環境で DNS クエリを解決できます。例えば、このサービスを利用すると、ハイブリッドネットワーク内のどこからでも AWS サービスが DNS リクエストにアクセスするのを許可できます。これを行うには、インバウンドおよびアウトバウンドの Resolver エンドポイントを設定します。 インバウンド Resolver エンドポイントを使用すると、オンプレミスネットワークまたは別の VPC から、使用している VPC への DNS クエリが可能になります。 アウトバウンド Resolver エンドポイントを使用すると、使用している VPC から、オンプレミスネットワークまたは別の VPC への DNS クエリが可能になります。 Resolver エンドポイントを設定した後、使用している VPC からオンプレミスの DNS リゾルバー (アウトバウンド)、およびオンプレミスから使用している VPC (インバウンド) に DNS クエリを転送するドメインの名前を指定するルールを設定できます。 これで、インバウンドまたはアウトバウンドの Resolver エンドポイントを作成または更新するときに、使用するプロトコルを指定できるようになりました。 ポート 53 経由の DNS ( [Do53] )。UDP または TCP のいずれかを使用してパケットを送信します。 DNS over HTTPS ( [DoH] )。TLS を使用してデータを暗号化します。 両方。DNS クライアントがどちらを使用するかによります。 FIPS の準拠 のために、インバウンドエンドポイント用の特定の実装 ( DoH-FIPS ) が用意されています。 これが実際にどのように機能するかを見てみましょう。 Amazon Route 53 Resolver での DNS over HTTPS の使用 Route 53 コンソール で、ナビゲーションペインの [Resolver] セクションから [インバウンドエンドポイント] を選択します。そこで、 [インバウンドエンドポイントを作成] を選択します。 エンドポイントの名前を入力し、VPC、セキュリティグループ、およびエンドポイントタイプ (IPv4、IPv6、またはデュアルスタック) を選択します。暗号化された DNS 解決と暗号化されていない DNS 解決の両方の使用を許可するには、 [このエンドポイントのプロトコル] オプションで [Do53] 、 [DoH] 、および [DoH-FIPS] を選択します。 その後、DNS クエリ用に IP アドレスを設定します。2 つの アベイラビリティーゾーン と、それぞれのサブネットを選択します。この設定では、サブネット内で使用可能な IP アドレスから自動的に IP アドレスを選択するオプションを使用します。 インバウンドエンドポイントの作成が完了したら、 amazonaws.com ドメイン ( AWS サービスエンドポイント によって使用されます) へのリクエストをインバウンドエンドポイントの IP アドレスに転送するようにネットワーク内の DNS サーバーを設定します。 同様に、アウトバウンド Resolver エンドポイントを作成し、プロトコルとして [Do53] と [DoH] の両方を選択します。その後、アウトバウンド Resolver エンドポイントがネットワーク内の DNS サーバーにリクエストを転送する必要があるドメインを指示する転送ルールを作成します。 これで、ハイブリッド環境の DNS クライアントがリクエストで DNS over HTTPS を使用すると、DNS 解決が暗号化されるようになりました。オプションで、暗号化を強制し、インバウンドエンドポイントとアウトバウンドエンドポイントの設定で [DoH] のみを選択できます。 留意点 Amazon Route 53 Resolver の DNS over HTTPS のサポートは、GovCloud リージョンおよび中国に拠点を置くリージョンを含む、Route 53 Resolver が提供されているすべての AWS リージョン で現在ご利用いただけます。 ポート 53 経由の DNS は、引き続きインバウンドまたはアウトバウンドの Resolver エンドポイントのデフォルトです。この方法では、DNS over HTTPS を採用しない限り、既存のオートメーションツールを更新する必要はありません。 Resolver エンドポイントで DNS over HTTPS を使用する場合、追加料金はかかりません。詳細については、「 Route 53 の料金 」をご覧ください。 Amazon Route 53 Resolver で DNS over HTTPS の使用を開始して、ハイブリッドクラウド環境のプライバシーとセキュリティを強化しましょう。 – Danilo 原文は こちら です。

12月20日、カナダで新しいリージョンがオープンしました。AWS カナダ西部 (カルガリー) は、 ca-west-1 とも呼ばれ、33 番目の AWS リージョンです。これは 3 つのアベイラビリティーゾーンで構成されます。これにより、世界中のアベイラビリティーゾーンの合計数は 105 となります。 この 2 つ目のカナダリージョンにより、データを国内に保持しながら、 ファイブナインの可用性 を満たすマルチリージョンインフラストラクチャを設計できます。 世界的なフットプリント インフラストラクチャの構築に対する当社のアプローチは、他のプロバイダーとは根本的に異なります。当社のグローバルインフラストラクチャの中核にはリージョンがあります。AWS リージョンは、複数のアベイラビリティーゾーンが存在する世界中の物理的な場所です。アベイラビリティーゾーンは 1 つ以上の個別のデータセンターで構成されており、それぞれが冗長的な電源、ネットワーキング、および接続を備え、別々の施設に存在しています。リージョンを単一のデータセンターとして定義することが多い他のクラウドプロバイダーとは異なり、複数のアベイラビリティーゾーンを利用することで、単一のデータセンターと比較して、可用性、耐障害性、スケーラビリティにより優れた本番アプリケーションおよびデータベースを運用できます。 AWS には、17 年を超える期間にわたってグローバルインフラストラクチャを構築してきた経験があります。また、経験についての圧縮アルゴリズムはありません。このことは、特にスケール、セキュリティ、パフォーマンスに関して当てはまります。 BlackBerry 、 CI Financial 、 Keyera 、 KOHO 、 Maple Leaf Sports & Entertainment (MLSE)、 Nutrien 、 Sun Life 、 TELUS などのグローバルブランド、 Good Chemistry や Cohere などのスタートアップ、 University of Calgary や Natural Resources Canada (NRCan) などの公共部門の組織を含む、あらゆる規模のカナダのお客様は、既に AWS でワークロードを実行しています。これらのお客様は、セキュリティ、パフォーマンス、柔軟性、そしてグローバルプレゼンスを理由として AWS を利用しています。 AWS Local Zones および AWS Outposts を含む、 AWS グローバルインフラストラクチャ により、お客様はネットワークレイテンシーを最小限に抑えるために、自らの近くにワークロードを柔軟にデプロイできます。例えば、AWS の柔軟性の恩恵を受けているお客様には、カナダの脱炭素化テクノロジーのスケールアップである BrainBox AI が含まれています。BrainBox AI は、AWS 上でクラウドベースの人工知能 (AI) と機械学習 (ML) を使用して、世界中の建物所有者が HVAC 排出量を最大 40 % 削減したり、エネルギー消費量を最大 25 % 削減したりするのをサポートしています。AWS グローバルインフラストラクチャにより、同社のソリューションは 20 を超える国々に存在する何百もの建物を、毎日 24 時間、低レイテンシーで管理できます。 利用可能なサービス ワークロードは、C5、M5、M5d、R5、C6g、C6gn、C6i、C6id、M6g、M6gd、M6i、M6id、R6d、R6i、R6id、I4i、I3en、T3、T4g インスタンスファミリーのいずれかにデプロイできます。新しい AWS カナダ西部 (カルガリー) では、オープン時点で 65 の AWS サービスを利用できます。一覧を次に示します (アルファベット順): Amazon API Gateway 、 AWS AppConfig 、 AWS Application Auto Scaling 、 Amazon Aurora 、 Aurora PostgreSQL 、 AWS Batch 、 AWS Certificate Manager 、 AWS CloudFormation 、 Amazon CloudFront 、 AWS Cloud Map 、 AWS CloudTrail 、 Amazon CloudWatch 、 Amazon CloudWatch Events 、 Amazon CloudWatch Logs 、 AWS CodeDeploy 、 AWS Config 、 AWS Database Migration Service (AWS DMS) 、 AWS DataSync 、 AWS Direct Connect 、 Amazon DynamoDB 、 Amazon ElastiCache 、 Amazon Elastic Block Store (Amazon EBS) 、 Amazon Elastic Compute Cloud (Amazon EC2) 、 Amazon EC2 Auto Scaling 、 Amazon Elastic Container Registry (Amazon ECR) 、 Amazon Elastic Container Service (Amazon ECS) 、 Amazon Elastic Kubernetes Service (Amazon EKS) 、 Elastic Load Balancing 、 Elastic Load Balancing – Gateway (GWLB) 、 Elastic Load Balancing – Network (NLB) 、 Amazon EMR 、 Amazon EventBridge 、 AWS Fargate 、 AWS Health Dashboard 、 AWS Identity and Access Management (IAM) 、 Amazon Kinesis Data Firehose 、 Amazon Kinesis Data Streams 、 AWS Key Management Service (AWS KMS) 、 AWS Lambda 、 AWS マネジメントコンソール 、 AWS Marketplace 、 Amazon OpenSearch Service 、 AWS Organizations 、 Amazon Redshift 、 Amazon Relational Database Service (Amazon RDS) 、 AWS Resource Access Manager 、 Resource Groups 、 Amazon Route 53 、 AWS Secrets Manager 、 AWS Security Hub 、 AWS Security Token Service 、 Service Quotas 、 AWS Shield Standard 、 Amazon Simple Notification Service (Amazon SNS) 、 Amazon Simple Queue Service (Amazon SQS) 、 Amazon Simple Storage Service (Amazon S3) 、 Amazon Simple Workflow Service (Amazon SWF) 、 AWS Site-to-Site VPN 、 AWS Step Functions 、 AWS Support API 、 AWS Systems Manager 、 AWS Trusted Advisor 、 Amazon Virtual Private Cloud (Amazon VPC) 、 VM Import/Export 、 AWS X-Ray 。 カナダの AWS 当社は、カナダ初の AWS リージョンである AWS カナダ (中部) が オープン した 2016 年 12 月以来、カナダのインフラストラクチャを利用してお客様やパートナーをサポートしてきました。同年、この地域のお客様により良いサービスを提供するために、トロントとモントリオールで Amazon CloudFront 拠点を 開設 しました。今日では、カナダには 10 の CloudFront ポイントオブプレゼンス (PoP) があります。その内訳は、トロントに 5 つ、モントリオールに 4 つ、バンクーバーに 1 つです。また、国内の複数の都市にエンジニアリングチームを設けています。 2016 ～ 2021 年にかけて、AWS はカナダに 25 億 7,000 万 CAD (19 億 USD) 超を投資し、2037 年までに 2 つのリージョンに最大 248 億 CAD (183 億 USD) を投資する予定です。 Statistics Canada が提供する産業連関の手法と統計表を用いた場合、計画された投資により、カナダの 国内総生産 (GDP) が 430 億 2,000 万 CAD (310 億 USD) 増加し、カナダ経済において、フルタイム換算 (FTE) で 9,300 人超に相当する雇用がサポートされると推定されます。 お客様に世界クラスのインフラストラクチャのメリットを提供することに加えて、 Amazon は 2040 年までに事業全体でネットゼロカーボンを達成することに取り組んでいるほか 、 2025 年までに 100% 再生可能エネルギーで事業を運営するという目標に向かって取り組みを進めています 。 2022 年に Amazon が消費した電力の 90% は再生可能エネルギーをその供給源としていました 。さらに、AWS は 2030 年までにウォーターポジティブになり、直接の事業で使用するよりも多くの水をコミュニティに還元するという目標を掲げています。Amazon はカナダで合計 4 つの再生可能エネルギープロジェクトを進めており、そのうち 3 つはカルガリー南部、もう 1 つはエドモントンの近くで行われています。 BloombergNEF によると、Amazon は、この国 (そして世界) 最大の再生可能エネルギーの企業購入者です。これらのプロジェクトは、カナダの 169 万世帯に電力を供給するのに十分な 230 万メガワット時 (MWH) を超えるクリーンエネルギーを生成します。 教育も当社の最優先事項の 1 つです。2017 年以来、当社は無料および有料の AWS トレーニングと認定 プログラムを通じて、200,000 人を超えるカナダの人々に対して、クラウドコンピューティングのスキルについてのトレーニングを実施してきました。学習者は、どのようなスキルレベル、役割、背景を備えているかにかかわらず、 AWS Skills Builder において最大 14 言語で 600 超の無料オンラインコースを利用して、知識と実践的なスキルを身に付けることができます。 Amazon は、2025 年までに世界中の 2,900 万人に対して、クラウドコンピューティングスキルについての無料トレーニングを提供することに取り組んでいます 。 セキュリティ 世界中のお客様は、AWS がデータを安全に維持してくれると信頼しており、ワークロードの安全性と機密性を維持することは、当社の運営の基礎となっています。AWS の創業以来、私たちはお客様の期待に応え、さらにはそれを超えるために、セキュリティ、プライバシーツール、プラクティスを絶えず革新してきました。 例えば、データをどこに保存するか、誰がデータにアクセスできるかを決定するのはお客様です。 AWS CloudTrail などのサービスを利用すると、データがいつどのようにアクセスされるかを検証できます。当社の仮想化テクノロジーである AWS Nitro System は、顧客データに対するオペレーターのアクセスを制限するように設計されています。これは、EC2 インスタンスで利用されているデータには、AWS のユーザーやサービスさえもアクセスできないことを意味します。英国に本拠を置く先駆的なサイバーセキュリティコンサルティング企業である NCC Group は、 Nitro アーキテクチャを監査し、当社が述べる利点を認めました 。 当社の中核的なインフラストラクチャは、軍、世界的な銀行、その他の高い機密性が求められる組織のセキュリティ要件を満たすように構築されています。 カナダの Neo Financial は、ビジネスをスケールするために AWS クラウドの伸縮性を活用する金融テクノロジーのスタートアップです。同社が 2019 年に AWS を選択したのは、規制要件を満たすのを当社がサポートできるからでした。同社は、コアインフラストラクチャに EC2、耐久性の高いストレージに S3、セキュリティ体制の強化に Amazon GuardDuty 、顧客のためのパフォーマンスの改善に CloudFront を利用しています。 パフォーマンス AWS グローバルインフラストラクチャは高いパフォーマンスを実現するために構築されており、極めて低いレイテンシー、極めて少ないパケット損失、極めて優れた質の全体的なネットワークを提供します。これは、完全に冗長な 400 GbE ファイバーネットワークバックボーンによって実現され、多くの場合、リージョン間で数テラビットのキャパシティを提供します。 カナダのお客様にさらに低いレイテンシーを提供できるように、 トロントとバンクーバーに 2 つの AWS Local Zones を開設することをお知らせしました 。 お気に入りのテレビ番組をストリーミングする場合、パフォーマンスは特に重要です。カルガリーに本拠を置く Kidoodle.TV は、子ども向けのストリーミングサービスを提供しています。同社のアプリケーションは世界中で 1 億回超ダウンロードされ、2 日ごとに 10 億秒超の広告時間を販売できます。Kidoodle.TV は AWS を利用して、数十億 USD 規模の企業がデプロイできるのと同じサービスアーキテクチャを構築できました。これにより、40 万人だった月間アクティブユーザー数を、1 年間で 1,200 万人までシームレスにスケールアップできました。 その他の情報 マレーシア、ニュージーランド、タイ、および AWS European Sovereign Cloud の 4 つの将来のリージョンにおける 12 の追加のアベイラビリティーゾーンについて事前にお知らせしました。これらのリージョンに関する詳細は随時共有しますので、ご期待ください。 この新しい AWS リージョンでお客様がどのようなイノベーションを起こし、どのようなすばらしいサービスをデプロイするのかを目にするのが待ちきれません。今すぐ ca-west-1 でインフラストラクチャを構築してデプロイしましょう。 — seb 原文は こちら です。 Aujourd’hui, nous inaugurons une nouvelle Région Amazon Web Services (AWS) au Canada.La Région AWS Canada Ouest (Calgary), également connue sous le nom ca‑west‑1 , est la 33e Région AWS.Elle compte trois Zones de disponibilité, emmenant ainsi le total des Zones de disponibilité à travers le monde à 105. Cette deuxième Région au Canada vous permet d’élaborer des infrastructures multi-Régions qui demeurent disponibles 99,999 % du temps , tout en conservant vos données à l’intérieur des frontières canadiennes. Une empreinte mondiale Notre approche en matière de développement de notre infrastructure est fondamentalement différente de celle adoptée par d’autres fournisseurs.Au cœur de notre infrastructure mondiale, vous trouvez des Régions.Une Région AWS est un lieu physique dans le monde, dans lequel nous avons plusieurs Zones de disponibilité.Les Zones de disponibilité sont formées d’un ou plusieurs centres de données distincts, chacun doté de systèmes d’alimentation, de réseau et de connectivité redondants, et hébergés dans des installations séparées.Contrairement aux autres fournisseurs infonuagiques, qui définissent souvent une région comme étant un centre de données unique, le fait de pouvoir compter sur plusieurs Zones de disponibilité vous permet d’exploiter des applications et des bases de données de production ayant une plus grande disponibilité, une meilleure tolérance aux pannes et une plus importante évolutivité, allant ainsi au-delà des possibilités offertes par un centre de données unique. AWS compte plus de 17 années d’expérience dans la mise en œuvre de son infrastructure mondiale.Il n’existe pas d’algorithme de compression pour remplacer une telle expérience, surtout lorsqu’il est question d’évolutivité, de sécurité et de performances. Des clients canadiens de toute taille, dont des marques mondiales telles que BlackBerry , CI Financial , Keyera , KOHO , Maple Leaf Sports & Entertainment (MLSE), Nutrien , Sun Life et TELUS , ainsi que de jeunes pousses comme Good Chemistry and Cohere , en plus d’organismes du secteur public telles que l’ Université de Calgary et Ressources naturelles Canada (RNCan), exécutent déjà des charges de travail sur AWS.Ces entreprises et organismes ont choisi AWS pour la sécurité, les performances, la flexibilité et la présence mondiale que nous offrons. L’infrastructure mondiale AWS , dont font partie les Zones locales AWS et les AWS Outposts , offre à nos clients la flexibilité de déployer leurs charges de travail à proximité de leur clientèle, minimisant ainsi la latence du réseau.Par exemple, un de nos clients qui bénéfice de la flexibilité d’AWS est BrainBox AI , une jeune entreprise en croissance qui élabore des technologies de décarbonation.BrainBox AI utilise l’intelligence artificielle (IA) et l’apprentissage automatique (AA) basés dans le Nuage AWS pour aider des propriétaires d’édifice, partout au monde, à réduire les émissions liées aux systèmes de chauffage, de ventilation et de climatisation jusqu’à 40 %, et la consommation énergétique jusqu’à 25 %.L’infrastructure mondiale AWS permet à leur solution de gérer, avec une latence faible, des centaines d’immeubles dans plus de 20 pays, et ce 24 heures sur 24, sept jours sur sept. Services disponibles Vous pouvez déployer vos charges de travail sur n’importe laquelle des familles d’instance C5, M5, M5d, R5, C6g, C6gn, C6i, C6id, M6g, M6gd, M6i, M6id, R6d, R6i, R6id, I4i, I3en, T3 et T4g.La nouvelle Région Canada Ouest (Calgary) compte 65 services AWS, tous disponibles dès le lancement.En voici la liste, en ordre alphabétique : Amazon API Gateway , AWS AppConfig , AWS Application Auto Scaling , Amazon Aurora , Aurora PostgreSQL , AWS Batch , AWS Certificate Manager , AWS CloudFormation , Amazon CloudFront , AWS Cloud Map , AWS CloudTrail , Amazon CloudWatch , Amazon CloudWatch Events , Amazon CloudWatch Logs , AWS CodeDeploy , AWS Config , AWS Database Migration Service (AWS DMS) , AWS DataSync , AWS Direct Connect , Amazon DynamoDB , Amazon Elastic Block Store (Amazon EBS) , Amazon Elastic Compute Cloud (Amazon EC2) , Amazon EC2 Auto Scaling , Amazon Elastic Container Registry (Amazon ECR) , Amazon Elastic Container Service (Amazon ECS) , Amazon Elastic Kubernetes Service (Amazon EKS ) ,  , Elastic Load Balancing ,  , Elastic Load Balancing – Gateway (GWLB) , Amazon EMR , Amazon EventBridge , AWS Fargate , AWS Health Dashboard , AWS Identity and Access Management (IAM) , Amazon Kinesis Data Streams , AWS Key Management Service (AWS KMS) , AWS Lambda , AWS Management Console , AWS Marketplace , Amazon OpenSearch Service , AWS Organizations , Amazon Redshift , AWS Resource Access Manager ,   Resource Groups , Amazon Route 53 , AWS Secrets Manager , AWS Security Hub , AWS Security Token Service , Service Quotas , AWS Shield Standard , Amazon Simple Notification Service (Amazon SNS) , Amazon Simple Queue Service (Amazon SQS) , Amazon Simple Storage Service (Amazon S3) , Amazon Simple Workflow Service (Amazon SWF) , AWS Site-to-Site VPN , AWS Step Functions , AWS Support API , AWS Systems Manager , AWS Trusted Advisor , VM Import/Export et AWS X-Ray . AWS au Canada Nous soutenons nos clients et partenaires grâce à notre infrastructure canadienne depuis décembre 2016, lorsque la première Région AWS au Canada, soit la Région AWS Canada (Centre), a été inaugurée .Au cours de cette même année, nous avons lancé des emplacements Amazon CloudFront à Toronto et Montréal afin de mieux servir vos clients dans ces régions.Actuellement, nous comptons 10 points de présence (PdP) au Canada : cinq à Toronto, quatre à Montréal et un à Vancouver.Nous avons également des équipes d’ingénieurs basées dans plusieurs villes à travers le pays. Entre 2016 et 2021, AWS a investi plus de 2,57 milliards $ CAD (1,9 milliards $ USD) au Canada et prévoit investir jusqu’à 24,8 milliards $ CAD (18,3 milliards $ USD) dans nos deux Régions d’ici 2037.En se basant sur la méthodologie entrée-sortie et les tableaux statistiques fournies par Statistique Canada , nous estimons que les investissements prévus ajouteront 43,02 milliards $ CAD (31 milliards USD) au produit intérieur brut (PIB) du Canada et soutiendront plus de 9 300 emplois équivalents temps plein (ETP) au sein de l’économie canadienne. En plus d’offrir les avantages d’une infrastructure de classe mondiale à nos clients, Amazon s’est engagé à atteindre une empreinte carbone nette zéro pour l’ensemble de ses activités d’ici 2040 , et est en voie d’ alimenter l’ensemble de ses opérations avec des énergies 100 % renouvelables d’ici 2025 . En 2022, 90 % de l’électricité consommée par Amazon provenait de sources d’énergie renouvelables .En outre, AWS s’est donné comme objectif d’avoir un bilan positif en matière d’eau d’ici 2030, restituant ainsi plus d’eau aux communautés que la quantité utilisée pour ses activités directes.Amazon compte quatre projets d’énergie renouvelable au Canada, soit trois situés au sud de Calgary et un autre près d’Edmonton.Selon BloombergNEF , Amazon est la plus grande entreprise acheteuse d’énergie renouvelable au pays (et au monde).Ces projets génèrent plus de 2,3 millions de mégawattheures (MWh) d’énergie propre, soit suffisamment pour alimenter 1,69 million de foyers canadiens. La formation est également l’une de nos principales priorités.Depuis 2017, nous avons formé plus de 200 000 Canadiens et Canadiennes en compétences infonuagiques par le biais de programmes de formation et certification AWS gratuits et payants.Des apprenants ayant différents niveaux de compétences, de responsabilités et d’expérience peuvent acquérir des connaissances et des compétences pratiques grâce à AWS Skills Builder , qui offre plus de 600 cours en ligne gratuits en jusqu’à 14 langues. Amazon s’est engagé à offrir des formations gratuites en compétences infonuagiques à 29 millions de personnes à travers le monde d’ici 2025 . Sécurité Des clients du monde entier font confiance à AWS pour assurer la sécurité de leurs données, alors que la sécurisation et la confidentialité de leurs charges de travail sont des éléments fondamentaux de notre mode de fonctionnement.Depuis les tous débuts d’AWS, nous innovons sans relâche en matière de sécurité, d’outils de protection de la vie privée et de pratiques afin de répondre aux attentes de nos clients, et même dépasser ces attentes. Par exemple, les décisions concernant l’emplacement de stockage de vos données, et qui peut y accéder, vous appartiennent.Des services tels qu’ AWS CloudTrail vous permettent de vérifier comment et quand les données sont consultées.Notre technologie de virtualisation, AWS Nitro System , a été conçue pour restreindre l’accès de tout opérateur aux données de la clientèle.Cela signifie qu’aucun membre du personnel d’AWS, ou même un service AWS, peut accéder aux données lorsqu’elles sont utilisées au sein d’une instance Amazon Elastic Compute Cloud (Amazon EC2) .En effet, NCC Group , une des principales firmes de conseil en cybersécurité au Royaume‑Uni, a procédé à une vérification de notre architecture Nitro et a confirmé nos affirmations . Notre infrastructure de base est conçue pour répondre aux exigences de sécurité des armées, des banques mondiales, ainsi que d’autres organisations traitant des informations hautement sensibles. Basée au Canada, Neo est une jeune pousse spécialisée en technologie financière qui profite de l’élasticité du Nuage AWS pour développer ses activités.En 2019, l’entreprise a choisi AWS car nous l’avions aidée à répondre aux exigences réglementaires du secteur.Elle utilise Amazon Elastic Compute Cloud (Amazon EC2) pour son infrastructure de base, Amazon Simple Storage Service (Amazon S3) pour un stockage très durable, Amazon GuardDuty pour améliorer sa posture de sécurité, ainsi qu’Amazon CloudFront afin d’optimiser les performances de ses systèmes pour sa clientèle. Performances L’infrastructure mondiale AWS est conçue pour offrir les meilleures performances et la plus faible latence atteignable, minimiser la perte de paquets et fournir la meilleure qualité générale pour l’ensemble du réseau.Cela est rendu possible grâce à un réseau dorsal de fibre optique de 400 GbE entièrement redondant, permettant souvent plusieurs térabits de capacité entre les Régions. Afin d’offrir une latence encore plus faible à nos clients canadiens, nous avons annoncé la mise en place de deux Zone locales AWS à Toronto et Vancouver . Les performances sont davantage importantes lorsque vous visionnez la diffusion en continu de votre émission préférée.L’entreprise Kidoodle.TV , basée à Calgary, offre un service de diffusion en continu destiné aux enfants.Elle compte plus de 100 millions de téléchargements de son application à travers le monde et plus d’un milliard de secondes publicitaires à vendre par période de 48 heures.En utilisant AWS, Kidoodle.TV a pu mettre en place le même type d’architecture de service que les entreprises multimilliardaires sont en mesure de déployer.Cela a permis à l’entreprise de passer, en une année, de 400 000 à 1,2 million d’utilisateurs actifs mensuels. Informations complémentaires Nous avons annoncé 12 futures Zones de disponibilité dans quatre Régions additionnelles en Malaisie, en Nouvelle‑Zélande, en Thaïlande et la Région souveraine en Europe ; nous aurons le plaisir de partager des informations supplémentaires le moment venu. Je suis impatient de découvrir vos innovations ainsi que les extraordinaires services que vous allez mettre en œuvre au sein de la Région AWS Canada Ouest (Calgary).N’hésitez pas à développer et à déployer votre infrastructure sur ca‑west‑1 dès aujourd’hui. — Seb

12月19日、AWS India のお客様は、インド準備銀行 (RBI) のガイドラインに従って、クレジットカードまたはデビットカードを AWS アカウントに安全に保存できるようになりました。お客様は、保存したカードを使用して AWS 請求書の支払いを行うことができます。 以前は、支払いのたびに支払いカード情報をコンソールに手動で入力する必要がありました。現在、お客様は、RBI のガイドラインに従って同意することでカードをアカウントに保存できるようになりました。カードは、AWS にサインアップするとき、支払いコンソールから支払い設定にカードを追加するとき、または請求書の支払いを行うときに保存することができます。 課金用カードの保存を開始する 開始するには、 AWS Billing and Cost Management コンソールの [支払い設定] にアクセスします。 [支払い方法を追加] を選択して、デビットカードまたはクレジットカードでの支払いを追加します。 [クレジットカードまたはデビットカード] オプションを有効にして、カード情報と課金先住所を入力します。また、 [Save card information for faster future payments] (今後の支払いを迅速に行うためにカード情報を保存する) チェックボックスを選択して同意する必要があります。 カード情報を確認するために銀行のウェブにリダイレクトされます。認証後、AWS India はカードトークンを今後の支払いのために安全に保管します。カード情報は、AWS にサインアップするとき、または既存の請求書の支払いを行うときに保存することもできます。 詳細については、AWS 請求ドキュメントの「 インドでの支払いの管理 」を参照してください。 今すぐご利用いただけます この機能は、AWS India を登録販売者として、インドで発行されたデビットカードとクレジットカードを使用しているすべてのお客様がご利用いただけるようになりました。インド国外で発行されたカードには影響はありません。国外で発行されたカードは、現在と同じ方法で保存して使用できます。 カードを保存するかどうかを選択できます。ただし、購入と支払いのエクスペリエンスが以前と同様にシームレスに保たれるため、そうすることをお勧めします。 今すぐ試して、通常の AWS サポートの連絡先を介してフィードバックを送信してください。 – Channy 原文は こちら です。

Amazon Web Services (AWS) re:Invent 2023 での思い出は、ジャカルタで AWS Community Day Indonesia 参加後の作業を終えつつある今も鮮明です。チョークトークや、AWS サービスチームとの思慮に富んだディスカッションから、 AWS ヒーロー 、 AWS コミュニティビルダー 、そして AWS ユーザーグループ のリーダーたちとの出会いまで、実に素晴らしい体験でした。AWS re:Invent では、学び、つながり、イノベーションからインスピレーションを得るために、世界中の AWS コミュニティが結集します。私は、このつながりの精神こそが、AWS re:Invent をいつも特別なものにしてくれるのだと思っています。 こちらは、AWS re:Invent と AWS Community Day Indonesia でのハイライトをまとめたものです。 AWS re:Invent に参加できなかった場合でも、 オンデマンド で基調講演やセッションを視聴できます。また、すべての主要リリースに関する AWS News Editorial チームの記事、「 Top announcements of AWS re:Invent 2023 」もお読みください。 最近の AWS リリース 過去 2 週間のリリースのうち、私の目に留まったものをいくつかご紹介します。 Query MySQL and PostgreSQL with AWS Amplify  – この記事では、数回クリックするだけで MySQL データベースと PostgreSQL データベースを AWS Amplify に接続する方法を Channy  が説明します。AWS Amplify は、AWS CDK を使用してデータベーステーブルをクエリするための GraphQL API を生成します。 Migration Assistant for Amazon OpenSearch Service – このセルフサービスソリューションを使用することで、セルフマネージド型クラスターから Amazon OpenSearch Service マネージドクラスターまたはサーバーレスコレクションにスムーズに移行できます。 AWS Lambda が Amazon RDS および RDS プロキシへの接続をシンプル化 – AWS Lambda コンソールを使用して、AWS Lambda を Amazon RDS または RDS プロキシに接続できるようになりました。ガイド付きのワークフローを備えたこの改良機能は、データベースインスタンスをすばやく起動し、Lambda 関数を正しく接続するための複雑性と労力を最小限に抑えるために役立ちます。 IoT データを視覚化するための新しいノーコードダッシュボードアプリケーション – この発表に伴い、新しいオープンソースのモノのインターネット (IoT) ダッシュボードを使用して、AWS IoT SiteWise からの運用データを視覚化し、操作することが可能になりました。 Amazon Rekognition が Face Liveness の精度とユーザーエクスペリエンスを向上 – このリリースは、顔認証アプリケーションのなりすまし検知における精度を向上させます。 AWS Lambda が、クォータモニタリングを強化するための追加の同時実行メトリクスをサポート – Lambda クォータ向けの CloudWatch メトリクスを追加して、同時実行数の上限に対する可視性を向上させます。 AWS Malaysia が 3D セキュア認証のサポートを開始 – このリリースは、銀行や決済ネットワークによって義務付けられている 3DS2 トランザクション認証を有効化し、セキュアなオンライン決済を促進します。 Amazon EventBridge Pipes 向けの AWS CloudFormation テンプレート生成の発表 – この発表に伴い、CloudFormation テンプレートを使用して EventBridge リソースのデプロイを効率化することが可能になり、イベント駆動型アーキテクチャ (EDA) の開発が加速化されます。 CloudWatch Logs のデータ保護の強化 – データ保護が強化された CloudWatch Logs は、ログ内の機密データの特定とリダクションに役立ち、個人データの不慮の漏洩を防ぎます。 アジア太平洋地域内での Amazon SNS を通じた SMS の送信 – この発表に伴い、ジャカルタ地域からアジア太平洋全域で SMS メッセージングを使用できるようになりました。 AWS Lambda adds support for Python 3.12 – このリリースにより、Lambda 関数に最新バージョンの Python が導入されます。 CloudWatch Synthetics が Node.js ランタイムをアップグレード – Canary 関数に Node.js 16.1 ランタイムを使用できるようになりました。 EC2 フリートの EBS ボリュームを管理 – このリリースは、EC2 フリート全体での EBS ボリュームのアタッチと管理をシンプル化します。 来年もよろしくお願いします! この記事は、今年最後の AWS Weekly Roundup です。素晴らしい読者の皆さんに心から感謝します。次回は、2024 年 1 月 8 日週にさらなるリリース情報をお届けする予定です。 それでは、よいお年をお迎えください! –  Donnie 原文は こちら です。

あなたは空港でゲートを探すのに苦労したことはありませんか？ あなたが良く利用する旅行アプリに表示されるゲート情報が、空港ターミナルに設置されているフライトインフォメーションディスプレイスクリーン（FIDS）に表示されるデータと異なっていることがあります。特にゲート情報が変更された場合、旅行当日に混乱が生じることは想像しやすいです。 マンチェスター空港、ロンドン・スタンステッド空港、イースト・ミッドランズ空港を所有・運営する英国最大の空港グループである マンチェスター・エアポーツ・グループ （MAG）とAWSは、ヨーロッパ最大の航空会社グループであるライアンエアーと共同で、ニアリアルタイムのイベント・プラットフォームを開発しました。その目的は、ロンドン・スタンステッド空港を経由するライアンエアー388便と、MAGが毎日のピークタイムに取り扱うマンチェスター発のライアンエアー129便を同日に利用する旅行者の体験を改善することでした。 既存ツールとの連携 MAGはゲートアロケーションを管理する独自システムを持っています。MAGの空港のオペレーションチームとグランドハンドリングエージェントのメンバーは、いくつかのアプリケーションを使ってこのプラットフォームを利用しています。ゲートが変更されると、従業員が新しい情報をデータベースに入力し、旅行者が空港で見るFIDSが更新されます。 すでに持っているデータを公開 MAGは、日々のオペレーション中に発生するイベントに合わせて、社内の空港オペレーションデータベース（AODB）からオペレーションデータをフィードします。 AWS Database Migration Service （DMS）は、データベースとアナリティクスのワークロードを迅速かつ安全にAWSに移行するためのマネージド移行・レプリケーションサービスです。DMSの変更データキャプチャ（CDC）を利用し、全て野データベースの変更をイベントとして Amazon Managed Streaming for Apache Kafka (MSK)のクラスタへパブリッシュすることができます。これによりニアリアルタイムのゲート変更イベントを取得することができます。 データベースのテーブルレベルでゲート情報に変更が発生すると、Kafkaにパブリッシュされ、 Amazon Elastic Container Service （ECS）（コンテナ化されたアプリケーションのデプロイ、管理、スケーリングを容易にするフルマネージドコンテナオーケストレーションサービス）で稼働する自社開発のマイクロサービスがイベントを検出します。マイクロサービスは、CDCデータから変換を実行し、合意されたスキーマにマッピングし、データは標準化されたJSONオブジェクトとして公開します。 { "Airport": "STN", "FlightDate": "2022-12-21T10:20:00Z", "FlightNumber": "FR8753", "GateAllocationDate": "2022-12-21T09:20:08Z", "GateNumber": "36", "GateStatus": "End Boarding", "GateStatusCode": "E", "StandCode": "J45R", "Terminal": "T1" } 次にデータを利用したい航空会社がサブスクライブすることのできる公開されたトピックにデータが送られます。データを利用したい航空会社は証明書と利用するシステムのIPのレンジでセキュリティを担保し、トピックに接続しデータを利用します。 MAGのエンジニアリング責任者であるイアン・フローリーは、”「我々がKafkaを選んだ多くの理由のひとつは、どの航空会社やグラウンドハンドリングの会社でも利用しやすいオープンな技術であることです。つまり、私たちは関心を持つあらゆる関係者にほぼリアルタイムの最新情報を提供できるのです。AWS内でKafkaを実行することで、マネージドサービスの恩恵も受けることができます”と述べています。 ゲートの変更情報を活用する ライアンエアーのような航空会社は、MAGが公開するKafkaトピックにサブスクライブすることで、ゲート変更イベントを取り込むインフラを構築し利用することができます。航空会社はイベントを取り込んだ後、ネイティブ・モバイル・アプリケーションのプッシュ通知などの関連チャネルを使用して、関連する顧客にデータを公開することができます。 これにより、旅行者が空港で目にするものと、航空会社のウェブやモバイル・アプリケーションで目にするものとの間に一貫性が生まれ、旅行当日のシームレスな移動が可能になります。 2022年12月現在、この機能はロンドン・スタンステッド空港とマンチェスター空港を利用するライアンエアーの顧客に提供されており、将来的には他の空港にも拡大する予定です。 MAGのエンジニアリング責任者であるイアン・フローリーは ”これは、AWS、MAG、ライアンエアーのアジャイルなコラボレーションであり、乗客に適切な情報を適切なタイミングで提供するという目的のために、最新で堅牢な技術を使用している。”と述べました。 MAGの最高技術責任者（CTO）であるジョン・ハドソンは、”AWSとライアンエアーの両社が協力してくれることで統一したユニークなデータの見え方や、独自の洞察を見つけ出すことが可能になり、旅行者に対しよりシームレスで継続的であり、かつパーソナライズしたサービスを提供することが可能になりました。”と述べました ライアンエアーの最高技術責任者（CTO）であるジョン・ハーリー氏は、”AWSおよびMAGと協力し、ゲート情報を入手次第ライブで提供することで、空港での顧客体験を可能な限りシームレスにできることをうれしく思います。これは、旅客の旅程を可能な限りわかりやすくすることを目的とした当社の Day of Travel Initiative に沿ったものです。”と述べました 結論 このブログでは、MAGがAWS上でイベントドリブンなゲート通知システムを迅速に構築し、Ryanairと協力して乗客の旅行体験を改善した方法を学びました。もしあなたも乗客のエクスペリエンスを改善する方法に興味があれば、aws.com/travelをご覧になるか、弊社までご連絡ください。 翻訳はソリューションアーキテクトの矢形が担当しました。原文は こちら です。 Ian Frawley マンチェスター・エアポーツ・グループのエンジニアリング責任者であるイアン・フロリーは、マンチェスターを拠点としている。イアンと彼の熟練ソフトウェアエンジニアのチームは、最新の開発技術を駆使して、MAGの3つの空港のフルスタックサービスを構築し、空港内の異種システムのギャップを埋めている。彼はDevOps愛好家であり、統合のスペシャリストであり、ソフトウェアエンジニアであり、スノーボーダーであり、レコードコレクターであり、ドラマーである。 Ronan Prenty ローナン・プレンティはアイルランドのダブリンを拠点とするソリューション・アーキテクト。アイルランドのあらゆる規模の企業とともに、最新テクノロジーを駆使したクラウド革新に取り組んでいる。ローナンはAWSサポートチームに在籍していたことから、サーバーレス領域の専門知識を持っている。ダンドークITでコンピューティングの学位を取得。余暇はブラジリアン柔術とボクシングのファン。

世界中の何百万人もの人々が通勤や長距離移動に列車を利用しており、信頼性の高い鉄道サービスを当たり前のように利用しています。乗客を安全に目的地まで運ぶために、列車は定期的な検査とメンテナンスを受ける必要があり、これは鉄道車両基地で行われます。 このブログでは、 Siemens Mobility がスイスを代表する鉄道の1つである マッターホルン・ゴッタルド鉄道（MGBahn） の車両基地を管理するクラウドベースのソリューションの構築と導入を支援した事例を紹介します。これによりMGBahnは、構内でのITインフラ管理に必要な重労働を省くことができました。ここではまず、鉄道車両基地と、彼らが直面している課題を紹介し、次にソリューションの概要を説明し、最後に技術的な実装の詳細を説明します。 はじめに 鉄道車両基地の心臓部である入出庫作業は、列車の運行を維持し、効率的な鉄道運行を保証する重要な作業です。入出庫作業では、車両基地内で客車を移動させ、列車の整理、組み替えを行うほか、メンテナンスや次の旅程への準備を行います。安全性と生産性を確保するためには、熟練したオペレーターのチームと、明確に定義された一連の手順を必要とする複雑なプロセスをが正しく進んでいるか管理する必要があります。 Matterhorn Gotthard Railway Depot in Glisergrund, Valais (VS) 今日まで、車両の入換は、ディスパッチャーと入換作業を行う運転士（以下、入換運転士）の間の複雑なコミュニケーション・プロセスが必要でした。また車両基地で働く人々は全体的な運行概要を把握できていないことが多くありました。車両基地の入換と旅客列車サービスで異なるシステムが使用されていることに起因します。シーメンス・モビリティの車両基地制御システム Controlguide® TrackOps Depot on AWS の導入により、これらの運用手順が透明化、合理化、簡素化されました。 ソリューションの概要 MGBahnのGlisergrund Depotは現在、Software as a Service（SaaS）として、世界初のデポ向けモバイルクラウドベースソリューション、Controlguide® TrackOps Depotを採用しています。このソリューションは、MGBahnのGlisergrund Depotの運用プロセスを最適化し、運行管理センタのディスパッチャーと入換運転士の間の複雑なコミュニケーションをシンプルにする事が可能です。AWS上のTrackOps Depotは、オペレーションを合理化し、包括的な可視性を提供します。 このソリューションにより、Glisergrund Depot内の入換運転士は、指定された入換ルートに沿った作業を独自に管理・監視することができるようになりました。運行管理センターのディスパッチャーと無線でやり取りすることなく、作業を行うことができます。迂回ルートのリクエストや、必要なポイントやスイッチの設定は、検証後にインターロッキングによって調整されます。このようにルートが明確に分離され、オペレーションの可視性が向上することで、安全性と作業効率が高まります。 MGBahnのフェルナンド・レーナー最高経営責任者（CEO）は次のように述べている： 「Siemens Mobilityとの緊密な協力のもと、TrackOps DepotをGlisergrund Depotに導入できたことを嬉しく思います。運転士が操作するタブレットで車両基地全体の把握や作業指示のリクエストができるおかげで、入換作業はより効率的に、よりシンプルに、より安全になりました。” Controlguide® TrackOps Depot in use by MGBahn Shunting Foreman Software as a Service AWSリージョンは、グローバル規模でSaaSアプリケーションのスケーラビリティ、可用性、パフォーマンスを確保するために必要なインフラとサービスを提供します。AWSリージョンは世界中に分散しているため、シーメンス・モビリティは複数のリージョンでSaaSアプリケーションを展開することができます。このため、Siemens Mobility社は、地理的に異なる場所にいるユーザーに対しても低遅延でアクセスできるようになり、グローバルな顧客基盤にリーチできるようになりました。今回のケースでは、MGBahnはデータレジデンシーとレイテンシーの要件から、スイス国内でのシステム展開を必要としましたが、 スイスのAWSリージョンの立ち上げ により、この要件が満たされた。Siemens Mobilityによると、新しいシステムや顧客のためのスケールアップやスケールアウトのためのインフラコストは、オンプレミスのハードウェアよりも低くとどめることが可能です。 システムのユーザビリティ Controlguide® TrackOps Depotは、鉄道制御および情報システム Controlguide® Iltis N と統合され、運行管理センターのディスパッチャーと入換運転士の調整を容易にします。ディスパチャーと入換運転士との間の複雑なコミュニケーション手順が不要になったことで、関連するデポの作業員の自律性が向上し、1日あたり300以上の自律的な作業が可能になりました。さらに、TrackOps Depotは直感的で柔軟なインターフェイスを提供し、入換運転士がモバイル・タブレットを使ってローカルでシステムをコントロールできるようにしました。このインターフェースは、入出庫ルートを表示・管理し、車両基地内の稼働情報を提供し、運行状況をリアルタイムで拡大表示します。 テクノロジーの概要 TrackOps Depotのデプロイメントにおいて、Siemens MobilityはAmazon EKSを使用しています。Amazon EKSはAWS上でKubernetesを実行することを可能にし、開発者がすでに習得していKubernetesの知識を利用しインフラ、ツール、プロセスを簡単に使用できるようにしました。Amazon EKSはクラスタのキャパシティを管理し、ノードのプロビジョニングとアップグレードを自動化することで、あらゆる規模でアプリケーションを実行することも容易にしています。 ソリューションの高可用性を実現するため、Siemens Mobilityは、AWSリージョン・チューリッヒ（eu-central-2）の3つの可用性ゾーン（AZ）にアプリケーションを展開し、99,99％というシステム全体の可用性目標を目指しています。 運用監視にはPrometheus、Loki、Grafanaを使用しており、Amazon CloudWatch、アプリケーション・ログなどからデータを取り込み、アプリケーションのパフォーマンスと健全性を監視しています。さらに、潜在的な問題が発生した場合Siemens Mobilityに通知するアラームが設定しています。これにより、課題を迅速に検出して解決することができ、ビジネスへの影響を軽減し、全体的なユーザー・エクスペリエンスを向上させることができます。 またAmazon RDSを使用することで、クラウド上でPostgreSQLデータベースのセットアップ、運用、スケーリングを容易にしました。Amazon RDSは、ハードウェアのプロビジョニング、データベースのセットアップ、パッチ適用、バックアップなど、時間のかかるデータベース管理タスクを引き受けます。これにより、データベース・インフラストラクチャの管理ではなく、アプリケーションの構築に集中することができました。 Controlguide® TrackOps Depot Architecture Deployed on AWS 結論 このブログ記事では、Siemens MobilityのクラウドベースのSaaSソリューションであるControlguide® TrackOps Depot on AWSが、マッターホルン・ゴッタルド鉄道のグリザーグルント駅での鉄道オペレーションをどのように改善しているかを紹介しました。Siemens Mobilityは、入換運転士や作業員にタブレットを使った車両基地の管理機能を提供することで、MGBahnのオペレーションを最適化し、プロセスを合理化し、セーフティクリティカルな鉄道環境における継続的なイノベーションを実現します。 AWSとの連携により、TrackOps Depotの信頼性とスケーラビリティがさらに強化され、AWSによってシーメンス・モビリティが鉄道業界のクラウドベースのデジタルトランスフォーメーションをリードしていることを嬉しく思います。 Siemens Mobility Controlguide® TrackOps Depot on AWSの詳細については、 AWSのお問い合わせフォーム からご連絡ください。お客様のオペレーションを変革し、ビジネスを新たな高みへと導くために、一緒に取り組みましょう。 翻訳はソリューションアーキテクトの矢形が担当しました。原文は こちら です。 Nils Brandes ニルス・ブランデスは、AWSのソリューションアーキテクトとして、企業のお客様のクラウド導入の旅に携わっています。Nilsは、製造業や工業分野の大規模なグローバル企業で5年以上の経験があり、ビジネス価値を生み出す革新的なソリューションをアーキテクトして提供しています。技術革新による変革の一翼を担うことに情熱を注いでいる。 Balz Guenat バルツ・グエナはシーメンス・モビリティAGのソフトウェア・アーキテクト兼エンジニアで、鉄道業界のデジタル化を推進するための最新のクラウドネイティブ・アプリケーションとシステムを開発している。安全でセキュアで信頼性の高いソフトウェアを構築するため、最先端のオープン技術スタックを駆使している。バルツと彼のチームは、モビリティと輸送の次の時代に備え、業界のイノベーションを加速させることを目指している。

12月20日、 AWS Cloud Development Kit (AWS CDK) のサポートを備えた、既存の MySQL および PostgreSQL データベースに接続してクエリする機能の一般提供を開始しました。これは、Amazon Web Services (AWS) 内外のリレーショナルデータベースのために、リアルタイムで安全な GraphQL API を作成するための新しい機能です。データベースエンドポイントと認証情報のみを使用して、すべてのリレーショナルデータベースオペレーション用の API 全体を生成できるようになりました。データベーススキーマが変更された場合、コマンドを実行して最新のテーブルスキーマの変更を適用できます。 2021 年に、 AWS Amplify GraphQL Transformer バージョン 2 を発表しました。これにより、デベロッパーは、クラウドに関する専門知識が極めて少ない場合でも、より機能が豊富で、柔軟かつ拡張可能な GraphQL ベースのアプリケーションバックエンドを開発できるようになりました。この新しい GraphQL Transformer は、GraphQL API リクエストをルーティングし、認可などのビジネスロジックを適用するとともに、 Amazon DynamoDB などの基盤となるデータソースと通信するために、拡張可能なパイプラインリゾルバーを生成することを目的として、一から再設計されました。 しかし、お客様は、Amazon DynamoDB に加えて、 Amazon RDS データベースや Amazon Aurora データベースなどの GraphQL API 用のリレーショナルデータベースソース を使用したいと考えていました。今後、リレーショナルデータベースと DynamoDB データソースの両方のために、 @model タイプの Amplify GraphQL API を使用できるようになりました。リレーショナルデータベースの情報は、別の schema.sql.graphql ファイルに生成されます。通常の schema.graphql ファイルを引き続き使用して、DynamoDB ベースのタイプを作成および管理できます。 MySQL または PostgreSQL データベースの情報を提供するだけで、仮想プライベートクラウド (VPC) の背後にある場合でも、インターネット上でパブリックにアクセスできる場合でも、 AWS Amplify は、データベーステーブルに安全に接続して、 作成、読み取り、更新、または削除 (CRUD) クエリおよびミューテーションを公開する、変更可能な GraphQL API を自動的に生成します。フロントエンドのために、データモデルの名前をより慣用的な名前に変更することもできます。一例として、データベーステーブルは「todos」(複数形、小文字) と呼ばれるが、クライアントには「ToDo」(単数形、パスカルケース) として公開される場合を挙げることができます。 1 行のコードで、既存の Amplify GraphQL 認可ルール を API に追加でき、所有者ベースの認可やパブリック読み取り専用パターンなどのユースケースをシームレスに構築できます。生成された API は AWS AppSync の GraphQL 機能に基づいて構築されているため、安全なリアルタイムサブスクリプションをすぐに利用できます。数行のコードで、任意のデータモデルから任意の CRUD イベントをサブスクライブできます。 AWS CDK で MySQL データベースの使用を開始する AWS CDK を使用すると、プログラミング言語の優れた表現力を活用して、信頼性とコスト効率が高く、スケーラブルなアプリケーションをクラウド上に構築できます。使用を開始するには、ローカルマシンに AWS CDK をインストール します。 $ npm install -g aws-cdk 次のコマンドを実行して、インストールが正しいことを検証し、AWS CDK のバージョン番号を出力します。 $ cdk –version 次に、アプリケーション用の新しいディレクトリを作成します。 $ mkdir amplify-api-cdk $ cd amplify-api-cdk cdk init コマンドを使用して CDK アプリケーションを初期化します。 $ cdk init app --language typescript Amplify の GraphQL API コンストラクトを新しい CDK プロジェクトにインストールします。 $ npm install @aws-amplify/graphql-api-construct CDK プロジェクトのメインスタックファイルを開きます (通常は lib/<your-project-name>-stack.ts にあります)。ファイルの先頭に必要なコンストラクトをインポートします。 import { AmplifyGraphqlApi, AmplifyGraphqlDefinition } from '@aws-amplify/graphql-api-construct'; MySQL データベースで次の SQL ステートメントを実行して、新しいリレーショナルデータベース API の GraphQL スキーマを生成します。列ヘッダーを含む結果を .csv ファイルに出力し、 <database-name> を、データベース名、スキーマ名、またはその両方に置き換えてください。 SELECT INFORMATION_SCHEMA.COLUMNS.TABLE_NAME, INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME, INFORMATION_SCHEMA.COLUMNS.COLUMN_DEFAULT, INFORMATION_SCHEMA.COLUMNS.ORDINAL_POSITION, INFORMATION_SCHEMA.COLUMNS.DATA_TYPE, INFORMATION_SCHEMA.COLUMNS.COLUMN_TYPE, INFORMATION_SCHEMA.COLUMNS.IS_NULLABLE, INFORMATION_SCHEMA.COLUMNS.CHARACTER_MAXIMUM_LENGTH, INFORMATION_SCHEMA.STATISTICS.INDEX_NAME, INFORMATION_SCHEMA.STATISTICS.NON_UNIQUE, INFORMATION_SCHEMA.STATISTICS.SEQ_IN_INDEX, INFORMATION_SCHEMA.STATISTICS.NULLABLE FROM INFORMATION_SCHEMA.COLUMNS LEFT JOIN INFORMATION_SCHEMA.STATISTICS ON INFORMATION_SCHEMA.COLUMNS.TABLE_NAME=INFORMATION_SCHEMA.STATISTICS.TABLE_NAME AND INFORMATION_SCHEMA.COLUMNS.COLUMN_NAME=INFORMATION_SCHEMA.STATISTICS.COLUMN_NAME WHERE INFORMATION_SCHEMA.COLUMNS.TABLE_SCHEMA = '<database-name>'; 次のコマンドを実行します。その際、 <path-schema.csv> を、前のステップで作成した .csv ファイルへのパスに置き換えます。 $ npx @aws-amplify/cli api generate-schema \ --sql-schema <path-to-schema.csv> \ --engine-type mysql –out lib/schema.sql.graphql schema.sql.graphql ファイルを開いて、MySQL データベーススキーマからインポートされたデータモデルを確認できます。 input AMPLIFY {      engine: String = "mysql"      globalAuthRule: AuthRule = {allow: public} } type Meals @model {      id: Int! @primaryKey      name: String! } type Restaurants @model {      restaurant_id: Int! @primaryKey      address: String!      city: String!      name: String!      phone_number: String!      postal_code: String!      ... } まだ作成していない場合は、 AWS Systems Manager コンソール の [パラメータストア] に移動し、データベースの接続の詳細のパラメータ ( hostname/url 、 database name 、 port 、 username 、 password など) を作成します。これらは、Amplify がデータベースに正常に接続し、そのデータベースに対して GraphQL クエリまたはミューテーションを実行するために次のステップで必要になります。 メインスタッククラスで、次のコードを追加して、新しい GraphQL API を定義します。 dbConnectionConfg オプションを、前のステップで作成したパラメータパスに置き換えます。 new AmplifyGraphqlApi(this, "MyAmplifyGraphQLApi", { apiName: "MySQLApi", definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( [path.join(__dirname, "schema.sql.graphql")], { name: "MyAmplifyGraphQLSchema", dbType: "MYSQL", dbConnectionConfig: { hostnameSsmPath: "/amplify-cdk-app/hostname", portSsmPath: "/amplify-cdk-app/port", databaseNameSsmPath: "/amplify-cdk-app/database", usernameSsmPath: "/amplify-cdk-app/username", passwordSsmPath: "/amplify-cdk-app/password", }, } ), authorizationModes: { apiKeyConfig: { expires: cdk.Duration.days(7) } }, translationBehavior: { sandboxModeEnabled: true }, }); この設定は、データベースがインターネットからアクセスできることを前提としています。また、デフォルトの認可モードは AWS AppSync の API キーに設定されており、すべてのモデルでパブリックアクセスを許可するためにサンドボックスモードが有効になっています。これは、より詳細な認可ルールを追加する前に API をテストする場合に役立ちます。 最後に、GraphQL API を AWS クラウドにデプロイします。 $ cdk deploy これで、 AWS AppSync コンソール に移動し、作成した GraphQL API を見つけることができます。 プロジェクトを選択し、 [クエリ] メニューを選択します。MySQL データベースのテーブルと互換性のある、新しく作成された GraphQL API (1 つの項目を取得するための getMeals や、すべての項目を一覧表示するための listRestaurants など) を確認できます。 例えば、フィールドが address 、 city 、 name 、 phone_number などの項目を選択すると、新しい GraphQL クエリを確認できます。 [実行] ボタンを選択すると、MySQL データベースからのクエリ結果が表示されます。 MySQL データベースをクエリすると、同じ結果が表示されます。 データベースに合わせて GraphQL スキーマをカスタマイズする方法 SQL でカスタムクエリまたはミューテーションを追加するには、生成された schema.sql.graphql ファイルを開き、 the :<variable> 表記を使用してパラメータで @sql(statement: "") パスを使用します。 type Query {     listRestaurantsInState(state: String): Restaurants @sql("SELECT * FROM Restaurants WHERE state = :state;”) } より長くて複雑な SQL クエリの場合は、 customSqlStatements 設定オプションで SQL ステートメントを参照できます。参照値は、SQL ステートメントにマッピングされたプロパティの名前と一致する必要があります。次の例では、 customSqlStatements の searchPosts プロパティが参照されています。 type Query { searchPosts(searchTerm: String): [Post] @sql(reference: "searchPosts") } SQL ステートメントが API 定義でどのようにマッピングされるかを次に示します。 new AmplifyGraphqlApi(this, "MyAmplifyGraphQLApi", { apiName: "MySQLApi", definition: AmplifyGraphqlDefinition.fromFilesAndStrategy( [path.join(__dirname, "schema.sql.graphql")], { name: "MyAmplifyGraphQLSchema", dbType: "MYSQL", dbConnectionConfig: { // ...ssmPaths, }, customSqlStatements: { searchPosts: // property name matches the reference value in schema.sql.graphql "SELECT * FROM posts WHERE content LIKE CONCAT('%', :searchTerm, '%');", }, } ), //... }); SQL ステートメントは、スキーマ内でインラインで定義されているかのように実行されます。パラメータの使用や戻り値のタイプの一致、および有効な SQL 構文が確実に使用されるようにすることに関しても、同じルールが適用されます。参照ファイルを使用すると、スキーマがクリーンな状態に保たれ、フィールド間で SQL ステートメントを再利用できるようになります。これは、より長くて複雑な SQL クエリ向けのベストプラクティスです。 または、 @refersTo ディレクティブを使用してフィールドとモデル名を変更することもできます。 @refersTo ディレクティブを指定しない場合、AWS Amplify は、モデル名とフィールド名がデータベースのテーブル名と列名に正確に一致すると想定します。 type Todo @model @refersTo(name: "todos") {      content: String      done: Boolean } 2 つのデータベーステーブル間の関係を作成する場合は、 @hasOne ディレクティブと @hasMany ディレクティブを使用して 1:1 または 1:M の関係を確立します。関係の親に戻る双方向の関係を作成するには、 @belongsTo ディレクティブを使用します。例えば、レストランとその食事メニューの間に 1:M の関係を作成できます。 type Meals @model {      id: Int! @primaryKey      name: String!      menus: [Restaurants] @hasMany(references: ["restaurant_id"]) } type Restaurants @model {      restaurant_id: Int! @primaryKey      address: String!      city: String!      name: String!      phone_number: String!      postal_code: String!      meals: Meals @belongsTo(references: ["restaurant_id"])      ... } DB インスタンスの GraphQL スキーマまたはデータベーススキーマに変更を加えるたびに、変更をクラウドにデプロイする必要があります。 DB インスタンスの GraphQL スキーマまたはデータベーススキーマに変更を加えるたびに、このガイドで前述した SQL スクリプトと .csv へのエクスポートのステップを再実行して、 schema.sql.graphql ファイルを再生成し、変更をクラウドにデプロイする必要があります。 $ cdk deploy 詳細については、AWS Amplify ドキュメントの「 Connect API to existing MySQL or PostgreSQL database 」をご覧ください。 今すぐご利用いただけます AWS Amplify のリレーショナルデータベースサポートは、Amazon VPC 内または AWS クラウド外の任意の場所でホストされている MySQL および PostgreSQL データベースで動作するようになりました。 ぜひお試しいただき、 AWS Amplify の AWS re:Post 、Amplify GraphQL API の GitHub リポジトリ 、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy P.S.サンプルコードの作成に貢献してくれた AWS の Principal Product Manager である René Huangtian Brandel に特に感謝します。 原文は こちら です。

Amazon Verified Permissions は、アプリケーション内の承認管理のプロセスを簡素化するために設計されています。本ブログでは、このサービスが様々なビジネスケースにどのように適用できるか理解いただくことを目的としています。 通常、企業はビジネスアプリケーション内に埋め込まれたカスタム権限ロジックを使用しています。これは最も一般的なアプローチで、ユーザのアクセス承認を管理するためのカスタムコードを記述する必要があります。これから、アプリケーション開発者とアクセス管理者がアプリケーション内でユーザのアクセス承認を取り扱う際に直面する一般的な課題と、Amazon Verified Permissionsがこれらの課題を解決する方法について説明します。そして、支払管理などのユースケースにVerified Permissions を組み込むための統合ガイドを提供します。最後に、きめ細かく、様々なケースに適応でき、アプリケーションの外部から管理されるアクセス制御システムの利点について議論します。 このブログ記事は、アクセスポリシーの管理を包括的かつ集約的なアプローチで行い、管理上のオーバーヘッドを軽減し、LoB (Line of Business) のユーザーがアプリケーション権限ポリシーを定義、管理、適用できるようにすることを目的としています。 エンタイトルメントシステムの構築に伴う課題 エンタイトルメントとは、アプリケーション内で各ユーザが何ができて何ができないかを決定するルールのことです。図1は、アプリケーションに組み込まれたコンポーネントと複数のデータストアに格納された、一般的なエンタイトルメントシステムのアーキテクチャを示しています。 図1: 典型的なエンタイトルメントシステム 独自の承認管理システムを作成することは、その有用性を確認するにあたって時間や専門知識が必要な、多くのリソースがかかる作業となります。企業は独自のエンタイトルメント管理システムを構築する際に、複雑性、セキュリティリスク、パフォーマンス、スケーラビリティ不足など多くの課題に直面します。これらの課題について詳しく見ていきましょう。 データの複雑性  – エンタイトルメントの決定は、ユーザーのロール、グループとの紐付き、プロダクトをどのように操作できるかなど、複雑なデータ関係に基づいて行われます。この複雑性の管理は困難で、特に多くのユーザー、グループ、プロダクトを持つ大規模な組織ではその管理はさらに難しくなります。 コンプライアンスとセキュリティ – エンタイトルメントシステムの構築には、コンプライアンス規制とセキュリティベストプラクティスの両方を慎重に考慮する必要があります。お客様のデータを保護し、セキュアな通信プロトコルを実装し、潜在的なセキュリティ上の脆弱性に対処する必要があります。 スケーラビリティ – 権限管理システムは、多数のユーザーとトランザクションを処理できるようスケールする必要があります。特に、サービスが重要なリソースへのアクセスを制御するために使用される場合は、この点が課題となります。 パフォーマンスと可用性 – エンタイトルメントサービスは、リアルタイムな判断を下すために頻繁に使用されるため、高性能である必要があります。加えて、お客様が自組織のエンタイトルメントが正しいと自信を持てるよう、信頼性や一貫性を備える必要があります。 Amazon Verified Permissionsを使用したエンタイトルメントサービスのアーキテクチャ設計 Amazon Verified Permissionsは、スケーラブルな権限管理ときめ細かな認可を提供するサービスであり、アプリケーションのコードに埋め込まれた認可の実装に大きく依存することなく、アプリケーションの構築とモダナイゼーションを支援します。Verified Permissionsを使用して、エンタイトルメントの管理方法について言及します。 ポリシーの作成と運用 Verified Permissionsは、ユーザーが特定のタスクを承認されるか禁止される権限をポリシーとして開発者が表現できるポリシー言語である Cedar を使用しています。一元的なポリシーベースの認証システムにより、開発者はアプリケーション間で一貫した方法できめ細かな認証を定義および管理でき、コードを変更する必要なく権限ルールを変更でき、権限をコードから外に移動することで可視性が向上します。 Verified Permissionsを使用することで、ロールベースアクセスコントロール(RBAC)と属性ベースアクセスコントロール(ABAC)の特徴を取り入れた特定の権限ポリシーを作成できます。このアプローチにより、 最小権限 の原則を優先しながらきめ細かなコントロールを実装できます。 ユースケース1 :メアリーは事務員として働いており、支払いの提出と閲覧ができます。彼女の支払い管理システム内のロールは複数のアクションを許可しており、この役割のポリシーは以下の通り定義できます。 permit ( principal, action in [ PaymentManager::Action::"SubmitPayment", PaymentManager::Action::"UpdatePayment", PaymentManager::Action::"ListPayment" ], resource ) when { principal.role == "clerk" }; 反対に、シャーリーは監査役で、支払いのリストアップのみが許可されています。この役割のポリシーは以下の通りです。 permit ( principal, action in [PaymentManager::Action::"ListPayment"], resource ) when { principal.role == "auditor" }; 支払いシステムは、主体、アクション、リソース、およびエンティティデータをVerified Permissionsに渡します。ユーザ情報がアプリケーション内で明示的に定義されていない場合は、支払いシステムはアイデンティティプロバイダやデータベースなどのデータストアからそれを取得する必要があります。 次に、Verified Permissionsは呼び出し元と対象となるリソースに影響するポリシーを組み立て、アクションを承認するか拒否するかの決定を下します。決定が下されると、それはアプリケーションに伝えられ、アプリケーションはその決定を強制できるようになります。 図2から分かるように、メアリーは「事務員」の役割を持ち、前述のポリシーがこのアクションを承認しているため、支払いの提出にアクセスできます。 図 2: テストベンチを使用した、メアリーが支払いを提出できるかどうかのテスト シャーリーは「監査人」という役割で支払いを提出できず、図3で示されるようにアクションが拒否されました。 図3:テストベンチを使用した、シャーリーが支払いを提出できるかのテスト ただし、図4に示すように、前述のポリシーではこのアクションが承認されているため、支払いを一覧表示することはできます。 図 4: テストベンチを使用した、シャーリーが支払いを一覧表示できるかどうかのテスト ユースケース2 :財務部長のジェーンが休暇中、支払システムアプリケーションを使用して、111222333という高額利用のアカウントにおけるアクセス権限を、財務部長代理のジョンに委任します。テンプレートからポリシーを作成することで、ジェーンの直接的な立会いなしにも関わらず、ジョンに支払いの承認権限を付与します。 支払いの承認ポリシーテンプレート :図5は、支払いを承認するためのサンプルポリシーテンプレートを示しています。このテンプレートを使用して作成されたポリシーを用い、以下のとおり、リソースの支払い承認権限をプリンシパルに提供します。 permit ( principal == ?principal, action in [PaymentManager::Action::"ApprovePayment"], resource == ?resource ); 図 5: ポリシーテンプレートの作成 テンプレートからポリシーを作成:図6は、前述のテンプレートを使用して作成されたポリシーを示しています。渡す必要があるパラメータは、プリンシパルとリソース情報です。このユースケースの場合、プリンシパルは「ジョン」で、リソースはアカウント「111222333」となっており、ジョンがそのアカウントの支払い承認を可能にしています。(AWSでは、プリンシパルとして統合的で一意な識別子(Universally Unique Identifier, UUID)の使用を推奨していますが、このブログ記事では読みやすさのため「ジョン」が使用されています。) 図 6: テンプレートからのポリシーの作成 ポリシーを評価:想定どおり、ジョンにはアカウント 111222333 の支払いを承認するためのアクセス権限が付与されます (図 7 を参照)。 図 7: テストベンチを使用した、ジョンが支払いを承認できるかどうかのテスト Verified Permissions を用いたエンタイトルメントサービスの構築 Verified Permissions では、認可機能を外部化し、ポリシーの管理と運用を中央集権化したエンタイトルメントサービスを構築できます。これにより、Verified Permissionsが提供する基盤となる権限管理を活用しながら、特定のアプリケーション要件に合わせてアクセス制御を調整することができます。 既存のエンタイトルメントサービスをVerified Permissionsと統合する 既存のエンタイトルメントサービスをVerified Permissionsと統合する方法が図8に示されています。エンタイトルメントサービスの基盤の実装においては、標準的なエンタープライズテクノロジースタックが使用されています。ユーザーとロール情報を格納するために Amazon DynamoDB が使用されています。 図 8: エンタイトルメントサービスとVerified Permissionsの統合 既存のエンタイトルメントサービスをVerfied Permissionsとスムーズに統合するためのアプローチがこちらです: 承認の識別 : まずは既存のエンタイトルメントサービスを評価し、現在使用している権限、様々な役割、アクション、リソースを特定することから始めます。権限の詳細なリストと、それぞれの目的をまとめてください。 ポリシーの構築 : 前のステップで各ユースケースに対して特定した承認ルールをポリシーにマッピングします。インラインポリシーとポリシーテンプレートの両方を使用できます。AWS マネジメントコンソールのVerified Permissionsテストベンチを使用して作成したポリシーを評価します。 ポリシーの作成 : ビジネスニーズに応じて、Verified Permissions内に1つまたは複数のポリシーストアを作成します。これらのポリシーストア内にポリシーを作成します。これは1回限りのタスクで、自動化を使用することをお勧めします。 エンタイトルメントサービスの更新 : 既存のインターフェイスを使用して、現在のリクエストペイロードをVerified Permissionsの認可リクエストが期待する形式に変換するロジックを作成します。必要なパラメータを既存のインターフェイスに追加する必要があるかもしれません。この同じ変換ロジックをレスポンスペイロードにも適用します。Verified Permissionsの認可リクエストとレスポンス形式についてはこちらの ドキュメント を参照してください。 Verified Permissionsとの統合 : Verified Permissions APIまたはAWS SDKを使用して、エンタイトルメントサービスをVerified Permissionsと統合します。 Amazon DynamoDB からユーザーロールを取得する、Verified Permissionsへの認可リクエストを行う、レスポンスを処理する、などのタスクが含まれます。 テスト : 権限変更後にサービス全体を徹底的にテストします。すべての機能が予期どおり動作し、Verified Permissionsのポリシーが正しく利用されていることを確認します。 デプロイ : サービスがレビュープロセスを通過したら、更新されたエンタイトルメントサービスと統合されたVerified Permissionsをロールアウトします。 モニタリングとメンテナンス : デプロイ後は、継続的にパフォーマンスをモニタリングし、フィードバックを収集します。状況に応じて、エンタイトルメントサービスのさらなる調整を実施します。 ドキュメントとサポート : エンタイトルメントサービスを使用する開発者向けに包括的なドキュメントを提供します。利用可能なエンドポイント、リクエストとレスポンスの形式、認可の要件について明確に説明します。 既存の権限サービスをサードパーティのエンタイトルメント管理システムと統合する場合においても、同様のアプローチをとることができます。 Amazon Verified Permissions を使用した AWS 上での新しいエンタイトルメントサービスの構築 図9の参考アーキテクチャは、Verified Permissionsを使用して新しいエンタイトルメントサービスを構築する方法を示しています。AWSのお客様はすでに Amazon Cognito を簡易で高速な認証のために使用しています。Amazon Verified Permissionsにより、お客様はAmazon Cognitoが生成したID Tokenにユーザープロファイル属性を追加することで、既存のアプリケーションに簡易で高速な認可を追加できるようになります。 図9:Verified Permissionsを使用したエンタイトルメントサービス 図に示されているワークフローは以下の通りです: お客様はAmazon Cognitoを使用してアプリケーションにサインインします。 認証が成功した場合、トークン生成前のLambda関数が起動します。 トークン生成前のLambda関数を使用して、Amazon Cognitoが生成するアイデンティティトークンをカスタマイズする前に、アイデンティティトークンに新しいクレームとしてユーザープロファイル属性を追加できます。この場合、トリガーはユーザープロファイル属性をアイデンティティトークンに新しいクレームとして追加するために使用されます。 ユーザープロファイル属性はAmazon DynamoDBから取得されます。 属性はその後アイデンティティトークンに新しい主張として追加されます。 ユーザーはサインインした後、 Amazon API Gateway を介してアプリケーション内の保護されたリソースへのアクセスをリクエストします。 Amazon API Gatewayは、Lambdaオーソライザーを使用して認可チェックを開始します。Lambdaオーソライザーは、Amazon Cognitoによって生成されたアイデンティティトークンを使用してカスタム認可スキームを実装できるAPI Gatewayの機能です。 Lambdaオーソライザーは、アイデンティティトークンから検証、デコード、ユーザープロファイル属性の取得を行います。 Lambda認可機能は、プリンシパル、アクション、リソース、ユーザープロファイル属性をエンティティとしてVerified Permissionsの認可APIに渡します。 Verified Permissionsによって返された判断に基づいて、リソースへのアクセスが承認または拒否されます。 エンタイトルメントサービスの一般的な落とし穴 エンタイトルメントサービスは複雑な場合がありますが、いくつかの共通のミスを避ければ、よりセキュアで使いやすいようにすることができます。 エンタイトルメントサービスの設定ミスはセキュリティ上の脆弱性を生み、データ漏洩を引き起こす可能性があります。エンタイトルメントサービスを慎重に設定し、ポリシーを定期的に見直して正しく最新の情報に更新されているか確認することが重要です。 ビジネスアプリケーションを初めて使用する時、ユーザーに過剰な承認を与えがちです。これはアプリケーションのセキュリティを低下させ管理を難しくします。ユーザーに必要最小限の承認のみを与えることが重要です。 特に承認の申請と管理に関わる場合には、ユーザーはエンタイトルメントサービスの正しい利用方法についてトレーニングを受ける必要があります。もしユーザーがこれらの作業を適切に行えない場合、システムの脆弱性の原因になる可能性があります。 結論 Amazon Verified Permissions は、きめ細かなアクセス制御、柔軟な認可、アプリケーション外部で一元化されたアクセス制御を管理したい企業向けの包括的なソリューションです。このサービスにより、組織は新しいポリシーを環境全体に迅速かつ便利に適用できるため、ユーザー管理プロセスが合理化され、全体的なセキュリティが向上します。この記事では、アプリケーション内の権限管理に Verified Permissions を使用することの多くの利点が強調されています。このサービスをビジネスユースケースにどのように適用できるかを理解するうえで参考になれば幸いです。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 翻訳はソリューションアーキテクトの高野が担当しました。原文は こちら です。

このブログ記事では、 AWS IAM Identity Center(AWS Single Sign-On の後継) を使用して、許可セットとアカウント割り当ての管理を委任する方法をご紹介します。日々のユーザーと権限の管理を委任することで、チームはより速く動き、中央集権的なアイデンティティ管理者の負担を軽減できます。 IAM Identity Centerは、安全にWorkforce Identityを作成または接続し、AWSアカウントとアプリケーションに渡るアクセスを一元的に管理することに役立ちます。Identity Centerでは、 AWS Organizationsによってマルチアカウントが管理されている 必要があります。Identity Centerの管理は、 メンバーアカウント(管理アカウント以外のアカウント)に委任 できます。 管理アカウントにアクセスできる人を制限 し、 管理アカウントの利用は管理アカウントが必要なタスクに限って使用する ことをおすすめします。 委任された管理は、このブログで取り上げている許可セットとアカウント割り当ての委任とは異なります。AWS IAM Identity Centerの委任管理についての詳細は、「 AWS IAM Identity Center委任管理の導入 」をご覧ください。このブログポストで説明する手法は、Identity Centerがメンバーアカウントに委任されているか、または管理アカウントに残っているかに関係なく機能します。 許可セット は、AWSアカウントに対するユーザーまたはグループのアクセスレベルを定義するために使用されます。許可セットには、 AWS管理ポリシー 、 カスタマー管理ポリシー 、 インラインポリシー 、および アクセス許可境界 が含まれる可能性があります。 ソリューションの概要 組織が成長するにつれて、許可管理とアカウント割り当ての権限をチームに委任して、チームの自律性を高め負担を減らすことを検討したいと考えるかもしれません。または、自分たちの 組織単位(OU) で運用している様々な社内ビジネスユニットや社外のユーザーが、自分たちのアイデンティティ管理をよりコントロールしたいと考えるかもしれません。 このシナリオでは、例として3つの開発チーム(レッド、ブルー、イエロー)を持つある組織を仮定します。各チームはそれぞれ自分たちのOUを運用しています。IAM Identity Centerは管理アカウントから管理用メンバーアカウントに委任されています。図1はこの例の組織構成を示しています。 図1:本ブログで仮定するシナリオの組織構造 このシナリオの組織には既にある許可セットのコレクションがあります。中央集権的なアイデンティティ管理チームから許可セットとアカウント割り当ての管理を委任したいと考えています。 レッドチームは、自分たちのOU内のアカウントに既存の許可セットを割り当てることができるようにしたいと考えています。これはアカウントベースのモデルです。 ブルーチームは、単一の許可セットを編集・使用し、その許可セットをチームの単一アカウントに割り当てたいと考えています。これは許可ベースのモデルです。 イエローチームは、「Team: Yellow」とタグ付けされた許可セットを作成、編集、使用し、その許可セットを自分たちの組織単位内の全アカウントに割り当てたいと考えています。これはタグベースのモデルです。 これら3つのユースケースの必要な許可セットを見ていきます。 注意 : AWS Management Console を使用している場合は、 追加の許可が必要 です。 ユースケース 1: アカウントベースのモデル このユースケースでは、レッドチームに対してOU内の3つのアカウントに既存の許可セットを割り当てる許可が与えられます。これにはアカウント割り当ての削除許可も含まれます。 このモデルを使用すると、組織は一般的な許可セットを作成し、AWSアカウントに割り当てることができます。これにより、管理者の複雑性が軽減され、組織のベストプラクティスに従う許可セットの使用状況が確認しやすくなります。これらの許可セットは、特定のリソースではなく、サービスと機能をベースにアクセスを制限します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:ProvisionPermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>", "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/*", "arn:aws:sso:::account/112233445566", "arn:aws:sso:::account/223344556677", "arn:aws:sso:::account/334455667788" ] } ] } 上記のポリシーでは、プリンシパルはAWSアカウントIDが112233445566、223344556677、334455667788の3つのAWSアカウントに既存の許可セットを割り当てることができます。このポリシーには管理者向けの許可セットが含まれるため、どのアカウントに許可セットの割り当てるか十分に検討してください。 arn:aws:sso:::instance/ssoins-<sso-ins-id> はIAM Identity Center におけるインスタンスID の ARNです。 AWSコマンドラインインターフェイス(AWS CLI) v2  の  list-instances APIまたは AWS管理コンソール を使用して以下のように確認できます。 AWS CLI の使用 AWS コマンドラインインターフェイス (AWS CLI) を使用して以下のコマンドを実行してください: aws sso-admin list-instances AWS CloudShell を使用してコマンドを実行することもできます。 AWS マネジメントコンソールの使用 ご利用の AWS リージョンの管理コンソールを使用して、IAM Identity Center に移動し、ダッシュボード上の アイデンティティソースの確認 を選択してください。 図2: コンソール上のIAM Identity Center インスタンス ID ARN ユースケース 2: 権限ベースのモデル この例では、ブルーチームは1つまたは複数の特定の許可セットを編集する許可を与えられ、それらの許可セットを1つのアカウントに割り当てることができます。以下の許可は、チームがAWS管理ポリシー、カスタマー管理ポリシー、インラインポリシーを使用できるようにします。 このモデルでは、委任管理者が特定のAWSアカウント上のきめ細かなアクセス許可を使用できます。チームがAWSアカウント内へのアクセス許可を完全に管理したい場合、および管理ロールを作成する能力を持ちたい場合に有用です。このような場合、アカウントを操作するチームの方がサービスとワークロードの理解が深いため、アクセス許可は通常管理者よりもチームの方が実施しやすくなります。 アクセス許可の完全なコントロール権限を与えることは、意図しないまたは望ましくない結果につながる可能性があります。許可セットは IAMの評価と認証 の対象であるため、 サービスコントロールポリシー(SCP) により特定のアクションを拒否することができます。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sso:AttachCustomerManagedPolicyReferenceToPermissionSet", "sso:AttachManagedPolicyToPermissionSet", "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:DeleteInlinePolicyFromPermissionSet", "sso:DetachCustomerManagedPolicyReferenceFromPermissionSet", "sso:DetachManagedPolicyFromPermissionSet", "sso:ProvisionPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:UpdatePermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>", "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/ps-1122334455667788", "arn:aws:sso:::account/445566778899" ] } ] } ここでは、プリンシパルは許可セット arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/ps-1122334455667788 を編集し、AWS アカウント 445566778899 に割り当てることができます。編集権限には、お客様管理ポリシー、AWS 管理ポリシー、インラインポリシーが含まれます。 前述のポリシーを使用する際には、ご自身の IAM Identity Center インスタンス ID とアカウント番号で値を書き換えてください。 前述のポリシーでは、 arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/ps-1122334455667788 が許可セットの ARN です。この ARN はコンソールから、または以下の AWS CLI コマンドを使用してすべての許可セットをリストすることで見つけることができます。 aws sso-admin list-permission-sets —instance-arn <上記のインスタンス ARN> この許可セットも、最初のユースケースと同様に、アカウント ID のリストに追加のアカウント ID を追加することで、複数のアカウントに適用できます。同様に、許可セットを追加して、ユーザーが複数の許可セットを編集し、セットのアカウントに割り当てることができます。 ユースケース 3: タグベースのモデル この例では、イエローチームには「Team: Yellow」とタグ付けされた許可セットを作成、編集、使用する許可が与えられます。その後、それらのタグ付けされた許可セットをすべてのアカウントに割り当てることができます。 この例は、組織がチームに対して自由に許可セットを作成および編集し、チーム自身のアカウントに割り当てることを可能にします。タグは、どの許可セットを作成および編集できるかを制御するために使用されます。正しいタグが付いていない許可セットは変更できません。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "sso:CreatePermissionSet", "sso:DescribePermissionSet", "sso:UpdatePermissionSet", "sso:DeletePermissionSet", "sso:DescribePermissionSetProvisioningStatus", "sso:DescribeAccountAssignmentCreationStatus", "sso:DescribeAccountAssignmentDeletionStatus", "sso:TagResource" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>" ] }, { "Effect": "Allow", "Action": [ "sso:DescribePermissionSet", "sso:UpdatePermissionSet", "sso:DeletePermissionSet" ], "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Yellow" } } }, { "Effect": "Allow", "Action": [ "sso:CreatePermissionSet" ], "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/", "Condition": { "StringEquals": { "aws:RequestTag/Team": "Yellow" } } }, { "Effect": "Allow", "Action": "sso:TagResource", "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Yellow", "aws:RequestTag/Team": "Yellow" } } }, { "Effect": "Allow", "Action": [ "sso:CreateAccountAssignment", "sso:DeleteAccountAssignment", "sso:ProvisionPermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>", "arn:aws:sso:::account/556677889900", "arn:aws:sso:::account/667788990011", "arn:aws:sso:::account/778899001122" ] }, { "Sid": "InlinePolicy", "Effect": "Allow", "Action": [ "sso:GetInlinePolicyForPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:DeleteInlinePolicyFromPermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>" ] }, { "Sid": "InlinePolicyABAC", "Effect": "Allow", "Action": [ "sso:GetInlinePolicyForPermissionSet", "sso:PutInlinePolicyToPermissionSet", "sso:DeleteInlinePolicyFromPermissionSet" ], "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Yellow" } } } ] } このポリシーでは、プリンシパルは Team: Yellow というタグがついた許可セットのみを作成することができ、Account ID 556677889900、667788990011、778899001122のAWSアカウントに対してそれらの  Team: Yellow でタグ付けされた許可セットを割り当てることができます。 プリンシパルは Team: Yellow でタグ付けされた許可セットのインラインポリシーのみを編集できます。他のチームのために既にタグ付けされた許可セットのタグを変更することはできません。 上記のポリシーを使用する際には、ご自身のIAM Identity CenterインスタンスID、タグ、アカウント番号に置き換えてください。 注意 :このポリシーは、プリンシパルに適用されるその他のステートメントがないことを前提としています。追加の許可ステートメントが必要な場合は、結果としてポリシーが権限昇格のリスクを生み出さないか確認してください。 タグを使用したAWSリソースへのアクセスの管理 についての追加情報を参照できます。 このポリシーでは、インラインポリシーを使用した許可設定の委任のみが許可されています。カスタマー管理ポリシーとは、各AWSアカウントに対して固有に払い出されたIAMポリシーのことです。許可セットでカスタマー管理ポリシーを使用する場合は、各AWSアカウントにおいて同じ名前およびパスのIAMポリシーを作成する必要があります。IAMポリシーが存在しない場合は、Identity Centerはアカウントへの割り当てを行いません。カスタマー管理ポリシーをIdentity Centerでどのように使用するかについては、 高度な AWS IAM Identity Center のユースケースに向けたカスタマー管理ポリシーの使用方法 を参照してください。 以下の2つのステートメントにより、上記のポリシーに対し、 カスタマー管理ポリシー の委任も許可するように拡張することもできます。 { "Sid": "CustomerManagedPolicy", "Effect": "Allow", "Action": [ "sso:ListCustomerManagedPolicyReferencesInPermissionSet", "sso:AttachCustomerManagedPolicyReferenceToPermissionSet", "sso:DetachCustomerManagedPolicyReferenceFromPermissionSet" ], "Resource": [ "arn:aws:sso:::instance/ssoins-<sso-ins-id>" ] }, { "Sid": "CustomerManagedABAC", "Effect": "Allow", "Action": [ "sso:ListCustomerManagedPolicyReferencesInPermissionSet", "sso:AttachCustomerManagedPolicyReferenceToPermissionSet", "sso:DetachCustomerManagedPolicyReferenceFromPermissionSet" ], "Resource": "arn:aws:sso:::permissionSet/ssoins-<sso-ins-id>/*", "Condition": { "StringEquals": { "aws:ResourceTag/Team": "Yellow" } } } 注意 : 上記ステートメントは両方の記載が必要です。なぜなら、タグによる条件キー aws:ResourceTag/${TagKey} には PermissionSet リソースタイプのみが対応しており、リストされているアクションは、インスタンスと PermissionSet リソースタイプの両方に対するアクセス権限が必要であるためです。詳細は  AWS IAM Identity Center のアクション、リソース、条件キー を参照してください。 ベストプラクティス 許可セットおよびアカウント割り当ての管理を委任する場合に考慮すべきベストプラクティスは以下の通りです。 特定の許可セットの編集権限のみを付与してください。すべての許可セットの編集権限を付与すると、そのロールは彼ら自身の許可セットも編集できてしまいます。 管理者のみがグループ管理を行えるようにしてください。グループ内ユーザーの編集権限を持つユーザーは、Organizations 管理者グループを含め自分を任意のグループに追加できてしまいます。 IAM Identity Center を委任アカウントで使用する場合は、 委任された管理のベストプラクティス も考慮してください。 まとめ 組織はIAM Identity Centerでの許可セットとアカウント割り当ての管理をチームに委任することで、チームに権限を与えることができます。これらのアクションの委任は、チームがより迅速に動くことに寄与し、また中央集権的なアイデンティティ管理チームの負担を軽減できます。このシナリオと例は、組織内で組み合わせて拡張できる委任概念を共有しています。 AWS セキュリティに関するニュースをもっと知りたいですか？ X でフォローしてください。 翻訳はソリューションアーキテクトの高野が担当しました。原文は こちら です。

AWS Fault Injection Service (FIS) は 、Chaos Engineering を大規模に実践するのに役立ちます。11月30日、AWS アベイラビリティーゾーンで停電が発生したり、ある AWS リージョンから別の AWS リージョンへの接続が失われたりした場合に、アプリケーションが意図したとおりに動作することを実証できる新しい シナリオ を発表しました。 シナリオを使用して実験を行うことで、何か問題が発生したときにアプリケーション (単一リージョンかマルチリージョンかを問わず) が期待どおりに動作するという確信を築き、直接的および間接的な依存関係をよりより深く理解し、復旧時間をテストできます。アプリケーションを一定のペースでテストし、期待どおりに機能することを確認したら、実験の結果をコンプライアンスの目的で使用できます。 AWS Resilience Hub 、 の他の部分と組み合わせて使用すると、アプリケーションの全体的な 耐障害性体制 を完全に理解するのに役立ちます。 シナリオ入門 AWS アプリケーションで管理された実験を実施できるように、2021 年に FIS を立ち上げました。今回のリリースを発表するために 書いた私の投稿 では、実験テンプレートの作成方法と、それを使った実験方法を紹介しました。これらの実験は強力で低レベルのアクションを使用して構築されており、特定タイプの AWS リソースの指定されたグループに影響を与えます。例えば、次のアクションは EC2 インスタンスと Auto Scaling グループで動作します。 これらのアクションを構成要素として、私たちは最近 AWS FIS シナリオ ライブラリ を立ち上げました。ライブラリ内の各シナリオでは、アプリケーションの耐障害性をテストするために使用できるイベントまたは条件が定義されています。 各シナリオを使用して実験テンプレートを作成します。シナリオをそのまま使用することも、任意のテンプレートをベースに必要に応じてカスタマイズまたは拡張することもできます。 シナリオは、同じ AWS アカウントまたは他の AWS アカウントのリソースを対象にすることができます。 新しいシナリオ これらすべてを背景として、新しいシナリオを見てみましょう。 AZ 可用性: 停電 — このシナリオでは、EC2 インスタンス (EKS および ECS クラスター内のインスタンスを含む)、EBS ボリューム、Auto Scaling グループ、VPC サブネット、 Amazon ElastiCache for Redis クラスター、 Amazon Relational Database Service (RDS) クラスターなどを含む 1 つのアベイラビリティーゾーン内の対象となるリソースすべてで一時的に「プラグを抜く」ことになります。ほとんどの場合、複数のアベイラビリティーゾーンにリソースを持つアプリケーションで実行しますが、予想される結果として停電が発生するシングル AZ アプリケーションで実行することもできます。1 つの AZ を対象とし、実験中に指定した一連の IAM ロールまたは Auto Scaling グループが新しいインスタンスを起動したり、停止したインスタンスを起動したりできないようにすることもできます。 新しいアクションとターゲットエクスペリエンス により、シナリオ内のアクションとそれらが影響する AWS リソースの種類など、すべてを一目で簡単に確認できるようになります。 シナリオには、実験テンプレートのカスタマイズに使用されるパラメーターが含まれます。 詳細パラメータ — ターゲットタグ を使用すると、実験の対象となるリソースを見つけるために使用されるタグキーと値を制御できます。 クロスリージョン: 接続 — このシナリオでは、テストリージョンのアプリケーションがターゲットリージョンのリソースにアクセスできなくなります。これには、VPC にアタッチされた EC2 インスタンス、ECS タスク、EKS ポッド、および Lambda 関数からのトラフィックが含まれます。また、 Transit Gateway と VPC ピアリング 接続を経由するトラフィック、およびクロスリージョンの S3 と DynamoDB のレプリケーションも含まれます。このシナリオは、初期の状態で次のとおりです。 このシナリオは 3 時間実行され ( disruptionDuration パラメーターを変更しない限り)、指定された方法でテストリージョンをターゲットリージョンから分離します。詳細なパラメータを使用して、分離されたリージョン内の影響を受ける AWS リソースを選択するために使用されるタグを制御します。 また、このシナリオで使用されている 中断 アクションや 一時停止 アクションは、それだけでも役立つ場合があります。 例えば、 aws:s3:bucket-pause-replication アクションを使用して、リージョン内のレプリケーションを一時停止できます。 留意点 新しいシナリオについて知っておくべきことがいくつかあります。 リージョン — 新しいシナリオは、FIS が利用できるすべての商用 AWS リージョンで、追加費用なしで利用できます。 料金 — 実験の実行で消費されたアクション分に対してお支払いいただきます。詳細については、 AWS Fault Injection Service (FIS) の料金表ページをご覧ください。 サービス名 — このサービスは、以前は AWS Fault Injection Simulator と呼ばれていました。 – Jeff ; 原文は こちら です。

11月30日、 Amazon Route 53 Application Recovery Controller の新機能であるゾーン自動シフトを公開しました。これにより、AWS がそのアベイラビリティーゾーンに影響する潜在的な障害を特定したときに、ワークロードのトラフィックを アベイラビリティーゾーン から 自動的に かつ 安全に 移動し、障害が解決したら元のアベイラビリティーゾーンに復元できます。 耐障害性の高いアプリケーションのデプロイでは、通常、リソースをリージョンの複数のアベイラビリティーゾーンにデプロイします。アベイラビリティーゾーンとは、さまざまな電力、接続、ネットワークデバイス、および氾濫原管理を確保するために、通常数マイル離れた物理データセンターの個別のグループのことです。 デプロイの失敗、構成の誤り、オペレーターのミスなど、アプリケーションのエラーからユーザーを保護するために、当社では昨年、 手動またはプログラムでゾーンシフトをトリガーする機能 を導入しました。 これにより、あるアベイラビリティーゾーンでメトリクス値の低下が検出したときに、トラフィックをそのアベイラビリティーゾーンから遠ざけることができます。そのためには、すべての新しい接続を正常なアベイラビリティーゾーンのインフラストラクチャのみに転送するようにロードバランサーを設定します。これにより、障害の根本原因を調査する間、顧客はアプリケーションの利用を継続できます。障害が解消されたら、ゾーンシフトを停止して、トラフィックが再びすべてのゾーンに分散されるようにします。 ゾーンシフトは、NLB のデフォルトである クロスゾーン負荷分散 が無効になっている場合にのみ、 Application Load Balancer (ALB) または Network Load Balancer (NLB) レベルで機能します。簡単に言うと、ロードバランサーには 2 つのレベルの負荷分散があります。最初のレベルは DNS で設定されます。ロードバランサーはアベイラビリティーゾーンごとに 1 つ以上の IP アドレスを公開し、ゾーン間のクライアント側の負荷分散を実現します。トラフィックがアベイラビリティーゾーンに到達すると、ロードバランサーは登録された正常なターゲット (通常は Amazon Elastic Compute Cloud (Amazon EC2) インスタンス) にトラフィックを送信します。デフォルトでは、ALB はすべてのアベイラビリティーゾーンのターゲットにトラフィックを送信します。ゾーンシフトを正しく機能させるには、クロスゾーン負荷分散を無効にするようにロードバランサーを設定する必要があります。 ゾーンシフトが始まると、次の図に示すように、DNS はすべてのトラフィックをあるアベイラビリティーゾーンから遠ざけます。 手動によるゾーンシフトは、ユーザー側で発生したエラーからワークロードを保護するのに役立ちます。しかし、アベイラビリティーゾーンで障害が発生した可能性がある場合、障害の特定や検出が困難な場合があります。ほとんどの場合、アベイラビリティーゾーンごとにメトリクスを追跡することはないため、アプリケーションメトリックスを使用してアベイラビリティーゾーンの問題を検出することは困難です。さらに、サービスがアベイラビリティーゾーンの境界を越えて依存関係を呼び出すことが多く、その結果、すべてのアベイラビリティーゾーンでエラーが発生してしまいます。最新のマイクロサービスアーキテクチャでは、これらの検出と復旧の手順を数十または数百の個別のマイクロサービスで実行しなければならないことが多く、復旧に数時間かかってしまいます。 お客様から、アベイラビリティーゾーンで発生した可能性のある障害を特定する負担を軽減できないかと問い合わせがありました。結局のところ、当社が内部のモニタリングツールを使用すれば、潜在的な問題についてお客様より先に検出できる可能性があります。 今回のリリースにより、アベイラビリティーゾーンで発生する可能性のある障害からワークロードを保護する ゾーン自動シフト を設定できるようになりました。当社では、ネットワークトラフィックのシフトをいつトリガーするかを決定するために、独自の AWS 内部モニタリングツールとメトリクスを利用します。シフトは自動的に開始され、API を呼び出す必要はありません。ゾーンに電源障害やネットワーク障害などの潜在的な障害が発生していることが検出されると、インフラストラクチャの NLB または ALB トラフィックの自動シフトが自動的にトリガーされ、障害が解決された時点でトラフィックを元に戻します。 言うまでもなく、トラフィックをアベイラビリティーゾーンから遠ざけることはデリケートなオペレーションであり、慎重に準備する必要があります。アプリケーションの可用性を誤って低下させないように、一連の保護手段を構築しました。 まず、トラフィックを一度に複数のアベイラビリティーゾーンから移動させないようにするための内部制御が必要です。次に、毎週 30 分間、インフラストラクチャの移行を演習します。例えば、月曜日から金曜日の 08:00～18:00 など、演習をブロックする時間帯を定義できます。3 つ目は、演習実行中の サーキットブレーカー として機能する 2 つの Amazon CloudWatch アラームを定義することです。一方は演習の実行をまったく開始しないようにするアラーム、他方は演習実行中のアプリケーションの状態をモニタリングするアラームです。演習中にどちらかのアラームがトリガーされると、停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。演習実行終了時のアプリケーションヘルスアラームの状態は、実行の結果 (成功または失敗) を示します。 責任共有の原則 によれば、2 つの責任があります。 まず、すべてのアベイラビリティーゾーンに十分な容量がデプロイされていることを確認して、トラフィックが移動した後に残りのアベイラビリティーゾーンのトラフィックが増加しても対応できるようにする必要があります。残りのアベイラビリティーゾーンには常に十分な容量を確保し、アプリケーションの復旧を遅らせたり可用性に影響を与えたりする可能性のあるスケーリングメカニズムに依存しないことを強くお勧めします。ゾーン自動シフトがトリガーされると、 AWS Auto Scaling はリソースをスケーリングするのに通常よりも時間がかかる場合があります。リソースを事前にスケーリングすることで、最も要求の厳しいアプリケーションの復旧時間を予測できます。 通常のユーザートラフィックを吸収するために、アプリケーションが 3 つのアベイラビリティーゾーンに 6 つの EC2 インスタンス (2×3 インスタンス) を必要とするとします。ゾーン自動シフトを設定する前に、1 つのアベイラビリティーゾーンが利用できない場合にトラフィックを吸収するのに十分な容量が残りのアベイラビリティーゾーンにあることを確認する必要があります。この例では、1 つのアベイラビリティーゾーンにつき 3 つのインスタンス (トラフィックが 2 つのアベイラビリティーゾーンに移動されたときに 2×3 = 6 つのインスタンスを維持して負荷分散する必要があるため、3 つのアベイラビリティーゾーンに 3×3 = 9 つのインスタンスが必要) という意味です。 実際には、高い信頼性が求められるサービスを運用する場合、顧客による負荷の急上昇や時折のホスト障害などの不測の事態に備えて、ある程度の冗長容量をオンラインで運用するのが一般的です。この方法で既存の冗長性を満たすことで、アベイラビリティーゾーンの問題が発生したときに迅速に復旧できるだけでなく、他のイベントに対する堅牢性も高まります。 次に、選択したリソースのゾーン自動シフトを明示的に有効にする必要があります。AWS は、選択したリソースにのみゾーン自動シフトを適用します。ゾーン自動シフトを適用すると、アプリケーションに割り当てられる合計容量に影響します。先ほど説明したように、残りのアベイラビリティーゾーンに十分な容量をデプロイして、アプリケーションを準備する必要があります。 もちろん、この追加容量をすべてのアベイラビリティーゾーンにデプロイすることにはコストがかかります。耐障害性について話すとき、アプリケーションの可用性とコストのどちらを決めるかというビジネス上のトレードオフがあることを説明します。これが、選択したリソースにのみゾーン自動シフトを適用するもう 1 つの理由です。 ゾーン自動シフトの設定方法を見てみましょう ゾーン自動シフトの設定方法を示すために、今や有名になった TicTacToe ウェブアプリケーションを CDK スクリプトを使ってデプロイします。 AWS マネジメントコンソール の [Route 53 Application Recovery Controller] ページを開きます。左側のペインで、 [ゾーン自動シフト] を選択します。次に、ウェルカムページで、 [リソースのゾーン自動シフトを設定] を選択します。 デモアプリケーションのロードバランサーを選択します。現在のところクロスゾーン負荷分散が無効になっているロードバランサーのみがゾーン自動シフトの対象であるということに注意してください。コンソールの警告からもわかるように、アベイラビリティーゾーンが 1 つ失われても動作を継続するのに十分な容量がアプリケーションにあることも確認しています。 ページを下にスクロールして、AWS に 30 分間の演習を実行させたくない時間と曜日を設定します。最初は、自動シフトに慣れるまで、月曜日から金曜日の 08:00〜18:00 は演習をブロックします。時刻は UTC で表示され、 夏時間 は適用されないことに注意してください。 UTC 時間変換アプリケーション を使用すると便利です。最初は営業時間を外して問題ありませんが、アプリケーションのトラフィックが少ないときやまったくない場合には表示されない可能性がある問題を確実にキャプチャできるように、営業時間中にも演習を実行するように設定することをお勧めします。ピーク時に衝撃を与えずに機能させるには、おそらくゾーン自動シフトが最も必要ですが、テストしたことがない場合は、どの程度自信がありますか? 常時ブロックしないのが理想ですが、それが常に現実的であるとは限らないことを私たちは認識しています。 同じページのさらに下にある 2 つのサーキットブレーカーアラームを入力します。最初のものは演習の開始を妨げます。このアラームを使って、今は演習を始めるのに良いタイミングではないと示します。例えば、アプリケーションで現在問題が発生している場合や、アプリケーションの新しいバージョンを本番環境にデプロイする場合などです。2 番目の CloudWatch アラームは、演習実行の結果を示します。これにより、ゾーン自動シフトにより、アプリケーションが演習実行にどのように反応しているかを判断できます。アラームが緑色のままであれば、すべてがうまくいったことがわかります。 演習中にこれら 2 つのアラームのいずれかがトリガーされると、ゾーン自動シフトは演習を停止し、すべてのアベイラビリティーゾーンへのトラフィックを復元します。 最後に、30 分間の演習実行が毎週実行され、アプリケーションの可用性が低下する場合があることを認めます。 その後、 [Create] を選択します。 それだけです。 数日後、コンソールの [リソースのゾーンシフト履歴] タブに演習実行の履歴が表示されます。2 つのサーキットブレーカーアラームの履歴をモニタリングして、すべてが正しくモニタリングされ、設定されていることを確認しています。 自動シフト自体をテストすることはできません。アベイラビリティーゾーンで潜在的な問題を検出すると、自動的にトリガーされます。この記事で共有した手順をテストするためにアベイラビリティーゾーンをシャットダウンできるかどうかサービスチームに尋ねたところ、丁寧に断られました。 自動シフトと同じように動作する手動シフトをトリガーすれば、設定のテストができます。 さらに押さえておくべきこと ゾーン自動シフトは、中国と GovCloud を除くすべての AWS リージョンで追加料金なしで利用できるようになりました。 クロール、ウォーク、ラン方式の適用をお勧めします。まず、手動のゾーンシフトから始め、アプリケーションに対する信頼性を確立します。次に、営業時間外に演習実行を設定したゾーン自動シフトを有効にします。最後に、営業時間中のゾーンシフトの演習を含めるようにスケジュールを変更します。イベントが発生したくないときに、イベントに対するアプリケーションの応答をテストしたいと考えています。 また、トラフィックを 1 つのアベイラビリティーゾーンから別のアベイラビリティーゾーンに戻したときに、アプリケーションのすべての部分がどのように復旧するかを総合的に考えることをお勧めします。私が思いつくリスト (完全なものではありませんが) は次のようなものです。 まず、すでに説明したように、容量増加の計画を立てます。次に、各アベイラビリティーゾーンで発生する可能性のある単一障害点について考えてみましょう。例えば、単一の EC2 インスタンスで実行される自己管理型データベースや、1 つのアベイラビリティーゾーンに存在するマイクロサービスなどです。ゾーンシフトを必要とするアプリケーションには、 Amazon DynamoDB や Amazon Aurora などのマネージドデータベースを使用することを強くお勧めします。これらには、レプリケーションとフェイルオーバーのメカニズムが組み込まれています。3 番目に、アベイラビリティーゾーンが再び利用可能になったときに切り替える計画を立ててください。リソースのスケーリングにはどの程度の時間が必要ですか? キャッシュをリハイドレートする必要がありますか? 耐障害性の高いアーキテクチャと方法論について詳しくは、 同僚の Adrian が執筆したこの素晴らしい記事シリーズ をご覧ください。 最後に、現在ゾーン自動シフトの対象となるのは、クロスゾーン負荷分散が無効になっているロードバランサーのみであることに注意してください。CDK スクリプトからクロスゾーン負荷分散を無効にするには、 stickinessCookieDuration を削除し、ターゲットグループに load_balancing.cross_zone.enabled=false を追加する必要があります。CDK とタイプスクリプトを使った例を以下に示します。 // 負荷分散として Auto Scaling グループを追加します // リスナーをターゲットにします。 const targetGroup = listener.addTargets('MyApplicationFleet', { port: 8080, // ゾーンシフトでは、維持設定とクロスゾーンの負荷分散を無効にする必要があります // stickinessCookieDuration: Duration.hours(1), targets: [asg] }); // クロスゾーン負荷分散を無効にする targetGroup.setAttribute("load_balancing.cross_zone.enabled", "false"); 次は、ゾーン自動シフトのメリットが得られるアプリケーションを選択します。まず、各アベイラビリティーゾーンのインフラストラクチャ容量を確認してから、サーキットブレーカーアラームを定義します。モニタリングが正しく設定されていることを確認したら、 ゾーン自動シフトを有効にしてください 。 — seb 原文は こちら です。