Route53 Latency based routing

AWS recently enhanced Route53 with the ability to do latency based routing, which serves user requests from the EC2 region for which network latency is lowest. You create a latency resource record, and when Route53 receives a query for the domain, it will select the resource record for the EC2 region that will have the lowest latency for the requesting user. It really is as simple as that. Ylastic now supports managing these latency records. In the example below, we have a load balancer in US East(Virginia) region and one in the US West (California) region. 

R531

You can create a latency record for all seven AWS regions if you like from one screen. How does AWS figure out the latencies in order to make the routing decisions? AWS apparently gathers these latency measurements between most /24 subnets on the internet and the different AWS regions in order to create the dataset that is the basis of latency-based routing. The technology underpinning this is also used by CloudFront, the AWS CDN product.

R532
R533

 

You can also use IP addresses/Elastic IPs instead of ELBs for creating these records. This is a really nice addition to Route53, and much requested by the users. Enjoy :-)

Scheduling the AWS Account Advisor

You can now schedule the AWS Account advisor in Ylastic to run on a time period of your choice. So you can set it up to run checks against your account, say once a week and alert you via email if any flags are raised by the check. How easy is it to setup?

Advisor1
Advisor2

 

You will get an email if there are any warnings from the advisor run.

Advisor3

Advisor5

Simplify your AWS cloud management!

Simple Backups for EBS Instances

At Ylastic, we have been looking at backup management and ways to make it easier and simpler to both create the backups, as well as manage them easily without getting lost in looking through tons of AMIs. Introducing simplified EBS instance backup management - Select an instance, view all of its backups, launch new instances from any of the backups, and even schedule backups to happen on a time period of your choice.

Backups3

 

Backups can be created in two different ways - on-demand, by clicking a button and filling out a few fields.

Backups1

 

You can automate backups by setting up a scheduled task to create them on a time schedule that you want. Automate backups for multiple instances with a single task by specifyng a string to match in the name tag for instances. Ylastic will also save you storage costs by ensuring that only the specified number of latest backups are kept, and prune the older backups. The task shown below will backup all EBS instances in Virginia whose name contains Lorax at 1:00 AM everyday, and keep only the latest ten backups.

Backups5

 

Backups6

 

Ebs instance backup management is a feature available in the Ylastic Plus version. AWS cloud management made easier :-)

Simplifying CloudFormation Stack Management

Ylastic just released several enhancements for CloudFormation stack management. Our initial implementation of the UI was done when CloudFormation was first released, and it is now a rather large and complex service that enables you to reference and use resources from a lot of different services in the AWS stable. The increase in complexity leads to a quick proliferation of the number of resources that comprise your stack, and correspondingly needs a simpler way to get your head around what is in your stack. You launch this wonderful stack that creates instances, databases, Route53 resource records, autoscaling groups and so on. How do you actually view all of these resources that are part of your stack? No, we do not want to view a rather large incomprehensible table that lists just the physical ids for resources, as it is completely worthless in terms of getting any work done. And no, we do not mean navigating to 20 different pages to view them. We mean a single place to view your resources and additional information for each resource. Here we go ..

Formation6

 

All the resources in a stack are displayed on this page, separated by the service that they are part of. Additional and meaningful information for each resource is also presented. For example, if you are viewing the instances that comprise your stack, you can view other info for the instance such as AMI id, zones, uptime, cloudwatch data, etc.

New_formation3

 

There is also an easier way to view the JSON template definition associated with the stack. We added a nicely formatted representation of your stack template. You can even expand and collapse various sections in the template as you like.

New_formation1

 

Stacks have a cost associated with them like most resources in AWS. We like knowing the money that we are spending on AWS, and knowing the expenses that are being incurred for a stack is very, very useful. We now display the estimated costs for each stack computed for two different time periods:

  • Estimated month to date cost for running the stack.
  • Estimated cost to run the stack for the whole year.
New_formation2

 

Finally, another thing that we use a lot when using stacks - the ability to view cloudwatch charts for a resource. Each resource such as instance, elb, volumes, etc will display a little sparkline graph for the CPU util or similar metric for the last 20 minutes. Click on the sparkline to display detailed cloudwatch charts for the selected resource.

New_formation4

Manage your AWS cloud the easier way :-)

AWS Account Advisor

Introducing the Ylastic AWS Account Advisor, a tool for inspecting your AWS environment and identifying opportunities for optimizing your usage of AWS. 

Advisor_0

 

We built it to be very simple and intuitive to use. You pick the checks you want to include in each run of the advisor (this initial release has a total of ten checks), Ylastic runs the checks and gives you a nice list of things that it found. Each advisor run is saved, and at any time you can review past runs.

Advisor_2

 

The checks are broadly divided into four categories:

  • Cost Optimization - Opportunities for reducing costs by detecting unused volumes, elastic load balancers, elastic ip addresses and Route 53 zones. These checks will also display an estimated cost saving per month and per year from removing the unused resources.
  • Disaster Recovery - Check your ability to recover from system wide failures by detecting volumes that are in-use but not being backed up to snapshots. The advisor will also flag volumes that have snapshots older than several days, as that may be an indication that the backups are getting stale.
  • Fault Tolerance - Identifies situations that can impact your ability to recover from the failure of an EC2 availability zone, by checking if your elastic load balancers have distributed allocation of instances, as well as if you have instances distributed in more than one zone.
  • Security Audit - Secure access to your resources by detecting security groups that provide public access to sensitive ports or port ranges, as well as S3 buckets that can be listed by anonymous users across the internet.

