Announcing the General Availability of WordPress on Azure App Service
We are thrilled to announce that WordPress on Azure App Service, which was running on Public Preview since 15 February 2022, has been made Generally Available on 8 August 2022. To read the Public Preview Announcement read the blog post on The new and better ‘WordPress on App Service’ - Microsoft Tech Community.
App Service to Storage Account Connection Condition Summary
Currently, there are 4 main conditions the Azure App Service can connect to Azure Storage Account. Condition 1: App Service (Public ) --> Storage Account (Public, Same region) Condition 2: App Service (Public ) --> Storage Account (Public, Different region) Condition 3: App Service (Regional Vnet Integration) --> Storage Account (Private, Service Endpoint ) Condition 4: App Service (Regional Vnet Integration) --> Storage Account (Private, Private Endpoint) Before going deeper, here is a brief summary for your to choose the suitable design for your system. Requirements: If your security require the Firewall on the Storage Account. And the Storage Account and Azure App Service are in the same region. --> Use the above Condition 3 for 4 for your design. If your security require the Firewall on the Storage Account. And the Storage Account and Azure App Service are in the different region. --> Use the Condition 1 or Condition 4 for your design. When you would like to make the connection private, use the Condition 4. For the deeper analysis for the above 4 conditions, please see following: Background knowledge: ============ Azure Storage Account Network restricting logic is different from the Azure App Service. Even when we configured the Network restricting from the Azure Storage Account side, the tcpping will still working well like this: And the "List" request to the Azure Storage Account will not be locked. In order to verify if the Network Restricting is working or not, you can use the script to upload a file to Azure Storage Account to test. I am using the code: <?php $accesskey = "xxxx"; $storageAccount = 'xxxx'; $filetoUpload = realpath('xxxx'); $containerName = 'xxxx'; $blobName = 'xxxx'; $destinationURL = "https://$storageAccount.blob.core.windows.net/$containerName/$blobName"; function uploadBlob($filetoUpload, $storageAccount, $containerName, $blobName, $destinationURL, $accesskey) { $currentDate = gmdate("D, d M Y H:i:s T", time()); $handle = fopen($filetoUpload, "r"); $fileLen = filesize($filetoUpload); $headerResource = "x-ms-blob-cache-control:max-age=3600\nx-ms-blob-type:BlockBlob\nx-ms-date:$currentDate\nx-ms-version:2015-12-11"; $urlResource = "/$storageAccount/$containerName/$blobName"; $arraysign = array(); $arraysign[] = 'PUT'; /*HTTP Verb*/ $arraysign[] = ''; /*Content-Encoding*/ $arraysign[] = ''; /*Content-Language*/ $arraysign[] = $fileLen; /*Content-Length (include value when zero)*/ $arraysign[] = ''; /*Content-MD5*/ $arraysign[] = 'image/png'; /*Content-Type*/ $arraysign[] = ''; /*Date*/ $arraysign[] = ''; /*If-Modified-Since */ $arraysign[] = ''; /*If-Match*/ $arraysign[] = ''; /*If-None-Match*/ $arraysign[] = ''; /*If-Unmodified-Since*/ $arraysign[] = ''; /*Range*/ $arraysign[] = $headerResource; /*CanonicalizedHeaders*/ $arraysign[] = $urlResource; /*CanonicalizedResource*/ $str2sign = implode("\n", $arraysign); $sig = base64_encode(hash_hmac('sha256', urldecode(utf8_encode($str2sign)), base64_decode($accesskey), true)); $authHeader = "SharedKey $storageAccount:$sig"; $headers = [ 'Authorization: ' . $authHeader, 'x-ms-blob-cache-control: max-age=3600', 'x-ms-blob-type: BlockBlob', 'x-ms-date: ' . $currentDate, 'x-ms-version: 2015-12-11', 'Content-Type: image/png', 'Content-Length: ' . $fileLen ]; $ch = curl_init($destinationURL); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false); curl_setopt($ch, CURLOPT_HTTPHEADER, $headers); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, "PUT"); curl_setopt($ch, CURLOPT_INFILE, $handle); curl_setopt($ch, CURLOPT_INFILESIZE, $fileLen); curl_setopt($ch, CURLOPT_UPLOAD, true); $result = curl_exec($ch); echo ('Result<br/>'); print_r($result); echo ('Error<br/>'); print_r(curl_error($ch)); curl_close($ch); } uploadBlob($filetoUpload, $storageAccount, $containerName, $blobName, $destinationURL, $accesskey); Preparation: ============ Write code to upload the file to Azure Storage Account for testing as mentioned in above. Create xxx.php file under the wwwroot folder for testing. Enable the "Diagnostic settings" from Azure Portal Test: ============ Condition 1: App Service (Public ) --> Storage Account (Public, Same region) By Default, Azure App Service can access the Storage Account and upload the files. But if we enable the Firewall settings under the Networking blade of Storage Account, and add the Azure App Service Outbound IP to the whitelist like following screenshot, the Azure App Service will still not able to access Azure Storage Account. If we check the Azure Storage Account log, we will see the Azure App Service was trying to use an internal IP (100.x.x.x) to access the Storage Account. Not using the Azure App Service public outbound IP: Why? I discussed this behavior with the Azure Storage Account and Azure App Service Product Group, and the result showed if the Azure App Service and Azure Storage Account are in the same datacenter, they did some optimization, so the Azure App Service will always reach the Storage Account via the fastest route, so the resource IP (Azure App Service) observed from Azure Storage Account could be an un-predicted IP (could start with 100.x.x.x or 10.x.x.x or other others) and this IP could change at any time. Question: Considering the resource IP from Azure App Service looks like start with 100.x.x.x for now, if I whitelist the 100.0.0.0/8 in the Azure Storage Account, will the Azure App Service can upload the file on it? Answer: Yes it will make the Azure App Service can access the Storage Account for now. But cannot promise it will always work, it is a not officially support scenery. Because the IP could change to 10.x.x.x and some other un-predicted IPs. Another thing is, the x.0.0.0/8 is a huge range, so it is not a good design. If you would like to enable the Firewall in the Azure Storage Account and would like to make sure the Azure App Service in the same region still could access this Storage Account, please see the details in the Condition 3 and Condition 4. Condition 2: App Service (Public ) --> Storage Account (Public, Different region) As we can see in the Azure Storage Account log, the Azure App Service is using the public IP accessing the Azure Storage Account (13.x.x.x is one of the public outbound IP of my test Azure App Service. ) And you can enable the Firewall on Azure Storage Account and whitelist all the Azure App Service outbound IP (Inbound/Outbound IP addresses - Azure App Service | Microsoft Docs). That will make sure the Azure App Service can always access the Storage Account. Condition 3: App Service (Regional Vnet Integration) --> Storage Account (Private, Service Endpoint ) Create Vnet Integration from Azure App Service to Azure Vnet Subnet. Make sure the "Microsoft.Storage" is enabled as Service Endpoint for the Subnet that App Service is integrated with. Make sure the "Route All" is enabled for the Vnet Integration: Configure Azure Storage firewalls and virtual networks | Microsoft Docs After doing above, if we check the Azure App Service resource IP, it will be one of the IP under the Vnet Subnet: Condition 4: App Service (Regional Vnet Integration) --> Storage Account (Private, Private Endpoint) Similar configuration as the Condition 3, but please make sure: Disable the Service Endpoint on the Vnet Subnet. Create Private Endpoint on the Storage Account side. Make sure the Storage Account FQDN could be resolved to private endpoint IP from Azure App Service: We can see the similar private IP records as we saw when using the Service Endpoint. But the different between the condition 3 is the Private Endpoint support cross region traffic , and the Service Endpoint only support the connection from the Azure App Service in the same region.Announcing the General Availability of New Availability Zone Features for Azure App Service
What are Availability Zones? Availability Zones, or zone redundancy, refers to the deployment of applications across multiple availability zones within an Azure region. Each availability zone consists of one or more data centers with independent power, cooling, and networking. By leveraging zone redundancy, you can protect your applications and data from data center failures, ensuring uninterrupted service. Key Updates The minimum instance requirement for enabling Availability Zones has been reduced from three instances to two, while still maintaining a 99.99% SLA. Many existing App Service plans with two or more instances will automatically support Availability Zones without additional setup. The zone redundant setting for App Service plans and App Service Environment v3 is now mutable throughout the life of the resources. Enhanced visibility into Availability Zone information, including physical zone placement and zone counts, is now provided. For App Service Environment v3, the minimum instance fee for enabling Availability Zones has been removed, aligning the pricing model with the multi-tenant App Service offering. The minimum instance requirement for enabling Availability Zones has been reduced from three instances to two. You can now enjoy the benefits of Availability Zones with just two instances since we continue to uphold a 99.99% SLA even with the two-instance configuration. Many existing App Service plans with two or more instances will automatically support Availability Zones without necessitating additional setup. Over the past few years, efforts have been made to ensure that the App Service footprint supports Availability Zones wherever possible, and we’ve made significant gains in doing so. Therefore, many existing customers can enable Availability Zones on their current deployments without needing to redeploy. Along with supporting 2-instance Availability Zone configuration, we have enabled Availability Zones on the App Service footprint in regions where only two zones may be available. Previously, enabling Availability Zones required a region to have three zones with sufficient capacity. To account for the growing demand, we now support Availability Zone deployments in regions with just two zones. This allows us to provide you with Availability Zone features across more regions. And with that, we are upholding the 99.99% SLA even with the 2-zone configuration. Additionally, we are pleased to announce that the zone redundant setting (zoneRedundant property) for App Service plans and App Service Environment v3 is now mutable throughout the life of these resources. This enhancement allows customers on Premium V2, Premium V3, or Isolated V2 plans to toggle zone redundancy on or off as required. With this capability, you can reduce costs and scale to a single instance when multiple instances are not necessary. Conversely, you can scale out and enable zone redundancy at any time to meet your requirements. This ability has been requested for a while now and we are excited to finally make it available. For App Service Environment v3 users, this also means that your individual App Service plan zone redundancy status is now independent of other plans in your App Service Environment. This means that you can have a mix of zone redundant and non-zone redundant plans in an App Service Environment, something that was previously not supported. In addition to these new features, we also have a couple of other exciting things to share. We are now providing enhanced visibility into Availability Zone information, including the physical zone placement of your instances and zone counts. For our App Service Environment v3 customers, we have removed the minimum instance fee for enabling Availability Zones. This means that you now only pay for the Isolated V2 instances you consume. This aligns the pricing model with the multi-tenant App Service offering. For more information as well as guidance on how to use these features, see the docs - Reliability in Azure App Service. Azure Portal support for these new features will be available by mid-June 2025. In the meantime, see the documentation to use these new features with ARM/Bicep or the Azure CLI. Also check out BRK200 breakout session at Microsoft Build 2025 live on May 20th or anytime after via the recording where my team and I will be discussing these new features and many more exciting announcements for Azure App Service. If you’re in the Seattle area and attending Microsoft Build 2025 in person, come meet my team and me at our Expert Meetup Booth. FAQ Q: What are availability zones? Availability zones are physically separate locations within an Azure region, each consisting of one or more data centers with independent power, cooling, and networking. Deploying applications across multiple availability zones ensures high availability and business continuity. Q: How do I enable Availability Zones for my existing App Service plan or App Service Environment v3? There is a new toggle in the Azure portal that will be enabled if your App Service plan or App Service Environment v3 supports Availability Zones. Your deployment must be on the App Service footprint that supports zones in order to have this capability. There is a new property called “MaximumNumberOfZones”, which indicates the number of zones your deployment supports. If this value is greater than one, you are on the footprint that supports zones and can enable Availability Zones as long as you have two or more instances. If this value is equal to one, you need to redeploy. Note that we are continually working to expand the zone footprint across more App Service deployments. Q: Is there an additional charge for Availability Zones? There is no additional charge, you only pay for the instances you use. The only requirement is that you use two or more instances. Q: Can I change the zone redundant property after creating my App Service plan? Yes, the zone redundant property is now mutable, meaning you can toggle it on or off at any time. Q: How can I verify the zone redundancy status of my App Service Plans? We now display the physical zone for each instance, helping you verify zone redundancy status for audits and compliance reviews. Q: How do I use these new features? You can use ARM/Bicep or the Azure CLI at this time. Starting in mid-June, Azure Portal support should be available. The documentation currently shows how to use ARM/Bicep and the Azure CLI to enable these features. The documentation as well as this blog post will be updated once Azure Portal support is available. Q: Are Availability Zones supported on Premium V4? Yes! See the documentation for more details on how to get started with Premium V4 today.
Azure AppService Linux container fails to serve files from mounted file storage
A perfectly working setup suddenly started failing after redeploying the Azure resources involved: Storage account with multiple file shares Azure AppService on a Linux ServicePlan, hosting a Linux Docker container Azure AppService, configured with Path Mappings to the various file shares on the storage account After reprovisioning the resources (end of June 2021), we found out Apache (inside container) wasn't able to serve files from the mounted storage anymore: it returned a HTTP status 502. It was still able to persist files to these same mounted file shares (excluding hypotheses that our mounted drives were somehow unreachable). When accessing the container inside the AppService over SSH, basic curl commands to these same files returned "Received HTTP/0.9 when not allowed" We escalated this issue to MS support. The issue got fixed by applying a work-around: we had to identify an empty ResourceGroup. That way MS could make sure internally that our AppService/ServicePlan deployment eventually landed on the proper hosting resources, resulting in proper behavior. If we redeploy our resources as-is, without notice to MS support, we inevitably are confronted with the unwanted behavior. We've been asking MS Support for a ETA on a structural fix ever since (last 3 months), but never got commitment from their end. We continue to be amazed that a fairly trivial scenario, as this one, seemingly doesn't get any more priority. No doubt lots of other customers are impacted in the same way as we are. Anybody experienced any similar behavior?
Managed Identity for Azure App Services
Azure App Service supports an interesting feature called Managed Identity from Azure Active Directory. This allows your App Service to easily connect to Azure Resources such as Azure KeyVault, Azure Storage, Azure SQL etc. You could refer to our official documentation for more details on this feature here. MSI-Validator helps you troubleshoot issues with Managed Identity on App Services.
