AWS re:Invent 2017 Security re:Cap レポート

こんにちは、ひろかずです。
今日は、12/14にアマゾン目黒オフィス(東京)で行われた AWS re:Invent 2017 Security re:Capに行ってきたので一筆書きます。

サブタイトルに re:Invent 2017のセキュリティを振り返る会 と題されていました。
年末にも関わらず、19時前に会場が満席!
AWS熱が依然高いことを感じさせます。

テーマはセキュリティ
ボルテージは否応がなく高まります。

今回の目的は…

  • re:Invent 2017前後で発表されたAWSセキュリティ関連情報の収集・共有の場の提供
  • AWSセキュリティを 企業組織内で活用できるか考える
  • re:Invent2018に参加する、そして登壇する

資料は公開されるので、話を中心に書いていきます。

例によってリアルタイム執筆ですので、誤字脱字、記載漏れ、表記ゆれはご容赦ください。

スティーブ・シュミットのメッセージ

  • 人とデータは切り離す(自動化している)
  • セキュリティの判断は人の判定が必要であるので、その瞬間に1人が稼働している。
  • いわゆるステレオタイプのSOCは持っていない

AWSセキュリティサービスアップデート①

AWS Single Sign-On

AWSソリューションアーキテクト
辻 義一

権限とコストを分ける方法

  • IAMユーザー/ポリシー
  • コストタグを付ける

要件によっては、分離できないこともある。
その場合は…

  • AWSアカウントを分ける
  • アカウント超えのデータ転送やピアリング接続ができる

そうすると権限の管理やログインが分離してしまって手間
シングルサインオンが求められる

  • SSOソリューションがあるが…
  • マネコンにアクセスするだけなのに高くて難しいのは辛い

AWS SSO

ユーザーポータルの提供
アプリのポータルも提供
既存のADを活用
簡単に実現

料金とリージョンと条件

SSO自体は無料
MSADやAD Connectorの費用がかかる
Virginiaのみ
AWS Organizationが必要

ユーザーリポジトリは、AD

  • Simple ADには対応していない

RADIUSによるワンタイムパスワード

ログイン先はAWS Organizationに参加しているAWSアカウント
SAML2.0に対応しているアプリケーション

アカウント毎に複数の権限を設定できる

  • 対象組織を選定し、パーミッションセットを設定できる(IAMポリシーと同じ文法)

AWSコンソールのログインフロー

SSOポータルから
ADの認証情報を使ってログイン
パー民ションセットに基いてあぷりが 表示され
選択したアカウントのIAM権限が割り当てられる

Cloudtrailで監査できる

アプリを登録

事前定義のアプリやカスタムアプリに、アプリのメタデータを登録する
SaaS側の定義手順も掲載されている
自分たちのアプリケーションにも実装することもできる

関連サービス

IAM

  • STSが裏で動いている

AWS Directory Service

  • 機能は似ているが、SSOはSAMLも追加

Cognito

  • モバイルアプリのSSOにも使える

ADとAWS ADの連携

パターン1

  • 既存ADとAWS MSADと信頼関係を結ぶ

パターン2

  • 既存AD環境とVPN接続して、AD Connectorで接続

日本から使うには?

パターン1

  • インターネットVPN
  • Direct Connect Gateway

パターン2

  • インターネットVPNサーバを経由する

パターン3(東京リージョンは来年…)

  • VPCのリージョン間接続

QA

LDAPが話せればいいなら、Azure ADと接続できる?

  • 信頼関係を結べるか謎

エンドユーザーセッション①

株式会社ドワンゴ
第二サービス開発本部
Dwango Cloud Service部 Consultingセクション
第二プロダクト開発部 第一セクション
鈴木 栄伍

スライドはニコナレに公開してます。
ニコナレは、AWSで構築されています。

re:Inventと今後のdwangoでのAWSセキュリティについて

re:Invent参加の背景

2016年から参加
初回は、最新動向把握、EBC(Executive Briefing Center)参加のため

  • 社内コンサルやAWSで構築したサービスのインフラエンジニアをやっていた流れ

参加して良かったこと

EBCにてAWS開発者と意見交換できた

  • 今年はAWS OrganizationやECSホウエンと会話した
  • サービスの利用感を感じることができるまたとない機会

Brakeoutセッションへの参加

  • 自分がやっていることと同じようなことを、世界の人たちがどうやっているか
  • 自分の方向性が合っているか分かる
  • DisneyとMarvel Studioのセッションが良かった

社内の困りごとと構想

アカウント(AWS, IAM)管理関連

  • rootアカウントフローが手動
  • Organizationでコマンド発行したい
  • AWS SSOが待ち遠しい

AWS上で構築されたシステムのNWセキュリティ

  • 何かあったときに後手後手に回る
  • FlowLogsとCloudTrailのログをMaisyとGuardDutyで検知できるようにしたい

AWSセキュリティの期待

  • 少数精鋭チームなので、マネジメントサービスで効率化したい
  • System ManagerとGuardDutyの連携
  • Amazon Inspectorとの連携もしてくれるといいなぁ

AWSセキュリティサービスアップデート②

Amazon GuardDuty AWSパートナーソリューションアーキテクト
酒徳 知明

副題:AWSクラウドの脅威検知の実装

DevSecOps

  • セキュリティベースラインがある中でDevOpsを回すのがいい

Amazon GuardDuty

脅威リスクを検知するサービススコープ

  • 脅威リスクのモデルは、膨大なデータサンプルが必要
  • データが多ければモデルの精度が上がる
  • 何をリスクと定義するか?
  • Bad IPや異常検出、機械学習で統合分析している

利用リージョン

  • 東京リージョン使えます!

対象

  • EC2またはIAMに置ける脅威を検出
  • エージェントレス、センサーレス、アプライアンスレス
  • 30日間の無料枠(課金状況を見て高かったら止められる)

高機能なので、無料枠で是非試して!

インプット

  • VPC Flow Logs
  • Cloud Trail
  • DNS Log

アラート

リスクのタイプ(Detection Type)

  • 悪意のあるスキャン(ポートスキャンとか)
  • インスタンスへの脅威(BitCoin掘り掘りとか)
  • アカウントへの脅威(通常と異なるAPIの発行とか)

サービスデリバリーコンセプト

− いかに簡単に有効にできるか
– CloudTrailが有効になってないとかの排除

既知の脅威リストのカスタマイズ

  • ユーザー独自の脅威IPリストとのギャップを埋めるTrusted IP ListThreat IP List

検知の閲覧は2系統

  • AWS Management Console
  • API/JSON

重要度

  • 0~3.9(青)
  • 4.0~6.9(黄)
  • 7.0~10.0(赤)

