カテゴリー別アーカイブ: AWS

ClassicLinkを使用してVPCとEC2-Classic間の相互通信を行う

Pocket

こんにちは。技術開発部部長の川住です。

弊社DSP「Bypass」はシステムをAWSに移行してから5年以上が経過しました。近年ではEC2インスタンスをVPC (Virtual Private Cloud) 内に作成し運用していますが、AWSへの移行当初にVPC外(EC2-Classic)に作成したサーバがいくつか現在も稼働しており、「VPC内で稼働しているインスタンス」と、「VPC外で稼働しているインスタンス」が混在している環境となっています。今回はこのような環境で使用すると便利な「ClassicLink」という機能を紹介します。

ClassicLinkを使うとできること

  • VPC外のインスタンスと特定のVPCの相互接続

ClassicLinkを使用すると、VPC内(外)のサーバがあたかも同一のLAN上に存在するかのように、VPC外(内)のインスタンスからアクセスできるようになります。これによって、VPC外インスタンスのVPC内への移行を段階的に行えますし、移行の際のダウンタイムを減らせます。

ClassicLinkではできないこと

  • 異なるVPC間の相互接続

ClassicLinkでは、「VPC外 (EC2-Classic) 」のインスタンスと特定のVPCとの相互接続を行う機能であり、VPC間の相互接続には使用できません。このような場合には、「VPC peering」機能を使用して相互接続の設定を行う必要があります。

  • VPC外のインスタンスと、複数のVPCとの相互接続

ClassicLinkはサーバごとに相互接続を行うVPCを設定できますが、ClassicLinkで接続できるVPCは1インスタンスに対して1つだけです。複数のVPCへのアクセスを実現にするには「VPC peering」機能と、VPCのルーティング設定を組み合わせる必要があります。

ClassicLinkの使い方

ClassicLinkの設定はAWSのコンソール画面上、またはaws-cliで行えます。設定したいインスタンスを選択し、接続したいVPC名と、VPC外からの通信の際にVPC側で適用するセキュリティグループを選択します。VPC内のセキュリティグループからはVPC外のセキュリティグループは参照できないので、EC2-ClassicのIP帯などを指定したインバウンドルールを設定したセキュリティグループを作成しておく必要があります。

ClassicLink使用時の注意点

ClassicLinkは起動中のインスタンス対してのみ設定でき、停止すると設定が失われてしまうので注意が必要です。

まとめ

使用できる場面は少ないですが、ClassicLinkを使用することで、VPC内外の相互接続を簡単に行えて、それによってVPC内への移行作業の手間やダウンタイムの削減が可能です。

今回は以上となります。

SQS + Lambdaでs2sの基盤を作った話

Pocket

こんにちは。技術開発部・配信/インフラチームの二階堂です。

弊社のプロダクトでは連携している効果測定ツールに対して、S2Sで通知を行う場合があります。 この通知処理を以前まではEC2上に配置したデーモンプログラムで行っていたのですが、処理の共通化・高速化・インフラ費用削減などの目的でSQS+Lambdaに移行しました。 この経験を踏まえて移行時のポイントを紹介したいと思います。

移行前のフローと問題点

  1. 通知先のURLの入ったログを通知用インスタンス(複数ある内のどれか一つ)に書き出す
  2. EC2上に配置したデーモンプログラムがログを読み込み通知を行う
  3. 同じくデーモンプログラムが通知結果のログを書き出す

問題点

  1. 常時起動のインスタンスが高価
  2. 時間帯によって通知量が変化するため通知量が多い時に時々遅延が発生する
  3. 通知漏れが発生した際にどの通知用インスタンスが原因か調査するコストが高い

SQS + Lambda のフロー

  1. 通知先のURLの入ったログをSQSに送信
  2. 定期実行されるLambda(図中a)がSQSに送られたメッセージ数(NumberOfMessageSent)に比例した数の通知用Lambda(図中b)をキック
  3. 通知用LambdaがSQSからメッセージを取得→通知→結果をS3に保存を5分間繰り返す

