【読んでみた】Amazon VPCを保護するためのベストプラクティス #reinvent #NET309

はじめに

こんにちは、佐伯です。

私はre:Invent 2017に参加していないので、レポートではなく「読んでみた」という形で以下ワークショップのスライドをGoogle翻訳を駆使して読んでみました。所々にAWSドキュメントのリンクも入れています。なお、ワークショップのスライドなので、ハンズオン部分は省いてます。ご了承ください！

[slideshare id=83144263&doc=net309-best-practices-for-secu-d21b4ab5-aad1-4bf0-bf1e-4018bb9b832b-525728499-171201191331]

予防的制御

• 悪意のある、意図しない、または望ましくないアクティビティの防止
• 一般的にベースラインのセキュリティ要件(インターネットからのSSH接続を許可しないなど)を満たす
• インフラストラクチャの「望ましい状態」を表す

AWSにおける予防的制御

• VPC、セキュリティグループおよびネットワークACL
• ルーティングとVPCピアリング
• 転送データの暗号化
• AWS WAFとAWS Shield
• VPCエンドポイント
• IAMポリシー

VPC、サブネット、ゲートウェイおよびピアリング

サブネットとゲートウェイの種類

• Publicサブネット
• インターネットへはインターネットゲートウェイ経由で通信が可能
• Privateサブネット
• インターネットへのアウトバウンド方向の通信はNATゲートウェイ or NATインスタンス経由のみで通信が可能
• またはインターネットへはアクセスできない(仮想プライベートゲートウェイ/VPCピアリングへの通信のみ)
• ゲートウェイの種類
• インターネットゲートウェイ(IGW): Publicサブネットからインターネットへの通信を可能にする
• NATゲートウェイ(NGW): Privateサブネットからアウトバウンド方向のインターネットへの通信を可能にする
• 仮想プライベートゲートウェイ(VGW): VPN経由のプライベートネットワークとの通信を可能にする

NATインスタンス vs NATゲートウェイ

項目	NATゲートウェイ	NATインスタンス
可用性	AZごとに冗長化されている	スクリプトを使用したフェイルオーバーなど、ユーザーが用意する必要あり
パフォーマンス	10Gbpsまでのバーストをサポート	インスタンスタイプに依存する
メンテナンス	AWSのマネージドサービス	ユーザーがインスタンスを管理する
コスト	NATゲートウェイの数、使用期間、データ転送量に応じて課金	NATインスタンスの数、使用期間、インスタンスタイプ/サイズに応じて課金
セキュリティ	ネットワークACLをサポート	セキュリティグループとネットワークACLをサポート
モニタリング	Flow LogsとCloudWatchをサポート	Flow LogsとCloudWatchをサポート
フラグメンテーション	UDPのみサポート	TCP/UDP/ICMPをサポート

NAT インスタンスと NAT ゲートウェイの比較 - Amazon Virtual Private Cloud

VPCピアリング

• ふたつのVPC間を接続する機能
• 同じAWSアカウント内のVPCとの接続、または他のAWSアカウントのVPCとの接続ができる
• ただし、VPCは同一リージョンである必要がある
• Amazon VPCの既存インフラを使用してVPCピアリングを作成している
• ボトルネックや単一障害点は存在しない
• VPCピアリングでVPC間を接続する場合は既存VPCのセキュリティグループとネットワークACLを考慮する

VPC分離の課題

• 複雑さが増す
• メッシュ型のピアリング接続の管理
• IPアドレス空間の管理
• VPCピアリングデータ転送コスト
• AWSサービスの制限事項
• AWS MicrosoftAD経由のRDS認証は単一のVPCのみ
• VPCピアリング越しにNLBのエンドポイントにはアクセスできない
• VPC間はフルメッシュで接続する必要があり、ハブアンドスポーク型のルーティングはできない

無効な VPC ピア接続設定 - Amazon Virtual Private Cloud

セキュリティグループとネットワークACL

セキュリティグループ vs ネットワークACL

セキュリティグループ	ネットワークACL
インスタンスレベルで動作する	サブネットレベルで動作する
許可ルールのみ設定可能	許可および拒否ルールを設定可能
ステートフル(戻り通信は自動で許可される)	ステートレス(戻り通信の許可ルールを設定する必要がある)
全てのルールが評価される	ルール番号の低い順に評価され一致するルールがあれば以降の評価は行わない
インスタンスに明示的に関連付けた場合に適用される	関連付けられたサブネット内の全てのインスタンスに自動的に適用される

