Author: AWS Japan

こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。 1月23日にre:Invent 2017で発表されたAWS Media Servicesのラウンチセミナーを行いましたので、その資料公開とともに内容をブログでお届けします。 AWS Media Servicesは、クラウド上で動画ワークフローを構築可能なフルマネージドのメディアサービス群となります。 このサービスを使用して、信頼性の高い、ブロードキャスト品質の動画ワークフローをクラウド上で簡単に構築できます。AWS Media Servicesを使用すると、メディアおよびエンターテイメント企業、エンタープライズ、スタートアップ企業、政府機関のいずれを問わず、視聴者にプロフェッショナル品質のメディア環境を簡単に提供できます。従来のデータセンターで時間、労力、費用を費やして特殊なビデオ機器を運用する必要はありません。これらのオンデマンドで伸縮自在なサービスにより、イノベーションを加速させ、動画テクノロジーのさまざまな変化に迅速に対応できます。 Amazon CloudFront、AWS CloudFormation、Amazon CloudWatch などの AWS の補完的なサービスと、セキュリティ、管理、本番環境向けサードパーティアプリケーションとの統合により、ライブ動画およびオンデマンド動画コンテンツの処理と配信のためのツール一式が提供されます。 AWS Media Servicesは全部で5個のサービスから構成されます。 AWS Elemental MediaConvert AWS Elemental MediaLive AWS Elemental MediaPackage AWS Elemental MediaStore AWS Elemental MediaTailor それぞれのサービスの紹介は是非、上記リンクをクリックしてご確認ください。 セミナーではまず、私の方からAWSのロードマップに見るCloudFrontの重要性や、分散型と集中型におけるアーキテクチャの違い、AWSメディアワークロードの事例についてお話をさせていただきました。 続いて、AWS Elementalプロダクト マネージメント ディレクターのリオネル・ブランギエ から 本題のAWS Media Services 紹介セッションを同時通訳でお届けしました。 その後、ソリューションアーキテクト M&E の安司　仁より、「初心者でも簡単 AMSデモンストレーション」としてLive配信を20分で構築可能なデモを行いました。 20180123 20分でlive配信aws media services（media live mediapackage）_pub 当日、一部設定ミスをおこしても操作開始から１０分程度で発表者のスマートフォンからLive配信を確認いただき、簡単かつ迅速に環境構築、配信可能であることを体感頂きました。   […]

Amazon AuroraのMySQL 5.7互換版が皆様にご利用頂けるようになりました。JSONサポート、空間インデックス、generated columnsなどをご利用頂け、MySQL 5.7より最大5倍高速です。 Amazon Auroraの空間インデックスの作成は、MySQL 5.7よりも20倍以上の書き込みパフォーマンスと10倍以上の読み込みパフォーマンスとなっています。この機能がどのように実装されているかについては、AWSデータベースブログをご覧ください。またAmazon Auroraのドキュメントもご参照下さい。 Aurora with MySQL compatibilityがご利用頂ける13リージョン(US East (N. Virginia), US East (Ohio), US West (Oregon), US West (N. California), Canada (Montreal), Europe (Ireland), Europe (Frankfurt), Europe (London), Europe (Paris), Asia Pacific (Tokyo), Asia Pacific (Sydney), Asia Pacific (Seoul), and Asia Pacific (Mumbai))全てでご利用頂けます。 ハイエンドな商用データベースのパフォーマンスと可用性を、オープンソースデータベースのシンプルさとコスト効率と組み合わせたAmazon Aurora (MySQLとPostgreSQL互換のリレーショナルデータベース)の詳細については、Amazon Auroraの製品ページをご覧ください。 CLIを用いた際のエンジンバージョンの指定方法や、スナップショットを利用したアップグレードなどAurora MySQL5.7互換に関する詳細な情報はドキュメントやフォーラムアナウンスをご覧ください。 […]

