Amazon Web Services ブログ

  政府統一基準に対応したAWSクラウド利用のセキュリティリファレンスについて   アクセンチュア株式会社、株式会社NTTデータ、PwCあらた有限責任監査法人、富士ソフト株式会社は共同で、内閣サイバーセキュリティセンター（NISC）制定の政府統一基準に対応したAWSクラウド利用のセキュリティリファレンスを作成し、2017年3月23日より無償提供を開始しました。本リファレンスは、2016年8月31日に改訂された「政府機関の情報セキュリティ対策のための統一基準（平成28年度版）」を背景としており、クラウドの選定および利用の際のガイドラインやセキュリティ要件等の基準が追加されたことに対して、AWSクラウド環境におけるセキュリティ対応策の詳細を網羅的に提示しています。 サイバーセキュリティ基本法に基づいてNISCが制定する政府統一基準（以下、NISC統一基準）は、国内の政府機関が実施すべきセキュリティ対策の指針として幅広く利用されています。一方で、その要件やチェック項目は複雑かつ広範にわたるため、AWSクラウド等のクラウドを利用する際に、そのガイドラインや要件を満たすことを確認することは容易ではありませんでした。このたび共同開発した本リファレンスは、各社の情報セキュリティ対策に関する知見と実績を結集したものです。政府統一基準への準拠のノウハウを具体的に提示することにより、各政府機関が安全で信頼性の高いシステムを実現することを支援できるものと期待しています。   パートナー各社の取り組み   2017年5月30日に開催された「パブリックセクタ― シンポジウム ～AWS Summit Tokyo 2017 – Dive Deep Day～」にて、本リファレンスの作成者であるパートナー各社によるパネルディスカッションが行われ、各社の取り組みが紹介されました。

こんにちは。プロフェッショナルサービスの宮本です。AWS Black Belt オンラインセミナー 6 月の配信についてご案内させて頂きます。6 月は、AWSの新サービス、機能追加のご紹介や、5月30日から6月2日まで4日間に渡って開催予定のAWSサミットの振り返り、Lambda書籍発売を記念したLambdaの網羅的なサービス解説など幅広いラインナップでお送ります。 6 月の開催予定 サービスカット 6/7(水) 18:00-19:00 Amazon Redshift Update – 最近追加された新機能とRedshift Spectrumの解説 6/14(水) 18:00-19:00 検討中 6/21(水) 18:00-19:00 Server Migration Service Application Discovery Service 6/28(水) 18:00-19:00 AWS Code Services Part 2 ソリューションカット 6/13(火) 12:00-13:00 AWS Summit Tokyo 2017 まとめ 6/20(火) 12:00-13:00 Lambda書籍発売記念 お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。スピーカーおよびスタッフ一同、みなさまのご参加をお待ちしております。

