121–130 of 152 posts
Earlier quoted context omitted.
Even cloudfront is ridiculously overpriced for a CDN. If you're pushing anything close to real bandwidth you could do a lot better elsewhere.
If you're pushing anything close to real bandwidth you're probably getting an individually negotiated price that is not public.
Earlier quoted context omitted.
True, but outside of S3 and Route53, how much under the AWS umbrella is much use without using at least one EC2 instance? I can see a lot of benefit to using S3 without EC2, but after that, I'm not sure what else would be possible. Care to elaborate more? Can you use their queues and database tools w/o using EC2? (If you are using a VPC, maybe?)
Not sure why it has to be without EC2 to be useful. The main benefit is indeed the fact that you can have VMs, queue, load balancers, databases, DNS, cache, etc. all using consistent APIs, etc. You can create dev/test environments that are as close to prod as possible with fraction of the cost, etc. In our case (and I'm pretty sure we're not in the fringe) when you consider all costs including the administrative over…
Expect to pay a LOT more than you'd expect to pay from the pricing page.
I don't get the whole line of reasoning : either your project is not important and having weekly or monthly backups is certainly sufficient. In such a case, having a script to backup a VPS is by far the most cost efficient way to run the project.
If your project is important enough to have a complex AWS setup, you have an admin anyway.
"But you can trust amazon". Well, no : http://www.businessinsider.com.au/amazon-lost-data-2011-4 (note that disasters on VPS/dedicated servers are also rare)
If you're making complex AWS setups because "it's cool", then by all means, but keep in mind that you're paying a lot for the privilege. Don't do this on production.
What? CloudFront bandwidth costs are, at best, the same as S3 outbound costs, and at worse much more expensive.
S3 outbound costs are 12 cents per GB worldwide. [1]
CloudFont outbound costs are 12-25 cents per GB, depending on the region. [2]
Not only that, but your cost-per-request on CloudFront way more than S3 ($0.004 per 10,000 requests on S3 vs $0.0075-$0.0160 per 10,000 requests on CloudFront)
[1] http://aws.amazon.com/s3/pricing/ [2] http://aws.amazon.com/cloudfront/pricing/
Earlier quoted context omitted.
"Can you use their queues and database tools w/o using EC2?" Yes, you very easily can. RDS is a simple setup, and so is SQS (queuing). The same goes for Dynamo and Redshift.
Are you really going tolerate 10+ ms of latency between a database, and an app server? I have never personally tried it, but it seems like it would be a disaster.
At most it's been 4 to 6 ms. And that has coped with our heaviest load.
Earlier quoted context omitted.
Can you list some of those tools and provide an estimate of how long they take to configure and how much day-to-day support they require?
Sure. Pop in opscode chef. Took me a weekend to write the basic framework, 3 weeks to make it solid. The 3 weeks more than paid for itself and hosting the config servers with them is a couple hundred a month. I could've hosted it myself too. This includes support for things like a load balancer, heterogeneous nodes (db, app, cache, chat, etc). Ansible, puppet, sprinkler, and the like would take a similar amount of ti…
The benefit of AWS is that you have some immediate bootstrap, and simple auto scaling. This last is a killer feature. Being able to scale your caches and load balances silently, based on metrics, is a real time and money saver.
Sure. You need to have a level of scale to need that :) but when you do, AWS can have some good features.
Can you (or somebody else) elaborate on disabling ssh access? Is this a dogma of "automation should do everything" or is there a specific security concern you are worried about? What is the downside of letting your ops people ssh into boxes, or for that matter of their needing to do so?
Earlier quoted context omitted.
Based on the article, it seems it's there to make sure that you're automating everything, instead of logging in to do that one little thing by hand.
Thanks. Does anybody else here agree with this mentality? This seems a major mispractice to me. I've worked at companies with as few as two people to as many as 50,000 people. None of them have had production systems that are entirely self-maintaining. Most startups are better off being pragmatic than investing man-years of time handling rare error cases like what to do if you get an S3 upload error while nearly out…
I'd also add to the list - make sure that AWS is right for your workload. If you don't have an elastic workload and are keeping all of your servers online 24/7, then you should investigate dedicated hardware from another provider. AWS really only makes sense ($$) when you can take advantage of the ability to spin up and spin down your instances as needed.
The startup I'm working for has minimal scaling required but we still use AWS despite the higher cost for EC2 because the broad ecosystem of AWS products make it easier to develop interesting things quickly and efficiently. If we went with all of our own dedicated hardware, or cheaper instances from a different cloud provider then we'd miss out on ELB, have slower and more expensive communication to and from S3, not…