※最小構成（コスト的に）で構築する手順を書いていますが、注意が必要なので前置きが長いです。まずは作ってから考えたい人はスクロールして前置きを読み飛ばしてください
※構造を理解するために書いたものです。一部予想図で書いています
※Elasticsearchの具体的な操作方法は知りません。環境構築するためのお話です
Amazon Elasticsearch Service（AmazonES）の位置づけ
Elasticsearch は、Elastic社が中心となって開発しているオープンソース製品名。
AmazonESは、このオープンソースをSaaSとして利用できるようにしたもの。
AWSの他のサービスと比べて、癖が強い感じがするので、癖の部分を”ポイント”としてまとめますた。
そのうえで、最小構成でAmazonESドメインを構築する手順を記載します。
ポイント１：通信経路について
管理コンソールのドメイン作成ウィザードで、以下の選択があります。
”VPCアクセス”とは、自分が作成したVPC内にインスタンスが作成されるわけではなく、VPCピアリングによって、Saas環境とプライベートIPで接続できる。という意味っぽい。
見えないところに↓のような環境が構築されるのだと思われる（あくまでも予想図）
※VPCアクセスで設定したときは、自AWSアカウント側にはプライベートIPをもつネットワークインターフェイスのみができている。VPCエンドポイントオブジェクトはできていない（隠している？？（陰謀論））
ポイント２：ツールごとの操作範疇
CloudFormation / AWSCLI / AWSSDK は、AmazonESドメイン構築等、環境に関する部分のみ操作できる
Elasticsearch本体に対してのデータ操作関連は、HTTPSで行う。ポイント１の通信経路を経由して利用できるということになる。
なお、REST APIを使う場合は
接続先ホストは、”エンドポイント”
利用可能なAPIは Open Distro for Elasticsearchを使う事になる（多分、本家Elasticsearch APIからの派生したもの）
ポイント３：インスタンスタイプと機能制限
サポートされるインスタンスタイプ
とりあえずお試しで使ってみたくて、インスタンスタイプを最弱である t2.small.elasticsearch を 選択した場合は、「きめ細かい」と言われるアクセス方法が使えないので注意
Kibanaで使える機能も変わってくる様子
| きめ細かい無 | きめ細かい有 |
|---|---|
 |
 |
ポイント４：アクセス権限について
AmazonESドメインに対するアクセス制限は、以下のように３段階で考えるのが吉
（まくまでも予想図です）
- 通信経路による制限 → VPCの中・外の２択。
- 利用許可制限 → Elasticsearch側で許可するユーザ・ロール・IPアドレスが指定できる
- きめ細やかな設定 → Kibanaにより指定可能
1.通信経路
ポイント１の通り
VPC経由の方が安全ですわな
2.利用許可
IAMでポリシーを決定する必要はない
ポイント２の通り、環境構築の場合はAWS側で。データ操作はElasticsearchで。という分類となる。
つまり、データ操作を行う場合は、IAMでポリシーを設定する必要はない。（というかできない）
Elasticsearchにとっては、”誰が（IAMuser）・何か(IAMrole)”が判ればよい程度となる。
Elasticsearch側の認可（利用許可）
ここ
・誰、もしくはどのリソースからのアクセスを許可するか→IAMリソースのARNによって指定
・どこからのアクセスを許可するか→IPアドレスで指定
・誰なら何が使えるとかも設定可能
ドメイン新規作成時の「アクセスポリシー」か、ドメイン作成後の「アクセスポリシーの変更」で設定できる
3.きめ細かな
ここに記載されている通り、要するにKibana内でARNごとに、具体的な操作まで指定できる。
Role MappingsにIAM User・RoleのARNを指定する事で接続許可される。
ここから先は、Kibana側の範疇になるので略
最小構成でのドメイン作成
ゴール：最小構成（コストが安い。という意味で）ドメインを作成し、自分のPCからKibanaが操作できること。
Step 1
デプロイタイプ：開発およびテスト
Step 2
ドメイン名とインスタンスタイプを指定します。
ドメイン名は適当に。インスタンスタイプは最安のt2.small.elasticsearch
以下、デフォルト
Step 3
パブリックアクセスを指定します。インターネット経由でElasticsearchとKibanaにアクセスするという意味です。
インターネット経由なので、何らかの制限をしておく必要があります→ドメインアクセスポリシーで縛ります
（ちなみにVPC内からアクセスできるのなら、ドメインアクセスポリシー設定は不要です。この例では”自分のPCでアクセスできること”をゴールとしているので。。）
t系のインスタンスタイプだと、「細かい…」が有効化できないので、ドメインアクセスポリシーで個別指定します。
ドメインアクセスポリシーで、アクセス許可するIPアドレスを指定します。
例として、192.168.100.100/32としていますが、グローバルIPを指定しないといけないです。
もしくは、JSONで定義できるのなら、ここを参考に設定します。
完成後
管理コンソールに、出力されている Kibana のURLにブラウザでアクセスしてみます。
Kibanaのログイン画面なしで、直接ログイン後画面になります。（IPアドレスでしか制限していないからですね）（怖）
試していないが、RESTAPIもパスワード無でいけてしまう気がする。。
接続できない場合は、ドメインアクセスポリシーで設定したIPアドレスが間違っているとか。
まとめ
という事で、最小構成だとセキュリティ面がかなり心配。少なくともKibanaログインにユーザアカウントくらいは使いたい。
となるので、
t2.small.elasticsearchを使ってテストする場合は、あくまでも機能面の調査となると思われます。