概要 最近、AWSの試験やらなんやら受検しているのですが、あとになったら逆に受けづらくなるだろうと思い、今のうちにCLF（クラウドプラクティショナー）を受検することにしました。 また、せっかくなので、自宅で受検するという体験をしてみようと思い、自宅受検をしてみました。 過去の受検履歴 AWS SAA を受検した AWS DVAを受検した 結果 合格しました。SAAとDVAを最近勉強していたのでCLFは簡単でしたが、分からないこともあって、少し焦りました。 結果として得点は893点なのでやはり何問かは落としてしまったようです。 SAAと比べると、DVA同様何言ってるかよくわからない日本語があったりするので、そのときは英語をみたほうがイメージがつきやすいものがありました。 ※たとえば「弾力性」って回答があったとして、普段使わないですけど、英語で「Elasticity」とあると、これだな感があります。 勉強 書くほどでも無いですが、SAAやDVAを先月先々月取得するのに勉強していたという前提で、今回は前日の2時間程度だけが勉強期間でした。 今後別の資格も受検しようと思っているので、koiwaclub の有料プランを契約して試験想定問題で前日で8割程度の得点でした。 ただ、書籍での勉強でも良いとは思います。 SAAやDVAと比べてわからなかった技術 下記はSAAやDVAではあまり出てこなかったように記憶しています。 問題のレベルはこれからAWSを導入したい人向けという感じで、質問はわかりやすかったです。 Cost Explorer AWS Budgets snowball Edge Well Architected フレームワーク AWS Config あとは、そのサービスがなんの目的かがわかれば、選択肢はおのずと決まってくるなと思いました。 自宅で受検してどうだったか 正直いうと、次選択することは無いなと思いました。 メリット、デメリットは下記の通り。 ★メリット 自宅で受検できるので移動時間が無い いつも使っているPCが利用できる コロナのリスクが避けられる 日本語の試験監督で受検可能 テストセンターよりも時間の選択肢がある ★デメリット 事前のPCチェックがある スペックそこそこのPC(メモリ8GB, Corei5/MacBook Pro 2019)でもピアソンonVueが重い 家族の人払いが必要 片付けが必要 チェックイン30分前なのですが、私は不安だったので一時間くらい前からチェックをしはじめたところ、macOSのセキュリティ系ブロックのポップアップがあり、やり直しを2度ほど実施しました。 その後、自分の顔と免許証を写真で撮影するのですが、スマホでトライしたところ画面が非常に重くなって、スマホが固まる問題が発生。 2度トライして駄目だったので、PCのカメラでトライしました。（この時点で試験開始前残り15分） また、試験スタートする際のピアソンonVue起動時の画面が死ぬほど重くて、レインボーマークが多発。 スタート直前画面だったので、時間は換算されないものの、1分ほどはじめられなくて不安になりました。 場所においては、事前に片付けが必要だったり、人が入ってきては駄目ということで、今日はたまたま子供が土曜日授業だったので奥さんには外出してもらうなど、別のところで調整が必要です。 いつも使っている椅子でできるならいいかと思ったのですが、手の届く範囲で物を於いてはいけないので片付けてください、テーブルをカメラで見せてくださいと試験監督に言われたりもします。結果として結局いつもの作業部屋とは違うリビングでの受検となりました。 この辺を考慮してだと思いますが、このように割り切ってお風呂でやってらっしゃる方もいます。