特徴・改善点

  • 常時起動EC2よりLambdaの方が圧倒的に安価 (問題点1)
  • 全てのログを一度SQSに送る事でそれ以降のフローを共通化し調査コストを下げた (問題点3)
  • Lambdaを2段構成にする事で通知量の変化に柔軟に対応できるようになった (問題点2)
  • 通知用Lambdaはログのパースと通知しかしていないので他の通知にも容易に対応できる

効果

  • インフラコストが約10分の1に減った
  • リリース以前には定期的に発生していた調査や再通知などの対応もほぼ無くなり安定して動作している

移行した感想

Lambdaの料金は実行時間*メモリ使用量なのでその辺を意識したコードになっていないと高い効果が得られません。 今回の処理内容はただの通知なのでメモリはあまり使わないので速度を上げる工夫として通知部分を並列化しました。 最初は並列化していなかったのですがその時は移行前とあまり費用が変わらなかったことを考えるとコスト意識の重要性が判りやすいのではないかと思います。

今回の基盤開発は並列化対応も含めて何かと初めての経験が多い開発だったので効果にしても経験にしてもとても有意義なものだったと思います。

今回は以上となります。

Lambda@Edgeを利用した画像のリサイズを試してみた

Pocket

こんにちは。技術開発部部長の川住です。

弊社プロダクトにて、「オリジナル画像を適切な大きさに縮小してから読み込む仕組み」を作る必要が生じたので、遅ればせながらLambda@Edgeを使ってみたので、利用時のポイントを紹介したいと思います。

Lambda@Edgeとは?

Lambda@Edgeは、Amazon CloudFrontのエッジサーバで、AWS Lambdaの関数を実行できる仕組みです。リクエスト-レスポンス間の以下4つのタイミングに対してLambda関数を設定できます。

  • CloudFrontのエッジサーバがユーザからのリクエストを受け取る時 (Viewer Request)
  • (エッジサーバにキャッシュがなく)、オリジンサーバへリクエストを転送する前 (Origin Request)
  • オリジンサーバからレスポンスを受信した後 (Origin Response)
  • エッジサーバからユーザへレスポンスを転送する前 (Viewer Response)

Lambda関数に機能を実装することで、例えば以下のような仕組みを実現できます。

  • ユーザ認証やリダイレクトを行う
  • HTTPヘッダを操作する (追加, 削除, 変更)
  • コンテンツを必要に応じて加工してレスポンスする

Lambda@Edgeを使用した画像のリサイズ

Lambda@Edgeを利用した画像のリサイズの仕組みの構築方法に関しては、こちら にて詳しく紹介されていますので、実装の詳細については割愛します。大雑把に言いますと、2つのLambda関数を実装しそれらをCloudFrontに設定することで実現しています。

  • Viewer Requestとして、リサイズ後の幅や高さなどのパラメータを受け取り、パスに組み込む関数をCloudFrontに登録する
    • エッジにリサイズ後の画像のキャッシュがあれば、オリジンへリクエストは転送されず、キャッシュデータがレスポンスされる
  • Origin Responseとして、必要に応じてオリジンから受け取った画像をリサイズし、レスポンスとして返す関数をCloudFrontに登録する
    • オリジンにリサイズ後の画像がすでに保管されている場合は、保管されている画像をレスポンスする
    • オリジンにリサイズ後の画像が保管されていない場合は、画像を取得してリサイズした後、オリジンにデータを格納し、画像をレスポンスする

Lambda@Edge利用時のポイント

Lambda@EdgeはAWS Lambdaと同様の制約を受けるほかに、Lambda@Edge特有の制約や注意点があったので紹介します。

スペック面での制約

AWS Lambdaでは実行時のメモリ量やタイムアウト時間を設定できますが、Lambda@Edgeでの実行時にはこれらの設定上限が通常よりも厳しくなります。

  • メモリ量の上限: 128MB
  • タイムアウトの上限: 5秒

