I became interested in Azure and while studying and answering questions, i'm really confused about this question.
ExpressRoute "Microsoft Peering" enables customers to: (select all that apply)
A. Connect to their virtual network resources from on premises
B. Connect to internet resources securely
C. Connect to Office 365 Services
D. Connect to Azure Services
I think it is B only not really sure.
I found this online
"Microsoft peering
Microsoft 365 was created to be accessed securely and reliably via the Internet. Because of this, we recommend ExpressRoute for specific scenarios. For information about using ExpressRoute to access Microsoft 365, visit Azure ExpressRoute for Microsoft 365.
Connectivity to Microsoft online services (Microsoft 365 and Azure PaaS services) occurs through Microsoft peering. We enable bi-directional connectivity between your WAN and Microsoft cloud services through the Microsoft peering routing domain. You must connect to Microsoft cloud services only over public IP addresses that are owned by you or your connectivity provider and you must adhere to all the defined rules. For more information, see the ExpressRoute prerequisites page.
it is A, Express Route is used when you want a secured but also a speedy and committed connection your Azure region of choice. This way the connection from your organization's on-prem network is not only secure but also fast as you go from on-prem to your Telco then Hub to your Azure region. ExpressRoute is available for both Azure and Office 365 services.
Related
We have some dedicated LOB application on-premise applications. Access to these apps is through the public Internet. Active Directory Domain Services is used to authenticate users.
In Azure, there are multiple ways to create high-availability; is there something similar for on-premise apps using Azure? By this I mean if one on-premise system is down, traffic is routed to another app.
I know there are some options such as Application Gateway, Traffic manager and Front-door including Azure LB, my question is - are these the right services we should use in an on-premise setting?
For your on premise environment, you can use Network Load balancing(NLB) feature of Windows Server. See details here, it has an Azure inspired feature too.
We are migrating our website on Azure platform in PaSS model. our website needs to communicate to our back office system using web services.
Currently the Back Office system is in a providers data center. and we have a firewall which enables web service communication for specific IP's
Now website going to be hosted on Azure with PaSS model, can some one please advice which IP address we need to add in whitelist of our Back office firewall.
Please note we want to set up our web app to be out-scaled to multiple instances.
will each instance will be able to communicate with out Back office ?
Regards
Umesh Deshmukh
can some one please advice which IP address we need to add in
whitelist of our Back office firewall. Please note we want to set up
our web app to be out-scaled to multiple instances. will each instance
will be able to communicate with out Back office ?
For a long-term, Hybrid Connection is much better. If you still want to know whitelist the outbound IP of web app service, you could find these possible outbound IP addresses in additional outbound IP addresses setting of the web app properties. You can't know beforehand which IP address a given app instance will use to make the outbound connection, so your back-end service must open its firewall to all the outbound IP addresses of your app. You could get more details about Inbound and outbound IP addresses in Azure App Service.
You could use Azure Service Bus Relay to connect your web app to your on-premises database that's behind the firewall. Azure service bus relay uses internet port 80 so there should be no firewall issues. Hope it helps.
Within an App Service is a feature called a Hybrid Connection, which can be found under the Networking section of the App Service you want to connect to your back office.
You will create a new Hybrid Connection via the Portal.
Complete the form with the information that pertains to the back office system you want to connect to. You should always use a Fully Qualified Domain Name for all your back office systems. If you are connecting to multiple back office systems, you will need one Hybrid Connection for each one.
A Hybrid Connection relies on a Service Bus Relay to communicate with your on-premises resources.
You will install the Hybrid Connection Manager in your on-premises systems and connect it to the Service Bus Relay you created in the portal.
Once the Hybrid Connection you create in the Portal has been connected to a Hybrid Connection Manager (called a Listener), the connection will show as Connected in the Portal.
Once connected, an application running in an App Service will be able to communicate with your on-premises resources as if they were sitting right next to each other. There is going to be some inherent latency involved with using a Hybrid Connection and this should be planned for. The latency we have seen using Hybrid Connections have been minimal and are usually barely noticeable. I have even heard that people are streaming media from on-premises systems using Hybrid Connections.
More information about Hybrid Connections can be found here.
Is it okay to use a single Azure Expressroute connection for both Office 365 and Cloud Infrastructure migration? My customer is moving towards O365, and later probably next year they will start moving their infrastructure assets including their developer workstations to Azure IaaS. Customer is concerned about the public internet based communication and wants to implement a secure and faster communication channel. However, I understand that just for O365 Expressroute maybe an overkill, but considering the longer term plans, I can safely suggest Expressroute. So, my questions are:
A single Expressoute connection can handle both O365 and Cloud
Infra migration?
Is there a difference in the type of circuits used for O365 and
Cloud Infra?
I would think that you can easily accomplish that depending, on how much bandwidth you are piping through the ExpressRoute
ExpressRoute for Azure and for Office365, all run off the same hardware / circuits as far as i can recall.
Great diagram for Azure ExpressRoute for O365:
https://support.office.com/en-us/article/azure-expressroute-for-office-365-6d2534a2-c19c-4a99-be5e-33a0cee5d3bd?ui=en-US&rs=en-US&ad=US
Important to note:
Some connections such as Public DNS and Content Delivery Network nodes
still require the public internet connection. Also the
users who are not located in their ExpressRoute connected
building are connecting over the Internet.
1) For sure you could use a single ExpressRoute circuit. Circuits are available with speeds from 50 Mb to 10 Gb- speeds and prices: https://azure.microsoft.com/en-au/pricing/details/expressroute/.
2) Initially, i would suggest just signing up for Microsoft peering. This will allow you to configure Route Filters with the BGP Communities relevant to Office 365 and your use case- like Exchange Online (to move mailboxes). If you work with your Microsoft account manager/TAM to get approval for Azure AD as well, you can move authentication via the BGP Community "Other Office 365 Services".
I would stress though that Office 365 is designed to work over the public internet. Most customers i've worked with in the past migrated 100's of Gb's worth of mail over the public internet with no issue at all, averaging 5-10 Gb data of uploads per hour on 100 Mb WAN links contended with general internet traffic.
What are the differences between Hybrid Connection and the On-Premises Data Gateway?
Initially my focus is on Azure App Services (Web Apps, Logic Apps, maybe API Apps) connecting to internal web services
I started checking out Hybrid Connections versus Service Bus Relay, but another member of the team mentioned the On-Premises Data Gateway which is coming from the Microsoft business application platform, so Power BI, Microsoft Flow and Power Apps
So I'm now confused over the direction ... is the Gateway replacing Hybrid and Relay?
I'm not totally sure about this but it seems that On-Premises Data Gateway is a connection between On-Premise and servers (IaaS) in Azure. Hybrid Connection is used to connect On-Premise to e.g. Web Apps (PaaS) in Azure.
So I would say that at least one difference is whether On-Premise is connected to IaaS or PaaS.
My answer above is based on information in following links:
https://learn.microsoft.com/en-us/azure/analysis-services/analysis-services-gateway
https://azure.microsoft.com/sv-se/resources/videos/josh-twist-introduces-hybrid-connections
From an integration perspective, let's say you want to read some data from on-premises SQL server as a step in a logic app.
If you have either a Site-to-Site VPN or ExpressRoute providing connectivity between your on-premises network and Azure VNET, create an Azure ISE (Integration Services Environment) deployed to an Azure VNET. You will then be able to connect directly to the SQL server from your Logic App (since it is resolvable / contactable via DNS). Ref:
https://learn.microsoft.com/en-us/azure/logic-apps/connect-virtual-network-vnet-isolated-environment-overview
If you do not have this connectivity in place, you can install a Data Gateway component on-premises to present configured internal data sources to Azure using a persistent outbound connection (like app proxy). Ref:
https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-gateway-connection
However, even if you do have network connectivity in place, in some scenarios (and from experiences) there may be a benefit in using the Data Gateway for it's caching capabilities (if applicable to the scenario). Ref:
https://learn.microsoft.com/en-us/power-bi/guidance/gateway-onprem-sizing
We have a corporate web services with back end SAP, CRM etc. We would like to expose this web service (java web service) so that azure web role can connect to corporate intranet web services.
Could someone please suggest which of below technologies will fit and why:
1. Windows Service Bus
2. Windows Azure Connect
or 3. VPN (Virtual Network).
Service bus will require some effort to get working, but is a good solution if your corporate network overlords are very picky about exposing endpoints. Windows Azure Connect creates a VPN-like tunnel, but requires that specific software be installed, configured and maintained. I have an app that successfully uses virtual networking and utilises existing VPN gateways and skills - very understandable to the security and networking people.