既存システムと連携する静的サイト基盤の設計・構築

企業の共通AWS基盤上に、LPを公開するための静的サイト基盤を設計・構築しました。既存システムのフォーム受付・メール送信機能を利用する構成とし、基盤管理者や開発チームと設定・作業範囲を調整しています。

支援領域： AWS設計・構築、既存システムとの接続調整、配信設定・検証

対象： フォーム連携を伴うLP公開基盤

主要な配信・連携経路を抜粋した概略図

共通基盤の運用ルールを踏まえた追加構築

公開環境は、企業の共通AWS基盤と既存システムのアカウントにまたがる構成でした。配信基盤や証明書・DNSは基盤管理者への申請で用意し、提供後の設定とS3への接続を進める必要がありました。

担当範囲と構築順序を整理し、申請に必要な情報の準備から、提供されたリソースの設定・検証まで対応しました。既存システム側の変更は管理ベンダーと調整し、管理方法に沿って引き継ぐ方針としています。

LP配信と既存バックエンド連携の構成

LPの静的コンテンツはS3に保存し、CloudFrontを通じて配信する構成にしました。S3への公開アクセスは遮断し、CloudFrontからのアクセスを許可することで、配信経路を限定しています。

フォーム送信はLPの配信経路と分け、ブラウザから既存バックエンドへ接続します。既存の受付・メール送信機能を共用し、LP側に新たなアプリケーションサーバーを持たない構成です。

構築時に重視したこと

既存システムとの接続を調整

LPとフォーム送信先のドメインが異なるため、ブラウザからの通信を許可するCORS設定を整えました。LPのオリジンと必要なメソッド・ヘッダーに合わせて設定し、プリフライト応答と許可対象外オリジンの扱いを確認しています。

既存のレスポンスヘッダーポリシーを変更する際は、他の設定を保持し、変更前のバックアップと差分確認を行う手順にしました。共有リソースへの変更範囲を確認したうえで作業を進めています。

静的サイトのURLと更新時の挙動を整備

ディレクトリ形式のURLでもページを表示できるよう、CloudFront Functionsの関数コードを作成しました。末尾スラッシュへのリダイレクトと、S3上のファイル名に合わせた index.html の補完を行う処理です。

また、CloudFrontのキャッシュ無効化後もブラウザに古い内容が残る問題を踏まえ、ブラウザへ再検証を促すレスポンスヘッダー設定を用意しました。配信側のキャッシュとブラウザ側のキャッシュを分けて扱い、更新時の挙動を整理しています。

公開範囲とコンテンツの復元に配慮

HTTPSへのリダイレクトやセキュリティヘッダーに加え、開発環境だけに検索避けのヘッダーを付ける設定を整備しました。同じコンテンツを使いながら、環境ごとの公開条件をインフラ側で分けています。

コンテンツの誤上書きに備え、S3のバージョニングと保持期間・世代数の設定を用意しました。アクセスログは別バケットへ保存し、保存期間を過ぎたログを削除する構成です。

設定と検証の手順をコードに残す

構築・設定用のスクリプトと、CloudFrontやCORSの状態を確認する検証スクリプトを整備しました。環境ごとの値を分離し、設定漏れや接続先の取り違えを確認しながら作業できる形にしています。

Markshipの担当範囲

• LP公開基盤の構成設計と構築手順の整理
• 共通基盤への申請情報の準備・設定調整
• S3の構築とCloudFrontからのアクセス設定
• 既存バックエンドとのCORS接続調整・検証
• URL補完用の関数コードと配信ヘッダー設定の整備
• 構築・設定・検証スクリプトの作成