NEW in ParkMyCloud: Containers! Now Offering AWS EKS Cost Optimization

NEW in ParkMyCloud: Containers! Now Offering AWS EKS Cost Optimization

We are happy to announce that ParkMyCloud can now optimize costs for container services, beginning today with Amazon EKS (managed Elastic Kubernetes Service) cost optimization through scheduling. As container adoption grows faster than ever before, ParkMyCloud is here to ensure your costs are controlled and optimized.

Container Cost Optimization Is Needed – Now

Container adoption is growing. Gartner predicts that by 2023, more than 70% of global organizations will have more than two containerized applications in production – and that’s compared to less than 20% last year. That growth will, of course, come with greater spending on these technologies, with 451 Research predicting a $2.7 billion market this year, growing by 60% to $4.3 billion by 2022. In a customer survey we conducted earlier this year, 50% of users of EKS said they planned to either use it the same as this year (14%) or see increased usage (36%).

As is the case with compute and database resources, inefficient use of containers can cause significant wasted cloud spend. Sources of waste include: nonproduction pods that are idle outside of working hours, oversized pods, oversized nodes, and overprovisioned persistent storage. 

EKS Scheduling in ParkMyCloud

Since 2015, ParkMyCloud users have reduced cloud costs by identifying idle and over-provisioned compute and database resources, and programmatically scheduling and resizing them, saving enterprises around the world tens of millions of dollars.

Now, that same scheduling is available to reduce EKS costs. You can set schedules based on working hours and automatically assign those schedules with the platform’s policy engine. Better yet, see ParkMyCloud schedule recommendations for your resources based on your utilization data. 

Try it now:

  • If you are new to ParkMyCloud – start a free trial to get started.
  • If you have an existing ParkMyCloud account, please note you’ll have to update your IAM role permissions. Details available in the release notes
  • If you use another cloud or container service…we’ll catch up with you soon! See below.

More Container Optimization Coming Soon

This release is just the beginning of container optimization in ParkMyCloud. In the next few months, the platform will also support scheduling for Amazon ECS, AWS Fargate, Azure Kubernetes Services (AKS), and Google Kubernetes Engine (GKE).

In addition to container on/off scheduling, we also plan to provide Kubernetes Cluster rightsizing recommendations, and help you account for your containers when looking at buying reserved instances and savings plans.

Questions? Feature requests? We’d love to hear them. Comment below or contact us directly.

Further reading:

ParkMyCloud Expands Cloud Cost Optimization to Containers

ParkMyCloud Expands Cloud Cost Optimization to Containers

ParkMyCloud’s Amazon EKS Scheduling Enables Enterprises to Identify and Eliminate Billions in Wasted Cloud Spend

March 31, 2020 (Dulles, VA) ParkMyCloud, provider of the leading enterprise platform for continuous cost control in public cloud, has expanded its public cloud cost optimization capabilities to container technology, starting with Amazon Elastic Kubernetes Service (Amazon EKS). 

Wasted cloud spend is a significant problem, draining IT budgets in companies of all sizes and across industry verticals. ParkMyCloud reports that cloud waste will exceed $17.6 billion this year, with container spend accounting for $2.7 billion of that, growing by 60% to $4.3 billion by 2022. 

As is the case with compute and database resources, inefficient use of containers can cause significant wasted cloud spend. Sources of waste include: nonproduction pods that are idle outside of working hours, oversized pods, oversized nodes, and overprovisioned persistent storage. 

Since 2015, ParkMyCloud users have reduced cloud costs by identifying idle and over-provisioned compute and databases resources, and programmatically scheduling and resizing them, saving enterprises around the world tens of millions of dollars. Now, that same scheduling is available to reduce EKS costs. Users can set schedules based on working hours and automatically assign those schedules and resources with policy-driven actions. ParkMyCloud recommends schedules for resources based on actual utilization data. 

“Customers have an immediate need to optimize their Kubernetes spend across the three major cloud providers,” said ParkMyCloud Founder Jay Chapel. “There is a significant pain point around growing wasted spend here, which needs to be addressed through automation and data-driven action – and that’s what ParkMyCloud is now providing.”

Following today’s Amazon EKS support release, ParkMyCloud will soon also support scheduling for Amazon ECS, AWS Fargate, Azure Kubernetes Services (AKS), and Google Kubernetes Engine (GKE), with cluster rightsizing to follow scheduling.

