てくなべ (tekunabe)

ansible / network automation / 学習メモ

[Ansible] UNIX タイムスタンプを任意の日付時刻フォーマットに変換する strftime

ansible

はじめに

1609948923 のような UNIX タイムスタンプを、2021/01/07 01:02:03 のようなフォーマットに変換する方法です。

これをやりたい機会があって調べてたのですが、思いの外目当ての情報ににたどり着けず・・。 結局ちゃんと公式ドキュメントに書いてありました。公式ドキュメントへの橋渡しを兼ねて記事にします。

  • 環境
    • Ansible 2.9.14
    • Jinja2 2.11.2

Playbook

strftime を利用します。

---
- hosts: localhost
  gather_facts: false

  tasks:
    - name: debug datetime format
      debug:
        msg: "{{ '%Y/%m/%d %H:%M:%S' | strftime(1609948923) }}"

利用できるフォーマットは、以下の Python のドキュメントに掲載されています。

time — Time access and conversions — Python 3.9.1 documentation

実行

Playbook を実行します。

$ ansible-playbook -i localhost, ts.yml

PLAY [localhost] **************************************************************************************************

TASK [debug datetime format] **************************************************************************************
ok: [localhost] => {
    "msg": "2021/01/07 01:02:03"
}

PLAY RECAP ********************************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

"2021/01/07 01:02:03" と表示されました。

参考

公式ドキュメントはこちら。

docs.ansible.com

以下のサンプルが掲載されています。

# Use arbitrary epoch value
{{ '%Y-%m-%d' | strftime(0) }}          # => 1970-01-01
{{ '%Y-%m-%d' | strftime(1441357287) }} # => 2015-09-04

[Ansible] 「つまずき Ansible 【Part25】assert で期待値確認をしたい」ふりかえり

ansible つまずきAnsible

はじめに

2021/01/09 に、YouTube Live で「つまずき Ansible 【Part25】assert で期待値確認をしたい」という配信をしました。

実際に作業しながら（ときには）エラーと戦って進めるシリーズです。

今回は、条件式を与えて期待値のチェックなどができる、assert モジュールを扱いました。

tekunabe.connpass.com

  • 環境
    • Ansible 2.9.16


動画

youtu.be

  • 0:00 イントロダクション
  • 1:50 概要
  • 6:02 簡単な使い方
  • 11:37 少し応用（ネットワーク機器の状態確認）
  • 30:20 おわりに

■ やったこと

基本的な使い方

単一の条件

pass のパターン

    - name: assert
      assert:
        that:
          - 1 == 1

結果

TASK [assert] ********************************************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

fail のパターン

    - name: assert
      assert:
        that:
          - 1 == 0

結果

TASK [assert] *******************************************
fatal: [localhost]: FAILED! => {
    "assertion": "1 == 0",
    "changed": false,
    "evaluated_to": false,
    "msg": "Assertion failed"
}

AND 条件

that に複数書くと AND。

    - name: assert
      assert:
        that:
          - 1 == 0
          - 1 == 1

結果

TASK [assert] ******************************
fatal: [localhost]: FAILED! => {
    "assertion": "1 == 0",
    "changed": false,
    "evaluated_to": false,
    "msg": "Assertion failed"
}

OR 条件

or を指定する。

    - name: assert
      assert:
        that:
          - (1 == 0) or (1 == 1)

結果

TASK [assert] **************************************
ok: [localhost] => {
    "changed": false,
    "msg": "All assertions passed"
}

少し応用的な使い方

Cisco ISO のネットワーク機器から収集したファクト（インターフェースの状態やLLDPネイバー情報など）が期待したどおりかを assert でチェック。

ホスト変数

まず、期待値をホスト変数として定義。

  • ホスト変数ファイル ios01.yml
---
expected:
  interfaces:
    - name: GigabitEthernet0/1
      lineprotocol: up
  llpd_neighbors:
    - local_intf: GigabitEthernet0/1
      host: ios02.sakana.local
      port: Gi0/1
  • ホスト変数ファイル ios02.yml
---
expected:
  interfaces:
    - name: GigabitEthernet0/1
      lineprotocol: up
  llpd_neighbors:
    - local_intf: GigabitEthernet0/1
      host: ios01.sakana.local
      port: Gi0/1

