AWSセキュリティ ベストプラクティスとは？設定・監視・対策を徹底解説

AWSセキュリティ対策の必要性

AWSをはじめとするクラウドサービスは「クラウド事業者がセキュリティを守ってくれる」というイメージを持たれることがありますが、実際にはそうではありません。AWSとユーザはそれぞれ異なる範囲のセキュリティ責任を担っており、この考え方を「責任共有モデル」と呼びます。

参考：「AWS 責任共有モデル」をもとに作成

責任共有モデルでは、AWSはデータセンターや物理サーバなどのインフラ層を担当します。一方、その上で動くOSの設定、アクセス権限の管理、データの暗号化といった領域はユーザ側の責任です。EC2インスタンスへのOSパッチ適用、S3バケットのアクセス制御、IAMユーザーへの権限付与はすべてユーザ側で対処すべき作業にあたります。
「クラウドだから安全」という思い込みが最大のリスクです。設定ミスや権限の誤付与は、外部からの不正アクセスや内部の誤操作によるデータ漏洩・サービス停止に直結します。自社が守るべき範囲を正確に把握することが、AWSセキュリティ対策の出発点になります。

AWSセキュリティ ベストプラクティスの全体像

AWSはクラウド環境を安全・効率的に構築・運用するための指針として「AWS Well-Architectedフレームワーク」を公開しています。フレームワークはオペレーショナルエクセレンス・セキュリティ・信頼性・パフォーマンス効率・コスト最適化・持続可能性の6つの柱で構成されており、本記事ではその中の「セキュリティの柱」にフォーカスします。フレームワークの詳細については「AWS運用のベストプラクティス：AWS Well-Architected」の解説記事もあわせてご確認ください。
セキュリティの柱はさらに7つの領域に分かれており、各領域のベストプラクティスに沿って対策を進めることが推奨されています。

領域	主な対策内容
1.セキュリティ基盤	アカウント管理・ガードレール設計・ログ基盤の整備
2.アイデンティティとアクセス管理（IAM）	最小権限・MFA・IAMロールの適切な設計
3.検出	不正アクセス・異常操作の検出
4.インフラストラクチャの保護	VPC設計・セキュリティグループ・通信の可視化
5.データ保護	保存・転送中の暗号化、S3の公開設定管理
6.インシデント対応	対応フローの整備と自動化ルールの構築
7.アプリケーションセキュリティ	開発・デプロイ工程でのセキュリティ組み込み

「全部やる必要があるのか」と感じる方もいるかもしれませんが、重要なのは自社の現状と照らし合わせ、どの領域に抜け漏れがあるかを把握することです。各領域を順に見ていきましょう。

クラウド環境のセキュリティ対策ならクラウドファスナー CloudFastener（クラウドファスナー）はクラウドセキュリティリスクの可視化から、アラートの優先度整理・是正・改善まで、専門チームが継続的にサポートします。 【無料】CloudFastnerのサービス資料をダウンロードする

領域1.セキュリティ基盤

冒頭で触れた責任共有モデルを前提に、AWSアカウント全体のセキュリティ基盤を設計することが出発点です。セキュリティ基盤は、個別サービスの設定に先立って整えるべき土台であり、アカウント管理の方針・ガードレールの設計・ログ基盤の整備を行うことで、以降の領域が機能する環境が整います。

マルチアカウント管理とガードレールの設計

AWSを本格的に運用する場合、用途ごとにAWSアカウントを分離するマルチアカウント構成が推奨されます。単一アカウントですべてを運用すると、ある環境での侵害や設定ミスが全体に波及するリスクがあります。本番・開発・ログ集約などアカウントを分離することで、影響範囲を局所化し、環境ごとに適切な権限設計を適用できます。
あわせて重要なのが「ガードレール」の設計です。ガードレールとは、セキュリティ上問題のある操作をそもそも実行できないようにする「予防的統制」と、問題のある設定を検出して通知する「発見的統制」の総称です。個々の担当者のスキルや注意力に依存せず、組織全体で一定のセキュリティ水準を保つための仕組みです。

AWS Organizations
複数のAWSアカウントを一元管理するサービスです。アカウントの作成・グループ化・請求の一本化ができるほか、後述するSCPの適用基盤になります。

AWS Control Tower
マルチアカウント環境を安全なベースライン設定で自動構築するサービスです。予防的・発見的ガードレールがあらかじめ組み込まれており、セキュリティのベースラインを一から設計する手間を大幅に削減できます。

