AWSをいじり倒す（12.Amazon Lightsail)

今回は勉強ではなく、仕事でLightsailを使ってredmineサーバを建てることになったのでついでに記事化

そもそもLightsailとは何か

Amazon Lightsailとは？EC2との違いとメリット・デメリットを調べてみた | NHN テコラス Tech Blog | AWS、機械学習、IoTなどの技術ブログ

簡単に言うとAWSのパッケージ商品。

何も考えなくてもちゃんとした構成で用意してくれる。

何だかえらいポップな画面からスタート。

ロケーションの選択。国旗まで出しちゃってまあ。

明らかに他のサービスとは異質w

プラットフォームの選択

Windowsだとできることは現時点でほとんどなく、

Linux/Unixが主流のようだ

どのアプリ入れますか

複数選択はできない。今回はRedmine

キーペアの設定

デフォルトだと、キーの名前を自動生成してくれるみたい。

デフォルトキーを手元にダウンロードしておく。

スナップショットは・・・うーんいるようないらんような

月額$0.05/GBで、２回目以降は増分のみとのことなのでとりあえず有効化。

お値段。月額$3.5は安い。

派手な使い方しないしこれでよさそう。後から増築もできるし。

リソース名の設定とか、インスタンス数の指定とか。

このキータグはLightsailのリソースの中だけで使うものみたいだ。

用途は普通に管理のため。

Amazon Lightsail のタグ | Lightsail ドキュメント

でもわざわざキーオンリータグを準備した意味がわからん。キー値タグでいいやん

せっかくなのでつけてみた。

作成ボタンポチー

こんばんは！

過剰にユーザフレンドリー感だしてるなぁ。

AWSとっつきにくい人向けなのかね。

ほどなくしてできた。

独自のSSHクライアントも提供してくれているみたいだが、

IPとユーザ名と、先ほどダウンロードしたキーがあるので

EC2にアクセスするのと同じ要領でSSHで接続。

つながった

そしてこの黒塗りのところにブラウザからのログインパスワードが書いてある

パブリックIPをブラウザに放り込むと

無事表示された。

仕上げの設定。

IPアドレスの固定化。無料だから必ずやろう。

ネットワーキングから静的IPの作成

ロケーションは東京、インスタンスは先ほど作ったものを指定

静的IPの指定で一意な名前をつける

アタッチしている間は無料ですよ、と。

ちなみにアタッチしないと$0.005/h取られる模様。無駄に確保すんなってことね

作成を押すと静的IPが取得できた。アタッチもそのまましてくれたっぽい

早速このIPアドレスでRedmineにログインできることが確認できた。

DNSの設定も行えるらしい。

静的IPを設定した後、新たなメニューが増えている

が、今回はLBも使わないので

ドメイン取得した場所で今取った静的IPアドレスを登録して

名前解決してやれば事足りてしまった。

ということで今回はAWSの設定見送り。

月額$3.5、遊びでポイポイたてるにはちと高いが、

ちゃんと使う目的で建てるなら安いし、何よりラクチンだ。

後日、HTTPS化を行った。

やり方は複数あるみたいで、

lightsailで立てたredmineをHTTPS化する手順を書いたサイトを探したが、

certbot-autoを入れるやり方はredmine 404 errorとでてうまくいかん。

結局、lego clientを使うこれでうまくいった。

Generate and Install a Let's Encrypt SSL Certificate for a Bitnami Application

lightsail環境だとApacheが動いているみたいなのでApacheの場合を選んでいけばOK。

bitnami公式ドキュメントだから手順も安心

このサイトにたどり着くまでに３時間、たどり着いてからは１０分でできた。。。

進捗

AWSをいじり倒す(11.リソースグループ)

組織アカウントを使っている関係で、人目に付かないところでテストを行おうと思ってオハイオリージョンで作業をしていたのだが、リソースグループ機能使えば同一リージョンでも見えなくできるのでは？という話がでたので試してみる。（Azureのリソースグループ機能ならそういうことができるらしい。）

ちなみに先に結論を書いておくと、残念ながら見えなくすることはできないみたいだ。

AWSマネジメントコンソールにおいて、IAMユーザごとに参照(表示)できるEC2インスタンスを制御したい - Qiita

ここに書いてあるように、人目から隠すなら（今の自分の環境では）リージョンを変えるのが最良。

ただ、色々触っているせいでサービスが乱立しているのは間違い無いので、

管理のためにリソースグループを使ってみる。

AWS リソースグループ とは? - AWS リソースグループ

手順はこちらを参考に

[AWS]リソースグループを使って、テスト・ステージング・本番環境ごとにAWSリソースを管理する | Developers.IO

ここから設定開始

グループの作成

リソースタイプは全て、でいいとして

タグ・・・

ああ〜〜こうなるのかー。今まで適当につけてきたツケがw

統一しとけばよかった

タグもNameじゃなくて、リソースグループ用のタグを１個作った方がよさそう

そんなあなたにタグエディター。タグをまとめて変更できる便利な機能。

条件を指定して検索し、出てきたリソースを選んで、タグを管理するボタンを押す

Nameは個を識別するために残しておきたいので、

envというタグを作り（何でもいいが参考にしていた記事がenvとつけたので真似した）

今回の作業に関するもの全てにproject-testとつけることにした

こんな感じでまとめて設定される

この調子で今まで作ってきたリソースにポチポチとenvタグをつけていく

改めてリソースグループ作成画面に戻って、

env project-testを指定

一つのタグでずらずらでるようになった。

グループ名と、このグループそのものにつけるタグの設定。

できた。

使い方。

色々探したが、下図のような参考記事にある超便利そうな画面が出したいのに見当たらない・・・。なんで？

リソースグループの画面から、まとめあげた各リソースにアクセスできるのは確認。

便利かもしれないがレイアウトが不満だなぁ。

また、タグを使って絞り込むことは可能だけど

あくまでただのタグによる絞り込みなので、リソースグループの便利さってわけではない。

では、どんな時にリソースグループを使えばいいのか。

複数人で管理する時に、作った本人はどんなサービス使ってるかだいたい把握しているけど別の人がみる場合はどこで何使っているのかわからないので、リソースグループとしてまとまってみれたほうがありがたい、とか。

また、リソースグループをRun Commandの対象にできるらしいので、これを使う場合は便利かも。

Run Commandのターゲットとしてリソースグループが選択可能になりました | Developers.IO

ということでリソースグループそれ自体はふーんという感じだが

タグは個を識別するNameと、グループを識別するenvの２つつけていきましょうってのが今回の学び。

AWSをいじり倒す(10.Route53)

もっと早くにやれば良かったと思いつつ、DNSサービスたるRoute53を触ってみる。

具体的には、

Route53 でDNSフェイルオーバーを設定する。 - Qiita

を参考にして、DNSフェイルオーバーを使ったsorryページ表示を試してみることにする

ELBは対象をEC2にしかできない（その分ヘルスチェックをきめ細やかに設定できる）がDNSフェイルオーバーはEC2、S3、ELBを対象にできる。

また、S3で簡易なHP(sorryページ用）を作れるというのも面白い点だ

まずは思い出しながらELB環境を作成。

ELBからは(無駄に)AutoScailingで作成した２台のEC2がぶら下がっており、

そのどちらでもWebサーバが立っている状態。

次にS3にsorryページを作ってみる。

ちなみに、バケット名はドメイン名と同一にしなければならないという注意書きがあるのだが、この時点ではその意味がよく理解できていないので名前は後で変更する。

（変更というか、削除して作り直す）

Static website hositingから

ウェブサイトをホストしますを選択し

インデックスドキュメントの名前(index.html)を書いて、保存。

せっかくなのでAWS CLIを使って、index.htmlを送り込むことにする

適当なEC2上で20年前ぐらいに覚えた化石htmlでindex.htmlを作成し、保存

アップロード実行

この状態で直接アクセスしてみたらどうなるのか試してみたら

AccessDenied。S3のパブリックアクセスの設定してないせいだとおもう。

こいつのチェックを外して再トライしてみる

・・・だめですね。

index.htmlの権限を確認してみる。アクセス権限のところをクリック。

出てきた画面

ここのパブリックアクセスの許可っぽいな〜〜

読み取り許可を出して保存。

リトライ結果やいかに

でた！

静的なHPであればもうこれでいいんじゃ無いのってぐらい簡単だ。

まあでもS3ってダウンロード量に応じてお金がかかるから、アクセスされればされるほどお金取られることになる。そう思うと動画コンテンツとかうかうか載せてらんないし、sorryページ利用ぐらいがちょうどいいのかもしれん。

S3なら絶対にダウンしないのも魅力。耐久性99.999999999%は伊達じゃない。

さて、次にRoute53を設定していく

ヘルスチェックの設定。このOKNG結果でフェイルオーバーを機能させることになる。

ヘルスチェックの環境設定

まずはELBのヘルスチェック設定ということで名前にELBを入れた。

他のヘルスチェックのステータス・・・でELBのヘルスチェックが指定できるのかな？と一瞬思ったが、どうも違うらしい

Amazon Route 53 がヘルスチェックの正常性を判断する方法 - Amazon Route 53

Route53内でヘルスチェックに親子関係を作って、子のヘルスチェック結果を親が利用する・・・と読めた。

今回はエンドポイントを選択。

監視対象の設定

ドメイン名指定で、ELBのドメインを指定

高度な設定

文字列マッチングというのが気になった。

ポーリングのレスポンスに含まれる文字列をみて、指定文字列が入ってて初めてOKと見なすものらしい。いつ使うんだろうと思って調べたら、事例を見つけた。

Route53 ヘルスチェックのエンドポイント設定のわな - Qiita

へぇ〜

最後に通知設定

作成。

S3版ヘルスチェックも作成する

結果を見てみると

ELBがうまくいってない。各地のヘルスチェッカーさんがFailureを出している。

そういやセキュリティーグループの設定はどうなってたっけ。

黒塗りしているが、マイIPしか許可していなかったw

う〜ん、でもこのブログに堂々とドメインとか書いているので

誰からもアクセスOKにはしたくない・・・せや！

これを・・・

こうして・・・・

こうじゃ

正常で結果もSuccessとなったのでヨシ！

いよいよDNSフェイルオーバーの作成・・・がここで引っかかる。

DNSフェイルオーバーを設定してみたというブログ記事はいくつか見かけたが

どれもこれも既に独自のドメイン名を取得している状態から始まっており

今回のように０から設定する時のことが考えられた記載になっていないようだ。訴訟！

このように最初、ホストゾーン設定は空である。

さらにこのドメイン名、AWSで取得すると結構な金がかかる。

詳しくはここに書いてあるが、年間契約でどんなに安くても9$からっぽい。

さすがに使い捨てに1000円はかけられない・・・。

ということで無料ドメインを取ってくることにするが

最終的にIPアドレスに解決するのはAWSなので、AWSのネームサーバに名前解決を委託

つまりNSレコードがかける無料DNSサーバでないといけない

・・・これがなかなか見当たらない。

AWS Route 53を使って独自ドメインのWebページを表示させてみよう | Avintonジャパン株式会社

うまくいっている例っぽいこれを参考にfreenomもアクセスしてみたが、ドメインが取得不可と出て前に進まない、困った。

苦肉の策として、ゴリ押しで架空ドメインを登録することにした。

まずは、適当に

test12345domain.ddns.net

を使うことに決める。

で、これを先ほどのドメイン名のところに放り込んで、

パブリックホストゾーンで登録

するとこの

test12345domain.ddns.netを

解決してくれるネームサーバ一覧が見えるようになる。

フェイルオーバーの設定兼、このドメインを何のIPで解決したらいいかを設定する。

レコードセットの作成から

Aレコードの設定。エイリアス先にELBのDNSを指定。

これでweb.test12345domain.ddns.netをAWSのネームサーバに聞きにきたら、

ELBのドメイン名（で解決できるIPアドレス）を返却してくれるようになる。

ルーティングポリシーはフェイルオーバーにして、こちらはプライマリ

ヘルスチェックとの関連付けも有効にして、先ほど作ったヘルスチェックを指定

作成。

さて、改めて今どういう状況かというと、

普段インターネットを使う環境で名前解決しようとすると失敗する。

なぜならweb.test12345domain.ddns.netは世界に向けて公開されていないからだ。

（この世界に向けて公開、というのが無料DNSサービスにお願いしようとしていた部分であり、AWSにお願いすると１０００円取られる部分である。）

でも、AWSのネームサーバさんに直接、お前知ってるよな？と聞くと答えてくれる！

さきほど教え込んだからだ。

あとはパソコンのDNSサーバ設定を

awsのネームサーバに指定してしまえばゴリ押しの完成である。

Macだとここ。WindowsならIPアドレス設定するところの下のほうに入力できる

パソコンの設定を変えたあとはコマンド上でDNSサーバ指定しなくても名前解決できる。

この状態でブラウザにweb.test12345domain.ddns.netを放り込むと

ELB越しにEC2で動いているWebサーバのページが表示された。

フェイルオーバーの設定を続ける。フェイルオーバー先のS3について、

前述の通りS3のバケット名は「S3のバケット名をプライマリサイトのドメイン名と同じにする」ことが必要なので、改めて作成する。

つまり今回はweb.test12345domain.ddns.netという名前のバケットが必要ということになる。

こんなかんじ。index.htmlの設置などは先に説明した通りなので割愛。

Route53に戻ってきて、再度レコードセットを作成する。

エイリアス先に今作ったS3を指定する。

フェイルオーバーをセカンダリにして、

ヘルスチェックとの関連付けも、はいに。

（バケット名変えたのでヘルスチェックの対象設定も変更しなおした。）

これで、設定は完了。

ようやくテストを行っていく。

まずは普通に繋がることを確認。

次に、ELB配下のEC2を停止する

するとこいつらへのヘルスチェックが失敗して・・・

切り替わる！

しばらくのち、Auto-Scalingが働いて新しいEC2が建つ

ホームページ復活。

きれいに動いた〜！

欲を言うと、フェイルオーバーの切り替わりにはそこそこ時間がかかったので

ヘルスチェックの間隔はもっと短くていいと思った。

今は３０秒間隔で３回失敗したら異常と判定するので切り替わりに９０秒かかる。

１０秒間隔にも設定できるので、早く切り替えたい場合はこちらかな。

途中謎の工夫をしたせいでめちゃめちゃ時間がかかってしまった。

ホストゾーン設定も存在しているだけで毎月そこそこのお金を取られるらしいので、最後に全消しして、終わり。Webページ用のS3も削除。

本記事に書いてあるIPやドメインにアクセスしても繋がらないのであしからず。

進捗。いい加減図を整理しないと辛くなってきたぞ

AWSをいじり倒す(9.CroudTrail、Athena)

前回からの引き続きで、CroudTrailを使ってVPCエンドポイントを使ったS3へのアクセス証跡を確認してみる

参考にしたのはこれ

S3のVPC Endpoint経由でアクセス出来ているか否かの確認 – Publicサブネット編 – サーバーワークスエンジニアブログ

CroudTrailは有効化しないとログ残らないのかな、と思っていたが

特に設定の必要はなく常時ONになっているようだ。

画面を開いてみると早速今までいじくりまわしてきた形跡が見えた。

一部切り取って確認してみる。

眺めていて気付いたのは

・バケットにオブジェクトをアップロードしたログ、というのは残ってない。

・EC2上でCLIによるBucket操作を行うと、ユーザ名はEC2のインスタンスIDになる。

（黒塗りのところはAWSコンソールから操作したので自分のユーザIDが表示されている）

という点。つまり、何でもかんでもCroudTrailに残るわけではないので、事前に目的のログが保存されるかどうかは確認しておかないといけないし、EC2に誰がアクセスしたかを別途把握する仕組みがないと追えなくなる。

具体的には、S3のオブジェクト操作ログは、

S3オブジェクトレベルのログ記録+監視方法 - Qiita

のようにオブジェクトレベルのログの記録を有効にする必要がある。

また、EC2のログはClowdWatch logsと連携させてログ記録+監視できる。

AWS構成パターン（CloudWatch Logs/EC2ログ管理）

このように調べたら何らかの対処法は出てくるけど、この辺は手探りで設定していくと検討漏れが出ること間違いなしなので、構築ノウハウを記載した書籍等を読んで所謂ベストプラクティスなやり方を身に付けた方が良さそうだ。

資格対策本ではこの辺はカバーできないなぁ。

さて改めて、

・S3にエンドポイント経由のアクセスができているかどうか

・ついでにオブジェクトレベルのログ記録ができるかどうか

の２点を確認することにする。

 S3にエンドポイント経由のアクセスができているかどうか

エンドポイントのない状態でバケット作成・削除→エンドポイント作成→バケット作成・削除のログ。

エンドポイント作成前のCroudTrailのイベント情報

ログ詳細を頑張って見なくても、発信元IPがパブリックIPになっているので、

これでもう十分インターネット経由ってわかりそう

エンドポイント作成後

発信元IPアドレスがローカルになっている。 

やはりこれだけでちゃんと機能しているとわかってしまった。

寂しいのでログ詳細も見てみると

エンドポイントなし

エンドポイントあり

 vpnEndpointIdってのが増えていることがわかる。

通信時間に大した差がないのは前記事の通りだが、

エンドポイント経由かどうかで料金が変わってくるので、

エンドポイント設定後は一度ぐらいこのログを見て安心した方が良いと思う。

オブジェクトレベルのログの記録

このオブジェクトレベルのログというのは

今まで見ていたイベント履歴にログが増えるわけではなく、

証跡情報として指定したS3バケットに保存される形式になるようだ。

まずはログ保存用のバケットをサクッと作る

そしてログ保存の設定。

CroudTrailの証跡の作成から

証跡情報の作成

証跡名は適当に。

別リージョンからアクセスすることはないので、

全てのリージョンに→いいえ

管理イベントはとりあえず全部記録したいので「すべて」「はい」

Insightsイベント

書き込み管理APIの異常な呼び出しボリュームとはいったい

CloudTrail Insights の発表: 異常な API アクティビティの特定とそれへの対応 | Amazon Web Services ブログ

スムーズに実行されている場合のログエントリは、さながら工場で安定して響く安心感のある機械音のようなものです。しかし不具合が発生した際には、その音が邪魔になりどの機器に不具合があるのかが聞き取りにくくなります。ログデータの量が膨大になる可能性があるような大規模なソフトウェアシステムでも、同じことが言えます。その記録を精査して実用的な情報を見つけるのは骨が折れる仕事です

ぐうわかる・・・

で、その中から異常なアクティビティを発見してくれる機能ってことらしい。

お値段安かったら有効にしてもいいと思うけど

CloudTrail Insights では、Insight タイプごとに分析された書き込み管理イベントについて、100,000 イベントごとに 0.35 USD の料金が請求されます。

100000イベント・・・が多いかどうかはシステムの規模にも依るのでなんとも。

データイベント

記録したいS3バケットを指定することができる。

てっきりS3の設定画面からログ記録の有効化するのかと思ったけど、

CroudTrail側から設定できるみたいだ。

S3バケットの追加からバケットを選択

ストレージの場所

ログの保存先S3。さっき作ったS3バケットを指定。

プレフィックスで指定した場所にたまっていく模様

ログファイルの検証とは、ログの改竄がないかどうかをチェックする仕組み。

できた。

S3の設定を見に行くと、オブジェクトレベルのログ記録が有効になっている

さっそくオブジェクト操作をしてみる

確認、削除、アップロードを行った。

 念の為、S3のGUIから手動でも適当なファイルをアップロードダウンロードを行っておく

〜１０分後〜

ログの生成を確認。保存先の階層が結構深い

json形式が.gzで保存されているので、ローカルに落として解凍し

中身を見てみる

わかりにくっ！

これはこうやって読むものじゃないな

これによるとAthenaで読むのが良いみたい。

CloudTrailでS3オブジェクトレベルのログを取得してAthenaで閲覧してみた | Developers.IO

そもそもAthenaってなんだ

Amazon Athena とは - Amazon Athena

標準 SQL を使用して Amazon Simple Storage Service (Amazon S3) でのデータの直接分析を簡易化するインタラクティブなクエリサービスです。

めちゃめちゃ限定的ィ！

それだけS3のログはよく利用されるってことなのかな。

早速、CroudTrailのイベント履歴からAmazon Athenaで高度なクエリを実行

保存場所を選ぶ。この時のSQLのクエリは自動で作ってくれている。

ここで自動生成されるAthenaテーブル名は後で使う。

できたようなのでAthenaに移動

Athenaの画面。

まずはSettingsで、Athenaクエリ実行結果を保存するS3バケットを指定。

クエリを作成。

参考記事からコピペしたものをベースに、日付とテーブル名を変更。

テーブル名はさきほど表示されていたものを使用。

左のメニューにも表示されてるけどね。

ところでこのクエリの書き方って、どうやって学ぶんだろう・・・。

自動生成する方法は見当たらないので、いじくってたらだんだん覚えていく系かしら

 Save asでクエリを保存。

Run queryで実行してみると・・・

あれ？GUIから出し入れしたログのみが出てきて、

EC2からCLIで操作したログがでてこない・・・。

仕方ないのでログファイルを直接頑張って読んでみることにする

eventNameがDeleteObject・・・これはrmしたときのログだろう。

一方でcpしたときは

UploadPartに
 

CreateMultipartUploadに

CompleteMultipartUpload

という３種類が出てきている。
 

みるべきキーワードが分かってきたので、クエリを変更してみる。

GetObject,DeleteObjectに加えて上記の３種イベントを追加。

また、ログに

と書いてあったので、

and useridentity.type = 'IAMUser';

の条件では引っ掛からなくなると思い、削除した。

このクエリの実行結果はこちら。

で、このUploadpartとは、

つまるところ適当に30MBのファイルをアップロードしてしまったせいで

図らずしもこのマルチパートアップロードを行ってしまったらしい

Amazon S3 マルチパートアップロード CLI

大きなファイルをアップロードするときに分割する機能。

cpコマンドを使うと自動でマルチパートになるんだと。

 これは１パートあたり５MB以上、最大１００００パートまでという仕様。

Amazon S3 マルチパートアップロードの制限 - Amazon Simple Storage Service

今回30Mのアップロードは４分割されてるっぽいので、8M前後に勝手に分けられたと推測。ログをよく読むとそれも書いてあった。

これが１つと

これが３つ。

いい具合に分割して送ってくれてたのね。

順番としては

CreateMultipartUpload→Uploadpart*4→CompleteMultipartUpload

なんだろうけど、順番通りログがでてないのは謎。

ログはコンマ0秒以下は残ってないので、仕方ないのかなぁ。

で、小さいファイルならCLIでもPutObjectになるんだよね？

ってことで1KBのファイルを作ってcpしてみる

結果。

無事PutObjectになった。

S3に複数人でファイルやりとりするとなったら、

やっぱ出し入れの情報は見たいし、オブジェクトレベルでのログ確認は必須だろうなぁ

ということでS3の操作から始まって、AWS CLI、VPCエンドポイント、CroudTrail、Amazon Athena、マルチパートアップロードと色々話が広がって勉強になった。

進捗

AWSをいじり倒す(8.AWS CLI)

以下を参考にCLIでs3を操作する。

AWS CLIを使ってEC2のファイルをS3へアップロードしよう | Avintonジャパン株式会社

ゆくゆくはCLIマスターして、JSONでポリシーかけるマンになりたいなぁ。

環境としては、自PCから専用のIAMユーザとしてアクセスする方法と

EC2に操作したい対象のサービスのIAMロールをアタッチしてアクセスする方法がある。

VPC作って、VPC内で通信を完結させることも多いので

基本的には後者のほうがよさそう。

S3を操作したいので、今回はS3FullAccessをアタッチする。

EFSの時に作ったEC2にアタッチ済みのロールに追加（手抜き）

AWS CLIツールはEC2(Amazon Linux)なら最初から入っているのでインストールは

不要。

EC2を立ち上げ、アクセスしconfig変更。

今回アクセスキーは使わないのでNone
EC2のリージョン名はいろんな確認方法があると思うが

DNSとかにも埋め込まれているのでそれ見て抽出

出力はjsonがおすすめらしい

configの格納場所も確認

VPCの確認コマンドを打つとエラー

権限を付与していないので、当然。

UnauthorizedOperationって出た時はIAMロールを見直す必要がある。

当該EC2にアタッチ中のロールに追加で２ポリシーをアタッチ

VPCReadOnlyAccessがあれば上記コマンドは通るはず。

早速試すと・・・通った。再アタッチとかは必要なくて即時反映

EC2ReadOnlyAccess権限も付与したので、インスタンス情報も取得可能

aws helpコマンドでヘルプが読めるけど

awsの後に続くコマンドはめちゃめちゃ種類が多いので

やりたいことがある都度ネットで調べた方が早そう。

早速、前回作ったS3バケットにファイルを入れてみる。

test-s3-12345は前回つくったバケットの名前

特に問題なく移動できた

バケットそのものを作る

バケットを削除する

思いの外簡単で、詰まるところがない。

--forceオプションで中身があっても強制削除できる。

次に、VPCエンドポイントの効力を確認してみる。

すでにVPC作る時にS3へのエンドポイントを作ってしまっていたので、

まずはエンドポイントありの時間を計測

３０MBの空ファイルを作成

timeで計測

VPCのS3向けエンドポイントを削除する

削除すると、ルートテーブルからも消えた。賢い。

一旦消して、再度送信すると・・・

変わ・・・らない！？

EC2はオハイオ、S3もオハイオの状況だとAWS内部を通すも外部を通すも

転送速度としてはそんなに変わらないのかもしれない・・・。

探していると、同じく確認しようとしている記事を見つけた。

S3のVPC Endpoint経由でアクセス出来ているか否かの確認 – Publicサブネット編 – サーバーワークスエンジニアブログ

なるほど、CroudTrailか。次回CroudTrailを触ってみることにする。

進捗

AWSをいじり倒す(7.S3)

S3を使ってみる。

バケットを作成ボタンを押す。

設定

バケット名は適当に、一意に。全S3ユーザで一意なので、生半可な名前は被るw

リージョンは改めてここで選択。

testにつかっているEC2サーバと同じリージョンにする

パブリックアクセスの設定

基本的にはブロック推奨らしい。

日本語変だなぁ・・・

いったんブロックで作って、余力があったらパブリックも試すことにする。

S3で誤ったデータの公開を防ぐパブリックアクセス設定機能が追加されました | Developers.IO

S3のアクセス制御はなかなか奥が深そう

オブジェクトのロック

今回は無効。

これで作成。設定項目少ないな〜

できたっぽい。

フォルダの作成

フォルダ名を入れて作成

暗号化についてこの辺が参考になる

S3 オブジェクトに暗号化を追加する方法 - Amazon Simple Storage Service

できた。

アップロードしてみる

う〜ん直感的。書くことがないぐらい。

適当に画像をD&Dで追加

アクセス設定

このユーザーIDって誰やねんと思ったら、自分のことらしい。

プロパティの設定。

勘違いしていたけど、バケットに対してストレージが割り当てられるんじゃなくて

オブジェクトに対してストレージの種類を割り当てる感じなのね。

暗号化とメタデータ

メタデータのヘッダーについて

https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/user-guide/add-object-metadata.html

上図のようにアップロードしようとしているファイルのヘッダーを変更したり、AWSオリジナルヘッダーを追加したりできる。

タグはNameを指定してみたが・・・S3ではそういう使い方ではないみたい。

他のサービスで使うようなタグというよりは、ポリシーの対象グループとするなど、もう少し高級な使われ方をするようだ

S3 オブジェクトのタグ付け機能を使ってみた – サーバーワークスエンジニアブログ

アップロードボタンを押してアップロード

できた。

ただ、あんまりGUI上で操作しているような記事を見かけず

CLIでの操作が主流。

次回、AWS CLIを使って、CLIでの操作にトライする

AWSをいじり倒す(6.EFS)

EFSを使ってみる。

以前、複数のWindowsサーバをEC2で立ち上げて、

ファイル共有したいなぁと思って調べた時に出てきたキーワードだけど

EFSはWIndows対応してなくて使えなかった。

blackbeltみてても結構大きくWIndows非対応と書いてあるので、今後も対応することはないのだろう・・・。

（ちなみにその時は多めにEBSを積んだEC2をストレージ用として建て、別EC2からネットワークドライブとしてマウントした。）

調べてみると、気合でWindowsから使う方法もあるにはあるみたいだが、

今回はLinuxサーバを２つたてて、それぞれにEFSをマウントし、ファイル共有を試す

AWS EFS をEC2にマウントしてみる - Qiita

これが参考になりそう

サービスからEFSを選択した最初の画面

ネットワーク設定

アクセスしたいEC2の所属するVPCを指定する。

マウントターゲットの設定

セキュリティグループはデフォルトで何か入っているが、今までの経験からするとうまく機能しないと思われるので、要確認。

タグの設定

なんでか説明が詳しくて、Nameがデフォルトで入っている

ライフサイクル管理

EFSにはスタンダードと定頻度アクセスという２種類のストレージがある

EFS ストレージクラス - Amazon Elastic File System

ただ、定頻度を最初から指定できるわけではなく、このライフサイクル管理によって指定した期間アクセスがないと自動で移動されるような使い方になる

選択肢はこんな感じ。

長期保存となるものはなるべくS3に保存すべきなんだろうけど、

使うと思ってたけど実は使わない、みたいなものがあるとしたら

有効にしといて損はない機能かな。

スループットモードの選択

バーストは、普段貯金しておいて突発的な支出に備えるモードであるが

貯金で買えない量のトラフィックが必要ならプロビジョニングモード。

この辺はblackbeltP66あたり参照

パフォーマンスモード

最大I/Oを使うべきかどうかはClowdWatchあたりで監視してないとわからん気がする

暗号化

暗号化を有効にすると、保管されているデータの暗号化はともかく

転送中のデータ暗号化は証明書の準備など、設定がややこしくなる。

インターネット越しにEFSと通信する時とかに必要になってきそう。

同一VPC内のEC2との通信であれば不要かな。

Amazon Elastic File System（EFS）を使ううえでの勘所 - Qiita

デフォルトでいろんな制限しておいて、IDベースで権限を上書きして使う。

 これはこの辺が参考になった

[アップデート] Amazon EFSでIAM認証とアクセスポイントの設定が可能に | Developers.IO

試しに、読み取り専用アクセスを強制にチェック。

ポリシーの設定を押して

JSONの画面を出して、保存する。ここまでしないと反映されない。

アクセスポイント

アクセス権限付きのディレクトリ を作成するイメージ。

先ほどと同じ

[アップデート] Amazon EFSでIAM認証とアクセスポイントの設定が可能に | Developers.IO

が参考になる。見様見真似で２個ディレクトリ を作成

確認画面を経て、作成。

割とすぐできた

上の画像に見えているファイルシステムIDを使ってマウントすることになる。

セキュリティグループの確認

入ってるのはデフォルトのガバガバ設定だった。

なんか作る時は先にセキュリティグループを作らんとあかんかも。

NFSは2049のTCP。

ルールを作って

ファイルシステムアクセスの管理から

新たにセキュリティグループを選択して保存

接続確認をしていく。

接続したいEC2に、Linux NFSv4 Clientのインストールが必要。

EFSマウントヘルパーというのがamazon-efs-utilsに含まれており、これを使うことが推奨されている

sudo yum –y install amazon-efs-utils

特に問題なくインストールできた。

さてマウント。

怒られた。

どうもこの指定したファイルシステムIDからドメイン名を生成して、

ドメイン名からマウント対象のEFSを探してくる挙動みたいなのだが

DNSの解決ができねーぞ、と。

【AWS】EC2からEFSをマウントする - MOテクノロジー

久々にVPCの画面を開いてDNS設定を確認

DNS解決の編集・・・すでに有効

DNSホスト名の編集

チェックついていなかったので、有効化

・・・で、DNSホスト名の編集って何？

VPC での DNS の使用 - Amazon Virtual Private Cloud

パブリック IP アドレスを持つインスタンスが、対応するパブリック DNS ホスト名を取得するかどうか示します。

この属性が true の場合、VPC 内のインスタンスは DNS ホスト名を取得しますが、これは enableDnsSupport 属性も true に設定されている場合のみです。

今回のEFSはパブリックIPなんて持ってないはずなんだけど・・・。

パブリックDNSって関係なくない？

これで結果が変わる理由がよくわからないままコマンドが・・・通った。

念の為nslookup

ローカルIPだよなぁ。モヤモヤ

気を取り直して、アクセス制限を確認する。

想定通り。

EC2用のロールを作成

ロールの作成

EC2を選ぶ

今回必要なのはElasticFileSystemでClientでRead/Writeなので

これを選択。

タグに適当に名前をつけて、作成。

できた。

EC2の画面を出して、ロールのアタッチ

先ほど作ったロールを選択。

さて、これで本当にいけるんだろうか。

いったんEFSをアンマウントして、iamを指定してマウントする

ファイルを作ってみると・・・

いけた！

アクセスポイントも試してみる。

read-onlyのアクセスポイントにマウントしたら、書き込みが不可となった。

 

違うEC2を建てて、マウントしてみると今まで作ったファイルが見えた。

試し忘れたけど、EC2再起動するとマウント状態も解除されてしまうので

永続的にマウントするには追加設定が必要

Amazon EFS ファイルシステムを自動的にマウントする - Amazon Elastic File System

Linux系をメインで使うときの共有ストレージとしては、気軽にアタッチできて使いやすいかも。

でもSMB対応のストレージも欲しいなぁ

進捗