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

31–40 of 152 posts

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

#31

Post by berkay »

mbreese wrote: post #11

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.

AWS != EC2. Do not assume that AWS is only used as VMs. It's different for everyone but AWS provides massive savings for many companies. It makes sense for many use cases in addition to elastic workloads.

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

#32

Post by toomuchtodo »

ceejayoz wrote: post #20
toomuchtodo wrote: post #5

Earlier quoted context omitted.

I've always seen issues pushing objects directly to S3 from a browser using CORS. YMMV.

You can specify CORS headers for S3, or you can just use a standard form POST.

You still need a stub API for generating the signature to sign the upload requests to S3, correct?

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

#33

Post by bearbin »

AaronBBrown wrote: post #21
dangrossman wrote: post #15

Earlier quoted context omitted.

They don't have to make any purchasing decisions. They can rent servers from companies like Softlayer and Rackspace (#3 and #4 behind AWS for YC startups), or spin up much cheaper VPS's (Linode's #2). We're talking $120/month commitments, not buying hardware and driving to a data center to install it. Deploying to a freshly imaged physical server is the same as deploying to EC2, and they can be provisioned for you in…

As someone who has worked w/ AWS (and Rackspace) for several years with multiple startups... Unless they have dramatically improved their offering in the last couple years, an hour or two from "I need a new server" to delivery is 1) not an accurate timeframe for physical servers from Rackspace and 2) even if it was realistic, that's an eternity when you are trying to iterate quickly. I can have a new server in 30 sec…

DigitalOcean - Same or better speed, 1/6 or less of the price of ECC.

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

#34

Post by freerobby »

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?

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

#37

Post by pavel_lishin »

freerobby wrote: post #34

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?

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.

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

#38

Post by mslot »

Be very careful with assigning IAM roles to EC2 instances. Many web applications have some kind of implicit proxying, e.g. a function to download an image from a user-defined URL. You might have remembered to block 127.0.0.*, but did you remember 169.254.169.254? Are you aware why 169.254.169.254 is relevant to IAM roles? Did you consider hostnames pointed to to 169.254.169.254? Did you consider that your HTTP client might do a separate DNS look-up? etc.

There are other subtleties which make roles hard to work with. The same policies can have different effects for roles and users (e.g., permission to copy from other buckets).

IAM Roles can be useful, especially for bootstrapping (e.g. retrieving an encrypted key store at start-up), but only use them if you know what you're doing.

Conversely, tips like disabling SSH have negligible security benefit if you're using the default EC2 setup (private key-based login). It's really quite useful to see what's going on in an individual server when you're developing a service.

Also, it does matter whether you put a CDN in front of S3. Even when requesting a file from EC2, CloudFront is typically an order of magnitude faster than S3. Even when using the website endpoint, S3 is not designed for web sites and will serve 500s relatively frequently, and does not scale instantly.

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

#40

Post by mscarborough »

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.
Post reply on HN