先日、業務にて「既存のRDSのストレージを暗号化したい」という、シンプルかつ重たい要件が降ってきました。

これの何が困るかというと、皆様ご存知の通りRDSの仕様です。 RDSは作成後の暗号化ステータスの変更ができません。つまり、既存のRDSを暗号化するためには、「暗号化有効」設定で作り直す（再作成する）必要があります。

参考: Amazon RDS DB インスタンスおよびクラスターの暗号化 – AWS Prescriptive Guidance

さらに今回はインフラを AWS CDK で管理しています。
単純にCDKのコードを書き換えてデプロイすると、CloudFormationの仕様により「リソースの置換」が発生し、予期せぬダウンタイムやデータ損失のリスクがあります。
また、よくある「スナップショットから復元して差し替え」という手法も、CDKのState管理との兼ね合いで今回は採用できませんでした。

様々な制約がある中、「既存データを維持しつつ」「CDK管理のまま」暗号化リソースへ移行できたので、その手法を共有します。

今回の要件と制約

今回のミッションにおける前提条件は以下の通りです。

• 既存RDSの暗号化（最重要）
• 既存データをそのまま移行できること
• アプリ側の変更を避けるため、エンドポイント（またはDNS）の変更がないこと
• ダウンタイムは許容（ALBでメンテナンス画面を挟む前提）
• バッチ処理が稼働していない夜間帯での作業
• CDKコードの変更は最小限に留め、今後もCDKで管理し続けること

結論：CDKデプロイを3回行う

結論から言うと、「削除ポリシーを変更して既存RDSをCDK管理から切り離し、新規で暗号化RDSを作成する」という力技で解決しました。

具体的には以下の3ステップでデプロイを行います。

1. RemovalPolicy.RETAIN を設定（既存保護）
2. instanceIdentifier を変更（既存切り離し）
3. storageEncrypted: true を指定（新規作成）

なぜこの手順が必要なのか？（ハマりポイント）

通常、CDKで管理されているリソースに対し、instanceIdentifier（物理ID）を固定したまま storageEncrypted: true に変更してデプロイしようとすると、以下のエラーが発生して失敗します。

CloudFormation cannot update a stack when a custom-named resource requires replacing

これは、「カスタム名（明示的な名前）がついているリソースを置換（削除＆作成）することはできない」というCloudFormationの安全装置です。これを回避するために、あえて識別子を変更して別リソースとして認識させる必要があります。

手順詳細

1. 削除ポリシーの変更

まず、既存のRDSがCDKのスタック操作によって削除されないようにします。 これをやらないと、次の手順で「既存RDSの削除」が走ってしまい、データが消えます（超重要）。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db', // 現在の識別子
  // ...
  removalPolicy: cdk.RemovalPolicy.RETAIN, // ここを追加！
});

この状態で一度 cdk deploy します。 これで、このRDSはスタックから削除される際も、AWS上にはリソースが残るようになります。

2. instanceIdentifier の変更

次に、既存のRDSをCDKの管理下から外す（Orphanにする）作業です。 CDK上の識別子を、既存のものとは別の名前に書き換えます。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db-temp', // 3と被らない一時的な名前に変更
  // ...
  removalPolicy: cdk.RemovalPolicy.RETAIN,
});

この状態で cdk deploy します。

何が起きるか：
CloudFormationは「my-prod-db を管理から外し、新しく my-prod-db-temp を作る」という挙動をします。 ステップ1で RETAIN を設定しているため、旧RDS（データ入り）は削除されずにそのまま残ります。
※この時点でアプリはまだ旧RDSを見ています。

3. いよいよ暗号化RDSの構築

最後に、本命の「暗号化されたRDS」を作成します。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db', // 元の名前に戻す（ここが変わるとエンドポイント変わるので注意）
  storageEncrypted: true,           // 暗号化をON
  removalPolicy: cdk.RemovalPolicy.RETAIN,
  // ...
});

この状態で cdk deploy します。

注意点：
もし instanceIdentifier を手順1と同じ名前（my-prod-db）に戻したい場合、手順2の時点でAWS上に古い my-prod-db が残っているため、名前重複でエラーになる可能性があります。
その場合は、AWSマネジメントコンソールまたはCLIから、古いRDS（手順2で切り離されたもの）の識別子を手動で my-prod-db-old などにリネーム してからデプロイしてください。

これで、暗号化された空っぽのRDSが立ち上がりました。

データ移行

新旧2つのRDSが存在している状態になりました。

• 旧RDS
  • データあり
  • 非暗号化
  • CDK管理外
• 新RDS
  • データなし
  • 暗号化済み
  • CDK管理下

データ量がそれほど多くない（数GB〜数十GB程度）ため、今回はシンプルに mysqldump で移行を行いました。TB級の場合は AWS DMS (Database Migration Service) の利用を検討してください。

# SSM Session Manager 等で踏み台サーバーに接続

# 1. 旧RDSからデータをエクスポート（パイプで圧縮して転送時間を短縮）
mysqldump -h [旧RDSエンドポイント] -u [ユーザー名] -p \
  --single-transaction --routines --triggers \
  --databases [対象のスキーマ] \
  | gzip > dump.sql.gz

# 2. 新RDSへインポート
zcat dump.sql.gz | mysqldump -h [新RDSエンドポイント] -u [ユーザー名] -p

データの移行が完了したら、アプリケーションの接続先が新RDSに向いていることを確認し、メンテナンスを解除します。

後片付け

無事稼働確認が取れたら、不要なリソースを削除してお財布を守りましょう。

1. 手順2で立ち上がった一時的なRDS（CDKの管理からは外れているはずですが、念の為確認して削除）
2. 手順1以前から存在していた旧RDS（リネームした my-prod-db-old など）

スナップショットが取れていることを確認した上で、マネジメントコンソールから削除しました。

(おまけ) 試したけどうまくいかなかったこと

cdk import での既存リソース取り込み

既存のリソースをリネームして、新しいスタックに取り込もうと cdk import を試みましたが、以下のようなメッセージが出てスキップされました。

TmpStack: no new resources compared to the currently deployed stack, skipping import.

また、定義と実リソースのプロパティ（暗号化の有無）が食い違っているため、インポート自体が整合性エラーになる可能性が高いです。

DatabaseInstanceFromSnapshot の利用

スナップショットから復元するCDKのクラスですが、これをメインの定義にしてしまうと、常に「スナップショットから作られた状態」が正となり、パラメータグループやバージョン更新などの運用時にドリフト（設定乖離）の管理が面倒になると判断し、今回は見送りました。

まとめ

CDKで管理しているステートフルなリソース（RDSなど）の「再作成必須な変更」は非常に神経を使います。 「Retainで保護」→「Identifier変更で管理から切り離し」→「新規作成」 というフローは、RDSに限らず他のリソースでも応用が効くテクニックなので、覚えておいて損はないはずです。

なにはともあれですが、RDSは最初から暗号化しましょう。これだけは覚えて頂けると。。。

同じ悩みを抱えるPHPer（およびAWS使い）の助けになれば幸いです！

CDK、楽しいですよね。Typescript でインフラがかけるなんて最高です。でも、学習を始めていくとある壁にぶつかりました。

ネット上の「CDKでECS構築してみた！」系の記事を参考にすると、大抵の場合 VPCもECSもRDSも全部一つの lib/my-stack.ts に処理が書かれている」のです。サンプルコードとしてはわかりやすいのですが、いざ実務でLMAP環境を作ろうとすると⋯…

• VPC は更新頻度が低いからスタックを分けたい
• RDS はステートフルだから独立させたい
• ECS はアプリケーションコードのデプロイで頻繁に更新が入るかも