Somckit Khemmanivanhは、Amazon Web Services(AWS)のSAP Solutions Architectです。 現在、AWSクラウド上の244 GiBから4 TiB RAMのスケールアップ、あるいは最大50 TiB RAMのスケールアウトで認定されているSAP HANAシステムの自動的なプロビジョニングとインストールのために、AWS SAP HANAクイックスタートは利用されていますか？FAST移行プログラムの移行戦略の一環としてSAP HANAクイックスタートを使われているかもしれません。もし、SAP HANAシステムとして1つ、あるいは複数のSAPアプリケーションをプロビジョニング、インストールしたいとき、これらと同様なシナリオを必要としていないでしょうか。少し前までは、独自のAWS CloudFormationテンプレートを作成するか、自動的にAmazon Elastic Compute Cloud(Amazon EC2) インスタンスをプロビジョニングして、SAPシステムをインストールするカスタムスクリプトを開発する必要がありました。今回のSAP NetWeaverクイックスタートにより、これらの面倒な仕組みづくりや手作業を排除できます。お客様に必要なすべてのこれらのタスクが実行されるので、お客様は他のビジネスクリティカルな活動に集中することができます。 SAP NetWeaverは、SAP アプリケーションを開発・実行するための一連のテクノロジーを提供する基盤コンポーネントです。SAP Business Suite、SAP S/4HANA、SAP Business Warehouse(SAP BW)、および SAP BW/4HANAなどのSAP製品やアプリケーションは、SAP NetWeaverに依存しています。クイックスタートは、AWSベストプラクティスに従い、AWS上に主要なテクノロジーをデプロイするためのAWS CloudFormationテンプレートを使用して、リファレンスの展開を自動化します。このクイックスタートは、Advanced Business Application Programming(ABAP)用のSAP NetWeaver Application Server(AS)を展開し、SAP HANAデータベース用のABAPベースのアプリケーション開発をサポートします。SAP HANAクイックスタートと統合されており、引き続き個別に展開することもできます。 このクイックスタートは、AWSクラウド環境にSAPアプリケーションサーバを展開し、これらのサーバをSAP HANAシステムと接続して統合します。その結果、完全にプロビジョニングされ、自動的にインストールされたSAPシステムがSAP HANA上で実行されます。 以下は、SAP NetWeaverクイックスタートが展開するアーキテクチャの概要です。 このクイックスタートでは、お客様のAWSアカウントにおける仮想プライベートクラウド(VPC)内に、SAPアプリケーション層、SAP HANAデータベース層、リモートデスクトッププロトコル(RDP)、および踏み台ホストを展開します。この展開には、SAPシステムの機能を提供するプライマリアプリケーションサーバ(PAS)インスタンスと、SAPアプリケーション層をスケールアウトするためのオプションであるアディショナルアプリケーションサーバ(AAS)インスタンスを含みます。 システムを異なった方法で構築したい場合は、GitHubリポジトリからAWS CloudFormationテンプレートとスクリプトをダウンロードし、お客様の固有要件に合わせてカスタマイズすることができます。 AWS上でSAP […]

こんにちわ。プロダクトマーケティング エバンジェリストの亀田です。 日々セミナーなどで皆さんにいろいろなコンテンツをお届けしていますが、その中でとても多くの再演要望をいただいているセミナーがあります。今回その「見積もり作成のハンズオン」をオンデマンドウェビナーとしてご提供することができるようになりました。お申込みをいただければ、いつでも皆さんが必要な時に視聴できるようになっています。是非こちらからお申込みください。 全部で3部構成となっています。 Part 1： Amazon EC2、Amazon RDS 等 主要サービスの費用について基本的な考え方をまとめています。   Part 2： 概算費用算出における検討事項のポイントやお支払方法についてまとめています。 クラウドは IT リソースの伸縮が自由であり、オンプレミス型の IT とは考え方が異なる部分が多くあります。見積もり作成において、そのあたりの注意点が含まれています。また日本円支払い、請求書支払いについてもまとめました。 Part 3： 実際の練習問題をもとに簡易見積もりツールを用いて、皆さんに見積もりを作成いただくハンズオン形式になっています。AWS の提供するクラウドサービスは、従量課金で費用想定が複雑だと思われるかたもいらっしゃるかもしれません。実際は、非常に簡易に概算費用の予測が可能となっています。是非お試しください。 より複雑な構成での概算費用が必要な方は、担当アカウントマネージャにお問い合わせいただくか、こちらのお問い合わせフォームまでお問い合わせください。 また、見積もりではなく、 AWS の基本的なコンセプトなどの独習をご希望される方は、弊社シニアプロダクトマーケティングマネージャー 石橋による、はじめての AWS オンデマンドウェビナーを合わせてご視聴ください。   – プロダクトマーケティング エバンジェリスト 亀田

