Keeping AWS Charges Under Control with VPC Endpoints

We have all heard the horror stories of the sysadmin who racked up a multi-thousand dollar bill because of a misconfigured environment, and sadly these tales of woe are indeed not myths. One of my customers very recently discovered a $4000 charge due to sending over 105 TB with of data to S3! What happened there, how did we fix it, and how can we prevent this from happening in the future?

First, the way I describe AWS to my customers is that it’s not one monolithic organization in which one service seamlessly communicates with other services via hidden channels. Instead, it’s easier to think of AWS as a huge conglomerate of separate teams (because that’s really what they are), and those teams’ products talk to each other largely via the use of APIs, accessed over HTTP. That means that if you want to send a file from an instance in EC2 (originating from an EBS block volume) to an S3 bucket, you need to establish a connection to that bucket in the same manner you would access a website over the internet.

Here’s the problem: AWS charges you for every gigabyte of data processed through a NAT gateway as well as egress out of EC2 to the Internet (as well as between regions and other AWS services). If you are moving 105 TB from EC2 over a NAT gateway to S3, you’re going to be facing a serious bill.

blog3

 

Ouch! So how do we avoid something like this from happening? The answer is thankfully very simple, and it’s in the form of a VPC Endpoint. A VPC Endpoint is a way that allows you to securely connect your existing VPC to another AWS service, effectively creating an internal route within AWS’ “walls”. In this fashion, your data never traverses over the gateway of last resort (either being a NAT gateway, your VPN, or IGW), and you are therefore not on the hook for processing that data!

To create a VPC endpoint, select the appropriate region you want to configure, and go to the VPC dashboard here:

blog4

Click on Create Endpoint. There are two separate types of endpoints: interface endpoints, which are driven by AWS PrivateLink, and gateway endpoints. Only two services are supported by gateway endpoints: S3 and DynamoDB. Find S3 and select it:

blog5

Finally, select the appropriate VPC and the route tables that are associated with the Subnets you want to ensure utilize the endpoint. In the context of Zerto and keeping transfer costs from the ZCA to S3 buckets low, this will be the VPC that your ZCA is installed and the route table(s) that your ZCA’s subnet is associated with. You may also decide to customize your endpoint policy at this time as well. If your security rules require a minimally-permissive policy to be implemented to control which resources may utilize the endpoint, you may edit that policy now or later.

Click on the create endpoint button when finished! The endpoint will be created and S3-bound traffic originating from the subnets that are associated with the route tables you have specified will now flow over the endpoint.

blog6

Best of all, gateway endpoints are free! There are edge cases where a VPC endpoint may not be an appropriate fit, and I encourage you to check out https://docs.aws.amazon.com/vpc/latest/userguide/vpce-gateway.html#vpc-endpoints-limitations on the matter, but for Zerto customers wanting to protect their data in AWS, this is a very important topic to understand and I strongly advise you to consider it. It takes literally moments to set up, is free, and will save you the headache of begging your AWS rep for cost forgiveness (or explaining to your boss why there’s suddenly a massive unexpected charge this month).

I welcome any tips, suggestions, or comments here or on Twitter. Hit me up at @vPilotSchenck.

-ajs

VM Types and Sizes in Azure — Picking the right fit for your needs

One of the most-asked questions that I answer for my customers concerns the topic of what their VMs will look like in the cloud post-migration or failover. Zerto makes it very simple to select a VM type and size while creating a virtual protection group, but there are a dizzying amount of VMs that you can pick from!

“A simple problem to resolve,” an administrator may say. “I shall just pick a VM type that has the same hardware as what I have running on-premise in vSphere!” Sadly, this approach is often not possible. VMs in Azure are not built with individual virtual hardware components but rather via pre-defined templates. Thus, one may not be able to make a VM that has the same specifications as on premise. What is an administrator or architect to do?

In this article, we shall explore the topic of virtual machines in Azure. We shall talk about VM types, how to read the Microsoft Azure shorthand to identify those VMs, and how to pick the best VM type for the performance that you need at the price you are willing to pay.

VM Types

When you create a VM in Azure, you are greeted with a window that looks like this:

blog1

Here, you will specify the name of the VM, the region it will run in, and other important details. What we want to focus on is the size. Clicking on “Change size” presents you with this:

blog2

You are presented with a variety of different options, including the VM size, whether it’s a promo or a standard offering, the family type, and the hardware profile.

So what do the VM size letters and numbers mean? Here is a table of what you may see:

Type Purpose
A General purpose
B Burstable – discounted VMs capable of bursting when needed. Do not use for consistently high-CPU workloads.
D General purpose compute, ideal for enterprise applications
DC Security optimized. Built-in encryption capabilities and uses secure enclaves.
E Memory optimized. High memory-to-CPU core ratio.
F CPU optimized. High CPU core-to-memory ratio.
G Giant or “Godzilla”. Massive VMs that exceed the capabilities of the D-series family.
H High-Performance Computing. Extremely high memory bandwidth VMs, ideal for scientific simulations (ie fluid dynamics, quantum simulation, rendering, etc.)
Ls Storage-optimized. High throughput, low-latency, directly mapped NVMe storage. Ideal for databases and data warehousing.
M (Massive) memory optimized. The largest memory optimized VMs possible in Azure. Ideal for SAP HANA and other in-memory critical workloads.
N GPU-optimized. Ideal for graphics rendering, deep learning, gaming, etc.

You may also notice that your VM type may have additional letters appended to it. For example, you may see something like “DS3_v2” or “B8ms”. These additional letters refer to VM capabilities or a revision of a VM family type. So DS3_V2 refers to:

  • D = General purpose enterprise compute
  • S = SSD, machine capable of supporting Premium Managed disks
  • 3 = Size “3”, which is an indicator of how “big” the VM is in terms of CPU, memory, etc.
  • V2 = Version 2 of the VM type.

Similarly, B8ms refers to:

  • B = Burstable
  • 8 = Size “8”
  • m = Memory multiplier, indicating there is more memory available for this VM than usual for this family type
  • s = Premium storage options available (ie Premium managed disks).

There are other codes as well, such as “i” (isolated) and “r” (remote direct memory access). When in doubt, check the official Microsoft page to verify what features a VM may have at https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes.

Performance, Cost, and Compatibility

Now that you understand what the VM name code means, you will want to compare the actual underlying performance of the VM relative to other options. One way to do this would be to look at how many Azure Compute Units (ACUs) that a VM has. ACUs are a way to compare CPU performance between different types of virtual machines in Azure. The benchmark starts at 100 for A1 through A4; a rough rule of thumb is that a 200 ACU \ vCPU value VM is twice as performant than a 100 ACU \ vCPU VM. Use the following link to show the ACU count for any particular VM SKU: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/acu.

Next, you will want to consider the cost of running a VM in the cloud. To do this, navigate to https://azure.microsoft.com/en-us/pricing/details/virtual-machines/windows/ and find your instance type. You may notice that certain VM types are not available in the region of your choice (for example, at the time that this article was written, G-type VMs were not available in the East US region). Make sure you account for that when planning your deployment!

Now that we have determined the VM type that we want to run our migrated or failed over VMs on, and we have determined that the cost is acceptable for the performance we expect, we want to finish our planning by make sure that the VMs themselves are supported in the cloud. I often tell my customers that Zerto doesn’t care what you’re replicating, but Azure does. Microsoft maintains a supportability matrix for both Windows and Linux, so it is wise to ensure that you are failing over a VM that has a supported OS.

https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

https://docs.microsoft.com/en-us/azure/virtual-machines/linux/endorsed-distros

Example:

Your customer is running SQL Server 2018 on Windows Server 2016. The virtual machine consists of 4 vCPUS, 32GB of RAM, and 16 VMDKs. The customer wants to utilize premium managed disks in Azure. Which VM size will most closely fulfill the customer’s requirements?

  1. DS13-4_v2
  2. E4s_v3
  3. A4m_v2
  4. E4_v3

You can immediately discount 3 and 4, as neither of those instance types support premium managed disks. Looking at the VM size matrix, you can see that DS13-4_v2 will be enough, but it has more RAM and disks than is required. E4s_v3 however has 4 vCPUs, 32GB of memory, but only 8 data disks are supported, and you cannot exceed that number without moving onto a new VM type! Thus, out of the four options available, the best answer is 2.

Note that for the aforementioned example, an even better option exists in Azure: E8-4s_v3, which provides 4 vCPUs, 64GB of RAM, and 16 data disks, at a cost of $374.98 per month, versus the DS13-4_v2, which costs $551.30. Also note that the ACU for Es_v3 is 160-190 versus 210-250 for the DS13-4_v2. However the DS13-4_v2 VM is not hyperthreaded while the E4s_v3 is. Take into consideration these details before committing to a specific VM family type!

Conclusion

It is ultimately the end-user’s responsibility to choose the correct VM type and size for their workloads when moving or rearchitecting VMs to run in the cloud. However, as trusted advisors and solutions engineers, we can help guide our customers through the often-confusing journey to the cloud. Picking the right size VM requires an understanding of your customer’s data and applications, but by investing the time and effort to understanding their requirements, you will significantly improve their chances of success.
Continue reading “VM Types and Sizes in Azure — Picking the right fit for your needs”