セキュリティグループとネットワークACLはリンクローカルアドレス (169.254.0.0/16) またはAWS予約済みIPアドレスとやり取りされるトラフィックをフィルタリングしません。AWS予約済みアドレスは、サブネットの最初の4個のIPアドレス (VPCのAmazon DNSサーバーアドレスを含む)

セキュリティ - Amazon Virtual Private Cloud

ネットワークACLを使用する理由

• 役割の分離
• 異なるIAMアクションにより、セキュリティグループとネットワークACLの管理を分離できる
• 明示的な拒否ルールを指定できる
• 特定のIPアドレス/ポートをブラックリスト形式で登録できる
• 接続追跡されたトラフィックフローを切断する
• セキュリティグループを削除した際、そのトラフィックがすぐに中断されるようにする場合にネットワークACLを使用する(*)

(*)Linux インスタンスの Amazon EC2 セキュリティグループ - 接続追跡 - Amazon Elastic Compute Cloud

落とし穴

• セキュリティグループは同一サブネットであってもインスタンス間の通信を暗黙的に許可しない
• セキュリティグループのルールにプライベートアドレスを設定した場合は、プライベートアドレス宛の通信に対して機能する
• VPC内からパブリックIPへのアクセスは送信元がパブリックIPアドレスとなる
• ELBを使用する際のネットワークACLでの注意
• ELBからバックエンドへのヘルスチェック通信を許可する
• ELB通信は同一サブネットであってもVPCルーターを経由する

VPCエンドポイント

VPCエンドポイントはプライベートなVPCからのAWSサービスへの接続を提供する機能

VPCエンドポイントの種類

• Amazon VPC Gateway Endpoint
• インターネットゲートウェイ、NATゲートウェイ、パブリックIPは不要
• プライベートIPからS3またはDynamoDBにアクセスできる
• コンテンツ固有のアクセス制御
• 堅牢なアクセス制御
• AWS Interface Endpoint(AWS PrivateLink)
• インターネットゲートウェイ、NATゲートウェイ、パブリックIPは不要
• プライベートIPから指定したAWSサービスにアクセスできる
• セキュリティグループによるアクセス制御

VPC Gateway Endpoint

• ルートテーブルにプレフィックスリストを追加する
• プレフィックスリストとは
• ターゲットの論理的な宛先
• 動的にサービスIPアドレスに変換される
• S3プレリックスリストはS3のIPレンジへの抽象的な変換を行う
• プレフィックスリストはセキュリティグループのルールに設定できる

VPC Interface Endpoint(AWS PrivateLink)

• PrivateLinkはVPC内に作成される
• ENIをAZごとに作成する
• IPアドレスはサブネットのIPアドレス範囲
• Direct Connect経由のアクセスも可能
• プライベートDNSをサポート
• AWSサービスのDNS名を上書きする
• 現在サポートしているAWSサービス
• Kinesis
• Service Catalog
• Amazon EC2
• EC2 Systems Manager(SSM)
• Elastic Load Balancing

VPC内のトラフィック

• VPC内の通信はAWSアカウントとに分離されている
• AWSアカウントごとに通信フローの堅牢な分離
• 様々なAWSの制御と認証(PCI-DSSなど)で実証されている
• 通信はAmazonのプライベートネットワークを流れる
• ユーザーの責任範囲は転送データの暗号化
• アプリケーションレベル(TLS)の暗号化

AWSマネージドサービスを使用したSSL/TLS通信

• AWSマネージドサービスを使用したSSL/TLSオフロード
• AWSでSSL証明書とSSL Terminationを管理
• ネットワークエッジでトラフィックの復号化(必要に応じてトラフィックの検査)
• 復号化した通信をインスタンスへ送信(必要に応じて再暗号化)
• SSL/TLSオフロードをサポートするAWSサービス
• AWS Certificate Manager
• Application Load Balancer
• Amazon Classic Load Balancer(L7モード)
• Amazon CloudFront
• Amazon API Gateway

ユーザーリソースを使用したSSL/TLS通信

• インスタンスへのSSL/TLS通信を許可する
• 非暗号化通信は許可しない
• SSL/TLS通信はそのままインスタンスに到達する
• AWSでコンテンツの検査はできない
• ユーザー管理によるSSL/TLS通信をサポートするAWSサービス
• Amazon Network Load Balancer
• Amazon Classic Load Balancer(L4モード)

AWS Shield Standard & AWS WAF

AWSに組み込まれたDDoS保護

• AWSグローバルインフラストラクチャに統合
• AWSデータセンターによる冗長化されたインターネット接続性
• 外部ルーティングなしで迅速な緩和が可能
• 一般的な攻撃からの常時保護を提供する
• SYNフラッド攻撃
• UDPフラッド攻撃
• リフレクション攻撃
• カスタマイズ可能なL7攻撃に対する保護を提供
• AWS WAF
• 従量制料金

WAFはどのような攻撃を防ぐか?

AWS WAFの特徴

• カスタマイズ可能なルールに対応した豊富な機能
• フル機能のAPIを提供
• DevOps WAFとして設計
• 新しいWebサイトやアプリケーションでインライン展開が可能
• AWSサービスとの統合：
• CloudFront、ALB、CloudWatch
• AWSパートナーとの統合：
• Alert Logic, Trend Micro、Imperva
• AWSから従量制料金で提供

AWS WAFによって対処される攻撃ベクトル

• SQLインジェクション
• クロスサイトスクリプティング
• スキャナーやプローブ
• 既知の攻撃元
• ボットとスクレイバー
• アプリケーションレベルのエクスプロイト

AWS WAFのコンポーネント

• 条件
• リクエスト元のIPアドレス
• リクエスト内の文字列
• SQLインジェクションの有無
• クロスサイトスクリプティングの有無
• リクエストの長さ
• ルール
• 優先順位、ルール、アクション
• Webアクセス制御リスト(Web ACL)
• AWSリソース
• CoudFrontディストリビューション
• ALB
• レポート
• リアルタイムメトリクス
• サンプリングされたWebリクエスト

AWS Shield Advanced

AWS Shield Advanced

• 以下のDDoS保護をサポート
• アプリケーションレイヤー
• ALBとCLB
• CloudFront、Route53
• EC2インスタンスとNLB(New!)
• 追加機能
• 攻撃の通知とレポート
• DDoS攻撃によるAWS料金の急増に対するコスト保護
• AWS DDoS Response Team(DRT)の利用
• AWS WAFルールの支援
• L7レイヤーへの攻撃緩和のための積極的なDRTの関与

AWS Shield Standard vs Advanced

機能	AWS Shield Standard	AWS Shield Advanced
ネットワークフローモニタリング	○	○
アプリケーションのトラフィックモニタリング	×	○
一般的なDDoS攻撃の防御	○	○
DDoS攻撃に対する追加の保護機能	×	○
レイヤー3/レイヤー4の攻撃に関する通知とレポート	×	○
レイヤー3/レイヤー4/レイヤー7のヒストリカルレポート	×	○
DDoSレスポンスチーム(DRT)によるサポート	×	○
コスト保護	×	○

階層の比較 - AWS Shield | AWS

AWS IAMポリシー

ネットワーキングサービスがサポートするIAMアクセス

サービスおよび関連するIAM情報	次のアクセス権限をサポート
	アクションレベル	リソースレベル	リソースベース	タグベース	一時認証	サービスにリンクされたロール
Amazon VPC	Yes	Yes	Yes	Yes	Yes	No
Amazon CloudFront	Yes	No	No	No	Yes	No
AWS Direct Connect	Yes	No	No	No	Yes	No
Amazon Route 53	Yes	Yes	No	No	Yes	No

AWSリソースタグを使用したアクセス制御

• 必要に応じてタグベースのアクセス制御を使用する
• プロジェクトなどの単位でリソースを扱う
• 新しいリソース作成時に自動的にアクセス許可を適用する
• 以下のサービスは現在タグベースのアクセス制御をサポートしている
• Amazon EC2
• Amazon VPC
• Amazon EBS
• Amazon Glacier
• Amazon RDS
• Amazon Simple Workflow Service
• AWS Data Pipeline

IAM と連携する AWS サービス - AWS Identity and Access Management

タグベースのアクセス制御

• AWSが管理するタグを使用すると不変性を確保できる
• ユーザーはCloudFormationやAutoScalingグループで付与されるタグを直接変更できない
• aws:cloudformation:stack-name
• Aws:autoscaling:groupName
• 上記のタグをIAMポリシーの条件に関連付けることができる
• 特定のユーザーのみタグの変更の許可をする

