7 ms·

1. AWS beats all others when it comes to security [1]. 2. EC2 is just one item in the package called AWS. Hence, if you just build something more than just "we

by tzury 13y ago

1. AWS beats all others when it comes to security [1]. 2. EC2 is just one item in the package called AWS. Hence, if you just build something more than just "web-app with *db" at the back-end, say a full blown platform, then I know no other option for you to get the full stack integrated API for Data-warehouse, DNS, Load-balancing, auto-scaling, billing, etc. 3. Speed is sometimes over-rated. You should be be speedy where it matters more. That is, how fast can you redeploy your entire cloud from scratch in case of a disaster should be more interesting to you than if a webpage takes 20 more ms to get to the browser. In our case, at AWS, it is a matter of < 20 minutes. 1: https://aws.amazon.com/compliance/ https://aws.amazon.com/compliance/ and https://aws.amazon.com/security/ https://aws.amazon.com/security/

nasalgoat 13y ago
20ms could mean the difference between a single digit rank in the App Store and a three digit rank. I see it every day - if my systems drop by 50ms average, I see a drop in rank. And 20ms? Try more like 300ms+ difference. Hell, sometimes a full second or more for some sites. Anyone who says total disaster recovery time is more important than total latency isn't running anything remotely to scale.
- tzury 13y ago
  Are you globally distributed? Are you using CloudFront? Those are cheap services which improve speed dramatically.
  - nasalgoat 13y ago
    Yes and yes, we're using a CDN. Neither of those change that EC2 instances are slow and have unreliable performance, and the network is abstracted to the point where you can't effectively control packet flow.
    - tzury 13y ago
      EC2 will not become faster. However, at least, for web traffic, CPU and IO are not the only factors. Network is, in fact, a major player in the latency, and by being globally distributed, configuring Route53 appropriately, and integrating CloudFront CDN, a given web-app gets a boost that I doubt a faster computer can beat.
      - nasalgoat 13y ago
        We experimented with EC2 in the early stages to use as a possible load failover, and no matter what we did, we could never get better than 150ms ping times even between internal zones. The EC2 network also has mysterious packet filtering on it that prevented IPSec tunnels from working correctly. I've managed to leverage CDN and globally distributed servers for a fraction of the cost of Amazon services just fine, and I have the added benefit of 100% full control of all aspects of it, including the network. A good analogy is that EC2 is like an interpreted language versus compiled - you can get a lot done and it's easier to get started, but if you're really serious about performance, you need to program in C.
dantiberian 13y ago
> 3. Speed is sometimes over-rated. You should be be speedy where it matters more. That is, how fast can you redeploy your entire cloud from scratch in case of a disaster should be more interesting to you than if a webpage takes 20 more ms to get to the browser. In our case, at AWS, it is a matter of < 20 minutes. Personally, I'd rather have 20ms shaved off my users time than a 20 minute disaster recovery time. Disasters happen perhaps once a year (on AWS, possibly less on dedicated servers), people are loading pages every day.
- tzury 13y ago
  That's perhaps depend on the type of your customers/users, and their priorities. If you have "users", then you might be right, as no harm will be done, if once in a few years, their free service will be shutdown for 18 hours. However, if your customers are running core and critical parts of their business on your system, this part becomes a significant factor in the equation.
  - frozenport 13y ago
    Another perspective: My nontechnical boss doesn't know about the 20ms difference (thinks her computer is slow?) but an outage is visible like the difference between day and night.
    - aidos 13y ago
      At 2s difference it's fair to say that a user is going to notice. Maybe even at 200ms. But at 20ms? I'm not sure that counts. I know it's just a fabricated number but the point is that the server you're running on won't make a difference to the user experience. And, probably in the case of the differences were talking in these machines, a user would never notice it. Edit: meant to say, I agree with you.