Service Control Policies（SCP）
Organizations全体または特定のアカウントグループに対して、IAMポリシーより上位のアクセス制限を適用できます。たとえば「特定リージョン以外へのリソース作成を禁止する」「ルートアカウントの操作を制限する」といった予防的ガードレールを組織全体に強制できます。個々のIAM設定に依存せず、組織レベルで操作を制限できる点が特徴です。

ログ基盤の整備

セキュリティ上の異常を検知し、インシデント発生時に原因を追跡するには、ログが記録されている状態が前提です。後から「ログを取っていなかった」では対応できないため、利用開始時点での有効化が重要です。

AWS CloudTrail
AWSアカウント内のすべてのAPIコール操作を記録します。「誰が・いつ・何を操作したか」を追跡できる証跡として、インシデント調査の基盤になります。マルチリージョン証跡を有効にし、S3への長期保存を設定しておきましょう。

AWS Config
AWSリソースの設定変更を継続的に記録し、設定の変遷を可視化します。「いつ・誰が・どのリソースの設定を変えたか」を把握できるため、意図しない変更の検出や監査対応に役立ちます。

領域2.アイデンティティとアクセス管理（IAM）

IAM（Identity and Access Management）は、AWSリソースへの「誰が」「何を」「どこまで」操作できるかを制御する仕組みです。セキュリティの入口として最も重要な領域であり、設定の甘さが直接的な侵害につながります。

最小権限・MFA・IAMロールの基本

IAMの基本原則は「最小権限の原則（Least Privilege）」です。ユーザやサービスに対して、業務に必要な権限だけを付与し、それ以上は与えないという考え方です。
具体的な実践ポイントは次のとおりです。

MFA（多要素認証）の有効化
ルートアカウントおよびすべてのIAMユーザーに対してMFAを設定します。特にルートアカウントは「最終手段」として扱い、日常的な操作には使わないことが原則です。

IAMロールの活用
EC2・Lambda・ECSなどのAWSサービスがほかのAWSリソースにアクセスする際は、アクセスキーをコードに埋め込まず、IAMロールを割り当てます。アクセスキーの漏洩リスクを根本から減らす設計です。

ポリシーはAWS管理ポリシーまたはカスタム管理ポリシーを使用
インラインポリシーは管理が煩雑になるため、再利用性の高い管理ポリシーを使用します。権限の棚卸しがしやすくなります。

権限の棚卸しで見直すべきポイント

IAMでよく見られる問題は「いつの間にか権限が膨らんでいる」状態です。よくあるパターンを確認してみましょう。

「とりあえずAdministratorAccess」の放置
開発初期に「全部使えるように」とAdministratorAccessをつけたまま本番運用に移行しているケースは珍しくありません。攻撃者に奪われた場合、AWSアカウント全体が掌握されるリスクがあります。

未使用のIAMユーザーの残存
退職した社員や外部業者のIAMユーザーが削除されずに残っていると、使われなくなった認証情報が攻撃の入口になります。IAM Access Analyzerや認証情報レポートを活用し、定期的に棚卸しする習慣が必要です。

アクセスキーの長期放置
アクセスキーの有効期限は無期限であるため、意識して定期的にローテーションしなければなりません。90日以上使われていないキーは失効または削除を検討します。
IAMの見直しには「最後のアクティビティ」を確認できるIAMコンソールの機能を活用すると、不要な権限の特定が効率化されます。

領域3.検出

セキュリティは「守る」だけでなく「気づく」仕組みが不可欠です。攻撃や異常をいかに早期に検出し、対応に結びつけるかが被害の大小を左右します。
予防的統制（攻撃を受けないようにする施策）と発見的統制（攻撃や異常を検知する施策）を組み合わせることで、多層的な防御が実現します。

CloudTrail・CloudWatch・GuardDuty・Security Hubの役割

AWSには監視・検出に特化した複数のサービスがあります。それぞれの役割を整理します。

AWS CloudTrail
「ログ基盤の整備」でも記載しましたが、AWS CloudTrailは「誰が・いつ・何の操作をしたか」を追跡できるため、インシデント発生後の原因調査（フォレンジック）に不可欠です。

Amazon CloudWatch
AWSリソースのメトリクスとログを収集・可視化します。EC2のCPU使用率・ネットワーク通信量・カスタムアプリケーションのログなどをモニタリングし、閾値超過時にアラームを発報する設定が可能です。CloudWatch Logsと連携させることで、ログの一元管理ができます。

