builders.flash

マルチテナント Web ホスティングにおける独自ドメインの自動プロビジョニング — 「ロリポップ！AIサイトエージェント」を支える Amazon CloudFront SaaS Manager 活用事例

2026-06-08 | Author : 横尾瑞樹 (GMOペパボ株式会社), 鈴木祥太

はじめに

GMOペパボは「ロリポップ！レンタルサーバー byGMOペパボ」「ムームードメイン byGMOペパボ」「ヘテムル byGMOペパボ」などのレンタルサーバー・ドメインサービスを 20 年以上にわたって運営してきました。私たちはサービスを通じて、インターネット上で表現活動 (アウトプット) に取り組む方々を支援することを大切にしています。その姿勢のもと、いま私たちは生成 AI を活用して「サイトを作る作業を AIと一緒に進められる」新しい体験を届けようとしています。

その第一歩として現在提供しているのが、本記事のテーマである「ロリポップ！AIサイトエージェント」です。チャットで要望を伝えるだけで、AI が Web サイトを生成・編集し、そのまま公開・運用できる SaaS 型のサービスです。

本サービスでは、利用者ごとに異なるドメインで Web サイトを公開できる仕組みが求められます。そのため、マルチテナント環境における CDN・TLS 証明書・ドメイン管理が大きな技術課題となりました。本記事では、それらの課題に対して Amazon CloudFront SaaS Manager をどう活用したかを、アーキテクチャ・実装・運用の 3 つの観点からご紹介します。マルチテナント SaaS や Web ホスティング基盤を設計されている方の参考になれば幸いです。

X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。

今すぐ登録 »

1. 「ロリポップ！AIサイトエージェント」とは

「ロリポップ！AIサイトエージェント」は、チャットで Web サイトを作れる AI エージェント型 SaaS です。ロリポップ！レンタルサーバー byGMOペパボ / ムームードメイン byGMOペパボの利用者を対象に、以下の体験を提供します。

チャットで複数パターンのサイトを生成 : 「カフェのコーポレートサイトを作って」のような自然言語の指示を入力すると、AI が画像つきのサイト案を複数パターン同時に生成。利用者は好みのパターンを選んで利用を始められる
GUI とチャットによる編集 : 選んだサイトはビジュアルエディターで個別セクションを編集できるほか、「予約導線を強化したい」のようなチャット指示で AI に追加生成・差し替えを依頼できる
即時公開 : 生成したサイトはサービス標準のドメイン (.lolipop.website) で即座に公開
独自ドメイン対応 : 利用者が保有する独自ドメイン (例: example.com、shop.example.jp) を割り当て可能。TLS 証明書はサービス側で自動発行・更新

本サービスは、従来「サーバー」と「ドメイン」を提供してきた GMOペパボのホスティング事業に、「サイトそのもの」を生成する新しいレイヤーを加える試みです。利用者がサーバー構成・テンプレート・HTML を意識せずに、自分の Web サイトをすぐに公開できる状態を目指しています。

2. 本サービスにおけるコンテンツ配信の課題

サービスの性質上、利用者が増えるほど公開ドメインの数も比例して増えていくため、コンテンツ配信レイヤーには次のような特徴的な課題がありました。

2-1. 利用者ごとに増え続けるドメインを CDN にどう載せるか

本サービスの公開ドメインは、大きく分けて 2 種類あります。

サービス標準ドメイン : <サブドメイン>.lolipop.website を全利用者に発行 (ワイルドカード)
独自ドメイン : 利用者が任意に持ち込むドメイン (例 : example.com、shop.example.jp)

特に独自ドメインは、利用者が増えるたびに運用中に動的に追加されるという特徴があります。Amazon CloudFront の従来モデルでは、独自ドメインを追加するために次のいずれかが必要でした。

既存の Distribution の Aliases (Alternate Domain Names) にドメインを追加する
テナントごとに新しい Distribution を作成する

前者は Aliases の上限値・更新ごとのデプロイ時間・失敗時の影響範囲がテナント全体に及ぶことが課題になり、後者は AWS アカウント単位の Distribution 数上限・1 つあたりの作成時間・管理対象リソースの肥大化が課題になります。数百 ~ 数千のテナント規模では、どちらの方式でも運用が難しくなります。