この記事はAstadia社のレガシーモダナイゼーションサービスのバイスプレジデントである Craig Marbleによるものです。 ユニシスメインフレームをお持ちの場合は、あなたはビジネスのバックボーンとして機能している信頼性の高いプラットフォームとアプリケーションポートフォリオの構築に投資していると思います。しかし、今日の技術環境は、ユニシス、メインフレームが提供できるよりも低コストで、より柔軟性と俊敏性を必要としています。 Amazon Web Services（AWS）のコンサルティングパートナーであるAstadiaでは、ユニシスメインフレームのアプリケーションワークロードを実行するための現代的で柔軟性のある選択としてAWSを利用しており、ユニシスメインフレームのアプリケーションとデータへの過去の投資を活用していることがわかりました。 慎重に計画、管理、実行すると、ユニシスメインフレームワークロードをAWSに移行することの利点は数多くあります。 Pay-as-you-goモデルのコスト削減に加えて、ユニシスメインフレームアプリケーションセットがAWSに完全に移行されると、実証済みのビジネスロジックを最新のテクノロジーと統合して、データ分析やモバイル対応を可能にし、新しい市場、顧客、パートナーにビジネスを拡大します。これを念頭に置いて、ユニシスメインフレームアプリケーションをクラウドに移行することは、贅沢と言うより必要にせまられてということのようです。 この記事では、ユニシスメインフレームアプリケーションをAWSに移行するのに役立つ５つのステップを紹介します。 元のアプリケーションのソースコードとデータを再利用し、最新のAWSサービスに移行することをお勧めします。 ユニシスメインフレームの移行を可能にするツールは、既存のコードをそのまま維持することができますが、一部のコンポーネントを置き換えてデータストレージを再考する必要があります。 このような最小限の変更のアプローチは、手作業の書き換えやパッケージの置き換えに比べてプロジェクトのコストとリスクを削減し、20年または30年の投資を活用しながら新しい市場を活用するための新技術との統合のメリットを享受します。ひとたび移行されると、アプリケーションは、既存のスタッフが現代化を進めるのに十分な特性をもつようになります。また価値ある知識野蓄積を新しいデベロッパーに伝えています。 ステップ１：ディスカバー まず、環境内のすべてのアプリケーション、言語、データベース、ネットワーク、プラットフォーム、およびプロセスをカタログ化して分析する必要があります。アプリケーション間のとすべての連携ポイントと、外部連携ポイントを文書化します。できるだけ多くの自動分析を使用し、すべてを一元的なリポジトリにまとめます。 Astadiaは、Micro Focus Enterprise Analyzerなどの商用分析ツールと独自に開発したパーサーを組み合わせて、従来のコードを迅速かつ効率的に分析します。この分析出力は、Astadia Code変換エンジンに供給される移行ルールを確立するために使用されます。これらのルールは、プロジェクト全体を通じて更新され、洗練されます。 ステップ２：デザイン すべてのソースコード、データ構造、および最終形の要件を分析した後、ソリューション設計をするときが来ました。設計には、以下の詳細を含める必要があります。 AWSインスタンスの詳細：インスタンスタイプについて言うと、汎用Tインスタンスは、開発、テスト、または統合環境に向いていますが、汎用Mインスタンスは本番環境、本番前環境、およびパフォーマンスが要求される環境に向いています。 トランザクション負荷：一般的な非機能要件ですが、1秒あたりのトランザクション数が多いなどのパフォーマンス要件、または迅速な応答時間は、メインフレームのワークロードの実行にとって重要な場合が多いです。このことはネットワーク、ストレージ、コンピューティングの設計とサイズ設定を慎重に行う必要があるということです。 バッチ要件：バッチアプリを動かすほとんどすべてのユニシスメインフレームは、通常I/O集約型で、ストレージやデータストアからのレイテンシーが非常に短い事が要求されます。これは分散システムの課題であるため、バッチインフラストラクチャは早期に設計してテストする必要があります。 プログラミング言語の変換と置換：移行対象先でサポートされていない言語や使用できない言語は、ツールで変換したり、新しい機能に置き換えることができます。 外部システムとの統合：ユニシスメインフレームは、一般的にサテライトやパートナーシステムのバックエンドまたは記録システム（SOR）であり、移行後にはプロトコル、インターフェイス、レイテンシー、帯域幅などの統合を維持する必要があります。 サードパーティのソフトウェア要件：各ISV（Independent Software Vendor）はAWS上で機能的に同等のソフトウェアを利用できる場合もあれば、そうでない場合もあるため、特定の移行パスの定義が必要です。 将来要件の計画：ビジネス、IT戦略、優先順位は、特に将来のパフォーマンスと統合機能に関わるため、アーキテクチャの決定を左右します。 ソースコードには、Sperry MAPPER、Burroughs LINC、COBOL、またはECLが含まれます。データストアには、DMS（ネットワーク接続）、DMSII（階層型）、またはRDMS（リレーショナル型）が含まれます。 このデザインがUnisys ClearPath Libraマッピングを探す方法は次のとおりです。 図2 – Unisys Libra（Burroughs）メインフレーム移行アーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。   同様のマッピングは、TIP、MASM、BIS（Mapper）、ECLを含むUnisys ClearPath Doradoシステムでも実行できます。 図2のアーキテクチャのコアコンポーネントは、レガシーコードを実行するための一連のエミュレータとユーティリティを使用するメインフレームクラウドフレームワークです。 OpenMCSは、移行されたコードをサポートするUnisys COMSの必要なトランザクション処理機能を提供するAstadiaのメッセージ制御システムです。このメインフレームクラウドフレームワークは、コンピュートリソースとしてAmazon Elastic Compute Cloud（Amazon EC2）上で動作します。 ほとんどの場合、ユニシスメインフレームの階層型およびフラットファイルのデータ構造は、Amazon Relational Database Service（Amazon […]

