この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちは。望月です。
昨日、VPC Peeringという特大アップデートがありました！今までは行えなかった、VPC間のローカル接続を実現するVPC Peering機能です！詳細はこちらのブログを参照して下さい。
さて、このアップデートで今まで出来なかった色々な問題が解決されると思います。で、私がこの機能追加を聞いた時に「これだ！」と思ったものをCDP候補"Shared Server"として提案したいと思います！CDP(Cloud Design Pattern)については、公式サイトを御覧ください。
解決したい課題
AWSの設計の基本として、「システムごとにVPCを作成して独立したネットワーク環境を作成する」というのが定石になっています。しかし一方で、この方針を採用することによる不都合な点も出てきます。例えば
- 一般的なVPCに必要なNATや踏み台といった要素をそれぞれのVPCに作成する必要がある。(一般的なVPC構成については過去ブログを参考にして下さい。
- 監視サーバなどの複数システムから利用されることがあるシステムも、VPC毎に作成する必要がある。
そのためEC2インスタンス数が増え、メンテナンス負荷と利用料金が増大するというのが今までの欠点でした。しかし、今回のアップデートにより、複数のシステムから共通で利用するVPCを作成することができるようになりました。
構造
構成図はかなりシンプルです。構築する上でのポイントは３つです。
- VPC Peeringを設定するVPCは、異なるCIDRアドレスブロックで作成する
- それぞれのVPCのRoute Tableで、VPC間の通信を許可する
- Security Groupで、必要なポートの通信を許可する
いくつかこのCDPを利用した実例を紹介します。VPC Peeringの設定や仕組みに関しては、前述のブログを参考にしてみてください。
実例その１：踏み台サーバ
VPC毎に踏み台を作成せずに、単一の踏み台からSSH接続を行うケースです。従来ですと、VPC毎に踏み台サーバを作成する必要がありました。それはそれで、役割と権限の分割、という意味で非常に意味のある構成です。一方で、一人の管理者が複数システムを管理するような場合ですと、踏み台サーバが複数存在することが煩雑に感じられるケースもあると思います。
そこで、上図でいう10.0.0.0/16のVPCにBastionインスタンスを作成し、そこから10.1.0.0/16のインスタンスにSSHでアクセスしてみます。
VPC Peeringの設定方法に関しては、前述のブログを参照して下さい。
$ ssh 54.199.247.157 # 10.0.0.0/16に作成した踏み台にアクセス
Last login: Tue Mar 25 10:25:51 2014 from :
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-ami/2013.09-release-notes/
[ec2-user@ip-10-0-0-181 ~]$ ssh -i <鍵ファイル> 10.1.0.143 # 10.1.0.0/16のホストにSSHアクセスする
The authenticity of host '10.1.0.143 (10.1.0.143)' can't be established.
RSA key fingerprint is aa:cf:a9:8d:06:ca:58:21:9a:94:74:c4:ac:9e:09:1b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.1.0.143' (RSA) to the list of known hosts.
Last login: Tue Mar 25 10:25:47 2014 from :
__| __|_ )
_| ( / Amazon Linux AMI
___|\___|___|
https://aws.amazon.com/amazon-linux-ami/2013.09-release-notes/
17 package(s) needed for security, out of 39 available
Run "sudo yum update" to apply all updates.
[ec2-user@ip-10-1-0-143 ~]$別のVPCにSSH接続することが確認できました。
実例その２：Zabbixサーバ
今度は、10.0.0.0/16のVPCにZabbix Serverをインストールしてみます。その上で、10.1.0.0/16のVPCにZabbix Agentをインストールしたインスタンスを用意し、Zabbix Serverに対して情報を送信します。Zabbix Serverのインストールについては、過去のブログで紹介していますので、そちらをお使い下さい。
- Amazon LinuxにZabbix2.0.9をインストールしてみた - Developers.IO クラスメソッド開発ブログ
- お手軽リソース監視 〜 Zabbix編 | アドカレ2013 : CFn #6 - Developers.IO クラスメソッド開発ブログ
監視対象側(10.1.0.0/16側)にZabbix Agentをインストールしたら、/etc/zabbix/zabbix_agentd.confを編集しましょう。Serverの設定項目をZabbix ServerのプライベートIPアドレスに設定します。
$ sudo vim /etc/zabbix/zabbix_agentd.conf
# 86行目を変更
Server=<Zabbix ServerのプライベートIPアドレス>
$ sudo service zabbix_agent startAgentが起動したら、ZabbixのWeb画面からホストの追加を行います。
登録をしてしばらくすると、監視が実際に実行されているのが確認できます。
異なるVPCのインスタンスをZabbixで監視することができるようになりました。
注意点
公式ページや前述のブログでも言及されていますが、同じCIDR同士のアクセスやIGW,VGWを共有した通信などは現在のVPC Peeringではサポートされていません。
制限事項はあるものの、しっかりと理解した上でこの機能を利用すればかなりVPC活用の幅が広がるのではないでしょうか。
また、「構造」の部分でも述べましたが、接続予定のそれぞれのVPCのCIDRは、別のレンジを設定しておくことを意識して下さい。「既存のVPCを全て同じCIDRで作ってしまっているよ！」という方は多いと思いますが、その救済はあるのでしょうか...
まとめ
CloudSearchの日本語対応など、最近のAWSのアップデートは非常に頻繁に、更に大型のものが続いています。今後もこのような機能の追加が続けば、AWSの面白い使い方が更に広がるのではないでしょうか。
あと、Shared Serverという名前を仮でつけましたが、サーバーというよりも、「あるシステムが果たす役割」をシェアしているイメージです。あまりイケてないネーミングだと思うので、どなたか良い名付け親になってください。
2