とスタックを分割したくなりませんか？
でも、分割した途端に「StackA で作ったVPCのIDをどうやってStackBにわたすの？」という問題が発生します。

当記事では、現時点での私の持論である スタック間のリソース共有を紹介します。

IDではなくオブジェクトを渡す

VPC スタックとECSスタックを分けるときに、ついやってしまいがちなのが VPC IDを Props で渡す という手法です。
Terraform に慣れていると、この発想になりがちですよね。

この手法では CDK の 型安全を活かすことが出来ないので、 VPCオブジェクトそのもの を渡すのがベストだと考えています。

私の構成案：
司令塔となる エントリーポイント app がバケツリレーのようにオブジェクトを渡していくイメージです。

1. VPCStack： VPCを作る。 public readonly vpcでVPCオブジェクトを公開する
2. APP： VpcStack からVPCオブジェクトをもらい、 ECSStackに渡す
3. EcsStack： 受け取ったVPC オブジェクトを使ってクラスターを作る

実際にコードを見ていきましょう。

型安全の恩恵を受ける

VPCStack ⇒ 渡す側

ここでは this.vpcをクラスのメンバ変数として公開しておきます。

// lib/vpc-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { Construct } from 'constructs';

export class VpcStack extends cdk.Stack {
  // 外部に公開するプロパティ（これが重要！）
  public readonly vpc: ec2.IVpc;

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    this.vpc = new ec2.Vpc(this, 'LampVpc', {
      maxAzs: 2,
    });
  }
}

EcsStack ⇒ 受け取る側

ここがポイントデス。 vpcId: stringではなく、 vpc: ec2.IVpc というインターフェース型で受け取ります。

// lib/ecs-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';

// Propsの定義：文字列ではなく「VPCの型」を指定する
interface EcsStackProps extends cdk.StackProps {
  vpc: ec2.IVpc;
}

export class EcsStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: EcsStackProps) {
    super(scope, id, props);

    // 文字列から検索する必要なし！そのまま使える
    const cluster = new ecs.Cluster(this, 'LampCluster', {
      vpc: props.vpc, 
    });
  }
}

bin/app.ts ⇒ 繋ぐ場所

最後にエントリーポイントで紐づけます。

// bin/app.ts
import * as cdk from 'aws-cdk-lib';
import { VpcStack } from '../lib/vpc-stack';
import { EcsStack } from '../lib/ecs-stack';

const app = new cdk.App();

// 1. VPCを作る
const vpcStack = new VpcStack(app, 'VpcStack');

// 2. VPCオブジェクトをECSスタックに渡す
const ecsStack = new EcsStack(app, 'EcsStack', {
  vpc: vpcStack.vpc, // ここでバケツリレー
});

この方法の何が良いの？

この方法のメリットは2つあると思っています。
（一言で言うとプログラミング言語による抽象化です。）

1. 圧倒的な型安全性
   もし間違えてS3のオブジェクトを渡そうとすると、エディタがその場でエラーを吐いてくれます。
   「デプロイしてみたらIDが違ってコケた」という悲劇が未然に防げます
2. 記述がメチャ楽
   受け取る側で ec2.Vpc.fromLookup() のようなインポート処理を書く必要がありません。渡された瞬間から props.vpc.addInterfaceEndpoint のようにメソッドが使えます

議論したいポイント

ここまで「これが正解だ」という顔で書いてきましたが、実はこの構成には明確なデミリットもあります。それは、 スタック同士が密結合 になることです。

Cloudformation の Export/Import 機能でガッチリ紐づいてしまうため、以下のような問題が置きます。

• スタック間の参照があるため、「VPCだけを作り直したい」が出来ない

ただし、私は上記のような問題が発生したとしても、
LAMP 環境という一つのアプリケーションにおいて、VPCとECSは「運命共同体」にあたるため問題ないと考えています。

「ECSが生きているのにVPCだけ消したい」という状況は稀ではないでしょうか。そのためこの密結合はあえて受け入れるべき仕様だと割り切っています。

ただ、もし組織の基盤となる共通のVPCを作る場合は、ライフサイクルが異なるため、疎結合なID渡しにするのが正解なのかもしれません。

皆さんの構成おしてほしいっす。

本記事では、AWS CDK（Cloud Development Kit）を用いて、ECSとRDSの監視アラーム、ECSのオートスケーリング、そしてそのイベントをSlackに集約する通知基盤をIaCとして一括で構築する方法を解説します。

監視・通知アーキテクチャの全体像

採用するアーキテクチャは以下の通りです。

事前準備: AWS ChatbotとSlackの連携

CDKデプロイの前に、AWSアカウントとSlackを連携させるためのAWS Chatbotクライアントを作成しておく必要があります。

1. AWS Chatbotコンソールで、Slackワークスペースとチャンネルを連携させます。
2. この設定により、通知先のSlackチャンネルIDとワークスペースIDが取得できます。これらはCDKコード内で使用します。

監視とオートスケール基盤の構築

今回は、ECSサービスとRDSインスタンスが既に存在することを前提に、その監視・スケール設定を定義するCDKスタックを作成します。

CDKスタックのセットアップ

必要なCDKライブラリをインポートし、スタックを定義します。

// lib/monitoring-stack.ts

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as sns from 'aws-cdk-lib/aws-sns';
import * as cloudwatch from 'aws-cdk-lib/aws-cloudwatch';
import * as actions from 'aws-cdk-lib/aws-cloudwatch-actions';
import * as events from 'aws-cdk-lib/aws-events';
import * as targets from 'aws-cdk-lib/aws-events-targets';
import * as autoscaling from 'aws-cdk-lib/aws-applicationautoscaling';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import * as chatbot from 'aws-cdk-lib/aws-chatbot';

// 環境依存の定数を定義 (適宜置き換えてください)
const CLUSTER_NAME = 'your-ecs-cluster-name';
const SERVICE_NAME = 'your-ecs-service-name';
const RDS_IDENTIFIER = 'your-rds-instance-identifier';
const SLACK_CHANNEL_ID = 'C01234567'; // 取得したチャンネルID
const SLACK_WORKSPACE_ID = 'T01234567'; // 取得したワークスペースID

export class MonitoringStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 既存のECSサービスを参照
    const ecsService = ecs.FargateService.fromFargateServiceAttributes(this, 'ExistingEcsService', {
      serviceArn: cdk.Stack.of(this).formatArn({
        service: 'ecs',
        resource: 'service',
        resourceName: `${CLUSTER_NAME}/${SERVICE_NAME}`,
        sep: '/',
      }),
      cluster: ecs.Cluster.fromClusterAttributes(this, 'ExistingCluster', {
        clusterName: CLUSTER_NAME,
        vpc: ({} as any), // 参照のため空オブジェクト
        securityGroups: [],
      }),
    });
  }
}

通知用SNSトピックとChatbotの設定

アラームやイベントが通知を送るSNSトピックを作成し、それをAWS Chatbotに連携させます。

// 1. 通知用SNSトピックの作成
    const alarmTopic = new sns.Topic(this, 'AlarmTopic', {
      displayName: 'System-Monitoring-Notifications',
    });

    // 2. AWS ChatbotとSNSトピックの連携 (Slackへのルーティング)
    new chatbot.SlackChannelConfiguration(this, 'ChatbotConfig', {
      slackChannelConfigurationName: 'EcsRdsMonitoring',
      slackWorkspaceId: SLACK_WORKSPACE_ID,
      slackChannelId: SLACK_CHANNEL_ID,
      notificationTopics: [alarmTopic], // このトピックへの通知がSlackに送られる
    });