検知時アクション

  • CloudWatchでアラートでもOK

検知内容は

課金形態

  • イベントあたり(CloudTrailは1億イベントあたり)
  • ログデータあたり(FlowLogs/DNSログは、GBあたり)
  • とりあえず有効化して、無料枠で見極めて!

展開方式

  • CloudFormation -Stacks- で、全リージョン、全アカウントに同じセキュリティベースラインを展開できる
  • アカウントに対してやOrganizationのヒエラルキーを対象にできる

パートナー

  • 多数のセキュリティベンダーが取り扱う
  • パートナーインテグレーションは、パートナーがGuardDutyのデータを持っていく方式
  • 各ベンダー、無料トライアルを提供しているのでぜひ使ってみて!

エンドユーザーセッション②

株式会社リクルートテクノロジーズ
ITソリューション統括部 サイバーセキュリティエンジニアリング部
セキュリティオペレーションセンター
安東 美穂 様

リアルタイム執筆はご遠慮をーとのことです。
残念

LT①

三井物産セキュアディレクション株式会社
プロフェッショナルサービス事業部
マネージャー
佐藤 裕貴 様

サイバーセキュリティ専門会社のre:Invent振り返り

Keynoteの中でDynamoを使っているサービス
Tinder
出会い系アプリ
研究用途で使ってます

セキュリティ系セッション会場は遠かったので行かなかった。

  • 複数名で担当を分けて行くのが良い

Managed Rule for AWS WAF

  • AlertLogicがパートナーとして参加
  • Wordpress向けの仮想パッチを提供
  • Shareが大きいところに投入
  • SQL/SQLiが攻撃ボリュームが大きい
  • Rule作成から開放されよう!

Amazon GuardDuty

  • AWS不正操作、悪意のあるアクセス元の検知
  • サードPartyベンダーのセキュリティサービスも利用して、網羅的なセキュリティを実現

LT②

トレンドマイクロ株式会社
セキュリティエキスパート本部
パートナービジネスSE部 パートナーSE課
姜 貴日 様

Deep Securityを出典してきました。
8カテゴリの中でトレンドマイクロがセキュリティ部門一位(実質Deep Security)

Amazon GuardDutyとは?

  • Deep Securityとはかぶらない(一部かぶる)
  • GuardDutyは、フルマネージドと検出
  • Deep Securityは、検知と防御
  • ShildもWAFも出た時は問い合わせがあった
  • Deep Securityは、サーバー内部で攻撃を遮断するので根本的に違う

Amazon GuardDutyとDeep Securityの連携

  • 検知内容に基いて、対象IPを遮断
  • OSS扱いでGitに公開中

ManagedRule

  • マーケットプレイスで購入すると、サポートは米国になる
  • トレンド提供のRuleは、Apache SuiteとCMS向け

LT③

AWS WAF Partner Managed Rules
AWSソリューションアーキテクト
藤倉 和明

今日はデモ
帰ったら有効にしたくなる話をします

WAF管理画面にMarket Placeが増えてるので、そこから有効化

  • 間を取ってFortinetを選択(笑)
  • No overrideは防御モード。
  • まずは、Override on Counntで慣熟運用すること。

とにかく最高なので、Countではじめよう!

大盛り上がりで終わりました!
今日はここまでです。
お疲れ様でした。

続きを読む

GuardDutyのイベントをSplunkで検索・可視化

re:Invent 2017で発表されたGuardDutyですが、Splunkでそのデータを取り込んで分析できるとのことなので、さっそく試して試してみました。

記事(英語)
Splunk Announces New Integrations With Amazon Kinesis Firehose and Amazon GuardDuty

Amazon GuardDutyって?

Amazon GuardDuty – 継続したセキュリティ監視と脅威の検知

(抜粋)

GuardDutyは 脅威情報を含む複数のデータストリームから、悪意のあるIPアドレス、デバイスドメインを認識し、あなたのAWSアカウントで悪意のある、もしくは不正な行動があるか特定するために学習します。VPC Flow Logs、CloudTrail のイベントログ、DNS ログを集め組み合わせることにより、GuardDuty は非常に多くのことなったタイプの危険性のある、悪意のある行動を検知します。

なるほど、AWSリソースの脅威を機械学習で発見するんですね。

Splunkって?

https://www.splunk.com/
ログ分析のソフトウェア。
あらゆるマシンデータをインデックスして検索や可視化、アラート通知や分析ができるっていう優れモノ。

設定してみた

5つのステップで設定できます。
1. SplunkにAppインストール
2. Splunk HTTP Event Collector有効化
3. Amazon GuardDuty有効化
4. AWS Lambdaでテンプレから関数作成
5. AWS CloudWatchでGuardDutyとLambdaを設定したルールを作成

ということで、設定方法を書いていきます。

Splunk設定

まずはデータの受け口であるSplunkの設定から
App入れてHTTP Event Collector (HEC)有効化するだけです。

Appインストール

このApp↓をSplunkインスタンスにインストールしましょう。
AWS GuardDuty Add-on for Splunk

(補足)Appインストール方法

Splunkにログインした後、左側のメニューにある歯車アイコンをクリック
Screen Shot 2017-12-14 1.31.38 PM.png

上記リンク先からAppをダウンロードして ファイルからAppをインストール からインスコ、もしくは、 他のAppを参照 からGuardDutyを検索してインスコ
Screen Shot 2017-12-14 1.35.35 PM.png

データ入力設定

Appインストール完了後、ログイン後のトップ画面に aws_guardduty というAppが追加されています。
Screen Shot 2017-12-14 1.38.53 PM.png

早速 aws_guardduty に移動
Screen Shot 2017-12-14 1.41.51 PM.png

まだ何もデータが入ってきていない状態なので、データ受け取りとしてHTTP Event Collectorを設定します。

右上の 設定 から データ入力 をクリック
Screen Shot 2017-12-14 1.42.50 PM.png

HTTPイベントコレクタ をクリック
Screen Shot 2017-12-14 1.44.07 PM.png

別の記事でHECの設定方法は書いたので、これ以降の手順は割愛します。こちらを参照ください。
https://qiita.com/kikeyama/items/515d65906537239e04d2#splunk%E3%81%AE%E8%A8%AD%E5%AE%9A

(注意)ソースタイプは aws:cloudwatch:guardduty を選択してください。

設定後のトークンはどこかにコピペしておいてください。

GuardDuty設定

AWSコンソールからAmazon GuardDutyに行って有効化。

今すぐ始める をクリック
Screen Shot 2017-12-14 1.15.38 PM.png

