Amazon Web Services ブログ

AWS ディープラーニング AMI を使用してディープラーニングを開始

ディープラーニングの初心者、また高度なディープラーニングプロジェクトをクラウドで構築したい方でも、AWS を使えば簡単に始められます。

AWS ディープラーニング AMIs は Ubuntu と Amazon Linux バージョンでの利用が可能になっており、いかなるスケールでもクラウドでディープラーニングアプリケーションを実行できるようにします。Amazon マシンイメージ (AMIs) には、Apache MXNet、TensorFlow、Microsoft Cognitive Toolkit (CNTK)、Caffe、Caffe2、Theano、Torch、Keras を含むオープンソースのディープラーニングフレームワークがプリインストールされています。

AMIs では、カスタムの AI モデルをトレーニングしたり、新しいアルゴリズムを試したり、新たなディープラーニングのスキルやテクニックを学ぶことができます。AMIs に追加料金はかかりません。アプリケーションを保存し実行するために必要な AWS のリソースに対してのみお支払いいただきます。

また、AMIs は事前設定されている CUDA や cuDNN ドライバー、Intel Math カーネルライブラリ (MKL) を介して GPU に加速度を提供しています。AMIs には人気の Python パッケージや Anaconda プラットフォームも含まれています。

そのシンプルさ、使いやすさ、コスト節約など、開発者へのメリットは明らかです。そしてコンピューティングインスタンスの起動も簡単です。次の手順に従うと、数分でディープラーニングを開始することができます。 

AMI の起動

AWS マネジメントコンソールにアクセスし、アカウントにサインインするか新しいアカウントを作成します。

(more…)

新機能 – インタラクティブな AWS コストエクスプローラー API

当社は、お客様による AWS のコストの追跡、割り当て、管理を可能にする AWS コストエクスプローラーの提供を、数年前に開始しました。この提供開始や、それ以降に追加された機能に対する反応は、非常に好評です。ただし、Jeff Bezos が語っているように、お客様は「心の底では必ず何かしらの不満を抱えています」。

私は毎日これを直接感じています。当社が新機能の提供を開始すると、それによりお客様は触発されてさらに多くを求めるようになります。たとえば、多くのお客様が揃って自社 IT インフラストラクチャの大部分を AWS クラウドに移行する中で、コストエクスプローラーにフィードする raw データに関して多くのリクエストが寄せられてきました。こうしたお客様は、AWS のコストをプログラムで調べ、アプリケーション別、部門コスト別に帳票や経理システムを更新し、支出を要約した概要ダッシュボードを構築したいと考えています。こうしたお客様の一部では、コストエクスプローラーで提供されるグラフやレポートからのデータの抽出で、問題が発生していたのです。

新しいコストエクスプローラー API
本日より、コストエクスプローラーにフィードする基盤データをプログラムで利用可能になります。新しいコストエクスプローラー API により、前述したすべてを実行できる一連の関数が提供されます。複数のディメンション (サービス、関連アカウント、タグ、アベイラビリティーゾーンなど) にわたりフィルタリングおよびグループ化されたコストと使用量を、日別または月別に集計して取得できます。これにより、簡単に使用を開始し (毎月の合計コスト)、必要な詳細レベル (本番稼働用とタグ付けされた DynamoDB テーブルへの書き込み) までリクエストを絞り込むことができ、応答は数秒で得られます。

そのオペレーションは次のとおりです。

GetCostAndUsage – フィルタリングとグループ化により、1 つのアカウントまたはすべてのアカウント (組織のマスターアカウントはすべてのメンバーアカウントにアクセスできる) のコストおよび使用量メトリクスを取得します。

GetDimensionValues – 指定された期間における指定されたフィルタに対して利用できるフィルタ値を取得します。

GetTags – 指定された期間に利用できるタグキーおよびタグ値を取得します。

GetReservationUtilization – 指定された期間における EC2 リザーブドインスタンスの使用率を、毎日または毎月の詳細度に加えてフィルタリングとグループ化を使って取得します。

これらの関数と、それによって返されるデータにより、お客様のビジネスについてより良い洞察が得られる、本当に興味深いことが可能になると私は考えています。たとえば、個別のマーケティングキャンペーンまたは開発プロジェクトをサポートするために使用するリソースにタグを付け、コストを詳細に調べて、ビジネス上の価値を測定することができます。サイバーマンデイブラックフライデイなど、重要な出来事に関するインフラストラクチャへの支出を、1 セント単位まで知ることが可能になります。

主要事項
この API の利用方法を検討する際は、以下のことを念頭に置いてください。

グループ化 – コストエクスプローラーウェブアプリケーションで提供されるグループ化は 1 レベルですが、API では 2 レベルが提供されます。たとえば、まずサービス別にコストまたは RI 使用率をグループ化してから、リージョン別にグループ化できます。

ページ分割 – 関数は大量のデータを返します。また、追加のデータが利用可能な場合は、 nextPageToken を含めて、ページ分割の AWS 全体のモデルに従います。トークンを指定して同じ関数をもう一度呼び出して、先に進みます。

リージョン – サービスエンドポイントは米国東部 (バージニア北部) リージョンにあり、すべてのパブリック AWS リージョンの使用量データを返します。

料金 – API コールごとに 0.01 USD がかかります。これをわかりやすくするため、この API を使用してダッシュボードを構築し、ユーザーからの 1 か月あたりのヒット数が 1000 であるとします。このダッシュボードの運用コストは 10 USD 程度です。これは独自のシステムをセットアップし、データを抽出、取り込み、インタラクティブクエリに対応するよりもはるかに少ないコストで済みます。