その他制約に関してはこちらが詳しいです。また、AWS Lambdaでは複数の言語をサポートしていますが、Lambda@Edgeで使用できるのは「 node.js 6.10, node.js 8.10 」のみとなっています。

Lambda関数はus-east-1 (バージニア北部) に登録する必要がある

CloudFrontに設定できるLambda@Edge関数はバージニア北部に登録されているものだけです。

バージョンつきのarnを紐つける必要がある

CloudFrontには $LATEST$ALIAS のarnを設定できないので、バージョンを発行したLambda関数をCloudFrontに設定する必要があります。

実行時のCloudWatch Logはエッジサーバのリージョンに排出される

Lambda関数の登録自体はus-east-1 (バージニア北部) ですが、実行はCloudFrontのエッジサーバであるため、実行時のCloudWatch Logの排出先はエッジサーバのロケーションに依存します。 (日本からアクセスした場合には、東京、ソウル、シンガポールリージョンあたりにログが排出されていました。大半は東京。)

使ってみた感想

  • 今回の用途以外にも、A/Bテストなどにも利用できそう
  • 大量アクセスのある場面には注意が必要
    • リクエスト数とLambdaのコード実行時間に比例して利用料金が発生。キャッシュヒット率を高める工夫が必要になってきそう。

今回は以上となります。

AWS ストレージサービス「S3」

Pocket

今週もまた台風が近づいておりますね。 初めまして、今年新卒で入社した技術開発部の程です。 週末は同僚と登山に行く予定なのに台風直撃の知らせを聞いて下がり気分です。 自然ばかりはITの技術だけではどうにもならないので仕方ないですね。

さて、私、現在は自社DSP、Bypassの開発に携わっているのですが 弊社広告配信システムはAWSを利用して構築されております。 今回は、AWSの中でも特に 弊社広告配信システムにおいても実際に活用している S3というストレージサービスについて 簡単に概要や特徴などについてまとめたいと思います。

S3

S3では、バケットと呼ばれる仮想的なオブジェクト置き場に 様々なファイルやメディアコンテンツ(=オブジェクト)を格納し AWSクラウドサーバ上に保存することができます。 保存したオブジェクトはいつでもどこからでも参照したり 新規オブジェクトを追加することができます。

S3の特徴

  • 容量無制限
  • スケーラブル
    容量は無制限となっており、大量のデータを扱う場合にも、上限を心配することなく使用できます。
  • 冗長化されている
    保存したオブジェクトは異なるアベイラビリティゾーン(AWSによる場所の区分け) にある複数のサーバーに複製保存されるので 障害発生時にデータロストの危険性が低く安心です。 また、自前で冗長化する手間が省けるという利点もあります。
  • 高い堅牢性
    99.999999999%(イレブンナイン)の堅牢性(aws公式サイトより)

S3の操作

S3上でオブジェクトは次のような形式で表現され、管理されます。

調べたところ、S3内部ではフォルダという概念はなく、S3上では単純にKey-Value方式でオブジェクトが格納されているのだそうです。 とはいえ、実際に使ってる時はあんまり意識する必要はなく、通常のファイルと同じような感覚で操作できるのがいいですね。

AWSではS3を操作するための方法をいくつか用意しており、目的に応じて使い分けも可能です。 具体的には以下のようなものが挙げられます。

  • ブラウザ上のコンソールから操作
  • コマンドラインから操作
  • AWS提供のSDKより各種アプリケーションから操作
  • 3rd party製のツールで操作

コマンドラインから操作できるのは便利ですね。 以下のように、基本的なバケットやファイルの作成、削除、コピーなどの操作は一通りCLIで実行可能です。

S3操作用のコマンドとしては上記のものの他に、aws s3apiというものがあり、前者はAPIとコマンドが1:1で対応する形の低レベルなコマンド群であるのに対し、後者は複数のリクエストにまたがる様な処理などが実装された高レベルなコマンド群である、という違いがあります。

