yamamototis1105’s tech blog

ネットワークを中心とした技術ブログです

AWS ハイブリッド接続のBGPパラメータ設計のポイント

ネットワーク AWS

はじめに

　昨年ご紹介したAWS DirectConnectパートナーのチェックポイントですが、BGPパラメータあたりがフワッとした書きっぷりでしたので、実際どう設計するか整理してみました。
　本記事は、AWSハイブリッド接続のBGPパラメータ設計で必要な情報を纏めています。

  • 本記事で説明すること
    • DirectConnect(PrivateVIF/TransitVIF)上のBGPパラメータ設計
    • Site-to-Site VPN上のBGPパラメータ設計
      ※ Site-to-Site VPN over DirectConnect(TransitVIF/PublicVIF)もコチラへ含まれます。
  • 本記事で説明しないこと
    • DirectConnect(PublicVIF)上のBGPパラメータ設計
    • TGW Connectアタッチメント上のBGPパラメータ設計
    • 仮想ルータ～オンプレミスルータ間のBGPパラメータ設計
    • インターネット上のBGPパラメータ設計
      ※ DirectConnect(PublicVIF)上のBGPパラメータ設計は私が利用しないので割愛します汗
yamamototis1105.hatenablog.com

BGPとは

　「IPネットワーク上で通信するために必要なルート情報を動的に更新するプロトコルの一つ」とだけ覚えとけば、AWS利用上で困らないと思います(NEの風上にも置けぬ奴と言われそうですが...汗)。
公式サイトで詳しくは説明されていますので、ご興味がある方は是非ご覧下さいませ。

aws.amazon.com

BGPパラメータ設計

　BGPトポロジ、BGPメトリック、BGPタイマーの切り口で考えると理解しやすいかなと思います。こちらの切り口で、DirectConnect冗長構成(パートナー機器なし)、DirectConnect冗長構成(パートナー機器あり)、DirectConnect/Site-to-Site VPN冗長構成の各パターンを見ていきたいと思います。

1. BGPトポロジ

　BGPスピーカーにASNを設定し、BGPピアリングを構成します。

DirectConnect冗長構成 (パートナー機器なし)
　TGWのASNは64512、DXGWのASNは64513、ユーザ機器のASNは65000を割り当てています。
DirectConnect冗長構成 (パートナー機器あり)
　パートナー機器のASNはパートナー側で固定化されています。
単一ASNだけでなく複数ASNを経由する場合もあり、パートナーへ確認する必要があります。
DirectConnect/Site-to-Site VPN冗長構成
　Site-to-Site VPNはデフォルトでBGPピアリング over VPNトンネルが冗長化されています。
それ以外、ASNの割り当て方はDirectConnectと変わりありません。

2. BGPメトリック

　BGPピアリングごとのメトリックを設定し、BGPルーティングを制御します。

DirectConnect冗長構成 (パートナー機器なし)
　AS Pathは、メインのユーザ機器に65000、バックアップのユーザ機器に65000 65000を設定し、メインが64513、65000の合計2パス、バックアップが64513、65000、65000の合計3パスになり、AWS→オンプレミス通信はメインパスが優先されます。
　Local Preferenceは、メインのユーザ機器に200、バックアップのユーザ機器に100を設定し、オンプレミス→AWS通信はメインパスが優先されます。
DirectConnect冗長構成 (パートナー機器あり)
　AS Pathは、メインのユーザ機器に65000、バックアップのユーザ機器に65000 65000を設定し、メインが64513、XXXXX、65000の合計3パス、バックアップが64513、YYYYY、65000、65000の合計4パスになり、AWS→オンプレミス通信はメインパスが優先されます。
　Local Preferenceは、メインのユーザ機器に200、バックアップのユーザ機器に100を設定し、オンプレミス→AWS通信はメインパスが優先されます。
DirectConnect/Site-to-Site VPN冗長構成
　Site-to-Site VPN向けルートよりDirect Connect向けルートの方が優先されるため、AS Pathは設定しなくてもAWS→オンプレミス通信はメインパスが優先されます。
　Site-to-Site VPNよりDirect Connectの方がデフォルトMEDが小さいため、Local Preferenceは設定しなくてもオンプレミス→AWS通信はメインパスが優先されます。

3. BGPタイマー

　BGPピアリングごとのタイマーなどを設定し、BGPフェイルオーバータイムを制御します。

DirectConnect冗長構成 (パートナー機器なし)
　タイマー10s/30s、BFD300ms/3回をユーザ機器に設定します。
DirectConnect冗長構成 (パートナー機器あり)
　AWS～パートナー機器間のBGPフェイルオーバータイムは、パートナー機器のタイマーとBFDの設定次第のため、パートナーに確認する必要があります。
DirectConnect/Site-to-Site VPN冗長構成
　BFDは回線品質が安定しないSite-to-Site VPNに設定することを推奨しません。
それ以外、タイマーの設定方法はDirectConnectと変わりありません。

まとめ

　AWSハイブリッド接続のBGPパラメータは、以下の切り口で考えると理解しやすいです。

  • BGPスピーカーにASNを設定し、BGPピアリングを構成します。
  • BGPピアリングごとのメトリックを設定し、BGPルーティングを制御します。
  • BGPピアリングごとのタイマーなどを設定し、BGPフェイルオーバータイムを制御します。

おわりに

　AWS ハイブリッド接続のBGPパラメータを設計される方々にとって、本記事がご参考になりますと幸いです。

ランキング参加中
ネットワーク（Network）

AWS Site-to-Site VPNトンネルエンドポイントのライフサイクル制御機能によるメンテナンステスト

ネットワーク AWS

はじめに

　昨年度リリースされたSite-to-Site VPNトンネルエンドポイントのライフサイクル制御機能ですが、単なるメンテナンス通知・表示・実行の機能でなく、メンテナンステスト機能としての有効性を伝えるために記事を書きました。
（JAWSUG発表内容と被りますが、検証だけでなく事例も書き加えてます。）

aws.amazon.com

機能概要

　2023/3/30に発表された機能で、Site-to-Site VPN のメンテナンス情報が可視化されて制御できるようになりました。主要な機能は以下1～3です。

  1. メンテナンスの対象VPN接続や日時をユーザにメールで通知
  2. 保留中のメンテナンス有無、自動適用日、最終適用日を表示
  3. ユーザの好きなタイミングでメンテナンスを実行 (VPNトンネル置き換え)

機能詳細

