挨拶
白"雪姫"です。
２０２５年からはQiitaの方へ移植させて頂きました。
今までのブログは、残しておきます。
備忘録も兼ねまてますので。
今回のお題
Mountpoint for Amazon S3というS3をマウントできるツールがAWSには有ります。
これを何か有用活用できないかな。と思い、色々やってみました。
先に結論
お休みの間にちょっと試そうと思ったので、やりたかったことは色々エラーが出てしまいできてません。
本当はやりたかったこと
- AWSのVPCと自宅をVPN接続をする
- VPCは4Subent用意(PubricSubnet2つ、PrivateSubnet2つ)
- PrivateSubnetに紐付くS3のInterfaceEndpointを作成
- 自宅内に建てたLinuxマシンから、InterfaceEndpointを経由してS3をマウント
- 自宅内LinuxからS3のデータを読み出してWebサーバで読み出せるか。
やりたかったことの構成図
今回やったこと
- VPCで4Subnetを用意(PublicSubnet2つ、PrivateSubnet2つ)
- PrivateSubnetに紐付くS3のInterfaceEndpointを作成
- PublicSubnet及びPrivateSubnetにEC2を1台ずつ構築（PublicSubnetは踏み台用,PrivateSubnetで実験)
- PrivateSubnetにあるEC2でS3のマウントを行う
- S3のデータの読み込み、書き込みを行い、速度の測定を行う
今回やったことの構成図
そんなわけで、やってみましょう。
EC2のセットアップ
- VPCとサブネットまではCloudformationで作ります。該当のCloudformationはClaudeで素直に作ってもらいました(笑)
- EC2やVPC Endpointについては手動でポチポチ起動します。
- PrivateSubnetで起動してるのでCloudShellを用いてアクセスを行います。
利用したのは AmazonLinux 2のx86_64、t2.microで立ち上げています。
IAMロールは、実験と言うこともありAdministrator Accessを割り当てています。
mount-s3の設定
# epelの有効化
$ sudo amazon-linux-extra install epel
# 念の為最新化
$ sudo yum update -y
$ sudo yum upgrade -y
# mount-s3のインストール
$ wget https://s3.amazonaws.com/mountpoint-s3-release/latest/x86_64/mount-s3.rpm
# https://s3.amazonaws.com/mountpoint-s3-release/latest/arm64/mount-s3.rpm #arm version
$ sudo yum install ./mount-s3.rpm
$ mount-s3 --version
インストールはこれで完了です。
マウントする
$ mount-s3 "対象のS3 backet" "mount directory"
これで、マウントは完了です。
問題が1点。削除や移動ができませんでした。
どうやら普通のマウント設定とは異なるようです！（オブジェクトストレージなんだからそりゃそうだ)
一度mountを解除してオプションを確認してみます。
$ sudo umount "mount directory"
# helpを確認します。
$ mount-s3 --help
#helpはご自身でご確認を。
確認してみたら、--delete-allowというオプションが有る様なので再マウントしてみましょう。
$ mount-s3 "対象のS3 backet" "mount directory" --delete-allow
これで、マウント出来ました。
テスト
# 実際の書き込みテスト
[root@ip-172-19-0-138 ***]# dd if=/dev/zero of=/"mount directory"/tmp.data bs=1M count=500 oflag=direct
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 2.6715 s, 196 MB/s
196MB/sは出るようです。うん、速度としては充分だよね。
備忘録
ここまでやってみて、ハタと気が付きます「S3+Cloudfront」で、サイト作れるのだし、当然動く位はリード速度は充分に出るということに気が付きました。
今回やった実験はここまでです。
今回VPCのアクセスからの検証をあきらめた理由 >!!実はこれ重要!!<
- 1つ目
- コストです。単純にお金がかかりすぎてしまうためです。
- 2つ目
- セキュリティ面での不安が発生したためです。
別の機会があればちゃんと試したいなと思っています。
今回、あきらめた理由になります。
2つ目のセキュリティ面について詳しく書いておきましょう。
- IAMのアクセスキーとシークレットアクセスの保存問題
- IAMのアクセスキーとシークレットアクセスをサーバに書き込みしたまま残しておくのとローテーションが大変だなぁと思ってしまったためです。
- 補足するとIAM role anywareという物があって、これを利用するとロールをAWS外部で利用できるというので調べてやってみようとしましたが、残念ながら今回利用した検証サーバのOSにインストールされている必要ツールのバージョンが古く最新版にも対応していない状態だったため利用できず。。。
- IAMのアクセスキーとシークレットアクセスをサーバに書き込みしたまま残しておくのとローテーションが大変だなぁと思ってしまったためです。
- VPNの経路の名前解決とルータ内のfilter問題
- 宅内の回線で追加でVPNを張っていた関係で、ルーティングとfilterまた、向き先のDNSの問題があり、元に戻すのも少し大変なためこちらも問題が発生。
- 問題になったのは、S3のアクセスが、VPN経由ではなく、グローバル経由になってしまっていたことになります。
- DNSに関しては、Amazon Route 53 Resolverのインバウンドリゾルバーエンドポイントを利用すれば解決します。
- サーバでResolverで割り充てられているDNSを上記でDNSに指定を行うと自動的にVPN経由にはなってくれてましたが、一部通信がまだグローバルに通信することも問題の点になりました・・・。
- 問題になったのは、S3のアクセスが、VPN経由ではなく、グローバル経由になってしまっていたことになります。
- 宅内の回線で追加でVPNを張っていた関係で、ルーティングとfilterまた、向き先のDNSの問題があり、元に戻すのも少し大変なためこちらも問題が発生。
- セキュリティ面とは違った他の問題も・・・
- 今回は実験しましたが、mount-s3はマウントしたユーザでのみ読み書きができるという状態だったため想定していたことが少しできないなと感じたのもあります。(mountをrootもしくは操作ユーザで実施して、nginx等のユーザで読み取りさせたかったが不可能っぽいため)
また時間が取れたら細かくやりたいなぁとは思っています。