WHITE PAPER

Amazon Web Services（AWS）

リファレンスアーキテクチャ
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

目次

概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

責任共有モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4

AWS の主な概念 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

リージョンとアベイラビリティゾーン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5

VPC（仮想プライベートクラウド）. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

サブネット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

ネットワーク ACL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

セキュリティグループ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

ルートテーブル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

インターネットゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

NAT ゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

Elastic ネットワークインタフェース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

AWS VPN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

仮想プライベートゲートウェイ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

カスタマーゲートウェイ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

Transit gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .10

AWS における FortiGate VM 次世代ファイアウォール . . . . . . . . . . . . . . . . . . .11

FortiManager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

FortiGuard セキュリティサービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

2
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

目次

サポートされるインスタンスタイプ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12

AWS での FortiGate の起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .13

FortiGate の初回起動でのブートストラップ. . . . . . . . . . . . . . . . . . . . . . . . . .13

フォーティネット ファブリックコネクタ. . . . . . . . . . . . . . . . . . . . . . . . . . . .14

ダイナミックアドレスオブジェクト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .14

例：動的アドレスオブジェクトを使用した
ファイアウォールポリシーの作成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

単一 FortiGate-VM の AWS 上での展開 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .15

インバウンドトラフィックのインスペクション（垂直方向）. . . . . . . . . . .15

アウトバウンドトラフィックのインスペクション（垂直方向）. . . . . . . . .16

トラフィックインスペクション（水平方向）. . . . . . . . . . . . . . . . . . . . . . . .17

FortiGate が AWS で実現する高可用性と耐障害性 . . . . . . . . . . . . . . . . . . . . . .17

オンプレミスネットワークへのアウトバウンド接続における耐障害性. . . . .18

ユニキャスト HA を使ったアクティブ / パッシブ構成 . . . . . . . . . . . . . . . . . .18

アクティブ / パッシブ環境の耐障害性 - 2 つのアベイラビリティゾーン. . . .19

アウトバウンドトラフィックの耐障害性 -
アクティブ / アクティブフェイルオーバー. . . . . . . . . . . . . . . . . . . . . . . . . . .21

設計パターン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

FortiGate オートスケーリングによる柔軟なロードバランシングの
サンドイッチ構成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .23

Transit VPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24

耐障害性 FortiGate 構成と AWS Transit Gateway の統合 . . . . . . . . . . . . . . . .25

まとめ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27

3
概要
パブリッククラウド（クラウド）は、広く普及しているクラウドコンピューティングモデルです。クラウドサービスプロバイダーは、インフラス
トラクチャやストレージ、サーバーといったリソースをインターネット経由で企業に提供します。共有される物理ハードウェアは、サードパーティ
のプロバイダー側が所有して運用を担い、企業は必要に応じて使用します。このようなマルチテナント環境は、インフラストラクチャのコストを
複数ユーザー間で分散できます。世界中の企業はクラウドの導入によって次のようなメリットを得ています。

コスト効率：クラウドインフラストラクチャを使用することで機器の購入と保守にかける多大なコストが不要になり、CapEx（設備投資）を大幅
に削減できます。ハードウェア、設備、ユーティリティに要するリソースと時間を節約でき、ビジネス成長のために大規模データセンターを保持
する必要がなくなります。

拡張性：帯域幅が増大し変動する企業にとってクラウドの使用は理想的なソリューションです。需要の増大に応じてクラウドキャパシティを容易
に拡張できるため、物理インフラストラクチャに投資する必要はありません。このような俊敏性は、重要な競争力の 1 つです。

災害復旧：データ損失は、どの組織にとっても重要な課題です。ラップトップや PC といった機器が破損しても、顧客データをクラウドに格納し
ておけば、常にデータを取り出すことができます。クラウドベースのサービスは、
自然災害や停電などの緊急時の迅速なデータ復旧を可能にします。

俊敏性の向上：今日、企業の生産性を向上するには動的な態勢が必要です。プロセス、ツール、テクノロジー、ポリシーを常に進化させ、改善し
なければなりません。企業の俊敏性は、迅速な意思決定、優先順位付け、顧客満足の向上につながります。クラウドの活用によって、より良いデ
リバリ、コラボレーション、新たなビジネスイニシアティブの展開を加速することができます。

責任共有モデル

クラウドプロバイダーはクラウドのセキュリティを管理しますが、クラウドでのセキュリティ対策はユーザーが責任を負います。コンテンツとア
プリケーションの保護に使用するセキュリティ機能は、ユーザーが管理します。

ユーザーのアプリケーション、コンテンツ
データのセキュリティ
アプリケーション
セキュアな接続

可視化と制御

ユーザー：
ネットワーク インベントリと
クラウド「内」の
セキュリティ 構成
セキュリティを管理

／ データの
アクセス制御
セキュリティ

クラウドプロバイダー：
クラウド基盤 クラウド「の」
サービス セキュリティを管理
データベース ストレージ ネットワーク コンピュート

図 1：責任共有モデル

4
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

クラウドプロバイダーは、ホストオペレーティングシステムや仮想化レイヤーからサービスを
運用する設備の物理的なセキュリティに至るまで、あらゆるコンポーネントの運用、管理、制 専門用語の解説
御を担います。その一方で、データの所有権と制御はユーザーにあり、ユーザーは、環境内の
n アベイラビリティゾーン：1 つま
基本的なセキュリティの設定と導入の責任を負います。
たは複数のデータセンター。電源、
Amazon Web Services（AWS）は、企業がアプリケーションの実行に使用するクラウドコン ネットワーキング、接続性が冗長
ピューティングサービスを提供する最大手のプロバイダーの 1 つです。フォーティネット 化され、分散した設備に設置され
FortiGate NGFW（次世代ファイアウォール）は、AWS 上での使用において、優れた自動化機 る。
能によって企業が高度なサイバー攻撃に対抗できるよう支援します。
n AWS リージョン：複数のアベイラ
次のセクションでは、本設計ガイドに関連する AWS の主な構成要素を説明します。 ビリティゾーンが設置されている
物理的なロケーション
AWS の主な概念
本書の主な目的は、AWS のセキュアなアーキテクチャの設計原則とガイドラインを説明するこ
とにあるため、AWS の概念と主な AWS サービスに関する知識は、本書で解説する設計トピッ
クを理解する上での前提条件となります。

リージョンとアベイラビリティゾーン

AWS クラウドインフラストラクチャは、AWS リージョンとアベイラビリティゾーンから構成さ

れています。AWS リージョンは、物理的なロケーションで、世界中に分散され、リージョン内
には複数のアベイラビリティゾーンが設置されています。アベイラビリティゾーンは、1 つまた
は複数のデータセンターから構成されます。電源、ネットワーキング、接続性が冗長化されて
おり、それぞれは分散した設備に配置されます。アベイラビリティゾーンは、本番稼働のアプ
リケーションやデータベースの運用に対応します。アプリケーションやデータベースは、単一
のデータセンターでは提供できない優れた可用性、フォルトトレランス、拡張性を得られます。

Amazon リージョンは、それぞれが完全に分離されています。これにより、最高レベルの対障害
性と安定性が実現されます。アベイラビリティゾーンは独立していますが、同じリージョン内
のアベイラビリティゾーン間は低レイテンシのリンクで相互接続されています。AWS では、イン
スタンスやデータの配置に非常に柔軟に対応します。各 AWS リージョン内の複数のアベイラビリティゾーンのみならず、複数の地理的に離れた
場所への配置や格納が可能です。アベイラビリティゾーンは、それぞれが独立した障害ゾーンとして設計され、標準的な都市部の、物理的に隔離
された、冠水リスクの低い場所に設置されています。2019 年 3 月時点で、AWS クラウドは世界中で 20 のリージョン内に 61 のアベイラビリティ
ゾーンを展開しており、さらに 12 のアベイラビリティゾーンと 4 つのリージョンの追加を計画しています 1。

AWS Cloud

Region : us-west-2（オレゴン） Region : eu-west-1（アイルランド）

Availability Availability
Zone Zone
ク

ク
ン

ン
リ

リ
シ

シ
ン

ン
テ

テ
イ

イ
レ

レ
低

Availability Availability Availability Availability

Zone Zone Zone Zone

図 2：AWS リージョンとアベイラビリティゾーン

「AWS Global Infrastructure」AWS、2019 年 3 月：https://aws.amazon.com/about-aws/global-infrastructure/

1

5
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

アベイラビリティゾーンの耐障害性と分離機能を活用するには、アプリケーションとセキュリ
ティサービスを分散し、複数のアベイラビリティゾーンで保護する必要があります。 技術的なヒント 1

VPC（仮想プライベートクラウド） Amazon VPC では、プライマリ CIDR

Amazon VPC（仮想プライベートクラウド）を使用して、ユーザーは定義済みの仮想ネットワー の変更はサポートされていません。
クで AWS リソースを使用できます。この仮想ネットワークは、顧客が独自のデータセンター
を運用できるという点で従来のネットワークに非常に似ており、さらに、拡張性に優れた AWS
インフラストラクチャを使用するメリットもあります。Amazon VPC では、AWS クラウドの 全体的なネットワークマップを検討し
論理的に隔離されたセクションをプロビジョニングすることが可能で、このセクションでは、 てから、VPC を作成し、CIDR 定義し
定義した仮想ネットワーク内で AWS リソースを起動できます。IP アドレス範囲の選択、サブ てください。CIDR を定義する方法は、
ネットの作成、ルートテーブル、ネットワークゲートウェイの設定など、仮想ネットワーク環 物理的なデータセンターで CIDR を割
境を完全に制御できます。VPC ネットワークは、IPv4 と IPv6 両方のアドレスをサポートします。
り当てる際と同様です。これにより、
ほとんどの AWS アカウントでは、デフォルトの VPC が提供され、各アベイラビリティゾーン AWS アカウントにインスタンスを実
のデフォルトサブネットが付属します。Amazon VPC に関する知識を持たないユーザーでも、 装した後で IP アドレスの重複が発覚
デフォルトの VPC でインスタンスを起動できます。また、AWS では、ユーザーはデフォルト する、といった問題を回避できます。
の VPC 以外に専用の VPC も作成できます。これにより、VPC CIDR（Classless InterDomain
Routing）、サブネット、ネットワーク構成の柔軟なカスタマイズが可能になります。