今回は、去年 Amazon EC2 Container Service に追加したいくつかの機能に関する概要と、お客様事例やコードについてご紹介します。このサービスは EC2 インスタンスのマネージド型クラスターの範囲内で Docker コンテナをいくつでも実行しやすくします。また、同サービスはコンソール、API、CloudFormation、CLI、PowerShell のサポートも備えています。簡単にアクセスできるように、Linux や Windows Docker イメージを EC2 Container Registry に保存できます。 リリースの要約 それでは ECS の最新機能と、その使用方法を説明したブログをいくつか見てみましょう:「アプリケーションの負荷分散 (Application Load Balancing)」- 去年は「アプリケーションロードバランサー (application load balancer)」のサポートを追加しました。この高性能なロードバランシングオプションはアプリケーションレベルで実行され、コンテンツベースのルーティングルールで定義することができます。ダイナミックポートをサポートし、複数のサービスでの共有が可能なため、コンテナ内でマイクロサービスを実行しやすくなります。詳細については「サービスロードバランシング (Service Load Balancing)」をご覧ください。 タスクで使用する IAM ロール – ECS タスクに IAM ロールを割り当てることでインフラストラクチャを安全にできます。これにより、各タスクごとに細かく設定しアクセス許可を付与できるので、各タスクが必要とするアクセス許可を割り当てることが可能です。詳しくは「タスクで使用する IAM ロール (IAM Roles for Tasks)」をご覧ください。 サービス Auto Scaling – 需要の変化に応じるため、サービス (タスク) のスケールダウンやスケールアップに関するスケーリングポリシーを定義できます。お客様は必要なタスクの最小数および最大数を選択し、1 つまたはそれ以上のスケーリングポリシーを作成するのみです。あとはサービス […]

  2017年5月12日頃からWannaCry(別名、WCry、WanaCrypt0r 2.0、Wanna Decryptorなど)と呼ばれるランサムウェア(身代金マルウェア)による被害が世界中から報告されはじめました。日本でも複数の大手企業がこのマルウェアに感染したというニュースが報道されています。 このマルウェアは、ファイル共有および印刷共有サービスを提供するWindows SMBサーバー上に存在する脆弱性を悪用します。デフォルトでは、SMBサーバーはUDPポート137/138およびTCPポート139/445で動作します。また、Windowsオペレーティングシステムの複数のバージョンが対象で、Microsoft社は、この脆弱性を解消するため、2017年3月14日にMicrosoft Windows SMB Server（4013389）の重要なセキュリティ更新プログラムをリリースしました。詳細は、Microsoft MSRC blog もしくは Microsoft Security Bulletin MS1​​7-010 をご参照ください。   WannaCryによるAWSサービスへの影響   EC2 Windows   Amazon EC2上のWindowsに関しては、AWSから提供されている2017.04.12以降のリリースのAMIであれば、この脆弱性の被害を受けていません。また、自動更新が有効になっている場合も、この脆弱性は解消されています。2017.04.12より前のAMIを使用している、かつ、自動更新を有効にしていないお客様は、前述のセキュリティ更新プログラムをインストールすることをお勧めします。 AWSでは、セキュリティのベストプラクティスに従い、セキュリティグループの設定を確認し、その必要のあるインスタンスおよびリモートホストに対してのみ前述のポートへのアクセスを許可することを、常にお勧めしています。デフォルトでは、EC2セキュリティグループはこれらのポートをブロックします。 AWSのWindows AMIのリリースノートはこちらです。   WorkSpaces   Amazon WorkSpacesに関しては、2017 年4月15日以降にWorkSpaceを作成した、または、自動更新を有効にしたAmazon WorkSpacesのお客様は、この脆弱性の影響を受けません。 2017年4月15日より前にWorkSpaceを作成し、自動更新を有効にしていないお客様は、セキュリティ更新プログラムをインストールするか、 WorkSpaceを終了して再作成することをお勧めします。   Directory Service   AWS Directory Serviceに関しては、2017/05/20時点でパッチ適用作業が完了しました。お客様による対応は必要ありません。Amazon Simple AD、 AD Connector、AWS Cloud Directory はこの問題の影響を受けていません。最新情報につきましては、下の原文へのリンク先をご参照ください。   Elastic Beanstalk   […]