もちろん、ローカル->S3だけではなく, S3->ローカルやS3->S3間のファイル移動を行うこともできます。

コンソールから操作する場合は以下のような画面上で、バケット作成やファイルのアップロードを行います。

ログインしたら最初に表示されるバケット管理画面のイメージです。

バケット新規作成の後は、そのバケット内に格納されるファイルを管理する画面に遷移します。 この画面上では、バケットへのファイルのアップロードや、フォルダの作成などができます。

適当に1個ファイルをアップロードしてみるとこのようにファイルが追加されます。

コンソール上で操作する場合は、クリック操作だけで非常に簡単に、バケットの作成からファイルのアップロードまで実行することができました。

S3のユースケース

AWS公式サイトやWebサイト上の記事を調べると、次の3つが主なユースケースとしてよく取り上げられています。

  • データのバックアップ
    前述の通り、高い堅牢性を備えていることから、消失すると困る様々なデータを保管する。
  • コンテンツ配信
    S3上に保存したコンテンツを配信する。
  • ログデータなどの保存先
    EC2で収集されたログの退避先、ビッグデータ分析で使用する生データの保存先として利用する。

弊社広告配信システムにおいては特に動画広告の場合に、S3上に動画素材をアップロードした上で AWS CloudFrontとS3を連携させることで、容量の大きい動画系広告でも高速かつ安定した広告配信を実現しています。

バージョン管理

S3で保存されるオブジェクトは、バージョンで管理することも可能です。例えば、誤削除などのミス発生時などにこの機能が適用されていれば、すぐに以前のバージョンに復旧することができます。 この機能を有効化すると、オブジェクトを更新した時などに 前の世代のオブジェクトが自動的に保管される様になります。 何世代分保存するかを指定することもできます。

Notification(通知)機能

バケットにファイルが追加されたことをイベントとして検知したい時はこの機能が有用です。 この機能ではバケット単位で、以下のイベントが発生した際に Amazon SNS, SQS, LambdaといったAWSサービスに通知を飛ばすことができます。

  • 新しいオブジェクトの作成イベント(Put, Post, Copy, CompleteMultiPartUpload)
  • オブジェクト削除イベント(Delete, DeleteMarkerCreated)
  • 低冗長化ストレージのオブジェクト消失イベント(RRSObjectLost)

その他の機能

  • クロスリージョンレプリケーション
    別リージョンへの複製保存を行う。
  • S3へのアクセスログ
    S3上でバケットに対してどんな操作を行ったかの記録ログを出力させる。
  • Tag管理
    バケットに対してタグを指定する。
  • メタデータ
    オブジェクトに対してメタデータを設定する。

私自身、入社して初めてクラウドサービスを触ったのですが 実際に使ってみるとその操作の簡単さと便利さに驚きました。 個人利用も可能なので、個人の自主アプリ制作などにも活用できそうですね。

それでは以上となります。

AWS Glue + Athena構成を試す

Pocket

こんにちは。技術開発部の赤井橋です。

弊社では現在adstirログ基盤のリプレイスを計画しており、その一貫としてAWS Glueでのデータ変換(json → parquet)、及び変換データのAthenaでの検索を試しました。

Glueとは

https://aws.amazon.com/jp/glue/

2017-08-15から利用出来るようになった抽出、変換、ロード (ETL) を行う完全マネージド型のAWSサービスです。 使い所としてはファイルのカラムナフォーマットへの変換、及びパーティションが有効なディレクトリへの配置、データカタログ(テーブル定義のメタデータ)の更新・・など、 ビッグデータを使いやすく成型する場面が多いかと思います。

Glueが提供する機能

大きく分けて2つ存在します。(2018-07-31時点)

1. データカタログの更新