物理的なデータセンターのネットワークでは CIDR ブロックの拡張作業が煩雑になることに対

して、VPC では、VPC の作成時に CIDR ブロックを定義し、後でセカンダリ CIDR を追加す
ることで範囲を拡張できるため、クラウドの動的なメリットを活用できます。VPC の作成時の
CIDR の定義と割り当てはユーザーの任意ですが、RFC 1918「プライベート網のアドレス割り
当て」に従って CIDR を使用することを強く推奨します。

デフォルトでは、VPC 内のすべてのインスタンスは、同じ VPC 内の他のインスタンスへのルー

トを持っています。ただし、定義された CIDR がパブリックルーティング可能な IP アドレス範
囲であったとしても、インターネット接続はデフォルトでは有効になりません。インターネッ
ト接続を確立するには、インターネットゲートウェイを作成し、VPC にアタッチする必要があ
ります。これにより、インターネット接続を必要インスタンスにパブリック IP アドレスを割り当てることができます。Elastic IP アドレスも、イン
スタンスへの割り当てが可能です。VPC とオンプレミス間の接続を必要とする場合には、VPN ゲートウェイデバイスを作成し、VPC にアタッチ
します。これにより、VPN ゲートウェイとオンプレミスのカスタマーゲートウェイ間に IPsec VPN 接続を確立できるようになります。

サブネット

VPC の作成が完了したのち、各アベイラビリティゾーンに 1 つまたは複数のサブネットを追加できます。サブネットの作成では、VPC CIDR ブロッ

クのサブネットとなる CIDR ブロックを指定する必要があります。サブネットは 1 つのアベイラビリティゾーン内に配置し、複数のゾーンにまた
がることはできません。サブネットのトラフィックがインターネットゲートウェイにルーティングされると、
そのサブネットはパブリックサブネッ
トとして認識されます。サブネットがインターネットゲートウェイにルーティングされない場合、サブネットはプライベートサブネットとして認
識されます。

サブネットの CIDR ブロックは、VPC の CIDR ブロックと同じ場合（VPC 内に 1 つのサブネット）と、VPC の CIDR ブロックのサブネットの場合

（複数サブネット）があります。ブロックサイズは、/28 ネットマスクから /16 ネットマスクの間であり、VPC 内でサブネット CIDR は重複できま
せん。たとえば、VPC CIDR ブロックが 10.0.0.0/24 の場合、/25 CIDR サブネットを VPC 内に 2 つ作成できます。各サブネット CIDR ブロックで
は、最初の 4 つの IP アドレスと最後の IP アドレスはユーザーが使用できない点と、インスタンスへの割り当てはできない点に注意してください。
たとえば、サブネット CIDR が 10.0.0.0/24 の場合、次に示す 5 つのアドレスは予約済みです。

n 10.0.0.0: ネットワークアドレス

n 10.0.0.1: AWS が VPC ルーター用に予約

n 10.0.0.2: AWS が DNS サーバー用に予約（VPC CIDR ＋ 2 のベース）AWS は、各サブネット範囲＋ 2 のベースも予約

n 10.0.0.3: AWS の将来的な使用のために予約

n 10.0.0.255: ネットワークブロードキャストアドレス

6
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

ネットワーク ACL
ネットワーク ACL（アクセス制御リスト）は、VPC のオプションとして使用できるセキュリティ ネットワーク ACL の使用に必要な知識
レイヤーで、L4 ステートレスファイアウォールとして 1 つまたは複数のサブネットのインバウン
n VPC に は、 す べ て デ フ ォ ル ト の
ド / アウトバウンドトラフィックを制御します。VPC ではサブネット間ルーティングをデフォ
NACL が付属します。この NACL は、
ルトで使用できるため、ネットワーク ACL を使用することで、サブネットが VPC 内の他のサブ
インバウンドとアウトバウンドの
ネットにアクセスする操作を禁止できます。
IPv4 トラフィックをすべてサポー
トします。
セキュリティグループ
セキュリティグループは、インスタンスの仮想レイヤー 4 ファイアウォールとして機能し、イン n ネットワーク ACL には、番号付きの
バウンド / アウトバウンドトラフィックを制御します。セキュリティグループは、インスタンス ルールリストが指定されています。
のネットワークインタフェースで適用されます。したがって、サブネット内のインスタンスを、 番号の小さいルールから順に評価を
それぞれ別のセキュリティグループに割り当てることが可能です。AWS では、デフォルトで、ネッ 行い、ネットワーク ACL に関連する
トワークインタフェースに最大 5 つのセキュリティグループを割り当てることができます。 サブネットのトラフィック送受信を許

ネットワーク ACL とは異なり、セキュリティグループはステートフルで、拒否アクションはサ 可するかどうかを判定します。

ポートしません。 n ネットワーク ACL には、独立した
セキュリティグループはレイヤー 4 ファイアウォールとしてのみ機能し、パケットを調査する インバウンド / アウトバウンドルー
アプリケーションレイヤーの可視化機能は備えていません。したがって、NGFW をセキュリティ ルがあり、個々にトラフィックの
レイヤーに追加し、高度なサイバー攻撃の検出と防御を行う必要があります。 許可 / 拒否を行います。

n ネットワーク ACL はステートレス

ルートテーブル
です。許可されたインバウンドト
VPC には、暗黙的なルーターを備えており、VPC 内の各サブネットをルートテーブルに関連
ラフィックへの応答は、アウトバ
付ける必要があります。ルートテーブルでは、サブネットから送信されるアウトバウンドトラ
ウンドトラフィックのルールの適
フィックに対して、許可するルートが指定されています。
用対象となります。
メインルートテーブル：VPC を作成すると、メインルートテーブルが自動生成されます。メイン
ルートテーブルは、他のルートテーブルに明示的に関連付けられていないすべてのサブネット
のルーティングを制御します。メインルートテーブル内のルートは、削除、追加、変更が可能
です。メインルートテーブルは削除できません。 セキュリティグループの主な特徴

カスタムルートテーブル：メインルートテーブル以外に、ユーザーが追加できるルートテーブ n「許可」ルールの適用は可能ですが、
ルです。サブネットとカスタムルートテーブルを関連付けることで、サブネットルートのアウ 「拒否」ルールは適用できません。
トバウンドトラフィックを個別に明示的に制御できます。
n インバウンドトラフィックとアウ
すべての Amazon VPC ルートテーブルには、デフォルトでローカルルートエントリーが付属し トバウンドトラフィックには別の
ますが、このエントリーを詳細なルートプレフィックスで上書きすることはできません。この ルールを指定できます。
ルートエントリーにより、すべてのインスタンスに、VPC 内の他のインスタンスへのルートが
n「許可」ルールは、すべてセキュリ
提供されます。ただし、詳細なプレフィックスルールがないため、サブネット内トラフィック
ティグループに明示的に追加する
とサブネット間トラフィックをネットワークセキュリティアプライアンスへとネイティブステ
必要があります。追加しない場合、
アリングすることはできません。
デフォルトの AWS アクションが適
図 3 は、VPC のメインルートテーブルと、プライベートサブネットに関連付けられているカス 用され、すべてのトラフィックを
タムルートテーブルを示しています。いずれのルートテーブルにもローカルルートエントリー ブロックします。
があり、削除できません。
n セキュリティグループはステート
インターネット フルです。インスタンスからリク
エストが送信されると、関連する
AWS Cloud

セキュリティグループのインバ
インターネットゲートウェイ
ウンドルールに関係なく、リクエ
パブリックサブネット ルーター ストに対する応答トラフィックは
ルートテーブル - パブリックサブネット
許可されます（逆も同様）。
宛先 ターゲット

n 別のホストからインスタンスへの
NAT ゲートウェイ

Web サーバー インバウンドトラフィックを許可

プライベートサブネット
するには、セキュリティグループ
ルートテーブル - プライベートサブネット のインバウンドルールを更新する
必要があります。これは、AWS は、
宛先 ターゲット

デフォルトではインバウンドルー
ルが作成されないためです。
データベースサーバー

Availability Zone 1

図 3：Amazon VPC ネットワークの基礎

7
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

インターネットゲートウェイ

VPC ルーティングの設計上、インターネットゲートウェイがアタッチされていない状態では、 ENI の特徴

VPC、プライベートサブネット、パブリックサブネット内のインスタンスによるインターネッ n プライマリプライベート
トを介した通信はできません。インターネットゲートウェイは、パブリック IPv4 アドレスが割 IPv4 アドレス
り当てられたインスタンスのネットワークアドレス変換を行います。
n 1 つまたは複数のセカンダリ
インターネットゲートウェイを作成して VPC にアタッチした後、インターネット行きのトラ プライベート IPv4 アドレス
フィックからインターネットゲートウェイへとダイレクトするルートを、パブリックサブネッ
トと関連付けられたルートテーブルに追加する必要があります（図 3）。また、インスタンスがイン n 1 つのプライベート IPv4 アドレス
ターネットを介して通信できるようにするには、パブリック IP アドレス、またはパブリック IP に対して 1 つの Elastic IP アドレス
アドレスに関連付けられた Elastic IP アドレスの割り当てが必要です。インスタンスが識別でき （IPv4）
るのはプライベート IP アドレスのみのため、インターネットゲートウェイは、インスタンスの
n 1 つのパブリック IPv4 アドレス
ために論理的な 1 対 1 の NAT（ネットワークアドレス変換）を行う必要もあります。これにより、
リターントラフィックの宛先が、インスタンスのパブリック IP アドレスになります。 n 1 つまたは複数のセキュリティ
グループ

