富士通Japan株式会社 Public & Education事業本部
クラウドサービス事業部 の 吉村 康良 です。
令和3年度ガバメントクラウド先行事業からガバメントクラウドを利用したインフラストラクチャの設計に従事し、現在は主にガバメントクラウド上のインフラの運用保守を担当しています。
はじめに
本記事の想定読者は、ガバメントクラウドのAWS上にオブジェクトストレージを利用したファイル連携機能の構築担当者や、構築されたオブジェクトストレージとのSFTP連携の実装担当者となります。
地方公共団体の基幹業務システムの統一・標準化 の 共通機能の標準仕様 の一つである「ファイル連携に関する詳細技術仕様書」にはオブジェクトストレージを利用したファイル連携と、オブジェクトストレージを利用したファイル連携が困難な場合において、ファイルサーバでのファイル連携の2つの方式が記載されています。
ここで、「連携先と連携方式を合わせないといけない」「AWS Transfer Familyを利用しているがバケット名の接尾辞がバケット作成ベンダ毎に異なり、アプリケーション側でパスを合わせないといけない」といった課題に直面したことはありませんか？
この記事では、AWS Transfer Family の「論理ディレクトリ」機能に焦点を当て、これらの課題を解決し、ファイル連携環境を構築する方法を、具体的な設定例とともに解説します。
AWS Transfer Family とは？
AWS Transfer Family は、フルマネージド型のサービスです。SFTP、FTPS、FTP、およびAS2経由で AWS ストレージサービスと直接ファイル転送でき、今回の対象であるオブジェクトストレージの Amazon S3 へファイルを保存することができます。
論理ディレクトリ とは？
AWS Transfer Family の論理ディレクトリ機能は、ユーザーが SFTP/FTPS/FTP クライアントから見たファイルシステム上のパスと、実際のS3バケットまたはEFSのパスをマッピングする機能です。
これにより、S3バケット名のベンダ毎の差を気にすることなく、アプリケーションに見せるディレクトリ構造を定義できます。
ユースケース例
例えば、住民記録システムと児童手当システムの連携用 S3バケット 011002-0001-0027 の中に、以下のパスがあります。
※自治体コードについては仕様書に合わせているのみであり、該当自治体について担当しているわけではございません。
011002-0001-0027/
├── 0027/ ※住民記録システムから児童手当システムへファイルを送信する場合に利用
│ └── rireki/
└── 0001/ ※児童手当システムから住民記録システムへファイルを送信する場合に利用
└── rireki/
Transfer Familyで論理ディレクトリ未設定の場合、SFTPクライアントからは以下の階層のとおり、バケット名を含む、バケットと同じパスで見えます。
/
└ 011002-0001-0027/
├── 0027/ ※住民記録システムから児童手当システムへファイルを送信する場合に利用
│ └── rireki/
└── 0001/ ※児童手当システムから住民記録システムへファイルを送信する場合に利用
└── rireki/
論理ディレクトリを使えば、以下のようにファイルサーバの連携フォルダの仕様に合わせたファイル連携環境を提供できます。
-
住民記録システムには、SFTPクライアントから/0001/0027/というパスでアクセスさせ、実際にはS3バケット011002-0001-0027/0027/にファイルをアップロードさせる。 -
児童手当システムには、SFTP クライアントから/0001/0027/というパスでアクセスさせ、実際にはS3バケット011002-0001-0027/0027/内の住民記録システムがアップロードしたファイルをダウンロードさせる。 -
児童手当システムには、SFTP クライアントから/0027/0001/というパスでアクセスさせ、実際にはS3バケット011002-0001-0027/0001/にファイルをアップロードさせる。 -
住民記録システムには、SFTP クライアントから/0027/0001/というパスでアクセスさせ、実際にはS3バケット011002-0001-0027/0001/内の児童手当システムがアップロードしたファイルをダウンロードさせる。
/
├ 0001/
│ └── 0027/ ※住民記録システムから児童手当システムへファイルを送信する場合に利用
│ │ （実際にはS3バケット 011002-0001-0027/0027/）
│ └── rireki/
└ 0027/
└── 0001/ ※児童手当システムから住民記録システムへファイルを送信する場合に利用
│ （実際にはS3バケット 011002-0001-0027/0001/）
└── rireki/
これにより、仕様書の連携フォルダ構成に準拠でき、システムはS3バケット名を意識する必要が無くなります。
また、一方のシステムがオブジェクトストレージを利用した連携方式、もう一方のシステムがファイルサーバを利用した連携方式の場合でもシームレスにファイル連携を行うことができます。
-
児童手当システムには、オブジェクトストレージを利用した連携方式でS3バケット011002-0001-0027/0001/にファイルをアップロードさせる。 -
住民記録システムには、SFTP クライアントから/0027/0001/というパスでアクセスさせ、実際にはS3バケット011002-0001-0027/0001/内の児童手当システムがアップロードしたファイルをダウンロードさせる。
論理ディレクトリの設定方法
ここからは、実際にAWS Transfer Family のサーバーで論理ディレクトリを設定する手順を見ていきましょう。
前提条件
- AWS Transfer Family サーバーが作成済みであること。
- S3バケットが作成済みであること。
- Transfer Family ユーザーを認証するための IAMロールが作成済みであること。このIAMロールには、S3へのアクセス権限（
s3:PutObject,s3:GetObject,s3:ListBucketなど）が必要になります。
1. IAMポリシーの準備
Transfer Family ユーザーが利用するIAMロールに、論理ディレクトリを定義するためのポリシーを付与します。
例えば、児童手当システム用のTransfer Family ユーザーが /0027/0001/ というパスでアクセスし、S3バケット 011002-0001-0027/0001/ にファイルをアップロードでき、/0001/0027/ というパスでアクセスさせ、S3バケット 011002-0001-0027/0027/ からファイルをダウンロードするようにする場合、IAMポリシーのサンプルは以下のようになります。
実際には複数の業務システム分を記載いただくか、ワイルドカードで記載を簡略化できます。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion",
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:PutObjectTagging",
"s3:GetObjectTagging"
],
"Resource": [
"arn:aws:s3:::011002-0001-0027/0001",
"arn:aws:s3:::011002-0001-0027/0001/*",
"arn:aws:s3:::011002-0001-0027/0027",
"arn:aws:s3:::011002-0001-0027/0027/*"
],
"Effect": "Allow"
}
]
}
ワイルドカードで記載する場合は、バケット名の命名として システム区分と業務ID又は独自施策システム等IDを合わせた4桁の数字の小さい方を先にすること と仕様で定義されているため、先でも後でも対応できるように記載します。
{
"Version": "2012-10-17",
"Statement": [
{
"Action": [
"s3:PutObject",
"s3:PutObjectAcl",
"s3:GetObject",
"s3:DeleteObjectVersion",
"s3:DeleteObject",
"s3:GetObjectVersion",
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:PutObjectTagging",
"s3:GetObjectTagging"
],
"Resource": [
"arn:aws:s3:::011002-????-0027/????",
"arn:aws:s3:::011002-????-0027/????/*",
"arn:aws:s3:::011002-0027-????/????",
"arn:aws:s3:::011002-0027-????/????/*"
],
"Effect": "Allow"
}
]
}
2. Transfer Family ユーザーの作成または更新
次に、Transfer Family のユーザー設定で論理ディレクトリを定義します。
Home Directory Type: LOGICAL を選択します。
Home Directory Mappings: ここで、論理ディレクトリのマッピングを設定します。
- 住民記録システムの例
※実際には連携システム分のすべてを記載する必要があります。
| Entry (SFTPクライアントから見えるパス) | Target (S3の実パス) |
|---|---|
/0001/0027 |
/011002-0001-0027/0027 |
/0027/0001 |
/011002-0001-0027/0001 |
AWS CLI を使用する場合は、create-user または update-user コマンドで --home-directory-type と --home-directory-mappings を指定します。
aws transfer create-user \
--user-name User0001 \
--server-id s-11112222333344445 \
--role arn:aws:iam::1234abcd5678:role/transfer-user0001-role \
--home-directory-type LOGICAL \
--home-directory-mappings "[{\"Entry\":\"/0001/0027\", \"Target\":\"/011002-0001-0027/0027\"}, {\"Entry\":\"/0027/0001\", \"Target\":\"/011002-0001-0027/0001\"}]" \
--ssh-public-key-body file://･･･
aws transfer update-user \
--user-name User0001 \
--server-id s-11112222333344445 \
--home-directory-type LOGICAL \
--home-directory-mappings "[{\"Entry\":\"/0001/0027\", \"Target\":\"/011002-0001-0027/0027\"}, {\"Entry\":\"/0027/0001\", \"Target\":\"/011002-0001-0027/0001\"}]" \
CloudFormation を利用する場合は HomeDirectoryType と HomeDirectoryMappings を指定します。
Type: AWS::Transfer::User
Properties:
HomeDirectoryMappings:
- Entry: /0001/0027
Target: /011002-0001-0027/0027
- Entry: /0027/0001
Target: /011002-0001-0027/0001
HomeDirectoryType: LOGICAL
Role: arn:aws:iam::1234abcd5678:role/transfer-user0001-role
ServerId: s-11112222333344445
SshPublicKeys:
- String
UserName: User0001
Targetのパスは、S3バケット名から始まるフルパスで記述します。
バケット名に接尾辞が付く場合で 011002-0001-0027-prod であれば、/011002-0001-0027-prod/0027 のように指定します。
動作確認
SFTPクライアントを使用して、作成したユーザーで AWS Transfer Family サーバーに接続します。
- ログイン後、
lsコマンドを実行すると/0001/0027と/0027/0001が表示されることを確認します。 -
cd /0001/0027で/0001/0027ディレクトリに移動できることを確認します。 -
put local_file.txtでファイルをアップロードし、S3の011002-0001-0027/0027/にファイルが作成されていることを確認します。 -
/0027/0001/ディレクトリ内のファイルをget remote_file.txtでダウンロードできることを確認します。※remote_file.txtは事前にS3の011002-0001-0027/0001/に格納する必要があります。
論理ディレクトリの注意点
-
マッピングの制限: サービスマネージドユーザーの場合は最大2,000エントリのマッピングのサポートとなります（2026年3月8日時点）。
連携先業務1つにつき2エントリが基本と考えられ、1,000個の連携先まで対応できる制限のため、運用上は十分足りると考えます。
詳細は以下のリンク先の論理ディレクトリを使用する際のルールを参照ください。
まとめ
今回、以下について解説いたしました。
- AWS Transfer Family の論理ディレクトリ機能について
- 論理ディレクトリ機能によるファイルサーバ利用の仕様に準拠できること
- 論理ディレクトリ機能の具体的な設定方法
論理ディレクトリを活用することで、S3バケット名に依存しない、ファイルサーバのファイル連携仕様でのファイル連携環境を構築できます。
これにより、アプリケーションのデータ連携設計をより容易に行うことが可能になります。
AWS Transfer Family と論理ディレクトリを使い、連携方式に関わらずオブジェクトストレージを利用したシームレスな連携の実現の参考になれば幸いです。