こんにちは。ゲームソリューションアーキテクトの吉田です。 昨日1/24(水)に第２回となるGaming Tech Nightを開催し、多くのゲーム開発者、インフラエンジニアの方々にご参加いただきました。Gaming Tech Nightは過去2016年に開催された、ゲームに特化した技術情報をお届けすることを目的としたAWS主催のイベントでしたが、今年からは定期開催イベントとして新しく生まれ変わりました。記念すべき再開１回目となる今回は、re:Born(再始動)というタイトルでサーバレスやCI/CDなど複数のテーマで計４セッションをお届けしました。   サーバレスアーキテクチャ入門 ~ Game Server Services 丹羽様 Game Server Services株式会社 代表取締役社長CEOの丹羽様より、サーバレスアーキテクチャについてご講演いただきました。入門というタイトルですが、サーバレスの定義から実装に関する注意点、実際に丹羽様が構築・運用する中で習得されたノウハウなどが詰まった内容の濃いセッションでした。これからサーバレスをはじめる方だけでなく、すでに構築・運用されている方々にも非常に参考になるポイントが多かったのではないかと思います。登壇資料はGS2 Blogで公開されています。   AWSにおけるモバイルゲーム向けAPIサーバの実装2018 ~ ソリューションアーキテクト 畑 ソリューションアーキテクトの畑より、モバイルゲームを対象としたAWSにおけるAPIサーバ実装について解説しました。典型的な実装パターンである３層Webアプリケーションパターンをはじめ、API Gateway+Lambda+DynamoDBを利用したサーバーレスアーキテクチャ、アプリケーション上で実装されたAWS SDKを通じて各AWSサービスのAPIに直接アクセスする2-Tierアーキテクチャなどの実装ポイントをご紹介しました。また、現在Public Preview中であるAWS AppSyncによる実装パターンにも触れました。API用のクエリ言語であるGraphQLは、クライアント〜サーバ間で共有される型が利用できたり、クライアント側からサーバのレスポンスデータの形式を指定できたりとモバイルゲームでも応用できる多くの利点があります。AWS AppSyncはマネージドなGraphQLのサービスであり、ゲーム開発者の方にもインフラを意識することなくご利用いただけます。ぜひPreviewにご参加ください。 Serverless backendformobilegame and_aws-appsync_gamingtechnight-2   AWS上で実現するゲーム開発CI/CDパイプライン ~ ソリューションアーキテクト 森 ソリューションアーキテクトの森からは、AWSのCode系サービスを利用したゲーム開発におけるCI/CDパイプラインの実装例の解説とデモを披露しました。ソースコードをCodeCommitにpushし、CodeBuildによるビルド、CodeDeployによるステージング環境へのデプロイ、そしてステージングでのテスト完了後に再度CodeDeployを使って本番環境にという一連の流れをCodePipelineを自動化することが可能です。特にコードのビルドについては、ビルド用で常にインスタンスを確保されているお客様も多いと思いますが、CodeBuildはビルド実行時間のみの課金となりますので、コストが削減できるケースも多いと思います。ぜひゲーム開発のCI/CDにおいてもAWSのマネージドサービスをご活用ください。 Gaming cicd-pipeline gaming-technight-2   AWSを最大限活用したロングヒット戦略 ~ Amazon Game Services 下田 最後のセッションでは、Amazon Game Serviceの下田からは、オンラインゲームでAWSを導入する際に考慮すべきポイントや、クラウドを利用してどのようにゲームの価値高めていくかについて解説しました。設計段階でのユーザ数やゲームフローを意識したプランニングや負荷試験、網羅的なアーキテクチャレビューの必要性をはじめ、ロングヒット戦略の施策に欠かせないユーザ動向解析などの分析に関するAWSのツール群もご紹介しております。オンラインゲームのサービス構築ではいろいろな重要な要素を考慮する必要がありますが、ご不明な点がございましたら、ぜひ弊社ソリューションアーキテクトまでご相談ください。   Long hit strategy-gamingtechnight-2 […]