クローラという機能を用いてデータカタログの自動更新を行うことが出来ます。 クローラは指定されたデータソース(特定のS3ディレクトリなど)内をスキャンし、該当ディレクトリにあるファイルフォーマットに合わせたテーブル定義(パーティショニング含む)を自動で行ってくれます。 定義されたデータカタログはAthena、EMR、Redshift Spectrumでも使用(2018-07-31時点)でき、実行スケジュールの登録も可能です。

2. ETL

ジョブという機能を用いてデータ抽出、変換を行うことが出来ます。 ジョブ追加時のセットアップガイダンスに従って進めていくと最終的にPythonのスクリプトが自動生成されます。シンプルな処理であればスクリプトの修正は不要ですが、手の込んだ処理の場合修正する必要があります。 ジョブを定期実行するトリガーという機能もあります。

使用にあたり

上記2つの機能はどちらかだけ使用してもよく、どちらとも使用したい場合も使用順序に制約はありません。 そのため、クローラでテーブル定義を更新し、更新されたテーブル定義を元にジョブでのデータ変換を行う、という流れ以外にもジョブで変換されたファイルに対してクローラでテーブル定義を更新する、という用途でも使用出来ます。

ジョブのスクリプト

セットアップガイダンスを終えるとPythonスクリプトが生成されますが、例えば特定の引数を受け取って処理を行いたい場合は別途実装が必要です。 スクリプトではGlueで独自定義されたDynamicFrameというデータ構造を操作することで独自の変換処理を行えます。

例)AWS CLIからyear引数を指定してGlueを実行し、受け取ったyear引数をS3のデータソースのパスとして設定したい場合

AWS CLI

スクリプト

変換対象のフォーマットが複雑な場合も別途実装が必要です。

例)tsvフォーマットの1列にjson文字列があり、json文字列の部分をstructの配列として変換したい場合

元データ(tsv)

スクリプト

GlueとAthena、使ってみて不自由だった点

Glueでデータソースとして読み込めるのは文字コードがUTF-8のみ

UTF-8以外の文字列が変換対象のデータソースに含まれているとGlueでの変換処理が失敗します。

[AWS Black Belt Onine Seminar] AWS Glue

根本的な解決ではないですが、AWS Lambdaを用い対象となるログファイルをUTF-8に変換する、という前処理を行うことで対処しました。

DPUを上げても劇的な処理速度向上は見込めない

GlueではDPU(データ処理ユニット)の数を指定出来るのですが、2倍にすれば2倍処理が早くなる、という挙動ではありませんでした。 7.7G分のファイルでそれぞれ検証したところ、

という結果でした。

Athenaでのstruct型の使い勝手が悪い

struct型のスキーマ定義に値を追加すると、スキーマと同様の構造で格納されているパーティションでは問題なく検索出来ますが、 値が存在しない(スキーマ変更前の構造の)ファイルが格納されているパーティションでは「HIVE_CANNOT_OPEN_SPLIT」エラーが発生し検索できませんでした。

こちら根本的な解決法はないようで、暫定対応としてstruct型をstring型に変更し検索の際にstring文字列をjsonと扱うように対処しました。

まとめ

検証の結果、コストや処理時間なども考慮するとまだGlue + Athenaを導入する判断に至っていません。ただ、比較的新しく提供されたサービスのため今後も機能が追加され使い勝手も改善されていくはずです。 ビッグデータがますます全盛となる時代、このようなサービスの重要性は増していくのではないでしょうか。

今回は以上です。

APIを利用したCloudWatchの設定

Pocket

こんにちは。配信/インフラチームの佐々木です。

弊社ではAWS上にシステムを構築していますが、前回お話しした通り監視ツールはCloudWatchを利用するケースが増えております。 今回はAPIを利用してCloudWatchを設定する手順をご説明します。

Alarmの設定

CloudWatchの用途としてインスタンスの監視に使うケースは多いと思います。そこでインスタンスのAlarmを設定するスクリプトを作ってみました。aws-cliとbotoどちらかを利用するのですが、今回はaws-cliで実装しています。