コストエクスプローラー API は今すぐ使い始めることができます。詳細については、コストエクスプローラーの API についてお読みください。

Jeff;

Amazon EMR で GPU インスタンスタイプを持つディープラーニングフレームワークを実行

AWS は Apache MXNetAmazon EMR での新世代 GPU インスタンスタイプのサポートについて発表いたします。これにより、機械学習ワークフローおよびビッグデータ処理とともに分散ディープニューラルネットワークの実行が可能になります。さらに、GPU ハードウェアにより、EMR クラスター上でカスタムディープラーニングライブラリをインストールおよび実行できます。ディープラーニングフレームワークの使用を通じて、自動運転車から人工知能 (AI)、個人化されたヘルスケア、コンピュータビジョンまで、さまざまなユースケースに対応する新しいツールキットを入手できます。

Amazon EMR は、Apache Spark、Apache Hive、PrestoApache HBase、Apache Flink などのフレームワークとともに、Amazon S3 で大量のデータを簡単かつ迅速に、コスト効率の高い方法で処理できるマネージド型 Hadoop フレームワークを提供します。ログの分析、ウェブインデックス作成、データ変換 (ETL)、財務分析、科学シミュレーション、リアルタイム処理、バイオインフォマティクスを含む、数多くのビッグデータのユースケースに低コストで対応し、確実かつ安全に処理できます。

EMR には、スケーラブルな機械学習ワークロードを実行可能にしてきた長い歴史があります。2013 年には、Apache Hadoop MapReduce を使用した分散型機械学習ワークロードの実行を支援するため、Apache Mahout のサポートが追加されました。2014 年には、お客様は Apache Spark を利用して (2015 年に公式サポートを追加)、Spark ML で利用できるさまざまなオープンソース機械学習ライブラリを使用して、スケーラブルな機械学習パイプラインを簡単に構築し始めました。

当社は過去 2 年間に、Jupyter ノートブックの簡単なインストールのための Apache Zeppelin ノートブックのサポート、およびデータサイエンティストが機械学習モデルを簡単かつ迅速に開発、トレーニングし、本番稼働に移行するための Apache Livy のサポートを追加しました。EMR の 1 秒あたりの請求と Amazon EC2 スポットインスタンスを使用した最大 80% のコスト削減により、機械学習パイプラインを大規模に、しかも低コストで簡単に実行できます。 (more…)

自律走行車の構築 パート 4: 自動運転の車で Apache MXNet と行動クローニングを使用

自律走行シリーズ 1 回目のブログでは、Donkey カーの構築と Amazon EC2 インスタンスでパイロットサーバーをデプロイしました。そして、2 回目のブログでは Donkey カーの運転を学び、Donkey カーが自律走行を学びました。3 回目のブログでは AWS IoT を使用して Donkey カーから AWS にテレメトリをストリーミングするプロセスをご紹介しました。

今回のブログでは、カーの運転を有効にするディープラーニングについて詳しく見ることにします。また、畳み込みニューラルネットワーク (CNN) を使用した行動クローニングの概念についても説明します。CNN は「前方には道がありますか、それともトラフィックコーンがありますか?」といったような、カーに対する質問に答えるなど、コンピュータビジョンタスクにおける最先端のモデリング技術として現れたものです。


1) AWS 自律走行車を構築し re:Invent の Robocar Rally でレースに参加
2) 自律走行車の構築 パート 2: 自律走行車の運転
3) 自律走行車の構築 パート 3: 自律走行車の接続
4) 自律走行車の構築 パート 4: 自動運転の車で Apache MXNet と行動クローニングを使用


P2 で Donkey のトレーニングデータをセットアップ

トレーニングの実行方法の詳細については、すでにシリーズ 2 回目のブログで説明しました。主なステップとコマンドを簡単に復習しておきましょう。

  1. Pi からデータを Amazon EC2 インスタンスにコピーするには
    $ rsync -rva --progress -e "ssh -i /path/to/key/DonkeyKP-us-east-1.pem" /home/pi/d2// ec2-user@ec2-your-ip.compute-1.amazonaws.com:~/d2/data/
  2. トレーニングプロセスを開始するには
    $ python ~/d2/manage.py train --model /path/to/myfirstpilot
  3. トレーニング済みのモデルを再び Pi へコピーするには
    $: rsync -rva --progress -e "ssh -i /path/to/key/DonkeyKP-us-east-1.pem" ec2-user@ec2-your-ip.compute-1.amazonaws.com:~/d2/models/ /home/pi/d2/models/

モデルの舞台裏

このセクションでは、モデルが学ぶ内容と独自で運転できる方法について説明します。現在の Donkey の構築には Keras がデフォルトのディープラーニングフレームワークとして使用されています。AWS は Apache MXNet や Gluon、PyTorch など他のフレームワークのサポートを追加する作業に取り組んでいます。このブログでは Apache MXNet を使用して、自動運転を有効にするモデルがどのように動作するのか詳しく見ることにします。以前にも触れましたが、AWS では行動クローニングという技術を使用してカーの自動運転を有効にします。基本的に、このモデルはトラックを運転した時に収集したトレーニングデータをもとに、運転することを学びました。データの大半が「クリーン」であることが大切です。つまり、この目的は意図した道を進むことなので、カーがトラックにいない状態または方向を間違えた場合などのイメージがトレーニングデータに多く含まれていないことが大切です。人がハンドルを握って道からそれないように運転する時と同じで、現状で与えられた状態で方向を定めるモデルを構築します。そうすることで問題を「入力イメージに従って運転するためのステアリング角度は?」といったようにモデリングすることができます。実際の運転状況にはアクセラレーションやトランスミッションギアといったコンポーネントが追加されるので、より複雑になります。まずはシンプルにしておくため、スロットルを一定の割合に設定してカーが運転できるようにすることから始めます。実際にやってみると、トレーニングデータ 25~30% のスロットルが Donkey カーには最適な速度であることが証明されました。

これを行うには畳み込みニューラルネットワーク (CNN) というディープラーニング技術を使用します。CNN はコンピュータビジョン問題において事実上のネットワークとして現れたものです。CNN は各ノードが受容フィールドと呼ばれる小さな枠と関連付けられた畳み込みレイヤーから成り立っています。これによりイメージ内にあるローカルの特徴を抽出することができます。「イメージにあるのは道ですか、それとも人ですか?」といった質問は、先に計算されたこうしたローカルの特徴を使用して、計算することができます。CNN がどのように機能するか説明した詳細情報はこちらをご覧ください。

データセット

このブログでは、トラックを 15 分ほど運転して収集したデータセットを使用します。先に説明したように、カーがトラックにいなかった場合のイメージを破棄してクリーンな状態にしました。Donkey ソフトウェアは「不適切」なイメージを削除するため、ブラウザベースの UI をすでに提供しています。 donkey tubclean <folder containing tubs>) です。これに似たトラックを運転しているカーのイメージのデータセットはこちらで入手できます。

(more…)

Amazon Rekognition がリアルタイム顔認識、イメージ内のテキスト認識のサポート、および機能強化された顔検出を発表

Amazon Rekognition に、3 つの新しい機能として、イメージ内のテキストの検出と認識、数千万の顔からのリアルタイム顔認識、および密集写真からの最大 100 個の顔検出が追加されました。顔の検証と識別に Amazon Rekognition をすでにご利用の場合は、ほとんどのケースで精度が最大 10% 向上します。

イメージ内のテキスト

Amazon Rekognition でイメージ内のオブジェクトや顔を検出しているお客様方から、イメージに埋め込まれたテキストを認識できないかとのご要望があります。たとえば、交通監視カメラで捉えた道路標識や車のナンバープレート、TV 画面のニュースや字幕、携帯に取り込まれた家族写真の図案化された文字などです。本日より、Rekognition の「イメージ内のテキスト」を使用して、イメージからテキストコンテンツを認識して抽出できるようになりました。「イメージ内のテキスト」は、ドキュメントのイメージよりも実際のイメージで特に効果を発揮するように構築されています。多種多様なレイアウト、フォント、スタイルで埋め込まれたほとんどのラテン文字や数字のテキストがサポートされます。また、バナーやポスターなどの背景のオブジェクトに様々な向きで重ねられたテキストもサポートされます。

「ビジュアル駆動型のプラットフォームである Pinterest では、イメージの速度と画質が極めて重要ですが、これらのイメージに付随するテキストも同じように重要です。テキストは、当社の 2 億を超えるアクティブユーザーに実際に Pin するための背景情報を提供します。Amazon Rekognition の『イメージ内のテキスト』を使うことで、大量のイメージに取り込まれたリッチテキストが抽出しやすくなり、Amazon S3 に保存された何百万という Pin のレイテンシーを低く抑えることができます。これからも AWS とのパートナーシップを深め、Pinner に高品質で高速なサービスを提供し、Pinterest のビジネスを成長させていくつもりです。」– Vanja Josifovski、CTO、Pinterest

「プロの写真家が SmugMug を使用して共有したり販売したりする写真に、マラソン大会のゼッケン番号などの数字が含まれていることがあります。Amazon Rekognition の『イメージ内のテキスト』を使用すると、大量のゼッケン番号をプログラムで抽出できるため、これらの大会で写真家が撮った写真をすばやく簡単に共有したり収益化したりできるようになります。」 – Don MacAskill、Co-founder、CEO & Chief Geek at SmugMug

リアルタイムの顔認識

何千万という顔のコレクションに対してリアルタイムの顔検索ができるようになりました。これにより、検索のレイテンシーが以前よりも 5〜10 分の 1 に短縮されると共に、コレクションに保存できる顔の数が 10〜20 倍に増えます。セキュリティと公共安全のアプリケーションでは、今回の更新により、何百万という顔のコレクションから目当ての人物をリアルタイムで識別できます。これは、迅速なレスポンスが要求されるユースケースに役立ちます。

ワシントン郡保安官オフィスは、オレゴン市民からの 911 番緊急通報に対するファーストレスポンダーです。このオフィスでは、全国の市警に対して犯罪防止のサポートも提供しています。昨年から Amazon Rekognition を使い始め、通報された容疑者の識別所要時間を 2〜3 日から数分に短縮し、新しいシステムを使用して最初の容疑者を 1 週間以内に逮捕しました。

「この改善により、現場の警察官はほぼリアルタイムで検索の結果を得られます。必要な情報を取得してすばやく対応できます。現場では、数秒の差が人命救助の分かれ目になることがあります。」– Chris Adzima、上級インフォメーションシステムアナリスト、ワシントン郡保安官オフィス

人混みモードの顔検出

本日より、1 つのイメージに含まれている多数の顔から最大 100 (以前は 15) までを検出、分析、インデックスできるようになりました。この機能強化により、グループ写真、混雑したイベントや公共の場所 (空港やデパートなど) の写真で、すべての顔の人口統計データを正確にキャプチャしてセンチメントを分析できます。

