Amazon ECS Overview: What You Need To Know

Amazon ECS Overview: What You Need To Know

Amazon ECS is a great choice of container hosting platforms for AWS developers, among the many available options. Jumping into an ECS deployment can be daunting, as there are multiple options and varying terminology with hard-to-predict costs. We’ll go over some of the basics of Amazon ECS, including some terminology and price considerations you’ll need to consider.

Amazon ECS 101

Amazon ECS (which stands for Elastic Container Service) lets you run Docker containers without having to manage the orchestration of those containers. With ECS, you can deploy your containers on EC2 servers or in a serverless mode, which Amazon calls Fargate. Both deployment types handle the orchestration and underlying server management for you, so you can just schedule and deploy your containers.

Amazon ECS can work for both long-running jobs and short bursts of tasks, and includes tools for adjusting the scale of the container fleet as well as the scheduling of those containers. Task placement definitions let you choose which instances get which containers, or you can let AWS manage this by spreading across all Availability Zones.

Benefits of Amazon ECS include:

  • Easy integrations into other AWS services, like Load Balancers, VPCs, and IAM
  • Highly scalable without having to manage the cluster masters
  • Multiple management methods, including the AWS console, the AWS API, or CloudFormation templates
  • Elastic Container Registry helps you manage and sort your container images

Tasks and Services and Containers (Oh My!)

Diving into the world of containers on AWS requires the use of some terminology you may not be familiar with:

  • Container – An isolated environment that contains the bare minimum of services and code needed to run just a particular part of your application or microservice, designed to be run on any Docker-compatible OS.
  • Task Definition – A layout of the pieces required to run your application, which can include one or more containers along with networking and system requirements.
  • Task – An instantiation of a Task Definition.  Multiple tasks can use the same task definition.
  • Service – A layout of the boundaries and scaling options you set for your groupings of similar Tasks, which is similar to the relationship between AutoScaling Groups and EC2 Virtual Machines.
  • Cluster – A collection of EC2 instances running a specialized operating system where you will run your Service.

ECS Pricing: The (Hopefully Not) Million Dollar Question

Amazon ECS pricing has a few different variables, starting with your choice of deployment methods.  Since Fargate abstracts away the underlying infrastructure, you only pay for the seconds of vCPU and Memory that your Tasks are using (with a minimum of 1 minute for each Task). This pricing structure has the “serverless architecture” benefit of only paying for what you need when you need it, but also means that estimating these charges can be quite difficult.

Standard ECS pricing does not charge per-Task, but will charge based on the infrastructure you have deployed for your cluster. The cluster uses AutoScaling Groups of EC2 instances, and during setup of the cluster you can choose the instance size you want and the number of instances for the initial cluster deployment.  Since the cluster can scale up and down, you have the flexibility if you get a spike in task usage, but you do need to keep an eye on underutilized or idle instances.

Containing the Containers

As you can tell, utilizing Amazon ECS containers manages a lot of the back-end work for you, but brings a whole different set of considerations for your organization.  ParkMyCloud has some news coming later this year to help you manage your ECS containers! Contact us if you’d like to be notified when that’s available.

Not yet using containers, but have other AWS infrastructure? We can help control costs.

How MSPs Can Educate Customers on Cloud Cost Models

How MSPs Can Educate Customers on Cloud Cost Models

Part of the role of any managed service provider managing cloud services is to guide their customers through the process of creating and evaluating cloud cost models. This is important whether migrating to the cloud, re-evaluating an existing cloud environment, or simply understanding a monthly cloud bill. Many customers may be more familiar with on-prem cost models, so relating to that mindset is crucial. Here are a few important things to keep in mind when educating your customers about cloud costs.

1.  Explain CapEx vs. OpEx

One of the biggest shifts in mentality that must be made when evaluating cloud cost models is the shift from predominantly Capital Expenditures with on-prem workloads as compared to predominantly Operational Expenditures with cloud workloads.

As one of our customers explained the mindset problem:

“It’s been a challenge educating our team on the cloud model. They’re learning that there’s a direct monetary impact for every hour that an idle instance is running.”

Another contact added: “The world of physical servers was all CapEx driven, requiring big up-front costs, and ending in systems running full time. Now the model is OpEx, and getting our people to see the benefits of the new cost-per-hour model has been challenging but rewarding.”

