AWS Advanced Networking(ANS-C01)で出題されるAWSサービスのまとめ

勉強AWS,勉強,資格

はじめに

前回の記事でAWS Certified Advanced Networking – Specialty(ANS-C01)の受験体験記を書きました。

今回は、ANS-C01の出題範囲であるAWSネットワークサービスについてまとめます。※当方が勉強中にメモした内容です。

  • Amazon VPC
  • Amazon Route 53
  • AWS Direct Connect
  • AWS Site-to-Site VPN
  • Elastic Load Balancing
  • AWS Gateway Load Balancer
  • Amazon CloudFront
  • AWS Global Accelerator

なお、上記のサービスはANS-C01のメインとなるサービスではありますが、実際の出題範囲はもう少し広いです。詳しくはこちらのAWS公式試験ガイドにてご確認ください。

Amazon VPC

サブネット

  • パブリックサブネット
    インターネットゲートウェイ等を経由しインターネットに通信ができるサブネット。パブリックサブネットもプライベートアドレスが付与されている。
  • プライベートサブネット
    インターネットとは通信しないプライベートなサブネット。ただし、Instance等がOSバージョンアップなどでインターネットと通信したいときはパブリックサブネットにNATゲートウェイを設けて通信可能になる。
  • VPCで使えるアドレスはRFC1918(プライベートアドレス10.0.0.0/8、172.16.0.0/20、192.168.0.0/16)とRFC6598(100.64.0.0/10)。
  • サブネットで利用できないIPアドレスは始まりから4個目のIPまで、及び最後のIP。(下記の例は第四オクテットが0で/24の場合)
    .0 ネットワークアドレス
    .1 VPCルータ
    .2 Amazon提供のDNSサーバ(Route53 Resolver)
    .3 AWSで予約
    .255ブロードキャストアドレス
    ※169.254.169.253でRoute53 Resolverをlookupすることも可能

セキュリティグループ

  • ステートフルなFirewall
  • デフォルトではインバウンド全拒否、アウトバウンド全許可
  • インスタンス単位で適用する

ネットワークACL

  • ステートレスなFirewall
  • デフォルトではインバウンド全許可、アウンバウンド全許可
  • サブネット単位で適用する
  • ルールは上から評価される。

Ingress Routing

  • インターネットゲートウェイやVGW等に対するアウトバウンド、インバウンド双方のトラフィックを特定のEC2インスタンスのENIに向けることができる。例えば、IDS/IPSのインスタンスにパケットを向けるようなことができる。

DHCP機能

  • インスタンスへのIP設定はDHCP。固定設定でも実際はDHCPで割り当てている。

DNS機能

  • Enable DNS resolution設定
    →基本Yesで有効。Noで無効にするとVPCでDNS機能が無効になる。
  • Enable DNS hostname
    →TrueにするとDNS名が割り当てられる。Trueにしないと割り当てられない。

NTPサーバ

  • 169.254.169.123がNTPサーバ

IPv6対応

  • AWSのVPCはIPv6対応可能。
  • インターネットゲートウェイを構成すればアサインしたIPv6を使ってインターネット通信可能。
  • オンプレミス環境とAWS間をIPv4のSite to Site VPNを行い、VPNトンネル上でオンプレのIPv6ホストとAWS上のIPv6リソース間で通信可能。

VPCの外に位置するリソース

  • AWSクラウドへのリソースはIGWを使いインターネット越しに通信する。プライベートサブネットからはNATゲートウェイ。

VPCエンドポイント

  • Gateway型
    インスタンスがS3やDynamoDBのDNS問い合わせをRoute53 resolverに問い合わせし、VPCエンドポイントを通り、S3のサービスに直接通信可能。通信先のIPはグローバルIPアドレス。閉域でいける。
  • Interface型(PrivateLink)
    サブネット内にPrivateLinkを設けることが可能。EC2 API等をRoute53 resolverに問い合わせし、同セグメントのIPが返ってくる。そこに通信が行われNATされて通信可能。IPアドレスは自動で採番される。

仮想プライベートゲートウェイ(VGW)

  • VPCがVPNやDirectConnectと接続するためのゲートウェイのこと。各VPCに1つだけアタッチする。
  • VGWは内部で冗長化されている

