外部からの攻撃については皆さんがご説明された通りですが、サーバーをプライベートサブネットに置くことは内部からの攻撃に対する防御にもなる点について、蛇足ですが補足させていただきます。
昨今のプログラム事情であれば、OSに組み込まれているものなどもも含めて多くのライブラリ群をサーバーにインストールして動かすことになると思います。
そのライブラリのわずか1つに悪意あるプログラムが含まれると、例えば内部ログなどの機密情報を盗み見られてしまうかもしれません。
その場合において、プライベートサブネットに置かれたサーバーでは、外部「から」の通信を遮断するだけでなく外部「へ」の通信も遮断しますので、盗み見られた機密情報を攻撃者のもとへ送信することができません。
外部「へ」の通信の遮断は、サーバーごとのセキュリティグループでも設定が可能ですが、逆に設定をし忘れたり、設定を更新し忘れたりすると脅威にさらされることになります。
ですので、あらかじめ外部と通信しないことが分かっている場合には、プライベートサブネットにいれてしまうことで「間違っても外部と通信できない」ようにしておく、というのは一つのベストプラクティスになっているというわけです。
このベストプラクティスは外部への通信を行わない場合にのみ使えるもので、サーバーの処理内容次第では外部へ通信する必要があり(外部サービスのAPIを呼び出すなど)ますが、その場合はプライベートサブネットに置いてしまうと通信ができなくなってしまうので、このベストプラクティスで内部からの攻撃にたいするセキュリティメリットを享受することはできません。
「間違っても外部"から"の通信を受け付けたくない」が、「外部"へ"の通信は許可したい」という場合には、プライベートサブネットにサーバーを配置した上で NAT Gateway を併設するという手法がとられます
この場合、外部からの攻撃に対するセキュリティメリットは享受できますが、内部からの攻撃に対するセキュリティメリットは享受できないことに注意してください
さらに補足しておくと、外部"へ"の通信がAWSサービスのみが対象の場合、VPC Endpoint を利用することにより、プライベートサブネットに置いたままAWSサービスのみに対して通信を許可することができます
この通信経路はインターネットを経由しないため、たとえ設定を間違えたとしても第三者へ通信が行われることはなく、内部からの攻撃に対してもセキュリティメリットを得ることができます