ドキュメント

Document

自分のための備忘録です。

ALBとVPC Peering

ref. https://aws.amazon.com/jp/premiumsupport/knowledge-center/elb-access-load-balancer-vpc-peering/?utm_source=pocket_mylist

ALBを使ったよくある構成1

Webアプリケーションサーバ：プライベートサブネットに配置
- ユーザー：ロードバランサー経由でアクセス
- 開発者：パブリックサブネットに配置した踏み台サーバーからアクセス
踏み台サーバ：パブリックサブネットに配置（SSHのみ許可）

開発者はトンネリングを使用してWebアプリケーションにアクセス
AWSネットワーク構成はパブリックサブネットにNATゲートウェイを配置して、プライベートサブネットのルートテーブルにNATゲートウェイへのルートを設定

※ Webアプリケーションサーバと踏み台サーバとは同じ公開鍵/秘密鍵を使用することを前提とする。

ALBをよくある構成2（internal ALB）

VPC PeeringでVPCを接続してinternalなALBを使って相互通信する。

キャプチャ

internal-alb

前提として知っておくと良いこと

ルートテーブルにInternet Gatewayのルートを持つサブネットをパブリックサブネット、持たないサブネットをプライベートサブネットと呼ぶ
パブリックサブネットとプライベートサブネットの違いは文字通りインターネットへのルートを持つかどうかの違い
internalなALBはプライベートサブネットに配置する（パブリックサブネットには配置できない）

DNS設定

internalなALBにはDNS名（internal-xxxxxxxxx.ap-northeast-1.elb.amazonaws.com）でアクセスする。

VPCのDNS設定

VPCのDNS ホスト名を有効にする
VPCのDNS解決を有効化する

VPC PeeringのDNS設定

ALBのセキュリティグループ

よくないが一旦とりあえすべてのソースからのHTTPを許可して解決（適切な制御を考える）。

かんたんな疎通確認

