【AWS高可用＆セキュリティ設計】ALB × WAF × Firehose × Multi-AZ ASGによる脆弱性遮断と監査ログ外部連携パイプライン

Posted at 2026-09-28

📌 はじめに

単一のアベイラビリティゾーン（Single AZ）で稼働する Web アプリケーションは、AZ レベルの障害に対して無防備であり、エンタープライズの可用性要件（SLA）を満たすことができません。また、パブリック公開されるシステムでは、SQL インジェクション（SQLi）やクロスサイトスクリプティング（XSS）といった Web 脆弱性攻撃から保護し、拒否された不正リクエスト（Blocked Requests）をリアルタイムに第三者監査基盤へ連携する仕組みが強く求められます。

今回は、「Multi-AZ Auto Scaling Group による単一障害点（SPOF）の排除」、「AWS WAF によるマネージド型脆弱性遮断」、そして 「Amazon Kinesis Data Firehose によるリアルタイム外部ストリーミング」 を組み合わせた業界標準アーキテクチャをまとめます。

1. 業務シナリオとコア課題の整理

現行アーキテクチャの課題

単一障害点（SPOF）: トラフィックが単一 AZ 内の EC2 インスタンスにのみ配分されており、AZ 障害やハードウェア故障でサービスが全停止するリスクを抱えている。

セキュリティ・防御要件

Web 脆弱性防御: 入力リクエストを検査・フィルタリングし、SQL インジェクションや XSS などの一般的な Web 脅威を未然に遮断すること。

ログ監査と外部連携要件

拒否ログのリアルタイム連携: WAF によってブロックされたリクエスト（Blocked Requests）の監査ログを、自前でバッチスクリプトを組むことなく、準リアルタイムでサードパーティ製の監査・分析アプリケーション（Splunk / Datadog 等）へ転送すること。

可用性制約

システム全体の高可用性（High Availability）: すべての構成コンポーネントにおいて単一障害点を排除すること。

2. アーキテクチャトポロジー（AWS WAF ＋ Firehose ＋ Multi-AZ ASG）

[ クライアント入室リクエスト ]
        │
        ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ Amazon Route 53 / パブリック入口                                                       │
└───────────────────────────┬────────────────────────────────────────────────────────────┘
                            │
                            ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ Application Load Balancer (ALB) - 複数 AZ 展開                                         │
│                                                                                        │
│   ┌──────────────────────────────────────────────────────────────────────────────────┐ │
│   │ AWS WAF (Web ACL 関連付け)                                                        │ │
│   │  - AWS マネージドルールグループ (Common Rule Set 等) を適用し脆弱性を自動遮断    │ │
│   └────────────────────────┬───────────────────────────────────┬─────────────────────┘ │
└────────────────────────────┼───────────────────────────────────┼───────────────────────┘
     [ 正常リクエスト (Allow) ]│                                   │ [ 拒否ログ (Blocked) ]
                             │                                   ▼
                             │       ┌─────────────────────────────────────────────────┐
                             │       │ Amazon Kinesis Data Firehose                    │
                             │       │  - AWS WAF のログ出力先としてネイティブ統合     │
                             │       │  - フルマネージドな準リアルタイムストリーミング │
                             │       └───────────────────────┬─────────────────────────┘
                             │                               │ HTTP エンドポイント連携
                             │                               ▼
                             │       ┌─────────────────────────────────────────────────┐
                             │       │ サードパーティ監査基盤 (Splunk / Datadog 等)    │
                             │       └─────────────────────────────────────────────────┘
                             ▼
┌────────────────────────────────────────────────────────────────────────────────────────┐
│ Multi-AZ Auto Scaling Group (ASG)                                                      │
│                                                                                        │
│   ┌─────────────────────────────────────┐      ┌─────────────────────────────────────┐ │
│   │ アベイラビリティゾーン A (Subnet A) │      │ アベイラビリティゾーン B (Subnet B) │ │
│   │  [ EC2 インスタンス (ゴールデンAMI) ]│      │  [ EC2 インスタンス (ゴールデンAMI) ]│ │
│   └─────────────────────────────────────┘      └─────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────────────────────────────┘

3. なぜこの設計を選択するのか？（3大コアメカニズム）

① コンピュート層の真の高可用性：Multi-AZ Auto Scaling Group

SPOF の完全排除:
アプリケーションを AMI（Amazon Machine Image）として標準化し、複数の AZ に跨がるプライベートサブネットを指定して Auto Scaling Group（ASG） を構築します。
手前の Application Load Balancer（ALB） が健全なインスタンスにのみトラフィックを分散します。
自動ヒーリングと弾力性:
いずれかの AZ で障害が発生したり、特定インスタンスのヘルスチェックが異常（Unhealthy）となった場合でも、ASG が健全な別 AZ 内に新しいインスタンスを自動的にプロビジョニングするため、ユーザー影響を最小化できます。

② マネージドルールによる運用レスな防御：AWS WAF