GuardDutyの有効化 をクリック
Screen Shot 2017-12-14 1.16.47 PM.png

GuardDuty設定は完了
Screen Shot 2017-12-14 1.20.55 PM.png

今はまだ空っぽですけど、とりあえずGuardDutyの設定はこれでおしまいです。

Lambda設定

まずは 関数の作成
これでSplunkにHTTPでイベントをPOSTするインターフェースを作ります。
Screen Shot 2017-12-14 1.49.39 PM.png

設計図 (Blueprints) を選択して、検索画面に splunk と入力して検索
Screen Shot 2017-12-14 1.51.43 PM.png

Splunk Logging を選択
Screen Shot 2017-12-14 1.53.08 PM.png

下にスクロールすると環境変数の設定があるので、こちらにSplunkのHECエンドポイントURLとトークンを設定
Screen Shot 2017-12-14 1.58.09 PM_mosaic.png

で、名前をつけて保存

その後、作成した関数を編集して sourcetype の値を aws:cloudwatch:guardduty に上書き

index.js
    // Advanced:
    // Log event with user-specified request parameters - useful to set input settings per event vs token-level
    // Full list of request parameters available here:
    // http://docs.splunk.com/Documentation/Splunk/latest/RESTREF/RESTinput#services.2Fcollector
    logger.logEvent({
        time: Date.now(),
        host: 'serverless',
        source: `lambda:${context.functionName}`,
        sourcetype: 'aws:cloudwatch:guardduty',
        event: event,
    });

CloudWatch設定

ルールを一個作りましょう
Screen Shot 2017-12-14 2.08.15 PM.png

サービス名は GuardDuty 、ターゲットは Lambda関数 から、先ほど作成したLambda関数を選択
Screen Shot 2017-12-14 2.09.28 PM.png

あとは名前をつけて保存

以上、すべての設定は完了!

GuardDutyイベントを検索

ということで、しばらく待つとGuardDutyデータがSplunkにインデックスされてきました。

Screen Shot 2017-12-14 2.16.08 PM_mosaic.png

ダッシュボード

GuardDuty Appには既成のダッシュボードがあるようです。

GuardDuty Examples からダッシュボードに移動してみましょう
Screen Shot 2017-12-14 2.19.22 PM.png

Screen Shot 2017-12-14 12.42.27 PM.png

脅威が検知されてしまったみたいですね・・・。
比較的シンプルなダッシュボードですが、可視化やモニタリングには十分かな、と。
運用してみて足りない部分は自前でダッシュボード作ってみよう。

最後に

どうやらダッシュボード内のテーブルをクリックすると、Splunk App for AWSにドリルダウンできるようです。

Kinesis FirehoseからSplunkにデータを流せるとのことですし、せっかくなので近日中にこのAppも設定してみて記事を書いてみようかなと思います。

続きを読む

Goadを使った負荷試験とパフォーマンス分析手法について

この記事は『ドワンゴ AdventCalendar 2017』の14日目の記事です。

はじめに

アプリケーション開発において、近年ではQA(Quality Assurance)という品質やパフォーマンスを保証することに対してエンジニアリングがどう対応していくかといったことに注目が集まりつつあります。

例えばGoogleでは既存の品質保証プロセスで存在していた手動プロセスを自動化するという試みが行われており[1]、MercariではQA-SETチームという職務横断型プロジェクトの発足といった取り組みがなされているようです[2]。

今回はこのようなQAの確認項目の一つである負荷試験とパフォーマンス分析についてお話できればと思います。

Goadの紹介

負荷試験(LoadTest)は、構築したシステムがパフォーマンス要件を満たしているかの確認、ボトルネックの発見、パフォーマンス最大化のために行われる測定プロセスです[3]。

負荷試験に使われるツールとしてはApache JMeterなどが有名でしょうか。
今回はJMeterという選択肢もあったのですが、自分たちでそこそこ高性能なサーバを何台か用意しなければならないことや、実際にアクセスがスパイクした場合と環境を似せるためにGoadを採用してみることにしました。

Goadは、AWS LambdaとSQSを使ったオープンソースの負荷試験ツールで、最大で同時10万リクエストまで行うことができます。実際に同時接続数を数百に設定し、数万リクエスト程度の負荷試験を行ったところ問題なく動作している感じでした。Lambdaの料金も数十万リクエスト程度ではほとんどゼロなので非常にコストパフォーマンスが高いツールだと思います。

