Amazon Web Services ブログ

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

by AWS Japan Staff | on | in General |

こんにちは。ソリューションアーキテクトの焼尾です。AWS Black Belt オンラインセミナー4月の配信についてご案内させて頂きます。4,5月は組織変更などがあった方も多く、基本に立ち返り、AWSの基礎となるサービスを中心に開催します。また、AWS re:Invent 2016 にて発表された新モバイルサービスの一つ、Amazon Pinpoint も開催します。

speakers
4月の開催予定

サービスカット
4/5(水) 18:00-19:00 Amazon EC2
4/12(水) 18:00-19:00 Amazon VPC
4/19(水) 18:00-19:00 Amazon S3
4/26(水) 18:00-19:00 Amazon Pinpoint

ソリューションカット
4/11(火) 12:00-13:00 初心者向け クラウドコンピューティング はじめの一歩
4/18(火) 12:00-13:00 サーバレスによるアーキテクチャパターンのご紹介

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

サーバレス JavaScript アプリケーションで SAML: Part I

by AWS Japan Staff | on | in Amazon Cognito, AWS IAM, General, Serverless, セキュリティ |

このブログ記事は AWS の Richard Threlkeld, Gene Ting, Stefano Buliani によって AWS Compute Blog に投稿された「SAML for Your Serverless JavaScript Application: Part I」の翻訳記事です。

このブログ記事に掲載したコードや SAM テンプレートの全体は samljs-serverless-sample GitHub レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。


SAML 認証連携を実現したくありませんか? AWS プラットフォームで使うことができる一時的なセキュリティ認証情報の発行を、短期間の SAML アサーションを交換で実現できます。

エンタープライズ Web アプリケーションを構築する時は、認証や認可が一貫して行われ業界のベストプラクティスに沿っている事が必須事項です。AWS では、ユーザに一意のIDを作成し、AWS のサービスにアクセスできる短期間の認証情報を使えるようにできる Amazon Cognito と呼ぶサービスを構築しました。これらの認証情報は、IAM ポリシーに基づくロールと関連付けて、異なるリソースへのアクセスを許可や拒否する事ができます。

この記事では、Amazon Cognito で SAML プロバイダと認証連携を行う異なる方式を紹介していきます。応用すると、異なるタイプの認証プロバイダ (IdP) と連携させることができます。Facebook、Twitterやその他のサードパーティのソーシャルメディアを IdP にする事もできます。Amazon Cognito のユーザプールと認証連携させ、独自のマネージドユーザディレクトリを作成することもできます。

例えば、ユーザが Active Directory Federation Services (ADFS) で認証する事ができる JavaScript アプリケーションを構築したいかもしれません。ユーザは AWS 認証情報で許可された範囲で API を呼び出して得た情報をアプリケーションに表示させたり、DynamoDB テーブルに書き込むことができます。AWS Mobileブログの記事「Announcing SAML Support for Amazon Cognito」では、新しい SAML 機能について Java、Android、iOS のサンプルコード付きで紹介しました。この記事では、ADFS フローのカスタマイズについて JavaScript のサンプルを交えて詳細に紹介します。

シナリオ

この記事では、クライアント側のフローを紹介します。SAML アサーションは Amazon API Gateway 経由で渡され、ブラウザ上のコードは Amazon Cognito Identity から直接認証情報を受け取ります。次回のブログ記事では、バックエンド側の処理を紹介します。SAML アサーションと認証情報は、AWS Lambda ファンクション内で処理でき、ビジネスロジックを実現するようカスタマイズしたり監査履歴を取ったりする事ができます。

このシナリオの全コードは SAM テンプレート含め、GitHub の samljs-serverless-sample レポジトリにあります。手動でリソースを作成する事もできますが、GitHub レポジトリにある SAM テンプレートを使ってリソースを作成することを強くお勧めします。

サーバレスのアーキテクチャとなっていますが、ADFS との連携は従来のコンピュート サービスである EC2 インスタンスのようなコンポーネントで置き換えることもできます。ADFS の用語や定義については「Claims-based identity term definitions」を参考にして下さい。

前提条件

このブログ記事では、ADFS が動作している環境が必要です。以下の事を実施して下さい。:

  1. AWS コンソールで ADFS との認証連携を設定。「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」を AWS CloudFormation テンプレートと共に参考にしてください。
  2. サインインページ(https://localhost/adfs/IdpInitiatedSignOn.aspx)からユーザ example\bob が ADFS-Dev と ADFS-Production の両方のグループとして認証出来ることを確認します。
  3. Amazon Cognito Identity のプールを作成します。

ADFS 設定の概要

チュートリアルを始める前に、幾つか AWS と SAML の設定を確認しましょう。まず、前提条件にある通り IAM ロールが作成されているかから確認して下さい。アプリケーション用に新しく IAM ロールと AD グループを作成してもかまいません。この記事では、「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」の記事の通り ADFS-Dev と ADFS-Production を利用します。

  1. IAM コンソールで、ロールを選択し ADFS-Ddev を選択し、信頼関係 (Trust Relationships) のタブを開き、以下のコードのようになっている事を確認します。:
    {
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Federated": "arn:aws:iam::YOURACCOUNTNUMBER:saml-provider/ADFS"
          },
          "Action": "sts:AssumeRoleWithSAML",
          "Condition": {
            "StringEquals": {
              "SAML:aud": "https://signin.aws.amazon.com/saml"
            }
          }
        }
      ]
    }

このポリシーは “ADFS” という SAML IdP で認証されたユーザがロールを引き受ける事を許可しています。また、ポリシーには条件が含まれており、SAML アサーション内の AudienceRestriction が https://signin.aws.amazon.com/ である事となっています。SAML アサーションは ADFS から AWS に HTTP POST で SAMLResponse というヘッダとして送られて来ます。前提条件に記載されている設定が実施済みであれば、ADFS コンソールでは以下のように設定されており、利用者(Ralying Party)の URL として AWS メタデータ URL が指定されています。詳細については、「認証レスポンスの SAML アサーションを設定する」を確認して下さい。



認証後、ADFS は利用者のアプリケーションに自動的にリダイレクトします。

上記のスクリーンショットでは、認証後の SAMLResponse の値を見るために Chrome を利用しました。「トラブルシューティングのためにブラウザで SAML レスポンスを表示する方法」に記載されているとおり、他のブラウザでも同様のことを行えます。SAMLResponse を貼り付ければ、Audience、Roles や Destination などの値を見ることができる “SAML Decoder” がインターネット上にあります。パート 2 のブロク記事では、これをプログラムで行う方法を紹介します。

ADFS からサーバレス Web サイトにリダイレクトし、Amazon Cognito に繋げる

この1つ目のブログのシナリオの方が難しくありません。多くの組織での要件にベストな流れとなっています。ユーザは ADFS で認証して Amazon Cognito から AWS 認証情報を受け取り、アプリの中でアクションを行えます。このサンプルアプリケーションは:

  1. ADFS で認証するログイン メカニズムを変更して取り出すことで、SAMLResponse ヘッダを取り出します。ユーザが S3 上に配置されたウェブサイトを訪問した際に、自動的にこの仕組みが行われます。
  2. ADFS-Dev ロールの信頼ポリシーを変更し、Active Directory の AWS-gDev グループのメンバであれば Amazon Cognio から一時的な認証情報を受け取れるようにします。
  3. ユーザのロールを選択するコードをアプリケーションの中に組み込みます。このブログ記事では、ADFS-Dev ロールを選択します。

参考までに、AWS Console への認証連携の場合 #3 と同様の内容は、ADFS のウェブページ IdpInitiatedSignOn.aspx からリダイレクトされた後にラジオボタンでロールをクリックして選択する事で実現されます。より詳しい内容については、セキュリティブログの「Enabling Federation to AWS Using Windows Active Directory, ADFS, and SAML 2.0」をご覧下さい。もしユーザが 1 つの Active Directory グループのメンバだけであれば、SAMLResponse には複数のロールが含まれておらず、その場合は #3 は省略されます。構成は以下の図のとおりとなります。

チュートリアル: ADDFS からサーバーレス Web サイトにリダイレクトし、Amazon Cognito に繋げる

まず、サーバレス Web サイトをセットアップし、認証情報を取得するログインフローを開始させます。シングル Web アプリを配置するのには S3 を使用します。

S3 バケットの作成

  1. S3 のコンソールで、「バケットを作成」を選択して一意なバケット名を入力します。以下の例では “serverlessweb” としますが、皆様は何か他の名前として下さい。
  2. バケットを作成後、詳細設定のページで「プロパティ」を選び、「バケットポリシーの編集」をクリックします。
  3. 以下のポリシーを設定して下さい。YOURBUCKETNAMEGOESHERE は置き換えて下さい。このポリシーは、バケットに入っている HTML や JavaScript などのファイルを誰でも GET リクエストを行えるようにします。Web サイトにアクセスすると Web ブラウザは GET リクエストを発行し、このポリシーがリソースの読み込みをユーザに許可します。
    {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Sid": "PublicReadForGetBucketObjects",
              "Effect": "Allow",
              "Principal": "*",
              "Action": "s3:GetObject",
              "Resource": "arn:aws:s3:::YOURBUCKETNAMEGOESHERE/*"
          }
      ]
    }
  4. 「静的ウェブサイトホスティング」を選択し、「ウェブサイトのホスティングを有効にする」とします。フォームに「index.html」と「error.html」を入力します。

  5. 次に、HTML ファイルをバケットに追加して、https://YOURBUCKETNAME.s3-website-REGION.amazonaws.com をブラウザで開きページが見れるか確認します(YOURBUCKETNAME と REGION は読み替えて下さい。)。まずは以下の HTML をテンプレートとして使って下さい。
    <!DOCTYPE html>
    <html>
     <head>
      <title>
       Amazon Cognito SAML Example
      </title>
      <script src="aws-sdk.min.js">
      </script>
     </head>
     <body>
      <h1>
       Testing SAMLResponse
      </h1>
     </body>
    </html>
      
  6. JavaScript SDK から圧縮(Minify)されたバージョン aws-sdk.min.js をダウンロードして、HTML ファイルと同様にバケットに保存し、エラー無くロードできることを確認します。

(オプション) CloudFront ディストリビューションのセットアップ

次に進める前に、さらにもう1つセットアップしたいと思います。CloudFront ディストリビューションです。S3 静的 Web ホスティングに CloudFront やその他の CDN を使用することで、独自ドメイン名で SSL を使用することができるようになります。

API Gateway から HTTP サイトにリダイレクトする事もできるため強制ではありませんが、Web サイトや認証や認可のシステムはエンドツーエンドで HTTPS を使うべきです。以下がセットアップで行う内容です。

  1. CloudFront コンソールで、Web タイプのディストリビューションを作成します。
  2. 「Viewer Protocol Policy」には、「HTTPS Only」を選択します。
  3. 「Origin Domain Name」には S3 バケットを選択します。
  4. ベストプラクティス通り、「Restrict Bucket Access」を選択します。こうすることで、バケットが直接アクセスされることから守ることができます。これで CloudFront ディストリビューションのドメイン名で、サイトにアクセスできるようになると思います。

ログイン メカニズム

次に、ログイン メカニズムを構築します。

ウェブサイトではログインさせるために、ボタンを押させることも出来ますし、自動的に認証情報が有効かどうか確認してからログインのフローにリダイレクトをさせる事もできます。

この例では、2 つ目のアプローチを取ります。ユーザがページを訪れると JavaScript を使ってすぐに状態を確認し、初回の訪問であれば認証情報を入手するためにリダイレクトさせます。このページにはログインの流れの中で API Gateway から再度リダイレクトされても来るため、ログインの進捗に合わせ ADFS のログインページにリダイレクトさせるのと同様に、届いた SAMLResponse のデータをキャプチャする事も必要です。今回の例では、以下のような流れになります。:

function loginWorkflow(){
    var activelogin = sessionStorage.getItem('activelogin');
    if (activelogin=='inProgress'){                                   //ADFS login redirect from API Gateway
        var samlResponse = getParameterByName('SAMLResponse');
        sessionStorage.removeItem(‘activelogin’);
        if (samlResponse != null){
            getSamlCredentials(samlResponse.replace(/\s/g, ''));
        }
    }
    else if (activelogin === null) {                                 //First page visit. Redirect to ADFS login.
        var RPID = encodeURIComponent('urn:amazon:webservices');
        var result = 'https://localhost/adfs/ls/IdpInitiatedSignOn.aspx' + "?loginToRp=" + RPID;
        sessionStorage.setItem('activelogin', 'inProgress');
        window.location = result;
    }
    else {//Credentials exist, page refresh, etc.
        console.log('activelogin already exists in session and the value is ' + activelogin);
    }
}

上記では、ADFS IdP への呼び出しを始める時にセッション変数を設定し、SAMLResponse (getParameterByName() で取り出せる)と一緒にWeb サイトに戻って来た時には getSamlCredentials() 関数を呼び出します。