Amazon GuardDuty
CloudTrailのログ、VPC Flow Logs、DNSクエリログなどを機械学習で分析し、不審な動作を自動検出する脅威検知サービスです。有効化するだけで動作し、外部IPからの異常なAPIアクセスや内部からの不審な通信などを検出します。全リージョンで有効にしておくことが推奨されます。

AWS Security Hub
GuardDuty・Inspector・Macieなど複数のセキュリティサービスの検出結果を一元集約し、CIS AWS Foundationsベンチマークなど複数の標準への準拠状況をスコアで可視化します。何をどこまで対応すべきかの優先順位付けにも役立ちます。

「ログは取っているが活用できていない」状態を抜け出すには

「CloudTrailを有効にしてS3に保存している。でも何かあったときに見方がわからない。」こうした状態に心当たりがある方は少なくないはずです。
ログを活用できていない主な原因は、「何を監視すべきかが決まっていない」ことです。アラートの基準が曖昧なまま大量のログを蓄積しても、何かあったときに該当のログを特定できません。

まず取り組むべきは監視すべきイベントの絞り込みです。具体的には以下のようなイベントに対してCloudWatchアラームやGuardDutyの検出を設定するところから始めると実効性が高まります。

• ルートアカウントへのサインイン
• MFAなしのコンソールサインイン
• IAMポリシーの変更
• セキュリティグループの変更
• S3バケットポリシーの変更
• CloudTrailの無効化

監視項目を絞り、アラート発報後の対応フローを決めておくことで、「ログを取っているが活用できていない」状態から「異常を検知して動ける」状態に移行できます。

領域4.インフラストラクチャの保護

ネットワーク層の設計は、外部からの不正アクセスを防ぐ最初の防壁です。AWSではVPCを中心にした設計でトラフィックを制御します。

VPC設計・セキュリティグループ・NACLの基本

VPC（Virtual Private Cloud）の設計原則
パブリックサブネットとプライベートサブネットを分離し、インターネットに直接さらされる必要のないリソース（DBサーバ・バックエンドAPIなど）はプライベートサブネットに配置します。外部アクセスが必要な場合はNATゲートウェイやロードバランサを経由させる構成が基本です。

セキュリティグループ（SG）
インスタンス単位で適用するステートフルなファイアウォールです。インバウンドルールは必要なポート・プロトコル・送信元IPのみに絞り、0.0.0.0/0（全IPからのアクセス許可）は原則として使用しません。特に22番ポート（SSH）や3389番ポート（RDP）をインターネットに開放することは避けてください。

NACL（ネットワークACL）
サブネット単位で適用するステートレスなファイアウォールです。セキュリティグループと組み合わせることで多層防御が実現します。悪意のあるIPをサブネットレベルでブロックしたい場合に活用できます。

VPC Flow Logsで通信を可視化する

VPC Flow Logsは、VPC内のネットワークインターフェースに出入りするIPトラフィックの情報を記録するサービスです。通常の運用では気づきにくい不審な通信を可視化できます。

Flow LogsをS3またはCloudWatch Logsに出力することで、以下のような用途で利用できます。

• 普段接続してこないIPアドレスからの大量アクセスの検出
• 特定ポートへの継続的なスキャン（ポートスキャン）の把握
• 内部リソースから外部への不審なデータ送信（C2通信）の検出
• GuardDutyの検出結果と照合した証跡確認

Flow LogsはデフォルトではOFFのため、明示的に有効化する必要があります。コストが気になる場合はVPC単位ではなく特定のENI（ネットワークインターフェース）単位で有効化する方法も選択できます。

脆弱性スキャンとパッチ適用の自動化

インフラストラクチャの保護はネットワーク設計だけでなく、稼働中のリソースの脆弱性を継続的に管理することも含みます。一度設定して終わりではなく、日常的に回し続ける仕組みが求められます。

Amazon Inspector
EC2インスタンス・コンテナイメージ（ECR）・Lambda関数に対して脆弱性スキャンを継続的に実行するサービスです。CVEデータベースと照合し、既知の脆弱性を自動検出します。有効化するだけで対象リソースが自動的にスキャン対象になります。検出された脆弱性はリスクスコアで優先順位付けされるため、対応順序の判断がしやすくなっています。

