The service you need may not exist in Zurich

I have written about data residency twice here: about what “data in Switzerland” technically covers, and about what the Zurich region costs against Frankfurt.

Both posts assume something I took for granted at the time: that the services you need exist in Zurich at all.

What happened to me

A project of mine had to connect devices in the field. MQTT over TLS, device identity through certificates, a state document per device. On AWS that is IoT Core.

The region had been fixed long before, eu-central-2, for the reason everyone gives: Swiss customers, Swiss data.

IoT Core is not available there.

No preview, no waiting list. The service simply does not exist in eu-central-2. The device connection runs in eu-central-1 today, Frankfurt, and that is written down in the project documentation.

I noticed while writing the first line of infrastructure code. That was early enough. Two months later it would have been expensive.

A region is a catalogue

The word “region” creates the wrong picture. It sounds like a data centre holding everything AWS offers, only in Zurich instead of Frankfurt.

In practice a region is a catalogue, and catalogues have gaps. Services arrive when there is enough demand, and Switzerland is a small market.

Zurich launched in November 2022 with 58 services. AWS now puts the count at around 173. That is solid progress, and it is exactly the number that creates an impression of completeness. Frankfurt still sits well above it.

With IoT Core the picture is unambiguous. The service runs in 25 of 37 regions as of August 2026. In Europe that includes Frankfurt, Ireland, London, Paris, Stockholm, Milan and Spain.

None of this is a complaint about AWS. The mistake happens on our side, when we infer completeness from the word “region” and write the sentence about Swiss data residency into a proposal before anyone has walked the list.

The check, ten minutes

1. List concrete services, not categories. “Database” is not an answer, “DynamoDB” is. Walk through the planned architecture and write down the service names. The invisible ones count: the queue, key management, the scheduler, the store for log data, outbound mail.
2. Look up each service individually. The official overview is called “AWS Services by Region” and lives on aws.amazon.com. Do not rely on memory, including your own. The table keeps changing, which is rather the point.
3. Watch for the region-less services. Some services have no region in the usual sense. IAM is global. CloudFront is a worldwide network configured in us-east-1. Route 53 likewise. That is usually unproblematic, but it belongs in the record, otherwise an auditor trips over it and then you get to explain.
4. Record the result with a date. A table of service, region, checked on. That document is later the difference between “we considered this” and “this slipped through”.

Step four is the one everybody skips, and it is the only one still worth anything months later.

Four routes when a service is missing

A missing service does not sink a project. It demands a decision, and that decision is better made early.

Run the service in another region and disclose it. This is the route I took. What matters is which data is actually processed there. For my device connection that is telemetry values and certificate identifiers. No personal data sits there. That distinction belongs in the proposal, because it is the real answer to the customer’s question.

Replace the service. Sometimes another one exists in Zurich that solves the same problem, with a little more work on your side.

Run the function yourself. A managed broker can be replaced by your own installation on containers. Then you carry operations, patching and on-call yourself. That is an honest trade and the right one for some projects.

Clarify the requirement. Fewest people take this route, and it is usually the best one.

The question that improves the conversation

“Do you want Swiss data residency?” is not a useful question. The answer is always yes.

Useful is: which data exactly has to stay in Switzerland, and where does that requirement come from?

Does it come from a contract, a tender, professional secrecy, an internal policy? Swiss data protection law does not require domestic storage, as I set out elsewhere. What it requires is that a transfer abroad goes to a country with adequate protection, or is covered by suitable safeguards. The Federal Council maintains a country list, and the EU member states are on it. Processing in Frankfurt is therefore legally unproblematic in many cases, and saying so usually takes the initial fright out of the conversation. None of this is legal advice; it is the groundwork that makes a legal review worth doing.

In practice the pressure almost always comes from an agreement, and an agreement binds just as tightly as a statute once it is signed.

In practice the answer often turns out narrower than the blanket sentence suggests. Customer master data yes, system utilisation metrics no. Once that is settled, a hard obstacle becomes an architecture decision with several workable variants. And the roughly ten percent premium the Zurich region carries then applies only to the parts where it is justified.

What I do now

I check regional availability before the first draft, not during implementation. The effort is trivial next to a retrofit.

And I no longer write a sentence about data residency into a proposal without the checked service list beside it.

A region is the frame. The decision is made per service.

Frequently asked questions

Are all AWS services available in AWS eu-central-2 (Zurich)?

No. An AWS region carries a subset of the overall catalogue, and Zurich is one of the smaller regions. AWS itself puts Zurich at around 173 services, up from 58 at launch in November 2022. Frankfurt sits well above that. AWS IoT Core, for example, is available in 25 of 37 regions as of August 2026, in Europe including Frankfurt, Ireland, London, Paris, Stockholm, Milan and Spain. Zurich is not among them.

How do I check whether an AWS service is available in a region?

Through the official “AWS Services by Region” overview on aws.amazon.com. What matters is checking the concrete service names rather than the categories: “database” is not an answer, “DynamoDB” is. The invisible building blocks count too, so queues, key management, schedulers and the store for log data. Record the result with a date, because the table keeps changing.

What do I do when a service I need is missing in Zurich?

Four routes work. Run the service in another region and disclose which data is processed there. Replace it with one that does exist in Zurich. Run the function yourself, on containers for instance. Or clarify the requirement, because it is often narrower than the blanket sentence about Swiss data residency suggests. What never works is making the promise before the check.

To look up

Availability by hand: the “AWS Services by Region” overview on aws.amazon.com. The figures quoted here are as of August 2026.

Availability in a script: AWS publishes the service-to-region mapping as public parameters in the Systems Manager Parameter Store.

aws ssm get-parameters-by-path \
  --region us-east-1 \
  --path /aws/service/global-infrastructure/services/<service>/regions/eu-central-2 \
  --output text

An empty answer means: not available in that region. The valid service names come from the same call against the path /aws/service/global-infrastructure/services. The path is queryable from only a few regions, which is why --region us-east-1 is in the call regardless of where your account otherwise works.

A common mix-up worth naming: aws account list-regions answers a different question, namely which regions are enabled for your account. Useful to know, and it says nothing about any individual service.