AWS が必要とする SAMLResponse 値は POST binding のみがサポートされていますが、S3 の静的ウェブサイトは、GET リクエストしか受け取ることができません。このため、JavaScript アプリケーションが ADFS からの SAMLResponse を受け取るために API Gateway を利用します。Lambda をプロキシとして利用し、SAMLResponse をクエリ文字列に入れて静的ウェブサイトにリダイレクトで戻ってこさせます。

Lambda 関数の設定

  1. Lambda のコンソールで、GitHub レポジトリにある /Scenario1/lambda/redirect/index.js を使って samlRedirect という名前の関数をランタイムは Node.js 4.3 で作成します。実行ロールにはログ保存のために CloudWatch Logs の権限だけが必要です。
  2. 基本的な実行ロールが既になければ、関数作成時に新しいロールを Lambda のコンソール上で作成する事ができます。
  3. LOG_LEVELREDIRECT_URL という名前の環境変数を作成し、LOG_LEVEL には info を REDIRECT_URL には S3 の静的ウェブサイトの URL(静的ウェブホスティングを有効にしている場合にはバケットのプロパティに表示されているエンドポイント、あるいは先程記載したオプションの CloudFront ディストリビューション設定をした場合はドメイン名)を設定します。

API Gateway 設定

  1. API Gateway のコンソールで、SAMLAuth あるいは何か似た名前を付けた API を作成します。
  2. リソース」 を選択し、「SAML」という名前の子リソースを作成します。
    lambdasamlone_7.png
  3. POST」メソッドを作成します。「統合タイプ」には「Lambda」を選択し、「samlRedirect」関数を指定します。「メソッドリクエスト」の「HTTP リクエストヘッダー」に「SAMLResponse」を設定します。
    lambdasamlone_8.png

先ほど作成した samlRedirect 関数では、クエリ文字列に SAMLResponse を付けた静的ウェブサイトの URL を location プロパティに設定します。リダイレクトが実行されるように、API Gateway が 302 ステータスコードを返すように設定します。

  1. メソッドレスポンス」でステータスコード 200 を削除し、302 を追加します。「レスポンスヘッダ」に「Location」を設定し、「レスポンス本文」には「コンテンツタイプ」に「application/json」、「モデル」に「Empty」と設定します。
    lambdasamlone_9.png
  2. 「統合レスポンス」で「メソッドレスポンス」のステータスが 200 のものを削除し、302 のものを追加します。レスポンスヘッダ「Location」の「マッピングの値」には「integration.response.body.location」を設定します。
    lambdasamlone_10.png
  3. Lambda 関数が SAMLResponse と RelayState を受け取れるように、「統合リクエスト」で「コンテンツタイプ」が 「application/x-www-form-urlencoded」の「本文マッピングテンプレート」を以下のように追加します。:

    {
    "SAMLResponse" :"$input.params('SAMLResponse')",
    "formparams" : $input.json('$')
    }
  4. 変更を保存します。
  5. /saml リソースで「アクション」から「CORS の有効化」を選択します。「CORS を有効にして既存の CORS ヘッダを置換」を行いします。

  6. アクション」から「API のデプロイ」を選択します。「ステージ」には「Prod」や似た名前を使用します。「ステージエディター」で、「SDK 生成」を選択します。「プラットフォーム」には「JavaScript」を選択し、「SDK の生成」を行い、どこかのフォルダに保存します。ADFS の設定に必要になるため、トップに表示されている「URL の呼び出し」をメモします。

ADFS リダイレクト設定

  1. ADFS のコンソールで、「利用信頼関係」にある Amazon Web Services のプロパティを開き、「利用者を自動的に更新する」の項目を無効(チェックしない)にします。
    lambdasamlone_11.png
  2. エンドポイント」のタブを開き、既にあるエンドポイントを編集します。「バインディング」は「POST」のままで、「URL」には API Gateway でデプロイした API の「URL の呼び出し」を入力します。URL の最後に 「/saml」を追加します。
    lambdasamlone_12.png
    これまで構築してきたことを復習します。:

    • Web ページはユーザが認証情報を持っていなければ、ADFS のログインページにリダイレクトします。
    • 認証に成功したら、ADFS は SAMLResponse を付けて Web ページにユーザを戻します(API Gateway 経由)。
    • SAMLResponse は元の Web ページにクエリ文字列の一部として渡されます。

    Amazon Cognito から認証情報を取得するには、JavaScript コードでこのクエリ文字列を取り出し getCredentialsForIdentity 呼び出しのパラメータの一部として渡す必要があります。

  3. Amazon Cognito の Federated Identities のコンソールで、前提条件でセットアップした認証プールを開きます。認証プールの ID を確認し、以下の JavaScript コードの先頭に利用するリージョン名と同様に記載します。
    const identityPool = 'YOURCOGNITOPOOLID';
    AWS.config.region = 'COGNITOREGION'; // Region
    
    AWS.config.credentials = new AWS.CognitoIdentityCredentials({
        IdentityPoolId: identityPool
    });
    
    var identityId = localStorage.getItem('cognitoid');
    if (identityId != null){
        console.log('Identity ID: ' + identityId);
        loginWorkflow();
    } else {
        console.log('Calling GetID');
        AWS.config.credentials.get(function(){
            console.log('Identity ID: ' + AWS.config.credentials.identityId);
            localStorage.setItem('cognitoid', AWS.config.credentials.identityId);
            identityId = localStorage.getItem('cognitoid');
            loginWorkflow();
        });
    }

このコードは、アプリケーションでユーザに Amazon Cognito で生成した一意の ID を付与する最初の部分です。その上で、クエリ文字列に SAMLResponse の値を入れて返させるために loginWorkflow() を呼び出します。

以下は Stack Overflow で紹介されているサンプルのユーティリティ関数で、クエリ文字列から特定の項目を取り出すためのものです。

function getParameterByName(name, url) {
    if (!url) {
      url = window.location.href;
    }
    name = name.replace(/[\[\]]/g, "\\$&amp;");
    var regex = new RegExp("[?&amp;]" + name + "(=([^&amp;#]*)|&amp;|#|$)"),
        results = regex.exec(url);
    if (!results) return null;
    if (!results[2]) return '';
    return decodeURIComponent(results[2].replace(/\+/g, " "));
}

これで Web ページは ADFS から BASE64 エンコードされた SAMLResponse を取得しました。これを Amazon Cognito に渡せば AWS 認証情報を取得することが出来ます。Cognito の getSamlCredentials() 関数は以下のコードで、loginWorkflow() から呼び出されます。:

function getSamlCredentials(samlResponse) {
    var role = 'arn:aws:iam::ACCOUNTNUMBER:role/ADFS-Dev';
    var params = {
        IdentityId: identityId,
        CustomRoleArn: role,
        Logins: {
            'arn:aws:iam::ACCOUNTNUMBER:saml-provider/ADFS' : samlResponse,
        }
    };

    cognitoidentity.getCredentialsForIdentity(params, function(err, data) {
        if (err) console.log(err, err.stack);
        else {
            console.log('Credentials from Cognito: ');
            console.log(data.Credentials);
        }
    });
}

ARN にある ACCOUNTNUMBER は2つとも書き換える必要がある事に注意して下さい。今回は使用するロールがソースに直書きされています。もし、SAML クレームに複数のロールが入って返されないのであれば、このパラメータは省略することもできます。引き受けるロールを何かしらのロジックで選択するようにしたい場合もあると思います。このブログ記事のパート II ではクライアント側ではなくバックエンドでこれをできるようにする内容を含める予定です。

また、logins map にあるキーは IAM コンソールで作成した ADFS の IdP 登録の ARN で、値は samlResponse です。これもアカウント番号に書き換える必要があります。この情報により Amazon Cognito は SAMLResponse の値が信頼している対象の ADFS からのものであるか検証できます。

この時点でこのコードを試しても動作しません。Amazon Cognito の認証プールで、認証プロバイダとして SAML IdP を有効にする必要があります。

  1. Amazon Cognito の Federated Identities のコンソールで、プールを選択し、Authentication Providers までスクロールし、SAML を選択します。ADFS の IdP を示すチェックボックスを選択します。
  2. Save Changes をクリックします。
    lambdasamlone_13.png

次に、Amazon Cognito が有効な SAMLResponse アサーションを受け取った時に、ユーザがロールを引き受けられるように信頼ポリシーを変更します。Amazon Cognito は STSAssumeRoleWithWebIdentity API を呼び出してこれを実現します。

IAM のコンソールで、ADFS-Dev ロールの信頼ポリシーを以下のポリシーに編集します。(JavaScript コードのように適切な位置に Amazon Cognito のプール ID を挿入します。):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "",
      "Effect": "Allow",
      "Principal": {
        "Federated": "cognito-identity.amazonaws.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "cognito-identity.amazonaws.com:aud": "YOURCOGNITOPOOLID"
        },
        "ForAnyValue:StringLike": {
          "cognito-identity.amazonaws.com:amr": "authenticated"
        }
      }
    }
  ]
}

これで Amazon Cognito の信頼ポリシーは設定できました。Web ページをテストして下さい。AWS サービスのリクエストへの署名に使える認証情報はコンソールログに (AccessKey, SecretKey, Token) の 3 つが含まれる形で “data” オブジェクトで出力されます。アプリケーションの共通のシナリオは、AWS_IAM 認証に設定された API Gateway のメソッド呼び出しを行うことです。認証情報は SDK のリクエストを使うことで渡す事ができます。上記の呼び出して指定したロールにその API を呼び出す権限があれば、メソッド呼び出しは成功します。

例えば、API Gateway で API を作成した場合、メソッドに AWS_IAM 認証を有効にできます。上記で指定されたロール(logins mapで指定)に、メソッド呼び出しの権限があることを確認して下さい。より詳しいことは、「API Gateway へのアクセスを IAM アクセス権限で制御する」をご覧下さい。API をデプロイした場合、SDK の生成を使ってそのステージの JavaScript SDK を生成してダウンロードできます。これからのメソッド呼び出しを Web ページに組み込む事ができます。より詳しいことは、「API Gateway で生成した JavaScript SDK を使用する」をご覧下さい。トピックの最後に、apigClientFactory.newClient コンストラクタにアクセスキーシークレットキーをどうやって渡すことができるか確認しましょう。

Amazon Cognito Identity は短期間だけ有効な認証情報(1 時間で無効になる)を利用するため、一時的なアクセスキー、シークレットキー、セッショントークンを、apigClientFactory.newClient コンストラクタに渡します。:

        var apigwClient = apigClientFactory.newClient({
        accessKey: data.Credentials.AccessKeyId,
        secretKey: data.Credentials.SecretKey,
        sessionToken: data.Credentials.SessionToken
    });

機能の動作確認ができる Web ページのコードは、GitHub レポジトリ内の /scenario1/website/index.html にあります。同じディレクトリにある configs.js ファイルを更新します。リージョン、Cognito Identity のプール ID、SAML IdP の ARN、ADFS-Dev ロールの ARN を変更します。SAM テンプレートを使って API Gateway に AWS_IAM 認証の MOCK エンドポイントを作成する事もでき、連携された認証情報が機能するか Web ページ上のテストボタンで確認する事ができます。

lambdasamlone_14.png

最後に

チュートリアルを通じて SAML 認証や Amazon Cognito を使った AWS 認証について深いレベルで理解する手助けになる事を願っています。まだ完了していなければ、少し時間をかけて頂き、GitHub レポジトリの samljs-serverless-sample にあるコードを実際に動かし確認して下さい。また感想についても教えてください。

このシナリオは最初のステップとして十分かもしれませんが、組織によってはより多くのことをする必要があるかもしれません。例えば、ロールの選択をユーザに任せたいやビジネスロジックに基づき独自の IAM 範囲を実装したい事もあるかと思います。このシリーズのパート 2 ではこれらをどのようにしたら実現できるかを見ていきたいと思います。

[訳注] このブログで紹介している方法では、ADFS におけるデフォルトの AWS の証明書利用者設定を変更します。そのため、同じ ADFS 環境で AWS のマネージメントコンソールへ認証連携してアクセスさせる事とは同時に実現できません。

原文: SAML for Your Serverless JavaScript Application: Part I (翻訳: SA 辻 義一)

R で Amazon Athena を活用する

by AWS Japan Staff | on | in Amazon Athena |

データサイエンティストはしばしば、R から SQL クエリを投げるときに、その裏側のビッグデータ基盤のインフラ管理を気に掛けなければなりません。Amazon Athena はインフラ管理の必要がなく、標準 SQL で簡単に S3 上のデータを直接分析できる、インタラクティブクエリサービスです。R と Amazon Athena の連携によって、データサイエンティストはインタラクティブな分析ソリューションのための、強力なプラットフォームを手に入れることができます。

このブログポストでは、Amazon EC2 インスタンス上で動作する R/RStudio から Athena に接続します。