　メンテナンスが計画された状態で、(1)「ルーティングされていないVPNトンネルから置き換え」、(2)「ルーティングされているVPNトンネルから置き換え」を実施した結果をまとめてみました。

(1) ルーティングされていないVPNトンネルから置き換え

　メンテナンス済みのトンネル向けのMED値を下げ、メンテナンス済みのトンネルにルーティングするため、通信影響を与えません。

(2) ルーティングされているVPNトンネルから置き換え

　ルーティングされているトンネルを置き換えようとしても、他トンネルにルーティングしてからトンネルを置き換えるため、通信影響を与えません。

注意事項

　VGW(TGW)でIN方向ルーティング制御のためMED値が設定され、CGWでOUT方向ルーティング制御のためWeight値やLocalPreference値を設定した場合、前者より後者の方が優先されます。
　そのため、Weight値やLocalPreference値を設定しない、もしくは同じ値を設定しなければ、メンテナンス時におけるルーティング自動変更が機能せず、通信影響を与えることになります。

　公式サイトのルーティング注記でも、「MED の低いアップトンネルが優先されるようにするには、カスタマーゲートウェイデバイスで、両方のトンネルに対して同じ重みおよびローカル優先設定の値が使用されていることを確認します」と記載されています。

docs.aws.amazon.com

ユースケース

　一見、通信影響を与えないようにメンテナンスできるからありがたい！と思われるかもしれません。
　実は、メンテナンスの自動適用日まで放ったらかしでも、本機能と同様の動作で通信影響を与えずに自動的にメンテナンスされるため、敢えてユーザがメンテナンスしたいケースは絞られると思います。

　具体的なユースケースとしては、(1)「ユーザの好きなタイミングでメンテナンスしたいケース」、(2)「Site-to-Site VPNの疑似メンテナンステストを事前に実施したいケース」などが考えられます。
　個人的には、(2) の使い方が大変有用だと思っています。

(1) ユーザの好きなタイミングでメンテナンスしたいケース

　前述の通り、メンテナンスが通信影響を与えないため、敢えてユーザがメンテナンスのタイミングを制御したいケースは少ないかと思いますが、以下1～3が挙げられます。

  1. VPNトンネルが単一構成で、メンテナンス時に通信断が発生するため、通信断が許容できるタイミングでメンテナンスしたいケース（公式サイト記載ユースケース）
  2. VPNトンネルの状態変化によって、監視アラームが鳴動するなどの影響を受けるため、VPNトンネルの状態変化のタイミングを指定したいケース（公式サイト記載ユースケース）
  3. VPNトンネルは冗長構成だが、万が一ルーティング自動変更が失敗する可能性を考慮し、通信断が許容できるタイミングでメンテナンスしたいケース

(2) 「Site-to-Site VPNのメンテナンステストを実施したいケース」

　メンテナンス時におけるルーティング自動変更は、Site-to-Site VPNを作成するだけで動作するわけでなく、CGWのBGPパラメータによっては上手く動作しない可能性があります。
　今まで疑似的にメンテナンスを発生させられず、パラメータの妥当性をテストできませんでしたが、本機能によってテストできるようになりました（本機能はメンテナンス有無問わず実行可）
　障害時に備えたテストは大切ですが、その他の運用中に起こりうる動作・状態を確認する意味では、こうしたメンテナンス時に備えたテストも大切かと思います。

　有効性が確認できた一例として、メンテナンスの通信影響を与えないようにするため、冗長化されたトンネルのWeight値を違う値から同じ値に変更した場合における事例を紹介します。
　Weight値を変更すること自体は難しいことではありませんが、「本当にメンテナンスが生じた場合に通信影響を与えないだろうか？」といった不安の声もありました。
　その際には、以下1～3の流れで進めることでWeight値の変更妥当性を説明することができました。

  1. Weight値が違う状態でトンネルを置き換え、通信影響を与えることを確認する。
  2. Weight値を違う値から同じ値に変更する。
  3. Weightが同じ状態でトンネルを置き換え、通信影響を与えないことを確認する。

利用手順

　詳細な手順は公式サイトをご覧いただければと思います。本記事ではスクリーンショットと合わせて簡易な手順のみ載せていますので雰囲気を感じる程度にご覧ください。

docs.aws.amazon.com

トンネルエンドポイントのライフサイクル制御の有効化

　Site-to-Site VPN画面にて「アクション」から「VPNトンネルオプションを変更」を選択のうえ、 「トンネルエンドポイントのライフサイクル制御」の「有効にする」をチェックしてください。
※有効化・無効化ともトンネル切断が発生するため注意してください。

メンテナンス情報の表示

　Site-to-Site VPN画面にて保留中のメンテナンス有無、自動適用日、最終適用日など確認できます。 保留中のメンテナンスがある場合、「利用可能」と表示されています。

VPNトンネルの置き換え

　Site-to-Site VPN画面にて「アクション」もしくは「利用可能」から「VPNCトンネルを置き換え」を選択のうえ、 「VPNトンネル外部IPアドレス」から対象トンネルを選択してください。
※トンネル置き換え時はトンネル切断が発生するため注意してください。

まとめ

  • Site to Site VPNトンネルエンドポイントのライフサイクル制御機能を有効化することによって、メンテナンスを通知・表示・実行することができます。
  • 注意事項としては、メンテナンスの通信影響を与えないようにするため、CGWでWeight値やLocalPreferencwe値は設定しない、もしくは同じ値にする必要があります。
  • ユースケースとしては、ユーザが好きなタイミングでメンテナンスしたいケースのほか、メンテナンステストを実施したいケースで有効だと考えられます。

おわりに

　Site-to-Site VPNトンネルエンドポイントのライフサイクル制御機能をご利用される方々にとって、本記事の機能・注意事項・ユースケースがご参考になりますと幸いです。

ランキング参加中
ネットワーク（Network）

AWS TGW Connectアタッチメント接続のCFnカスタムリソース作成

ネットワーク AWS

はじめに

　ここ最近、TGW Connectアタッチメント接続するための検証環境を構築することが多々ありますが、この度CFn提供待ちに痺れを切らして、カスタムリソースを作ったので本記事を書きました。
　カスタムリソースは可読性や保守性を考えると使いどころが難しいですが、もし作成される場合には本記事を一例としてご参考にしていただけますと幸いです。

TGW Connectアタッチメント接続構成