NATゲートウェイ

  • プライベートサブネットのリソースがインターネットやAWSクラウドへ通信できるようになる。パブリッククラウドに設置する。インターネットゲートウェイと併設。EIPの割り当てが可能。45Gbpsまで自動拡張される。

VPCフローログ

  • セキュリティグループ、ネットワークACLでのaccepted、rejectされたログを取得できる。

VPCトラフィックミラーリング

  • パケットミラーリング。ソース、フィルタ、ターゲットとそれらを結ぶセッションで構成する。

GuardDuty

  • 脅威を自動で確認することができる。EC2、IAMの脅威を検出。機械学習する。

Amazon Route 53

  • Route 53 Public Hosted Zone
    インターネットに公開されたDNSドメインのゾーン

Route 53 Resolver

  • Route 53 Private Hosted Zone
    VPCに閉じたプライベートネットワーク内のDNSドメインのゾーン
    →Public Hosted Zoneで外への名前解決も可能。(フォワーダー)
  • InstanceへはDHCPでRoute 53 Resolverのアドレスが自動設定される

Route 53 Resolver for hybrid Cloud

  • Route 53 Resolverがオンプレミス環境と連携する場合に使用するプライベートネットワーク内のドメインのゾーン。
    →ハイブリッド環境での名前解決が可能。(下記コンポーネントを使う)
    →Outbound endpoint
    →Inbound endpoint
    →リゾルバールール
    Endpointの実態はENIs。そのため、セキュリティグループでポートを開ける必要あり。tcp53/udp53

Route 53 Hosted Zone

  • 代表的なレコード
     SOA ゾーンの管理主体であること、権威であることを宣言。(Zone Apexを定義)
     NS 権限移譲先のネームサーバのFQDNを指定する。
     A IPv4アドレスの応答 
     AAAA IPv6アドレスの応答
     CNAME Canonical NAMEを応答。名前解決を置き換えて継続する。
          CNAMEの制約で、CNAMEで名前を定義すると、同一の名前で
          ほかのレコード定義ができない。AWSでは回避方法としてエイリアス
          レコードが用意している。
     PTR IPアドレスからFQDNの逆引きを応答
     MX 当該ドメインのメールサーバのFQDNを応答
     TXT 任意の文字列を応答。多用途に利用される
     SRV 任意のサービスのサーバのFQDNを応答。
     ALIAS 最終的に必要とするAレコードタイプを応答する。Aレコード先はAmazonのサービスで、動的なIPに追従してくれる。
  • Route 53 Hosted Zoneはネームサーバ
    スプリットビューが可能。同じ名前をインターネット上の公開と、VPC内のプライベートネットワークからのゾーンに分けて、応答内容を変える。
  • トラフィックルーティング(クエリ応答の決定方法)
    シンプル…静的なマッピング。(普通のDNS。ラウンドロビン)
    加重…複数の応答に対して重みづけをして応答する。
    フェイルオーバー…ヘルスチェックを行い、使えるリソースのみにルーティングさせる。
    複数値回答…ランダムな正常なレコードにルーティングする。
    レイテンシー…ネットワークレイテンシーが早いものにルーティングさせる。
    位置情報…特定の国や地域をベースにしたルーティング。
    物理的近接性…物理的に近いものの応答をする。

AWS Direct Connect

  • Direct Connectロケーション
    カスタマーとAWSの中間に入るパートナー企業。キャリア。
    DirectConnectはロケーションからAWS間のことをさす。ロケーションからカスタマー拠点は専用線の接続が一般的。

LOA-CFA

  • カスタマーがAWSのコントロールパネルからLOA-CFAをダウンロードする(PDF)。このファイルをDC事業者へ提出し、DirectConnectロケーションのMeet-Me Room内でパートナー様ラックとAWSラックの物理的接続が行われる。

物理接続

  • 1000BASE-LX、または10GBASE-LR、シングルモードファイバー、オートネゴシエーション無効化。

接続方法

  • DirectConnextロケーションにカスタマールータ設置もあればパートナー様のルータ設置パターンもある。
  • ロケーションからカスタマー間は専用線や、閉域網の場合あり。

LinkAggregation

  • 同じ速度の回線を最大4つで集約可能。
  • LACP仕様。
  • 回線メンバーは同じAWSデバイスに収容されるので、シングルポイントはある。