SaaS として「ボタンひとつで独自ドメインを登録・公開できる」体験を実現するには、CDN 側のドメイン管理をテナント単位でアトミックに、かつ並列に行えるアーキテクチャが必要でした。

2-2. TLS 証明書の発行・更新のスケーラビリティ

GMOペパボは、共有レンタルサーバー上で 100 万件規模の無料 TLS 証明書を Let's Encrypt で自動発行・更新する仕組みを長年運用してきました。今回もその経験を活かして「AWS Certificate Manager ＋ AWS Lambda で証明書を発行し、Distribution に紐付ける」アプローチも検討しましたが、

証明書発行リクエストから Distribution への紐付け (UpdateDistribution で Aliases と証明書 ARN を組み替える) までを連動させるフローを自前で持つことになる
AWS Certificate Manager の各種クォータ (証明書枚数、リクエストレート) によって、独自ドメインを追加できるペースが制約される
リージョン制約 (Amazon CloudFront 向けは us-east-1) や、テナント増減と証明書・Distribution の整合性管理を含む運用設計が必要

など、本来注力すべき領域とは別の部分にエンジニアリングコストがかかることが見えていました。

私たちが解きたいのは「AI が生成したサイトを、利用者の独自ドメインで安全に公開する」ことであって、証明書ライフサイクル管理のフレームワークを自作することではありません。そのため、TLS 証明書の発行・検証・更新・失効監視といったライフサイクル管理は、自前で組み上げるのではなく、できる限りマネージドな仕組みに委ねられる構成が求められました。

2-3. 設定の一貫性と、テナントごとの柔軟性の両立

すべてのテナントで共通して適用したい設定 (Origin、Cache Behavior、Cache Policy、Response Headers Policy、AWS WAF など Distribution 単位の設定すべて) と、テナントごとに変えたい設定 (ドメイン、TLS 証明書) が混在します。

このうち Cache Policy・Response Headers Policy・AWS WAF は独立リソースとして複数 Distribution から参照できるため、従来の Amazon CloudFront の構成でも共通化は可能です。一方で Origin や Cache Behavior などの Distribution 単位の設定そのものは、テナントごとに Distribution を分ける構成だと各 Distribution に複製する必要があり、また各テナントが個別のルーティングエンドポイントを持つことになります。「Distribution 単位の設定そのものを一元管理し、全テナントが同一のルーティングエンドポイントを共有する」モデルを Amazon CloudFront のレイヤーでシンプルに実現できることが要件でした。

3. Amazon CloudFront SaaS Manager とは

前章では、ロリポップ！AIサイトエージェントにおけるコンテンツ配信の課題について紹介しました。本章では、これらの課題を解決するために活用した Amazon CloudFront SaaS Manager の機能概要について解説します。

3-1. Amazon CloudFront SaaS Manager の概要

マルチテナント型のサービスを運営していると、テナントごとのドメイン管理や TLS 証明書の発行・更新、セキュリティ設定の適用といった運用タスクが、テナント数の増加に比例して膨らんでいきます。Amazon CloudFront SaaS Manager は、こうしたマルチテナント環境における CDN 運用の負荷を軽減するために 2025 年 4 月に一般提供が開始された機能です。

Amazon CloudFront SaaS Manager を利用すると、テンプレートベースの再利用可能な設定と API を通じて、多数のテナントドメインに対する Amazon CloudFront エッジロケーションでのコンテンツ配信、AWS WAF によるセキュリティ保護、AWS Certificate Manager を用いた TLS 証明書管理をまとめて扱えるようになります。個々のテナントに対して個別にディストリビューションを作成・管理する必要がなくなるため、運用上の複雑さを大幅に削減できます。

3-2. マルチテナントディストリビューションモデル

Amazon CloudFront SaaS Manager は、「マルチテナントディストリビューション」と呼ばれるテンプレートベースのディストリビューションモデルを採用しています。このモデルでは、設定とインフラストラクチャを共有しながら、複数のドメインでコンテンツを提供します。

主要な構成要素は以下のとおりです。

