Azure Static Web App stuck on slow stamp (.7 in eastasia) — new resource group still assigns same stamp

This is a frustrating issue, and you've done an excellent job documenting the problem. The significant, consistent performance difference between the .1 and .7 stamps in the eastasia region, even on a brand new, empty Static Web App (SWA), strongly indicates a problem with the underlying stamp infrastructure itself.

Based on the available information, here are the direct answers to your questions and the recommended path forward.

Can Our Production SWA Be Migrated to a Faster Stamp?

No, there is no native Azure feature to migrate a Static Web App between stamps within the same region. This is a hard limitation of the service architecture.

The behavior you observed, where a new SWA in a new Resource Group still landed on the slow .7 stamp, confirms the underlying "webspace" principle that applies to many Azure App Services . Once a stamp (or "webspace") is assigned to a combination of a region and a resource group, it cannot be changed. Your new resource group in the eastasia region was simply assigned to the next available webspace, which unfortunately was also the slow .7 stamp.

Is There a Workaround? (Recreating Until You Get a Fast Stamp)

This is the only viable, though inelegant, workaround available to you today. Since you cannot force a specific stamp, you must resort to repeatedly creating new SWAs until one is provisioned on a high-performing stamp (like .1).

Here is the recommended process:

Create a new SWA in the eastasia region. Use a new, uniquely named Resource Group each time.

Test the new SWA's performance immediately after creation, before any code is deployed. You can use a simple curl command or a browser to measure the TTFB of the default blank page.

bash

curl -o /dev/null -s -w 'Total: %{time_total}s\nTTFB: %{time_starttransfer}s\n' https://your-new-swa-name.azurestaticapps.net

If the performance is good (comparable to your .1 stamp), deploy your production application to this new, fast SWA.

If the performance is poor (comparable to your .7 stamp), delete the entire resource group and repeat the process from step 1.

This is purely a trial-and-error method. While it is the only current solution, it is time-consuming and not a sustainable long-term strategy.

Alternative Strategic Solutions

Given the limitations of the "recreate until it works" approach, you should also consider these alternative strategies to solve your performance problem for Korean users.

Solution Description & Relevance for Korean Users Pros Cons

Use a Global Load Balancer (Recommended) Place Azure Front Door or Traffic Manager in front of your SWA. These services route users to the closest healthy endpoint. You could create fast SWAs in eastasia and another region like westeurope (for cross-traffic). - Bypasses stamp issue entirely.

• Provides global load balancing and failover.
• Improves performance for all global users. - Adds another service (cost and complexity).
• Still requires a fast endpoint in eastasia to exist.

Switch to a Different Azure Service Deploy your static site using a Storage Account with static website hosting fronted by the Azure CDN. This is a very common, high-performance alternative. - Complete control over the underlying infrastructure.

• Highly performant and cost-effective. - Lose SWA-specific features (e.g., integrated Functions API, GitHub Actions build orchestration).

Direct API Calls (For API-Heavy Apps) If your app's primary issue is API latency, bypass the SWA proxy and have your frontend call your Azure Functions directly. - Can dramatically reduce API latency by removing the SWA hop . - Requires you to handle CORS and authentication yourself in the Functions.

What Will Not Work

To save you further time, it's important to clarify what won't solve this:

Changing the App Service Plan Tier: Your SWA is already on the Standard tier. Changing the plan within the same stamp will not change the stamp itself .

Enabling Enterprise-Grade Edge: While this can speed up static content delivery globally, your measured TTFB originates from the origin server (the stamp). This feature will not fix an overloaded or slow origin stamp, and it may even add latency to API calls, as noted in community findings .

Moving to a Different Region: This is not possible for SWAs; they are locked to the five available regions .

Summary & Final Recommendation

Short-term: The fastest way to resolve this is to use the trial-and-error creation method to secure a fast SWA for your production app.

Long-term: To avoid this issue permanently, you should architect for resilience. Implement a global load balancer like Azure Front Door. This not only provides a path to bypass future stamp problems but will also deliver a better, more consistent experience for your users in Korea and around the world by routing them to the best available endpoint.

I hope this provides a clear path forward. Given the constraints of the service, the "recreate until you get a good stamp" method is your most immediate solution, while Azure Front Door is the most robust, long-term architectural fix.

Please let me know if you have any other questions as you work through this.

Hello @Jay

Thank you for reaching out Microsoft Q&A. I do understand your issue, please could you provide the details requested in private message so that I can the issue.

Hello @Jay

Nearest location definitely do help, but faster stamp cannot be ensured. Implementing Azure front door might help.

Hi @Jay

From investigation I can confirm what you’re seeing: your production app (and the new one in the fresh resource group) is landing on the .7 stamp (lively-bush-0da42ca00.7.azurestaticapps.net, Geo Master waws-prod-hk1-3c2ef8b4). This explains the consistently higher origin TTFB you’re measuring compared to the .1 stamp.

Unfortunately, there is currently no supported way to migrate an existing Static Web App between stamps inside the same region, nor any option to request or pin a specific stamp during creation. This is due to how the underlying webspace/stamp assignment works in Azure Static Web Apps.

Short-term recommendation:

The only reliable workaround right now is to create new Static Web Apps (ideally in a brand-new resource group each time) until one provisions on a faster stamp like .1. Once you get a good one:

• Deploy your code to it
• Validate the performance
• Point your custom domain to the new app (CNAME swap with proper DNS TTL)
• Decommission the old one

This blue-green style cutover minimizes risk and downtime. Many customers in similar situations script this process using Azure CLI to speed things up.

Quick win worth testing

Since your app is on the Standard tier and Enterprise-grade edge is currently disabled, I recommend enabling it. It puts Azure Front Door in front of your Static Web App, which can significantly improve global routing, caching, and perceived performance for your users in Korea and other Asian locations — even if the origin stamp remains the same.

You can enable it directly from the portal under Settings > Enterprise-grade edge.
reference: https://learn.microsoft.com/en-us/azure/static-web-apps/enterprise-edge?tabs=azure-portal

reference:

https://learn.microsoft.com/en-us/azure/static-web-apps/troubleshooting

https://learn.microsoft.com/en-us/troubleshoot/azure/app-service/troubleshoot-performance-degradation

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.