Author: AWS Japan Staff


SPICEデータのスケジュールリフレッシュがAmazon QuickSightに追加されました

Amazon QuickSightにSPICEデータのスケジュールリフレッシュ機能が追加されました。以下はAWS Bigdata Blogに掲載されたブログの翻訳です。


Jose KunnackalはAmazon QuickSightのシニアプロダクトマネージャ

2016年11月に私達はAmazon QuickSightローンチしました。これはクラウドのパワーで稼働し、お客様のデータをクイックかつ簡単に分析するビジネスアナリティクスのサービスです。QuickSightはSPICE (Super-fast, Parallel, In-Memory Calculation Engine)というフルマネージドのデータストアを持っており、これにAWSやオンプレミス、クラウドサービスのデータを格納することで超高速なビジュアライゼーションを可能にします。SPICEに格納したデータはQuickSight上にあるボタンをクリックするだけでいつでもリフレッシュ(新しいデータの取り込み)を行うことが可能です。

本日、リフレッシュのスケジュール実行機能をローンチいたします!

SPICEデータセットをスケジュールリフレッシュする

schedule refresh
SPICEデータセットを選択し、スケジュールリフレッシュを指定します。その後、タイムゾーン、リフレッシュ頻度、およびスケジュールの開始日時を指定します。

スケジュールを適切に設定することで、SPIPCEのデータセットや分析、ダッシュボードを元のデータソースに同期させることが可能になります。

スケジュールリフレッシュはサポートされるすべてのデータソース、つまりAWS、クラウドサービス、およびオンプレミスにあるデータに対して有効であり、全サポートリージョンのすでに作成済のデータセットについても利用可能です。手動でのリフレッシュと同様に、データセットのリフレッシュ状況のサマリを確認することが可能です。

データのスケジュールリフレッシュによって高いパフォーマンスを発揮するインタラクティブなダッシュボードをQuickSightとSPICEでシンプルに実現可能です。データリフレッシュのために所定の時間にQuickSightにログインする必要もありませんし(もしくはうっかり忘れることもなくなります)、QuickSightを活用して高速でインタラクティブなビジュアライゼーションを多くのユーザに提供することにフォーカスできます。

QuickSightのパワーをぜひ今日から体験してみてください – 無料枠がありますのでぜひサインアップを!もしご質問などがありましたら、コメントを残してください。
(訳注:QuickSightには全機能を60日間試せるFree Trialがあります。また、機能は制限されますが無料でずっと利用できるFree Tierも用意されています。詳しくはこちらをご確認ください。)


原文:https://aws.amazon.com/jp/blogs/big-data/scheduled-refresh-for-spice-data-sets-on-amazon-quicksight/

翻訳:下佐粉 昭 (@simosako)

 

3月のAWS Black Belt オンラインセミナーのご案内

こんにちは。ソリューションアーキテクトの志村です。AWS Black Belt オンラインセミナー3月の配信についてご案内させて頂きます。今月は2月にリリースされたばかりの「Amazon Chime」をはじめとして、初登場となるサービスが多数あります!

201703_BB

3月の開催予定

サービスカット
3/1(水) 18:00-19:00 Amazon Athena
3/8(水) 18:00-19:00 Amazon Chime
3/15(水) 18:00-19:00 Auto Scaling
3/22(水) 18:00-19:00 Developer Tools (CodeX シリーズ)
3/29(水) 18:00-19:00 Amazon AI

ソリューションカット
3/14(火) 12:00-13:00 Well-Architected Framework
3/28(火) 12:00-13:00 動画配信 on AWS

お申し込みは、それぞれ上記のリンクより行って頂けます。キャンセルの際も連絡不要ですので是非お早めにご登録ください。Speaker、Staff 一同みなさまのご参加をお待ちしております。

Amazon EBSのアップデート – 新機能エラスティックボリュームが全てを変える

お客様からビジネスのダイナミックさと、それを実現するためのアプリケーションがブロックストレージに求めるものについてご意見をうかがうことは、いつも興味深いものです。ビジネス状況の変化に伴ってブロックストレージへの要求も変化し、容量を追加したり、性能特性の異なるボリュームが必要になったりすることもあるはずです。今日では、24時間運用され続けるシステムも珍しくはありません。結果として、ダウンタイムやシステム運用への影響なく変更作業を行えることがお客様にとって重要な要素となってきます。

我々は長年にわたり、お客様の様々なユースケースをカバーするために、EBSに新機能を追加し続けてきました。例えば、2016年にはスループット最適化HDD(st1)とコールドHDD(sc1)という2種類のボリュームタイプをリリースしました。これらのボリュームをシステム運用への影響なく、パフォーマンス特性の変更やコスト削減を行うことで、階層化ストレージのように利用したいと考えるお客様がいらっしゃいます。言い換えると、お客様はEBSがより柔軟になることを望んでいるのです!

エラスティックボリューム
本日、EBSの新機能としてエラスティックボリュームをリリースいたしました。これは現行世代のEC2インスタンスにアタッチされた、全ての現行世代のEBSボリュームで利用可能です。お客様はボリュームサイズの拡張、パフォーマンスの調整、ボリュームタイプの変更を利用中に行うことができます。変更処理はオンラインで行われますので、お客様のアプリケーションは引き続き利用可能でダウンタイムはありません。

この新機能はリソース計画やチューニング、空き容量の管理といった作業を劇的にシンプル化してくれます。あるいは作業自体が不必要になるかもしれません。従来のやり方はダウンタイムを伴うため、変更の完了までプランニングやシステム停止の調整を含めると数週間から数ヶ月にわたる時間が必要でした。しかしこれからは、利用しているストレージインフラストラクチャをシンプルなAPIコールで簡単に変更することが可能になります。

  • ワークロードの変化 – インフラ構築を急ぐ必要があり、汎用SSDボリュームを採用することにしました。システムをリリースし、運用を行っていくにつれて、スループット最適化HDDボリュームが最適であることに気づいたとしましょう。エラスティックボリュームの機能により、単純にボリュームタイプを変更するだけで対応が完了します。
  • 突発的な需要への対応 – プロビジョンドIOPSボリューム上に構築したリレーショナルデータベースで、1ヶ月のほとんどの期間にわたり問題なく処理を行えるシステムがあります。ただし月末処理の関係で各月終わりの3日間は10倍のトラフィックを処理する必要があったとします。この場合は、エラスティックボリュームを利用して月末の3日間だけIOPSを高く設定し、処理が終わったら元に戻すという運用が可能です。
  • ストレージの増加 – 100GBのボリュームで運用してきたシステムで、ディスク使用率が90%を超過したというアラームが発報しました。あらかじめ設定を行っておけば、ボリュームとファイルシステムの拡大を自動的にダウンタイム無しで行うこともできます。

エラスティックボリュームの利用

お客様はこれら全ての操作をAWSマネジメントコンソールやAPIコール、AWSコマンドラインインタフェース(CLI)で実行できます。これに加えて、AWS CloudFormationのスタック更新機能を利用することも可能で、対象のボリュームに必要な変更を行ってくれます。コンソールを利用する場合は、対象のボリュームを選択してアクションメニューから「Modify Volume」を選択するだけです:
ebs1

ポップアップするウィンドウの中で、ボリュームタイプやサイズ、IOPS値(プロビジョンドIOPSボリュームの場合)を変更してください。これは75GBの汎用SSDボリュームを、20,000IOPSで400GBのプロビジョンドIOPSボリュームに変更する例です:
ebs2

変更ボタンをクリックしたら、確認ウィンドウが表示されるので問題が無ければ「YES」をクリックします:
ebs3

ボリュームの「状態」に変更処理の進捗状況(modifying、optimizing、completed)が表示されます:
ebs4

次のステップは追加されたストレージ領域を利用できるようにするために、ファイルシステムを拡張することです。作業の詳細についてはLinuxでEBSボリュームのストレージ領域を拡張するWindowsでEBSボリュームのストレージ領域を拡張するを参照してください。ボリュームの状態が最適化中に変わったら(通常数秒で変わります)、ファイルシステムの拡張作業を行うことができます。新しいボリュームの容量やタイプはすぐに利用可能になりますが、最適化の処理は最大で24時間を要する場合があります。コストについて補足すると、ボリュームの状態がoptimizingになったタイミングで新構成を基準に計算されることになります(変更自体のコストはかかりません)。