マルチテナントディストリビューション (テンプレート) : オリジン設定、キャッシュ動作、セキュリティ設定など、ドメイン全体で共通して使用される基本設定を定義します。例えば、サービスの料金プランごとにテンプレートを作成し、設定を一元管理できます。
ディストリビューションテナント : 各テンプレートディストリビューションに紐づく個別のテナントです。ドメイン固有のオリジンパスやオリジンドメイン名を設定でき、ウェブ ACL のオーバーライドやカスタム TLS 証明書など、テナント固有のカスタマイズも可能です。
接続グループ : 複数のディストリビューションテナントに対して、コンテンツを提供する Amazon CloudFront のルーティングエンドポイントを提供します。DNS レコードは CNAME を使用して接続グループの Amazon CloudFront のエンドポイントをポイントします。

3-3. テナント管理の柔軟性

ディストリビューションテナントは、関連付けられたマルチテナントディストリビューションの TLS 証明書やセキュリティ設定を継承できます。一方で、テナント専用の新しい証明書をアタッチしたり、セキュリティ設定をオーバーライドしたりすることも可能です。これにより、共通設定による運用効率と、テナントごとの個別要件への対応を両立できます。

3-4. TLS 証明書の自動管理と証明書の HTTP 検証

Amazon CloudFront SaaS Manager の大きな特徴の一つとして、ディストリビューションテナントに対する TLS 証明書の取得・管理を Amazon CloudFront が代行する仕組みです。テナントにドメインを追加すると、Amazon CloudFront が AWS Certificate Manager からマネージド証明書を取得し、証明書の更新も自動的に行われます。

証明書発行時のドメイン所有権の検証方式として HTTP 検証をサポートしており、従来の DNS 検証のようにテナントに検証用 DNS レコードの追加を依頼する必要がありません。テナントに割り当てられるドメインの DNS レコードがディストリビューションを指すように設定されていれば Amazon CloudFront が検証リクエストへの応答を自動的に処理するため、SaaS プロバイダー側の証明書管理の運用負荷を大幅に軽減できます。

Amazon CloudFront SaaS Manager の詳細については、AWS 公式ブログ記事や Amazon CloudFront デベロッパーガイドもあわせてご参照ください。

4. Amazon CloudFront SaaS Manager による課題解決とアーキテクチャ

4-1. 採用判断

前述の課題に対し、Amazon CloudFront SaaS Manager は次の点で要件と合致しました。

Distribution Tenant を 1 ドメイン単位の独立リソースとして扱えるため、テナント追加・削除を他テナントに影響を与えずアトミックに実行できる
Managed Certificate によって、TLS 証明書のリクエスト・DNS / HTTP 検証・更新までを Amazon CloudFront 側に委譲できる
共通の Multi-Tenant Distribution に Cache Policy・Response Headers Policy・AWS WAF を 1 度だけ定義すれば、全テナントに自動適用される

「テナント増減の状態管理から解放され、本来注力したいサービス開発に時間を使える」構図が、SaaS 提供事業者として目指す運用像と一致したため、採用を決定しました。

4-2. 全体アーキテクチャ

本記事で扱うアーキテクチャは「利用者が AI で生成・公開している Web サイト」 (以下、ユーザーサイト) を配信するレイヤーに限定します。サービス自体の管理画面・社内 API・非同期処理プロセスは別構成 (GMOペパボのプライベートクラウド上の Kubernetes クラスター) で運用していますが、本記事のスコープからは外れるため省略します。本サービスのユーザーサイト配信レイヤーは次の構成です。

100 %

構成のポイント

ポイントは次の 3 点です。

1 つの Multi-Tenant Distribution に、すべてのドメインを Distribution Tenant として束ねる
- サービス標準ワイルドカード .lolipop.website も、利用者の独自ドメインも、同じ Multi-Tenant Distribution のテナントとして扱います。Cache Policy・Response Headers Policy・AWS WAF は Multi-Tenant Distribution 側に 1 セット定義しているため、テナントが何件増えても共通設定の更新は 1 箇所 で済みます。
Amazon CloudFront からは VPC Origin 経由で内部 ALB に接続
- ユーザーサイト配信アプリケーション (Next.js) は Amazon ECS (Fargate) 上で動作し、内部 ALB の背後に置いています。Amazon CloudFront から VPC Origin で直接到達することで、ALB やその先のアプリケーションをインターネットに露出させずに済みます。
アプリ側のテナント解決は Host ヘッダーで実施
- Amazon CloudFront からはアクセス元のホスト名がそのままユーザーサイト配信アプリケーションに届くため、アプリ側は Host ヘッダーを見て「どのサイトを返すか」を判定します。

