Amazon Web Services ブログ

TorchElastic Controller for Kubernetes を使った耐障害性のある機械学習分散トレーニング

 はじめに 機械学習チームが Kubernetes を使用すると、Amazon EC2 P3 などの強力な GPU インスタンスのフリート全体に分散したトレーニングジョブを実行でき、トレーニング時間を数日から数時間に短縮することができます。しかし、Kubernetes によく関連付けられている従来のマイクロサービスベースのアプリケーションと比較すると、分散トレーニングには制限があります。分散トレーニングジョブは耐障害性がありませんし、ノードの障害または回復によってトレーニングが中断された場合、ジョブを続行できません。それに加え、要求されたリソースをすべて取得しないとジョブを開始できず、また、再起動せずに拡張や縮小することもできません。このように、回復性と柔軟性が欠如しているため、トレーニングの時間とコストが増大します。 この投稿では、AWS の Kubernetes チームと Facebook の PyTorch チーム間の新しいオープンソースコラボレーションである TorchElastic Controller for Kubernetesについて説明します。これで、上記のような制限に対処したり、PyTorch ビルドモデルや Kubernetes 分散トレーニングの新機能を利用できます。たとえば、EC2 スポットインスタンスでのトレーニング、ハードウェア障害に耐性のあるジョブの実行、クラスターリソースの可用性に基づいた動的なジョブのスケーリングなどが可能となります。 PyTorch Elastic と Kubernetes の統合 PyTorch Elastic は大規模な深層学習モデルをトレーニングするためのライブラリで、動的な可用性に基づいたコンピューティングリソースのスケーリングに不可欠です。PyTorch ジョブを作成するためのプリミティブとインターフェースで、複数のマシンで伸縮性を持ちつつ実行できるようになります。最小限のワーカーが集まるとすぐに分散ジョブを開始でき、停止または再起動を実行しなくても最大数のワーカーまで拡張できます。伸縮性とは、トレーニングジョブ中にフレームワークがノード数を拡張または縮小する機能です。耐障害性とは、ジョブを再起動せずに、フレームワークがトレーニングジョブ中に失敗したノードを検出して置き換えることができる機能です。 PyTorch Elastic には Rendezvous と呼ばれるコンポーネントが含まれています。このコンポーネントはトレーニングジョブの参加者 (ワーカー) を集め、そこで、全員が参加者と全員のロールとの同じリストに同意し、トレーニングをいつ開始/再開できるかについて一貫した集団での決定を行います。詳細については、GitHub のオープンソースプロジェクトにアクセスしてください。 TorchElastic Controller for Kubernetes (TECK) は PyTorch Elastic インターフェースのネイティブ Kubernetes 実装で、TorchElastic […]

Read More

AWS Data Exchange で TruFactor のウェブセッションインテリジェンスをクエリ、視覚化、予測する

データは無限にあるという性質を考えると、ビジネスの洞察を得るために適切なデータセットを見つけることは困難な場合があります。さまざまなデータセットの中央リポジトリにアクセスして、クエリ、視覚化、予測を行うことで、ビジネスを改善できます。AWS Data Exchange により、適切なデータセットを見つけることがはるかに簡単になりました。例として、ウェブセッションの訪問と人口統計に関するデータセットを使用して、どの人口統計グループが最も頻繁にウェブサイトにアクセスするかを理解するのに役立ちます。その後、機械学習 (ML) モデルと訪問予測を使用してビジネスを改善できます。 AWS Data Exchange では、クラウドでサードパーティのデータを簡単に検索、サブスクライブ、使用できます。AWS Data Exchange 内でデータ製品をサブスクライブした後、AWS Data Exchange API、AWS CLI や AWS マネジメントコンソールを使用して、データを直接 Amazon S3 にロードできます。その後、分析から機械学習に至るまで、さまざまな AWS のサービスでインポートされたデータを分析できます。 この記事では、AWS Data Exchange 上の TruFactor Intelligence-as-a-Service データを紹介します。TruFactor の匿名化プラットフォームと独自の AI は、ワイヤレスキャリア、OEM、モバイルアプリから毎日 850 億以上の高品質の生信号を取り込み、フィルターにかけ、物理的およびデジタルの次元にわたる統合された「フィジタル」消費者グラフに変換します。TruFactor インテリジェンスは、アプリケーション対応で AWS アナリティクスまたは ML サービス内で使用でき、AWS で実行されているモデルやアプリケーションを強化します。追加の処理は必要ありません。一般的なユースケースは次のとおりです。 消費者セグメンテーション – 米国のインターネット閲覧行動に関するウェブインテリジェンスは、興味、意見、価値観、デジタル行動、感情などの消費者の全体像を提供し、顧客と競合他社のセグメンテーションを伝えます。 顧客獲得またはチャーンキャンペーン – インターネットの閲覧行動は、新しい見込み顧客の類似性の特性を特定できるだけでなく、競合他社のウェブサイトに切り替える可能性も特定できます。 このチュートリアルでは、TruFactor の Daily Mobile Web Session […]

