Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

THIS. No one cares about regions, you just care that the app is fast and globally available. The way we did things is a relic of the past and everyone mimics it because trying to guide new user behaviour is hard. The reality is we just need the app to be globally deployed with a globally distributed database and anycast DNS to route you to the local most DC. There's a lot more to it, have built this architecture more than a couple times, but it all needs to be in the service of something and if you're UX isn't better than the next guy, it won't matter much.


As a counterpoint, anyone working with compliance data needs to know and be certain that data does not cross geo-boundaries. Intelligence data for US gov’t agencies must typically be kept stateside: AWS uses the GovCloud region specifically for satisfying gov compliance requirements.

Passing HIPAA data through other countries when not needed to is generally frowned upon - data should be kept as local as reasonably possible. I haven’t worked with GDPR requirements but I have heard they are similar. AWS solved this problem well with regions. I’m curious what other providers that are “regionless” do to solve the compliance problem.


Cloudflare does this although to my knowledge it's not available without an Enterprise subscription which is the only thing they offer with this level of compliance anyway.

All lower plans maybe get PCI DSS and that's it.

It's a valid counter to my point - while they clearly can do it locking it behind an enterprise "talk to us" subscription is lame. That said they are generally customer, market, and product savvy and I suspect they know that any/most orgs that are able to pull off the broader process, etc for actual compliance with these requirements are in fundamentally different positions than some random startup with a bunch of consumer data.

We're also seeing more and more ambiguity with coaching platform startups, etc who don't have a covered entity in sight but that's a different topic for a different day.

I've spent most of my career in HIPAA-relevant startups. Generally, I think it's actually a disservice all around for Amazon to basically rubber stamp these architectures and solutions with a HIPAA BAA so that companies think they can call themselves "HIPAA compliant". That's not even what it's supposed to mean, let alone the virtually endless issues and process that need to happen throughout the org for "compliant" to actually mean anything. I haven't reviewed it but I'm certain the AWS BAA is so specific and exclusionary it's trivial to step outside of what it covers.

Yes these agreements are a piece of the puzzle but it's completely reckless to throw something together in AWS, present the BAA to a customer, and call yourselves "HIPAA compliant". Savvy customers, investors, etc will call you out but otherwise it's mostly just a matter of time before you discover your standalone AWS BAA is actually just one of the things on a 50 point (or whatever) checklist.


> Amazon to basically rubber stamp these architectures and solutions with a HIPAA BAA so that companies think they can call themselves "HIPAA compliant".

N-2 companies ago I was a tech lead in 2015 where we were migrating to AWS. AWS was constantly explaining which underlying services were HIPAA compliant and what you build on top of it was your responsibility. I had to answer to separate non AWS compliance folks about my architecture.

AWS also gave guidance. But made no promises that your implementation was compliant. That’s where the entire “shared responsibility model” comes in.

Now, I work at AWS in ProServe. I am very familiar with our messaging regarding HIPAA compliance. We are very careful not to rubber stamp things as compliant. I know the best practices in and out. But when I’m asked if something is compliant, I say this is the guidance we are given. I’ll do a presentation before an Architecture Review board. But I would never make anything that hints as a guarantee.


Both anecdotal experiences but in my recent exercises with HIPAA compliance with AWS, etc they were nowhere near this explanatory/helpful.

The messaging/communication was more like what I described - "Oh yeah here's BAA you're good to go".


How large were your employers? If you have Enterprise support, you definitely get one or more TAMs dedicated to helping your company.

If you are a smaller organization, you may be able to request an SA.

My personal experience is from when companies pay for consulting hours from ProServe.

At the n-2 company I referred to above, the only thing we got from AWS is a BAA and we had an outside consulting company and compliance auditors. I was just learning AWS then.


Compliance is a completely different conversation.

In the Cloudflare Workers platform, we have a number of features to control "jurisdictions" where compute runs or where data is stored. These are meant for compliance, not for performance. Our goal is that no one has to think about regions for performance reasons, but certainly compliance issues are not going to go away -- in fact, they are getting more onerous over time. So features to control jurisdiction are likely to expand.

(I'm the tech lead for Workers.)


This is MAY be true consumer applications and even then not all.

But it is rarely true for enterprise customers. They want the guarantees their data never leaves certain regions even in a request along with other security and compliance guarantees.


Regions do matter for stuff like GDPR though. It is beneficial to know that all of the data is in the EU region and will stay there.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: