【AWS】Former2を安全に使うための3つの工夫

概要

既存AWSリソースをスキャンしてCloudFormationテンプレート(以降 CFnテンプレート)を生成するOSSツールである”Former2”をより安全に使うための情報を紹介します。

“Former2”はAWS クラウドサービス活用資料集(ブラックベルト)(※)でも紹介されている非常に強力なCFnテンプレート自動生成サービスで、私も頻繁に利用しています。しかし、自アカウントのAWSリソースをスキャンするためにクレデンシャルの登録が必要であり、本当に安全に扱われているのか？という点が心配でした。

本投稿では、上記の懸念について調査した結果を記載しています。

記載内容

• Former2とは
• クレデンシャルの安全性に関するAWSブログ上の記載
• 安全に使うための工夫1：AssumeRoleを使用する
• 安全に使うための工夫2：Former2をdockerでホストする
• 安全に使うための工夫3：閲覧データとログ削除
• まとめ

Former2とは

• 既存AWSリソースをスキャンし、CloudFormationテンプレートを生成するOSS。
• APIコールにはAWS JavaScript SDKを使用。CloudFormationの他、Terraform, CDK等をサポート。
• Webサービスとしても提供されており、いつでもすぐに利用可能。
• 料金は無料。(リソーススキャン時にAPIコールした分のAWS利用料は発生)

○GitHub：https://github.com/iann0036/former2

○Webアプリ：https://former2.com/

使い方

基本的には、2ステップです。可読性の高いきれいなコードが生成されます。

1. AWSアカウントのIAMキーペア(アクセスキーID/シークレットアクセスキー)を入力し、ブラウザ右上の緑の"Scan Account"を押下します。
2. スキャンが終わったら、左側のペインから各サービスの画面を参照します。スキャンされたAWSリソースが一覧化されているので、選択してブラウザ左上のGenerateを押せばCloudFormationテンプレートの自動生成は完了です。

引用：https://former2.com/

補足事項：

• CORS(Cross-Origin Resource Sharing)が必要なリソース(S3, IAM等)の場合、ブラウザ拡張機能のインストールが必要です。
• 一部未対応なサービスやリソースがあります。例えば各リソースに付与したTagがリソースタイプによっては生成されません。また、極一部生成されないパラメータもあります。生成後は必ずパラメータシートと突合してください。

クレデンシャルの安全性に関するAWSブログ上の記載

上述の説明で、非常に便利なサービスであることは理解いただけたと思います。 しかし、IAMキーペアを登録しても大丈夫だろうか？と心配になった方もいると思います。 これに関して、AWSのブログには下記の記載があります。 引用：Accelerate infrastructure as code development with open source Former2 | AWS Open Source Blog

安全に使うための工夫1：AssumeRoleを使用する

上述のAWSブログの記載はあるものの、やはり永続的なキーペアを外部サイトに登録したくないという方は多いと思います。また、IAMユーザが作成できない事情(SAML認証を必須としている環境等)がある方もいると思います。そのような方はIAMロールを作成し、AssumeRoleする事を検討してください。 <実行例>

$ aws sts assume-role --role-arn [ロールのARN] --role-session-name [任意の名前]

Tips：assume-roleコマンドの実行時、「--duration-seconds」オプションを指定することで一時的な認証情報の有効期限をデフォルトの1時間から15分(900秒)まで短くすることができる。

コマンド実行結果を以下の様に入力してスキャンします。

安全に使うための工夫2：Former2をdockerでホストする

プロジェクトのセキュリティポリシー上、一時クレデンシャルでもIAMキーペアを外部サイトに入力することが許容されないケースもあると思います。
そういった方は、Former2をdockerでホストする事をご検討ください。 github.com

※Former2をdockerでホストする方法については、検索すると別の方が既にブログとして記事にしているので割愛します。

Former2をdockerでホストすることは、サービス継続性の観点でもメリットがあります。Webアプリとして公開されているFormer2はSLAがあるわけではありません。いつサービス終了するかもわかりません。Former2をdockerでホストすることは、使いたいときにいつでも使えるという点でもメリットがあります。

dockerでホストする際のTips1

詳細は割愛しますが、私の環境ではFormer2のコンテナイメージをECRに保存し、Fargate上で稼働させています。

ちなみに、GitHubで配布されているdocker-compose.ymlで定義されているnginx:1.17.8-alpineやDockerfileで定義されているnginx:1.15については、ECRで脆弱性スキャンしたところ脆弱性が検出されました。

そのため、1.21.6-alpineにバージョンアップして使っていますが、今のところ問題なく稼働しています。

dockerでホストする際のTips2

Former2のスキャンは、Former2から直接AWSアカウントをスキャンするのではなく、手元の端末を経由します。そのため、手元の端末からAWSアカウントへの通信経路が必要です。

安全に使うための工夫3：閲覧データとログ削除

Former2をローカルにホストし、IAMキーペアに一時クレデンシャルを使っているのでもう安心と思った方、油断は禁物です。ブラウザおよびブラウザのログに保存されているクレデンシャルは都度削除してください。

• GitHubのソースコードを確認すると、クレデンシャルはLocalStorageというクラスに格納されることがわかります。 引用：https://github.com/iann0036/former2/blob/master/js/app.js

• ブラウザの検証機能を覗いてみると確かにLocalStorage保存されています。※これにより、一度ブラウザを閉じても、再度Former2にアクセスすると再度クレデンシャルを入力することなくスキャンが可能です。

• IAMキーペアの漏洩の可能性があるため、閲覧データの削除をしましょう。

• さらに、GoogleChromeのログを見ると入力したクレデンシャルがログに出力されています。こちらも削除しましょう。
  私の手元の環境で複数ブラウザで確認しましたが、GoogleChromeとMicrosoftEdgeの場合はログファイルにもクレデンシャルが平文で出力されていました。FireFoxではそのようなログファイルは見当たりませんでした。 C:\Users\ユーザ名\AppData\Local\Google\Chrome\User Data\Default\Local Storage\leveldb

まとめ

• Former2は非常に強力なツールです。マネコンなどで作成した既存リソースを複製する時などに非常に役立ちます。
• 新規リソース作成時にも便利です。CloudFormationテンプレートの作成時に面倒だと思う事の一つとして、マネジメントコンソールでリソース作成する際、バックエンド側でよしなに作成してくれるIAM等のリソースを、全部定義しなければならない点が挙げられます。Former2を使えば、一度マネジメントコンソールで作成した後、自動でテンプレートを作成するといった手法で、この点を効率化することができます。
• 現時点ではFormer2は全てのパラメータに対応してないようです。作成したリソースについては、必ずパラメータシートと突合しましょう。

安全に使うための工夫まとめ

1. 永続的なIAMキーペアが使用できない場合、AssumeRoleを使用する(IAMロール,一時クレデンシャル)を使用する。
2. 外部のWebサービスに自アカウントのクレデンシャルを入力できない場合、dockerでホストする。ベースイメージをバージョンアップするとなお良い。
3. Former2で入力した情報はブラウザに残るため、閲覧データを削除する。一部ブラウザ(Chrome,Edge)ではログにも残るため、削除する。

【AWS】LinterによるCloudFormation構文エラーの自動検出

概要

AWSの環境構築にCloudFormationを使うことも多いと思います。

• CloudFormationテンプレートの構文エラーをソースコードレビューで全部発見できますか？
• 完璧だ！と思ってマネコンからアップロードして、構文エラーになったら辛くないですか？
• エラーにはならないが、不要な定義が残っていたり、変数の型が間違っていたりするテンプレートを綺麗にしたくないですか？

本投稿では、上記を劇的に改善してくれるツールAWS CloudFormation Linter(cfn-python-lint)を紹介します。

記載内容

• Linterが検出する構文エラーの具体例（クイズ）
• Linterの紹介
• Linterが何に基づき構文チェックを行っているか
• コマンドラインで使用した際の構文エラー検出画面イメージ
• VS Codeで使用した際の構文エラーの検出イメージ
• まとめ
• Tips
  • CloudFormationテンプレート上のコメントは英語で記載
  • 無視しても良い構文エラーの定義方法

CloudFormation構文クイズ

Linterが検出する構文エラーの具体例をご理解いただくために、クイズを作りました。 各ボックスの中には、好ましくない記載箇所があります。探してみてください。

問題1:

ALB:
  Type: AWS::ElasticLoadBalancingV2::LoadBalancer
  Properties:
    IpAddressType: ipv4
    LoadBalancerAttributes:
      - Key: sample_key
        Value: true
                    ~~~~~~略~~~~~~

問題2:

 BackupSelection:
    DependsOn: BackupPlan
    Type: AWS::Backup::BackupSelection
    Properties:
                    ~~~~~~略~~~~~~
      BackupPlanId: !Ref BackupPlan
                    ~~~~~~略~~~~~~

問題3:

SnsTopicPolicy:
    Type: AWS::SNS::TopicPolicy
    Properties:
      PolicyDocument:
        Version: '2008-10-17’
                    ~~~~~~略~~~~~~

CloudFormation構文クイズ解答

問題1：LoadBalancerAttributesのValueはString型ですが、BooleanのTrueが設定されている。

問題2：DependsOnは不要。"!Ref BackupPlan"により、暗黙的にBackupPlanが先行して作成される。

問題3：IAM Policyのバージョンが古い。最新は2012-10-17。

cfn-python-lintのご紹介

github.com

• GitHubで公開されている3rd Party製の構文チェックツールです。
• AWSのブログでも紹介されています。
  cfn-lint を使った AWS CloudFormation テンプレートの Git pre-commit バリデーション | Amazon Web Services ブログ
• Python(Python 2.7+ and 3.5+ are supported.)で動ています。
• 多様なIDEにプラグインとして組み込めます。組み込むことで、クイズとして紹介した様な不備は、書いているそばから自動で検出してくれます。紹介した不備以外にも、"パラメータとして定義したが使用されていない変数"等、人の目では気が付きにくい沢山の不備を自動で検出してくれます。
  • Atom
  • Emacs
  • NeoVim 0.2.0+/Vim 8
    • ALE
    • Coc
    • Syntastic
  • Sublime
  • Visual Studio Code
  • IntelliJ IDEA

Linterが何に基づき構文チェックを行っているか

AWSが公開しているCloudFormationリソース仕様に基づいてチェックしてくれます。 引用：AWS CloudFormation リソース仕様 - AWS CloudFormation

チェック方法

コマンドプロンプトでの使い方

公式ページに従って、Python,Pip,cfn-lintをインストールしてください。 後は以下のように簡単に使用可能です。

 >cfn-lint {ファイルパス}

Visual Studio Codeでの使い方

先にコマンドプロンプトで使える状態にした上で、yml用、cfn-python-lint用、CloudFormation用のExtensionsをインストールしてください。

Name: YAML
Id: redhat.vscode-yaml
Description: YAML Language Support by Red Hat, with built-in Kubernetes syntax support
Version: 1.4.0
Publisher: Red Hat
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=redhat.vscode-yaml

Name: CloudFormation
Id: aws-scripting-guy.cform
Description: VS Code Plugin for CloudFormation
Version: 0.0.24
Publisher: aws-scripting-guy
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=aws-scripting-guy.cform

Name: CloudFormation Linter
Id: kddejong.vscode-cfn-lint
Description: AWS CloudFormation template Linter
Version: 0.21.0
Publisher: kddejong
VS Marketplace Link: https://marketplace.visualstudio.com/items?itemName=kddejong.vscode-cfn-lint

まとめ

• CloudFormationの構文チェックをLinterを使って効率化する方法を紹介しました。強力な構文チェックツールなので、 CloudFormationを使う案件は利用することを強く推奨します。
• Linterで検出される不備の中には、CloudFormationスタック作成時の構文チェックをスルーするものが多数あります(変数の型の誤り等)が、それはAWSがうまく解釈してくれているだけだと私は理解しています。ある日突然構文チェックが厳しくなる可能性も無いとは言えないので、構文はまもりましょう。(バージョンアップに伴って構文の型チェックが厳密になって動かなくなった・・・とか悲惨です。)
• Githubを見ると、terraform用、Python用など、多様なLinterが存在しているので、何かいいものがあったらみんなで共有しましょう。

Tips

• cfn-python-lintは全角文字があると動きません。使う場合はコメントはすべて英語で記載する必要があります。

• 無視したいチェック項目は無視できます。

  • コマンドプロンプトの場合

    >cfn-lint {パス} --ignore-checks {エラーコード1},{エラーコード2},・・・
    

  • VS Codeの場合

【AWS】今年度学習したAWSサービスの特徴をまとめておく - AWS analytics services編

概要

インフラ系のクラウドエンジニアとして、日々自己研鑽に努めています。 本投稿は今年度の学習のまとめとして、今後も覚えておきたい情報を記載したものです。 AWS analytics servicesに含まれるサービスについて、要件に適したサービスや、調査・検証が必要な内容をすぐに探し出せるようになることを主な目的に、各サービスと関連技術の特徴と効果的に活用するためのTipsを記載しています。

記載内容は、AWS公式ドキュメントやインターネットから拾い集めた情報を個人的に解釈した結果を記載しています。実機確認等による裏付けがされた内容ではない点、ご留意ください。

Analytics

Athena

• Prestoベースのクエリサービス。S3へのクエリ実行可能(Glacierはサポートしない)。
• CSV,JSON,カラムナフォーマットであるParquet,ORCが利用可能

