StorageGateway on EC2(ファイルゲートウェイ)をプライベート環境で使ってみる

オッス、オラCI部の柿﨑です。
先日、1ヵ月のうちに数日しかオープンしないケーキ屋さんに行きました。
たまたま前を通りがかったときにオープンしていまして、
10人ちょっとしか並んでないじゃん！と思って並んだところ、
2時間ほど待ちました（　＾ω＾）・・・。ケーキはおいしかったです！

今回は、StorageGateway on EC2のファイルゲートウェイをプライベート環境で使います。
ドキュメントと睨めっこしつつ、最終的にAWSサポートに問い合わせて通信要件を確認しました。
通信要件のところだけお伝えしたいため、それ以外の説明や設定は所々省いています。

構成

• IGWはアクティベーション時、Bastionアクセス用途
• BastionはクライアントEC2に接続するため
• StorageGateway on EC2をクライアントEC2でNFSマウントする
• プライベート環境からS3、StorageGateway(以下SGW)に接続するためのエンドポイントを作成

作ります

まずはVPC、サブネット、IGW、各種ルートテーブルを作成してください。
VPCはDNSホスト名とDNS解決を有効化しておいてください。
※説明は省略します。   SGを以下のように作成。

• SGW プライベートリンクのSG
  インバウンドルールのソースは、SGW on EC2のSGIDに設定
  アウトバウンドルールはなし
• SGW on EC2のSG
  インバウンドルールは、80番をアクティベート時に使用するIPアドレスに設定
  (今回はマネジメントコンソールに接続する端末のグローバルIPアドレス)
  (踏み台からアクティベートすることも可能とのことだが、諸事情によりまた今度とさせてください)
  その他はNFS用にクライアントEC2のSGIDを許可
  アウトバウンドルールは、443がS3とSGWのエンドポイント向け、その他はすべてSGWのエンドポイント向けを許可
  
  
  
• クライアントEC2のSG
  インバウンドはBastionからのSSHを許可
  アウトバウンドはSGW on EC2向けにNFS許可、その他+αでお好きなように
• BastionのSG
  クライアントEC2にSSHできれば何でもいいです(今回は重要ではない)

S3エンドポイントを作成。 プライベートサブネットだけルーティングするようにします。
また、以下のポリシーを適用すると特定のS3だけに通信を許可することができます。

{
    "Version": "2008-10-17",
    "Statement": [
        {
            "Sid": "Access-to-specific-bucket-only",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::S3バケット名",
                "arn:aws:s3:::S3バケット名/*"
            ]
        }
    ]
}

SGWのプライベートリンクを作成。 こちらもプライベートサブネットのみに作成します。
また、適切なSGを割り当てます。 続いて、S3バケットを作成します。
バケットポリシーに使用するため、先ほど作成したS3エンドポイントのIDをメモ。 S3バケットを作成。
バケット名を入力して、作成でおｋです。 以下のバケットポリシーを適用し、
S3エンドポイント経由でないと操作できないようにします。
aws:usernameに何かしらのIAMユーザー名を登録しないと、
マネジメントコンソールからS3をいじれなくなって面倒なため、
今回は私のIAMユーザー名を入力。
細かいActionなども絞れますが、割愛します。

{
    "Version": "2012-10-17",
    "Id": "Policy1415115909152",
    "Statement": [
        {
            "Sid": "Access-to-specific-VPCE-only",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "s3:*",
            "Resource": [
                "arn:aws:s3:::S3バケット名",
                "arn:aws:s3:::S3バケット名/*"
            ],
            "Condition": {
                "StringNotEquals": {
                    "aws:sourceVpce": "S3エンドポイントID",
                    "aws:username": "任意のIAMユーザー名"
                }
            }
        }
    ]
}

SGWの作成に移ります。
まずはアクティベート用にプライベートサブネットにIGWのルートを追加。 SGW用のEC2を作成。
SGWコンソールを開き、今すぐ始めるを押下。
その後、ファイルゲートウェイを選択して次へ。 以下の画面にて、インスタンスの起動をポチっと押します。 インスタンスタイプは、m5xlargeに設定し、ネットワークはプラベートサブネット。
EBSは150GiBを1つ追加し、適切なSGを割り当てて作成します。 SGW用のEC2を作成しましたら、ElasticIPを割り当ててください。
その後、以下の画面を進みます。 サービスエンドポイントの画面にて、VPCを選択。
入力する値は、SGWプライベートリンクのDNSになります。 ゲートウェイに接続画面にて、SGW用EC2のElasticIPを入力してゲートウェイに接続。 ゲートウェイのアクティブ化画面にて、適切なタイムゾーン、名前を設定し、ゲートウェイのアクティブ化を押下。 少し待ちますと、以下の画像のようにローカルディスクを認識しますので、追加したEBSにキャッシュが割り当てられていることを確認後、
ログ記録を設定を押下し、次の画面で終了をクリックしてください。 ここまででアクティベートが完了しましたので、SGW用EC2からElasticIPをデタッチし、
プライベートサブネットのIGW向けルートを削除します。 このあたりでBastionサーバーとクライアントEC2を構築します。
適切なSGを割り当てるだけですので、細かいところは省略します。 クライアントEC2に接続し、NFSマウント用のディレクトリを作成。
念のためにマウント情報も確認しておきます。

sudo su
cd /
mkdir file
df -hT

SGWコンソールへ移り、ファイル共有を作成します。 S3バケット名を入力して次へ。 新しいIAMロールを作成するを選択し、次へ。 許可されたクライアントをクライアントEC2のIPアドレスか、プライベートサブネットのCIDRに設定し、ファイル共有の作成を押下。 上記の手順で作成されたファイル共有のLinux用コマンドをコピー。 クライアントEC2にてコピーしたコマンドをペースト。
無事マウントされていますね。
※クライアントEC2再起動時もマウントさせるには、/etc/fstabを忘れずに。 マウントしたディレクトリで試しにファイルを作成すると、S3にも反映されていることが分かります。

リストアしてみる

SGW用EC2のAMIを取得します。 SGW用EC2のプライベートIPアドレスをメモります。 SGW用EC2を終了します。
SGWコンソールでも疎通ができなくなることを確認。 先ほど作成したAMIから削除したEC2と同じ設定で起動します。
プライベートIPアドレスは先ほどメモったものを使用します。 こんな感じで作ってあげると、SGWコンソールでも再認識してくれます。 最後にクライアントEC2からSGWの状態を確認してみますと、
問題なくS3を操作できることが分かるかと思います。

まとめ

こちらのStorageGatewayの要件を確認しますと、
SGW用EC2のSGに22番(サポートチャネル)、53番DNS、123番NTPが
必要なんじゃないの？って思ってしまいます。
が、SGW on EC2にて53番DNS、123番NTPをAWSのデフォルト設定で使用する場合は、
透過的に通信するため、明示的に許可する必要がありません。
22番はEC2であれば、サポートチャネル用に開けてやる必要もないのです。
結果、アクティベート時に使用する80番ポートだけに注力して通信を絞ることで、
プライベートな環境でSGWを使用することができました。
※また時間があるときに踏み台経由でアクティベートする方法は試す予定です。   また、一度アクティベートされたSGWは、
バックアップを取得しておくことでプライベート環境内で
リストアできることが分かりました。   本記事が、皆様のお役に立てれば幸いでございます。