Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
全通信要件をカバーできる!?AWS TransferFamilyのネットワークアーキテクチャ
Search
まちや
August 06, 2026
65
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
全通信要件をカバーできる!? AWS TransferFamilyの ネットワークアーキテクチャ
TransferFamliy のエンドポイントで
全通信要件をカバーできるエンドポイントはないけど
工夫すれば非推奨で制約があるけど一応できるよって話です。
まちや
August 06, 2026
More Decks by まちや
See All by まちや
AWSとオンプレミスをセキュアにつなぐ勘所
masa_my
5
710
Featured
See All Featured
Reality Check: Gamification 10 Years Later
codingconduct
0
2.2k
Embracing the Ebb and Flow
colly
88
5.1k
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
66
57k
Color Theory Basics | Prateek | Gurzu
gurzu
0
410
Java REST API Framework Comparison - PWX 2021
mraible
34
9.6k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.5k
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
11k
Keith and Marios Guide to Fast Websites
keithpitt
413
23k
Facilitating Awesome Meetings
lara
57
7.1k
Raft: Consensus for Rubyists
vanstee
141
7.6k
Scaling GitHub
holman
464
140k
Code Review Best Practice
trishagee
74
20k
Transcript
全通信要件をカバーできる!? AWS TransferFamilyの ネットワークアーキテクチャ まちや
自己紹介 まちや (町屋 真隆) • 社会人歴:5年目 • 趣味:バンド(ギター) サウナ(ルーマプラザおすすめ!) •
好きな技術:ネットワーク、クラウド • 好きなAWSサービス:Amazon VPC
TransferFamily • フルマネージド型のファイル 転送サービス • 対応プロトコル • SFTP • FTPS
• FTP • AS2
TranferFamilyの エンドポイントについて
①パブリック エンドポイント ポイント ・インターネット通信のみ ・固定IP付与できない ・SFTPのみ対応 AWS Transfer Family の設計や導入を検討する際に、設定項目や構成例などの把握すべきポイントをまとめてみた
| DevelopersIO
②VPC(内部向け)エンドポイント ポイント ・インターネット通信不可 ・プロトコルはすべて対応可能 AWS Transfer Family の設計や導入を検討する際に、設定項目や構成例などの把握すべきポイントをまとめてみた | DevelopersIO
③VPC(インターネット向け)エンドポイント ポイント ・通信方式は すべて対応可能 ・固定IP付与可能 ・プロトコルはFTPがNG AWS Transfer Family の設計や導入を検討する際に、設定項目や構成例などの把握すべきポイントをまとめてみた
| DevelopersIO
要件:すべてカバーしたい プロトコル ネットワーク FTP インターネット File Transfer Protocol FTPS FTP
over SSL/TLS SFTP SSH File Transfer Protocol Public Internet × VPN Site-to-Site VPN 専用線 Direct Connect
TransferFamilyのエンドポイント エンドポイントタイプ SFTP FTPS FTP パブリック 〇 × × VPC(内部向け)
〇 〇 〇 VPC(インターネット向け) 〇 〇 × エンドポイントタイプ インターネット VPN 専用線 パブリック 〇 × × VPC(内部向け) × 〇 〇 VPC(インターネット向け) 〇 〇 〇
TransferFamilyのエンドポイント エンドポイントタイプ SFTP FTPS FTP パブリック 〇 × × VPC(内部向け)
〇 〇 〇 VPC(インターネット向け) 〇 〇 × エンドポイントタイプ インターネット VPN 専用線 パブリック 〇 × × VPC(内部向け) × 〇 〇 VPC(インターネット向け) 〇 〇 〇
TransferFamilyのエンドポイント エンドポイントタイプ SFTP FTPS FTP パブリック 〇 × × VPC(内部向け)
〇 〇 〇 VPC(インターネット向け) 〇 〇 × エンドポイントタイプ インターネット VPN 専用線 パブリック 〇 × × VPC(内部向け) × 〇 〇 VPC(インターネット向け) 〇 〇 〇
全カバーできる エンドポイントがない・・・
FTPを捨てるorインターネット 通信を捨てるしかなくないか?
そんなことなかった ※条件付き
当時の設計アプローチから
全プロトコルはカバーしたいから エンドポイントはVPC(内部向け)にする
異なるNWなのに1つのVPCに依存は 良くない!
VPCを分ける
VPC間をPrivateLinkで接続することで インターネット通信も可能に!!
でも実は・・・ NLB を Transfer Family の前段に置くことは 非推奨 その理由 ・コスト増加 ・クライアント
IP が正確に見えない ・ FTPS の同時接続数が 10,000 → 300 に激減 https://docs.aws.amazon.com/ja_jp/transfer/latest/userguide/infrastructure-security.html それでもやった理由 全通信要件をカバーするにはこの構成しかなかった
まとめ 1. Transfer Family のエンドポイントには制約がある FTP × インターネット通信は単一エンドポイントでは満たせない 2. PrivateLink
+ VPC 分離構成で全要件を突破できる VPC 内部向けエンドポイント+ネットワーク別専用 VPC + PrivateLink の組み合わせ 3. 公式非推奨でも、全要件カバーにはこれしかなかった