• パフォーマンス向上のコツ

  1. パーティション分割：各クエリがスキャンするデータ量が制限され、パフォーマンス向上とコスト削減が期待できる。パーティション追加後は、カタログ内のメタデータ更新が必要（Hive互換の場合：MSCK REPAIR TABLEコマンド、Hive互換ではない場合：ALTER TABLE ADD PARTITIONコマンド）
  2. カラムナフォーマット(Parquet)を使用。コスト削減効果も。
  3. ファイルを圧縮する。(S3からのロードが早くなる) ※その他詳細はリンク先参照Amazon Athena のパフォーマンスチューニング Tips トップ 10 | Amazon Web Services ブログ

• Workgroupsを使用することで、クエリ結果の分離(他のグループに参照させない)、格納先S3の分離、グループ毎に異なるコスト制約（クエリ毎にスキャン可能なデータ量、またはWG毎に一定期間の間スキャン可能なデータ量）を設けることが可能。Workgroupsのアクセス制限はIAMで行う。

• Redshiftへのクエリ発行も可能。Athena(ペタバイト単位)とRedshift spectrum(エクサバイト単位)を比較する際、パフォーマンスを重視する場合はRedshift spectrumが優れている。(★Redshiftとの使い分けのポイント)
• 失敗したクエリに対しては課金されない。
• テーブル定義としてGlue データカタログを使用している。そのため、Glue分の料金が発生。

EMR

• Hadoopエコシステムの集合体。分散処理・分析を行う。
  • Ambari:オーケストレーション
  • Presto：分散型SQL
  • Hue：GUI
  • Ganglia：モニタリング
  • Hive：分散処理。性能はHive>Pig。
  • Pig:分散処理。性能はHive>Pig。
  • Ranger:データに対するきめ細やかなアクセス制御
• インスタンスフリート：ターゲット容量を指定する。EMRは事前設定されたターゲット容量を満たすようオンデマンドorスポットインスタンスをプロビジョニングする。Provisioning timeoutの設定では、指定時間以内にスポットインスタンスをプロビジョニングできない場合。クラスターを終了させるアクションまたはオンデマンドインスタンスで容量を補うというアクションを設定可能。スポットインスタンス終了等に伴うデータ破損を防ぎたい場合は、EMRFS(S3)にデータを格納する。
• クラスタノードにSSHアクセス可能。
• 二種類のオートスケーリングがある。
  • EMR managed scaling：主要なメトリクスをモニタリングするマネージドなアルゴリズムにオートスケール。
  • AutoScaling：カスタムメトリクスを使用し、利用者が設定。
• EMR on EC2はマルチAZ非対応。EMR on EKSはマルチAZをサポート。
• Spark DataFrame:PySparkのクラスで、高いパフォーマンスを実現可能なデータ構造
• PrestoやSparkではS3 Select Pushdownを利用することで、EMRとS3間のデータ転送を削減し、パフォーマンスが向上する(効果の有無はクエリの特性に依存するため、使用有無は公式ドキュメントのガイドを参考にすること)。
• Rangerを使用することにより、行レベルのアクセス制御が可能(★アクセス制御の単位は他のサービスとの使い分けのポイント)。
• DataSyncにより、S3,EFS,FSx for Windows File ServerとHDFS間のデータ転送が可能。
• 一定期間idle状態だった場合、自動終了するポリシーの設定が可能(以前はidleメトリクスを監視し、CloudWatchアラーム,SNS,Lambdaと連携するといった仕組みの構築が必要だった。)。
• EMR notebookはGithub,Codecommit,GitBucketと統合している。
• EMRクラスタを削除した場合、EBSも削除される。データ永続化にはS3を使うこと。
• EMRマスターインスタンス、コアインスタンス、タスクインスタンスには異なるマネージドセキュリティグループが関連付けられている。
• EMRのファイルシステム
  • HDFS:高速だがエフェメラル。ジョブのキャッシュが主な用途。
  • EMRFS：S3上のファイルを直接読み書き。永続化が必要なデータに使用する。
  • ローカルファイルシステム：EC2のインスタンスストア。一時ファイルに使用する。