Deploying a project in a private cloud involves lots of up-front purchases and ongoing maintenance, including servers, power, hardware, buildings, and more. On top of the actual purchase cost, you must account for amortization, depreciation, and the opportunity cost of those purchases.

Cloud workloads often work on a pay-as-you-go model, where you pay only for what services and features you use and how long you use them. This provides organizations with almost no Capital Expenditures for these resources, but results in a dramatic increase in Operational Expenditures. Neither is necessarily a bad thing, but your job as an MSP is to clearly articulate this shift so the customer can understand why the ongoing costs appear so much higher. And, of course, you’ll have to incorporate your own value into the equation.

2.  Make Sure Your Clients Understand Their Cloud Bill Breakdown

For on-prem services, the details of the cost model don’t usually require detail about what software or service is actually running on the physical machine. A database server and a web server may have different specs, but everything becomes normalized to the physical hardware that must be purchased as a one-time fee. This provides a certain level of simplicity in your calculations, but still must account for all the additional physical factors like power, air conditioning, redundancy, cabling, racks, and maintenance.

Cloud services not only charge based on time used, but also have very different costs for each service. A database server and a web server are going to have very different cost structures, and will show up on your monthly bill as separate items. This often makes the bill look much more complex, but the flip side of that is that you have many opportunities for optimization and cost allocation.

3.  Be the Authority on IT Costs

Creating cloud cost models for your customers can require a big mental shift from other cost models, but it’s an important step for current and future IT projects. Understanding what the options are, what the costs are, and what your usage will be, are all factors. Make sure to convey all of these aspects to the stakeholders of your client in a clear way to avoid the surprise bill at the end of each month.  

Ultimately, the market for cloud managed services is growing, which is good for managed service providers. As customers migrate to the cloud, they will need cost optimization expertise, which is a great angle for MSPs to get a foot in the door.

Review of the AWS Right Sizing Tool: Helpful or Clunky?

Review of the AWS Right Sizing Tool: Helpful or Clunky?

Amazon Web Services (AWS) provides a treasure trove of documents and CloudFormation templates in their AWS Solutions portal, including AWS right sizing, the AWS instance scheduler, a chatbot framework, and more. These solutions can be used as-is for immediate integration into your existing environment, or can be the starting point for developing your own unique toolsets. Today, we’re reviewing the AWS Right Sizing tool to see how much it can help you optimize your infrastructure.

AWS Right Sizing: What It Does

AWS offers a variety of types and sizes of EC2 instances. That means that it’s perfectly possible to select an instance type that’s too large for your actual needs, which means you’ll be paying more than necessary. In fact, the data shows that this is happening most of the time. The AWS Right Sizing tool exists to help users find the correct instance size to meet their needs at the lowest cost.

The tool uses a CloudFormation template that deploys infrastructure and scripts needed to make right sizing recommendations for your AWS account. This infrastructure includes an EC2 instance that will run python scripts, a 2-node Redshift cluster for the right sizing analysis, and an S3 bucket for the raw CloudWatch data and the final CSV output. The total cost of this deployment in the us-east-1 region is $0.65 per hour.

The basis of the right sizing logic is to look at the Max CPU from the past 2 weeks of CloudWatch data for each EC2 instance. If the max CPU is above 50% at any point, then it will not recommend a change, but if it is always below 50% then it will attempt to find the cheapest instance size that matches the I/O, memory, network, and at least the max CPU that was found. The final output is a CSV file that includes information about the existing instance sizes, the utilization of those instances, the recommended instance size, and the cost saved per month.

Worth the hassle?

Based on the logic above, the AWS Right Sizing tool does a very basic level of recommendation for instance sizing. There are a few scenarios where these recommendations may not be helpful, such as applications that are memory-intensive or cases where the instance needs to be a larger size than it currently is. The tool also only spits out a CSV with the recommendations, which means you still have to make decisions and take actions based on those recommendations. The CSV file looks like this:

If those recommendations don’t seem to fit what you’re looking for, the nice thing is they offer the full stack, along with all scripts and CloudFormation templates, as an open-source repository. This means you can take the core of the recommendation engine and tweak it to follow your own logic for customized recommendations, or even use it to trigger the resizing of the instance. AWS also offers Trusted Advisor as a part of their Business-level and Enterprise-level support plans, which can offer right sizing recommendations in real time (amongst other health checks and recommendations).

