Our Windows Azure roles need to know programmatically which datacenter the roles are in.
I know a REST API ( http://msdn.microsoft.com/en-us/library/ee460806.aspx) return location property.
And if I deploy to, let’s say, West US, the REST API returns West US as location property.
However, if I deploy to Anywhere US, the property is Anywhere US.
I would like to know which datacenter our roles are in even if location property is Anywhere US.
The reason why I ask is our roles need to download some data from Windows Azure storage.
The cost of downloading data from the same datacenter is free but the that of downloading data from the different datacenter is not free.
It is a great question and I have talked about it couple of time with different partners. Based on my understanding when you create your service and provide where you want this service to location ("South Central US" or "Anywhere US"), this information is stored at the RDFE server specific to your service in your Azure subscription. So when you choose a fixed location such as "South Central US" or "North Central US" the service actually deployed to that location and exact location is stored however when you choose "Anywhere US", the selection to choose "South Center" or "North Central" is done internally however the selected location never updated to RDFE server related to your service.
That's why whenever you try to get location info related to your service in your subscription over SM API or Powershell or any other way (even on Azure Portal it is listed as "Anywhere US" because the information is coming from same storage), you will get exactly what you have selected at first place during service creation.
#Sandrino idea will work as long as you can validate your service location IP address from a given IP address range published by Windows Azure team.
Two days ago Microsoft published an XML file containing a list of IP ranges per region. Based on this file and the IP address of your role you can find in which datacenter the role has been deployed.
<?xml version="1.0" encoding="UTF-8"?>
<regions>
...
<region name="USA">
<subregion name="South Central US">
<network>65.55.80.0/20</network>
<network>65.54.48.0/21</network>
...
</subregion>
<subregion name="North Central US">
<network>207.46.192.0/20</network>
<network>65.52.0.0/19</network>
...
</subregion>
</region>
</regions>
Note: It looks like the new datacenters (West and East US) are not covered by this XML file, which might make it useless in your case.
I had some services deployed in Anywhere US and in order to find out which data centre it was deployed in I had to log a support call with Microsoft. They were helpful and got me the information but even they had to go away and look it up. As a result of this I would never use and the the "Anywhere ..." locations. Knowing which data centre your services are running in is very important for knowing where to deploy things like SQL Azure and service bus which don't support affinity groups and don't have an Anywhere option.
Related
We have a requirement to call a 3rd party API via a source with a fixed set of IPs. The IPs need to be static.
Since we are already using Logicapps(consumption) to do other processing, my initial thought was to continue using logic apps. I have already checked the concurrency and message size and they are all within acceptable range to use Logicapps.
My only question is on the IP of the Logicapp when it makes an API call. We had explored using Logic apps standard with VNET integration and Natgateway but this adds additional cost. The other option was to use APIM to provide a static IP, but the Logic would need to integrate with AAD for oAuth2 authentication and we would face challenges in managing the AAD tokens. We don't want to call AAD for a new token for each and every execution.
From the portal I can see a set of outbound IPs for my Logicapp.
I have already tested that the IP exposed is within this list. But I wanted to know if there is a chance that this can change in the future. I was not able to find any concrete Microsoft documentation around this question.
You should always take in account those IPs can change.
Microsoft exposes a downloadable list of Azure Ip Ranges here
This file contains the IP address ranges for Public Azure as a whole, each Azure region within Public, and ranges for several Azure Services (Service Tags) such as Storage, SQL and AzureTrafficManager in Public. Service Tags are each expressed as one set of cloud-wide ranges and broken out by region within that cloud. This file is updated weekly. New ranges appearing in the file will not be used in Azure for at least one week. Please download the new json file every week and perform the necessary changes at your site to correctly identify services running in Azure.
You can also get this data using the PowerShell Get-AzNetworkServiceTag in case you want to automate things. Example:
$serviceTags = Get-AzNetworkServiceTag -Location westeurope
$logicApps = $serviceTags.Values | Where-Object { $_.Name -eq "LogicApps" }
$logicApps.Properties
Region :
SystemService : LogicApps
ChangeNumber : 11
AddressPrefixes : {4.232.111.16/28, 4.232.111.32/27, 13.64.231.196/32, 13.65.39.247/32...}
I would like to create a new Azure Cosmos DB under my free MPN Subscription and would like to set the location to "(Europe) West Europe" just like I did for my ResourceGroup, but this location (and a lot of other locations) is not available?
See the complete list here
If I create a new Resource Group it's not a problem to choose "(Europe) West Europe" and all the other locations/regions that I can normally choose among.
Anyone who knows why this happens and what I can do to fix it?
You can still create resources in West Europe. The locations are unlisted but still available when you create your resources using ARM templates.
To achieve this, follow these simple steps:
configure your resource up to the point where you need to create it, but use one of the listed locations. Do not create the resource.
In the "Review + Create" page of the wizard, choose "Download a template for automation".
Choose Deploy
Change 'Location' to westeurope and 'Location Name' to West Europe, agree terms and conditions and click 'Purchase'
I think this would be due to recent compute shortages in Microsoft Azure due to SARS-COV-2. All the free subscriptions are affected**
https://www.zdnet.com/article/microsoft-cloud-services-demand-up-775-percent-prioritization-rules-in-place-due-to-covid-19/
Ok.
So I'm new to deploying infrastructure to Azure.
I do understand the basics.
I've been tasked to create a "web tier", "middle tier machine", and "database server" in Azure. I'm probably using on-premise terms for these....maybe they map to Azure.
I am using App-Service-Plan and App-Service. Windows flavored.
I am also liking terraform very much, but this question isn't terraform dependent I think. (terraform is just the fancier way to create the necessary objects in Azure, or that's my novice understanding).
So right now, I've been able to create.
App-Service (which would be my "web-server"). I'll call this AppServiceWT.
App-Service (which would be my "middle tier"). I'll call this AppServiceMT.
And Sql-Server/Sql-Server database.
I've been able to create some of this using terraform flavored scripts.
resource "azurerm_resource_group" "testrg" {}
..
resource "azurerm_app_service_plan" "testaspwt" {
name = "some-app-service-plan-for-webtier"
sku {
tier = "Standard"
size = "S1"
}
}
resource "azurerm_app_service" "testaswt" {
name = "AppServiceWT_SomeGlobalUniqueName"
}
..
resource "azurerm_app_service_plan" "testaspmt" {
name = "some-app-service-plan-for-middletier"
sku {
tier = "Standard"
size = "S1"
}
}
resource "azurerm_app_service" "testasmt" {
name = "AppServiceMT_SomeGlobalUniqueName"
}
..
resource "azurerm_sql_server" "primary_azurerm_sql_server" {}
resource "azurerm_sql_database" "primary_azurerm_sql_database" {}
So I have the "parts" ( I think ??? ).
So my hurdle now is.
What am I doing to secure the network traffic.
Requirements:
The middleTier can make requests sql-server-tier. sql-server-tier is not accessible to anything besides middle-tier. In the on-premise world, we would open up port 1433 on the sql-server to allow traffic.
The webTier can make requests middle-tier. middle-tier is not accessible to anything besides web-tier. In the on-premise world, we would open up port 80/443 on the middle-tier to allow traffic.
WebTier is open to world.
What azure "objects" am I missing?
Bonus points for pointing to terraform "tasks" (or whatever they are called).
https://www.terraform.io/docs/providers/azurerm/index.html
But yeah, I'm reaching out to SOF for help to fill in the "traffic" and "secure network" gaps in my head.
Thanks in Advance.
If I'm asking the wrong questions, let me know.
I do not want to maintain my own VM's. So I think Azure App-Service-Plan and App-Service is the correct choice. While I'm a little familiar with Azure-Functions and Logic-Apps, we want to not use those for this project.
To add a little more info.
I'm eventually trying to do a "hello world" using the below microsoft how-to article. The article above does not have a middle-tier, but once I have the concepts down, I think I can make a web/middle/sql 'hello world'.
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-dotnetcore-sqldb
There are a few ways you can secure the application in the app service you are creating -
1.I believe you are already doing it or not sure if you require it but
we can authenticate access to the web app (using OAuth2.0 etc..).
2.If you want more control over the network where we are deploying the apps we
can utilize App service Environments which provides
virtual network integration feature that helps you restrict incoming
source IP addresses through network security groups (NSGs).
Probably once can use it for both the front end and middle tier.
3.White-list the allowed ranges of IP Address in the database.In your case if
any other service should not access the database other
than the web app , then it should be the IP of the frontend web app.
With webapps, your only option is opening webapp external ip addresses to sql to be able to talk to each other.
webapp has got several potential external ip addresses it can have, so you open those on sql. traffic will use azure back bone as long as azure sql\webapp are in the same region.
On the middle tier you should use ip restrictions (web.config can do that).
I have created one Azure Function App in an existing Azure Resource Group. While creating a Function App, by mistake I didn't notice the selected region, and it got created in "South Central US" region. After a significant development, I realized this mistake, and now want to move it to "West Europe" region, so it gets aligned with rest of my resources.
Any idea of how I can move a resource from one region to other region, without deleting and recreating?
There is still no way to change your deployment from one region to the other. You'll have to create another Azure Function in that correct region and redeploy your application.
Troy Hunt outlines his journey with an Azure Website here but the same steps still apply.
still, I don't see any new option (We can move resources from one resource group/ subscription level).
I think as of now 3 options available
Create a resource in the new region then delete existing resource.
Deploy new resource with the same configuration using PowerShell/CLI.
Deploy through portal (Export Template > Deploy > Select New region > change parameters then Purchase) similar to option 2, but you don't need to write any script.
Ultimately all three options would create a new resource and you need to update access key in the dependent services. I think option 2 is a good choice for a production workload.
I have an interesting issue in Azure where somehow I've had some resources assign themselves to "Default-Web-NorthEurope" and some to "Default-Web-northeurope". (Note capitalisation)
Lets say I have Website1 and Website2. I'd like both of these to belong to the same App Service Plan. If I create a new one for "Website1" named "WebsitesServicePlan" The UI won't show me that plan when trying to change the plan for "Website2".
Has anyone else come across this issue and have any idea of a solution?
First of all, Azure Resource Group naming is not case sensitive. So I've no idea how you created two resource groups with the name Default-Web-NorthEurope and Default-Web-northeurope successfully. I suggest you double check the names in the portal.
Assume that the Default-Web-NorthEurope and Default-Web-northeurope are different groups and as you descriped Website1 is in Default-Web-NorthEurope, Website2 in Default-Web-northeurope, UI will definitely not show you the App Service Plan you created for "Websites1" when trying to change the plan for "Website2". Because both apps and plans are contained in a resource group. Apps can be moved between plans as long as the plans are in the same resource group and geographical region. In other words, when you want to change plans for app, the plans must be in the same resource group and geographical region.
Check azure-web-sites-web-hosting-plans-in-depth-overview for details.