AWS Systems Manager Patch Manager
SSM Agentの導入を前提に、EC2インスタンスへのパッチ適用をポリシーベースで自動実行します。パッチ承認ルールを設定し、重要度の高いパッチを優先的に適用するフローを組むことができます。

AWS Config
AWSリソースの設定変更を継続的に記録し、事前に定義したルールへの準拠状況を評価します。「S3バケットが暗号化されているか」「セキュリティグループに0.0.0.0/0のルールがないか」といったチェックを自動実行し、非準拠のリソースを可視化します。自動修復ルール（AWS Config Remediations）と組み合わせることで、非準拠リソースの検出から是正アクションの実行までをほぼ自動化できます。

領域5.データ保護

AWSで扱うデータは「保存中のデータ（Data at Rest）」と「転送中のデータ（Data in Transit）」に分けて、それぞれ暗号化の設計を考えます。

保存データ・転送中データの暗号化

保存データの暗号化
S3・EBS・RDS・DynamoDB・EFSなど、主要なAWSストレージサービスはいずれもAWS KMS（Key Management Service）を使用した暗号化に対応しています。新規作成時にデフォルト暗号化を有効にしておくことで、意図せず暗号化されていないデータが生まれるリスクを防げます。
AWS KMSでは「AWSが管理するキー（aws/s3など）」と「カスタマー管理キー（CMK）」が選択できます。規制対応や監査ログの詳細確認が必要な場合はCMKの使用を検討しましょう。

転送中データの暗号化
クライアントとAWSサービス間、またはAWSサービス間の通信はTLS（Transport Layer Security）で暗号化します。ALBやCloudFrontで古いTLSバージョン（TLS 1.0/1.1）を受け付けない設定にし、TLS 1.2以上を強制することが推奨されます。

S3バケットの公開設定ミス対策

S3バケットの誤った公開設定は、データ漏洩インシデントの原因として最も報告が多いケースのひとつです。機密情報が誰でもアクセス可能な状態で放置されていたというケースは国内外を問わず発生しています。
対策の基本は以下の設定です。

S3 Block Public Accessの有効化
アカウントレベルおよびバケットレベルで「Block Public Access」を有効にします。これにより、意図しない公開設定の変更をブロックできます。

バケットポリシーの定期確認
バケットポリシーに”Principal”: “*”（誰でもアクセス可能）が含まれていないかを定期的に確認します。AWS Config RulesやSecurity Hubのチェック項目に含まれているため、自動評価が可能です。

Amazon Macieの活用
Amazon Macieは機械学習を活用してS3内の機密データ（個人情報・認証情報など）を自動で検出するサービスです。「どのバケットに何の情報が入っているか把握できていない」という状況の解消に役立ちます。

領域6.インシデントへの対応

セキュリティインシデントは「起きるかもしれないこと」ではなく「いつか起きること」として備える必要があります。発生後に初めて対応を考えると、判断が遅れ被害が拡大します。

対応手順の事前整備とシミュレーション

インシデント対応計画（IRP）の作成
最低限、以下の内容を文書化しておきましょう。

• 対応担当者と責任範囲の定義
• 検知から報告・エスカレーションまでの連絡フロー
• インシデントの重大度分類（Critical/High/Medium/Low）
• 初動対応の判断基準（封じ込め・遮断の条件）
• 関係者の役割と連絡先

ゲームデイ（シミュレーション訓練）
AWSはインシデント対応訓練として「ゲームデイ」を推奨しています。本番環境に近い環境で擬似的なインシデントを発生させ、対応手順の実効性を確認します。手順書に書いてあることが実際に対応できるかどうかは、訓練してみないとわかりません。

自動修復の仕組みづくり

インシデント発生時にすべてを手動で対応しようとすると、深夜・休日の対応が困難になります。あらかじめ「この状況ではこの処置を自動で行う」というルールを設計しておくことが重要です。

Amazon EventBridge + AWS Lambda
GuardDutyやSecurity Hubが検出したイベントをEventBridgeで受け取り、あらかじめ設定したルールに基づいてLambdaが自動アクションを実行する仕組みです。たとえば「不審なIPからのアクセスを検出したらセキュリティグループから自動排除する」「侵害が疑われるIAMユーザーのアクセスキーを自動無効化する」といった処理を、人手を介さずに動かせます。

AWS Systems Manager Automationドキュメント
EC2インスタンスの隔離・スナップショット取得・ログ収集といった対応手順をコード化したRunbookとして整理できます。インシデント時に手順書を見ながら手作業する代わりに、承認ボタン一つで一連の処置を実行できる環境を整えておきましょう。