NAT ゲートウェイ n MAC アドレス

NAT ゲートウェイは、プライベートサブネット内のインスタンスによるインターネット接続を
n 送信元 / 宛先チェックフラグ
可能にするマネージド AWS サービスです。また、一方的なインターネットトラフィックがプラ
イベートインスタンスに到達できないようにします。インターネットに送信されるトラフィッ
クの送信元 IP アドレスは、NAT ゲートウェイのパブリック IP アドレスに置換されます。同様に、
インスタンスへの応答トラフィックのアドレスは、NAT ゲートウェイによってインスタンスの
プライベート IP アドレスに戻されます。

NAT の作成後、プライベートサブネットに関連付けられたルートテーブルを更新し、インター
ネット行きのトラフィックを NAT ゲートウェイへとポイントする必要があります。これにより、
プライベートサブネット内のインスタンスはインターネットと通信できるようになります。た
とえば、プライベートサブネットに関連付けられたルートテーブル（図 3）には、NAT ゲートウェ
イをターゲットとするデフォルトルートのルートエントリーが含まれています。このルートに
より、インターネット行きのトラフィックはすべて NAT ゲートウェイ経由でルーティングされ
ます。

AWS では、NAT インスタンスと NAT ゲートウェイという 2 つのタイプの NAT デバイスが提供

されています。ただし、NAT ゲートウェイは AWS で管理されており、管理作業の手間がかから
ないという点で、NAT ゲートウェイを推奨します。

Elastic ネットワークインタフェース

ENI（Elastic ネットワークインタフェース）とは、VPC（仮想ネットワークカード）内の論理
的なネットワーキングコンポーネントで、仮想のネットワークカードとなります。ユーザーは、
アカウントでネットワークインタフェースを作成および構成し、それを VPC 内のインスタンス
にアタッチできます。ENI は、複数の属性を持っています。

インスタンスを起動すると、1 つ以上のネットワークインタフェースが提供されます。このプラ
イマリインタフェースは、切断できません。ENI と ENI が接続されているインタフェースが同
じアベイラビリティゾーン内にある限り、
これ以外の ENI をすべてインスタンスからデタッチし、
別のインスタンスにアタッチすることが可能です。

送信元 / 宛先チェック：送信元 / 宛先チェック属性は、インスタンスでの送信元 / 宛先チェック

の有効性を制御します（デフォルトは有効）。インスタンスでこの属性を無効にすると、そのイン
スタンス宛て以外のネットワークトラフィックを処理できるようになります。たとえば、ファ
イアウォールサービスを実行するインスタンスでは、この値を無効にしてください。図 5 では、
FortiGate ファイアウォールの 2 番目の ENI（プライベートインタフェース）の送信元 / 宛先チェッ
クは無効になっています。これにより、インターネット行きのトラフィックは、ファイアウォー
ルを経由します。

8
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

インターネット
技術的なヒント 2

仮想プライベートゲートウェイの作成

パブリックサブネット
時に ASN を指定しない場合、AWS は
デフォルトで ASN 64512 を割り当て
ます。

ルートテーブル - プライベートサブネット

宛先 ターゲット

サーバー

プライベートサブネット

図 4：送信元 / 宛先チェックを有効にした場合のトラフィック転送

インターネット

パブリックサブネット

ルートテーブル - プライベートサブネット

宛先 ターゲット

サーバー

プライベートサブネット

図 5：送信元 / 宛先チェックを無効にした場合のトラフィック転送

AWS VPN

AWS VPN（Site-to-Site） は、 ユ ー ザ ー の デ ー タ セ ン タ ー や 支 社 の ネ ッ ト ワ ー ク を、IPsec

トンネルを介して AWS クラウドへと拡張し、仮想プライベートゲートウェイと AWS Transit
Gateway の両方への接続をサポートします。ユーザーは、IPsec トンネルを介した BGP（Border
Gateway Protocol）をオプションで実行できます。

仮想プライベートゲートウェイ

仮想プライベートゲートウェイとは、Site-to-Site VPN 接続の AWS 側にある VPN コンセントレー

タです。仮想プライベートゲートウェイを VPC にアタッチし、VPC 内の VPN 終端点として機
能させることができます。仮想プライベートゲートウェイの作成時には、ASN（自律システム
番号）の割り当てが可能です。ただし、作成後の変更はできません。

仮想プライベートゲートウェイを作成して VPC にアタッチし、VPN 接続を確立すると、仮想

プライベートゲートウェイはユーザーのオンプレミスデータセンターへのゲートウェイとして
機能します。リモートルーターのターゲットとしてルートテーブルに静的に追加する方法と、

9
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

BGP を介してリモートルートを学習した後、ルートテーブルに自動追加する方法があります。
たとえば、図 6 のルートテーブルの場合、10.17.0.0/16 へのルートは動的に学習し、追加されます。 技術的なヒント 3

プライベートゲートウェイで Site-to-Site VPN 接続を複数作成することは可能ですが、ネットワー

クパフォーマンスが低下する恐れがあります。これは、帯域幅に制限があることと、多くの企 仮想プライベートゲートウェイがサ
業で必要とされる、数ギガ規模のスループットの要件に対応できる動的な拡張性がないことが ポートできるネットワークスループッ
理由です。 ト は、 最 大 1.25 Gbps で す。 ま た、
ECMP（等価コストマルチパス）ルー

カスタマーゲートウェイ ティングはサポートしません。

カスタマーゲートウェイとは、ユーザーのデータセンターで稼働する物理アプライアンスまた
はソフトウェアアプリケーションを指します。AWS では、VPN 接続を確立する前に、AWS ア
技術的なヒント 4
カウントでカスタマーゲートウェイオブジェクトを作成する必要があります。カスタマーゲー
トウェイでは、VPN 接続の作成に使用する、パブリックなルーティングが可能な IP アドレスが
必要です。カスタマーゲートウェイデバイスの作成には、ネットワークに割り当てられている IPsec トンネルを確立するには、ユー

既存の ASN を使用できます。または、64,512 ∼ 65,534 の範囲のプライベート ASN を使用する ザーのゲートウェイでトンネルを初期

ことも可能です。作成したカスタマーゲートウェイでは、VPN 接続の確立に必要な構成を行い 化する必要があります。

ます。フォーティネットは AWS チームと連携し、AWS から直接ダウンロード可能な構成テン
プレートを提供しています。

パブリックサブネット

IPSecトンネル

ルートテーブル - プライベートサブネット

VPN ゲートウェイ 宛先 ターゲット アクティブ 伝搬

カスタマーゲートウェイ

プライベートサブネット

図 6：AWS Site-to-Site VPN 接続

図 6 で示すように、Site-to-Site VPN 接続にはトンネルが 2 つあり、それぞれが、仮想プライベー

トゲートウェイの一意のパブリック IP アドレスを使用しています。両方のトンネルで冗長化構
成を行うことが重要です。これにより、いずれかのトンネルが使用不能になった場合（システ
ムダウンや保守など）、ネットワークトラフィックは、その Site-to-Site VPN 接続で使用可能なトン
ネルへと自動的にルーティングされます。

Transit gateway

最近まで、VPC の相互接続を行うための選択肢には制限がありました。ポイント間ピアリング
を作成して各 VPC でネットワーキングを管理することは可能ですが、非常に複雑になってしま
います。また、共有 VPC において、各 VPC からサードパーティルーター / ファイアウォールア
プライアンスへの IPsec トンネルを作成することも可能です。このハブ & スポークトポロジを、
Transit VPC を呼びます。

10
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

VPC 間接続とセキュリティ要件への対応には、Fortinet Transit VPC のような Transit VPC の導入

を推奨します。AWS 仮想プライベートゲートウェイは、各 VPC スポークに導入され、VPN 接 Transit Gateway の主な特性
続を終端しますが、帯域幅に大きな制限があるためネットワークパフォーマンスが低下します。
n VPC ま た は VPN 接 続 を Transit
AWS Transit Gateway では、大規模接続に対応した新しい分散サービスの使用によりこの問題の Gateway にアタッチできます。
解決を図っています。ECMP（等価コストマルチパス）ルーティングをサポートするため、トラ
n Transit Gateway にはデフォルトの
フィックは、同じ IP プレフィックスを伝搬する複数の VPN 接続に対して均等に配分されます。
ルートテーブルがあり、オプション
Transit Gateway は AWS アカウント全体で機能しますが、アタッチできるのは、同じリージョン でルートテーブルを追加できます。
内の VPC のみです。
n デ フ ォ ル ト で は、Transit Gateway
にアタッチされている VPC および
AWS Cloud
CIDR
TGW デフォルトルートテーブル
アタッチメント
VPN 接続は、デフォルトの Transit
パブリックサブネット
Gateway ルートテーブルに関連付
けられています。
プライベートサブネット

Availability Zone 1
n そ れ ぞ れ の Transit Gateway は、1
つのルートテーブルに割り当てら
プライベートサブネット れています。
Availability Zone 2

Transit GW
アタッチメント
プライベートサブネット
n 各ルートテーブルに関連付けるア
アカウント 1 タッチの数は、ゼロから複数です。

n VPC 内のアベイラビリティゾーン
AWS Cloud

宛先 ターゲット アクティブ 伝搬
に割り当て可能な Transit Gateway
ルートテーブル -
プライベートサブネット
のアタッチは、1 つのみです。
プライベートサブネット

Availability Zone 1
n VPC ま た は VPN 接 続 は、Transit
アカウント 2 Gateway の ル ー ト テ ー ブ ル へ と
ルートを動的に伝搬します。
図 7：AWS Transit Gateway のアーキテクチャ

図 7 の Transit Gateway は、2 つの異なる AWS アカウントにある 2 つの VPC にアタッチされ

