Connecting the usable resources is a central point in cloud computing. The connection between the on-premises infrastructure and the cloud environment plays an important role in IT operational tasks, so as to make the most of all synergies of your own infrastructure.
The requirements depending on the specific case must be taken into account with regard to latencies, bandwidth and, especially, secure communication. In my latest blog article I’ll show you the ways of setting up a connection between your on-premises home constellation and the cloud infrastructure constellations.
“What’s with the „worm“ part? The worm thing. I-I don’t get that.“ – O’Neill
Azure offers several different ways of connecting your existing infrastructure. In this article we’ll focus on connections of the site-to-site type (S2S). Their most basic components include a stargate endpoint on each side, pointing into the respective network.
Following the negotiation and configuration of the connection parameters, a wormhole tunnel is set up between the gateways, enabling communication between the two sites. These communication paths are private and encrypted and therefore essential for meeting the safety requirements on secure communication.
There are two basic types of technologies for connecting Azure resources:
VPNs are encrypted point-to-point connections (tunnels) via the internet. They protect the information flow against unauthorized reading of data and enable a safe connection between remote constellations networks despite use of the public network.
– Source: Microsoft/own representation
Express routes are private connections between different locations, with the data traffic not flowing through the internet. Express routes are redundant by default and offer very low latencies at high bandwidths.
– Source: Microsoft/own representation
While both connection types require gateways, not every connection type is recommended for every application case.
Establishing a S2S VPN between Azure and your on-premises environment requires setting several parameters (the same ones on both ends). Target and home coordinates Required are remote and local gateway addresses, the IKE version (Internet Key Exchange), the networks (to be accessed behind the stargate gateway) and the parameters for phase 1 (key exchange) and phase 2 (data exchange).
– Source: Xinux
An IPsec connection to Azure provides the following features:
Connection via an Azure S2S VPN is suitable for most application cases and significantly less expensive than connection by express route. If no requirements prohibit data traffic flow via a public channel (the internet), and no unusually high bandwidths (> 1.25 Gbps) or very low latencies are required, you should choose an S2S connection.
Unlike IPsec VPN, express route connections transmit data not through public channels, but through a backbone network from Microsoft and its partners. The partners perform the peering between your home world locations and the partner planets partner locations and from there to the Azure networks.
– Source: Microsoft
Express route connections include the following features:
If requirements demand a private connection or a connection with very low latencies and unusually high bandwidths (up to 10 Gbps), an express route connection is recommended. VPN connections can also terminate on an express route stargate gateway.
Connections through different networks have been with us since the late 1990s, when Microsoft created the first point-to-point protocol (PPTN) in 1996. Little by little, this technology established itself as a means of securely interconnecting remote networks.
The advent of cloud computing has increased the need for high-performance and especially secure connections. Hybrid architectures are unavoidable, and the progressive decentralization of networks necessitates companies to set up increasingly secure connections.
Site-to-site VPN or an express route to Azure allows connecting to your home world in a secure and flexible way.
„I am your god!“– pick a random goa‘uld
IT – Security Engineer
Uni Campus Nord
D – 66123 Saarbrücken
As a security engineer at Scheer GmbH I work in the Managed Services division of the company. I am responsible for the secure operation of the infrastructure including its strategic development in respect of security organisation and technologies.
My extensive experience gained from working in security related projects and the running of workshops plays a major role in my work. My focus lies in the tasks of developing and implementing security concepts. In this context, I concentrate on cloud security as well as the adherence to and implementation of compliance requirements in the cloud.