Lagoon vs AWS：Drupalホスティング選定のための徹底比較ガイド

はじめに：Drupalホスティング選びはなぜ重要か

Drupalで構築したWebサイトを公開するとき、「どのホスティング環境を選ぶか」はパフォーマンス・コスト・運用負荷のすべてに影響する、きわめて重要な意思決定です。

選択肢は多岐にわたりますが、近年とくに注目を集めているのがLagoonとAWS（Amazon Web Services）の2つです。Lagoonは「DrupalをはじめとするオープンソースCMSのために設計されたKubernetesネイティブPaaS」として、世界中の大規模Drupalサイトで採用が進んでいます。一方のAWSは言わずと知れたクラウドインフラの最大手であり、柔軟性と豊富なサービス群を武器に、あらゆる規模のWebサイトを支えています。

この2つはアーキテクチャも思想もまったく異なります。「どちらが優れているか」という単純な比較ではなく、プロジェクトの性質・チームのスキル・予算・運用方針に合わせてどちらを選ぶべきかを、本記事では多角的に掘り下げていきます。

1. Lagoonとは何か

Image

Lagoonの概要と誕生の背景

Lagoonは、スイスのWeb開発会社amazee.ioが開発・提供するオープンソースのアプリケーションデリバリープラットフォームです。もともとDrupalの大規模案件を多数手がけるamazee.ioが、自社プロジェクトの運用効率化のために作り上げたインフラ基盤をオープンソース化したもので、現在はGitHubで公開されています。

Lagoonの最大の特徴は、Kubernetesをベースとした完全なコンテナ駆動型のアーキテクチャにあります。開発者はDockerfileと設定ファイルを書くだけで、開発・ステージング・本番の各環境を自動的に管理できます。また、GitブランチやPull Requestに紐づいた動的なプレビュー環境の自動生成機能も備えており、現代的なCI/CDワークフローとの親和性が非常に高い点も評価されています。

Lagoonの主な特徴

• Kubernetesネイティブ：コンテナオーケストレーションをKubernetesで行い、スケーラビリティと高可用性を実現
• GitOps対応：GitリポジトリのブランチやタグにHookしてデプロイを自動化。Pull Requestごとにプレビュー環境を自動生成
• OSS最適化：Drupal・WordPress・Node.jsなど主要なオープンソースアプリケーションに最適化されたビルドパイプライン
• マルチクラウド対応：AWS・GCP・Azure・独自データセンターなど、複数のインフラ上でLagoonを動かすことができる
• オープンソース：コア部分はMITライセンスで公開されており、自社インフラでのセルフホストも可能

Lagoonを使用した代表的なホスティングサービス

LagoonはOSSですが、amazee.ioはマネージドサービスとしてのLagoonも提供しています。インフラ管理・監視・セキュリティパッチ・24時間サポートをamazee.ioが担当するため、開発チームはアプリケーション開発に集中できます。PantheonやAcquiaと同様の「Drupal専用マネージドホスティング」の立ち位置にありながら、KubernetesネイティブであるためよりモダンなDevOpsワークフローを実現できる点が差別化ポイントです。

2. AWS（Amazon Web Services）とは何か

Image

AWSの概要

AWSはAmazonが提供するクラウドコンピューティングプラットフォームで、200以上のサービスを世界中のデータセンターから提供しています。仮想サーバー（EC2）・マネージドデータベース（RDS）・コンテンツデリバリー（CloudFront）・オブジェクトストレージ（S3）・コンテナ管理（ECS/EKS）など、Webサイトの運用に必要な機能はほぼすべて揃っています。

AWSの強みは圧倒的な柔軟性とサービスの充実度にあります。自分のニーズに合わせてサービスを組み合わせることで、小規模なブログから数億PVを誇るエンタープライズサイトまで対応できます。その反面、適切な構成を選ぶには一定の知識が必要であり、「自由度の高さ」は「複雑さ」と表裏一体でもあります。

DrupalをAWSで動かす際の代表的な構成

