こんにちは、SCSK林です！
今回は、AWSで完全にプライベート環境で実現するサーバレスAPI、S3静的ホスティングについて解説します。
エンタープライズ領域だと、クラウド導入の大きな壁となるのが『セキュリティ要件』だと感じています。
- データは絶対にインターネットに出してはならない・・・
- アクセスは専用線やVPN経由の閉域網に限る・・・
などなど、会社ごとに厳格なポリシーをお持ちだと思います。
本来、パブリックなアクセスを前提とするサーバーレスサービスを、いかにして閉域網の中に封じ込め、かつ安全に運用するか。
本記事では、実際に構築した例をベースにアーキテクチャ選定の背景と、構成や技術的に気をつけるポイントについて共有していきたいと思います。
構成の背景（いわゆる要件）
今回想定する割とありがちな（と個人的には思っている）要件は以下のとおりです。
- アクセス経路：ユーザーはオンプレミス環境からのみアクセス可能。インターネットからのアクセスは一切遮断する。
- 運用負荷の軽減：極力EC2などのサーバ管理を廃止し、マネージドサービスを活用したい。
- モダンなUX：SPA（Single Page Application）によるリッチなUIを提供する。
通常、SPAの配信にはAmazon S3の静的ウェブサイトホスティングやAmazon CloudFrontが定石ですが、これらはパブリックアクセスが前提となります。閉域網要件を満たすために、「サーバーレスの利便性」と「ネットワークの閉塞性」をどう両立させるかが、アーキテクチャ設計の肝となります。
アーキテクチャ概要
最終的に採用したアーキテクチャは、ALB (Application Load Balancer) をシステムの唯一の入り口とし、バックエンドのリソースを全てプライベートネットワーク内に配置する構成です。
【構成のポイント】
- アクセス元：オンプレミス環境（Direct Connect / VPN経由）
- 入口：VPC内に配置した Internal ALB
- フロントエンド：ALB → VPC Endpoint (Interface型) → S3 バケット
- バックエンド：ALB → Lambda
この構成により、トラフィックが一切インターネットに出ることなく、AWSのネットワーク内だけで完結するセキュアな通信経路を確立しました。
アーキテクチャのポイント
ALBによる入口の集約
当初、S3やAPI GatewayのVPCエンドポイントを直接クライアントに公開する案もありました。しかし、前段にALBを配置する構成を採用しました。S3やAPI Gatewayのエンドポイントが個別に分散すると、クライアント（オンプレ側）でのDNS設定やファイアウォール設定が複雑化します。ALBを挟むことで以下のメリットを享受できました。
- インターフェースの集約：フロントエンドもAPIも、単一のドメインでアクセス可能にする（パスベースルーティング）。
- セキュリティの一元化：SSL/TLS終端をALBに集約し、証明書管理を一本化。将来的なWAF導入などの拡張性も確保。
Route 53 Resolver によるハイブリッドDNS設計
オンプレミス環境からAWS内のプライベートリソースへアクセスさせる際、大きな技術的課題は「名前解決」です。オンプレミスのDNSサーバーは、AWS内のプライベートIPアドレスをもちろん知りません。
hostsファイル等での個別対応は運用破綻のリスクがあるため、Amazon Route 53 Resolver (Inbound Endpoint) の導入をしています。 オンプレミスのDNSサーバーから、特定ドメインへのクエリをAWS側のResolverにフォワードするハイブリッド構成とすることで、ユーザーはネットワークの境界を意識することなく、シームレスにシステムを利用できるようになりました。
まとめ
今回のプロジェクトを通じて、「閉域網」と「サーバーレス」は決して相容れないものではないことを実証できました。
- セキュリティ：完全プライベートな環境で、企業の厳しいコンプライアンス要件を遵守。
- 運用効率：サーバー（EC2）レスにより、OSパッチ適用などの運用コストを大幅に削減。
単に流行りの技術を使うだけでなく、ビジネス要件という制約の中で、技術をどう組み合わせ、最適な解を導き出すかというアーキテクト視点の重要性を再認識しました。
今後も、技術の理想とビジネスの現実のバランスを取りながら、顧客にとって価値あるクラウド活用を推進していきたいと思います。