Playbook

以下のように fail_msg を指定すると失敗したときのメッセージをカスタマイズできる。実際の値は何だったのか表示するときな喉に便利。success_msg オプションもある。

---
- hosts: ios

  tasks:

    - name: assert interface lineprotocol
      assert:
        that:
          -  ansible_facts.net_interfaces[item.name].lineprotocol == item.lineprotocol
        fail_msg: "実際は{{ ansible_facts.net_interfaces[item.name].lineprotocol }}"
      loop: "{{ expected.interfaces }}"

    - name: assert lldp neighbors
      assert:
        that:  # 0番目の neighbor しか見てないので荒い実装です 
          -  ansible_facts.net_neighbors[item.local_intf][0].host == item.host
          -  ansible_facts.net_neighbors[item.local_intf][0].port == item.port
        fail_msg: "実際は{{ ansible_facts.net_neighbors[item.local_intf][0] }}"
      loop: "{{ expected.llpd_neighbors }}"

実行（期待通りだったとき）

$ ansible-playbook -i inventory.ini  ios_assert.yml 

PLAY [ios] *************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************
[WARNING]: Ignoring timeout(10) for ios_facts
[WARNING]: Ignoring timeout(10) for ios_facts
[WARNING]: default value for `gather_subset` will be changed to `min` from `!config` v2.11 onwards
ok: [ios01]
ok: [ios02]

TASK [assert interface lineprotocol] ***********************************************************************************
ok: [ios01] => (item={'name': 'GigabitEthernet0/1', 'lineprotocol': 'up'}) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": {
        "lineprotocol": "up",
        "name": "GigabitEthernet0/1"
    },
    "msg": "All assertions passed"
}
ok: [ios02] => (item={'name': 'GigabitEthernet0/1', 'lineprotocol': 'up'}) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": {
        "lineprotocol": "up",
        "name": "GigabitEthernet0/1"
    },
    "msg": "All assertions passed"
}

TASK [assert lldp neighbors] *******************************************************************************************
ok: [ios01] => (item={'local_intf': 'GigabitEthernet0/1', 'host': 'ios02.sakana.local', 'port': 'Gi0/1'}) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": {
        "host": "ios02.sakana.local",
        "local_intf": "GigabitEthernet0/1",
        "port": "Gi0/1"
    },
    "msg": "All assertions passed"
}
ok: [ios02] => (item={'local_intf': 'GigabitEthernet0/1', 'host': 'ios01.sakana.local', 'port': 'Gi0/1'}) => {
    "ansible_loop_var": "item",
    "changed": false,
    "item": {
        "host": "ios01.sakana.local",
        "local_intf": "GigabitEthernet0/1",
        "port": "Gi0/1"
    },
    "msg": "All assertions passed"
}

PLAY RECAP *************************************************************************************************************
ios01                      : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
ios02                      : ok=3    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0


実行（インターフェースの状態が期待通りでなかったときの抜粋）

failed: [ios01] (item={'name': 'GigabitEthernet0/1', 'lineprotocol': 'up'}) => {
    "ansible_loop_var": "item",
    "assertion": "ansible_facts.net_interfaces[item.name].lineprotocol == item.lineprotocol",
    "changed": false,
    "evaluated_to": false,
    "item": {
        "lineprotocol": "up",
        "name": "GigabitEthernet0/1"
    },
    "msg": "実際はdown"
}


おわりに

assert モジュールは、molecule の verifier を Ansible にしたときにもよく利用することになると思います。

あるいみ単純なモジュールですが、手になじませておくと便利です。


Part26 にむけて

以下のネタを検討中です。気が向いたものをやります。

  • Ansible 2.10 関連
  • connection: local ななにか
  • ansible.cfg
  • Jinja2、フィルター
  • Windows
  • ESXi で VM作成
  • cli_parse モジュール（Part15 の続き）

[AWS] Transit Gateway とオンプレの VPN 接続を試してみた

aws network

はじめに

AWS の VPC を VPN で接続する方法自体は、以前から仮想プライベートゲートウェイ（VGW）経由の方法がありました。

