こんにちは、テクニカルトレーナーの鬼形です。
2016/10/26に開催されましたAWS Black Belt Online Seminar「Amazon EMR」 の資料を公開しました。
« 2016年9 月 | メイン | 2016年11 月 »
こんにちは、テクニカルトレーナーの鬼形です。
2016/10/26に開催されましたAWS Black Belt Online Seminar「Amazon EMR」 の資料を公開しました。
2016/10/27 カテゴリー: awsblackbelt | 個別ページ | コメント (0)
こんにちは、テクニカルトレーナーの鬼形です。
2016/10/19に開催されましたAWS Black Belt Online Seminar「AWS IoT」 の資料を公開しました。
こちらで動画もご覧になれます。
頂いたご質問の回答についても併せてご覧ください。
Q1: デバイス証明書のパターン2は、どのようなメリットがあるのでしょうか?
パターン1の1クリックで生成されるデバイス証明書は有効期限が無期限になっています。もし有効期限を指定したい場合はパターン2のCSRに有効期限を指定することで設定することが可能です。
Q2: 液晶ディスプレイの電源をONしたりOFFしたりをシャドウで実現できますか?
液晶ディスプレイ自身か液晶ディスプレイを制御できる端末がAWS IoTと接続することが可能で、液晶ディスプレイ自身か制御端末がプログラムで電源を制御できるのであれば可能です。
Q3: もっと複雑なデバイス属性情報を管理したいときは、どういう方法がありますか?
Thingタイプを利用すると50個までの属性を管理することができますが、さらに複雑な属性を管理したい場合は例えばDynamoDBに情報を保存するなどの方法が可能です。
Q4: Websocketを利用するときの認証情報は?
WebSocketを利用する場合は、認証方式はIAMクレデンシャルを使うSIGV4の認証になります。
Q5: メータリングユニットとは何でしょうか?
計測機器のことです。一例として上げさせて頂きました。
Q6: デバイスへのx509証明書登録を効率よく行う方法はないでしょうか
スクリプトでAWS CLIを利用することで効率化が可能です。
Q7: mqttのwillはサポートされてますか?
willはサポートされておりませんが、ライフサイクル イベントを利用してデバイスのConnect/Disconnectを取得することができます。
Q8: AWSIoT到達後、各種DBへ転送した際、転送時間にタイムラグなどはあるのでしょうか。
AWS IoT到達後から各種DBへ転送の間にタイムラグが発生する可能性はあります。もし正確なデータの生成時間が必要であれば、デバイス側で生成時刻を取得してトピックのメッセージに保存するなどの工夫が必要です。
QAは以上となります。
今後のAWS Black Belt Online Seminarのスケジュールは こちら です。多くの方のご参加をお待ちしております。
2016/10/26 カテゴリー: awsblackbelt | 個別ページ | コメント (0)
2016/10/24 カテゴリー: awsblackbelt | 個別ページ | コメント (0)
こんにちは、ソリューションアーキテクトの舟崎です。
2016/10/18に開催されましたAWS Black Belt Online Seminar「AWS上でのActive Directory構築」 の資料を公開しました。
また、頂いたご質問の回答についても併せてご覧ください。
Q1: AWS Directory Serviceの配下にできるEC2はLinuxも可能ですか?
はい。LinuxまたはWindowsが稼動しているEC2インスタンスをMicrosoft ADまたはSimple ADに追加することができます。
Q2: AWS Directory Serviceは、サーバー監視やスケールアウトも不要ですか?
ディレクトリのステータスが変更されるときに電子メールやテキストメッセージを受信するようにAmazon Simple Notification Service (SNS)を設定できます。また、Microsoft ADは最大50,000ユーザー(ユーザー、グループ、およびコンピュータを含め約20,000ディレクトリオブジェクト)を想定されて設計されています。
Q3: オンプレのAD DSとAWS ADサービスの構成のおすすめはシングルフォレスト・シングルドメインとのことですが、「シングルドメイン」の場合はAWS側の制約(例:パスワードポリシ)にオンプレ側を合わせる必要があると思います。正しいでしょうか?
オンプレミスのAD DSとの間でシングルドメイン構成をとる場合、パスワードポリシーなどはオンプレミスにあわせていただくことが可能です。また、マネージドサービスのMicrosoft ADを使用する場合は、フォレスト間の信頼関係を使用するためマルチフォレスト構成となります。
Q4: AWSのADサービスでは、Windows DHCPではなく別途提供されるDHCPサービスを利用するとのことですが、機能はAD DHCP相当と考えてよいでしょうか? たとえば、DDNSによるA/PTXレコード更新やサービスリソースレコードの登録は可能ですか?
AWS上にActive Directoryを展開する場合、VPC内のDHCPサービスを利用します。また、DHCP Option Setで指定することにより、Amazon DNSではなくMicrosoft DNSを参照することできるようになるため、DDNSなどの機能は問題なく利用できます。
Q5: FSMOはオンプレにあるべきでしょうか?新規ADをAWS上(仮想上)にだけ配置することで問題点はないでしょうか?
操作マスタ(FSMO)はオンプレミスにあってもAWSにあっても問題ありません。
Q6: オンプレミスとAWSディレクトリサービスで信頼関係を結ぶ場合は、Direct Connectのみがサポートでしょうか?
インターネットVPNもしくはDirect Connect 専用線接続が利用可能です。
Q7: AWS Directory Serviceの配下にオンプレのサーバーを組み込めますか?社内にAD DSをおかずにAWS ADサービスを使用し、社内のクライアントをメンバーとして利用することは可能ですか?
オンプレミスのサーバー/クライアントから直接AWS上のMicrosoft ADがホストするDNSを参照するようにすれば、AWS上のドメインに参加することは可能です。ただし、認証のトラフィックやネットワーク切断時の影響などを考慮するとオンプレミスにもドメインコントローラーを配置することを推奨します。また、Microsoft ADではドメインコントローラーの追加はサポートされないため、その場合はEC2上での構築が前提となります。
Q8. AWSのコンソール画面の機能制限は、詳細に設定できますか?
Active DirectoryからIAMフェデレーションでマネージメントコンソールにログインした場合、IAMポリシーによって操作可能な機能を制限することが可能です。
QAは以上となります。
今後のAWS Black Belt Online Seminarのスケジュールは こちら です。多くの方のご参加をお待ちしております。
AWSは、インターネットからの攻撃に対して、高い可用性とセキュリティ、弾力性を兼ね備えています。この取り組みの一環として、弾力性のあるアプリケーションを実現するために、AWSサービスに対するDDoS攻撃への対応や、ツール、ベストプラクティスを提供しています。
私たちは、「AWS Best Practice for DDoS Resiliency Whitepaper」の2016年版をリリースしました。これは、DDoSを受ける可能性のあるパブリック接続されているエンドポイントに対して効果があります。このホワイトペーパーは下記の方に読んでもらいたいと考えています。
更新されたホワイトペーパーは、アプリケーションレイヤの攻撃や帯域をあふれさせるような攻撃といった、様々な攻撃手法について記載があり、また、それらの効果的な対策としてのベストプラクティスが記載されています。私たちは、あなたのアプリケーションを守るために、DDoSを緩和するための戦略において、サービスと機能がフィットするかについての説明を加えています。また、ホワイトペーパーの「ベスト・プラクティスの概要」という表は、ホワイトペーパーを規範的なガイダンスとして利用し、アーキテクチャの改善を行うきっかけを作るチェックリストとして使うことが可能です。
- Andrew
原文: Updated Whitepaper Available: AWS Best Practices for DDoS Resiliency - https://aws.amazon.com/jp/blogs/security/updated-whitepaper-available-aws-best-practices-for-ddos-resiliency/
(翻訳:瀧澤与一)
こんばんは。SAの小川です。
先週10/12に開催したBlackBeltオンラインセミナー「Elastic Load Balancing」の資料が公開されました。新リリースとなるApplication Load Balancer と従来版のClassic Load Balancerのそれぞれについて解説した資料となっております。セミナー中にみなさまからお寄せ頂いたQ&Aの回答と併せて掲載させて頂きます。
2016/10/19 カテゴリー: awsblackbelt | 個別ページ | コメント (0)
こんにちは、ソリューションアーキテクトの舟崎です。
2016/10/11に開催されましたAWS Black Belt Online Seminar「AWSのコスト削減オプション」の資料が公開されました。
今後のAWS Black Belt Online Seminarの予定は こちら をご覧ください。
多くの方のご参加をお待ちしております。
みなさんこんにちは、ソリューションアーキテクト小川です。
先日開催致しましたAWS BlackBelt オンラインセミナー「AWS Quarter Update - 3Q 2016」の資料が公開されております。当日頂戴したQAと併せて紹介させて頂きます。
2016/10/15 カテゴリー: awsblackbelt | 個別ページ | コメント (0)
Amazon マシンイメージ (AMI) はお客様のAWS環境にインスタンス(仮想サーバ)を起動させる為に必要な情報を提供します。お客様はパブリックAMIからインスタンスを起動し, セキュリティやビネス要求に合わせたカスタマイズを行い、カスタムAMIとして保存することができます。最近リリースされた、暗号化されたAmazon Elastic Block Store (Amazon EBS) スナップショットのアカウント間コピー機能により、AWS Key Management Service (KMS)を利用した暗号化されたスナップショットを利用したAMIの作成や、アカウントやリージョンにまたがって AMIを公開することができる様になりました。KMSを利用して暗号化されたスナップショットを持つAMIを作成し、アカウントやリージョンに跨ってAMIを共有することができるように なりました。これにより、必要なハードニングと設定を行ったAMIを作り、カスタムAMIに基づきグローバルに一貫したインスタンスを起動することができます。また、データを保護するための利用者自身によるセキュリティやコンプライアンス要求に従いながら、分散したワークロードによって、パフォーマンスと可用性を高めることができます。
このブログ記事では、パブリックAMIから暗号化されたカスタムAMIをつくり、暗号化されたEBSスナップショットによるカスタムAMIをアカウントやリージョンにまたがって共有するプロセスをウォークスルーします。このアプローチにより、同一の基礎となる暗号化されたAMIを利用して、複数アカウントでグローバルにAmazon EC2インスタンスを起動することができます。
Note: この記事は、Windows AMIやbillingProduct codeを持つAWS マーケットプレイスからの他のAMIには適用できません。
ソリューション概要
次の図は、このブログ記事で議論するソリューションを表現しています。
前提条件
このウォークスルーでは、2つのAWSアカウントが必要です。
この例では、架空のアカウントIDである111111111111 と999999999999をそれぞれソースアカウント、ターゲットアカウントとします。この記事を読み進める際には、それらのアカウントIDを自身の環境に合う様に読み替えてください。加えて、ソースアカウントのソースリージョンにて、KMS customer master key (CMK) を作成し、同じ様にターゲットアカウントのターゲットリージョンにて、CMKを作成してください。ターゲットアカウント向けのCMKを作成する際には、カスタムAMIを利用してEC2インスタンスを起動させるリージョンを選択してください。KMSの鍵は、作成されたAWSリージョンの外に転送されるは無いことに注意が必要です。分かり易くする為に、ここでは、2つのKSM CMKを作成しました。アカウント111111111111 のus-east-1にcmkSourceを作成し、アカウント999999999999 のeu-west-1にcmkTargetを作成しています。
Note: デフォルトEBS CMKで暗号化されたスナップショットは別のアカウントに共有することはできません。サービスデフォルトCMKで暗号化されたリソースは同じアカウントでのみ共有できます。デフォルトEBS CMK (キーエリアスはaws/ebs)による暗号化されたスナップショットから始める場合は、スナップショットをコピーし、KMSで作成したカスタムCMKにて再暗号化してください。外部のアカウントIDがアクセスできるようにカスタムCMKの鍵ポリシーを変更することが出来ます。
ソースアカウントのIAMユーザやロールはカスタムAMIを作る権限とEC2 ModifySnapshotAttribute操作権限が必要となります。
上記に加え、このIAMユーザやロールは、ソースアカウントのKMS CMK(cmkSource)に対してKMS DescribeKey、CreateGrant,、GenerateDataKey、ReEncypt 操作権限も必要となります、
ソースアカウントのIAMユーザ、ロールのポリシー
次のJSONドキュメントはIAMユーザ、ロールが必要となる権限の例です。このIAMポリシー内の権限が有効になるように、cmkSourceの鍵ポリシードキュメントはソースアカウントに権限委譲しなくてはなりません。この権限委譲は、KMS鍵を作成した際に発生します。cmkSourceに対する鍵ポリシーを変更している場合には、変更を戻し、そのアカウントへの委譲を再び有効にしてください。詳細は、KMS Developer Guideを確認してください。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:CreateGrant", "kms:DescribeKey*" ], "Resource": [ "arn:aws:kms:us-east-1:111111111111:key/Key-ID of cmkSource" ] }, { "Effect": "Allow", "Action": [ "kms:ListKeys", "kms:ListAliases" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:RunInstances", "ec2:StartInstances", "ec2:CreateImage", "ec2:CopyImage", "ec2:ModifySnapshotAttribute", "ec2:CreateSecurityGroup", "ec2:AuthorizeSecurityGroupIngress", "ec2:Describe*" ], "Resource": [ "*" ] } ] }
ターゲットアカウントでのIAMユーザやロールはAMIを作成する権限が必要です。共有されたAMIの暗号化されたスナップショットを復号化する為に、ターゲットアカウントでのIAMユーザやロールは、ソースアカウントのcmkSource鍵に対してKMS DescribeKey、CreateGrant、およびDecryptの権限が必要となります。加えて、ターゲットアカウントによって管理されているKMS鍵を使った新しいAMIスナップショットを作成する為に、ターゲットアカウントのcmkTarget鍵に対してKMS CreateGrant、 Encrypt、 Decrypt、 DescribeKey、GenerateDataKeyWithoutPlaintext 操作を実行できなくてはなりません。
次の手順では、cmkSourceをスナップショットの復号化に利用する権限付与を示します。ターゲットアカウントIDをcmkSource鍵ポリシーに追加する必要があります。
アカウント間によるカスタム暗号化鍵の共有に関するさらなる情報は、「Share Custom Encryption Keys More Securely Between Accounts by Using AWS Key Management Service.」を参照して下さい。
ターゲットアカウントのIAMユーザ、ロールのポリシー
次のJSONドキュメントはIAMユーザ、ロールが必要となる権限の例です。このIAMポリシーのKMS権限が有効になるよう、cmkSource、cmkTargetに対する鍵ポリシードキュメントは、アカウントに権限委譲しなくてはなりません。この権限委譲は、デフォルトでKMS鍵を作成する際に発生します。cmkSourceまたは、cmkTargetに対する鍵ポリシーを変更している場合には、変更を戻し、そのアカウントへの委譲を再び有効にしてください。詳細は、KMS Developer Guideを確認してください。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "kms:DescribeKey", "kms:CreateGrant", "kms:Decrypt" ], "Resource": [ "arn:aws:kms:us-east-1:111111111111:key/key-id of cmkSource" ] }, { "Effect": "Allow", "Action": [ "kms:CreateGrant", "kms:Encrypt", "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": [ "arn:aws:kms:eu-west-1:999999999999:key/key-id of cmkTarget" ] }, { "Effect": "Allow", "Action": [ "kms:ListKeys", "kms:ListAliases" ], "Resource": [ "*" ] }, { "Effect": "Allow", "Action": [ "ec2:ModifySnapshotAttribute", "ec2:CreateImage", "ec2:CopyImage", "ec2:RegisterImage", "ec2:CopySnapshot", "ec2:Describe*" ], "Resource": [ "*" ] } ] }
ソリューションのデプロイ
Step 1: パブリックAMIからEBS-backendのカスタムAMIの作成
パブリックAMIからEBS-backendのカスタムAMIの作成:
EBS-backend AMIの作り方に関する詳しい概要は、Creating an Amazon EBS-Backed Linux AMI と Creating an Amazon EBS-Backed Windows AMI.を確認してください。
Step 2: 暗号化スナップショットによるカスタムAMIの作成
暗号化されたbootボリュームを利用したカスタムAMIの作成:
次のスクリーンショットの様に、暗号化スナップショットを持つカスタムAMIが作成されます。
Step 3: 暗号化スナップショッのターゲットアカウントへの共有
暗号化スナップショットによるAMIをアカウント間で直接共有することは出来ません。代わりに、AMIに紐づく化暗号化スナップショットを個別に他アカウントにコピーし、ターゲットアカウントで再作成しなくてはなりません。これは、暗号化されたスナップショットは潜在的に異なるKMSマスター鍵により暗号化され、各スナップショットのcopy/decrypt/reencrypt操作は独立して行われる為です。
暗号化されたスナップショットをターゲットアカウントに共有する:
Step 4: ターゲットリージョンへのスナップショッのコピーとターゲットリージョンにおけるターゲットアカウント KMS暗号化鍵による再暗号化
ターゲットリージョンへのスナップショットのコピーとターゲットリージョンにおけるターゲットアカウント KMS暗号化鍵による再暗号化
Step 5: ターゲットリージョンにおける暗号化されたEBSスナップショットを使用したAMIの作成
ターゲットリージョンにおける暗号化されたEBSスナップショットを使用した、ターゲットアカウントでのAMIの作成 :
これで、ソースアカウントのus-east-1からコピーしたカスタムAMIを使って、ターゲットアカウントのeu-west-1にEC2インスタンスを起動できる様になりました。カスタムAMIは、ソースアカウントで行ったカスマイズ済みの構成を利用し、全てのデータはエンドツーエンドで暗号化されています。
まとめ
このブログ記事では、暗号化スナップショットを持つAMIをアカウント及びリージョンをまたがってコピーする方法を示しましました。
これによって、分散されたワークロードによる俊敏性と可用性を向上させながら、利用者自身のセキュリティやコンプライアンス要求に従った、承認されたAMIに基づいてグローバルで一貫性のあるインスタンスの起動を行える様にします。さらなる学習に為には、次のドキュメントも確認して下さい。
この記事に対してコメントについては、Comments欄から投稿下さい。質問、実装時における問題がある場合は、EC2フォーラムに投稿をお願いします。
- Eugene
原文:How to Create a Custom AMI with Encrypted Amazon EBS Snapshots and Share It with Other Accounts and Regions(翻訳:SA 浅野)
先日ご紹介したAmazon PersonalizationチームがAmazon ECS上でDSSTNEを使ったレコメンド生成を行っている事例の参照実装として、AWS Computeブログに記事が投稿されましたので翻訳しました。AWS CloudFormationテンプレートが提供されているので、どなたでも今すぐ環境を構築することができますのでぜひお試し下さい。
なお、こちらの内容について10月末に開催されるHadoop Summit Tokyo 2016でもセッションを行いますので、ぜひご参加下さい。
Amazon ECS上のワークロードの多くは、コンテナと明らかに親和性の高い3つのカテゴリに分類されます:
これらは最も一般的なワークロードではありますが、ECSは他にも多種多様なアプリケーションにも使われています。その中でも新しく興味深いワークロードの1つがGPU高速化のワークロードです。もっと詳細に言えば、多数のノードにまたがる多くのGPUを効率的に活用したいワークロードということになります。
この記事では、どの様にしてECSでGPUワークロードを有効化すればいいのかを見ていきます。例えば、Amazon.comではAmazon PersonalizationチームがECS上の多数のGPUを使って巨大な機械学習の学習ワークロードを効率的に実行しています。
ECSはAWS上でコンテナを動かすためのスケーラビリティとパフォーマンスの高いサービスです。ECSの状態管理エンジンはお客様自身がオーケストレーションのソフトウェアを動かすという重労働を代わりにやってくれ、また他の多くのAWSサービスとの連携も提供します。例えば、Task毎にIAMロールを割り当てたり、Serviceの負荷に応じてコンテナをAuto Scalingさせたり、アプリケーションの負荷を分散するために新しいApplication Load Balancerを使って、Auto Scalingのアクションが起こった時には自動的に新しいTaskをチェックして登録することもできます。
現在、多くのお客様が多種多様なアプリケーションをAmazon ECS上で動かしていて、その中のいくつかのケースは以下で読むことができます:
Amazon.comにログインすると、あなたが興味あるであろう商品が推薦されているのを見ることができると思います。Amazon PersonalizationチームがAmazonのお客様一人一人向けに商品の推薦を生成しています。そのために、Amazon.comが持っている数億個の商品(また同じくらいのお客様)に関する情報を含む巨大なデータセットを要約する必要があります。
この仕事を現実的な時間内に終わらせるためには、超多数のマシンにまたがって処理を分散する以外に方法はありません。Amazon Personalizationではニューラルネットワークの学習にGPUを利用できる機械学習のソフトウェアを使っていますが、超多数のGPUコアにまたがってこの処理を管理するのは難しい課題です。
この課題解決のために、Amazon PersonalizationではAmazon EC2のGPUインスタンスを使ったClusterの管理にECSを利用しています。チームはP2という、NVIDIA Tesla K80 GPUが載ったインスタンスを使っています。P2インスタンスのClusterは、CPU、メモリ、そしてGPUを統合した1つのリソースプールとして機能しており、その上に機械学習の処理がスケジュールされます。
ECS Cluster上でこの処理を実行するために、DockerイメージはNVIDIA CUDAドライバを使って設定されているので、GPUハードウェアと通信することができますが、それをAmaozn EC2 Container Registry (Amazon ECR)に保存されています。
ECS Task DefinitionではECR上のそのコンテナイメージを指しており、他にもどれくらいのCPUやメモリを各コンテナが使うべきか、もしデータボリュームが必要であればコンテナのどこにマウントすればよいのか、ソースデータがAmazon S3のどこに存在するのか、といった実行時の設定を指定しています。
ECSにTaskの実行を依頼すると、ECSのSchedulerはCluster内で利用可能なリソースを持っているインスタンスを指定することで、そのコンテナ達が実行するのに十分な場所を見つけます。以下のアーキテクチャ図にある通り、ECSはコンテナをEC2のGPUインスタンス(図の中で”GPU slaves”と書かれている部分) にコンテナを配置することができます。
ECS上でGPUを簡単に試せる様に、AWS CloudFromationテンプレートを作成しておいたので面倒な作業をせずに済みます。このデモアーキテクチャは、Amazon Personalizationチームが実際の推薦情報の生成に利用しているオープンソースの機械学習ライブラリであるDSSTNEを中心に構築されています。CloudFormationテンプレートはGitHubレポジトリで見ることができます。
このテンプレートはAuto ScalingグループでEC2のGPUインスタンスを1台起動したECS Clusterを作成します。もしやりたければ、もっと大きいClusterで実行するためにグループの必要なキャパシティを調整することができます。
インスタンスはDSSTNEがGPUハードウェアを操作するのに必要な、NVIDIAドライバ等のソフトウェアが全て設定済となっています。またテンプレートはGCC、HDF5、Open MPIといった開発に必要なツールやライブラリもインストールされているので、起動時にDSSTNEライブラリをコンパイルすることができます。その後DSSTNEライブラリをパッケージしたDockerコンテナをビルドしてECRにアップロードします。そしてECR上のコンテナイメージのURLを使って、それを指定したECS Task Definitionを作成します。
CloudFormationテンプレートからの生成が完了したら、Outputsタブを見ると作成されたリソース群を見ることができます。
この記事では、ECSをGPUワークロードでどの様に使えばよいかを解説し、ECSとDSSTNEを簡単に試すことのできるCloudFormationテンプレートを共有しました。
残念ながら、この記事で機械学習の詳細について説明すると長くなってしまうので省略しましたが、AWS Big Data BlogのGenerationg Recommendations at Amazon Scale with Apache Spark and Amazon DSSTNEという記事(訳注: こちらに日本語訳があります)を読むと、DSSTNEがモデル学習や予測生成をどうやってApache Sparkと連携しているかや、機械学習の興味深いコンセプトについて知ることができます。
原文: Orchestrating GPU-Accelerated Workloads on Amazon ECS (翻訳: SA岩永)
このブログ内の記事を検索
このブログの最新情報はTwitter、Facebookでもお知らせしています。お気軽にフォローください。 @awscloud_jpをフォロー
日 | 月 | 火 | 水 | 木 | 金 | 土 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |