こんにちは、大石(@se_o_chan)です。
今回はAWS Storage Gatewayの一種であるAmazon S3 File Gatewayをプライベートサブネットで実装します。実は実装時にパブリックアクセスが可能であることを前提としているので、少し実装方法に癖があります。
システム構成
今回構築するシステム構成は次の通りです。
Amazon S3 File Gateway(以下、File Gateway)をプライベートサブネットにEC2でデプロイします。システム通信は極力プライベートにするため、S3のゲートウェイ型エンドポイントと、Storage Gatewayのインターフェース型エンドポイントを配置します。今回はパブリックサブネットに踏み台サーバを用意し、そのサーバにFile GatewayをSMBでマウントしてみます。
実装する
事前準備
まず、事前準備としてセキュリティグループ、ルートテーブル、エンドポイントをセットアップします(VPC・サブネット・インターネットゲートウェイは構成図のとおり実装済とします)。
セキュリティグループは構成図の通り、3つ用意します。
- Bastion用セキュリティグループ
インバウンドは操作端末のIP(マイIP)からのRDP接続(3389番)。
アウトバウンドは特に制限をかけません。 - File Gateway用セキュリティグループ
インバウンドはBastion用セキュリティグループからのSMB接続(445番)と、操作端末のIP(マイIP)からの80番。
アウトバウンドは特に制限をかけません。 - エンドポイント用セキュリティグループ
インバウンドはFile Gateway用セキュリティグループからのTCP 443、1026、1027、1028、1031、2222番。
アウトバウンドルールは無しでよいです。
「File Gatewayはプライベートサブネットにあるのに、操作端末のIPからのインバウンドがあるの?」と思うかもしれませんが、そこが今回の肝です。マネジメントコンソールからFile Gatewayをセットアップしようとすると、操作端末からFile GatewayをデプロイするEC2に80番通信が必要になるのです。
ということは、プライベートサブネットに実装するとはいえ、一度パブリックアクセスが可能(=パブリックサブネット)な状態にしないといけません。そこで、プライベートサブネット用のルートテーブルに一時的に「デフォルトルート(0.0.0.0/0)がインターネットゲートウェイ」のルートを追加します。
File Gatewayの実装が終われば、このルートは削除できます。
最後にエンドポイントを用意します。Storage Gatewayのインターフェース型エンドポイントを、プライベートサブネット上に実装します。その時、先ほど作成したエンドポイント用セキュリティグループをアタッチしてください。
S3のゲートウェイ型エンドポイントも対象のVPCに実装します。ゲートウェイ型なのでセキュリティグループ等の設定は不要です。
これで事前準備が整いました。
ゲートウェイをセットアップ
では、ここからFile Gatewayをセットアップしていきます。Storage Gatewayコンソールから「ゲートウェイの作成」ボタンをクリックします。
ゲートウェイのオプションとして「Amazon S3 ファイルゲートウェイ」を選択します。プラットフォームオプションは「Amazon EC2」です。今回は「設定をカスタマイズ」から実装していきますので、「インスタンスの起動」ボタンからEC2コンソールへ移動します。
すでにAMIはStorage Gateway用のものが選択済になっていますので、そのままにしておきます。インスタンスタイプはAWS推奨の内、最小構成のm5.xlargeを選択します。
サブネットはプライベートサブネットを選択します。ただし、ここでポイントが「パブリックIPの自動割り当て」は有効化にしてください。初期実装時のみ操作端末からの直接(80番)通信が必要なためです。
EC2には事前準備で作ったFile Gateway用セキュリティグループをアタッチしておきます。ストレージはルートボリュームの他に、最低150GBのEBSボリュームの追加が推奨です。
EC2インスタンスを起動し、ステータスが正常になったことを確認したらインスタンスのパブリックIPアドレスを確認して、File Gatewayのセットアップ画面に戻ります。
接続オプションはIPアドレスを選択し、EC2インスタンスのパブリックIPアドレスを入力します。エンドポイントのオプションはホストされたVPCを選び、事前準備で作成したStorage Gatewayエンドポイントを選択します。
ここで「次へ」を押すと、操作端末からEC2インスタンスへの80番通信が走ります。事前準備が正しくできていれば、下記の確認画面が表示されるはずです。表示されている内容に誤りがないことを確認し、「アクティブゲートウェイ」ボタンを押します。
キャッシュストレージの設定には「キャッシュ」を選びます。CloudWatchロググループとアラームの設定は任意ですが、今回は「新しいロググループを作成」と「Storage Gatewayの推奨アラームを作成」にします。
これで「設定」ボタンを押せば、ゲートウェイのセットアップは完了です。 ここまでくれば、事前準備で用意した
は削除してしまっても良いです。当初目的のプライベートサブネットに戻しましょう。
ファイル共有の作成
File Gatewayはデプロイされたのですが、まだどのS3バケットへ接続するのかといった設定はしていません。そこでStorage Gatewayコンソール > ゲートウェイから「ファイル共有の作成」ボタンをクリックします。
ゲートウェイには先ほど作成したFile Gatewayを選択します。今回Windows Serverにマウントさせるのでファイル共有タイプはSMBを、S3バケットにはSMB経由で連携したいバケットを選びます。
ユーザー認証は今回「ゲストアクセス」を選んでいます。この場合、パスワード(この画面で設定させられます)を知っている人なら誰でもSMBマウント可能になります。その他には、Active Directoryと連携して所定のドメインユーザまたはドメイングループのみがアクセス可能にすることもできます。
デフォルト設定でよいので「ファイル共有の作成」ボタンをクリックします。するとファイル共有の設定値が表示されます。この画面下にコマンドが用意されているので、これを使ってマウントしてみます。
SMBでマウントする
パブリックサブネットにWindows ServerのEC2インスタンス(Bastion)を起動しておきます。セキュリティグループとして、事前準備で作成したBastion用セキュリティグループをアタッチしておきます。
では、BastionにRDP接続をして、先ほどのコマンドを参考にZドライブとしてマウントしてみます。するとパスワードを求められるので、ファイル共有の作成時に設定したパスワードを入力します。
無事マウントできました!!
では、このZドライブにファイルをアップしてみましょう。合わせてフォルダも作成してみます。
S3にアップしたファイルが格納され、フォルダも作成されていることが確認できました!
(補足)CloudWatchアラームの内容
ちなみに、途中で自動作成されたCloudWatchアラームはどんな内容でしょう?CloudWatchコンソールから確認してみると、次のアラームが作られていました。
FileSharesUnavailableは利用不可になっているファイル共有が無いか、IoWaitPercentはIO性能のモニタリングですね。
Storage Gateway経由でファイルを書き込んだ場合、一度キャッシュとして保持し、非同期でS3にアップロードします。CachePercentDutyはS3アップロードしていないキャッシュが異常に増えたことを示すメトリクスです。
(出典) AWS Storage Gateway(AWS Black Belt)
まとめ
情報としては目新しいものではないですが、業務上必要になりそうだったため手順の確認を兼ねてFile Gatewayの実装方法を整理しました。次回はActive Directoryと連携させたアクセス制御の実装にも踏み込んでみようと思います。