4-3. Multi-Tenant Distribution と Distribution Tenant の構造化

Amazon CloudFront のリソース管理は、対象によって Terraform と AWS SDK を使い分けています。

共通基盤 (Multi-Tenant Distribution 本体・サービス標準ドメイン用テナント) : Terraform で宣言的に管理
利用者の独自ドメインに対する Distribution Tenant : Terraform では宣言せず、後述のとおりアプリケーション側から AWS SDK 経由で動的に作成

Terraform でデプロイした基盤の上で、アプリケーション側が AWS SDK 経由で利用者の独自ドメインに対する Distribution Tenant を動的に追加・削除する構成になっています。Terraform 側は要点のみの抜粋で示します (実コードでは comment、静的アセット用の追加 Cache Behavior、prevent_destroy など、構成上必要な記述も含まれます)。

Terraform の抜粋 (要点のみ)

bash

# Multi-Tenant Distribution (全テナントに適用される共通設定) 
resource "aws_cloudfront_multitenant_distribution" "main" {
  enabled      = true
  tenant_config {}

  origin {
    domain_name = aws_route53_record.alb.name
    id          = "alb-origin"
    vpc_origin_config {
      vpc_origin_id = aws_cloudfront_vpc_origin.alb.id
    }
  }

  default_cache_behavior {
    target_origin_id           = "alb-origin"
    viewer_protocol_policy     = "redirect-to-https"
    cache_policy_id            = aws_cloudfront_cache_policy.multitenant.id
    response_headers_policy_id = aws_cloudfront_response_headers_policy.multitenant.id

    allowed_methods {
      items          = ["DELETE", "GET", "HEAD", "OPTIONS", "PATCH", "POST", "PUT"]
      cached_methods = ["GET", "HEAD"]
    }
  }

  viewer_certificate {
    acm_certificate_arn      = aws_acm_certificate_validation.cloudfront.certificate_arn
    ssl_support_method       = "sni-only"
    minimum_protocol_version = "TLSv1.2_2021"
  }

  web_acl_id = aws_wafv2_web_acl.cloudfront.arn
}

# サービス標準ドメイン (*.lolipop.website) をテナントとして定義
resource "aws_cloudfront_distribution_tenant" "service_domain" {
  name            = "lolipop-production-domains"
  distribution_id = aws_cloudfront_multitenant_distribution.main.id
  enabled         = true

  domain {
    domain = "*.lolipop.website"
  }
}

5. 実装のポイントと工夫

ここからは、Amazon CloudFront SaaS Manager を実運用するために行った工夫を紹介します。本章で登場するプロセスは次の 2 つです。

管理画面 (Next.js / プライベートクラウド Kubernetes): 利用者がドメインを追加するエントリーポイント
非同期処理プロセス (Node.js / BullMQ ベース / プライベートクラウド Kubernetes): キューに積まれたジョブの実行と、1 分ごとなどの定期処理を担当

5-1. 独自ドメイン追加フロー — 「設定ボタンひとつ」の裏側

利用者の操作と、システム側の処理を整理すると次のようになります。

利用者から見ると「ドメインを入力 → 数分待つだけで独自ドメインで公開された状態になる」だけですが、内側では (a) Distribution Tenant の作成、(b) Managed Certificate の発行、(c) 証明書の Distribution Tenant への紐付け、(d) ドメインの active 化待機、という 4 つの非同期ステップが走っています。

5-2. Distribution Tenant 作成と証明書発行リクエスト

実際にテナントを作るのは、AWS SDK for JavaScript の CreateDistributionTenantCommand を呼ぶシンプルな API ラッパーです。

typescript

// website-builder/core/src/server/infrastructure/cloudfront/cloudfront-saas-client.ts
// (抜粋。コンストラクタの DI と環境変数の必須チェックは省略)
export class CloudFrontSaaSClient {
  private client = new CloudFrontClient({ region: "ap-northeast-1" });
  private distributionId = process.env.CLOUDFRONT_DISTRIBUTION_ID!;

