AWS などのパブリッククラウド環境に展開された threat defense virtual インスタンスでは、ネットワークトラフィックでスパイクとディップが発生すことがあるアプリケーションがサポートされます。トラフィックのスパイクにより、展開された Threat Defense Virtual インスタンスの数がネットワークトラフィックの検査には足りないシナリオが発生する可能性があります。トラフィックがディップすると、Threat Defense Virtual インスタンスがアイドル状態になり、不要な運用コストが発生する可能性があります。

Auto Scale ソリューションは、トラフィックがスパイクした場合に Threat Defense Virtual インスタンスの数を自動的にスケールアップし、トラフィックが小休止しているときにインスタンスの数をスケールダウンするのに役立つため、ネットワークリソースを効率的に処理して、運用コストを削減できます。

AWS の threat defense virtual Auto Scale は、AWS 環境の threat defense virtual インスタンスに Auto Scaling 機能を追加する完全なサーバーレス実装です（この機能の自動化に関与するヘルパー VM はありません）。

バージョン 6.4 以降、ネットワークロードバランサ（NLB）ベースの Auto Scale ソリューションは、Management Center によって管理される threat defense virtual でサポートされます。バージョン 7.2 以降では、ゲートウェイロードバランサ（GWLB）ベースの Auto Scale ソリューションもサポートされています。

シスコでは、Lambda、Auto Scaling グループ、Elastic Load Balancing（ELB）、Amazon S3 バケット、SNS、CloudWatch などの複数の AWS サービスを使用して、threat defense virtual ファイアウォールの Auto Scaling グループを展開するための CloudFormation テンプレートとスクリプトを提供しています。

threat defense virtual Auto Scale ソリューションは、以下の内容を提供する CloudFormation テンプレートベースの導入です。

• Management Center による Threat Defense Virtual インスタンスの登録と登録解除の完全な自動化。

• スケールアウトされた Threat Defense Virtual インスタンスへの NAT ポリシー、アクセス コントロール ポリシー、およびルートの自動適用。

• ロードバランサとマルチ可用性ゾーンのサポート。

• Management Center でのみ動作し、Device Manager はサポート対象外。

Auto Scale の機能拡張（バージョン 6.7）

• カスタム指標パブリッシャ：新しい Lambda 機能は、Auto Scale グループ内のすべての Threat Defense Virtual インスタンスのメモリ消費量について を 2 分ごとに Management Center をポーリングし、その値を CloudWatch メトリックに公開します。

• メモリ消費に基づく新しいスケーリングポリシーを使用できます。

• Management Center への SSH およびセキュアトンネル用の Threat Defense Virtual プライベート IP 接続。

• Management Center 設定の検証.

• ELB でより追加のリスニングポートを開くためのサポート。

• シングルスタック展開に変更。すべての Lambda 機能と AWS リソースは、合理化された展開のためにシングルスタックから展開されます。

Auto Scale ソリューションは、次のコンポーネントで構成されています。

CloudFormation テンプレート

CloudFormation テンプレートは、AWS の Auto Scale ソリューションの設定に必要なリソースを展開するために使用されます。テンプレートの構成は次のとおりです。

• Auto Scale グループ、ロードバランサ、セキュリティグループ、およびその他のコンポーネント。

• 展開をカスタマイズするためのユーザー入力を取り込むテンプレート。

  （注）	テンプレートのユーザー入力の検証には限界があるため、展開時に入力を検証するのはユーザーの責任です。

Lambda 関数

Auto Scale ソリューションは、Python で開発された一連の Lambda 関数で、ライフサイクルフック、SNS、CloudWatch イベントやアラームイベントからトリガーされます。基本的な機能は次のとおりです。

• インスタンスに対して Diag、Gig0/0、および Gig 0/1 インターフェイスを追加/削除します。

• ロードバランサのターゲットグループに Gig0/1 インターフェイスを登録します。

• Management Center で Threat Defense Virtual を新規登録します。

• Management Center を介して新規の Threat Defense Virtual を展開します。

• スケールインした Threat Defense Virtual を Management Center から登録解除（削除）します。

• Management Center からメモリメトリックをパブリッシュします。

Lambda 関数は、Python パッケージの形式でお客様に提供されます。

ライフサイクルフック

• ライフサイクルフックは、インスタンスに関するライフサイクルの変更通知を取得するために使用されます。

• インスタンス起動の場合、ライフサイクルフックを使用して、threat defense virtual インスタンスにインターフェイスを追加し、ターゲットグループに外部インターフェイス IP を登録できる Lambda 機能をトリガーします。

