AWS Shieldで保護されるサービス一覧を解説！CloudFront・ALB・Route 53など

1. AWS Shieldとは？

1. AWS Shieldとは？

AWS Shieldは、Amazon Web Services（アマゾン ウェブ サービス）が提供するDDoS攻撃防御の仕組みです。読み方はシールドで、標準のShield Standard（スタンダード）は無料で自動適用されます。さらに有料のShield Advanced（アドバンスド）を契約すれば、より強力な防御とサポートを受けられます。

DDoS攻撃とは、分散型サービス拒否攻撃のことを指し、読み方はディードスこうげきです。大量のリクエストを送りつけてサービスを止める攻撃で、クラウドサービスを使う上で大きなリスクとなります。そこで、AWS Shieldが事前に防御をして、システムの安定性を確保するのです。

2. 保護される代表的なサービス

2. 保護される代表的なサービス

AWS Shieldがカバーしている代表的なサービスは次の通りです。

• Amazon CloudFront（クラウドフロント）：CDN（コンテンツ デリバリー ネットワーク）サービスで、世界中にコンテンツを配信する仕組みです。大量のアクセスに強く、攻撃を受けやすい場所でもあります。
• Elastic Load Balancing（エラスティック ロード バランシング）：ALB（アプリケーションロードバランサー）、NLB（ネットワークロードバランサー）などが対象で、複数のサーバーに通信を分散する仕組みです。
• Amazon Route 53（ルート53）：DNS（ディーエヌエス）のサービスで、ユーザーのリクエストを適切なサーバーに振り分けます。DDoS攻撃で最も狙われやすい部分のひとつです。
• Amazon Global Accelerator（グローバル アクセラレーター）：グローバル規模でアプリケーションの通信を最適化するサービスで、ネットワーク全体の耐障害性を高めます。

これらのサービスは、インターネットに直接さらされることが多いため、DDoS攻撃の標的になりやすいのです。そのため、Shieldによる保護が標準で提供されています。

3. CloudFrontが保護される理由

3. CloudFrontが保護される理由

Amazon CloudFrontは世界中に分散配置されたエッジサーバーを使ってコンテンツを配信するサービスです。動画配信やECサイトで多く使われており、アクセス集中や攻撃の影響を受けやすい場所でもあります。Shieldが有効化されていることで、攻撃を検知してトラフィックを遮断し、正規の利用者には影響を与えないようにできます。

4. ALBやNLBの保護

4. ALBやNLBの保護

Elastic Load BalancingのALBやNLBは、複数のEC2インスタンスやコンテナにアクセスを振り分ける役割を持ちます。ロードバランサーが攻撃を受けると全体のシステムに影響が出てしまうため、Shieldで守ることが非常に重要です。特にALBはアプリケーション層の通信を扱うので、DDoS攻撃だけでなく複雑な攻撃からも守る仕組みと組み合わせると効果的です。

5. Route 53とDNS保護

5. Route 53とDNS保護

Amazon Route 53は、ユーザーが入力したURLを適切なサーバーへと導くDNSサービスです。DNSはインターネットの住所録のような役割を持つため、ここが攻撃されると全体のサービスが利用できなくなる危険性があります。ShieldはDNSへの大量リクエストを自動で防御し、ユーザーが普段通りにサービスを利用できるようにしています。

6. Global Acceleratorでの保護

6. Global Acceleratorでの保護

Amazon Global Acceleratorは、ユーザーのリクエストを最適な経路でアプリケーションに届けるサービスです。ゲームや金融取引のようにリアルタイム性が求められる環境で使われます。ここも攻撃対象になりやすいため、ShieldによるDDoS防御が自動的に働いています。

7. Shield Advancedで追加される対象

7. Shield Advancedで追加される対象

標準のShield Standardでは主にCloudFrontやALBなどが保護されますが、Shield Advancedを契約するとさらに広い範囲のサービスで保護が可能になります。例えば、Elastic IP（エラスティック アイピー）を直接利用しているEC2インスタンスなども対象になります。これにより、クラウドインフラ全体をDDoSから守ることができます。

まとめ

まとめ

ここまで、AWS Shield（エーダブリューエス シールド）が保護対象とする主要なサービス、Amazon CloudFront（クラウドフロント）、ALB（アプリケーションロードバランサー）、Amazon Route 53（ルート53）、そしてGlobal Accelerator（グローバルアクセラレーター）について詳しく解説してきました。DDoS攻撃（ディードスこうげき）は、現代のインターネットビジネスにおいて避けては通れない脅威ですが、AWSを利用することで強力な防御基盤を容易に構築できることがお分かりいただけたかと思います。