このように引数にNameタグを指定して利用します。

インスタンスIDで指定する方がシンプルな実装になるのですが、インスタンスIDはコピーペーストする必要がありますし、Nameタグの方がワイルドカード指定も出来て便利です。またアラーム名にもNameタグが入っていた方わかりやすくて良いと思います。ただNameタグが一意である必要がありますのでその点は注意が必要です。

Dashboardの設定

CloudWatchのDashboardもAPIを利用して設定することが可能です。その手順を記載します。

APIの仕様は以下になるのですが、元になる設定が無いと難しいと思いますので、適当なDashboardから定義をコピーします。ここでは2台のインスタンスのCPU使用率とNetworkInのメトリックを登録しています。

https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_PutDashboard.html

[アクション]の[ダッシュボードの編集]を選択すると、Jsonの定義を取得できます。ここから直接変更することも可能です。

コピーしたJsonを元に編集します。インスタンスを1台増やしてサイズも倍にしてみました。

作成したJsonファイルを以下のコマンドで適用します。

完成しました。

またこちらのページに、複数インスタンスを自動で登録するスクリプトが載っております。台数や取得するパラメータが多い場合などにはかなり有用かと思います。

https://aws.amazon.com/jp/blogs/news/new-api-cloudformation-support-for-amazon-cloudwatch-dashboards/

今回は以上になります。

Amazon Elasticsearch ServiceでKibanaを利用する

Pocket

みなさんこんにちは。配信/インフラチームの佐々木と申します。adstirの配信サーバの開発とインフラを担当しております。

今回はAmazon Elasticsearch ServiceとKibanaを利用したデータの可視化について書きたいと思います。

ElasticsearchとKibanaについて

両方とも有名なミドルウェアなので詳細な説明は省きますが、端的に言うとElasticsearchは全文検索エンジンでKibanaがそれを可視化するためのWEB-GUI(中身はNode.js)になります。

ポイントとしてはElasticsearchもKibanaもオープンソースで公開されているのですが、両方ともAWSのマネージドサービスとしても提供されているため、構築と運用の負担が非常に軽いという点があります。(もちろんEC2を利用する事もできますし、AWS以外の環境でも利用は可能です。) 開発元が同一なため親和性が高く、今後はバージョンも統一されていくようです(現在は5.x) Kibanaは以前のバージョンではダッシュボードは黒をベースとしたUIでしたが、このバージョンは非常にカラフルなデザインになっております。

ちなみに余談ですが正しくは”ElasticSearch”ではなく”Elasticsearch”となります。ですがちょっと長いのでこのブログではESと略させていただきます。

データのフロー

ESはWEB-APIとして動作するのですが、Fluentdでプラグインが用意されているためそれを利用するケースが多いです。 直接POSTしても良いのですが、Fluentdを利用した方が簡単かつフレキシブルに使えます。流れとしては

Fluentd -> ES -> Kibana

となりますが、データをS3に保存する場合は以下のような流れが良さそうです。

Fluentd -> S3 -> Lambda -> ES -> Kibana

今回は前者の手順を記載いたします。

構築手順

1. AmazonESとKibanaのセットアップ

セットアップ自体は非常に簡単で、ものの数分で終わります。(作成の待ち時間がそれなりにありますが)AWSさまさまと言ったところです。

ESのダッシュボードでCreate a new domainをクリックします。 スクリーンショット 2017-06-15 18.36.03

Domain名とバージョンを指定しNextをクリックします。 スクリーンショット 2017-06-15 18.36.59

インスタンス数やスペックなどを指定しNextをクリックします。 スクリーンショット 2017-06-15 18.37.52

最後にアクセスポリシーを設定し、Confirm and createをクリックします。 スクリーンショット 2017-06-15 18.39.40

10分程度待てば作成が完了します。同時にKibanaも使える状態になっています。 スクリーンショット 2017-06-15 18.40.28