「過去にユーザーが購入した写真や、ユーザーから当社のプラットフォームにアップロードされた写真の膨大なコレクションがあります。これらのコレクションから特定のユーザーの子供の写真を探す場合があり、そのために Amazon Rekognition を利用しています。多くのグループ写真には何十という小さな顔が収められていて、これまでは 1 つ 1 つの顔を正確に検出するために元のイメージをトリミングして分割していました。新しい人混みの顔検出機能を使用すると、特に複雑な前処理をすることなく、一度ですべての顔を簡単に検出できます。」– Shinji Miyazato、Engineering Department SRE Lead、Sen Corporation

顔検出モデルの精度向上

顔検出アルゴリズムの精度も改善しました。これにより、チェックインカウンターや従業員用の回転式通用口、モバイルの顔ベースの認証で使用される顔検証/識別アプリケーションの精度が最大 10% 向上します。

特に注目に値する点として、さまざまな業界で大規模なイメージ分析ワークロードを本稼働環境で運用するお客様が増えています。代表的なお客様の例をいくつかご紹介します。

Butterfleye – この家庭および小規模企業向けのセキュリティカメラプロバイダーは、Amazon Rekognition を使用して顔/物検出カメラを低コストで迅速に開発し、開発所要時間を 18 か月から 4 か月に短縮して研究開発費を 100 万ドル以上削減しました。

Open Influence – この会社の業務は、エンタープライズ顧客がブランドを販売促進するためのソーシャルメディアインフルエンサーを見つけることです。Amazon Rekognition を自社独自のデータパイプラインと簡単に連携させることで高品質の検索結果を生成し、他の手段では見つけることができなかったインフルエンサーを顧客が発掘できるようにしています。

Marinus Analytics – 人身売買の防止に Amazon Rekognition を役立てています。この会社の主力ソフトウェアは、米国の法執行機関で性目的の人身売買の捜査に採用されています。Amazon Rekognition と Marinus Analytics を連携させた捜査により、何百万という記録から数秒で被害者を見つけ出し、迅速で効果的な対応ができます。

Amazon Rekognition の詳細については、こちらを参照してください。Amazon Rekognition をすぐに使用するには、こちらの開始方法を参照してください。ご質問があればコメント内に記入してください。


Ranju は、Amazon での勤務歴がほぼ 5 年で、Amazon Rekognition チームを率いています。Amazon Rekognition は、ディープラーニングベースのイメージ認識サービスであり、何百万というイメージを検索、検証、整理できます。Ranju は Amazon の前に Barnes & Noble で Nook Cloud エンジニアリングのチームリーダーでした。このチームは、Nook モバイルサービスおよびデジタルアセット管理サービスの戦略、設計、開発、および SaaS 運用を担当していました。

AWS IoT の更新 – 新しい料金モデルでより優れた価値を提供

AWS ユーザーは AWS IoT を使用して接続済みデバイスをよりインテリジェントにしています。こうしたデバイスは、環境下 (地下、水中、現場、病室など) でデータを収集したり測定し、AWS IoTAWS クラウドへのゲートウェイとして使用します。クラウドに接続すると、ユーザーはデバイスのデータを Amazon Simple Storage Service (S3)Amazon DynamoDB に書き込むことができ、Amazon KinesisAWS Lambda 関数を使用してデータを処理し、Amazon Simple Notification Service (SNS) のプッシュ通知を開始したり、その他多くの操作を実行することができます。

新しい料金モデル (20-40% 削減)
より優れた価値を提供できるように AWS IoT の料金モデルを変更することにしました。この変更により、大半のユーザーにとって約 20~40% のコスト削減になるでしょう。また、ワークロードによっては大幅な割引の対象になるユーザーもいると思います。

オリジナルモデルでは、サービスに送信またはサービスから送信されたメッセージ数をもとに請求額が定められていました。この包括的なモデルは起点としては優れていましたが、実際に使用していない AWS IoT の一部においても支払う必要があったユーザーもいたことを意味しています。たとえば、不定期に呼び出すまばらなルールセットを使用して頻繁に AWS IoT から反応を求めるデバイスを使用しているユーザーもいます。AWS の新しいモデルは、それに比べてより細かく各コンポーネントでそれぞれの料金が適用されます (米国東部 (バージニア北部) リージョン)。

接続 – 使用しているデバイスが AWS IoT に接続している合計時間をベースに 1 分間単位で計測されます。100 万分間の接続あたり、料金は 0.08 USD です (24 時間 365 日対応の接続、デバイス 1 台につき 0.042 USD に相当)。デバイスは 30 秒から 20 分の間隔で追加費用なしにキープアライブの ping を送ることができます。

メッセージング – デバイスと AWS IoT の間で送信されたメッセージ数で計測されます。料金は 100 万件のメッセージにつき 1 USD から提供しています。ボリューム料金は 100 万件につき 0.70 USD まで引き下げました。最大 128 キロバイトまでメッセージを送信したり受信することが可能です。メッセージは 5 キロバイト単位で計測されます (以前は最大 512 バイト)。たとえば、8 キロバイトのメッセージはメッセージ 2 件として計測されます。

ルールエンジン – ルールがトリガーされる場合とルール内で実行する操作の数で計測されます。1 回の操作につき 1 つの操作が最低限となります。料金はトリガーされたルール 100 万件につき 0.15 USD、実行した操作 100 万件につき 0.15 USD です。5 キロバイト以上のメッセージを処理するルールは 5 キロバイトサイズの倍数で計測されます。たとえば、8 キロバイトのメッセージを処理するルールは、ルール 2 件として計測されます。

