Three new features in Ylastic to make your Route 53 management even more easier.
We now have customers that are importing large zone files with hundreds of resource records into Route 53. Ylastic added the ability to batch your changes so you can import even large zone files without running into the Route 53 limitation of 100 changes at a time. All you have to do is pick a zone file to import, and we will take care of all the chunkng and batching for the changes on our end.
Have lots of resource records in your zones, and feeling a bit overwhelmed with finding what you need? We have the fix for you. Search and filter through your records easily. Type a string to match and off you go.
Ability to delete all resource records from a zone easily. This will only delete the records that you added or imported, and will not remove the Route 53 provided NS and SOA records. Oh yeah, we handle the batching of change requests, even if you are deleting more than 100 records.
Are you a texting ninja that gets their info fixes via short messages? Ylastic can send you AWS alerts via SMS. If you want to receive an SMS on an international number, just append a +CountryCode to the phone number on the settings page :-)
If you are thinking about migrating from your existing DNS provider to Route53 or just want to kick the tires on Route 53, Ylastic just added two features that will make the move a lot simpler and quicker.
Import zone file data from your existing DNS provider into Route 53.
Export zone data from Route 53 for backups, etc.
First the import. Here is my hosted zone with only the default NS and SOA records.
Select the Import Records button, paste the contents of your zone file and click import.
Your resource records will refresh and display the imported records.
The export is even easier. Just select the Export to Zone File button, and you will get all the records from your selected hosted zone in BIND zone file format.
AWS recently released a new service named Route 53 for managing the DNS for your domains. Ylastic now provides complete management for this new service. Route 53 introduces the concept of hosted zones which are collections of resource record sets for each domain you host with AWS. You can manage and configure all of the DNS information for each hosted zone by modifying the resource records for the zone. We have integrated support for Route 53 into our dashboard so you can manage your DNS along with a host of other infrastructure services from AWS in one unified interface.
Create, update, delete hosted zones for your domains.
Create, update, delete all types of resource records for a hosted zone.
Your DNS records are a crucial piece of the infrastructure puzzle, and misconfigured domains are a bit of a pain to debug, especially when changes are made to a working version rendering it unuseable. Ylastic gives you the ability to save and view changelogs for all changes made to a specific hosted zone. You can quickly view and review changes being made.
Ylastic also stores a complete audit trail for all the changes made to hosted zones and their associated resource records. You can go back and view a history which also includes the name of the user making the change as well as the IP address from where the change was made. You can use either a simple table based view or a graphical timeline based visualization of the audit trail.
We setup a domain while building and testing our Route 53 support, and it really was a breeze to setup the DNS. Kudos to AWS for a fantastic service. Here’s a sample output from a DiG query for our hosted zone.
There is a very cool new initiative from the wonderful folks at NPR called Project Argo - an effort to strengthen and foster local journalism. The Argo network consists of twelve of the largest NPR member stations around the United States bringing topical, locally focused news and analysis to an internet audience around the world. Argo is now live and running on AWS, and managed with Ylastic.
My formative years were spent in San Diego listening to KPBS which is one of the members in the Argo network. It is so coooool to see Ylastic being of use to them. Congratulations to Marc Lavallee and the other Argonauts !
So, last night SQS had an issue where some of the API calls were not working. How does something like that show up in your Ylastic dashboard?
The dashboard page displays icons for each of the AWS regions - green good, red bad. If you look at the screenshot below, you see a flashing red icon in the US East region in North Virginia.
Just click the red icon to display a visualization of your EC2/RDS instances in the US East region. At the top, there is a list of services in that region. Again, you will see SQS flashing red. Hmm, something wrong with the service? Hover over it to display the current issue with that service.
If you were monitoring instances, and an alert was triggered, the specific EC2/RDS instances will also be flashing red. Manage your cloud, the easy way !
EC2 block devices are really useful and we use them quite a bit over here at Ylastic. We have been improving support for specifying these mappings when you launch an EBS backed instance. Today’s Ylastic release makes it very easy to do a bunch of things.
Over-ride default block device mappings. For instance, if the AMI was created with a mapping like /dev/sda1=snap-xyz::True, you can modify it to change its default size or the delete on termination and specify it like this - /dev/sda1=snap-xyz:20:False.
Connect instance local storage when you launch an EBS backed instance. The instance local storage drives are available but by default EC2 will not connect them to the EBS instance. So when you launch the instance, specify how you would like to connect them. For Linux, you can specify a mapping like /dev/sdb=ephemeral0, and if you are using windows, just specify it as /dev/xvdg=ephemeral0. Keep in mind that the new t1.micro instances are EBS storage only, and you will not be able to connect local instance storage to them.
Specify multiple block device mappings at launch. As simple as can be. Just comma separate the device mappings and we will pass it on to EC2 when the instance is launched.
Here’s a screenshot of the stock Windows Server EBS version (ami-c3e40daa) launched from Ylastic and connecting the first ephemeral disk to device xvdg, which shows up as drive d: in Windows File Explorer.