  /** Distribution Tenant を作成 (Managed Certificate のリクエスト付き)  */
  async createDistributionTenant(name: string, domain: string) {
    const command = new CreateDistributionTenantCommand({
      DistributionId: this.distributionId,
      Name: name,
      Domains: [{ Domain: domain }],
      Enabled: true,
      ManagedCertificateRequest: {
        ValidationTokenHost: "cloudfront",
        PrimaryDomainName: domain,
        CertificateTransparencyLoggingPreference: "enabled",
      },
    });

    const response = await this.client.send(command);
    return {
      tenantId: response.DistributionTenant!.Id!,
      tenantArn: response.DistributionTenant!.Arn!,
      eTag: response.ETag!,
    };
  }
}

Amazon CloudFront SaaS Manager を採用した大きなメリットの 1 つが、証明書管理の簡潔さです。その実装上の表れが、上記のように CreateDistributionTenantCommand に ManagedCertificateRequest を同梱している点で、Distribution Tenant の作成と Managed Certificate の発行依頼を 1 回の API コールで進められます。証明書の発行・検証・有効期限監視・自動更新は SaaS Manager 側に任せられ、アプリケーション側に残るのは「発行完了を待って Distribution Tenant に紐付ける」処理だけです (5-3. で詳述)。

なお、利用者操作を起点とする Distribution Tenant 作成リクエストは BullMQ のキューに乗せ、API リクエストのライフサイクルとは切り離しています。失敗時は指数バックオフ (60s→120s→240s→480s→960s) で自動リトライされるため、AWS 側の一時的なエラーに対しても堅牢です。

5-3. 証明書 issued 待ちのポーリングとバインド

CreateDistributionTenant のレスポンスを受け取った時点では、証明書はまだ pending-validation 状態です。証明書の発行と検証の完了は AWS 側で非同期に進むため、非同期処理プロセス内で 1 分ごとに走る定期ジョブを起動し、PENDING 状態のドメインを順にポーリングしています (setInterval で周期実行し、内部で GetManagedCertificateDetails を呼び出すシンプルな構成です) 。

typescript

// 1分ごとに走るポーリングジョブ内のメインロジック (成功パスのみ抜粋。
// 実装では pending-validation / validation-timed-out / failed など
// 状態ごとに分岐処理を入れている) 
const certDetails = await; cf.getManagedCertificateDetails(tenant.tenantArn);

if (certDetails?.certificateStatus === "issued") {
  // 証明書を Distribution Tenant に紐付け
  await cf.bindCertificateToTenant(tenant.tenantId, certDetails.certificateArn);

  // ドメインが active になったか確認
  const info = await cf.getDistributionTenant(tenant.tenantId);
  if (info.domainStatus === "active") {
    await repository.updateStatus(customDomainId, "ACTIVE");
  }
}

実装上の工夫

実装で意識した工夫は以下のとおりです。

冪等性の確保 : ジョブは「すでに ACTIVE のものは何もしない」「DistributionTenant がすでに存在すれば作成をスキップ」など、再実行しても副作用が積み重ならない構造にしています。これにより、定期ポーリングによる再試行と、利用者の操作リトライの双方を安全に扱えます。
エラー時のステータス遷移 : 証明書発行が validation-timed-out などの状態に陥った場合は、CustomDomain を ERROR ステータスに遷移させて UI から再試行できるようにし、内部的には requestCertificateReissue で再発行をリクエストする経路を用意しています。

5-4. DNS 設定の利用者ガイダンス

利用者にとって「独自ドメインの設定」で一番つまずくのが DNS です。

Multi-Tenant Distribution では、テナント群を Connection Group という単位でまとめ、Connection Group ごとに 1 つのルーティングエンドポイント (例: xxxxxxxxx.cloudfront.net) が割り当てられます。本サービスではすべてのテナントを 1 つの Connection Group に束ねる構成にしているため、全利用者が同じルーティングエンドポイントを共有しています。利用者は自分のドメインの DNS で、このルーティングエンドポイントを宛先とするレコードを設定することで、自分のドメインへのアクセスを Multi-Tenant Distribution に流せるようになります。