毎月数回、シアトルのエグゼクティブブリーフィングセンターでお客様と話をします。私たちのイノベーションのプロセスを説明し、各AWS製品のロードマップがお客様の要望とフィードバックによってどのように決められているかやりとりします。 その良い例が、SAP社のビジネスソリューションのポートフォリオにとってAWSを魅力的な場所にするための私たちの取り組みです。長年にわたり、お客様はAWS上で大規模なSAPアプリケーションを本番環境で稼働しており、このワークロードに対応するように設計されたEC2インスタンスを提供することに努めてきました。SAPシステムは間違いなくミッションクリティカルであり、SAP社はいくつかのEC2インスタンスのタイプとサイズで彼らの製品を利用できるよう認定しています。私たちは、AWSをSAP製品にとって堅牢で信頼できる基盤にし、認定を取得するために、SAP社と密に連携しています。 ここで、この分野での最も重要なお知らせを簡単にまとめておきます： 2012年6月 – AWS上で利用可能なSAP認定ソリューションの範囲を拡大しました 2012年10月 – AWS上でSAP HANAインメモリデータベースを本番稼働できるようになりました 2014年3月 – 最大244GBのメモリを搭載したcr1.8xlargeインスタンスでSAP HANAが本番稼働し、テスト用途のクラスタはさらに大きく作成できるようになりました 2014年6月 – r3.8xlargeインスタンスのSAP認定と合わせて、SAP HANA導入ガイドとAWS CloudFormationテンプレートを公開しました 2015年10月 – SAP HANA、Microsoft SQL Server、Apache SparkやPrestoを実行するために設計された2TBメモリを搭載したx1.32xlargeインスタンスを発表しました 2016年8月 – X1インスタンスのクラスタを使用して、最大7ノードつまり14TBメモリの本番稼働SAP HANAクラスタを作成することができるようになりました 2016年10月 – 1TBメモリを搭載したx1.16xlargeインスタンスを発表しました 2017年1月 – r4.16xlargeインスタンスでSAP HANA認定を取得しました 現在、幅広い業界のお客様がSAPアプリケーションをAWS上で本番稼働させています（SAPとAmazon Web Servicesのページには、多くのお客様成功例が掲載されています）。 私の同僚のBas Kamphuisが最近、SAPとクラウドによるデジタルジャーニーのナビゲートという記事を書きました（閲覧には登録が必要）。彼は、デジタルトランスフォーメーションにおけるSAPの役割について説明し、それをサポートするクラウドインフラストラクチャの主要な特性を検証しながら、他のホスティングオプションと比較してクラウドのほうが多くの利点を提供していると指摘しています。彼がこの記事でこれらの利点をどのように紹介しているかは以下のとおりです： SAPアプリケーションの本稼働環境としてAWSがより良い場所になるよう、引き続き取り組んでいます。私たちが取り組んでいることのいくつかを以下に示します： より大きなSAP HANAクラスタ – スケールアウトのSAP HANAクラスタを最大17ノード（34TBメモリ）まで構成できるようになりました 4TBのインスタンス – 今度、4TBメモリ搭載のx1e.32xlargeインスタンスを提供します 8から16TBのインスタンス – 16TBまでのメモリを搭載したインスタンスを計画しています 詳細をみてみましょう！ より大きなSAP HANAクラスタ SAP社と連携し、x1.32xlargeインスタンスを使用した最大17ノード（34TBメモリ）のスケールアウトクラスタでSAP認定を取得したことをお知らせします。これは、現在のクラウドプロバイダから提供される最大のスケールアウト構成であり、AWS上で非常に大きなSAPワークロードを展開することができます（詳細は、SAP HANA認定ハードウェアディレクトリのx1.32xlargeインスタンスを参照してください）。スケールアウトクラスタの構築および展開方法については、SAP HANA on AWSクイックスタートを参照してください。 メモリ重視のX1ファミリの拡張 お客様のご要望に対応し、確実な成長経路を提供するために、このインスタンスファミリおよび他のインスタンスファミリに引き続き投資します。 今年後半には、複数のAWSリージョンで、オンデマンドとリザーブドインスタンス両方の形式のx1e.32xlargeインスタンスを利用できるようにする予定です。このインスタンスは、（x1.32xlargeの2倍の）4TBのDDR4メモリ、128個のvCPU（4つの2.3 GHz […]

本日、AWS X-Ray で AWS Lambda サポート の一般提供開始を発表しました。Jeff が GA で投稿したブログですでにご存知の方もいるかと思いますが (「Jeff の GA POST (Jeff’s GA POST)」)、X-Ray は分散アプリケーションの実行やパフォーマンス動作を分析する AWS サービスです。 複数の独立したコンポーネントを異なるサービスで実行するマイクロサービスベースのアプリケーションでは、従来の問題をデバッグする方法がうまく機能しません。アプリケーションでレイテンシーを分けることで、X-Ray はエラーや処理の低下、タイムアウトを迅速に診断することができます。それでは、シンプルな Lambda ベースのアプリケーションを構築し分析する方法をお見せしながら、独自のアプリケーションで X-Ray を使用する方法をご説明します。 今すぐ開始したい場合は、関数の設定ページで追跡を有効にすれば既存の Lambda 関数で簡単に X-Ray を使い始めることができます。 または AWS Command Line Interface (CLI) で関数の tracing-config を更新してください (必ず –function-name も忘れずに): $ aws lambda update-function-configuration –tracing-config ‘{“Mode”: “Active”}’ トレースモードをオンにすると、Lambda は関数を追跡しようとします (アップストリームサービスによって追跡されないよう明示的に指示されていない限り)。オフの状態では、アップストリームサービスによって追跡するよう明示的に指示されている場合のみ関数が追跡されます。トレーシングモードをオンにすると追跡の生成が始まり、アプリケーションとその間のコネクション (辺) におけるリソースのビジュアル表現が見られるようになります。 […]