エラスティックボリュームの自動オペレーション
手動オペレーションでの変更も充分に魅力的ですが、自動化を行うたくさんのチャンスがあります。いくつかのアイデアをお見せしてみましょう:

  • 正しいサイジング – IOPS上限か、それに近いレベルに到達しているかをCloudWatchで監視しアラームを上げるよう設定します。アラームが上がったらIOPS値の増加や、ボリュームタイプの変更を行うための承認プロセスを開始し、変更作業の準備を進めます。同様にCloudWatchのカスタムメトリクスを利用して空き容量をモニタリングして、拡張のための承認プロセスを開始することもできます。
  • コストの削減 – CloudWatchメトリクスや予め設定したスケジュールに従ってIOPSの削減やボリュームタイプの変更を行います。(背景:先週、大学のセキュリティ管理者と会話する機会がありました。彼は学内の全てのサーバから1日に10GBのログを収集し、60日間に渡って保持するという仕事をしています。ほとんどのファイルは参照されることはなく、参照が必要になったときでもアクセス速度はそれほど求められません。この場合、1日分のログを書き込むための汎用SSDボリュームを作成し高速な書き込みを実施し、完了したらスループット最適化HDDに変更することでコストを最適化することができます。)

先にお伝えしたように、新たに追加された領域を利用できるようにするためにはファイルシステムをリサイズする必要があります。この手順をお見せするために、私の同僚がCloudWatch Events、AWS Lambda、EC2 Systems Managerを利用したPythonとPowerShellのサンプルスクリプトを提供してくれました。このルールはEBSから送信される情報に基づきmodifyVolumeというイベントにマッチし、logEventsというLambdaファンクションを起動します:
ebs5

このファンクションは対象となるボリュームを特定し、これがEC2 Systems Managerで管理されるインスタンスにアタッチされていることを確認したうえでメンテナンス用のタグ情報を付与します:

def lambda_handler(event, context):
    volume =(event['resources'][0].split('/')[1])
    attach=ec2.describe_volumes(VolumeIds=[volume])['Volumes'][0]['Attachments']
    if len(attach)>0: 
        instance = attach[0]['InstanceId']
        filter={'key': 'InstanceIds', 'valueSet': [instance]}
        info = ssm.describe_instance_information(InstanceInformationFilterList=[filter])['InstanceInformationList']
        if len(info)>0:
            ec2.create_tags(Resources=[instance],Tags=[tags])
            print (info[0]['PlatformName']+' Instance '+ instance+ ' has been tagged for maintenance' )

 

その後に、EC2 Systems Managerがメンテナンス用のタグが付与された全てのインスタンスでPowerShellスクリプトを起動します。このスクリプトはインスタンスのディスクとパーティションの情報を参照し、拡張を必要とする全てのドライブとファイルシステムについて、許容可能な最大サイズまで拡張を行います。以下がスクリプトの抜粋です:

foreach ($DriveLetter in $DriveLetters) {
	$Error.Clear()
        $SizeMax = (Get-PartitionSupportedSize -DriveLetter $DriveLetter).SizeMax
}

自動化について詳しく知りたい場合は、こちらを参照してください。(訳注:翻訳時点では英語版のみですが、随時翻訳を進めて参ります)

本日からご利用頂けます
エラスティックボリュームの機能は本日今すぐにご利用頂くことができます!特殊なケースにおける例外や、制約についてはドキュメント(本記事執筆時点では英語版)をご確認ください。

— Jeff;
(日本語版はSA小林が翻訳しました。原文はこちら)

AWS Direct Connect アップデート – Link Aggregation Groups, Bundles そして re:Inventの一部振り返り

AWS Direct Connect は、大規模な顧客に対してオフィス、データセンターやコロケーション設備におけるプライベートでハードウェア専有のネットワーク接続の設立を支援します。1 Gbps と 10 Gbps の接続を設立することで、顧客にとってはネットワークコストの削減、データ転送スループットの向上、そしてインターネット基盤で可能な接続よりもさらに安定したネットワーク接続を確立することができます。本日は、Direct Connect の新しい Link Aggregation 機能についてご紹介します。また、新しい Direct Connect バンドルについて、そして Direct Connect をどのように活用して AWS re:Invent 2016 年の最先端の顧客エクスペリエンスを提供していることについてもさらに詳しくお話ししたいと思います。

Link Aggregation グループ 顧客なかには自身のロケーションと 46 の Direct Connect ロケーションのうちの 1 つに複数の接続 (一般的にはポートと呼ばれる) を設立することをお望みの方もいらっしゃると思います。このような顧客のなかには、AWS の外部におけるネットワーク問題に対しても復元力がある高度な利用可能性をもったリンクの設立が希望でしょう。また、さらなるデータ転送スループットのみを必要とする場合もあります。このような顧客にとって重要なユースケースをサポートするために、最大で 4 つまでのポートの購入とそのすべてを単一管理の接続として扱うことができるサービスの提供が始まりました。これは、Link Aggregation グループ、あるいは LAG と呼ばれます。このサービスを設立すると、トラフィックはポートを通して個別のパケット接続レベルで負荷分散されます。すべてのポートは同時にアクティブとなり、単一の BGP セッションとして提供されます。グループ間のトラフィックは、動的 LACP (Link Aggregation Control Protocol、または ISO/IEC/IEEE 8802-1AX:2016) を通して管理されます。グループの作成時には、接続が有効となる際にアクティブとなるべきポートの最低数も指定する必要があります。複数のポートを持った新しいグループを注文して、既存のポートをこの新しいグループに加えることもできます。どちらの場合でも、すべてのポートは同じスピード (1 Gbps あるいは 10 Gbps) であることが必要です。グループとしてのすべてのポートは、AWS 側で同じデバイスとして接続されます。デバイスに空き容量がある限り、既存のグループにポートを追加することもできます (空き容量情報は Direct Connect Console から入手できるようになりました)。既存のグループの拡張を希望していても、デバイスに開放ポートがない場合には、新しいグループを注文して接続を移動するだけ十分です。コンソールから Link Aggregation を作成する方法を次に示します。まず、新しい LAG をゼロから作成します。

次に、既存の接続から LAG を作成します。


Link Aggregation グループは、 US East (Northern Virginia)US West (Northern California)US East (Ohio)US West (Oregon)Canada (Central)South America (Brazil)Asia Pacific (Mumbai)Asia Pacific (Seoul) リージョンで現在提供されており、今すぐ作成できます。 今月末には、そのほかのリージョンでもサービスの提供が可能になる予定です。

Direct Connect バンドル
re:Invent 2016 年にいくつかの新しい強力な Direct Connect バンドルが発表されました。それぞれのバンドルは、複雑性を低減してパフォーマンスを向上させた最先端のハイブリッドリファレンスアーキテクチャとなっています。新しいバンドルは次の通りです。Level 3 コミュニケーションパワー Amazon WorkSpaces – エンタープライズアプリケーションデータ接続、ユーザーワークスペース、そしてエンドポイントデバイスによって、信頼できるパフォーマンスとより向上したエンドユーザーエクスペリエンスを提供します: AT&T NetBond によって拡張された SaaS アーキテクチャ – AWS クラウドに移動したアプリケーション用に拡張された機能とユーザーエクスペリエンス: Megaport DX 搭載の Aviatrix ユーザーアクセス – AWS クラウドリージョン間、エンタープライズデータセンターと AWS 間、そして AWS への VPN アクセスにおける暗号化接続のサポート: Verizon の安全なクラウド相互接続 における Riverbed の Hybrid SDN/NFV アーキテクチャ – エンタープライズ顧客に安全で最適化された AWS サービスへのアクセスをハイブリッドネットワーク環境で提供します:

re:Invent 2016 年の Direct Connect
re:Invent の参加者とパートナーに最上のエクスペリエンスを提供するために、高度な利用性と完全な冗長化の通信を設立できる Level 3 を開発しました。このネットワークは、休憩セッション、認定試験、ハンズオンラボ、キーノート講演 (122 か国から 25000 人以上の閲覧者に向けたライブストリームを含む)、ハッカソン、ブートキャンプ、ワークショップをサポートするために利用されました。この re:Invent ネットワークは、10 Gbps 接続を使用し、各 2 接続が US West (Oregon)US East (Northern Virginia) です:

これは、すべての re:Invent イベントをサポートしました:

ここに、実現に至った方法とお客様ご自身で実現させる方法の詳細について役立つビデオ資料を紹介します。

Jeff;

