Author: AWS Japan Staff


新機能 – AWS OpsWorks for Chef Automate

AWS OpsWorks は、Chef を使用したアプリケーションの設定と実行に役立ちます。ドメイン固有言語 (DSL) を使って、アプリケーションのアーキテクチャと各コンポーネントの設定を定義するクックブックを記述します。Chef サーバーは、設定プロセスで不可欠な要素です。このサーバーはすべてのクックブックを保存し、各インスタンス (Chef の用語ではノード) の状態情報を追跡します。Chef サーバーは新しく起動されたインスタンスが設定されるときは重要なパスにあるため、信頼性が高い必要があります。多くの OpsWorks および Chef ユーザーは、この重要なアーキテクチャコンポーネントを自分でインストールして維持しています。本稼働スケールの環境では、これによりバックアップ、復元、バージョンのアップグレードなどをユーザーが処理する必要があります。

新しい AWS OpsWorks for Chef Automate
今月初めに、AWS OpsWorks for Chef AutomateAWS re:Invent ステージから開始されました。Chef Automate サーバーは、わずか 3 回のクリックで起動し、数分以内に使用を開始することができます。Chef Supermarket をはじめ、Test KitchenKnife などのコミュニティツールからのコミュニティクックブックを使用できます。Chef Automate を使用すると、アプリケーションのインフラストラクチャのライフサイクルを通じてインフラストラクチャを管理できます。たとえば、新しく起動した EC2 インスタンスは自動的に Chef サーバーに接続し、自動関連付けスクリプトを使用して、指定されたレシピを実行できます (詳細については、「AWS OpsWorks for Chef Automate でのノードの自動的な追加」を参照)。登録スクリプトを使用して、Auto Scaling グループを通じて動的に作成された EC2 インスタンスを登録し、オンプレミスサーバーを登録できます。

詳しく見る
OpsWorks コンソールから Chef Automate サーバーを起動してみましょう。開始するには、[Go to OpsWorks for Chef Automate] をクリックします。

[Create Chef Automate server] をクリックし、サーバーに名前を付けます。次にリージョンを選択し、適切な EC2 インスタンスタイプを選択します。

SSH キーペアの 1 つを選択するか、SSH からオプトアウトします。

最後に、ネットワーク (VPC)、IAM、メンテナンスウィンドウ、およびバックアップの設定を指定します。

[Next] をクリックし、設定を確認して、[Launch] をクリックします。起動プロセスにかかる時間は 20 分未満です。その時間中に、スターターキットとともに Chef Automate ダッシュボードのサインイン認証情報をダウンロードできます。

すべての Chef Automate サーバーを一目で表示できます。

サーバー名 (ここでは BorkBorkBork) をクリックし、[Open Chef Automate dashboard] をクリックします。次に、認証情報を入力してログインします。

ダッシュボードを次に示します。

ノードを表示して管理できます。

ワークフローを管理する

ほかにもさまざまな機能があります。バックグラウンドでは、起動プロセスによって AWS CloudFormation テンプレートが呼び出されます。このテンプレートにより、EC2 インスタンス、Elastic IP アドレス、およびセキュリティグループが作成されます。

今すぐご利用可能
AWS OpsWorks for Chef Automate は、US East (Northern Virginia)US West (Oregon)、および Europe (Ireland) リージョンで今すぐご利用できます。料金はサーバーに接続されたノードの数と時間数に基づきます。詳細については、Chef Automate の料金表ページを参照してください。AWS Free Tier の一部として、12 か月当たり最大 10 ノードまでは無料で使用できます。

Jeff;

毎日集計される料金表の通知 ~ AWS料金表API

昨年、AWS のお客様とパートナーから、AWS のサービスの料金を取得するためのシステム的な方法を求める要望が寄せられました。このニーズに対して、昨年 12 月に 13 の AWS のサービスの料金を対象とした AWS の料金表 API を発表しました。この API は、ダウンロード用に JSON および CSV 形式で料金表データを提供し、お客様は AWS のサービスの料金を問い合わせることができます。料金表 API では、Amazon SNS 通知を通じて料金変更の更新情報を受け取ることもできます。

AWS 料金表の API の拡張
過去 3 か月に、当社は AWS の料金表 API サービスを拡張し、すべての AWS のサービスについて料金表データを提供するようにしました。クラウドベースのソリューションの構築またはクラウドへのオンプレミスワークロードの移行に関するコスト分析を行っているお客様は、AWS のサービスの包括的な料金表にこれまでよりも簡単にアクセスできます。これにより、お客様とパートナーは、クラウドソリューションの予算、予測、および計画をより詳細に管理できます。AWS の料金表 API の拡張に加えて、お客様はサインアップして割引料金、新しいサービスやインスタンスタイプの通知を受け取ることができます。通知の受信のサブスクライブの際は、更新情報を受け取るタイミングをカスタマイズでき、1 日 1 回、または料金の更新が発生するたびに設定できます。1 日 1 回の通知を選択した場合、SNS 通知にはその日に適用されたすべての料金変更が含まれます。料金表 API にサブスクライブした場合に受け取る E メール通知のサンプルを次に示します。

