AWS上で運用しているシステムにペネトレーションテストや脆弱性診断を実施しようとすると、まず気になるのが「AWSへの事前申請は必要なのか」という点です。結論からお伝えすると、許可された主要なサービスであれば、現在は事前の承認なしでペネトレーションテストや脆弱性評価を実施できます。
ただし、どのサービスでも無条件に実施してよいわけではなく、禁止されている行為や、今も別のフォームからの申請が必要になるケースが残っています。
かつてはAWSに事前申請フォームを提出する必要があったため、「今も申請がいるのか、不要なのか」で情報が錯綜しがちなテーマです。本記事では、2026年11月時点のAWS公式ポリシーをもとに、申請なしで試せる対象サービスの一覧、申請不要でも禁止されている行為、今も別フォーム申請が必要なケースを整理します。
あわせて、負荷テストとペネトレーションテストの申請要否の違いや、申請不要の範囲を確認したあとに自社で実施する・外注するという次の一歩も解説します。
目次
一括ダウンロードする
AWSのペネトレーションテストに事前申請は必要？
AWSの公式ポリシーでは、許可されたサービスに対しては事前の承認なしでセキュリティ評価やペネトレーションテストを実施できると明記されています。まず結論となる公式の文言を確認します。
AWS のお客様は、[Permitted Services] (許可されたサービス) の下の次のセクションに記載されているサービスについて、事前の承認なしに AWS インフラストラクチャのセキュリティ評価またはペネトレーションテストを実行できます。（中略）Command and Control (C2) を含むすべてのセキュリティテストには、事前の承認が必要です。
出典：ペネトレーションテスト｜AWS カスタマーサポートポリシー
このように、自社が管理するAWSリソースのうち許可されたサービスであれば、AWSに申請してから実施するという手順は不要です。一方で、指揮統制（C2：Command and Control）の通信を含むテストは、許可されたサービス上であっても事前承認が必要になります。この但し書きは、後述する「別フォーム申請が必要なケース」とも関わります。
いつ・何が変わって申請不要になったのか
AWSは2019年に、主要なサービスについてペネトレーションテスト・脆弱性テストの事前承認を不要とする方針へ変更しました。それ以前は、テストの前にAWSへ申請フォームを提出し、承認を待つ必要がありました。この変更以降、対象となるサービスは段階的に広がり、現在の公式ポリシーでは16項目のサービスが「許可されたサービス」として挙げられています。
「以前は申請が必要だった」という記憶や、2019年前後に書かれた情報を見て迷うことがありますが、現在の対象範囲や手続きは当時から変わっています。本記事は2026年11月時点のAWS公式ポリシーに基づいて整理していますが、対象サービスや条件は更新されることがあるため、実施前には必ずAWS公式ページで最新の内容を確認してください。
テストできるのは自社のリソースだけ（責任共有モデル）
申請不要で実施できるのは、あくまで自社が管理するリソースに対するテストです。AWSの基盤やAWSのサービス自体を対象にしたセキュリティ評価は認められていません。クラウドでは、AWSが守る範囲（基盤・物理インフラ・サービス自体）と、利用者が守る範囲（自社で設定・運用するリソース）が分かれており、この考え方は責任共有モデルと呼ばれます。
注: お客様が AWS インフラストラクチャまたは AWS サービス自体のセキュリティ評価を実施することは許可されていません。セキュリティ評価で観察された AWS サービスのいずれかでセキュリティの問題を発見した場合は、すぐに AWS セキュリティにお問い合わせください。
出典：ペネトレーションテスト｜AWS カスタマーサポートポリシー
そのため、テスト対象はIPアドレスやリソースの所有者が自社であることを確認したうえで設定します。クラウドではIPアドレスが動的に割り当てられるため、テスト開始前に対象が自社のリソースであるかを確かめておくと安全です。
事前申請なしでペネトレーションテストできる対象サービス一覧
ここからは、事前申請なしでペネトレーションテストを実施できる「許可されたサービス（Permitted Services）」を確認します。自社が診断したいサービス（EC2・RDS・API Gateway・Lambdaなど）がこの一覧に含まれているかを確かめてください。以下はAWS公式ポリシーに記載された一覧です。
出典：ペネトレーションテスト（許可されたサービス）｜AWS カスタマーサポートポリシー
- Amazon EC2 インスタンス、WAF、NAT ゲートウェイ、Elastic Load Balancer
- Amazon RDS
- Amazon CloudFront
- Amazon Aurora
- Amazon API Gateway
- AWS AppSync
- AWS Lambda 関数および Lambda Edge 関数
- Amazon Lightsail リソース
- Amazon Elastic Beanstalk 環境
- Amazon Elastic Container Service
- AWS Fargate
- Amazon OpenSearch Service
- Amazon FSx
- Amazon Transit Gateway
- Amazon Bedrock AgentCore
- AWS Global Accelerator
Webアプリケーションの入り口になるEC2やELB、データベースのRDS・Aurora、API GatewayやLambdaといったサーバーレスの構成要素、コンテナのECS・Fargate、CDNのCloudFrontなど、一般的なWebサービスを構成する主要なサービスが含まれています。一覧にないサービスをテストしたい場合は、AWSサポートまたはアカウント担当者に直接相談する必要があります。
AWSで広く使われるS3などがこの一覧に明記されていない場合も、診断したいときはAWSサポートへの相談が入り口になります。禁止行為に挙げられている「S3バケット乗っ取り」は、使われなくなったバケット名を第三者が取得して乗っ取るような攻撃を指すもので、自社リソースの診断とは区別して考えます。
また、許可されたサービスは年々拡大してきた経緯があり、今後も内容が更新される可能性があります。実施前にはAWS公式の最新一覧を確認してください。
「申請不要・禁止・別フォーム申請」の3区分早わかり表
AWSでのセキュリティテストは、「事前申請なしで実施できるもの」「申請しても実施できない禁止行為」「今も別フォームからの申請が必要なもの」の3つに分かれます。自社が予定しているテストがどこに当たるかを、以下の表で確認してください。各区分の詳細は、このあとの見出しで解説します。
| 区分 | 事前申請なしで実施できる | 禁止（申請しても実施不可） | 別フォーム申請が必要 |
|---|---|---|---|
| 対象になるテスト・行為 | 許可されたサービス上で、自社が管理するリソースに対して行う通常のペネトレーションテスト・脆弱性診断 | DoS・DDoS、各種フラッディング、Route 53 経由の DNS 攻撃、S3 バケット・サブドメイン乗っ取り、API Gateway・Bedrock AgentCore からのアウトバウンドテスト | 許可サービス以外のテスト、C2 を含むテスト、レッド/ブルー/パープルチーム演習、模擬フィッシング、マルウェアテスト、DDoS シミュレーション、大規模なネットワーク負荷テスト など |
| 進め方 | AWSへの申請なしで実施可能（指揮統制=C2 を含むテストを除く） | 実施できない（DoS・DDoS のシミュレーションは別枠の DDoS シミュレーションテストポリシーの対象） | シミュレートイベントフォーム等から、開始の2週間前までに申請して審査を受ける |
※2026年11月時点のAWS公式ポリシーに基づく整理です。最新の内容はAWS公式ページでご確認ください。
申請不要でも禁止されている行為
許可されたサービスであっても、実施してはいけない行為が定められています。診断会社に外注する場合も、これらを対象から外すよう依頼仕様に明記しておくと、トラブルを避けられます。AWS公式ポリシーが挙げる禁止行為は次のとおりです。
出典：ペネトレーションテスト（禁止される行為）｜AWS カスタマーサポートポリシー
- Amazon Route 53 ホストゾーン経由の DNS ゾーンウォーキング
- Route 53 経由の DNS ハイジャック
- Route 53 経由の DNS ファーミング
- サービス拒否 (DoS)、分散型サービス拒否 (DDoS)、シミュレートされた DoS、シミュレートされた DDoS (これらは DDoS シミュレーションテストポリシー の対象となります)
- ポートフラッディング
- プロトコルフラッディング
- リクエストフラッディング (ログインリクエストフラッディング、API リクエストフラッディング)
- S3 バケット乗っ取り
- サブドメイン乗っ取り
共通するのは、他の利用者や共有基盤に影響を及ぼすおそれのある行為だという点です。いずれも、自社のテストという名目であっても実施できません。
ただし、DoS・DDoSのシミュレーションについては完全に不可というわけではなく、後述する別枠のDDoSシミュレーションテストポリシーに沿った手続きが用意されています。
また、許可されたサービスであっても、そこを起点にした外向き（アウトバウンド）のペネトレーションテストが禁止されているサービスがあります。公式ポリシーでは、Amazon API GatewayとAmazon Bedrock AgentCoreがアウトバウンドのペネトレーションテスト禁止対象として挙げられています。
今も別フォーム申請が必要なケースと「2週間前」の締切
許可されたサービスへの通常のペネトレーションテストは申請不要ですが、より踏み込んだシミュレーションや、許可リストにないサービスを対象にする場合は、今も別のフォームからの申請が必要です。公式ポリシーが「他のシミュレートされたイベント」として挙げ、申請・審査が求められるものには、次のようなテストがあります。
- レッドチーム・ブルーチーム・パープルチームのテストや、C2（指揮統制）をホスティングする敵対的シミュレーション
- ネットワークストレステスト・負荷テスト
- DDoS シミュレーションテスト
- 模擬フィッシング、マルウェアテスト、iPerf によるテスト
- 許可されたサービスの一覧に含まれないサービスへのテスト
これらを実施する場合は、AWSのシミュレートイベントフォームから申請します。提出の締切について、公式ポリシーは次のように定めています。
すべての Simulated Event リクエストは、遅くとも開始日の 2 週間前に AWS に送信する必要があります。
出典：ペネトレーションテスト（他のシミュレートされたイベント）｜AWS カスタマーサポートポリシー
そのため、これらのテストを計画する場合は、スケジュールに2週間以上の余裕を見込んでおく必要があります。申請先は、以前は専用のメールアドレスが案内されていた時期もありましたが、現在はAWSサポートコンソールのシミュレートイベントフォームから提出する形に整理されています。許可リストにないサービスをテストしたい場合も、AWSサポートまたはアカウント担当者への相談が入り口になります。
個別に条件があるケース（CloudFrontのNDAは現在は不要）
2019年前後の情報では、CloudFrontのテストにはAWSとの秘密保持契約（NDA：Non-Disclosure Agreement）の締結が前提とされていました。「aws ペネトレーションテスト NDA」で検索したときに見かけるのは、この当時の情報です。
しかし現在のAWS公式ポリシーでは、CloudFrontは但し書きのない通常の許可サービスとして一覧に含まれており、NDAの締結を前提とする記載は見当たりません。古い情報のまま準備を進めないよう注意してください。
一方、現在も個別に事前承認が求められる例として、指揮統制（C2）を含むテストがあります。許可されたサービス上のテストであっても、C2の通信を含む場合は事前の承認が必要になるため、レッドチーム演習のように攻撃者の活動を再現するテストでは、前述の別フォーム申請の対象になります。
負荷テスト（ストレステスト）とペネトレーションテストの申請要否の違い
ペネトレーションテストと混同しやすいのが、負荷テスト（ストレステスト）です。性能検証も兼ねて負荷をかけたい場合、ペネトレーションテストと同じ感覚で進めてよいのか迷いますが、両者は扱いが分かれます。AWSのEC2テストポリシーは、正当なトラフィックを送る負荷テストと、意図的に過負荷状態を作り出すテストを区別しています。
パケット/接続フラッド攻撃、リフレクション/増幅攻撃、またはその他の大量のトラフィックを用いてターゲットやインフラストラクチャを意図的に過負荷状態にしようとするテストは、ネットワーク負荷テストではなく、分散型サービス拒否 (DDoS) テストと見なされます。
Amazon EC2 プラットフォームではボリューム型のネットワークベース DDoS シミュレーションが明示的に禁止されているため、これらのガイドラインの対象外となっています。
出典：Amazon EC2 テストポリシー｜Amazon Web Services
整理すると、正当なトラフィックを送って性能を確かめる負荷テストはEC2テストポリシーの範囲で扱われ、意図的に過負荷を発生させるテストはDDoSテストと見なされて、EC2プラットフォームでは禁止されます。かつては「1Gbps・1Gb PPS 未満なら承認不要」といった目安が示されていた時期もありましたが、現在のEC2テストポリシーにはこの数値は記載されていません。
現在の同ポリシーは、関連するネットワークパスやリージョンに応じてトラフィックの急増が25Gbpsまたは100Gbpsを超える場合に、AWSがトラフィックシェーピングを行う場合があるとしています。これは申請の要否を分ける閾値ではなく、AWS側が制御し得る水準です。
どうしてもDoS・DDoSに相当する負荷をかけて検証したい場合は、別枠のDDoSシミュレーションテストポリシーに沿って進めます。
このテストは、AWSが事前に承認したDDoSテストパートナーが実施することが前提で、帯域やパケット量などに技術的な上限が定められています（具体的な数値はFAQで後述します）。
これらの技術的な制限を超える場合や、承認されたパートナー以外が実施する場合は、テスト予定日の14日前までにフォームから申請して承認を得る必要があります。
申請不要の範囲を確認したあとの進め方（自社実施と外注）
申請不要の範囲が把握できたら、次は実際のテスト計画です。自社で実施するのか、診断会社に外注するのかで、準備する内容が変わります。ここからは、禁止行為を外した計画の立て方と、外注する場合の依頼先の見極め方を解説します。
自己診断と外部ベンダーへの依頼をどう使い分けるか、それぞれの費用の目安まで含めてAWS環境の診断の進め方を具体的に知りたい場合は、以下の記事で詳しく解説しています。
禁止行為を外して自社でテスト計画を立てる手順
自社で実施する場合は、まず対象を許可されたサービスの範囲に絞り、テスト対象のIPアドレスやリソースが自社の管理下にあることを確認します。次に、禁止行為に当たるテスト項目（DoS・DDoS、各種フラッディング、DNS系の攻撃、S3バケット・サブドメイン乗っ取りなど）を計画から除外します。
レッドチーム演習やC2を含むテスト、大規模な負荷テスト、DDoSシミュレーションを行う場合は、2週間前までの別フォーム申請が必要になるため、その分のスケジュールを見込んでおきます。そのうえで、対象範囲（スコープ）・実施期間・連絡体制を文書化しておくと、テスト中に想定外の事態が起きた場合にも対応しやすくなります。
脆弱性診断とペネトレーションテストのどちらを依頼するか
外注を検討する場合、まず「脆弱性診断」と「ペネトレーションテスト」のどちらが自社の目的に合うかを整理します。脆弱性診断は、システムに存在する弱点を網羅的に洗い出すことを目的とします。これに対してペネトレーションテストは、攻撃者の視点で特定のシナリオに沿って侵入を試み、実際にどこまで到達・悪用できるか、その影響範囲を確認することを目的とします。
脆弱性診断とペネトレーションテストは、目的だけでなく費用や向いている場面も異なります。一度もセキュリティテストを実施していないシステムであれば、まず脆弱性診断から始めるのが一般的です。どちらを依頼すべきか判断に迷う場合は、以下の記事で両者を詳しく比較しています。
診断を外注するときの依頼先の見極め
AWS環境の診断を外注する場合は、クラウド特有の観点まで診られる依頼先かどうかが分かれ目になります。クラウドで侵入の起点になりやすいのは、IAM（AWSの権限管理）の過剰な権限設定、セキュリティグループやVPCの公開設定の不備、公開状態のS3バケットといった設定ミスです。
Webアプリケーションの脆弱性だけでなく、こうしたAWSの構成・権限設計まで踏み込んで診られるかを、依頼先の対応範囲として確認します。あわせて、AWSの許可ポリシーに沿った実施経験があるか、本番環境で影響を抑えながら診断した実績があるか、報告書に修正の優先度や再現手順が含まれるか、修正後の再診断に対応するかといった点も、依頼先を比較する際の判断材料になります。
AWS環境の脆弱性診断・ペネトレーションテストに対応するサービス
ここからは、AWS環境の脆弱性診断・ペネトレーションテストに対応し、クラウドの設定診断まで含めて依頼できるサービスを紹介します。ツールで継続的に検査するタイプと、専門家が手動で診断するタイプがあり、自社の体制や目的に合わせて選べます。
以下はご紹介するサービスの比較表です。
| サービス | Aikido Security | NRIセキュア | ラック | GMO byイエラエ | SQAT |
|---|---|---|---|---|---|
| 診断方式 | ツール型（SaaSの自動スキャン） | 手動主体（ハイブリッド） | 手動主体（ハイブリッド） | ハイブリッド（手動診断＋ツールASM） | ハイブリッド（手動＋独自自動診断） |
| AWS・クラウド設定診断（CSPM） | ●AWS・Azure・GCP対応 | ●クラウド設定評価（CSPM） | ●クラウド・SaaS設定診断 | ●AWS・Azure・GCP対応 | ●クラウド設定診断 |
| ペネトレーションテスト | △人手診断はAndGoの別サービス | ● | ● | ● | ● |
| 主な診断対象 | ソースコード／クラウド設定／Webアプリ（DAST）／コンテナ／公開資産（ASM） | Web／プラットフォーム／スマホアプリ／API／クラウド設定／ソースコード／AI／IoT・OT | Web／プラットフォーム／クラウド・SaaS設定／スマホアプリ／IoT／ソースコード | Web／スマホアプリ／クラウド／ネットワーク／NFT・ブロックチェーン／デスクトップ／IoT／AI | Web／ネットワーク／スマホアプリ／IoT／クラウド設定／ソースコード／アタックサーフェス |
| 料金の目安 | 月額5万円台〜 | 個別見積もり | 情報システムペネトレーションテスト 700万〜1,000万円（税抜）／TLPT 1,000万円程度〜 | 手動診断は個別見積もり／ネットde診断ASMは月額課金 | 個別見積もり |
| 詳細情報 | 公式資料を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る | サービス詳細を見る |
ここで紹介するのは、AWS環境に対応できるサービスの一例です。クラウドに限らず脆弱性診断サービス全体を、診断方法や費用相場、選び方の観点から比較して検討したい場合は、以下の記事もあわせてご覧ください。
1. Aikido Security（株式会社AndGo）
Aikido Securityは、ソースコード・依存ライブラリ・クラウド設定・コンテナ・稼働中のWebアプリを1つの管理画面で検査する、ツール型のオールインワン脆弱性診断SaaSです。ベルギーのAikido Securityが開発し、日本では株式会社AndGoが販売・問い合わせ窓口を担っています。
AWS環境との関わりで中心になるのが、クラウドの設定を検査するCSPM（クラウドセキュリティ態勢管理）の機能で、公式ページではAWS・Azure・GCPなどに対応すると記載されています。これに加えてソースコード解析（SAST・SCA）、動的なWebアプリ検査（DAST）、公開資産の洗い出し（ASM）などを備えます。
複数の単機能ツールを組み合わせるとアラートが分散しがちですが、統一した画面で対応すべきアラートを絞り込める点を特徴として挙げています。検出した問題の修正案をプルリクエストの形で提示する自動修正の機能もあります。開発の初期段階からセキュリティを組み込むDevSecOpsの進め方を、ツールの面から支える位置づけの製品です。
日本窓口の料金は、年間契約・利用者10人までの場合でBasicプランが3,780ドル/年、Proプランが7,560ドル/年、Customプランは要問い合わせです（2026年11月時点の参考価格）。月額では5万円台からの案内で、請求は為替を考慮した日本円で行われます。人手によるペネトレーションテストは、AndGoが別のサービスとして案内しています。
出典・参考資料（2件）
日本窓口の株式会社AndGoは、ツールによる継続的な検査の延長線上で、侵入テスト（ペネトレーションテスト）の進め方が今後どう変わっていくと見ているかについて、次のように語っています。
AIコーディングが当たり前になるほど、「AIが書いたコードも含めて、日常的に検証できる仕組み」が重要になります。その文脈で、AIエージェントがハッカーをエミュレーションして侵入テストを行い、ログや証跡を残す“AIペンテスト”の方向性も出てきています。これが進むと、コストや時間の都合で「リリース前に1回」が限界だった侵入テストを、ビルドパイプラインに組み込み、毎日回す世界が見えてきます。
2. セキュリティ診断（脆弱性診断・ペネトレーションテスト）／NRIセキュア（NRIセキュアテクノロジーズ株式会社）
NRIセキュアテクノロジーズは、野村総合研究所（NRI）グループのセキュリティ専業会社です。提供するセキュリティ診断は、専門家による手動診断を中核に据えている点が特徴で、Webアプリケーション診断では手作業のみで行うプロフェッショナル方式と、手作業にツールを補助的に併用するハイブリッド方式を選べます。
診断対象は、Webアプリケーション、プラットフォーム、スマートフォンアプリ、API、ソースコードに加え、クラウドの設定を評価するクラウド設定評価サービス（CSPM）まで幅広く揃っています。攻撃者視点で侵入を試みるペネトレーションテストや、組織の対応能力まで評価するレッドチームオペレーションも提供しており、金融機関や上場企業での診断実績があるとしています。
AWSの設定診断とWebアプリやAPIの診断、ペネトレーションテストを同じベンダーに依頼したい場合に適した選択肢です。料金は診断範囲に応じた個別見積もりです。
出典・参考資料（2件）
3. 脆弱性診断・セキュリティ診断サービス（株式会社ラック）
株式会社ラックの脆弱性診断・セキュリティ診断サービスは、弱点を網羅的に洗い出す脆弱性診断と、攻撃者視点で侵入の影響範囲まで確認するペネトレーションテストを明確に区別して提供しています。診断対象は、Webアプリ、生成AIを活用したシステム、サーバ・ネットワーク機器、スマホアプリ、クラウド・SaaSの設定、クライアント端末などに及びます。
セキュリティ監視を担うJSOCや、インシデント発生時に対応するサイバー救急センターを自社で持ち、診断から監視・緊急対応までを同じベンダーで組み合わせられます。
公式ページでは、攻撃者が侵入したと想定して影響を確認する情報システムペネトレーションテストを、標準のマルウェア感染シナリオで700万〜1,000万円（税抜）、脅威ベースのペネトレーションテスト（TLPT）を1,000万円程度からと示しています（範囲・シナリオにより変動）。本格的なペネトレーションテストやTLPTまで視野に入れる場合の選択肢です。
4. 脆弱性診断・ペネトレーションテスト（GMOサイバーセキュリティ byイエラエ株式会社）
GMOサイバーセキュリティ byイエラエ株式会社は、セキュリティ技術者（ホワイトハッカー）が在籍するサイバーセキュリティの専門企業です。専門家による手動主体の脆弱性診断・ペネトレーションテストを中核とし、公式には13種のメニューを掲載しています。Webアプリケーション、スマホアプリ、ネットワークに加え、AWS・Azure・Google Cloudなどを対象にしたクラウド診断も用意されています。
社内ネットワークやWebを対象にしたペネトレーションテスト、レッドチーム演習、IoTデバイスの診断まで幅広く、手動での診断を担う診断員が実施します。手動の診断とは別に、攻撃面を継続的に把握するASM（攻撃面管理）ツール「GMOサイバー攻撃ネットde診断」を月額のSaaSとして提供しています。
一度きりの診断だけでなく、公開資産を継続的に監視したい場合にも対応できます。手動診断は個別見積もり、ASMは月額課金という料金体系です。
出典・参考資料（2件）
5. SQAT（株式会社ブロードバンドセキュリティ）
SQAT®（エスキュート）は、2000年創業のセキュリティ専業企業である株式会社ブロードバンドセキュリティ（BBSec）が提供する脆弱性診断サービスの総称です。公式ページでは、精度の高い手動診断と独自開発の自動診断を組み合わせたハイブリッド方式で実施すると説明されています。
診断メニューは、Webアプリケーション、ネットワーク、スマホアプリ、IoT、ソースコードのほか、クラウドセキュリティ設定診断やペネトレーションテストまで揃います。公式トップでは、延べ10,300組織・64,280システムを超える診断実績（2025年6月現在）を掲げています。
ソースコード診断とWebアプリ診断を組み合わせたハイブリッド診断のメニューや、範囲を優先度の高い部分に絞る短納期の診断メニューもあり、クラウド上のシステムに対して、目的に応じた範囲で診断を依頼したい場合に検討しやすいサービスです。
まとめ
AWSでは、許可された主要なサービスであれば、自社が管理するリソースに対するペネトレーションテスト・脆弱性診断を事前の承認なしで実施できます。一方で、DoS・DDoSや各種フラッディング、Route 53経由のDNS攻撃、S3バケット・サブドメインの乗っ取りは、申請の有無にかかわらず禁止されています。
レッドチーム演習やC2を含むテスト、DDoSシミュレーション、大規模な負荷テスト、許可リストにないサービスへのテストは、今もシミュレートイベントフォームから開始の2週間前までに申請が必要です。負荷テストは、正当なトラフィックを送る範囲であればEC2テストポリシーの対象として扱われ、意図的に過負荷を発生させるテストはDDoSテスト扱いで別の手続きになります。
これらの範囲を確認したうえで、禁止行為を外した計画を自社で立てるか、IAMやセキュリティグループといったAWS固有の設定まで診られる診断会社に外注するかを選びます。対象サービスや条件は更新されることがあるため、実施前には必ずAWS公式ポリシーで最新の内容を確認してください。
よくある質問（FAQ）
Q. AWSのペネトレーションテストとは何ですか？
A. AWSのペネトレーションテストとは、AWS上に構築した自社システムに対して攻撃者の視点で実際に侵入を試み、どこまで到達・悪用できるかという影響範囲を確認するセキュリティテストです。システムの弱点を網羅的に洗い出す脆弱性診断とは目的が異なり、特定のシナリオに沿って防御の有効性を検証します。
AWS環境では、EC2やRDSといった自社が管理するリソースが対象であり、AWSの基盤やサービス自体はテストの対象にできません（責任共有モデル）。
Q. AWSのペネトレーションテストに事前申請は必要ですか？
A. AWSが許可した主要なサービスであれば、現在は事前の承認なしでペネトレーションテストや脆弱性評価を実施できます。かつてはAWSへ申請フォームを提出して承認を待つ必要がありましたが、2019年の方針変更以降、EC2・RDS・API Gateway・Lambdaなどの許可されたサービスは申請不要になりました。
ただし、指揮統制（C2）を含むテストや、許可リストにないサービスへのテストは、今も別フォームからの申請が必要です。
出典・参考資料（1件）
Q. AWS環境で負荷テスト（ストレステスト）をするのに申請は必要ですか？
A. 正当なトラフィックを送って性能を確かめる負荷テストはAWSのEC2テストポリシーの範囲で扱われますが、意図的に過負荷状態を作り出すテストはDDoSテストと見なされ、EC2プラットフォームでは禁止されています。ペネトレーションテストと同じ感覚で過負荷をかけることはできません。
ただし「1Gbps・1Gb PPS未満なら承認不要」といった目安が示されていた時期もありましたが、現行のEC2テストポリシーにこの数値は記載されていません。
どうしてもDoS・DDoSに相当する負荷で検証したい場合は、別枠のDDoSシミュレーションテストポリシーに沿って進めます。
出典・参考資料（1件）
Q. AWSでDoS・DDoSに相当するテストを試すにはどうすればいいですか？
A. DoS・DDoSおよびそのシミュレーションは通常のペネトレーションテストとしては禁止されていますが、AWSが事前承認したDDoSテストパートナーが実施する「DDoSシミュレーションテストポリシー」に沿えば実施できます。
このポリシーでは、帯域20Gbps、パケット量（CloudFrontを対象とする場合は毎秒500万パケット・それ以外のリソースでは毎秒5万パケット）、リクエスト量毎秒5万という上限が定められています。
これらを超える場合や承認されたパートナー以外が実施する場合は、テスト予定日の14日前までにフォームから申請して承認を得る必要があります。
出典・参考資料（1件）
Q. 許可されたサービスの一覧にないサービスをAWSでテストしたい場合、どこに申請すればいいですか？
A. 許可されたサービスの一覧にないサービスをテストしたい場合は、AWSサポートまたはアカウント担当者に直接相談する必要があります。レッドチーム演習やC2を含むテスト、DDoSシミュレーション、大規模な負荷テストなどは、AWSのシミュレートイベントフォームから開始日の2週間前までに申請し、審査を受けます。
以前は専用のメールアドレスが案内されていた時期もありましたが、現在はシミュレートイベントフォームからの提出に整理されています。
出典・参考資料（1件）
Q. AWSのCloudFrontをテストするにはNDA（秘密保持契約）の締結が必要ですか？
A. 現在のAWS公式ポリシーでは、CloudFrontは但し書きのない通常の許可サービスとして一覧に含まれており、NDAの締結は不要です。2019年前後の情報ではCloudFrontのテストにNDAが前提とされていたため、「aws ペネトレーションテスト NDA」で検索すると当時の情報が見つかりますが、現行ポリシーにNDAを前提とする記載はありません。
古い情報のまま準備を進めないよう注意してください。
出典・参考資料（1件）
Q. AWS環境では、脆弱性診断とペネトレーションテストのどちらを先に実施すべきですか？
A. 一度もセキュリティテストを実施していないシステムであれば、まず脆弱性診断で全体の弱点を洗い出すところから始めるのが一般的です。脆弱性診断は、設定ミスや既知の脆弱性を網羅的に把握するのに適しています。取引先からペネトレーションテストの実施を求められている場合や、脆弱性診断を実施済みで、より実戦的に防御の有効性を確かめたい場合には、ペネトレーションテストが適しています。
Q. ペネトレーションテストで、AWS上の本番サービスが停止するリスクはありませんか？
A. AWSが禁止するDoS・DDoSや各種フラッディングを計画から外し、対象を許可されたサービスの範囲に絞れば、本番サービスを停止させるリスクは抑えられます。診断会社に外注する場合も、これらの禁止行為を対象から除外するよう依頼仕様に明記しておくと、トラブルを避けられます。本番環境への影響が心配な場合は、本番と同一構成の検証用（ステージング）環境を用意し、そちらを対象に実施する方法もあります。
Q. 診断を外注する場合、AWSの設定ファイルやソースコードを開示する必要はありますか？
A. 開示が必要かどうかは、依頼する診断の方式によって異なります。外部からの通信だけで侵入を試みるブラックボックス方式であれば、診断対象のドメインやグローバルIP、APIエンドポイントの提示だけで実施でき、ソースコードやログイン情報の開示は不要なことが一般的です。
一方、IAMの権限設定やセキュリティグループの構成まで踏み込んで診るクラウド設定診断では、設定情報の共有が前提になります。どこまで開示するかは、診断の目的と方式に合わせて依頼先と取り決めます。
脆弱性診断・ペネトレーションテストの料金・資料を一括チェック
MCB FinTechカタログでは、AWS環境に対応した脆弱性診断・ペネトレーションテストサービスの最新資料を無料で一括請求できます。診断の対応範囲や料金、サポート体制を比較して、自社に合うサービスを検討できます。
一括ダウンロードする
MCB FinTechカタログに掲載しませんか？
MCB FinTechカタログでは、掲載企業様を募集しています。マネックスグループの金融実務ノウハウを活かした独自の評価軸と検索設計により、導入検討者が最適なサービスを効率的に発見できる法人向け比較プラットフォームです。掲載後は管理画面から料金表や導入事例を随時更新でき、常に最新の情報を訴求可能。まずは下記フォームより、お気軽にお問い合わせください。
マネックス証券 フィナンシャル・インテリジェンス部 暗号資産アナリスト
松嶋真倫
監修の範囲は記事の一般的な解説部分であり、比較表および各製品・サービスの紹介内容は監修の対象外です。