• EMRのインスタンスストアとEBSはLinux Unified Key Setup (LUKS)による暗号化が可能。ネイティブなEBS暗号化もサポート。
• S3DistCp(OSSツール)：S3→HDFSに効率的(圧縮して)にデータをコピー。
• EMRFSの暗号化

  Amazon S3 暗号化は、Amazon S3 との間で読み書きされた EMR ファイルシステム (EMRFS) オブジェクトで使用できます。Amazon S3 サーバー側での暗号化 (SSE) またはクライアント側の暗号化 (CSE) をデフォルトの暗号化モード保管時の暗号化を有効にする場合。オプションで、[Per bucket encryption overrides (バケットごとの暗号化オーバーライド)] を使用して、バケットごとに異なる暗号化方法を指定できます。Amazon S3 暗号化が有効であるかどうかにかかわらず、Transport Layer Security (TLS) は、EMR クラスターノードと Amazon S3 間で伝送中の EMRFS オブジェクトを暗号化します。 引用：暗号化オプション - Amazon EMR

Redshift

• PostgreSQL互換(PSQL等も使用可能)。DWHにクエリ機能も付いているイメージ。
• 3つのインスタンスタイプがある。
  • 高密度コンピューティング DC2
  • 高密度ストレージ DS2
  • Redshift マネージドストレージを備えた RA3
• マルチAZ非対応。大規模障害対策にはクロスリージョンスナップショットを使う。
• ディメンジョンテーブル：マスタデータ/ファクトテーブル：動的データ
• データベース接続とユーザーアクティビティ情報を監査ログとして記録可能。保存先はS3。
• KMSと統合されているが、KMSでキーを管理せず、AWS CloudHSM または on-premises HSMで直接キーを管理することも可能。
• 複数セッションやユーザが同時にクエリを実行している際、相互に影響を受けないようワークロード管理(WLM)を使ってキューを分けることが可能。自動WLMと手動WLMとがあるが、自動WLMは一貫した高速のクエリパフォーマンスで、事実上無制限の同時ユーザーと同時クエリをサポートするとのこと。
• クラスターのサイズ変更
  • Elastic resize：既存クラスターにノード追加またはノード変更。10～15分で完了。リサイズ中クラスターは読み取り専用。
  • Classic resize：新しいクラスタを作成し、元のクラスターからデータをコピー。データ量によって数時間から数日要する。リサイズ中クラスターは読み取り専用。
• MATERIALIZED VIEWを使用することで、コスト削減(クエリ処理の削減)が可能なケースがある。VIEWのデータを更新するにはREFRESH MATERIALIZED VIEWを実行する(dead tuplesを削除するためにさらにVACUUMをしたほうが良い。)。
• 1 つ以上の列をソートキーとして定義可能（複合ソートキーとインターリーブソートキー）。インターリーブソートキーは複合ソートキーに比べて大幅なパフォーマンス向上が見込める。ただし、ID 列,日付,タイムスタンプなど、一定間隔で増加する属性を持つ列でのインターリーブソートキーの使用は非推奨。
• パフォーマンスのため、カーディナリティは低く保ったほうが良い。
• Athena(ペタバイト単位)とRedshift spectrum(エクサバイト単位)を比較する際、パフォーマンスを重視する場合はRedshift spectrumが優れている。(★Redshiftとの使い分けのポイント)
• Redshift spectrumはRedshiftテーブルにデータをロードすることなく、クラスターに依存しない専用のAmazon Redshiftサーバー上でクエリ実行するため、Redshiftクラスターにほとんど負荷がかからない。
• S3→Lambda(トラック管理はDynamoDB)→RedshiftのData転送アーキテクチャが公開されている。
• 以前はRSをVPCに配置してもS3などのサービスに対してはIGW経由での通信が必要だったが、拡張ルーティング機能によりVPCのルーティングテーブルに従ってルーティング可能になった。
• DBlinkを使ってPosrgreSQLと統合可能(PostgreSQLからRSに対してSQL実行可能)。
• データをロードするためのベストプラクティス(データをロードするための Amazon Redshift のベストプラクティス - Amazon Redshift) 例：単一の COPY コマンドを使用した複数のファイルからのロード

  Amazon Redshift は、複数の圧縮データファイルからの並列的なデータロードを、自動的に実行します。ただし、複数の COPY コマンドを同時に使用して複数のファイルから 1 つのテーブルにデータをロードする場合には、Amazon Redshift はそれらの読み込みを直列的に実行します。この種類のロードはかなり低速で、テーブルにソート列が定義されている場合は、最後に VACUUM プロセスが必要になります。引用：単一の COPY コマンドを使用した複数のファイルからのロード - Amazon Redshift

Kinesis Data Analytics

• Apache Flinkベースのリアルタイム分析サービス。
• KDSとKDFを流れるデータに対してSQLベースのクエリが発行可能。クエリ結果はKDSやLambdaに転送。
• 処理できないレコードはエラーストリームに転送することで後から解析可能。
• マシンラーニング(Random Cut Forest)による異常検知が可能。
• 1KPU=4GBメモリ。8KPUが上限。
• ウィンドウクエリ

  • Stagger Windows: データが届くと開く、キー付けされた時間ベースのウィンドウを使用してデータを集計するクエリ。キーによって、複数の重なり合うウィンドウが可能になります。タンブリングウィンドウと比較すると、Stagger Windows は遅延データまたは順序通りでないデータを削減するため、これは、時間ベースのウィンドウを使用してデータを集約する方法として推奨されます。
  • タンブリングウィンドウ: 定期的に開閉する、個別の時間ベースのウィンドウを使用してデータを集計するクエリ。
  • スライディングウィンドウ: 固定時間または rowcount 間隔を使用して、データを継続的に集計するクエリ。引用：ウィンドウクエリ - Amazon Kinesis Data Analytics for SQL Applications 開発者ガイド

• ETL処理も可能。
  例: 複数のデータ型の変換 - Amazon Kinesis Data Analytics for SQL Applications 開発者ガイド

Elasticsearch Service（OpenSearch）

• OSSのElasticsearchベースのサービス。(Close APIは使用不可)
• 3つのAZを使用したマルチAZモードでの起動が推奨構成。以下はESのクラスタの構造。
  • マスターノード：3つ。1つのマスターと2つのスレーブ
  • データノード：3つ。各々のノード内部に複数のシャードを持つ。プライマリシャードは一つ。2つはレプリカシャード。
• クラスタのことをドメインと呼ぶ。複数のドメイン横断のクエリを実行可能(これはOSS版のESにはできないAWS版ESだけの独自機能)。
• ドメインの作成時にパブリックドメイン or VPCドメインを選ぶ。
  • パブリックドメイン：パブリックにアクセス可能。
  • VPCドメイン：プライベートサブネット内にENIを作成し、それを経由することで他のAWSサービスとプライベートな通信が可能。
• 標準では各ノードのインスタンスストアまたはEBSにデータを格納するが、高いパフォーマンスが必要ないデータについてはUltraWarmストレージ(S3)を使用可能。
• ドメインに含まれるインスタンスタイプやボリュームサイズ等の変更を行った場合、内部的にBlue/Greenデプロイが行われる。
• Kinesis Data Firehose(KDF)の出力先に指定可能。
• CloudWatchLogsからのデータ取り込みはLambda等を経由する必要がある。
• Kibanaダッシュボードはリフレッシュレートの設定により、定は的(15分毎,7日毎等)に更新が可能(★Quicksightとの使い分けのポイントの一つ)。
• Kibanaのログイン認証にCognitoを使用可能。
• リソースベースIAMをサポート。それとは別にKibanaの権限管理機能も利用可(作成時に有効化する必要がある)。
• 自動BackupはS3に格納される。自動バックアップからは新しいESドメインの作成は不可。バックアップから新しいESドメインを作成したい場合は手動Snapshotを使用する必要がある。

Quicksight(QS)

• データの可視化サービス。様々なグラフが予め用意されている。データに対して適切なグラフが不明な場合、AutoGraph機能を使うと、QSが自動判定してくれる。(Excelのグラフ機能をリッチにしたイメージ)
• データを更新した際、接続プロパティとデータの格納場所に応じて処理が異なる。QSがダイレクトクエリを使用してデータに接続する場合、ダッシュボードを開くたびに自動更新される。ダイレクトクエリの代わりに、SPICE(インメモリデータストア)にデータをインポートすることも可能。SPICEのデータは定期更新可能(毎時(Enterpriseのみ),日次,週次,月次)(★Kibanaとの使い分けのポイントの一つ)。
• 主なデータソース：リレーショナルデータ(Athena,S3,Redshift,PostgreSQL,等)やファイル(CSV,TSV,ELF,CLF,JSON,Excel)やSaaS(ServiceNow等)など多様。※DynamoDBやGlueデータカタログは公式ドキュメント上データソースとして記載なし。
• Standard EditionとEnterprise Editionがある。Enterpriseの特徴は以下の通り。
  • データセットの行レベルでのアクセス制御が可能(★アクセス制御の単位は他のサービスとの使い分けのポイント)。
  • 1時間毎のSPICEの定期更新が可能
• プライベートサブネット内にENIを作成し、それを経由することで他のAWSサービスとプライベートな通信が可能。QS用セキュリティグループという特殊なSGを介して通信を制御する。
• マシンラーニング(Random Cut Forest)による異常検知が可能。

Data movement

Glue