ています。すべてのアタッチメントは、Transit Gateway のデフォルトルートテーブルと関連
付けられています。2 番目のアカウントで使用する VPC のルートテーブルは更新され、Transit
Gateway へのルートが含まれています。アカウント 1 では、タイプ VPN の Transit Gateway ア
タッチメントオブジェクトが 1 つ作成されており、ハブ VPC にある FortiGate NGFW に Transit
Gateway を接続します。また、各 AZ に 1 つずつ、合計 2 つの Transit Gateway アタッチメント
が作成され、アカウント 1 のスポーク VPC と Transit Gateway 間接続の可用性を高めます。

AWS における FortiGate VM 次世代ファイアウォール

ステートフルインスペクションと包括的なセキュリティ機能を融合した FortiGate NGFW テクノ
ロジーは、コンテンツとネットワークを完全に保護します。このソリューションは、AWS 上の
環境で使用できます。

トップクラスの脅威データベース、脆弱性管理、フローベースのインスペクションといった高
度な機能に加えて、アプリケーション制御、ウイルス対策、IPS、Web フィルター、VPN をは
じめとする機能が連携し、最新の複雑なセキュリティ脅威を特定および軽減します。

強力なセキュリティを提供する FortiOS オペレーティングシステムは、マルウェアの検査と識別

を考慮した専用の設計と、ダイレクト SR-IOV（シングルルート I/O 仮想化）のサポートによって、
高速かつ安定したパフォーマンスを実現します。

11
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

FortiManager

FortiManager 仮想セキュリティ管理アプライアンスは、FortiManager ハードウェアアプライアン

スと同等の強力なネットワークセキュリティ管理機能を AWS でも提供します。シンプルな積み
上げ式のライセンス体系によって、ネットワーク環境に合わせて容易に拡張することができま
す。ハードウェアと仮想アプライアンスを組み合わせて導入してその両者を連携させて運用で
き、共通の FortiManager プラットフォームから一元管理することも可能です。

FortiGuard セキュリティサービス
AWS における FortiGate-VM の
FortiGuard Labs は、脅威の最新状況に関するリアルタイムの情報を駆使して、フォーティネッ
メリット
トのさまざまなソリューション向けに包括的なセキュリティアップデートを提供します。セキュ
リティに対する脅威の研究者、エンジニア、犯罪科学のスペシャリストで構成されるチームが、 n FortiGuard Labs セキュリティサー
脅威の監視を手掛ける世界有数の機関やネットワーク / セキュリティ分野を代表するベンダー、 ビスによって継続的に提供される
世界各国の捜査機関と協力して、優れたサービスをお届けします。 脅威インテリジェンスを使用して、
既知のエクスプロイトとマルウェ
アから保護
ライセンス

FortiGate-VM for AWS は、オンデマンドの PAYG（Pay-As-You-Go）モデルや BYOL（Bring-Your- n クラウドアプリケーションを含む

Own-License）モデルにより、さまざまなプライベート / パブリッククラウド環境を幅広い導入 数千規模のアプリケーションを特
方法でサポートします。 定し、ネットワークトラフィック
を詳細に検証
BYOL は、販売代理店やディストリビューターから購入する年次ベースの永久ライセンスです。
プラットフォームにかかわらず、プライベート / パブリッククラウドすべてに同じ注文ポリシー n 動的分析を使用して未知の攻撃を
が適用されます。顧客は、インスタンスへの初回アクセス時にライセンスを有効にすることで、 検知し、自動減災機能によって標
各種機能を使用できるようになります。このモデルは、既存のプライベートクラウド環境をパ 的型攻撃を阻止
ブリッククラウド環境へと移行するユースケースに最適です。既存のライセンスを使用する場
n AWS GuardDuty 脅 威 検 知 サ ー ビ
合には、追加コストのみで AWS インスタンスを使用できます。
スがインシデント対応を自動化し、
PAYG は、非常に柔軟なオプションです。新しい導入環境と必要に応じて成長する環境のいずれ 脅威インテリジェンスを提供
にも適しています。幅広いインスタンスタイプがサポートされるため、あらゆるユースケース
n Fortinet ファブリックコネクタを介
にも対応できます。このライセンスでは、UTM バンドルで FortiOS が提供されます。PAYG を
して AWS アカウントとネイティブ
購入するには、AWS マーケットプレースでサブスクリプションを購入します。
に統合し、顧客のマルチクラウド
環境全体にセキュリティポリシー
サポートされるインスタンスタイプ
を動的に適用
FortiGate-VM は AWS 上で次のインスタンスタイプをサポートします。

インスタンスタイプ vCPU NIC の最大数（AWS で有効）

表 1：FortiGate-VM が AWS 上でサポートするインスタンスタイプ

アクティブ / パッシブ HA（高可用性）モードで実行する場合、FortiGate-VM インスタンス 1 つ

あたり 4 つのネットワークインタフェースが必要になります。

12
 WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

インスタンスタイプは、C4 も使用できますが、AWS の高度なネットワーキングを活用してネットワークスループットを最大限に高めるには、C5

または C5n の使用を強く推奨します。

次の表は、通常購入可能な BYOL モデルです。

v シリーズは、デフォルトでは VDOM をサポートしないことにご注意ください。v モデルで VDOM を実行するには、VDOM ライセンスの追加購

入が必要です。

モデル名 vCPU – 最小 vCPU - 最大

表 2：FortiGate-VM モデル（BYOL）

FortiOS 6.0.2 以降の FortiGate-VM ライセンスでは、FortiGate は vCPU の数に制限されなくなり、ライセンスのサポート数を上回る vCPU を使用

する AWS 内の VM インスタンスで実行できるようになりました。ライセンスで指定される vCPU 数による制限がなくなったことで、仮想インスタン
スの vCPU 数にかかわらず FortiGate を実行できます。ただし、トラフィックを処理するのはライセンスで許可される vCPU のみであり、それ以
外の vCPU は使用されません。

AWS での FortiGate の起動

FortiGate の最も基本的な導入環境は、1 つの FortiGate と、パブリックインタフェースとプライベートインタフェースが 1 つずつ、合計 2 つのネッ

トワークインタフェースで構成されます。

パブリックサブネット プライベートサブネット

図 8：FortiGate-VM on AWS

FortiGate の初回起動でのブートストラップ

AWS ユーザーデータとは、一連のコマンド / データセットであり、起動時に Amazon EC2（Elastic Compute Cloud）インスタンスにインジェク

トできます。このデータを使用するかどうかは、EC2 のゲスト OS に応じて決まります。AWS における FortiGate-VM はこの機能をサポートする
ことで、ゼロデイ構成など、FortiGate インスタンスに必要なブートストラップを自動化します。

ユーザーは、Amazon S3 バケットを作成して BYOL インスタンスのライセンスファイルをアップロードする操作や、ゼロデイ構成ファイルを S3

バケットにアップロードする操作を実行できます。起動時に、S3 バケットへのアクセスを許可する IAM（アイデンティティとアクセス管理）ロー
ルを、FortiGate インスタンスにアタッチする必要があります。FortiGate インスタンスの起動時、ブートストラップのために、次のようなユーザー
データが渡されます。

{
“"bucket”:“unique-bucket-name”,
“region”:“us-west-2”,
“license”:“/FGVM020000000000.lic”,
“config”:“/fgtconfig-init.txt”,
}

13
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

フォーティネット ファブリックコネクタ

動的なネットワーク環境がますます拡大する中で、急速に変化するオペレーションに対応でき 次の情報を入力し、AWS VPC に接続

る俊敏性を実現するには、セキュリティソリューションを、ネットワーキングなどの IT インフ 可能なコネクタを作成します。
ラストラクチャとさらに緊密に統合する必要があります。 n AWS アクセスキー ID / シークレッ
マルチクラウド環境では、パブリッククラウド、プライベートクラウド、物理エンティティが トアクセスキー：API アクセスに必
それぞれ分離された集合体のため、それぞれ異なるセキュリティ管理手法が必要とされ、管理 要な AWS 認証情報
者の作業負担が増大します。また、サイトやテナントごとにセキュリティソリューションが異
n AWS リージョン名
なり、セキュリティ管理の一貫性を欠くため、異なるクラウドでのセキュリティ態勢の統一は
多くの企業が直面する大きな課題となっています。 n AWS VPC ID

フォーティネットのファブリックコネクタは、API などのインタフェースを備えることで、プ n 更新間隔：コネクタが動的なアド

ラットフォームの拡張性を高めます。すぐに使える統合機能が組み込まれており、FortiGate / レスオブジェクトを更新する間隔
FortiManager と、主要な SDN（ソフトウェア制御によるネットワーク）や AWS をはじめとす
るパブリッククラウドソリューションとのオーケストレーションを実現します。

ダイナミックアドレスオブジェクト

フォーティネット ファブリック コネクタは、SDN（プライベートクラウド）とクラウド（パブ

リッククラウド）向けの FortiGate（スタンドアロンシステムとして）または FortiManager（複
数の FortiGate NGFW を管理）を、サードパーティ SDN またはクラウドプラットフォームと統
合します。FortiManager の場合、FortiGate ファイアウォールポリシーで保護する動的アドレス
グループオブジェクトを同期します。

オブジェクトの形式や場所がエラスティックで常に変化する場合でも、FortiGate は、送信元 /
宛先として使用可能なアドレスオブジェクトとして識別します。適切なファイアウォールポリ
シーを自動的に適用するため、管理者による手作業の操作は必要ありません。

FortiManager は、 オ プ シ ョ ン の コ ン ポ ー ネ ン ト で す。 こ の セ ク シ ョ ン で は、 ユ ー ザ ー は
FortiGate を直接使用して、アドレスオブジェクトとファイアウォールポリシーを設定すること
を前提とします。

ファブリック コネクタ

新
定 更
の
義 クト
の
伝 ジェ
搬 ブ
オ

動的
オブジェクト

図 9：フォーティネット ファブリック コネクタ

AWS リソースの動的アドレスオブジェクトを作成するには、まず FortiGate CLI/API/GUI を使用