kppullin 13y ago
> 1. AWS beats all others when it comes to security [1]. While the compliance and security links are impressive, AWS still doesn't offer a BAA agreement for HIPAA/HITECH compliance. There are plenty of health care companies that are held back from AWS for this single reason. Surprisingly enough Microsoft is leading in this respect (or not, given their historical enterprise focus...) - http://www.windowsazure.com/en-us/support/security-and-compliance/compliance/ http://www.windowsazure.com/en-us/support/security-and-compl...
- WestCoastJustin 13y ago
  This is not entirely correct. AWS does offer AWS GovCloud which, provides an environment that enables agencies to comply with HIPAA regulations [1]. You have to be a US government organization to use it though. Updated: AWS also has a whitepaper on Creating HIPAA-Compliant Medical Data Applications with AWS [2]. Looks like this is support on the standard non GovCloud stack. [1] http://aws.amazon.com/about-aws/whats-new/2011/08/16/announcing-aws-govcloud-us/ http://aws.amazon.com/about-aws/whats-new/2011/08/16/announc... [2] http://media.amazonwebservices.com/AWS_HIPAA_Whitepaper_Final.pdf http://media.amazonwebservices.com/AWS_HIPAA_Whitepaper_Fina...
  - emidln 13y ago
    I don't believe you need to be a US government organization to use the GovCloud region. I think you just have to be a US corporation or person and pay through the nose. It's only available directly via signing an actual contract, not a la carte like normal AWS services.
  - kppullin 13y ago
    The trouble with HIPAA requirements is that they're not clearly defined and are open to a variety of interpretations. Our experts advise a safe, CYA approach and mandate a BAA agreement is in place with every partner touching sensitive patient data, even if encrypted and protected on multiple levels. Thus far Amazon is not accommodating to such a request. Other's have their own opinions and, in the end, we all weigh the risks vs rewards (including Amazon itself - I'm sure they've plenty of reasons of operating in their present gray area).
Corrado 13y ago
1. Agreed. IAM is really, really, nice, and I find myself missing it greatly when I'm on other platforms. 2. We use quite a few more things than EC2 for our systems. - SQS eliminates the need to build / manage a queuing system. - DynamoDB/SimpleDB eliminate the need to build / manage a distributed data store. - OpsWorks eliminates the need for a DevOps team (mostly). - ELB eliminates the need to build / manage a load balancer. - SES seamlessly takes care of out-bound mail. - Direct Connect gives us a way to extend our DC tools into the "cloud". - And to top it all off, I can bring up any/all of these services at a moments notice, run some experiments, and then shut them down when I'm done. I don't think there are very many vendors that can help us do these things with this much flexibility. Yea, AWS can be expensive, but we feel like its worth it.
banachtarski 13y ago
It's not just a question of speed. If your machines are slow, that means you need more machines to handle your throughput, which means you are paying for that 20 ms slowdown in actual dollars.
- threeseed 13y ago
  Not necessarily. AWS has a far superior network to almost anything else out there. Machine performance is not the only important part.
  - nirvdrum 13y ago
    Sure, but the whole thing is predicated on the 20ms slowdown coming from a slow machine, not network latency. And that's a pretty good assumption. Due to RAM limitations and abysmal performance, I could maybe push 15 concurrent requests on a c1.medium running a Rails app in Passenger with a non-CoW Ruby. Forking is terribly slow on EC2. An m1.small was out of the question.
    - justincormack 13y ago
      But if you are using Rails you care more about convenience than performance anyway.
      - nirvdrum 13y ago
        That's one way to look at it. Another is when this app started 3.5 years ago, Rails & the app had a drastically different performance profile and Amazon didn't have super-over-subscribed hardware. Not that it matters much, but there's nothing convenient about having to engineer around EC2. And doubling your capacity or constantly upgrading instance sizes is not cheap, nor a scalable solution in any practical sense. Pick your language though. With terrible forking performance, any process-based execution environment is going to have similar issues. And I found running a servlet container on anything smaller than an m1.large to be an utter waste. 1.7 GB RAM isn't enough for many JVM-based apps and threading could easily overwhelm the system. Anything less than high I/O capacity just can't keep up.