デバイスシャドウとレジストリ更新 – デバイスシャドウまたはレジストリデータにアクセスするための操作数で計測され、料金はオペレーション 100 万件あたり 1.25 USD になります。デバイスシャドウとレジストリ操作はデバイスシャドウまたはレジストリのレコードサイズ 1 キロバイト単位で計測されます。たとえば、1.5 キロバイトのシャドウレコードに更新した場合はオペレーション 2 件として計測されます。

AWS 無料利用枠で、接続分数、メッセージ、トリガーしたルール、ルールアクション、シャドウ、レジストリの使用量に、最大 50 台のデバイスのフリート操作に十分な割り当て枠を提供するようになりました。新しい料金は 2018 年 1 月 1 日から適用されます。お客様は何もする必要はありません。その時点で、更新された料金は AWS IoT Pricing ページに反映されます。

re:Invent の AWS IoT
今年の AWS re:Invent では IoT 専用のトラックを用意しています。サンプルは次をご覧ください。

PhilipsPanasonicEnelSalesforce など顧客によるセッションもご利用可能になっています。

Jeff;

Amazon EC2 Systems Manager による Microsoft VSS を使用したスナップショットサポート

私たちはここでWindows AMIを稼働させるAmazon EC2におけるMicrosoftボリュームシャドウコピー(VSS)のサポートをアナウンスできることを嬉しく思います。VSSはMicrosoft Windows(主要なSQL ServerやExchange Serverなどのマイクロソフトアプリケーションを含む互換性のある)環境における非常に一般的なボリュームバックアップ技術です。VSSはファイルの書き込みなどのディスク処理をバックアップ処理実行中も適切に管理するため、アプリケーション一貫性を持ったバックアップが可能となります。 アプリケーション一貫性バックアップは、マシンまたはインスタンスに接続されたボリュームのバックアップと同時に実行され、メモリ内のすべてのデータと処理中のすべてのトランザクションをキャプチャします。

VSSが有効なAmazon EBSボリュームのスナップショット(以降、”VSS有効化スナップショット”と表記) は、Amazon EC2 Systems ManagerのRun Commandから使用可能です。AWSEC2-CreateVssSnapshot コマンドによってWindowsインスタンスのEC2にアタッチされたEBSボリュームを、バックアップ処理の間トランザクションデータの一貫性を失うことなく、アプリケーション一貫性を持ったスナップショットを取得可能です。この機能によってSQL Backupや、カスタムスクリプトなどによって提供されたアプリケーション固有のバックアップソリューションは不要となります。さらに、イメージレベルバックアップにおけるアプリケーション一貫性を維持するためのサードパーティ製ツールも不要になります。

AWSEC2-CreateVssSnapshotの使用方法

VSS有効化スナップショットは、Windowsが稼働するEC2インスタンスに対してAWSEC2-CreateVssSnapshotコマンドをEC2 Systems Manager Run Commandから呼び出すことで実行します。AWS管理コンソールやAWS CLIから実行したり、PowerShellスクリプトやLambda関数から呼び出すことも可能です。本ブログではEC2コンソールからコマンドで実行する例を示します。

AWSEC2-CreateVssSnapshot Run Command

EC2管理コンソールで、AWSEC2-CreateVssSnapshotコマンドのドキュメントを選択し、VSS有効化スナップショットを取得したいEBSボリュームを持つインスタンスを選択します。 インスタンスを選択した後、スナップショットに追加したい説明やタグを設定します。ブートボリュームをスナップショット処理から除外することも可能です。

Calling AWSEC2-CreataeVssSnapshot Run Command

起動されるとRun CommandはVSSコンポーネント(詳細については後述)に対して、EC2 Windowsインスタンス上のVSS対応アプリケーションのすべての処理中のI/Oをコーディネーションするよう指示します。これによってI/OバッファはEBSボリュームに対してフラッシュされ、すべてのI/Oはスナップショット取得が完了するまでフリーズされます。この結果アプリケーション一貫性が維持されます。スナップショットが取得された後、I/Oフリーズが解除され通常処理に復帰します。

Run Commandやスクリプトから取得したスナップショットは、EC2コンソール左側のEBSスナップショットメニューで確認できます。 このプロセスで正常に取得された全てのVSS有効化スナップショットには “AppConsistent:True”というタグが付与されます。本機能についてのより詳細についてはこちらAWSEC2-CreateVssSnapshot のドキュメントを参照してください。

VSS有効化スナップショットを取得するためのEC2インスタンスの準備

  • インスタンスへのスナップショット許可 : IAMコンソールを開き、”Amazon EC2″サービスに対する以下の権限を許可する新しいポリシーを作成します。
    1. DescribeInstances
    2. CreateTags
    3. CreateSnapshot

またIAMコンソールからAmazon EC2ロールAmazonEC2RoleForSSMに対して上記で作成したポリシーを適用します。さらにこのロールを直接EC2 Windowsインスタンスにアタッチします。

IAM permissions to take VSS-enabled EBS snapshots

  • VSSコンポーネントのインストール : 2017年11月以降のMicrosoft Windows Server AMIイメージにはVSSコンポーネントはプリインストールされています。もし使用しているWindowsインスタンスのパッケージが最新でない場合は、VSSコンポーネント(AwsVssComponents)をAWS-ConfigureAWSPakageコマンドをSystems ManagerのRun Commandから呼び出してインストールする必要があります。

AWS-ConfigureAwsPackage to install VSS components

より詳しいVSS有効化スナップショット取得のためのEC2インスタンスのセットアップについてはこちらAmazon EC2 ドキュメントを参照ください。

Installing VSS components on EC2 instances

