ALBとVPC Peering
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を使って相互通信する。
キャプチャ

前提として知っておくと良いこと
- ルートテーブルに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-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を経由してプライベートサブネットのインスタンスにアクセスする。
今回は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