ECSとRDSの監視アラーム設定

主要なメトリクスに対してCloudWatchアラームを作成し、アクションとして上記SNSトピックを設定します。

// --- ECS Fargate アラーム ---
    // ECS CPU利用率が80%を超えた場合にアラーム
    const ecsCpuAlarm = new cloudwatch.Alarm(this, 'EcsCpuHighAlarm', {
      metric: cloudwatch.Metric.fromNamespaceAndName('AWS/ECS', 'CPUUtilization').with({
        dimensionsMap: { ClusterName: CLUSTER_NAME, ServiceName: SERVICE_NAME },
      }),
      threshold: 80, 
      evaluationPeriods: 2,
      comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
      alarmDescription: 'ECS Service CPU utilization is too high.',
    });
    ecsCpuAlarm.addAlarmAction(new actions.SnsAction(alarmTopic));
    // ecsCpuAlarm.addOkAction(new actions.SnsAction(alarmTopic)); // 復旧時も通知したい場合は追加

    // --- RDS アラーム ---
    // RDS CPU利用率が70%を超えた場合にアラーム
    const rdsCpuAlarm = new cloudwatch.Alarm(this, 'RdsCpuHighAlarm', {
      metric: cloudwatch.Metric.fromNamespaceAndName('AWS/RDS', 'CPUUtilization').with({
        dimensionsMap: { DBInstanceIdentifier: RDS_IDENTIFIER },
      }),
      threshold: 70, 
      evaluationPeriods: 3,
      comparisonOperator: cloudwatch.ComparisonOperator.GREATER_THAN_OR_EQUAL_TO_THRESHOLD,
      alarmDescription: 'RDS CPU utilization is too high.',
    });
    rdsCpuAlarm.addAlarmAction(new actions.SnsAction(alarmTopic));

ECSサービスのオートスケーリング設定

ECSサービスをCPU利用率$60%$を目標に自動スケーリングするように設定します。

// 3. ECSサービスのオートスケーリング設定
    // サービスのDesired Countをスケーリング対象にする
    const scalableTarget = autoscaling.ScalableTarget.forEcsService(this, 'EcsScalableTarget', {
      service: ecsService,
      minCapacity: 1, // 最小タスク数
      maxCapacity: 5, // 最大タスク数
    });

    // 目標CPU利用率 60% を維持するように調整するターゲット追跡スケーリングポリシー
    scalableTarget.scaleToTrackMetric('CpuScalingPolicy', {
      metric: ecsService.metricCpuUtilization(), 
      targetValue: 60,
      scaleOutCooldown: cdk.Duration.seconds(60),
      scaleInCooldown: cdk.Duration.seconds(300),
    });

// 4. オートスケールイベントを捕捉しSNSトピックへルーティング
    new events.Rule(this, 'AutoScalingNotificationRule', {
      description: 'Notify Slack on successful ECS Auto Scaling events.',
      eventPattern: {
        source: ['aws.application-autoscaling'],
        detailType: ['Application Auto Scaling Policy Execution'],
        detail: {
          // 成功したスケーリング操作のみを通知
          statusCode: ['Successful'], 
        },
      },
      // ターゲットは既存のSNSトピック
      targets: [new targets.SnsTopic(alarmTopic)],
    });

コンテナ技術は現代のアプリケーション開発・運用に欠かせないものとなりましたが、コンテナを運用する上で「セキュリティ」と「イメージサイズ」は常に大きな課題として立ちはだかります。

あなたのコンテナイメージは本当に安全で、そして最小限に保たれていますか？

多くの開発者は、手軽さからコンテナをroot（管理者）権限で実行し、また開発やデバッグに不要なOSパッケージをそのまま含めてしまいがちです。

これが、セキュリティリスクの増大と、イメージサイズの肥大化を招く原因となります。

この記事では、この課題を解決するための Unprivileged（非特権ユーザー実行）とDistroless（ディストロレス）イメージについて、その概念から実践的な使い方、そして運用上の注意点までを解説します。

そもそも「Unprivileged」と「Distroless」とは何か？

1. Unprivileged (非特権ユーザー実行) とは？

Unprivileged実行とは、「最小特権の原則」をコンテナで実践することです。

• 定義
  コンテナ内のメインプロセスをrootユーザー（UID 0）ではなく、一般ユーザー（非特権ユーザー）として実行すること。
• メリット
  コンテナが何らかの理由で侵害されたり、エスケープ（コンテナの外側にあるホストOSへの侵入）が試みられたりした場合でも、プロセスが持つ権限が最小限に抑えられます。
  これにより、ホストシステムへの影響範囲を劇的に制限できます。
• 実現方法
  Dockerfile内でUSER命令を使用して、コンテナの実行ユーザーを切り替えます。

2. Distroless (ディストロレス) イメージとは？

Distrolessイメージとは、セキュリティとサイズを極限まで追求したベースイメージです。

• 定義
  OSディストリビューション（Linux）の要素、具体的にはbash、apt、lsといった一般的なシェルやパッケージ管理ツールを意図的に含めない、アプリケーション実行に必要な最小限のランタイムとライブラリのみで構成されたコンテナイメージです。
• 「通常のイメージ」との違い
  通常のイメージ（例: ubuntu:latest）には多くの汎用ツールが含まれていますが、Distrolessイメージにはそれらが一切含まれていません。デバッグツールさえないため、その名（Distro-less = ディストリビューションがない）が示す通り、極めて軽量です。

Unprivileged & Distroless を組み合わせるメリット

この二つのアプローチを組み合わせることで、コンテナの運用は次のレベルに引き上げられます。

1. 圧倒的なセキュリティ向上

• 攻撃対象領域の削減
  Distroless化により、イメージに含まれるバイナリやライブラリの数が最小限になります。
  その結果、既知の脆弱性（CVE）を持つ可能性のあるパッケージが激減し、攻撃対象となる領域を大幅に縮小します。
• 権限昇格リスクの低減
  Unprivileged実行により、仮にコンテナに侵入されても、攻撃者がホストシステムでroot権限を得るのが極めて困難になります。

2. イメージサイズの劇的な削減

• 不要なOSレイヤーやツールがないため、イメージサイズは通常のベースイメージに比べて数百MB単位で削減されることがあるらしい
• これにより、レジストリへのプッシュ/プル時間が短縮され、デプロイ時間の高速化、そしてストレージコストの削減につながります。

3. ビルド時間の短縮と効率化

ベースイメージが小さくなることで、CI/CDパイプラインでのダウンロード時間が短縮され、コンテナのビルドプロセス全体が効率化されます。

Unprivileged & Distroless なコンテナの使い方

Unprivileged & Distrolessを実現する最も一般的な方法は、マルチステージビルドを利用することです。

1. Distroless イメージの基本構造

1. Build Stage
   開発に必要なコンパイラ、パッケージマネージャなどを含む通常のイメージ（例: golang:latest, node:latest）を使い、アプリケーションのビルドや依存関係のインストールを行います。
2. Final Stage
   Distrolessイメージをベースとし、Build Stageで生成された最終的なバイナリや必要なランタイムファイルだけをコピーします。

2. Unprivileged実行の設定

Distrolessイメージの多く（例: gcr.io/distroless/...）は、セキュリティのため、デフォルトで非rootユーザー（例: nonroot）が設定されています。

もしご自身でベースイメージから構築する場合、Dockerfileに以下のコマンドを追加してユーザーを切り替えます。

# ユーザーを作成し、パーミッションを設定
RUN adduser --disabled-password --gecos "" appuser

# 実行ユーザーを一般ユーザーに切り替える
USER appuser