クラウド環境のセキュリティ対策ならクラウドファスナー CloudFastener（クラウドファスナー）はクラウドセキュリティリスクの可視化から、アラートの優先度整理・是正・改善まで、専門チームが継続的にサポートします。 【無料】CloudFastnerのサービス資料をダウンロードする

領域7.アプリケーションセキュリティ

アプリケーションセキュリティは、AWSで動くアプリケーションの開発・デプロイ・運用の各工程にセキュリティを組み込む領域です。インフラ層の設定が整っていても、アプリケーション層に脆弱性があれば侵害の入口になります。

開発・デプロイ工程へのセキュリティ組み込み

「セキュリティは後で対応する」という進め方は、修正コストの増大と対応漏れのリスクを招きます。開発の早い段階からセキュリティチェックを組み込む「シフトレフト」の考え方が推奨されています。

Amazon Inspector（コードスキャン）
ECRに登録したコンテナイメージのスキャンに加え、Lambda関数のコードに含まれるソフトウェア依存関係の脆弱性も検出します。CI/CDパイプラインに組み込むことで、デプロイ前の自動チェックが実現します。

AWS WAF（Web Application Firewall）
ALBやCloudFront、API Gatewayの前段に配置し、SQLインジェクションやクロスサイトスクリプティング（XSS）などのWebアプリケーションへの攻撃を検出・ブロックします。AWSが提供するマネージドルールを利用することで、専門知識がなくても一定水準の防御を迅速に適用できます。

セキュリティテストと依存ライブラリの管理

本番環境に近い環境での定期的なペネトレーションテスト（侵入テスト）や、使用しているOSSライブラリの脆弱性情報の継続的な追跡も、アプリケーションセキュリティの重要な取り組みです。Amazon Inspector v2はLambdaのコード依存関係スキャンにも対応しており、ライブラリ起因の脆弱性を自動で把握する仕組みとして役立ちます。

AWSセキュリティの設定におけるよくある失敗と対策例

ここまで7つの領域を紹介してきましたが、実際の現場ではどのような失敗が起きているのでしょうか。

ルートアカウントの管理不備
MFAが設定されていない、日常的な操作にルートアカウントを使い続けているケースは依然として多く、乗っ取られた場合はアカウント全体が掌握されます。またSCPが未設定のままOrganizationsを運用しているケースも多く、ガードレールのない状態では設定ミスを組織レベルで防ぐ手段がありません。

IAMの権限過多
「まず開発を進めるためにAdministratorAccess」から始まり、本番環境でもそのまま使い続けているケースです。攻撃者に乗っ取られると全リソースが影響を受けるため、権限の棚卸しは優先度を高く設定しましょう。

S3バケットの意図しない公開
バケット作成時の設定ミスやポリシーの誤記述により、機密データが外部から閲覧可能な状態になっていたという事例が国内外で続いています。Block Public Accessをアカウントレベルで有効化しておくことが基本的な防衛策です。

ログの未活用
CloudTrailを有効にしているものの、アラートの設定がなく異常が起きていても気づかない——という状態は「守っているつもり」になりやすい危険なパターンです。最低限、ルートアカウントへのサインインやIAMポリシーの変更に対してアラートを設定しておくだけでも大きく変わります。
「自社は大丈夫」と思っていても、棚卸しを行っていなければ実態は把握できていないはずです。一度、上記の観点で現状確認することをおすすめします。

ベストプラクティスを実践する上での現実的な課題

AWSセキュリティのベストプラクティスを把握することと、実際に継続して運用することの間には、大きな壁があります。

まず、対策項目が多すぎて優先順位がつけにくいという問題があります。IAM・監視・VPC・暗号化・脆弱性管理・インシデント対応と、各領域ごとに設定事項が積み重なり、「全部やる」のは現実的ではありません。どこから手をつけるかの判断に時間がかかり、結果として何も進まないことも起きます。

次に、アラート対応の工数です。GuardDutyやSecurity Hubを有効化すると大量の検出結果が届きます。それぞれの内容を評価し、誤検知なのか本当に危険なのかを判断するためには、AWSサービスの知識と運用経験が必要です。

そしてセキュリティ専門人材の不足。AWSに加え、セキュリティの専門知識も持つ人材を社内に確保することは、多くの企業にとって現実的ではありません。