AWSでDrupalを動かす場合、以下のような構成が一般的です。

• Webサーバー： EC2（Auto Scaling Group）またはECS/EKS上のコンテナ
• データベース： Amazon RDS（MySQL/MariaDB/PostgreSQL）
• キャッシュ： Amazon ElastiCache（Redis/Memcached）
• ファイルストレージ： Amazon S3 + Amazon EFS
• CDN： Amazon CloudFront
• ロードバランサー： Application Load Balancer（ALB）
• DNS： Amazon Route 53

これらを組み合わせることで、高可用性・高スループット・低レイテンシのDrupal環境を実現できます。ただし、各サービスの設定・連携・監視・コスト管理はすべて自分（あるいは自チーム）の責任となります。

3. Lagoon vs AWS：5つの観点で徹底比較

① セットアップと導入のしやすさ

Lagoonのセットアップは、Drupal開発者を主なターゲットとして設計されているため、CMS運用に特化したワークフローが整っています。プロジェクトのリポジトリに.lagoon.ymlとdocker-compose.ymlを追加し、amazee.ioのダッシュボードにリポジトリを連携するだけで、自動的にビルドパイプラインが動き始めます。DDEVとの連携も公式でサポートされており、ローカル開発環境から本番環境までのフローがシームレスです。

# Lagoon CLIのインストール（macOS）
brew install amazeeio/lagoon-cli/lagoon

# プロジェクトの確認
lagoon list projects

# デプロイの実行
lagoon deploy branch --branch=main --project=my-drupal-site

一方、AWSでDrupalを本番運用可能なレベルで構築するには、EC2・RDS・ElastiCache・S3・CloudFront・ALB・IAMなど複数のサービスを個別に設定・連携させる必要があります。TerraformやAWS CDKを使ったInfrastructure as Codeの知識、セキュリティグループの設計、AMIの管理など、インフラエンジニアとしてのスキルが不可欠です。Drupal開発チームがインフラも兼務する場合、学習コストは決して小さくありません。

【結論】 セットアップの容易さではLagoonが圧倒的に有利。AWSは高い自由度の代償として習熟コストが高い。

② 開発・デプロイワークフロー

LagoonはGitOpsを標準とした開発ワークフローを提供します。mainブランチへのマージで本番デプロイ、developブランチへのプッシュでステージング自動更新、Pull Request作成で専用プレビュー環境の自動生成——これらがすべて設定ファイルだけで実現できます。

また、Lagoonはデプロイ前後に自動実行されるフック（post-rollout tasks）をサポートしており、以下のようなDrupalの運用コマンドをデプロイパイプラインに組み込むことができます。

# .lagoon.yml の post-rollout タスク例
tasks:
  post-rollout:
    - run:
        name: drush deploy
        command: drush deploy
        service: cli
    - run:
        name: clear cache
        command: drush cr
        service: cli

AWSでも、GitHub ActionsやAWS CodePipelineを使えばCI/CDパイプラインを構築できます。ただし、Lagoonのようにドキュメント化されたDrupal向けのテンプレートが存在するわけではなく、自前で設計・構築する必要があります。柔軟性は高い一方、初期の設計コストがかかります。

【結論】 Drupal特化のデプロイワークフローとしてはLagoonが洗練されている。AWSは汎用的なCI/CDツールと組み合わせることで同等以上の柔軟性を発揮できるが、設計・構築コストが伴う。

③ スケーラビリティとパフォーマンス

Lagoonはキャッシュ層にVarnishとRedisを標準で組み込んでおり、DrupalのページキャッシュとセッションキャッシュをKubernetesのスケーリング機能と組み合わせて高トラフィックに対応します。amazee.ioのマネージドサービスでは、Kubernetesのオートスケーリングが有効になっており、急激なトラフィック増加にも自動で対応できます。

