How We Saved $132k a Year With an IT Infrastructure Audit

Re:How We Saved $132k a Year With an IT Infrastructure Audit by toomuchtodo on Wednesday April 06, 2016 @11:16AM (#11439308)

> The tradeoff for CPU stealing is that now you have multiple services running on the same machine so if the machine goes down you lose them all. On AWS it is very unlikely that two of your VMs end up on the same physical machine.

Yes. But its also very likely that when AWS has issues, the entire region is going to be having problems, like last Saturday (IAM, EC2, Autoscaling, etc broken badly for 6 hours).

> But we don't need pesky things like 24hr uptime and dedicated bandwidth for dev servers.

You're not getting this SLA unless you're managing everything yourself and are globally redundant. AWS doesn't provide bandwidth guarantees, nor will you get 100% uptime.

[ Parent | on HN ]

Re:How We Saved $132k a Year With an IT Infrastructure Audit by throwaway2016a on Wednesday April 06, 2016 @11:52AM (#11439579)

True. You have to design for failure with AWS. Which does have a large amount of cognitive overhead. If you don't design for failure you're going to have a bad time.

However, designing for strict SLAs is not impossible with AWS. You just need to have multi-region redundancy and you can get very very good with multi-availability zone redundancy.

I have no excuse for the IAM outage, it sucked for our ops team. I guess my only two consultations are:

1. We haven't had a customer-visible outage due to AWS in years because we follow best practices (which does cost more - but see my previous point on more smaller machines vs many large machines)

2. If we were running our own authentication and access control system similar to IAM, it too could have an outage.

But I agree, that is a bad thing about AWS.

[ Parent | on HN ]