To get started, public cloud users should visit www.parkmycloud.com/free-trial to start a free 14-day trial of the product and receive recommendations for Amazon EKS resources, as well as compute and database resources in AWS, Azure, and Google Cloud. 

About ParkMyCloud

ParkMyCloud, a Turbonomic company, provides a self-service SaaS platform that helps enterprises automatically identify and eliminate wasted cloud spend. More than 1,400 enterprises around the world – including Sysco, Workfront, Hitachi ID Systems, Sage Software, and National Geographic – trust ParkMyCloud to cut their cloud spend by tens of millions of dollars annually. ParkMyCloud allows enterprises to easily manage, govern, and optimize their spend across multiple public clouds. For more information, visit www.parkmycloud.com.

Contact

Katy Stalcup, ParkMyCloud

kstalcup@parkmycloud.com 

How Microsoft Azure Deallocate VM vs. Stop VM States Differ

How Microsoft Azure Deallocate VM vs. Stop VM States Differ

Do you know the difference between Azure “deallocate VM” and “stop VM” states? They are similar enough that in conversation, I’ve noticed some confusion around this distinction.  

If your VM is not running, it will have one of two states – Stopped, or Stopped (deallocated). Essentially, if something is “allocated” – you’re still paying for it. So while deallocating a virtual machine sounds like a harsh action that may be permanently deleting data, it’s the way you can save money on your infrastructure costs and eliminate wasted Azure spend with no data loss.

Azure’s Stopped State

When you are logged in to the operating system of an Azure VM, you can issue a command to shut down the server. This will kick you out of the OS and stop all processes, but will maintain the allocated hardware (including the IP addresses currently assigned). If you find the VM in the Azure console, you’ll see the state listed as “Stopped”. The biggest thing you need to know about this state is that you are still being charged by the hour for this instance.

Azure’s Deallocated State

The other way to stop your virtual machine is through Azure itself, whether that’s through the console, Powershell, or the Azure CLI. When you stop a VM through Azure, rather than through the OS, it goes into a “Stopped (deallocated)” state.  This means that any non-static public IPs will be released, but you’ll also stop paying for the VM’s compute costs. This is a great way to save money on your Azure costs when you don’t need those VMs running, and is the state that ParkMyCloud puts your VMs in when they are parked.

Which State to Choose?

The only scenario in which you should ever choose the stopped state instead of the deallocated state for a VM in Azure is if you are only briefly stopping the server and would like to keep the dynamic IP address for your testing. If that doesn’t perfectly describe your use case, or you don’t have an opinion one way or the other, then you’ll want to deallocate instead so you aren’t being charged for the VM.

If you’re looking to automate scheduling when you deallocate VMs in Azure, ParkMyCloud can help with that. ParkMyCloud makes it easy to identify idle resources using Azure Metrics and to automatically schedule your non-production servers to turn off when they are idle, such as overnight or on weekends. Try it for free today to save money on your Azure bill!

Further reading:

How to Use Google Preemptible VMs to Get 80% Savings

How to Use Google Preemptible VMs to Get 80% Savings

Google Cloud has always had a knack for non-standard virtual machines, and their option of creating Google preemptible VMs is no different. Traditional virtual machines are long-running servers with standard operating systems that are only shut down when you say they can be shut down. On the other hand, preemptible VMs last no longer than 24 hours and can be stopped on a moment’s notice (and may not be available at all). So why use them?

Google Cloud Preemptible VM Overview

Preemptible VMs are designed to be a low-cost, short-duration option for batch jobs and fault-tolerant workloads. Essentially, Google is offering up extra capacity at a huge discount – with the tradeoff that if that capacity is needed for other (full-priced)  resources, your instances can be terminated or “preempted”. Of course, if you’re using them for batch processing, being preempted will slow down your job without completely stopping it. 

You can create your preemptible VMs in a managed instance group in order to easily manage a collection of VMs as a single entity – and, if a VM is preempted, the VM will be automatically recreated. Alternatively, you can use Kubernetes Engine container clusters to automatically recreate preempted VMs.  

Preemptible VM Pricing

Pricing is fixed, not variable, and you can view the preemptible price alongside the on demand prices in Google’s compute pricing list and/or pricing calculator. Prices are 70-80% off on demand, and upward of 50% off even compared to a 3-year committed use discount

Google does not charge you for instances if they are preempted in the first minute after they start running.

Note: Google Cloud Free Tier credits for Compute Engine do not apply to preemptible instances. 

Use Cases for Google Preemptible VMs