AWSもオートスケーリングを標準サポートしており、CloudFrontによるグローバルCDNキャッシュと組み合わせることで、世界規模のトラフィックを処理できます。リージョン・アベイラビリティゾーンの組み合わせによるマルチAZ構成は、可用性の面でも業界最高水準です。データベースの読み取りスループットが課題になる場合はRDS Proxyやリードレプリカを活用するなど、スケールアップのオプションは無限にあります。

【結論】 スケーラビリティはLagoon・AWSともに高水準。超大規模トラフィックや細かいアーキテクチャのカスタマイズが必要な場合はAWSが有利。一般的な企業・メディアサイトであればLagoonで十分対応できる。

④ セキュリティと可用性

Lagoonのセキュリティ対策は、amazee.ioが管理しているマネージドサービスの場合、インフラレベルのパッチ適用・監視・侵入検知をプロバイダーが担当します。各プロジェクト環境はKubernetesのNamespaceレベルで分離されており、他のテナントとのリソース干渉や情報漏洩リスクが低く抑えられています。SOC 2 Type IIの認定を取得しているため、セキュリティ要件の厳しい企業案件でも採用実績があります。

AWSはISO 27001・SOC 1/2/3・PCI DSSなど、業界で認められた多数のコンプライアンス認定を取得しています。AWS Shield（DDoS対策）・AWS WAF（Webアプリケーションファイアウォール）・AWS GuardDuty（脅威検出）など、セキュリティサービスのエコシステムが充実しており、金融・医療・官公庁といった厳格なセキュリティ要件にも対応できます。ただし、これらのサービスを適切に設定・運用するにはセキュリティ専門知識が必要です。

【結論】 両者ともにエンタープライズレベルのセキュリティを提供。amazee.io LagoonはDrupal特化のセキュリティノウハウが強み。AWSはコンプライアンスの網羅性と細かいカスタマイズ性が強み。

⑤ コストと価格モデル

コストの比較は単純ではありませんが、重要なポイントを整理します。

Lagoon（amazee.ioマネージドサービス）の場合、月額固定料金または使用量ベースの料金体系が提供されています。インフラ管理・監視・サポートコストがすべて含まれているため、「総所有コスト（TCO）」として考えると割安になるケースが多いです。特に、インフラエンジニアを専任で雇用するほどの規模でないチームにとっては、managed serviceとしてのLagoonは費用対効果が高いといえます。

AWSは従量課金モデルが基本です。使った分だけ課金されるため、小規模サイトでは安価に始められますが、トラフィックが増加するにつれてコストが増加します。さらに、AWSの場合はサービス費用だけでなく、インフラ設計・構築・運用のための人件費（内製またはSI委託）も合算する必要があります。専任のインフラエンジニアがいないチームでは、実質的なTCOがLagoonよりも高くなることがあります。

一方で、AWSにはSavings PlansやReserved Instancesといった長期割引プランがあり、大規模サイトでは大幅なコスト削減が可能です。また、AWSのスキルを持つエンジニアが社内にいる場合は、追加のインフラコストがかからないため有利になります。

【結論】 小〜中規模でインフラスキルが限られたチームにはLagoonのマネージドサービスがコスト効率的。大規模で専任インフラエンジニアがいるチームや厳密なコストコントロールが必要な場合はAWSが有利。

4. ユースケース別：どちらを選ぶべきか

Lagoon（amazee.io）が向いているケース

• Drupal・WordPress・Node.jsなどのCMSを専門に扱うWeb制作会社・代理店：複数クライアントのサイトを効率よく管理できる
• インフラエンジニアが社内にいないDrupal開発チーム：アプリケーション開発に集中しながら本番品質のインフラを利用できる
• Pull Requestごとのプレビュー環境が必要なアジャイル開発チーム：GitOpsワークフローが標準でサポートされている
• Drupal CMSのレシピ機能と組み合わせて素早くサイトを立ち上げたいチーム：DDEVとLagoonのシームレスな連携が活きる
• 自治体・大学・NPOなど、限られたIT予算で高品質なサイトを運用したい組織：管理コストを最小化できる

AWSが向いているケース

