AWS環境上に構築したWebシステムのフロントにSaaSサービスを用いる場合の検討ポイントについて
はじめに
近年、AWS上にWebシステムを構築する際、SaaSサービスをフロントエンドに配置するアーキテクチャが増えています。これらのSaaSサービスは、主にDDoS対策、WAF機能、CDN機能などのセキュリティ・パフォーマンス向上を目的として導入されます。
しかし、AWS環境とSaaSサービスを組み合わせる際には、セキュリティ、運用、可用性の観点から事前に検討すべき重要なポイントが存在します。本記事では、SaaSサービスとAWSを適切に組み合わせるための検討ポイントを具体的に解説します。
想定するシステム構成
本記事では、以下のようなシステム構成を前提として解説を進めます。
この構成では、CloudFrontがAWS環境のフロントエンドとして機能し、SaaSサービスからの通信を受け付けます。CloudFrontの背後には、静的コンテンツを配信するS3と、動的コンテンツを処理するALB+コンピューティングリソース（EC2/ECS等）が配置されています。
AWSのみ vs SaaS+AWS：アーキテクチャパターンの比較
Webシステムのフロントエンド構成には、大きく分けて「AWSサービスのみで構成するパターン」と「SaaSサービスとAWSを組み合わせるパターン」の2つがあります。それぞれのメリット・デメリットを理解し、システム要件に応じて適切なパターンを選択することが重要です。
パターン1：AWSサービスのみで構成
メリット
| 観点 | 詳細 |
|---|---|
| 統合管理の容易性 | すべてのリソースをAWSマネジメントコンソールやIaCツール（CloudFormation、Terraform等）で一元管理できる |
| コスト効率 | 追加のSaaSサービス利用料が不要。特に中小規模のトラフィックでは、AWSのみの方がコストを抑えられる可能性が高い |
| レイテンシの最適化 | 外部SaaSサービスを経由しないため、通信経路が短くレイテンシを最小限に抑えられる |
| 柔軟なカスタマイズ | AWS WAF、Lambda@Edge、CloudFront Functionsなどを使用して、独自のロジックを柔軟に実装できる |
| データ主権の明確性 | データがAWSのリージョン内に留まるため、コンプライアンス要件を満たしやすい |
| ベンダーロックインの回避 | 特定のSaaSベンダーへの依存がなく、将来的な変更が比較的容易 |
パターン1のデメリット
| 観点 | 詳細 |
|---|---|
| 高度なセキュリティ機能の実装コスト | 大規模DDoS対策、高度なボット検知、WAFルールのチューニングなどを自前で実装・運用する必要があり、専門知識と工数が必要 |
| グローバル展開の複雑性 | CloudFrontは世界中にエッジロケーションを持つが、一部の地域ではSaaS CDNの方が優れたパフォーマンスを発揮する場合がある |
| DDoS攻撃への対応 | AWS Shield Standardは自動で有効だが、高度な攻撃にはShield Advancedの契約（月額約3,000ドル〜）が必要 |
| 運用負荷 | セキュリティイベントの監視、WAFルールの更新、脅威インテリジェンスの適用など、継続的な運用タスクが発生 |
| 専門人材の確保 | セキュリティ専門家やAWSアーキテクトの確保・育成が必要 |
パターン1が向いているケース
- 中小規模のトラフィックを扱うシステム（月間数TB程度まで）
- コスト最適化を重視するプロジェクト
- AWS環境に精通したチームがあり、自前での運用が可能
- 厳格なデータ主権要件があり、データを特定のAWSリージョン内に留める必要がある
- 高度なカスタマイズが必要で、AWSサービスの柔軟性を最大限活用したい
- スタートアップやMVP段階で、まずはシンプルな構成から始めたい
パターン2：SaaSサービスとAWSを組み合わせる
パターン2のメリット
| 観点 | 詳細 |
|---|---|
| 高度なセキュリティ機能 | SaaSベンダーが提供する最新の脅威インテリジェンス、機械学習ベースのボット検知、ゼロデイ攻撃対策などを即座に利用できる |
| 大規模DDoS対策 | テラバイト級の大規模DDoS攻撃にも対応できる、SaaSベンダーがグローバルに展開している場合にはそのグローバルネットワークを活用できる |
| 運用負荷の軽減 | セキュリティルールの自動更新、24/7のSOC（Security Operations Center）サービスなど、運用の多くをベンダーに委託できる |
| グローバルパフォーマンス | 例えばAkamaiなどであれば歴史と実績のあるCDNネットワークにより、世界中で最適化されたコンテンツ配信が可能 |
| 専門知識の活用 | セキュリティ専門家を自社で確保せずとも、ベンダーの専門知識を活用できる |
| スケーラビリティ | 突発的な大規模トラフィック増加にも、SaaSサービスのキャパシティで対応可能 |
| コンプライアンス認証 | PCI DSS、ISO 27001など、SaaSベンダーが取得している各種認証を活用できる |
パターン2のデメリット
| 観点 | 詳細 |
|---|---|
| コスト増加 | SaaSサービスの利用料が追加で発生 |
| 管理の複雑性 | AWS環境とSaaSサービスの両方を管理する必要があり、設定ミスや連携不備のリスクが増加 |
| レイテンシの増加 | SaaSサービスを経由するため、数ミリ〜数十ミリ秒のレイテンシが追加される可能性がある |
| ベンダーロックイン | 特定のSaaSサービスに依存すると、将来的な変更が困難になる可能性がある |
| トラブルシューティングの複雑化 | 障害発生時、AWS側かSaaS側か原因の切り分けが必要になり、対応が複雑化する |
| データの経由 | データが第三者（SaaSベンダー）のネットワークを経由するため、一部のコンプライアンス要件に抵触する可能性がある |
パターン2が向いているケース
- 大規模トラフィックを扱うシステム（月間数十TB以上）
- 高度なセキュリティ要件があり、最新の脅威対策が必須
- グローバル展開しており、世界中で高パフォーマンスが求められる
- 24/7の運用体制を自社で構築するのが困難
- コンプライアンス認証（PCI DSS等）を迅速に取得する必要がある
- 大規模DDoS攻撃のリスクが高い業界（金融、eコマース、ゲームなど）
- エンタープライズ企業で、セキュリティへの投資が十分にある
- 専門人材の確保が困難で、外部の専門知識を活用したい
ハイブリッドアプローチの検討
実際のシステム設計では、完全にどちらか一方に決める必要はありません。例えば、以下のようなハイブリッドアプローチも有効です：
- 段階的な導入: 初期はAWSのみで構築し、トラフィックやセキュリティ要件の増加に応じてSaaSサービスを追加
- 環境別の使い分け: 本番環境にはSaaSサービスを導入し、開発・ステージング環境はAWSのみで構成してコストを最適化
- 機能別の選択: WAF機能はSaaSサービス、CDN機能はCloudFrontというように、機能ごとに最適なサービスを選択
判断基準のまとめ
どちらのパターンを選択すべきか迷った場合、以下の判断基準を参考にしてください：
| 判断要素 | AWSのみを推奨 | SaaS+AWSを推奨 |
|---|---|---|
| 月間トラフィック量 | 〜数TB | 数十TB以上 |
| 予算 | 限られている | 十分な投資が可能 |
| セキュリティ要件 | 標準的 | 非常に高い（金融、医療等） |
| 運用体制 | AWSエンジニアが充実 | セキュリティ専門家の確保が困難 |
| グローバル展開 | 国内・地域限定 | 世界中に展開 |
| レイテンシ要件 | 極めて厳しい（ミリ秒単位） | 多少の余裕がある |
| カスタマイズ要件 | 高度なカスタマイズが必要 | 標準機能で十分 |
| DDoS攻撃リスク | 低〜中 | 高（攻撃対象になりやすい） |
セキュリティ観点での検討ポイント
1. 通信元の制限によるセキュリティ担保
SaaSサービスをフロントに配置する場合、AWS環境（CloudFront）はSaaSサービス以外からの通信を拒否する制御を実装することが重要です。これにより、SaaSサービスのセキュリティ機能をバイパスした直接攻撃を防ぐことができます。
実装方法
| 実装箇所 | 実装方法 | 備考 |
|---|---|---|
| CloudFront | カスタムヘッダーによる検証 | SaaSサービスから付与される特定のヘッダーをOriginもしくはLambda@Edgeなどで検証 |
| AWS WAF | IPアドレス制限 | SaaSサービスのIPレンジのみ許可 |
| Security Group | インバウンドルール設定 | CloudFrontからのトラフィックのみ許可 |
具体的な実装例：
SaaSサービス側で以下のようなカスタムヘッダーを設定します：
X-Custom-Secret: <ランダム文字列>
CloudFrontのオリジン(ALB)側やLambda@Edgeで、AWS WAFのカスタムルールでこのヘッダーの存在と値を検証します。ヘッダーが一致しない場合はリクエストをブロックすることで、SaaSサービスを経由しない直接アクセスを防止できます。
2. 多層防御の重要性
SaaSサービスを導入したからといって、それだけでセキュリティ対策が完了するわけではありません。 AWS環境側でも適切なセキュリティ対策を実装し、多層防御の考え方でシステム全体を保護することが必要です。
AWS側で実装すべきセキュリティ対策
- AWS WAF: アプリケーション層での攻撃検知・防御
- AWS Shield: DDoS攻撃からの保護（特にStandard版は無料で有効）
- VPC Security Group: ネットワーク層でのアクセス制御
- Amazon GuardDuty: 脅威検知とインシデント対応
- AWS Secrets Manager: 認証情報の安全な管理
SaaSサービスはあくまで"第一の防御線"として位置づけ、AWS環境内でも独立したセキュリティ対策を講じることで、万が一SaaSサービス側で攻撃が通過した場合でも被害を最小限に抑えることができます。
また、業務通信部分だけでなくAWS IAMの適切な利用等、AWS環境を適切に管理することももちろん重要です。ここについてはSaaSサービス導入等とは別次元の話と考えましょう。
運用観点での検討ポイント
3. トレーサビリティの確保
SaaSサービスを経由する通信において、送信元の特定や通信の一意識別が可能な情報を含めることで、障害発生時の原因調査やセキュリティインシデント対応を円滑に行うことができます。
カスタムHTTPヘッダーの活用
SaaSサービス側でカスタムヘッダを付与することができる場合には、バックエンドとなるAWS環境に対して以下のようなカスタムヘッダーを付与することで運用性を高めることが可能です。
| ヘッダー名 | 用途 | 設定例 |
|---|---|---|
| X-Request-ID | リクエストの一意識別 | UUID形式 |
| X-Edge-Location | SaaSサービスのエッジロケーション | 地域コード |
| X-Client-IP | 実際のクライアントIPアドレス | IPv4/IPv6アドレス |
| X-Forwarded-For | プロキシチェーン情報 | カンマ区切りのIPリスト |
これらの情報をCloudWatch LogsやALBのアクセスログに記録することで、エンドツーエンドでのトレーサビリティが確保できます。
4. オブザーバビリティ製品との連携
New Relic、Datadog、Dynatraceなどのオブザーバビリティ製品を現在利用している、または将来的に導入を検討している場合、SaaSサービス側も同じオブザーバビリティ製品に対応しているかを製品選定時に確認することが重要です。
特にフロントにSaaSサービスを活用するようなケースは大規模で複雑なシステムとなっているケースも多くあります。そういうシステムではオブザーバビリティ製品を活用したくなることも多いかと思いますので、SaaSサービスを利用開始する時点でそこまで考慮して製品選定することが望ましいと思います。
確認すべきポイント
- SaaSサービスがオブザーバビリティ製品のエージェントやAPIに対応しているか
- メトリクス、ログ、トレースの各データを統合して可視化できるか
- SaaSサービス側のパフォーマンスデータ（レイテンシ、スループット等）を取得できるか
- アラート設定やダッシュボード作成が柔軟に行えるか
統合されたオブザーバビリティ環境を構築することで、SaaSサービスからAWS環境に至るまでの全体的なシステムの健全性を一元的に監視・分析できるようになります。
可用性観点での検討ポイント
5. SaaSサービス自体の可用性確保
AWS環境は、マルチAZ構成やAuto Scalingなどの機能により高い可用性を比較的容易に実現できます。しかし、SaaSサービスがボトルネックとなり、システム全体の可用性が低下するリスクもあります。
製品選定時にチェックすべき項目
| 項目 | 確認内容 | 望ましい基準 |
|---|---|---|
| SLA | サービスレベル保証の内容 | 99.9%以上の稼働率保証 |
| 冗長性 | 複数データセンター、マルチリージョン対応 | グローバルに分散配置されたエッジロケーション |
| フェイルオーバー | 障害時の自動切替機能 | 自動フェイルオーバーが実装されている |
| 過去の障害実績 | サービス障害の頻度と影響範囲 | 公開されている障害情報を確認 |
| バックアップ経路 | SaaSサービス障害時の代替経路 | 直接CloudFrontにアクセス可能な緊急用経路の確保 |
特に重要なのは、SaaSサービスで障害が発生した場合の緊急対応手順を事前に策定しておくことです。例えば、DNSの切り替えによりSaaSサービスをバイパスしてCloudFrontに直接アクセスする経路を用意しておくなどの対策が考えられます。
（但しCloudFrontに直接アクセスする経路を用いて通信している間はSaaSサービスが提供している価値を享受できないため、あくまでも緊急時のものと考えて下さい）
パフォーマンス観点での検討ポイント
6. レイテンシの増加への対処
SaaSサービスを経由することで、エンドユーザーからAWS環境までの通信経路が長くなり、レイテンシが増加する可能性があります。
対策
- SaaSサービスのエッジロケーション: ユーザーに地理的に近いエッジロケーションを持つサービスを選択
- Keep-Alive接続: SaaSサービスとCloudFront間でHTTP Keep-Aliveを有効化し、TCP接続の再利用を促進
- キャッシュ戦略の最適化: SaaSサービス側とCloudFront側の両方でキャッシュ設定を適切に行い、オリジンへのアクセスを削減
- HTTP/2、HTTP/3の活用: 最新のプロトコルを使用してパフォーマンスを向上
7. コスト最適化
SaaSサービスとAWS環境の両方でデータ転送料金が発生するため、コスト最適化の観点からキャッシュ戦略を見直すことが重要です。
- SaaSサービス側のキャッシュTTLを適切に設定し、CloudFrontへのリクエスト数を削減
- CloudFrontのPrice Classを調整し、必要な地域のみにコンテンツを配信
- S3への直接アクセスを避け、必ずCloudFront経由でアクセスさせることでデータ転送コストを最適化
その他の考慮事項
8. コンプライアンスとデータ所在地
SaaSサービスを利用する場合、データがどの地域のデータセンターを経由するかを確認することが重要です。特に、個人情報保護法やGDPR等の規制がある業界では、データの所在地が法的要件を満たしているかを確認する必要があります。
9. ベンダーロックインの回避
特定のSaaSサービスに依存しすぎないよう、抽象化レイヤーを設けたり、複数のSaaSサービスに対応可能な設計とすることで、将来的なサービス変更を容易にすることができます。
まとめ
AWS環境上に構築したWebシステムのフロントにSaaSサービスを配置する場合、以下の検討ポイントを押さえることが重要です：
- セキュリティ: SaaSサービス以外からの通信を制限し、AWS側でも多層防御を実装
- トレーサビリティ: カスタムHTTPヘッダーによる通信の識別・追跡
- オブザーバビリティ: 既存・将来の監視ツールとの連携可能性を確認
- 可用性: SaaSサービス自体のSLAと障害時の対応策を事前に検討
- パフォーマンス: レイテンシ増加への対策とキャッシュ戦略の最適化
- コンプライアンス: データ所在地と法的要件の確認
SaaSサービスの導入はセキュリティとパフォーマンスの向上に大きく寄与しますが、それ単体では完全なソリューションとはなりません。AWS環境側も含めた全体最適の視点で設計・運用を行うことで、安全で高可用性なシステムを実現できます。
本記事で紹介した検討ポイントを参考に、自社のシステム要件に合わせた最適なアーキテクチャを構築していただければ幸いです。