VPC-FooとVPC-Bがある
VPC-Fooに(intenalな）ALBが配置されておりEC2にバランシング
VPC-FooとVPC-BarはVPC Peeringで接続
VPC PeeringはVPC-BarがリクエスタでVPC-Fooがアクセプタ
VPC-BarからVPC-Fooに疎通を確認

VPC Peering

VPC Peeringには必ずリクエスタVPCとアクセプタVPCが存在する。

同一アカウント

vpc-peering

VPC-FOO
- VPC Peering Foo（リクエスタ）
VPC-BAR
- アクセプタ

CloudFormation

ref. AWS::EC2::VPCPeeringConnection

VpcId（リクエスト）
PeerVpcId（アクセプタ）

The ID of the VPC with which you are creating the VPC peering connection. You must specify this parameter in the request.

※ PeerOwnerId

The AWS account ID of the owner of the accepter VPC.

他アカウントに対してVPC Peeringを設定する場合はアクセプタのAWS アカウントIDを指定。

AWS::EC2::Route

送信先
ターゲット

別アカウント（クロスアカウント）

VPC Peeringは異なるアカウントでも接続できる（PeerOwnerIdを指定）

AWS::EC2::VPCPeeringConnection

AWS::EC2::VPCPeeringConnectionのProperties。

VpcId（リクエスタ VPC）

The ID of the VPC.
PeerVpcId アクセプタ VPC

The ID of the VPC with which you are creating the VPC peering connection. You must specify this parameter in the request.
PeerOwnerId

The AWS account ID of the owner of the accepter VPC.

ref. https://docs.aws.amazon.com/ja_jp/AWSCloudFormation/latest/UserGuide/aws-resource-ec2-vpcpeeringconnection.html

ユースケース internalなALBを使ったVPC間通信

やりたいこと

internal-alb

プライベートサブネットのインスタンスからinternalなALBを経由してプライベートサブネットのインスタンスにアクセスする。

今回はfoo/barと2つのVPCを作成する。
ALBとアクセス先をfooに作成する。
アクセス元をbarに作成する。

fooのプライベートサブネットにWebサーバ用EC2インスタンスが2つ稼働している
- APIサーバにはinternalなALBを使ってアクセスする
barのプライベートサブネットにEC2インスタンスが稼働している
↑のインスタンスから（fooの）Webサーバにリクエストする

foo, barともにプライベートサブネットのインスタンスにアクセスするために、パブリックサブネットに踏み台サーバを配置している。

ALBとターゲットグループ

設定

今回は後述するようにWebサーバとしてSimpleHTTPServerをPort 8080で稼働する。 ALBおよびターゲットグループを以下のように設定する。

ターゲットグループのPortを8080に設定する（値は任意）
インスタンスのセキュリティグループのインバウンドでカスタムTCP 8080を許可する
ALBのリスナに↑で作成したターゲットを指定することで、ALBの80のアクセスを8080に転送する

※ ALBのセキュリティグループのインバウンドでHTTPを許可するのを忘れない。

ALBにはDNS 名（例 internal-foo-internal-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com）でアクセスできる。

$ curl -v internal-foo-internal-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com

ターゲットグループでPort 8080を指定する例は以下のとおり。

Amazon Linuxを使用した確認

ALBの疎通確認のために、プライベートサブネットのEC2インスタンスにWebサーバ（PythonのSimpleHTTPServer）を起動する。例はAmazon Linuxを使用している。

$ mkdir www
$ cd www
$ vim ndex.html
$ python -m SimpleHTTPServer 8080
Serving HTTP on 0.0.0.0 port 8080 ...

<html>
  <head>
    <title>Welcom to web1</title>
  </head>
  <body>
    Hello World
  </body>
</html>

ALBのリスナにターゲットが設定されるとヘルスチェックが行われる。

以下は上記で稼働したSimpleHTTPServerにヘルスチェックが行われている例。

$ python -m SimpleHTTPServer 8080
Serving HTTP on 0.0.0.0 port 8080 ...
10.2.1.175 - - [12/Mar/2022 11:15:16] "GET / HTTP/1.1" 200 -
10.2.2.171 - - [12/Mar/2022 11:15:17] "GET / HTTP/1.1" 200 -
10.2.1.175 - - [12/Mar/2022 11:15:46] "GET / HTTP/1.1" 200 -
10.2.2.171 - - [12/Mar/2022 11:15:47] "GET / HTTP/1.1" 200 -
10.2.1.175 - - [12/Mar/2022 11:16:16] "GET / HTTP/1.1" 200 -
10.2.2.171 - - [12/Mar/2022 11:16:17] "GET / HTTP/1.1" 200 -
10.2.1.175 - - [12/Mar/2022 11:16:46] "GET / HTTP/1.1" 200 -
10.2.2.171 - - [12/Mar/2022 11:16:47] "GET / HTTP/1.1" 200 -
10.2.1.175 - - [12/Mar/2022 11:17:16] "GET / HTTP/1.1" 200 -

VPC barのプライベートサブネットのインスタンスからの接続を確認する。

$ curl -v internal-foo-internal-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com

*   Trying 10.2.1.175:80...
* Connected to internal-foo-internal-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com (xxx.xxx.xxx.xxx) port 80 (#0)
> GET / HTTP/1.1
> Host: internal-foo-internal-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sat, 12 Mar 2022 11:25:20 GMT
< Content-Type: text/html
< Content-Length: 103
< Connection: keep-alive
< Server: SimpleHTTP/0.6 Python/2.7.18
< Last-Modified: Sat, 12 Mar 2022 11:00:37 GMT
<
<html>
  <head>
    <title>Welcom to web1</title>
  </head>
  <body>
    Hello World
  </body>
</html>
* Connection #0 to host internal-foo-internal-alb-xxxxxxxxxx.ap-northeast-1.elb.amazonaws.com left intact

プライベートホストゾーンを設定

alb.homeでアクセス可能

$ curl -v alb.home
*   Trying 10.2.2.171:80...
* Connected to alb.home (10.2.2.171) port 80 (#0)
> GET / HTTP/1.1
> Host: alb.home
> User-Agent: curl/7.79.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Sat, 12 Mar 2022 11:34:13 GMT
< Content-Type: text/html
< Content-Length: 103
< Connection: keep-alive
< Server: SimpleHTTP/0.6 Python/2.7.18
< Last-Modified: Sat, 12 Mar 2022 11:00:37 GMT
<
<html>
  <head>
    <title>Welcom to web1</title>
  </head>
  <body>
    Hello World
  </body>
</html>
* Connection #0 to host alb.home left intact

プライベートアドレスは停止や休止では変更されない。

プライベート IPv4 アドレスは、プライマリアドレスまたはセカンダリアドレスを問わず、インスタンスが停止して起動、または休止して起動した際に、ネットワークインターフェイスに関連付けられたままになり、インスタンスを終了すると解放されます。

ref. https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-instance-addressing.html#concepts-private-addresses

プライベートホストゾーンの名前空間が重複する際の優先順序は以下に記載されている。

https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/hosted-zone-private-considerations.html?utm_source=pocket_mylist