して AWS コネクタを作成する必要があります。

14
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

次に、この AWS コネクタを使用してアドレスオブジェクトを定義します。ユーザーは、インスタンス ID、インスタンスタイプ、サブネット ID な

どさまざまな AWS 属性に基づいてアドレスオブジェクトを定義できます。アドレスオブジェクトは、リソースに関連付けられたタグに基づいて
定義することも可能です。

例：動的アドレスオブジェクトを使用したファイアウォールポリシーの作成

タイプが AWS ファブリック コネクタのアドレスオブジェクトを作成したら、そのアドレスを送信元または宛先とするファイアウォールポリシー

を構成できます。図 10 は、ユーザーの AWS アカウントで導入した FortiGate のファイアウォールポリシーで使用されている動的アドレスオブジェ
クトを示しています。

インターネット AWS 用
Fortinet ファブリック コネクタ

パブリックサブネット

動的
アドレスオブジェクト

宛先 ターゲット

動的アドレス
オブジェクト - 更新

プライベートサブネット

図 10：動的アドレスオブジェクトを使用してファイアウォールポリシーを作成

この例のユーザーは、Dept=Eng のタグが付いたエンジニアリングリソースを、音声 / ビデオストリーミング Web サイトにアクセスできないよう

にすべてブロックしようとしています。
“tag.Dept=Eng”フィルタールールで作成した動的アドレスグループには、
EC2 インスタンスが 2 つ（10.0.1.9
と 10.0.1.10）含まれています。このアドレスオブジェクトを送信元アドレスとするファイアウォールポリシーが作成されます。このポリシーは、
音声 / ビデオストリーミング Web サイト（netflix.com など）を宛先とするアドレスオブジェクトからのアクセスを、すべてブロックします。したがっ
て、エンジニアリングチームが新しい EC2 インスタンスを起動すると、適切なタグ付けが行われている限り、そのインスタンスは自動的にアドレ
スオブジェクトに接続します。新しいインスタンスからストリーミング Web サイトへの接続は自動的にブロックされるため、管理者がファイア
ウォールを手動で構成する必要はありません。

単一 FortiGate-VM の AWS 上での展開

FortiGate を展開することで、環境をセキュリティ保護し、送信 / 受信トラフィックで詳細なパケットインスペクションを実行できます。次のセク

ションでは、単一の FortiGate 導入シナリオでのパケットフローを説明します。

インバウンドトラフィックのインスペクション（垂直方向）

Web アプリケーションが急増する現在、AWS と Web アプリケーションの両方を導入しているユーザーは、高度なサイバー攻撃からアプリケー

ションを保護する必要があります。そのためには、FortiGate-VM を VPC に導入し、インターネットから伝送されるすべてのインバウンドトラフィッ
クのインスペクションを行います。単一の FortiGate-VM で背後の複数のサービスを保護するアプローチとして一般的なのは、各サービスの IP ア
ドレス / Port を、FortiGate NGFW のパブリックネットワークインタフェースに関連付けられた単一の Elastic IP アドレス（EIP）にマッピングす
る方法です。たとえば、図 11 の Web サービスは Port 8080 でホストされており、FortiGate EIP / Port 8080 にマッピングされています。

15
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

Web サーバーを宛先とするすべてのトラフィックは、FortiGate-VM によって検査されます。VPC にアタッチされた IGW（インターネットゲート

ウェイ）は、インターネット接続を可能にし、FortiGate の ENI-0 のプライベート IP アドレスとインタフェースに関連付けられた EIP をネットワー
クアドレス変換します。

インターネット

パブリックサブネット

ルートテーブル - プライベートサブネット

宛先 ターゲット

Web
サーバー

プライベートサブネット

図 11：FortiGate-VM によるインバウンドトラフィックインスペクション

図 11 は、受信トラフィックのパケットフローとリターントラフィックのパスを示しています。

インバウンドトラフィック：IGW は、宛先 IP アドレス（FortiGate の ENI-0 に関連付けられている EIP）を、FortiGate の ENI-1 のプライベート IP

アドレスへと変換します。FortiGate NGFW は、宛先 NAT を適用することで、宛先 IP アドレスをバックエンド Web サーバーの IP アドレスへと変
更します。

リターントラフィック：Web サーバーから戻ってくるトラフィックは、プライベートサブネットのルートテーブルに従います。ここには、すべて
のインターネット行きトラフィックを FortiGate へとポイントするルートエントリーが含まれています。図 11 で示すように、FortiGate と IGW は
いずれも送信元 NAT をリターントラフィックに適用し、送信元 IP をパブリックルーティング可能な IP アドレス（FortiGate NGFW の ENI-0）に
関連付けられた EIP）へと変更します。

アウトバウンドトラフィックのインスペクション（垂直方向）

Web アプリケーショントラフィックは、ほとんどの場合インターネットからの受信が中心ですが、Web アプリケーションがインターネットへリ

クエストを送信する場合もあります。たとえば、マネージド Web サービスやユーザーによる Web サーバー管理を行う場合、セキュリティパッチ
のダウンロードやライブアップデートの実行を要求する必要があります。ユーザーは、プライベートサブネットのルートテーブルにデフォルトルー
トを追加し、FortiGate プライベートインタフェースをネクストホップとしてポイントすることが可能です。これにより、インターネット行きトラ
フィックを FortiGate で検査できるようになります。図 11 は、Web サーバーが生成するインターネット行きリクエストに対して送信元 NAT を割
り当て、宛先 NAT をリターントラフィックに割り当てる方法を示しています。

前述のとおり、FortiGate-VM でトラフィック転送を行うには、送信元 / 宛先チェックフラグをネットワークインタフェースレベルで無効にする必

要があります。

16
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

インターネット

パブリックサブネット

ルートテーブル - プライベートサブネット

宛先 ターゲット

Web
サーバー

プライベートサブネット

図 12：FortiGate-VM によるアウトバウンドトラフィックインスペクション

図 12 の例で示すように、OS パッチのダウンロードを行うには、プライベートサブネットの Web サーバーは、インターネット行きのリクエスト

を開始する必要があります。図で示すように、FortiGate-VM と IGW の両方が、送信元 NAT をアウトバウンドトラフィックに適用します。また、
宛先 NAT を応答トラフィックに適用することで、FortiGate の ENI-0 の EIP とプライベート IP アドレスを変換します。

トラフィックインスペクション（水平方向）

前述のように、AWS VPC ネットワーキングでは、VPC ネットワークのセグメンテーションを、VPC に割り当てられた CIDR の枠を超えて行うこ

とはできません。したがって、VPC 内のすべてのインスタンスは、サブネットに関係なく、サブネット内にある他のインスタンスへのルートを持
つことになります。たとえば、CIDR が 10.100.0.0/16 の VPC の場合、10.100.0.0/16 以外のルートを持つルートエントリー（10.100.1.0/24 など）
は許可されません。その結果、FortiGate-VM NGFW などの仮想ネットワークセキュリティアプライアンスへのトラフィックステアリングをネイティ
ブで行う方法がないため、VPC 内トラフィックインスペクション機能に制限が生じます。ただし、いくつかの回避策と代替的な設計により、AWS
にある水平方向トラフィックインスペクションの不足部分を補うことができます。

ホストルートテーブルのアップデート：AWS VPC サブネットで起動するすべての EC2 インスタンスのホストルートテーブルでは、デフォルトゲー

トウェイは、Amazon がそのサブネットのデフォルトゲートウェイとして予約した IP アドレスに設定されています。ユーザーはこのデフォルトゲー
トウェイを変更し、FortiGate ファイアウォールのネットワークインタフェースをポイントすることが可能です。インスタンスの数が限定される場
合は、このアプローチを推奨します。数を増やす場合には、ユーザーデータやその他のツールを使ってルートテーブルのアップデートを自動化す
る方法があります。

マルチ VPC 設計：AWS は、VPC レベルでのネットワークセグメンテーションを推奨しています。このアプローチでは、サブネットレベルではな

く VPC レベルでワークロードをグループ化します。VPC 間のトラフィックはすべて、個々の VPC または共有 VPC において、ネットワークセキュ
リティ仮想ファイアウォールによって検査されます。これを、大規模環境で自動実行するには、Transit VPC や AWS Transit Gateway のような設計
パターンを使用できます。

FortiGate が AWS で実現する高可用性と耐障害性

前述のように、クラウドには固有のセキュリティの課題があり、それに対応するには革新的なアプローチが必要になります。本番環境に NGFW セ
キュリティソリューションを導入するユーザーは、高可用性と耐障害性の設計を極めて重視しています。フォーティネットは、このニーズに応え
るために、AWS で FortiGate NGFW を導入するうえで耐障害性にすぐれたさまざまなアーキテクチャをサポートしています。

17
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

オンプレミスネットワークへのアウトバウンド接続における耐障害性

クラウドにワークロードを移行する企業が急増する一方で、その多くはオンプレミスにも多くのワークロードを残すことを考えています。高スルー
プット FortiGate NGFW を、AWS VPC 内の VPN ゲートウェイとして導入し、VPN トンネルを確立することで、クラウドワークロードを物理的なデー
タセンターへと戻すことができます。図 13 で示すように、ペアで導入することで物理データセンターへのアウトバウンド接続の耐障害性を実現
できます。

ルートテーブル プライベートサブネット
― Availability Zone 1
AWS Cloud
宛先 ターゲット

Availability Zone 1

パブリックサブネット
プライベートサブネット

データセンター / 支社 Web
サーバー

パブリックサブネット プライベートサブネット

インターネット
Web
サーバー

ルートテーブル プライベートサブネット
― Availability Zone 2

宛先 ターゲット

Availability Zone 2

図 13：物理データセンターのアウトバウンド接続で耐障害性を実現

AWS VPC 内での VPN トンネルの終端には、AWS 仮想プライベートゲートウェイを使用することが可能ですが、サポートできる帯域幅が格段に大