概要 約一ヶ月ぶりにアソシエイトレベルの2つ目の資格であるAWS DVA（デベロッパーアソシエイト）を受検して合格しました。 SAAを受検したときの記録はこちら。 AWS SAA を受検した これから受検する人たちへのアドバイス Udemyの模擬試験も申込みして5つの問題中3つほどやりましたがそんなに難しい問題は出てこないので、4つ目5つ目はトライするのをやめました。 下記一冊をしっかりとやって、わからないところだけググったりするのが良いかと思われます。 問題や回答の書き方は違えど、同じようなレベルの問題と回答が問われました。 私はそれで約2週間程度（15時間くらい？）の勉強でしたが8割取得できました。 ポケットスタディ AWS認定 デベロッパーアソシエイト (アソシエイト試験ポケットスタディ) あと、DVAの試験はSAAと比較して受験者数が少ないのか、とにかく試験の誤訳が多いのも注意です。 例えば覚えている範囲では、Lambdaに関する問題で「実行時エラー」とあって、回答と一致しないなと思って英語をみたら「runtime error」となっていました。 ※Lambdaのランタイムは言語別の実行環境を指すので実行時エラーというとニュアンスが変わってきます。Lambdaがエラーを吐いたのか、実行した際のエラーなのかみたいな微妙な違いですが。 また、別の問題はあきらかに問題と回答が一致せず、なんだこれ。。。って思ってEnglishを見たら最後の一文が訳されていなかったり！ ※S3に静的コンテンツが〜　という翻訳だけで、回答にアクセスログとライフサイクルポリシーを設定するみたいなのばかりで「？？」となって英語をみたら、問題の最後の文に「アクセスログも確認したいし監査もしたいからファイルを残したい」みたい英文があり、日本語の問題文に記載がなかったり。。。 他にもタイポがあったり、気がついただけで上記と含めて3箇所は怪しい翻訳があるので、ちょっと躓いたらEnglishボタン押して英語を見ると良さそうです。 英語自体も日本語と照らし合わせながら読めば、理解できるかと思います。 感想 DVAは範囲がそこそこ広いし覚えることが多く、触ったことが無いサービスなんかはイメージがしにくいところがありました。 ただ、API GatewayやLambda、AWS SAMなんかは何度か触っていたので、知識がアップデート出来たのは大変良かったです。 また、SQSは使いどころが見えていませんでしたが、今回受検したことで、SQS,SNS,KMSなんかは使用したほうがより良くなることがわかり、受検勉強により得るものが多かったと思います。 お葬式やらお通夜でバタバタしており、本当はもう少し前に受検する予定で少しずれこんだのですが、取得することが出来て安心しました。 次はSOAの取得を目指しますが、実はその前に取得したい、ITとは全く関係のない資格があるので、まずはそこを次は頑張ろうと思います。 全然自信が無いのでまた受検が終わったらブログに残そうと思います。 <p style='padding: 5px;'>

はじめに 本日AWS SAA を受検して、合格できました。 合格点720に対して743という、ギリギリのスコアでした。 私にとってはかなり難しく感じましたので、反面教師にしていただきたいのと反省も込めて記録しておきます。 勉強期間 2週間(15時間ほど) 勉強方法 まずは下記でアカウントを作成して、試験日程を決定する。普段使うAWSアカウントやAmazonのアカウントとは異なる様子。 https://www.certmetrics.com/amazon/login.aspx?language=ja 公式ガイド（2019）→1.5周 先週と今週 Udemy 模擬試験 5回/6回分 うち2回だけ再試験→前日土曜日朝から夜まで勉強 まず、公式ガイドを1.5周した以外はほぼ前日の Udemy だけの勉強でした。 Udemyはとても良い教材でした。が、このやり方自体はまったくもってオススメ出来ません。 理由として、試験対象のサービスが広範囲で触れたことが無いサービス、勉強しなかったサービスは当たり前ながら回答を絞ることが出来ませんので余裕もって幅広く対策をしたほうが良いからです。 私の場合、 AWS Organizationに関する問題がさっぱりでした。前職も現職も某請求代行の関連で、その企業のOrganization配下に所属するため、普段触れることが無く、同様の契約を会社でやっている場合は注意して勉強した方が良さそうです。 また、私の勉強方法は公式ガイドを何周かするスタイルなのですが、所有していた書籍が古く、既に内容が異なる状態になっていたので2周目を読むのを諦めたのが試験3日前。 例えば所有していた書籍にはS3は 結果整合性 とありますが、　2021年4月現在では強い一貫性 を持つようになっています。 Gracier Deep Archive も記載が無く、試験ではS3関連がよく問われるとのことだったので、逆にややこしくなってしまいました。 Udemy に賭けたところ、6回分の試験で1度目で合格点を超えることは1度も無く、昨日の夜の時点で 47% という合格点を大きく下回る結果でした。 1日中勉強して5回目の試験でそれだったのと、季節の変わり目で花粉症が酷くて疲れてしまい、半ば諦めムードで試験当日を迎えました。 試験難易度 公式ガイドよりは難しく範囲も圧倒的に広いです。 Udemyの試験よりは簡単ですが、範囲は同じくらいでしょうか。 試験場所 渋谷のテストセンター 朝の時間だと人の出入りが多くて、集中力が途切れやすいかもしれません。ただ、駅から近いというメリットがあります。 試験内容 私が受けた際は S3 と CloudFront 関連の問題がいくつもあったように思います。 また、RDSの構成、特に高負荷時の対応に関する問題が多かったです。 個人的に全く分からなかったのがVPN関連でした。 オンプレミスからのAWS移行もいくつかあったと記憶してます。 感想 結果として取得することができましたが、反省の多い勉強の仕方だったなと思っています。 ただ、Udemyの模擬問題集は元々難しいという設定ではあるので、自分の弱点を炙り出しするという意味ではとても意味があるかなと思います。 自社で活用しているAWSサービスに、どうやって反映していくかを今後は考えていけると資格取得の意義がありそうだなと思いました。 なにはともあれ、AWSの資格の登竜門的な存在のAWS SAAを取得できたので、次も目指していきます。