私たちは、AWS Glue の ETL(Extract、Transform、Load)を実行するためのスクリプトにおけるScalaのサポートを発表することに興奮しています。Scala が好きな人達は強力な武器を1つ手に入れることになり喜んでくれるでしょう。AWS Glue では Apache Spark をデータ加工のエンジンとして使用していますが、Scala は Apache Spark のネイティブな言語です。 洗練された言語としての機能が使える以外にも、Glue のスクリプトをScala で書くことはPython で書くことに比べて2つの利点があります。まずは、Python とApache Spark のScala ランタイム(JVM)の間でデータを移す必要がないので、Scala は大量のデータ移動を伴う加工整形処理がより高速です。サードパーティのライブラリで独自の変換を作成したり関数を呼び出すことができます。 次に、Scala はJava と互換性があるように設計されているため、外部Java クラスライブラリの関数をScala から呼び出すことが簡単です。 そのため、Scala のコンパイル結果は Java と同じバイトコードになりますしデータ構造を変換する必要もありません。 これらの利点を説明するために、GitHubアーカイブから入手可能なGitHub パブリックタイムラインの最近のサンプルを分析する例を説明します。このサイトはGitHubサービスへのパブリックリクエストのアーカイブで、コミットとフォークから、イシューとコメントまで35種類以上のイベントタイプを記録しています。 この記事は、タイムラインのネガティブなイシューを特定するScala スクリプト作成の方法を紹介します。このスクリプトではタイムラインサンプルのイシュー イベントを引き出し、Stanford CoreNLPライブラリのセンチメント推定機能を使用してタイトルを分析し、最もネガティブなイシューを浮き彫りにしています。 入門 スクリプトを作成する前に、AWS Glue Crawler を使ってデータ構造と特性を理解します。また、開発エンドポイントとZeppelin ノートブックをセットアップすることで、データをインタラクティブに探索してスクリプトを作成することもできます。 データをクロールする この例で使われているデータセットは、GitHub アーカイブからAmazon S3 のサンプルデータセットバケットにダウンロードされています。場所は以下の通りです： s3://aws-glue-datasets-<region>/examples/scala-blog/githubarchive/data/ <region>をあなたの作業中のリージョンに置き換えて最適なフォルダを選択してください。例えばap-northeast-1 などです。AWS Glue Developer Guide […]