運用上の注意点：非特権ユーザーとポート番号の壁

UnprivilegedコンテナをECS（または任意のLinuxホスト）で運用する際、セキュリティの恩恵と引き換えに、ある実用上の課題に直面します。

1. ポート1024未満のバインドはroot権限が必要

Linux OSのセキュリティ原則により、Webサーバーなどで一般的に使われるポート番号1024未満（ウェルノウンポート、例: HTTPの80、HTTPSの443）にバインドするには、root権限（特権）が必要です。

あなたがECSでUnprivilegedかつDistrolessなNginxイメージを使った際、Nginxがデフォルトで80番ポートを使おうとすると、権限がないため「Permission Denied」といったエラーが発生し、コンテナの起動に失敗してしまいます。

2. ECS/Fargate環境での具体的な解決策

この問題を解決しつつ、Unprivilegedのセキュリティメリットを維持するには、以下の方法が最も推奨されます。

1. アプリケーション側のポート変更:Webサーバー（Nginxなど）の設定ファイルを変更し、1024番以上のポート（例: 8080、8081）で待ち受けるように設定を変更します。
2. ロードバランサー (ALB) でのポートマッピング:
   • ECS（Fargate）のタスク定義で、コンテナが使用するポートを8080などに設定します。
   • Application Load Balancer (ALB) を利用し、ALBは外部からのアクセスを80番（標準HTTP）で受けます。
   • ALBは、内部のECSタスクグループに対しては8080番でルーティングします。

これにより、コンテナ内部は非特権ユーザーで安全に運用され、外部ユーザーはポート番号を意識することなくWebサイトにアクセスできるようになります。

次世代コンテナの標準へ

UnprivilegedとDistrolessの組み合わせは、コンテナのセキュリティ基準とデプロイ効率を大きく引き上げる、次世代コンテナの標準パターンです。

• Distroless: 攻撃対象領域とイメージサイズを最小化。
• Unprivileged: 権限昇格リスクを最小化。

特にECSなどの本番環境で運用する際は、ポート1024未満の制限に注意を払い、ロードバランサーを活用して安全かつ効率的な構成を構築しましょう。

あなたのプロジェクトも、今日からこの強力なセキュリティパターンに移行してみませんか？

しかし、ローカルのDocker Compose環境では問題なく動作しても、AWSのECS Fargateのような本番環境にデプロイしようとすると、いくつかの疑問に直面します。

• 「NginxとPHP-FPMコンテナはどう連携させるのがベスト？」
• 「fastcgi_pass ってローカルと設定を変える必要ある？」
• 「InertiaでビルドしたReactのJS/CSSファイルは、結局どのコンテナに置くのが正解？」

この記事では、fastcgi_pass の基本から、ECS Fargateでの最適なコンテナ構成、そしてInertia/Reactプロジェクト特有の「静的ファイルの配置場所」問題までを、順を追って解説します。

fastcgi_pass とは？

NginxとPHP-FPMの「橋渡し」

まず基本のおさらいです。Nginxは高性能なWebサーバーですが、それ自体はPHPコードを実行できません。
一方、PHP-FPMはPHPコードを実行することに特化したプロセス（サーバー）です。

Nginxがクライアント（ブラウザ）から .php ファイルへのリクエストを受け取ったとき、そのリクエストをPHP-FPMに処理してもらう必要があります。

このとき、Nginxの設定ファイル（nginx.conf）で、「どのPHP-FPMに処理を依頼するか」の宛先を指定するのが fastcgi_pass ディレクティブです。

location ~ \.php$ {
    # ...
    # ↓ この一行が「橋渡し」の指定
    fastcgi_pass php-fpm-server:9000; 
}

ローカル開発 (Docker Compose) での構成

ローカル開発では、「1コンテナ1責務」の原則に従い、NginxとPHP-FPMを別々のコンテナとして docker-compose.yml で定義するのが一般的です。

# docker-compose.yml (抜粋)
version: '3'
services:
  # Nginxコンテナ
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./nginx.conf:/etc/nginx/conf.d/default.conf
      - ./laravel-project:/var/www/html

  # PHP-FPMコンテナ
  php:
    build: . # PHP-FPMとLaravelコードを含むDockerfile
    volumes:
      - ./laravel-project:/var/www/html

この構成では、NginxコンテナとPHPコンテナは 別々のネットワーク空間 に存在します。Docker Composeが提供する内部ネットワークを介して、サービス名で通信します。

したがって、NginxコンテナからPHPコンテナへは、php というサービス名（ホスト名）を使ってアクセスします。

# nginx.conf (Docker Compose用)
location ~ \.php$ {
    # ...
    # 'php' サービス（コンテナ）の 9000番ポートに転送
    fastcgi_pass php:9000;
}

（※ このTCP/IP通信によるパフォーマンスやセキュリティの懸念は、コンテナ間通信がDockerの内部ネットワークに限定されていれば、実用上ほとんど問題になりません。）

【1タスク2コンテナ】本番 (ECS Fargate) での構成：

さて、本題のECS Fargateです。
ECSでは、docker-compose.yml に相当するものとして「タスク定義 (Task Definition)」を使います。

ここで重要なキーポイントは、「1つのタスク定義の中で、NginxコンテナとPHP-FPMコンテナの2つを定義する」ことです。

これら2つのコンテナは、1セットで「Webアプリケーションサーバー」として機能します。

ECS Fargateでのfastcgi_passはどうなる？

ECSの同一タスク内で実行されるコンテナは、同じネットワーク空間（ネットワークモード awsvpc）を共有します。

これは、Nginxコンテナから見ると、PHP-FPMコンテナが「他人」ではなく、「自分自身（localhost）」として見えることを意味します。

したがって、ECS Fargate用のNginxイメージに含める nginx.conf の設定は、以下のようになります。

# nginx.conf (ECS Fargate用)
location ~ \.php$ {
    # ...
    # サービス名ではなく、localhost (127.0.0.1) を指定する
    fastcgi_pass 127.0.0.1:9000;
}

タスク定義のイメージ

タスク定義では、以下のように設定します。

• コンテナ-A: php-fpm-container
  • イメージ: （Laravelコードを含むPHP-FPMイメージ）
  • ポートマッピング: なし (外部に公開する必要はないため)
• コンテナ-B: nginx-container
  • イメージ: （設定済みのnginx.confと静的ファイルを含むNginxイメージ）
  • ポートマッピング: 80:80 (ALBからのトラフィックを受け取るため)

ALB（ロードバランサー）からのトラフィックはNginxコンテナが受け取り、必要に応じて localhost:9000 を介してPHP-FPMコンテナに処理を渡します。

Inertia/Reactのビルドファイルはどこに置く？

ここで、Inertia/React構成特有の問題に直面します。

「InertiaはLaravel（PHP）がビューを配信する仕組みだから、npm run build で生成された public/build フォルダは、PHP-FPMコンテナにだけ置けば良いのでは？」

これはよくある誤解ですが、パフォーマンスと責務分離の観点から、ビルドした静的ファイル（JS/CSS）はNginxコンテナに配置するのが正解です。

この理由を理解するために、Inertiaのページが読み込まれる2段階のフローを見てみましょう。

ステップ1: HTMLシェルのリクエスト (PHP-FPMが処理)

