Actionable Advisories

Optimization Opportunities with ‘Clickable Actions’

Actionable Advisories

Actionable Advisories alerts users via emails of possible optimization opportunities and more importantly allow them to take immediate actions to execute on those recommendations. This option provides full control to the customers and provides semi-automated actions with all the added value of Dynamic resource optimization. Advisories will be in the form of daily emails, with clickable links to optimization actions.



Broad Analysis

Screen Shot 2017-05-21 at 3.48.19 PM

Customizable: Advisories can now be customized by specifying various metrics used to identify advisories. Eg. Max read/write capacity to be used to determine DynamoDB over-provisioned advisories. Age of snapshots in days to identify old snapshots, High/low CPU utilization to be used to determine underutilized EC2 instances etc.

Screen Shot 2017-05-21 at 3.50.34 PM

Applications level categorization: Customers can now define ‘Applications’ based on tags and get advisory reports based on applications across multiple AWS accounts allowing customers to manage and optimize costs at Applications level.

Account level categorization: For customers with multiple accounts, Advisories are automatically categorized under each account for easier management.

Filters: For easier management, advisories can be filtered based on advisory types, Accounts, or products. Advisories can also be searched based on any keywords or tags used on resources.

Ignore Advisories:  In scenarios where a user decides to keep a resource over-provisioned future advisories can be marked to be ignored so that no further advisories are generated.


Advisory of the week

EC2 Autoscale Group Underutilized 

AWS Auto Scaling Group enables customers to dynamically adjust the number of EC2 instances automatically. Customers define Launch Configurations, Scaling Policies, as well as minimum size, maximum size, desired size for each Auto Scaling Group. Launch Configuration specifies an EC2 type, AMI, spot price. Scaling Policy can specify a target value for CPU, ELB, or network utilization. Customers can also create a policy with steps which specifies how many instance to add/remove when a certain CloudWatch alarm is triggered.


However,  many customers over provision Auto Scale Group which results in unnecessary cost. The over-provisioning could come from conservative estimation or change of the usage pattern. The Under-utilized Auto Scaling Groups advisory identifies over provisioned Auto Scaling Groups based on history CPU utilization. Available actions are:

  1. Reduce minimum size to a proper value
  2. Ignore

Unattached EBS Volumes 

Elastic Block Store (EBS) is block storage resource typically used by high-performance applications such as databases. AWS offers EBS in many flavors with different cost and performance characteristics. Broadly, EBS storage can be provisioned based on capacity (gp2, st1, st1) or performance (io1).

Often customers create EBS volumes for test purposes and forget to delete them when they are no longer in use. Typically EC2 instances may be deleted, but the EBS volumes attached are forgotten (AWS does provide a switch to delete attached storage when EC2 instances are deleted).  Such volumes remain unattached and add to the wasted spending.

This advisory identifies and reports all EBS volumes that are not attached to any EC2 instances. Available actions are:

1) Delete

2) Take a snap and delete

3) Ignore

Over provisioned DynamoDB Tables

Like most of AWS services, customers are required to provision read/write capacities they expect to utilize when provisioning DynamoDB resources. AWS charges customers based on the capacities provisioned.  Often customers over provision read/write capacities, resulting in wasted spending.  This advisory analyzes read/write capacity utilization of DynamoDB tables and alerts customers on over provisioned tables. Alerts are sent via emails with clickable actions and are also accessible from the Web GUI. Available actions for this advisory are 1) Adjust capacity to x 2) Ignore. On selecting ‘Adjust capacity’ and executing the action will adjust the provisioning the optimum level, reducing cost.

This advisory can be customized to specify the following parameters:

  1. Provisioned Reads (Report only if the provisioned capacity is above the specified value)
  2. Provisioned Writes (Report only if the provisioned capacity is above the specified value)
  3. Days to Check:  Number of days worth of data that should be analyzed to make a recommendation

EBS IOPS Schedule Recommendation

Elastic Block Store (EBS) is block storage resource typically used by high-performance applications such as databases. AWS offers EBS in many flavors with different cost and performance characteristics. Broadly, EBS storage can be provisioned based on capacity (gp2, st1, st1) or performance (io1).  For IO1 type storage, customers pay for provisioned performance or IOPS  in addition to provisioned capacity.  For e.g. a customer may provision a volume capable of 10,000 IOPS and AWS will guarantee that performance.

As is the case with most AWS resources, customers pay for provisioned EBS IOPS and not used IOPS. You may provision a 10,000 IOPS volume but may use the full capacity only for short periods of time a day (or may not use the max provisioned capacity at all).  Significant cost savings can be achieved if IOPS provisioning is adjusted multiple times a day to match the utilization.

Consider the following utilization for a volume with say 10,000 provisioned IOPS:

  • 9am-11am – Peak utilization 9,000 IOPS
  • 11am-4pm – Peak utilization 2,000 IOPS
  • 4pm-6pm – Peak utilization 3,000 IOPS
  • 6pm-9am – Peak utilization 5,00 IOPS

By scheduling the EBS IOPS using the schedule above can result in significant cost savings!  This advisory uses machine learning to identify recommended IOPS schedule so that customers don’t have to try to figure out the best utilization schedule. Customers are then allowed to convert the recommendations into an actual schedule with the click of a mouse and from then on software manages the IOPS provisioning based on the recommended schedule.