事前準備

Athena との連携を開始する前に、以下のステップを完了してください。

  1. AWS アカウントの管理者に依頼して、Athena にアクセスするのに必要な権限を、Amazon の Identity and Access Management (IAM) コンソール経由で、自身の AWS アカウントに付与してもらってください。具体的には、IAM にあるデータサイエンティストのユーザーグループに対して、関連する Athena のポリシーをアタッチしますRAthena_1
  2. Amazon S3 バケットに、ステージングディレクトリを作成してください。Athena はクエリする対象のデータセットと、クエリ結果を置く場所として、このバケットを利用します。このポストでは、ステージングバケットを s3://athenauser-athena-r とします

注意: このブログポストでは、すべての AWS リソースは us-east-1 リージョンに作成します。ほかのリージョンでも Athena が利用可能かどうか、製品およびサービス一覧で確認してください。

EC2 上での R と RStudio の起動

  1. AWS上でRを実行する” のインストラクションにしたがって、EC2 インスタンス(t2.medium かそれ以上のサイズ)で Amazon Linux を動かし、R のセットアップを行います。始める前に、以下のステップを確認しておいてください
  2. このブログポストの “高度な詳細” の記述で、ステップ 3 まできたら、最新バージョンの RStudio をインストールするため、以下の bash スクリプトを実行してください。必要であれば、RStudion のパスワードも修正してください
#!/bin/bash
#install R
yum install -y R
#install RStudio-Server
wget https://download2.rstudio.org/rstudio-server-rhel-1.0.136-x86_64.rpm
yum install -y --nogpgcheck rstudio-server-rhel-1.0.136-x86_64.rpm
#add user(s)
useradd rstudio
echo rstudio:rstudio | chpasswd

Java 8 のインストール

  1. EC2 instance に SSH でログインします
  2. 古いバージョンの Java を削除します
  3. Java 8 をインストールします。これは Athena を動かすために必要です
  4. コマンドライン上で、以下のコマンドを実行します
#install Java 8, select ‘y’ from options presented to proceed with installation
sudo yum install java-1.8.0-openjdk-devel
#remove version 7 of Java, select ‘y’ from options to proceed with removal
sudo yum remove java-1.7.0-openjdk
#configure java, choose 1 as your selection option for java 8 configuration
sudo /usr/sbin/alternatives --config java
#run command below to add Java support to R
sudo R CMD javareconf

#following libraries are required for the interactive application we build later
sudo yum install -y libpng-devel
sudo yum install -y libjpeg-turbo-devel

.Renviron のセットアップ

R の環境変数 .Renviron に対して、必要となる Athena のクレデンシャルを追加します。

  1. AWS 管理者から、必要なクレデンシャルを AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY の形式で取得します
  2. Linux のコマンドプロンプトから以下のコマンドを打ち込んで、vi エディタを立ち上げます
    sudo vim /home/rstudio/.Renviron
    
    Provide your Athena credentials in the following form into the editor:
    ATHENA_USER=< AWS_ACCESS_KEY_ID >
    ATHENA_PASSWORD=< AWS_SECRET_ACCESS_KEY>
  3. 編集結果をセーブして、エディタを終了します

RStudio にログイン

続いて、EC2 上の RStudio にログインします。

  1. EC2 のダッシュボードからインスタンスのパブリック IP アドレスを取得して、ブラウザのアドレス欄に貼り付け、後ろに :8787(RStudio のポート番号)を付けます
  2. EC2 インスタンスに関連付けられたセキュリティグループm設定で、アクセス元の IP アドレスから 8787 ポートへのアクセスが許可されていることを確認してください
  3. 先ほど設定したユーザ名とパスワードで、RStudio にログインします

R パッケージのインストール

続いて、必要な R パッケージをインストールして、ロードします。

#--following R packages are required for connecting R with Athena
install.packages("rJava")
install.packages("RJDBC")
library(rJava)
library(RJDBC)

#--following R packages are required for the interactive application we build later
#--steps below might take several minutes to complete
install.packages(c("plyr","dplyr","png","RgoogleMaps","ggmap"))
library(plyr)
library(dplyr)
library(png)
library(RgoogleMaps)
library(ggmap)

Athena への接続

以下の R のスクリプトで、Athena ドライバーのダウンロードと、コネクションの設定を行います。アクセスしたいリージョンの JDBC URL に接続してください。

#verify Athena credentials by inspecting results from command below
Sys.getenv()
#set up URL to download Athena JDBC driver
URL <- 'https://s3.amazonaws.com/athena-downloads/drivers/AthenaJDBC41-1.0.0.jar'
fil <- basename(URL)
#download the file into current working directory
if (!file.exists(fil)) download.file(URL, fil)
#verify that the file has been downloaded successfully
fil
#set up driver connection to JDBC
drv <- JDBC(driverClass="com.amazonaws.athena.jdbc.AthenaDriver", fil, identifier.quote="'")
#connect to Athena using the driver, S3 working directory and credentials for Athena 
#replace ‘athenauser’ below with prefix you have set up for your S3 bucket
con <- jdbcConnection <- dbConnect(drv, 'jdbc:awsathena://athena.us-east-1.amazonaws.com:443/',
s3_staging_dir="s3://athenauser-athena-r",
user=Sys.getenv("ATHENA_USER"),
password=Sys.getenv("ATHENA_PASSWORD"))
#in case of error or warning from step above ensure rJava and RJDBC packages have #been loaded 
#also ensure you have Java 8 running and configured for R as outlined earlier

これで RStudio から Athena に接続する準備ができました。

サンプルクエリでテスト

# get a list of all tables currently in Athena 
dbListTables(con)
# run a sample query
dfelb=dbGetQuery(con, "SELECT * FROM sampledb.elb_logs limit 10")
head(dfelb,2)

RAthena_2

インタラクティブなユースケース

次に、分析と可視化のために R から Athena に対してインタラクティブなクエリを行ってみましょう。S3 上にあるパブリックデータセットの GDELT を使います。

GDELT データセットに対して、R から Athena のテーブルを作成します。このステップは “Amazon Athena – Amazon S3上のデータに対話的にSQLクエリを” で紹介されているように、AWS のマネジメントコンソール上からも実行することができます。

#---sql  create table statement in Athena
dbSendQuery(con, 
"
CREATE EXTERNAL TABLE IF NOT EXISTS sampledb.gdeltmaster (
GLOBALEVENTID BIGINT,
SQLDATE INT,
MonthYear INT,
Year INT,
FractionDate DOUBLE,
Actor1Code STRING,
Actor1Name STRING,
Actor1CountryCode STRING,
Actor1KnownGroupCode STRING,
Actor1EthnicCode STRING,
Actor1Religion1Code STRING,
Actor1Religion2Code STRING,
Actor1Type1Code STRING,
Actor1Type2Code STRING,
Actor1Type3Code STRING,
Actor2Code STRING,
Actor2Name STRING,
Actor2CountryCode STRING,
Actor2KnownGroupCode STRING,
Actor2EthnicCode STRING,
Actor2Religion1Code STRING,
Actor2Religion2Code STRING,
Actor2Type1Code STRING,
Actor2Type2Code STRING,
Actor2Type3Code STRING,
IsRootEvent INT,
EventCode STRING,
EventBaseCode STRING,
EventRootCode STRING,
QuadClass INT,
GoldsteinScale DOUBLE,
NumMentions INT,
NumSources INT,
NumArticles INT,
AvgTone DOUBLE,
Actor1Geo_Type INT,
Actor1Geo_FullName STRING,
Actor1Geo_CountryCode STRING,
Actor1Geo_ADM1Code STRING,
Actor1Geo_Lat FLOAT,
Actor1Geo_Long FLOAT,
Actor1Geo_FeatureID INT,
Actor2Geo_Type INT,
Actor2Geo_FullName STRING,
Actor2Geo_CountryCode STRING,
Actor2Geo_ADM1Code STRING,
Actor2Geo_Lat FLOAT,
Actor2Geo_Long FLOAT,
Actor2Geo_FeatureID INT,
ActionGeo_Type INT,
ActionGeo_FullName STRING,
ActionGeo_CountryCode STRING,
ActionGeo_ADM1Code STRING,
ActionGeo_Lat FLOAT,
ActionGeo_Long FLOAT,
ActionGeo_FeatureID INT,
DATEADDED INT,
SOURCEURL STRING )
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
STORED AS TEXTFILE
LOCATION 's3://support.elasticmapreduce/training/datasets/gdelt'
;
"
)

dbListTables(con)

上記のステートメントを実行すると、RStudio のコンソールに ‘gdeltmaster’ というテーブルが新しく作成されたのを確認できます。

RAthena_3

2015 年に US で開かれた CAMEO イベントの回数をカウントするクエリを、Athena テーブルに投げましょう。

#--get count of all CAMEO events that took place in US in year 2015 
#--save results in R dataframe
dfg<-dbGetQuery(con,"SELECT eventcode,count(*) as count
FROM sampledb.gdeltmaster
where year = 2015 and ActionGeo_CountryCode IN ('US')
group by eventcode
order by eventcode desc"
)
str(dfg)
head(dfg,2)

RAthena_4

#--get list of top 5 most frequently occurring events in US in 2015
dfs=head(arrange(dfg,desc(count)),5)
dfs

RAthena_5-300x140

上記の R の出力結果から、CAMEO イベントは 42 回という高頻度で行われたことがわかります。CAMEO のマニュアルから、このイベントの概要が “会議やその他のイベントのための、他の地域への出張” となります。

次に、この分析から得られる知見を使い、この特定のイベントに関連したすべての地域の座標リストを、Athena テーブルから取得します。

#--get a list of latitude and longitude associated with event “042” 
#--save results in R dataframe
dfgeo<-dbGetQuery(con,"SELECT actiongeo_lat,actiongeo_long
FROM sampledb.gdeltmaster
where year = 2015 and ActionGeo_CountryCode IN ('US')
and eventcode = '042'
"
)
#--duration of above query will depend on factors like size of chosen EC2 instance
#--now rename columns in dataframe for brevity
names(dfgeo)[names(dfgeo)=="actiongeo_lat"]="lat"
names(dfgeo)[names(dfgeo)=="actiongeo_long"]="long"
names(dfgeo)
#let us inspect this R dataframe
str(dfgeo)
head(dfgeo,5)

RAthena_6

続いて、アメリカ合衆国の地図を生成します。

#--generate map for the US using the ggmap package
map=qmap('USA',zoom=3)
map

RAthena_7

これで、Athena テーブルから得られた地理データが、地図上にプロットされました。これにより、2015 年に US でひらかれたすべての当該イベントについて、開催場所を可視化することができました

#--plot our geo-coordinates on the US map
map + geom_point(data = dfgeo, aes(x = dfgeo$long, y = dfgeo$lat), color="blue", size=0.5, alpha=0.5)

RAthena_8

結果を可視化することによって、あるイベントの開催場所が US の北東部に極めて集中していることを把握できました。

結論

この記事では Athena と R を使って、簡単なインタラクティブアプリケーションを構築する方法を説明しました。Athena は標準 SQL を用いて、ビッグデータを保存し、それに対してクエリをかけるのに使うことができます。またその一方で、R の持つ強力なライブラリ群を活用することで、Athena に対してインタラクティブにクエリを投げ、分析のインサイトを得ることができます。

質問やアドバイスなどがありましたら、コメント欄にフィードバックをお願いします。

原文: Running R on Amazon Athena (翻訳: SA志村)

発表: Amazon GameLift がすべての C++ と C# ゲームエンジンをサポート

by AWS Japan Staff | on | in Amazon GameLift |

すべてのゲーム開発者の方にお知らせします。数週間前にサンフランシスコで行われた GDC 2017 は大人気でした。そのため、クールなゲームの学習と構築に刺激を受け、情熱を注ぐには今が最適なタイミングです。ここで、Amazon GameLift がすべての C++ と C# ゲームエンジンで利用可能になったことをお知らせします。これには、Amazon Lumberyard、Unreal Engine、Unity が含まれ、そのすべてでゲームセッションのマッチング機能が向上しています。Amazon GameLift に詳しくないお客様向けに、ゲーム開発者が楽しく革新的なオンラインゲーム体験を提供できるよう支援するために設計された、このマネージド型サービスについてご紹介します。