1. ブラウザが https://example.com/dashboard にアクセスします。
2. ALB → Nginxコンテナがリクエストを受け取ります。
3. NginxはこれがPHPのリクエストだと判断し、fastcgi_pass 127.0.0.1:9000 を使ってPHP-FPMコンテナに転送します。
4. PHP (Laravel) が起動し、Inertiaは app.blade.php をレンダリングしようとします。
5. このとき、PHPは public/build/manifest.json を読み取り、HTMLに含めるべきJS/CSSのファイル名を特定します。
6. PHPは以下のようなHTMLの「ガワ」を生成し、Nginx経由でブラウザに返します。

   <html>
   <head>
       <script src="/build/assets/app.12345.js" defer></script>
       <link rel="stylesheet" href="/build/assets/app.67890.css">
   </head>
   <body>
       <div id="app" data-page="..."></div>
   </body>
   </html>
   

ステップ2: 静的アセット(JS/CSS)のリクエスト (Nginxが処理)

1. ブラウザは、ステップ1で受け取ったHTMLを解析します。
2. 「/build/assets/app.12345.js と /build/assets/app.67890.css が必要だ」と判断し、ブラウザは別途2回のリクエストをサーバーに送信します。
3. このリクエストは、もはやPHPとは全く関係ありません。
4. ALB → Nginxコンテナがこの2つのリクエストを受け取ります。
5. Nginxは「自分の管理下（public フォルダ）にそのファイルがあるか？」を探します。
6. Nginxコンテナに public/build/ 以下の実体ファイルが存在するため、NginxはPHP-FPMを起動することなく、それらの静的ファイルを超高速でブラウザに直接返します。

もし、NginxコンテナにJS/CSSファイルがなければ、このリクエストもPHP-FPMに転送されてしまい、「JSファイルを取得するためだけにLaravelを起動する」という深刻なパフォーマンスボトルネックが発生します。

CI/CDでのベストプラクティス

上記2ステップから、CI/CDパイプラインでDockerイメージをビルドする際は、以下の構成が最適です。

1. npm run build を実行し、public/build ディレクトリを生成します。
2. PHP-FPMイメージのビルド:
   • Laravelのコード（app/, routes/ など）をコピーします。
   • ステップ1のために public/build/manifest.json をコピーします。（リンク生成に必要）
3. Nginxイメージのビルド:
   • nginx.conf をコピーします。
   • ステップ2のために public フォルダ全体（index.php と、public/build 以下の 全てのJS/CSSファイル を含む）をコピーします。（静的アセットの配信用）

結論

manifest.json はPHP-FPMコンテナに、JS/CSSの実体ファイルはNginxコンテナに必要です。

両方のイメージに public フォルダ（または public/build）全体をコピーするのが、最もシンプルで確実な方法です。

まとめ

ECS Fargateで Laravel + Inertia + React 構成を動かすための要点をまとめます。

1. 構成: 「1タスク2コンテナ（Nginx + PHP-FPM）」構成を採用します。
2. fastcgi_pass: NginxからPHP-FPMへの通信は、同一タスク内のため fastcgi_pass 127.0.0.1:9000; を指定します。
3. 静的ファイル: ビルドしたJS/CSSは、パフォーマンス最適化のためNginxコンテナに配置し、Nginxから直接配信させます。
4. manifest.json: HTMLシェル生成のため、PHP-FPMコンテナにも manifest.json が必要です。

この構成により、PHP-FPMは動的処理に専念し、Nginxは静的ファイルの高速配信に専念するという、「1コンテナ1責務」のメリットを最大限に活かした、スケーラブルな本番環境を構築できます。

「ALBでHTTPS化したのに、なぜ後ろにいるECSコンテナはポート80（HTTP）のままで通信できるんだろう？」

この一見不思議な挙動は、ALBが持つ2つの重要な役割を理解することで、スッキリと解決します。今回は、このALBの「魔法」の仕組みを、セキュリティグループの設定から紐解いていきましょう。

最終的な構成：安全な3層アーキテクチャ

まず、私たちが目指すのは、セキュリティと可用性のベストプラクティスに基づいた、以下のような3層アーキテクチャです。

• Web層: ALBがインターネットからのリクエストをすべて受け付けます。
• AP層: ECSコンテナがプライベートな領域でアプリケーションを動かします。
• DB層: RDSがさらに内側のプライベートな領域でデータを安全に保管します。

この構成のセキュリティの肝は「ECSはALBからの通信しか受け付けない」というルールです。これを実現するのが、次に説明するセキュリティグループです。

門番の役割を担う「セキュリティグループ」

セキュリティグループは、リソースのドアを守る「バーチャルな門番」です。今回は3人の門番を配置します。

1. ALBの門番: インターネットからの訪問者（ポート80, 443）を全員受け入れます。
2. ECSの門番: ALBの門番から紹介された人（ALBからのトラフィック）だけを通します。それ以外の人は全員お断りです。
3. RDSの門番: ECSの門番から紹介された人（ECSからのトラフィック）だけを通します。

この連携により、たとえ攻撃者がECSに直接アクセスしようとしても、門前払いされる仕組みが完成します。

ALBがこなす2つの全く異なる仕事

さて、ここからが本題です。ユーザーがhttp://でアクセスしてきた時に、ALBとコンテナの間で何が起きているのでしょうか。実は、これは2段階の独立した処理になっています。

ポイントは役割が2つ存在するということです。

ブラウザへの「リダイレクト指示」

最初のやり取りは、ユーザーのブラウザとALBの間だけで完結します。

1. ユーザー: ブラウザで http://example.com (ポート80) にアクセス。
2. ALB (ポート80の受付係): リクエストを受け取ると、中身は見ずにこう応答します。「すみません、こちらの窓口は安全ではありません。向かいにある安全な443番の窓口へ行き直してください」。これがHTTP 301リダイレクトです。

この時点では、リクエストはまだECSコンテナには一切届いていません。

ステップ2：コンテナへの「リクエスト転送」

ブラウザはALBからの指示に従い、今度は最初から安全な窓口へ向かいます。

1. ユーザー: ブラウザが自動的に https://example.com (ポート443) に新しいリクエストを送信します。
2. ALB (ポート443の受付係):
   • 暗号化されたリクエストを受け取り、持っているSSL証明書を使って通信を復号します（SSL/TLS終端）。
   • 安全な平文になったリクエストを、宛先であるECSコンテナのポート80へ転送（フォワード）します。
3. ECSコンテナ (ポート80): ALBから来た通常のHTTPリクエストを受け取り、処理を実行します。

このように、ALBはユーザーを正しい入口へ案内する「案内係」の仕事と、リクエストを内部の担当者へ届ける「取次係」の仕事という、2つの全く異なる役割をこなしているのです。

コンテナからすれば、常にALBという信頼できる取次係から、暗号化が解かれた分かりやすいリクエストが届くだけなので、ポート80で待ち受けていれば良い、というわけです。

非常に便利ですね。。

CDKの実装

SecurityGroup の実装

// ALB用セキュリティグループ
const albSecurityGroup = new ec2.SecurityGroup(this, 'AlbSg', { vpc });
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(80), 'Allow HTTP');
albSecurityGroup.addIngressRule(ec2.Peer.anyIpv4(), ec2.Port.tcp(443), 'Allow HTTPS');

// ECS用セキュリティグループ
const ecsSecurityGroup = new ec2.SecurityGroup(this, 'EcsSg', { vpc });
// ALBからの通信のみを、コンテナのポート80で許可
ecsSecurityGroup.addIngressRule(
    albSecurityGroup,
    ec2.Port.tcp(80),
    'Allow traffic only from ALB'
);

ALBリスナー

// ALB本体を作成
const alb = new elbv2.ApplicationLoadBalancer(this, 'MyAlb', {
    vpc,
    internetFacing: true,
    securityGroup: albSecurityGroup,
});