Read More

Amazon FSx for Windows File Server を共有 VPC にデプロイする

企業がアプリケーションフットプリントの多くをクラウドに移行し続けると、ファイルデータのためのソリューションが必要であることにすぐに気づきます。最近の多くのアプリケーションは、オブジェクトストア、NoSQL、グラフデータベースなどの API 駆動型ストレージサービスとインタラクションするように構築されていますが、ファイルサービスに依存するワークロードは依然として多数あります。多くの場合、これらのアプリケーションは、ファイルストレージソリューションの厳密な可用性の特性を必要とする一連の原則に基づいて設計されています。 前述の理由により、多くのお客様は、業界標準の SMB プロトコルでアクセスでき、回復力があり、スケーラブルで耐久性のある Windows ファイルストレージをアプリケーションに提供する簡単な方法として、Amazon FSx for Windows File Server (Amazon FSx) を利用しています。最近、Amazon FSx は、共有 Virtual Private Cloud (VPC) 環境のサポートを発表しました。これにより、お客様は、ローカルアカウント内で共有されるサブネットに直接ファイルシステムをデプロイできます。このタイプのパターンを採用すると、アプリケーション開発者は、職務の分離を通じて、セキュリティを維持しながらスピードを向上させることができます。基盤となるネットワークトポロジが組織のすべてのセキュリティ標準およびベストプラクティスを確実に満たすようにする作業を別のチームが行うことで、アプリケーション開発者は構築に集中できます。これらの利点については、以下で詳しく説明します。 このブログ投稿では、共有 VPC 環境での Amazon FSx のデプロイについて説明します。しかし、最初に、一部のお客様が共有 VPC の採用を決定した理由について少しお話ししましょう。 お客様が共有 VPC を使用している理由 多くの AWS のお客様は、ワークロードの分離を提供するために複数のアカウントを使用しています。アプリケーションごとに 1 つのアカウントをプロビジョニングすることから、アーキテクチャパターンまたは分類によってアプリケーションをグループ化することまで、ワークロードをアカウントにマッピングするためにお客様が使用できる多くの戦略があります。これらのアカウントを大規模に管理するには、多くの場合 AWS Organizations を使用する必要があります。Organizations は AWS Resource Access Manager (AW​​S RAM) と統合され、お客様は、他の AWS アカウントと多数のサービス (VPC サブネットなど) を共有し、単一のロケーションからその共有を制御できます。 […]

Read More

AWS ChatBot – Slack および Chime を使用した ChatOps

昨年、同僚の Ilya Bezdelev が、AWS Chatbot パブリックベータ版のリリースにあたり、Introducing AWS Chatbot: ChatOps for AWS というブログを執筆しました。また、彼は re:Invent 2019 Launchpad に参加し、詳細な AWS Chatbot のデモも行いました。 Ilya は最初に投稿した記事で、Amazon Chime や Slack 内で ChatOps を実施し、その協調しやすい環境内で AWS 通知を受信したり、コマンドを実行したりする方法を紹介しました。その後投稿した記事、Running AWS commands from Slack using AWS Chatbot では、Slack チャンネルで AWS Chatbot を構成する方法、CloudWatch アラームを表示する方法、AWS リソースを記述する方法、Lambda 関数を呼び出してログを取得する方法、AWS サポートケースを作成する方法を紹介しています。また、同僚の Erin Carlson と Matt Cowsert は、Launch: AWS Budgets Integration with […]

Read More

AWS IoT Core を用いた認可ポリシーのスケーリング