スクリーンショット 2017-12-14 1.28.47.png
(図1: https://goad.io/ から引用)

インストール

バイナリをこちらからDownloadして適当な場所に展開する必要があります。
MaxOS版のリンクがなぜか404なのでMacOSを使っている場合は、githubのreleasesからダウンロードできます。

使い方

基本的にはReadmeの通りに実行するだけですが、日本語の記事だと

Lambda を利用した分散 Web 負荷テストツール Goad を使ってみた
こちらの記事が参考になるかと思います。

ただ現在の最新版(v2.0.4)を実行すると、Goadの内部で使っているSQSのFIFOキューがまだ東京リージョンに対応していないのでエラーが発生します。

そのため東京リージョンでGoadを動かしたい場合v2.0.3を使用する必要があります。

最新版を使うとハマるので要注意です。

サービス公開前や開発環境でテストを行う

実際にGoadを使って負荷試験を行う際に問題となるのが、Lambdaを使ってrequestが行われる都合上アクセス元のIPアドレスを固定することができないことです。

公開前のサービスや開発環境の場合、Firewallでアクセス制限をかけていることがほとんどであるため、Lambdaのような非固定的なPublicIPからのアクセスをどう扱うかは難しいところです。

とはいえLambdaが使用するEC2インスタンスに使われるIPアドレス帯はリージョンごとに決まっているため(https://ip-ranges.amazonaws.com/ip-ranges.json)、今回は上記のリンクからAWS東京リージョンのEC2インスタンスに割り当てられているCIDRを取得し、このCIDRからのみアクセスを許可するSecurityGroupを作成、負荷試験時のみアクセスを受け付けるようにして対応しました。

上記のSecurityGroupを作成するサンプルスクリプトをベタ書きですがNode.jsで作りましたのでご参考まで。


const AWS = require('aws-sdk')
const request = require('request-promise');

AWS.config.update({ region: 'ap-northeast-1' });
const ec2 = new AWS.EC2({ apiVersion: '2016-11-15' });

// security groupを作成するVPCのID
const vpc = "";

const paramsSecurityGroup = {
  Description: 'security group for load test.',
  GroupName: 'aws-tokyo-region-ec2-http-inbound',
  VpcId: vpc
};

let paramsIngress = {
  GroupId: "",
  IpPermissions: []
};

ec2.createSecurityGroup(paramsSecurityGroup).promise()
  .then((data) => {
    const SecurityGroupId = data.GroupId;
    console.log("Security Group Created", SecurityGroupId);
    paramsIngress.GroupId = SecurityGroupId;

    const options = {
      url: 'https://ip-ranges.amazonaws.com/ip-ranges.json',
      method: 'GET',
      headers: { 'Content-Type': 'application/json' }
    }

    return request(options);

  }).then((body) => {
    const prefixes = JSON.parse(body).prefixes;

    // 東京リージョンのEC2インスタンスに使われるip-rangeを抜き出してparamsにset
    prefixes.forEach((element) => {
      if (element.service === "EC2" && element.region === "ap-northeast-1") {
        paramsIngress.IpPermissions.push({
          IpProtocol: "tcp",
          FromPort: 80,
          ToPort: 80,
          IpRanges: [{ "CidrIp": element.ip_prefix }]
        })
      }
    });
    return ec2.authorizeSecurityGroupIngress(paramsIngress).promise();

  }).then(() => {
    console.log("Ingress Successfully Set.");
  }).catch((err) => {
    console.log("Error", err);
  });

USEメソッド

負荷試験を行う環境が整ったところでさあ実際にやってみようと思うわけですが、次に負荷をかけてみるのはいいけどそもそもシステムパフォーマンスの分析ってどうやればいいの?とか、そもそも何の指標をみればいいの?という疑問が湧きます。

ここで使えるのがUSEメソッドです。

USEメソッドは、システムの個々のリソースを使用率(Utilization)、飽和(Saturation)、エラー(Errors)の3つの観点から分析する、パフォーマンス分析手法の一つです。Brenda Gregg氏が提唱する方法であり、彼が著者である詳解システムパフォーマンスという本にも出てきます。

詳細はGregg氏のこちらのブログエントリにもまとまっています。

具体的に何をみるのか

USEメソッドはCPUやメモリ、ネットワークといったシステムを構成する全てのリソースに対して以下の3つの観点から分析を行います。

  • 使用率.. ある時間内にどれだけ対象のリソースが使われていたか
  • 飽和… 対象リソースにおいて処理できていない要求がどれだけあったか
  • エラー.. エラーイベントの回数

例えばCPUやメモリの場合は使用率は仮想環境では vmstat などのコマンドで取得できるリソース使用率になりますし、飽和はCPUの場合はLoadAverage、メモリの場合はswap-outの値になります。

使用率は馴染みがありますがなぜ飽和をチェックしなければならないのでしょうか。

これは使用率の定義が、ある時間内で定義される平均の側面を持っているからです。例えば一分あたりの使用率が低くても、ある特定の瞬間の使用率がすごく高く、バーストして処理しきれない場合というのは想定できます。例えばアクセスがスパイクするような場合がありますね。
そのためパフォーマンス検証はリソースが飽和して処理ができていない要求は存在しなかったか、要はキューイングされて処理待ちになっているかどうかをチェックする必要があります。

USEメソッドの分析手順

USEメソッドは各リソースに対して以下の観点からパフォーマンスの分析を行います。

  1. Errorが発生していないか
  2. 利用率は高いか
  3. 飽和はどの程度あるか

flow chartで表すと以下になります

スクリーンショット 2017-12-13 22.51.39.png
(図2: Gregg氏の記事から引用)

Greggの記事にもありますが、環境によってはリソースの指標を取得することが難しかったりするものもあるため(クラウド環境のCPUエラーなど)そのあたりは臨機応変に取捨選択します。
自分は負荷試験時に例外などのアプリケーションエラーが発生していた場合はまずそこから分析し、その後でCPUやメモリ、ネットワークといったリソースの使用率と飽和を分析していくというやり方にしています。

USEメソッドの利点

さて、なぜ自分がUSEメソッドをここで紹介したかというと、このメソッドはパフォーマンスを分析するための極めてシンプルで見通しの良いロールモデルだと思うからです。
Gregg氏曰くUSEメソッドは5%の努力で約80%の問題を解決することができる手法とのことですが、パフォーマンス分析時に調べるべき指標や内容が上記の手順のようにはっきりとしているため効率良く解析を行うことができました。

まとめと所感

QAの一環として、負荷試験ツールであるGoadとUSEメソッドを使ったパフォーマンス分析手法を紹介しました。QAやSREというとまだまだ概念としては新しく、なおかつ対象の範囲が広いためどうしても内容が抽象的になってしまいます。

しかし実際のタスクをこなしていくと、まだまだ手動で行われている部分が多く、またこれまでの慣例や経験則から導かれたヒューリスティックな設定項目があったりと様々な効率化ポイントがあることがわかります。

ソフトウェア開発というと要件定義や設計に焦点があたりがちではありますが、ユーザ数が増えるにつれリリース時に要求されるクオリティのハードルが高まり、必然的にQAのマネジメントが必要になってきます。
そのため今後QAの効率化と自動化が、機敏な開発を継続していくためにますます重要な要素になると思っています。

今回の記事がさらなる開発の効率化に少しでも貢献できれば幸いです。

参考

[1] From QA to Engineering Productivity, https://testing.googleblog.com/2016/03/from-qa-to-engineering-productivity.html
[2] メルカリQA-SETチームが考えているQAやテストの未来のはなし, http://tech.mercari.com/entry/2017/08/18/100138
[3] Load testing, https://en.wikipedia.org/wiki/Load_testing

続きを読む

【初心者向け】Amazon GuardDuty入門 #reinvent

Amazon GuardDuty は、VPC フローログおよび AWS CloudTrail イベントログを分析および処理する継続的なセキュリティモニタリングサービスです。GuardDuty は、セキュリティロジックと AWS の使用統計を使用して、AWS 環境内の予期しない、未承認および悪意のあるアクティビティの可能性を特定します。 続きを読む

Amazon Athenaではじめるログ分析入門

はじめに

Amazon AthenaはAWSの分析関連サービスの1つで、S3に保存・蓄積したログに対してSQLクエリを投げて分析を行えるサービスです。分析基盤を整えたり分析サービスにログを転送したりする必要が無いため、簡単に利用できるのが特長です。

今回はAthenaを使ってこんなことできるよー、というのを紹介したいと思います。

※社内勉強会向け資料をQiita向けに修正して公開しています

ログ分析とAmazon Athena

ログ分析は定量的にユーザ行動を分析してサービスの改善に役立つだけでなく、障害時の調査にも役立つなど非常に便利です。ログ分析に利用されるサービスとしてはGoogle BigQueryやAmazon Redshiftなど様々なものがありますが、その中でAmazon Athenaの立ち位置を確認したいと思います。

ログ分析の流れ

ログ分析の基盤の概念図は下記のようになります。

Screen Shot 2017-12-11 at 17.22.23.png

この図からわかるように、考えることは多く、どのようなログを出すのか、どのように分析用のDBやストレージにデータを移すのか(ETL)、分析エンジンは何を使うのか、可視化のためにどのようなツールを利用するかなどの検討が必要です。

また初期は問題なく動作していてもデータ量が増えるうちに障害が起きたりログがドロップしてしまうなど多くの問題が出てきます。

そのため、多くの場合専門のチームが苦労をしながら分析基盤を構築・運用しています。

Amazon Athenaとは

Amazon Athenaはサーバレスな分析サービスで、S3に直接クエリを投げることができます。AWS上での分析としてはEMRやRedShiftなどがありますが、インスタンス管理などの手間があり導入にはハードルがありました。

Athenaでは分析エンジンがフルマネージドであり、ログ収集の仕組みやサーバ管理の必要がなく分析クエリを投げられます。

Screen Shot 2017-12-11 at 17.22.30.png

RDBのテーブルなどとのJOINは(データをS3に持ってこないと)できないためあくまで簡易的な分析にとどまりますが、ログを集計するというだけであればとても簡単に分析の仕組みが構築できます。

Screen Shot 2017-12-05 at 14.28.56.png

料金について

BigQueryなどと同じクエリ課金です。一歩間違えると爆死するので注意は必要です。

  • ストレージ

    • S3を利用するのでS3の保存料金のみ
  • クエリ
    • スキャンされたデータ 1 TB あたり 5 USD
  • データ読み込み
    • S3からの通常のデータ転送料金。AthenaとS3が同一リージョンなら転送料金はかからない。

使ってみる – ELB(CLB/ALB)のログを分析

Athenaのユースケースとして一番簡単で有用なのはELBのログ分析だと思っています。ここでは簡単に利用手順を紹介します。

1. S3バケットを作成し適切なアクセス権を付与

ドキュメントを参考にS3のバケットを作成し、アクセスログを有効化すると、15分毎にアクセスログが出力されます。

http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/load-balancer-access-logs.html#enable-access-logging

2. Athena でテーブルを作る

公式ドキュメントにそのまま利用できるクエリが載っているので、AWSマネージメントコンソールからAthenaのQueryエディタを開きこれを実行します。

http://docs.aws.amazon.com/athena/latest/ug/application-load-balancer-logs.html

3. クエリを実行

Athenaの実行エンジンPrestoは標準SQLなので通常のRDBMSへのクエリのように実行できます。

SELECT count(*)
FROM alb_logs

使ってみる – ELBログから様々なデータを取得する

ELBのログに出力されている内容はそこまで多くないものの、意外と色々取れたりします。

1. あるエンドポイントの日別アクセス数を調べる

SELECT date(from_iso8601_timestamp(time)),
         count(*)
FROM default.alb_logs
WHERE request_url LIKE '%/users/sign_in'
        AND date(from_iso8601_timestamp(time)) >= date('2017-12-01')
GROUP BY  1
ORDER BY  1;

2. 直近24時間の500エラーの発生数を調べる

SELECT elb_status_code,
         count(*)
FROM default.alb_logs
WHERE from_iso8601_timestamp(time) >= date_add('day', -1, now())
        AND elb_status_code >= '500'
GROUP BY  1
ORDER BY  1;

3. レスポンスに1.0s以上時間がかかっているエンドポイント一覧を出す

SELECT request_url,
         count(*)
FROM alb_logs
WHERE target_processing_time >= 1
GROUP BY  1
ORDER BY  2 DESC ;

4. ユーザ単位の行動ログを出す

Cookieは出せないのでIPから。連続したアクセスだとポートも同じになるのでそこまで入れても良い。

SELECT *
FROM alb_logs
WHERE client_ip = 'xx.xxx.xxx.xxx'
        AND timestamp '2017-12-24 21:00' <= from_iso8601_timestamp(time)
        AND from_iso8601_timestamp(time) <= timestamp '2017-12-25 06:00';

5. あるページにアクセスした後、次にどのページに移動しているかを調べる

3回joinしているのでちょっとわかりづらい。これもIPがユーザー毎にユニークと仮定しているので正確ではない。

SELECT d.*
FROM 
    (SELECT b.client_ip,
         min(b.time) AS time
    FROM 
        (SELECT *
        FROM alb_logs
        WHERE request_url LIKE '%/users/sign_in') a
        JOIN alb_logs b
            ON a.time < b.time
        GROUP BY  1 ) c
    JOIN alb_logs d
    ON c.client_ip = d.client_ip
        AND c.time = d.time
ORDER BY  d.time

運用してみる

Athenaについて何となくわかってもらえたでしょうか。次に、実際に運用するときのためにいくつか補足しておきます。

パーティションを切る

ログデータはすぐにTB級の大きなデータとなります。データをWHERE句で絞るにしてもデータにアクセスしないことには絞込はできませんので、Athenaは基本的には保存されている全てのデータにアクセスしてしまいます。

これを防ぐためにパーティションを作って運用します。パーティションを作成するにはCREATE TABLEでPARTITIONED BYでパーティションのキーを指定しておきます。

CREATE EXTERNAL TABLE IF NOT EXISTS table_name (
  type string,
  `timestamp` string,
  elb string,
  client_ip string,
  client_port int,
  target_ip string,
  target_port int,
  request_processing_time double,
  target_processing_time double,
  response_processing_time double,
  elb_status_code string,
  target_status_code string,
  received_bytes bigint,
  sent_bytes bigint,
  request_verb string,
  url string,
  protocol string,
  user_agent string,
  ssl_cipher string,
  ssl_protocol string,
  target_group_arn string,
  trace_id string )
 PARTITIONED BY(d string)
 ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe' WITH SERDEPROPERTIES (  'serialization.format' = '1',
  'input.regex' = '([^ ]*) ([^ ]*) ([^ ]*) ([^ ]*):([0-9]*) ([^ ]*):([0-9]*) ([.0-9]*) ([.0-9]*) ([.0-9]*) (-|[0-9]*) (-|[0-9]*) ([-0-9]*) ([-0-9]*) \"([^ ]*) ([^ ]*) (- |[^ ]*)\" ("[^"]*") ([A-Z0-9-]+) ([A-Za-z0-9.-]*) ([^ ]*) ([^ ]*)$' )
LOCATION
 's3://bucket_name/prefix/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/'

実際のパーティションの構築るには2種類の方法があります。

http://docs.aws.amazon.com/athena/latest/ug/partitions.html

1.ファイルの保存パスにパーティションの情報を入れる(Hiveフォーマット)

s3のkeyを例えば s3://bucket_name/AWSLogs/123456789012/d=2017-12-24/asdf.logという形で保存します。

この状態で次のコマンドを実行すると自動でパーティションが認識されます。

MSCK REPAIR TABLE impressions

2.ALTER TABLEを実行する

ELBのログなどAWSが自動で保存するログは上記のような形式で保存できないので、直接パーティションを作成します。

ALTER TABLE elb_logs
ADD PARTITION (d='2017-12-24')
LOCATION 's3://bucket/prefix/AWSLogs/123456789012/elasticloadbalancing/ap-northeast-1/2017/12/24/'

これらを毎日実行するようなLambdaなどを作成して運用することになります。

BIツールを利用する

Athenaを実行するだけだと生データが手に入るだけなので、必要に応じてグラフにしたりといったことが必要になるかと思います。

ExcelやGoogle SpreadSheetでも良いですが、BI(Business Intelligence)ツールと呼ばれるものを使って定期的なクエリ実行やその可視化、通知などを実現できます。

Athenaに対応しているものではAWSのサービスの一つであるQuickSightやRedashがあります。

列指向フォーマットについて

データ量が増大してくると、クエリの実行時間が増えると同時にお金もかかるようになってきます。そんな時に利用を検討したいのが列指向フォーマットです。

列指向フォーマットでは列単位でデータを取り出せるため、JOINやWHEREを行う際にすべてのデータを取り出す必要がありません。そのため、高速にかつ低料金でクエリを実行できます。

通常のログは行単位で出力されているため、あらかじめ変換処理を行う必要があります。これにはEMRを利用する方法がAWSで解説されているので、大量データに対して頻繁にクエリを行う際は利用を検討してみてください。

https://aws.amazon.com/jp/blogs/news/analyzing-data-in-s3-using-amazon-athena/

アプリケーションのログを分析する(CloudWatch Logsの場合)

ここまではELBのログでここまでできる的な内容でしたが、実際にはアプリケーションが出力したログを利用したくなります。とにかくS3に集めれば良いのでFluentdなどで集めればOKです。

ただ最近はECSやElastic Beanstalkを使っているとCloudWatch Logsに集約しているケースも増えてきているのではないかと思います。この場合S3に持っていくのが微妙に手間になってきます。CloudWatch LogsではS3にログをエクスポートできますが、通常では特定のログをフィルタをして出力したいと思うので、少し工夫が必要になります。

例えば下記のような構成です。

Screen Shot 2017-12-11 at 17.43.23.png

こちらについては https://aws.amazon.com/jp/blogs/news/analyzing-vpc-flow-logs-with-amazon-kinesis-firehose-amazon-athena-and-amazon-quicksight/ この記事などが参考になります。

おわりに

Amazon Athenaの使い方について自分の持っている知識をまとめてみました。Athenaの利用までの簡単さはログ分析の導入としては非常にハードルが低く、とても有用だと思っています。

他の分析サービスとどう違うのかとかは難しいところですが、AthenaはManagedなPrestoであってそれ以上ではなく、EMRやRedshiftの方が上位互換的に機能が多いので、Athenaで出来ないことが出てきたら他を使うとかでも良いのかなぁと思っています。(ここは詳しい人に教えて貰いたいところ。。)

S3 Selectという機能も出てきてS3ログの分析が更に柔軟になっていく予感もありますのでその導入としてのAmazon Athenaを触ってみてはいかがでしょうか。

注意事項

  • ELBログについて

    • ベストエフォート型のため、全てのログの取得は保証されていません
    • ELBのログはUTCで保存するのでJSTの日付とはパーティションがずれます
    • ログは15分ごとにまとめられるので 23:45〜23:59 頃のログは翌日のパーティションに入ってしまいます

参考資料

続きを読む

ElasticBeanstalkでクロスゾーン負荷分散されない問題の解決【AWS】

EB環境を気軽に使い捨てしたい

本番環境からCloneしているのに上手く動くor動かないの分岐があり、悩んでいました。
本腰入れて調べたところ、クロスゾーン負荷分散がうまくいっていないようでした。
ap-northeast-1aにインスタンスが立つとInServiceになるけど、1cに立つとならない、みたいな。

「おかしいな、EBのクロスゾーン負荷分散オプションはチェック入れてるのにな。」

そう思って、自力解決を諦め、AWSのサポートに連絡したところ、無事解決したのでメモしておきます。

いやぁ。AWSのビジネスサポートは解答が的確で助かります。ほんの少しのコストでプロフェッショナルがサクっと問題解決してくれるかとおもうとありがたいですよね。

クロスゾーン負荷分散に関するオプション設定は2ヶ所ある

2ヶ所ある、というと正確な表現ではないかも。

要は、EB側の設定と、ELB側の設定があり、今回でいうとEB側しか出来ていなかったということです。

ELB側の設定は、EBコンソールの 設定 > VPC > 「アベイラビリティーゾーンの ELB インスタンスと EC2 インスタンスに対しては異なるサブネットを選択します。」配下から行えます。

ここでチェックの入っているAZにしかルーティングされないよということでした。そんな設定あったんか~い!しらんかった~!

おわりに

EBについてはだいたい把握してるつもりだったんですが見事にハマりました。
Bussinessサポートはいっててよかった~!(感謝の宣伝)

まあでも、ロギングちょっと弱いよな~とは思いますよね。EB。

続きを読む

AWS PrivateLinkをメンテナンスラインとして使う #reinvent

ども、大瀧です。 AWSの年次イベントre:Invent 2017で発表されたPrivateLink for Customer and Partner Serviceは異なるAWSアカウントやVPCにプライベート接続を提供する新しい機能です。PrivateLinkの設定手順は以下のブログ記事を参照ください。 AWS PrivateLinkで異なるAWSアカウント間の重複するVPCレンジ間 … 続きを読む

TerraformとDataDogで始めるMonitoring as Code入門

はじめに

この記事は、dwango advent calenderの12日目の記事です!
今年に入ってから、自分の担当しているプロダクトではDataDogを利用してシステムの監視を行なっています。
DataDogを導入したキッカケの一つとして、Terraformで監視設定を構成管理配下に置いてコード化したい!ということがありました。
同じ設定をGUIでぽちぽちするのはなかなかに辛いですし、ドキュメントを書き続けるのも辛いので、すでにAWSのインフラ環境構築で行なっていることと同じようなフローでコード化が行えるのは魅力の一つでした。
ということで、今回は簡単なサンプルコードと共に、TerraformとDataDogで始めるMonitoring as Code入門したいと思います。

事前に必要な作業

  • AWSアカウント、アクセスキー/シークレットキーの準備

    • 1インスタンスぽこっと立ち上げます
  • terraformのインストール
    • 今回は0.11.x系を対象に
    • tfenvが便利
  • DataDogの API Key, Application Keyの払い出し
  • DataDogのslack Integration連携

Terraform DataDog Providerでは何を操作できるのか

2017/12現在、TerraformのDataDog Providerでは以下のリソースの操作を行うことができます。

この記事では、入門ということで、monitorのみ設定します。
コードはこちらにあげてあります。

AWS環境の立ち上げ

  • 1. 上記のリポジトリをgit clone後、下記のようなコマンドでインスタンスに登録するkey_pair用の秘密鍵/公開鍵を作成します
    ※AWS構築時のアクセスキーやプロファイルの設定については割愛します
$ cd aws/
$ ssh-keygen -t rsa -N "" -f batsion
$ mv batsion batsion.pem
  • 2. secret.tfvars.templateをコピーし、作成した公開鍵とagentのインストール時に利用するDataDogのAPI Keysを埋めます
$ cp secret.tfvars.template secret.tfvars
$ vim secret.tfvars
bastion_public_key    = "実際の公開鍵"
datadog_api_key = "実際のAPI Key"
  • 3. terraformを実行し、VPC作成〜インスタンス作成まで行います(apply時にapproveを求められるのでyesを入力
# terraform provider取り込み
$ terraform init
# plan実行
$ terraform plan  -var-file=secret.tfvars
# apply実行
$ terraform apply -var-file=secret.tfvars

以上で監視対象のインスタンスが作成されました。
追加されるとこんな感じにDataDogの方に現れます。
スクリーンショット 2017-12-12 1.49.40.png

DataDogの監視設定追加

さて、続けてmonitor設定の追加を行います。

  • 1. secret.tfvars.templateをコピーし、DataDogのAPI Keys, Application Keysを埋めます
$ cp secret.tfvars.template secret.tfvars
$ vim secret.tfvars
datadog_api_key = "実際のAPI Key"
datadog_app_key = "実際のApplication Key"
  • 2. terraformを実行し、monitor作成まで行います(AWSの時同様にapply時にapproveを求められるのでyesを入力
    bash
    # terraform provider取り込み
    $ terraform init
    # plan実行
    $ terraform plan -var-file=secret.tfvars
    # apply実行
    $ terraform apply -var-file=secret.tfvars

以上でmonitor設定の追加が行われました。
今回はsystem.cpu.user(インスタンスのCPU usertime)の5分平均が50%以上であればwarnnig、60%以上であればcriticalとし、事前に設定したslackチャンネルに通知するようにしています。
これらは、variable.tf にてデフォルト値が設定指定あるので、変更したい場合は適宜変更してみてください。
※例えば下記のように

datadog_monitor_slack_channel = "slack-system-alert"
datadog_monitor_cpu_usertime_thresholds_warning = "60"
datadog_monitor_cpu_usertime_thresholds_critical = "70"

アラートテストを行う

さて、監視がうまくいってるかどうか確認、ということで作成したインスタンスにログインし、インスタンスに負荷を適当にかけてみます
※デフォルトのSecurity Groupでは、サンプルということでどこからでもSSHが可能なようにしているため、batsion_ingress_cidr_blocksの値を適宜変更すると安全かもしれません

# ログイン
$ ssh -i bastion.pem ec2-user@[インスタンス EIP]
# 負荷をかける
$ yes >> /dev/null &

上記を実施後、しばらくすると下記のようにアラートが飛んできます!
スクリーンショット 2017-12-12 1.57.16.png

ということで、yesコマンドを停止し、復旧通知を確認して終了です。おつかれさまでした。
スクリーンショット 2017-12-12 2.11.52.png

なお、作成したインスタンスはterraform destroy -var-file=secret.tfvarsを実行することで削除可能です。

終わりに

簡単でしたが、Monitoring as Code入門でした。
DataDogには、今回のような簡単な監視だけでなく、他にも様々なメトリクスアラートやもっと高度な機械学習型のアラートが存在するので、よりうまい具合に活用しつつ、Monitoring as Codeを推し進めていきたいな、と思います。

続きを読む

postgresql – unable to connect to AWS VPC RDS instance (mysql or postgres)

postgresql – unable to connect to AWS VPC RDS instance (mysql or postgres) – Stack Overflow. Additional information for people who might run into similar issues trying to connect to RDS or R… 続きを表示. Additional information for people who might run into similar issues trying to connect to RDS or … 続きを読む

AnsibleでAWS環境(RDS)を自動構築する

はじめに

AWSの無料枠範囲で遊んでいます。

無料枠を超えないようにするため、作っては削除。作っては削除。をコンソールでやるのがめんどくさくなりました。

そのため、AnsibleでAWSの環境構築を自動構築できるようにしよう!ということで、
Ansible Playbookのサンプルを作成してます。

この記事で作成したplaybookはgithubで公開しています。

https://github.com/rednes/ansible-aws-sample
(AWS02フォルダ)

AWSの何を作るか

以下の内容をAnsibleで自動構築できるようにします。

  • VPCの作成
  • Internet Gatewayの作成
  • サブネットの作成
  • ルートテーブルの作成
  • セキュリティグループの作成
  • EC2インスタンスの作成
  • サブネットグループの作成
  • RDSの作成
  • EC2インスタンスにWordPress環境の構築

前提

  • ansible, botoをインストールすること
  • AWSのサーバー構築に使用するIAMユーザが作成されていること
  • AWSマネジメントコンソールでキーペア登録していること

AWS構成図

今回Ansibleで構築するAWSの構成図はこんな感じです。

AWS構成図

ディレクトリ構成

├── ansible.cfg
├── group_vars
│   └── all.yml
├── host_vars
│   └── localhost.yml
├── hosts
│   ├── ec2.ini
│   └── ec2.py
├── roles
│   ├── ec2
│   │   └── tasks
│   │       ├── ec2.yml
│   │       ├── main.yml
│   │       ├── security_group.yml
│   │       └── vpc.yml
│   ├── rds
│   │   └── tasks
│   │       ├── main.yml
│   │       └── rds.yml
│   ├── wordpress
│   │   ├── defaults
│   │   │   └── main.yml
│   │   └── tasks
│   │       └── main.yml
│   └── yum
│       ├── defaults
│       │   └── main.yml
│       └── tasks
│           └── main.yml
└── site.yml

Playbookの解説

AnsibleでAWS環境(RDS以外)を構築する内容については、過去の記事を参考にしてください。
今回はRDSの構築についてだけ説明します。

RDSの環境はrdsのroleで作成しています。

roles/rds/tasks/main.yml
---
- include_tasks: rds.yml

main.ymlでは単純にrds.ymlをインクルードしているだけです。
rds.ymlでRDSインスタンスを作成しています。

サブネットとセキュリティグループはec2のroleであわせて作成しています。

1. 異なるAZでサブネットを二つ作成

ec2_vpc_subnetモジュールでサブネットを構築します。
サブネットではVPC, Availability Zone, CIDRを指定します。

RDSでは単独のAZでしか使用しない場合でも、複数のAZにまたがったサブネットグループを作成する必要があるため、
今回は使用していませんがわざわざ使用しないAZにサブネットを作成しています。

サブネットグループ作成時に使用するサブネットを識別するため、タグに「route: private」を設定しています。

roles/ec2/tasks/vpc.ymlの一部
- name: subnet作成
  ec2_vpc_subnet:
    region: "{{ aws.common.region }}"
    state: present
    vpc_id: "{{ vpc_net.vpc.id }}"
    az: "{{ aws.common.region }}{{ item.value.zone }}"
    cidr: "{{ item.value.cidr }}"
    map_public: "{{ item.value.map_public|default(True) }}"
    tags: "{{ item.value.tags }}"
  with_dict: "{{ aws.vpc.subnet }}"
  register: vpc_subnet
host_vars/localhost.ymlの一部
aws:
  common:
    region: ap-northeast-1
  vpc:
    subnet:
      subnet1:
        tags:
          Name: public-a
          route: public
        cidr: 10.0.1.0/24
        zone: a
      subnet2:
        tags:
          Name: private-a
          route: private
        cidr: 10.0.2.0/24
        map_public: False
        zone: a
      subnet3:
        tags:
          Name: private-c
          route: private
        cidr: 10.0.3.0/24
        map_public: False
        zone: c

2. セキュリティグループを作成

ec2_groupモジュールでセキュリティグループを構築します。
セキュリティグループでは主にVPCとインバウンドルールを指定します。

AnsibleDBという名称のセキュリティグループを作成して、
EC2からのみ接続できるように設定しています。

roles/ec2/tasks/security_group.ymlの一部
- name: security group作成
  ec2_group:
    name: "{{ item.value.name }}"
    description: "{{ item.value.description }}"
    tags:
      Name: "{{ item.value.name }}"
      vpc_id: "{{ vpc_net_fact.vpcs[0].id }}"
    region: "{{ aws.common.region }}"
    purge_rules: "{{ item.value.purge_rules|default(False) }}"
    rules: "{{ item.value.rules }}"
  with_dict: "{{ aws.vpc.security_group }}"
  register: security_group
host_vars/localhost.ymlの一部
aws:
  common:
    region: ap-northeast-1
  vpc:
    security_group:
      security_group1:
        name: AnsibleWeb
        description: EC2 group
        rules:
          - proto: tcp
            ports:
              - 22
            cidr_ip: 0.0.0.0/0
          - proto: tcp
            ports:
              - 80
              - 443
            cidr_ip: 0.0.0.0/0
      security_group2:
        name: AnsibleDB
        description: EC2 group
        rules:
          - proto: tcp
            ports:
              - 3306
            cidr_ip: 10.0.1.0/24

3. サブネットグループを作成

rds_subnet_groupモジュールでサブネットグループを構築します。
サブネットグループでは主にsubnet idを指定します。

ec2_vpc_subnet_factsモジュールでタグが「route: private」である全てのサブネットを取得して、
一つのサブネットグループを作成しています。

roles/rds/tasks/rds.ymlの一部
- name: subnet取得
  ec2_vpc_subnet_facts:
    region: "{{ aws.common.region }}"
    filters:
      "tag:route": private
  register: ec2_subnet_facts
  check_mode: no

- name: rds-subnet-group作成
  rds_subnet_group:
    name: "{{ aws.vpc.rds.subnet_group.name }}"
    region: "{{ aws.common.region }}"
    state: present
    description: "{{ aws.vpc.rds.subnet_group.description }}"
    subnets: "{{ ec2_subnet_facts.subnets | map(attribute='id') | list }}"
  register: rds_subnet_group
host_vars/localhost.ymlの一部
aws:
  common:
    region: ap-northeast-1
  vpc:
    rds:
      subnet_group:
        name: wp-dbsubnet
        description: WordPress DB Subnet

4. RDSを作成

rdsモジュールでRDSインスタンスを構築します。
セキュリティグループはec2_group_factsモジュールを利用して、
名称からIDを引っ張ってきて定義しています。

roles/rds/tasks/rds.ymlの一部
- name: RDS作成
  rds:
    command: create
    instance_name: "{{ aws.vpc.rds.db_name }}"
    username: "{{ aws.vpc.rds.db_user }}"
    password: "{{ aws.vpc.rds.db_password }}"
    db_name: wordpress
    region: "{{ aws.common.region }}"
    subnet: "{{ aws.vpc.rds.subnet_group.name }}"
    vpc_security_groups: "{{ ec2_group_facts.security_groups[0].group_id }}"
    db_engine: "{{ aws.vpc.rds.db_engine }}"
    engine_version: "{{ aws.vpc.rds.engine_version }}"
    license_model: "{{ aws.vpc.rds.license_model }}"
    instance_type: "{{ aws.vpc.rds.instance }}"
    size: "{{ aws.vpc.rds.size }}"
    tags:
      Name: "{{ aws.vpc.rds.db_name }}"
  register: rds
host_vars/localhost.ymlの一部
aws:
  common:
    region: ap-northeast-1
  vpc:
    rds:
      db_name: wordpressdb
      db_user: root
      db_password: password
      db_engine: MySQL
      engine_version: 5.6.37
      license_model: general-public-license
      instance: db.t2.micro
      size: 20

注意点

RDSのエンドポイントがRDSを作成するまでわからないため、まず最初にRDSインスタンスまで作成した後に
RDSのエンドポイントをgroup_vars/all.ymlに追記する必要があります。

group_vars/all.ymlの一部
---
my_vars:
  rds:
    endpoint: XXXX # RDSで作成したDBのエンドポイントを入力

RDS作成が完了したら以下の様にawscli等を使用してエンドポイントを取得し、
上述のall.ymlにエンドポイントを記載するとEC2からRDSのmysqlに接続してWordPress環境を構築できます。

$ aws rds describe-db-instances --query="DBInstances[].Endpoint"

続きを読む