2018年に Transit Gateway というものを経由する方法もできてたことを知りました。

Transit Gateway を利用する場合は、VPC ごとに VGW、VPN を作成しなくてよく、効率的なようです。

そこで、雰囲気を掴みたく、Transit Gateway とオンプレの VPN 接続を試してみました。

設定手順

基本的には、以下の記事を参考にさせていただきました。

dev.classmethod.jp

私の環境の場合は、接続したい VPC 配下のサブネットが利用しているルートテーブルに、作成した Transit Gateway に向けるルートを追加しました。 （うまくやれば自動反映されるのでしょうか・・？）（追記: ルートテーブルの伝搬を有効にすれば反映されたはず）

f:id:akira6592:20210103113706p:plain
Transit Gateway をターゲットとしたルートエントリ

VPC は2つ（10.0.0.0/16、10.2.0.0/16）アタッチしました。

なお、オンプレ側のルーターは、固定IPを振った RTX 1200 を利用しました。コンフィグは、AWS 側の画面で生成されてダウンロードしたものをベースにしました。


確認

AWS 側

VPN 接続では、2つのトンネルがアップしました。

f:id:akira6592:20210103113640p:plain
トンネルのアップ

Transit Gateway 接続では、アタッチした2つの VPC（10.0.0.0/16、10.2.0.0/16）と、オンプレのルーターから広報された2つの経路（192.168.1.0/24、192.168.100.0/24）が掲載されました。

f:id:akira6592:20210103113749p:plain
VPC 側とオンプレ側のルート

ルーター側

tunnel 1 と tunnle 2 それぞれ Online。

rtx# show status tunnel 1
TUNNEL[1]: 
Description: 
  Interface type: IPsec
  Current status is Online.
  from 2021/01/02 20:38:10.
  15 hours 3 minutes 43 seconds  connection.
  Received:    (IPv4) 12378 packets [782025 octets]
               (IPv6) 0 packet [0 octet]
  Transmitted: (IPv4) 12091 packets [740159 octets]
               (IPv6) 0 packet [0 octet]
rtx# 
rtx# show status tunnel 2
TUNNEL[2]: 
Description: 
  Interface type: IPsec
  Current status is Online.
  from 2021/01/02 20:34:25.
  15 hours 7 minutes 38 seconds  connection.
  Received:    (IPv4) 14017 packets [942791 octets]
               (IPv6) 0 packet [0 octet]
  Transmitted: (IPv4) 16045 packets [1147258 octets]
               (IPv6) 0 packet [0 octet]

2つの BGP ネイバーは Established 。

rtx# show status bgp neighbor 
BGP neighbor is 169.254.140.1, remote AS 64512, local AS 65000, external link
  BGP version 4, remote router ID 169.254.140.1
  BGP state = Established, up for 00:46:42
  Last read 00:00:01, hold time is 30, keepalive interval is 10 seconds
  Received 283 messages, 0 notifications, 0 in queue
  Sent 285 messages, 0 notifications, 0 in queue
  Connection established 3; dropped 2
  Last reset 01:31:55
Local host: 169.254.140.2, Local port: 179
Foreign host: 169.254.140.1, Foreign port: 39273

BGP neighbor is 169.254.65.129, remote AS 64512, local AS 65000, external link
  BGP version 4, remote router ID 169.254.65.129
  BGP state = Established, up for 04:36:03
  Last read 00:00:03, hold time is 30, keepalive interval is 10 seconds
  Received 1658 messages, 0 notifications, 0 in queue
  Sent 1661 messages, 0 notifications, 0 in queue
  Connection established 2; dropped 1
  Last reset 05:21:17
Local host: 169.254.65.130, Local port: 179
Foreign host: 169.254.65.129, Foreign port: 42405

2つの VPC の分を受信し、オンプレから 2つの経路を広報。

rtx# show status bgp neighbor 169.254.140.1 received-routes 
Total routes: 2
*: valid route
  Network            Next Hop        Metric LocPrf Path
  10.0.0.0/16        169.254.140.1      100        64512 IGP
  10.2.0.0/16        169.254.140.1      100        64512 IGP