きい点で、FortiGate NGFW を使用することを強く推奨します。

図 13 は、2 つのアベイラビリティゾーンに FortiGate VM を 2 つ導入することで、耐障害性を実現する構成例です。各プライベートサブネットのルー

トテーブルでは、それぞれのアベイラビリティゾーンにある FortiGate の ENI-1 をポイントするルートが含まれています。1 つのアベイラビリティ
ゾーンでダウンタイムが発生しても、他のアベイラビリティゾーン内のワークロードのアウトバウンド接続は維持されます。

FortiGate NGFW は BGP をサポートするため、ユーザーのゲートウェイも BGP をサポートする場合には、オンプレミスネットワークからルート

を動的に学習します。さらに、それぞれの FortiGate は、インターネット行きの全トラフィックのデフォルトゲートウェイとして機能します。

ユニキャスト HA を使ったアクティブ / パッシブ構成

これまで、ユーザーはデータセンター内で FortiGate NGFW の高可用性構成を行うことで、FortiGate Clustering Protocol（FGCP）によるセッション

同期と耐障害性を実現してきました。このプロトコルで使用するハートビートトラフィックはマルチキャストパケットを使用しますが、AWS
VPC ネットワーキングでは、マルチキャスト / ブロードキャストパケットは使用できません。

FortiGate インスタンスのペアがセッションを同期できる AWS 環境をサポートするために、フォーティネットはユニキャスト HA を提供してい

ます。これは、AWS 向けのアクティブ / パッシブクラスタリングソリューションです。このソリューションは、マスターとスレーブとして構成
した 2 つの FortiGate インスタンスと連携します。この 2 つのインスタンスは、単一 VPC 内にある同じアベイラビリティゾーン内の同じサブセッ
トに導入する必要があります。この 2 つの FortiGate インスタンスは、論理的な単一のインスタンスとして動作し、同じインタフェース IP アド
レスを共有します。構成を同期することで、スタンドアロンの FortiGate と同じ方法でクラスタを構成することが可能になります。フェイルオー
バーが発生すると、クラスタは素早く自動的に復旧します。管理者に通知が送信されるため、障害の原因となった問題を修正し、ダウンしたリソー
スのリストアを行うことができます。

18
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

AWS Cloud

AWS での FGCP コンポーネント

n 2 つの FortiGate NGFW。それぞれ
が 4 つのネットワークインタフェー
セカンダリ IP:

スを持つ
パブリックサブネット（データ） パブリックサブネット（管理）

セカンダリ IP:
n 2 つの専用 ENI。1 つはパブリック
イ ン タ フ ェ ー ス 用（ENI0\port1）、

宛先 ターゲット
もう 1 つはプライベートインタ
セカンダリ IP:

フェース用（ENI1\port2）です。こ
セカンダリ IP:
の ENI は、セカンダリ IP アドレス
プライベートサブネット（データ） プライベートサブネット（ハートビート）

を使用します。これによって、両
方の FortiGate インスタンスが、実
Availability Zone 1

際の FortiOS 構成 / 同期セッション

図 14：AWS での FortiGate FGCP の導入

内で、同じ IP アドレスをネイティ
ブに共有することが可能になりま
す。AWS では ENI のプライマリ IP
インバウンドフェイルオーバーでは、ENI0\port1 のセカンダリ IP アドレスを、FortiGate 1 の
を変更できないため、セカンダリ
パブリックインタフェースから FortiGate 2 のパブリックインタフェースへと再割り当てしま
IP アドレスを使用する必要がある
す。さらに、ENI0\port1 のセカンダリ IP アドレスに関連付けられている EIP を、FortiGate 1
点に注意してください。
のパブリックインタフェースから FortiGate 2 のパブリックインタフェースへと再割り当てし
ます。 n クラスタ EIP は、現在のマスター
FortiGate インスタンスのパブリッ
アウトバウンドフェイルオーバーでは、ENI 1\port2 のセカンダリ IP アドレスを、FortiGate 1
クインタフェース（ENI0\port1）の
のプライベートインタフェースから FortiGate 2 のプライベートインタフェースへと再割り当
セカンダリ IP に関連付けられ、新
てします。また、FortiGate 1 のプライゲートインタフェースを参照するルートターゲットは
し く マ ス タ ー と な っ た FortiGate
更新され、FortiGate 2 のプライベートインタフェースを参照します。図 14 と図 15 は、AWS
インスタンスへの関連付けが再度
VPC における FGCP のフェイルオーバープロセスを示しています。
行われます。

n FGCP HA 通 信 専 用 の ENI（ENI2\
AWS Cloud

port3）。ハートビートチェック、構
成の同期、セッションの同期といっ
たタスクを実行

セカンダリ IP:
n 各インスタンスへの管理アクセス
パブリックサブネット（データ） パブリックサブネット（管理）
を行う専用 ENI（ENI3\ port4）。ま
た、これによって各インスタンス
セカンダリ IP:

は、パブリック AWS EC2 API との

宛先 ターゲット 独立した直接通信を実行
セカンダリ IP:

n AWS IAM ロ ー ル。 こ の ロ ー ル を
セカンダリ IP:
プライベートサブネット（データ） プライベートサブネット（ハートビート）
引 き 継 ぐ こ と で、FortiOS は AWS
Availability Zone 1
EC2 API へのアクセスを承認され、
ルートテーブルの更新やクラス
タ EIP の再割り当てといったアク
図 15：AWS での FortiGate FGCP のフェイルオーバープロセス
ションを実行できるようになりま
す。
アクティブ / パッシブ環境の耐障害性 - 2 つのアベイラビリティゾーン

従来の物理的なデータセンターのように、完全なセッション同期機能を備えた HA ソリュー
ションを求める AWS ユーザーがいる一方で、多くのユーザーは、耐障害性（複数の AZ）を
備えた環境の整備により、可用性に優れたセキュリティサービスを実現しようとしています。
フォーティネットは、Lambda ベース、デュアル AZ、アクティブ / パッシブフェイルオーバー
を特徴とするソリューションを提供しています（詳細はこちら 2 をご覧ください）。このソリュー
ションは、TCP ヘルスチェックによって AWS EIP とルートテーブルを自動更新し、2 つの異な
るアベイラビリティゾーンにある 2 つの異なる FortiGate インスタンスで送受信トラフィックの

「AWS-CloudFormationTemplates/Templates/LambdaAP-EIP+RouteFailover/6.0/」GitHub（英語）：
2

https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAP-EIP%2BRouteFailover/6.0

19
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

フェイルオーバーを行います。このソリューションは、主に 2 つのコンポーネントで構成されます。1 つ目のコンポーネントは、インスタンスの

パブリックインタフェース（ENI0\port1）です。これには、プライマリ / セカンダリ IP アドレスが割り当てられています。いずれのインスタンス
でも、専用 EIP がパブリックインタフェースのプライマリ IP に関連付けられています。さらに、アクティブインスタンスでは、パブリックインタ
フェースのセカンダリ IP に Floating EIP が割り当てられています。2 つ目のコンポーネントは、インスタンスのプライベートインタフェース（ENI1\
port2）です。これには、プライマリ IP アドレスのみが割り当てられています。

Lambda Function：TCP ヘルスチェックと AWS VPC ネットワーキングの更新には、1 つの Lambda Function が使用されます。この Lambda
Function は、両方のインスタンスについて、ENI1 のプライマリ IP の TCP ヘルスチェックを、アクティブインスタンスから実行します。

CloudWatch イベントルール：単一の CloudWatch イベントルールを使用して、Lambda Function をスケジュールに従って（毎分）トリガーします。

API Gateway：FortiOS スティッチアクションで Lambda Function をアドホックベースでトリガーする操作には、API ゲートウェイが使用されま

す。FortiGate NGFW の動的なブートストラップが行われ、リンクモニターを使用してプライベートインタフェース（ENI1\port2）を介した相互
監視（ping）を実行します。また、スティッチが構成され、リンクモニターのステータスが変化した場合に API ゲートウェイを介して Lambda
Function をトリガーできるようになります。

VPC エンドポイント：EC2 の VPC インタフェースエンドポイントが作成されます。これによって Lambda Function は、ユーザーの VPC 内から

プライベート IP で AWS EC2 API と FortiGate インスタンスの両方にアクセスできるようになります。

Region

パブリックサブネット パブリックサブネット

プライマリ IP: プライマリ IP:

セカンダリ IP: セカンダリ IP:

プライマリ IP: プライマリ IP:

宛先 ターゲット 宛先 ターゲット

プライベートサブネット プライベートサブネット

図 16：FortiGate デュアル AZ によるアクティブ / パッシブ HA

ヘルスチェックでアクティブインスタンスが不合格、パッシブインスタンスが合格となった場合、Lambda Function は、ENI0 または ENI1 をポイン

トしているアクティブインスタンスのルートを、パッシブインスタンスへと更新します。EIP の中に、アクティブインスタンスの ENI0 のセカンダ
リ IP に関連付けられているものがある場合には、パッシブインスタンスへと変更されます。次に、
「ha:status」タグの値が入れ替わり、現在のアクティ
ブインスタンスとパッシブインスタンスが正しく参照されます。図 17 は、現在アクティブなインスタンス（FGT-1）から現在パッシブなインスタン
ス（FGT-2）へとフェイルオーバーする状態を示しています。導入方法の詳細についてはこちら 3 の「Lambda ベース、デュアル AZ、アクティブ / パッ
シブフェイルオーバー」の項目をご覧ください。

「AWS-CloudFormationTemplates/Templates/LambdaAP-EIP+RouteFailover/6.0/」GitHub（英語）：
3

https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAP-EIP%2BRouteFailover/6.0

20
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

Region

アクティブ / アクティブな
パブリックサブネット パブリックサブネット
アウトバウンドトラフィックの
プライマリ IP: プライマリ IP:
コンポーネント
セカンダリ IP:
n FortiGate インスタンス
セカンダリ IP:

n Lambda Function
プライマリ IP: プライマリ IP:

n CloudWatch イベントルール
宛先 ターゲット 宛先 ターゲット

n API Gateway

プライベートサブネット プライベートサブネット
n VPC エンドポイント

図 17：FortiGate デュアル AZ のアクティブ / パッシブ HA によるフェイルオーバープロセス

アウトバウンドトラフィックの耐障害性 - アクティブ / アクティブフェイルオーバー

アクティブ / パッシブ構成は耐障害性に優れたアーキテクチャではありますが、稼働できる
FortiGate インスタンスは 1 つに限定されます。アクティブ / アクティブ FortiGate フェイルオー
バー（図 18）では、AWS ルートテーブルを自動更新することで、異なるアベイラビリティゾーン
にある 2 つの独立した FortiGate インスタンスで送信トラフィックフローを処理します。いずれ
の FortiGate インスタンスも同時に稼働し、トラフィックを処理します。ただし、このソリュー
ションで実現できるのは、VPC から出て行くアウトバウンドトラフィックの耐障害性のみです。
インバウンドトラフィックの耐障害性を実現するには、AWS ELB や Route 53 サービスといっ
た外部リソースを利用できます。インバウンドトラフィックを対象にしたファイアウォールの
耐障害性については、本書の「設計パターン」のセクションをご覧ください。

Region

パブリックサブネット パブリックサブネット

プライマリ IP: プライマリ IP:

プライマリ IP: プライマリ IP:

宛先 ターゲット 宛先 ターゲット

プライベートサブネット プライベートサブネット

図 18：FortiGate アクティブ / アクティブ構成でアウトバウンドトラフィックの耐障害性を実現

図 18 のソリューションは、前のセクションで説明した Lambda ベースのアクティブ / パッシブ

構成に非常に類似しており、同じコンポーネントで構成されています。

21
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

大きな違いは、2 つのアベイラビリティゾーンにあるルートテーブルに、異なる FortiGate プライベートインタフェースをポイントするルートエン

トリーが含まれているという点です。これにより、トラフィックの発生元となる送信元のアベイラビリティゾーンに基づいて、両方の FortiGate イン
スタンスが利用可能になります。図 19 は、この設計のフェイルオーバープロセスを示しています。現在ポイントしている FortiGate 1 のプライベー
トインタフェースを、FortiGate 2 のプライベートインタフェース（ENI1）へと更新することで、アウトバウンドフェイルオーバーが実現されます。

FortiGate 1 がオンラインに復帰し、ヘルスチェックに合格した時点で、AZ1 のルートリストが更新されて FortiGate 1 がポイントされ、AZ のロー

カルインスタンスになります。

AWS SDN とタグの更新は、VPC エンドポイントインタフェースを介して、Lambda Function が API コールを起動することで行われます（VPC 内

で Lambda が自動生成した ENI から実行）。導入方法の詳細についてはこちら 4 をご覧ください。

Region

パブリックサブネット パブリックサブネット

プライマリ IP: プライマリ IP:

プライマリ IP: プライマリ IP:

宛先 ターゲット 宛先 ターゲット

プライベートサブネット プライベートサブネット

図 19：FortiGate アクティブ / アクティブ耐障害性構成によるアウトバウンドトラフィックのフェイルオーバープロセス

「AWS-CloudFormationTemplates/Templates/LambdaAA-RouteFailover/6.0/」GitHub（英語）：
4

https://github.com/fortinet/aws-cloudformation-templates/tree/master/LambdaAA-RouteFailover/6.0

22
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

設計パターン
本書の前のセクションでは、AWS の主な概念と FortiGate の導入モデルについて詳しく説明し この設計の主なコンポーネント
ました。このセクションでは、さまざまな AWS サービスと設計パターンを使用して、物理的な n AWS ベストプラクティスに従って、
データセンターの一部または全部を AWS 環境へと移行するユーザーを対象に、拡張性に優れた パブリック / プライベートサブネッ
自動セキュリティソリューションを提供する方法を説明します。インフラストラクチャのセキュ トで構成された VPC。この環境で
リティ設計では、次の内容を検討する必要があります。 は、2 つのアベイラビリティゾーン

拡張性：Transit VPC などの設計パターン、Transit Gateway、単一 VPC の設計のどれが最適な で耐障害性を高めます。

のかは、ユーザー環境に存在する VPC の数に応じて決まります。また、ルーティング要件も設 n パブリックサブネット内の FortiGate

計に影響を及ぼします。 ホスト。自動スケーリンググループ
自 動 化：AWS な ど の ク ラ ウ ド に は 分 散 / 動 的 と い う 特 性 が あ る た め、Terraform や 内にあり、AWS セキュリティグルー
CloudFormation の IaaC（コードとしてのインフラストラクチャ）ツールも極めて重要です。さ プを補完します。これにより、レ
らに、AWS Auto Scaling などの AWS ネイティブサービスも、AWS の柔軟性を効率化かつ自動 イヤー 7 のセキュリティ機能（侵
化する上で役立ちます。 入検知、Web フィルタリング、脅
威検知など）が提供されます。
高可用性と耐障害性：本番環境でワークロードを処理するユーザーにとって、優れた耐障害性
と可用性を備えたセキュリティソリューションは、データとアプリケーションの保護に理想的 n パブリックサブネット内の FortiGate
です。FortiGate の耐障害性オプションと AWS のマネージドサービスは、このニーズに応える NGFW。NAT ゲ ー ト ウ ェ イ と し
ことができます。 て機能し、プライベートサブネッ
ト内のリソースのアウトバウンド

FortiGate オートスケーリングによる柔軟なロードバランシングのサンドイッチ構成 インターネットアクセスを可能に

します。また、
FortiGate NGFW イン
AWS ELB（Elastic Load Balancing）は、AWS 環境向けのロードバランシングサービスです。
スタンスによるアウトバウンドト
ELB は受信アプリケーショントラフィックを分散し、トラフィックのニーズに合わせてリソー
ラフィックインスペクションも実
スを拡張します。高スループット NGFW を求めるユーザーは、FortiGate インスタンスを AWS
行されます。
ELB / AWS Auto Scaling と統合することで、トラフィックの変動に対応できます。FortiGate
NGFW インスタンスは、オートスケーリンググループ内にあり、AWS の外部向け NLB（Network n 外部向けの NLB。内部向けの NLB
Load Balancer）の前に置かれます。内部向け NLB をもう 1 つオプションで使用し、プライベー はオプションです。
トサブネット内にあるバックエンドサーバーへとトラフィックを分散することも可能です。こ
n Amazon API ゲ ー ト ウ ェ イ。
の構成は、FortiGate インスタンスが 2 つの NLB に挟まれているため、ELB サンドイッチと呼
FortiGate オ ー ト ス ケ ー リ ン グ グ
ばれます。
ループのコールバック URL を提供
することで、フロントドアとして
機能します。

AWS Cloud n Lambda Function。スケーリング、

Region
フェイルオーバー管理、その他の
外部向け 関連コンポーネントの構成を行い
ます。
Availability Zone 1 Availability Zone 2

パブリックサブネット パブリックサブネット

ネットワーク
ロードバランサー n Amazon DynamoDB データベース。
FortiGate FortiGate フォーティネットが提供するスク
ゲートウェイ ゲートウェイ
オートスケーリング
グループ
リプトを使用して、自動スケーリン
グの条件ステートに関する情報を
プライベートサブネット

格納します。
プライベートサブネット

内部向け

保護された ネットワーク 保護された

Web サーバー ロードバランサー Web サーバー

図 20：ELB サンドイッチ構成での FortiGate オートスケーリング

23
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

FortiGate は、API ゲートウェイを使用して API コールを送信します。そして、FortiGate Config-

Sync タスクを処理し、オートスケーリングイベントの実行時に、複数の FortiGate インスタン Fortinet Transit VPC の
ス全体でオペレーティングシステム構成を同期します。現在、これは VPC の内部使用に限定さ 主なコンポーネント
れており、パブリックアクセスはできません。
n Transit VPC で ア ク テ ィ ブ / ア ク
既存の VPC 内にあるプライベートサブネット内の Web サーバーへの受信リクエストは、イン ティブモードで構成された 2 つの
ターネットゲートウェイ、ネットワークロードバランサー、FortiGate オートスケーリンググルー FortiGate インスタンス
プを介して送られ、Web サーバーへと到達します。Web サーバーは、同じ接続を使って応答を
n Transit VPC（ハブ）とアプリケー
返します。
ション VPC（スポーク）
Web サーバーからの送信リクエストは、個々の FortiGate NAT ゲートウェイとインターネット
ゲートウェイを介して、外部ネットワークへと送られます。外部ネットワークは、同じパスを使っ n 各スポーク VPC で構成された AWS

て応答を返します。 VPN ゲートウェイ

このソリューションは完全に自動化され、既存の VPC と新しい VPC のいずれにも導入可能です。 n 2 つの Lambda Function（仮想プラ

この構成は、AWS クイックスタートガイドとして提供されています。 イベートゲートウェイポーラーと
フォーティネット VPN コンフィギュ
レーター）
Transit VPC

ほとんどの AWS 環境は、単一の VPC から始まり、複数のリージョンにまたがる複数の VPC へ n AWS CloudWatch イベントルール

と拡張していきます。ただし、複数の VPC で構成される環境の場合、VPC 間接続には VPC ピ
n オプションの物理データセンター
アリングを使用した明示的なピアリングが必要であり、非常に複雑になります。また、VPC ピ
（カスタマーゲートウェイ）
アリングでは、VPC 間のトラフィックフローをユーザーが制御することはできません。もう 1
つのアプローチとして、オンプレミスデータセンター内でホストするファイアウォールなどの
物理ゲートウェイにトラフィックをバックホールし、VPC 間通信を行う方法もあります。ただ
しこのアプローチでは、クラウドトラフィックをオンプレミスへとバックホールするため、ト
ラフィックが宛先に到達するまでに遅延が生じます。この問題は、Transit VPC でハブ & スポー
クトポロジを構成することによって解決できます。ハブ VPC で仮想ファイアウォールをホスト
し、スポーク VPC をハブファイアウォールで相互接続します。この構成では、クラウドトラフィッ
クがユーザーの AWS 環境外に出ることはありません。