AWSEC2-CreateVssSnapshot使用する際には、対象のEC2インスタンスに対してEBSスナップショット作成およびタグ書き込み許可のIAM許可が必要となります。コンプライアンスやポリシーの理由から追加のIAM許諾をインスタンスに付与したくない場合には、カスタム可能なサンプルのスクリプトを活用可能です。このスクリプトの詳細についてはこちらAWSEC2-ManageVssIOに関するドキュメントを参照して下さい。

VSS有効化スナップショットのリストアプロセスは通常のEBSスナップショットと同様です。こちらのリストアのサンプルスクリプトも使用できます。このリストア用スクリプトで、指定されたEBSスナップショットからEC2 Windowsインスタンスにリストアすることが可能です。

About the Author

Purvi Goyal is a Senior Product Manager with the Amazon EC2 team, where she strives to enhance the cloud experience of AWS Enterprise customers. Outside of work, she enjoys outdoor activities like hiking and kayaking.

 

(翻訳:SA松崎, 元の記事はこちらです)

AWS CodeCommitのプルリクエストを使用してコードレビューをリクエストし、コードについて議論する

シニアクラウドアーキテクトのMichael Edge氏のCodeCommitのプルリクエストに関する素晴らしいブログに感謝します。

~~~~~~~~~~~~~
AWS CodeCommitは、プライベートGitリポジトリを安全にホスティングするフルマネージドなサービスです。CodeCommitは今ではプルリクエストをサポートするようになりました。これによってリポジトリのユーザは、コードの変更に対するレビュー、コメント、対話的なイテレーションが可能になります。チームメンバー間のコラボレーションツールとして使用されるプルリクエストは、CodeCommitリポジトリに対する変更の可能性を、リポジトリにそれらの変更をマージする前に確認するのに役立ちます。各プルリクエストは、次のように単純なライフサイクルを通じて実行されます:

  • マージされる新機能は、featureブランチに1つ以上のコミットとして追加されます。コミットは、宛先のブランチにマージされません。
  • プルリクエストが通常は2つのブランチの差異から作成されます。
  • チームメンバーはプルリクエストをレビューし、コメントします。プルリクエストは、追加のコミットで更新される可能性があります。これにはコメントに対応して行われる変更や宛先ブランチとの差分から発生する変更が含まれます。
  • チームメンバーがプルリクエストに満足すれば、それは宛先ブランチにマージされます。 コミットは、プルリクエストに追加されるのと同じ順序で宛先ブランチに適用されます。

(more…)

AWS Shield Advancedを使用してAmazon EC2インスタンスとNetwork Load Balancerを保護できるようになりました

11月22日から、AWS Shield Advancedは、インフラストラクチャレイヤの分散サービス拒否(DDoS)攻撃からAmazon EC2インスタンスとNetwork Load Balancerを保護できるようになりました。 AWS Elastic IPアドレスに対してAWS Shield Advancedを有効にし、インターネットに接続されたEC2インスタンスまたはNetwork Load Balancerにアタッチすることで利用可能です。 AWS Shield Advancedは、Elastic IPアドレスの背後にあるAWSリソースの種類を自動的に検出し、DDoS攻撃を緩和します。

AWS Shield Advancedは、Amazon VPCネットワークアクセスコントロールリスト(ACLs)をAWSネットワークのエッジにあるAWS Shield上で自動的に実行し、追加の帯域幅とスクラビング容量を利用することで、大量のDDoS攻撃を軽減します。また、AWS DDoS対応チームと協力し、事前に軽減策を設定したり、発生したインシデントに対応したりすることで、AWS Shieldの追加の軽減策をカスタマイズできます。AWS Shield Advancedによって検出されたすべてのインシデントについては、Amazon CloudWatchのメトリックを通じて、ほぼリアルタイムに可視化されます。インシデントの詳細についても、攻撃の地理的な起点や送信元IPアドレスなどが確認いただけます。

Elastic IPアドレスに対応したAWS Shield Advancedは、DDoSコスト保護の適用範囲を拡大します。DDoSコスト保護により、DDoS攻撃の結果として利用リソースが増加した場合に、Elastic Load BalancingAmazon CloudFrontAmazon Route 53、およびEC2インスタンス時間についてサービスクレジットを要求できるようになりました。

EC2インスタンスとNetwork Load Balancer保護の開始

開始方法:

  1. AWS Management Consoleにサインインし、AWS WAFおよびAWS Shieldコンソールに移動します。
  2. 「AWS Shield Advancedを有効にする」を選択、条件をご確認いただき、AWS Shield Advancedを有効化します。
  3. ナビゲーションペインで「Protected resources」に移動します。
  4. 保護するElastic IPアドレスを選択します(これらはEC2インスタンスまたはネットワークロードバランサを指し示します)。

AWS Shield AdvancedがDDoS攻撃を検出した場合、CloudWatchを確認するか、AWS WAFおよびAWS Shieldコンソールの「Incidents」タブを調べることで攻撃の詳細を取得できます。 この新機能とAWS Shield Advancedの詳細については、AWS Shieldのホームページを参照してください。

この投稿に関するご意見やご質問は、(原文)記事の「コメント」セクションにお寄せいただく、またはAWS Shieldフォーラムで新しいスレッドを開始いただくか、AWSサポートにお問い合わせください

– Ritwik

原文:Now You Can Use AWS Shield Advanced to Help Protect Your Amazon EC2 Instances and Network Load Balancers(翻訳:SA安司)

 

Amazon Elasticsearch Service へのアクセスコントロールの設定