• Apache SparkベースのETLサービス。
• PythonとScalaに対応している。既存のコードをS3に格納し、呼び出すことも可能。
• AWS GlueクローラとジョブはCron式(最短5分)で定期的なスケジュールで実行可能(複数ジョブ同時実行可)。これにより、カタログを最新の状態に保つことができる。
• DynamoDBからデータのロードが可能(DynamoDBへのunloadは不可)。

• S3から小さなファイルを大量に読み込む際、groupFilesの設定を有効にし(さらにまとめて読み込むサイズを指定し)、まとめて読み込むと効果的。ただし、入力ファイル数が50,000を超える場合には自動的に有効になる。また、以下の点に注意。

  groupFiles は、csv、Ion、grokLog、json、および xml のデータ形式から作成された DynamicFrames でサポートされています。このオプションは、avro、parquet、orc ではサポートされていません。 引用：大きなグループの入力ファイルの読み取り - AWS Glue

• DynamicFrames:AWSによるPySparkの拡張の一つ。Spark DataFrameに似ており、高いパフォーマンスを実現可能なデータ構造

• リソースベースポリシーをサポート。アクセス制御の単位はデータカタログのARN粒度に依存すると思われる。(★アクセス制御の単位は他のサービスとの使い分けのポイント)。
• AWS Glue Schema Registryにより、スキーマ(データレコードの構造と形式)のバージョン管理が可能。現状JSONとApache Avro形式をサポート。Kinesis Data Streams(KPL,KCL)やMSKとも統合している。
• DataBrew：コードを書くことなくデータのクリーニングや正規化が可能な視覚的なツール。クレジットカードの番号を下４桁にするといった機密情報を削除する処理も可能。

Managed Streaming for Apache Kafka (MSK)

• Apache Kafka ACLでアクセス制限が可能。MSKにPush可能なProducerの制限等に利用可。
• 容量管理やスケーリングの管理をしたくない場合、MSK Serverlessを使用可能。ただし、クォータの制限が多い点に注意。例：最大メッセージサイズ8MB(★メッセージサイズの上限は、SQSやKinesisとの使い分けのポイントの一つ)ServerlessではないMSKのメッセージサイズに関する記載はAWS公式ドキュメント上見当たらなかった。
• ストレージのAuto Scalingが可能
• コンポーネント

  • ブローカーノード— Amazon MSK クラスターの作成時に、Amazon MSK が各アベイラビリティーゾーンに作成するブローカーノードの数を指定します。この図に示すクラスターの例では、アベイラビリティーゾーンごとに 1 つのブローカーがあります。各アベイラビリティーゾーンには、独自の仮想プライベートクラウド (VPC) サブネットがあります。
  • ZooKeeper ノード— Amazon MSK は、Apache ZooKeeper ノードも作成します。Apache ZooKeeper は、信頼性の高い分散調整を可能にするオープンソースのサーバーです。
  • プロデューサー、消費者、トピック作成者— Amazon MSK では、トピックの作成し、データの生成および消費のために、Apache Kafka データプレーンオペレーションを使用できます。
  • クラスターオペレーション♪AWS Management Consoleとすると、AWS Command Line Interface(AWS CLI) または SDK の API を使用してコントロールプレーンオペレーションを実行します。たとえば、Amazon MSK クラスターの作成または削除し、アカウント内のすべてのクラスターを一覧表示し、クラスターのプロパティの表示、クラスター内のブローカーの数とタイプの更新を行うことができます。 引用：アマゾンMSKって何ですか - Amazon Managed Streaming for Apache Kafka

Kinesis Data Streams(KDS)

• リアルタイムにデータを転送。プログラム間(KPL/Kinesis Agent→KCL,Lambda等)へデータ転送するイメージ。Sparkからの読み書きも可能。AutoScaling機能はない。(★KDFとの使い分けのポイント)
• プロデューサ：Kinesis Producer Library,Kinesis Agent。Agentは1MB/sまたは1000回/s転送可、KPLはパフォーマンスが高い。KPLに圧縮機能はない。
• コンシューマ：Kinesis Client Library(純正),Kinesis Connector Library(3rdParty製)
• ポーリング間隔の推奨は各シャード毎に1秒に一回。
  Kinesis Client Libraryのデフォルトもそれに従っているが、idleTimeBetweenReadsInMillisでチューニング可能。