Amazon GameLift は、専用ゲームサーバーをホストするためのマネージド型の AWS のサービスで、ゲーム開発者が簡単にゲームのキャパシティーをスケールし、利用可能なゲームセッションでプレイヤーをマッチングできるようにします。Amazon GameLift を使用すると、サーバーのホスト、ゲームの可用性の追跡、分散サービス拒否 (DDoS) 攻撃からのゲームサーバーの防御が可能なほか、ゲームをオフラインにすることなくアップデートをデプロイできます。Amazon GameLift サービスは Amazon Game Studios の専用ゲームサーバーや外部のゲーム開発顧客に役立ち、指定された時間内に開始、終了するゲームループで、セッションベースのゲームをサポートするよう設計されています。最新の Amazon GameLift リリースではサービスの最新機能が強化されているほか、開発者向けにゲームの開発とデプロイの簡略化を支援する優れた新機能が追加されています。Amazon GameLift サービスのクールな機能のいくつかについて見てみましょう。

  • 複数エンジンのサポート: 当初、Amazon GameLift サービスは Amazon Lumberyard ゲームエンジンのみで使用できました。現在、このサービスは強化され、Unreal EngineUnity のような一般的なゲームエンジンをはじめ、カスタム C# と C++ ゲームエンジンと統合されます。
  • 新しいサーバー SDK 言語のサポート: より多くのお客様と開発者をサポートするため、このサービスでは C# と C++ で利用できる Amazon GameLift Server SDK が提供されます。これには、Amazon GameLift 用の Unreal Engine API と互換性のある、カスタマイズされたバージョンの C++ Server SDK である Unreal Engine プラグインが含まれています。
  • クライアント SDK 言語サポートの拡張: Amazon GameLift Client SDK は 多数の言語で提供されている AWS SDK にバンドルされました。これにより、ゲーム開発者は選択した言語で Amazon GameLift サービスが統合されたゲームクライアントを構築できます。
  • マッチメーキング: Amazon GameLift は世界中の利用可能なゲームサーバーを継続的にスキャンし、プレイヤーのリクエストにマッチングしてゲームに参加させます。低レイテンシーのゲームサーバーが利用できない場合は、プレイヤーの周囲にキャパシティーを自動的に追加するようサービスを設定できます。Amazon GameLift は新しいゲームが開始されるか新しいインスタンスが起動するまで待機中のプレイヤーのキューを維持してから、待機中のプレイヤーを最もレイテンシーが低いゲームに配置します。
  • プレイヤーデータの処理: ゲーム開発者はカスタムプレイヤー情報を保存し、ゲームサーバーに直接渡せるようになりました。これにより、ゲームサーバーまたは API を持つその他のゲームエンティティは、Amazon GameLift からプレイヤーデータを取得できます。
  • コンソールのサポート: Amazon GameLift は、XBox One および PS4 用に開発、作成されたゲームをサポートします。

Amazon GameLift はセッションベースのマルチプレイヤーゲームの作成に必要であった手間のかかるタスクを、ゼロからのインフラストラクチャの構築に関連する時間、コスト、リスクを減らしつつ、ゲームサーバーのデプロイ、スケーリング、維持のプロセスを簡略化することで実行します。Amazon GameLift を利用するゲームソリューションのリファレンスアーキテクチャを次に示します。

 

ゲームへの Amazon GameLift の統合
ゲームビルドへの Amazon GameLift の統合はいくつかの簡単なステップに分割できます。

  1. Amazon GameLift Server SDK を使用してゲームサーバープロジェクトを設定し、プロジェクトに通信コードを追加して、ゲームサーバーで Amazon GameLift のホスティングを準備します。
  2. ゲームデプロイの対象とした AWS リージョンに対してゲームサーバービルドをパッケージ化し、アップロードします。
  3. ゲームをホストするための複数のコンピューティングリソースを作成、構築します。
  4. AWS SDK と Amazon GameLift API を使用して Amazon GameLift によって維持されるゲームセッションに接続するようゲームクライアントを準備し、Amazon GameLift サービスへの呼び出しのゲームクライアント用のコードを追加して、プレイヤーのリージョンを識別します。
  5. Amazon GameLift でホストされたゲームセッションに接続し、ゲームセッションを作成中であることを確認して、Amazon GameLift の統合をテストします。

Unreal ゲームエンジンを使用して簡単なゲームサーバープロジェクトで Amazon GameLift Server SDK をセットアップして、これらのステップの実行を開始しましょう。Unreal Engine (UE) Epic の Unreal ゲームエンジンから開始します。分かりやすいように、オンラインマルチプレイヤー機能が組み込まれたサンプルの Shooter Game プロジェクトを作成し、コンピュータにローカルに保存します。

マルチプレイヤー Shooter Game のサンプルをダウンロードし、マシンでローカルに開いたので、C++ コードを操作して、Amazon GameLift サービスを UE オンラインサブシステムに追加し、オンラインゲームセッションを管理する必要があります。Shooter Game サンプルは Unreal Engine の Blueprints Visual Scripting システムを利用します。Blueprints システムは UE エディタのノードベースのインターフェイスに基づくゲームプレイスクリプティングシステムです。これにより、ゲーム設計者とコンテンツ作成者は UE エディタ内でゲームプレイ要素と機能を作成できます。私の目標は Amazon GameLift C++ SDK を使用して Amazon GameLift サービスをゲームに含め、ゲームコードを変更することなので、ゲームと結び付ける Visual Studio プロジェクトソリューションを作成し、Shooter Game のソースコードとバイナリをプロジェクトに関連付ける必要があります。これを達成するため、コンテキストメニューに移動して、[File] メニューオプションを選択します。メニューのドロップダウンで、[Generate Visual Studio Project Files] オプションを見つけて選択します。

プロジェクトが生成されたら、コンテキストメニューに戻って [File] を選択し、プロジェクトを開いてソースコードを表示するために [Open with Visual Studio] を選択します。

Amazon Game Lift サービスをゲームサービスとして Shooter Game に追加する準備として、またゲームセッションの管理のため、プロジェクトで OnlineSubSystem モジュールを有効にする必要があります。これを行うには、Visual Studio プロジェクトでゲームビルド設定ファイルを開きます。このゲームプロジェクトの名前は ShooterGame であるため、ビルドファイルの名前は ShooterGame.Build.cs になり、次に示すように Source/ShooterGame フォルダにあります。

ビルドファイルを開き、OnlineSubsystemNull モジュールの行のコメントを解除します。既にマルチプレイヤーオンラインシステムを利用しているサンプルを使用しているため、ビルドオプションは適切に設定され、コードは次のようになります。

public class ShooterGame : ModuleRules
{
	public ShooterGame(TargetInfo Target)
	{
		PrivateIncludePaths.AddRange(
			new string[] { 
				"ShooterGame/Classes/Player",
				"ShooterGame/Private",
				"ShooterGame/Private/UI",
				"ShooterGame/Private/UI/Menu",
				"ShooterGame/Private/UI/Style",
				"ShooterGame/Private/UI/Widgets",
            		}
		);
       PublicDependencyModuleNames.AddRange(
			new string[] {
				"Core",
				"CoreUObject",
				"Engine",
				"OnlineSubsystem",
				"OnlineSubsystemUtils",
				"AssetRegistry",
             			"AIModule",
				"GameplayTasks",
			}
		);
       PrivateDependencyModuleNames.AddRange(
			new string[] {
				"InputCore",
				"Slate",
				"SlateCore",
				"ShooterGameLoadingScreen",
				"Json"
			}
		);
		DynamicallyLoadedModuleNames.AddRange(
			new string[] {
				"OnlineSubsystemNull",
				"NetworkReplayStreaming",
				"NullNetworkReplayStreaming",
				"HttpNetworkReplayStreaming"
			}
		);
		PrivateIncludePathModuleNames.AddRange(
			new string[] {
				"NetworkReplayStreaming"
			}
		);
	}
}

これで Shooter Game プロジェクトを設定したので、Amazon GameLift SDK に再び注目しましょう。C++ SDK を Unreal Engine のプラグインとして利用したいので、このゲームエンジン用のバイナリを構築するコンパイルディレクティブを使用して SDK をコンパイルする必要があります。SDK ソースをダウンロードした状態で、オペレーティングシステムに基づいてソースから SDK をコンパイルできます。このプロジェクトには Windows マシンを使用しているため、次のステップを完了します。

  • コードのコンパイルから生成されたバイナリを保持する out ディレクトリを作成します。

mkdir out

  • 前に作成したディレクトリに移動します。

cd out

  • CMake を使用して、VS 2015 Win x64 のビルドシステムジェネレーターを指定し、UE コンパイルフラグを設定します。

cmake -DBUILD_FOR_UNREAL=1 -G “Visual Studio 14 2015 Win64” <ソースディレクトリ>

  • 選択したビルドシステム (このプロジェクトの場合は MS Build) を使用してバイナリを作成する C++ プロジェクトを構築します。

msbuild ALL_BUILD.vcxproj /p:Configuration=Release

ライブラリをコンパイルしたので、Amazon GameLift Unreal Engine プラグインを使用するために次のバイナリファイルが必要です。

Linux:

* out/prefix/lib/aws-cpp-sdk-gamelift-server.so

Windows:

* out\prefix\bin\aws-cpp-sdk-gamelift-server.dll

* out\prefix\lib\aws-cpp-sdk-gamelift-server.lib

次に示すように、私は Windows を使用しているため、コンパイルされた Amazon GameLift ライブラリ aws-cpp-sdk-gamelift-server.dll および aws-cpp-sdk-gamelift-server.lib はそれぞれ prefix\bin および prefix\lib フォルダにあります。

GameLiftSDK Unreal Engine プラグインフォルダにバイナリをコピーすると、Amazon GameLift プラグインフォルダが設定され、Unreal Engine ゲームプロジェクトに追加する準備が整います。これを踏まえて、Unreal Engine の ShooterGame プロジェクトに Amazon GameLift プラグインを追加します。Unreal Engine Editor を使用してプラグインを追加できますが、その代わりに、Visual Studio プロジェクトに留まり、ゲームディレクトリとプロジェクトファイルを更新してプラグインを追加します。

Windows エクスプローラーで、Plugins というフォルダを ShooterGame ディレクトリに追加し、準備した GameLiftServerSDK フォルダを、Unreal Engine のプラグインに関するドキュメントに示されているように、このディレクトリにコピーします。

ここで、ShooterGame.Build.cs ファイルを開きます。これはゲームの依存関係に関する情報を保持する C# ファイルです。

ファイル内で次のコードを追加します。

PublicDependencyModuleNames.AddRange(
            new string[] {
                "Core",
                "CoreUObject",
                "Engine",
                "InputCore",
                "GameLiftServerSDK"
            }
       );

これまでに行った変更とすべてが同期されていることを確認するため、Visual Studio を閉じ、UE Editor に戻って [Refresh Visual Studio Project] を選択します。

完了したら、[Open Visual Studio] を選択します。ShooterGame ディレクトリに追加した Plugins フォルダがプロジェクトに含まれていて、Solution Explorer で表示できます。

次に、ソリューション全体を再構築して、Amazon GameLift SDK バイナリをプロジェクトに統合します。

UE Editor に戻り、ツールバーの [Build] を選択して、Amazon GameLift プラグインの側面が ShooterGame に含まれていることを確認します。コンパイルが完了したら、[Settings] ツールバーを簡単に確認します。[Plugins] オプションには Amazon GameLift プラグインが追加されていて、プロジェクトで認識されていることがわかります。[Enabled] チェックボックスを選択します。これにより、UE Editor の再起動が求められます。[Restart Now] を選択し、Unreal Engine がゲームコードファイルを再構築できるようにします。

ビルドが完了すると、エディタが再起動し、ShooterGame がもう一度開かれます。

これで ShooterGame プロジェクトで Amazon GameLift SDK の使用に関する設定が完了しました。Unreal エディタを開いた状態で、[Open Visual Studio] メニューオプションに移動し、ShooterGame コードに戻ります。これにより、Visual Studio およびゲームコードが開きます。Visual Studio を開いた状態で、ShooterGameMode.cpp ファイルに移動し、コードを追加して Amazon GameLift SDK を初期化します。Shooter Game プロジェクト内で Amazon GameLift に正しくコードを追加するために実行する必要がある主要なことは、次のとおりです。

  1. フラグ WITH_GAMELIFT=1 を使用してプリプロセッサ条件内で Amazon GameLift コードを囲みます
  2. 対象のサーバー OS (Linux など) 用に、Unreal Engine で専用サーバーを構築します
  3. ビルドの対象がゲームサーバータイプであることを確認します (Type == TargetRules.TargetType.Server)

Unreal Engine プロジェクトで Amazon GameLift を追加するために必要なコードの例は、こちらのドキュメントに記載されています。さらに、Unreal Engine wiki で提供されている Windows および Linux 向けの専用サーバーガイドに従って、Unreal Engine の専用サーバーを構築する方法を参照できます。これらの資料を利用すると、Amazon GameLift をゲームプロジェクトに首尾よく統合できます。Unreal Engine ゲームエンジンへの Amazon GameLift SDK の組み込みについて簡単に説明しましたが、Amazon GameLift SDK を Unity など C# エンジンに追加するオプションもあることを忘れないでください。Amazon GameLift Server SDK をダウンロードし、.Net framework 3.5 ソリューションをコンパイルすることで、GameLiftServerSDKNet35.sln になります。GameLiftServerSDKNet35.sln ソリューションを使用すると、Amazon GameLift ライブラリを Unity3D プロジェクトに追加することができます。Amazon GameLift C# Server SDK プラグインのセットアップと使用の詳細については、Amazon GameLift SDK ドキュメント「Unity での C# サーバー SDK の使用」を参照してください。