orthecreedence 13y ago
In regards to speed, I think one place EC2/EBS fails (I'm speaking based on other people's experiences) is the consistency. 200ms is better than 100ms if you get 200ms every time, but from what I've read, a lot of AWS services are all over the board. This makes infrastructure very hard to provision and predict.

by tzury 13y ago

nasalgoat 13y ago

20ms could mean the difference between a single digit rank in the App Store and a three digit rank. I see it every day - if my systems drop by 50ms average, I see a drop in rank. And 20ms? Try more like 300ms+ difference. Hell, sometimes a full second or more for some sites. Anyone who says total disaster recovery time is more important than total latency isn't running anything remotely to scale.

tzury 13y ago
Are you globally distributed? Are you using CloudFront? Those are cheap services which improve speed dramatically.
- nasalgoat 13y ago
  Yes and yes, we're using a CDN. Neither of those change that EC2 instances are slow and have unreliable performance, and the network is abstracted to the point where you can't effectively control packet flow.
  - tzury 13y ago
    EC2 will not become faster. However, at least, for web traffic, CPU and IO are not the only factors. Network is, in fact, a major player in the latency, and by being globally distributed, configuring Route53 appropriately, and integrating CloudFront CDN, a given web-app gets a boost that I doubt a faster computer can beat.
    - nasalgoat 13y ago
      We experimented with EC2 in the early stages to use as a possible load failover, and no matter what we did, we could never get better than 150ms ping times even between internal zones. The EC2 network also has mysterious packet filtering on it that prevented IPSec tunnels from working correctly. I've managed to leverage CDN and globally distributed servers for a fraction of the cost of Amazon services just fine, and I have the added benefit of 100% full control of all aspects of it, including the network. A good analogy is that EC2 is like an interpreted language versus compiled - you can get a lot done and it's easier to get started, but if you're really serious about performance, you need to program in C.

dantiberian 13y ago

> 3. Speed is sometimes over-rated. You should be be speedy where it matters more. That is, how fast can you redeploy your entire cloud from scratch in case of a disaster should be more interesting to you than if a webpage takes 20 more ms to get to the browser. In our case, at AWS, it is a matter of < 20 minutes. Personally, I'd rather have 20ms shaved off my users time than a 20 minute disaster recovery time. Disasters happen perhaps once a year (on AWS, possibly less on dedicated servers), people are loading pages every day.

tzury 13y ago
That's perhaps depend on the type of your customers/users, and their priorities. If you have "users", then you might be right, as no harm will be done, if once in a few years, their free service will be shutdown for 18 hours. However, if your customers are running core and critical parts of their business on your system, this part becomes a significant factor in the equation.
- frozenport 13y ago
  Another perspective: My nontechnical boss doesn't know about the 20ms difference (thinks her computer is slow?) but an outage is visible like the difference between day and night.
  - aidos 13y ago
    At 2s difference it's fair to say that a user is going to notice. Maybe even at 200ms. But at 20ms? I'm not sure that counts. I know it's just a fabricated number but the point is that the server you're running on won't make a difference to the user experience. And, probably in the case of the differences were talking in these machines, a user would never notice it. Edit: meant to say, I agree with you.

kppullin 13y ago

> 1. AWS beats all others when it comes to security [1]. While the compliance and security links are impressive, AWS still doesn't offer a BAA agreement for HIPAA/HITECH compliance. There are plenty of health care companies that are held back from AWS for this single reason. Surprisingly enough Microsoft is leading in this respect (or not, given their historical enterprise focus...) - http://www.windowsazure.com/en-us/support/security-and-compliance/compliance/ http://www.windowsazure.com/en-us/support/security-and-compl...