Amazon Chime – 統合されたコミュニケーションサービス

私のように職場での日々を過ごしている方々は、職場仲間とのコミュニケーションに多くの時間を費やしていることと思います。毎日のように私は全世界の人々と通信し、お互いに協力関係を築いています。オフィスでコンピューターの前に座っている人もいれば、移動しながらスマートフォン端末を使って接続し、コミュニケーションしている人もいます。私たちはフレンドリーにチャットを交わし、頻繁に会合し、ドキュメントや画像を送受信し、画面を共有しています。長年のあいだ、多くの「ビジネス生産性」ツールには何かが欠けていました。こういったツールの多くには、1 つか 2 つのコミュニケーションモデルや協力スタイルのみが用意され、妨げとなることがありました。ライセンスの入手とトレーニングのコスト、そして社内以外の外部との協力関係へのサポートの欠如は、事態を悪化させるだけでした。今このような状況を変化させる時です。

Amazon Chime の紹介
今日は Amazon Chime についてお話ししたいと思います。この新しい統合されたコミュニケーションサービスは、ミーティングをこれまで以上に容易にし、さらに効果的にするためにデザインされています。Amazon Chime では、ワンクリックで高品質なサウンドとビデオのミーティングを始めることができます。ミーティングを始めると、チャット、コンテンツの共有、画面の共有がスムーズなエクスペリエンスとして実現でき、コンピューターや MAC のデスクトップ、iOS デバイスと Android デバイスに対応しています。Amazon Chime は完全に管理されたサービスとなるため、事前の投資、ソフトウェアの導入や常時のメンテナンスが必要ではありません。ユーザーは Amazon Chime アプリをダウンロードするだけで、数分で利用を開始できます。Amazon Chime の主な機能のいくつかを簡単にご紹介しましょう。

オンタイムミーティング – ミーティングのためにダイアルインする必要はもうありません。ミーティングのための長い識別子や同じく長いパスワードを入力する必要はありません。その代わりに、Amazon Chime はミーティングが開始する際にアラートを発信し、ワンクリックあるいはタップによって参加する (または、遅れての参加を知らせる) ことができます。

ミーティング名簿 – 冗長な「誰が参加したか」についての質問の代わりに、Amazon Chime は参加者、遅れての参加者、欠席者の名簿を視覚的に提供します。また、広範囲にアクセスできる消音機能が提供され、ほかの参加者が入力していたり、犬が吠えていた場合などに便利です。

広範囲なアクセスAmazon Chime はモバイル使用に構築され、アプリによるコンピューターとモバイルデバイスで実行できます。さらに、Amazon Chime ではひとつのデバイスからミーティングに参加し、その後シームレスに別のデバイスに移動できます。

簡単な共有 – 協力関係を築くことが Amazon Chime の中心となる機能です。ミーティングの参加者は、好きな時に画面を共有でき、許可を得る必要はありません。Amazon Chime のチャットルームでは、参加者が協力して作業でき、共有の履歴が作成されて暗号形式で保存されます。

高音質な通話Amazon Chime は、高音質で雑音のない音声とはっきりとしてクリアな HD ビデオをすべてのユーザーデバイスとほぼ全種類の会議室ビデオシステムに提供します。

Amazon Chime の実証
Amazon Chime の主な機能をまず主画面から実行してみましょう。

ミーティングをクリックし、続いて Outlook カレンダーまたは Google カレンダーにミーティングスケジュールを予定します。

Outlook カレンダーは Amazon Chime アドインを使用しています。Outlook にスケジュールをクリックするとこのアドインのインストールが求められます。通常通りにこのイベントを設定するだけです。

Amazon Chime は、ミーティング開始時にお知らせを発信します。

回答するをクリックし、音声オプションを選択するだけです。

こうして、ミーティングが始まります。別の人を招待したり、画面や希望するすべてのウィンドウの共有、webcam の使用などができます。

ミーティング開催中に変更できる数々のオプションがあります。

Amazon Chime には常時、1 対 1 のチャットとチャットルームも用意されています。新しいチャットルームの作成方法を示します。

チャットルームの作成後、ブロガーを招待し、長期の継続する会話を実現できます。これまで通り、機能の一部のみを紹介しています !今すぐ始めるには、Amazon Chime サイト にアクセスして、使い始めてみてください。

Amazon Chime Editions
Amazon Chime では、3 種類がご利用いただけます。

  • Basic Editionは無料で利用できます。このエディションでは、ミーティングへの参加、1 対 1 のビデオ通信、Amazon Chime のすべてのチャット機能ができます。
  • Plus Edition は、1人のユーザーにつき毎月 2.50 ドルで利用できます。 このエディションでは、すべての電子メールドメインの管理、1 ユーザーにつき 1 GB のメッセージ保存、そして Active Directory への接続をサポートしています。
  • Pro Edition は、1人のユーザーにつき毎月 15.00 ドルで利用できます。 このエディションでは、100 人まで参加できるミーティングが可能です。

Amazon Chime Pro は、30 日間の無料お試し期間をクレジットカードなしで提供しています。30 日の期間経過後、無料の Amazon Chime Basic を引き続きお好きなだけ利用することも、Amazon Chime Pro を 1人のユーザーにつき毎月 15.00 ドルで購入することもできます。事前のお支払いは必要なく、いつでも登録の変更およびキャンセルができます。

今すぐ始められます
Amazon Chime は今すぐご利用いただきます。サインアップして、今すぐ使い始めましょう !

Jeff;

既存のAmazon EC2インスタンスにIAM Roleがアタッチできるようになりました

AWS Identity and Access Management(IAM) のロール を利用することで、Amazon EC2上で実行するアプリケーションは、AWSが自動的に作成、配布、およびローテーションする一時的なセキュリティ資格情報を利用することができます。一時的な資格情報を使用することは、IAMのベストプラクティスとなっており、インスタンスで長期間の鍵の管理する必要がなくなります。IAM Roles for EC2 (EC2のIAMロール)を使用することで、長期的なAWSアクセスキーを手動またはプログラムで管理する必要もなくなります。そして本日、既存のEC2インスタンスにIAMロールをアタッチすることが可能になり、アプリケーションはAWSによって提供される一時的なセキュリティ資格情報を使用できるようにするよう設定できるようになりました。 また、既存のEC2インスタンスに添付されているIAMロールを変更することも可能になります。

このブログ記事では、AWS CLIを使用して既存のEC2インスタンスにIAMロールをアタッチする方法をご紹介します。

ソリューションの概要
このブログ記事のソリューションでは、

1. IAMロールの作成

2. IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ

3. アタッチされているIAMロールの付け替え

この記事では、新しく作成されたIAMロールを”YourNewRole“とします。このロールに関連付けられたインスタンス・プロファイルを”YourNewRole-Instance-Profile“、 既存のインスタンスを”YourInstanceId“とすることにます。 これら(赤字)はアカウントのリソース名に置き換えてください。
ここでは、AWSコマンドラインインターフェイス(CLI)の設定が完了しており、IAMロールを作成する権限、EC2 APIを呼び出す権限を持っていることを前提としています。

IAMロールの作成

注:既存のIAMロールをアタッチする場合は、このポストの「IAMロールなしで最初に起動された既存のEC2インスタンスにIAMロールをアタッチ」に進んでください。 またAWSマネージメントコンソールを使用してIAMロールを作成してから、同じセクションに進むこともできます。

AWS CLIからIAMロールを作成する前に、信頼ポリシーを作成する必要があります。 信頼ポリシーは、EC2などのAWSサービスがアプリケーションに代わってIAMロールを引き受けることを許可します。 信頼ポリシーを作成するには、下記のポリシーをコピーし、YourNewRole-Trust-Policy.jsonという名前で保存したテキストファイルに貼り付けます。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

信頼ポリシーを作成すると、既存のEC2インスタンスにアタッチできるIAMロールを作成する準備が整いました。

AWS CLIからIAMロールを作成

1. AWS CLIから、create-roleコマンドを呼び出し、信頼ポリシー YourNewRole-Trust-Policy.jsonに基づいきYourNewRoleというIAMロールを作成します。


$aws iam create-role --role-name YourNewRole --assume-role–policy-document file://YourNewRole-Trust-Policy.json