ストリーミングデータソリューションを構築する場合、ほとんどのお客様は、本番データと同様のデータを使用してストリーミングデータソリューションをテストしたいと考えています。この、データを作成してソリューションにストリーミングすることは、ソリューションをテストする際の最も退屈な作業かもしれません。 Amazon Kinesis StreamsとAmazon Kinesis Firehoseを使用すると、数十万のソースから1時間にテラバイト級のデータを連続的に捉えて保存できます。 Amazon Kinesis Analyticsでは、標準SQLを使用してリアルタイムでこのデータを分析および集計することができます。 AWS Management Console（またはAWS CLIまたはAmazon Kinesis APIを使用したいくつかのコマンド）で数回クリックするだけで、Amazon KinesisストリームまたはFirehose配信ストリームを簡単に作成できます。ただし、テストデータの連続したストリームを生成するには、AWS SDKまたはCLIを使用してAmazon Kinesisにテストレコードを送信することで、連続して実行されるカスタムプロセスまたはスクリプトを作成する必要があります。この作業はソリューションを適切にテストするために必要ですが、複雑さと開発時間とテスト時間が長くなることを意味します。 テストデータを生成してAmazon Kinesisに送信するユーザーフレンドリーなツールがあれば素晴らしいとは思いませんか？そこで、Amazon Kinesis Data Generator（KDG）の出番です。

今年のNVIDIAのGPU Technology Conferenceにて、AWSとNVIDIAはいくつかのイニシアチブにおいてパートナーとなりました。1つ目はとてもワクワクしている最新のVoltaベースのGPUインスタンスで、LSTMの学習が3倍高速になるように、AI開発者が接する世界を完全に別物にしてしまうと我々は考えています。2つ目は、AWSで動いているDeep Learning Institute (DLI)を通じて10万人以上の開発者をトレーニングする計画を発表しました。3つ目として、広い開発者コミュニティのために深層学習を大規模にスケール可能とするツールの共同開発です。 GTCでAWSは複数のセッションを行っており、Apach MXNetを使ってAmazon EC2のP2インスタンス上で学習をスケールさせたり、NVIDIAのJetson TX2 platformを使ってエッジ上でモデルを動かしたりしています。以下が今回の重要なパートナーシップと素晴らしいイノベーションの内容になります！ Volta – インスタンスとしてあなたの側にやってくる Tesla V100はVoltaアーキテクチャベースで640のTensor Coreを備え、混合精度の深層学習において120テラフロップスという素晴らしいパフォーマンスを提供します。AWSはV100をAmazon EC2インスタンス上でサポートできるということに非常にワクワクしています。このサポートが意味するところは、成長しつづける深層学習のコミュニティがスパコン級の能力を活かしてより深いモデルを学習し、AIの限界を押し広げることができるということです。また、NVIDIAとのコラボレーションによって、AWSのエンジニアと研究者はApache MXNetのNeural machine translation (NMT)アルゴリズムを先行して最適化することができました。これによって開発者はVoltaベースのプラットフォーム上で可能な最も速い手法で学習をすることができます。まとめると、Voltaベースのインスタンスが開発者にとってとても人気のあるものになると期待しています！ 深層学習を世界中の10万人以上の開発者に届ける NVIDIAとパートナーとなって、AWS上でDeep Learning Instituteのコースを提供できることを嬉しく思います。DLIは、自動運転車、ヘルスケア、ウェブサービス、ロボティクス、動画分析、そして金融サービス等のための深層学習の応用利用をカリキュラムに含める様に拡大しています。カリキュラムには、講師主導のセミナー、ワークショップ、そして講座が含まれ、アジア、ヨーロッパ、アメリカに渡る開発者にリーチしようとしています。AWSのグローバルインフラストラクチャは42のアベイラビリティゾーン(8つの追加が計画中)と16のリージョン(3つがさらに計画中)を持っているので、AWSは多様な開発者達にリーチするのに最適なインフラストラクチャプラットフォームであります。 深層学習の人達に簡単な利用とスケールを届ける 昔は、深いネットワークを学習するために必要なレベルのパフォーマンスを得るためには、国立の研究所にあるスーパーコンピュータにアクセスする必要がしばしばありました。また、それを使うにはmessage passing interface (MPI)といった分散コンピューティングライブラリを理解して、複数のライブラリやいくつか依存するパッケージをセットアップできることが要求されました。スケーラブルな深層学習を開発者にとって簡単に使えるようにするというゴールに集中するために、AWSはNVIDIAとパートナーとなって最適化された開発者ツールを作ることにしました。これらのツールは、cuDNN、NCCL、TensorRT、そしてCUDA toolkitといったNVIDIA Deep Learning SDKライブラリを使ってビルドされています。開発者がこれらのツールを使うことで、もっと簡単に大量のGPUを数千万インスタンス時間規模でほとんどオーバーヘッドなくスケールできるということを見てきています。 クラウドからエッジへ深層学習を持ち込むためにコラボレーション 低電力デバイス上でのエッジの深層学習は、今日の深層学習の最も大きいトレンドの1つになります。レイテンシを抑えらることや、ネットワーク可用性のためのデータ局所性等、エッジにあるデバイス上でモデルを実行したい理由はたくさんあります。今週のGTCのAWSセッションにおいて、我々はP2インスタンス上で最新のモデルをどのように学習できるかをお見せします。また、最先端の人工知能の能力を低電力デバイスに持ち込むために、Jetson TX2 platformを含む多様な低電力デバイス上にどれだけ簡単にそのモデルをデプロイできるかもお見せしました。そして、AWS IoTやAWS Greengrassといったサービスを通じてこれらのデバイスを管理することができるので、end-to-endのAIワークフローを提供することができます。 さらに学ぶには GTCのAWS深層学習セッションをご確認下さい AWS Marketplace上のAWS Deep learning AMIを使って、今すぐ始めましょう 原文: AWS and NVIDIA Expand Deep Learning Partnership […]

