こんにちは、技術4課の城です。
今回は既存Webシステムへの外部からのアクセスに対する認証として、ALBの認証機能を利用する検証をしてみました。
通常は社内ネットワークからDirectConnectやVPN回線経由で利用しているシステムに対して、インターネット経由の窓口としてのALBを追加するような用途を想定しています。

要件

要件としては下記となります。

• 既存社内Webシステムに対して、外部からアクセスさせる。
• 既存Webシステムの変更は行わない。
• Webシステムにアクセスさせる前段で多要素認証を実施。（ログイン画面へのアタック防止）

概要

検証してみた結果、下記の構成は実現することが出来ました。

• ホストベースのルーティングにて複数システムを1つのALBに紐づけ
• CognitoユーザープールでのSMSによる多要素認証

構成図は下図となります。

利用したサービス一覧

利用したサービスとおおまかな内容は下記となります。

• Route53
  • ALBへのエイリアスレコードの登録
  • ワイルドカード証明書作成のための検証
• ACM
  • ワイルドカード証明書作成
• ALB
  • HTTPSリスナー
  • ホスト名ベースのルーティング
  • 認証
  • ターゲットグループは各システム用に２つ作成
• Cognitoユーザープール
  • ユーザープールは各システム用に２つ作成
  • 多要素認証はSMSを利用
• EC2
  • 仮想社内システム用

Cognitoユーザープールの作成

それぞれのシステム用に2つのユーザープールを作成します。

プール名の指定

属性の指定

今回はEメールアドレスをユーザー名としました。
SMSでの多要素認証を利用するため、phone numberも必須としています。

ポリシーの指定

パスワード強度、有効期限はデフォルトのまま、管理者のみユーザの作成を許可としています。

MFAの設定

今回はMFA必須、SMSテキストメッセージでの認証としています。
Eメール、電話番号の検証を必須とし、[ロールの作成]ボタンをクリックしてSMS送信に必要なIAMロールを作成します。

後で調べたところ、下記のポリシーが付与されたロールが作成されていました。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "sns:publish"
            ],
            "Resource": [
                "*"
            ]
        }
    ]
}

Amazon SNSのサービス上限

ここでちょっと気になるメッセージが出ていました。

重要：ユーザーに SMSメッセージを送信して電話番号の確認やMFAを行うには、Amazon SNSに対して使用量の上限の引き上げをリクエストする必要があります。

Amazon SNSのデフォルトのSMSメッセージ使用量上限は1$となっており、十数通メッセージを送ると上限に達してしまいます。
SMSメッセージの料金表は下記です。
https://aws.amazon.com/jp/sns/sms-pricing/

AWSサポートへの上限緩和申請とSNSのアカウントの使用制限の設定を忘れずに行っておきましょう。

私はこのblogの検証環境を得意気に上司に見せている時に上限にかかり、ワンタイムパスワードが送信されず、半泣きになってました。
SMS14通目でした。絶対に忘れません。

メッセージのカスタマイズ

デフォルトのままとしました。

タグ

タグはなしで[次のステップ]にいきます。

デバイスの記憶

デバイスの記憶はなしで[次のステップ]にいきます。

デバイスの記憶について詳細は下記をご参照ください。
https://docs.aws.amazon.com/ja_jp/cognito/latest/developerguide/amazon-cognito-user-pools-device-tracking.html

アプリクライアントの設定

[アプリクライアントの追加]をクリックします。

デフォルト設定のまま、アプリクライアント名を入力し、[次のステップ]をクリックします。

[次のステップ]をクリックします。

トリガー

こちらもデフォルトのまま[次のステップ]をクリックします。

確認と作成

設定値を確認し[プールの作成]をクリックします。

作成できました。

アプリクライアントの設定追加

下記ドキュメントを参考にして、設定を行いました。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/listener-authenticate-users.html
実際にした設定としては下記となります。

ドメイン名の指定

ここではAmazon Cognitoのサインインページで利用されるドメインを指定します。
今回はホストされたドメインを利用しました。

ユーザーの作成

ユーザープールの管理画面の[ユーザーとグループ]にて[ユーザーの作成]をクリックします。

必要な情報を入力します。
注意点ですが、電話番号は国番号を含めた形で記載する必要があります。
【誤】

【正】

ユーザーを作成できました。

Cognitoの設定は以上です。

ワイルドカード証明書の作成

ALB認証はHTTPSリスナーのみ利用できますので、今回はACMにてワイルドカード証明書を作成しておきます。
作成手順についてはこちらをご覧ください。

ターゲットグループの作成

こちらもそれぞれのホスト用に2つのターゲットグループ、ブラックホール用のターゲットグループを１つ作成します。
ホスト用には仮想社内システムとして作成した、２台のEC2をそれぞれ登録しました。
ブラックホール用にはインスタンスの登録されていないターゲットグループを作成します。
これはデフォルトのルールに適用し、レスポンスを返さないようにするためです。
デフォルトのルールに該当するアクセスは、具体的にはALBのエンドポイントに直接アクセスをされるケースを想定しています。

ALBの作成

ALBを作成します。
詳細な作成方法については省略します。
ポチポチっと作成しましょう。

リスナーのルールの設定

下記のように設定しています。

Route53の設定

構成図にも記載のとおり、下記サブドメインのエイリアスレコードに作成したALBを登録しました。
ap01.testdomain-jo.tk
ap02.testdomain-jo.tk

アクセス確認

アクセスしてみます。
【ID・パスワード認証画面】

【ワンタイムパスワード認証画面】
登録した電話番号にSMSでワンタイムパスワードが送られてくるので入力します。

ap01にアクセスできました！

ap02も同様に認証後、アクセスできました。

最後に

全くなれない認証の分野ではあったのですが、ある程度容易に多要素認証を追加することが出来ました。
個人的にはCognito、OAuth2.0の仕様などについて、もう少し深く理解していきたいところです。

「わたしと仕事、どっちが大事なの？」
「チョコ味といちご味、どっちが好き？」
「こっちのレジとあっちのレジ、どっちがすいてる？」

記録的な猛暑の中、争いながら萎れてる僕らは人間は
どうしてこうも比べたがるのでしょう？

かく言う自分も、夏の日差しに溶けながら、こんなことを思ったのでした。

「ELBって、ALBとNLBとCLBって何が違うの？」

AWSが提供している比較表

Elastic Load Balancing 製品詳細　というページの
「Elastic Load Balancing 製品の比較」という項目内に比較表が掲載されています。
これをみると、ELBの機能比較がひと目でわかります。
これで済ますと、ブログが終わってしまうので、特にNLBについて、上記の表に、6点ほど記載項目の補足事項を記載してみました。（2018年7月時点の仕様をベースにしています。）

補足事項の説明

※1 アクセスログ出力は非対応

ALBとCLBは、アクセスログをS3バケットに出力することができますが、NLBはアクセスログの出力に対応していません。表中の「ログ」は、VPC フローログとCloudTrail ログを意味しているものと思われます。

※2 IPアドレスでのターゲット設定時は、ソースIPアドレスの保持は無効となる／※5 インスタンスでのターゲット設定時に限る

NLBは、ターゲットグループの設定方法によって、ターゲットグループ内のノードに到達するパケットのソースIPアドレスが変わります。

ターゲットグループの設定をインスタンスIDで行った場合

ターゲットグループ内のノードに到達するパケットのソースIPアドレスは、クライアントのIPアドレスになります。

ターゲットグループの設定をIPで行った場合

ターゲットグループ内のノードに到達するパケットのソースIPアドレスは、NLBのIPアドレスになります。

※3 作成時に指定することは不可。作成時に自動付与されたものが維持される

NLBに付与されるIPアドレスは、静的IPアドレスです。ただし、後述のElastic IP アドレスを指定しない限り、Private IPアドレスや、Public IPアドレスを特定のものを指定することはできません。NLB作成時に自動付与されたIPアドレスが維持され静的IPとなります。

※6 Internet Facingの場合、ターゲットのインスタンスは、0.0.0.0/0宛としてインターネットへの経路を保持しておかなければならない

NLBをInternet Facing構成で使う場合、ターゲットグループ内のEC2インスタンスは、Internet Gatewayや、NAT Gatewayもしくはパブリックサブネットの EC2 インスタンスへのルートを 0.0.0.0/0 と指定しておく必要があります。

と、ここまで書いて思い出しましたが、セキュリティグループの付与が、NLBにはできない点も、重要な比較ポイントでした。

まとめ

NLBについて、比較表内の補足事項を記載してみましたが、今後の機能追加や仕様変更で、上記内容が変更する可能性もありますので、ご注意ください。

技術4課の鎌田(裕)です。
元々プログラマーだった経歴がある私、時々コードを書きたくなる時があります。
そんな私が遭遇した問題が、「CloudFrontで429のステータスを受けた時に、エラーページを返したい」というもの。

Cloud Frontはエラーページの設定がありますが、残念ながら429のステータスコードを受けた時に限ってはエラーページの設定が出来ません。
ならば実装してしまえ、ということで試してみました。
ここで登場するのがLambda@Edgeです。

Lambda@Edgeとは

Lambda@Edgeは、Cloud Frontと組み合わせて使うサービスで、Cloud Frontに対してのリクエストやレスポンスに対し、Lambda Functionを実行して、リクエストやレスポンスを変更出来る、というものです。

AWSドキュメントにも記載がありますが、Cloud Frontの以下のリクエスト、レスポンスを変更できます。

• CloudFront がビューワーからリクエストを受信した後 (Viewer request)
• CloudFront がリクエストをオリジンサーバーに転送する前 (Origin request)
• CloudFront がオリジンからレスポンスを受信した後 (Origin response)
• CloudFront がビューワーにレスポンスを転送する前 (Viewer response)

エラーページの実装は、3つ目のOrigin responseを変更することになります。

Lambda@Edge実装上の注意

Lambda@Edgeには実装上の注意がいくつかあります。
AWSドキュメントも参考にしてください。

特に、以下の3つは把握しておかないと、実装する時に躓きますので注意しましょう。

• 対応言語はNode.jsのみ。バージョンは6.10と8.10に対応。
• Cloud Frontに設定するには、バージョン番号を付ける必要がある。$LATESTやALIASは不可。
• Lambda@EdgeのLambda Functionはus-east-1(バージニア北部)で作成する必要があります。

なおLambda@EdgeをCloud Frontに設定すると、Frontに設定したタイミングの都度、Lambda Functionが実行されます。
Lambda@Edgeも通常のLambda Function同様に、スロットリングが発生します。
このため、アクセス数を考慮し、事前にLambda Functionでスロットリングが起きないよう、上限緩和申請を実施されることをお勧めします。

Lambda Functionのソースコード

実装したサンプルコードはこちらです。
Node.js 6.10で動作確認をしています。

'use strict';

let content = `<\!DOCTYPE html>
<html lang="jp">
<head><title>Sorry!</title></head>
<body>
<h2>Service Temporarily Unavailable. Please try again later.</h2>
</body>
</html>`;

exports.handler = (event, context, callback) => {
    const response = event.Records[0].cf.response;

    if (response.status >= 400 && response.status <= 599) {
        response.status = 200;
        response.statusDescription = 'OK';
        response.headers['content-type'] = [{
            key: 'Content-Type',
            value: 'text/html'
        }];
        response.body = content;

      console.log(response.headers['content-type']);

    }

    callback(null, response);
};

このソースコードでは、オリジンから受け取ったレスポンスのhttpステータスコードを確認し、400番台と500番台の場合、レスポンスのステータスを200に書き換え、htmlの中身をsorryページに変更しています。
sorryページの内容は、ソースコードを書き換えていただければご利用いただけます。
簡単に実装できることがお分かりいただけるかと思います。

おわりに

Lambda@Edgeのポイント、ご理解いただけたでしょうか。
実装も、そこまで敷居が高くないことをご理解いただけたと思います。
次の記事で、実際にCloud Frontに設定する方法をご案内したいと思います。

Amazon Transcribeを利用する時のIAMポリシーについて Part1では、IAMポリシーで設定できるアクションは3つと述べましたが、Amazon Transcribeの機能を考えるとアクションが3つしかないはずがありません。

Amazon Transcribeのアクション

APIリファレンスを見てみると、Amazon Transcribeのアクションは全部で8つ。前回の3つに加えて、

• CreateVocabulary
• DeleteVocabulary
• GetVocabulary
• ListVocabularies
• UpdateVocabulary

があります。

Vocabulary(カスタム語彙)とは

今回はあまり詳しくは紹介しませんが、Amazon TranscribeではVocabulary(カスタム語彙)を登録することで、文字起こしの精度を高めることができます。テキストファイルやCSVに語句を入力しておき、Amazon Transcribeへアップロードします。ユーズケースとしては、業界用語や製品名など一般的な語句ではない文字起こしをする、というよなことが考えられます。今回はカスタム語彙に関する操作を許可する権限について説明します。

IAMポリシーをつくってみる

ビジュアルエディターではカスタム語彙のアクションが見あたらないので、JSONで書いてみることに。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "transcribe:CreateVocabulary",
                "transcribe:GetVocabulary",
                "transcribe:ListVocabularies",
                "transcribe:UpdateVocabulary",
                "transcribe:DeleteVocabulary"
            ],
            "Resource": "*"
        }
    ]
}

すると…

「識別されないアクション」だと…

ひょっとして権限いらない？

ひょっとするとカスタム語彙を操作するのに何も権限がいらないとか…

そんなことはありませんでした。
not authorized to perform: transcribe:ListVocabularies

では、どうするか？

AWS管理のポリシーにAmazonTranscribeFullAccessとうのがあったのでそれを使うことに。
中身は↓な感じ。Amazon TranscribeのすべてのアクションとS3のGetObjectが許可されています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "transcribe:*"
            ],
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject"
            ],
            "Resource": [
                "arn:aws:s3:::*transcribe*"
            ]
        }
    ]
}

すると…

うん、見えました。

カスタム語彙へのアクションの許可

どうやら、カスタム語彙へのアクションのみを許可することはできない仕様のようです。まあ、だからと言って困ることはないと思います。AmazonTranscribeReadOnlyAccessというポリシーもあり、そちらを確認すると…

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "transcribe:Get*",
                "transcribe:List*"
            ],
            "Resource": "*"
        }
    ]
}

このようにGet*とList*でジョブとカスタム語彙の読み込み両方が許可されています。カスタム語彙へのアクションの中でも、GetVocabularyを許可したい、ListVocabulariesを許可したいという場合はこれでOKです。もちろんこれだと、GetTranscriptionJob/ListTranscriptionJobsも同時に許可されます。CreateVocabulary・DeleteVocabulary・UpdateVocabularyを許可したい場合はAmazonTranscribeFullAccessのようにAmazon Transcribeの全てのアクションを許可する必要があります。
IAMポリシーでは、カスタム語彙へのアクションの許可を細かくは管理できず、カスタム語彙へのアクションを許可しようとすると、ジョブへのアクションも許可するということです。

つづく…

　こんにちは、サーバーワークスのこけしの人、坂本（@t_sakam）です。今回は、先日リリースされたAlexa Skills Kit SDK for Python (Beta) を使って、昨日（7月26日）発売したEcho Spot用のスキルを作ってみたいと思います。

　今回は、公式のGitHubにあるサンプルを少しアレンジして、簡単なEcho Spot用の「画像が表示されるスキル」を作ります。こけしの系統である「ナルコ」か「トーガッタ」を選ぶと、Echo Spotの画面に「鳴子系か遠刈田系のこけしの顔が表示される」という簡単なスキルです。
　それでは、作ってみましょう！

Amazon Developer ServicesのAlexa Skills Kitでスキル作成

スキルの作成

　まずはAmazon Developer Servicesにログインします。［Alexa Skills Kit］タブ – Alexa Skills Kitのトップのスキル一覧ページで［スキルの作成］ボタンをクリックします。
　［新しいスキルを作成］ページでスキル名を「こんにちはこけし」、デフォルトの言語を「日本語」に設定します。

　［スキルに追加するモデルを選択］の箇所では「カスタム」を選択し、［スキルを作成］ボタンをクリックします。

呼び出し名の入力

　左のメニューから［呼び出し名］を選択します。［スキルの呼び出し名］の箇所で「こんにちはこけし」と入力します。

カスタムインテントを作成

　左メニューの［インテント（3）］の横の［追加］リンクをクリックします。ラジオボタンで［カスタムインテントを作成］を選択します。「HelloKokeshiIntent」と入力し、［カスタムインテントを作成］ボタンをクリックします。

カスタムスロットタイプを作成

　左メニューの［スロットタイプ（0）］の横の［追加］リンクをクリックします。ラジオボタンで［カスタムスロットタイプを作成］を選択します。「KOKESHI_ITEM_LIST」と入力し、［カスタムスロットタイプを作成］ボタンをクリックします。

スロット値の設定

　作成された「KOKESHI_ITEM_LIST」にスロット値を設定します。「このスロットタイプの新しい値を入力」と書かれた入力ボックスに「ナルコ」と入力し、左の［＋］ボタンをクリックします。続けて、「トーガッタ」と入力し、左の［プラス］ボタンをクリックし、スロット値を設定します。

インテントスロットとサンプル発話の設定

　［インテントスロット］一覧の1番目の「新しいスロットを作成」と書かれた入力欄に「Kokeshi」と入力し、［＋］ボタンをクリックします。左のスロットタイプは先程作成した「KOKESHI_ITEM_LIST」を選択します。

　上のサンプル発話は「このインテントの呼び出しに使われると考えられる発話」と書かれた入力ボックスに「{Kokeshi}」と入力し、左の［＋］ボタンをクリックします。

インターフェイスの設定

　左メニューから［インターフェイス］を選択します。

　このスキルは、画面と音声対話の両方を使用するので［Displayインターフェイス］を有効にします。

　有効後は、画面操作向けの［ビルトインテント］が左メニューで増えています。

スキルIDをコピー

　左メニューから［エンドポイント］を選択します。ラジオボタンで［AWS LambdaのARN］を選択します。すると、このスキルのスキルIDが表示されます。あとで使うので、コピーして控えておきます。

モデルの保存とビルド

　ここまでできたら、いったんモデルの保存とビルドをおこなっておきます。上の方にある［モデルを保存］ボタンをクリックします。保存が終わったら、［モデルをビルド］ボタンをクリックします。

Alexa Skills Kit SDK for Python

　開発環境（EC2）で、スキル用のディレクトリ「hello_kokeshi」を作成し、作成したディレクトリに移動します。
　このディレクトリに以下のコマンドでAlexa Skills Kit SDK for Pythonをインストールします。

pip install ask-sdk -t .

Serverless　Framework

　Serverless　Frameworkで必要なファイルを自動生成します。

serverless create --template aws-python3

Serverless Framework参考記事
http://blog.serverworks.co.jp/tech/2016/09/07/serverless-framework-1-beta-1/

「serverless.yml」ファイルの編集

　自動生成された「serverless.yml」ファイルを以下の画像のように編集します。ここで先程控えておいたスキルIDを使います。

handler.py

　Alexa Skills Kit SDK for Python (Beta) の公式Githubにあるサンプル「Hello World」のコードをコピーし、画像を扱うのに必要なクラスを追加で読み込んだり、Echo Spotで画像を表示したい箇所や、文言を編集します。

サンプル「Hello World」
https://github.com/alexa-labs/alexa-skills-kit-sdk-for-python/blob/master/samples/HelloWorld/skill_using_decorators/hello_world.py

　以下のコードの赤枠の箇所で、画面付きのデバイスかどうかをチェックして、処理を分岐しています。そうしておかないと、画面なしのデバイスで実行した場合にうまく動かないためです。画面付きのデバイスから実行された場合は、バックグラウンドにこけしの顔の画像を表示するようにしています。

デプロイ

　Serverless　Frameworkでデプロイします。

