Visualizing Meltdown on AWS • Hacker News Board

Re: Visualizing Meltdown on AWS

#31

Post by lykr0n » Sat, Jan 13, 2018, 2:44 PM UTC

amazingman wrote: post #19

scurvy wrote: post #16

"Why I like to run my own hardware for $100, Alex" You can patch various tiers of servers at your own leisure, depending on threat levels and exposure. Measure the impact, capacity plan, etc. Rather than it being forced on you across all tiers because cloud.

You forgot to type 5 or 6 zeros there.

If you know what you are doing, it is leaps and bounds cheaper to run your own hardware (co-located, rented from soneone else). The only issue is latency on scaling out (hours), but if you are halfway decent with trend lines you can preempt this.

Re: Visualizing Meltdown on AWS

#32

Post by xiaodown » Sat, Jan 13, 2018, 2:50 PM UTC

lykr0n wrote: post #31

amazingman wrote: post #19

Earlier quoted context omitted.

You forgot to type 5 or 6 zeros there.

If you know what you are doing, it is leaps and bounds cheaper to run your own hardware (co-located, rented from soneone else). The only issue is latency on scaling out (hours), but if you are halfway decent with trend lines you can preempt this.

That's not the only issue; there's also a lot of compliance issues that having a hosting company can take care of. There's whole sections of PCI and HIPPA compliance that you can just write off as "not our problem, talk to AWS".

Re: Visualizing Meltdown on AWS

#33

Post by perfmode » Sat, Jan 13, 2018, 2:50 PM UTC

Over a 15 year time scale, there is no way AWS will remain competitive with GCP.

Re: Visualizing Meltdown on AWS

#34

Post by stephengillie » Sat, Jan 13, 2018, 2:56 PM UTC

scurvy wrote: post #16

"Why I like to run my own hardware for $100, Alex" You can patch various tiers of servers at your own leisure, depending on threat levels and exposure. Measure the impact, capacity plan, etc. Rather than it being forced on you across all tiers because cloud.

It's very easy for a single admin with a single machine to provide 4 nines to a small group with a small load. But this usually scales exponentially.

Re: Visualizing Meltdown on AWS

#35

Post by MBCook » Sat, Jan 13, 2018, 3:14 PM UTC

voidlogic wrote: post #10

MBCook wrote: post #7

Earlier quoted context omitted.

What I’ve seen is it takes five years to design a CPU from scratch. I imagine they’ll try and rush this to get it out there as fast as possible (obviously a lot of people would like to buy CPUs they don’t have this issue for security/performance reasons) but it’s going to take a while. I think years is definitely the minimum. Meltdown is easy enough (relatively) but Spectre is kind of a disaster. What do you do? Does…

>Does the branch predictor have to start tagging every branch guess with some sort of process ID to prevent one process from messing with another’s predictions? Its worth pointing out that for their newest designs AMD (and Samsung Exynos) uses the full memory address for branch predictions; no doubt Intel's next design will be doing this.

Ah, that makes since. Sounds like a much less complicated fix than my idea.

Re: Visualizing Meltdown on AWS

#36

Post by scurvy » Sat, Jan 13, 2018, 3:38 PM UTC

xiaodown wrote: post #32

lykr0n wrote: post #31

Earlier quoted context omitted.

If you know what you are doing, it is leaps and bounds cheaper to run your own hardware (co-located, rented from soneone else). The only issue is latency on scaling out (hours), but if you are halfway decent with trend lines you can preempt this.

That's not the only issue; there's also a lot of compliance issues that having a hosting company can take care of. There's whole sections of PCI and HIPPA compliance that you can just write off as "not our problem, talk to AWS".

PCI compliance had little to do with where you're hosted, but how you're hosted and what you do with data.

AWS is not a magical PCI compliance button.

Re: Visualizing Meltdown on AWS

#37

Post by sorenbs » Sat, Jan 13, 2018, 3:40 PM UTC

mrep wrote: post #5

My team saw a 40% CPU usage increase on all of our EC2 instances and even our RDS instances. We were shocked since the media was downplaying the performance impact. I tried to start a poll but it seems as though my team was just the unlucky one: https://news.ycombinator.com/item?id=16109036

Do you have premium support with AWS? Maybe try opening a ticket.

Re: Visualizing Meltdown on AWS

#38

Post by scurvy » Sat, Jan 13, 2018, 3:42 PM UTC

stephengillie wrote: post #34

scurvy wrote: post #16

"Why I like to run my own hardware for $100, Alex" You can patch various tiers of servers at your own leisure, depending on threat levels and exposure. Measure the impact, capacity plan, etc. Rather than it being forced on you across all tiers because cloud.

It's very easy for a single admin with a single machine to provide 4 nines to a small group with a small load. But this usually scales exponentially.

Just because you can't do it doesn't make it impossible. A small team of 4-5 good ops people can scale a network of many thousand nodes, petabytes of storage, and terabits of network throughput.

Tech stuff isn't hard. The biggest problem is the lack of capacity planning and project communication in tech today. Nimble startup is a euphemism for pure anarchy and chaos. No one wants to plan anything any more.

Re: Visualizing Meltdown on AWS

#39

Post by scurvy » Sat, Jan 13, 2018, 3:45 PM UTC

gnosek wrote: post #24

amazingman wrote: post #19

Earlier quoted context omitted.

You forgot to type 5 or 6 zeros there.

https://www.kimsufi.com/us/en/ Granted, that's the bottom of the barrel (single disk, no IPKVM etc.), but $100 keeps you running for over a year. Better servers are easily available as well, usually a couple of times cheaper than AWS. Is this a US thing? Based on HN only, I'd never know there's anything between the public cloud and racks of own hardware that you have to wire up and maintain. I have a bunch of quad co…

HN types are enamored with the scale and size that is necessary to run the massive framework for their blogs.

Re: Visualizing Meltdown on AWS

#40

Post by mike_heffner » Sat, Jan 13, 2018, 3:45 PM UTC

Would love to know if anyone else had data on:

* Impact on M5/C5 instances over similar time period, any difference with the Nitro hypervisor?

* Were Dedicated instances (https://aws.amazon.com/ec2/purchasing-options/dedicated-inst...) patched as well?

* Other examples of software that adapted batching performance automatically with increase in call latency.