Dr. Jon Handler (@_searchgeek) は、検索技術を専門とする AWS ソリューションアーキテクトです。

Amazon Elasticsearch Service (Amazon ES) ドメインを保護することで、権限のないユーザーがデータにアクセスしたり変更したりすることを防ぐことができます。ほとんどのお客様は、IP アドレスベースまたは ID ベースのアクセスポリシーのセキュリティを望んでいますが、利便性からオープンアクセスを選択しています。オープンアクセスのドメインは、インターネット上の任意の当事者から Amazon ES ドメインへのデータの作成、表示、変更、および削除の要求を受け入れるため、このオプションはほとんどのお客様にとって適切なものではありません。

以前のブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」では、アクセスコントロールについて詳細に説明しました。このブログ記事では、ドメインの IAM ポリシーを開始する簡単な方法をいくつか紹介します。AWS Identity and Access Management (IAM) ポリシーを設定するにはいくつかの作業が必要ですが、この「予防的対策」により後で大量の作業が発生するのを防ぐことができます。

Amazon Elasticsearch Service における主要なアクセスコントロールの概念

Amazon ES が作成するドメインには、Elasticsearch クラスタ内のノードと複数の AWS サービスのリソースが含まれます。Amazon ESがドメインを作成すると、ドメインはサービス制御された VPC でインスタンスを起動します。これらのインスタンスの前面には Elastic Load Balancing (ELB) があり、ロードバランサーのエンドポイントはRoute 53 を通じて発行されます。ドメインへのリクエストは、ドメインの EC2 インスタンスにルーティングする ELB ロードバランサをパススルーします。リクエストがどこに行くかに関わらず、インスタンスは IAM にコンタクトしてリクエストが承認されているかどうかを判断します。承認されていないリクエストはブロックされ、破棄されます。

IAM ポリシーがどのように適用され、解決されるかを理解するための鍵は、次の点にあります。

  • ポリシーの場所: IAM ポリシーは、ドメインまたは個々のユーザーまたはロールに付加できます。ポリシーがドメインに付加されている場合は、リソースベースのポリシーと呼ばれます。ユーザーまたはロールに関連付けられている場合は、ユーザーベースのポリシーと呼ばれます。
  • ポリシーの解決: IAM は、リクエストが承認されているかどうかを判断するために、リクエストに適用されるすべてのユーザーベースおよびリソースベースのポリシーを収集します。詳細については、ブログ記事「Amazon Elasticsearch Service ドメインのアクセスコントロールを設定する方法」を参照してください。

リソースベースのポリシー、ユーザーベースのポリシー、またはそれらの組み合わせを作成するかどうかにかかわらず、IAM は特定のリクエストに対してすべてのポリシーを尊重します。

Amazon ES コンソールのウィザードを使用してドメインを作成すると、Amazon Elasticsearch Service はさまざまな種類のアクセスに対していくつかのテンプレート IAM ポリシーを提供します。

  • [1 つ以上の  AWS アカウントまたは IAM ユーザーにアクセスを許可、または拒否する] を選択した場合: ドメインにアクセスする必要がある IAM ユーザーまたはロールを指定します。ドメインへのすべてのリクエストは、AWS 署名バージョン 4 署名で署名する必要があります。リクエストがドメインに到達すると、署名検証とアクセスコントロールのためにリクエストが IAM に転送されます。
  • [Allow access to the domain from specific IP(s) (特定の IP からのアドメインへのアクセスを許可する)] を選択した場合: IP または CIDR ブロックを指定します。その IP アドレス範囲からの匿名 (署名なし) リクエストは許可されます。
  • [Deny access to the domain (ドメインへのアクセスを拒否する)] を選択した場合: 署名付きまたは署名なしにかかわらず、リクエストは許可されません。
  • [Deny access to the domain (ドメインへのアクセスを拒否する)] を選択した場合: 署名付きまたは署名なしにかかわらず、リクエストは許可されません。このテンプレートを選択すると、Amazon ES からポップアップ警告が表示されます。

シンプルな IP アドレスベースのセットアップ
Amazon Elasticsearch Service を使い始めたばかりのときは、データをすばやく読み込んだり、いくつかのクエリを実行したり (コマンドラインから、または Kibana を使用して)、コマンドラインからより詳細な検査と監視を行いたいものです。オープンアクセスポリシーは、ネイティブの Elasticsearch クライアント、curl、ウェブブラウザなどのツールがクラスタとやりとりすることを可能にするため、最も早く始める方法となります。

その性質上、オープンアクセスは安全ではありません。オープンアクセスポリシーはお勧めできません。IP アドレスベースのアクセスコントロールを使用すると、ドメインを保護することができます。不正な訪問者やポートスキャナは、次のようなメッセージで拒否されます。

{“Message”: “User: anonymous is not authorized to perform: es:ESHttpGet on resource:<domain ARN>”}

開発を EC2 インスタンスから行う場合は、VPC を設定してパブリック IP アドレスまたは Elastic IP アドレス (EIP) を割り当てることができます。

この簡単なセットアップで、[Allow access to the domain from specific IPs] オプションを選択すると、次のようなポリシーを生成できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "111.222.333.444/0"
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }

 

IPアドレス、アカウント ID、ドメイン名(赤で表示) を必ず自分の値に置き換えてください。

この設定は、開発およびテストのために必要な基本アクティビティをサポートします。curl のようなツールを使ってコマンドをクラスタに直接送ることができます。その EC2 インスタンスで Kibana を実行できます。IP アドレスベースのアクセスポリシーはフルアクセスを許可します。署名されていても匿名であっても、異なる IP アドレスからのドメインへのその他のすべてのリクエストは、IAM によって拒否されます。