仮想インタフェース(Virtual Interface=VIF)

  • VIF=Connectionを通してAWSリソースにアクセスるための論理インタフェース
     →AWSとカスタマーのルータ間でBGPで経路交換をする。
     →VLAN IDをもつ。
    クロスアカウント。複数のアカウントで、VIFを割り当て課金を別にすることも可能。
  • プライベートVIF
    VPCへプライベートIPを介した接続を提供する。
  • パブリックVIF
    AWSの全リージョンへパブリックIPを介した接続を提供(S3等への接続)
  • トランジットVIF
    Trasit Gateway用のDirectConnetゲートウェイへ接続を提供
  • ※Connectionの管理をパートナーアカウントで管理し、各VIFをカスタマー(ユーザのアカウント)に売るサービスプランもある。

Direct Connectゲートウェイ(DXGW)

  • 中国を除く全リージョンの複数のVPCと接続可能。
  • 複数のオンプレミス間でのDXGW折り返し通信はNG。複数のVPC間折り返し通信もNG
  • AWS側でDirectConnectを終端するリソース。DXGWから各VPCに割り当てているVGWと接続することで、DirectConnectはVPCと接続される。

カスタマーとAWSの接続(BGP)

  • プライベートVIFを使ったBGP接続
    →カスタマールータとDirectConnectゲートウェイ間にてBGPで経路交換をする。
    →カスタマールータとVGW間にてBGPで経路交換をする。(今後は非推奨)
  • パブリックVIFを使ったBGP接続
    →カスタマールータとAWSルータとBGPで経路交換をする。
    →BGPピア用に/31で構成し、カスタマールータ側でNAT(IPマスカレード)を行いカスタマー→AWS方向の際の送信元IPをパブリックIPに変換する。
  • トランジットVIFを使ったBGP接続
    →カスタマールータとDirectConnectゲートウェイ間にてBGPで経路交換をする。DirectConnectゲートウェイとTrasit Gatewayが接続する。
    →Trasit GatewayでアタッチしているVPC CIDRはそのままではアドバタイズされないので注意。DirectConnectゲートウェイで指定した任意のCIDRがアドバタイズされる。
    →Trasit Gatewayは1/2/5/10Gbpsのみで作成可能。

BGPの経路設計

  • 冗長構成の場合はオンプレミス側は2つのBGPルータ間でiBGPを組むことが推奨。
    上りと下りのトラフィックコントロールはカスタマールータで制御する。
     ・AWS→カスタマーへ広報する経路はAS-Pathプリペンドを使って制御。
     ・カスタマー→AWSへ広報する経路はLPを使って制御。
  • AWS→カスタマー方向のトラフィック制御は下記の順で評価される。
      1,ロンゲストマッチ
      2,BGPコミュニティ値
      3,AS Path
  • 2のBGPコミュニティ値は、パブリック接続とプライベート接続で分かれている。
     ・パブリック接続
      ・AWSに広告するプレフィックスの 伝播を制御するためのBGPコミュニティ
       ・7224:9100 ローカルAWSリージョン内のみに伝播
       ・7224:9200 同じ大陸のすべてのAWSリージョンに伝播
       ・7224:9300 グローバル(すべてのパブリックAWSリージョン)に伝播
       ・デフォルト=すべてのパブリックAWSリージョン(グローバル)に伝播
      ・AWSが広告するプレフィックスに付与されるBGPコミュニティ
       ・7224:8100 AWSDirectConnetのプレゼンスポイントが関連付けられているAWSリジョンと同じリージョンから送信されるルート。
       ・7224:8200 AWSDirectConnetのプレゼンスポイントが関連付けられている大陸と同じ大陸から送信されるルート。
       ・タグなし グローバル(すべてのパブリックAWSリージョン)
  •  プライベート接続
      ・AWSに広告する経路のローカルプリファレンスを制御するためのBGPコミュニティ
       ・7224:7100 優先設定:低
       ・7224:7200 優先設定:中
       ・7224:7300 優先設定:高
      ※AS-PathプリペンドでもAWSからカスタマールータ向けのトラフィックの優先度を制御可能。ただしリージョン別の間では機能しない

BFD

  • BGPの高速切り替え手段の一つ。カスタマー側とAWS側のBFDが機能する。
  • カスタマールータ側のBFDの設定値がAWS側にも自動反映される。
  • 設定内容は例えば300ミリ秒*3回でやく1秒で障害を検知する。