多彩なルーティング機能と強力なアプリケーションセキュリティ機能を備えた AWS 上の
FortiGate-VM は、優れたセキュリティ、高スループット、自動化を特徴とする Transit VPC 環境
を実現します。VPC 間通信とオンプレミスデータセンターへの接続に対応します。

Availability Zone 1 Availability Zone 2

図 21：Transit VPC

24
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

Fortinet Transit VPC の導入には、AWS CloudFormation テンプレートを使用できます。Transit VPC の作成が完了すると、Lambda 自動化インフラ

ストラクチャがスポーク VPC を Transit VPC に接続します。Lambda Function（仮想ゲートウェイポーラーと Fortinet Configurator）が連携し、仮
想プライベートゲートウェイの検出と、FortiGate への VPN 接続の構成を行います。

仮想プライベートゲートウェイポーラーが仮想プライベートゲートウェイをチェックする処理では、CloudFormation テンプレートで指定されたタ
グを検索し、Transit VPC アカウント内の仮想プライベートゲートウェイをチェックします。“transitvpc:spoke=true”タグのペアを持つ VGW が見
つかると、Fortinet Configurator の Lambda Function は VPN 接続を定義し、FortiGate 構成をプッシュして IPsec トンネルを作成します。Lambda
Poller Function は CloudFormation で指定された S3 バケットにファイルを作成し、構成すべき内容をコンフィギュレーターに通知します。VPN 接
続に関連付けられたパラメータと構成は、すべて S3 バケットに保存されます。PUT S3 バケットイベントは、もう 1 つの Lambda Function（Fortinet
Configurator）をトリガーします。図 22 は、Fortinet Transit VPC アーキテクチャを示しています。

キー：
値：

Availability Zone 1 Availability Zone 2

Spoke VPC 2 – プライベートサブネット
ルートテーブル

宛先 ターゲット アクティブ 伝搬

インターネット

オンプレミスの
企業 DC

図 22：Fortinet Transit VPC アーキテクチャ

BGP ピアリングセッションは、スポーク VPC 仮想プライベートゲートウェイと Transit VPC FortiGate 間で確立されます。BGP セッションは、

Transit VPC 自動化フレームワークで生成された VPN IPsec トンネルを介して確立されます。

Fortinet Transit VPC は、複数のアカウントと複数のリージョンをまたいでスポーク VPC を接続することができます。

詳しくは、フォーティネットの「AWS TRANSIT VPC WITH FORTIGATE NEXT-GENERATION FIREWALL」5（英語）をご覧ください。

耐障害性 FortiGate 構成と AWS Transit Gateway の統合

Fortinet Transit VPC のような Transit VPC の導入は、VPC 間接続とセキュリティ要件に対応できるアプローチです。一方で、AWS 仮想プライベー

トゲートウェイは、各 VPC スポークに導入され、VPN 接続を終端しますが、帯域幅に深刻な制限があり、ネットワークパフォーマンスが低下します。

この問題を解決するために、AWS Transit Gateway は、大規模な接続にも対応できる拡張性を備えた分散サービスを新たに提供しています。このサー

ビスは ECMP（等価コストマルチパス）ルーティングをサポートし、トラフィックは、同じ IP プレフィックスを伝搬する複数の VPN 接続に対し
て均等に配分されます。その結果、ネットワークの柔軟性が大幅に向上します。AWS スイートの一部であるため、CloudFormation や CloudWatch
といったネイティブサービスや VPC フローログを使用して、AWS Transit Gateway の管理と監視を実行できます。

AWS Transit Gateway は、垂直と水平を含むあらゆる方向のトラフィックのルーティングを実行できます。フォーティネットのクラウドサービス

ハブは、AWS Transit Gateway サービスを活用することで、複数の重要なユースケースを実現し改善します。

「AWS TRANSIT VPC WITH FORTIGATE NEXT-GENERATION FIREWALL」フォーティネット（英語）：

5

https://www.fortinet.com/content/dam/fortinet/assets/deployment-guides/dg-fortigate-transit-vpc.pdf

25
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

ハイブリッドクラウド：一般的なハイブリッドクラウド環境では、複数のリモート支社、企業データセンター、アプリケーション VPC 間を、大量

のデータが常に移動しています。フォーティネットのクラウドサービスハブは、クラウド内に中央のハブ VPC を作成することで、相互接続性と
トラフィックインスペクションを容易にします。クラウドサービスハブでは、ECMP を拡張性に優れた方法で使用します。アプリケーション VPC
は Transit Gateway に直接アタッチできますが、物理データセンターやリモート支社は、クラウドサービスハブ内の FortiGate NGFW に接続する
ことが可能です。

インバウンドアプリケーショントラフィックでファイアウォール耐障害性を実現：VPC 内のプライベートサブネットにアプリケーションを導入す
る方法は、パブリック IP アドレスを必要としないという点で、多くのユーザーに好まれる方法です。ただし、外部からの攻撃からアプリケーション
を保護する必要があります。フォーティネットのクラウドサービスハブは、AWS Transit Gateway と統合することで、プライベート VPC に Web
アプリケーションを導入できる利便性があり、耐障害性に優れた FortiGate NGFW をパブリック VPC で実装することによってアプリケーションを
保護できます。図 23 では、2 つの FortiGate NGFW の前面に、インターネットに面している AWS Load Balancer があります。バックエンドサー
ビスが、Transit Gateway に接続された 2 つのスポーク VPC に実装されています。

インターネット

AWS Cloud

パブリックサブネット パブリックサブネット

Transit Gateway
アタッチメント

プライベートサブネット プライベートサブネット

Availability Zone 1 Availability Zone 2

図 23：インバウンドトラフィックのファイアウォール耐障害性を実現する Transit Gateway

水平方向のトラフィックインスペクション：ゼロトラストのセキュリティ導入戦略は小規模から大規模な企業に採用されていますが、この戦略で
は、すべてのトラフィックを検査することが極めて重要になります。最近の調査によると、クラウドトラフィックの大半が環境内を水平方向に移
動します。

フォーティネットのクラウドサービスハブは、すべてのトラフィックを調査することで、脅威の水平移動を阻止します。その 1 つの方法が、
Transit Gateway サービスを使用して AWS Transit Gateway にルートテーブルを複数作成する方法です。このアプローチでは、FortiGate の高度な
セキュリティ機能で、VPC 間トラフィックの一部またはすべてを調査できます（さらに、セキュリティファブリック全体に導入されているその他
のセキュリティソリューションを使用）。インスペクションの対象となるトラフィックはすべて、フォーティネットのクラウドサービスハブに導
入されている FortiGate ソリューションに送信されます。

図 24 で示すように、この環境では、2 つの Transit Gateway ルートドメインが使用されます。1 つは、すべてのスポーク VPC にアタッチしているルー

トテーブル、もう 1 つはクラウドサービスハブ VPC にアタッチしているルートテーブルです。フローのアフィニティを保証するために、送信元
NAT を各 FortiGate NGFW で適用する必要があります。さらに、各スポーク VPC ルートテーブルには、クラウドサービスハブに戻るルートも必要
です。

図 24 の構成は、アクティブ / アクティブ FortiGate 構成を前提とします。または、FortiGate をアクティブ / パッシブで実装する Transit Gateway

とクラウドサービスハブ間で、Transit Gateway アタッチメントを作成することもできます。この構成では送信元の NAT 指定が不要であるため、
水平トラフィックインスペクションで送信元 IP アドレスを維持したい場合に適しています。

26
WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

企業のデータセンター /
Spoke（VPC-B）ルートテーブル 支社

宛先 ターゲット

FortiGate に戻るルート
– NAT プール

SNAT を適用して
フローアフィニティを保証

VPN アタッチメント

Cloud Services Hub

VPC ルートドメイン ルートドメイン

クラウドサービスハブ

図 24：FortiGate NGFW と AWS Transit Gateway による VPC / VPC トラフィックインスペクション

まとめ
クラウドを導入する組織が増加する今、クラウドジャーニーの早い段階で要件に適したセキュリティアーキテクチャを設計することが極めて重要
になっています。AWS におけるフォーティネット FortiGate-VM は、さまざまな構成と設計モデルをサポートし、AWS ユーザーが求める拡張性、
可用性、耐障害性の要件を満たします。さらに、ネイティブ AWS サービスや自動化フレームワークとの統合により、FortiGate NGFW は動的な拡
張性を自動的に実現し、トラフィックの変動にも対応します。フォーティネットのセキュリティファブリックコネクタは AWS とネイティブに統
合することで、FortiGate インスタンス全体の管理やファイアウォールポリシーの適用を自動化します。

27
 WHITE PAPER | Amazon Web Services（AWS）リファレンスアーキテクチャ

〒106-0032
東京都港区六本木 7-7-7
Tri-Seven Roppongi 9 階
www.fortinet.com/jp/contact

Copyright© 2020 Fortinet, Inc. All rights reserved. この文書のいかなる部分も、いかなる方法によっても複製、または電子媒体に複写することを禁じます。この文書に記載されている仕様は、予告なしに

変更されることがあります。この文書に含まれている情報の正確性および信頼性には万全を期しておりますが、Fortinet, Inc. は、いかなる利用についても一切の責任を負わないものとします。Fortinet®、
FortiGate®、FortiCare®、および FortiGuard® は Fortinet, Inc. の登録商標です。その他記載されているフォーティネット製品はフォーティネットの商標です。その他の製品または社名は各社の商標です。

WP-AWS-Reference-Architecture-202001-R1