rtx# 
rtx# show status bgp neighbor 169.254.140.1 advertised-routes 
Total routes: 2
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 192.168.1.0/24     169.254.140.2                 65000 IGP
* 192.168.100.0/24   169.254.140.2                 65000 IGP

rtx# show status bgp neighbor 169.254.65.129 received-routes 
Total routes: 2
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 10.0.0.0/16        169.254.65.129     100        64512 IGP
* 10.2.0.0/16        169.254.65.129     100        64512 IGP
rtx# 
rtx# show status bgp neighbor 169.254.65.129 advertised-routes 
Total routes: 2
*: valid route
  Network            Next Hop        Metric LocPrf Path
* 192.168.1.0/24     169.254.65.130                65000 IGP
* 192.168.100.0/24   169.254.65.130                65000 IGP

ルーティングテーブルには tunnel 2 に向く経路が載っています。

rtx# show ip route 
Destination         Gateway          Interface       Kind  Additional Info.
default             -                    PP[01]    static  
10.0.0.0/16         169.254.65.129    TUNNEL[2]       BGP  path=64512
10.2.0.0/16         169.254.65.129    TUNNEL[2]       BGP  path=64512
169.254.65.128/30   -                 TUNNEL[2]  implicit  
169.254.140.0/30    -                 TUNNEL[1]  implicit  
...(略)...

エンドツーエンド

オンプレ側のマシン（192.168.100.2）から、各 VPC 内のインスタンスへの ping が無事通過。

[root@awx-try ~]# ping 10.0.1.10
PING 10.0.1.10 (10.0.1.10) 56(84) bytes of data.
64 bytes from 10.0.1.10: icmp_seq=1 ttl=252 time=9.76 ms
64 bytes from 10.0.1.10: icmp_seq=2 ttl=252 time=9.45 ms
64 bytes from 10.0.1.10: icmp_seq=3 ttl=252 time=9.45 ms
64 bytes from 10.0.1.10: icmp_seq=4 ttl=252 time=8.87 ms
[root@testsv ~]# 
[root@testsv ~]# ping 10.2.1.10
PING 10.2.1.10 (10.2.1.10) 56(84) bytes of data.
64 bytes from 10.2.1.10: icmp_seq=1 ttl=252 time=8.44 ms
64 bytes from 10.2.1.10: icmp_seq=2 ttl=252 time=10.1 ms
64 bytes from 10.2.1.10: icmp_seq=3 ttl=252 time=8.29 ms
64 bytes from 10.2.1.10: icmp_seq=4 ttl=252 time=8.16 ms


参考: awscli での設定手順

GUI であちこち設定画面を行き来するのが少しだけ手間だったので、 あとで、awscli でも同様のことができるか試しました。

Transit Gatetway の作成

まずは、Transit Gatetway を作成します。

aws ec2 create-transit-gateway --options="AmazonSideAsn=64512" --tag-specifications "ResourceType=transit-gateway,Tags=[{Key=Name,Value=tgw-test99}]"

戻り値の TransitGatewayId の値を控えておきます。

Customer Gateway の作成

GUI では、Create Transit Gateway Attachment 画面で、Customer Gateway の作成と Transit Gatetway との接続を同時に設定しました。

一方、awscli まず Customer Gateway を作成します。

aws ec2 create-customer-gateway --bgp-asn 65000 --public-ip ${カスタマーゲートウェイ側のIP}  --type ipsec.1 --tag-specifications "ResourceType=customer-gateway,Tags=[{Key=Name,Value=cgw-test99}]"

戻り値の CustomerGatewayId の値を控えておきます。

VPN 接続の作成

続いて VPN 接続を作成します。このとき、最初に作成した Transit Gateway の ID を --transit-gateway-id オプションで指定します。

aws ec2 create-vpn-connection  --type ipsec.1  --customer-gateway-id ${控えておいたCustomerGatewayId}  --transit-gateway-id ${控えておいたTransitGatewayId} --tag-specifications "ResourceType=vpn-connection,Tags=[{Key=Name,Value=vpn-test99}]"

これを実行したあと、VPN の設定画面の「設定のダウンロード」でダウンロードした、コンフィグをルーターに流し込みます。

