Amazon Web Services ブログ

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

AWS オンラインセミナー – 2017 年 1 月 (12 月のオンラインセミナー要約を含む) ※英語のみ

1 月のオンラインセミナー

AWS では常にトレーニングや学習資料の提供に努めています。1 月のセミナー内容をきっとお楽しみいただけると思います。受講は無料ですが、すぐに満席になってしまうため、お早目の登録をお勧めします。開催時間はすべて太平洋標準時、所有時間は 1 時間です。

1 月 16 日:

1 月 17 日:

1 月 18 日::

1 月 19 日:

1 月 20 日

12 月のオンラインセミナー要約 12 月のオンラインセミナーはすでに完了していますが、要約と録画をこちらからご覧いただけます: 12 月 12 日:

12 月 13 日:

12 月 14 日:

12 月 15 日:

Jeff;

PS – 2017 年に向け先立って予習を開始したい方は、簡単にアクセスできる re:Invent 2016 のプレゼンテーションre:Invent 2016 の動画をご覧ください。

新しい AWS Application Discovery Service コンソール

AWS Application Discovery Service は、クラウドへの移行計画を立てるのに役立ちます。 AWS クラウド導入フレームワークの中心的なコンポーネントとして、これはシステムに関する重要な情報を検出して収集する処理を自動化するプロセスを簡略化します (詳細については、新しい AWS Application Discovery Service – クラウド移行を計画するをお読みください)。 データ収集には 2 つのオプションがあります。軽量エージェントを物理サーバーまたは VM にインストールすることもできますし、VMware 環境で Agentless Discovery Connnector を実行することもできます。 どちらの場合でも、AWS Application Discovery Service は以下の情報を収集します。

  • インストール済みのアプリケーションおよびパッケージ。
  • 実行中のアプリケーションおよびプロセス。
  • TCP v4 および v6 接続。
  • カーネルブランドおよびバージョン。
  • カーネル設定。
  • カーネルモジュール。
  • CPU およびメモリの使用状況。
  • プロセスの作成および終了イベント。
  • ディスクおよびネットワークイベント。
  • NIC 情報。
  • DNS、DHCP、および Active Directory の使用。

軽量エージェントは、リッスンする TCP ポートと関連するプロセスに関する情報も収集します。この機能は Agentless Discovery Connector にも近日中に追加される予定です。 情報は収集され、オプションのレビューのためにローカルに保存されてから、ポート 443 の安全な接続を介してクラウドにアップロードされます。この情報は処理され、相関され、暗号化された形式でリポジトリに格納されます。その後、その情報を使用して移行したいアプリケーションを選択することができます。 新しい Application Discovery Service コンソールこのサービスについて最初に書いた際、処理され相関された情報は、分析ツールや移行ツールで使用するために XML 形式と CSV 形式で利用できました。 本日、AWS はクラウド移行プロセス全体を簡略化するよう設計された、新しい Application Discovery Service コンソールをリリースしました。エージェントをインストールし、アプリケーションを検出し、アプリケーションの依存関係をマッピングし、アプリケーションのパフォーマンスを測定するのに役立ちます。では、見ていきましょう。 ランディングページには、利点と機能のリストがあり、このサービスの概要をつかめます。

その後、データ収集のオプションを選びます (サーバーまたは VM でのエージェント、または VMware 環境でのエージェントレス)。 [Learn more] をクリックしてセットアップ手順の詳細を見ることができます。

すぐに使用できるエージェントとコネクタ (両方を一緒に使うことができます) のセットアップにより、[Start data collection] をクリックして、選択したエージェント/コネクタから検出を開始することができます。

サーバーは検出されたとおりに表示されます。

数回クリックするだけで、1 つまたは複数のサーバーを選択して、それらを指定したアプリケーションにグループ化することができます。

各サーバーに 1 つ以上のタグを追加できます。

ネットワーク接続、プロセス、ネットワークトラフィックを生成または消費するプロセスなど、各サーバーの詳細情報をすべて表示できます。

および

アプリケーションの一覧を表示できます (それぞれ 1 つ以上のサーバーで実行されています)。

各アプリケーションの詳細についても説明されています。

これらの情報があれば、AWS クラウドへの移行を計画して実行する準備が整います。詳細については、Application Discovery Service ユーザーガイドをお読みください。

Jeff;