要約
Amazon GameLift マネージド型サービスに追加された新しい側面の 1 つのみを説明しましたが、このサービスは開発者やゲームスタジオに対してさらに多くの機能を提供しています。Amazon GameLift は、DDoS 攻撃からゲームを防御しながら、インフラストラクチャの管理、キャパシティーのスケーリング、利用可能なゲームセッションへのプレイヤーのマッチングを簡単にして、分散型ゲームを構築できます。

Amazon GameLift サービスの詳細については、Amazon GameLift のドキュメントと Amazon GameLift 開発者ガイドを参照してください。また、Amazon GameDev チュートリアルページの Amazon GameLift チュートリアルを確認して、Amazon GameLift サービスを使用したゲーム開発を本格的に開始することができます。どうぞゲームをお楽しみください。

Tara

Amazon Rekognitionを使ってMacOS Finderのタグ機能を更に良いものにしよう

by AWS Japan Staff | on | in Amazon Rekognition |

こちらは、AWSのGlobal Startup EvangelistであるMackenzie Kosut(@mkosut)によってAWS Startups Blogに投稿された「Using Amazon Rekognition to enhance MacOS Finder Tags」の翻訳記事です。


日曜の朝、私はラップトップにある何百枚もの写真が保存されている大きなフォルダを眺めていました。サムネイルは素晴らしいのですが、私が本当にやりたかったことは、簡単にそしてクイックに”崖”の写真を探し当てることでした。

OS X Mavericksからタグ機能が使えるようになり、Finderウインドウでタグ付けされたファイルを探せるようになっています。そこで、私はラップトップからAmazon Rekognitionに写真を送信し、それぞれの写真についてAmazon RekognitionのDeep Learningベースの画像認識を行い、そして、識別情報をタグとしてファイルに登録し、Finderでそのファイルを開けるようにする、という一連の処理に関してどの程度の手間がかかるのか知りたいと思っていました。

これが実現できると、FinderもしくはSpotlight(MacOSの検索機能)において、Tag:<term>という形で検索できるようになります。例えば、全ての猫(cat)の写真を引き当てたい場合は Tag:Cat と入力することで結果を得ることが出来る、というものです。

writexattrsファンクションのコードスニペットをオンラインで見つけた後、そうこうするうちに、Amazon Rekognitionに写真を送り、Tagの結果を得て、それらをファイルに登録することが出来てしまいました。約30分の間に50行ほどのコードを書いて、それが実際に動作するプロトタイプになりました。

コードは https://github.com/mkosut/rekognition_osx_tagfile にありますので、是非ご覧になさってください。

多数の写真がある大きなフォルダーについても正しく動作しました。そして、パフォーマンス向上のため、アップロードの前にイメージのリサイズを行い、プロセスをマルチスレッドで行えるようなpull requestをチームの中のメンバーが送ってくれました。

私が本当に欲しかったものは、画像がフォルダに追加された時に自動でタグ付けされる、というものでした。私はそのためにMacOS Automatorを活用しました。Automatorでは使い勝手の良い簡単なインターフェースを通じてフォルダーのアクティビティをウォッチすることができ、新しいファイルが書き込まれたらアクションを走らせることができます。これはAmazon S3にファイルのファイルが変更された時にAWS Lambdaの処理をいつでも自動的に稼働させるものと似ていると言えるでしょう。

このワークフローは”TagMe”フォルダーに新しいファイルが書き込まれるのを待ち受け、それらを rek_osx_tagfile.py スクリプトにファイル名をパラメーターとして渡して起動します。

それでは最終テストです:

成功しました!

このhackを通して私は大きな気付きを得ました。それは、AWSはどんなことにも活用できるケーパビリティを持っているということです。ここには非力な1台のラップトップしかありませんが、私はAmazon Rekognitionの巨大なDeep Learning基盤を用いることで大量の写真の解析をすることができましたし、何より少ないコードでそれを実現できました!

 