DirectConnexのモニタリング

  • AmazonCloudWatchを使い、接続メトリクス(Connectionのアップダウンやデータ転送量など)、仮想インタフェース(VIF)のメトリクス(VIFのデータ転送量等)でモニタリングタブから確認可能。

AWS Site-to-Site VPN

  • カスタマーVPN装置とAWS側のVGWでVPN接続を行う
    →VGWなので特定のVPCに接続するのに適している。
  • カスタマーVPN装置とAWS側のTrasit GatewayとでVPN接続を行う。
    →Trasit Gatewayであれば、複数のVPCと直接接続できる。
    →Trasit Gateway接続の場合はECMPを有効化することも可能。

ルーティング

  • 静的設定、またはBGPでルーティングが可能。BGPが推奨。
  • 複数のオンプレミス拠点で1つのVGW or TGWでBGP構成をしている場合。
     ・オンプレミス間で折り返しをしたい場合は、各オンプレミスルータのASNをユニークにする。
     ・オンプレミス間で折り返しをしない場合は、各オンプレミスルータのASNを同一にする。

VPN 認証タイプ

  • 事前共有キー、まやはプライベート証明書の2タイプがある。

MTU

  • 1399以下にする。(パスMTU検出機能は実装されていない)

冗長性

  • デフォルトで2本のVPNトンネルが張られる。しかし、筐体とインターネット回線も冗長させないと意味がないので、VPNで冗長するならば、回線と筐体を2セット用意する必要あり。

DirectConnetとの併設

  • DirectConneとSite-to-Site VPNの組み合わせ時に、BGP構成を組み、同一プレフィックスのルーティングを行わせると、DirectConneの経路が優先される。
  • VPNで静的ルートを使うと、VPNの経路が優先される。
  • しかし、BGP側のより細かいルート広報を行っていればばBGP経路が使われる。(ロンゲストマッチが効く)

Elastic Load Balancing

  • ALB
    →HTTP,HTTPS,HTTP/2
    →VPC
    →L7のコンテンツベースのLB
    →WAF、GlobalAcceleratorと連携することが可能
  • NLB
    →TCP,UDP,TLS
    →VPC
    →L4機能のLB
  • CLB(以前の世代)
    →HTTP,HTTPS,TCP,SSL
    →EC2-Classicネットワーク用のLB
  • ※NLBはIPアドレスが固定になるが、ALBやCLBはIPアドレスが変動する。
  • ELBのアクセスはDNS名となる。ELBを作成するとDNS名が設定される。
    →独自ドメインを使いたい場合はRoute53のエイリアスレコードで登録する。
    →Route53以外の場合はCNAMEを使う。ただし、ZoneApexの場合は通常のDNSサーバのCNAMEではNGなのでRoute53のALIASレコードを使う。
  • ELBはVPCに設置しAZをまたいで配置。パブリックサブネットに配置。
  • ALBとCLBはセキュリティグループの適用が可能。NLBは適用不可。

ターゲット

  • ターゲットになるインスタンス等はプライベートサブネットに配置するのがスタンダード。
  • ターゲットの種類としては、インスタンスIDで指定、IPアドレスで指定(CLBは未対応)、Lamda関数、となる。
  • IPアドレスでのターゲットは、オンプレミス環境の自社サーバなどを指定することが可能。

クロスゾーン負荷分散

  • 複数のAZ構成でターゲットメンバーの数が一致しない場合、負荷の量としては均等にならない。その場合、クロスゾーン負荷分散を使うと均等にさせることができる。
  • ALB → デフォルトで有効
  • NLB → デフォルトで無効
  • CLB → デフォルトで有効

スケーリング

  • ELB事態も自動でスケーリングをする。ただし、ALB/CLBは急な負荷にたいしてはHTTP503を返す。
  • NLBはかなりのトラフィックをさばける 

モニタリング

  • CloudWatchによりELBのメトリクスを使ってモニタリングが可能。

アクセスログ

  • 最短5分間隔でアクセスログを取得可能
  • S3バケットに簡単に保管

コネクション

  • 無通信タイムアウト値
    ALB/CLBは60秒(変更可能)
    NLBは350秒(変更不可能)

Connection Draining

  • ELBからターゲットへのヘルスチェックが失敗した場合すぐ切り離すのではなく、処理中のリクエストがおわるまで一定期間待つ機能

