Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AWS Tips I Wish I'd Known Before I Started

wblinks.com

Post reply on HN
Print view View original

131–140 of 152 posts

Re: AWS Tips I Wish I'd Known Before I Started

#131

Post by durzagott »

richadams wrote: post #54
pavel_lishin wrote: post #37

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.

This is correct. The tip about disabling SSH isn't about security, it's just about quickly highlighting areas where you're not automated. When developing an application for example, it's often necessary to SSH in to play with some things. But once you've ready to go to production, you want as much automation as possible. Forcing yourself to not use SSH will quickly show you where you aren't automated.

What if my automation tool uses SSH (ie, Ansible)?

Re: AWS Tips I Wish I'd Known Before I Started

#132

Post by jon-wood »

mbreese wrote: post #53
AaronBBrown wrote: post #47

Earlier quoted context omitted.

DO, Linode, and Rackspace have lower bottom line costs, but a (much) smaller feature set which means more operational work. Especially when kicking things off, developer and operational time is often far more valuable than the cost of the servers.

Yeah, but it you start out using too much of the AWS tools, you're far more likely to get trapped in the AWS infrastructure and end up paying significantly more in the long term (which is what they want!). I'm not saying that AWS doesn't have useful features, but you need to appreciate the costs of these things before starting. If you need to spend a bit more time on devops in the beginning, then so be it. If you're…

Depending which tools you're using you'll have to do a bit of work to migrate out of AWS, but there tools are usually pretty standard stuff managed for you.

For example, RDS is just a database instance with management. You'd have to invest some time to replicate what AWS already does for you, but its not rocket science. The same for Elasticache, Autoscaling, ELB, and most of their other services.

Re: AWS Tips I Wish I'd Known Before I Started

#134

Post by tel »

mscarborough wrote: post #40
Fasebook wrote: post #36

What's the point of auditing security in the Cloud? Is there any point at which you can know that your making any progress?

Just one example -- Amazon will sign a Business Associate's Agreement for HIPAA compliance. That doesn't absolve you of your application security responsibilities, but it does give you piece of mind on the PAAS EC2/S3 side of things.

For further note though, they won't unless you buy dedicated instances. This also disables RDS.

Re: AWS Tips I Wish I'd Known Before I Started

#135

Post by richadams »

Fizzer wrote: post #125

> you pay the much cheaper CloudFront outbound bandwidth costs, instead of the S3 outbound bandwidth costs. 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…

Doh, I feel stupid now. I only looked at bandwidth costs, not the request prices. That's what I get for editing my post late at night based on reading, instead of based on personal experience.

For low bandwidth, you're absolutely right, the costs are at best the same. For high bandwidth however (once you get above 10TB), CloudFront works out cheaper (by about $0.010/GB, depending on region). But that wasn't taking into account the request cost, which as you point out, is more expensive on CloudFront, which can negate the savings from above depending on your usage pattern.

I'll update my post accordingly, thanks for pointing this error out!

Re: AWS Tips I Wish I'd Known Before I Started

#136

Post by berkay »

waps wrote: post #123
berkay wrote: post #99

Earlier quoted context omitted.

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…

Considering just how much more expensive AWS is, I have my doubts on this. AWS also really likes "hiding" costs, like bandwidth costs. It's not obvious that most sites will go over the bandwidth limit and pay extra, whereas for sites on VPS providers, this won't happen. In reality they have a billion different line items on every bill, and most are not mentioned on their pricing pages. Expect to pay a LOT more than y…

I can only give you a datapoint. This has not been the case in our case. We never paid more than what we expected.

If you think VPS providers is an alternative to AWS, you have an entirely different use case than ours. For an application with high availability requirements, messages queues, scalable data store, etc. admin work is not "monthly backups". Implementing and maintaining highly available load balancing, message queues, data stores, DNS, auto scaling, etc. all require a lot of work, and often skills that you may not have in the team. AWS makes these tasks easier. You still have to do admin work, but much less of it, and don't have to be expert at each one. That's worth a lot.

Re: AWS Tips I Wish I'd Known Before I Started

#137

Post by tyw »

tedivm wrote: post #121
Consultant32452 wrote: post #63

Earlier quoted context omitted.

If you're pushing anything close to real bandwidth you're probably getting an individually negotiated price that is not public.

Not with Amazon you aren't, they are amazingly stringent in their pricing on this matter.

http://aws.amazon.com/cloudfront/pricing/ the reserved capacity pricing is much better than the on demand pricing. Basically like EC2 on demand vs reservations. We set our reserved capacity at about 70-80% of what we expect to use most of the time. We could probably shave a few tenths of a cent per gig off but we get a good price on everything above what we've reserved so it's worked out.

If you use a lot of cloudfront bandwidth without setting up a reservation, yeah... you're gonna pay through the nose.

Re: AWS Tips I Wish I'd Known Before I Started

#138

Post by richadams »

durzagott wrote: post #131
richadams wrote: post #54

Earlier quoted context omitted.

This is correct. The tip about disabling SSH isn't about security, it's just about quickly highlighting areas where you're not automated. When developing an application for example, it's often necessary to SSH in to play with some things. But once you've ready to go to production, you want as much automation as possible. Forcing yourself to not use SSH will quickly show you where you aren't automated.

What if my automation tool uses SSH (ie, Ansible)?

Someone else pointed this out too. The goal of the tip is really to stop users SSHing in just to fix that one little thing, so you could still allow your automation frameworks SSH access and just disable it for users (the idea is to disable in firewall, not turning off SSH on your server, that way you can still use it for emergencies). The idea worked well for me, but obviously isn't for everyone, YMMV.

Re: AWS Tips I Wish I'd Known Before I Started

#139

Post by banachtarski »

ErrantX wrote: post #127
banachtarski wrote: post #65

Earlier quoted context omitted.

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…

I don't really follow you here; AWS is infrastructure. So all the chef/puppet stuff has to happen anyway. 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…

When I said AWS I was speaking more about the entire ecosystem which includes a load balancer, databases with failover, snapshotting, backups, dns lookups, and more.

Re: AWS Tips I Wish I'd Known Before I Started

#140

Post by jamiesonbecker »

Estragon wrote: post #133

How hard is it to roll your own version of AWS's security groups? I want to set up a Storm cluster, but the methods I have come up with for firewalling it while preserving elasticity all seem a bit fragile.

Check out Dome9. Amazing tool and I think they work with both AWS and elsewhere.
Post reply on HN