このIAMロールにアカウントのリソースへのアクセス権を付与するに、attach-role-policyコマンドを呼び出します。 この例では、アカウント内のすべてのAmazon S3バケットとバケット内のオブジェクトへの読み取り専用アクセスがアプリケーションに必要であると想定しています。 そのため、AWS管理ポリシーである、AmazonS3ReadOnlyAccess を使用することにします。 AWS管理ポリシーの詳細については、「管理ポリシーの使用」を参照してください。


$aws iam attach-role-policy --role-name YourNewRole --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

3. create-instance-profileコマンドを呼び出し、続いてadd-role-to-instance-profileコマンドを実行し、IAMインスタンスプロファイル”YourNewRole-Instance-Profile“を作成します。 インスタンスプロファイルにより、EC2はIAMロール”YourNewRole“をEC2インスタンスに渡すことができます。 詳細については、「インスタンスプロファイルの使用」を参照してください。


$aws iam create-instance-profile --instance-profile-name YourNewRole-Instance-Profile

$aws iam add-role-to-instance-profile --role-name YourNewRole --instance-profile-name YourNewRole-Instance-Profile

YourNewRole“というIAMロールが正常に作成されました。

IAMロールなしで起動された既存のEC2インスタンスにIAMロールをアタッチ

これで、YourNewRoleというIAMロールをEC2インスタンスYourInstanceIdにアタッチする準備が整いました。 ロールを添付するには:

associate-iam-instance-profileコマンドを呼び出して、新しく作成されたIAMロールの”YourNewRole-Instance-Profile“、”YourNewRole“のインスタンスプロファイルをEC2インスタンス”YourInstanceId“にアタッチします。


$aws ec2 associate-iam-instance-profile --instance-id YourInstanceId --iam-instance-profile Name=YourNewRole-Instance-Profile

2. describe-iam-instance-profile-associationコマンドを呼び出すことで、IAMロールがインスタンスにアタッチされていることを確認します。


$aws ec2 describe-iam-instance-profile-associations

3. これで、IAMロールを使用してAWSリソースにアクセスできるようになるため、インスタンスから長期間保管した鍵を削除するようにアプリケーションを更新できます。

アタッチされたIAMロールの付け替え

役割の要件が変更され、IAMロールを介してEC2インスタンスに付与された権限を変更する必要がある場合は、IAMロールに関連付けられたポリシーを置き換えることもできます。 ただし、このIAMロールを使用する他のEC2インスタンスのアクセス許可も変更されます。

代わりに、replace-iam-instance-profile-associationを呼び出して、現在アタッチされているIAMロール”YourNewRole“を別のIAMロールに置き換えることができます。 次の例では、”YourCurrentAssociation-id“を使用して現在のiam-instance-profile-associationインスタンスを示し、”YourReplacementRole-Instance-Profile“を使用して、そのインスタンスに関連付ける置換インスタンスプロファイルを示します 。 これらのプレースホルダーを、適切なassociation-idとアカウントのIAMインスタンスプロファイル名に置き換えてください。


$aws ec2 replace-iam-instance-profile-association --association-id YourCurrentAssociation-id --iam-instance-profile Name=YourReplacementRole-Instance-Profile

注:YourCurrentAssociation-idは、describe-iam-instance-profile-associationsを呼び出すことで取得できます。

最後に

このブログ記事で紹介しました通り、インスタンスを再起動することなく、既存のEC2インスタンスにIAMロールをアタッチすることで、アプリケーションがAWSによって提供される一時的なセキュリティ資格情報を使用できるようにすることができます。 ミッションクリティカルなワークロードを終了することなく、EC2インスタンスにアタッチされたIAMロールを置き換えることもできます。

この投稿に関するコメントがある場合は、下記の「コメント」セクションに投稿してください。 ご質問やご提案がありましたら、IAMフォーラムでコメント下さい。

– Apurv

翻訳はPartner SA 酒徳が担当しました。原文はこちらです。

Amazon Rekognition の更新 – 顔の推定年齢範囲

Amazon Rekognition は当社の人工知能サービスの 1 つです。Rekognition では、画像内の物体、シーン、および顔を検出できるほか、顔を検出して比較することができます。Rekognition は、バックグラウンドで詳細な神経ネットワークモデルを使用して、毎日数十億の画像を分析しています (詳細については、「Amazon Rekognition – ディープラーニングによる画像の検出と認識」を参照してください)。Amazon Rekognition は、画像で見つけた顔ごとに属性の配列を返します。本日、推定年齢範囲という新しい属性を追加します。この値は年数で表され、整数のペアとして返されます。年齢範囲は重なる場合があります。つまり、5 歳の顔の推定範囲は 4~6 歳になるが、6 歳の顔の推定範囲は 4~8 歳となる場合があります。この新しい属性を使用すれば、公共安全アプリケーションの増強、人口動態の収集、必要な期間を対象とした写真の整理が可能になります。この新機能を少し楽しむため (私はこの投稿を金曜日の午後に書いています)、自分の写真アーカイブを掘り起こして、Rekognition に私の年齢を推定させてみました。答えは次のようになりました。最初から始めましょう。この写真では、おそらく私は 2 歳でした。

この写真は、1966 年の春に私の祖母の家で撮られたものです。

私は 6 歳でした。Rekognition は私の年齢を 6~13 歳と推定しました。

2003 年の私の最初の公式な Amazon PR 写真では、私は 43 歳でした。

これには 17 年の範囲があり、私の実年齢はちょうどその中間でした。そして私の最新の (2015 年後半) の PR 写真 (55 歳) です。

これもまたかなり幅がありますが、私の年齢はちょうど中間です。一般的に、顔の実年齢は Rekognition で示された年齢の範囲に収まりますが、正確に中間になることを当てにしないでください。この機能は提供が開始されており、今すぐ使い始めることができます。

Jeff;

さらに多くの Amazon 風力および太陽光発電所が稼働!

風力発電所AWS の持続可能性の最前線でのすばらしいニュースで新年が始まりました。

2016 年末に 3 つの風力および太陽光プロジェクトが新たに稼働し、AWS データセンターの電力を賄う送電網にエネルギーを供給しています。簡単なまとめとして、re:Invent 2016 で、副社長兼特別エンジニアの James Hamilton がメインステージで、当社は 2016 年末までに 40% の再生可能エネルギーで電力を賄うという目標を超えたこと、さらに AWS チームとエネルギーパートナー様の取り組みにより、2017 年末までに 50% を賄うという新しい目標を設定したことを発表しました。2016 年初頭に本稼働を開始したインディアナ州ベントン群にある Amazon Wind Farm Fowler Ridge に加えて、3 つの新しいプロジェクトが 12 月にオンラインになりました。これには以下が含まれます。

Amazon Wind Farm US East – 当社はまず昨年 7 月に、Amazon Wind Farm US East に関して Avangrid Renewables (当時の名前は Iberdrola Renewables) との提携を発表し、風力発電所の建設を開始しました。これはノースカロライナ初となる商業規模の風力発電所です。また、アメリカ東南部においても最初の風力発電所の 1 つで、ノースカロライナのパスクォタンク群とパーキマンス郡にまたがるものです。

Amazon Solar Farm US East – AWS はバージニア州アッコマック郡に Amazon Solar Farm US East を建設するべく、2015 年 6 月に Community Energy と提携しました。この発電所は、年間約 170,000 メガワット時間の太陽エネルギーを発電します。現在、バージニアで 5 つの追加の太陽光発電所を建設中で、2017 年中にはオンラインになる見込みです。

Amazon Wind Farm US Central – 2015 年 11 月に、当社はオハイオ州ポールディング群に 100 メガワットの風力発電所を建設するべく、EDP Renewables と提携しました。この発電所は、年間約 320,000 メガワット時間の風力エネルギーを発電します。これに続き、Amazon Wind Farm US Central 2 (オハイオ) が 2017 年中に稼働する予定です。

これまで、AWS は合計 10 個の再生可能エネルギープロジェクトを発表し、これらの風力および太陽光発電所では、260 万メガワット時間のエネルギーを発電する見込みです。これは年間に米国の 240,000 世帯の電力を賄うために十分なエネルギーです。当社の長期的な目標である 100% の再生可能エネルギーという目標への道のりをフォローするには、ぜひ AWS & Sustainability ウェブページをご覧ください。

Amazon は、AWS グローバルインフラストラクチャへの電力供給に焦点を当てた持続性の取り組みを超えて、全社的にその他のクリーンエネルギー活動についてもいくつか調査中です。その他のプロジェクトには、Amazon Wind Farm Texas (テキサス州スカリー郡の 253MW の風力発電所、グリーンルーフ) や、シアトルの Amazon オフィスの暖房用に再生エネルギーを使用する District Energy Project などがあります。

