AWSでMagento環境を構築するうえでの注意点（サポート現場のリアルな知見）

AWSでMagento環境を構築するうえでの注意点（サポート現場のリアルな知見）

はじめに：AWSでMagentoを立てる前に知っておいてほしいこと

Magento（Adobe Commerce）は、世界中で使われている本当に素晴らしい高機能ECプラットフォームです。ただ、システム構成が複雑で、インフラに要求されるリソースがかなり大きいという特徴があります。だからこそ、柔軟にスケーリングできるAWSとはすごく相性が良いんですよね。

しかし、サポートの現場にいると、「一般的なLAMP環境と同じ感覚で、とりあえずAWS上に構築してみました！」というケースに遭遇することが実はとても多いんです。Magentoの特性を考慮せずに組まれた環境は、管理画面がもっさりして使い物にならなかったり、セールのアクセス集中でカート画面が落ちてしまったりと、後々かなり痛い目を見ることになります。

この記事では、これからAWSでMagento環境を構築する方に向けて、私たちがサポート現場で実際に直面した「リアルなハマりどころ」と、それを回避するためのベストプラクティスをこっそりお伝えします。

1. インフラ構成設計の落とし穴とベストプラクティス

AWS上でMagentoを安定させるには、コンポーネントをうまく分離する設計がキモになります。

CloudFrontとVarnishのキャッシュ設定、競合していませんか？

Magentoはフルページキャッシュ（FPC）としてVarnishを強く推奨しています。AWSで組む場合、前段にCloudFront（CDN）を置き、EC2側でVarnishを動かす構成が王道です。
ここで本当によく見かける罠が、CloudFrontとVarnishでのキャッシュルールの設定漏れや競合です。CloudFront側でCookieやクエリ文字列を正しくフォワードしないと、「他人のカートの中身が見えてしまう！」という大事故に繋がることも。カートやマイページといった動的ページは、絶対にキャッシュから除外するようルーティングを念入りに設定してください。

複数台構成時の画像共有：EFSの「遅延」に注意

EC2を複数台並べる場合、商品画像などのディレクトリ（/pub/media）を共有する必要があります。ここで手軽なAmazon EFSを選びがちなんですが、EFSのレイテンシ（遅延）がボトルネックになるという相談をよく受けます。
ファイルアクセスが頻繁に発生すると、カタログページの読み込みが激重になります。アクセスは極力CloudFront経由にして、EFSへ直接読み書きに行く回数を最小限に抑える工夫が必須です。

RDSとOpenSearchは絶対に分離する

Magento 2.4系以降、カタログ検索にOpenSearch（またはElasticsearch）が必須になりました。ここでコストを抑えようと、EC2の中にデータベースやOpenSearchを同居させるのは、正直なところ絶対におすすめしません。
インデックスの再構築（Reindex）が走った瞬間、強烈な負荷がかかってサイト全体が沈黙します。Amazon RDS（Aurora MySQLがおすすめ）と、Amazon OpenSearch Serviceは、お財布と相談しつつも必ず分離させましょう。

2. EC2インスタンス選びで失敗しないために

インスタンス選びは、コストとパフォーマンスに直結する大事なポイントです。

「とりあえずT系」は危険！CPUクレジット枯渇の恐怖

「検証用だし、スモールスタートだから」と、t3.medium などを選んでしまうと後悔します。Magentoは裏側で重いCron処理やインデックス更新が頻繁に走るため、T系インスタンスのCPUクレジットをあっという間に食いつぶします。クレジットが枯渇した途端、サイトが信じられないほど遅くなる…というトラブルを何度も見てきました。

Magentoが求める推奨スペック

本番環境なら、コンピュート最適化（C系）か汎用（M系）を選ぶのが鉄則です。

最低でも1台あたり 4GB〜8GBのメモリ と 2vCPU以上 は確保してください。

Gravitonプロセッサのコスパが最高

もしこれから新しく構築するなら、ARMベースのAWS Graviton2/3プロセッサ（m6gやc6gなど）を強くおすすめします。PHPで動くMagentoはARMアーキテクチャの恩恵を受けやすく、従来のインスタンスと比べてコストが下がるのにパフォーマンスは上がるという美味しい思いができますよ。

3. 各種設定・ミドルウェア連携の「あるある」

インフラだけでなく、Magento内部の設定にも気を配る必要があります。

Redisの設定：セッションとキャッシュは絶対に分ける

高速化のためにRedisを導入するのは大賛成ですが、「セッション管理用」と「キャッシュ用」を同じRedisデータベースに突っ込んでいる構成をたまに見かけます。
これをやると、キャッシュをクリアした瞬間にユーザーが強制ログアウトされたり、アクセス集中時にRedisの処理が詰まってサイトがフリーズしたりします。必ず用途ごとにデータベース（またはエンドポイント）を分割してください。

Cronジョブが大暴走して負荷が跳ね上がる

Magentoはメール送信からカタログ同期まで、あらゆる裏側処理をCronに頼っています。これをデフォルト設定のまま放置すると、処理が並列・重複して走り、CPU使用率が常に100%に張り付く事態になりかねません。（とくに外部エクステンションを入れていると顕著です）。スケジュールの見直しと、Cron実行時間の監視はマストで行いましょう。

PHPのメモリ制限とOpcache

公式ドキュメント通り、PHPの memory_limit は最低2GBは確保したいところです。とくにデプロイ時のコンパイル処理（setup:di:compile）はメモリをバカ食いします。また、Zend Opcacheは確実に有効化して数値をチューニングしておかないと、本来のスピードは出ません。

4. 運用を見据えたセキュリティと監視

最後に、運用を楽にするために最初からやっておくべき設定です。

AWS WAFと「管理者ブロック」の悲劇

セキュリティ対策としてのAWS WAFは必須級ですが、Magento特有の誤検知（フォルス・ポジティブ）にはかなり悩まされます。
管理画面から長文のHTMLブロックや複雑な設定を保存しようとすると、WAFが「SQLインジェクションだ！」「XSSだ！」と反応してしまい、管理者がエラー画面に弾かれる…これ、本当にあるあるなんです。管理画面のURL（/admin_xxx/ など）や社内IPについては、構築の段階でWAFルールの除外設定（ホワイトリスト化）をしておくと、運用開始後のクレームを減らせます。

CloudWatchで最低限見ておくべきメトリクス

障害の予兆をキャッチするため、最低限これだけはCloudWatchでアラーム設定しておきましょう。

• EC2: CPU使用率（万が一T系を使うなら CPUCreditBalance は絶対）
• RDS: FreeableMemory（メモリ不足）、DiskQueueDepth（I/Oの詰まり）
• Redis: EngineCPUUtilization（シングルスレッドなのでCPU負荷に注意）、Evictions（メモリ不足の警告）

まとめ：AWS×Magentoの組み合わせを成功させるために

AWSでMagentoを構築する際の落とし穴は、「とりあえず動く」状態から「高負荷に耐えうる本番環境」へと引き上げる部分に潜んでいます。

キャッシュの連携、T系インスタンスの回避、Redisの用途別分離など、設計段階で少し気を配るだけで、運用後の安定感が劇的に変わります。今回ご紹介したサポート現場の知見を活かして、ぜひ安全でサクサク動くMagento環境をAWS上で実現してください！