翻訳:篠原英治(原文:「Using Amazon Rekognition to enhance MacOS Finder Tags」 – https://aws.amazon.com/blogs/startups/using-amazon-rekognition-to-enhance-macos-finder-tags/

Amazon WorkDocs の更新 – コメントやレビュー機能の強化と新しいアクティビティフィード

by AWS Japan Staff | on | in Amazon WorkDocs |

以前にも触れましたが、Amazon では自社のシャンパンを好んで飲むようにしています。つまり、独自で開発したサービス、ツール、アプリケーションを仕事の一部として使用し、その上で改善に役立ちそうなアイデアや予想どおりに機能していないものについて開発チームにフィードバックを提供するようにしています。Amazon WorkDocs (旧名: Zocalo) を初めて紹介したのは 2014 年の中頃ですが、私はそれ以来ずっとこのサービスを使用しています (忙しい時は下書きの段階にあるブログが同時に 7 件~8 件あることも稀ではありません)。新しいブログ投稿の下書き (通常 PDF 形式) を WorkDocs にアップロードし、プロダクトマネージャー、プロダクトマーケティングマネージャー、指定されているその他のレビュー担当者と共有します。レビュー後にフィードバックを追加してもらい、下書きを更新して次のフィードバックを待ちます。このプロセスを何度か繰り返した後に下書きが完了し、ブログ投稿の許可を待ちます。このレビュープロセスには開発者、シニアマネジメントなども含まれます。私はドキュメントを共有してフィードバックを待つだけです。できる限り早急にフィードバック (いくつもの提案と場合によっては質問) をすべて読みプロセスし、見落としがないか確認するのが私の仕事です。そこで、今回はこれまで以上に WorkDocs を便利にする最新の機能強化についてご紹介します。コメント機能やレビュー機能の他にアクティビティフィードも追加しました。

コメント機能の強化
レビュープロセスを行っている間に追加されたコメントからディスカッションが始まる場合もあります。特定の機能やイメージが適切であるかどうか検討が必要な場合もあります。会話を簡単に始めたり続行できるようにするため、WorkDocs がスレッドで構成したコメントをサポートできるようになりました。[Reply] をクリックしてコメントに返信するだけです。

次のように表示されます。

[Private] をクリックすると、これにアクセスできるのは最初のコメントを書いたユーザーのみになります。メッセージを分かりやすくするため、コメントでシンプルな形式 (太字、斜体、取り消し線) を使用することもできます。詳しくはこちらをご覧ください。

使用例をご覧ください。

[?] をクリックすると、形式に関する簡単なガイドが表示されます。

コメントのプロセスが完了したら、クリック 1 回でフィードバック機能を無効にすることができます。

詳細については 「フィードバックを追加するには」を「WorkDocs ユーザーガイド」でご覧ください。

レビュー機能の強化
コメントが増えるにつれて、場合によってはレビュー担当者たちに特に注目して欲しいコメントもあると思います。そのような時は、コメント内で @ を入力しポップアップメニューからユーザー名を選択します。

ユーザーにはフィードバックが必要なことをメールでお知らせします。これまでは、レビュー担当になる可能性があるユーザーに WorkDocs ドキュメントの URL が渡っても、そのドキュメントへのアクセスは付与されていませんでした。今後は、そうしたユーザーでも次のようなドキュメントへのアクセスをリクエストできるようになりました。

リクエストはメール経由でドキュメントの所有者から承認を受けるために転送されます。同様に、読み取り専用のアクセス権を許可されていたユーザーも寄稿者レベルのアクセス権をリクエストできるようになりました。

繰り返しますが、リクエストはメール経由でそのドキュメントの所有者から承認を受けるために転送されます。

 

アクティビティフィード
常時、複数のブログ投稿がレビュープロセスにあるので、これらを上手に整理することはなかなかのチャレンジです。全体図をより分かりやすく提供するため、WorkDocs にアクティビティフィードが追加されました。フィードを見れば、共有しているドキュメントで何が起きているのかが分かります。ファイルやフォルダの作成、変更、削除や追加されたコメントを確認できます。さらに誰が変更を追加したのか、そして変更した日時を確認することもできます。

検索用語を入力してフィードに何を表示するか管理できます。

アクティビティタイプや日付別にフィルターに掛けることもできます。

 

今すぐ利用可能
これらの機能は今すぐご利用いただけます。

Jeff;

Amazon Elasticsearch Service が Elasticsearch 5.1 をサポート

by AWS Japan Staff | on | in Amazon Elasticsearch Service |

Amazon Elasticsearch Service は、オープンソース検索および分析エンジンである Elasticsearch を容易にデプロイ、運用、拡張できるようにするマネージド型サービスです。このたび Amazon Elasticsearch Service で Elasticsearch 5.1 および Kibana 5.1 がサポートされるようになったことを、ここにお知らせいたします。Elasticsearch 5 は非常に多くの新機能と機能拡張を備えており、Amazon Elasticsearch Service をご利用のお客様はそれらを活用いただけるようになりました。今回の Elasticsearch 5 のリリースには、次のような内容が含まれています。

  • インデックス作成のパフォーマンス: ロックの実装の更新および非同期のトランザクションログ FSYNC による、インデックス作成のスループットの向上
  • 取り込みパイプライン: 受信データは一連の取り込みプロセッサを適用するパイプラインに送信できます。これにより検索インデックスに必要なデータに正確に変換できます。単純な付加アプリケーションから複雑な正規表現アプリケーションまで、20 個のプロセッサが含まれています
  • Painless スクリプティング: Amazon Elasticsearch Service は Elasticsearch 5 のための新しい安全でパフォーマンスに優れたスクリプト言語である、Painless をサポートします。スクリプト言語を使用すると、検索結果の優先順位を変更したり、クエリでインデックスフィールドを削除したり、検索結果を修正して特定のフィールドを戻したりすることができます。
  • 新しいデータ構造: 新しいデータ型である Lucene 6 データ構造をサポートし、半精度浮動小数点、テキスト、キーワード、さらにピリオドが含まれるフィールド名を完全にサポートします
  • 検索と集計: リファクタリング検索 API、BM25 関連性計算、Instant Aggregations、ヒストグラム集計と用語集計の機能強化、再設計されたパーコレーターと完了サジェスタ
  • ユーザーエクスペリエンス: 厳密な設定、本文とクエリ文字列パラメーターの検証、インデックス管理の向上、デフォルトで廃止予定のログを記録、新しい共有割り当て API、ロールオーバーと圧縮 API のための新しいインデックス効率パターン
  • Java REST クライアント: Java 7 で稼働してノード障害時に再試行 (またはラウンドロビン、スニッフィング、要求のログ記録) を処理するシンプルな HTTP/REST Java クライアント
  • その他の向上: 遅延ユニキャストのホスト DNS ルックアップ、再インデックス作成の自動並列タスク、update-by-query、delete-by-query、タスク管理 API による検索のキャンセル

Elasticsearch 5 による強力な新機能や機能強化により、サービスをより迅速に、より容易に提供することができ、さらにセキュリティの強化を図ることができます。マネージド型サービスである Amazon Elasticsearch Service を使うと、お客様は Elasticsearch による次のような機能を活用して、ソリューションを構築、開発、デプロイすることができます。

  • 複数のインスタンスタイプを設定
  • データストレージに Amazon EBS ボリュームを使用
  • 専用マスターノードによるクラスターの安定性の向上
  • ゾーン対応 – 同じリージョン内の 2 つのアベイラビリティーゾーンにまたがるクラスターノード割り当て
  • AWS Identity and Access Management (IAM) によるアクセスコントロールとセキュリティ
  • リソース用にさまざまな地理的場所やリージョンを活用
  • Amazon Elasticsearch ドメインのスナップショットによるレプリケーション、バックアップ、リストア
  • Amazon CloudWatch との統合による Amazon Elasticsearch ドメインメトリクスのモニタリング
  • AWS CloudTrail との統合による設定の監査
  • Kinesis Firehose および DynamoDB などの他の AWS のサービスとの統合による、リアルタイムストリーミングデータの Amazon Elasticsearch Service への読み込み

Amazon Elasticsearch Service では、ダウンタイムなしで動的な変更を行うことができます。インスタンスの追加、インスタンスの削除、インスタンスのサイズの変更、ストレージ設定の変更、その他の変更を動的に行うことができますい。上記の機能のいくつかについて、その機能を具体例でご紹介します。先日の IT/Dev カンファレンスでは、Express.js、AWS Lambda、Amazon DynamoDB、および Amazon S3 を使用して、サーバレスで従業員オンボーディングシステムを構築する方法の説明を、プレゼンテーションさせていただきました。このデモでは、架空のオンボーディングプロセス用の従業員に関する人事データを収集して、DynamoDB に保存しました。収集された従業員データを、会社の人事部門が必要に応じて検索、照会、分析するシナリオを考えてみます。オンボーディングシステムを容易に拡張して、従業員テーブルが DynamoDB Streams を使用して Lambda を起動するようにし、必要な従業員の属性を Amazon Elasticsearch Service に保存することができます。この結果、次のようなソリューションアーキテクチャとなります。

従業員レコードが入力されてデータベースに保存されるたびに、従業員データを Amazon Elasticseach Service に動的に保存してインデックスを作成する方法のみに焦点を当てます。前述の既存のオンボーディングソリューションにこの拡張機能を追加するには、以下の詳細なクラウドアーキテクチャ図に示すように、ソリューションを実装します。

従業員の Amazon Elasticsearch Service へのロードプロセスを実装する方法を見てみましょう。これは上の図に示されている最初のプロセスフローです。Amazon Elasticsearch Service: ドメイン作成 AWS コンソールにアクセスして、Elasticsearch 5 が実行されている Amazon Elasticsearch Service を確認しましょう。ご想像どおり、AWS コンソールのホームから [分析] グループの [Elasticsearch Service] を選択します。

Elasticsearch ソリューションを作成するための最初のステップは、ドメインの作成です。お気付きのとおり、Amazon Elasticsearch Service ドメインの作成時に Elasticsearch 5.1 バージョンを選択できるようになりました。今日の本題は Elasticsearch 5 のサポート開始ですので、Amazon Elasticsearch Service でのドメイン作成にあたり、もちろん 5.1 Elasticsearch エンジンのバージョンを選択します。


[Next] をクリックし、インスタンスとストレージの設定を構成して、Elasticsearch ドメインを設定します。クラスターのインスタンスタイプとインスタンス数は、アプリケーションの可用性、ネットワークボリューム、およびデータのニーズに基づいて決定する必要があります。データの不整合や Elasticsearch のスプリットブレインの問題を回避するために、複数のインスタンスを選択することが推奨されるベストプラクティスです。そこで、今回はクラスター用に 2 つのインスタンス/データノードを選択し、EBS をストレージデバイスとして設定します。

具体的なアプリケーションに必要なインスタンスの数を理解するには、AWS データベースブログの「Get Started with Amazon Elasticsearch Service: How Many Data Instances Do I Need (Amazon Elasticsearch Service をはじめよう: 必要なインスタンス数の算出方法)」の記事を参照してください。あと必要なのは、アクセスポリシーを設定してサービスをデプロイするだけです。サービスを作成すると、ドメインが初期化され、デプロイされます。

これで Elasticsearch Service を実行することができました。次は、データを入力するメカニズムが必要です。DynamoDB Streams を使用して、Amazon Elasticsearch Service への従業員データの動的なデータロードプロセスを実装します。Amazon DynamoDB: テーブルとストリーム DynamoDB コンソールに着手する前に、まずは基本を簡単に確認しましょう。 Amazon DynamoDB はスケーラブルな分散 NoSQL データベースサービスです。DynamoDB Streams は、すべての CRUD オペレーションの順序付けられた時間ベースのシーケンスを DynamoDB テーブル内の項目に提供します。各ストリームレコードには、テーブル内の個々の項目のプライマリ属性の変更に関する情報が含まれています。ストリームは非同期で実行され、実質的にリアルタイムでストリームレコードを書き込むことができます。さらに、ストリームはテーブルの作成時に有効にでき、また既存のテーブルで有効にして変更することができます。DynamoDB Streams の詳細については、「DynamoDB 開発者ガイド」を参照してください。それでは DynamoDB コンソールから、OnboardingEmployeeData デーブルを確認しましょう。

このテーブルには、プライマリパーティションキー UserID があり、これは文字列データ型です。さらにプライマリソートキー Username があり、これも文字列データ型です。ここでは UserID を Elasticsearch のドキュメント ID として使用します。さらにこのテーブルではストリームが有効で、ストリームの表示タイプは New image です。表示タイプが New image に設定されたストリームには、更新された後に項目レコード全体を表示するストリームレコードがあります。ストリームが、変更前のデータ項目を提供するレコードを表示するようにすることもできます。また項目のキー属性のみを提供したり、古い項目と新しい項目の情報を提供したりすることもできます。AWS CLI を使用して DynamoDB テーブルを作成する場合、取得するキー情報は [Stream Details] セクションの下に表示される 最新のストリーム ARN です。DynamoDB ストリームには一意の ARN 識別子があります。これは DynamoDB テーブルの ARN の外にあります。ストリーム ARN は、ストリームと Lambda 関数の間のアクセス権限の IAM ポリシーを作成するために必要です。

IAM ポリシー あらゆるサービスの実装で第一に重要なことは、適切なアクセス権限を設定することです。このため、まずは IAM コンソールを使って、DynamoDB と Elasticsearch にアクセス権限を設定する、Lambda 関数のロールとポリシーを作成します。まず、DynamoDB ストリームを使用した Lambda の実行のための既存の管理ポリシーに基づくポリシーを作成します。

すると次にポリシーの確認画面に移ります。ここでは選択された管理ポリシーの詳細が表示されます。ここでは、このポリシーの名前を Onboarding-LambdaDynamoDB-toElasticsearch として、ソリューション用にポリシーのカスタマイズを行います。現在のポリシーでは、すべてのストリームがアクセス可能であることに注意します。推奨されるベストプラクティスは、最新のストリーム ARN を追加して、このポリシーで特定の DynamoDB ストリームのみがアクセスできるようにすることです。ポリシーを変更して、DynamoDB テーブル OnboardingEmployeeDataARN を追加し、ポリシーを検証します。変更されたポリシーは次のようになります。

あとは、Amazon Elasticsearch Service のアクセス権限をポリシーに追加するだけです。Amazon Elasticsearch Service のアクセス権限のコアポリシーは次のとおりです。

このポリシーを使って、特定の Elasticsearch ドメインの ARN を、ポリシーのリソースとして追加します。これにより、ポリシーのセキュリティのベストプラクティスである、最小権限の原則を適用したポリシーを活用することができます。次のように Amazon Elasticsearch Service ドメインを追加して、ポリシーを検証して保存します。

カスタムポリシーを作成する最も望ましい方法は、IAM Policy Simulator を使用するか、またはサービスドキュメントの AWS のサービスのアクセス権限の例を参照することです。AWS のサービスのサブセットのポリシーの例については、こちらを参照することもできます。最小権限の原則によるセキュリティのベストプラクティスを適用して、必要な ES のアクセス権限のみを追加してください。上記は単なる一例です。アクセスを許可するために Lambda 関数が使用するロールを作成し、そのロールに前述のポリシーをアタッチします。

AWS Lambda: DynamoDB がトリガーする Lambda 関数 AWS Lambda は、アマゾン ウェブ サービスのサーバーレスコンピューティングサービスの中心となるものです。Lambda を使うと、サポートされた言語を使って、事実上あらゆる種類のアプリケーションやバックエンドサービスのコードを作成して実行できます。Lambda は、AWS のサービスまたは HTTP リクエストからのイベントに対応して、コードをトリガーします。Lambda はワークロードに基づいて動的にスケールします。コードの実行に対してのみ料金を支払います。DynamoDB ストリームが Lambda 関数をトリガーし、それによりインデックスが作成され、データが Elasticsearch に送信されます。もう 1 つの方法は、DynamoDB の Logstash プラグインを使用することです。ただし、Logstash プロセッサのいくつかは Elasticsearch 5.1 コアに組み込まれ、さらにパフォーマンスの最適化が向上されているため、今回は Lambda を使用して DynamoDB ストリームを処理し、Amazon Elasticsearch Service にデータをロードすることにします。では AWS Lambda コンソールを使って、Amazon Elasticsearch Service に従業員データをロードするための Lambda 関数を作成しましょう。コンソールでブランク関数設計図を選択して、新しい Lambda 関数を作成します。次に [Configure Trigger] ページに移ります。トリガーページで、Lambda をトリガーする AWS のサービスとして DynamoDB を選択し、トリガー関連オプションとして次のように入力します。

  • テーブル: OnboardingEmployeeData
  • バッチサイズ: 100 (デフォルト)
  • 開始位置: 水平トリム

[Next] をクリックすると、関数の設定画面に移動します。関数の名前を ESEmployeeLoad とし、この関数を Node.4.3 で作成します。

Lambda 関数のコードは次のとおりです。

var AWS = require('aws-sdk');
var path = require('path');

//すべての ElasticSearch ドメイン情報のオブジェクト
var esDomain = {
    region: process.env.RegionForES,
    endpoint: process.env.EndpointForES,
    index: process.env.IndexForES,
    doctype: 'onboardingrecords'
};
//作成された ES ドメインエンドポイントからの AWS エンドポイント
var endpoint = new AWS.Endpoint(esDomain.endpoint);
//AWS 認証情報は環境から取得される
var creds = new AWS.EnvironmentCredentials('AWS');

console.log('Loading function');
exports.handler = (event, context, callback) => {
    //console.log('Received event:', JSON.stringify(event, null, 2));
    console.log(JSON.stringify(esDomain));
    
    event.Records.forEach((record) => {
        console.log(record.eventID);
        console.log(record.eventName);
        console.log('DynamoDB Record: %j', record.dynamodb);
       
        var dbRecord = JSON.stringify(record.dynamodb);
        postToES(dbRecord, context, callback);
    });
};

function postToES(doc, context, lambdaCallback) {
    var req = new AWS.HttpRequest(endpoint);

    req.method = 'POST';
    req.path = path.join('/', esDomain.index, esDomain.doctype);
    req.region = esDomain.region;
    req.headers['presigned-expires'] = false;
    req.headers['Host'] = endpoint.host;
    req.body = doc;

    var signer = new AWS.Signers.V4(req , 'es');  // es: サービスコード
    signer.addAuthorization(creds, new Date());

    var send = new AWS.NodeHttpClient();
    send.handleRequest(req, null, function(httpResp) {
        var respBody = '';
        httpResp.on('data', function (chunk) {
            respBody += chunk;
        });
        httpResp.on('end', function (chunk) {
            console.log('Response: ' + respBody);
            lambdaCallback(null,'Lambda added document ' + doc);
        });
    }, function(err) {
        console.log('Error: ' + err);
        lambdaCallback('Lambda failed with error ' + err);
    });
}

Lambda 関数の環境変数は次のとおりです。

既存のロールのオプションで ESOnboardingSystem を選択します。これは先に作成した IAM ロールです。

Lambda 関数のための IAM ロールのアクセス権限を完成したら、Lambda 関数の詳細を確認し、ESEmployeeLoad 関数の作成を完了します。

Elasticsearch との通信を行う Lambda 関数の構築プロセスは、これで完了です。では、データベースへのデータ変更のシミュレーションを行って、関数のテストを行いましょう。

関数 ESEmployeeLoad は、オンボーディングシステムのデータベースでのデータの変更により実行されます。また、CloudWatch ログを確認することにより、Lambda 関数の Elasticsearch への処理を確認できます。さらに Lambda 関数を変更して新機能を利用したり、直接 Elasticsearch を使って新しい取り込みモードを利用することもできます。たとえば、従業員レコードドキュメントのパイプラインを実装することができます。

この関数を複製して、従業員レコードに合わせてバッジを更新する処理や、従業員データに対するその他のプリプロセッサを活用したりすることができます。たとえば、Elasticsearch ドキュメントのデータパラメーターに基づいてデータを検索する場合、検索 API を使用してデータセットからレコードを取得できます。

可能性は無限です。データのニーズに応じて創造性を発揮しながら、優れたパフォーマンスを確保できます。Amazon Elasticsearch Service: Kibana 5.1 Elasticsearch 5.1 を使用しているすべての Amazon Elasticsearch Service ドメインでは、オープンソースの可視化ツールの最新バージョンである Kibana 5.1 が備えられています。可視化と分析のための補完プラットフォームである Kibana も、Kibana 5.1 リリースで機能強化されました。Kibana を活用すると、さまざまなグラフ、テーブル、マップを使用して、Elasticsearch データの表示、検索、操作を行うことができます。さらに、Kibana は大量データの高度なデータ分析を実行できます。Kibana リリースの主な機能強化は次のとおりです。

  • 可視化ツールの新しいデザイン: カラースキームの更新と表示画面活用の最大化
  • Timelion: 時間ベースのクエリ DSL による可視化ツール
  • コンソール: 従来 Sense と呼ばれていた機能がコア機能の一部となりました。以前と同様の設定を使って、Elasticsearch へのフリーフォームのリクエストを行うことができます
  • フィールドスクリプト言語: Elasticsearch クラスターで新しいスクリプト言語 Painless を使うことが可能
  • タグクラウドの可視化: 5.1 では、データの重要度による単語ベースのグラフィカルビューが追加されました
  • グラフの拡張: 前回削除されたグラフが復活し、さらに X-Pack の高度なビューが追加されました
  • Profiler の UI: ツリービューによる Profile API の拡張を提供
  • レンダリングパフォーマンスの向上: パフォーマンスを向上させ、CPU 負荷を低減

まとめ ご覧いただいたように、このリリースでは Elasticsearch ソリューションの構築に役立つ、広範な機能強化や新機能を備えています。Amazon Elasticsearch Service では新たに、15 個の Elasticsearch API と 6 つのプラグインをサポートします。Amazon Elasticsearch Service は Elasticsearch 5.1 の次のオペレーションをサポートします。

Elasticsearch でサポートされるオペレーションの詳細については、「Amazon Elasticsearch 開発者ガイド」を参照してください。また Amazon Elasticsearch Service のウェブサイトを活用したり、AWS マネジメントコンソールにサインインして開始することもできます。- Tara

 

Amazon EC2 Systems Manager を使用して AMI メンテナンスとパッチ適用を合理化 | 自動化

by AWS Japan Staff | on | in Amazon EC2 |

EC2 シニアプロダクトマネージャーの Taylor Anderson が自動化を利用して AMI メンテナンスとパッチ適用を合理化する方法についてご説明します。-Ana


去年 12 月の re:Invent でリリースした Amazon EC2 Systems Manager では、ソフトウェアインベントリの収集や OS パッチの適用、システムイメージの作成そして Windows や Linux のオペレーティングシステム設定などのプロセスを自動化することができます。こうした機能は自動設定や継続的に行う大規模なシステム管理を自動化し、Amazon EC2 やオンプレミスで実行しているインスタンスのソフトウェアコンプライアンスを維持することができます。Systems Manager には自動化の機能が含まれています。パッチの適用やエージェントの更新、Amazon Machine Image (AMI) にアプリケーションを組み込む場合に、この機能を使用することができます。自動化を使用することで、イメージの更新を手動で行うための時間や労力を省くことができます。代わりに、合理化し繰り返し可能で監査可能なプロセスを通じて AMI を構築することができます。先日、AWS は自動化に関する公開ドキュメントを初めてリリースしました。詳しくは AWS-UpdateLinuxAmi をご覧ください。

このドキュメントは Ubuntu、CentOS、RHEL、Amazon Linux AMI のパッチ適用を自動化できるようしたり、その他のサイト固有のパッケージと設定のインストールも自動化します。さらに、自動化ドキュメントを最初に書く必要を排除することで自動化を取り入れやすくしています。 AWS-UpdateLinuxAmi は、ご自分の自動化ワークフローを構築する場合にテンプレートとして使用することもできます。Windows ユーザーを対象にした、今後公開予定の AWS-UpdateWindowsAmi ドキュメントはこれと同等の内容を提供します。AWS-UpdateLinuxAmi は次のワークフローを自動化します。

  1. ソース Linux AMI から一時 EC2 インスタンスを起動
  2. インスタンスのアップデート
    • インスタンスでユーザー提供の更新前のフックを起動
    • 可能な場合にインスタンスの AWS ツールやエージェントを更新
    • ネイティブパッケージマネージャを使用してインスタンスのディストリビューションパッケージを更新
    • インスタンスでユーザー提供の更新後のフックを起動 (オプション)
  3. 一時インスタンスを停止
  4. 停止したインスタンスから新しい AMI を作成
  5. インスタンスを終了

警告: 実行中のインスタンスから AMI を作成すると、インスタンスの認証情報、社外秘情報、その他の機密情報が新しいイメージに記録される可能性があります。この方法で作成した AMI を管理する場合は十分な注意が必要です。

自動化のロールおよびアクセス権限の設定

過去に自動化を使用したことがない場合は、IAM ロールとアクセス権限を設定してください。これには自動化のサービス作成、passrole を指定してユーザーがサービスロールを提供できるように承認したり、インスタンスロールを作成して System Manager でインスタンス管理を有効にすることも含まれています。詳細については「自動化用にアクセスを設定する」を参照してください。

自動化を実行

      1. EC2 コンソールで [Systems Manager Services] > [Automations] を選択します。
      2. [Run automation document] を選択します。
      3. [Document name] で [AWS-UpdateLinuxAmi] を選択します。
      4. ドキュメントの最新バージョンを選択します。
      5. SourceAmiId に Linux AMI の ID を入力して更新します。
      6. InstanceIamRole に、インスタンスを管理するために System Manager を有効にして作成したインスタンスロール名を入力します (AmazonEC2RoleforSSM 管理ポリシーを含んでいるもの)。詳細については「自動化用にアクセスを設定する」を参照してください。
      7. [AutomationAssumeRole] に、自動化用に作成したサービスロールの ARN を入力します。詳細については「自動化用にアクセスを設定する」を参照してください。
      8. [Run Automation] を選択します。
      9. [Automation Steps] タブで進捗状況を監視し、ステップレベル出力を確認します。

実行が完了したら [Description] を選択してワークフローが返した出力を確認します。この例では AWS-UpdateLinuxAmi が新しい AMI ID を返しています。次に [Images] > [AMIs] を選択して新しい AMI を確認します。

自動化の使用に追加料金はかかりませんが、ワークフローで作成したリソースにはわずかな料金が発生します。「インスタンス削除」のステップに行く前に AWS-UpdateLinuxAmi を終了すると、ワークフローが作成した一時インスタンスは終了します。上記ステップの CLI チュートリアルについては「自動化 CLI チュートリアル: Linux AMI のパッチ適用」をご覧ください。

まとめ

AWS-UpdateLinuxAmi を問題なく実行できたら、サービスやインスタンスロールのデフォルト値を作成することをおすすめします。AWS-UpdateLinuxAmi をベースに、ご自分の自動化ドキュメントを作成してワークフローをカスタマイズすることができます。詳細については「 自動化ドキュメントの作成」をご覧ください。ドキュメント作成が完了したら追加ステップを書いてワークフローに足すことができます。ステップ例をご覧ください。

      • 新しい AMI ID で Auto Scaling を更新 (aws:invokeLambdaFunction アクションタイプ)
      • 新しい AMI の暗号化されたコピーを作成 (aws:encrypedCopy アクションタイプ)
      • RunPowerShellScript で Run Command を使用して新しい AMI を検証 (aws:runCommand アクションタイプ)

自動化はアプリケーションの組み込みに使う CI/CD パイプラインにとって大きな強化点となります。また、Jenkins で CLI 構築ステップとして呼び出すこともできます。こうした例の詳細については、自動化の技術文書を必ずご覧ください。

自動化、Amazon EC2 Systems Manager、Amazon CloudFormation、AWS Config、AWS OpsWorks やその他の管理サービスの更新については、新しい管理ツールのブログをフォローしてください。

EC2 リザーブドインスタンスの新たなインスタンスサイズの柔軟性

by AWS Japan Staff | on | in Amazon EC2 |

リザーブドインスタンスは AWS のお客様がご利用されている EC2 の使用量に対し、大幅な割引を提供します (オンデマンドの料金に比べ最大 75% の割引)。また、特定のアベイラビリティーゾーン (AZ) で使用する RI を購入される際のキャパシティー予約においても同様です。去年後半には、リージョン内の AZ すべてを対象に割引を適用するリージョン RI をリリースし、今まで以上にリザーブドインスタンスの柔軟性を高めました。また、リザーブドインスタンスに関連付けられたインスタンスファミリーやその他のパラメーターを変更できるようにするコンバーティブル RI も提供しました。どちらのタイプの RI も管理に掛かるコストを削減し、追加オプションを提供します。リージョン RI を使用すると、RI 割引の対象になる AZ で起動することを心配せずにインスタンスをスタートできます。コンバーティブル RI を使用する場合、時間が経過するに連れて選択するインスタンスタイプやサイズが変わっても、RI が使用量に適しているか確認することができます。

インスタンスサイズの柔軟性
3 月 1 日より、すでにご利用されているリージョン RI の柔軟性が今まで以上に高まります。一括請求により、複数のアカウントで使用している場合でも、共有テナンシーを持つすべての Linux/UNIX RI をインスタンスファミリーと AWS リージョン内のあらゆるサイズのインスタンスに適用できるようになりました。これにより、RI の管理時間を節約したり、コンピューティングリソースをよりクリエイティブで革新的に使用できるようになります。新しい RI や既存の RI のサイズはインスタンスサイズに基づいた正規化係数により決定されています。

インスタンスサイズ 正規化係数
nano 0.25
micro 0.5
small 1
medium 2
large 4
xlarge 8
2xlarge 16
4xlarge 32
8xlarge 64
10xlarge 80
32xlarge 256

c4.8xlarge の RI をすでに所有しているとします。この RI はそのリージョン内で共有テナンシーを使用する Linux/UNIX C4 インスタンスで適用されるようになりました。例については次をご覧ください。

  • c4.8xlarge インスタンス 1 件
  • c4.4xlarge インスタンス 2 件
  • c4.2xlarge インスタンス 4 件
  • c4.large インスタンス 16 件

また、c4.4xlarge インスタンス 1 件と c4.large インスタンス 8 件といった他の組み合わせも含みます。RI が実行中のインスタンスよりも小さな場合は、オンデマンド料金の日割り計算で余分な容量のコストが請求されます。つまり c4.4xlarge の RI を購入し、大抵の場合そのインスタンスを使用していても、時々 c4.8xlarge インスタンスにスケールアップすることができます。大きいインスタンスには時間単位でオンデマンド料金の半分が請求されます (AWS は可能な限りコストを抑えた状態でお客様がコンピューティング能力にアクセスできるようにすることを目的としています)。大きなインスタンスの RI を所有していて、小さなインスタンスを実行している場合の RI には小さなインスタンスの料金が適用されます。ただし、未使用の予約が蓄積されることはありません。

提供開始
今すぐこの新たな柔軟性をご利用いただけます。これはリージョンの共有テナンシーを使用している Linux/UNIX RI で自動的に適用されます。お客様からの操作は必要ありません。

Jeff;

AWS Microsoft ADとオンプレミスの資格情報を使用してAWS管理コンソールにアクセスする方法

by AWS Japan Staff | on | in AWS Directory Service, AWS Management Console, General |

これは、AWS Security blogに投稿された「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」の翻訳記事です。


 

AWS Microsoft ADと略される、AWS Directory Service for Microsoft Active Directory は、AW​​Sクラウドにホストされた管理されたMicrosoft Active Directory(AD)です。オンプレミスのAD管理ツールを使用して、AWSリソースを管理する権限をユーザに簡単に付与できます。AWS Microsoft ADを使用すると、Identity and Access Management(IAM)を利用してAWSリソースへのアクセス管理をしたり、セキュリティアサーションマークアップ言語(SAML)でADフェデレーションサービス(AD FS)を構成する代わりに、オンプレミスユーザーにAWS管理コンソールなどのリソースへのアクセス許可を与えることができます。

このブログ記事では、AWS Microsoft ADを使用してオンプレミスのADユーザーがオンプレミスのADユーザー資格情報を使用してAWS管理コンソールにサインインし、IAMロールを通じてAWSリソースにアクセスして管理する方法を示します。

 

概要

AWSのお客様は、オンプレミスADを使用してユーザーアカウントを管理し、グループメンバーシップを管理し、オンプレミスリソースへのアクセスを制御します。 多くのAWS Microsoft ADのお客様がいる場合は、オンプレミスのAD資格情報を使用してAWS管理コンソールにサインインして、 Amazon EC2Amazon RDSAmazon S3などのAWSリソースを管理できるようにすることもできます。

このようなサインインパーミッションを有効にすると、主に4つの利点があります。

  1. オンプレミスのADグループ管理者は、IAMの代わりに標準のAD管理ツールを使用して、AWSリソースへのアクセスを管理できるようになります。
  2. ユーザーは、ADとAWS Management Consoleにサインインするために1つのIDのみを記憶すればよくなります。
  3. ユーザーはオンプレミスのAD資格情報でサインインするため、AWS管理コンソールへのアクセスには、AD強制パスワードポリシーの量可能になります。
  4. ADからユーザーを削除すると、AWS Microsoft ADとIAMは自動的にAWSリソースへのアクセスを取り消します。

IAMロールは、AWSリソースを管理する権限を定義する便利な方法を提供します。 AWS Microsoft ADとオンプレミスADの間のAD信頼関係を使用することで、オンプレミスのADユーザーとグループをIAMロールに割り当てることができます。 これにより、割り当てられたユーザとグループにAWSリソースを管理するためのIAMロールの権限が与えられます。 オンプレミスのADグループをIAMロールに割り当てることで、ADユーザとコンピュータ(ADUC)などの標準的なAD管理ツールを使用してAWSアクセスを管理できるようになります。

オンプレミスのユーザーやグループをIAMロールに割り当てた後、ユーザーはオンプレミスのAD資格情報を使用してAWS管理コンソールにサインインできます。 そこから、割り当てられたIAMロールのリストを選択できます。 ロールを選択すると、IAMロールに割り当てた管理機能を実行できます。

この記事の残りの部分では、これを4つのステップで達成する方法を示します。

  1. アクセスURLの作成。
  2. AWS管理コンソールへのアクセスの有効化。
  3. オンプレミスのユーザーとグループをIAMロールへの割り当て。
  4. AWS管理コンソールへの接続。

 

前提条件

このブログ記事の指示に従い、次のコンポーネントを実行する必要があります。

  • AWSクラウドで作成されたMicrosoft ADディレクトリ。 詳細については、「Create a Microsoft AD Directory」を参照してください。
  • 既存のオンプレミスActive Directory。
  • AWS Microsoft ADからオンプレミスActive Directoryへの双方向におけるフォレストの信頼関係。 詳細は、「Now Available: Simplified Configuration of Trust Relationships in the AWS Directory Service Console」を参照してください。 信頼に関する追加情報、およびAWS管理コンソールへのドメインレスサインインのアクセス方法については、「How to Easily Log On to AWS Services by Using Your On-Premises Active Directory」を参照してください。
  • AWSディレクトリサービスに設定された信頼関係を持つIAMロール。 これを行うにはヘルプが必要な場合は、「Editing the Trust Relationship for an Existing Role」を参照してください。

注: AWS Microsoft ADに格納されているユーザーIDにIAMロールを割り当てることができます。この記事では、オンプレミスのADに格納されているユーザーIDにIAMロールを割り当てることに重点を置いています。 これには、オンプレミスのActive DirectoryとAWS Microsoft ADディレクトリの間にフォレストの信頼関係が必要です。

 

ソリューションの概要

私が自分の会社のADとIAMロールの両方を管理する管理者だとします。私の会社では、全従業員がオンプレミスの資格情報を使用してAWS管理コンソールにサインインし、AWSリソースにアクセスして管理できるようにしたいと考えています。私の会社はEC2、RDS、S3を使用しています。これらのリソースへの管理権限を管理するために、サービスに完全にアクセスできるように各サービスの権限を作成しました。これらのロールにEC2FullAccess、RDSFullAccess、および、S3FullAccessという名前を付けました 。

私の会社には責任の異なる2つのチームがあり、ADセキュリティグループのユーザーを管理しています。 MaryはDevOpsセキュリティグループのメンバーであり、RDSデータベースの作成と管理、EC2でのデータ収集アプリケーションの実行、S3での情報のアーカイブを担当しています。JohnとRichardはBIMgrsセキュリティグループのメンバーで、EC2を使用してデータベースに対して分析プログラムを実行します。 JohnンとRichardはデータベースとアーカイブされた情報にアクセスする必要がありますが、それらのシステムを操作する必要はありません。EC2インスタンスを管理するための許可が必要です。

AWSリソースへの適切なアクセスを許可するには、ADのBIMgrsセキュリティグループをIAMのEC2FullAccessロールに割り当て、 DevOpsグループを3つのロール(EC2FullAccess 、RDSFullAccess、およびS3FullAccess)すべてに割り当てる必要があります。また、AWS Management Consoleにサインインした後で、従業員全員が十分な管理作業を完了できるようにしたいので、コンソールセッションタイムアウトを60分から240分(4時間)に増やします。

次の図は、私の会社のADユーザーとグループと私の会社のAWSの権限とサービスの関係を示しています。 図の左側は、ユーザーとグループを含む私のオンプレミスのADを表しています。 右側は、AWS管理コンソール、AWSリソース、IAMロール、およびオンプレミスADにフォレストの信頼関係を介して接続されたAWS Microsoft ADディレクトリを含むAWSクラウドを表しています。

 

このシナリオの手順を開始しましょう。この記事では、すでにAWS Microsoft ADディレクトリが作成されており、AWS Microsoft ADからオンプレミスADへの双方向フォレストの信頼を確立しています。AWSリソースへのアクセスを管理するため、以下のIAMロールも作成してあります。

  • EC2FullAccess :EC2へのフルアクセスを提供し、 AmazonEC2FullAccess AWS管理ポリシーを添付します。
  • RDSFullAccess :AWS管理コンソール経由でRDSへのフルアクセスを提供し、 AmazonRDSFullAccess管理ポリシーを添付します。
  • S3FullAccess :AWS管理コンソール経由でS3へのフルアクセスを提供し、 AmazonS3FullAccess管理ポリシーを添付します。

IAMロールを作成して管理ポリシーを添付する方法の詳細については、「管理ポリシーのアタッチ」を参照してください。

注: Microsoft ADを使用してAWS管理コンソールにサインインするユーザーがアクセスする必要があるすべてのロールに、ディレクトリサービス信頼ポリシーを含める必要があります。 詳細は、「Editing the Trust Relationship for an Existing Role」を参照してください。

 

ステップ1 – アクセスURLを作成する

AWS Management Consoleへのアクセスを有効にするための最初の手順は、AWS Microsoft ADディレクトリのための一意のアクセスURLを作成することです。アクセスURLは、グローバルに一意のURLです。AWS管理コンソールなどのAWSアプリケーションは、URLを使用して、AWS Microsoft ADディレクトリにリンクされているAWSサインインページに接続します。 アクセスURLは、ディレクトリへの他のアクセスを提供しません。 アクセスURLの詳細については、「Creating an Access URL」を参照してください。

アクセスURLを作成するには、次の手順を実行します。

 

  1. ディレクトリサービスコンソールに移動し、AWS Microsoft AD Directory IDを選択します。
  2. Directory Detailsページで、Apps & Services タブを選択し 、Access URL ボックスに一意のアクセスエイリアスを入力し、 Create Access URLを選択してディレクトリのアクセスURLを作成します。ディレクトリのアクセスURLは、 <access-alias> .awsapps.comという形式にする必要があります。 この例では、 https://example-corp.awsapps.comを使用しています。

 

ステップ2 – AWS管理コンソールへのアクセスを有効にする

ユーザがオンプレミスの認証情報でAWS Management Consoleにサインインできるようにするには、AWS Microsoft ADディレクトリのAWS管理コンソールアクセスを有効にする必要があります。

  1. ディレクトリサービスコンソールから、AWS Microsoft AD Directory IDを選択します。 AWS apps & servicesセクションのAWS Management Consoleリンクを選択します。
  2. Enable AWS Management Consoleダイアログボックスで、 Enable Accessを選択して、ディレクトリに対するコンソールアクセスを有効にします。

    これにより、AWS Microsoft ADディレクトリのAWS Management Consoleへのアクセスが可能になり、コンソールに接続するためのURLが提供されます。 URLは、ステップ1: <access-alias>.awsapps.com/consoleで作成したアクセスURLの末尾に「 /console 」を付加して生成されます。 この例では、AWS管理コンソールのURLは、https://example-corp.awsapps.com/consoleです。

 

ステップ3 – オンプレミスのユーザーおよびグループをIAMロールに割り当てる

ユーザーがアクセスURLを使用してAWS管理コンソールにサインインする前に、オンプレミスのユーザーまたはグループをIAMロールに割り当てる必要があります。このステップで、オンプレミスのユーザーおよびグループがAWS管理コンソールからアクセス可能なAWSリソースを制御できます。

私のオンプレミスのActive Directoryでは、 Maryは既にDevOpsグループのメンバーであり、JohnとRichardはBIMgrsグループのメンバーです。私はすでにAWS Microsoft ADから私のオンプレミスADへの信頼関係を確立しました。EC2FullAccess 、RDSFullAccessおよびS3FullAccessの権限を作成できました。

これで、オンプレミスグループをIAMロールに割り当てる準備が整いました。私はDevOpsグループをEC2FullAccess、RDSFullAccess 、およびS3FullAccess IAMロールに割り当て、BIMgrsグループをEC2FullAccess IAMロールに割り当てます。オンプレミスグループをIAMロールに割り当てるには、次の手順に従います。

  1. AWS Microsoft ADディレクトリのディレクトリサービスの詳細ページを開き、Apps & servicesタブのAWS Management Console リンクを選択します。 Continue を選択して、 Add Users and Groups to Rolesページに移動します。
  2. Add Users and Groups to Rolesページでは、既に設定した3つのIAMロールが表示されます(次のスクリーンショットを参照)。 ディレクトリサービス信頼ポリシーが有効なIAMロールがない場合は、 新しいロールを作成するか、既存のロールに対してディレクトリサービスを有効にすることができます。
  3. オンプレミスのDevOpsグループとBIMgrsグループをEC2FullAccessロールに割り当てます。これを行うために、私はEC2FullAccess IAMロールリンクを選択して、Role Detailページに移動します。 次に、次のスクリーンショットに示すように、 Addボタンをクリックしてユーザーまたはグループをロールに割り当てます。
  4. Add Users and Groups to Role ポップアップウィンドウで、割り当てるユーザーとグループを含むオンプレミスのActive Directoryフォレストを選択します。 この例では、そのフォレストはamazondomains.comです。 注:オンプレミスADへの信頼を使用せず、AWS Microsoft ADディレクトリにユーザーとグループを作成する場合は、 このフォレストのデフォルトを選択してMicrosoft ADのユーザーを検索できます。
  5. Active Directoryグループを割り当てるには、Search forフィールドの上にあるGroupフィルタを選択します。 検索ボックスにActive Directoryグループの名前を入力し、検索ボタン(虫眼鏡のマークを選択します。 私はオンプレミスのActive DirectoryからDevOpsグループを検索できたことがわかります。
  6. この例では、社内のグループDevOpsとBIMgrsをEC2FullAccessロールに追加しています。終了したら、Addボタンを選択して、ユーザとグループをIAMロールに割り当てます。 これで、DevOpsとBIMgrsオンプレミスADグループにEC2へのフルアクセスが正常に付与されました。これらのADグループのユーザは、自社の認証情報を使用してAWS管理コンソールにサインインし、EC2インスタンスを管理できるようになりました。
    Add Users and Groups to Rolesページから、残りのグループをIAMロールに割り当てるプロセスを繰り返します。次のスクリーンショットでは、DevOpsグループを3つのロールに、BIMgrsグループを1つのロールに割り当てたことがわかります。
    ADセキュリティグループを自分のIAMロールに割り当てることで、オンプレミスユーザーをセキュリティグループに追加および削除して、IAMロールへのアクセス許可を付与または取り消すことができます。これらのセキュリティグループのユーザーは、割り当てられたすべての権限にアクセスできます。
  7. オプションで、AWS Microsoft ADディレクトリのログインセッション長を設定できます。デフォルトの長さは1時間ですが、最大12時間まで延長できます。私の例では、コンソールのセッション時間を240分(4時間)に設定しています。

 

ステップ4 – AWS管理コンソールに接続する

私は、ユーザが自社の認証情報でAWS Management Consoleにサインインできるようになりました。 ステップ2で作成したアクセスURL: https://example-corp.awsapps.com/consoleを自社のユーザーにメールで送信しました。 これで、ユーザーはURLにアクセスしてAWS Management Consoleにサインインできます。

DevOpsグループのメンバーであるMaryがアクセスURLにアクセスすると、AWS Management Consoleに接続するためのサインインページが表示されます。 Usernameボックスでは、3つの方法でサインイン名を入力できます。

  • 社内のNetBIOSログイン名(corp\mary)の指定。
  • 彼女の完全修飾ドメイン名(FQDN)のログイン名( amazondomains.com\mary)の指定。
  • ドメインなしのログインで彼女のユーザー名だけを使用。ドメインレスログインの詳細については、「How to Easily Log On to AWS Services by Using Your On-Premises Active Directory」を参照してください。

DevOpsグループは3つのIAMロールに関連付けられており、MaryはDevOpsグループに属しているため、ログイン後に表示されるリストから希望するロールを選択できます。次のスクリーンショットはこのステップを示しています。

マルチファクタ認証(MFA)を使用してAWS管理コンソールを保護する場合は、AWS Microsoft AD設定にMFAを追加することもできます。 Microsoft ADでMFAを有効にする方法の詳細については、「How to Enable Multi-Factor Authentication for AWS Services by Using AWS Microsoft AD and On-Premises Credentials」を参照してください。

まとめ

AWS Microsoft ADを使用すると、オンプレミスの資格情報を使用してAWS管理コンソールに簡単に接続できます。 また、AWSリソースへのアクセスを制御しながら、パスワード有効期限、パスワード履歴、アカウントロックアウトポリシーなどの社内ADセキュリティポリシーを再利用することもできます。

ディレクトリサービスの詳細については、 AWS Directory Serviceのホームページを参照してください 。 このブログの投稿に関するご質問がある場合は、 ディレクトリサービスフォーラムで新しいスレッドを開始してください。

– Vijay


 

翻訳:瀧澤与一(原文:「How to Access the AWS Management Console Using AWS Microsoft AD and Your On-Premises Credentials」 – https://aws.amazon.com/blogs/security/how-to-access-the-aws-management-console-using-aws-microsoft-ad-and-your-on-premises-credentials/