Overall, this AWS right sizing tool can either be a useful check-up tool for your environment, or the basis for your own cost-optimization initiative, but many users will want a more out-of-the-box automated solution for this.

Since changing server sizes and timing this with maintenance windows can be a hassle, ParkMyCloud has introduced a feature to automate the resizing of your EC2 instances. Interested? Check it out with a free trial.

How to Use 9 Cloud DevOps Best Practices For Cost Control

How to Use 9 Cloud DevOps Best Practices For Cost Control

Any organization with a functioning cloud DevOps practice will have some common core tenants. While those tenants are frequently applied to things like code delivery and security, a company that fails to apply those tenants to cost control are destined to have a runaway cloud bill (or at least have a series of upcoming meetings with the CFO). Here are some of those tenants, and how they apply to cost control:

1. Leadership

One common excuse for wasted cloud spend is “well that other group has cloud waste too!” By aggressively targeting and eliminating cloud waste, you can set the tone for cost control within your team, which will spread throughout the rest of the organization. This also helps to get everyone thinking about the business, even if it doesn’t seem like wasting a few bucks here or there really matters (hint: it does).

2. Collaborative Culture

By tearing down silos and sharing ideas and services, cost control can be a normal part of DevOps cloud practice instead of a forced decree that no one wants to take part in. Writing a script that is more generally applicable, or finding a tool that others can be invited to will cause others to save money and join in. You may also get ideas from others that you never thought of, without having to waste time or replicate work.

3. Design for DevOps

Having cost control as a central priority within your team means that you end up building it into your processes and software as you go. Attempting to control costs after-the-fact can be tough and can cause rewrites or rolling back instead of pressing forward. Also, tacked-on cost control is often less effective and saves less money than starting with it.

4. Continuous Integration

Integrating ideas and code from multiple teams with multiple codebases and processes can be daunting, which is why continually integrating as new commits happen is such a big step forward. Along the same lines, continually controlling costs during the integration phase means you can optimize your cloud spend by sharing resources, slimming down those resources, and shutting down resources until they are needed by the integration.

5. Continuous Testing

Continuous testing of software helps find bugs quickly and while developers are still working on those systems. Cost control during the testing phase can take multiple forms, including controlling the costs of those test servers, or doing continuous testing of the cost models and cost reduction strategies. New scripts and tools that are being used for cost control can also be tested during this phase.

6. Continuous Monitoring

Monitoring and reporting, like cost control, are often haphazardly tacked on to a software project instead of being a core component. For a lot of organizations, this means that costs aren’t actively being monitored and reported, which is what causes yelling from the Finance team when that cloud bill comes. By making everyone aware of how costs are trending and noting when huge spikes occur, you can keep those bills in check and help save yourself from those dreaded finance meetings.

7. Continuous Security

Cloud cost control can contribute to better security practices. For example, shutting down Virtual Machines when they aren’t in use decreases the number of entry points for would-be hackers, and helps mitigate various attack strategies. Reducing your total number of virtual machines also makes it easier for your security teams to harden and monitor the machines that exist.

8. Elastic Infrastructure

Auto-scaling resources are usually implemented by making services scale up automatically, while the “scaling down” part is an afterthought. It can be admittedly tricky to drain existing users and processes from under-utilized resources, but having lots of systems with low load is the leading cause of cloud waste. Additionally, having different scale patterns based on time of day, day of the week, and business need can be implemented, but requires thought and effort into this type of cost control.

9. Continuous Delivery/Deployment

Deploying your completed code to production can be exciting and terrifying at the same time. One factor that you need to consider is the size and cost of those production resources.  Cost savings for those resources is usually different from the dev/test/QA resources, as they typically need to be on 24/7 and can’t have high latency or long spin-up times. However, there are some cost control measures, like pre-paying for instances or having accurate usage patterns for your elastic environments, that should be considered by your production teams.

Full Cloud DevOps Cost Control

As you can see, there are a lot of paths to lowering your cloud bill by using some common cloud DevOps tenants. By working these ideas into your teams and weaving it throughout your processes, you can save money and help lead others to do the same. Controlling these costs can lead to fewer headaches, more time, and more money for future projects, which is what we’re all aiming to achieve with DevOps.