はじめに IoTソリューションを構築するソリューションアーキテクト、開発者、およびシステム設計者は、ソリューション全体において、データとデータを操作する機能を適切に保護する必要があります。この投稿では、 AWS IoT Core を使用したマルチユーザーおよびマルチデバイスのユースケースに焦点を当て、認可ポリシーのスケーリングのためのいくつかの設計手法について説明します。デバイス、ユーザー間のカーディナリティやスケールのレベルに応じたパターンを紹介します。 AWS IoT サービス上にソリューションを構築する際のセキュリティ設計やアーキテクチャ検討時に活用頂ければと思います。 IoT デバイス、ネットワークパス、エンドユーザーデバイス、データベース、バックエンドシステムなど、データのやり取りが発生するあらゆるコンポーネントにおいてセキュリティ対策が必要です。IT セキュリティにおいて、セキュアなアーキテクチャを検討する際には、「AAA」と言われる3つのAを考慮する必要があります。 それぞれ、 Authentication (認証)、 Autorization (認可)、 Accounting (アカウンティング)または Auditing (監査)です。 AAA は、セキュリティ要件を整理し、それらの要件とソリューションアーキテクチャを対応付ける方法です。この方法により、ソリューションの利害関係者、エンドユーザー、およびコンプライアンスの専門家は、関連する重要な要件を満たすために、どのようにソリューションが設計されているかを把握することができます。 IoT ソリューションは、固有の設計要素をもつ分散システムアーキテクチャを意味します。分散システムアーキテクチャでは、補完的な分散セキュリティソリューションが必要になります。多くのお客様は、クラウド内の分散システムや、クラウドとオンプレミスのエンタープライズシステムを統合するハイブリッドアーキテクチャの ID (認証)機能を実現するために、 ID フェデレーション( ID 連携)を使用しています。この手法は IoT のデータと機能の保護にも利用できます。 AWS ID フェデレーションオプションの詳細については、 ID フェデレーションの記事をご覧ください。 ID の強固なソリューションを導入すれば、2番目の「A」である認可の要件への対応に集中できます。 IoT ソリューションの開発者が直面する一般的な認可のユースケースに焦点を当てます。一般的に、ユーザー、デバイス間の構成は 1:1 、もしくは 1:多となることが多いため、以降ではそれらのケースについて例をご紹介します。 単純なユースケース: 1 ユーザー 1 デバイス(1:1) 1 ユーザーが 1 つのデバイスを利用するケースは、最も理解しやすく、 IoT […]

Read More

Amazon Chimeで行う遠隔授業・講義