同僚のKiuk ChungがAWS Batchを使って深層学習をするという素晴らしい記事を書いてくれました。 GPUインスタンスは当然のように深層学習とペアになりますが、それはそのニューラルネットワークのアルゴリズムがGPUインスタンスの超並列処理能力を活かすことができるからです。AWSではg2やp2といったGPUインスタンスを提供しており、お客様はスケーラブルなGPUワークロードを実行することができます。AWS Batchを使うことでそのスケーラビリティをもっと効率よく使うことができます。(訳注: 丁度GTC 2017のKeynoteにて次期NVIDIA GPUであるV100に関する情報も発表されましたのでご参考頂ければ幸いです: AWS and NVIDIA Expand Deep Learning Partnership at GTC 2017) AWS Batchは皆さんの代わりに下回りの計算リソースを管理してくれるので、リソース管理のオーバーヘッド無しにモデリングすることに集中できます。AWS Batchにおける計算環境 (すなわちクラスタ)とは、皆さんのアカウント内のインスタンスのプールであり、AWS Batchはジョブの数に応じてインスタンスを起動したり削除したりしながらそれを動的にスケールしてくれます。これによって無駄なインスタンスを最小化でき、コストを最適化することができます。 さらに、AWS Batchは登録されたジョブが適切なインスタンスに配置されるように確実にスケジュールしてくれるので、ジョブのライフサイクルが管理されます。お客様独自のAMI利用の機能追加によって、AWS Batchの利用者はGPUが必要とされるジョブのためにもこの弾力性や利便性を活用することができるようになりました。 この記事ではGPUベースの深層学習ワークロードをAWS Batch上でどのように動かせばよいかをお見せします。Apache MXNetを使ってMNISTデータセットから手書きの数字を認識するための、畳み込みニューラルネットワーク(LeNetアーキテクチャ)の学習を例として使います。 MXNetのジョブをAWS Batchで実行する Apache MXNetは機能が豊富で、柔軟にプログラムが書け、高いスケーラビリティをもった深層学習フレームワークで、畳み込みニューラルネットワーク (CNNs)やlong short-term memory networks (LSTMs)を含む最新の深層モデルをサポートしています。 AWS Batchでジョブを実行するには3つのステップがあります: カスタムAMIを作成 AWS Batchのリソースを作成 学習ジョブを登録 カスタムAMIを作成 まず、NVIDIAドライバとAmazon ECSエージェントを含むAMIを作成するところから始めます。AWS Batchでは、計算環境を作成する時にimage_idを指定することで特定のAMIからインスタンスを起動させることができます。GPUが必要なジョブを実行しようとしているので、NVIDIAドライバが含まれたAMIが必要となります。 Launch Stackを選択して、あなたのアカウント上でus-east-1にCloudFromationテンプレートを起動します:  下にある様に、CloudFormationスタックのOutputsタブの中にあるAMIという値をメモしておきます。次のセクションで計算環境を作成する時にこれをimage_idの値として使います。 または、AWS BatchのドキュメンテーションのGPU有効なAMIを作成するに従っても良いです。 AWS Batchのリソースを作成 AMIを作成したら、以下のリソースを作成します: […]