私たちは Distribution Tenant の作成前に DNS の到達性チェックを行い、利用者には次のレコード設定を案内しています。

サブドメイン形式 (例: shop.example.com) : ルーティングエンドポイントを宛先とする CNAME レコード 1 件
Apex ドメイン形式 (例: example.com) : ルーティングエンドポイントを宛先とする ALIAS レコード 1 件 + _cf-challenge.<ドメイン> (例: _cf-challenge.example.com) を名前としてルーティングエンドポイントを値に持つ TXT レコード 1 件

同じ Connection Group の中ではすべてのテナントが同じルーティングエンドポイントを共有します。利用者にとっては独自ドメインがいくつあっても DNS に設定する値は同じで、複数サイトを運用するときも案内内容が変わらず、設定ミスも起こしにくい構造です。

5-5. セキュリティ・運用面の工夫

AWS WAF は Multi-Tenant Distribution に 1 セット定義 : Multi-Tenant Distribution レベルで AWS WAF を一度定義すれば、配下のすべての Distribution Tenant に同じ Web ACL が即時に適用されます。ルール変更を全テナントに反映する運用フローがシンプルになります。
ALB を非公開のまま運用 : ALB はプライベートサブネットに置き、Amazon CloudFront からは VPC Origin で直接到達します。インターネットからアクセスできる経路は Amazon CloudFront に一本化され、ALB やその先のアプリケーションへの直接アクセス経路を持ちません。
テナント情報を DB にミラーリング : AWS から取得したテナント情報 (Distribution Tenant の ID と ARN、Routing Endpoint、Managed Certificate の ARN と発行ステータス) を DB にまとめて保存しています。アプリケーション側は AWS API を毎回呼ばずに DB クエリで状態を判定でき、独自ドメインを論理削除する設計と組み合わせれば、削除済みドメインに紐づくテナント情報も履歴として残せます。

6. 導入効果

新規サービスでの採用のため定量的な比較は難しいのですが、もし Amazon CloudFront SaaS Manager がなかった場合に必要だったことを基準に整理すると、次のような定性的効果が得られました。

TLS 証明書ライフサイクル管理の運用負荷を大幅に削減できた
発行・検証・更新・失効監視を SaaS Manager 側に委ねられ、これらを連動させる自前の管理フローを組まずに済みました。アプリ側に残る証明書関連処理は、発行完了を待って Distribution Tenant に紐付ける処理と、ドメイン削除時の証明書クリーンアップ呼び出し程度に収まっています。レンタルサーバー事業で培った証明書運用のノウハウは、別の領域に集中して投入できるようになっています。
独自ドメイン機能の提供までのリードタイムを短縮できた
独自ドメイン機能の中核コンポーネントを早期に組み立てられたため、利用者向けの UI・DNS ガイダンス・DB 設計といった、本来注力すべき SaaS 固有の体験設計に時間を使えました。
テナント追加が他テナントに影響しない構造を最初から実現できた
共通設定を 1 つの Multi-Tenant Distribution にまとめつつ、ドメインの追加・削除は Distribution Tenant 単位でアトミックに実行できるため、「あるテナントの設定変更が他のテナントを巻き込む」リスクを設計段階で排除できました。
テナント数の上限に対する余裕と将来の打ち手を持てた
Multi-Tenant Distribution に束ねられるテナント数は無制限ではないものの、2-1.で挙げた従来モデル (既存 Distribution への Alias 追加・テナントごとの Distribution 作成) と比べて桁違いに大きい水準まで許容されます。上限に近づいた場合は、Amazon CloudFront の部分をマルチアカウント化することで対応していく想定です。

まとめ

本記事では、GMOペパボが提供する「ロリポップ！AIサイトエージェント」における Amazon CloudFront SaaS Manager の活用事例を紹介しました。

マルチテナント SaaS においては、テナントごとのカスタムドメイン管理や TLS 証明書の運用、CDN 設定の一貫性と柔軟性の両立といった課題が、サービスの成長に伴い運用負荷として顕在化しがちです。Amazon CloudFront SaaS Manager を活用することで、テンプレートベースの設定管理によりこれらの課題を解消し、テナント数の増加に対してもスケーラブルなコンテンツ配信基盤を実現できることをご紹介しました。