serverless deploy

仕上げ

LambdaファンクションのARNをコピー

　AWSのマネジメントコンソールにログインします。作成されたLambdaファンクションを表示し、画面右上のARNをコピーして控えておきます。

エンドポイントを設定

　Amazon Developer ServicesのAlexa Skills Kitのエンドポイントのページに戻ります。先程控えたLambdaファンクションのARNを［デフォルトの地域］に入力し、画面上の［エンドポイントを保存］ボタンをクリックして、設定を保存します。

公開設定

　画面上の［公開］タブをクリックします。まだスキルは公開しませんが、ベータテストに招待した人がAlexaアプリでみたときにわかりやすいようにアイコンなど一応設定しておきます。


　ベータテストに招待された人がAlexaアプリで確認すると以下のようになります。

テスト

　画面上の［テスト］タブをクリックしてテストしてみましょう。

ナルコを選んだ場合

トーガッタを選んだ場合

ヘルプ

　ヘルプのときはサンプルの「Hello World」の文言しかいじっていないので、カードの表示となっています。

まとめ

　今回は、Alexa Skills Kit SDK for Python (Beta) を使って、昨日発売したEcho Spot用のスキルを作ってみました。

　サンプルの「Hello World」を少しいじった簡単なスキルですが、よいスキルができたのではないでしょうか？
　画像を使うことによって伝えられる情報が増えるので、Alexaの活用方法がますます広がりそうですね！ SDKにPythonが加わったのも、Pythonユーザーには嬉しい限り！

　いや〜、ASK SDK for PythonとEcho Spotって本当にいいものですね！

前回はカスタム語彙へのアクションに必要な権限について説明しました。ジョブの実行時にカスタム語彙を指定できますが、カスタム語彙を指定したジョブを実行するときにはどんな権限が必要になるのでしょうか？

コンソールの場合