As with most trade-offs, the biggest reason to use a preemptible VM is cost. Preemptible VMs can save you up to 80% compared to a normal on-demand virtual machine. (By the way – AWS users will want to use Spot Instances for the same reason, and Azure users can check out Low Priority VMs). This is a huge savings if the workload you’re trying to run consists of short-lived processes or things that are not urgent and can be done any time. This can include things like financial modeling, rendering and encoding, and even some parts of your CI/CD pipeline or code testing framework.

How to Create a Google Preemptible VM

To create a preemptible VM, you can use the Google Cloud Platform console, the ‘gcloud’ command line tool, or the Google Cloud API. The process is the same as creating a standard VM: you select your instance size, networking options, disk setup, and SSH keys, with the one minor change that you enable the ‘preemptible’ flag during setup. The other change you’ll want to make is to create a shutdown script to decide what happens to your processes and data if the instance is stopped without your knowledge. This script can even perform different actions if the instance was preempted as opposed to shut down from something you did.

One nice benefit of Google preemptible VMs is the ability to attach local SSD drives and GPUs to the instances. This means you can get added extensibility and performance for the workload that you are running, while still saving money. You can also have preemptible instances in a managed instance group for high scalability when the instances are available. This can help you process more of your jobs at once when the preemptible virtual machines are able to run.

FAQs About Google Preemptible Instances

How long do GCP preemptible VMs last?

These instances can last up to 24 hours. If you stop or start an instance, the 24-hour counter is reset because the instance transitions into a terminated state. If an instance is reset or other actions that keep it in a running state, the 24-hour clock is not reset. 

Is pricing variable?

No, pricing for preemptible VMs is fixed, so you know in advance what you will pay.

What happens when my instance is preempted? 

When your instance is preempted, you will get a 30 second graceful shutdown period. The instance will get a preemption notice in the form of an ACPI G2 Soft Off signal. You can use a shutdown script to complete cleanup actions before the instance stops. If an instance does not stop after 30 seconds, it will get an ACPI G3 Mechanical Off signal to the operating system, and terminate it. You can practice what this looks like by stopping the instance.

By using managed instance groups, you can automatically recreate your instances if capacity is available. 

How often are you actually preempted?

Google reports an average preemption rate from 5-15% per day per project, with occasional spikes depending on time and zone. This is not a guarantee, though, and you can be preempted at any time. 

How does Google choose which instances to preempt?

Google avoids preempting too many instances from a single customer, and preempts new instances over older instances whenever possible – this is to avoid losing work across your cluster. 

How to Use Google Preemptible VMs to Optimize Costs

Our customers who have the most cost-effective use of Google resources often mix Google preemptible VMs with other instance types based on the workloads. For instance, production systems that need to be up 24/7 can buy committed-use discounts for up to 57% savings on those servers. Non-production systems, like dev, test, QA, and staging, can use on-demand resources with schedules managed by ParkMyCloud to save 65%. Then, any batch workloads or non-urgent jobs can use Google preemptible instances to run whenever available for up to 80% savings. Questions about optimizing cloud costs? We’re happy to help – email us or use the chat client on this page (staffed by real people, including me!).

Further reading on Google Cloud cost optimization:

5 Things You Need to Know About AWS Regions and Availability Zones

5 Things You Need to Know About AWS Regions and Availability Zones

Anytime you provision infrastructure from Amazon Web Services (AWS), you will need to choose which of the AWS Regions and Availability Zones it will live in. Here are 5 things you need to know about these geographic groupings, including tips on how to choose, and things to watch out for. 

1. What are AWS Regions and How Many are There? 

AWS Regions are the broadest geographic category that define the physical locations of AWS data centers. Currently, there are 22 regions dispersed worldwide across North America, South America, Europe, China, Africa, Asia Pacific and the Middle East. All Regions are isolated and independent of one another. 

Every region consists of multiple, separate Availability Zones within a geographic area. AWS offers Regions with a multiple AZ design – unlike other cloud providers who see a region as one single data center. 

AWS has a larger footprint around the globe than all the other cloud providers, and to support their customers and ensure they maintain this global footprint, AWS is constantly opening new Regions. 

Here’s a look at the different regions and their AWS code. 

