4 ms·
"I guess you are essentially confirming that the instance maintenance was likely to be the reason for the major change to cpu usage, and that the only solution
by panarky 9y ago
"I guess you are essentially confirming that the instance maintenance was likely to be the reason for the major change to cpu usage, and that the only solution now is to change instance type."
"Of course I am not entirely happy about this. I bought a 3-year reserved instance 2 years ago, and now have to hope I can sell the remaining year for a reasonable amount (which may be a stretch given that I am apparently using legacy instance type), and then purchase new reserved instance after upgrading."
- skywhopper 9y agoSounds like all instance types can now be run in HVM mode (news to me, but the AWS tech in the thread made the claim). Converting to HVM is annoying but ultimately not that hard or risky. Since HVM mode appears to resolve much of the performance issue, this seems like a reasonable workaround.
- gregdunn 9y ago>Sounds like all instance types can now be run in HVM mode (news to me, but the AWS tech in the thread made the claim) https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtualization_types.html https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/virtuali... "All instance types support HVM AMIs." This is a recent change. (I work at AWS, not directly involved with this change and not speaking in any sort of official capacity, but can confirm you can use HVM on m1, etc, now)
- taf2 9y agoOr migrate to google since they don’t have a broken discounting billing system
- RhodesianHunter 9y agoI'll stick with the vastly superior offering and swallow the occasional hiccup, but thanks.
- vageli 9y ago"Vastly superior" could use some qualification. I find the gcloud tooling to he superior to awscli.
- etaioinshrdlu 9y agoI would describe much of AWS and the supporting tooling as "ugly", sometimes hideously ugly, but the services tend to work well. They clearly prioritize making things work over making them pleasant to use. AWS Lambda Mapping Templates and S3 Bucket Policy are two things that come to mind as hideously ugly. But they work!
- vertis 9y agoI have used Amazon for many years happily, but I'm struggling to understand what you consider to be vastly superior? Google has some very solid product offerings. Google Container Engine for instance is amazing. Granted Amazon has recently launched a couple of products that offer similar features, but as of mid last year running containers on Google felt like it was ahead of Amazon.
- chucky_z 9y agorunning containers on google compute or ec2 has always been the same. gke is great, however. if you need to run kubernetes in production, today, i would not even slightly hesitate to yell to the corners of the earth to run gke. it makes me excited for eks! i would also say that the new c5 instance type w/ ena is extremely nice. if they are unaffected by this, they're probably the fastest cpu-based instances you can get anywhere (admittedly i haven't checked... really anything else, but they're fast).
- fishywang 9y agoOne thing is s3/gcs latency. On my last job we had a Go server running on ec2/gce and do some occasional read from s3/gcs (same, single region). We used to be running on ec2+s3 but later switched to gce+gcs for cost reasons (gcp only costs ~60% of aws' cost for our setup). But the thing we noticed was that when we were on aws reading ~10KB single file from s3 usually takes <100ms, occasionally hit 100ms+ but rarely hit >200ms. On gcp that's usually >100ms, sometimes hikes to >1s and rarely goes <100ms.
- _wmd 9y agoGoogle offer exactly the same reservations mechanism https://cloud.google.com/compute/docs/instances/signing-up-committed-use-discounts https://cloud.google.com/compute/docs/instances/signing-up-c...
- gizzlon 9y ago"Discounts apply to the aggregate number of vCPUs or memory within a region so they are not affected by changes to your instance's machine type."
- ti_ranger 9y agoSure, if you're happy with global outages. https://status.cloud.google.com/incident/compute/17003 https://status.cloud.google.com/incident/compute/17003 - On Monday 30 January 2017, newly created Google Compute Engine instances, Cloud VPNs and network load balancers were unavailable for a duration of 2 hours 8 minutes. https://status.cloud.google.com/incident/compute/16007 https://status.cloud.google.com/incident/compute/16007 - On Monday, 11 April, 2016, Google Compute Engine instances in all regions lost external connectivity for a total of 18 minutes, from 19:09 to 19:27 Pacific Time. Or, complete outages for a region: https://status.cloud.google.com/incident/compute/17008 https://status.cloud.google.com/incident/compute/17008 - On Thursday 8 June 2017, from 08:24 to 09:26 US/Pacific Time, datacenters in the asia-northeast1 region experienced a loss of network connectivity for a total of 62 minutes. AWS guarantees regional independence for all services, and EC2 guarantees availability-zone independence.