（設定のダウンロードは自動化できるのでしょうか・・？戻り値の CustomerGatewayConfiguration 内の値と何かしらのテンプレートで生成できそうすが）

Transit Gatetway と VPC のアタッチ

Transit Gatetway と VPC にアタッチします。

aws ec2 create-transit-gateway-vpc-attachment  --vpc-id ${対象の VPC ID} --transit-gateway-id ${控えておいたTransitGatewayId} --subnet-ids ${対象のサブネットID} --tag-specifications "ResourceType=transit-gateway-attachment,Tags=[{Key=Name,Value=tgw-attach-vpc-test99}]"

ルートテーブルに Transit Gateway 追加

最後に、対象サブネットが利用するルートテーブルに、Transit Gateway をターゲットとするルートを追加します。ここではデフォゲとして設定します。

aws ec2 create-route --route-table-id ${対象のルートテーブルID} --destination-cidr-block  "0.0.0.0/0" --transit-gateway-id ${控えておいたTransitGatewayId}


おわりに

Transit Gateway を経由して、VPC とオンプレの間を VPN 接続で接続できることを試しました。

Transit Gateway をハブとした構成で接続できるのは便利なのだろうなと思いました。

[AWS] VPC 関連の個人的メモ

aws

はじめに

引き続き、VPC 周りを学習中です。 用語や特性、どのような関連があるのかを整理するために、個人的なメモをまとめます。

VPC

  • 仮想ネットワーク
  • CIDR は一度決めたらあとから変更できないため、余裕をもった設計にしておく

サブネット

  • VPC 内に作る
  • 例えば VPC が 10.0.0.0/16 であれば、サブネットは 10.0.1.0/24 のように
  • サブネットごとにアベイラビリティゾーンを指定できる
  • パブリック IPv4 アドレスを自動割り当て を はい にすると、所属インスタンスに設定を引き継げる
  • 後述のインターネットゲートウェイ経由でインターネットと通信するサブネットをブリックサブネット、そうでないものをいプライベートサブネット呼ぶ

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

  • インターネットとの接続に必要なもの
  • インターネット側からもアクセスするために使う（中→外のにであれば後述の NAT ゲートウェイ）
  • 所属サブネットのルートテーブルのデフォルトゲートウェイをインターネットゲートウェイに向けると、インターネットに出ていける
  • 特に設定はないが、VPC にアタッチさせる

NAT ゲートウェイ

  • 中からインターネットへの接続のみ必要なときに利用する
  • パブリックサブネットに配置して、EIP を付ける

ルートテーブル

  • いわゆるルーティングテーブル
  • VPC 作成時に、ローカル（VPC内）のみルーティングするデフォルトのルートテーブルができる（メイン: はい のもの）
  • デフォルトのルートテーブルは各サブネット共通なので影響が大きいためそのままにしておく
  • ルートテーブルを変更シたい場合は、別途ルートテーブルを作って関連付けし直す

セキュリティグループ

ネットワークACL

  • サブネットに適用
  • 許可の拒否を指定
  • ステートレス

EC2 の IP アドレス

  • インスタンス側の設定としては DHCP クライアントにする
  • プライマリプライベート IP アドレスは一度決まると変更されない
  • 自動で割り当てられたパブリック IP アドレスは再起動では変更されないが、停止→開始では変更される
  • 停止→開始でも固定化したい場合は EIP を割り当てる

参考

www.nikkeibp.co.jp book.impress.co.jp tekunabe.hatenablog.jp

[AWS] ALB への証明書インポート時の互換性エラー（Common Name 未設定の凡ミス）

aws

はじめに

ALB のリスナーの設定として、証明書をインポートしようとしたら以下のエラーが発生しました。

ただの凡ミスだったのですが、その症状と原因と対処です。

同じエラーメッセージでも複数の原因があるかと思います。

症状

表示されたのは以下の証明書の互換性エラーです。

f:id:akira6592:20210102115535p:plain
証明書の互換性エラー

新しいリスナーの追加。 各 リスナー には 転送, リダイレクト, 固定レスポンス タイプのアクションの 1 つが含まれている必要があります。 リスナーの作成中にエラーが発生しました インポートされた証明書の設定に互換性がないため、リスナーの使用可能な証明書のリストには表示されません。別の証明書を選択またはアップロードして、やり直してください。