料金表 API の使い方を簡単に見てみましょう。最初に、料金表 API を介して料金情報にアクセスし、オファーインデックスファイルとオファーファイルという 2 種類のファイルをダウンロードします。オファーインデックスファイルは JSON ファイルとして利用でき、サポートされている AWS のサービスと、関連するサービスオファーファイルの URL が記載されています。このオファーファイルでは、単一の AWS のサービスに関する製品や料金が一覧表示され、CSV または JSON ファイル形式として利用できます。両方とも単純なダウンロードリンクを介してアクセスでき、簡単な方法で料金表データファイルを入手できます。

今すぐ料金表 API の使用を開始し、いずれの AWS のサービスについても、料金表データを入手できます。AWS の料金表 API の拡張によりすべての AWS のサービスが対象になったことで、料金表 API へのサブスクライブにより、最新の AWS の割引料金の情報を受け取るとともに、新しいサービスの紹介を受けることができます。

AWS の料金表 API の詳細、および API 通知へのサブスクライブ方法の詳細については、サービスについて紹介している前の AWS ブログ投稿、および AWS の料金表 API の使用に関するドキュメントを参照してください。

– Tara

事前にご確認ください – AWSにおける2016年12月31日(日本時間2017年1月1日)のうるう秒

2016年末最後の数秒をカウントダウンする場合は、最後に1秒を追加するのを忘れないようにしてください!

次回のうるう秒(通算27回目)が、UTC(世界標準時)の2016年12月31日 23:59:60として挿入されます(訳注:日本標準時では2017年1月1日 8:59:60になります)。これは地球上での時刻(協定世界時)と太陽時(天文時)とのずれを小さくするために行われ、この結果、UTCでは今年最後の1分は61秒あることになります。

前回のうるう秒の際に出した情報(事前にご確認ください – AWSでのうるう秒対応)は引き続き有効で、今回も同様に処理されますが、少しの違いと進展があります:

AWS調整時刻(AWS Adjusted Time) –うるう秒挿入前後の24時間の期間にわたって、うるう秒の1秒を少しずつ分散します(UTCで12月31日の11:59:59から、2017年1月1日12:00:00まで)。AWS調整時刻と協定世界時はこの期間が終了後に同期します。(訳注:この期間の1秒をごくわずかに遅くすることで、追加される1秒を長い時間のなかに分散する方法であり、これは前回うるう秒挿入時と同じ挙動です。詳しくは前回の情報をご確認ください。)

Microsoft Windows – Amazonによって提供されたMicrosoft WindowsのAMIを利用しているインスタンスは、AWS調整時刻に従います。

Amazon RDS – 大多数のAmazon RDS インスタンスは (UTCで設定されている場合)“23:59:59” を2回記録します。しかし、Oracle 11.2.0.2、11.2.0.3、12.1.0.1 はAWS調整時刻に従います。Oracle 11.2.0.4と12.1.0.2について詳細な情報が必要な場合はAWSサポートにお問い合わせください。

サポートが必要ですか?
このうるう秒挿入についてご質問がある場合は、AWSサポートにコンタクトいただくか、EC2フォーラムにポストしてください。

Jeff;

