# ネットワーク
Outpost のデプロイは、管理、モニタリング、サービス運用が適切に機能するために、アンカー AZ への耐障害性の高い接続が不可欠です。各 Outpost ラックに冗長ネットワーク接続を提供し、AWS クラウド内のアンカーポイントへの信頼性の高い接続を提供するようにオンプレミスネットワークをプロビジョニングする必要があります。また、Outpost で実行されているアプリケーションワークロードと、それらが通信する他のオンプレミスおよびクラウドシステムとの間のネットワークパスについても検討してください。このトラフィックをネットワーク内でどのようにルーティングしますか。
**Topics**
+ [
# ネットワークアタッチメント
](network-attachment.md)
+ [
# アンカー接続
](anchor-connectivity.md)
+ [
# アプリケーション/ワークロードのルーティング
](applicationworkload-routing.md)
# ネットワークアタッチメント
各 AWS Outposts ラックは、Outpost ネットワークデバイス (OND) と呼ばれる冗長なトップオブラックスイッチで構成されています。各ラックのコンピューティングサーバーとストレージサーバーは、両方の OND に接続します。各 OND をデータセンターのカスタマーネットワークデバイス (CND) と呼ばれる個別のスイッチに接続して、各 Outpost ラックにさまざまな物理パスと論理パスを提供する必要があります。OND は、光ファイバーケーブルと光トランシーバーを使用して 1 つ以上の物理接続で CND に接続します。[物理接続](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#physical-connectivity)は、[リンク集約グループ (LAG) リンク](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#link-aggregation)で構成されます。
![\[冗長ネットワークアタッチメントを備えたマルチラック Outpost を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/multi-rack-outpost.png)
OND から CND へのリンクは、物理接続が 1 本の光ファイバーケーブルであっても、常に LAG で設定されます。リンクを LAG グループとして設定すると、論理グループに物理接続を追加してリンク帯域幅を増やすことができます。LAG リンクは IEEE 802.1q イーサネットトランクとして設定され、Outpost ネットワークとオンプレミスネットワーク間の分離されたネットワーキングを可能にします。
すべての Outpost には、カスタマーネットワークとの通信またはカスタマーネットワーク経由の通信が必要な、論理的に分離されたネットワークが少なくとも 2 つあります。
+ **サービスリンクネットワーク** — サービスリンクの IP アドレスを Outpost サーバーに割り当て、オンプレミスネットワークとの通信を容易にし、サーバーがリージョン内の Outpost アンカーポイントに再接続できるようにします。単一の論理 Outposts に複数のラック実装がある場合は、各ラックにサービスリンク /26 CIDR を割り当てる必要があります。
+ **ローカルゲートウェイネットワーク** — Outpost の VPC サブネットと Outpost ローカルゲートウェイ (LGW) 経由のオンプレミスネットワーク間の通信を可能にします。
これらの分離されたネットワークは、LAG リンクを介した一連の[ポイントツーポイント IP 接続](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity)によってオンプレミスネットワークに接続されます。OND から CND への各 LAG リンクは、分離されたネットワーク (サービスリンクと LGW) ごとに VLAN ID、ポイントツーポイント (/30 または /31) IP サブネット、および eBGP ピアリングで設定されます。ポイントツーポイントの VLAN とサブネットを含む LAG リンクは、レイヤ 2 セグメント化され、ルーティングされたレイヤ 3 接続と見なす必要があります。ルーティングされた IP 接続は、Outpost 上の分離されたネットワークとオンプレミスネットワーク間の通信を容易にする冗長な論理パスを提供します。
![\[サービスリンクピアリングを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/service-link-peering.png)
![\[ローカルゲートウェイピアリングを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/page-20-local-gateway-peering.png)
直接接続された CND スイッチでレイヤ 2 LAG リンク (およびその VLAN) を終了し、CND スイッチに IP インターフェイスと BGP ピアリングを設定する必要があります。データセンターのスイッチ間で LAG VLAN をブリッジしないでください。詳細については、*AWS Outposts ユーザーガイド*の「[Network layer connectivity](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity)」(ネットワークレイヤーの接続性) を参照してください。
論理的なマルチラックの Outpost 内では、OND が冗長的に相互接続され、ラックとサーバー上で実行されているワークロード間の可用性の高いネットワーク接続を実現しています。AWS は、Outpost 内のネットワークの可用性を管理します。
## ACE を使用しない可用性の高いネットワーク接続の推奨プラクティス
+ Outpost ラック内の各 Outpost ネットワークデバイス (OND) を、データセンターの個別のカスタマーネットワークデバイス (CND) に接続します。
+ 直接接続されたカスタマーネットワークデバイス (CND) スイッチ上でレイヤー 2 リンク、VLAN、レイヤー 3 IP サブネット、および BGP ピアリングを終了します。CND 間またはオンプレミスネットワーク経由で OND を CND VLAN にブリッジしないでください。
+ リンク集約グループ·(LAG) リンクを追加して、Outpost とデータセンター間で利用可能な帯域幅を増やします。両方の OND を経由するさまざまなパスの集約帯域幅に依存しないでください。
+ 冗長 OND を経由するさまざまなパスを使用して、Outpost ネットワークとオンプレミスネットワーク間の耐障害性の高い接続を実現します。
+ 最適な冗長性を実現し、中断することなく OND メンテナンスを行えるように、BGP アドバタイズとポリシーを次のように設定することをお勧めします。
+ お客様のネットワーク機器は、BGP 属性を変更せずに Outpost から BGP アドバタイズを受信し、BGP マルチパス/ロードバランシングを有効にして (お客様から Outpost への) 最適なインバウンドトラフィックフローを可能にする必要があります。メンテナンスが必要な場合に備えて、Outpost BGP プレフィックスに AS-Path への付加を使用して、トラフィックを特定の OND/アップリンクから移行します。お客様のネットワークは、AS-Path length 4 のルートよりも Outpost with AS-Path length 1 からのルートを優先する必要があります。つまり、AS-Path への付加に対応する必要があります。
+ お客様のネットワークは、Outpost 内のすべての OND に対して、同じ属性を持つ同じ BGP プレフィックスをアドバタイズする必要があります。デフォルトでは、Outpost ネットワークはすべてのアップリンク間で (お客様に向けた ) アウトバウンドトラフィックの負荷分散を行います。Outpost 側では、メンテナンスが必要な場合にトラフィックを特定の OND から移行するために、ルーティングポリシーが使用されます。このトラフィック移行を実行し、中断することなくメンテナンスを実行するには、すべての OND でお客様側からの同じ BGP プレフィックスが必要です。お客様のネットワークでメンテナンスが必要な場合は、AS-Path への付加を使用して、特定のアップリンクまたはデバイスからのトラフィックを一時的に移行することをお勧めします。
## ACE を使用した可用性の高いネットワーク接続の推奨プラクティス
4 台以上のコンピューティングラックを備えたマルチラックデプロイでは、集約、コア、エッジ (ACE) ラックを使用する必要があります。これは、オンプレミスネットワークデバイスへのファイバーリンクの数を減らすためのネットワーク集約ポイントとして機能します。ACE ラックは各 Outposts ラックの OND への接続を提供するため、AWS は OND と ACE ネットワークデバイス間の VLAN インターフェイスの割り当てと設定を所有します。
サービスリンクとローカルゲートウェイネットワークの分離されたネットワークレイヤーは、ACE ラックを使用するかどうかにかかわらず引き続き必要です。これは、VLAN ポイントツーポイント (/30 または /31) IP サブネット、および分離された各ネットワークの eBGP ピアリング設定を持つためです。提案されたアーキテクチャは、次の 2 つのアーキテクチャのいずれかに従う必要があります。
![\[2 つのカスタマーネットワークデバイス\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/page-22-two-customer-networking-devices.png)
+ このアーキテクチャでは、お客様は 2 つのネットワークデバイス (CND) を使用して ACE ネットワークデバイスを相互接続し、冗長性を確保する必要があります。
+ 各物理接続について、たとえそれが単一の物理ポートであっても、Outpost とデータセンター間の利用可能な帯域幅を増やすために LAG を有効にする必要があります。また、LAG は 2 つのネットワークセグメントを伝送し、2 つのポイントツーポイント VLAN (/30 または /31) と、ACE と CND 間の eBGP 設定を持ちます。
+ 定常状態では、トラフィックは ACE レイヤーからカスタマーネットワークへの、またはカスタマーネットワークからの Equal-cost multipath (ECMP) パターンに従って負荷分散されます。ACE 全体でのトラフィック分散は 25% です。この動作を可能にするには、ACE と CND 間の eBGP ピアリングで BGP マルチパス/負荷分散が有効になっており、4 つの eBGP ピアリング接続で同じ BGP メトリクスを使用してカスタマープレフィックスがアナウンスされている必要があります。
+ 最適な冗長性を実現し、中断のない OND メンテナンスを可能にするには、次の推奨事項に従うことをお勧めします。
+ カスタマーネットワークデバイスは、Outpost 内のすべての OND に対して、同じ属性を持つ同じ BGP プレフィックスをアドバタイズする必要があります。
+ カスタマーネットワークデバイスは、BGP 属性を変更せずに Outpost から BGP アドバタイズを受信し、BGP マルチパス/ロードバランシングを有効にする必要があります。
![\[4 つのカスタマーネットワークデバイス\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/page-23-four-customer-networking-devices.png)
このアーキテクチャでは、ACE ネットワークデバイスを相互接続するための 4 つのネットワークデバイス (CND) を持つことになります。これにより、2 つの CND アーキテクチャに適用可能な VLAN、eBGP、ECMP などの冗長性と同一のネットワークロジックが提供されます。
# アンカー接続
[Outpost サービスリンク](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html)は、Outpost の親リージョンの特定のアベイラビリティーゾーン (AZ) にあるパブリックアンカーまたはプライベートアンカーのいずれか (両方ではない) に接続します。Outpost サーバーは、サービスリンク IP アドレスからアンカー AZ のアンカーポイントへのアウトバウンドサービスリンク VPN 接続を開始します。これらの接続は UDP と TCP ポート 443 を使用します。AWS は、リージョン内のアンカーポイントの可用性を確保する責任があります。
Outpost サービスリンク の IP アドレスがネットワーク経由でアンカー AZ のアンカーポイントに接続できることを確認する必要があります。サービスリンク IP アドレスは、オンプレミスネットワーク上の他のホストと通信する必要はありません。
パブリックアンカーポイントは、リージョンの[パブリック IP 範囲](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) (EC2 サービス CIDR ブロック内) にあり、インターネットまたは [AWS Direct Connect](https://aws.amazon.com/directconnect/) (DX) パブリック仮想インターフェイス (VIF) 経由でアクセスできます。パブリックアンカーポイントを使用すると、サービスリンクトラフィックはパブリックインターネット上のアンカーポイントに正常に到達できる任意のパスにルーティングできるため、より柔軟にパスを選択できます。
プライベートアンカーポイントを使用すると、IP アドレス範囲をアンカー接続に使用できます。プライベートアンカーポイントは、お客様が割り当てた IP アドレスを使用して、[専用 VPC 内のプライベートサブネット](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#private-connectivity)に作成されます。VPC は Outpost リソースを所有する AWS アカウントで作成され、VPC が使用可能で、適切に設定されていることを確認する必要があります。AWSOrigamiServiceGateway Organizations でセキュリティコントロールポリシー (SCP) を使用して、ユーザーがその仮想プライベートクラウド (VPC) を削除できないようにします。プライベートアンカーポイントには、[Direct Connect プライベート VIF](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/) を使用してアクセスする必要があります。
Outpost とリージョン内のアンカーポイントの間には冗長なネットワークパスを用意し、接続は複数の場所にある別々のデバイスで終了するようにしてください。動的ルーティングは、接続またはネットワークデバイスに障害が発生した場合に、トラフィックを自動的に代替パスに再ルートするように設定する必要があります。1 つの WAN パスに障害が発生しても残りの WAN パスに負荷がかからないように、十分なネットワーク容量をプロビジョニングする必要があります。
次の図は、AWS Direct Connect とパブリックインターネット接続を使用する、アンカー AZ への冗長ネットワークパスがある 3 つの Outposts を示しています。Outpost A と Outpost B は、同じリージョンの異なるアベイラビリティーゾーンにアンカーされています。Outpost A は、リージョン 1 の AZ 1 のプライベートアンカーポイントに接続しています。Outpost B はリージョン 1 の AZ 2 のパブリックアンカーポイントに接続しています。Outpost C はリージョン 2 の AZ 1 のパブリックアンカーに接続します。
![\[AWS Direct Connect とパブリックインターネットアクセスとの高可用性アンカー接続を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/highly-available-anchor-connectivity.png)
Outpost A には、プライベートアンカーポイントに到達するための冗長ネットワークパスが 3 つあります。1 つの Direct Connect の場所では、冗長な Direct Connect 回路を通じて 2 つのパスを使用できます。3 番目のパスは、2 つ目の Direct Connect の場所にある Direct Connect 回路を経由して利用できます。この設計では、Outpost A のサービスリンクトラフィックをプライベートネットワーク上に維持し、パスの冗長性を確保することで、いずれかの Direct Connect 回線の障害や Direct Connect の場所全体の障害にも対応できます。
Outpost B には、パブリックアンカーポイントに到達するための冗長ネットワークパスが 4 つあります。3 つのパスは、Direct Connect 回線と Outpost A が使用する場所にプロビジョニングされたパブリック VIF を介して利用できます。4 つ目のパスは、お客様の WAN とパブリックインターネットを介して利用できます。Outpost B のサービスリンクトラフィックは、パブリックインターネット上のアンカーポイントに正常に到達できる任意のパスを介してルートできます。Direct Connect パスを使用すると、レイテンシーがより安定し、帯域幅の可用性が高くなる可能性があります。一方、パブリックインターネットパスはディザスタリカバリ (DR) や帯域幅増強のシナリオに使用できます。
Outpost C には、パブリックアンカーポイントに到達するための冗長ネットワークパスが 2 つあります。Outpost C は、Outpost A および Outpost B とは異なるデータセンターでデプロイされています。Outpost C のデータセンターには、お客様の WAN に接続する専用回線はありません。代わりに、データセンターには 2 つの異なるインターネットサービスプロバイダー (ISP) が提供する冗長インターネット接続があります。Outpost C のサービスリンクトラフィックは、いずれかの ISP ネットワークを経由してルートされ、パブリックインターネット上のアンカーポイントに到達できます。この設計により、利用可能なあらゆるパブリックインターネット接続でサービスリンクトラフィックを柔軟にルートできます。ただし、エンドツーエンドのパスは、帯域幅の可用性とネットワーク遅延が変動するパブリックサードパーティーネットワークに依存しています。
Outpost とそのサービスリンクアンカーポイント間のネットワークパスは、次の帯域幅の仕様を満たしている必要があります。
+ 500 Mbps - Outpost ラックあたり 1 Gbps の使用可能帯域幅 (例えば、3 ラックの場合、1.5～3 Gbps の使用可能帯域幅)
## 高可用性アンカー接続の推奨プラクティス
+ 各 Outpost とリージョン内のアンカーポイントとの間に冗長なネットワークパスをプロビジョニングします。
+ Direct Connect (DX) パスを使用して、レイテンシーと帯域幅の可用性を制御します。
+ Outpost サービスリンク CIDR ブロックから親リージョンの [EC2 IP アドレス範囲](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)への TCP および UDP ポート 443 が開いている (アウトバウンド) ことを確認します。すべてのネットワークパスでポートが開いていることを確認します。
+ リージョンの CIDR 範囲のサブセットを使用している場合は、ファイアウォールの Amazon EC2 IP アドレス範囲を追跡します。
+ 各パスが帯域幅の可用性とレイテンシーの要件を満たしていることを確認します。
+ 動的ルーティングを使用して、ネットワーク障害を回避するトラフィックのリダイレクトを自動化します。
+ 計画した各ネットワークパスでサービスリンクトラフィックのルーティングをテストして、パスが想定どおりに機能することを確認します。
# アプリケーション/ワークロードのルーティング
Outpost からアプリケーションワークロードには、次の 2 つのパスがあります。
+ サービスリンクパス: [MTU を 1,300 バイト](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links)に制限することに加え、アプリケーショントラフィックが Outposts コントロールプレーントラフィックと競合することを考慮してください。
+ ローカルゲートウェイ (LGW) パス: お客様のローカルネットワークが、オンプレミスと AWS リージョンの両方のアプリケーションへのアクセスを許可することを検討します。
Outpost サブネットルートテーブルを設定して、宛先ネットワークに到達するまでのパスを制御します。LGW を指すルートは、トラフィックをローカルゲートウェイからオンプレミスネットワークに転送します。インターネットゲートウェイ、NAT ゲートウェイ、仮想プライベートゲートウェイ、TGW など、リージョン内のサービスとリソースを指すルートは、[サービスリンク](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html)を使用してこれらのターゲットに到達します。同じ Outpost にある複数の VPC ピアリング接続を使用している場合、VPC 間のトラフィックは Outpost に残り、リージョンに戻るサービスリンクは使用しません。VPC ピアリングの詳細については、「Amazon VPC ユーザーガイド」の「[VPC ピアリングを使用して VPC を接続する](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html)」を参照してください。**
![\[Outpost サービスリンクと LGW ネットワークパスの視覚化を示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/outpost-service-link-and-lgw-network-paths.png)
アプリケーションルーティングを計画する際は、ネットワーク障害時の通常の運用と制限されたルーティングとサービスの可用性の両方を考慮するように注意する必要があります。Outpost がリージョンから切断されている場合、サービスリンクパスは利用できません。
Outpost LGW と重要なオンプレミスのアプリケーション、システム、およびユーザーとの間には、さまざまなパスをプロビジョニングし、動的ルーティングを設定する必要があります。ネットワークパスが冗長化されていると、障害が発生してもネットワークがトラフィックをルートできるようになり、部分的なネットワーク障害が発生しても、オンプレミスのリソースが Outpost で実行されているワークロードと通信できるようになります。
Outpost VPC ルート設定は静的です。サブネットルーティングテーブルは、AWS マネジメントコンソール、CLI、API、およびその他の Infrastructure as Code (IaC) ツールを使用して設定しますが、切断イベント中はサブネットルーティングテーブルを変更できません。ルートテーブルを更新するには、Outpost とリージョン間の接続を再確立する必要があります。通常の運用には、切断イベント時に使用する予定と同じルートを使用してください。
Outpost 上のリソースは、サービスリンクとリージョン内のインターネットゲートウェイ (IGW)、またはローカルゲートウェイ (LGW) パスを介してインターネットにアクセスできます。LGW パスとオンプレミスネットワークを介してインターネットトラフィックをルーティングすると、既存のオンプレミスのインターネット入出力ポイントを使用でき、リージョン内の IGW へのサービスリンクパスを使用する場合と比較して、レイテンシーが低く、MTU が高くなり、AWS のデータ送信料金が削減されます。
アプリケーションをオンプレミスで実行する必要があり、パブリックインターネットからアクセスできるようにする必要がある場合は、アプリケーショントラフィックをオンプレミスのインターネット接続経由で LGW にルーティングして Outpost 上のリソースに到達する必要があります。
Outpost のサブネットは、リージョンのパブリックサブネットのように設定できますが、ほとんどのユースケースでは望ましくない方法です。インバウンドのインターネットトラフィックは AWS リージョン を経由して入ってきて、サービスリンクを経由して Outpost で実行されているリソースにルーティングされます。
応答トラフィックは、次にサービスリンクを介してルーティングされ、AWS リージョン のインターネット接続を経由して戻ります。このトラフィックパターンではレイテンシーが発生する可能性があり、トラフィックが Outpost に向かう途中でリージョンを離れ、リターントラフィックがリージョンを経由してインターネットに出るときに、データ出力の料金が発生します。アプリケーションをリージョンで実行できる場合は、そのリージョンで実行するのが最適です。
(同じ VPC 内の) VPC リソース間のトラフィックは、常にローカルの VPC CIDR ルートをたどり、暗黙的 VPC ルーターによってサブネット間でルーティングされます。
例えば、Outpost で実行されている EC2 インスタンスとリージョン内の VPC エンドポイントの間のトラフィックは、常にサービスリンクを介してルーティングされます。
![\[暗黙的ルーターを介したローカル VPC ルーティングを示す図\]](http://docs.aws.amazon.com/ja_jp/whitepapers/latest/aws-outposts-high-availability-design/images/local-vpc-routing-through-implicit-routers.png)
## アプリケーション/ワークロードのルーティングの推奨プラクティス
+ 可能な場合は、サービスリンクパスの代わりにローカルゲートウェイ (LGW) パスを使用します。
+ LGW パスを介してインターネットトラフィックをルーティングします。
+ Outpost サブネットルーティングテーブルを標準のルートセットで設定します。これらは通常の運用と切断イベントの両方に使用されます。
+ Outpost LGW と重要なオンプレミスアプリケーションリソース間の冗長ネットワークパスをプロビジョニングします。動的ルーティングを使用して、オンプレミスのネットワーク障害を回避するトラフィックのリダイレクトを自動化します。