200 万の I/O を持つ AWS マシン Linux インスタンス t2.micro があります。
私の理解が正しければ (間違っていたら教えてください)、200 万の I/O は、無料サービスで 200 万に対応できることを意味しますindex.php。
私の質問は、大量のアクセスやリクエストを避けるために、どのようにサーバーを保護できるかということです。
答え1
まず、ここで参照している内容に関する AWS の説明を見てみましょう。
汎用 (SSD) またはマグネティックの任意の組み合わせで 30 GB の Amazon Elastic Block Storage、さらに 200 万 I/O (マグネティック使用時) と 1 GB のスナップショット ストレージ
これらの I/O はディスクへの直接アクセス用であり、index.php ファイルはキャッシュされてメモリにロードされるため、index.php ファイルの動作によっては I/O に影響が出る可能性は低くなります。
アクセスやリクエストの急増に関する懸念をテストして監視する1つの方法は、人気の高いBees with Machine Gunsユーティリティ（https://github.com/newsapps/beeswithmachineguns) を Web アプリケーションに適用し、CloudWatch で影響を監視します。CloudWatch はデフォルトで 5 分間隔で監視するため、しばらくお待ちください。CloudWatch を 1 分間隔で監視するように変更すると追加料金が発生するため、注意してください。基本的にインスタンスでサービス拒否攻撃を実行することになるため、事前に AWS からテスト実行の許可を得る必要があります。許可を得ないと、AWS アカウントが停止されるリスクがあります。(https://aws.amazon.com/security/侵入テスト）
トラフィックの不要な急増や本格的な DDoS (分散型サービス拒否) 攻撃からサーバーを保護する最も簡単でおそらく最も安価な方法は、CloudFlare.com などのマネージド サービスを使用することだと思います。もちろん、Sophos UTM 9 や Imperva などのセキュリティ アプライアンスを使用することもできますが、追加の時間単位のコストやライセンス コストに加えて、その構成方法と保守方法を知っておく必要があります。
AWS は最近 AWS WAF (Web アプリケーション ファイアウォール) を発表しましたが、これを CloudFront に関連付ける必要があるようです。詳細はこちら）
他のツールを使用したくない場合は、Web アプリケーションを継続的に監視し、VPC サブネット上の仮想プライベート ネットワーク (VPC) とネットワーク アクセス コントロール (NACL) を使用して、不要なリクエストをブロックする必要があります。この方法は有効ですが、サイトが頻繁に攻撃を受ける場合は、モグラ叩きのような状況になる可能性があります。
最後に、Web サイトを保護する最善の方法は、複数のセキュリティ レイヤー (多層防御とも呼ばれます) を使用することです。そのため、その方法がわからない場合は、コーヒーを 1 杯 (または 2 杯) 飲みながら、OWASP (The Open Web Application Security Project) で学習を始めることをお勧めします。(www.owasp.org)