• 専任のインフラ・クラウドエンジニアがいる大規模組織：AWS全サービスを活用した精緻なアーキテクチャを設計できる
• 金融・医療・行政など、特定の規制・コンプライアンス要件がある業界：AWSの広範な認定対応が強みになる
• DrupalだけでなくさまざまなシステムをAWSで統合管理したい組織：他システムとのシナジー効果が高い
• グローバル展開が必要な超大規模サイト：世界30以上のリージョンを活用したマルチリージョン構成が可能
• AWSのスキルを持ったエンジニアが社内にいる組織：既存のスキルセットを最大活用できる

Lagoon + AWSという選択肢

実は、LagoonとAWSは対立するものではありません。LagoonはKubernetesベースのため、AWSのEKS（Elastic Kubernetes Service）上でLagoonを動かすことができます。amazee.ioのマネージドサービスもAWSインフラ上で提供されているオプションがあります。

この組み合わせにより、「AWSの強力なインフラ基盤の上で、Drupal最適化されたLagoonのデプロイワークフローを利用する」という欲張りな構成も実現可能です。予算に余裕があり、セキュリティ・コンプライアンス要件が高く、かつ開発チームのワークフロー効率も最大化したい場合には、この組み合わせが最強の選択肢になり得ます。

5. 実際のDrupalサイトへの適用：移行の考え方

既存DrupalサイトをLagoonへ移行する手順概要

すでにAWSや従来型サーバーで動いているDrupalサイトをLagoonに移行する場合、大まかに以下のステップで進めます。

1. Lagoonの設定ファイル追加： リポジトリに.lagoon.yml・docker-compose.yml・必要なDockerfileを追加する
2. ローカル環境での動作確認： DDEVまたはLagoonのDocker Composeで動作確認を行い、既存サイトが正しく動くことを確認
3. amazee.ioのプロジェクト作成： ダッシュボードからプロジェクトを作成し、GitリポジトリとSSHキーを設定
4. データベース・ファイルの移行： 既存DBのダンプとファイル（sites/default/files）をLagoon環境へ転送
5. DNS切り替え： 動作確認後にDNSを新環境へ向け替え、移行完了

# データベースのエクスポート（旧環境）
drush sql:dump --gzip > backup.sql.gz

# Lagoon環境へのデータベースインポート
lagoon ssh --project=my-project --environment=main
drush sql:cli < backup.sql

Drupal CMSとLagoonの相性

Drupal CMS（Starshot）は、DDEVによるローカル開発を前提とした設計になっています。LagoonはDDEVとの連携を公式サポートしており、ローカル環境のdocker-compose.ymlをそのままLagoonのデプロイ設定として活用できます。Drupal CMSのレシピ機能でセットアップしたサイトをそのままLagoonへデプロイする、というシームレスな開発フローが実現します。

6. 主要なDrupalホスティングの全体比較表

LagoonとAWSを含む主要なDrupalホスティングの特徴を一覧にします。

まとめ：あなたのDrupalプロジェクトに合った選択を

LagoonとAWSはそれぞれ異なる強みを持った、優れたホスティング選択肢です。どちらが「正解」かではなく、あなたのプロジェクトの要件・チームのスキル・予算・長期的な運用方針に合わせて選ぶことが大切です。

まとめると、以下のような基準で検討するとよいでしょう。

• Drupal開発に集中したい・インフラに割けるリソースが少ない → Lagoon（amazee.io）
• インフラの完全な制御権が必要・AWS専任エンジニアがいる・大規模サイト → AWS
• 最高の開発体験とエンタープライズ品質を両立したい → Lagoon on AWS

Drupal CMSの普及により、これまでDrupalを敬遠していた開発者・組織がDrupalに参入してくることが増えています。その際に「どこで動かすか」の選択を誤ると、運用フェーズで大きな負荷になります。本記事がその選択の一助となれば幸いです。

まずはLagoonの無料トライアルやAWSの無料枠を活用して、自分のプロジェクトで実際に試してみることをおすすめします。