Amazon の持続性に関する取り組みの詳細については、www.amazon.com/sustainability を参照してください。

SAP HANA on AWSの展開 – どのような選択肢が?

Sabari RadhakrishnanはAmazon Web Services(AWS)のパートナー ソリューション アーキテクトです。

SAPアプリケーションをSAP HANAプラットフォーム上に移行、または新規で構築する予定がありますか?もしそうであれば、AWSがSAP HANAのワークロードを実行するためにどのような選択肢を提供しているか知りたいのでは、と思っています。本ブログ記事では、SAP HANAに必要となる主なインフラストラクチャ・コンポーネントおよびAWS上にSAP HANA仮想アプライアンスを構築するためのビルディング・ブロックについて説明します。本記事により、展開方法について深くご理解いただけると幸いです。本記事は、ブログシリーズとして、SAP on AWSに関する様々な情報を公開する最初の記事ですので、頻繁に確認していただければと思います。

SAP HANA Tailored Data Center Integration (TDI) モデルに準拠している場合、メモリー、コンピュート、ストレージ、そしてネットワークの4つがSAP HANAに必要となる主要なインフラストラクチャ・コンポーネントになります。これらの中で、メモリーがデータサイズに依存する唯一の変数となっています。コンピュート、ストレージ、ネットワーク要件はメモリーサイズから算出されるか、あらかじめ定義されています。例えば、メモリーサイズに基づいたコンピュートに必要なコア数の決定には、SAP社が設定した標準的なコアとメモリー比率の要件があります。ストレージについては、メモリーサイズに関係なく、SAP HANA Hardware Configuration Check Tool (HWCCT) ガイドに記載されているように、異なるブロックサイズやその他のKPIにおける特定のスループット要件を満たす必要があります。 最後にネットワークですが、特にスケールアウト構成において、メモリーサイズに関係なく、SAP HANAのノード間で最小9.5 Gbpsのスループットを実現する必要があります。

ここ数年、AWSはSAP社と密に連携して、AWSプラットフォーム上でSAP HANAのワークロードを実行するためのコンピュートおよびストレージ構成の認証を取得しています。どのように我々はこれを実現したのでしょうか。その答えは、 AWSがAmazon Elastic Compute Cloud (Amazon EC2)のインスタンスを様々なメモリーサイズで設計し、コンピュートのための適切なコアとメモリー比率を含むSAP HANAの厳しい性能要件を満たすことです。加えて、Amazon Elastic Block Store (Amazon EBS)は多くの場合にTDIモデルのストレージKPIを満たしています。そしてEC2インスタンスのネットワーク帯域幅は、スケールアウト構成のノード間通信で必要な9.5 Gbpsを満たしています。

それではこれらのビルディング・ブロックと構成オプションについて詳細をみていきましょう。

メモリーとコンピュート

AWSでは様々なワークロードに対応できるよう、いくつかのEC2インスタンスのタイプをご用意しています。 メモリー最適化のR3とR4インスタンス、そして大容量メモリー最適化のX1インスタンスといったSAP HANAのワークロードに最適な2つのEC2インスタンスのタイプがあります。これらのインスタンスファミリーは、SAP HANAのようなインメモリーワークロード専用に設計されています。このインスタンスタイプとインスタンスファミリーにはSAP HANAのワークロードを実行するための様々なコンピュートオプションがあります。OLAP(online analytical processing)用途、例えばSAP Business Warehouse on HANAやSAP BW/4HANA、データマートなどにおいて、SAP社の完全サポート対象として244GiBから2TBまで垂直方向に、また最大14TBまで水平方向にスケールすることができます。AWSラボでは、最大25ノードの展開、つまり合計50 TBのRAMのテストに成功していることもご認識ください。OLTP(online transaction processing)用途、例えばSAP Business Suite on HANA、SAP S4/HANA、SAP CRMなどにおいては、今日現在で244GiBから2TBまで垂直にスケールすることが可能です。最新のCPU世代でAWSが新しいインスタンスタイプを提供し続けるにあたり、弊社はSAPと密に連携して、それらのインスタンスタイプでもSAP HANAのワークロードのために認証を取得していくつもりです。SAP HANAワークロードの本稼働環境で使用できる認定EC2インスタンスタイプをすべて表示するには、SAP社が認定およびサポートするSAP HANAハードウェアディレクトリーのCertified IaaS Platformsのページを参照してください。特定のインスタンスファミリーでは、非本稼働用途においてr3.2xlargeやr4.2xlargeといった小さいインスタンスサイズを使用することでTCOを削減することもできます。クラウドネイティブなインスタンスにより、SAP HANAのメモリー利用量に合わせて64GiBから2TBに増やすことを、またはその逆に減らすことも、数分でシームレスに変更できる柔軟性があることも覚えておいてください。SAP HANAの導入において、これまでにはない俊敏性がもたらされます。

次の表と図は、これまで説明してきたメモリーとコンピュートの選択肢を整理したものです。

HANA_on_AWS

本稼働ワークロードの選択肢
インスタンスタイプ メモリー (GiB) vCPU SAPS
x1.32xlarge 1,952 128 131,500
x1.16xlarge 976 64 65,750
r4.16xlarge 488 64 76,400
r3.8xlarge 244 32 31,920
非本稼働ワークロードの選択肢
インスタンスタイプ メモリー (GiB) vCPU SAPS
r4.8xlarge 244 32 38,200
r4.4xlarge 122 16 19,100
r4.2xlarge 61 8 9,550
r3.4xlarge 122 16 15,960
r3.2xlarge 61 8 7,980
 — SAP Business One, version for SAP HANAについてはこれ以外のインスタンスとメモリーサイズが利用可能です。このトピックは別のブログを参照してください。

ストレージ

AWSでは、SAP HANAの永続ブロックストレージに複数のオプションを用意しています。性能重視のデータやログボリューム用に2つのSSD-backed EBSボリュームタイプ(gp2io1)があり、またSAP HANAバックアップ用にコスト最適化および高いスループットのHDD-backed EBSボリューム(st1)があります。

  • 汎用SSD (gp2) ボリュームタイプでは、ボリュームあたり最大160MB/sのスループットを実現できます。TDIモデルの要件である最大400MB/sのスループットを達成するためには、SAP HANAのデータとログファイル用に3つのボリュームをストライピングする必要があります。
  • プロビジョンドIOPS SSD (io1) ボリュームでは、ボリュームあたり最大320MB/sのスループットを提供し、スループット要件を満たすには少なくとも2つのボリュームをストライピングする必要があります。
  • スループット最適化HDD (st1) ボリュームでは、大きなブロックサイズでのシーケンシャルな読み書きで最大500MB/sのスループットを実現できます。そのため、st1はSAP HANAバックアップの保存先に理想的な候補となります。

重要な点の1つとして、それぞれのEBSボリュームがAWSのアベイラビリティゾーン内で自動的に複製されることで、障害から保護され、高い可用性と耐久性を提供することがあります。 これにより、性能を最大限に引き出すためにオペレーティングシステムレベルでRAID 0アレイが構成でき、一方でボリュームの保護(RAID 10またはRAID 5)は心配する必要がなくなります。

ネットワーク

SAP HANAのネットワーク性能は、特にスケールアウト構成において重要な要素になります。すべてのEC2インスタンスは一定のネットワーク帯域幅を提供しており、X1のような最新のインスタンスファミリーでは、SAP HANAの要求に合わせて最大20 Gbpsのネットワーク帯域幅を提供します。さらに多くのインスタンスでは、Amazon EBSストレージ接続のための独立したネットワーク帯域幅を持っています。例えば、もっとも大きいX1インスタンス(x1.32xlarge)では、20 Gbpsのネットワーク帯域幅と10 Gbpsの専用ストレージ帯域幅を持ちます。 R4インスタンス(r4.16xlarge)では、20 Gbpsのネットワーク帯域幅と12 Gbpsの専用ストレージ帯域幅を持ちます。 以下はSAP認定インスタンスのネットワーク機能の簡単な概要になります。

本稼働ワークロードの選択肢
インスタンスタイプ ネットワーク帯域幅 (Gbps) EBS専用の帯域幅 (Gbps)
x1.32xlarge 20 10
x1.16xlarge 10 5
r4.16xlarge 20 12
r3.8xlarge 10*