つい先日、AmazonAppFlowというSaaS間連携のサービスがリリースされました。 https://aws.amazon.com/jp/blogs/news/new-announcing-amazon-appflow/ S3, RedShift, Salesforce, Slack, Marketo, Google Analytics, Amplitudeなど全16サービスの連携が行えるということで、Salesforce(以下SFDC)のバックアップをこれで出来ないかと思い検証してみました。 ちなみに、シンプルにバックアップをやろうとすると、ある程度手作業が発生します。 そのため、自動化するにはSOAPやRESTAPIでSOQLを書いて、出力したファイルをバックアップするという作業があるので、それなりにツライです。 事前準備 SFDCのsandboxを用意 バックアップファイルを保存するS3バケットを用意 検証 まず、AppFlowの画面で フローの作成 を実行します。 つぎに フロー名 を指定します。 ここでデータ暗号化にKMSが指定できます。（今回はテストなので使いませんが、本番ではKMSで暗号化したほうが良さそうです。） つぎに連携するSaaSを選択します。今回はSFDCです。 新規接続先を作成を選択します。既に作成済みの接続先は下から選択できるようになります。 SFDCの場合に設定できる項目は下記の通りで、ProductionかSandboxの選択と、接続先ホスト名の指定が可能です。 その後に、ポップアップウィンドウでSFDCのログイン画面が表示されますので、ここでログインを実施します。 ログインが出来たら、データ転送フローにイベントかオブジェクト単位（テーブル）かを選択できます。 今回はオブジェクト単位にします。 その次に送信先を選択できます。面白いのは送信先にもSFDCが選択できるところです。SFDC to SFDCは次回検証してみようと思います。 今回はバックアップ用途なので、S3を選択します。 S3を選択すると、存在するバケット名の一覧が出てきますので選択し、バックアップ先のパスを指定します。 今回はSFDCとします。 フローの実行トリガーを選択できます。 パターンとしては、ボタンを都度押して実行するオンデマンド実行、定期実行、イベントトリガーになります。 今回はバックアップ用途ではありますがテストなので、オンデマンド実行にします。 スケジュール実行にした場合は下記のように指定ができるので、定期実行もできそうです。 次に進むとフィールドのマッピングが行えます。 恐らく、SFDC to SFDCやRedShitなどにした場合に、どこのフィールド（カラム）を指定するかのマッピングがここで行えるようです。 バックアップ用途なのですべて選択します。 次の画面ではフィルターの設定が行えます。条件によって実行するかしないかを決められるようです。 今回は未設定で進めます。 最後に確認して作成します。 10秒ほどで作成されます。 画面右のフローを実行ボタンから実行してみます。 実行が完了すると、S3へのリンクが表示されるのでクリックします。

事の始まり 最近、趣味でサイトのスクレイピングとか簡単なものを作ったりしている。 もちろん対象サイトに負荷をかけないようにするのはそうなんだけど、単純にBANされないようにする方法を考えた時に、UserAgentをちゃんと定義したりする以外に、やはりIPアドレスの分散は課題である。 そこで、Lambdaでスクレイピングした場合に、接続元のIPアドレスはどの程度固定になり、どの程度分散されるのか調査してみました。 IPアドレスチェック用のLambda まず、単純にIPアドレスが返ってくる簡単なLambdaを作成した。 これでCloudWatchLogsにログが記録されるため、IPアドレスがわかるようになる。 import json import requests from datetime import datetime, timedelta, timezone def lambda_handler(event, context): res = requests.get('https://ifconfig.me') JST = timezone(timedelta(hours=+9), 'JST') now = datetime.now(JST) time = now.strftime("%Y%m%d %H:%M:%S") print(time) print(res.text) 調査方法 そもそも、LambdaのIPアドレスは固定じゃないというのはどこかで記事を見かけていて、なんならVPCに配置してEIPつけるみたいな記事を見たことあったため、一旦手動で時間を空けて実行してみた。 その結果、Lambdaの実行時間の最大である15分経過すると、どうやらLambdaが破棄されるのか、IPアドレスが変わるタイミングがわかった。 ※二分探索により、最初30分、5分、20分、10分、15分といった感覚でゆっくり漫画見ながら調べた。 あとは、15分おきに実行するようにCloudWatchRuleで設定して約1日実行してみた。 CloudWatch Logsのダウンロード 設置した翌日、下記コマンドでログをダウンロード。 awslogs get /aws/lambda/ifconfig -s '24 hours ago' --profile プロファイル名 > ~/Downloads/awslogs.txt 行のカウント エディタで適当に不要な行を削除して行をカウント。 4(15min) x 24 = 96IPアドレスなので合っていることを確認。 wc -l ~/Downloads/awslogs.txt 96 /Users/DAREKAUSER/Downloads/awslogs.txt ユニークチェック IPアドレスがユニークであるかチェックTOP10。

