最大で、VPCネットワークACLには40のルールを適用できます。
50を超えるIPアドレスのリストがあり、ポートやプロトコルを問わず、システムでのアクセスを明示的にブロックする必要があります。これはACLの理想的な目的ですが、制限があるためにこのタスクを完了できません。
もちろん、これを各ホストのIPTablesで行うことはできますが、VPC内のすべてのコンポーネント(ELBなど)へのすべてのトラフィックをブロックする必要があります。さらに、これらのルールをすべてのホスト上ではなく、1つの場所で管理する方がはるかに理想的です。
システム/プラットフォームレベルでこれを行うことを理解していない何らかの方法があることを願っています。セキュリティグループは明示的な許可であり、拒否アクションはないため、トリックを実行しません。
これが左側のアイデアです。各IPのVPCルートテーブルに「壊れた」ルートを追加することで、50個のブロックされたIPを「ヌルルート」にすることができます。
これにより、インフラストラクチャに到達するIPからのトラフィックが妨げられることはありませんが(NACLとSGのみがそれを防止します)、戻りトラフィックがすべて「帰宅」するのを防ぎます。
NACLの制限を増やす方法はなく、多数のNACLルールがネットワークパフォーマンスに影響を与えます。
何よりも建築上の問題があるかもしれません。
NACLルールの制限に達している場合は、VPCアーキテクチャへのAWS推奨のアプローチを採用しておらず、WAF(および Shield for DDoS)のようなサービスを使用して不要なトラフィックと明白なブロックを行っていない可能性が高いです攻撃。
懸念がDDoS攻撃の場合: Amazon CloudFrontおよびAmazon Route 53を使用して動的WebアプリケーションをDDoS攻撃から保護する方法
これは正確にはあなたが求めたものではありませんが、十分にうまくいくかもしれません。
インフラストラクチャの前にCloudFrontをセットアップします。 IP一致条件 を使用して、トラフィックを効果的にブロックします。 CloudFrontは静的コンテンツと動的コンテンツの両方で機能し、パブリックインターネットではなくAWSバックボーンを使用するため、動的コンテンツを高速化できます。ここにドキュメントが言うことです
一部のWeb要求を許可し、要求の発信元のIPアドレスに基づいて他のWeb要求をブロックする場合は、許可するIPアドレスのIP一致条件と、ブロックするIPアドレスの別のIP一致条件を作成します。
CloudFrontを使用する場合は、セキュリティグループを使用してパブリックリソースへの直接アクセスをブロックする必要があります。 AWS Update Security Groups lambda は、セキュリティグループを最新の状態に保ち、CloudFrontトラフィックを許可しますが、他のトラフィックは拒否します。 CloudFrontを使用してhttpをhttpsにリダイレクトする場合は、スクリプトを少し調整して、httpがインフラストラクチャに到達しないようにすることができます。また、直接管理者アクセスが必要なIPをホワイトリストに登録することもできます。
または、CloudFlareなどのサードパーティのCDNを使用することもできます。 CloudFlareには効果的なファイアウォールがありますが、必要なルールの数は月額200ドルです。それはCloudFrontよりも安いかもしれませんが、AWSの帯域幅はかなり高価です。無料プランでは5つのファイアウォールルールのみが提供されます。