検知制御

AWSにおける検知制御

• AWS CloudTrail
• AWS Config and Configルール
• Amazon CloudWatch Logsとサブスクリプション
• Amazon CloudWatchメトリクスとアラーム
• VPC Flow Logs
• Amazon Inspector

Amazon CloudTrail

• CloudTrailはAWSアカウントのガバナンス、コンプライアンス、運用とリスク監査を可能にするサービス
• APIコールとアカウントアクティビティイベントを記録する
• コンプライアンス監査を簡素化する
• ユーザーとリソースのアクティビティの可視性を高める
• セキュリティや運用上の問題の発見とトラブルシューティングに役立つ

AWS Config

• AWS Configは継続的な記録・評価サービス
• AWSリソースの変更を追跡する
• AWSリソースの設定がベストプラクティスに準拠しているか確認する
• 設定がベースラインポリシーに準拠していない場合は警告する
• リソースの設定変更に対する影響の評価をサポートする

AWS Config Rules

• 設定変更をチェックする
• 継続的な評価
• スケジュールによるレビュー
• AWSによる定義済みのルール
• AWS Lambdaを使用したカスタムルール
• カスタムルールを使用して設定の自動修復を起動することができる
• GitHubリポジトリ: awslabs/aws-config-rules: [Node, Python, Java] Repository of sample Custom Rules for AWS Config.
• ダッシュボードマットからのコンプライアンス可視化
• コンプライアンスリザルト
• コンプライアンスに違反する変更を特定できる

Amazon CloudWatch Logs

• さまざまなサービスのテキストベース(CSV、JSON)のログデータの保存、検索、および監視を提供する。
• AWS Lambda、Amazon API Gateway、VPC Flow LogsなどのAWSサービス
• Syslog、セキュリティログ、Webアプリケーションのログなどのユーザーサービスのログ
• データの取り込み
• Amazon CloudWatch Logsエージェントを使用して、Linux/WindowsからAmazon CloudWatch Logsに様々なインスタンスベースのログデータを送信することができる
• APIインタフェース、CLIツール、サードパーティインテグレーション
• データの検索
• CloudWatchなど他のAWSサービスとの統合
• APIインタフェース、CLIツール、サードパーティインテグレーション

Amazon CloudWatch Logsの概念

• ログイベント
• アプリケーションまたはAWSリソースによって記録されたアクティビティのレコード。レコードにはタイムスタンプとUTF-8でエンコードされた生のイベントメッセージが含まれている。
• ログストリーム
• 同じソースから送信された順序でイベントを表す
• ロググループ
• 同じ設定を共有するログストリームのグループ
• メトリクスフィルタ
• 受信したログファイルにパターンと照合し、Amazon CloudWatchカスタムメトリクスを更新する
• 保持期間
• ログデータの保持期間
• サブスクリプション
• さらに処理や分析のためログデータを他のサービス(AWS Lambda、Amazon ElasticSearchなど)に送信できる

メトリクスフィルタの作成

• フィルタパターンの定義
• 例: [field1, field2, field3 = "マッチする文字列", field4 != "除外する文字列"]
• フィルタパターンの名前指定
• メトリクスの詳細設定
• メトリクスのネームスペース: "ReInventWorkshop"などのメトリクスの集合
• メトリクスの名前: ネームスペース内で一意となるメトリクスの識別子
• メトリクスの値: メトリクスとしてパブリッシュする値(フィールドからも取得可能)
• メトリクスフィルタは、メトリクスフィルタ作成後に受信したログデータのみに適用される
• コスト
• メトリクスフィルタによって作成されたカスタムメトリクスは、カスタムメトリクスあたり0.30ドル/月
• カスタムメトリクスからトリガーされるアラームは、アラームあたり0.10ドル/月

ベストプラクティス

• CloudWatch Logsはさまざまな利益を提供する
• ログデータの有用な集約ポイント
• データを他のサービスにプッシュする機能
• サードパーティのサービスとの統合
• 注意すべき制限事項
• メトリクスフィルタ、特にプレーンテキストのログデータの場合は複雑なクエリはサポートされない
• サブスクリプションフィルタはロググループごとにひとつしか作成できない

VPC Flow Logs

VPC Flow Logsとは?