• APIの上限とペイロード毎の制限は分けて考える。例：GetRecordsのAPIコールの上限は5TPSで、呼び出し毎に最大10,000レコードまたは最大10 MB返却可能。※上限を超えるAPIコールはスルーされる。
• レコードサイズは最大1000KB(★メッセージサイズの上限は、SQSやMSKとの使い分けのポイントの一つ)。
• 拡張ファンアウト：コンシューマが1シャードを占有し、最大で2MB/sの送信が可能。これにより、コンシューマに対して70ms以内の配信が可能となる。
• サーバーサイド暗号化：KMSの"CMK"を使用して自動的にデータを暗号化。
• Glueと統合されている。

Kinesis Data Firehose(KDF)

• ニアリアルタイムにデータを転送(最短60s)。サービス間(S3,cloudwatch,Redshift,ES,splunk等)でデータ転送するイメージ。Sparkからの読み書きは不可。AutoScaling機能がある。(★KDSとの使い分けのポイント)
• KDFにデータを追加する方法は、Kinesis AgentとAPIの二種類ある。さらに、APIにはPutRecord(1API毎に1レコード)とPutRecordBatch(1APIで複数レコード)がある。Kinesis AgentはOS上のログやイベントをKDS,KDF,CloudWatch,CloudWatchLogsへ転送する(リトライ機構も具備)。
• レコードサイズは最大1000KB(★メッセージサイズの上限は、SQSやMSKとの使い分けのポイントの一つ)。

Data lake

S3

• Strong Consistencyがサポートされている(以前は結果整合性だった)。
• ライフサイクルは、同一バケット内でストレージクラスを変更する機能
• ファイルの整合性確認にETag値を使用可能
• レプリケーション時、フィルター設定で対象を選択可能。
• パフォーマンス向上のポイントはプレフィックスの構造。

  Amazon S3 バケットのプレフィックスごとに 1 秒あたり 3,500 の PUT/COPY/POST/DELETE リクエスト、または 5,500 の GET/HEAD リクエストを送信することができます。バケット内で持つことができるプレフィックスの数に制限はありません。引用：Amazon S3 バケットのスロットリングを解決する

Predictive analytics and machine learning

Machine Learning

• コーディングなしでMLを利用可能(★SageMakerとの使い分けのポイント)
• トレーニングデータのデフォルトの上限は100GB(サポートリクエストで調整可能)(★SageMakerとの使い分けのポイント)
• MLタイプは三つ。
  • バイナリ：二者択一。例：ネコか？犬か？
  • マルチクラス：複数選択。例：ネコ？トラ？ライオン？
  • 回帰：将来予測。

SageMaker

• トレーニングデータに特に上限はない。(★MLとの使い分けのポイント)
• SageMaker NEO：特定デバイスに最適化(高速化)するようモデルをコンパイル。

Othres

Lambda

• vCPUの上限は6/メモリの上限は10GB
• RedshiftへのクエリはData APIを使用
• 最長15分でタイムアウト

Simple Queue Service

• 最大メッセージサイズは256KB。Amazon SQS Extended Client Library for Javaにより、ペイロードをS3から参照することが可能で、最大2GBのメッセージに拡張可能(★メッセージサイズの上限は、MSKやKinesisとの使い分けのポイントの一つ)。

DataSync

• DataSync Agentを介して、on premisesからS3やEFSにデータを移行可能。データ転送中はTLS1.2により暗号化され、データ整合性チェックも実施される。
• S3,EFS,FSx for Windows File ServerとHDFS間のデータ転送が可能。

Database Migration Service

• DBのデータ移行に使用するサービス
• SSL/TLSで通信は暗号化

DynamoDB

• プライマリーキーのタイプは二つ。パーティションキー単一で構成するタイプと、パーティションキーとソートキーの複合キーとするタイプ。
• 1レコード400KBまで。
• RCU：最大4KBの項目の読み込みについて、強い整合性の場合は1回/s、結果整合性の場合は2回/sの可能。※割り切れない数に注意。5KBの項目は強い整合性で2RCU,結果整合性で1RCU必要。5KBのファイルが4つ、合計20KBの場合は強い整合性で8RCU,結果整合性で4RCU。
• WCU:最大1KBの書き込みについて、1回/s可能。
• IAM認証可能。
• DynamoDBは暗号化可能(DynamoDB Streamsも含めて)。

Key Management Service (KMS)

• KMSのAPIで暗号化可能なデータサイズは4MBまで。
• エンベロープ暗号化：プレーンテキストとデータキーを別のキーで暗号化する機能。

一般的なETLのナレッジ

• ETLでは、ターゲットテーブルを変更 (更新、挿入含む) する前に、ステージングテーブルにデータを一時的に保持するということが行われる。GlueやRedshiftのAWS公式ドキュメントにもその手法に関について記載されている。