多くのAWSのお客様がミッションクリティカルなワークロードをIBM Db2データベースプラットフォームを利用して実行しています。一般的に、こういったワークロードには、ノード障害やデータセンターサイトの障害時でも運用を続けられる高い可用性が必要とされます。 従来のIBMソフトウェアにおける高可用性手法は、共有ディスクと仮想IPアドレスを使用し、これをTivoli System Automation for Multi-Platforms (TSAMP)でコントロールするというものでした。このブログポストでは ネイティブのIBMとAWSの技術を用い、かつ自動化された手法を説明します。これによりミッションクリティカルなDb2ワークロードをAWS上で稼働でき、高可用性のDb2データベースを安心して提供できるようになります。 注：このガイドで使用するIBM Db2は、フル機能が90日間利用できるトライアル版のDb2 for Linux, Unix and Microsoft Windows バージョン11です。トライアル期間が終了したあとは、必要とするエディションを選択、購入し、ライセンスファイルを導入して利用することが可能です。このガイドで利用している機能が使用できるエディションは、Db2 Advanced Enterprise Server Edition、 Db2 Enterprise Server Edition、Db2 Advanced Workgroup Server Edition、Db2 Workgroup Server Editionです。より詳細な情報はIBM Webサイトを確認してください。（訳注：こちらにエディションの違いの詳細があります） この記事のステップを進めていくと、2つのアベイラビリティゾーン（AZ）にまたがって高可用性を実現するDb2 データベースを作成します。データはAZ1にあるプライマリーインスタンスとAZ2にあるスタンバイインスタンスの間でHADR(High Availability Disaster Recovery)機能でレプリケーションされます。もしプライマリーノードが利用できなくなった場合、TSAMPがそれを検知し、スタンバイインスタンスにフェイルオーバーさせます。Db2 クライアントアプリケーションは自動クライアントリルート機能 (IBM Automatic Client Reroute : ACR)により自動的に新しくプライマリーになったインスタンスに再接続されます。 事前準備のステップ このソリューションはAWSのデフォルトVPC (Virtual Private Cloud)にデプロイされます。デフォルトVPCはAWSアカウント作成時に自動的に各リージョンに作成されています。もしデフォルトVPCが無い場合は、次のステップに進む前に以下を実行してください。 同一リージョンの２つのパブリックサブネットを持つVPCを作成してください。それぞれのサブネットは別のAZに配置してください。 VPCにインターネットゲートウェイを配置してください。それぞれのサブネットはインターネットゲートウェイ経由でインターネットに出られるようにします。 最初にAmazon S3 […]