Should You Use the Cloud-Native Instance Scheduler Tools?

Should You Use the Cloud-Native Instance Scheduler Tools?

When adopting or optimizing your public cloud use, it’s important to eliminate wasted spend from idle resources – which is why you need to include an instance scheduler in your plan. An instance scheduler ensures that non-production resources – those used for development, staging, testing, and QA – are stopped when they’re not being used, so you aren’t charged for compute time you’re not actually using.

AWS, Azure, and Google Cloud each offer an instance scheduler option. Will these fit your needs – or will you need something more robust? Let’s take a look at the offerings and see the benefits and drawbacks of each.

AWS Instance Scheduler

AWS has a solution called the AWS Instance Scheduler. AWS provides a CloudFormation template that deploys all the infrastructure needed to schedule EC2 and RDS instances. This infrastructure includes DynamoDB tables, Lambda functions, and CloudWatch alarms and metrics, and relies on tagging of instances to shut down and turn on the resources.

The AWS Instance scheduler is fairly robust in that it allows you to have multiple schedules, override those schedules, connect to other AWS accounts, temporarily resize instances, and manage both EC2 instances and RDS databases.  However, that management is done exclusively through editing DynamoDB table entries, which is not the most user-friendly experience. All of those settings in DynamoDB are applied via instance tags, which is good if your organization is tag-savvy, but can be a problem if not all users have access to change tags.

If you will have multiple users adding and updating schedules, the Instance Scheduler does not provide good auditing or multi-user capabilities. You’ll want to strongly consider an alternative.

Microsoft Azure Automation

Microsoft has a feature called Azure Automation, which includes multiple solutions for VM management. One of those solutions is “Start/Stop VMs during off-hours”, which deploys runbooks, schedules, and log analytics in your Azure subscription for managing instances. Configuration is done in the runbook parameters and variables, and email notifications can be sent for each schedule.

This solution steps you through the setup for timing of start and stop, along with email configuration and the target VMs. However, multiple schedules require multiple deployments of the solution, and connecting to additional Azure subscriptions requires even more deployments. They do include the ability to order or sequence your start/stop, which can be very helpful for multi-component applications, but there’s no option for temporary overrides and no UI for self-service management. One really nice feature is the ability to recognize when instances are idle, and automatically stop them after a set time period, which the other tools don’t provide.

Google Cloud Scheduler

Google also has packaged some of their Cloud components together into a Google Cloud Scheduler. This includes usage of Google Cloud Functions for running the scripts, Google Cloud Pub/Sub messages for driving the actions, and Google Cloud Scheduler Jobs to actually kick-off the start and stop for the VMs. Unlike AWS and Azure, this requires individual setup (instead of being packaged into a deployment), but the documentation takes you step-by-step through the process.

Google Cloud Scheduler relies on instance names instead of tags by default, though the functions are all made available for you to modify as you need. The settings are all built into those functions, which makes updating or modifying much more complicated than the other services. There’s also no real UI available, and the out-of-the-box experience is fairly limited in scope.

Cloud Native or Third Party?

Each of the instance scheduler tools provided by the cloud providers has a few limitations. One possible dealbreaker is that none of these tools are multi-cloud capable, so if your organization uses multiple public clouds then you may need to go for a third-party tool. They also don’t provide a self-service UI, built-in RBAC capabilities, Single Sign-On, or reporting capabilities. When it comes to cost, all of these tools are “free”, but you end up paying for the deployed infrastructure and services that are used, so the cost can be very hard to pin down.

We built ParkMyCloud to solve the instance scheduler problem (now with rightsizing too). Here’s how the functionality stacks up against the cloud-native options:

 

AWS Instance SchedulerMicrosoft Azure AutomationGoogle Cloud SchedulerParkMyCloud
Virtual Machine scheduling
Database scheduling
Scale Set scheduling
Tag-based scheduling
Usage-based recommendations
Simple UI
Resize instances
Override Schedules
Reporting
Start/Stop notifications
Multi-Account
Multi-Cloud

Overall, the cloud-native instance scheduler tools can help you get started on your cost-saving journey, but may not fulfill your longer-term requirements due to their limitations.

Try ParkMyCloud with a free trial — we think you’ll find that it meets your needs in the long run.