Archive for January, 2013

Using and Managing AWS – Plan Your Instance Size

January 28th, 2013 Comments off

Amazon machine instances come in a variety of sizes. The default of most GUI management consoles is the small instance. The specific sizes were spelled out in chapter 2 but as a refresher, there is the small (1 compute unit (CU) and 1.7GB of ram), large (4CU and 7.5GB of ram), extra large (8CU and 15GB of ram), high-CPU medium (5CU and 1.7GB of ram) and high-CPU extra large (20CU and 7GB of ram).

The fact that large, medium and extra large are mixed like that tells me that Amazon is keeping its options open for additional sizes in the future. Really, they can make pretty much any size desired. Generate a template and make it available and new size is available. For now, I think what they offer will accommodate just about anyone.

When you size your hardware for purchase, there is a huge burden for getting it right the first time. You may need as much as six months of lead time to purchase a machine. That sometimes means buying your production hardware before coding even begins. That’s an awful way to do business.

This is also one of the major reasons for cloud computing. Start your development project and pick the small instance. If, as you build your application, you need to scale larger, shut down your small instance (making sure to persist data to EBS volumes), start up a larger AMI and attach the EBS volumes.

This is also good for testing, as you add testers and do volume testing, you may find that your guesstimated instance will not be large enough. No problem, the same steps as in development, save to EBS and attach to a larger instance.

It is important to size your hardware correctly in production, but the pressure is off with cloud computing. Even if you go to production and need to scale later, with dynamic IPs and virtual hosting, you can resize your instance with very little (and possibly no) downtime.

Categories: cloud computing Tags:

Using and Managing AWS – Configure the Security Group

January 25th, 2013 Comments off

Configure the Security Group

The next step is to plan out your security group. Remember that the security group is your instance’s firewall. You open (or close) ports, as needed, for the applications that will be running.

The first port to open is 22. Port 22 is used by SSH and is your primary means of connecting to the instance.

If you will be running a database, you will need to open the appropriate port. For example, Oracle uses a default port of 1521. It is a best practice not to use the default so you may want to open 15120 or something like that. The same applies for any other database using TCP connections.

If you are going to be running web applications, you will need to open ports 80 and, if running SSL, 43. I usually open alternative web ports such as 8000 and 8080 to allow me development and administrative access.

The ports that you open are determined by the applications that you will be running. You can open up all of the ports if you want to but that is inherently insecure. As a best practice, only open those ports that are required.

You cannot change the security group in a running instance but you can open and close ports while the instance is running. You can start with just port 22 and modify as needed.

Categories: cloud book, cloud data Tags: