Increasing Operational Efficiency With Kasten K10 V6.0

Image
We are excited to announce the release of Kasten K10 version 6.0, the latest and most advanced version of our industry-leading platform that provides enterprise-grade Kubernetes data protection and application mobility. This release helps customers scale their cloud native data protection efficiently. Kubernetes deployments are growing at an unprecedented rate. Gartner predicts that by 2027, more than 90% of global organizations will be running containerized applications in production. However, today’s market conditions are scarred with financial uncertainty and a shortage of cloud native skills. Therefore, you must ensure operational efficiencies are in place to unleash the full potential of your cloud native environments while protecting your data. Additionally, security remains an imperative as organizations focus on keeping their businesses running. With this release, we also continue to innovate in this growing ecosystem, so that you can take advantage of the best-of-breed inn

What is the Point? Comparing Microsoft Azure Service and Private Endpoints

Information is key in today’s business world. Not just having it, but making sure it does not end up in the wrong hands. This is true regardless if you are in a private cloud or leveraging a public cloud like Microsoft Azure.

Keeping your network traffic secure and avoiding routing over the internet is key to maintaining data security. Luckily, Microsoft Azure provides two “endpoint” methods to ensure data takes an optimized route:

  • Service endpoint:
    • This provides secure and direct connectivity to Azure services over the Azure backbone

A list of Azure services supported with a service endpoint can be found here.

  • Private endpoint:
    • Allows you to leverage a private IP from your virtual network to connect privately and securely to an Azure service

A list of Azure services supported with a private endpoint can be found here.

Before we get into the specifics of each endpoint, it is important to understand what occurs if there are no endpoints (service or private) configured.

Note: for the examples used in this blog, we will be connecting to a Microsoft Azure storage account.

When a storage account is created, a public endpoint is used for communication. This means that when a workload/client/application needs to communicate with the storage account, the public endpoint will resolve to a public IP address and the traffic will be routed over the internet.

Although the traffic is encrypted, it will traverse the internet.

The first way we can avoid sending traffic over the internet is via a service endpoint. But how do service endpoints function?

Believe it or not, the storage account endpoint still creates and resolves to the public IP… but an additional step occurs. When any Azure VM within the vNet attempts to connect to the PUBLIC endpoint of a storage account, the “next hop” will be redirected to the Azure network backbone.

The figure below highlights the properties of a vNIC and the “Effective routes”. We can see that there are additional routes automatically created/added when the service endpoint is configured:

And once the routes are added, any traffic that is targeting the public endpoint of the storage account will be directed over the Azure network backbone.

The second way we can avoid sending traffic over the internet that is destined for an Azure service is via a private endpoint. The benefit of a private endpoint is that all traffic will remain in the vNet and it will never traverse the internet and/or the Azure network backbone.

The first step is that the storage account will leverage a private IP address from within the vNet — in the example: 10.0.0.10. This will allow the workloads to communicate directly with the Azure service via the private IP.

Next, a public and private DNS entry/IP address will also be automatically created.

  • Public Endpoint DNS name: <sa>.blob.core.windows.net
  • Public Endpoint DNS name: <sa>.privatelink.blob.core.windows.net

Azure will also create a CNAME DNS record resolving the public address to the private IP. In this case, the public endpoint will resolve to 10.0.0.10. This means that all traffic will stay within the Azure vNet and not traverse the Azure network backbone.

And because we now have a routed network, resources from on-premises can communicate with Azure services WITHOUT going over the public internet — assuming there is an ExpressRoute or VPN connection.

Note: Keep in mind that DNS / HOSTS file will need to be updated to resolve appropriately for on-premises connectivity

Let’s now directly compare the service and private endpoints:

 

Service endpoint

Private endpoint

Scope

Per service

Per instance

Connectivity

Public IP

(Effective routes updated on VM NIC)

Private IP

 Network Security

Group (NSG) Config

May need to adjust

Not applicable as communication is within the subnet

Data security

Traffic leaves virtual network to Azure backbone

No data exfiltration

On-premises connectivity

No

Yes

Note: this is a great way to leverage ExpressRoute or VPN for Scale-Out Backup Repository Offloading tasks

Cost

Included in Azure services… FREE

Cost for using service

Cost for amount of data transferred

 

For details on use cases for service and private endpoint, please connect with your local Veeam account team.

 

A service or private endpoint is a great way to keep your data secure and maximize performance, all the while minimizing costs — the great combination when leveraging Veeam to protect your data.

The post What is the Point? Comparing Microsoft Azure Service and Private Endpoints appeared first on Veeam Software Official Blog.



Original post here: What is the Point? Comparing Microsoft Azure Service and Private Endpoints

Comments

Popular posts from this blog

What is Multi-Cloud?

How To Migrate a Veeam Backup & Replication Configuration Database to PostgreSQL

Securing Veeam Hardened Repository