• インスタンス終了の場合、ライフサイクルフックを使用して Lambda 機能をトリガーし、ターゲットグループから threat defense virtual インスタンスを登録解除します。

Simple Notification Service（SNS）

• AWS の Simple Notification Service（SNS）を使用してイベントが生成されます。

• AWS にはサーバーレス Lambda 関数に適した Orchestrator がないという制限があるため、ソリューションは、イベントに基づいて Lambda 関数をオーケストレーションするための一種の関数チェーンとして SNS を使用します。

VPC

アプリケーション要件に応じて VPC を作成する必要があります。VPC には、インターネットへのルートがある少なくとも 1 つのサブネットを持つインターネットゲートウェイがあることが想定されます。セキュリティグループ、サブネットなどの要件については、該当するセクションを参照してください。

セキュリティ グループ

提供された Auto Scale グループテンプレートでは、すべての接続が許可されます。Auto Scale ソリューションを機能させるために必要なのは、次の接続だけです。

Management Center インスタンスのセキュリティグループまたは ACL

これらは、Lambda 機能と Management Center 間の HTTPS 接続を許可するために必要です。Lambda 機能は、NAT ゲートウェイをデフォルトルートとして持つ Lambda サブネットに保持されるため、Management Center には NAT ゲートウェイ IP アドレスからのインバウンド HTTPS 接続を設定できます。

サブネット

サブネットは、アプリケーションの要件に応じて作成できます。Threat Defense Virtual が動作するには 3 つのサブネットが必要です。

（注）	複数の可用性ゾーンのサポートが必要な場合、サブネットは AWS クラウド内のゾーンプロパティであるため、各ゾーンにサブネットが必要です。

外部サブネット

外部サブネットには、インターネットゲートウェイへの「0.0.0.0/0」のデフォルトルートが必要です。このサブネットには、Threat Defense Virtual の外部インターフェイスが含まれ、インターネットに面した NLB も含まれます。

内部サブネット

これは、NAT/インターネットゲートウェイの有無にかかわらず、アプリケーションサブネットに似ています。Threat Defense Virtual の正常性プローブでは、ポート 80 経由で AWS メタデータサーバー（169.254.169.254）に到達できる必要があることに注意してください。

（注）	この Auto Scale ソリューションでは、ロードバランサの正常性プローブが inside/Gig0/0 インターフェイスを介して AWS メタデータサーバーにリダイレクトされますが、ロードバランサから Threat Defense Virtual に送信される正常性プローブ接続を提供する独自のアプリケーションで変更できます。その場合、AWS メタデータサーバー オブジェクトをアプリケーションの IP アドレスに置き換えて、正常性プローブ応答を提供する必要があります。

管理サブネット

このサブネットには、Threat Defense Virtual 管理インターフェイスが含まれます。 このサブネットで Management Center を使用している場合、Threat Defense Virtual への Elastic IP アドレス（EIP）の割り当ては任意です。診断インターフェイスもこのサブネット上にあります。

Lambda サブネット

AWS Lambda 関数では、デフォルトゲートウェイとして NAT ゲートウェイを持つ 2 つのサブネットが必要です。これにより、Lambda 関数が VPC に対してプライベートになります。Lambda サブネットは、他のサブネットと同じ幅である必要はありません。

アプリケーションサブネット

Auto Scale ソリューションからこのサブネットに課せられる制限はありませんが、アプリケーションに VPC 外部のアウトバウンド接続が必要な場合は、サブネット上にそれぞれのルートが設定されている必要があります。これは、アウトバウンドで開始されたトラフィックがロードバランサを通過しないためです。詳細については、AWS Elastic Load Balancing User Guide [英語] を参照してください。

サーバーレスコンポーネント

S3 バケット

Amazon Simple Storage Service（Amazon S3）は、業界をリードする拡張性、データ可用性、セキュリティ、およびパフォーマンスを提供するオブジェクト ストレージ サービスです。必要なすべてのファイルを S3 バケットに配置できます。

テンプレートが展開されると、S3 バケット内の zip ファイルを参照して Lambda 機能が作成されるため、S3 バケットはユーザーアカウントにアクセスできる必要があります。

AWS CloudFormation コンソール

AWS CloudFormation コンソールで CloudFormation スタックへの入力パラメータを確認できます。これにより、Web ブラウザからスタックを直接作成、監視、更新、削除できます。

目的のスタックに移動し、[パラメータ（parameter）] タブを確認します。[Lambda関数環境変数（Lambda Functions environment variables）] タブで Lambda 関数への入力を確認することもできます。configuration.json ファイルは、Auto Scale Manager Lambda 関数自体でも表示できます。

AWS CloudFormation コンソールの詳細については、 『AWS CloudFormation ユーザーガイド（AWS CloudFormation User Guide）』を参照してください。