• VPCのネットワークインタフェース間で送受信されるIPトラフィックの情報をキャプチャできる
• VPC、サブネット、またはネットワークインタフェースのフローログを作成できる
• ELB、RDSなど他のAWSサービスのフローログを作成できる
• フローログデータはAmazon CloudWatch Logsに保存される
• CloudWatch Logsのロググループにパブリッシュされる
• 各ENIは一意のログストリームを持っている
• 各レコードは特定の5-tuple(送信元IPアドレス、送信元ポート番号、送信先IPアドレス、送信先ポート番号、プロトコル)のネットワークフローをキャプチャする

VPC Flow Logのフォーマット

項目	説明
version	VPC Flow Logバージョン
account-id	AWSアカウントID
interface-id	ログストリームが適用されるENIのID
srcaddr	送信元IPアドレス
dstaddr	送信先IPアドレス
srcport	送信元ポート番号
dstport	送信先ポート番号
protocol	トラフィックのIANAプロトコル番号
packets	キャプチャウィンドウ中に転送されたパケット数
bytes	キャプチャウィンドウ中に転送されたバイト数
start	キャプチャウィンドウの開始時刻(Unix時間)
end	キャプチャウィンドウの終了時刻(Unix時間)
action	トラフィックに関連付けられたアクション(ACCEPT or REJECT)
log-status	フローログのロギングステーテス(OK, NODATA, SKIPDATA)

VPC フローログ - Amazon Virtual Private Cloud

VPC Flow Logsの制限事項

• トラフィックがセカンダリIPアドレスを持つENI宛に送信されても、フローログの送信先IPアドレスはプライマリIPアドレスが表示される
• フローログの API アクション (ec2:*FlowLogs) は、いずれもリソースレベルのアクセス権限をサポートしていない
• 以下のトラフィックはキャプチャされない
• Amazon DNSサーバー宛のトラフィック
• Windowsライセンスアクティベーションサーバー宛のトラフィック
• インスタンスメタデータ用の169.254.169.254宛のトラフィック
• DHCPリクエストとDHCPレスポンスのトラフィック
• デフォルトVPCルーターの予約済みIPアドレスへのトラフィック

VPC Flow Logsの用途

• トラブルシューティングと障害診断
• 制限が過度に厳しいセキュリティグループやネットワークACLの診断
• セキュリティツールとして、インスタンスに達しているトラフィックをモニタリングすることができる
• メトリクスを作成し、傾向やパターンを特定
• 特定の種類のトラフィックに応じてアラームを作成

Amazon Inspector

• AWSアカウントのガバナンス、コンプライアンス、運用とリスク監査を可能にするサービス
• DevSecOpsをサポートするように構築されている
• APIによる自動化
• CI/CDツールとの統合
• ルールパッケージの検索結果を生成する
• 共通脆弱性識別子 (CVE)
• Center for Internet Security (CIS) ベンチマーク
• セキュリティのベストプラクティス
• 実行時の動作の分析

検知制御の要約

• VPC内のネットワークおよびアプリケーショントラフィックの監視とロギング
• VPC Flow Logs、ELBログ
• Amazon CloudWatch Logs
• Amazon Inspector
• AWSアカウント内で行われているAWS APIコールのロギングと監視
• AWS CloudTrail
• AWS Config
• 疑わしいまはた非標準的なアクティビティのアラート
• Amazon CloudWatchアラーム
• AWS Config Rules

自動化

• 検知制御の情報に基づいて環境を「望ましい」状態に戻すのに役立つ
• 人による手動対応がない(または限られた部分だけ)ように設計されている
• 予防的制御が失敗した場合や危殆化した場合、通常はフェールセーフ機能を提供する

AWSにおける自動化

• CloudWatch Events
• AWS Config Rules(カスタムルール)
• EC2 Systems Manager(AWS Systems Manager)

Amazon CloudWatch Events

Amazon CloudWatch Eventsの概念

• イベント: AWS環境における変化を示す
• 他のAWSサービスによって生成される
• スケジュールによって生成される
• カスタムアプリケーションレベルのイベントによって生成される
• ターゲット: イベントを処理する対象
• ターゲットには例えばAWS Lambda、Kinesis Streams、Step Functionsなどを設定することができる
• ルール: 一致した受信イベントを検出し、イベント処理のためにターゲットに振り分ける
• ひとつのルールで複数のターゲットを指定できる
• 並列に処理される

サービスイベント vs CloudTrail APIイベント