AWS Shield StandardとAdvancedの使い分け

AWS Shieldには、追加料金なしで自動適用される「Standard（スタンダード）」と、高度な保護を提供するサブスクリプション型の「Advanced（アドバンスド）」の2種類があります。Standardでもレイヤー3（ネットワーク層）やレイヤー4（トランスポート層）の一般的な攻撃には十分対応可能ですが、ビジネスの規模が拡大し、より高度なレイヤー7（アプリケーション層）への対策や、専門家チームによるサポートが必要な場合はAdvancedの導入を検討すべきです。

特に、AWS WAF（ウェブアプリケーションファイアウォール）との連携は非常に強力です。Shieldでインフラストラクチャを保護し、WAFでSQLインジェクションやクロスサイトスクリプティングなどのアプリケーション固有の脆弱性を防ぐという二段構えのセキュリティ対策が、可用性の高いシステム構築の鍵となります。

CloudFormationを使ったセキュリティ設定の自動化

実際の運用現場では、手動でShieldの設定を確認するのではなく、Infrastructure as Code (IaC) を用いて設定を管理するのが一般的です。例えば、AWS CloudFormation（クラウドフォーメーション）を使用して、CloudFrontにShieldの保護が適用されているか、あるいはWAFが正しく紐付けられているかを定義することができます。

以下は、CloudFrontディストリビューションに対してWAFのウェブACLを関連付け、基本的な防御構成を定義する際のテンプレート例です。Shield Advancedを有効化している場合、これらのリソースはさらに強固な監視対象となります。

AWSTemplateFormatVersion: '2010-09-09'
Description: 'CloudFront with WAF Integration for DDoS Protection'

Resources:
  # CloudFrontウェブACLの定義
  MyWebACL:
    Type: 'AWS::WAFv2::WebACL'
    Properties:
      Name: 'GlobalWebACL'
      Scope: 'CLOUDFRONT'
      DefaultAction:
        Allow: {}
      VisibilityConfig:
        SampledRequestsEnabled: true
        CloudWatchMetricsEnabled: true
        MetricName: 'GlobalWebACL'
      Rules:
        - Name: 'AWSManagedRulesCommonRuleSet'
          Priority: 0
          Statement:
            ManagedRuleGroupStatement:
              VendorName: 'AWS'
              Name: 'AWSManagedRulesCommonRuleSet'
          OverrideAction:
            None: {}
          VisibilityConfig:
            SampledRequestsEnabled: true
            CloudWatchMetricsEnabled: true
            MetricName: 'AWSCommonRuleSet'

  # CloudFrontディストリビューション
  MyCloudFrontDistribution:
    Type: 'AWS::CloudFront::Distribution'
    Properties:
      DistributionConfig:
        Enabled: true
        WebACLId: !GetAtt MyWebACL.Arn
        Origins:
          - Id: 'MyS3Origin'
            DomainName: 'my-bucket.s3.amazonaws.com'
            S3OriginConfig:
              OriginAccessIdentity: ''
        DefaultCacheBehavior:
          TargetOriginId: 'MyS3Origin'
          ForwardedValues:
            QueryString: false
          ViewerProtocolPolicy: 'redirect-to-https'

コマンドラインでの保護状況確認

現在のリソースがShieldによってどのように保護されているかは、AWS CLI（コマンドラインインターフェース）を通じても確認が可能です。特にインフラ構築後の自動テストや、定期的な監査スクリプトにおいて、以下のようなコマンドが活用されます。

aws shield list-protections --region us-east-1
{
    "Protections": [
        {
            "Id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
            "Name": "CloudFrontProtection",
            "ResourceArn": "arn:aws:cloudfront::123456789012:distribution/EDFDVBD6EXAMPLE",
            "ProtectionArn": "arn:aws:shield::123456789012:protection/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111"
        }
    ]
}

このように、AWS Shieldは単体で機能するだけでなく、CloudFrontやALBといったサービスと密接に連携することで、インターネット上のあらゆる場所からの攻撃をエッジ（ユーザーに近い場所）で食い止める役割を果たしています。セキュリティは「一度設定すれば終わり」ではありません。トラフィックの傾向を常にモニタリングし、必要に応じてShield Advancedへのアップグレードや、WAFのルールカスタマイズを行っていくことが、安定したウェブサイト運営には不可欠です。

今回の内容を参考に、自社のシステムがどのレベルで保護されているのか、改めて見直してみてはいかがでしょうか。特にRoute 53やGlobal Acceleratorなどは、攻撃を受けてからでは手遅れになるケースも多いため、事前に対策を講じておくことが強く推奨されます。