Amazon CloudWatch ログ

個々の Lambda 関数のログを表示できます。AWS Lambda はお客様の代わりに Lambda 関数を自動的に監視し、Amazon CloudWatch を通じてメトリックを報告します。関数の障害のトラブルシューティングに役立つように、Lambda は関数によって処理されたすべての要求をログに記録し、Amazon CloudWatch ログを通じてコードによって生成されたログも自動的に保存します。

Lambda コンソール、CloudWatch コンソール、AWS CLI、または CloudWatch API を使用して、Lambda のログを表示できます。ロググループと CloudWatch コンソールを介したロググループへのアクセスの詳細については、『Amazon CloudWatch ユーザーガイド（Amazon CloudWatch User Guide）』でモニターリングシステム、アプリケーション、およびカスタムログファイルについて参照してください。

ロードバランサのヘルスチェックの失敗

ロードバランサのヘルスチェックには、プロトコル、ping ポート、ping パス、応答タイムアウト、ヘルスチェック間隔などの情報が含まれます。ヘルスチェック間隔内に 200 応答コードを返す場合、インスタンスは正常と見なされます。

一部またはすべてのインスタンスの現在の状態が OutOfService であり、説明フィールドに「インスタンスがヘルスチェックの異常しきい値の数以上連続して失敗しました（Instance has failed at least the Unhealthy Threshold number of health checks consecutively）」というメッセージが表示された場合、インスタンスはロードバランサのヘルスチェックに失敗しています。

Management Center 構成の正常性プローブ NAT ルールを確認する必要があります。詳細については、『Troubleshoot a Classic Load Balancer: Health checks』を参照してください。

トラフィックの問題

threat defense virtual インスタンスのトラフィックの問題をトラブルシューティングするには、ロードバランサルール、NAT ルール、および threat defense virtual インスタンスで設定されているスタティックルートを確認する必要があります。

セキュリティグループのルールなど、展開テンプレートで提供される AWS 仮想ネットワーク/サブネット/ゲートウェイの詳細も確認する必要があります。たとえば、「EC2 インスタンスのトラブルシューティング（Troubleshooting EC2 instances）」https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-troubleshoot.htmlなど、AWS のドキュメントを参照することもできます。

Management Center への接続に失敗

管理接続が中断された場合は、設定とログイン情報を確認する必要があります。『Cisco Secure Firewall Management Center Configuration Guide』の「Requirements and Prerequisites for Device Management」を参照してください。

デバイスが FMC への登録に失敗 Management Center

デバイスが Management Center に登録できない場合は、Management Center 構成に障害があるか到達不能であるか、または Management Center に新しいデバイスを収容するキャパシティがあるかどうかを判断する必要があります。『Cisco Secure Firewall Management Center Configuration Guide』の「Add a Device to the Management Center」を参照してください。

Threat Defense Virtual に SSH 接続できない

threat defense virtual に SSH 接続できない場合は、テンプレートを介して複雑なパスワードが threat defense virtual に渡されたかどうかを確認します。

デュアルアームプロキシ設定のトラブルシューティング

threat defense virtual の EC2 インスタンスが起動に失敗するか、起動と終了が連続的に繰り返される。

アクティビティ履歴を確認する必要があります。[自動スケーリンググループ（Autoscale Group）] > [自動スケーリンググループ（Autoscale Group）] > [アクティビティ（Activity）] > [アクティビティ履歴（Activity History）] に移動して、デバッグを開始してください。

考えられる原因としては、AMI の欠落や Lambda 関数実行時のエラーなどがあります。

• AMI が AWSアカウントに存在することを確認します。

• [接続（Connection）]、[設定（Configuration）]、および [ライセンス（Licensing）] を確認します。

• threat defense virtual の EC2 インスタンスに関連付けられているタグを確認して、デバイスの接続ステータス、設定ステータス、ライセンスステータス、およびその他のステータスを取得します。

• CloudWatch ログ を確認します。

  • 個々の Lambda 関数のログは、CloudWatch ログで表示できます。

  • デバイスの接続または設定に問題がある場合は、Lambda 関数の CloudWatch ログに進み、根本原因を把握します。

  • Lambda 関数のロググループを確認します。

AWS クラウド側のデバッグ：トラフィックが通過しない。

• すべての AWS サブネットのルーティングテーブルがトポロジ図で指定されているとおりであることを確認します。出力（East-West）トラフィックルートがデバイスに存在することを確認します。

• すべてのデバイスインターフェイスに関連付けられている AWS セキュリティグループで、予想される IP アドレス範囲が許可されていることを確認します。