先に同じのもを ACM に登録してもリスナー設定画面ではその証明書は一覧に表示されませでした。

原因

最初は鍵長などを疑ったのですが、結局 CSR 生成時に Common Name を空してしまったためという凡ミスです。

対処

Common Name を指定して CSR の再生成と、証明書の再生成してインポートし直したところ無事にインポートされました。

Common Name には ALBのDNS名（例: hogehoge-elb-xxxxxxxxxx.us-east-2.elb.amazonaws.com ）を指定しました。

# CSR の生成
$ openssl req -new -key ./server.key -out ./server.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:JP
State or Province Name (full name) []:
Locality Name (eg, city) []:
Organization Name (eg, company) []:
Organizational Unit Name (eg, section) []:
Common Name (eg, fully qualified host name) []:     ★ここに ALB の DNS 名を指定
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:

# 証明書の生成
$ openssl x509 -in server.csr -days 365 -req -signkey server.key -out server.crt
Signature ok
subject=/C=JP/CN=hogehoge-elb-xxxxxxxxxx.us-east-2.elb.amazonaws.com
Getting Private key

自分のグローバルIPアドレスを知れるサービス ifconfig.io

はじめに

今作業しているマシンが、インターネットへ通信するときに、送信元IPアドレスが何になるか知りたいときはないでしょうか。

そんなときに私が使っているのが、https://ifconfig.io/ というサービスです。

以下の特徴があります。

  • curl ifconfig.io で単純に IPアドレスだけ返ってくる
  • JSON に対応
  • IPv6 に対応
  • http / https 両対応
  • 個人的に覚えやすいアドレス（主にこの理由で使っています）

使い方

ブラウザで https://ifconfig.io を開くと大体の使い方が分かります。

サクッと curl ifconfig.io

単純に IP アドレスだけ知りたときは curl ifconfig.io を実行します。一番良く使います。

$ curl ifconfig.io
203.0.113.1

IPv6 での通信の場合は、IPv6 アドレスが返ってきます。

$ curl ifconfig.io
2001:0db8::1

明示的に IPv4 を指定する場合は curl のオプション -4 をつけます。

$ curl ifconfig.io -4 
203.0.113.1

もっと情報を知りたい場合は

他のリクエスト情報をいろいろ JSON で取得するには curl ifconfig.io/all.json を実行します。

$  curl ifconfig.io/all.json
{"country_code":"JP","encoding":"gzip","forwarded":"203.0.113.1","ifconfig_hostname":"ifconfig.io","ip":"203.0.113.1","lang":"","method":"GET","mime":"*/*","port":39880,"referer":"","ua":"curl/7.64.1"}

他の類似サービス

[2021/01/02 追記] ブックマークのコメントでも他のサービスや注意点などのコメントを頂いています。

b.hatena.ne.jp

[AWS] VPC 周りの設定とインバウンド、アウトバウンド通信可否の個人的まとめ

aws

はじめに

AWS の VPC 周りを学習中です。

その中で、インターネットゲートウェイ、NAT ゲートウェイ、パブリックIP の有無と、インタネットからEC2 インスタンスへインバウンド、インターネットへのアウトバウンド通信の関係が少々ややこしく感じました。

自分向けに試した結果をまとめておきます。試し方が間違っていたらごめんなさい。

まとめ

パターン No ゲートウェイ (*1) パブリックIP インバウンド (*2) アウトバウンド アウトバウンドの送信元IP (*3) public-ipv4 (*4)
1 インターネットゲートウェイ あり ○ ○ パブリックIP パブリックIP
2 インターネットゲートウェイ なし - × - -
3 NAT ゲートウェイ あり × ○ NAT ゲートウェイの EIP パブリックIP
4 NAT ゲートウェイ なし - ○ NAT ゲートウェイの EIP -

注釈

  • *1 インスタンスが所属しているサブネットのルートテーブルのデフォルトルートの先
  • *2 割り当てたパブリックIPに対してインターネット側からの SSH
  • *3 メタデータ curl http://169.254.169.254/latest/meta-data/public-ipv4 の結果
  • *4 curl ifconfig.io の結果