PS – Application Discovery Service パートナーは、お客様のクラウド移行をぜひお手伝いしたいと思っています。

新リリース:Amazon QuickSight Enterprise Edition

私がAmazon QuickSightについて初めて書いたのは2015年のことで(Amazon QuickSight 高速で簡単に利用できるビッグデータ用BI(Business Intelligence), 従来型ソリューションの1/10のコストで実現)、その際にStandard EditionとEnterprise Editionを用意することをお知らせしました。

Enterprise Edition
先月、私達はAmazon QuickSightのStandard Editionをリリースしました。本日、Enterprise Editionをリリースいたします。Standard Editionの機能に加え、Enterprise EditionにはActive Directoryとの統合と、データ暗号化(Encryption at Rest)が実装されています。

Enterprise EditionはAWSのマネージド・サービスとして提供しているMicrosoft Active Directory (AD)(Managed Microsoft AD)を使った認証をサポートします。これにより、AWS上で稼動しているMicrosoft ADやオンプレミスにある信頼関係をもったADを使ってQuickSightへのサインインできるようになります。どちらの方法であるにせよ、シングルサインオン(SSO)によって、ユーザがQuickSightを使い始めるのをよりクイックに、また管理を減らすことが可能になります。

あなたが企業でのQuickSight管理者であった場合、大量のユーザに対してQuickSightを一度に使えるようにしたり、パーミッションを数クリックで管理することが可能になります。これまで通りのディレクトリ操作のツールを使って管理できますし、企業のガバナンスポリシーに準拠させることも可能です。
以下の図は、どのように動作するのかを説明しています:

qs_ee_ad_setup_1

QuickSightはSPICE (Super-fast, Parallel, In-memory Calculation Engine) によって、分析用のアドホッククエリに対して高いスケーラビリティを実現しています。Enterprise Editonはデータをアマゾンによって管理されている鍵で暗号化してSPICE内に保存し、これによりさらなるデータ保護の層を追加しています。
Enterprise Editionを始動させましょう

管理者側の作業としては、Amazon QuickSight Enterprise Editionをセットアップするのはとても簡単です。作業には、必要とされるパーミッションを持つIAMでログインします。(ドキュメントの”Sign Up for Amazon QuickSight With an Existing AWS Account“を参照してください。”Set your IAM Policy“にIAM設定についての説明があります)

Enterprise Editionを選択し、あなたのユーザコミュニティを管理するAWSマネージドのADを選択して、ディレクトリへのアクセス権限を与えます。そしてディレクトリにエリアスを追加し、それをQuickSightのアカウント名として使用します。最後にマネージドAD、もしくは信頼されたフォレスト(Trusted forest)上にあるADグループを選択し、QuickSightアクセス用に有効化します。

qs_ee_create_account_1

サインアッププロセスが完了すると、設定したグループに所属するユーザはQuickSightのアカウント名(ディレクトリエリアス)とADのクリデンシャルでQuickSightにログインをすることが出来るようになります。

パスワードの制限、タイムアウト、ユーザ管理は、そのAD(AWSに上、もしくはオンプレミス)上で設定し、所属企業のポリシーに従うことが可能です。既存のツールを使ってグループのメンバーシップをマネージでき、必要に応じてユーザを追加・削除する管理タスクを実行することが可能になります。

費用、および利用可能リージョン

Amazon QuickSight Enterprise EditionのAD連携機能はUS East(北バージニア)リージョンでのみ利用可能です。Enterprise Editionのもう一つの機能であるデータの暗号化については、US East(北バージニア)、US West (オレゴン)、EU (アイルランド)で利用可能です 。費用は1ヶ月・1ユーザあたり$18からで利用でき、10GB分のSPICEキャパシティが含まれます。このSPICEキャパシティはアカウント内のユーザで共有されます(QuickSightの無料枠(Free tier)や、4ユーザまで利用できる60日間トライアルでも、SPICEストレージが共有されるという考え方は同様です)。詳細はQuickSightの価格ページを確認してください。

すでにUS East (北バージニア)リージョンでMicrosoft ADのインスタンスを利用されている場合、無料枠やフリートライアルを使って、追加コスト無しでEnterprise Editionを本日から利用いただくことが可能です。

原文:https://aws.amazon.com/jp/blogs/aws/new-amazon-quicksight-enterprise-edition/

翻訳:下佐粉 昭 (simosako@)