2. Fluentd設定

下準備としてはFluentdとfluent-plugin-aws-elasticsearch-serviceをインストールしている必要があります。送信先にESのURLを指定します。

3. ES設定

簡単な使い方をするのであれば設定は特に必要ありません。データがインサートされればそのまま使えるようになります。

4.Kibana設定

まずIndexの設定をする必要があります。ManagementでIndex Patternsをクリックします。 スクリーンショット 2017-06-20 12.40.21

Add Newをクリックします。 スクリーンショット 2017-06-20 12.41.07

作成したインデックスのパターンを入力し、Createをクリックします。 スクリーンショット 2017-06-21 11.58.45

登録したインデックスのデータは、Discoverから確認できます。この例ではscore_Xというランダム数値のデータを使用しています。 スクリーンショット 2017-06-21 11.56.59

次にインデックスからグラフを作成します。今回は折れ線グラフを作成しますので、VisualizeでLine chartを選択します。 スクリーンショット-2017-06-22-12.01.21

対象のインデックスを選択します。 スクリーンショット 2017-06-21 12.01.46

Y-Axisに対象のデータを登録し、X-AxisでDate Histogramを選択すれば時系列の折れ線グラフが出来ます。設定したらSaveをクリックします。 スクリーンショット 2017-06-21 12.23.32

あとはDashboardで作成したグラフを貼り付けます。KibanaはDashboardが自由にカスタマイズ出来、例えばWEBサーバのレイテンシを確認しながら生のログを見るといった使い方が出来ます。 スクリーンショット 2017-06-21 12.44.18

以上が構築手順になります。

最後に

弊社ではアドテクエンジニアを募集しております。広告技術に興味がある方・経験がある方のご応募をお待ちしております。また広告以外の部署やエンジニア以外の職種でも募集しておりますので、興味がある方はぜひご応募くだされば幸いです。

弊社コーポレートサイト
http://united.jp/recruit/information/

Wantedly
https://www.wantedly.com/companies/united/projects/

AWS利用におけるIAMの設計

Pocket

こんにちは。配信/インフラチームの石田です。
現在DACから出向でユナイテッドでお世話になっております。
DACでも社内/サービス側両方のインフラ担当を担っております。

弊社では、AWSをDSP/SSPのサービスの基盤として利用しております。
また、AWSの利用者も、インフラチームや開発者、データ解析チームまで様々です。
「皆が同じルートアカンウトでログインし、全操作可能な状態」はセキュリティ的に問題があると考えております。

今回は、AWSのリソースアクセスコントロールを行い、セキュリティを向上する目的で導入したIAMの設計を紹介します。ルートアカウントでのAWSログインの廃止、CloudTrailでの操作ログ取得を実施するまでの過程を紹介します。

■IAMとは

IAMとは、Identity and Access Managementのことです。
ユーザーに対してAWSへのアクセスを安全に制御するための仕組みで、無料で導入できるのが魅力です。簡単に言うと、「AWSアカウントの中で、だれが何をできるかをコントロールするためのサービス」です。

■認証情報の種類

AWSにおける認証情報の種類としてはと下記の4つのクレデンシャルがあります。

  • AWSアカウントのパスワード
  • AWSアカウントのAPIキー
  • IAMユーザのパスワード
  • IAMユーザのAPIキー

■前提方針

前提条件としては、下記2つです。当然ですが、AWSルートカウントを利用しない方針でなければCloudTrailでの操作ログとして成立しません。

  • AWSルートアカウントはパスワードを変更し、利用しない。
    登録情報等の管理と請求関連操作にだけ使う。
  • AWSルートアカウントのAPIキーは利用しない。

■設計

今回弊社では、「管理者・開発者・運用者の役割を設け、開発者の自由度を考慮した設計案」を採用しました。基本的には、個人にポリシーを付与する形ではなく、グループにポリシーを付与する形式をとっております。また、ポリシーを個別に作成することも可能ですが、AWS側であらかじめ準備しているポリシーを利用します。