* ネットワークとストレージのトラフィックは同じ10 Gbps ネットワークインターフェイスを共有

オペレーティングシステム(OS)

SAP社では、SUSE Linux Enterprise Server(SLES) またはRed Hat Enterprise Linux(RHEL)上でのSAP HANAの実行をサポートしています。どちらのOSディストリビューションもAWS上でサポートされます。さらに、お客様はAWS Marketplaceで提供されるSUSEまたはレッドハットのSAP HANA固有イメージを使って容易に開始することができます。また、お客様自身のOSサブスクリプションを持ち込むことも可能です。SAP HANA on AWSのOSに関する選択肢の詳細については、今後のブログ記事をご期待ください。

すべてをまとめて構築

“AWSがTDI同様にSAP HANAのビルディング・ブロックを提供するのは素晴らしいことですが、AWS上でこれらのコンポーネントをまとめてSAPの要件を満たすシステムを構築するにはどうすればよいですか?”と思うかもしれません。AWSのお客様からも数年前にこの質問を受けており、AWS Quick Start for SAP HANAを開発しました。 このクイックスタートでは、AWS CloudFormationテンプレート(Infrastructure as Code)とカスタムスクリプトを利用して、ストレージやネットワークを含むAWSインフラストラクチャ・コンポーネントの展開を支援します。クイックスタートは、SAP HANAインストールに必要となるオペレーティングシステムの設定も行います。また、お客様自身のSAP HANAソフトウェアとライセンスを持ち込むことで、SAP HANAソフトウェアのインストールもできます。クイックスタートは、世界中の多くのAWSリージョンで使用できるセルフサービスのツールです。SAP HANAシステムのインフラストラクチャの展開は、シングルノードであるかスケールアウトシステムであるかに関係なく、一貫して予測可能で繰り返し可能な方法で、1時間未満で提供されます。SAP HANAクイックスタートの実行は、AWS re:Invent 2016 カンファレンスにてSAP社との共同講演で実演した録画されたデモをご覧ください。

SAP HANAの構築には、AWSクイックスタートを利用したインフラストラクチャの展開を強く推奨します。ただし、クイックスタートを使用できない場合(たとえば、独自のOSイメージを使用する場合など)には、SAP HANA環境を手動で構築し、ビルディング・ブロックを自分で配置することができます。ストレージとインスタンスタイプについては必ずrecommendations in the Quick Start guideに従ってください。この特定の目的のために、SAP HANA on AWS – Manual Deployment Guideでステップ・バイ・ステップの手順も提供しています。(RHELを含む最新OSバージョンの手順を含む本ガイドはすぐに更新される予定です。)

バックアップとリカバリー

信頼性の高い方法でSAP HANAデータベースをバックアップおよびリストアする機能は、ビジネスデータを保護する上で非常に重要です。SAP HANA純正のツールを使用してデータベースをEBSボリュームにバックアップし、最終的にバックアップされたファイルをAmazon Simple Storage Service (Amazon S3)に移行することで、耐久性を高めることができます。Amazon S3は、スケーラビリティと耐久性に優れたオブジェクトストレージのサービスです。Amazon S3のオブジェクトは、リージョン内の複数の施設に重複して格納され、99.999999999の耐久性を実現します。Commvault、EMC NetWorker、Veritas NetBackup、IBM Spectrum Protect(Tivoli Storage Manager)などのエンタープライズクラスのバックアップソリューションを選択することもできます。これらのソリューションは、Amazon S3およびSAP HANA Backintインタフェースと統合されています。これらのパートナーソリューションは、SAP HANAデータベースをAmazon S3に直接バックアップし、エンタープライズクラスのソフトウェアを使用したバックアップ・リカバリーの管理に役立ちます。

高可用性(HA)と災害対策(DR)

HAとDRは、SAP HANA上で実行されるビジネスクリティカルなアプリケーションにとって重要です。AWSは、アップタイムとリカバリーの要件(RTO / RPO)に応じたHAとDRソリューションを構成できるよう、世界中の複数のAWSリージョンと各AWSリージョン内の複数のアベイラビリティゾーンを含むいくつかのビルディング・ブロックを提供しています。コスト最適化ソリューションまたはダウンタイム最適化ソリューションのどちらを探している場合でも、SAP HANA HA/DRアーキテクチャにいくつかの独自オプションを用意しています — これらの詳細については、SAP HANA HA/DR guideを参照してください。今後のブログ記事でこのトピックについて詳しく説明する予定です。

移行

実際の移行には、SAP標準のツールセットとして提供されるSAP Software Provisioning Manager(SWPM)やDatabase Migration Option(DMO) of the Software Update Manager(SUM)、または3rdパーティーの移行ツールを使って、任意のデータベースで実行されているSAPアプリケーションをSAP HANA on AWSに移行できます。 SAPのAWSへの移行プロセスは、一般的なオンプレミスの移行シナリオとほぼ変わりません。オンプレミスのシナリオでは、通常、同じデータセンター内にソースシステムとターゲットシステムが存在します。AWSに移行する場合の唯一の違いは、ターゲットシステムがAWS上に存在することです。そのため、AWSを自社のデータセンターの拡張と考えることができます。また、移行中に、オンプレミスのデータセンターでエクスポートされたデータをAWSに転送するための様々なオプションもあります。これらの選択肢の理解をより深めるために、Migrating SAP HANA Systems to X1 Instances on AWSを参照することをお勧めします。

その他の検討事項として、運用、サイジング、スケーリング、Amazon CloudWatchのようなAWSサービスとの統合、ビッグデータソリューションなどがあります。これらは今後のブログ記事で詳細を取り上げる予定です。それまでの間に、AWS Quick Start for SAP HANAを使ってSAP HANA on AWSを開始してみてはいかがでしょうか。AWS上で実行されるSAPワークロードの詳細については、SAP on AWS websiteのホワイトペーパーもご覧ください。

最後に、現在利用可能なシステムサイズを超えて拡張するシステムが必要な場合は、当社までご連絡ください。 私たちはお客様の要件について話し合い、その実装に関してご協力いただけることを嬉しく思います。

– Sabari

翻訳はPartner SA 河原が担当しました。原文はこちらです。

タスクIAMロールとパラメータストアを利用したAmazon ECSアプリケーションの秘密情報管理

同僚のStas Vonholskyが、Amazon ECSアプリケーションの秘密情報管理に関する素晴らしいブログを寄稿してくれました。

—–

コンテナ化されたアプリケーションとマイクロサービス指向のアーキテクチャが普及するにつれて、アプリケーションデータベースにアクセスするためのパスワードなどの秘密情報を管理することは、より困難かつ重要になっています。

いくつか課題の例を挙げます:

  • dev、test、prodなどのさまざまなアクセスパターンをコンテナ環境全体でサポートしたい
  • ホストレベルではなくコンテナ/アプリケーションレベルで秘密情報へのアクセスを隔離したい
  • サービスとしても、他サービスのクライアントとしても、アクセスが必要である疎結合なサービスが複数存在する

この記事では、Amazon ECS上で動作するコンテナアプリケーションの秘密情報管理をサポートする、新しくリリースされた機能に焦点を当てています。同僚のMatthew McCleanもAWSセキュリティブログに、S3とDockerを使用してECSベースのアプリケーションの秘密情報を管理する方法についての素晴らしい記事を公開しています。この記事では、コンテナパラメータ変数を使って秘密情報を受け渡し/保存する際の制限について説明しています。

多くの秘密情報管理ツールは、次のような機能を提供しています。

  • 高セキュアなストレージシステム
  • 集中管理機能
  • セキュアな認証と認証メカニズム
  • 鍵管理および暗号化プロバイダとの統合
  • アクセスのための安全な導入メカニズム
  • 監査
  • 秘密情報のローテーションと失効

Amazon EC2 Systems Manager パラメータストア

パラメータストアは、Amazon EC2 Systems Managerの1機能です。秘密情報のための集中化/暗号化されたデータストアを提供し、Run CommandやステートマネージャーなどのSystems Managerの他の機能と組み合わせることで多くの利点をもたらします。このサービスはフルマネージドで、高い可用性・セキュリティを持っています。

System Manager API、AWS CLI、およびAWS SDKを使用してパラメータストアにアクセスできるため、汎用の秘密情報管理ストアとして使用することができます。秘密情報は簡単にローテートしたり取り消したりすることができます。パラメータストアはAWS Key Management Service (KMS)と統合されているため、デフォルトまたはカスタムのKMSキーを使用して特定のパラメータを暗号化できます。 KMSキーをインポートすることで、独自のキーを使用して機密データを暗号化することも可能です。