NameCode
US East (Ohio)us-east-2
US East (N. Virginia)us-east-1
US West (N. California)us-west-1
US West (Oregon)us-west-2
US GovCloud Westus-gov-west-1
US GovCloud Eastus-gov-east-1
Asia Pacific (Hong Kong)ap-east-1
Asia Pacific (Mumbai) ap-south-1
Asia Pacific (Seoul)ap-northeast-2
Asia Pacific (Singapore)ap-southeast-1
Asia Pacific (Sydney)ap-southeast-2
Asia Pacific (Tokyo)ap-northeast-1
Canada (Central)ca-central-1
Europe (Frankfurt)eu-central-1
Europe (Ireland)eu-west-1
Europe (London)eu-west-2
Europe (Paris)eu-west-3
Europe (Stockholm)eu-north-1
Middle East (Bahrain)me-south-1
South America (São Paulo)sa-east-1
China (Beijing)cn-north-1
China (Ningxia)cn-northwest-1

**Note: AWS manages US GovCloud, AWS China, and the general AWS as distinct “partitions”. An account must be set up within the partition to get access to any of the regions in that partition.**

2. What are AWS Availability Zones and How Many are There? 

An Availability Zone (AZ) consists of one or more data centers at a location within an AWS Region. Each AZ has independent cooling, power, and physical security. Additionally, they are connected through redundant, ultra-low-latency networks. 

In AZ’s, customers are able to operate production applications and databases that are more fault tolerant, scalable, and highly available than you would see from a single data center. 

Every AZ in an AWS Region is interconnected with high-bandwidth, low-latency networking, fully redundant, metro fiber in order to provide high-throughput, low-latency networking between AZ’s. All AZ’s are physically separated by a significant distance from any other AZ,  although all are within 60 miles of each other.

Around the world, there are currently 69 Availability Zones. Here’s a breakdown of each Availability Zones you can find within a Region.

NameCode# of Availability ZonesAvailability Zones
US East (Ohio)us-east-23us-east-2a 

us-east-2b 

us-east-2c

US East (N. Virginia)us-east-16us-east-1a

us-east-1b

us-east-1c

us-east-1d

us-east-1e

us-east-1f

US West (N. California)us-west-13us-west-1a

us-west-1b

us-west-1c

US West (Oregon)us-west-24us-west-2a

us-west-2b

us-west-2c

us-west-2d

US GovCloud Westus-gov-west-13us-gov-west-1a

us-gov-west-1b

us-gov-west-1c

US GovCloud Eastus-gov-east-13us-gov-east-1a

us-gov-east-1b

us-gov-east-1c

Asia Pacific (Hong Kong)ap-east-13ap-east-1a

ap-east-1b

ap-east-1c

Asia Pacific (Mumbai) ap-south-13ap-south-1a

ap-south-1b

ap-south-1c

Asia Pacific (Seoul)ap-northeast-23ap-northeast-2a

ap-northeast-2b

ap-northeast-2c

Asia Pacific (Singapore)ap-southeast-13ap-southeast-1a

ap-southeast-1b

ap-southeast-1c

Asia Pacific (Sydney)ap-southeast-23ap-southeast-2a

ap-southeast-2b

ap-southeast-2c

Asia Pacific (Tokyo)ap-northeast-14ap-northeast-1a

ap-northeast-1b

ap-northeast-1c

ap-northeast-1d

Canada (Central)ca-central-12ca-central-1a

ca-central-1b

Europe (Frankfurt)eu-central-13eu-central-1a

eu-central-1b

eu-central-1c

Europe (Ireland)eu-west-13eu-west-1a

eu-west-1b

eu-west-1c

Europe (London)eu-west-23eu-west-2a

eu-west-2b

eu-west-2c

Europe (Paris)eu-west-33eu-west-3a

eu-west-3b

eu-west-3c

Europe (Stockholm)eu-north-13eu-north-1a

eu-north-1b

eu-north-1c

Middle East (Bahrain)me-south-13me-south-1a

me-south-1b

me-south-1c

South America (São Paulo)sa-east-13sa-east-1a

sa-east-1b

sa-east-1c

China  (Beijing)cn-north-12cn-north-1a

cn-north-1b

China (Ningxia)cn-northwest-13cn-northwest-1a

cn-northwest-1b

cn-northwest-1c

There is also an option available called AWS Local Zones. This allows deployment of latency-sensitive portions of applications close to large populations where no AWS region currently exists. The first one is Los Angeles, which belongs to the Oregon region (and not the California region).

3. How to Choose a Region/AZ