◉グループ
弊社では、AWS利用ユーザを3分類し、開発者の自由度を高く設計しております。

  • 管理者(Admin)
    →全サービス操作可能

  • 開発者(Developers)
    →IAM以外全サービスの操作可能

  • 運用者(Operators)
    →全サービスの参照のみ可能

◉ポリシー
今回は下記5つのポリシーを上記グループに付与する形で権限管理を行っております。

  • ”Administrator Access”
    →AWSアカウントに代わる強力な権限。全操作可能(既存)

  • ”Power User Access”
    →上記、Admin用からIAM操作権が省かれたポリシー(既存)

  • ”Read Only Access”
    →参照用ユーザ向けポリシー(既存)

  • ”ViewBilling”
    →請求情報参照用ポリシー(独自)

  • ”ChangePassword”
    →初回ログインPW変更可能ポリシー(独自)

◉グループとポリシーの関係
最終的なグループへの付与ポリシーは下記の通りです。

  • 管理者(Admin)
    ”Administrator Access”, ”ChangePassword”

  • 開発者(Developers)
    ”Power User Access”,”ChangePassword”

  • 運用者(Operators)
    ”Read Only Access”,”ChangePassword”,”ViewBilling”

■設定手順

–ユーザ作成編–

1)ルートアカウントでログインする。

2)IAMに移動し、ユーザを作成する。ユーザ名を入力し、「ユーザごとにアクセスキーを生成」にチェックを入れる。
iam-05

3)「認証情報をダウンロード」を選択し、アクセスキー、シークレットキーを保管する。

4)作成したユーザを選択し、認証情報タブを開き、「パスワードの管理」を選択する。
iam-06

5)初回ログイン時に必要になるユーザのパスワードを生成する。「自動作成パスワードの割り当て」を選択する。また、「次回のサインインで新しいパスワードを作成するようにユーザに求める」にチェックを入れる。
iam-07

6)「認証情報ダウンロード」から発行したパスワードを保管する。

–ポリシー作成編–

1)ルートアカウントでログインする。

2)アカウント>請求情報に対するIAMユーザアクセスの編集を選択する。
iam-01

3)請求情報に対するIAMユーザアクセスの「IAMアクセスのアクティブ化」にチェックする。
iam-02

4)IAMに移動し、ViewBillingポリシーの作成を行う。

5)ポリシーの作成>Policy Generatorを選択する。

6)アクセス許可の編集にて効果「許可」、AWSサービス「AWS Billing」、アクション「ViewAccount」「ViewBilling」にチェックを入れ, ステートメントを追加を選択する。
iam-03

7)ポリシードキュメントが作成されるので、「ポリシーの検証」を実行後、作成する。今回のポリシー名は「ViewBilling」とする。
iam-04

–グループ作成編–
1)ルートアカウントでログインする。

2)IAMに移動し、グループ>新しいグループの作成を選択する。

3)Admin には”Administrator Access”と”ChangePassword”を付与する。

4)Developersには”Power User Access”と”ChangePassword”を付与する。

5)Operatorsには”Read Only Access” と”ViewBilling”と”ChangePassword”を付与する。

–Cloud Trail編–
1)ルートアカウントでログインする。

2)Cloud Trailを選択する。
iam-07

3)証跡名、S3バケットを指定することでログ取得が可能になる。
iam-06

■まとめ

AWSのルートアカウントでのログインを行っている人もまだまだ、多いと思います。
例えば、退職者が発生する度にAWSのルートアカウントのパスワードを変更するといった運用を続けるのはどうなのでしょうか。 AWSといった責任共有モデルでは、個々のセキュリティレベルの意識によってセキュリティレベルも大きく変わってきます。 今回のIAMの導入は、ユーザ、グループ、ポリシーといったコアな機能のみで構成されており、既存のポリシーを生かしつつ、簡単に導入できます。