• 多くのAWSサービスはCloudWatch Eventsによって検出できるイベントを生成する。例として
• Auto Scaling(ライフサイクルアクション、EC2インスタンスの起動成功)
• AWSマネジメントコンソールへのサインイン
• Amazon EBS(スナップショット通知、ボリューム通知)
• CloudTrailイベントはAWSのAPIコールをキャプチャするCloudTrailによってトリガーされる
• イベントを出力しないAWSサービスに使用できる
• Get、List、またはDescribe APIコールではCloudTrailイベントは出力されない

サポートされている各サービスからの CloudWatch イベント イベントの例 - Amazon CloudWatch Events CloudTrail イベント履歴によってサポートされているサービス - AWS CloudTrail

Amazon CloudWatch Event Bus

• 他のAWSアカウントへのCloudWatch Eventsの送信を許可する
• 組織内/組織間で一元的なCloudWatch Eventsの管理を可能にする
• 受信側のAWSアカウントは登録したAWSアカウント、またはすべてのAWSアカウントからのイベント受信を許可することができる
• 考慮すべきポイント
• イベントのチェインはサポートされない(例: アカウントA→アカウントB→アカウントC)
• 送信側はCloudWatch Eventsの料金がかかるが、受信側には料金はかからない
• ルールは特定のAWSアカウントをスコープ設定することができる

Amazon EC2 Systems Manager(AWS Systems Manager)

• Amazon EC2とオンプレミスシステムの設定と管理を簡素化する
• 使いやすいオートメーション機能
• 可視性とコントロールを向上させる
• ソフトウェアコンプライアンスの維持
• コストを削減
• 安全なロールベースの管理
• さまざまなオペレーティングシステムをサポート
• Microsoft Windows: Windows Server 2003以降
• Linux: Amazon Linux、RHEL、SUSE、Ubuntu

Amazon EC2 Systems Manager(AWS Systems Manager)の7つの要素

• Run Command
• ステートマネージャー
• インベントリ
• メンテナンスウィンドウ
• パッチマネージャー
• オートメーション
• パラメーターストア

一般的なユースケース

• 一貫した設定を維持する
• ステートマネージャを使用してインスタンスとソフトウェアの必要な設定を指定し、自動的に維持することができる
• セキュリティとインシデント分析を実行
• インベントリはAWS Configと統合され、時間の経過とともにインベントリの変更履歴を提供する
• OSとアプリケ−ション構成の管理を容易に
• Run Commandを使用するとOSやアプリケーションの設定変更も可能であり、すべてのPowerShellとLinuxのコマンドをサポートする
• 機密情報へのアクセス制御
• パスワードなど特定のパラメータへのアクセスを制御するだけでなく、それらのパラメータに対して誰がどのような操作を実行できるか設定できる

自動化の概要

• 環境の変化に自動的に対応する
• AWS Custom Config Rules
• Amazon CloudWatch Events
• 大規模なフリートの管理の自動化
• Amazon EC2 Systems Manager(AWS Systems Manager)

サマリー

今日取り上げたこと

• 予防的制御の範囲を検討
• リージョン/グローバルレベルでのAWS WAFの導入
• 最小権限のIAM管理ポリシーの作成
• 検知制御を利用する方法を検討
• VPC Flow Logsのモニタリングおよび通知ログ
• ブラックリストに登録されたソフトウェアパッケージを検索するための設定ルール
• 自動化の利点を探る
• AWS Lambda FunctionをトリガーするAmazon CloudWatch Events
• 大規模なフリートを管理するためのAmazon EC2 Systems Manager(AWS Systems Manager)

一般的なベストプラクティス

• 設計
• アウトバウンドのセキュリティグループや特定のルーティングなど、あまり目立たない設定を忘れない
• 自動化
• CloudFormationなどのツールを使用することによって、人為的ミスを減らすことができる
• モニタ
• 正常なベースラインを確立し、偏差を探す
• AWS ConfigやCloudWatch Eventsなどのツールを使用してモニタリングを簡素化する

まとめ

長くてごめんなさい。ネットワークACLやVPC Flow Logsなど知ったつもりになっていた機能でも知らないことがあったりと新しい発見がありました。また、新しいサービスや新機能のリリースによってベストプラクティスは今後も変化していくんだろうなという印象を受けました。日々学ぶことを忘れずにキャッチアップせねば。