例えば広告やトラッキング系のSaaSツールを自社ドメインで配信したいといったユースケースがあります
クライアント -> 自社リバースプロキシ -> 3rdParty
とリバースプロキシを運用すれば可能になりますがなかなか面倒です。
すぐに思いつくのはfargate + squidあたりですがセキュリティ、信頼性、運用、コストがのしかかってきます。
たまに各社お手製のリバプロツールを提供していることがありますが結局運用が必要です。
そこで登場するのがCloudFrontです
originを3rdPartyとすることでCloudFrontからアクセスさせれば、
手離れがよく、低コスト高信頼性、余計なことができないのでセキュリティも担保できます。
CloudFrontを例に出していますがCDNならおおよそ可能と思われます。
利用までに重要なのは2点
- リバースプロキシを運用する
- クライアントSDKがあれば向き先をリバースプロキシに変える
CloudFrontの設定
目安です。セキュリティとパフォーマンスを限界まで極めたい方は適宜調整してください。
キャッシュポリシー
利用したいSaaSの仕様によりますが全無効が無難です
オリジンリクエストポリシー
AllViewExceptHostHeaderがよいでしょう
基本的に全部転送しつつ、Hostヘッダーは3rdPartyのものではなくなっているので除外する
レスポンスポリシー
CORS-with-preflight-and-SecurityHeadersPolicy
その他
パスルールを駆使すればdistribution一つで複数ツールに対応できます
好みにもよりますがクライアントサイドを調査しつつ検討
機能としては特定のサブドメインに転送するだけですが必要に応じてログやWAFを設定しましょう
SDK側
proxy設定があるかどうか、あるなら設定方法を一つ一つ調査する必要があります
ツールによってはproxyを通すときだけパスが異なります。
CloudFrontのorigin pathを設定してマッピングしましょう
パスが動的であったりとCloudFrontでのorigin pathだけでは修正不能なら、
ドメインはそのままLambda@edgeでoriginのパスを書き換えます
origin.custom.path
Lambda@edgeは配信方法やIAM権限にクセがあるので未経験の方は適宜記事を検索してください
＊CloudFront Functionsではoriginのパス書き換えはできません。操作できるのはviewerのみ。
CORS
リバプロのサブドメインがアプリケーションと異なるなら結局same-origin policyから見てsame originにはなりません
さいごに
ツールで利用するサブドメインが定まっている場合は検討してみましょう
参考
https://amplitude.com/docs/feature-experiment/advanced-techniques/proxy-requests-to-experiment-with-aws-cloudfront
https://posthog.com/docs/advanced/proxy/cloudfront