この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
コンニチハ、千葉です。
Direct Connect経由でS3エンドポイントにアクセスするにはDirect Connectのパブリック接続を利用する必要があります。
ただ、パブリック接続を使う場合、プロバイダが対応している必要があったり、グローバルIPが必要だったり、AWSエンドポイントのルーティングをオンプレ側のルータへ設定する必要があります。
そこで、もっとシンプルな構成としてDirect Connectのプライベート接続でS3へアクセスする、高可用性な構成を検証してみました。
構成
Internal ELBを構成し、AWS SDKやAWS CLIのプロキシとしてELBを指定します。
ELBには、httpプロキシ(squid)を組み込みます。httpプロキシサーバはS3エンドポイントへルーティングしS3へアクセスするように構成します。
可用性については、ELBを利用してhttpプロキシを冗長化することで確保しています。
また、オンプレ側でELBのFQDNを引ける必要があります。オンプレ側がパブリックなDNSへ接続可能な場合は問題ないのですが、 できない場合は、オンプレからAWSのDNSを引けるようにする必要があります。
以下構成のサマリです。
オンプレ側
- ELBの名前解決ができること
- AWS SDKまたはAWS CLIのプロキシ先をELBに設定
AWS側
- httpプロキシ(今回はsquid)を構成
- Internal ELBを構成し、httpプロキシを組み込む
- S3エンドポイントを構成
設定してみた
ELBの名前解決
オンプレ側でELBのFQDNを引ける必要があります。
オンプレ側でパブリックなDNSを参照できる場合は、ELBの名前解決が可能です(特に意識する必要なし)。しかし、パブリックなDNSにアクセスできない場合もあるかと思います。その場合は、こちらより、AWS環境のDNSを引くことが可能です。
httpプロキシ(今回はsquid)を構成
httpプロキシを構成します。今回はsquidをインストールして構成します。
インストール
# yum install squid
# chkconfig squid on
# service squid start設定ファイルの変更
# vi /etc/squid/squid.conf
### アクセス許可するネットワークを指定(不要な行はコメントアウト)
#acl localnet src 10.0.0.0/8 # RFC1918 possible internal network
#acl localnet src 172.16.0.0/12 # RFC1918 possible internal network
#acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
#acl localnet src fc00::/7 # RFC 4193 local private network range
#acl localnet src fe80::/10 # RFC 4291 link-local (directly plugged) machines
acl localnet src XXX.XXX.XXX.XXX/24
### プロキシするポートを指定(不要な行はコメントアウト)※80,443のみをプロキシする設定へ
#acl Safe_ports port 21 # ftp
#acl Safe_ports port 70 # gopher
#acl Safe_ports port 210 # wais
#acl Safe_ports port 1025-65535 # unregistered ports
#acl Safe_ports port 280 # http-mgmt
#acl Safe_ports port 488 # gss-http
#acl Safe_ports port 591 # filemaker
#acl Safe_ports port 777 # multiling http
### ホスト名の記述
visible_hostname unknown設定変更したらsquidを再起動しておきます。今回は冗長構成のため2台構成しておきます。
ELBを構成し、httpプロキシを組み込む
ELBを作成します。ELBはInternal ELBとして構成し、オンプレからプライベートIPでアクセスするように構成します。
AWS SDKまたはAWS CLIのプロキシ先をELBに設定
AWS SDKまたは、AWS CLIのプロキシ設定を行います。
先ほど作成したELBのFQDNをプロキシに設定します。AWS CLIの場合は以下となります。
# export HTTPS_PROXY=internal-XXX.ap-northeast-1.elb.amazonaws.com:3128
# export HTTP_PROXY=internal-XXX.ap-northeast-1.elb.amazonaws.com:3128S3エンドポイントを構成
S3エンドポイントを構成し、httpプロキシサーバがプライベート環境でもS3へアクセスできるように構成します。
動作確認
Direct Connect環境がないので、AWS上にオンプレVPC、AWSVPCを構成し擬似環境で確認してみました。
それでは、オンプレからS3へアクセスしてみます。
左：【オンプレ】S3アクセス、中：【AWS】httpプロキシ1アクセスログ、右【AWS】：httpプロキシ2アクセスログ
ファイルをアップロード
アップロード確認
プロキシ経由でのS3アクセスが可能であることを確認できました。
まとめ
Direct Connectのプライベート接続を利用して、S3へアクセスを行いました。Direct Connectを経由するので帯域を確保しつつ、さらに可用性も確保できました。もちろん、Direct Connect自体の冗長化も必要です。
[注意事項]安定的なS3接続をするには、ELBのタイムアウトやEC2の帯域幅を考慮する必要があります。ELBのタイムアウトのチューニング、EC2インスタンスタイプによる帯域幅のチューニングも重要です。
0