まずは以下のような権限で試してみます。ジョブ関連のアクションとS3:GetObjectを許可しています。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "transcribe:GetTranscriptionJob",
                "transcribe:StartTranscriptionJob",
                "transcribe:ListTranscriptionJobs"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::sample-bucket/*"
        }
    ]
}

もちろん拒否されます。ListVocabulariesだけが足りないのか…？

次に以下のようにList*でListVocabulariesも許可することに。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "transcribe:GetTranscriptionJob",
                "transcribe:StartTranscriptionJob",
                "transcribe:List*"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::sample-bucket/*"
        }
    ]
}

すると…

おっ、見えました。

もちろんジョブは正常に完了しました。

というわけで、コンソールから使用する場合はListVocabularies権限が必要です。カスタム語彙について何か確認する必要がなければGetVocabulariesはいらないでしょう。

CLI・SDKの場合

AWS CLIやSDKから利用する場合はどうでしょう。コンソールで最初に試した権限でこちらも試してみます。Pythonでジョブを実行します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "transcribe:GetTranscriptionJob",
                "transcribe:StartTranscriptionJob",
                "transcribe:ListTranscriptionJobs"
            ],
            "Resource": "*"
        },
        {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::sample-bucket/*"
        }
    ]
}

Pythonでのジョブの実行は以下のようなコードになりました。

import boto3


transcribe = boto3.client("transcribe")

transcribe.start_transcription_job(
   TranscriptionJobName="iam-test03",
   LanguageCode="en-US",
   MediaFormat="mp3",
   Media={
      "MediaFileUri": "https://s3.amazonaws.com/sample-bucket/sample.mp3"
    },
   Settings={
        "VocabularyName": "test"
   }
)

すると…

おや？正常に実行されました。

まとめ

Amazon Transcribeでカスタム語彙を指定してジョブを実行するとき、プログラムから実行する場合は特にカスタム語彙へのアクションの権限は必須ではありません。しかし、コンソールから実行する場合はListVocabulariesが必要になります。これはカスタム語彙を選択するときにプルダウンで一覧が表示する仕様のためだと考えられます。

技術課の森です。
気づけば子供が夏休みに入りだしました。夏休みの宿題は計画的にしないとですね。

今回は自分がハマったことの共有になります

はじめに

CloudFormationを使って、CentOSを起動しようとしましたが、実行中のまま終わらなかったので、おかしいなと思ったのがきっかけです。
結果的に実行エラーになったので、調べると１アクションしてから実行しないといけないということがわかりましたので、その手順を展開します

エラー内容

CloudFormationでスタックを作ってるとイベント情報として、 CREATE_FAILED となりました。
内容を見ると

In order to use this AWS Marketplace product you need to accept terms and subscribe.
To do so please visit https://aws.amazon.com/marketplace/pp?sku=6lcz3m1cx42wj1wg4qvuta8p6 (Service: AmazonEC2; Status Code:401; Error Code: OptlnRequired; Request ID: 33976022-bd2a-4851-b054-043c41dca429)

「MarketPlaceで利用規約に同意して、登録する必要がある」とのことで、URLにアクセスしてくださいとのことでした。

利用規約の確認、同意、登録

URLへアクセス ＆ Subscribe

まずはURLにアクセスしてください。
今回は、CentOS7を利用してます。
まずは、ページの内容をしっかり確認していただき、確認が終わりましたら、右上の「Continue to Subscribe」ボタンをクリックしてください。

利用規約の確認と同意

ページが遷移しますので、内容をしっかり確認していただき、確認が終わりましたら、中央部にある、「Accept Terms」をクリックしてください。

するとダイアログが表示されますので、「Proceed」ボタンをクリックしてください。

ページが遷移して、以下のような画面になればOKです。

もう一度、CloudFormationを実行

これで、CloudFormationをもう一度実行すればOKです。

さいごに

知ってるとドキドキしないのですが、知らないとどうすればよいのかドキドキしますよね。
あとは、落ち着いてログを見ればだいたい書いてることも気づけたので、良かったです。
僕も子供に負けじと夏休みの宿題を作って、こなしていこうと決意したCloudFormationの実行でした。

こんにちは、技術3課の峯です。

今回はAmazon Comrehendで分析を実行する3つの方法についてご紹介します。

Amazon Comprehendとは

そもそもAmazon Comprehendとはどういったサービスでしょうか？Amazon ComprehendはAWSが提供する自然言語処理サービスです。APIを叩くだけで簡単に言語・エンティティ・キーフレーズ・感情・構文を分析でき、またTopic Modelingを行うこともできます。分析にかけらる言語は、「言語」の分析を除いて、英語とスペイン語のみです（2018年8月現在）。ドキュメントを見ると、分析を行う処理の方法が3つ用意されています。

• 1つの文章を分析する
• 複数の文章をまとめて分析する
• S3に保存した文章を分析する

用途・目的によりその3つの方法を使い分けます。今回は出力が少なくわかりやすい「言語」の分析を例とし、実際にPythonで分析を実行しながら、これら3つの分析方法について説明します。

1つの文章を分析する

1つの文章のみを分析する方法です。アプリケーションからインタラクティブに分析したい時などにこの方法を使います。単にDetect~というのを実行すればOKです。

実際にやってみる

Pythonでは以下のように実行します。

import boto3


comprehend = boto3.client("comprehend")

response = comprehend.detect_dominant_language(
    Text="This sentence is English"
)

ちなみに今回のレスポンスはこんな感じ。もちろん分析によってレスポンスの内容は異なります。

{
    'Languages': [
        {
            'LanguageCode': 'en', 
            'Score': 0.9878036379814148
            
        }
    ], 
    'ResponseMetadata': {略}
    
}

複数の文章をまとめて分析する

複数の文章をいっぺんに分析にかけることができます。いっぺんといっても文章ごとにDetect~が実行されており、結果をまとめたものがレスポンスで帰ってきているだけです。BatchDetect~というのを実行すればOKです。

実際にやってみる

Pythonではこのように実行します。

import boto3


comprehend = boto3.client("comprehend")

response = comprehend.batch_detect_dominant_language(
    TextList=[
        'This sentence is Engilish',
        'Esta oracion es espanola',
        'この文章は日本語です'
    ]
)

レスポンスはこんな感じ。ResultListにそれぞれの分析結果が入ります。今回はありませんがエラーが出た場合は、ErrorListに結果が入ります。

{
    'ResultList': [
        {
            'Languages': [
                {
                    'LanguageCode': 'en', 
                    'Score': 0.9865556955337524
                    
                }
            ], 
            'Index': 0
        
        }, 
        {
            'Languages': [
                {
                    'LanguageCode': 'es', 
                    'Score': 0.9486181735992432
                    
                }
            ], 
            'Index': 1
            
        }, 
        {
            'Languages': [
                {
                    'LanguageCode': 'ja', 
                    'Score': 1.0000483989715576
                    
                }
            ], 
            'Index': 2
        }
    ], 
    'ResponseMetadata': {略}, 
    'ErrorList': []
}

S3に保存した文章を分析する

テキストファイルをいくつもS3に保存している場合、この方法をつかいます。この方法で分析を行う場合、分析は「ジョブ」という形で実行されます。結果はジョブ作成時に指定するS3バケットへ保存されます。ちなみTopic Modelingはこの方法でしか実行できません。

実際にやってみる

Pythonで実行すると以下のようになります。

import boto3


comprehend = boto3.client("comprehend")

start_response = comprehend.start_dominant_language_detection_job(
    InputDataConfig={
        'S3Uri': 's3://text-bucket/text/',
        'InputFormat': 'ONE_DOC_PER_FILE'
    },
    OutputDataConfig={
        'S3Uri': 's3://result-bucket/result/'
    },
    DataAccessRoleArn='arn:aws:iam::xxxxxxxxxxxx:role/SampleRole',
    JobName='example-job01'
)

InputDataConfigで分析にかけたいテキストの場所とフォーマットを指定します。S3UriでS3バケットとプレフィックスを指定します。ココで指定したプレフィックスが付いているファイルはすべて分析にかけられます。InputFormatにはONE_DOC_PER_FILE（1つのファイルに1つの文章）かONE_DOC_PER_LINE（1行に1つの文章）かを指定します。OutputDataConfigのS3Uriで結果ファイルを出力するS3バケットとプレフィックスを指定します。DataAccessRoleArnではジョブが利用するIAMロールのARNを指定します。このIAMロールにはインプットとなるS3バケットへのGetObject権限とListBucket権限、アウトプットするS3バケットのPutObject権限が必要となります。JobNameは指定しなくてもよいです。

ちなみにレスポンスはこんな感じ。ジョブステータスとジョブIDが返ってきます。ステータスはSUBMITTED|IN_PROGRESS|COMPLETED|FAILED|STOP_REQUESTED|STOPPEDがあります。STOP_REQUESTEDとSTOPPEDがあることからもわかるようにジョブは止めることができますが、詳しい説明は今回は割愛します。

{
    'ResponseMetadata': {略}, 
    'JobStatus': 'SUBMITTED', 
    'JobId': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
}

このジョブIDからジョブの詳細・ステータスを確認することができます

describe_response = comprehend.describe_dominant_language_detection_job(
    JobId='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
)

レスポンスはこんな感じ

{
    'DominantLanguageDetectionJobProperties': {
        'InputDataConfig': {
            'S3Uri': 's3://text-bucket/text/', 
            'InputFormat': 'ONE_DOC_PER_FILE'
        }, 
        'DataAccessRoleArn': 'arn:aws:iam::xxxxxxxxxxxx:role/SampleRole', 
        'JobId': 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx', 
        'JobStatus': 'COMPLETED', 
        'JobName': 'example-job01', 
        'SubmitTime': datetime.datetime(2018, 8, 3, 8, 59, 0, 318000, tzinfo=tzlocal()), 
        'OutputDataConfig': {
            'S3Uri': 's3://result-bucket/result/XXXXXXXXXXXX-LANGUAGE-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/output/output.tar.gz'
        }, 
        'EndTime': datetime.datetime(2018, 8, 3, 9, 7, 8, 515000, tzinfo=tzlocal())
    }, 
    'ResponseMetadata': {略}
}

結果のtar.gzをダウンロード＆解凍し、中身を見るとこんな感じ。ファイルに結果が出力されます。今回は言語の分析でしたのでこのような分析結果の内容になっています。あたりまえですが分析によって、出力結果が異なります。

{"File": "sample02.txt", "Languages": [{"LanguageCode": "es", "Score": 0.8467387557029724}, {"LanguageCode": "en", "Score": 0.1470765918493271}, {"LanguageCode": "pt", "Score": 0.002519829897210002}]}
{"File": "sample01.txt", "Languages": [{"LanguageCode": "en", "Score": 0.9844604730606079}, {"LanguageCode": "de", "Score": 0.004355866927653551}, {"LanguageCode": "fr", "Score": 0.002686671447008848}]}

まとめ

このようにAmazon Transcribeではアプリケーションでインタラクティブに分析したいか、S3に保存されたものをバッチ処理のように分析したいかによって、実行方法を選ぶことができます。適切な実行方法を選ぶことでより便利にAmazon Comprehendを利用することができます。それではよいComprehendライフを。

こんにちは、技術4課の城です。
最近では暑すぎて、アイスにハマっています。
今年はセブンイレブンの限定アイス「黄ぐま」が売り切れることなく販売されており、嬉しい限りです。

さて話は変わりますが、CloudwatchLogs、すごく便利なサービスと思いつつも、今までほとんど触れることがなかったです。
掲題の設定をするにあたり、かなり四苦八苦してしまいました。
簡単なことではあるのですが、備忘としてブログに残しておこうと思います。

CloudwatchLogsの設定方法

AWSドキュメントです。

主には以下の３つの方法で設定可能です。

• Run Command を使用する
• ステートマネージャー を使用する
• ローカル設定ファイルを使用する

どれを選んでも実際のインスタンスの設定としては C:\Program Files\Amazon\SSM\Plugins\awsCloudWatch\AWS.EC2.Windows.CloudWatch.jsonにCloudwatchLogsへの出力設定を記載します。

ステートマネージャーによる設定

当社ブログに詳細記載しておりますので、ご参照ください。

AWS.EC2.Windows.CloudWatch.jsonの設定内容

設定したい内容に合わせてjsonを書く必要があります。
ドキュメントを色々と見てみましたが、記載方法などが見当たらず、四苦八苦、右往左往でした。
最終的にCloudFormationの設定テンプレートの中に設定したい内容がそのまま書いてあり、解決しました。
ポイントとしては次の2点です。

• LogStream毎にIdを用意する
• ログ（LogStream）ごとにFlowを分ける
  今回作成した内容は下記になります。
  LogGroupをインスタンスごと、System、Security、Applicationの各イベントログでログストリームを分ける設定です。

{
  "IsEnabled" : true,
  "EngineConfiguration": {
    "PollInterval": "00:00:15",
    "Components": [
      {
        "Id": "SystemEventLog",
        "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
        "Parameters": {
          "LogName": "System",
          "Levels": "7"
        }
      },
      {
        "Id": "SecurityEventLog",
        "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
        "Parameters": {
          "LogName": "Security",
          "Levels": "7"
        }
      },
      {
        "Id": "ApplicationEventLog",
        "FullName": "AWS.EC2.Windows.CloudWatch.EventLog.EventLogInputComponent,AWS.EC2.Windows.CloudWatch",
        "Parameters": {
          "LogName": "Application",
          "Levels": "7"
        }
      },
      {
        "Id": "CloudWatchLogsSystemEventLog",
        "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",
        "Parameters": {
          "AccessKey": "",
          "SecretKey": "",
          "Region": "ap-northeast-1",
          "LogGroup": "Windows2016",
          "LogStream": "{instance_id}_System"
        }
      },
      {
        "Id": "CloudWatchSecurityEventLog",
        "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",
        "Parameters": {
          "AccessKey": "",
          "SecretKey": "",
          "Region": "ap-northeast-1",
          "LogGroup": "Windows2016",
          "LogStream": "{instance_id}_Security"
        }
      },
      {
        "Id": "CloudWatchLogsApplicationEventLog",
        "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch",
        "Parameters": {
          "AccessKey": "",
          "SecretKey": "",
          "Region": "ap-northeast-1",
          "LogGroup": "Windows2016",
          "LogStream": "{instance_id}_Application"
        }
      }
    ],
    "Flows": {
      "Flows": [
        "SystemEventLog,CloudWatchLogsSystemEventLog",
        "SecurityEventLog,CloudWatchSecurityEventLog",
        "ApplicationEventLog,CloudWatchLogsApplicationEventLog"
      ]
    }
  }
}

最後に

簡単ではありますが、CloudwatchLogsの設定について紹介しました。
どなたかのお役に立てれば幸いです。

はじめに

リソース構築を複数のAWSアカウントに対して同時に行いたいことってありますよね。例えば、ハンズオンセミナーを開催する時等では、参加者のAWSアカウントに同じ環境を用意する必要があります。
2~3アカウントであれば、マネジメントコンソールからポチポチ進められるかもしれませんが、アカウント数が多いと大変です。

もしこれが、ボタンぽち、で複数のAWSアカウントへの環境構築を一気に出来たら便利だと思いませんか？出来ますよ、そう、CloudFormation スタックセットならね。

参考：AWS CloudFormation が StackSet で複数のアカウントとリージョンのプロビジョニングをサポート

CloudFormation スタックセット概要

CloudFormation スタックセットにより、CloudFormationのスタックを複数アカウントに対してプロビジョニングできます。（CloudFormationについては弊社ブログでも記事がありますので、適宜参照ください）

CloudFormation スタックセットでは、管理者アカウント（CloudFormationのスタックセットを作成するアカウント）と、ターゲットアカウント（CloudFormationスタックが実行され、リソースが構築されるアカウント）の2種類のAWSアカウントが存在します。

スタックセットを作成する前にあらかじめ両方のアカウントにスタックセットのオペレーションを実行するためのIAMロールを作成しておく必要があります。それらのIAMロールを用いてクロスアカウントでのスタックセットのオペレーションが実行されます。

概要手順

それでは、以下、CloudFormation スタックセットを作成する手順の概要を紹介します。

前提条件

• 管理者アカウントのAWSアカウント、ターゲットアカウントのAWSアカウントが準備されていること
• リソースを構築するためのCloudFormationテンプレートが準備されていること
• ターゲットアカウントのAWSアカウントナンバーが記載されたCSVファイルが準備されていること
  • 以下のようにターゲットアカウントすべてのAWSアカウントナンバーが記載されたCSVファイルを準備しておきます

IAMロールの作成

管理者アカウントでIAMロール AWSCloudFormationStackSetAdministrationRole を作成します。
ターゲットアカウントでIAMロール AWSCloudFormationStackSetExecutionRole を作成します。

これらのIAMロールを作成するためのCloudFormationのテンプレートがAWSから提供されているため、これを使うとよいと思います。以下ページを参照ください。
前提条件: スタックセットオペレーションのアクセス権限の付与

スタックセットの作成

CloudFormationのページから左上の「CloudFormation」を選択し、「スタックセット」を選択します。

「スタックセットの作成」ボタンを選択します。

「テンプレートをAmazon S3にアップロード」を選択し、「テンプレートのアップロード」から「参照」ボタンを選択し、事前に準備しておいたCloudFormationのテンプレートファイルを選択します。
準備が出来たら「次へ」を選択します。

任意のスタックセット名を入力し、「次へ」を選択します。

「アカウントの設定」から「スタックがデプロイされている有効なアカウントのカンマ区切り値（CSV）のファイルをアップロード」を選択し、事前に準備したターゲットアカウントのAWSアカウントナンバーが記載されたCSVファイルを選択します。
「リージョンの指定」からスタックをデプロイするリージョンを選択します。
必要に応じて「デプロイオプション」を調整します、今回はデフォルトのまま「次へ」を選択します。

必要に応じて「オプション」を編集します。今回はデフォルトのまま「次へ」を選択します。

「AWS CloudFormationによってカスタム名のついたIAMリソースが作成される場合があることを承認します。」にチェックを入れ、「作成」を選択します。

無事にスタックのデプロイが完了すると、「スタックセットのプロパティ」ページで以下のようにステータスが「SUCCEEDED」になります。

おわりに

CloudFormation スタックセットで複数のAWS環境構築を一気に行う内容を紹介しました。
さて、実際にこの機能を準備に利用しているセミナーでもあるCloud Automatorのハンズオンセミナーが東京・大阪で開催されます。Cloud AutomatorやAWS運用自動化に興味のある方がいらっしゃれば、是非ご参加頂けたらと思います。お申込みは以下ページよりお願いします。

（大阪）大阪にてAWS運用自動化ツール「Cloud Automator」のハンズオンセミナーを開催します
（東京）AWS運用自動化ツール「Cloud Automator」のハンズオンセミナーを開催します

はじめに

これまでもAmazon Cognitoを使ってみようと思ったのですが、思っただけで触らず…
夏休みで子供が勉強してるので、自分も勉強しようと思います。

Amazon Cognitoとは

ドキュメントにも書いてますが、「ウェブアプリケーションやモバイルアプリケーションの認証、認可、ユーザ管理をサポート」をしてくれます。
ここで「認証と認可」についてまずは確認していきます。

認証と認可

認証

認証とは、いろんな意味があるのですが、利用者が本人であるかどうかを確認する作業ということで、
IDやパスワードで利用者が本人であることを確認することになります。

認可

認可とは、認証されたユーザのシステム資源へのアクセスをそのユーザ権限に応じて判断するということのようです。
認証されたユーザが権限に応じてReadOnlyだったり、ReadWriteだったり、Adminの権限を割り当てるって感じですね。

Amazon Cognitoの機能

Amazon Cognitoには３つ機能があります。

• Amazon Cognito User Pool
• Amazon Cognito Identity Pool
• Amazon Cognito Sync

ざっくり説明すると

Amazon Cognito User Pool

• サインアップ及びサインインサービス
• ユーザがサインインするための組み込みのカスタマイズ可能なウェブUI
• FacebookやGoogleを使ったソーシャルサインインやLogin with Amazon、ユーザプールからのSAML IDプロバイダーでサインイン
• ユーザディレクトリとユーザプロファイルの管理
• 他要素認証(MFA)などのセキュリティ機能
• 漏洩した認証情報のチェック
• アカウント乗っ取り保護
• 電話とEメールによる検証
• カスタマイズされたワークフローとAWS Lambdaトリガーによるユーザ移行

Amazon Cognito Identity Pool

• 認可を行う機能を持っている
• ユーザの一意のIDを作成して、IDプロバイダーで連携させることができます。
• IDプロバイダーとしてサポートしているものは以下の通り。
  • Login with Amazon
  • Facebook
  • Google
  • Amazon Cognito User Pool
  • Open ID Connect Provider
  • SAML ID Provider

Amazon Cognitoで、認証／認可というと

Amazon Cognitoでいうとどうなるでしょうか？
認証：Amazon Cognito User Pool
認可：Amazon Cognito Identity Pool
になります。

Amazon Cognito Syncとは

ここまで出てこなかったAmazon Cognito Syncですが、これまでの認証／認可とは違う機能で、
アプリケーションが使うユーザデータのデバイス間の同期を有効にする機能になります。
ただ、ドキュメントには、
「Amazon Cognito Syncを初めて使用する場合は、AWS AppSyncを使用してください。」とあるので、
利用方法は考えていかないといけない感じです。

さいごに

これで、Amazon Cognitoの概要が理解できてきたので、次は、実際に使ってみて、ユーザ管理をしてみようと思います。
夏休みの宿題って大変ですね。がんばりましょう！

はじめに

前回のブログ で、Amazon Cognitoのい・ろ・はを書きました。
今度は、ちょっと中身の話を書いていきます。
Amazon Cognito User PoolとAmazon Cognito Identity Poolについてです。
実際のサンプル実装を交えて、設定情報を記載していきます。

Amazon Cognitoの設定

Amazon Cognito User Poolを作る

まずはAmazon Cognito User Poolを作っていきます。

Amazon Cognito User Poolの管理

最初に、Amazon Cognitoを選択して、「ユーザープールの管理」をクリックします。

Amazon Cognito User Poolの作成

次に、「ユーザープールを作成する」をクリックします。

ユーザープール名の入力

「プール名」に任意の名前を入力してください。今回は、細かい設定は行いませんので、「デフォルトを確認する」をクリックします。

Amazon Cognito User Poolの作成の確認

「プールの作成」をクリックして、Amazon Cognito User Poolを作成します。

Amazon Cognito User Poolの作成完了

作成が完了したら画面が切り替わります。
「プールID」は後ほど利用しますので、メモしておいてください。
次に、画面下部の「アプリクライアント」の「アプリクライアントの追加」をクリックします。

アプリクライアントの作成

今回は、外部のIDプロバイダを使わず、Amazon Cognito User Poolを使っていきます。
それと今回、サンプルとして、HTMLとJavaScriptを利用します。
JavaScriptを利用するとクライアントシークレットが利用できないため、一部設定を変更する必要があります。
まずは、「アプリクライアント名」に任意の名前を入力します。
その後、「クライアントシークレットを生成」のチェックを外します。ここにチェックしたまま利用すると「NotAuthorizedException」が発生し、
「Unable to verify secret hash for client」というメッセージが出ますので、ご注意ください。
チェックを外したら、「アプリクライアントの作成」をクリックします。

アプリクライアントの作成完了

すると「アプリクライアントID」が表示されますので、これも後ほど利用しますので、メモしておいてください。
「プールの詳細に戻る」をクリックします。

Amazon Cognito User Poolの詳細

画面上部の「フェデレーティッドアイデンティティ」をクリックします。

Amazon Cognito Identity Poolを作る

Amazon Cognito Identity Poolの作成

「新しいIDプールの作成」をクリックします。

Amazon Cognito Identity Poolの入力

「IDプール名」に任意の文字を入力し、「認証プロバイダー」の「Cognito」タブにある「ユーザープールID」に先程メモした、「プールID」を入力し、「アプリクライアントID」に先程メモした「アプリクライアントID」を入力して、「プールの作成」をクリックします。

IAM Roleの設定

今回、IAM Roleは特に設定しませんので、そのままにしておきます。
画面下部の「許可」をクリックします。

これで、Amazon Cognito User PoolとAmazon Cognito Identity Poolの設定が完了になります。

Webサーバの準備

HTML/JavaScriptのサンプルは別で用意していますので、Webサーバを構築しておきます。
今回は、AmazonLinuxにnginxをインストールして利用できるようにしています。
なお、サンプルコードは、githubに用意しているので、自由にご利用ください。
コードを取得したら、ドキュメントルートにそのままコピーすればいい状態にしています。
あと、cognito-auth.jsの中に、ユーザープールIDとアプリクライアントIDを入力する必要があるので、ご注意ください。

動作確認

index.htmlにアクセス

index.htmlにアクセスするとSign Up画面になりますので、「E-Mail Address」にご利用されているメールアドレスを入力してください。
「Password」にパスワードを入力してください。ここでは、半角英数の大文字小文字＋記号を含む必要があります。
入力が完了したら、「sign up」ボタンをクリックしてください。

検証コードの送信完了連絡

ボタンをクリックすると完了ダイアログを出すようにしています。
これで、入力したメールアドレスに検証コードを送付するようになっていますので、「OK」をクリックしてください。

検証コードの確認

メールが届きますので、検証コードをメモしてください。

検証コードの入力

画面が遷移して、「Sign Up Confirmation」画面になります。
「E-Mail Address」に先程入力したメールアドレスを入力し、「Verification Code」に検証コードを入力し、「sign up verify」ボタンをクリックしてください。

検証完了

検証完了のダイアログが出るようになっています。「OK」をクリックしてください。

ログイン

では最後に登録した情報でログインしていきます。
「E-Mail Address」に先程入力したメールアドレスを入力し、「Password」に先程入力したパスワードを入力してください。
入力が完了したら、「Login」ボタンをクリックしてください。

ログイン完了

ログインOKなら、ダイアログが出るようになっています。「OK」をクリックすると「Login Success」画面に遷移して、サンプルの動作が成功になります。

さいごに

これで、Amazon Cognito User PoolとAmazon Cognito Identity Poolを使ったログインと権限付与ができるようになりました。
権限でS3へのPut権限を与えて、ファイルをPUTできるようにしたりなど、いろいろできるようになります。
今回のサンプルは単純なものなのですが、時間を見つけて、もうちょっと複雑なものを作ってみようかと思います。
一旦は、夏休みの宿題はこれで完了になります。
宿題と言わず、いろいろ作ってみようかと思った、暑い夏でした。

宮澤です。

今回はAmazon Connectのユーザー認証を、シングル・サイン・オン サービスのOneLoginと連携してSAML認証を行う手順を紹介します。

1.Amazon Connectの作成

Amazon Connectの画面に移動し”今すぐ始める”を押します。

“SAML2.0 ベースの認証”を選択して、アクセスURLを入力して”次のステップ”を押します。

このタイミングで、管理者を作成する場合は”新しい管理者の追加”を選択して、項目を入力します。
作成しない場合は”これをスキップ”を押して”次のステップ”を押します。

次にテレフォニーオプションを設定します。
今回は発着信両方ともConnectを使う想定なので、両方ともチェックして”次のステップ”を押します。

ログの保存先の設定が表示されますが、デフォルト設定を利用するため”次のステップ”を押します。

Connectの構成確認画面が表示されるので、問題がなければ”インスタンスの作成”を押します。

ユーザー作成

Connectの管理画面から、作成したインスタンスを選択します。

”概要 > 管理者としてログイン”を押します。

“ユーザー > ユーザー管理 > 新しいユーザーの追加”を押します。

ユーザー情報を確認し、問題なければ”ユーザーの作成”を押します。

ユーザーを作成する際、OneLogin上に存在するユーザーと姓、名、メールアドレスが一致するように作成してください。

作成するユーザー情報が表示されるので、問題がなければ”ユーザーの作成”を押します。

2.AWSアカウントとOneLoginをSAML設定

OneLogin側でコネクタ作成

Connectと連携するためのOneLoginのコネクタは、カタログに公開されていないものを利用します。
今回記載している内容で設定を行う場合は、弊社にお問い合わせください。

今回利用するコネクタを開き、Display NameにOneLogin上の表示名を設定し”SAVE”を押します｡

SAVEを押すと以下の画面に遷移するので､”MORE ACTIONS>SAML Metadata”を押してXMLファイルをダウンロードします｡
※後ほどAWSマネジメントコンソールの設定で利用します｡

AWS側のIDプロバイダ設定

IDプロバイダの作成

マネジメントコンソールにログイン後IAMの画面に移動し､”IDプロバイダー>プロバイダの作成”を押します｡

プロバイダタイプは”SAML”を選択し､プロバイダ名を任意で設定します｡
メタデータドキュメントは､先程OneLoginからダウンロードしたファイルを指定して”次のステップ”を押します。

最後に確認画面が表示されるので、問題なければ”作成”を押します。

IAM ポリシーの作成

ConnectをSAML経由で利用する場合、以下のIAMポリシーをロールに付与する必要があるので、任意の名前で以下の2つを作成します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement1",
            "Effect": "Allow",
            "Action": "connect:GetFederationToken",
            "Resource": [
                "arn:aws:connect:RegionID:AccountNumber:instance/ConnectInstanceID/user/${aws:userid}"
            ]
        }
    ]
}

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Statement2",
            "Effect": "Allow",
            "Action": "connect:GetFederationToken",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "connect:InstanceId": "ConnectInstanceID"
                }
            }
        }
    ]
}

IAM Roleの作成

IAMの画面で”ロール > 新しいロールの作成”を押します｡

”SAML2.0 フェデレーション”を選択し、”SAMLプロバイダー”の値を先ほど作成した、IDプロバイダーを指定します。
そして、”プログラムによるアクセスとAWSマネジメントコンソールによるアクセスを許可する”を選択して”次のステップ:アクセス権限”を押します。

該当IAMロールで利用する権限を設定します。
先程作成した2つのIAMポリシーを選択して”次のステップ : 確認”を押します。

最後に、ロール名を入力して”ロールの作成”を押します。

OneLoginのParameter設定

OneLoginのコネクタ設定画面に戻り”Parameters”タブを開きます｡
ParametersタブではSAML認証を行うときに利用する以下の3つの用に設定します｡

• Amazon Username UsernameAWS上でのユーザーの表示名) : Email
• Role : arn:aws:iam::アカウントナンバー:role/作成し/作成しロール名,arn:aws:iam::アカウントナンバー:saml-provider/作成したIDプロバイダ名
• RoleSessionName(AWS上でのユーザーの表示名) : Email

次に”Configuration”タブに移動し、”RelayState”に以下のようにURLを入力します。
https://region-id.console.aws.amazon.com/connect/federate/instance-id
OneLoginからCCPへ直接アクセスさせる場合は、以下のURLを指定します。
https://region-id.console.aws.amazon.com/connect/federate/instance-id?destination=%2Fconnect%2Fccp

最後に”Access”タブを押して､Connectを利用するユーザーが指定されているRoleを指定し”SAVE”を押します｡

3.ログイン確認

OneLoginからConnectのAWSアカウントにログインします。

SAMLログインが実行され、以下のダッシュボードに移動することができます。

注意事項

SAMLベースでConnectを作成すると、以下のような通常のログインURLは利用できない状態になります。

https://ConnectAlias.awsapps.com/connect/login

また、Amazon Connectセッションは、ユーザーがログインしてから10時間後に失効します。
10時間後、ユーザーは現在通話中であっても自動的にログアウトされてしまいます。
エージェントに10時間以上ログインさせる予定の場合は、セッションが終了する前に、Amazon ConnectおよびOneLoginからログアウトした後、再度ログインする必要があります。
※これにより、トークンに設定されたセッションタイマーがリセットされます。

宮澤です。
今回は、OneLoginのリスクベース認証機能の紹介をしたいと思います。

リスクベース認証とは

OneLoginの”リスクベース認証”機能は、機械学習によって、不正なログインを検知して多要素認証を利用させるオプション機能です。
学習要素は以下となっており、その学習を元に、ユーザーがアクセスした際にリスクを判定します。
※リスク判定は複数のレベルから選択できます。

• 地理的位置
  • 現実的でない地理的位置からアクセス
  • ブラックリストの国
  • 新しい国または都市
• ネットワークのアドレス
  • IP知名度
  • 新しいIPアドレス 
  • ブラックリストのIPからのアクセス
• デバイス
  • 未知のデバイス
  • OSの種類
  • ブラウザ
• 時間帯
  • 普段利用していない時間帯のアクセス
  • 同時アクセス

例えば、以下の条件で普段利用しているとします。
これを、機械学習で学習されることで、以下の条件下でOneLoginへアクセスする場合は、ID/パスワードのみで、多要素認証なしでログインができます。

• 地理的位置：東京
• デバイス：Windows
• ブラウザ：Google Chrome
• 時間帯：日本時間の日中

しかし、上記の条件のユーザーが海外に出張した場合、地理的位置や時間帯が学習内容と一致しなくなるため、海外からOneLoginへアクセスした場合、ID/パスワードにプラスして多要素認証を必須で求められます。

設定

管理画面にログインし、”SETTINGS > Policies” を選択します。

新規ポリシーにリスクベース認証を設定する場合は、右上の”NEW USER POLICY”を押します。
既存のポリシーにリスクベース認証を設定する場合は、下の一覧にある既存のポリシー名を選択します。

新規にポリシーを作成した場合は、上部の欄にポリシー名を設定します。
MFAタブを開き、下にスクロールすると”Adaptive MFA”の項目が表示されるので、”Enable”にチェックを入れます。
次にリスクレベルを、以下の3つから選択し、右上の”SAVE”を押します。

• No Risk (0-4)
• Low Risk (5-25)
• Medium (26-50)

リスクレベルについて

リスクベース認証を利用する場合、全てのログイン関連のイベントに対してリスクレベルのスコア計算が行われます。
スコアの内容は”ACTIVITY > Events”から確認できます。

詳細を確認すると、リスクスコアを判断した理由を確認することができます。
この値が、ポリシーで設定した値を上回っていた場合、ユーザーに多要素認証を求めるようになります。
今回の例の場合、”Low Risk (12/100)”と判定されているので、ポリシーの設定で”Medium Risk (26-50)”を設定していた場合、ユーザーは多要素認証が求められずにOneLoginにログインすることができます。

まとめ

リスクベース認証を利用することで、リスクがあるログインが発生した際に多要素認証を実施できるようになります。
これにより、普段利用する際のユーザーのストレスが軽減されます。

準備にかかった時間

• 企画アウトラインをまとめた時間：5分
• 上司に報告してからGOが出た時間：1分
• Amazon Connectトライアルチーム結成、スケジュール、運用、タスク分担決定：30分
• Amazon Connect 環境の準備(AWSアカウント発行〜Amazon Connect構築 SAML認証含む)：1時間
• オペレータ向け手順書の作成：30分
• オペレータの事前検証：5分ｘオペレータ人数

準備は2名で進めました
＜ざっくり役割分担＞
・インスタンス構築、ユーザー管理：宮澤
・IVR,運用：丸山
順調に準備は進んだのですが、唯一つまづいたのはお客様がHold中に流れる音楽についてです。
軽快な Amazon Connect デフォルトミュージック(This and That Is Life) のままでいくか、よくあるコール音(プルルルル～)にするか二人の意見がわかれました。
宮澤くんの強い要望でコール音はデフォルトから変更しました。(されました)

Amazon Connect試用メンバーからのフィードバック

よかった

• 固定電話→CCP(ソフトフォン)＋ヘッドセットになり両手があいてメモが取りやすい
• 電話音がならないのでとても静か
• テレワーク時の電話対応がリモートふくめて分散可能
• Bluetoothヘッドセットでも品質に問題なし
• 「電話」を数字で管理できた(コール数、対応時間等)

とまどった

• コールセンター仕様の着信にドギマギ
  • 現在の固定電話は着信があると全台から電話音がなります
  • Amazon Connectの場合コールされるのはAvailable である時間が最も長いエージェントになります
  • 1日目はいつ自分のCCPがなるのか緊張してしまうメンバーが多数
• CCPステータス管理に慣れない
  • デスクからちょっと離れるときにもOfflineに変更するのを忘れてしまう
  • ステータス変更がワンクリックではないので少し面倒
• ヘッドセット(イヤホン)対応に慣れない
  • コール音がなく突然「はい、サーバーワークスです」という声におどろく
  • 電話しているのか独り言を言っているのかわかりづらい
  • 違和感、肩がこる等の理由ではずしてしまう
  • 電話以外の通知音、操作音が気になる

ちょっとだけこまった

• AWSアカウントにログインしようとしたらConnect社内試用のアカウントでマネジメントコンソールにログインしてしまった
• 問い合わせの検索 にデータが表示されるまで数分あり、すぐに問い合わせ情報を調べることができなかった
• 前日のCCPクライアントログが取得できなかった

要望

• クライアントアプリがほしい、できればスマホアプリ熱望
• コンタクトデータが「分」表示になっているので「秒」表示にしてほしい
• 問い合わせ検索の検索条件(フィルター)は前回値を保持してほしい
• CCPクライアント側のログがS3に保存できたらうれしい
• リアルタイムメトリクスの情報を取得できるAPIがほしい
• 保存するレポート名で日本語も使えるようにしてほしい
• CCPステータス変更をワンクリックまたはキーボードショートカットでささっとできるようにしてほしい

How much？

今回のAmazon Connect試用は4時間ｘ2日で行いました。

まとめ

技術4課の鎌田(裕)です。
私、どういう訳か、あらゆるところで仕事をしている中で、新しい技術に触れる機会がとても多いです。
都度、キャッチアップをしていく訳ですが、1週間から10日程度で一旦資料をまとめる必要があるなど、あまり時間がないケースも多いです。
そんな時、私はどう考えて対応しているのか。
そんな一旦を、今日はご紹介します。

1.まずは触ってみる

何より、まずは触ってみることです。
特に、今のクラウドの世界、VPNなど一部で物理的な用意が必要なものがまだ残ってはいるものの、
ほとんどは、試しに展開してみることが出来るようになっています。
設定パラメタもまずは標準で試してみましょう。

その中で、いくつか決めなくてはいけない項目が出てきます。
決めなくてはいけない項目を確認して、書き出しておきましょう。

2.決めなくてはいけない項目が、自分が知っていることなのか知らないことなのか整理する

1.で出てきた、決めなくてはいけない項目を、自分が知っていること、知らないことに分類します。
知っていることならば、「あ、このサービスは、こういうコトが決めれば使えるのか」と、整理ができますね。

問題は、知らないことの方です。知らないことなので、調べなくてはいけません。

でも、ちょっと待ってください。
全部を調べる必要があるでしょうか？

3.知らないことが、知っていることの何かで代替できないか確認する

技術は、必ず何かベースになるものがあって、その上で動いています。
なので、全部が新しいものではなく、きっと以下の図のように、新しい要素と、今までやってきたこととが重なりあう部分があるはずですね。

面倒でも、この手順のを踏むことで、本当にキャッチアップしなければならない範囲がグッと減ります。
慣れるまでは大変なステップですが、是非トライいただければと思います。

4.新しい要素をじっくりとキャッチアップし、アウトプットをまとめる

最後に、新しい要素をじっくりキャッチアップします。
キャッチアップが終わったら、ブログなりお客様への資料なりにまとめていきます。

必ず、アウトプットをしましょう。
キャッチアップしたつもりで出来てなかった、分かったつもりで理解できてない、更にそんなところが見つかります。

まとめ

新しい技術をキャッチアップする時は、

• まずは触ってみること
• 次に、知っていることなのか、知らないことなのかを整理してみること
• 知らないことは、実は知っている何かと代替できないか確認してみること
• 残った要素はアウトプットしてみて、分かったつもりになっていないか確認すること

こんなことを心掛けてみてください。

クラウド、AWSの新しい技術を、これからも楽しんでいきましょう！

先日、DynamoDBを利用したアプリケーションの開発やテストに便利なDynamoDB Localの公式イメージが公開されたとのアナウンスがありました。

これまでは開発環境にJavaをインストールし、jarファイルをダウンロードしてからDynamoDBLocalを実行する必要があり利用するのに少し手間がかかりました。

今回、公式のDockerImageが公開されたことでよりdockerが利用できる環境であればのより手軽にDynamoDB Localを利用できるようになりました。

実際に使ってみる

今回はDocker for Macで実行しています。

DockerHubのページでは以下の実行コマンドが記載されています。

docker run -p 8000:8000 amazon/dynamodb-local

このコマンドを実行することで公式のdockerhubからイメージがダウンロードされコンテナが実行されます。
ただし、このコマンドだとフォアグラウンドで動くのでターミナルを閉じるとコンテナも終了してしまいます。

そこで、-dオプションを追加した以下のコマンドで実行するとバックグラウンドで実行されます。
これでターミナルを閉じても利用できますね。

docker run -d -p 8000:8000 amazon/dynamodb-local

AWS CLIでためしてみる

AWS CLIで利用する場合はエンドポイントURLのオプションを利用してエンドポイントを指定することで利用可能です。

例えばテーブルを作成する場合は以下のようなコマンドを実行するとLaunchListと言うテーブルがDynamoDBLocal内に作成されます。

aws --endpoint-url http://localhost:8000 dynamodb  create-table --table-name LaunchList --attribute-definitions AttributeName=Name,AttributeType=S --key-schema AttributeName=name,KeyType=HASH --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1

テーブルのリストを確認する場合には以下のような形になります。

aws --endpoint-url http://localhost:8000 dynamodb list-tables

SDKで実行するには

AWS CLIでは無く各言語のSDKを利用してDynamDBLocalを扱う場合でもAWS CLI同様エンドポイントURLを指定するだけで利用できます。

例えばpythonのSDKであるboto3で利用するには以下のようなコードになります。

boto3.client("dynamodb",endpoint_url="http://localhost:8000")

もしくは

boto3.resource("dynamodb",endpoint_url="http://localhost:8000")

Rubyでも同様に以下のように指定することで利用できます。

Aws::DynamoDB::Client.new(endpoint: 'http://localhost:8000')

Aws::DynamoDB::Resource.new(endpoint: 'http://localhost:8000')

SDKを利用している場合だとあとのテーブルの作成やデータのGET、PUTなどのコードは変更無く利用することができます。

実際にどんなコマンドが実行されてるの？

docker コンテナ内ではどんなコマンドでDynamoDBLocalが実行されているのでしょうか。

確認するためにdocker ps に --no-trunc オプションをつけて省略させずに各項目を表示させます。
手元では以下のような表示になりました

docker ps --no-trunc
CONTAINER ID                                                       IMAGE                   COMMAND                                   CREATED             STATUS              PORTS                    NAMES
978e3f0d4c19820b55be806b58dc5b28ac90bb0a1696320243b92420d288d9e1   amazon/dynamodb-local   "java -jar DynamoDBLocal.jar -inMemory"   22 hours ago        Up 22 hours         0.0.0.0:8000->8000/tcp   vigorous_shockley

これにより java -jar DynamoDBLocal.jar -inMemory が実行されていることがわかります。

-inMemory オプションで実行されているのでテーブルデータなどはDiskには書き込まれずメモリ上のみに存在する形になります。

そのためコンテナを停止するとDynamoDBLocalに格納されたデータは消えてしまいます。
DynamDBLocalはあくまで開発用のツールであるためこのようなコマンドになってると思われます。

まとめ

公式にDocker Image化されたことで利用開始の手間が大幅に少なくなりDynamoDB Localより使いやすくなりました。
これをうまく利用し、コードの動作確認を手元で行えることでDynamoDBを利用するアプリケーションの開発を加速させていきたいですね。

技術4課の鎌田(裕)です。
WorkSpacesはこれまで、専用のクライアントをダウンロードし、接続必要がありましたが、
ついに日本語OSでも、Webブラウザからのアクセスに対応しました。

1.対応ブラウザ

現時点で対応しているブラウザとバージョンは以下の通りです。
公式ドキュメントも参照してください。

• Chrome 53 and later
• Firefox 49 and later

なお、GraphicalのWorkSpacesはWebアクセスに対応していません。ご注意ください。

2.プロキシサーバーの対応

WebブラウザからのWorkSpacesアクセスで、Proxy経由での接続が出来るのはChromeのみ(versions 55 and later)です。
Firefoxは未対応となっています。
また、Proxyが認証を必要とする場合は未対応ですので、ご注意ください。

3. 接続の準備

では、実際に接続してみましょう。
その前に、設定を確認します。

マネジメントコンソールにアクセスし、WorkSpacesの画面で、左ペインからディレクトリを選択。
Webアクセスを可能にしたいディレクトリ名をチェックを入れて、アクションから「詳細の更新」をクリックします。

アクセス制御のオプションで、Web Accessにチェックが入っているか、確認してください。
入っていなければ、チェックを入れます。

チェックを入れたら、更新と終了をクリックします。

4.いよいよ接続

まず、以下URLにアクセスします。
https://clients.amazonworkspaces.com/webclient

「Enter a new Registration Code」をクリックします。
登録コードを入れる画面が出てくるので、WorkSpacesの登録コードを入力し、Registerをクリック。

なお、登録コードはマネジメントコンソールでWorkSpacesを表示した後、▼をクリックして詳細を表示させると出てきますので確認してください。

ユーザー名とパスワードを入力して、Sign Inをクリック

WorkSpacesの画面が、ブラウザで表示されます！

おわりに

WorkSpacesのWebアクセス、簡単に実施いただけることがお分かりいただけたかと思います。

ぜひ皆さんも、Webアクセスをお試しください！

　こんにちは、サーバーワークスのこけしの人、坂本（@t_sakam）です。（前回）は、Alexa Skills Kit SDK for Python (Beta) を使って、Echo Spot用のスキルを作りました。

　今回は、前回も利用した「Hello World」サンプルを少しアレンジして、簡単なEcho Spot用の「動画を流すスキル」を作ります。ListTemplate2を使った選択画面をタッチして、こけしの系統である「ナルコ」か「ヤマガタ」を選ぶと、Echo Spotの画面に「鳴子系か山形系のこけしの説明動画が流れる」という簡単なスキルです。
　百聞は一見にしかず、ということでまずは完成したスキルの動画をみてみましょう！

動画

Amazon Developer ServicesのAlexa Skills Kitでスキル作成

スキルの作成

　ここからはスキルの作成です。まずはAmazon Developer Servicesにログインします。［Alexa Skills Kit］タブ – Alexa Skills Kitのトップのスキル一覧ページで［スキルの作成］ボタンをクリックします。
　［新しいスキルを作成］ページでスキル名を「こけしビデオ」、デフォルトの言語を「日本語」に設定します。

　［スキルに追加するモデルを選択］の箇所では「カスタム」を選択し、［スキルを作成］ボタンをクリックします。

呼び出し名の入力

　左のメニューから［呼び出し名］を選択します。［スキルの呼び出し名］の箇所で「こけしビデオ」と入力します。

カスタムインテントを作成

　左メニューの［インテント（3）］の横の［追加］リンクをクリックします。ラジオボタンで［カスタムインテントを作成］を選択します。「KokeshiVideoIntent」と入力し、［カスタムインテントを作成］ボタンをクリックします。

カスタムスロットタイプを作成

　左メニューの［スロットタイプ（0）］の横の［追加］リンクをクリックします。ラジオボタンで［カスタムスロットタイプを作成］を選択します。「KOKESHI_ITEM_LIST」と入力し、［カスタムスロットタイプを作成］ボタンをクリックします。

スロット値の設定

　作成された「KOKESHI_ITEM_LIST」にスロット値を設定します。「このスロットタイプの新しい値を入力」と書かれた入力ボックスに「ナルコ」と入力し、左の［＋］ボタンをクリックします。続けて、「ヤマガタ」と入力し、左の［プラス］ボタンをクリックし、スロット値を設定します。

インテントスロットとサンプル発話の設定

　［インテントスロット］一覧の1番目の「新しいスロットを作成」と書かれた入力欄に「Kokeshi」と入力し、［＋］ボタンをクリックします。左のスロットタイプは先程作成した「KOKESHI_ITEM_LIST」を選択します。

　上のサンプル発話は「このインテントの呼び出しに使われると考えられる発話」と書かれた入力ボックスに「{Kokeshi}」と入力し、左の［＋］ボタンをクリックします。

インターフェイスの設定

　左メニューから［インターフェイス］を選択します。

　このスキルは、画面と動画の両方を使用するので［Displayインターフェイス］と［VideoApp］を有効にします。

　有効後は、画面と動画操作向けの［ビルトインテント］が左メニューで増えています。

スキルIDをコピー

　左メニューから［エンドポイント］を選択します。ラジオボタンで［AWS LambdaのARN］を選択します。すると、このスキルのスキルIDが表示されます。あとで使うので、コピーして控えておきます。

モデルの保存とビルド

　ここまでできたら、いったんモデルの保存とビルドをおこなっておきます。上の方にある［モデルを保存］ボタンをクリックします。保存が終わったら、［モデルをビルド］ボタンをクリックします。

Alexa Skills Kit SDK for Python

　開発環境（EC2）で、スキル用のディレクトリ「kokeshi_video」を作成し、作成したディレクトリに移動します。
　このディレクトリに以下のコマンドでAlexa Skills Kit SDK for Pythonをインストールします。

pip install ask-sdk -t .

Serverless　Framework

　Serverless　Frameworkで必要なファイルを自動生成します。

serverless create --template aws-python3

Serverless Framework参考記事
http://blog.serverworks.co.jp/tech/2016/09/07/serverless-framework-1-beta-1/

「serverless.yml」ファイルの編集

　自動生成された「serverless.yml」ファイルを以下の画像のように編集します。ここで先程控えておいたスキルIDを使います。

handler.py

　Alexa Skills Kit SDK for Python (Beta) の公式Githubにあるサンプル「Hello World」のコードをコピーし、画像や動画を扱うのに必要なクラスを追加で読み込んだり、Echo Spotで画像を表示したり、動画を流したい箇所と、文言を編集します。

サンプル「Hello World」
https://github.com/alexa-labs/alexa-skills-kit-sdk-for-python/blob/master/samples/HelloWorld/skill_using_decorators/hello_world.py

　画面をタッチして選択した場合のリクエストタイプは「Display.ElementSelected」になります。最初の選択画面でTokenにそれぞれ「naruko」と「yamagata」と設定しておいたので、ここではそのTokenの値によって、S3にあらかじめアップロードしてある鳴子系のこけしの動画か、山形系のこけしの動画を指定する流れにしています。

デプロイ

　Serverless　Frameworkでデプロイします。

serverless deploy

仕上げ

　仕上げの箇所は、（前回）の記事を参考におこなってください。

まとめ

　今回は、Alexa Skills Kit SDK for Python (Beta) を使って、Echo Spot用の動画を流すスキルを作ってみました。

　サンプルの「Hello World」を少しいじった簡単なスキルですが、よいスキルができたのではないでしょうか？
　動画を取り入れることによって伝えられる情報が増えるので、Alexaの活用方法がますます広がりそうですね！

　いや〜、ASK SDK for PythonとEcho Spotって本当にいいものですね！

最近ではNginx等のWEBサーバを利用するケースも増えていますがまだまだApache httpdを利用しているケースもあると思います。

今回はApache httpdを利用した環境で画像へのリクエストはログに残したくないや、
特定のディレクトリへのアクセスはログファイルを分けたいなどと行った要件が出てきた場合の設定方法についてご紹介します。

アクセスログの設定はCustomLogディレクティブ

ご存じかと思いますがアクセスログを出力させる場合CustomLogディレクティブについて振り返ります。
CustomLogディレクティブはログの出力先やフォーマットを指定します。

デフォルトの設定ではhttpd.confに以下のような設定が入っています。

CustomLog "logs/access_log" combined

CustomLogディレクティブはVirtualHostディレクティブの中でも設定でき、
以下のようなバーチャルホスト毎にアクセスログを分けるということは
おそらくほとんどの人がやったことがあるのではないでしょうか。

<VirtualHost>
ServerAdmin webmaster@host.example.com
DocumentRoot /var/www/vhosts/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
CustomLog logs/host.example.com-access_log combined
</VirtualHost>

そして今回のテーマである、リクエスト毎にログの出力先を変更する場合、
VirtualHostディレクティブ内にCustomLogディレクティブを複数書くことで実現します。

また、CustomLogは環境変数を引数に渡し出力させるログをコントロールすることができます。

リクエストの属性に基づいて環境変数を設定するSetEnvIfディレクティブ

画像や、特定のディレクトリへのアクセスがあった場合はログを記録しないやログファイルを
分けるといった条件分岐する場合にSetEnvIfディレクティブを利用することが可能です。

例えばfaviconへのアクセスがあった場合no_logという環境変数をセットしたい場合は以下のように書きます。

SetEnvIf Request_URI "favicon.ico$" no_log

また、testのディレクトリにアクセスがあった場合にtest_log環境変数をセットしたい場合は以下のように書きます。

SetEnvIf Request_URI "/test" test_log

CustomLog、SetEnvIfを利用してログの出力先を分ける

これまで説明してきたCustomLog、SetEnvIfの2つのディレクティブを利用して本題であるログの出力停止や
リクエストURI毎にファイルを分ける設定を行います。

今回の例ではhost.example.comのドメインを利用したバーチャルホストに
test01ディレクトリ、test02ディレクトリ、test03ディレクトリがあり、
このディレクトリへのアクセスはそれぞれ分けたいという要件があるとします。

また、favicon.icoへのアクセスはログに出力させない、ファイルを分けたログファイルは
分ける前のログファイルには出力させないという要件があったとします。

これらの要件を満たす設定は以下の通りになります。

<VirtualHost>
ServerAdmin webmaster@host.example.com
DocumentRoot /var/www/vhosts/host.example.com
ServerName host.example.com
ErrorLog logs/host.example.com-error_log
SetEnvIf Request_URI "favicon.ico$" no_log
SetEnvIf Request_URI "/test01" test01_log no_log
SetEnvIf Request_URI "/test02" test02_log no_log
SetEnvIf Request_URI "/test03" test03_log no_log
CustomLog logs/host.example.com-test01-access_log combined env=test01_log
CustomLog logs/host.example.com-test02-access_log combined env=test02_log
CustomLog logs/host.example.com-test03-access_log combined env=test03_log
CustomLog logs/host.example.com-access_log combined env=!no_log
</VirtualHost>

SetEnvIfディレクティブの解説

SetEnvIfディレクティブの四行については前項の設定とほぼ変わりません。
環境変数については空白区切りで複数設定することが可能です。

今回なぜ2つの環境変数を設定しているのかは後ほど解説します。

SetEnvIf Request_URI "favicon.ico$" no_log
SetEnvIf Request_URI "/test01" test01_log no_log
SetEnvIf Request_URI "/test02" test02_log no_log
SetEnvIf Request_URI "/test03" test03_log no_log

また、以下のような書き方をすることも可能です。
この場合後勝ちでの上書きとならず複数の環境変数がセットされます。

SetEnvIf Request_URI "favicon.ico$" no_log
SetEnvIf Request_URI "/test01" test01_log 
SetEnvIf Request_URI "/test01" no_log
SetEnvIf Request_URI "/test02" test02_log
SetEnvIf Request_URI "/test02" no_log
SetEnvIf Request_URI "/test03" test03_log
SetEnvIf Request_URI "/test03" no_log

CustomLogディレクティブの解説

次のログの出力設定です。
環境変数を引数に設定できるCustomLogディレクティブを使います。
そこにログファイルのパス、ログフォーマットの名前、環境変数を指定し以下のようになっています。

CustomLog logs/host.example.com-test01-access_log combined env=test01_log
CustomLog logs/host.example.com-test02-access_log combined env=test02_log
CustomLog logs/host.example.com-test03-access_log combined env=test03_log
CustomLog logs/host.example.com-access_log combined env=!no_log

env={環境変数}だとその環境変数にマッチしたリクエストのログが出力されます。
最後のアクセスログの出力設定は特定のディレクトリ以外へのアクセスログを出力させる設定です。

no_logを全てのSetEnvIfで設定した意味

CustomLogは原則全てのアクセスログを指定したファイルに出力します。
そのため以下の設定だとどうなるでしょうか。

SetEnvIf Request_URI "favicon.ico$" no_log
SetEnvIf Request_URI "/test01" test01_log
SetEnvIf Request_URI "/test02" test02_log
SetEnvIf Request_URI "/test03" test03_log
CustomLog logs/host.example.com-test01-access_log combined env=test01_log
CustomLog logs/host.example.com-test02-access_log combined env=test02_log
CustomLog logs/host.example.com-test03-access_log combined env=test03_log
CustomLog logs/host.example.com-access_log combined env=!no_log

答えはtest01ディレクトリにアクセスがあった場合はhost.example.com-test01-access_log のファイルと host.example.com-access_log の両方に同じログが出力されてしまいます。

これでは分けた意味が無いので今回はno_logの環境変数をつけてログが重複して出力されないよう設定してます。

まとめ

SenenvIfを利用して環境変数をセットし、その環境変数に合わせてログの出力先を変えることが可能です。
多すぎるログファイルは分析する際大変なこともあるので必要に応じてうまく分割してログを有効活用したいですね。