マルチテナント Web アプリケーションにおける CDN 管理に課題を感じている方にとって、本記事が設計や技術選定の参考になれば幸いです。

筆者プロフィール

横尾瑞樹

GMOペパボ株式会社技術部ホスティングインフラグループ

ロリポップ！レンタルサーバー byGMOペパボをはじめとするホスティングサービスのインフラ運用・開発に従事。

鈴木祥太

アマゾンウェブサービスジャパン合同会社. ソリューションアーキテクト

普段は Web 業界のお客様を中心にアーキテクチャ設計や構築をサポートしています。好きな AWS サービスは Amazon Elastic Kubernetes Service (Amazon EKS) です。

マルチテナント Web ホスティングにおける独自ドメインの自動プロビジョニング — 「ロリポップ！AIサイトエージェント」を支える Amazon CloudFront SaaS Manager 活用事例

はじめに

builders.flash メールメンバー登録

1. 「ロリポップ！AIサイトエージェント」とは

2. 本サービスにおけるコンテンツ配信の課題

2-1. 利用者ごとに増え続けるドメインを CDN にどう載せるか

2-2. TLS 証明書の発行・更新のスケーラビリティ

2-3. 設定の一貫性と、テナントごとの柔軟性の両立

3. Amazon CloudFront SaaS Manager とは

3-1. Amazon CloudFront SaaS Manager の概要

3-2. マルチテナントディストリビューションモデル

3-3. テナント管理の柔軟性

3-4. TLS 証明書の自動管理と証明書の HTTP 検証

4. Amazon CloudFront SaaS Manager による課題解決とアーキテクチャ

4-1. 採用判断

4-2. 全体アーキテクチャ

構成のポイント

4-3. Multi-Tenant Distribution と Distribution Tenant の構造化

Terraform の抜粋 (要点のみ)

5. 実装のポイントと工夫

5-1. 独自ドメイン追加フロー — 「設定ボタンひとつ」の裏側

5-2. Distribution Tenant 作成と証明書発行リクエスト

5-3. 証明書 issued 待ちのポーリングとバインド

実装上の工夫

5-4. DNS 設定の利用者ガイダンス

5-5. セキュリティ・運用面の工夫

6. 導入効果

まとめ

筆者プロフィール

横尾瑞樹

鈴木祥太

学ぶ

リソース

デベロッパー

ヘルプ

マルチテナント Web ホスティングにおける独自ドメインの自動プロビジョニング — 「ロリポップ！AIサイトエージェント」を支える Amazon CloudFront SaaS Manager 活用事例

はじめに

builders.flash メールメンバー登録

1. 「ロリポップ！AIサイトエージェント」とは

2. 本サービスにおけるコンテンツ配信の課題

2-1. 利用者ごとに増え続けるドメインを CDN にどう載せるか

2-2. TLS 証明書の発行・更新のスケーラビリティ

2-3. 設定の一貫性と、テナントごとの柔軟性の両立

3. Amazon CloudFront SaaS Manager とは

3-1. Amazon CloudFront SaaS Manager の概要

3-2. マルチテナントディストリビューションモデル

3-3. テナント管理の柔軟性

3-4. TLS 証明書の自動管理と証明書の HTTP 検証

4. Amazon CloudFront SaaS Manager による課題解決とアーキテクチャ

4-1. 採用判断

4-2. 全体アーキテクチャ

構成のポイント

4-3. Multi-Tenant Distribution と Distribution Tenant の構造化

Terraform の抜粋 (要点のみ)

5. 実装のポイントと工夫

5-1. 独自ドメイン追加フロー — 「設定ボタンひとつ」の裏側

5-2. Distribution Tenant 作成と証明書発行リクエスト

5-3. 証明書 issued 待ちのポーリングとバインド

実装上の工夫

5-4. DNS 設定の利用者ガイダンス

5-5. セキュリティ・運用面の工夫

6. 導入効果

まとめ

筆者プロフィール

横尾 瑞樹

鈴木 祥太

学ぶ

リソース

デベロッパー

ヘルプ

横尾瑞樹

鈴木祥太