このように、AWSセキュリティのベストプラクティスを自社で継続的に運用するには、人材・工数・専門知識の3つの壁があります。こうした課題への現実的な対処法として、マネージドサービスの活用が挙げられます。

AWSセキュリティ専門のマネージドサービスという選択肢

自社対応の限界とアウトソースのメリット

AWSのセキュリティを適切に維持するには、設定・監視・対応・改善を継続的に回し続ける体制が必要です。しかし専任のセキュリティエンジニアを採用・育成し、24時間体制を整えることは多くの企業にとって容易ではありません。

マネージドセキュリティサービス（MSS）に委託することで、社内リソースに依存せず専門家チームによる継続的な監視・対応が可能になります。「インシデントが起きたときだけ動く」ではなく、常時監視の態勢を外部で担ってもらうことで、日常の運用工数を大幅に削減できます。

一方で、マネージドサービスの選定では「AWSに特化しているか」「アラート発報後の対応まで含まれるか」「自社の業務に合わせた運用が可能か」を確認することが重要です。監視ツールを提供するだけのサービスと、分析・判断・対応まで担うサービスでは、提供される価値が大きく異なります。

CloudFastener（クラウドファスナー）で解決できること

CloudFastenerは、フルマネージドクラウドセキュリティサービスです。AWS MSSPコンピテンシーを日本企業として初めて、世界でも14社目として取得しており、AWSセキュリティの実績と専門性を持つチームが対応します。

継続監視とアラートトリアージ
GuardDuty・Security Hub・CloudTrailなどから発生する検出結果を専任チームが監視し、緊急度に応じてトリアージ（優先度評価）を実施します。大量のアラートを自社で捌く必要がなくなり、本当に対応が必要な事象に集中できます。

設定・監視・対応のワンストップ対応
セキュリティ設定の見直し・改善提案から、インシデント発生時の初動対応支援まで、AWSセキュリティに関わる業務をワンストップで担います。社内に専任エンジニアがいなくても、専門家チームをバックアップとして持てる環境です。

本記事で取り上げたセキュリティ基盤・IAM・検出・インフラ・データ・インシデント対応・アプリケーションセキュリティの7領域は、いずれも継続的に維持し続ける必要があります。ベストプラクティスは「全部やる」よりも「自社の現状と照らし合わせ、抜け漏れを特定する」ことが実践への第一歩です。対応が難しいと感じる部分は、CloudFastenerのような専門サービスとの役割分担も選択肢のひとつとして検討してみてください。

AWSセキュリティのベストプラクティスにおいてよくある質問

AWS Securityのベストプラクティスは？

AWSはWell-Architectedフレームワークのセキュリティの柱として、7つの領域にわたるベストプラクティスを公開しています。具体的には、セキュリティ基盤の整備・IAMによるアクセス制御・脅威の検出・インフラストラクチャの保護・データの暗号化・インシデント対応の仕組み化・アプリケーションセキュリティの組み込みが挙げられます。設定項目が多岐にわたるため、まず自社環境と照らし合わせて抜け漏れのある領域を特定することが実践の第一歩です。

各領域の詳細は「AWSセキュリティ ベストプラクティスの全体像」をご確認ください。

AWSのセキュリティグループルールとは何ですか？

セキュリティグループルールとは、EC2インスタンスなどに出入りするトラフィックを許可するための設定です。インバウンドルール（外部からインスタンスへの通信）とアウトバウンドルール（インスタンスから外部への通信）をそれぞれ設定します。ルールにはプロトコル・ポート番号・送信元または送信先のIPアドレス範囲を指定します。原則として必要な通信のみを許可し、0.0.0.0/0（全IPからのアクセス）の使用は最小限に抑えることがセキュリティ上の基本です。

設定のポイントは「VPC設計・セキュリティグループ・NACLの基本」をご確認ください。

AWSのNACLとセキュリティグループの違いは何ですか？

どちらもAWSのネットワークアクセスを制御する仕組みですが、適用範囲と動作の仕方が異なります。セキュリティグループはEC2などのインスタンス単位に適用するステートフルなファイアウォールで、一度許可した通信の戻りパケットは自動的に許可されます。一方、NACL（ネットワークACL）はサブネット単位に適用するステートレスなファイアウォールで、インバウンド・アウトバウンドそれぞれに明示的なルール設定が必要です。両者を組み合わせることで多層的な防御が実現します。

詳しくは「VPC設計・セキュリティグループ・NACLの基本」をご確認ください。