Introducing Amazon Virtual Private Cloud (VPC)
From <http://aws.typepad.com/aws/2009/08/introducing-amazon-virtual-private-cloud-vpc.html>
ついに Amazon が、オンプレミス連携に関するベータを出しましたね。 Windows Azure のサービスインに先行して、エンタープライズのためのクラウドという領域がヒートアップしてきますね。地域としては Availability Zone in the US-East に限定されているようですが、エンタープライズだからこそ、回線の品質が重視されるのでしょう。 Amazon も Azure も、はやく日本に来て欲しいです。 ーーー A.C.
Amazon Virtual Private Cloud (Amazon VPC) lets you create your own logically isolated set of Amazon EC2 instances and connect it to your existing network using an IPsec VPN connection. This new offering lets you take advantage of the low cost and flexibility of AWS while leveraging the investment you have already made in your IT infrastructure.
Amazon Virtual Private Cloud (Amazon VPC) により、Amazon EC2 インスタンスの論理的に分離されたセットの作成と、IPsec VPN 接続を用いた既存のネットワーク接続が実現される。 この新しいオファーは、すでに投資された ITインフラストラクチャにテコ入れする一方で、AWS における低コストと柔軟性をいうアドバンテージを促進する。
This cool new service is now in a limited beta and you can apply for admission here.
この斬新なサービスはベータであるが、ココから登録できる。
Here’s all you need to do to get started:
以下の手順により、このベータの利用が可能となる：
1: Create a VPC. You define your VPC’s private IP address space, which can range from a /28 (16 IPs) up to a /18 (16,384 IPs). You can use any IPv4 address range, including Private Address Spaces identified in RFC 1918 and any other routable IP address block.
2: Partition your VPC’s IP address space into one or more subnets. Multiple subnets in a VPC are arranged in a star topology and enable you to create logically isolated collections of instances. You can create up to 20 Subnets per VPC (you can request more using this form). You can also use this form to request a VPC larger than a /18 or additional EC2 instances for use within your VPC.
3: Create a customer gateway to represent the device (typically a router or a software VPN appliance) anchoring the VPN connection from your network.
4: Create a VPN gateway to represent the AWS end of the VPN connection.
5: Attach the VPN gateway to your VPC.
6: Create a VPN connection between the VPN gateway and the customer gateway.
7: Launch EC2 instances within your VPC using an enhanced form of the Amazon EC2 RunInstances API call or the ec2-run-instances command to specify the VPC and the desired subnet.
1: VPC を作成する。その VPC のプライベート IP アドレス空間を定義することで、 /28 (16 IPs) から /18 (16,384 IPs) までのレンジに対応。つまり、 RFC 1918 で識別されるPrivate Address Spaces と、ルーティングに対応する IP アドレス･ブックを含む、あらゆる IPv4 アドレス･レンジの利用が可能。
2: 定義された VPC の IP アドレス空間を、1つのサブネットもしくは、複数のサブネットに振り分ける。VPC のマルチ･サブネットはスター･トポロジーに割り当てられるため、複数のインスタンス上で論理的に分離されるコレクションの作成が可能。VPC ごとに、20 までのSubnet の作成が可能（それ以上のリクエストにも対応）。さらに、定義された独自の VPC 内で。 /18 以上のVPC もしくは、追加の EC2 インスタンスの利用も可能。
3: VPN と顧客のネットワークを接続するデバイス（一般的にはルーターもしくはソフトウェアVPNアプライアンス）を、表現するためのカスタマー･ゲートウェイを作成。
4: その VPN コネクションの AWS エンドを表現する、VPN ゲートウェイを作成。
5: そのVPN ゲートウェイを、作成された VPC にアタッチ。
6: VPN ゲートウェイとカスタマー・ゲートウェイの間で、VPN コネクションを作成。
7: Amazon EC2 RunInstances API コールもしくは、ec2-run-instances コマンドから、特定の VPN と指定されたサブネットへの拡張を用いて、作成された VPC 内の EC2 インスタンスを起動。
Once you have done this, all Internet-bound traffic generated by your Amazon EC2 instances within your VPC routes across the VPN connection, where it wends its way through your outbound firewall and any other network security devices under your control before exiting from your network.
IP addresses are specified using CIDR notation, where the value after the slash represents the number of bits in the routing prefix for the address. You’re currently limited to one VPC per AWS account, however, if you have a use case requiring more, let us know and we’ll see what we can do.
Because the VPC subnets are used to isolate logically distinct functionality, we’ve chosen not to immediately support Amazon EC2 security groups. You can launch your own AMIs and most public AMIs, including Microsoft Windows AMIs. You can’t launch Amazon DevPay AMIs just yet, though.
The Amazon EC2 instances are on your network. They can access or be accessed by other systems on the network as if they were local. As far as you are concerned, the EC2 instances are additional local network resources — there is no NAT translation. EC2 instances within a VPC do not currently have Internet-facing IP addresses.
上記の処理を行うと、VPC 内の Amazon EC2 インスタンスにより生成された、インターネットにバインドされた全てのトラフィックが、VPN 接続の向こう側にルーティングされる。それらのトラフィックは、オンプレミスのネットワークを抜け出す前に、アウト･バウンド･ファイアウォールや、他のネットワーク･セキュリティ･デバイスをくぐり抜けることになる。
IP アドレスは、CIDR 表記法を用いて指定される。つまり、スラッシュに続く値は、そのアドレスに対するルーティング･プリフィックスにおけるビット数を表す。現時点では AWS アカウントごとに、1 つの VPC と限定されているが、さらに多くの VPC を使用するケースにおいては、その要望を聴かせて欲しい。
機能を論理的に分離するための VPC サブネットを用いるため、Amazon EC2 セキュリティ･グループに関しては、ただちにサポートすることはない。 現時点で使用している AMI や、Microsoft Windows AMI などを含む、最も一般的な AMI を開始できる。 ただし、Amaazon DevPay AMI については、まだ、開始できない。
Amazon EC2 インスタンスは、個別のネットワーク上にある。そこからのアクセスや、反対に、ネットワーク上で他のシステムからのアクセスは、それらがローカルであるかのように実行される。 そのように運用する限り、 EC2 インスタンスは追加のローカル･ネットワーク･リソースであり、NAT トランスレーションは存在しない。 VPC 内の EC2 インスタンスは、現時点において、インターネットと直結する IP アドレスを持たない。
Requirements to interoperate with our VPN implementation include:
この VPN 実装と相互運用される要件は、以下の項目を含む：
- Ability to establish IKE Security Association using Pre-Shared Keys (RFC 2409).
- Ability to establish IPSec Security Associations in Tunnel mode (RFC 4301).
- Ability to utilize the AES 128-bit encryption function (RFC 3602).
- Ability to utilize the SHA-1 hashing function (RFC 2404).
- Ability to utilize Diffie-Hellman Perfect Forward Secrecy in “Group 2” mode (RFC 2409).
- Ability to establish Border Gateway Protocol (BGP) peerings (RFC 4271).
- Ability to utilize IPSec Dead Peer Detection (RFC 3706).
Optional capabilities that we recommend include:
- Ability to adjust the Maximum Segment Size of TCP packets entering the VPN tunnel (RFC 4459).
- Ability to reset the “Don’t Fragment” flag on packets (RFC 791).
- Ability to fragment IP packets prior to encryption (RFC 4459).
We’ve confirmed that a variety of Cisco and Juniper hardware/software VPN configurations are compatible; devices meeting our requirements as outlined in the box at right should be compatible too. We also plan to support Software VPNs in the near future. If you want us to consider explicitly validating a device not on this list, please add your request to the Customer Gateway support thread located here.
我々は、Cisco と Juniper のハードウェア／ソフトウェア VPN コンフィグレーションとの互換性を確認した。つまり、図内の右側のボックスで概説されるように、我々の要件を満たしているデバイスも、互換性を持つべきである。さらに、近い将来において、ソフトウェア VPN をサポートすることも計画している。このリストで明示される以外の、デバイスについて検証を望むなら、Customer Gateway サポート･スレッドにリクエストして欲しい。
Amazon VPC functionality is accessible via the EC2 API and command-line tools. The ec2-create-vpc command creates a VPC and the ec2-describe-vpcs command lists your collection of VPCs. There are commands to create subnets, customer gateways, VPN gateways, and VPN connections. Once all of the requisite objects have been created, the ec2-attach-vpn-gateway connects your VPC to your network and allows traffic to flow. While most organizations will likely leave the VPN connection (and VPC) up and running indefinitely, you can drop the connection, terminate the instances, and even delete the VPC if you would like.
Amazon VPC は、EC2 API とコマンドライン･ツールによりアクセスできる。 ここでいう、 ec2-create-vpc コマンドが VPC を作成し、 ec2-describe-vpcs コマンドが VPC のコレクションをリストアップする。さらに、サブネットや、カスタマー･ゲートウェイ、VPN ゲートウェイ、VPN 接続などを作成するコマンドが提供される。すべての必要とされるオブジェクトが作成された後に、ec2-attach-vpn-gateway により VPC とオンプレミスが接続され、その間でトラフィックが流れ始める。おそらく、大半の組織が、VPN 接続（そして VPC）を制限することなく、また、動いたままにしておくだろうが、その接続を遮断し、インスタンスを終了することが可能であり、必要に応じて VPC を削除することさえ可能となる。
You only pay for what you use. Pricing is on a pay-as-you-go basis. VPCs, subnets, customer gateways, and VPN gateways are free to create and to use. You simply pay an hourly charge for each VPN connection you create, and for the data transferred through those VPN connections. EC2 instances within your VPC are priced at the normal On-Demand rate. We’ll honor the hourly rate for any Reserved Instances that you have but during the beta we cannot guarantee that Reserved Instances will always be available for deployment within your VPC.
支払いは、使用に応じたものとなる。 その価格は、pay-as-you-go に基づいたものとなる。 つまり、VPC や、サブネット、カスタマー･ゲートウェイ、VPN ゲートウェイの作成と使用じゃ無料である。つまり、それぞれの VPN 接続に対する１時間あたりの料金と、 VPN 接続を介して転送されるデータ量に対して、支払うことになる。また、VPC 内の EC2 インスタンスに関しては、標準的な On-Demand レートで課金される。 この Reserved Instances について、時間単位での課金が行えることを嬉しく思うが、ベータの期間内においては、個別の VPC 内で Reserved Instances が常に利用できるとは限らない。
Imagine the many ways that you can now combine your existing on-premise static resources with dynamic resources from the Amazon VPC. You can expand your corporate network on a permanent or temporary basis. You can get resources for short-term experiments and then leave the instances running if the experiment succeeds. You can establish instances for use as part of a DR (Disaster Recovery) effort. You can even test new applications, systems, and middleware components without disturbing your existing versions.
既存のオンプレミス･サイトにある静的なリソースと、Amazon VPC の動的なリソースを、どのようにして結合するのか、その方式についてイメージを膨らませて欲しい。自社のコーポレート･ネットワークを、恒久的に、あるいは、一時的に、拡張できる。短期的な実験としてリソースを利用し、もし成功したのなら、そのまま実運用へと進むことが可能となる。 また、DR（Disaster Recovery）の一部として、インスタンスを確立することもできる。さらには、新しいアプリケーションや、システム、ミドルウェア、コンポーネントなどのテストを、既存のバージョン体系を乱すことなく、実施することが可能となる。
As is the case with many of our betas, this one is launching in a single Availability Zone in the US-East region. You can use Amazon CloudWatch to monitor your instances, but you can’t use Elastic IP addresses, Auto Scaling or Elastic Load Balancing just yet.
これまでの、数多くのベータと同様に、Availability Zone in the US-East で開始される。 インスタンスをモニターするために Amazon CloudWatch は利用できるが、 Elastic IP アドレス／Auto Scaling／Elastic Load Balancing は、まだ使用できない。
Recall that all traffic from your instances routes through the VPN connection. For now, this includes traffic to other Amazon Web Services such as EC2 instances outside of your Amazon VPC, Amazon S3, Amazon SQS, and Amazon SimpleDB. You can create Elastic Block Store (EBS) volumes and attach them to your instances. EBS volumes created within your cloud can be moved to standard EC2 instances and vice-versa.
実行されているインスタンスからの、すべてのトラフィックに対する Recall は、VPN 接続を介してルーティングされる。 今のところ、Amazon VPC 外の EC2 インスタンスや、Amazon S3、Amazon SQS、Amazon SimpleDB といった、Amazon Web Services へ向けたトラフィックも含まれる。Elastic Block Store（EBS）ボリュームを作成し、対象となるインスタンスにアタッチすることもできる。クラウド内で作成された EBS ボリュームを、標準的な EC2 に移動すること、そして、反対方向での移動も可能となる。
I do want to mention a few of the things on our road map as well. First, we’re planning to let you directly reach the Internet from your VPC. In early discussions with potential users, we learned that most of them wanted to completely isolate their EC2 instances, routing all of the traffic back to their data center, so we gave this feature the highest priority. Later on, we’ll let you decide if and how you want to expose your VPC to the Internet. Second, we’re planning to let you specify the IP address of individual Amazon EC2 instances within a subnet. During this beta, Amazon EC2 instances are automatically assigned a random IP from the subnet’s designated IP address range. Third, we’re evaluating ways to allow you to filter traffic per subnet, kind of like how you might implement router ACLs. We’re already working on these items and on other additions to the core functionality we’re releasing today. If you have opinions on these items, or anything else you’d like to see in the service, e-mail us or post to the forum. This service is for you; we really need your feedback!
ここで、ロードマップについても、少し説明しておきたい。あなたの VPC からインターネットへ向けて、直接的に接続することを、最初の目標としている。パワー･ユーザーとの初期のディスカッションで我々が学んだことは、EC2 インスタンスを完全に分離するここと、そして、オンプレミス･データセンターへ向けて、すべてのトラフィックをルーティングすることを、彼らの大半が望んでいることだった。そのため、この機能に対して、最高の優先順位を与えた。この後、あなたの VPC をインターネットに公開するための、方式について決定していく。 第二に、サブネット内の個々の Amazon EC2 インスタンスにおける、IP アドレス指定について計画している。 このベータ期間において、Amazon EC2 インスタンスは、サブネットで指名された IP アドレス･レンジに基づき、ランダムかつ自動的に割り当てられる。 第三に、ルーター ACL の実装のように、サブネットごとのトラフィック･フィルタリングを実現するための方式を評価している。今日リリースしたコア機能に対して、すでに、それらの項目などに関する作業を進めている。これらの項目や、その他について意見があるなら、対象となるサービスを参照すことが可能であり、また、電子メールやフォーラム･ポストも可能である。これらのサービスは、あなたのためにある。つまり、我々は、あなたのフィードバックを必要とする！
We think you can put Amazon VPC to immediate use and can’t wait to hear about new and imaginative use cases for it. Please feel free to leave a comment on this blog or to send us some email.
Amazon VPC を使用すると、それらの新しい機能が待ちきれなくなると推測している。 このブログへのコメントや、電子メールなどで、遠慮なく意見を聴かせて欲しい。
– Jeff;