　TGW～仮想アプライアンスをBGP over GRE接続する場合、Connectアタッチメントを利用します。Connectアタッチメントは、以下の流れで作成します。

  1. TGW～VPC(仮想アプライアンスあり)をVPCアタッチメントで接続する
  2. トランスポートアタッチメント(GREトンネルアドレスをルーティングするため)としてVPCアタッチメントを指定し、Connectアタッチメントを作成する
  3. さらにConnectアタッチメント内にConnectピアを作成し、GREおよびVPNを定義する

　以下の構成を作成する場合、TGW、TGWルートテーブル、VPCアタッチメント、ConnectアタッチメントまでCFnカバーされていますが、ConnectピアのみCFnカバーされていない状況です。
　ちなみに、VPCアタッチメントはGREトンネルアドレスをルーティングするためにAttachする必要がありますが、Association & Propagationする必要はありません。



　CFnロードマップ上、2022.06にカバレッジラベル付与、2023.03にResearching遷移、2023.08にComming Soon遷移、と間も無くカバーされる気もしますが、コレばかりは何とも言えないですね...

github.com github.com

カスタムリソースの概要

　それでは、どのようにCFnカバーされていないリソースを構築自動化するのでしょうか。
　CFnはLambdaやSNSを呼び出すカスタムリソースという機能があり、呼び出されたLambdaやSNSで自由度の高いロジックを実装することが可能となっています。
　例えば、CFnカバーされていないConnectピアを作成するLambdaを作成し、カスタムリソースからLambdaを呼び出すといった使い方も考えられます。


　一見すると便利そうですが、IaCの優位点である可読性や保守性が下げてしまう可能性もあります。個人的には、カスタムリソース検討時に以下のチェックポイントで確認するように心掛けてます。

  • 更新頻度はほぼなく繰り返し利用するか
  • サービス提供するため利用者の作業負担を抑えたいか
  • 部分的手動やshell+aws cliで代替できないか

　その他のカスタムリソースに関する詳細な情報は、CloudFormationのユーザガイドをご参照下さい。個人的には、MarketplaceでAMIと一緒に提供されているテンプレートを読む等も勉強になりました。

docs.aws.amazon.com

カスタムリソースの作成

　それでは、以下のミニマム構成(VPC、TGW、EC2、カスタムリソース)を作成していきます。
カスタムリソースは作成時のみ実装し、更新時・削除時が実装できていないためご留意下さい。

VPC

　VPC、Subnet、RouteTableなどを作成します。Route宛先のVPCアタッチメント作成は時間がかかるため、DependsOnにVPCアタッチメントを設定し待機させます。

{
  "Resources" : {
    "Vpc" : {
      "Type" : "AWS::EC2::VPC",
      "Properties" : {
        "CidrBlock" : "10.0.0.0/16",
        "Tags" : [ { "Key" : "Name", "Value" : "vpc" } ]
      }
    },
    "VpcSubnet" : {
      "Type" : "AWS::EC2::Subnet",
      "Properties" : {
        "VpcId" : { "Ref" : "Vpc" },
        "CidrBlock" : "10.0.1.0/24",
        "AvailabilityZone" : { "Fn::Select": [ 0, { "Fn::GetAZs": "" } ] },
        "Tags" : [ { "Key" : "Name", "Value" : "vpc-subnet" } ]
      }
    },
    "VpcRtb" : {
      "Type" : "AWS::EC2::RouteTable",
      "Properties" : {
        "VpcId" : { "Ref" : "Vpc" },
        "Tags" : [ { "Key" : "Name", "Value" : "vpc-rtb" } ]
      }
    },
    "VpcSubnetRouteTableAssociation" : {
      "Type" : "AWS::EC2::SubnetRouteTableAssociation",
      "Properties" : {
        "SubnetId" : { "Ref" : "VpcSubnet" },
        "RouteTableId" : { "Ref" : "VpcRtb" }
      }
    },
    "VpcRtbRoute" : {
      "Type": "AWS::EC2::Route",
      "Properties": {
        "RouteTableId" : { "Ref" : "VpcRtb" },
        "DestinationCidrBlock" : "192.168.1.0/24",
        "TransitGatewayId" : { "Ref" : "Tgw" }
      },
      "DependsOn" : "TgwVpcAttach"
    }
  }
}

TGW

　TGW、RouteTable、VPCアタッチメント、Connectアタッチメントなどを作成します。前述の通り、VPCアタッチメントはAssociation & Propagationしないようにします。

{
  "Resources" : {
    "Tgw" : {
      "Type": "AWS::EC2::TransitGateway",
      "Properties": {
        "AmazonSideAsn" : 64512,
        "DefaultRouteTableAssociation" : "disable",
        "DefaultRouteTablePropagation" : "disable",
        "TransitGatewayCidrBlocks" : [ "192.168.1.0/24" ],
        "Tags" : [ { "Key" : "Name", "Value" : "tgw" } ]
      }
    },
    "TgwRtb" : {
      "Type" : "AWS::EC2::TransitGatewayRouteTable",
      "Properties" : {
        "TransitGatewayId" : { "Ref" : "Tgw" },
        "Tags" : [ { "Key" : "Name", "Value" : "tgw-rtb" } ]
      }
    },
    "TgwVpcAttach" : {
      "Type": "AWS::EC2::TransitGatewayAttachment",
      "Properties": {
        "SubnetIds": [ { "Ref" : "VpcSubnet" } ],
        "TransitGatewayId": { "Ref" : "Tgw" },
        "VpcId": { "Ref" : "Vpc" },
        "Tags" : [ { "Key" : "Name", "Value" : "tgw-vpc-attach" } ]
      }
    },
    "TgwConnectAttach" : {
      "Type": "AWS::EC2::TransitGatewayConnect",
      "Properties": {
        "Options" : { "Protocol" : "gre" },
        "TransportTransitGatewayAttachmentId": { "Ref" : "TgwVpcAttach" },
        "Tags" : [ { "Key" : "Name", "Value" : "tgw-connect-attach" } ]
      }
    },
    "TransitGatewayRouteTableAssociation" : {
      "Type": "AWS::EC2::TransitGatewayRouteTableAssociation",
      "Properties": {
        "TransitGatewayAttachmentId" : { "Ref" : "TgwConnectAttach" }, 
        "TransitGatewayRouteTableId" : { "Ref" : "TgwRtb" }
      }
    },
    "TransitGatewayRouteTablePropagation" : {
      "Type": "AWS::EC2::TransitGatewayRouteTablePropagation",
      "Properties": {
        "TransitGatewayAttachmentId" : { "Ref" : "TgwConnectAttach" }, 
        "TransitGatewayRouteTableId" : { "Ref" : "TgwRtb" }
      }
    }
  }
}