WestCoastJustin 13y ago
This is not entirely correct. AWS does offer AWS GovCloud which, provides an environment that enables agencies to comply with HIPAA regulations [1]. You have to be a US government organization to use it though. Updated: AWS also has a whitepaper on Creating HIPAA-Compliant Medical Data Applications with AWS [2]. Looks like this is support on the standard non GovCloud stack. [1] http://aws.amazon.com/about-aws/whats-new/2011/08/16/announcing-aws-govcloud-us/ http://aws.amazon.com/about-aws/whats-new/2011/08/16/announc... [2] http://media.amazonwebservices.com/AWS_HIPAA_Whitepaper_Final.pdf http://media.amazonwebservices.com/AWS_HIPAA_Whitepaper_Fina...
- emidln 13y ago
  I don't believe you need to be a US government organization to use the GovCloud region. I think you just have to be a US corporation or person and pay through the nose. It's only available directly via signing an actual contract, not a la carte like normal AWS services.
- kppullin 13y ago
  The trouble with HIPAA requirements is that they're not clearly defined and are open to a variety of interpretations. Our experts advise a safe, CYA approach and mandate a BAA agreement is in place with every partner touching sensitive patient data, even if encrypted and protected on multiple levels. Thus far Amazon is not accommodating to such a request. Other's have their own opinions and, in the end, we all weigh the risks vs rewards (including Amazon itself - I'm sure they've plenty of reasons of operating in their present gray area).

Corrado 13y ago

1. Agreed. IAM is really, really, nice, and I find myself missing it greatly when I'm on other platforms. 2. We use quite a few more things than EC2 for our systems. - SQS eliminates the need to build / manage a queuing system. - DynamoDB/SimpleDB eliminate the need to build / manage a distributed data store. - OpsWorks eliminates the need for a DevOps team (mostly). - ELB eliminates the need to build / manage a load balancer. - SES seamlessly takes care of out-bound mail. - Direct Connect gives us a way to extend our DC tools into the "cloud". - And to top it all off, I can bring up any/all of these services at a moments notice, run some experiments, and then shut them down when I'm done. I don't think there are very many vendors that can help us do these things with this much flexibility. Yea, AWS can be expensive, but we feel like its worth it.

banachtarski 13y ago

It's not just a question of speed. If your machines are slow, that means you need more machines to handle your throughput, which means you are paying for that 20 ms slowdown in actual dollars.

threeseed 13y ago
Not necessarily. AWS has a far superior network to almost anything else out there. Machine performance is not the only important part.
- nirvdrum 13y ago
  Sure, but the whole thing is predicated on the 20ms slowdown coming from a slow machine, not network latency. And that's a pretty good assumption. Due to RAM limitations and abysmal performance, I could maybe push 15 concurrent requests on a c1.medium running a Rails app in Passenger with a non-CoW Ruby. Forking is terribly slow on EC2. An m1.small was out of the question.
  - justincormack 13y ago
    But if you are using Rails you care more about convenience than performance anyway.
    - nirvdrum 13y ago
      That's one way to look at it. Another is when this app started 3.5 years ago, Rails & the app had a drastically different performance profile and Amazon didn't have super-over-subscribed hardware. Not that it matters much, but there's nothing convenient about having to engineer around EC2. And doubling your capacity or constantly upgrading instance sizes is not cheap, nor a scalable solution in any practical sense. Pick your language though. With terrible forking performance, any process-based execution environment is going to have similar issues. And I found running a servlet container on anything smaller than an m1.large to be an utter waste. 1.7 GB RAM isn't enough for many JVM-based apps and threading could easily overwhelm the system. Anything less than high I/O capacity just can't keep up.

orthecreedence 13y ago

In regards to speed, I think one place EC2/EBS fails (I'm speaking based on other people's experiences) is the consistency. 200ms is better than 100ms if you get 200ms every time, but from what I've read, a lot of AWS services are all over the board. This makes infrastructure very hard to provision and predict.