Can I make an Azure storage account go offline to test my fallback code?

Question

I am developing an Azure application (C#, .NET 6, ASP.NET Core) that uses Azure blob storage as well as table storage.

I have geo-redundancy enabled on my storage account (RA_GRS) so that if my main storage account goes down, a read-only copy will be available in another Azure region.

When reading from blob storage, as far as I understand, I should be able to get it to automatically fall back to the secondary address by setting the GeoRedundantSecondaryUri property like this:

    return new BlobServiceClient(
        new Uri($"https://{accountName}.blob.core.windows.net/"),
        sharedKeyCredential,
        new BlobClientOptions
        {
            GeoRedundantSecondaryUri = new Uri($"https://{accountName}-secondary.blob.core.windows.net/")
        });

How can I end-to-end test that I am doing this correctly?

Can I tell the storage account to go offline so that my application should fall back to the read-only backup? I know I can stop an app service using az webapp stop from the command line. Can I do anything similar for storage accounts? Otherwise, how can I test my fallback logic?

(I am asking not only because I want to test the built-in geo-redundancy functionality. I have other failover-related code I want to test.)

EDIT 1: I do not want to use Azure's built-in "initiate account failover" functionality. At least not at this time. I want to test that my application can continue in a kind of "read-only mode" while the primary storage is down.

EDIT 2-3: I have tried to block the primary address ({accountName}.blob.core.windows.net/) using C:\Windows\System32\drivers\etc\hosts. My blob client does not seem to fall back.

• If I redirect to IP 0.0.0.0, the blob client throws this: "The requested name is valid, but no data of the requested type was found."
• If I redirect to IP 127.0.0.1, the blob client throws this: "No connection could be made because the target machine actively refused it."

Answer 1

If you just want to test the geo-redundancy of your Storage Account, you can initiate an account failover manually from Azure portal & see if your application resumes back the functionality via secondary endpoints.

This documentation might help you out in this scenario: Initiate Azure Storage Account Failover

Note that there will be a certain minimal amount of data loss if you perform a failover, so I'd recommend you to go through the implications of a failover before performing it.