やりたかったこと EC2の監視を外部サービスに依存せず、AWSの機能だけで行いたかったのと通知先はSlackにしたかったので下記を利用して設定した際のメモです。 CloudWatch(アラーム、エージェント、メトリクス) SNS AWS Chatbot 結論 先に結論を書くと、今のところ、監視はAWSの仕組みを使わずに外部サービスを使った方が良いかもな〜というのが私の感想です。 CloudWatchで取得できるメトリクスをモニタリング対象にして閾値をこえたら通知させることができるのですが、私が単にやりたかったことはディスクの容量やCPU使用率、メモリ使用率だけのシンプルなものに対して、かなり複数の要素が出てきて中々大変でした。 上記をやるだけならMackerelとかの方が圧倒的に楽です。 もしかしたらもっと良い方法があったのかもしれないですが、とりあえず私がやったことをメモしていきます。 まずはじめにCloudWatchAgentのインストール 設定の流れとしては、EC2にCloudwatchAgentをインストールして、メトリクスを取得する必要があります。 CloudWatchAgentの設定はSSM Managerを使うことでコンソールからエージェントをインストールしたり、共通設定を適用できるようです。 構成管理を行うためコンソールでポチポチではなくAnsibleでやりたいので、最低限の共通設定を下記のように作成して適用するようにしました。 main.yaml - name: install cloudwatch_agent repo tags: cwagent yum: name: https://s3.amazonaws.com/amazoncloudwatch-agent/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm state: present - name: install cloudwatch_agent tags: cwagent yum: name: amazon-cloudwatch-agent state: latest - name: remove default file tags: cwagent file: state: absent path: /etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.d/default notify: restart cwagent - name: copy common file tags: cwagent copy: src: files/common dest: /etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.d/common owner: cwagent group: cwagent mode: '0755' notify: restart cwagent commonファイル

概要 AWSサポートより、CodeBuildにおけるUbuntu14.04 EOL通知が来たのでその対応時にハマった点を記録する。 TL;DR OSはUbuntuのまま RuntimeをStandardにする Imageをaws/codebuild/standard:2.0へ変更する buildspecで Runtime（docker: 18） を指定する aptはapt-getへ変更する sudoは要らない The policy&#039;s default version was not created by enhanced zero click role creation or was not the most recent version created by enhanced zero click role creation. が出たら、Allow AWS CodeBuild to modify this service role so it can be used with this build project のチェックを外す Image 元々、UbuntuのRuntimeでBaseを使用していたところ、これが14.04だった。 まず、これらをStandardへ変更し、Imageは aws/codebuild/standard:2.0 へ変更する必要がある。 buildspec. そのままだと動かず YAML_FILE_ERROR Message: This build image requires selecting at least one runtime version.