翻訳:下佐粉 昭(@simosako

原文:https://aws.amazon.com/blogs/aws/look-before-you-leap-december-31-2016-leap-second-on-aws/

EC2 Systems Manager – EC2 およびオンプレミスのシステムの設定と管理

去年、EC2 Run Command をご紹介して、最初に EC2 インスタンスで、次いでハイブリッドおよびクラウド間の環境で大規模なリモートのインスタンス管理をするための使い方をご説明しました。その過程で、Linux インスタンスのサポートを追加したため、EC2 Run Command は幅広く応用できる非常に便利な管理ツールになりました。

ファミリーへようこそ
WernerEC2 Systems ManagerAWS re:Invent で発表したので、ついにお話しできるようになりました。これは、同じように便利な 8 つの機能と共に EC2 Run Command の強化版を含む新しい管理サービスです。EC2 Run Command と同様に、Windows と Linux を実行するインスタンスとサービスで構成されたハイブリッドおよびクラウド間の環境をサポートします。AWS Management Console を開き、管理するインスタンスを選択して、実施するタスクを定義します (API および CLI のアクセスも可能)。機能拡張と新機能の概要を次に示します。

Run Command – コマンドの実行速度を制御し、エラー率が高くなりすぎたときにコマンドの発行を停止できるようになりました。
State Manager – 定期的に適用される、ポリシーで定義されたシステム設定を維持します。
パラメーターストア – ライセンスキー、パスワード、ユーザーリスト、その他の値の一元管理型 (オプションで暗号化された) ストレージを提供します。
メンテナンス時間 – 更新のインストール、その他のシステムメンテナンスの時間枠を指定します。
ソフトウェアインベントリ – 各インスタンスから、詳細なソフトウェアおよび設定のインベントリ (ユーザー定義の追加を含む) を収集します。
AWS Config 統合 – 新しいソフトウェアインベントリ機能との組み合わせで、AWS Config は、ソフトウェアインベントリの変更をインスタンスに記録できます。
パッチ管理 – インスタンスのパッチ適用プロセスを簡略化および自動化します。
自動化 – AMI の構築およびその他の継続的な AMI に関連するタスクを簡略化します。それぞれについて見てみましょう。

Run Command の改善
同時コマンドの実行回数を制御できるようになりました。これは、コマンドリファレンスが内部更新やパッチサーバーのような共有の限定リソースであり、多すぎるリクエストによるオーバーロードを避けたい場合、役立ちます。この機能は現在 CLI および API からアクセスできます。同時実行数を 2 に制限する CLI の例を示します。

$ aws ssm send-command \
  --instance-ids "i-023c301591e6651ea" "i-03cf0fc05ec82a30b" "i-09e4ed09e540caca0" "i-0f6d1fe27dc064099" \
  --document-name "AWS-RunShellScript" \
  --comment "Run a shell script or specify the commands to run." \
  --parameters commands="date" \
  --timeout-seconds 600 --output-s3-bucket-name "jbarr-data" \
  --region us-east-1 --max-concurrency 2

タグやタグ値によるさらに興味深い形式があります。 --targets を次の代わりに指定 --instance-ids:

$ aws ssm send-command \
  --targets "Key=tag:Mode,Values=Production" ... 

オプションでエラーの上限や失敗率を指定して、エラーが返ってくる場合にコマンドの発行を停止することもできます。

$ aws ssm send-command --max-errors 5 ... 
$ aws ssm send-command --max-errors 5% ...

 

State Manager
State Manager は、インスタンスをドキュメントにより定義されたとおりの定義済みの状態に保つのに役立ちます。ドキュメントを作成し、それをターゲットインスタンスのセットに関連付けてから、ドキュメントが適用されるタイミングと頻度を指定する関連付けを作成します。Message of the Day ファイルを更新するドキュメントを示します。

そして、これが関連付けです (現在のインスタンス、および後で起動され、同じようにタグ付けされる他のインスタンスに適用されるようタグを使用)。

タグを使用してターゲットを指定することにより、将来も関連付けに十分対応できるようになり、動的なオートスケールの環境で期待どおりに機能するようになります。関連付けをすべて表示することが可能です。また、新しい関連付けを選択し、[Apply Association Now] をクリックすることにより新しい関連付けを実行することができます。

 

パラメーターストア
この機能はインスタンスに分散するライセンスキー、パスワード、その他のデータのストレージと管理を簡略化します。各パラメータには型 (文字列、文字列リスト、安全な文字列) があり、暗号化された形式で格納できます。パラメータの作成方法を示します。

そして、次がコマンドでのパラメータの参照方法です。

 

メンテナンス時間
この機能により、更新のインストールおよび他のシステムメンテナンスの時間枠の指定ができます。毎週土曜日 4 時間の時間枠を設ける方法は次の通りです。

時間枠を作成してから、インスタンスのセットを割り当てる必要があります。インスタンス ID またはタグを使用して行うことができます。

次にメンテナンスの時間帯に実行するタスクを登録する必要があります。たとえば、Linux シェルスクリプトを実行できます。

 

ソフトウェアインベントリ
この機能は一連のインスタンスのソフトウェアおよび設定についての情報を収集します。アクセスするには、[Managed Instances]、[Setup Inventory] をクリックします。

インベントリのセットアップは、AWS が所有するドキュメントとインスタンスのセットとの間に関連付けを作成します。 ターゲットを選択し、スケジュールを設定し、インベントリを実行する項目のタイプを特定してから、[Setup Inventory] をクリックします。

インベントリを実行後、インスタンスを選択してから [Inventory] タブをクリックして結果を確認します。

詳細な分析用に結果をフィルタリングすることができます。たとえば、開発ツールとライブラリのみを表示するために、AWS コンポーネントのリストを絞り込むことができます。

また、インベントリによるクエリをすべてのマネージドインスタンスに対して実行できます。4.6 より前のバージョンの .NET を実行している Windows Server 2012 R2 インスタンスを見つける方法は次のとおりです。

 

AWS Config 統合
インベントリの結果を AWS Config にルーティングして、アプリケーション、AWS コンポーネント、インスタンス情報、ネットワーク設定、および Windows アップデートの変更を継続して追跡することができます。この情報にアクセスするには、インスタンスの Config タイムライン上の [Managed instance information] をクリックします。

下部に表示される 3 行は、インベントリ情報へつながっています。以下にネットワーク設定を示します。

 

パッチ管理
この機能は、Windows インスタンスのオペレーティングシステムを最新の状態に保つのに役立ちます。パッチは、定義したメンテナンス時間中に適用され、ベースラインに対して実行されます。ベースラインは、分類または重大度に基づいてパッチを自動的に承認するためのルールと、承認または拒否するパッチの明示的なリストを指定します。私のベースラインを次に示します。

各ベースラインは 1 つ以上のパッチグループに適用できます。パッチグループ内のインスタンスには、[Patch Group] タグがあります。 私のグループに Win2016 という名前をつけました。

それから、値をベースラインに関連付けます。

次のステップでは、AWS-ApplyPatchBaseline ドキュメントを使用して、メンテナンス時間中にパッチを適用できるようにします。

マネージドインスタンスのリストに戻って、フィルタのペアを使用し、どのインスタンスにパッチが必要かを調べることができます。

 

自動化
最後に大切な点ですが、自動化機能は一般的な AMI の構築および更新タスクを簡略化します。たとえば、AWS-UpdateLinuxAmi のドキュメントを使用して、毎月新しい Amazon Linux AMI を構築することができます。

この自動化を実行すると、次のようになります。

 

今すぐ利用可能
このブログで紹介した EC2 Systems Manager のすべての機能は今日から無料でご利用いただけます。管理したリソースに対してのみ料金を支払います。

Jeff;

AWS コストエクスプローラーの更新 – リザーブドインスタンス使用率レポート

コストエクスプローラーは、レポートおよび分析ツールを使用して AWS の使用率を管理できるようにするツールです (詳細については、「The New Cost Explorer for AWS」を参照してください)。1 回クリックするだけでサインアップし、AWS コストの視覚化、傾向の分析、使用率のパターンの確認ができます。使用率は、事前定義された一連のビュー (サービス別、リンクされたアカウント別、日次など) で確認できます。関心のある特定の領域にドリルインしたり、カスタムフィルタを設定したりできます。エンタープライズ規模の AWS のお客様は、リザーブドインスタンスで実現されるコスト削減 (オンデマンドと比較した場合、最大 75%) を常に活用できます。こうしたお客様は、一般的に数千ものリザーブドインスタンス (RI) のサブスクリプションを持っていて、それらを十分に活用できていることを確認したいと考えています。

新しいリザーブドインスタンス使用率レポート
本日、コストエクスプローラーに新しいリザーブドインスタンス使用率レポートが追加されます。リンクされたアカウント間で分散された数千のサブスクリプションにユーザーが増えても、組織全体にわたり RI 全体の使用率を追跡し、管理する機能が得られます。また、1 年前まで遡って、使用率全体または個別の RI の使用率を確認することもできます。さらに、1 年前まで遡って、使用率全体または個別の RI の使用率を確認し、RI 使用率のしきい値を定義して、それに対する実際の使用率をモニタリングすることもできます。事前に定義されたターゲットを使用率が下回っている RI サブスクリプションが見つかった場合、ドリルダウンしてアカウントの所有者、インスタンスタイプ、および未使用の時間を確認できます。また、コストエクスプローラーで提供される既存のフィルタリング関数にすべてアクセスできます。私は数千のリザーブドインスタンスを所有していないので、サンプルのスクリーンショットとテストデータを使って、このレポートの外観と使用方法を示します。新しいレポートはコストエクスプローラーのメニューから日次または月次で利用できます (このメニューには、私が定義した 3 つのレポートが含まれています)。

RI 使用率の日次レポートを次に示します。

RI は RI 使用率の降順に表示されています。デフォルトでは、最も使用されていない RI がリストの先頭に表示されます。クリックすると、時間の経過に伴う使用率と、RI に関する詳細情報が表示されます。

特定の RI に注目するため、インスタンスタイプまたはその他の属性別にフィルタできます。

必要な時間範囲も設定できます。インスタンスタイプでフィルタして時間範囲を設定することで、先月に d2.8xlarge RI を十分に活用したことを次のように確認できます。

使用率ターゲットを目的の割合に設定でき、それが基準線としてグラフに表示されます。ここでは、6 月に使用率が 80% を下回ったことがわかります。

ここから日次ビューに切り替えて拡大 (クリックしてドラッグ) すると、詳細を表示できます。

前述したように、リンクされたアカウント、リージョン、および各 RI のその他の側面でフィルタすることもできます。

今すぐ利用可能
このレポートは今すぐ使い始めることができます。

Jeff;

新機能 – Amazon Cognito グループ、およびきめ細かなロールベースのアクセス制御

アプリケーションの構築における課題の 1 つは、ユーザー認証と管理に関する事柄です。この課題に直面しても、多くの開発者はアプリケーション用の別のユーザー ID と認証システムを構築したいとは考えていませんし、必要な場合を除いてユーザーにさらに別のアカウントを作成させたいとも思っていません。Amazon Cognito では、アプリケーションのデータとバックエンドシステムにアクセスするために、開発者がユーザーの ID、認証、および権限を簡単に管理できるようになっています。それに加えて、開発者がアプリケーションの異なるユーザーに異なる権限を割り当てるのを簡単にするサービス機能があればどんなによいでしょう。本日、Cognito ユーザープールがグループをサポートし、Cognito フェデレーション識別がきめ細かなロールベースのアクセス制御 (RBAC) をサポートするようになったことが発表されました。Cognito でのグループのサポートにより、開発者は異なるユーザータイプとアプリケーションの使用権限を表すグループを作成して、ユーザーのアプリケーションエクスペリエンスを簡単にカスタマイズできます。開発者は、グループからのユーザーの追加や削除、およびユーザーのセットに対してグループで権限を管理できます。権限に関しては、Cognito フェデレーション識別でのきめ細かなロールベースのアクセス制御 (RBAC) のサポートにより、開発者は異なる認証をされたユーザーに異なる IAM ロールを割り当てられます。これまで、Amazon Cognito ではすべての認証されたユーザーに対して 1 つの IAM ロールのみをサポートしていました。きめ細かな RBAC を使用すると、開発者はフェデレーティッドユーザーに異なる IAM ロールをマッピングすることができます。この機能は Facebook や Active Directory などの既存の ID プロバイダーと Cognito ユーザープールを使用したユーザー認証の両方で利用できます。

Cognito ユーザープールのグループ
新しい Cognito のグループの機能について調べる最善の方法は、Amazon Cognito コンソールで新しいグループを作成して、さまざまなグループタイプにユーザーを追加してみることです。Cognito - UserPoolCreateGroup   [my user pool]、[TestAppPool] を選択すると、[Users and groups] という更新されたメニュー項目があります。メニューオプションを選択すると、パネルに [Users] と [groups] の両方のタブが表示されます。新しいグループを作成するには、[Create Group] をクリックします。グループを作成するダイアログボックスが開きます。ここでは、AdminGroup という管理者ユーザー用のグループを作成します。グループの名前とグループの説明を記入し、優先順位を設定してグループを作成する準備ができました。優先順位の数値をグループに設定すると、複数のグループに割り当てられているユーザーに対して、どのグループの権限が優先して使用されるかが決定されます。優先順位の数字が低いほど、ユーザーが使用するグループの優先順位が高くなります。自分の [AdminGroup] の場合、このグループにゼロ (0) の優先順位を付けます。[Create group] ボタンをクリックして、自分のユーザープールグループを作成します。Cognito - CreateGroupDialog-s あとは、自分のユーザーをグループに追加するだけです。このテストアプリケーションプールでは、以下の図のように [TestAdminUser] と [TestUnregisteredUser] の 2 人のユーザーがいます。[TestAdminUser] を、新しく作成したグループに追加します。Cognito - Users ユーザーを AdminGroup ユーザープールグループに追加するには、[Groups] タブで自分の [AdminGroup] を選択します。AdminGroup の詳細画面の表示後、[Add users] ボタンをクリックすると、ユーザープール内のユーザーを表示するダイアログボックスが表示されます。このグループにユーザーを追加するには、追加するユーザー名の横にあるプラスのマークをクリックするだけです。ユーザーがグループに追加されたという確認を受け取ると、このプロセスは完了です。ウォークスルーからお分かりのように、開発者がユーザープール内にグループを作成することは簡単です。AWS マネジメントコンソール、API、および CLI を使用して、ユーザープール内のグループを作成および管理できます。開発者として、AWS 認証情報を使用してユーザープールのグループを作成、読み込み、更新、削除、およびリストすることができます。各ユーザープールには、最大 25 個のグループを含めることができます。さらに、ユーザープール内のグループからユーザーを追加または削除できます。また、グループに AWS IAM ロールを割り当てることによって、グループを使用して AWS のリソースへのアクセス許可をコントロールすることができます。Amazon API Gateway と組み合わせて Amazon Cognito を使用することによって、自分のバックエンドリソースへのアクセス許可をコントロールすることもできます。

Cognito - AddUsersAdminGroup - small

Cognito フェデレーション識別でのきめ細かなロールベースのアクセス制御
Cognito フェデレーション識別機能の、きめ細かなロールベースのアクセス制御 (Role-Based Access Control) を詳しく調べましょう。以降、これを RBAC と呼びます。RBAC について見てみる前に、Cognito フェデレーション識別機能の概要を確認しましょう。Cognito ID は、AWS アカウント認証情報を使用せずにアプリケーションから AWS リソースにアクセスするための、権限が制限されている一時的な認証情報のセットをユーザーに割り当てます。各ユーザーの権限は、お客様が作成する AWS IAM ロールを介して制御されます。この時点で、マネジメントコンソールの別のウォークスルーで RBAC について見ていきましょう。コンソールで [Cognito] サービスを選択したら、[Federated Identities] を選択します。RBAC を確認している間に稼働中の Cognito ユーザープールとフェデレーション識別を示すのが最善であると思うので、認証プロバイダーとして Cognito ユーザープールを使用する新しい ID プールを作成します。新しいユーザープールを作成するために、最初に ID プールの名前を入力し、認証されていない ID へのアクセスを有効にするチェックボックスをオンにします。次に、[Authentication Providers] の [Cognito] タブを選択して、TestAppPool ユーザープール ID とアプリケーションのクライアント ID を入力します。アプリケーションのクライアント ID を取得し、アプリケーションが Cognito ID プールを利用して関連付けられたユーザープールにアクセスするために、Cognito ユーザープール内にアプリケーション (アプリケーションクライアント) が作成済みである必要がある点に注意してください。Cognito - CreateIdentityPool ID プールの作成が済んだところで、Cognito ユーザープールの認証方法にロールベースのアクセスを割り当てましょう。異なるロールを割り当てる最も簡単な方法は、Cognito ID プールでルールを定義することです。各ルールは、ユーザー属性を指定するか、コンソールに表示されるようにクレームを指定します。クレームは、ルールによって一致し、特定の IAM ロールに関連付けられる、その属性のトークンの値です。RBAC の利点を真に示すためには、エンジニアリング部門のユーザーがオブジェクトを S3 に配置し、DynamoDB にアクセスできるテストアプリケーションの役割が必要になります。このロールを作成するために、まず S3、GetItem、クエリ、スキャンへの PutObject アクセスおよび DynamoDB への BatchGetItem アクセスが含まれるポリシーを作成する必要があります。このポリシーを TestAppEngineerPolicy と呼ぶことにします。前述のポリシーを作成した後で、このポリシーを活用する EngineersRole という名前の IAM ロールを作成します。この時点で、AWS リソースへのきめ細かなアクセスのできるロールがあるので、Cognito ID プールにもどります。[Edit identity pool] をクリックし、[Authentication providers] セクションをドロップダウンします。ID プールの認証プロバイダが Cognito ユーザープールであるため、[Cognito] タブを選択します。フェデレーティッド認証のきめ細かな RBAC を確立しているので、[Authentication provider] の [Authenticated role selection] セクションに注意を集中して、ルールを定義します。このセクションでは、ドロップダウンをクリックして、オプションの [Choose role with rules] を選択します。Cognito - AuthenticationProviderここで、クレーム (属性)、一致する値、特定の IAM ロール、EngineersRole のルールを設定します。たとえば、作成しているルールが特定の IAM ロール (例: EngineersRole) を、部門属性が「Engineering」として設定された Cognito ユーザープールで認証済みのユーザーに割り当てます。ルールに基づいている部門属性は、下の図に示すように、ユーザープール TestAppPool で作成したカスタム属性であることに注意してください。Cognito - CustomAttributes - smallこれで、この問題はクリアしたので、ルールの作成にもう一度注目します。クレームに関しては、前述のカスタム属性、部門を入力します。部門の値が、文字列「Engineering」と等しい場合にこのルールが適用されます。したがって、[Match Type] フィールドで [Equals match type] を選択します。最後に、ルールで一致する属性値に対する、実際の文字列値「Engineering」を入力します。ユーザーが部門属性に対して一致する値を持っている場合、認証情報を取得したときに EngineersRole IAM ロールを引き受けることができます。これを完了して、[Save Changes] ボタンをクリックすると、Cognito ユーザープールで認証済みの、エンジニアリング部門のユーザーがアプリケーションを使用している他の認証されたユーザーとは異なる権限を持てるルールが正常に作成されました。Cognito - AuthenticationRoleSelection Cognito ID プールで異なるロールに割り当てるルールの設定のウォークスルーを完了したので、きめ細かな RBAC について覚えておきたい重要なポイントをいくつか説明します。まず、最初に一致するルールが適用されるために、ルールはオーダーと IAM ロールで定義されます。次に RBAC を設定するには、ユーザープールにより割り当てられる ID トークンを介してルールを定義し、ロールを活用することができます。ID プールで設定された各認証プロバイダーに対して、最大合計 25 個のルールを作成できます。さらに、ユーザーアクセス権限は作成した AWS IAM ロールによって制御されます。

料金と提供地域
開発者はこれらの新機能をすぐに活用できます。新機能と Amazon Cognito サービスを活用することの他の利点については開発者用リソースページを参照してください。ユーザープール内のグループを使用しても追加コストが発生しないというのは大きなニュースです。無料利用枠の後は、料金は、Monthly Active Users (MAU) に対してのみ発生します。また、Amazon Cognito では、ユーザーのアクセス権限を制御、また一意の識別子の生成のために Cognito フェデレーション識別機能を常時無料で使用できることを覚えておいてください。詳細については、Amazon Cognito 料金表ページを参照してください。

Tara

Amazon ECS – Windows コンテナ (ベータ版) のサポート

お客様がコンテナベースのコンピューティングについて習熟していて、コンテナ化の価値について少なくとも基礎的な理解があることを心から願っています。私が 2014 年に述べたように、クラウドベースのアプリケーションをコンテナのコレクションとしてパッケージ化し、それぞれを宣言により指定することで、開発環境と本稼働環境の一貫性、アーキテクチャベースとしての分散アプリケーションプラットフォーム、開発効率、運用効率など、数多くの利点が得られます。当社は 2014 年後半に、Linux コンテナのサポートを含む Amazon EC2 Container Service をリリースしました。今年は、これまでにアプリケーションの負荷分散のサポートECS タスクの IAM ロールサービスの Auto ScalingAmazon Linux コンテナイメージBlox オープンソーススケジューラを追加しました。

Windows コンテナのサポート
本日は、ECS の一連のリリースを継続し、Windows コンテナのベータレベルのサポートを追加します。当社が本稼働環境での使用に向けてこの機能を最終的に完成させる間、お客様は Windows アプリケーションのコンテナ化とテストを今すぐ開始できます。使用を開始するには、クラスターの作成時に Windows Server 2016 Base with Containers AMI を指定するだけです (同じクラスターに Linux と Windows を混在させることはできません)。また、Windows コンテナ AWS CloudFormation テンプレートを開始点として使用することもできます。テンプレートは VPC で実行され、コンテナインスタンスの設定可能な数で Windows を利用するクラスターが作成されます。また、IAM ロール、Application Load Balancer、セキュリティグループ、Amazon ECS タスク定義、Amazon ECS サービス、および Auto Scaling ポリシーも作成されます。テンプレートはそのままで使用することも、お客様独自の使用に合わせて変更することもできます。私はすべてのパーツの連携を示すために、CloudFormation Designer でテンプレートを公開しました。その構造をもう少し明確にするため、項目を再配置しました。それを次に示します。

Windows コンテナのサポートの詳細については、「Windows コンテナ (ベータ版)」を参照してください。

主要事項
Windows Server Docker イメージはかなり大きなサイズ (約 9 GiB) です。Windows コンテナインスタンスでは Linux コンテナインスタンスよりも大きなストレージ容量が必要なため、それに応じて計画してください。イメージのサイズが大きいため、コンテンツをダウンロードおよび展開して最初に使用するまでに、最大で 15 分かかる場合があります。タスク用の IAM ロールを使用している場合 (詳細については、「Windows タスク用の IAM ロール」を参照)、この時間は 2 倍になることがあります。その他の問題と注意点の詳細な一覧については、「Windows コンテナに関する注意点」を参照してください。

Jeff;

Amazon EFS の更新 – Direct Connect を介したオンプレミスアクセス

昨年、Amazon Elastic File System をご紹介 (Amazon Elastic File System – Amazon EC2 の共有ファイルストレージ) し、本年初頭には本番環境での利用可能を発表 (Amazon Elastic File System – 3 つのリージョンで本番環境での利用が可能) しました。本年初頭の始動後、何千人もの AWS のお客様が、クラウド上の共有ファイルストレージを設定、スケーリング、および運用するためにこれを利用してきました。 そしてこの度、シンプルかつ信頼性が高い AWS Direct Connect を介したオンプレミスアクセスの紹介により、EFS はより便利なものとなります。これは、強く求められていた機能で、移行、クラウドバースト、バックアップにおいて有用です。 この機能を移行に使用するには、オンプレミスサーバーに EFS ファイルシステムをアタッチし、データをそこにコピーしてからクラウドで必要に応じて処理するだけです。データはそのまま AWS に長期間保存しておくことができます。クラウドバーストでは、オンプレミスデータを EFS ファイルシステムにコピーし、Amazon Elastic Compute Cloud (EC2) インスタンスを使用して高速で分析して、結果をオンプレミスにコピーしたり Amazon QuickSight で視覚化したりできます。オンプレミスサーバーから EFS ファイルシステムにアクセスした場合でも、または EC2 インスタンスからアクセスした場合でも、強力な一貫性とファイルロックを含む同様のファイルシステムのアクセスセマンティックスが得られます (もちろん、両方を同時にもできます)。また、EFS の一部であるマルチ AZ の可用性と耐久性を利用できます。 この新機能を利用するためには、オンプレミスのデータセンターと Amazon Virtual Private Cloud 間の専用ネットワーク接続を、AWS Direct Connect(専用線接続サービス) を使用して設定する必要があります。 その後、お客様のファイルシステムで、AWS Direct Connect(専用線接続サービス) 接続を介して到達可能なサブネットにマウントターゲットがあることを確認する必要があります。

また、マウントターゲットのセキュリティグループにルールを追加して、オンプレミスサーバーからポート 2049 (NFS) へのインバウンドの TCP および UDP トラフィックを許可する必要があります。

ファイルシステムを作成したら、IP アドレスでマウントターゲットを参照し、オンプレミスで NFS マウントしてファイルのコピーを開始できます。IP アドレスは、AWS Management Console 内から利用可能です。

Management Console でも、詳しい手順を知ることができます。オンプレミスのマウント手順をクリックしてください。

以下もご覧ください。

この機能は今すぐご利用いただけます。US East (Northern Virginia)US West (Oregon)Europe (Ireland)US East (Ohio) リージョンでは追加費用はありません。

Jeff;

AWS ブログチームを拡大 – 新メンバーに Ana、Tara、ローカリゼーションチームが参加

AWS の最初のブログを公開したのは 2004 年のことです。それ以来 2,700 件以上のブログを投稿してきました (先月中に投稿したブログだけでも 52 件ありました)。AWS のイノベーションのペースは以前に増して高まり、皆さんにご紹介する優れた機能も増え続けているためブログチームも拡大することになりました。では、新メンバーとなる Ana、Tina、Tara の 3 人をご紹介します。

Ana Visneski (@acvisneski) は米国沿岸警備隊の初の公式ブロガーでした。沿岸警備隊では捜索救助の調整やソーシャルメディアの確立においてチームをリードしていました。Ana はワシントン大学コミュニケーションリーダーシッププログラムを卒業、デジタルメディア分野の修士号 (MCDM) およびコミュニティ & ネットワーク分野のコミュニケーション修士号 (MCCN) の両方を初めて完了した経歴の持ち主です。Ana はブログのゲスト投稿者と協力し、AWS ブログのメトリクスをトラックしたり AWS ブログのアクティビティ調整に使用するチケットシステムの管理を担当しています。

Tina Barr (@tinathebarr) は AWS コマーシャルセールス部のリクルーティングコーディネーターです。Tina は、候補者に良い第一印象を提供しようと AWS お客様の成功事例を読み進めていくうちに、スタートアップ企業に特別な興味を抱くようになりました。リクルーティング業務に加え、Tina は AWS ホットスタートアップ (9 月10 月11 月) のブログを毎月投稿しています。Tina はウエスタンワシントン大学でコミュニティヘルスの学士号を取得、物を書くことが大好きだそうです。

Tara Walker (@taraw) は AWS のテクニカルエバンジェリストです。数社に渡るハイテク企業やメディア企業で開発者やソフトウェアエンジニアを務めた経験があります。IoT、モバイル、ゲーム、サーバーレスアーキテクチャ、クロスプラットフォーム開発に注目する Tara は、最新で優れた技術的なトピックに深くのめり込み思わず引き込まれるようなデモを構築することが大好きだといいます。Tara はジョージア州立大学で学士号を取得、現在はジョージア工科大学でコンピューターサイエンスの修士号の取得に励んでいます。私と同様に Tara は AWS リリースに関するブログを投稿していきます。このように 3 人のクリエイティブで優れた人材を新に AWS ブログチームに迎えられたことを大変嬉しく思うと同時に、彼らがどのようなコンテンツを提供していくのか楽しみにしています。

AWS ブログのローカリゼーションチーム
AWS ブログで公開している投稿の多くは日本語と韓国語に翻訳してご提供しています。この場をお借りしてローカリゼーションチームに感謝いたします。

Jeff;

最新のAWSコミュニティヒーロー (2016 年冬)

AWS コミュニティヒーローは AWS に関する知識を共有し、AWS への際立った熱意を示す AWS コミュニティのメンバーです。ユーザーグループ、ソーシャルメディア、ミートアップやワークショップなど、さまざまな方法を通じてその知識と熱意を皆さんと共有しています。今日、2016 年最後の AWS ヒーローの仲間達にハッピーホリデーウェルカムをしたいと思います。

11 月にすべての AWS コミュニティヒーローが reInvent に招待され、月曜日の夜、ヒーローのためのプライベートイベントに参加する機会がありました。2016 年最後の 2 人のヒーローは、re:Invent 週の月曜日の朝にコミュニティヒーローに参加するための招待を受け取り驚きました。彼らは直前の招待にもかかわらずイベントに参加することができ、他のヒーロー達に会うことができました。

多田 歩美さん

歩美多田 歩美さんは日本の本田技研工業株式会社で IT インフラストラクチャストラテジストとして働き、クラウドコンピューティングテクノロジーの使用を奨励しています。また、クラウドの使用を JAMA (一般社団法人日本自動車工業会) の CAE/HPC エリアも促進しています。彼女は以前、Honda R&D で IT システム管理者として、エンジニアリングシミュレーションシステム (コンピュータ支援エンジニアリング/CAE) を含むハイパフォーマンスコンピューティング (HPC) にクラウドを使用することに重点を置いてきました。そして re:Invent 2014 で AWS での HPC のユースケースを紹介しました。現在、彼女は広範囲なエンタープライズアプリケーションにおけるクラウドの使用を促進しています。多田さんは JAWS-UG (日本 AWS ユーザーグループ) のメンバーです。JAWS-UG は 2010 年に始まり、60 以上のブランチ、100 を超えるリーダー、1 年に 300 を超えるミートアップイベント、4,000 人以上のメンバーがいます。彼女は HPC スペシャリストと初心者向けの新しい JAWS ブランチの立ち上げリーダーの一人です。また、女性向けの JAWS 支部のオーガナイザーの一人でもあり、熊本およびエンタープライズ向けの JAWS (E-JAWS) ミートアップイベントを含む他のローカルブランチにも参加しています。多田さんは AWS 認定ソリューションアーキテクトのアソシエイト認証を受けており、ナショナルキャリア開発センターの国際パートナー組織のキャリア開発アドバイザーであり、早稲田大学の電気電子工学および情報工学の理学士号も取得しています。

Shimon Tolts

ShimonShimon Tolts は、8 歳の時からコンピュータに関心を持っていました。彼は、最初の PC を手に入れたとき、さまざまなパーツがどのように相互に接続しているのかを理解するために、すぐさま分解し始めました。その後、Linux とオープンソースソフトウェアにも大きな影響を受けた Shimon は 15 歳で初の会社を立ち上げ、プレクラウド時代に Linux サーバー上にウェブホスティングを提供しました。兵役中、Shimon は特別調査のセンターユニットでコンピューター犯罪調査官およびフォレンジック分析者を務めたため、軍務の後に Intel Security での業務を果たすことができました。2013 年に Shimon は ironSource に参加して、R&D インフラストラクチャ部門を設立しました。開発された最も革新的なソリューションの 1 つは ビッグデータパイプラインで、数千億もの毎月のイベントを、異なる ironSource 部門から Redshift にほぼリアルタイムでストリーミングするのに使われました。テックコミュニティに彼のソリューションのリクエストを受けた後、このソリューションは、ATOM DATA として一般にリリースされました。Shimon は、イスラエル AWS ユーザーグループを率いており、AWS サミットからポップアップロフトまでのビッグデータカンファレンスの定例講演者です。

-Ana