jread

My mother-in-law fell for a love scam last year. Luckily we caught it early and no money was lost, but I was surprised how difficult it was to convince her it was a scam despite the obvious signs and family and friends all telling her it was. The scammer claimed to be the actor Jack Wagner (popular on Hallmark channel and soap operas). Out of desperation we looked him up on cameo and paid him for a video message telling her it wasn't him texting her, and that finally snapped her out of it.

Ah, good to know, I hadn't seen that V2 update. Looks like a min 5m inactivity to auto-pause (i.e., scale to 0), and any connection attempt (valid or not) resumes the DB.

This was true for RDS serverless v1 which scaled to 0 but is no longer offered. V2 requires a minimum 0.5 ACU hourly commit ($40+ /mo).

As part of my CS grad research, I launched a website reporting on public cloud availability and performance.

https://cloudlooking.glass/#show=uptime

Yes, we've been testing volume attachments every 5m since start of the year, and have experienced 100-150 attachment failures per volume type in that time frame during multiple events (most recently last week):

https://cloudlooking.glass/dashboard/#aws.ebs.us-east-1--cp-...

Another interesting bit, is last March AWS changed something in the control plane which both triggered a multi-day LSE, and ultimately increased attachment times from 2-3s to 10-20s (also visible in the graphs).

I'm working on graduate research evaluating AWS control and data plane performance.

EBS volume attachment is typically ~11s for GP2/GP3 and ~20-25s for other types.

1ms read / 5ms write latencies seem high for 4k blocks. IO1/IO2 is typically ~0.5ms RW, and GP2/GP3 ~0.6ms read and ~0.94ms write.

References: https://cloudlooking.glass/matrix/#aws.ebs.us-east-1--cp--at... https://cloudlooking.glass/matrix/#aws.ebs.*--dp--rand-*&aws...

Lambda create-function control plane operations are still failing with InternalError for us - other services have recovered (Lambda, SNS, SQS, EFS, EBS, and CloudFront). Cloud availability is the subject of my CS grad research, I wrote a quick post summarizing the event timeline and blast radius as I've observed it from testing in multiple AWS test accounts: https://www.linkedin.com/pulse/analyzing-aws-us-east-1-outag...

For networking, the site only reports uptime % for zonal, regional, cross-region or cross-cloud tests. It excludes last mile network tests as those fail frequently due to many hops and endpoint unreliability (we use Ripe Atlas and Globalping.io endpoints which are not always reliable even with redundant probes per test).

For data and control plane I can determine the issue from the API request/response logs (i.e., network timeout, 5xx, etc.). Network tests are trickier and we don't have a great way to validate failure cause each of those events (i.e., we don't capture a traceroute on failure), other than to evaluate results from multiple endpoint combinations (e.g., AWS us-east-1 to us-west-1 fails while us-east-2 to us-west-1 succeeds).

Happy to answer any questions also.

$8549 with 1TB storage

There is lot of statistical and empirical data on this topic - MTBF estimates from vendors (typically 100k - 1m+ hours), Backblaze and Google drive failure data (~1-2% annual failure rate), IEEE and others. With N+1 redundancy (backup servers/RAID + spare drives) and proper design and change control processes, operational failures should be very rare.

With cloud hardware issues are just the start - yes you MUST "plan for failure", leveraging load balancers, auto scaling, cloudwatch, and dozens of other proprietary dials and knobs. However, you must also consider control plane, quotas, capacity, IAM, spend, and other non-hardware breaking points.

You're autoscaling isn't working - is the AZ out of capacity, did you hit a quota limit, run out of IPv4s, or was an AMI inadvertently removed? Your instance is unable to write to S3 - is the metadata service being flakey (for your IAM role), or is it due to an IAM role / S3 policy change? Your Lambda function is failing - did it hit a timeout, or exhaust the (512MB) temp storage? Need help diagnosing an issue - what is your paid support tier - submit a ticket and we'll get back to you sometime in the 24 hours.

Any usecase that requires interacting with a service is automatically excluded

This isn't correct. Many applications consist of a mix of static and dynamic content. Even dynamic content is often cacheable for a time. All of this can be served by a CDN (using TTLs) which is a much simpler and more cost effective solution than multi-region cloud infra, with the same performance benefits.

Hardware can fail for all kinds of reasons

Complex cloud infra can also fail for all kinds of reasons, and they are often harder to troubleshoot than a hardware failure. My experience with server grade hardware in a reliable colo with a good uplink is it's generally an extremely reliable combination.

If have a global user base, depending on your workload, a simple CDN in front of your hardware can often go a long ways with minimal cost and complexity.

Material for MkDocs is great for documentation centric websites.

Athena and Redshift Spectrum are the best alternatives on the AWS side.

As someone who spent 5 years attempting to get through zoning including a purely subjective “design review committee” in one of these affluent cities, I applaud this. While I agree with the desire to preserve the character and uniqueness one’s town, that pendulum has swung so far over driven by older, established nimbies who got theirs decades ago, or their offspring who inherited both homes and excessively low prop 13 tax rates locked in decades ago. The wealth disparity this whole system has created is staggering.

Sounds like an L1 or malfunctioning L2. I’d never revert to ICE in cold weather climates. Handling is great and ability to preheat (without idling) is a wonderful convenience on cold mornings.

The Moon is a Harsh Mistress and We are Legend (We are Bob) are a couple I really enjoyed during road trips.

+1 Bought a used X with FSD and learned the hard way to only use on freeways and highways in simple driving conditions or traffic. Even then I’m on constant alert for phantom braking. I can’t understand the $12,000 price justification.

When did you last use PHP? It's not the PHP of 15 years ago. It scales fine when properly written and deployed.

While not required, it is socially expected that 18-19yo mormon men serve missions.

+1 for iCloud+. I moved 3 business/family domains and shutdown my G Suite legacy account with no issues, and no extra cost (already paying for iCloud). Can't beat $0.99/mo for 50GB shared on up to 6 accounts.

AWS Lightsail is a possible workaround for bandwidth heavy simple workloads. The smallest $3.50/mo instance (t2.nano behind the scenes), comes with 1TB outbound bandwidth - equivalent of about $90 for the same in EC2 excluding the instance cost, and bundled bandwidth increases for larger types.

I’d be interested in your take on AWS Outposts - do you see potential in this type of offering?

Perhaps, but on many pilot's knees will be a digital touchscreen kneeboard which having learned with paper approach plates and map books myself was a godsend.

I suspect they are bottlenecked on CPU - most of these instance types are capable of higher throughput than they've captured, but you'd need more than 1 Iperf process to measure it on Azure.

us-west-2 seems to be the anchor region on the west coast - more AZs/capacity than us-west-1, and nearly identical pricing and instance class availability as us-east-1.

Love it or hate it seems to be the case here - not many fence sitters. Been reading TMC and FB Tesla Owners group the past hour and reactions are I’d estimate about 80% negative.