ロギングとデバッグ情報は、さまざまな角度からアプローチできます。アプリケーションフレームワークを使用する場合でも、一からコーディングする場合でも、異なるプロジェクト間で使い慣れたコンポーネントやツールを使用することは常に快適です。今回の例では、PHPアプリケーションからのログを、Amazon CloudWatch Logsに出力させます。これを実現するために、すでに普及しよく利用されている標準に準拠した既存のソリューションを使いたいと思っていました。これらの理由からオープンソースのログライブラリであるPHP Monolog（https://github.com/Seldaek/monolog）を使用します。 PHP Monolog 新しいPHPアプリケーション、フレームワーク、またはサービスを扱う人にとって、ソリューション間で頻繁に現れる技術の選択肢の1つとしてアプリケーションログ用のMonologを利用することが挙げられます。PHP Monologは標準に準拠したPHPライブラリで、開発者はデータベース、ファイル、ソケット、さまざまなサービスなどのさまざまな種類のフォーマットにログを送信できます。PHP MonologはPSR-3で定義されたPHPロギングの標準化よりも前に、PSR-3のインターフェースと標準を実装していました。これにより、Monologはロギングライブラリ用の共通インタフェースに準拠しています。CloudWatch LogsでMonologを使用すると、PSR-3互換ロギングソリューションが作成されます。Monologは、Laravel、Symfony、CakePHPなど多くの異なるアプリケーションやフレームワークで使用できます。今日の例は、アプリケーションログの目的で、PHP Monologを使用してCloudWatchLogsに情報を送信し、CloudWatchのアラームと通知でアプリケーションデータを使用できる構造とプロセスを構築することです。これにより、アプリケーションからのログをキーにAmazon EC2 AutoScalingのようなサービスのアクションに使用することができます。 Amazon CloudWatch Logs 顧客第一主義の組織として、AWSはお客様やAWSパートナーが要望する重要な機能やサービスを絶えず構築し、リリースしています。本日、ハイライトされるサービスの1つがAmazon CloudWatch Logsです。CloudWatch Logsを使用すると、アプリケーション、オペレーティングシステムおよびインスタンス、AWSサービス、およびその他のさまざまなソースからのログファイルの情報を保存できます。以前のブログ記事では、CloudWatch Logsをさまざまなプログラミング例とともに紹介しました。 ブログ記事にはCloudWatch Logsを使用してアプリケーションからのエントリを保存するPHPの例があります。この例を使用してスタンドアロンソリューションとして拡張し、アプリケーション内からCloudWatch Logsにログを送ることができます。この例では、PHP Monologを活用してこの機能を強化します。 Monologの実装 Monologを使用開始するには、Composer(https://getcomposer.org/)を使用して必要なライブラリをインストールします。以下の手順では、AWS SDK for PHP、PHP Monologおよび CloudWatch Logsへのログを有効にするMonologのアドオンをインストールします。 curl -sS https://getcomposer.org/installer | php php composer.phar require aws/aws-sdk-php php composer.phar require monolog/monolog php composer.phar require maxbanton/cwh:^1.0 あるいは、次のエントリをcomposer.jsonファイルにコピーし、php composer.phar installコマンドでインストールすることもできます。 { “minimum-stability”: “stable”, “require”: { […]