So as part of getting ready for IPEXPO next week in London, I decided to build a domain and Citrix Xenapp 6.5 environment running the Windows 7 theme for demo purposes. I am now working on getting this all fronted by the Netscaler tech preview, which I will post about once I have completed/got more info on.
Anywho, this post is to quickly outline my thoughts on how AWS works and how I have generally found this experience (so far).
If you can get your head around how Amazon delivers the AWS service, it is quite easy to deploy an environment up in the AWS “Cloud”.My personal opinion to ensure that you get full control over network topology, instances and security is to run it in AWS VPC, which is the virtual private cloud. (VPC FAQ)
So why not EC2 instead of VPC… generally it would do the job but it has a few flaws for larger businesses that maybe more security minded. Below are a couple of issues with EC2:
- All nodes are internet addressable. This doesn’t make much sense for nodes which have no reason to exist on the global internet. For example: a database node should not have any public internet hostname/IP.
- All nodes are on a shared network, and are addressable to each other. That means an EC2 node launched by a user “Bob” can access any of EC2 nodes launched by a user “Fred.” Note that by default, the security groups disallow this, but its quite easy to undo this protection, especially when using custom security groups.
- No public vs private interface. Even if you wanted to disable all traffic on the public hostname, you can’t. At the network interface level each EC2 instance only has one network interface. Public hostnames and Elastic IPs are routed onto the “private” network.
The VPC allows the following features on top of resolving the issues mentioned above:
- A Virtual Private Cloud (VPC): an isolated portion of the AWS cloud. You define a VPC’s IP address space from a range you select.
- Subnet: a segment of a VPC’s IP address range where you can place groups of isolated resources.
- Internet Gateway: the Amazon VPC side of a connection to the public Internet.
- NAT Instance: An EC2 instance that provides Port Address Translation for non-EIP instances to access the Internet via the Internet Gateway.
- Hardware VPN Connection: a hardware-based VPN connection between your Amazon VPC and your datacenter, home network, or co-location facility.
- Virtual Private Gateway: the Amazon VPC side of a VPN Connection.
- Customer Gateway: Your side of a VPN Connection.
- Router: Routers interconnect Subnets and direct traffic between Internet Gateways, Virtual Private Gateways, NAT instances and Subnets.
With the VPC you can link your current Datacenter with the AWS environment you build and run a seamless connection between the 2 using a VPN connection…. possibly another post for this one though 🙂
In my opinion AWS is quite simple to use. You can create your own network topology, security rules, instances etc all in one web console and the online support/admin guides are quite well written and generally get you sorted. Once you have your AWS VPC network and security rules in place the rest is just as if you were sat working in your own datacenter.
I found that if you create an initial admin instance and assign an EIP to that then RDP to that admin instance and connect to all other instances from there that management of the environment was easier than assigning a EIP to each instance you wanted to get access to.
One area I found a little frustrating with AWS was keeping track on how much the environment running was costing, as I didnt want to run a huge bill during the build phase of the environment and I wanted to try and see what cost benefits running in the Amazon Cloud offered. The way I worked the build phase was to keep the environment powered down until I came to work on it, otherwise you are paying for each hour or amount of bandwidth you are using. As well as this all instances were set to a type of M1.Small, so that when they were powered up they werent being charged the larger per hour fees. Obviously when/if you went live with AWS you could set scripts to power down certain aspects of your environment in the evening to save money and you can change your instance type depending on resources required by each instance.
As an example during my build phase it has cost roughly no more than $20 for over 52hours of uptime…. that isnt a lot but every penny counts 😛
A customer I have been liaising with recently has got a VPC environment that connects back to their corporate datacenter and runs at about $1000 a month depending on usage.
As an FYI – EC2/VPC customer can only have 5EIPs, unless granted more by Amazon (http://aws.amazon.com/contact-us/eip_limit_request/)
Also when creating security rules dont use 0.0.0.0/0 for anything as this is a big risk, take the time to create the right rules for communication between each instance.
On a final note when deploying instances ensure you select different availability zones for systems that need to be resilient, if you forget this all of your instances will fall into one availability zone which gives you no HA in the AWS VPC.