EC2

　EC2、ENI、SecurityGatewayなどを作成します。EC2はMarketplaceからCatalyst 8000Vを起動し、ユーザーデータでGREおよびBGP設定を行います。

{
  "Resources" : {
    "RouterSg" : {
      "Type" : "AWS::EC2::SecurityGroup",
      "Properties" : {
        "GroupName" : "router-sg",
        "GroupDescription" : "router-sg",
        "VpcId" : { "Ref" : "Vpc" },
        "SecurityGroupIngress" : [ { "IpProtocol" : "-1", "FromPort" : "-1",  "ToPort" : "-1",  "CidrIp" : "10.0.0.0/8" } ],
        "SecurityGroupEgress" : [ { "IpProtocol" : "-1", "FromPort" : "0", "ToPort" : "65535", "CidrIp" : "0.0.0.0/0" } ],
        "Tags" : [ { "Key" : "Name", "Value" : "router-sg" } ]
      }
    },
    "RouterEni" : {
      "Type" : "AWS::EC2::NetworkInterface",
      "Properties" : {
        "GroupSet" : [ { "Ref" : "RouterSg" } ],
        "SubnetId": { "Ref" : "VpcSubnet" },
        "PrivateIpAddress" : "10.0.1.254",
        "SourceDestCheck" : "false",
        "Tags" : [ { "Key" : "Name", "Value" : "router-eni" } ]
      }
    },
    "Router" : {
      "Type" : "AWS::EC2::Instance",
      "Properties" : {
        "InstanceType" : "t3.medium",
        "ImageId" : { "Fn::FindInMap" : [ "RouterAmi", { "Ref" : "AWS::Region" }, "AmiId" ] },
        "NetworkInterfaces": [ { "DeviceIndex": "0", "NetworkInterfaceId": { "Ref" : "RouterEni" } } ],
        "UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
          "ios-config-1=\"interface GigabitEthernet1\"\n",
          "ios-config-2=\" ip address 10.0.1.254 255.255.255.0\"\n",
          "ios-config-3=\"interface Tunnel1\"\n",
          "ios-config-4=\" ip address 169.254.6.1 255.255.255.248\"\n",
          "ios-config-5=\" tunnel source GigabitEthernet1\"\n",
          "ios-config-6=\" tunnel destination 192.168.1.1\"\n",
          "ios-config-7=\"ip route 192.168.1.0 255.255.255.0 10.0.1.1\"\n",
          "ios-config-8=\"router bgp 65000\"\n",
          "ios-config-9=\" timer bgp 10 30\"\n",
          "ios-config-10=\" neighbor 169.254.6.2 remote-as 64512\"\n",
          "ios-config-11=\" neighbor 169.254.6.2 ebgp-multihop\"\n",
          "ios-config-12=\" neighbor 169.254.6.3 remote-as 64512\"\n",
          "ios-config-13=\" neighbor 169.254.6.3 ebgp-multihop\"\n"
        ] ] } },
        "Tags" : [ { "Key" : "Name", "Value" : "router" } ]
      }
    }
  }
}

カスタムリソース

　Lambda、Role、カスタムリソースなどを作成します。LambdaはBoto3でConnectピアを作成し、Roleは最小権限の原則よりCloudWatchログ出力、Connectピア作成のみ認可します。

{
  "Resources" : {
    "TgwConnectPeerCreatorRole" : {
      "Type" : "AWS::IAM::Role",
      "Properties" : {
        "AssumeRolePolicyDocument" : {
          "Version": "2012-10-17",
          "Statement": [ {
            "Effect": "Allow",
            "Principal": { "Service" : [ "lambda.amazonaws.com" ] },
            "Action": [ "sts:AssumeRole" ]
          } ]
        },
        "Path" : "/",
        "ManagedPolicyArns" : [ "arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole" ],
        "Policies" : [ {
          "PolicyName": "TgwConnectPeerCreatorPolicy",
          "PolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [ {
              "Effect": "Allow",
              "Action": [ "ec2:CreateTransitGatewayConnectPeer" , "ec2:CreateTags" ],
              "Resource": "*"
            } ]
          }
        } ]
      }
    },
    "FunctionCreateTgwConnectPeer" : {
      "Type" : "AWS::Lambda::Function",
      "Properties" : {
        "Code" : {
          "ZipFile" : { "Fn::Join": [ "", [
            "import json\n",
            "import boto3\n",
            "import cfnresponse\n",
            "def lambda_handler(event, context):\n",
            "  try:\n",
            "    client = boto3.client('ec2')\n",
            "    response = client.create_transit_gateway_connect_peer(\n",
            "      TransitGatewayAttachmentId='" , { "Ref" : "TgwConnectAttach" } , "',\n",
            "      TransitGatewayAddress='192.168.1.1',\n",
            "      PeerAddress='10.0.1.254',\n",
            "      BgpOptions={'PeerAsn':65000},\n",
            "      InsideCidrBlocks=['169.254.6.0/29'],\n",
            "      TagSpecifications=[{\n",
            "        'ResourceType':'transit-gateway-connect-peer',\n",
            "        'Tags':[{'Key':'Name','Value':'tgw-connect-attach-peer'}],\n",
            "      }],\n",
            "      DryRun=False\n",
            "    )\n",
            "    cfnresponse.send(event, context, cfnresponse.SUCCESS, {})\n",
            "  except Exception as e:\n",
            "    cfnresponse.send(event, context, cfnresponse.FAILED, {})"
          ] ] }
        },
        "Handler": "index.lambda_handler",
        "Role": { "Fn::GetAtt" : [ "TgwConnectPeerCreatorRole", "Arn" ] },
        "Runtime": "python3.9",
        "Timeout": 60
      }
    },
    "CustomCreateTgwConnectPeer" : {
      "Type" : "Custom::FunctionCreateTgwConnectPeer",
      "Properties" : {
        "ServiceToken" : { "Fn::GetAtt" : [ "FunctionCreateTgwConnectPeer", "Arn" ] }
      }
    }
  }
}

つまづきポイントと解決方法

　テンプレートは直ぐに作成できたわけでなく、スタック作成・更新・削除を繰り返し試行することで作成できました。ここでは自らのつまづきポイントと解決方法をご紹介します。

CloudFormation/Lambdaのコーディング

　今日びググったら多くのサンプルを手に入れることは容易いですが、マイナーな設定と遭遇した場合は王道な調査方法が分かってないと立往生します。
　苦労したポイントは、CFnのリソースの構造、IAMポリシーのアクション、Boto3のメソッドの引数あたりですが、下記サイトで解決することができました。