皆さんAmazon Chimeはご存じでしょうか?Amazon Chimeは組織の内外で会議やチャットなどができるサービスです。既に会議などでは多くご利用頂いてはおりますが、遠隔授業・講義でももちろんご利用頂くことが可能です。 Amazon ChimeではクライアントソフトウェアやWebブラウザ、SIPまたはH.323準拠のテレビ会議デバイスから遠隔授業に参加できます。もちろんiOSやAndroidのスマートフォンやタブレットも利用できます。またネットワーク回線が安定しない場所からの参加の場合には、電話を使用して音声での参加も可能です。 Amazon Chimeの特徴は、サービスのページ( https://aws.amazon.com/jp/chime/features/)に詳しくはありますが、同じ遠隔授業の仮想ミーティングルームへ 250 接続まで同時参加が可能です。ビデオはデスクトップは最大16名(モバイルデバイスは最大8名)の表示が可能です。遠隔授業の仮想ミーティングルームに接続すると、同一画面内にチャット領域があり、ファイルの転送も可能です。これを例えば質疑応答に使ったり、授業内で出てきたURLを共有したり、補足資料ファイルの配布などに利用したりすることができます。 また、セキュリティについても関心が高いと思われますが、Amazon Chimeはサービスに直接組み込まれたセキュリティ機能が備わっています。メッセージ、音声、ビデオ、コンテンツは AES 256 ビット暗号化を用いて暗号化されます。また、既存のディレクトリサービスと接続し、認証情報を使用して Amazon Chime にログインさせることもできます。     Amazon Chimeのセットアップ ■ 遠隔授業に参加される方 クライアントソフトウェアまたはWebブラウザでアクセスし、仮想ミーティングルームのID(設定されている場合は仮想ルームのPIN)を入力して参加します。ログインは不要です。 あらかじめ https://app.chime.aws/check から接続環境のチェック、クライアントソフトウェアのダウンロードが可能です。クライアントソフトウェアをご利用いただく方が安定してご利用いただけるかと思います。 ■ 遠隔授業を開催される方 仮想ミーティングルームの作成は、作成権限があるユーザ(Proユーザ)でログインします。必要に応じて新規の仮想ミーティングルームのIDを作成しておきます。遠隔授業に参加される方にはあらかじめ仮想ミーティングルームのID等をお伝えしておきます。授業の時間になりましたら、仮想ミーティングIDへ接続し、遠隔授業を開始します。 遠隔授業では、画面シェアできる人、発言できる人を限定したい場合があるでしょう。その場合には、クライアントソフトウェア内のメニューから開催中の遠隔授業をイベントモードに変更し、プレゼンターの指定や参加者のミュート、参加者がミュートを解除できないようにするなどの設定をします。また会議をロックすることが可能ですので、新たな参加者の参加を防ぐ設定も可能です。これらは自由にon/offできますので、授業の説明のときには、イベントモード、質疑応答の時にはイベントモードの解除といったことができます。 ■ Amazon Chimeの管理者 Amazon Chimeの環境構築は https://docs.aws.amazon.com/ja_jp/chime/latest/ag/what-is-chime.html にあります開始方法を参照していただき、AWSアカウントにログインし、Amazon Chimeのアカウントの環境構築をしてください。仮想ミーティングルームを作成できるProユーザの作成・管理も手順にしたがって人数分行い、遠隔授業を主催される先生方にProユーザをそれぞれ割り当ててください。   遠隔授業開催のTIPS ここではAmazon Chimeに限りませんが、遠隔授業開催時のちょっとしたコツをお伝えします。 1) 参加者は必要の無いときはミュートします。ノイズが入ってしまって他の方が聞きづらかったり、音が回ってしまうことを防ぎます。 2) お話する方はできるだけヘッドセットを使いましょう。会議用のマイク・スピーカーでも良いのですが、お部屋の状況によっては音が反射してしまい、他の参加者が聞き取りづらくなることがあります。また自宅からほとんどの方は参加されると思いますが、ヘッドセットを利用すると生活音などの雑音を拾いにくくなりますので、相手方も聞き取りやすくなります。ヘッドセットが用意できない場合には、イヤホンマイク、それも難しい場合は、音はイヤホンで聞いてください。音の回り込みを減らすためです。 3) ビデオが本当に必要かは考えましょう。ビデオを利用するとその分ネットワークの帯域を消費しますので、できるだけビデオは切るのが良いでしょう。板書などをしたいという方がおられると思いますが、残念ながら一般的にカメラ映像での板書は見づらくなります。数千円程度でタブレットが購入可能な時代ですので、タブレットとペイントソフト(またはPowerPointの描画機能)などを組み合わせ、その画面をシェア(またはアプリケーションウィンドウのシェア)してあげることで、見やすくしてはどうでしょうか。また妨害やストーカー行為などを懸念される先生方もいらっしゃるでしょう。その観点からも必要無ければ参加のビデオをoffとするのも良いでしょう。 4) セキュリティには気をつけましょう。大学等の講義であれば参加者を厳密に管理する必要性はないかもしれませんが、学校などで参加者を限定したい場合には、仮想ミーティングIDの他にPINを設定しておくなどの必要があるでしょう。またAmazon Chimeの管理者はどの地域で仮想ミーティングをホストするのかの選択も可能です。 5) 可能であれば、事前に資料(や動画・音声)などをLMSなどで配信しておくことでネットワーク負荷を分散させることができるかもしれません。コンテンツはトピックごとに5〜15分程度におさまるようにしておくのが良いでしょう。一部コンテンツが古くなってアップデートする際に、全部変えなくても良くなり、再利用性が高まります。また授業時間を事前学習時間分短くし、双方向のオンライン授業では質疑やディスカッションの場にするのも面白いかもしれません。 […]

Read More

IoT@Loft #9 IoTにおけるカメラ・動画の扱い方

IoT@Loft の第9回目は「IoTにおけるカメラ・動画の扱い方」をテーマに、初のオンライン開催を行いました。 見守りカメラや監視カメラ、ドライブレコーダーやロボットなど、IoTではカメラや動画を扱う様々なユースケースが存在します。一方で、デバイスやメディアを取り扱う際には、セキュリティやスケーラビリティなどのIoTならではの課題があります。また、Webカメラの普及や低価格化により、デバイスだけではなくサービスとしての差別化が必要になってきており、例えばクラウド側やエッジ側での認識技術などと組み合わせることによる付加価値の提供も重要です。 この回では、エッジAI処理カメラやIoT通信プラットフォームを提供されているソラコム様、防犯カメラのクラウドサービスを提供されているセーフィー様に登壇いただき、カメラデバイスや動画を扱うサービスやソリューションにおけるAWSのユースケースや課題についてお話しいただきました。また、AWSからは、IoTにおける動画ソリューションの構築方法やその事例について紹介しました。

Read More

AWS トレーニング : 新コース「Planning and Designing Databases on AWS」を6月から受講できます

こんにちは!AWS テクニカルトレーナーの冨田修平です。様々なクラスルームトレーニングとプライベートオンサイトトレーニングを担当しています。 さて、本日は AWS トレーニングの新コース「Planning and Designing Databases on AWS」を紹介します。既に以下のリリース記事の通り、本コースは 2020年1月 に発表された新コースです。そして、日本では 2020年6月 から受講できることになりました。 新しい 3 日間のクラスルームコース: Planning and Designing Databases on AWS コース概要 AWSにおける設計のベストプラクティスの一つに”適切なデータベースソリューションを選択する”があります。 適切なデータベースとは何でしょうか? 一般的にはデータベースといえばリレーショナルデータベースが多く使われていますが、不向きなケースもあります。例えばデータの項目が様々で事前にスキーマを定義しておくことが難しいケース、一秒間に数十万、数百万回など非常に高い頻度のアクセスが必要なケース、大量のデータを高速に並列処理しなければならないケースなどがあります。このトレーニングに登場するさまざまなデータベースはこういったリレーショナルデータベースが不得意とする領域をカバーすることができますが、逆にリレーショナルデータベースの得意とするトランザクションやデータの一貫性が不得意なケースもあります。大規模なシステムを構築、もしくは既存のシステムをリファクタリングする際には、データモデル、データベースごとの機能/非機能要件に合わせた使い分けが重要となります。 「Planning and Designing Databases on AWS」はまず様々なデータベースを使い分けるための基礎となる原則や概念について学びます。続いて、AWSの8つのマネージドデータベースサービスについて、それぞれに適したワークロードとデータモデリング、リソースの設計について学習します。 参考までに本コースの「モジュール構成」を以下に載せます。演習(ラボ)もあります。 モジュール 1 : Database Concepts and General Guidelines モジュール 2 : Database Planning and Design モジュール 3 : Databases on Amazon […]

Read More

AWSのコストを削減する9の方法

みなさん、こんにちは。アマゾン ウェブ サービス ジャパン シニアエバンジェリストの亀田です。 昨今、世の中の状況の変化に伴い、ITリソース使用量の増減の振れ幅が大きく、また予測が難しい、通常とは異なるビジネスの状況に多くのお客様が直面しています。また、その状況に対応するためリソースの流動性を確保するためにシステムをクラウドへ移行するケースが増えています。既存システムのクラウド移行にはいくつかのアプローチがありますが、稼働中のシステムを移行させる場合、移行作業の影響を最小限にするため、Lift & Shiftという手法がとられます。システムアーキテクチャやアプリケーションへの変更を極小化したなるべく同じ状態でクラウドへシステムを移行し、稼働後必要に応じて適宜アーキテクチャ、アプリケーションなどを最適化していく方法です。一度クラウド化されたシステムはそのコピーを容易に作成させることができるため、リソースが有限であるオンプレミス上でシステム変更を行うよりは効率の良い移行方法といえます。 この際、アーキテクチャやアプリケーションへの修正影響範囲を極小化したまま、AWSのコストを最適化させる方法もいくつか存在しています。これは移行にかかわらずAWSを利用している全てのお客様が検討すべきであり、かつ迅速に効果が見込められる9つのコスト最適化のためのツールとアプローチをこのブログにて3回連載で取り上げます。 #1 未使用状態のAmazon EC2やAmazon RDS インスタンスへの支払いを止める #2 未使用状態の Amazon Redshift クラスターへの支払いを止める #3 Amazon S3 Intelligent-Tieringを有効にする #4 Amazon DynamoDB にはオンデマンドのキャパシティーモードを利用する #5 十分に活用されていないEC2 インスタンスへの支払いを止める #6 十分に活用されていないネットワークリソースを削除する #7 EC2 スポットインスタンス を利用する #8 Compute Savings Plans を利用する #9 リザーブドインスタンスを利用する いずれも迅速なコスト最適化が実現できる方法です。いくつかはAWSリソースの設定並びに管理方法の変更を必要としますが、特に8、9は購入オプションの変更により即時コストを削減可能となります。この第一回目の記事では、#1から#3を取り上げます。 #1 未使用状態のEC2やRDS インスタンスへの支払いを止める 開発環境、テスト環境などの本番環境以外で実行されているワークロードや、ミッションクリティカルでないワークロードなどにおいて、夜間、週末および祝日で、利用していない時間帯のEC2やRDSの費用を支払っている可能性があります。AWS では、AWS CloudFormationで事前に構築された以下の図において、AWS Instance Schedulerと呼ばれるソリューションを用いることで、インスタンスのスケジューリングを容易に実行することができます。AWS Instance Schedulerは、EC2 および RDS インスタンスの開始と停止のスケジュールを簡単に設定できるシンプルなソリューションです。 このソリューションは導入が容易で、AWS利用コストだけではなく運用コストの削減にも有効です。 インスタンスのスケジューリングにより、クラウドの伸縮自在な性質を活用し、必要な分だけ料金を支払うことができます。例えば、以下のグラフでは、EC2 インスタンスのコストを削減するために週末の稼働時間を削減していることを確認できます。 環境のサイズや複雑さに応じて、実装に数分から数時間かかります。このソリューションを使用して、金曜日の午後 6 時から月曜日の午前 6 […]

Read More

金融機関が機密性の高いデータのためにAWS のサービスを承認する方法

本投稿は ワールドワイドで金融業界を担当している プリンシパルソリューションアーキテクト の Ilya Epshteyn による寄稿を翻訳したものです。 グローバル展開されている金融事業グループの中でプリンシパルソリューションアーキテクトとして、私が最もよく聞かれる質問の1つは、特定の AWS サービスが 金融サービスで利用可能かどうかです。金融サービスのような規制された業界では、クラウドへの移行は単純なリフト&シフト作業ではありません。代わりに、金融機関は、 一般的にホワイトリストと呼ばれる秩序だったサービスごとの評価プロセスを使用して、クラウドサービスが規制上の義務にどのように対応できるかを実証しています。このプロセスが明確に定義されていない場合、クラウドにデータを移行する作業が遅れる可能性があります。 この記事では、最も機密性の高いデータに対するクラウドサービスのホワイトリスト化を簡素化するため、金融機関が焦点を当てるべき 5つの重要な考慮事項 で構成されるフレームワークについてご説明します。また、⾦融サービス組織がこの作業をする上で役⽴つ重要な AWS 機能についても概説します。 5 つの重要な考慮事項は、以下の通りです: コンプライアンスの達成 データ保護 コンピューティング環境の隔離 API による監査の自動化 運用上のアクセスとセキュリティ 私がこれまで関わってきたビジネスリーダーやテクノロジーリーダーの多くにとって、俊敏性と素早い変革がクラウド化の最大の推進要因です。金融サービス機関はクラウドに移行することで、パーソナライズされたデジタルエクスペリエンスの開発、データサイロの打破、新商品の開発、既存商品の利益率の向上、グローバルなリスクとコンプライアンス要件への積極的な対応を行いやすくしています。幅広い AWS サービスを使用する AWS のお客様は、クラウド導入の段階を進むにつれて俊敏性を高めることができるようになります。幅広いサービスを使用することで、組織は差別化につながらない面倒な部分を AWS に任せて、コアビジネスと顧客に集中することができます。 私の目標は、金融サービス機関が(本番環境とミッションクリティカルなワークロードの両方で)自社の極めて機密性の高いデータをクラウドに移行することに対し、ガイドを提供することです。以下の考慮事項は、金融サービス組織がクラウドサービスへの準備状況を判断し、クラウドで成功を収めるのに役立つでしょう。 1. コンプライアンスの達成 ホワイトリストのプロセスを使用する金融機関にとっての最初のステップは、クラウドサービスプロバイダー (CSP) のサービスの基盤となるコンポーネントが、基準となるコンプライアンスのベースラインを満たせるようにすることです。これについて確信を持つための重要な前提条件は、 AWS 責任共有モデルを理解することです。責任共有とは、AWS 上でアプリケーションが安全に機能するためには、CSP としてのAWSおよびお客様との両者でのアクションが必要であることを意味します。AWS のお客様は、クラウド 内 のセキュリティに責任があります。お客様は、コンテンツ、アプリケーション、システム、ネットワークのセキュリティを制御および管理します。 AWS は、 クラウドの セキュリティを管理し、サービスと機能の適切な運用の提供および維持し、AWS のインフラストラクチャとサービスの保護、運用上の優秀性の維持、関連する法的および規制要件を満たします。 責任共有モデルのAWS 側への信頼を確信するために、お客様は、独立した第三者監査人が作成したAWS System and Organization Controls […]

Read More