// HTTPリスナー (ポート80): HTTPSへリダイレクトするだけ
alb.addListener('HttpListener', {
    port: 80,
    defaultAction: elbv2.ListenerAction.redirect({
        protocol: 'HTTPS',
        port: '443',
        permanent: true,
    }),
});

// HTTPSリスナー (ポート443): ECSへリクエストを転送する
alb.addListener('HttpsListener', {
    port: 443,
    certificates: [certificate], // ACMで発行した証明書
    defaultAction: elbv2.ListenerAction.forward([ecsTargetGroup]), // ECSのターゲットグループ
});

まとめ

• ALBのHTTP→HTTPSリダイレクトは、「リダイレクト指示」と「リクエスト転送」の2段階で行われる。
• SSL/TLSによる暗号化・復号の処理はALBがすべて肩代わりしてくれる（SSL/TLS終端）。
• コンテナは、ALBから転送されてくる暗号化されていないHTTPリクエストを受け取るだけで良い。
• セキュリティグループを正しく設定することで、この安全な通信経路が完成する。

役割が2つあることが分からなければ理解できなかったなぁ。

参考記事

この記事では、この攻撃の仕組みと、特にNginxを使っている場合にどのように対策すべきかを分かりやすく解説します。

そもそも「クラウドメタデータ」って何？

クラウド環境でサーバー（インスタンス）を動かしていると、「メタデータ」というものが存在します。これは、そのサーバー自身の「身分証明書」のような情報です。

具体的には、以下のような情報が含まれます。

• インスタンスID: そのサーバー固有の識別番号
• ロール・認証情報: そのサーバーが他のクラウドサービスにアクセスするための権限や秘密鍵など
• ネットワーク情報: サーバーのIPアドレスなど
• 起動スクリプト: サーバーが起動時に実行するコマンド

これらの情報は、サーバーが自分自身を識別したり、他のクラウドサービスと安全に連携したりするために非常に重要です。そして、これらのメタデータには通常、**169.254.169.254**という特別なIPアドレスを介して、サーバー内部からのみアクセスできるようになっています。

169.254.169.254ってどんなIP？

この169.254.169.254というIPアドレスは、「リンクローカルアドレス」と呼ばれる特殊な範囲のIPアドレスです。これは、インターネットのような外部ネットワークからはアクセスできない、サーバー自身の内部ネットワークでのみ有効なIPアドレスです。

つまり、通常は外部からこのIPアドレスにアクセスすることはできず、サーバー内部のアプリケーションだけが、自分自身の情報を安全に取得するために使います。

クラウドメタデータ攻撃の仕組み

「クラウドメタデータ攻撃」は、この本来アクセスできないはずのメタデータに、不適切な設定を悪用してアクセスしようとする攻撃です。

攻撃者が狙うのは、ウェブサーバーとしてよく使われる「Nginx（エンジンエックス）」の設定ミスです。

curl -H "X-aws-ec2-metadata-token: $(curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")" http://169.254.169.254/latest/meta-data/

攻撃の手順

1. Nginxの誤設定: ウェブサーバーのNginxが、特定のルールなしに外部からのリクエストを内部のIPアドレスに転送してしまうような、不適切な設定になっているのが攻撃の前提です。
2. 特別なリクエストの送信: 攻撃者は、ウェブブラウザなどから、悪意のあるHTTPリクエストをNginxサーバーに送ります。このとき、リクエストの「Hostヘッダー」という部分に、先ほどのメタデータ用IPアドレスである169.254.169.254を意図的に含めます。
3. Nginxの転送: 誤設定されたNginxは、このHostヘッダーに169.254.169.254が含まれているリクエストを、本来ルーティング不可能なはずの内部メタデータサービスへ転送してしまいます。
4. メタデータの取得: 結果として、外部の攻撃者が、サーバーの機密性の高いメタデータ（認証情報など）を不正に取得できてしまうのです。

この攻撃が成功すると、攻撃者はサーバーになりすまして他のクラウドサービスへアクセスしたり、機密情報を盗み取ったりするなど、さらに深刻な被害につながる可能性があります。

3. Nginxでクラウドメタデータ攻撃を防ぐ方法

この攻撃を防ぐための最も効果的で直接的な方法は、Nginxの設定を正しく行うことです。

Nginxの設定ファイル（通常は/etc/nginx/nginx.confや/etc/nginx/conf.d/内のサイト設定ファイル）に、以下のルールを追加しましょう。

server {
    listen 80;
    listen 443 ssl; # HTTPSを使用している場合
    server_name your-domain.com; # 実際のドメイン名に置き換えてください

    location / {
        # HostヘッダーがメタデータIPアドレス（169.254.169.254）の場合、
        # アクセスを拒否し、403 Forbiddenエラーを返す
        if ($http_host = "169.254.169.254") {
            return 403;
        }
    }

    # その他のNginx設定
    # ...
}

設定のポイント

• if ($http_host = "169.254.169.254"): これが核心的な部分です。受信したリクエストのHostヘッダーが169.254.169.254であるかをチェックします。
• return 403;: もし一致した場合、そのリクエストをサーバーの内部処理に進ませず、すぐに「403 Forbidden（アクセス禁止）」のエラーを返します。これにより、攻撃者がメタデータにアクセスするのを防ぎます。

この設定を追加したら、必ずNginxの設定をテストし、再読み込み（または再起動）するのを忘れないでください。

sudo nginx -t # 設定ファイルの文法チェック
sudo systemctl reload nginx # Nginxの設定を再読み込み

まとめ

クラウドメタデータ攻撃は、クラウド環境を利用する上で注意すべきサイバー脅威の一つです。しかし、適切なNginxの設定を行うことで、このリスクを効果的に軽減できます。

あなたのウェブサーバーが安全に稼働しているか、今一度Nginxの設定を見直してみてはいかがでしょうか？

Ubuntu：24.04
PHP：8.2
Laravel：11.x

起こったこと

NginxをWebサーバーとして、LaravelアプリケーションとPHP-FPMを連携させている環境で、ある日突然 upstream sent too big header while reading response header from upstream というエラーがNginxのエラーログに表示され、Webサイトが正常に表示されなくなリマした…

調べていくと、このエラーは、PHP-FPM（アップストリームサーバー）がNginxに返そうとしたHTTPレスポンスヘッダーのサイズが、Nginxが受け入れられる設定値の上限を超えてしまった場合に発生します。

特にLaravelのような動的なアプリケーションでは、セッション情報やクッキーの肥大化が原因で発生しやすい問題とのことでやんす。

エラーが起きる原因は？

NginxがWebサーバーとしてクライアントからのリクエストを受け取り、それをバックエンドのPHP-FPM（FastCGIプロセス）に渡して処理してもらいます。

PHP-FPMが処理を終えてNginxに応答を返す際、そのHTTPレスポンスにはヘッダー情報が含まれます。このヘッダー情報がNginxが設定しているバッファのサイズを超えると、エラーが発生してしまいます。

主な原因として、以下のようなものが挙げられます。

• セッションデータの肥大化: Laravelなどのフレームワークでセッションをクッキーベースで管理している場合、ユーザーが多くの情報をセッションに保存したり、ショッピングカートに大量のアイテムを追加したりすると、クッキーのサイズが大きくなります。この大きなクッキー情報がレスポンスヘッダーに含まれることで、上限を超えてしまうことがあります。
• 多数のクッキーやカスタムヘッダー: アプリケーションが非常に多くのクッキーを設定している、または独自のカスタムヘッダーを大量に追加している場合も、ヘッダー全体のサイズが大きくなります。
• リダイレクトループ: 不適切なリダイレクト設定により、ブラウザが何度もリダイレクトを繰り返す際、そのたびに新しいクッキーやヘッダーが付与され、最終的にヘッダーが大きくなってしまうケースも考えられます。