CloudFormation/Lambdaのトラブルシュート

　大抵CloudFormationはCloudFormationイベント、LambdaはCloudWatchログを確認することにより問題判明できてましたが、それでも理解不能なエラーメッセージは出てきます。
　その時に解決の糸口になったのがCloudTrailイベント履歴でした。一つ一つのAPIログが確認でき、CloudWatchログより有益な情報が得られる場合がありました。

まとめ

　Connectピアのカスタムリソースを作成し、Connectアタッチメント接続がフル自動化できました。 カスタムリソースは可読性や運用性が失われる可能性もあるため十分検討したうえでご利用下さい。

　今回ご紹介したコードは下記ページをご参照下さいませ。

github.com

おわりに

　AWS TGW Connectアタッチメント接続に限らずカスタムリソースを利用される方にとって、本記事がご参考になりますと幸いです。

ランキング参加中
ネットワーク（Network）

AWS Network ManagerによるBGPモニタリング

ネットワーク AWS

はじめに

　AWSにおけるネットワークモニタリングはサービス毎にメトリクスやログが充実しているものの、BGPモニタリングについては少し物足りないなと感じてました。
　この度、AWS blogでNetwork ManagerによりBGPのネイバーやルートの状態変化を監視する方法が公開されてましたのでご紹介します（もしかすると以前より実装されてたかもですが汗）

aws.amazon.com

AWSにおけるネットワークモニタリングの課題

　AWSにおけるネットワークモニタリングは、上位レイヤーのサービスでは固有のメトリクスやログが提供される一方、下位レイヤーのサービスではトラフィックのパケット数/バイト数やBPS/PPSなどの情報のみ提供されるケースが多く見受けられます。
　しかし、構築時や運用時におけるトラブルシュートなどを考えた場合には、例え下位レイヤーのサービスでも、VPN/BGPのトンネル/ネイバーやルートなどの状態変化は正確な事象把握のうえで是非確認したいポイントとなってきます。

　VPNについては、Site-to-SiteVPNのメトリクスでトンネル状態変化を検知可能かつ、2022年8月19日リリースのログ出力機能でIKEフェーズや詳細なメッセージなども確認できる一方、
　BGPについては、ネイバーやルートの状態変化を検知する方法がなく、詳細な情報を確認したい場合はサポートへ問い合わせるしかないのが現状でした。

aws.amazon.com

AWS Network Managerによる検知と対処

　TGWでBGPのメトリクスやログを確認できませんが、Network ManagerでグローバルネットワークにTGWを登録することでBGPのイベントを監視できるようになりました。
　詳細なイベントの種類や説明は以下へ記載してます（トポロジ更新イベントは本記事のスコープから外れるため割愛します）

ステータス更新イベント

イベント説明
VPN-CONNECTION-IPSEC-DOWNVPNのIPsecトンネルがダウンした
VPN-CONNECTION-IPSEC-UPVPNのIPsecトンネルがアップした
VPN-CONNECTION-BGP-DOWNVPNのBGPネイバーがダウンした
VPN-CONNECTION-BGP-ESTABLISHVPNのBGPネイバーがアップした
CONNECT_PEER_BGP_DOWNTGWのConnect PeerのBGPネイバーがダウンした
CONNECT_PEER_BGP_UPTGWのConnect PeerのBGPネイバーがアップした

ルーティング更新イベント

イベント説明
CONNECT_PEER_DELETEDTGWのConnect Peerが変更された
TGW-ROUTE-INSTALLEDTGWでルートが作成された
TGW-ROUTE-UNINSTALLETGWでルートが削除された
docs.aws.amazon.com

AWS Network Managerの検証

　AWS blogやgithubにて、Network Managerによる検知や対処の手順や資材が紹介されてましたので、そちらを参考にして、下図の通り環境構築のうえ検証してみました。
　以降、ポイントとなるVyOS、Network Manager、EventBridgeのみ記載しています。

Network Managerの検証構成

VyOS作成 (VPNおよびBGPで接続するため)

  • Maketplaceにて、以下のイメージから起動します。
    • イメージは「VyOS Universal Router for AWS (Standard Support) - Pay-as-You-Go」
    • バージョンは「1.3.5」
  • Site-to-Site VPNにて、以下の設定をダウンロードします。
    • ベンダーは「Vytta」
    • プラットフォームは「Vyatta Network OS」
    • ソフトウェアは「Vyatta Network OS 6.5+」
    • IKEバージョンは「ikev1」
  • 構成やバージョンの違いにより、設定を以下のように修正し、VyOSに流し込みます。
修正前修正後
set vpn ipsec site-to-site peer x.x.x.x local-address '<Public-IP-of-EIP>'set vpn ipsec site-to-site peer x.x.x.x local-address '<Private-IP-of-ENI>'
set protocols bgp 6xxxx neighbor x.x.x.x soft-reconfiguration 'inbound'set protocols bgp 6xxxx neighbor x.x.x.x address-family ipv4-unicast soft-reconfiguration 'inbound'
set protocols bgp 6xxxx network x.x.x.x/xset protocols bgp 6xxxx address-family ipv4-unicast network x.x.x.x/x

Network Manager登録

  • Network Managerにて「グローバルネットワークを作成」を押します。
    「グローバルネットワークにコアネットワークを追加する」のチェックは外すこと！
  • Network Manager > グローバルネットワーク > (作成済みグローバルネットワーク) > Transit Gatewayネットワーク > 概要にて「TransitGatewayを登録」を押します。
  • Network Manager > グローバルネットワーク > (作成済みグローバルネットワーク) > Transit Gatewayネットワーク > イベントにて「CloudWatch Logs Insightsをオンボード」を押します。

EventBridge作成

  • EventBridgeにて「ルールを作成」を押します。
    • イベントソースは「AWSのサービス」
    • イベントのサービスは「Network Manager」
    • イベントタイプおよびイベントパターンは下表の通り。
    • ターゲットタイプは「AWSのサービス」
    • ターゲットのサービスは「SNSトピック」
    • ターゲットのトピックは「(作成済みトピック※自分宛メール)」
イベントタイプイベントパターン
Network Manager Status Update{
    "source": ["aws.networkmanager"],
    "detail-type": ["Network Manager Status Update"]
}
Network Manager Routing Uppdate{
    "source": ["aws.networkmanager"],
    "detail-type": ["Network Manager Routing Update"]
}