本日 東京リージョンにて、新たにアベイラビリティゾーンを追加しました。東京リージョンは、追加のアベイラビリティゾーンを合わせ、4つのアベイラビリティゾーンになりました。 AWSは、世界中に18の物理的なリージョンと51のアベイラビリティゾーンがあります。本日追加されたアベイラビリティゾーンは、シンガポールリージョンに続き52番目となり、東京リージョンでAWSのクラウドコンピューティングをご利用の10万以上のお客さまにご利用いただけます。 アベイラビリティゾーンは、自然災害やデータセンター単位の障害などビジネスに影響を与えるリスクを最小化するよう地理的に影響を受けない十分離れた場所にあり、フェイルオーバーを実現し事業継続性を確保できるインフラストラクチャです。各アベイラビリティゾーンは、独立した電源、空調、物理的なセキュリティを備え、広帯域でハイスピードの光回線のバックボーンに接続されています。AWSのお客さまは、アプリケーションを複数のアベイラビリティゾーンを利用することで高い耐障害性を実現することができます。また、100以上の Amazon CloudFront エッジロケーションにより遅延を最小化しつつ、ウェブサイト、アプリケーションおよびコンテンツの配信が可能となります。 すでに東京リージョンをお使いのお客さまは、追加されたアベイラビリティゾーンにおいて、東京リージョンで利用可能なすべてのサービスを利用できます。

モダンコンピュータプロセッサ上で投機的実行によるサイドチャネル分析の調査が新しく公開されたのを受け、AWS は AWS Security Bulletin（セキュリティ情報）AWS-2018-013 を先日公開しました。このセキュリティ情報では、CVE-2017-5715、CVE-2017-5753、および CVE-2017-5754 の3つのセキュリティ勧告に触れています。これらの勧告は Google Project Zero の調査に基づいたもので、Google Project Zero の発表はモダンコンピュータプロセッサ上でのサイドチャネル分析の新しい方法を発見したというものでした。これらの方法は、基礎的な技術、具体的には投機的実行に着目したもので、投機的実行は多くのベンダーのプロセッサに用いられています。そのため研究結果の対象となる範囲は幅広く、その範囲はハイパーバイザーからオペレーティングシステム、さらには Web ブラウザ、携帯電話からクラウドを構成するデータセンター内のサーバにまで及びます。   EC2 インスタンスの分離   Amazon EC2 のすべてのインスタンスは、上述の CVE に記載されたインスタンス間の既知の問題すべてから保護されています。インスタンス間での問題は、インスタンスまたは AWS ハイパーバイザーのメモリを近隣の別のインスタンスから読み取ることができると想定しています。この問題は AWS ハイパーバイザーでは解決されており、インスタンスは別のインスタンスのメモリを読み取ることも、AWS ハイパーバイザーのメモリを読み取ることもできません。 大多数の EC2 ワークロードに有意なパフォーマンスの影響は見られていません。   オペレーティングシステムへのパッチ   現代のオペレーティングシステムには、「ユーザー空間」プロセスからのカーネル分離、それぞれのプロセスの分離などの、いくつかのタイプのプロセス分離があります。影響を受けうるプロセッサ上でオペレーティングシステムが実行されている環境では、いかなる設定においても、公開された 3 つの問題すべてがプロセス分離に影響を与える可能性があります。ハイパーバイザで実装されている保護は、オペレーティングシステム内のプロセスレベルの分離にまで拡張されないため、リスクを軽減するためにオペレーティングシステムパッチが必要です。 準仮想化（PV）インスタンスでは、CVE-2017-5754 のプロセス間の問題に対処するためのオペレーティングシステムレベルの保護は無いことに注意してください。PV インスタンスは、前述のようにインスタンス間の問題について AWS ハイパーバイザーによって保護されます。しかしながら、PV インスタンスにおけるプロセスの分離（信頼できないデータ処理やコードの実行、ユーザのホスト）にご懸念をお持ちでしたら、長期的に見てセキュリティの恩恵を受けるため、HVM インスタンスタイプへの変更を強くお勧めします。PVとHVMの相違点（およびインスタンスアップグレードパスのドキュメント）の詳細については、以下の URL を参照してください。 https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html インスタンスのオペレーティングシステムにパッチを適用することで、同じインスタンス内で動作するソフトウェアを分離し、CVE-2017-5754 のプロセス間の問題を緩和することを強く推奨します。以下のオペレーティングシステムのパッチの詳細を記載します。 Amazon Linux & […]