Kinesis Firehose、Amazon CloudWatch ログ、または AWS IoT で使用するためのセットアップ
Amazon Elasticsearch Service を開始するには、別の AWS サービスからデータを送信するのが簡単です。Kinesis Firehose ストリームを作成するか、CloudWatch ログデータを Amazon ES にストリーミングするには、これらのサービスがドメインに書き込むことを許可するロールを作成する必要があります。IAM のポリシー解決により、他のサービスからのアクセスが許可され、ドメインにデータを書き込むことができるようになります。IP アドレスベースのポリシーによって、コマンドと Kibana のための EC2 インスタンスへのアクセスが許可されます。他のすべてのリクエストへのアクセスは拒否されます。

AWS IoT の安全なアクセスを設定する方法については、IP アドレスベースのポリシーを使用する方法について説明しているブログ記事「Analyze Device-Generated Data with AWS IoT and Amazon Elasticsearch Service (AWS IoT および Amazon Elasticsearch Service によるデバイス生成データの分析)」を参照してください。

IP アドレスがわからない場合のセットアップ
多くの場合、リクエスト元の静的 IP アドレスはわかりません。データセンター内のノードのセット、モバイルアプリケーションのサポート、または自動スケーリングされた一連のウェブサーバーまたは Logstash インスタンスからのリクエストの送信で、Kibana を実行することができます。

このような場合、VPC の既知の IPアドレスでリバースプロキシを使用して、Kibana から Amazon Elasticsearch Service サービスドメインにリクエストを転送し、ユーザーベースの認証で署名バージョン 4 の署名を使用してアプリケーションサーバーからリクエストを送信できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:role/webserver "
      },
      "Action": ["es:ESHttpGet"],
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    },
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": [
            "111.222.333.444/0",   <-- プロキシの IP アドレス
            "112.223.334.445/0"    <-- インスタンスの IP アドレス
          ]
        }
      },
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }

  ]
}

 

プロキシサーバーの IP アドレスを IP アドレスベースのポリシーに置き換えて、プロキシからのロクエストを許可します。ポリシーに別の IP アドレスを追加して、コマンドラインと Kibana のためのアクセスを開くこともできます。

前述のポリシー例では、ウェブサーバーのロールに許可されているアクションを HTTP GET 呼び出しに制限しています。作成する IAM ポリシーでは、さまざまなコマンドと HTTP メソッドを許可しているため、さまざまなアクターのアクセスコントロールを設定できます。詳細については、ブログ記事「Amazon Elasticsearch Service ドメインのアクセスをコントロールする方法」を参照してください。

プロキシを使用してリクエストの署名を簡素化する
プロキシを作成すると、プロキシの IP アドレスをアイデンティティのソースとして使用して、ドメインへのアクセスをコントロールできます。プロキシから許可されたリクエストのみを発信することによって、アクセスをコントロールします。署名バージョン 4 のリクエスト署名を使用して、リクエストの背後にあるアイデンティティ情報を提供することもできます。Amazon ES は IAM を使用してこれらのリクエストを認証し、許可または拒否します。

リクエストの署名を実装するには、コードを記述する必要があります。これは、コマンドラインまたは Kibana のアクセスのための開発の追加ハードルになります。リクエストを受け取り、署名バージョン 4で署名し、AWS に転送する小さなアプリケーションを提供するオープンソースプロジェクトがあります。

そのような署名プロキシがここにあります: https://github.com/abutaha/aws-es-proxy。この小さなアプリケーションはポート 9200 でリッスンし、署名されたリクエストを Amazon Elasticsearch Service に転送します。

注意: この署名プロキシは、AWS ではなくサードパーティによって開発されたものです。これは開発やテストには適していますが、本番稼働用ワークロードには適していません。AWS は外部コンテンツの機能または適合性について責任を負いません。この署名プロキシを使用すると、1 つ以上の AWS アカウントまたは IAM ユーザーにアクセスを許可、または拒否する テンプレートを使用して、ドメインのポリシーを次のように設定できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:user/susan"
      },
      "Action": "es:*",
      "Resource": "arn:aws:es:us-west-2:123456789012:domain/mydomain/*"
    }
  ]
}

 

ユーザー ARN と赤のドメイン ARN を生成されたポリシーからのものに置き換えます。プロキシを実行し、127.0.0.1:9200 でリッスンします。次に、curl を使用して Elasticsearch API 呼び出しを http://127.0.0.1:9200/ に送信すると、それらが使用するドメインに転送されます。開発マシン上で Kibana をローカルで実行する場合は、kibana.yml のhttp://127.0.0.1:9200/ を参照してください。

CloudTrail を使用してアクセスポリシーの変更を監視する
Amazon CloudTrail は、さまざまなサービスと対話するときに AWS に送信されるリクエストのログを提供します。Amazon Elasticsearch Service は、ドメインの作成、ドメイン設定の更新、タグの追加など、すべての管理アクションに対して CloudTrail イベントを送信します。CreateElasticsearchDomain および UpdateElasticsearchDomainConfig API 呼び出しの CloudTrail イベントを監視して、組織内のユーザーがドメインを作成または変更するときにアクセスポリシーを検証することをお勧めします。これらのログを使用して、すべてのアクセスポリシーを確認し、前述のプラクティスに準拠していることを確認できます。

まとめ
これで、テストと開発の際にニーズに合ったアクセスポリシーを簡単に設定できることを示すことができたと考えています。ご質問、コメント、ご提案があれば、コメントに投稿してください。