テスト

  • VyOSにて「reset ip bgp all」コマンドですべてのBGPネイバーをリセットすることにより、Network ManagerのイベントやSNSからのメールで下記メッセージが確認できました。
    （レコードを展開することにより、例えば追加されたルートなどの詳細も確認できました。）
    • 「BGP for a VPN connection has been established.」
    • 「BGP for a VPN connection has gone down.」
    • 「Routes in one or more Transit Gateway route tables have been installed.」
    • 「Routes in one or more Transit Gateway route tables have been uninstalled.」
Network Managerのイベント

今後の期待

　Network ManagerはTGWやCloudWANが対象であり、VGWやDXGWなどは対象となってません。
今後は同様のイベントが監視できるように、その他ゲートウェイも対象となることに期待！

まとめ

　Network ManagerによりBGPネイバーやルートのなど状態変化が検知できるようになりました。
今まで以上に詳細な情報が確認でき、トラブルシュートなどで役立つものと思われます。

おわりに

　AWSのネックワークモニタリングをご検討の方にとって、本記事の課題・対処がご参考になりますと幸いです。

ランキング参加中
ネットワーク（Network）

AWS ネットワーク仮想アプライアンスのHA構成パターン

ネットワーク AWS

はじめに

　AWSサービスが拡充される中、ネットワーク仮想アプライアンスを利用するケースは減ってますが、顧客要件次第でネットワーク仮想アプライアンスを利用しなければならないケースはあります。
　本記事では、このようなネットワーク仮想アプライアンスのHA構成パターンに関して記載します。

ネットワーク仮想アプライアンスのユースケース

　そもそもネットワーク仮想アプライアンスはどのようなケースで利用するのでしょうか。
　運用負荷軽減の観点より、AWSサービスは積極的に利用することをお勧めしますが、要件が充足できない場合はネットワーク仮想アプライアンスでカバーします。

　以下に設計項目ごとのAWSサービスの機能充足状況を記載しております。
　最近ではAWSサービスで暗号化も充足してますが、帯域制御/優先制御やSD-WAN機能等は充足しておらず、ネットワーク仮想アプライアンスを利用せざるを得ないです。

設計項目AWSサービス機能充足
暗号化Site-to-Site VPN、Client VPN、MACsec○
帯域制御/優先制御該当なし×
負荷分散Elastic Load Balancer○
アドレス変換NAT Gateway○
アクセス制御SecurityGroup、NetworkACL、Network Firewall○
その他SD-WAN機能等△

ネットワーク仮想アプライアンスの課題

　ネットワーク仮想アプライアンスはMarketplaceなどでEC2インスタンスとして提供されているため、AWSサービスとして冗長化されておらず、ユーザが冗長化しなければなりません。
　一方、オンプレミスとAWSは「ルートテーブル～アプライアンス間でBGPなどのダイナミックルーティングが利用できない」や、「アプライアンス間でVRRPなどの冗長化プロトコルが利用できない」などの違いがあります。
　このような違いを踏まえて、どのように冗長化されたネットワーク仮想アプライアンスの系切り替えを行うかがポイントになります。

ネットワーク仮想アプライアンスのHA構成

　以下の1～6の方法で課題を解決でき、ネットワーク仮想アプライアンスのHA構成を実現できます。
　これらの中で、当方がネットワークエンジニアのため贔屓目で見てる節も多々あると思いますが、BGP更新はシンプルのため大変お勧めです。

　　　1．Lambdaによるルートテーブル更新
　　　2．アプライアンスによるルートテーブル更新
　　　3．Site-to-Site VPNによるBGP更新
　　　4．TGW ConnectアタッチメントによるBGP更新
　　　5．CloudWAN ConnectアタッチメントによるBGP更新
　　　6．NLBによるターゲット切り替え

1．Lambdaによるルートテーブル更新

　EventBridgeで定期的にトリガーしているLambdaが主系アプライアンスを確認のうえ、異常な場合はルートテーブルのターゲットを副系アプライアンスに切り替えます。
　例えば、YAMAHA vRXの場合は主系アプライアンスのトンネル状態を監視し、CISCO Merakiの場合は主系アプライアンスのヘルス状態を監視し、ルートテーブル更新APIを実行します。
　EventBridgeの実行間隔が最短1分間、切断時間が最長1分間以上かかりますので、信頼性要件を充足するかの確認が必要となります[1][2]。

[1] YAMAHA vRX - Example of IPsec-Encrypted Hybrid Connection Setup
　https://network.yamaha.com/setting/virtual_router/aws/vrx_ipsec_redundancy
[2] Cisco Meraki Virtual MX - Quick Start Reference Deployment
　https://aws-quickstart.github.io/quickstart-cisco-meraki-sd-wan-vmx/

2．アプライアンスによるルートテーブル更新

　副系アプライアンスが主系アプライアンスを確認のうえ、異常な場合はルートテーブルのターゲットを副系アプライアンスに切り替えます。
　例えば、CISCO Catalyst 8000vの場合はBFDポーリング監視し、Fortinet Fortigate-VMの場合はハートビート監視し、ルートテーブル更新APIを実行します。
　Catalyst 8000vの場合はHAパッケージの別途インストールが必要となり、Fortigate-VMの場合は多くのENIが作れる上位のインスタンスタイプが必要となります[3][4]。


[3] Cisco Catalyst 8000V - Overview of High Availability
　https://www.cisco.com/c/en/us/td/docs/routers/C8000V/HighAvailability/c8000v-high-availability-configuration-guide/overview.html
[4] Fortinet Fortigate-VM - Deploying FortiGate-VM active-passive HA AWS between multiple zones
　https://docs.fortinet.com/document/fortigate-public-cloud/7.4.0/aws-administration-guide/229470/deploying-fortigate-vm-active-passive-ha-aws-between-multiple-zones

3．Site-to-Site VPNによるBGP更新

　VGWもしくはTGWと主系・副系アプライアンス間でSite-to-Site VPNを作成し、IPsecトンネル上を流れるBGPキープアライブで通信断を検知のうえルーティングテーブルを更新します[5][6]。


[5] Cisco Catalyst 8000V - Deploying Cisco Catalyst 8000V Edge Software on Amazon Web Services
　https://www.cisco.com/c/ja_jp/td/docs/routers/C8000V/AWS/deploying-c8000v-on-amazon-web-services/deploy-transit-vpc-with-transit-gateway-aws.html
[6] AWS - Getting started with AWS Site-to-Site VPN
　https://docs.aws.amazon.com/ja_jp/vpn/latest/s2svpn/SetUpVPNConnections.html

4．TGW ConnectアタッチメントによるBGP更新

　TGWと主系・副系アプライアンス間でConnectアタッチメントを作成し、GREトンネル上を流れるBGPキープアライブで通信断を検知のうえルーティングテーブルを更新します[7][8]。


[7] Fortinet Fortigate-VM - SD-WAN Transit Gateway Connect
　https://docs.fortinet.com/document/fortigate-public-cloud/7.4.0/aws-administration-guide/14501/sd-wan-transit-gateway-connect
[8] AWS - Transit Gateway Connect attachments and Transit Gateway Connect peers
　https://docs.aws.amazon.com/ja_jp/vpc/latest/tgw/tgw-connect.html

5．CloudWAN ConnectアタッチメントによるBGP更新

　CloudWANと主系・副系アプライアンス間でConnectアタッチメントを作成し、BGPキープアライブで通信断を検知のうえルーティングテーブルを更新します[9][10]。


[9] Cisco Meraki Virtual MX - Partner Solution Deployment Guide
　https://aws-ia.github.io/cfn-ps-cisco-meraki-vmx-cloudwan/
[10] AWS - Getting started with AWS Cloud WAN
　https://docs.aws.amazon.com/ja_jp/network-manager/latest/cloudwan/cloudwan-getting-started.html

6．NLBによるターゲット切り替え

　NLBのターゲットのヘルス状態を監視し、異常な場合はターゲットを切り替えます。
　NLBはエンドノードを切り替えるものでリレーノードを切り替えられません。そこで、エンドノードのアドレスをNATのうえリレーノードに持たせることで、NLBでリレーノード切り替えを実現します。
　(ALBはHTTP/HTTPS/gRPC通信のみ、GWLBはGENEVE対応がレアのため割愛)


まとめ

  • AWSサービスを可能な限り利用しつつも、帯域制御/優先制御やSD-WAN構成などの要件次第でネットワーク仮想アプライアンスを利用しなければならないケースがあります
  • VRRPなどの冗長化プロトコルやBGPなどのダイナミックルーティングが利用できない仕様に対し、系切り替えをどうするかの課題があります
  • AWSサービスを用いたルーティング制御により、ネットワーク仮想アプライアンスのHA構成を実現できます

おわりに

　AWS ネットワークでネットワーク仮想アプライアンスをお使いの方にとって、本記事の課題・解決策がご参考になりますと幸いです。

ランキング参加中
ネットワーク（Network）

AWS ハイブリッドクラウドの不安定事象やサイレント障害の検知および自動対処

ネットワーク AWS

はじめに

　ネットワークは機器筐体やリンクなどの障害でルートが切り替わる設計にも関わらず、ハードエラーやソフトエラーなどによる不安定事象やサイレント障害を検知できないため、ルートが切り替わらないケースがしばしばあります。

　ハイブリッド接続も例外ではないですが、2023年12月22日に検知の一助となるNetwork Monitor機能が公開されましたので、本機能を用いてどのような検知や対処が可能なのか、やってみた気付きなどをまとめてみました。

aws.amazon.com

不安定事象やサイレント障害の問題

　AWS DirectConnectやAWS Site-to-Site VPN上で利用されるBGPは、再送やタイムアウト機能により一時的な通信断が発生しても回復を試みる仕様になっています。
　一時的な通信断が頻発した場合、業務通信影響は生じているものの、BGPはエラーと認識しない程度であれば、ルート切り替わりどころか検知すらされない可能性があります。

　AWS DirectConnectやAWS Site-to-Site VPNのメトリクスであるスループット(BPS/PPS)などは正常な状態でも増減しうるため、一時的な通信断頻発といった異常な状態かどうかの判断が難しいです。
　静的な閾値のほか動的な異常検出機能を用いる選択肢もありますが、不規則なトラフィックの場合は誤検知が増えてしまい、異常検知のメリットより運用負担のデメリットの方が高まります。

docs.aws.amazon.com

Network Monitorによる検知および対処

　Network MonitorはAWSからオンプレミスへのICMP/TCPポーリングを行って、パケット損失やRTTのメトリクスを提供します。閾値超過が異常状態へ直結するため、検知のうえで有効なメトリクスです。
　このようなメトリクスを用いて、CloudWatchアラームで異常を検知し、EventBridgeで中継のうえ、LambdaでDirectConnectのBGPフェイルオーバーをトリガーする対処が考えられます。

やってみた

　公式blogおよびgithubにて、検知および自動対処の手順や資材が紹介されてましたので試しました。 原則は手順通りですが、今回は単一DX構成のため一部修正してますのでご了承下さい。

aws.amazon.com
github.com

Network Monitor作成

　CloudWatch > ネットワークモニタリング > Network Monitorへアクセスし、モニターを作成します。

  • モニター名は、任意の文字列を記入します。
  • 集計期間は、30秒もしくは60秒を選択します。
  • サブネットは、送信元のサブネットを選択します(ENIやSGは自動生成されます)。
  • IPアドレスは、送信先のIPアドレスを記入します。
  • プロトコルは、ICMPもしくはTCPを選択します(TCPの場合はポート番号も記入します)。
  • パケットサイズは、56～8500(byte)を記入します。
  • パケット損失、RTTなどが取得・表示できていたらOKです。
    監視機能だけでもお手軽に使えますので、テストなどで重宝しそうです。

SNS作成

　SNS >トピックへアクセスし、トピック・サブスクリプションを作成します。

  • タイプは、スタンダードを選択します。
  • トピック名は、任意の文字列を記入します。
  • プロトコルは、Eメールを選択します。
  • エンドポイントは、任意のEメールアドレスを記入します。
    確認メールのConfirm subscriptionをクリックするまで有効化されません。

CloudWatchアラーム作成

　Cloudwatch > アラーム > すべてのアラームへアクセスし、アラームを作成します。

  • メトリクスは、AWS/NetworkMonitor > Monitor,Prove > PacketLossもしくはRTTを選択します。
  • 条件は、任意の演算子と閾値、データポイントを選択・記入します。
  • アクションは、アラームをトリガーとして作成済みトピックへの通知を選択します。
  • アラーム名は、BGPフェイルオーバーしたいVIF IDを記入します。
    前述の資材を用いる場合、上記以外のアラーム名は正しく動かない可能性があります。

Lambda作成