Lambdaやりたいと言いながら放置していたので、このGWという連休でLambdaの簡単なスクリプトに手を付けよう！と意気込み、連休最終日（明日も休みにしちゃったけど）に作った。 モチベーション 単純にtodoistがAPIを公開しており、APIのリファレンスが比較的わかりやすかったことがある。 todoist api reference あと、Slackのtodoist appで特定プロジェクトのタスクの一覧表示とかできなかったのが大きい。(調べてみたけどわからなかった、、） 本当はLambdaでSlack botまで作ろうかと思ったけど、まずは通知するところからやることにした。 コード pythonを選んだ理由は,最近pythonのboto3で色々スクリプトを書いていたから。 # coding: utf-8 import json import requests import os import sys from todoist.api import TodoistAPI SLACK_CHANNEL = os.environ['SLACK_CHANNEL'] SLACK_POSTURL = os.environ['SLACK_POSTURL'] TDIAPI = TodoistAPI(os.environ['TODOISTAPITOKEN'], cache=False) TDIAPI.sync() name = os.environ['TODOIST_PJT'] def tasklist(name): list = TDIAPI.state['projects'] for projects_id in list: if projects_id['name'] == name: tasks_project_id = projects_id['id'] break try: tasks_project_id except NameError: print("プロジェクト名が正しくありません。プロジェクト名を正しく入力してください。") sys.exit() items = TDIAPI.state['items'] slackmessage = [] for name in items: if name['checked'] == 0 and name['project_id'] == tasks_project_id: taskcontent = '- ' + name['content'] slackmessage.

X-Tech JAWS 【第7回】平成最後のクラウド力アップ大作戦！！に参加してきたのでそのメモ。 X-Tech JAWS 【第7回】~平成最後のクラウド力アップ大作戦！！~ – X-Tech JAWS | Doorkeeper ハッシュタグ – #xtechjaws – #xtechjaws07 X-Tech JAWSの話 他の業界のAWSの活用状況とか知りたい クロステックではなくエクステック AWSを使っている人たちが対象 技術とは無縁な農業とかも対象 有名どこのドメインからAレコードひいてAWSだったら登壇依頼とかしてる Session1: 株式会社スナックミー CTO 三好 隼人さん『素早くおやつの新ブランドを立ち上げるためのLambda活用法』 スナックミー(snaq.me (スナックミー) | あなた専用のおやつBOXで頑張る自分にご褒美タイムを)とは「おやつのサブスクリプションBOX」 おやつの時間を価値ある時間にする 製造から発送まで自社でやってる LambdaはAWS Batchや音声でピッキングとかにも使っている ユーザーの商品選択をアサインと呼び、それらをLambdaでやっている Lambdaでできない範囲をAWS Batch ユーザーさんにはメールではなくLINEでやっている LINE PUSHは全ユーザーにしてしまうとBANされるので対象ユーザーを絞ってPUSHしている 用途ごとにStep Functionを使っている LambdaとRDBMSは相性が悪いが、ROだったり、一日数回だったら問題なさそう Step Functionが便利（ワークフロー作れるし、エラー吐いても途中からリトライできる） Layerでとてもテンションが上がった カスタム関数が重複しなくて済むようになる Pythonがメイン LambdaとLayerを分けて管理（用途ごとに分割） バージョン一覧を見えるようにした 1関数ごとにLayerARNを設定して1ファイルが大きくなりすぎない 本当にLambda Layersで幸せになれるのか？ 旧式のデプロイ方式からLambda Layersを活用したデプロイ方式への移行を検討する ｜ DevelopersIO Session2:株式会社朝日新聞社 佐渡 昭彦さん『メディアにおけるAI活用とAWSに期待すること（時事クイズと高校野球戦評記事の自動生成）』 サイバー攻撃をよくうける 時事クイズの自動生成の話 ニュースを読まない学生が非常に多いので、時事ニュースにふれる機会を増やす Qrich 重要語抽出->AWS Comprehenddが日本語未対応なので東大・横国大のOSSを使っている->形態素解析や複合語の学習 単語ベクトルとは単語の特徴を数値（ベクトル）で表現したもの サーバー構成でフロントは実はGCP->SNSログインがとても簡単なので 事実だけだけど記者が書いたのか自動生成された記事か分からない スコアテーブルと戦評記事をクレンジングしたら約8万件 OCRしたいけど7~8割り程度の制度(AWSはまだ日本語未対応) 会社として誤った記事は絶対出さないというスタンス テンプレートを用意するようにした（100万件） EC2 1台しか使ってない 過去30年分くらいはデジタル化されている Session3:アマゾン ウェブ サービス ジャパン株式会社 根本 裕規さん『グローバルでみたEdTech on AWSのメリットとEdStart』 EdStart(東京リージョンにきた)/Educate Public Sector（公共団体、大学、教育、医療） VDIとかメールとか、個人にパーソナライズされた教育などの相談を受ける EdStartを今年は東京でやる予定 技術支援やイベント、クレジット提供している 日本では4社 インドは今EdTechが熱い AWSの学習コースを学生向けに無料提供 ジョブボード（求人掲載）を提供 ドメインがAC.

概要 AWS LoftでAWS Startup Day 2019の春期講習補講＆おかわり編があったので参加してきた。 その時のメモ。 最初に 下記を週刊で公開していく予定 【週刊 Ask An Expert #01】AWS Loft Tokyo で受けた質問まとめ 20190408-0412 #AWSLoft | AWS Startup ブログ データストアどれを使えばいいのかわからない(@zabbioさん) よくある課題 サービスが多くてどれ選択すればよいのかわからない RDBMSに入れっぱなし RDBMSだけだとツライ 辛くなるケース 当初と仕様が変わってきてRDBMSでやり続けるのがツライ マネージドサービスを使っていってほしい 複雑な設定作業や手作業、運用コストを減らすために データストアの特定(RDS,Neptune,DynamoDB,Redshift…) 例:RDS->DMS->Kinesis->Firehose->Lambda データのマスキングしながらデータの移行とかも出来る 十分な停止時間が取れてデータベースエンジンが同一であればダンプツールを使う(mysqldump) 十分な停止時間が取れない場合は、DB純正のレプリケーションを組む 十分な停止時間が取れず、エンジンも異なる場合はDMS(AWS Database Migration Service（簡単、安全なデータベース移行）｜AWS)を使う ちゃんと検証をしよう 負荷エミュレーションを使う(mysqlslapなど) パフォーマンスインサイト(cloudwatch) Cloudwatch Logsでslow query logsの特定の文字列をフィルターしてLambdaでSlack通知とかも出来る パフォーマンスインサイトはAuroraMySQLではt2,t3は現状未対応 認証基盤ちゃんとしたい よくある課題 認証基盤を統一したい いろんな認証をしたい Amazon Cognitoを使おう 複雑な要件があったらLambda Amazon Cognito 認証処理の実装を軽減 認証情報の管理は不要 SNS,AD,ldPとの連携 サインイン、サインアップフォームを連携 複雑な要件ではAWS Lambdaでカスタムする SESで数字を送って、その後にreCAPTCHAを使う ユーザー移行Lambdaトリガーを使って移行であれば、サービス停止無い CSVインポートだと、全ユーザーによるパスワード再設定が必要 NIST 800-63-3(DRAFT NIST Special Publication 800-63-3) の資料がとても参考になる ログをちゃんと扱いたい Data Lakeとは AWSの定義-> 多種多様なデータを一元的に保存、データを失わない、サイズ制限なああい、APIですぐにアクセスできる AWS の Data Lake = S3 S3をData Lakeのコアにすることで、様々なサービスと連携ができる とりあえず生ログはS3に貯めておく CloudWatchのログをkinesis経由でS3に保存する EC2はCloudWatchLogs AgentでCloudWatchに送ることが出来る モニタリングが不要で分析がメインのログは Kinesis AgentでS3に送ることができる フロントエンドのログはKinesis Firehorseに送ることが出来る VPCのフローログは直接S3へ保存できる RDBMSにログを保存していた場合は、DMSを使ってS3に定期出力が可能 迷ったらKinesis Data Firehoseを使うことを考える 時系列データみたいなのは、10MBとか60sなどの単位でKinesisで指定して、S3へ保存できる 個人情報が含まれているなどマスクしたい場合、FirehoseからLambdaを呼んでマスクできる FirehoseからS3以外に、RedshiftやElasticsearchに移行しやすい 日本以外のリージョンだとKinesis Data Analyticsを使える AWS Glue : フルマネージドのデータカタログ + ETLサービス (Apache Spark) Amazon Athena : サーバーレスなインタラクティブクエリサービス Amazon EMR : Hadoopクラスターサービス, 最近ではSparkを使うことが多い ELBのログはそのままS3へ保存でき、ある程度構造化されている ELBのCSVログをGlueでparquet形式へ変更して、Athenaで検索できるようになる 構造化されていないFirehoseからのデータをGlueを非構造化データの正規化ができるので、きれいに処理したものをS3へ保存することができる 複数ソースから成るデータをEMRでデータ生成できる RAWデータをS3にしっかり貯める RDSのデータをGlueで定期的に抽出して、個人情報をマスキングしてS3へ保存できる。結果的に個人情報をきにせずに分析が出来るようになる BI,Dashboard: QuitckSight, Redash, Apache Zeppelin 機械学習系のサービスも最近充実 このあとにもセッションがあったが、上記内容である程度満足したのでここで退散した。