Over-provisioned RDS Instances

Amazon Relational Database Service (RDS) is a fully managed relational database service offered by AWS. It is easy to set up, operate and scales easily. AWS manages the service such that users don’t need to worry about typical database administration tasks. Six different database engines (Aurora, PostgreSQL, MySQL, MariaDB, Oracle, Microsoft SQL) are supported. RDS instances can be configured using different compute instance types with varying CPU/Memory characteristics.

As is the case with most public cloud resources and services, customers need to know the application requirements and decide the type of the database instance and the amount of storage space to be provisioned (Aurora is an exception where the storage capacity is automatically provisioned). Typically in every instance family, cost and the CPU/memory capabilities double with every step up. For e.g. on-demand cost of MySQL version of db.m4.4xlarge (which is $1.401/hour) is twice as much as db.m4.2xlarge. So, an incorrectly provisioned DB instance can waste a significant amount of money.

Similarly, AWS charges for the database storage based on provisioned capacity (except for Aurora). Storage can be provisioned as general purpose SSD or Provisioned IOPS SSD. Over provisioning of both capacity and performance can result in significantly wasted spending.


FittedCloud RDS advisory monitors RDS utilization and alerts customers on potential cost savings opportunities.  Following underutilized scenarios are identified and reported with appropriate actions attached.

  1. RDS instances with no connections for a specified number of days.  If there have been no connections to the database, it is an indication that the database may not really be in use, could be created for test purposes and could be deleted.
  2. RDS instances with low CPU utilization. This indicates that the DB instance could be scaled down to a lower instance type without impacting application performance and reduce cost.

Supported actions are ‘Stop’ (stops the DB instance), ‘Adjust’ (switches to a lower instance type), or ‘ignore’ (in which case no advisories will be generated on the same instance in the future.

Cross-Type EBS Optimization

Elastic Block Store (EBS) is block storage resource typically used by high-performance applications such as databases. AWS offers EBS in many flavors with different cost and performance characteristics. Broadly, EBS storage can be provisioned based on capacity (gp2, st1, st1) or performance (io1).

Type of the volume provisioned is usually determined by the need. For e.g. an application that requires guaranteed performance would provision IO1. For general high-performance applications, GP2 is a good choice and so on. Often customers find that they are not utilizing the full capabilities offered by the selected type. For. e.g. GP2 offers 3 IOPS per GB. A 500GB GP2 volume would provide 1500 IOPS (this is not considering the burst performance up to 3000 IOPS). If your application never really uses 1500 IOPS, it would make sense to change the type to SC1 or ST1.  ST1 offers 500 IOPS (at up to 1MB block size) and SC1 offers 250 IOPS (at up to 1MB block size). So, if your application uses below 250 IOPS, consider using SC1, which will give you a cost savings of 75%!  If your application uses below 500 IOPS, consider using ST1, which will give you a cost savings of 55%!  (Note: ST1 and SC1 requires a minimum capacity of 500GB)

This advisory analyzes the utilization of provisioned EBS and makes recommendations to reduce cost while maintaining application performance.

Recommendation examples are:

  • Reduce provisioned IOPS
  • Convert any IO1 to GP2
  • Covert GP2 to ST1 or SC1
  • Covert ST1 to SC1

Actions available depend on the type of the advisory, but fall under the categories of ‘reducing IOPS’ or ‘converting’ to a low-cost type.

EBS Volume snapshots older than specified days

Elastic Block Store (EBS) is block storage resource typically used by high-performance applications such as databases. AWS provides a mechanism to take snapshots of EBS volumes for backup and other purposes. snapshots are stored on S3. Data from snapshots can be brought back online by creating volumes from snapshots. Snapshots are also created when customers create AMIs.  AWS charges customers based on the actual space utilized on a volume.  For e.g. Snapshot of a 100GB volume which only has 10GB of data will only occupy 10GB of S3 space.

It is a common scenario that customers create snapshots and forget to delete them, adding to the cost. This advisory checks for snapshots that are older than a specified number of days (90 days is default).  This allows customers to ensure that any old snapshots that are no longer needed are identified and deleted. Supported actions are: 

1) Delete

2) Ignore

This advisory is customizable and users may specify the age of the snapshot to setup the recommendations.

In today’s connected world, chances of intrusion and malicious attacks are constant. Public cloud environments, such as AWS, are not immune either. For example, if a company’s identity and access management (IAM) keys get exposed or stolen they can be used by an attacker to create a large number of public cloud compute and storage resources that can cause financial harm. Unfortunately, there are no mechanisms that exist in public cloud infrastructures to prevent such a malicious act.

Human or programming errors in automation scripts can also cause abnormal changes to resource provisioning. These types of errors can create a significant number of resources not only causing direct financial harm but also restricting resources needed for mission critical applications.

FittedCloud Anomaly Detection Solution watches resource utilizations in a near real-time manner, identifies anomalies using sophisticated machine learning algorithms and alert customers so that such attacks or mistakes can be prevented.

Key Features:

Anomaly details with visualization

Simple and easy to configure

Highest accuracy with low/no noise

Email alerts to warn customers

Monitor Amazon EC2, EBS, S3 resources

Root cause analysis of anomalies

Sophisticated Machine Learning algorithms

Near real-time analysis