パラメータストアへのアクセスはIAMポリシーによって実現にされ、リソースレベルのアクセス許可をサポートします。特定のパラメータまたは名前空間にアクセス権を持つIAMポリシーを使用して、これらのパラメータへのアクセスを制限することができます。 CloudTrailログを有効にすると、パラメータへのアクセスを記録することも可能です。

Amazon S3も上記の機能の多くを持つので、集約秘密情報ストアの実装にも使用できますが、パラメータストアにはさらに次のような利点があります。

  • アプリケーションライフサイクルのさまざまなステージをサポートするためのネームスペースを簡単に作成できる
  • インスタンスまたはコンテナからKMSキーにアクセスし、ローカルメモリ内で復号化を実行することで、アプリケーションからパラメータの暗号化を抽象化するKMS統合機能を提供する
  • パラメータの変更履歴を保管できる
  • 他の多くのアプリケーションで使用されるS3とは別に制御できる
  • 複数システムを実装する際のオーバーヘッドを削減する構成情報ストアとなる
  • 使用料がかからない

注:本記事の公開時点では、Systems ManagerはVPCプライベートエンドポイント機能をサポートしていません。プライベートVPCからのパラメータストアエンドポイントへのより厳密なアクセスを強制するには、限られたIPアドレスセットからのみにアクセスを制限するIAMポリシーConditionとともに、Elastic IPアドレスを持つNATゲートウェイを使用します。

タスクIAMロール

Amazon ECSタスク用のIAMロールを使用すると、タスク内のコンテナが使用するIAMロールを指定することができます。 AWSサービスと対話するアプリケーションは、AWSクレデンシャルでAPIリクエストに署名する必要があります。ECSタスクIAMロールは、Amazon EC2インスタンスプロファイルがEC2インスタンスにクレデンシャルを提供するのと同じように、コンテナアプリケーションのクレデンシャルを管理する方法を提供します。

AWSクレデンシャルを作成してコンテナに配布したり、EC2インスタンスロールを使用する代わりに、IAMロールをECSタスク定義またはRunTask API操作に関連付けることができます。詳細については、IAM Roles for Tasksを参照してください。

タスク用のIAMロールを利用することで、集約パラメータストアを使用してアプリケーションまたはコンテナを安全に導入および認証することができます。秘密情報管理機能へのアクセスには、次のような機能が含まれている必要があります。

  • 使用されたクレデンシャルのTTL制限
  • きめ細やかな認可ポリシー
  • リクエストを追跡するためのIDのログ保存
  • デプロイされたコンテナまたはタスクと関連するアクセス権との間をマッピングできるスケジューラの統合サポート

タスクIAMロールは、ロールが定義されているコンテナ内からのみロールクレデンシャルにアクセスできるため、これらのユースケースをうまくサポートします。このロールは一時的なクレデンシャルを提供し、これらは自動的にローテーションされます。IAMポリシーは、送信元インスタンス、送信元IPアドレス、時刻などのオプション条件をサポートされています。

ソースとなるIAMロールは、一意のAmazonリソースネームに基いてCloudTrailログで識別でき、アクセス許可はいつでもIAM APIまたはコンソールで取り消すことができます。パラメータストアはリソースレベルの権限をサポートするため、特定のキーと名前空間へのアクセスを制限するポリシーを作成できます。

動的な環境の関連付け

多くの場合、環境を移動する際にもコンテナイメージは変更されず、イミュータブルなデプロイメントと結果再現性を保証します。変更されうるものは構成情報、この文脈では具体的には秘密情報です。たとえば、データベースとそのパスワードは、ステージング環境と本番環境で異なる場合があります。正しい秘密情報を取得するためにどのようにアプリケーションを指定すればよいでしょうか?

1つのオプションは、環境変数として環境タイプをコンテナに渡すことです。次に、アプリケーションは環境タイプ(prod、testなど)を相対キーパスに連結し、関連する秘密情報を取得します。ほとんどの場合、この方法では多数の独立したECSタスク定義が生まれてしまいます。

IAMロールは、“environment type”などの単一のCloudFormationパラメータで、パラメータストア、KMSキーおよび環境プロパティへのアクセスを提供します。

このアプローチを利用することで、一般的なCloudFormationテンプレートに基づいた単一のタスク定義をサポートすることができます。

ウォークスルー:タスクIAMロールを使用してパラメータストアリソースに安全にアクセスする

このウォークスルーはNorth Virginiaリージョン(us-east-1)向けに構成されています。同じリージョンを使って試すことをお勧めします。

Step 1: KMSキーとパラメータを作成する

最初に、既定のセキュリティポリシーを使用して、いくつかのパラメータを暗号化するためのKMSキーを作成します。

  • prod-app1  –  app1の秘密情報を暗号化するために使用されます
  • license-key  – ライセンス関連の秘密情報を暗号化するために使用されます
aws kms create-key --description prod-app1 --region us-east-1
aws kms create-key --description license-code --region us-east-1

両方のコマンドの出力のKeyIdプロパティを確認してください。ウォークスルー全体でKMSキーを識別するために使用します。

次のコマンドで、パラメータストアに3つのパラメータを作成します。

  • prod.app1.db-pass(prod-app1 KMSキーで暗号化)
  • general.license-code(license-key KMSキーで暗号化)
  • prod.app2.user-name(暗号化されていない標準文字列として保存)
aws ssm put-parameter --name prod.app1.db-pass --value "AAAAAAAAAAA" --type SecureString --key-id "<key-id-for-prod-app1-key>" --region us-east-1
aws ssm put-parameter --name general.license-code --value "CCCCCCCCCCC" --type SecureString --key-id "<key-id-for-license-code-key>" --region us-east-1
aws ssm put-parameter --name prod.app2.user-name --value "BBBBBBBBBBB" --type String --region us-east-1

Step 2: IAMロールとポリシーを作成する

ここで、後で作成するECSタスクと関連付けるロールとIAMポリシーを作成します。

IAMロールの信頼ポリシーは、ecs-tasksエンティティがロールを引き受けることを許可する必要があります。

{
   "Version": "2012-10-17",
   "Statement": [
     {
       "Sid": "",
       "Effect": "Allow",
       "Principal": {
         "Service": "ecs-tasks.amazonaws.com"
       },
       "Action": "sts:AssumeRole"
     }
   ]
 }

上記のポリシーを、ecs-tasks-trust-policy.jsonという名前のファイルとしてローカルディレクトリに保存します。

aws iam create-role --role-name prod-app1 --assume-role-policy-document file://ecs-tasks-trust-policy.json

次のポリシーはロールにアタッチされ、後でapp1コンテナに関連付けられます。 prod.app1.*という名前空間パラメータおよびライセンスコードパラメータへのアクセスと、prod.app1.db-passパラメータを復号化するために必要な暗号化キーへのアクセスが許可されています。名前空間リソースのパーミッション構造は、さまざまな階層を構築するのに便利です(環境、アプリケーションなどに基づいています)。

次のポリシーの<key-id-for-prod-app1-key>を関連するKMSキーのキーIDに、<account-id>をあなたのアカウントIDに置き換えてください。

{
     "Version": "2012-10-17",
     "Statement": [
         {
             "Effect": "Allow",
             "Action": [
                 "ssm:DescribeParameters"
             ],
             "Resource": "*"
         },
         {
             "Sid": "Stmt1482841904000",
             "Effect": "Allow",
             "Action": [
                 "ssm:GetParameters"
             ],
             "Resource": [
                 "arn:aws:ssm:us-east-1:<account-id>:parameter/prod.app1.*",
                 "arn:aws:ssm:us-east-1:<account-id>:parameter/general.license-code"
             ]
         },
         {
             "Sid": "Stmt1482841948000",
             "Effect": "Allow",
             "Action": [
                 "kms:Decrypt"
             ],
             "Resource": [
                 "arn:aws:kms:us-east-1:<account-id>:key/<key-id-for-prod-app1-key>"
             ]
         }
     ]
 }

上記のポリシーを、app1-secret-access.jsonという名前のファイルとしてローカルディレクトリに保存します。

aws iam create-policy --policy-name prod-app1 --policy-document file://app1-secret-access.json

次のコマンドの<account-id>はあなたのアカウントIDに置き換えてください:

aws iam attach-role-policy --role-name prod-app1 --policy-arn "arn:aws:iam::<account-id>:policy/prod-app1"

Step 3:S3バケットにテストスクリプトを追加する

以下のスクリプトファイルを作成し、access-test.shという名前をつけてアカウントのS3バケットに追加します。オブジェクトがパブリックアクセス可能であることを確認し、オブジェクトリンクを書き留めておいてください。

例えば、https://s3-eu-west-1.amazonaws.com/my-new-blog-bucket/access-test.shのようになります。

#!/bin/bash
#This is simple bash script that is used to test access to the EC2 Parameter store.
# Install the AWS CLI
apt-get -y install python2.7 curl
curl -O https://bootstrap.pypa.io/get-pip.py
python2.7 get-pip.py
pip install awscli
# Getting region
EC2_AVAIL_ZONE=`curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone`
EC2_REGION="`echo \"$EC2_AVAIL_ZONE\" | sed -e 's:\([0-9][0-9]*\)[a-z]*\$:\\1:'`"
# Trying to retrieve parameters from the EC2 Parameter Store
APP1_WITH_ENCRYPTION=`aws ssm get-parameters --names prod.app1.db-pass --with-decryption --region $EC2_REGION --output text 2>&1`
APP1_WITHOUT_ENCRYPTION=`aws ssm get-parameters --names prod.app1.db-pass --no-with-decryption --region $EC2_REGION --output text 2>&1`
LICENSE_WITH_ENCRYPTION=`aws ssm get-parameters --names general.license-code --with-decryption --region $EC2_REGION --output text 2>&1`
LICENSE_WITHOUT_ENCRYPTION=`aws ssm get-parameters --names general.license-code --no-with-decryption --region $EC2_REGION --output text 2>&1`
APP2_WITHOUT_ENCRYPTION=`aws ssm get-parameters --names prod.app2.user-name --no-with-decryption --region $EC2_REGION --output text 2>&1`
# The nginx server is started after the script is invoked, preparing folder for HTML.
if [ ! -d /usr/share/nginx/html/ ]; then
mkdir -p /usr/share/nginx/html/;
fi
chmod 755 /usr/share/nginx/html/
# Creating an HTML file to be accessed at http://<public-instance-DNS-name>/ecs.html
cat > /usr/share/nginx/html/ecs.html <<EOF
<!DOCTYPE html>
<html>
<head>
<title>App1</title>
<style>
body {padding: 20px;margin: 0 auto;font-family: Tahoma, Verdana, Arial, sans-serif;}
code {white-space: pre-wrap;}
result {background: hsl(220, 80%, 90%);}
</style>
</head>
<body>
<h1>Hi there!</h1>
<p style="padding-bottom: 0.8cm;">Following are the results of different access attempts as expirienced by "App1".</p>
<p><b>Access to prod.app1.db-pass:</b><br/>
<pre><code>aws ssm get-parameters --names prod.app1.db-pass --with-decryption</code><br/>
<code><result>$APP1_WITH_ENCRYPTION</result></code><br/>
<code>aws ssm get-parameters --names prod.app1.db-pass --no-with-decryption</code><br/>
<code><result>$APP1_WITHOUT_ENCRYPTION</result></code></pre><br/>
</p>
<p><b>Access to general.license-code:</b><br/>
<pre><code>aws ssm get-parameters --names general.license-code --with-decryption</code><br/>
<code><result>$LICENSE_WITH_ENCRYPTION</result></code><br/>
<code>aws ssm get-parameters --names general.license-code --no-with-decryption</code><br/>
<code><result>$LICENSE_WITHOUT_ENCRYPTION</result></code></pre><br/>
</p>
<p><b>Access to prod.app2.user-name:</b><br/>
<pre><code>aws ssm get-parameters --names prod.app2.user-name --no-with-decryption</code><br/>
<code><result>$APP2_WITHOUT_ENCRYPTION</result></code><br/>
</p>
<p><em>Thanks for visiting</em></p>
</body>
</html>
EOF

Step 4:テストクラスタを作成する

最新のECS AMIとECSエージェントを持つ新しいECSテストクラスタを作成することをお勧めします。次のフィールド値を使用します。

  • クラスタ名:access-test
  • EC2インスタンスタイプ:t2.micro
  • インスタンス数:1
  • キーペア:インスタンスにSSHして実行中のコンテナを操作したい場合を除き、EC2キーペアは必要ありません。
  • VPC:デフォルトVPCを選択します。わからない場合は、Amazon VPCコンソールで172.31.0.0/16のIPレンジのVPCのIDを探してください。
  • サブネット:デフォルトVPC内のサブネットを選択します。
  • セキュリティグループ:CIDRブロック0.0.0.0/0からのポート80のインバウンドアクセス用の新しいセキュリティグループを作成します。

他のフィールドはデフォルト設定のままにします。

パブリックNGINXコンテナとapp1用に作成したロールに依存するシンプルなタスク定義を作成します。利用可能なコンテナリソースやポートマッピングなどのプロパティを指定します。commandオプションは、コンテナにテストスクリプトのダウンロードおよび実行に利用されます。このテストスクリプトはAWS CLIをコンテナにインストールし、いくつかのget-parameterコマンドを実行し、結果を含むHTMLファイルを作成します。

次のコマンドの<account-id>はアカウントIDに、<your-S3-URI>はStep 3で作成したS3オブジェクトのリンクに置き換えてください。

aws ecs register-task-definition --family access-test --task-role-arn "arn:aws:iam::<account-id>:role/prod-app1" --container-definitions name="access-test",image="nginx",portMappings="[{containerPort=80,hostPort=80,protocol=tcp}]",readonlyRootFilesystem=false,cpu=512,memory=490,essential=true,entryPoint="sh,-c",command="\"/bin/sh -c \\\"apt-get update ; apt-get -y install curl ; curl -O <your-S3-URI> ; chmod +x access-test.sh ; ./access-test.sh ; nginx -g 'daemon off;'\\\"\"" --region us-east-1
aws ecs run-task --cluster access-test --task-definition access-test --count 1 --region us-east-1

アクセスの確認

タスクが実行状態になったら、インスタンスのパブリックDNS名を確認し、次のページに移動します。

http://<ec2-instance-public-DNS-name>/ecs.html

コンテナからアクセステストを実行した結果が表示されます。

テスト結果がすぐに表示されない場合は、数秒待ってからページを更新してください。

ポート80のインバウンドトラフィックがインスタンスにアタッチされたセキュリティグループで許可されていることを確認してください。

静的HTMLページに表示される結果は、コンテナから次のコマンドを実行する場合と同じものになります。

prod.app1.key1

aws ssm get-parameters --names prod.app1.db-pass --with-decryption --region us-east-1
aws ssm get-parameters --names prod.app1.db-pass --no-with-decryption --region us-east-1

必要なKMSキーとパラメータにアクセスできるポリシーがあるため、この2つのコマンドはどちらも実行可能なはずです。

general.license-code

aws ssm get-parameters --names general.license-code --no-with-decryption --region us-east-1
aws ssm get-parameters --names general.license-code --with-decryption --region us-east-1

“no-with-decryption”パラメータを持つ最初のコマンドだけが動作するはずです。指定したポリシーでは、パラメータストアのパラメータへのアクセスは許可されていますが、KMSキーへのアクセスは許可されていません。 2番目のコマンドは、アクセス拒否エラーで失敗するはずです。

prod.app2.user-name

aws ssm get-parameters --names prod.app2.user-name –no-with-decryption --region us-east-1

prod.app2の名前空間に関連付けられている権限がないため、このコマンドはアクセス拒否エラーで失敗するはずです。

仕上げ

料金が発生しないように、すべてのリソース(KMSキーやEC2インスタンスなど)を削除することを忘れないでください。

まとめ

集約秘密情報管理は、コンテナ化された環境のセキュリティにとって重要な機能です。

ユーザーは、パラメータストアとタスクIAMロールを使用することで、アプリケーションが必要なキーのみにアクセスすることができるKMSキーと統合されたアクセスレイヤーおよび集約秘密情報ストアを構築することができます。

秘密情報管理レイヤはパラメータストア、Amazon S3、Amazon DynamoDB、またはVaultやKeyWhizなど、どんなソリューションで実装されている場合でも、秘密情報の管理・アクセスのプロセスに不可欠なものです。

(翻訳はSA千葉が担当しました。原文はこちらです。)