S3/Cloudfront: I use these for static file (images, CSS, Javascript, etc). A current project I'm working on requires serving tens of thousands of images, so rather than having to deal with storing these myself, dealing with backups, etc. Cloudfront also serves these from edge locations closer to users for better performance.
EC2/EBS/ELB/RDS: My projects are too big for shared hosting, too small to buy a cluster of servers. EC2 is the best option for "in-between" projects. I can scale vertically or horizontally very easily. Elastic load balancing makes this very easy...just clone a new server from a storeed EBS snapshot and add it to the load balancer. I write my apps to point to a common RDS database instance (soon to be upgraded to support read replicas).
I'm a developer, not a sys admin, so I use the AWS Management Console most of the time. That makes it really easy to add/remove servers, create new S3 buckets, etc.
The startup is a Virtual Demos, Evaluations and Training solution. It uses the EC2 back-end to issue machines (eg. to give out a demo to prospective customers, or to issue a training environment to a student in a classroom environment).
In practice the startup uses EC2 to lease out machines, but itself is running on EC2. We use all the AWS goodies to scale the environment as demand builds up. So far I've found AWS to be an awesome service, and quite a game changes. If you're not aware, they now offer 'Micro' Unix boxes for 2 cents/hr and Windows boxes for 3 cents/hr, which is an awesome price point for any startup.
I'm using S3, EC2 for mostly all test-servers, and some EC2 instances also for production modus (resources were allocated when we need them). But as already mentioned, you have to be aware of the costs - so, I combine AWS with dedicated hosted servers also, because it is still cheaper yet.
The best things within AWS-Services are from my point, that you save CAPEX for your own infrastructure and you're more flexible in scaling (if your architecture supports that). But keep in mind that AWS has some "hidden" costs you should be aware about (charge for requests, own IP-addresses etc..)
I use EC2 for my builds. It means that the builds are fast, clean and known reproducible since they all start from a clean Ubuntu LTS install. The build system gets all upstream tarballs (eg. glibc, openssl etc) from my S3 bucket.
I also find EC2 really handy for quick experiments on different versions of Ubuntu and Debian. It is much quicker than setting up/maintaining images in VMware/VirtualBox.
I get the basics: EC2 VPS for computing power, and you get to pick a stack from a list of AMIs or customize one to fit your needs, S3 for storage, ClouFront CDN for better global distribution, but whenever I want to take a closer look, I feel so overwhelmed by the options that seem to be increasing over time.
What's the best reading material to get a solid, up to date foundation?
We use S3/ CloudFront/ IAM / Import-Export in our CloudBerry Explorer freeware tool to help manage all those services http://s3.cloudberrylab.com/
CloudBerry Explorer makes managing files in Amazon S3 storage EASY. By providing a user interface to Amazon S3 accounts, files, and buckets, CloudBerry lets you manage your files on cloud just as you would on your own local computer.
We also use S3 in our http://backup.cloudberrylab.com/ product line. CloudBerry Online Backup provides a powerful Backup and Restore program designed to leverage Amazon S3 storage to make your disaster recovery plan simple, reliable, and affordable.
Besides, we use EC2 machines to make rebranded software for our customers on demand. E.g. you the customer requests a build, we fire up EC2 instance, run it and shut it down. We also run scalability testing on EC2 to see how our product behaves with hundreds of simultaneous users.
6 comments
[ 1.8 ms ] story [ 38.6 ms ] threadEC2/EBS/ELB/RDS: My projects are too big for shared hosting, too small to buy a cluster of servers. EC2 is the best option for "in-between" projects. I can scale vertically or horizontally very easily. Elastic load balancing makes this very easy...just clone a new server from a storeed EBS snapshot and add it to the load balancer. I write my apps to point to a common RDS database instance (soon to be upgraded to support read replicas).
I'm a developer, not a sys admin, so I use the AWS Management Console most of the time. That makes it really easy to add/remove servers, create new S3 buckets, etc.
The startup is a Virtual Demos, Evaluations and Training solution. It uses the EC2 back-end to issue machines (eg. to give out a demo to prospective customers, or to issue a training environment to a student in a classroom environment).
In practice the startup uses EC2 to lease out machines, but itself is running on EC2. We use all the AWS goodies to scale the environment as demand builds up. So far I've found AWS to be an awesome service, and quite a game changes. If you're not aware, they now offer 'Micro' Unix boxes for 2 cents/hr and Windows boxes for 3 cents/hr, which is an awesome price point for any startup.
Simon @ LabSlice
I also find EC2 really handy for quick experiments on different versions of Ubuntu and Debian. It is much quicker than setting up/maintaining images in VMware/VirtualBox.
I get the basics: EC2 VPS for computing power, and you get to pick a stack from a list of AMIs or customize one to fit your needs, S3 for storage, ClouFront CDN for better global distribution, but whenever I want to take a closer look, I feel so overwhelmed by the options that seem to be increasing over time.
What's the best reading material to get a solid, up to date foundation?
We also use S3 in our http://backup.cloudberrylab.com/ product line. CloudBerry Online Backup provides a powerful Backup and Restore program designed to leverage Amazon S3 storage to make your disaster recovery plan simple, reliable, and affordable.
White-label versions of CloudBerry Backup will be available to our partners via the CloudBerry Lab Partner Program http://www.cloudberrylab.com/default.aspx?page=mbs
Besides, we use EC2 machines to make rebranded software for our customers on demand. E.g. you the customer requests a build, we fire up EC2 instance, run it and shut it down. We also run scalability testing on EC2 to see how our product behaves with hundreds of simultaneous users.