解決策：Nginxの設定を調整する

最も手軽で直接的な解決策は、Nginxが受け入れられるヘッダーバッファのサイズを増やすことです。

Nginxの設定ファイル（通常は /etc/nginx/nginx.conf か、サイト固有の .conf ファイル）を開き、http ブロック内、または対象の server ブロック内に以下のディレクティブを追加または調整します。http ブロックに記述すると、すべてのバーチャルホストに適用されます。

http {
    # ... 他の http ブロック内の設定 ...

    # upstream sent too big header エラー対策
    # PHP-FPM（FastCGI）からのレスポンスヘッダーに対応するため、fastcgi_ のディレクティブを設定します。
    # 必要に応じて proxy_ のディレクティブも設定しますが、PHP-FPMの場合はfastcgi_を優先します。
    fastcgi_buffer_size 128k;   # FastCGIヘッダーバッファの初期サイズ。デフォルトは4k/8k。
    fastcgi_buffers     4 256k; # 256KBのバッファを4つ用意。合計1MB。

    # 必要に応じて、もしプロキシとして使用している場合も考慮するなら、こちらも設定
    # proxy_buffer_size   128k;
    # proxy_buffers       4 256k;
    # proxy_busy_buffers_size 256k;

    # ... 他の http ブロック内の設定 ...
}

ディレクティブの解説

• fastcgi_buffer_size: NginxがFastCGIからのレスポンスヘッダーを読み込むための最初のバッファサイズを指定します。デフォルト値（通常は 4k または 8k）よりも大きな値（例：128k）を設定することで、大きなヘッダーにも対応できるようになります。
• fastcgi_buffers: ヘッダーを含むレスポンス全体をバッファリングするためのバッファの数とサイズを設定します。上記の例では、256KBのバッファを4つ使用し、合計で1MBのバッファスペースを確保します。

注意点: これらの値を必要以上に大きくしすぎると、Nginxが使用するメモリ量が増加し、サーバーリソースを圧迫する可能性があります。まずはエラーが出なくなる最小限の増加から試し、サーバーの負荷状況を見ながら調整してください。

設定変更後の手順

1. Nginx設定ファイルを保存: 変更したNginx設定ファイルを保存します。
2. 設定ファイルのテスト:
   sudo nginx -t

    

   このコマンドで構文エラーがないかを確認します。test is successful と表示されればOKです。

3. Nginxのリロード:

   sudo systemctl reload nginx
   

    

   Nginxサービスをリロードして、新しい設定を適用します。

これで、Nginxが大きなHTTPレスポンスヘッダーを適切に処理できるようになり、「upstream sent too big header」エラーは解消されるはずです。

根本的な解決策：Laravelアプリケーション側の最適化

Nginxの設定でエラーを抑制できますが、Laravelアプリケーション側で不必要に大きなヘッダーが生成されている場合は、そちらの最適化も検討することをお勧めします。

• セッションデータの見直し:
  • クッキーに保存しているセッションデータが大きすぎる場合、データベースやRedisなどのサーバーサイドストレージにセッションを保存するようにLaravelの設定を変更することを検討してください。これにより、クッキーにセッションIDのみが保存されるため、クッキーのサイズを大幅に削減できます。Laravelのセッション設定は config/session.php で変更可能です。
• クッキーの管理:
  • アプリケーションが設定しているクッキーの数や、個々のクッキーのサイズを減らせないかレビューします。不要なクッキーは削除しましょう。
• カスタムヘッダーの確認:
  • アプリケーションがレスポンスに含めているカスタムHTTPヘッダーが多すぎないか、または内容が大きすぎないかを確認します。

Nginxの設定調整で当面のエラーは解消されますが、アプリケーションの効率性を高めるためにも、Laravel側のヘッダー生成ロジックを見直すことは良いプラクティスです。

今日は、僕がAWS環境で構築したWEBアプリケーションがDoS攻撃を受け、サーバーダウンに至った際の障害対応について、その全貌を語りたいと思います。

特に、ALB（Application Load Balancer）の思わぬ落とし穴が原因だったという、衝撃の事実を皆さんに共有します。
同じような問題で悩んでいる方、これからAWS環境を構築する方は、ぜひ参考にしてください。

障害内容

ある日突然、ALB配下のアプリケーションサーバーがDoS攻撃によりダウンしてしまいました。

緊急事態発生です！確認すると、アクセスのあったIPはまさかのオレゴンリージョンから。

僕が管理しているアプリケーションサーバーは東京リージョンにあるため、なぜ遠く離れたオレゴンから大量のアクセスが来ているのか、この時点では全く見当がつきませんでした。

調査内容

まずは手がかりを求めて、nginxやアプリケーションのアクセスログ、エラーログを徹底的に漁りました。
しかし、一向に決定的な手がかりが見つかりません。

そんな中、アクセスログを注意深く見ていたところ、ある異変に気づきました。
通常、僕たちが意図的に公開している EIP で抑えているグローバルIPとは全く関係ないIPアドレスから、アプリケーションサーバーにアクセスが到達しているのです。

そこで、すかさずdigコマンドを実行してみると、やはり先ほどのEIPとは無関係のIPアドレスが確認できました。
しかし、「なぜ、僕たちに関わりのないIPがアプリケーションへアクセスを流しているんだ？」

この疑問が頭から離れません。ルーティングテーブルや他のAWSリソースを調べても問題は見当たらず、「うーん、わからない…」という状況が3時間ほど続きました。

精神的に疲弊し始めたその時、ふとALB（Application Load Balancer）のルールに問題があるのではないかという考えがよぎりました。そして、確認してみると…ビンゴです！

ALBのデフォルトルールが、アプリケーションサーバーが所属するターゲットグループにトラフィックを転送する設定になっていたのです。

そして、Route 53のAレコードにALBのエイリアスを指定していることで、ALBに紐づくサブネットのグローバルIPでもアクセスが可能になっている仕様もここで理解しました。

つまり、ALBのグローバルIPに直接アクセスが入ると、意図せずアプリケーションサーバーへ流れてしまう状態になっていたのです。

この瞬間、「これで勝ち確定！」と心の中で叫びましたね。

対策

今回の障害を受けて、最も効果的な対策はALBのデフォルトルールを適切に設定することです。意図しないアクセスをアプリケーションサーバーに流さないために、以下のように設定することをおすすめします。

• デフォルトルールで固定レスポンスを返す:レスポンスコード: 503 Service Unavailable
• 本文: 許可されていないリクエストです

これにより、正規のドメインを通さないALBへの直接アクセスはアプリケーションサーバーに到達せず、DoS攻撃のリスクを大幅に低減できます。

もし、プロジェクトの制約上、固定レスポンスを返すのが難しい場合は、少なくともアプリケーションサーバーへリクエストを流さない設定にすることが重要です。例えば、別のダミーのターゲットグループを指定するか、アクセスを拒否するアクションを設定することも検討してください。

調査に使ったもの

nginx のアクセスログ

該当のリクエストがあった時間帯のアクセスを dig ることで出どころのIP等がわかります。

IPでどの辺りの地域かが判別できたり、content-type を元に BOT からのリクエストなのかがわかったりします。一旦、アクセスログを覗いてみましょう。

2025年に入って、生成AIからのリクエストが頻繁に来ている事を確認できているのでアクセスログを覗いてみると面白いですよ。

VPC フローログ

AWS のサービスです。VPC内の監視ができるのでかなり有用です。。使っていないプロジェクトは導入オススメします。

