ガバメントクラウド上の標準準拠システム同士がデータ連携する方法は、オブジェクトストレージを使ったファイル連携とされてます。AWS ではオブジェクトストレージとして S3 が使われることから、インターネットへ接続できない閉域の VPC 間で S3 のエンドポイントを使うアクセス方法について検証し、次のようなブログ記事を以前書きました。
AWS の VPC 間であれば、閉域であったとしても、EC2 などの AWS リソースから S3 のエンドポイントへアクセスすることは容易です。
一方、閉域で接続されているオンプレミスと VPC の間で、オンプレミスのリソースから VPC の S3 エンドポイントへアクセスするには、アクセス許可のためのクレデンシャルを取得する必要があります。
簡単にこれを行う方法として IAM ユーザーを作成してアクセスキーを発行することが挙げられますが、ガバメントクラウドでは IAM ユーザーの作成、アクセスキーの利用は原則禁止のため、これができません。
IAM ユーザーの作成ができない環境で、アクセスキー以外の方法で閉域のオンプレミスのリソースが S3 へアクセスするためのクレデンシャルを取得するにはどうすればいいでしょうか？
それには、AWS STS で IAM ロールの AssumeRole を使うことが考えられます。しかし、要件が閉域内からとなるため、STS 自体にアクセスするためのクレデンシャルが必要となります。
閉域のオンプレミスから STS で AssumeRole するには、以下の方法が考えられます。
- プライベート CA を立てて IAM Roles Anywhere を使う
- オンプレミスのリソース（サーバーなど）に Systems Manager Agent (SSM Agent) をインストールする
- VPC 上のリソース（EC2 や Lambda など）から STS へアクセスしてクレデンシャルを取り出し、オンプレミスのリソースへ渡す
IAM Roles Anywhere だとプライベート CA の管理が生じます。VPC 上のリソースを使う場合もそのリソースの管理が必要な上、オンプレミスのリソースへ取り出したクレデンシャルを安全に渡す必要があり、手間がかかってしまいます。
SSM Agent のインストールは一番手っ取り早いのですが、アクティベーションの有効期限が最長 30 日間のため、更新の手間が生じます。
いずれも一長一短ですが、もし VPC に既に Systems Manager のエンドポイントがある場合、SSM Agent を使う方法が、コスト的なメリットがあると思われます。
そこで、オンプレミスの閉域な検証環境のサーバーに SSM Agent をインストールし、SSM Agent のアクティベーションにセットした IAM ロールのクレデンシャルを使って、オンプレミスのサーバーから S3 エンドポイントにアクセスする方法を検証してみます。
S3 エンドポイントへのアクセス検証の手順
まず自宅のオンプレミスに閉域サブネットを作成し、オンプレミスの VPN ルーターから VPC のパブリックサブネットにある EC2 の VPN インスタンスに接続し、VPC とオンプレミスを閉域で接続しています。
オンプレミスには DNS サーバーを立てて、VPC エンドポイントで使う amazonaws.com 宛ての名前解決要求を Route 53 インバウンドエンドポイントへ向けるようにします。
一連の手順は以下の記事にまとめています。
ここから、VPC に Session Manager と S3 のインターフェイスエンドポイントを作成することで、オンプレミスから VPC エンドポイントの DNS 名でアクセスできる想定です。
Session Manager には IAM ロールをセットしたアクティベーションを作成することで、オンプレミスのサーバーにインストールした SSM Agent が AssumeRole してクレデンシャルを受け取れます。
このクレデンシャルを使って、オンプレミスのサーバーはインターフェイスエンドポイント経由で S3 にアクセスすることができるようになります。
それでは早速検証してみます。
Systems Manager の設定
VPC エンドポイントを作成
Systems Manager を閉域から使うために、ssm, ssmmessages, ec2messages の 3 つの VPC エンドポイントを作成します。
「DNS 名を有効化」にチェックを入れると、Route 53 プライベートホストゾーンが裏で自動的に作られて、インバウンドエンドポイント経由で名前解決できるようになります。
Systems Manager は HTTPS（TCP 443 番ポート）を使うので、これを許可するセキュリティグループをアタッチしてください。
プライベート DNS 名で名前解決できる VPC エンドポイントが作成されました。
同様の手順で ssmmessages, ec2messages の VPC エンドポイントも作成します。
ハイブリッドアクティベーションの作成
オンプレミスのサーバーに SSM Agent をインストールして管理できるようにするため、Systems Manager のハイブリッドアクティベーションを作成します。
今回は検証なので、一旦デフォルトで作成される IAM ロールをアタッチして、後で作成された IAM ロールに S3 へアクセスできる IAM ポリシーを追加することにします。
最長 30 日間の有効期限を設定できます（空欄にすると 1 日間）。また、今回は特に使いませんが、インスタンス名も設定できます。
作成できたら、オンプレミスのサーバーに SSM Agent をインストールする際に必要となるアクティベーションコードと ID を控えておきます。
「AmazonEC2RunCommandRoleForManagedInstances」という IAM ロールが作られているので、S3 へのアクセスに必要な IAM ポリシーを許可ポリシーに追加しておきます。
S3 インターフェイスエンドポイントの作成
SSM Agent のインストールには S3 から HTTPS でファイルをダウンロードする必要があるので、オンプレミスのサーバーが、インターネット接続がなくても SSM Agent をインストールできるよう、先に S3 のインターフェイスエンドポイントを作成します。
手順は Systems Manager の VPC エンドポイントを作成する手順と同じです。S3 も HTTPS を使うため、HTTPS を許可するセキュリティグループをアタッチするようにしてください。
正しく設定できれば、オンプレミスのサーバーから名前解決して S3 インターフェイスエンドポイントのプライベート IP アドレスを取得できるはずです。
オンプレミスのサーバーの設定
SSM Agent のインストール
今回オンプレミスのサーバーとして Ubuntu Desktop 24.04 LTS を用意しましたので、これに SSM Agent をインストールします。
以下は東京リージョンのエンドポイントを使う例です。「activation-code」と「activation-id」は先ほどハイブリッドアクティベーションを作成した際に控えたものをセットしてください。
$ mkdir /tmp/ssm
$ curl https://amazon-ssm-ap-northeast-1.s3.ap-northeast-1.amazonaws.com/latest/debian_amd64/ssm-setup-cli -o /tmp/ssm/ssm-setup-cli
$ sudo chmod +x /tmp/ssm/ssm-setup-cli
$ sudo /tmp/ssm/ssm-setup-cli -register -activation-code "activation-code" -activation-id "activation-id" -region "ap-northeast-1"
先に S3 インターフェイスエンドポイントを作成していたので、インターネット接続のない閉域オンプレミスからでも SSM Agent のインストールができました。
フリートマネージャーから状態を確認
AWS のマネージメントコンソールに戻って、Sytems Manager のフリートマネージャーからマネージノードにオンプレミスのサーバーが加えられているか確認します。
オンプレミスから S3 エンドポイントへアクセスできることを確認
SSM Agent をインストールし、ハイブリッドアクティベーションに IAM ロールが正しく設定されていれば、Linux の場合 /root/.aws 以下にクレデンシャルがファイルに記録されています。
以下のコマンドで、クレデンシャルの内容である aws_access_key_id, aws_secret_access_key, aws_session_token の値が確認できます。
$ sudo more /root/.aws/credentials
これを実行ユーザーのホームディレクトリの .aws 以下にコピーするか、root にスイッチして AWS CLI を叩けば、クレデンシャルを使って IAM ロールで許可されている AWS リソースへアクセスすることができます。
以下のとおり、AWS CLI から S3 へアクセスできることが確認できました。
$ sudo su
$ aws s3 ls --region ap-northeast-1
まとめ
以上のとおり、VPC エンドポイント経由で Systems Manager を使うことで、プライベート CA を立てなくても閉域オンプレミスから AWS リソースへアクセスするためのクレデンシャルを取得することができました。
ただし Sytems Manager を使う方法は、アクティベーションが 30 日以内に切れるため、別途これを更新する方法を考えなければなりません。
最初に挙げた他の方法も含めて、S3 に閉域オンプレミスからアクセスするのは手間がかかり過ぎるので、コスト増が許容できるのであれば、Transfer Family の SFTP で S3 バケットのデータにアクセスする方が楽だと思います。
ガバメントクラウドの移行で、オンプレミスに残るシステムから S3 にアクセスする方法について悩んでいる方の参考になれば幸いです。
最後に Gov-JAWS の告知
公共分野の JAWS-UG である "Gov-JAWS" が誕生しました！早速第 1 回が 2025 年 4 月 24 日（木）19 時から、「中央省庁/自治体のAWS移行事例」をテーマに開催されます。
Gov-JAWSは公共分野のAWS利用に興味・関心を持つエンジニア＋行政に関わる関連組織の方のためのJAWS-UGです。
近年、政府のクラウド利用方針が示され、ガバメントクラウドをはじめとした公共分野でのAWS利用が急速に進んでいます。 Gov-JAWSはこの動向に対応し、公共分野のクラウド利用に興味・関心を持つエンジニア、行政に関わる関連組織の方々とAWSの知見/ノウハウをオープンかつポジティブに共有する勉強会を開催していきます。
※公共分野：中央省庁、地方公共団体をはじめとする国や地方公共団体に関連する領域を指す。
公共分野の AWS 活用について興味のある方はぜひよろしくお願いします！