I have a Hub-&-Spoke architecture.
I have 1 hub and multiple spokes that represent stages (dev, test, prod etc).
My applications live in AKS in spokes and I tag them and the services they use to keep tabs on costs incurred by each application. But how do I include the costs incurred by each application during data transfer?
Example #1
VNETs are peered, and inbound/outbound data is $0.01 / GB. How do I put this cost into the account of the responsible application?
Example #2
My firewall lives in hub and each application gets its data through the firewall. The Firewall is not part of any application. But how do I assign the data that the firewall process for each application?
Related
Some time ago we had a vendor build a proof of concept in Azure for us. We don't have time at this point to analyze it, and it is incurring costs even though things are turned off. Is there a way for us to export and delete everything so that we could at some point easily import it and spin it back up?
We've got 6 resource groups and 76 resource which include app services, app service plans, application isignts, disk, dns zone, function apps, key vault, kubernetes services, load balencer, network interface, network security groups, network watcher, public ip addresses, rout table, service bus namespace, shared dahsboard, sql databases, sql servers, storage accounts, virtual machine, virtual neworks.
Some of those services incur cost even if they are turned off so we want to decommission them entirely, but hopefully easily rebuild if necessary.
I know that Azure Isolated App Service Plan provide several benefits like:
Network level isolation
More worker units
Better performance
but i wonder if the isolation is also on the hardware level or not ?
With Azure App Service Environment version 3 (ASEv3), you can deploy it on a dedicated host group. Host group deployments are not zone redundant for ASEv3.
Azure Dedicated Host is a service that provides physical servers - able to host one or more virtual machines - dedicated to one Azure subscription. Dedicated hosts are the same physical servers used in our data centers, provided as a resource. You can provision dedicated hosts within a region, availability zone, and fault domain. Then, you can place VMs directly into your provisioned hosts, in whatever configuration best meets your needs.
This is NOT available with ASEv2.
Reference:
https://learn.microsoft.com/en-us/azure/app-service/environment/overview
https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts
I have two kind of services deployed on Azure, and they need communicate with each other. So far two options:
1. Put them in same Vnet
2. Put them in separate Vnet and create Vnet-to-Vnet connection between them.
My question is, is there any performance/bandwidth limitation on option 2 compared to option 1?
I would say approach 1 is better in case you have less load in your vNet.
In Approach 2 the communication depends on below factors-
1. Whether the two vNets are in same region or not. If yes obviously you will face less latency.
2. Which vNet gateway you have selected- high performance vNet gateway provides faster speed over basic and standard.
Azure point to site vpn connections are reliable only when the data to be transferred is not much ( < 1Tb ) and are in the same region.
Also consider that with option 2 you will face egress data charges for traffic exiting the VNET.
If you're workloads are similar or are even in two separate tiers (web vs app vs data for example), you can segregate them via subnet and NSG. You don't need to separate out into different VNETs.
I know that with the Premium tier, I could have up to 50 instances to put my web app on in Azure. If I needed to go beyond this, like 75 instances, what would be the most appropriate way to do this?
Maybe two different app service plans, different web app endpoints load balanced by Traffic Manager?
Thanks!
A Hosting Plan is simply a geographical collection of web servers. With in that hosting plan you can have 'x' number of servers (depending on the SKU)
The machines in a Hosting Plan will be split across fault and update domains. So that a server rack dying, or an upgrade rollout won't take out all of the servers in the hosting plan.
However what this doesn't protect you against is geographically scaled issues. If you have a hosting plan in West Europe and the West Europe region suffers an outage. At that point you could lose your entire deployment.
This is where them being a geographical collection of servers becomes an important characteristic. If you create a number of hosting plans in a number of regions, not only will you have local redundancy against fault and update outages but you will also gain redundancy against geographical outages.
Obviously if you need 500 servers, there is nothing stopping you creating 10 premium SKU hosting plans and deploying them all to the West Europe region and creating some sort of round robin DNS load balancing solution.
But the better solution is to share them across regions. Creating a hierarchy of traffic manager profiles to share the load amongst them. With the right automation you can have some regions coming on and off line as your load increases / decreases.
Personally, unless I have specifically required premium features (Biztalk etc) my preference has always been to simply deploy more service plans. It is far more cost effective.
I have more than one subscription to Windows Azure and would like to have machines in different subscriptions on the same network.
For example
An SQL Server in one subscription and an application server in another
An Active Directory Server in one subscription and machine members of the domain in another
An Azure network seems to be limited to a subscription.
I was thinking of adding a point-to-site VPN connection between subscription.
Would I get charged egress data for a VPN connection between Azure subscription in the same region?
I have a limited amount of free Azure credit in each subscription, but it is not enough to provision all the VMs that I need in one - I want to spread the machines over a couple of subscriptions.
One option is to communicate via public endpoints that have ACL's applied to them, to only allow incoming traffic from specific IP addresses (and in your case, you'd only allow traffic from sub1's deployment's public VIP associated with xyz.cloudapp.net). This allows communication without dealing with vnets or vpn's.
If your app involves message-passing (either via service bus or Azure queues), then the subscription boundary doesn't matter.
There's no bandwidth charges for services within the same region.