　Lambda > 関数へアクセスし、関数を作成します。

  • 関数名は、任意の文字列を記入します。
  • ランタイムは、Python3.9を選択します。
  • コードは、前述の資材(aws-dx-failover/python/dx-failover.py)より転記します。
    今回は単一DX構成のため、110～112行目の残VIF数のチェックをコメントアウトします。
  • 設定 > アクセス権限 > 実行ロールは、インラインポリシを追加します。
    インラインポリシは、前述の資材(aws-dx-failover/json/lambda-iam-policy.json)より転記します。
    resourcesオブジェクト内のVIF IDおよび作成済みトピックのARNを更新します。
  • 設定 > アクセス権限 > リソースベースのステートメントは、アクセス権限を追加します。
    アクセス権限は、以下の内容で作成します。※あらかじめEventBridge設定が必要。
    • サービスは、EventBridge (CloudWatch Events)を選択します。
    • ステートメントIDは、任意の文字列を記入します。
    • プリンシパルは、events.amazonaws.comを記入します。
    • ソースARNは、作成済みルールのARNを記入します。
    • アクションは、lambda:InvokeFunctionを記入します。
  • 設定 > 環境変数は、以下の内容で編集します。
    • EMAILは、任意のEメールアドレスを記入します。
    • FAILOVERは、BGPフェイルオーバーしたい時間(分)を記入します。
    • MINVIFSは、VIF最小値を記入します。今回は単一DX構成のため、0を記入します。
    • SNSARNは、作成済みトピックのARNを記入します。
    • VIFLISTは、BGPフェイルオーバーしたいVIF IDを記入します。

EventBridge作成

　EventBridge > バス > ルールへアクセスし、ルールを作成します。

  • ルール名は、任意の文字列を記入します。
  • ルールタイプは、イベントパターンを持つルールを選択します。
  • イベントパターンは、前述の資材(aws-dx-failover/json/event-rule.json)より転記します。
    resourcesオブジェクト内の作成済みアラームのARNを更新します。
  • ターゲットは、AWSのサービス、Lambda関数、作成済みLambda関数名を選択します。

テスト実行

　メトリクスの閾値調整によって障害を疑似的に発生させ、自動的にBGPフェイルオーバーを実行することが確認できました。

　もし上手くいかない場合には、CloudWatchアラーム履歴やCloudWatchログで問題のポイントや内容を確認しましょう。

まとめ

　AWS ハイブリッドクラウドの不安定事象やサイレント障害に対して、Network Monitorによる検知、自動的なBGPフェイルオーバーによる対処が有効です。

おわりに

　AWS ハイブリッドクラウドの不安定事象やサイレント障害でお悩みの方にとって、本記事の検知および対処がご参考になりますと幸いです。

ランキング参加中
ネットワーク（Network）

AWS セキュリティグループの落とし穴と新機能による対処策

ネットワーク AWS

はじめに

　AWS EC2インスタンスのインスタンスタイプは、どのような観点で選択されているでしょうか。CPU、メモリ、ネットワークパフォーマンス、用途によりENI数も確認されるかもしれません。

　本記事では、ネットワークパフォーマンスの中で帯域幅やPPS（Packet-per-second）と同じく指標の一つである、セキュリティグループの接続追跡数について取り扱いたいと思います。

セキュリティグループの接続追跡

　セキュリティグループは言わずと知れた、プロトコル、ポート番号（TCP/UDPのみ）、IPアドレスなどを用い、VPCを流れる通信を制御するファイアウォール機能です。
　ファイアウォール機能はステートフルなチェックを実現するためにコネクションをテーブルに保持し、この動作をセキュリティグループの接続追跡と呼んでいます。

追跡される接続追跡されない接続
  • 行きがAnyアドレスかつ帰りがAnyポートで
    許可されたTCP/UDPトラフィック
  • ただし、以下の手段で確立された接続は除く
docs.aws.amazon.com

接続追跡数オーバーの問題

　接続追跡数の最大値はインスタンスタイプで決まり、Linux等はメトリクスで確認できます。
　"Linux等" がネットワークエンジニア泣かせで、仮想アプライアンス等はメトリクスで確認できず、気付かない内に接続追跡数の最大値へ引っかかりパケットドロップしたケースもありました。
　帯域幅やPPSであれば、仮想アプライアンス上で確認するなどで代替できる場合もあります。

メトリクス説明
bw_in_allowance_exceededインバウンド帯域幅オーバーによるキューまたはドロップ数
bw_out_allowance_exceededアウトバウンド帯域幅オーバーによるキューまたはドロップ数
conntrack_allowance_exceeded接続追跡数オーバーによるドロップ数
conntrack_allowance_available確立できる残り接続追跡数（Nitroインスタンスのみ）
linklocal_allowance_exceededPPSオーバーによるドロップ数（リンクローカルサービスアクセス）
pps_allowance_exceededPPSオーバーによるドロップ数
docs.aws.amazon.com

接続追跡数オーバーへの対処

　今までインスタンスタイプを変更し、接続追跡数の最大値を増やすしか手段が無かったですが、接続追跡数を抑える手段として2023年11月20日に接続タイムアウトを変更する機能が実装されました。
　通常のファイアウォールと同じですが、サービスのタイムアウトより小さい値が設定されてしまうと、想定されていないコネクション切断が生じますのでご注意下さい。

aws.amazon.com

接続タイムアウトの変更方法

　上記の記事にて、セキュリティグループの接続追跡や変更可能なNitroインスタンスに関するリンクはあるものの肝心の変更方法は見つけられらず。
　re:Inventで公表されたAmazon Qへ質問したところ、セキュリティグループ画面で変更しろとの回答でしたが、実際の画面で見つけられず。


　Step4. でインバウンドorアウトバウンドルール編集を選択しても、Step5. の接続追跡のタイムアウトを設定できるセクションはありませんでした。
　ふと、セキュリティグループ画面じゃなくENI画面かも？と確認すると、、、見つかりました！Amazon Qもプレビュー版なので今後楽しみですね。




（TCP established timeoutのデフォルト値が432000秒=5日間は長いですね...）

まとめ

  • セキュリティグループの接続追跡数オーバーによりパケットドロップが生じる可能性があります。
  • 対処はインスタンスタイプのスケールアップのほか接続タイムアウトの変更があります。
  • 接続タイムアウトはセキュリティグループ画面でなくENI画面で変更できます。

おわりに

　AWS ネットワークでトラブルシュートされる方にとって、本記事の問題・対処がご参考になりますと幸いです。

ランキング参加中
ネットワーク（Network）