So that’s what they are – now how do you choose a region and availability zone for 

  • Distance – choose regions close to you and your customers to keep latency low
  • Service availabilityas we’ll discuss more below, there are some regions that offer more services than others, and new services will tend to be introduced in these regions first.
  • Cost – always check the AWS pricing calculator to compare the cost between regions. N. Virginia is usually the least expensive among others. Sao Paulo is typically the most expensive.
  • ComplianceGDPR, government contracting, and other regulated industries may require a specific region or multiple regions

4. What Sorts of Functions are Defined by Region and Availability Zone?

Regionless Services

Some services, like AWS IAM, do not support Regions. Therefore, the endpoints for those services do not include a Region. Other services, such as Amazon EC2, support Regions but, you are able to specify an endpoint that does not include a Region. Additionally, Amazon Simple Storage Service (Amazon S3), supports cross-Region replication.

AWS Regions introduced before March 20, 2019 are enabled by default. You can begin working in these Regions immediately. Regions introduced after March 20, 2019 are disabled by default – you must enable these Regions before you can use them. Administrators for an account can enable and disable Regions and use a policy condition that controls who can have access to AWS services in a particular AWS Region.

There are some less popular services such as Alexa for Business, Amazon Augmented AI (A2I), Amazon Fraud Detector, and Amazon Mobile Analytics are only available in the US East (N. Virginia) Region.

Region Differences Across Major Services

Amazon S3

Amazon Simple Storage Service (S3) is storage for the internet. You can use Amazon S3 to store and retrieve any amount of data at any time, from anywhere on the web. 

You specify an AWS Region when you create your Amazon S3 bucket. For S3 Standard, S3 Standard-IA, and S3 Glacier storage classes, your objects are automatically stored across multiple devices ranging on a minimum of three Availability Zones, each separated across an AWS Region. Objects stored in the S3 One Zone-IA storage class are stored redundantly within a single Availability Zone in the AWS Region you select. 

S3 operates in a minimum of three AZs, each separated by miles to protect against local events like fires, floods, etc. S3 is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East.

Amazon Elastic Compute Cloud

Amazon Elastic Compute Cloud (EC2) provides resizable, scalable computing capacity in the cloud. Each Amazon EC2 Region is designed to be isolated from the other Amazon EC2 Regions. This achieves the greatest possible fault tolerance and stability.

When you view your resources, you see only the resources that are tied to the Region that you specified. Why does this happen? Because Regions are isolated from each other, and resources are not automatically replicated across Regions.

When you launch an EC2 instance, you must select an AMI that’s in the same Region. If the AMI is in another Region, you can copy the AMI to the Region you’re using. When you launch an instance, you can select an Availability Zone or let Amazon choose one for you.

EC2 is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East.

AWS Lambda

AWS Lambda runs your code in response to triggers and automatically manages the compute resources for you. Lambda maintains compute capacity across multiple AZ’s in each Region in order to help protect code against individual machine or data center facility failures. 

AWS Lambda is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East. The only region Lambda is not available in is Osaka, which is a local region. This type of region is new and is made up of an isolated fault-tolerant infrastructure design located in a single data center. 

Amazon Simple Notification Service

Amazon SNS is a highly available, durable, secure, fully managed messaging service that allows you to decouple distributed systems, microservices, and serverless applications. SNS uses cross availability zone message storage to provide high message longevity. 

Amazon SNS is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East.

Amazon EBS

Amazon Elastic Block Store (EBS) is AWS’s block-level, persistent local storage solution for Amazon EC2 that allows you to minimize data loss and recovery time while being able to regularly back up your data and log files across different geographic regions.

EBS volumes are replicated within an Availability Zone (AZ) and can easily scale to petabytes of data. Each volume is designed to protect against failures by replicating within the Availability Zone (AZ), offering 99.999% availability and an annual failure rate (AFR) of between 0.1%-0.2%. You can also quickly restore new volumes to launch applications in new regions.

EBS Snapshots can be used to quickly restore new volumes across a region’s Availability Zones, enabling rapid scale.

EBS is available in all Regions in North America, South America, Europe, Africa, China, Asia Pacific and the Middle East.

5. Transferring Data Between Regions Can Matter Too

Transferring data between AWS services within a region costs differently depending on whether you’re transferring data within or across AZs.

Data transfers are free if you are within the same region, same availability zone, and use a private IP address. Data transfers within the same region, but in different availability zones, have a cost associated with them.

So, to summarize, AWS Regions are separate geographic areas and within these regions are isolated locations that are known as Availability Zones (AZ). It’s important to pay attention to the services offered in each Region and AZ so you can make sure you are getting the most optimal service in your area.