スティッキーセッション

  • ALB/CLBにでHTTP/HTTPSでクッキーが扱える。デフォルトでは無効

SSL/TLS Termination

  • ELBでSSL/TLS認証が可能。

AWS Certificate Manager(ACM)(TLSサーバ証明書)

  • AWS Certificate Manager(ACM)を使用すれば証明書のリクエストや管理が簡単。
  • 無料で証明書を利用可能。
  • 証明書は自動更新。
  • ACMで発行される証明書はドメイン認証タイプ(DV)、上位の証明書(OV,EV)を使いたい場合はサードパーティ製の証明書をインポートする。

ALBのコンテンツベースルーティング

  • パスベースのルーティング
    →リクエストURLに基づくルーティング
  • ホストベースのルーティング
    →HTTPヘッダーのHostフィールドに基づくルーティング(サブドメインのホスト部ベースでのルーティングが可能)
  • HTTPヘッダーべベースのルーティング
    →各リクエストのHTTPヘッダー(例えばUser-Agentにしたがってルーティング先の振り分けが可能)
  • HTTPメソッドベースのルーティング
    →HTTPメソッドにに基づくルーティング
  • クエリ文字列パラメータベースのルーティング
    →キーと値のペアまたはクエリストリングの値に基づくルーティング
     (http://example.com?version=v1のversion=v1の場所でルーティングを振り分けられる。)
  • 送信元IPアドレスCIDRベースのルーティング
    →リクエスト元のソースIPアドレスCIDRに基づくルーティング

ALBのユーザ認証機能

  • ユーザに対して、cognitoというAWSの認証サービスに転送させ、認証を挟むことができる。または、OIDC IdPによる認証を挟むこともできる。

X-Fowarded-For

  • ALBとCLBはXFFを有効にすることで、クライアントIPをインスタンスに伝えることが可能。
  • NLBはクライアントIPをそのまま透過する。

NLBの特徴

  • 固定IPアドレスが使える。EIPも利用可能。
  • 送信元IPアドレスの保持。XFFやProxyProtocolは不要。
  • 暖気なしに急激なスパイクにも対応可能。

AWS Gateway Load Balancer

  • GWLBを使うと、サードパーティのセキュリティアプライアンス製品などを可用性の高い構成がとれる。
  • GWLBEとGWLBの二つのコンポーネントで構成される。VPC内に構成する
  • GWLBとApplicationの間はGemeveになる。
  • IPv6はサポートしていない。
  • リスナーのようにポートは見ない。IPを軒並みGeneveにカプセリングする。

用途と動き

  • インライン監査などのセキュリティアプライアンスを通すときに利用するサービス。
  • トラフィックをGWLBEが受けて、GWLBにルーティングする。GWLBは専用アプライランスにルーティングする。専用アプライアンスで監査などを実施し、通信をGWLBにルーティングし、GWLBはGWLBEにルーティングする。

IngressRoutingの組み合わせ

  • GWLBEは別のVPCに立てて、そちらにインターネットGWが存在する。
  • インターネットGWのVPCはIngressRoutingを使ってパケットを戻す。

専用アプライアンス

  • Fortigateなどのセキュリティアプライアンス。Genaveをサポートしている製品であることが必要

Amazon CloudFront

  • 高性能な分散配信
  • 高いパフォーマンス
  • キャパシティアクセスからの解放
  • ビルトインのセキュリティ機能(WAN連携、DDos対策)
  • 設定が容易で即時利用可能
  • 充実したレポーティング
  • 完全従量課金

最適なエッジロケーションの割り当て

  • クライアントはDNSにより一番近いエッジにルーティングさせるようになっている。DNSは位置情報DBから情報を取得している。

リージョナルエッジキャッシュ

  • 以前は全エッジロケーションは一つのオリジンに通信しに行くが、本機能はエッジロケーションとオリジンの間に中継が入り、そこがアグリゲーションする。それにより、コンテンツ取得を削減することができる。

ディストリビューション

  • HTTP/1.0、HTTP/1.1、HTTP/2、WebSocket対応
  • GET,HEAD,OPTION(選択可能)(キャッシュモード)
  • PUT,POST,DELEAT,OPTION、PATCH(Proxyモード)
  • オリジンへのアクセスはInternet経由でアクセスが必要。

キャッシュコントロール

  • GET/HEAD/OPTIONのリクエストが対象
  • 単一ファイルサイズのキャッシングは最大20GB
  • URLパス毎にキャッシュ期間指定が可能
  • フォワードオプション機能による動的ページ配信
  • URLおよび有効化したフォワードオプション(クッキーやクエリ)のパラメーター値の観戦一致でキャッシュが再利用される。

動的コンテンツキャッシュへの対応

  • オリジンサーバに対してHeader,Cookie,Query Strings情報をフォワードすることで動的なページ配信にも対応

証明書

  • デフォルト証明書cloudfront.netが使える。
  • 独自SSL証明書も使える。
  • ACM(AWS CetificateManager)で発行された証明書も使える。
  • SNI SSL証明書
     →CloudFrontの専用IPアドレス費用を負担せず、独自ドメインでのSSL通信が可能。
     →一部古いブラウザはSNI拡張をさぽーとしていないため注意が必要。
  • 専用IPアドレスSSL証明書

CloudFrontとエッジ間の通信

  • SSLプロトコル方式
  • オリジンとの通信プロトコル(クライアントからの通信プロトコルにあわせる)
     →HTTPの選択が可能。S3へは標準でHTTPS
  • カスタムオリジンの場合のみ指定可能。

オリジンカスタムヘッダー

  • Shared-secret

地域制限

  • 地域クライアントの地域情報をもとに404を返す。

署名付きURL/Cookie

  • 特定のユーザ(署名のあるユーザ)にだけ応答することが可能なプライベートコンテンツ配信方法
    →ユーザは認証サイトに認証リクエストをなげ、署名付きURL,CookieでリダイレクトされCloudFrontにルーティングされる。問題なければコンテンツが送られ、NGであれば403を返す。

フィールドレベル暗号化

  • POSTリクエストの特定データフィールドを特定のアプリケーションのみアクセスできるように保護する。

オリジンサーバの保護

  • オリジンがS3の場合
    →OriginAccessIdentity(OAI)を利用
     →S3のBucketへのアクセスをCloudFrontからのみに制限
  • カスタムオリジンの場合
    →オリジンカスタムヘッダーを利用し、CloudFrontで指定された任意のヘッダーをオリジン側でチェック
    →オリジン側のアドレスを公開しないとともに、CloudFrontが利用するIPアドレスのみの許可させる。
     →CloudFrontのIPアドレスはJSONで公開されている。

AWS WAF連携

  • CloudFrontの前にAWS WAFを設置することでサイトの保護が可能。ブロックすると403をかえす

AWS Shield

  • AmazonのDDos緩和システム。デフォルトで有効になっている。

ログ、レポート

  • レポーティング
     →アクセスや利用状況傾向の確認、及び分析に使える
      →Management Consoleで実装
  • リアルタイムモニター
     →障害、異常検知や現状の利用確認
      →CloudWatchで実装
  • アクセスログ
     →複雑なアクセスや利用傾向分析データの可視化と詳細な障害分析
      →S3→AmazonAthena→AmazonQuickSightで実装

AWS Lambda@Edge

  • 完全に自動化された管理
  • 自動スケーリング
  • 利用に応じた支払い
  • 組み込みの耐障害性
  • グローバル分散
  • Lambda@Edgeイベント
    →クライアント→CloudFront→オリジンの→のリクエストとレスポンスの4箇所となる。
  • キャッシュヒット率の向上、コンテンツ生成、セキュリティ
  • 静的コンテンツを差し込んだり、カスタマイズされた動的コンテンツを差し込む。APIで取得した天気情報をサイトにうめこむことも可能。

AWS Global Accelerator

  • エッジロケーションに置かれる。IPエニーキャストを利用して全リージョンに同じIPでアクセスできる。
  • GlobalAcceletorを使うと、最初のGlobalAcceletor以降はAWSサービスまでAWSのバックボーンのみで通信が可能になる。それにより、品質があやしいISPを経由せずに高品質で高速な通信が可能となる。
  • 指定できるエンドポイントしては、ALB,NLB,EIP,特定EC2でTCPやUDP。
  • カスタムルーティングアクセラレータという機能を使用すると、エンドポイントではなく、決め打ちでEC2インスタンスのプライベートIPやポートに誘導させることができる。