VPC、サブネット、またはネットワークインターフェイスのフローログを作成できます。サブネットまたは VPC のフローログを作成する場合、そのサブネットまたは VPC 内の各ネットワークインターフェイスが監視されます。

監視されるネットワークインターフェイスのフローログデータは、フローログレコードとして記録されます。これは、トラフィックフローについて説明するフィールドで構成されるログイベントです。詳細については、「フローログレコード」を参照してください

フローログの基礎

コマンド類

nslookup

DNS が正しく設定されているか、IPがEIPと同値かに使用した、

dig

ドメイン名に関する詳細な情報を取得するためのツールです。今回はDNSの設定が正しいか検証するために使用しました。

tail

アクセスログを掘り起こすのに使用しました。リアルタイム監視を後輩に見せたら尊敬されたのでドヤりたい人使ってください。（後輩が可愛いだけ

まとめ

誰でも簡単に作れるようになっているのがAWSの特徴ですが、結果として穴ができてしまうことが多々あるので皆さんの環境も見てみましょう。

アプリケーションの外に興味を持ったことがキッカケでAWSの世界に足を踏み入れて1年ちょっとが経ちます。

そんなPHPerがAWS SAA(c03) に合格した話をしたいと思います〜

SAA C03 とは

AWS Certified Solutions Architect – Associate とは、 中級レベルに位置する AWS 認定資格です。

レベルとしては、4段階の下から2番目の資格となるため、難易度は高くはありません。

AWS 認定ソリューションアーキテクト – アソシエイトは、コストとパフォーマンスが最適化されたソリューションの設計に重点を置いています。これは、AWS クラウドまたはオンプレミス IT での経験が豊富な受験者にとって理想的な出発点です

AWS Certified Solutions Architect – Associate

カテゴリ	Associate
試験時間	130分
試験形式	65 個の問題 (複数選択または複数応答のいずれか)
コスト	150 USD。 為替レートを含むコストに関する他の情報については、「試験の料金」にアクセスしてください
受験オプション	Pearson VUE テストセンターまたはオンライン監督付き試験
対象言語	英語、フランス語 (フランス)、ドイツ語、イタリア語、日本語、韓国語、ポルトガル語 (ブラジル)、中国語 (簡体字)、スペイン語 (ラテンアメリカ)、スペイン語 (スペイン)、中国語 (繁体字)

AWS Certified Solutions Architect – Associate

受験者の経歴

• 基本的にバックエンドを生業としているアプリケーションプログラマー
• たまにサーバー構築/保守 のお仕事
• AWS 歴は3年(素人レベルの仕事
• 受験前に触ったことのあるサービス（基本的にLAMPに関わるサービスのみ
  • EC2
  • ALB
  • ECS
  • Lambda
  • RDS
  • S3
  • Cloud Watch
  • SQS
  • SES

[getpost id=”1842″ cat_name=”1″ date=”0″]

[getpost id=”1710″ cat_name=”1″ date=”0″]

[getpost id=”1448″ cat_name=”1″ date=”0″]

合格するための勉強法

Ping-t

Ping-t を中心に学習を進めました。

Ping-t は、1問1答型式で問題を解いていくことができ、分からないを解決しながら各種サービスの理解を深めていくことができる優れモノです。

各種サービスごとの問題集や試験レベルの問題を用意していくており、ひたらすら解いていくことで徐々に知識がついていきます。

SAA に関しては、完全無料で使うことができるため、 受験予定者はぜひ使っていただきたい神サービスです。（インフラ系の他資格の対策も練ることができるみたいなので、サイト閲覧してみてえください〜

AWS Black Belt

問題を解くだけでは、受験するメリットが薄まってしまいそうだったため、PHPerとして業務に関わりそうな以下のサービスに関しては、AWS Black Belt でお勉強をしました。

• EC2 + Auto Scaling
• RDS/Aurora
• DynamoDB
• ElastiCache
• S3/EFS
• SQS/SNS

あるべき姿を考えると試験範囲の全てのBlackBeltを読むべきだったのですが、残念ながら時間を確保することが難しかったため自分の業務に関わりそうなサービスだけ読んだ形になります。
資格取得のために Ping-t をひたらすら解いたのですが、業務に活かすという観点からは 公式資料を熟読している方が有意義でした。

総勉強時間

だいたい3週間ほど試験対策を行いました。

• 7日間: Black Belt
• 14日間: Ping-t

子育ての合間を縫っての勉強になったため結構な時間がかかってしまったのですが、 サーバー構築を1度でもやったことがある方だと、 Ping-t を3日間くらいやり込んだら取れるのではないかと思います。

なぜ、 サーバー構築を1度でもやったことがある人が3日間で取得可能かというと、サーバー構築をやるにあたって以下の知識が必要になってくるからです。
※ 深い知見は必要ないです。 DNS とは ドメイン管理しているサービスです くらいが言えるレベル感を指しています。

• ネットワーク
• DNS
• Linux

これらの基礎知識があれば、AWS の各種サービスについて学習していくだけで当たり前ですが合格できちゃいます。

逆にサーバー周りが何にも分からないって人は試験勉強の一環として一度だけLAMP環境を立ててみてほしいです。 Ping-t の解説がなるほど〜 となったり、 AWS の提供しているマネージドサービスに感動する事ができます。

普通に勉強すればどんな人でも合格可能な資格ですので、皆さん頑張っていきましょう〜

じゃーん

取得するとAWSの業務をこなせるようになるのか？

答えは No です。

合格するとAWS の各種サービスについて理解がある状態になるのですが、業務に速攻で活きるということは絶対にありません。

今のインフラ構成がAWS のベストプラクティスに反していることが分かっていても、過去に何があって今の構成に至っているかを把握しながら

受験したことで得た知識

業務に活きそうな知識は以下のとおりです。

• Lambda
  • コールドスタート対策
  • イベント駆動型での活用(SNS/SQS)
  • VPC内への配置
• S3/EFS
  • コスト低下戦略
  • アップロードの最適化
  • Putイベント
• RDS/Aurora
  • マルチリージョン
  • RDS Proxy
• ALB/NLB
  • パフォーマンス最適化
  • マルチリージョン
• VPCに関わるネットワーク
  • ピアリング
  • マルチリージョン
  • オンプレとの通信
• オンプレとクラウドのハイブリット戦略
  • ストレージ間の同期
    • データ転送量を考慮した構成/サービス
  • アプリケーションはオンプレ、データ基盤はクラウド
  • オンプレ配置されているデータセンターへのクラウド基盤の貸し出し

番外編の知識としては、学習していく中でたまたま出会えた知見たちです。
目からウロコのものもあったので、この辺りは勉強しておいて良かったなぁ〜と思っている所存です。

• DB インスタンスもセキュリティグループを絞る事を前提にパブリックサブネットに置いても良いんじゃないか説
• SSH 鍵を不要とする戦略

PHPer としての SAA の次のステップ

今のところ、SAAの上位資格のSAPを取得するつもりはありません。
前述した通り、資格を取ったからといって業務に直ぐに活きるということがないため、AWSの世界にどっぷり入ることになったタイミングで Professional 資格に挑もうと思います。

これからの目標としては、PHP に直接関わりのある MySQL や nginx といったミドルウェアや DevOps として CI/CD , IaC について知見を深めることができるといいなぁと考えています。

MySQL

• Materialized View
• Window関数, JSONの扱い
• パフォーマンスチューニング

nginx

• セキュリティに係るHTTPヘッダー
• プロセス管理

DevOps

• CI/CD （GitHub Actionis
• IaC （Terraform