Amazon EMR
# Amazon EMR
https://d1.awsstatic.com/webinars/jp/pdf/services/20191023_AWS-Blackbelt_EMR.pdf
## なぜAmazon EMR を利用するのか
- 何が求められているか
- 新たな非リレーショナルデータをペタバイト以上のスケールでリアルタイムにキャプチャして保存
- バッチレポートだけではなく、リアルタイム、予測、音声、画像認識を組み込む新しいタイプの分析をする必要がある
- 安全かつ管理された方法でデータへのアクセスを民主化する
- 従来までの分析方法
- Amazon EMRとは
- マネージドなHadoop と Spark
- 最新のHadoop および Spark エコシステムのリリースをデプロイ
- 任意のサイズに拡張可能
- 高い可用性と耐久性
- オートヒーリング
- 高い安全性
- 暗号化
- 保管時の暗号化
- 転送時の暗号化
- Amazon Macie によるセキュリティ
- VPCを利用したネットワーク分離
- S3 をPrivate Link で接続してよりセキュアに
- パブリックアクセスをブロックするオプション(Block Public Access)
- IAMポリシーとの連携
- AWS CloudTrail
- Kerberos サポートによるAD認証
- Hadoop エコシステム機能による認証認可
- RIを利用可能
- 必要に応じてスケールさせることができ、コスト最適化を図れる
- データはS3へ、コンピューティング部分と分けることで、用途に合わせたクラスタを立てることができる
- 他のAWSサービスとの連携
- Kinesis Connector
- DynamoDB-connector for Hive
- S3
- Redshift-spark connector
## Amazon EMR で何ができるのか
## どうやって利用するのか
- クラスタを作成後でも、ソフトウエア設定を再構成して、実行中のクラスタ内の各インスタンスグループに設定を追加・更新することができる
- Job 実行時の処理のステップを追加することが可能
- 複数のtask グループを設定することが可能（task グループによってインスタンスファミリーを変更するなど）
- オートスケーリングの設定
- ロギング
- デフォルトでマスターノードに書き込まれるログをS3に出力することもできる
- デバッグオプション
- EMRFS Consistent View
- S3は結果生合成を持つので、一貫性がない場合に処理を再実行させることができる
- DynamoDB をファイルレジストリとして使用し、矛盾の検出と処理の再実行を行う
- カスタムAMI
- ゴールデンイメージとして運用
- 起動時の処理の追加
- EC2キーペアを設定することでマスターノードにSSHできる
- IAMの設定
- 暗号化とセキュリティグループ
- EMRノートブック
## Amazon EMR とその他のサービスとの使い分け
- Amazon Athena
- AWS Glue
- 以下のケースに当てはまるなら Apache Spark on Amazon EMR を利用するのが良い
- ETL 処理にSpotインスタンスを利用したい
- 単一のノードのスペックを高くしたい
- ETL 処理にSpark 以外のアプリを使いたい
- Amazon Kinesis Data Analytics for SQL/Java App
- Amazon DynamoDB
まとめると以下の場合にはAmazon EMRを利用するのが良い
- Hadoop と各種アプリを柔軟にカスタマイズしたい
- オンプレのHadoop クラスタをシンプルに移行したい
- マネージドサービスの制限を回避したい
- できるだけ新しいバージョンを利用したい
- アプリケーションのバージョンを固定したい
- 複数種類のアプリケーションを同一クラスタ上に稼働させて連携させたい
## 雑感
Amazon のマネージド MapReduce。大量のデータを処理するための分散処理基盤であるHadoop / Spark のマネージドサービス。分析するAWSのサービスは他にAmazon Athena や Amazon Redshift があるが、これらはS3をデータソースとして分析するだけにとどまっているので比較的制限がある。それに対してAmazon EMR はより柔軟に大規模なデータを扱うのに適している。Amazon EMR で最初に処理を行った後にS3にストアしたデータを利用してAthena や Redshift を利用するという組み合わせで処理を組むことも可能。
インターネットに露出しない仕組みや、IAM やHadoop そのもののセキュリティの仕組みを利用してセキュアに利用することもできる。
Q. Redshift とEMR の使い分け
https://aws.amazon.com/jp/redshift/faqs/
Q. ビッグデータサービス（Athena, EMR, Redshift）との比較
Amazon Elasticsearch Service, Amazon CloudSearch
# Amazon Elasticsearch Service, Amazon CloudSearch
https://d1.awsstatic.com/webinars/jp/pdf/services/20200623_aws_blackbelt_amazon_es.pdf
https://d1.awsstatic.com/webinars/jp/pdf/services/20160323_AWS-BlackBelt-CloudSearch_AmazonES.pdf
## 全文検索とは
## Elasticsearch とは
- ログ分析や検索に関する様々なスースケースで利用できる、分散型RESTful 検索/分析エンジン
- コンポーネント
- 可視化
- Kibana
- 分析/検索
- Elasticsearch
- 収集
- Log stash
- beats
- データ挿入から活用までの流れ
- データの持ち方
- 論理的なデータの持ち方
- Index の中にDocument を持つ。Documentの中にフィールドとしてアイテムが格納される
- 物理的なデータの持ち方
- マスターノードとデータノードに分かれる
- データノードではプライマリーシャードとレプリカシャードが作成され、可用性を向上させている
## Amazon CloudSearch 概要(2011-)
- 自動拡張するフルマネージド検索サービス
- Auto Scaling
- Auto Partitioning
- Apache Solr のマネージドサービス
- Indexing
- 全ての喉にELB経由で均等にアップロード
- ファイルをS3に保存
- メタデータはDynamoDBに保存
## Amazon Elasticsearch Service の概要
- 概要
- Elasticsearch と Kibanaを簡単にデプロイ・管理・スケールさせることが可能なフルマネージドサービス
- エンタープライズグレードのセキュリティ、アラート、SQLなどにより強化されたElasticsearch のディストリビューションであるOpen Distro を採用
- 利点
- フルマネージド
- 柔軟性
- コスト効率
- RIも選択できる
- 高可用性
- セルフヒーリング
- モニタリング
- マルチAZ
- 自動バックアップ
- スケーラブル
- スケール
- バージョンアップ
- パッチ適用
- セキュア
- VPC内へのデプロイ
- Cognito によるログイン
- API
- サポートするインスタンスサイズ
- インスタンスサイズによって最大EBSサイズやHTTPリクエストペイロードの最大値がことなる
- 世代が古いと古いESバージョンが利用できるが、データ暗号化や詳細アクセスコントロールが設定できないなど制約も多い
- 推奨アーキテクチャ
## ログ分析
- データ投入
- ログ分析の場合、Kinesis Data Firehose 経由でストリームデータを直接ESに入れるのが定番（別アカウントからのインプットにも対応）
- CloudWatch Logs サブスクリプションにより、Lambdaを経由したストリームデータ投入も行える
- Lambda等からElasticsearch のBulk API を叩いてS3のデータを定期的にインポートするといったことも可能
- SQLインターフェースのサポート
- Ultrawarm ノード
- 大規模ログ分析を低コストで実現するためのノードタイプ
- S3に保持したデータに対してクエリを実行
- 読み取り専用
- クラスタ横断でのクエリ実行
## 検索
- 日本語全文検索用のプラグイン
- ユーザ辞書ルールによるカスタム辞書の使用
- Kuromoji で形態素解析をする時にユーザ登録の固有名詞を教えておく場合に利用
- カスタムパッケージによるファイルベース辞書の使用
- kNNによる最近傍探索
## 管理
- Indes State Management(ISM) でインデックス管理の自動化
- ISM機能により、日・週・月単位で新しく作られるインデックスの管理を自動化、従来Curator で行う必要があったものをAmazon ES 側で設定可能に
- Kibana 上でインデックス管理ポリシーを設定・管理
- _template API と併用することで新しいインデックスうにポリシーを自動で反映
- ロギング
- Elasticsearch API のログ
- 以下をCloudWatchに出力
- インデックススローログ（ドキュメントの追加・削除・更新）
- 検索スローログ（検索クエリ）
- エラーログ
- デフォルトでは無効になっている
- 設定APIのログ
- APIコールのログをCloudTrailに出力
- 検索APIベースのアラート
- Elasticsearch のクエリを指定して、一定の閾値を超えた場合にアラートをあげることが可能
- Slack 等に通知を飛ばす
- Anomary Detection をトリガーにしたアラートの実行
- Random Cut Forest アルゴリズムを用いた時系列の異常検知機能
- 設定変更
- ドメイン変更時にはBlue/Green デプロイによって行われる
- 一時的に倍のノードになりデータノードとマスターノードに負担がかかる
- 深夜帯に行うことを推奨
- スナップショット
- クラスターのバックアップ
- 自動スナップショット
- バックアップ
- １時間ごと14日間作成
- 手動スナップショット
- バックアップ / データ移行
- S3にデータを保存するため料金に入れる
運用のベストプラクティス
## セキュリティ
- 認証と認可
- IAMベースのAmazon ESドメインに対するアクセスポリシー
- Logstash のAWSプラグインを利用することでAWSのクレデンシャルを利用してデータ投入できる
- Open Distro ベースのドメインないサブリソースに対する詳細なアクセス権限管理
- ユーザー
- ES内部で管理
- Cognito 連携
- 詳細な権限管理
- インデックスレベル
- ドキュメントレベル
- フィールドレベル
- Kibanaのマルチテナンシー
- 暗号化
- VPC からAmazon ES にプライベート接続
## Amazon CloudSearch と Amazon ES の比較
- CloudSearch
- 検索エンジン
- Solr
- CloudSearch API を利用して検索
- AutoScaling でスケールする
- インスタンスストアにデータを保持するため大量データ保存は厳しい
- ログの可視化はできない
- リアルタイムデータ取り込みは制限がある
- Amazon ES
http://dev.classmethod.jp/cloud/elasticsearch-service-vs-cloudsearch/
- 決まった仕様のCloudSearch か 高いカスタマイズ性のElasticsearch
- 1対多のデータ構造対応ならElasticsearch
- 運用で楽がしたい場合はCloudSearch
## 雑感
AWS のマネージドElasticsearch。IAMによる制御に加え、OSS自体についている認証・認可の仕組みを利用して、ドメイン・ドキュメント・インデックスレベルで細かく制御をすることができる。
料金がノード間の転送料金はかからないが、Amazon ES からのin/out がかかるのでアプリの仕組みによってはお金がかかるようにも思える。
そもそも運用コストがElasticsearch が高いので、Amazon ESを利用することで運用コストをかなり減らすことができると思う。
それよりも仕様が決まっていて、運用で楽がしたいのであればCloudSearch を利用することが選択肢となると思う。
Amazon Kinesis
https://d1.awsstatic.com/webinars/jp/pdf/services/20180110_AWS-BlackBelt-Kinesis.pdf
- 概要
- ストリームデータを収集・処理するためのフルマネージドサービス群
- 利用場面
- 広告/マーケティング
- IoT
- ゲーム
- コンシューマー向け
- 運用/セキュリティ
- ストリーミングデータの利用シナリオ
- データの収集とETL
- 配信や入札データの収集
- 顧客行動データの収集
- 運用のシステムメトリクスの収集
- 継続的なメトリクス計算
- コンバージョンレート/収益/カバレッジの計算
- クリックレートの計算
- PVの計算
- システムログ分析
- リアルタイム分析と応答
- ユーザ行動に応じた配信・入札エンジンの最適化
- 稼働状態予測あアラート・通知の発行
- レコメンデーションエンジンの最適化
- 異常検知
### Kinesis Streams
ストリームデータを処理するためのアプリケーションを独自に構築
- アーキテクチャ
- input
- 認証・認可を経てデータをInput
- たくさんのストリームデータがKinesis Streams へ
- 3AZでの強い生合成でデータを複製
- 順序つきのイベントストリームとして複数のアプリケーションから同時アクセス可能
- Output
- コンセプト
- データの種類や用途に応じてストリームを作成。ストリームは１つ以上のシャードで構成
- 保存されるデータの単位を「データレコード」と呼ぶ
- 保存期間はデフォルトで24時間。最長7日
- １データレコードの最大サイズは1MB
- ストリーム内のシャード数を増減することでスループットをコントロール
- データレコードの分散
- データ入力時に指定するパーティションキーで保存先のシャードが決定
- 分散して処理が可能に
- 全てのデータレコードにはシーケンス番号（シャード内でユニーク）がアサインされ、順序が保証される
- サポートするプロデューサー・コンシューマー
- プロデューサー（送信側）
- AWS SDK
- Kinesis Producer Library (KPL)
- Amazon Kinesis Streams にデータを送信するOSSの補助ライブラリ
- Aggregation
- 複数件のデータを１データレコードに集約して送信可能
- Collection
- 複数レコードをバッファリングして送信
- Kinesis Agent
- Amazon Kinesis サービスにデータを簡単に収集して取り込むスタンドアロンJavaアプリケーション
- ファイルのローテート処理、失敗時の再試行、フォーマットの変換やログのパースなどの前処理をしてくれる
- Cloudwatch へメトリクスを送信
- Kinesis Streams / Kinesis Firehose のどちらへも送信可能
- AWS IoT
- Kinesis Log4j Appender
- Fluentd
- CloudWatch Events/Logs
- Amazon Kinesis Data generator(KDG)
- コンシューマー（データ処理側）
### Kinesis Firehose
ストリームデータをAmazon S3, Amazon Redshift, Amazon ESへ簡単に配信
データストアとダイレクトに統合
サーバレスETL
- コンセプト
- 配信先に応じて「配信ストリーム」を作成
- シャードの作成やパーティションキーの指定は不要
- 制限なしにスケール
- １データレコードの最大サイズは1MB
- 連携
### Kinesis Analytics
ストリームデータを標準的なSQLクエリでリアルタイムに分析
- コンセプト
- 分析単位に「アプリケーション」を作成し、入出力となる「ストリーミングソース/ディスティネーション」を設定
- SQLクエリ実行の前処理としてLambda 関数を指定可能
- クエリの複雑さとデータのスループットに応じてKPU(Kinesis Processing Units) を設定
- Kinesis Streams / Firehose -> 入力ストリーム -> Lambda -> SQL -> 出力ストリーム -> Kinesis Streams / Firehose
- 様々なタイムスタンプを利用して処理
- タンブリングウィンドウ/ スライディングウィンドウ を指定して問い合わせ
- CloudWatch によるアラート
- 参照テーブルの結合
- ユースケース1
- Data producer から Kinesis Firehose にデータを送り込む
- ユースケース2
- Lambdaを利用したスピード優先の処理
- Redshift やEMRを利用したBatch 処理での分析
- ユースケース3
- IoTと組み合わせたセンサーデータの収集と前処理
## 雑感
ストリームデータの受け取り、Lambda と連携した処理、データ受け取り後に他のサービスに流す処理を行うサービス。大量のデータを受け取り、分析がしやすい状態に加工して、本職のサービスが利用しやすい状態にすることがメインになる。
大量なデータを受け取ってもフルマネージドで無制限のスケールなので心配する必要がない。
Kinesis Data Streams とSQSの違いは
SQSはシンプルにキューイングしてコンシューマーはそれを取り出してキューから削除するが、Kinesis は大規模なストリーミングをリアルタイムに処理したり、レコードを数時間後に同じ順序で提供したい場合などで利用される。これはTTL時間の差やレコードのサイズの差にも表れている。
Amazon Athena
# Amazon Athena
https://d1.awsstatic.com/webinars/jp/pdf/services/20200617_BlackBelt_Amazon_Athena.pdf
## Athena とは
Amazon S3 にあるデータ（または様々なデータソース）に対してSQLを使用して簡単に分析可能とするインタラクティブなクエリサービス
- 特徴
- ユースケース
- シンプルにS3に対してクエリを発行して分析
- ログ分析
- S3に出力される様々なAWSサービスのログや収集データに対してクエリ
- ETL (Extract/Transform/Load)パイプラインをAthena で構築
## Athena の使い方
- データをS3に保存する
- Database Migration Service
- Kinesis Data Firehose
- Kinesis Data Streams
- S3
- Storage Gateway
- Snowball / Snowball Edge / Snowmobile
- DataSync
- AWS Transfer Family
- テーブルを定義する
- Athena ではクエリのためにテーブル定義が必要
- デフォルトでAWS Glue Data Catalog 状のテーブル定義を使用
- HiveQL形式でDDLを記述
- データソース
- データを記述するデータカタログとデータを合わせてデータソースと呼ぶ
- デフォルトのデータソースはAWS Glue Data Catalog
- すでに既存の仕組みがあり、Hive Metastore を持っている場合にはこれに対してAthena を接続できる
- クエリを実行する
## Athena の様々なクエリ
- CTAS(Create Table As Select)
- クエリ結果をもとに新しいテーブルを作成
- ETL処理をAthena で実行可能
- データを圧縮フォーマットに変換
- データを複雑に加工整形するための多段クエリ
- パーティショニングとバケッティング
- INSERT INTO
- クエリ結果をもとに、既存のテーブルにデータを追加
- 実行のたびに新しいファイルが生成されるため、少量データでの実行を繰り返すことで、大量の小さなファイルが生成されクエリパフォーマンスに影響
- パーティション追加
- VIEW
- クエリ自体を仮想的なテーブルとして登録
- 活用シーン
- データのサブセットをクエリする
- 複数のテーブルを１つのクエリに結合する
- 既存の基本クエリの複雑性を解消して、ユーザーによるクエリの実行を単純化する
- クエリ問い合わせのインターフェースとして利用し、クエリ仕様変更に対する影響を最小限にする
- 地理空間データ分析
- 変数（SELECT $path, WHERE $path)
- LIKE 句やWhere 句で利用
- Amazon Athena Federated Query
- 様々なデータソースに対してSQLクエリを実行可能
- AWS Lambda で動作するコネクタを利用して実行
- 標準コネクタ
- Amazon DynamoDB
- Amazon Redshift
- Apache HBase
- MySQL
- PostgreSQL
- Athena Query Federation SDK を利用して、独自コネクタを実装可能
- User Defined Function(UDF)
- ユーザ独自のスカラー関数をUDFとして定義してSQLクエリで呼び出すことが可能
- データの圧縮・解答、機密データの編集、カスタマイズされた復号の適用など独自の処理を実行可能
- Java で実装し、Lambda関数としてAthena から呼び出される
- Machine Learning(ML) with Amazon Athena
- Athena SQL クエリでSageMake MLモデルを呼び出し、推論を実行可能
## パフォマンスチューニング
### データ最適化
- 列指向フォーマットにする
- Online Analytical Processing 向き
- 特定の列をまとめて保持
- 特定の列だけを扱う処理では、ファイル全体を読む必要がない
- メリット
- OLAP 系の分析クエリを効率的に実行できる
- 単純な統計データならメタデータで完結する
- IOの効率が上がる
- データ圧縮
- 最低限分割可能な圧縮形式を利用しておくことで分散処理をすることが可能
### データレイアウトの最適化
- パーティションを利用する
- S3 オブジェクトのキーを構成をCREATE TABLE に反映
- Where句で絞った時に LOCATION でS3のパスを指定し該当ディレクトリだけを読み込む
- Partition Projection
- 概要
- 非常に多くのパーレィションがあるテーブルにたいするクエリ処理を高速化し、パーティション管理を自動化することが可能
- パーティションプルーニングでメタデータを利用して、クエリに適用されるパーティションにだけ処理を実行することで高速化を図れる。
- しかし、テーブルに非常に多くのパーティションがある場合AWS Glue Data Catalog に対するパーティション取得APIの呼び出しがクエリパフォーマンスに影響する可能性が生じる
- Partition Projection を利用するとパーティション情報をAthenaが計算できるようになるため(AWS Glue Data Catalog を経由しないため）クエリ高速化の恩恵を享受できる
- ユースケース
### クエリの最適化
- LIMIT を利用してORDER BY を最適化
- JOINの順番を工夫する
- GROUP BYの工夫
- LIKE演算子を利用する際にはregex に置き換えて実行する
- （多少の誤差を許容できる場合）近似関数を利用する
- 必要なカラムだけを読み込む
## Athena の運用管理
- Workgroups を利用した利用量・コストの管理
- EventBridge を利用したクエリ監視
- CloudWatch メトリクスの利用
- CloudTrail を利用した利用状況のロギング
## Athena のセキュリティ
- 保管時の暗号化
- 転送時の暗号化
- AWS Lake Formation によるFine Grained Access Control
- シンプルな権限のGrant / Revoke
- データカタログのデータベース・テーブル・列に対して権限を指定可能
- 全てのデータアクセスを一箇所で監査
- AWS Glue Data Catalog のリソースベースポリシー
- IAM との連携
- AWS Glue Data Catalog
- S3
- VPC エンドポイント
## 雑感
Athena と Redshift はSQLを発行できる、列指向（がメイン）として利用されるので競合に当たるものだと思う。Athena はフルマネージド、Redshift はマネージドだがクラスタを用意しないといけない点で異なる。イメージとしてはアドホックに利用したい場合や既存のあるデータが対応している場合に利用してみるかという感じ、Redshift はそもそもデータから何かを生み出すように設計して運用される場合に利用されるイメージ。
AWS WAF
# AWS WAF
https://d1.awsstatic.com/webinars/jp/pdf/services/20200324_AWS_BlackBelt_AWS_WAF_Update.pdf
## WAFとは
Web Application Firewall
ウェブアプリケーションの通信内容を検査し、不正なアクセスを遮断するルールセットを持つセキュリティ対策
## WAF の対応する範囲
- 攻撃手法
- DDos
- CloudFront
- ELB
- AWS Shield
- Application Attacks
- <- WAFはここ
- Targeted attackes
- WAFがしていること
- WAFは悪用する能力を制限するもの
- 様々なHTTPのリクエストパターンを検証
- 攻撃の変化に対応するためにルール構成を迅速に変更する機能
## WAF の機能
- 機能
## WAFの変更点
- 2019.11 でWAFはv2になり、v1 はWAF classic となった
- ルールの記述タイプが統一
- より柔軟に表現も可能に
- WAF Capacity Unit が上限
- それぞれのルールの中身に応じて処理コストを計上、その合計がWeb ACL のCapacity を超えない範囲でルールを登録可能
- 上限は1500
- ビルトインのマネージドルール
- AWS WAF Full logs の拡張
## WAF の詳細
- WAF のコンポーネント
## WAF を利用した多段防御
User - AWS Shield - Route53 - (WAF - CloudFront) - WAF - ELB - EC2
というように複数箇所の前段にWAFを置くアーキテクチャ
## ログとモニタリング
- モニタリング
- AWS WAF Full logs
- Elasticsearch と Kibana によるログ分析
- カスタムエラーページ
- CloudFront と連携させて設定可能
- パートナーマネージドルール
## WAF 利用のための考慮事項
- ルールポリシー
- ブラックリスト型
- デフォルトのアクションは許可
- ルールに合致した不正なリクエストをブロック
- ホワイトリスト型
- デフォルトのアクションはブロック
- ルールに合致したリクエストを許可
- 限られた利用者がアクセスするケース
- ルールの運用
- セルフサービス
- テンプレートなどを利用してルールを構築
- ログの分析やルールのアップデートを継続実施
- 誤検知が発生した場合はルールの見直しを自身で実施
- マネージド
- 導入ステップ
- Count モード
- 開発環境等でテスト
- 誤検知が発生していないかサンプルリクエストレポートで確認
- CloudWatch メトリクスでルールを評価
- Full Logを確認
- Block モード
- 連携
## 雑感
AWS のマネージドWeb Application Firewall。構成のところで確認したが、アーキテクチャの一番前段にはAWS Shield が入り、その後ろで多段で利用されるイメージ。
どのトラフィックを通すのか、どのくらいの連続したトラフィックを悪意のあるトラフィックとして遮断するかを柔軟にWCUの範囲内で設定することができる。
JSONで設定を管理することができるのでVCSで管理を用意にしやすいし、APIで管理できるので運用にも乗せやすそう。1ルールあたり1$かかるので、効率的にルールを決めて悪意のある攻撃を遮断できるように設計する必要がある。
AWS Shield
# AWS Shield
https://d1.awsstatic.com/webinars/jp/pdf/services/20170718_AWS-BlackBelt-Shield.pdf
## DDos 対策
DDos とは: Distributed Denial Of Service(ネットワークを通じた攻撃手法の一種で、標的となるコンピュータに対して複数のマシンから大量の処理負荷を与えることでサービスを機能停止状態へ追い込む手法のこと)
- ユーザーができるDDoS対策
- 攻撃対象領域を削減する
- スケールして攻撃を吸収できるようにする
- 公開されたリソースを保護する
- 通常時の動作について学習する
- 攻撃に対する計画を作成する
- AWSには標準でDDoS防御が組み込まれている
- セキュリティの脅威タイプ
## AWS Shield とは
AWS Shield はDDoSに対しての対策を行ってくれる
- 種類
- Standard Protection
- 全てのAWSユーザに適用
- 無料
- Advanced Protection
- より大規模な、より洗練された攻撃からの防御を提供する
- 有料のサービス
- AWS Shield Standard
- Layer 3/4 Protection
- 一般的な攻撃からの防御
- 自動検知＆自動緩和(DDoSのアクセスを90%以上軽減)
- AWSサービスにビルトイン済み
- CloudFront, Route53エッジロケーションの前にインラインで配置されて全てのパケットはAWS Shield を通るようになる
- Layer 7 Protection
- Layer 7 のDDoS攻撃への緩和はAWS WAFで行う
- セルフサービス
- AWS Shield Advanced Protection
- 対象サービス
- CLB
- ALB（インクルードされているWAFによる対応）
- CloudFront（インクルードされているWAFによる対応）
- Route53
- DDoSへの対策
- DDoS Response Team
- L7 DDoS Protection
- AWS WAFによる保護
- Cost Protection
- DDoS 攻撃によるスケーリングコストを回避
- Advanced Mitigation
- DDoSのトラフィックを軽減してくれる
- DDoS Response Team が手動でセットアップしてくれる部分もある
- L3/4での軽減
- L7 での軽減
- Reporting
- CloudWatch を経由してリアルタイム通知
- ニアリアルタイムメトリクスと攻撃のフォレンジクスのためのパケットキャプチャ
- 時系列の攻撃レポート
- Operation
- Self-Service
- WAFが追加費用なしで含まれる
- 攻撃の通知、フォレンジック、履歴レポート
- DDoS エキスパートによる対応
- 積極的なDDos Response Team の関与
## AWS Shield オペレーションとは
- AWS Shield Advanced を利用するまでのステップ
## AWS DDoS Shield の使い分け
- Standard Protection
- Advanced Protection
- 大規模な攻撃に対する防御
- 攻撃に対する可視性
- 複雑なケースでのDDoSエキスパートによるサポート
## 雑感
AWS のDDoSに対する防御と検知を提供するサービス。基本的なDDoSは無料で組み込まれているので十分と言えそうだが、より高度な攻撃に対応したい場合や、サポートが必要な場合はAdvanced Protection を入れる感じになる。とはいえ、月30万 で一年間利用をコミットしないといけないので判断はする必要がある。
AWS Sheild Advanced Protection にはWAFが付属していてこれによりDDoSだけではなくApplication Attack とBad Bots への対策にもなる。AWS Shield 自体は対応するリソースの前段で動き、悪意のあるトラフィックを検知・軽減してくれる。
AWS Directory Service
# AWS Directory Service
https://d1.awsstatic.com/webinars/jp/pdf/services/20151021_aws-blackbelt-directory-service.pdf
## ディレクトリとは
- ユーザに関わる各種情報を保管する仕組み
- ユーザー名
- 姓・名・部署・電話番号
- メールアドレス
- グループ
- パスワードなど
- ツリー状の構成をすることからディレクトリと呼ばれる
- LDAP、AD、OpenLDAP
- Active Directory とは
- Windows ネットワークの基本的な認証とセキュリティ基盤
- Windows 2000から標準機能として実装されたディレクトリサービス
- Active Directory の必要性
- Active Directory ドメインサービス
## AWS Directory Service
- Active Directory on AWS
- フルマネージド型のディレクトリサービス
- 既存のAD認証を利用して
- ディレクトリタイプの選択（ディレクトリのサイズ選択によって最大ユーザー数の上限が決まっている）
- Simple AD
- AWS上の新規ディレクトリ
- フルマネージドのディレクトリサービス
- AWS上に独立したドメインを作成
- Samba 4 互換
- AD Connector
- Simple AD
- Microsoft AD
## AWS Management Console との認証フェデレーション
- Active Directory フェデレーションサービス（ADFS）
- SSOの提供
- AC Connector によるフェデレーション
- ADユーザーはaccess URL 経由でコンソールにログイン
- MFAを設定できる
- ログイン先からさらにクロスアカウントアクセスでSwitch Role できる
## AWS アプリケーションとの連携
- シングルサインオンの有効化
## 雑感
AWSのAD統合サービス。フルマネージドなSimple AD か、AD Connectorで既存のADと連携させるかを選べる。社内システムやアプリケーションをSSOで管理できるようになり、セキュリティや効率が上がる。Linux の場合でもツールをインストールすることによってADドメインに入ることができる。
Azure AD と競合している。Azure AD とAWS Single Sign-On でAWSアクセス許可を一元管理することができる。Azure AD は標準の規格に加えて様々なカスタマイズができるようになっているようなので、シンプルに運用してAWSに寄せたいのであればAWS Directory Service 、それ以上に柔軟に設定・運用したい場合はAzure AD が選ばれるのではないかな。