As you use AWS over time, cruft builds up, and you start having unused resources in your account that are just driving up your costs. One of the cool features of the advisor is to flag these unused resources, and give you an estimate of the savings that you can get if you get rid of them. The screenshot below is from one of our customers that helped us test the advisor. Those elastic IPs, old unused volumes and balancers add up pretty quick :-)

    Advisor_9

     

    The advisor is a feature available in the Ylastic Plus version. Coming soon, the ability to run the advisor on a schedule, as well as enhancements and additional checks based on feedback from customers that have already been trying this out. 

    Enjoy :-)

    AWS Route53 Spending Analytics

    You have all your domains nicely imported into Route53 using Ylastic. You have scheduled backups of your zones to the S3 bucket of your choice for DR using Ylastic. You do have those zones backed up, right? You can view an audit trail of all the changes/additions/updates being made to your zones in Ylastic. And now you can view the spending break-down for all of those zones in Ylastic Plus. View the spending for the current month, previous month, curent year or the last year.

    R53_analytics_1
    Screen_shot_2012-01-11_at_7

     

    Easily view the cost associated with each of the zones you are hosting in Route53. The chart also displays the total number of queries made for the displayed zones in the chosen time period.

    R53_analytics_3

     

    R53_analytics_2

    More integrated cool tools for Route 53 in the pipeline. Manage your AWS cloud, the easy way!

    Migrating Amazon Linux AMI between EC2 regions

    You can now migrate Amazon Linux based AMIs between regions of your choice in Ylastic. Select your AMI, the region you want to migrate to, and that’s it.

    Screen_shot_2011-12-21_at_9

    Get an email when the migration is completed.

    Screen_shot_2011-12-21_at_9

    Launch an instance at your leisure from the new AMI and off you go.

    Screen_shot_2011-12-21_at_9

    Enjoy and happy holidays!!

    EC2 Auto Scaling Management

    Refreshed our auto scaling support to include all of the recent features released by AWS. Here is a quick run through of the various things that you can do with auto scaling on EC2.

    Scaling10

     

    Create auto scaling groups with a new easy to use wizard that also lets you set up policies and their associated alarms for scaling up/down your EC2 fleet.

    Scaling3

     

    View and manage all of your resources  associated with the scaling groups. 

    Scaling7

    Suspend scaling processes to investigate any configuration issues with your app and resume scaling processes when you are done.

    Scaling6

    Create and manage scaling policies and their associated alarms to setup the thresholds for scaling your fleet of instances.

    Scaling5

    Setup scheduled scaling actions to increase/decrease the number of instances in your fleet. You can also setup the scaling action to be recurring on a schedule of your choice.

    Scaling8

     

    Peruse cloud watch charts of group metrics for the scaling group of your choice.

    Scaling2

     

    You can still manage your auto scaling groups that are using the trigger mechanism that has been deprecated by AWS. 

    Scaling9

    More goodies on the way. Enjoy :-)

    Amazon EBS Snapshots in the EU-West Region

    AWS has discovered a bug in their software that cleans up EBS snapshots in the EU West region. They are contacting customers that have snapshots affected by this bug. Here is the email that some of our customers are receiving:

    Hello,

    We’ve discovered an error in the Amazon EBS software that cleans up unused snapshots.  This has affected at least one of your snapshots in the EU-West Region.During a recent run of this EBS software in the EU-West Region, one or more blocks in a number of EBS snapshots were incorrectly deleted. The root cause was a software error that caused the snapshot references to a subset of blocks to be missed during the reference counting process. This process compares the blocks scheduled for deletion to the blocks referenced in customer snapshots. As a result of the software error, the EBS snapshot management system in the EU-West Region incorrectly thought some of the blocks were no longer being used and deleted them. We’ve addressed the error in the EBS snapshot system to prevent it from recurring.

    We have now disabled all of your snapshots that contain these missing blocks. You can determine which of your snapshots were affected via the AWS Management Console or the DescribeSnapshots API call. The status for any affected snapshots will be shown as “error.”We have created copies of your affected snapshots where we’ve replaced the missing blocks with empty blocks. You can create a new volume from these snapshot copies and run a recovery tool on it (e.g. a file system recovery tool like fsck); in some cases this may restore normal volume operation. These snapshots can be identified via the snapshot Description field which you can see on the AWS Management Console or via the DescribeSnapshots API call. The Description field contains “Recovery Snapshot snap-xxxx” where snap-xxx is the id of the affected snapshot. Alternately, if you have any older or more recent snapshots that were unaffected, you will be able to create a volume from those snapshots without error. For additional questions, you may open a case in our Support Center: https://aws.amazon.com/support/createCase

    We apologize for any potential impact this might have on your applications.Sincerely,
    AWS Developer Support

    Migrating EBS instances to an AMI in a different region

    You have an EBS instance running in US east region. But you want to migrate this instance to an AMI in EU, for disaster recovery, testing, whatever. And you say want to do this simply and without major contortions, preferably via a GUI. We hear you :-) Ylastic now has the ability to migrate an EBS linux instance to an AMI in a region of your choice. Pick a few options, and click a button.

    Screen_shot_2011-07-10_at_9

    And receive an email when the migration is complete :-)

    Screen_shot_2011-07-10_at_11

    Enjoy :-)