OWASP Top 10 の自動ブロック:
ALB の直前に AWS WAF (Web ACL) を配置し、AWS 公式のマネージドルール（例: AWSManagedRulesCommonRuleSet、AWSManagedRulesSQLiRuleSet）をサブスクライブします。
自前で複雑な正規表現やシグネチャを保守することなく、最新の SQL インジェクションや XSS 攻撃をエッジ側で即時遮断できます。

③ 監査要件をノーコードで実現：Kinesis Data Firehose ネイティブ連携

フルマネージドなログストリーミング:
AWS WAF は、トラフィックログの配信先として Amazon Kinesis Data Firehose をネイティブにサポートしています。
サードパーティへの直接プッシュ:
Firehose は HTTP エンドポイント宛てのカスタム送信や、Datadog / Splunk / New Relic などの主要なサードパーティ SaaS 宛てネイティブコネクタを標準装備しています。
CloudWatch Logs から Lambda でポーリング抽出するようなカスタムスクリプトを一切作成・運用することなく、「遮断されたリクエスト（Blocked Requests）」のみを抽出してリアルタイムストリーミングすることが可能です。

4. Terraform によるインフラ構成コード例

1. AWS WAF Web ACL とマネージドルールの定義

resource "aws_wafv2_web_acl" "main_waf" {
  name        = "alb-security-waf"
  description = "Managed rules for ALB protection"
  scope       = "REGIONAL"

  default_action {
    allow {}
  }

  # AWS コアマネージドルール (OWASP Top 10 防御)
  rule {
    name     = "AWSManagedRulesCommonRuleSet"
    priority = 1

    override_action {
      none {}
    }

    statement {
      managed_rule_group_statement {
        name        = "AWSManagedRulesCommonRuleSet"
        vendor_name = "AWS"
      }
    }

    visibility_config {
      cloudwatch_metrics_enabled = true
      metric_name                = "CommonRuleSetMetric"
      sampled_requests_enabled   = true
    }
  }

  visibility_config {
    cloudwatch_metrics_enabled = true
    metric_name                = "MainWAFWebACL"
    sampled_requests_enabled   = true
  }
}

# ALB と WAF の関連付け
resource "aws_wafv2_web_acl_association" "alb_assoc" {
  resource_arn = aws_lb.external_alb.arn
  web_acl_arn  = aws_wafv2_web_acl.main_waf.arn
}

2. Kinesis Data Firehose によるログストリーミング設定

# Firehose 配信ストリーム (WAF ログ専用のプレフィックス aws-waf-logs- が必須)
resource "aws_kinesis_firehose_delivery_stream" "waf_log_stream" {
  name        = "aws-waf-logs-delivery-stream"
  destination = "http_endpoint"

  http_endpoint_configuration {
    url                = "[https://api.audit-collector.example.com/v1/logs](https://api.audit-collector.example.com/v1/logs)"
    name               = "ThirdPartyAuditEndpoint"
    role_arn           = aws_iam_role.firehose_delivery_role.arn
    buffering_size     = 5  # MB
    buffering_interval = 60 # 秒
    s3_backup_mode     = "FailedDataOnly"

    s3_configuration {
      role_arn           = aws_iam_role.firehose_delivery_role.arn
      bucket_arn         = aws_s3_bucket.firehose_backup_bucket.arn
      buffering_size     = 5
      buffering_interval = 300
      compression_format = "GZIP"
    }
  }
}

# WAF ログの出力先として Firehose をバインド (Blocked リクエストのみをフィルタリング)
resource "aws_wafv2_web_acl_logging_configuration" "waf_logging" {
  resource_arn            = aws_wafv2_web_acl.main_waf.arn
  log_destination_configs = [aws_kinesis_firehose_delivery_stream.waf_log_stream.arn]

  logging_filter {
    default_behavior = "DROP"

    filter {
      behavior    = "KEEP"
      requirement = "MEETS_ANY"

      condition {
        action_condition {
          action = "BLOCK" # 遮断されたリクエストのみを外部へストリーミング
        }
      }
    }
  }
}

5. 設計上の比較まとめ

検討観点	従来の構成 / アンチパターン	最適化後：WAF ＋ Firehose ＋ Multi-AZ ASG
可用性境界	単一 AZ 内の固定 EC2（SPOF 存在）	Multi-AZ ALB ＋ ASG による自動修復・負荷分散
セキュリティ防御	なし、または OS 内の IPTables/Nginx レベル	AWS WAF マネージドルールによるエッジ遮断
ログ転送方式	定期 Cron ジョブや Lambda ポーリング	Kinesis Data Firehose によるフルマネージド流式転送
運用保守コスト	パッチ適用やスクリプト障害保守が高コスト	サーバーレス・マネージドサービスにより運用コスト最小

6. まとめ

可用性の底座: Multi-AZ Auto Scaling Group と ALB を組み合わせることで、インフラレイヤーにおける単一障害点を完全に排除する。
ルール管理の省力化: AWS WAF の AWS マネージドルールを採用することで、進化し続ける Web 脆弱性脅威に対して常に最新の防御を維持する。
運用レスな監査統合: WAF と Kinesis Data Firehose のネイティブストリーミング機能を活用し、追加の自作コードなしで拒否ログをリアルタイムに第三者監査基盤へ集約する。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up