Today, we’re happy to announce two new enhancements to our “Create RDS Snapshot” action:
These new features allow you to automatically create, tag, and copy your RDS snapshots for a full disaster recovery strategy.
Amazon recently released the ability to add resource tags to your Redshift clusters and snapshots. More information can be read about this new feature on the Amazon Web Services blog:
Today, we are happy to say that Skeddly’s “Create Redshift Snapshot” action supports adding resource tags to your Redshift snapshots. Simply add the new tags names and values to your action configuration and the extra tags will be added to the new snapshots.
For quite some time, Skeddly has enabled you to create EBS snapshots and tag them according to your backup and disaster recovery strategies. Also, Skeddly has been able to copy EBS snapshots between AWS regions according to your schedule. But this was done separately from the creation process.
Today, we are happy to announce that these capabilities have been combined. When you create an EBS snapshot, you can now choose to have that new EBS snapshot automatically copied to another region. This further streamlines your ability to use Skeddly in your disaster recovery strategies.
AWS re:Invent is Amazon’s largest gathering of Amazon Web Services users, developers, and representatives.
I had the opportunity to attend last year’s event and it was very worthwhile. You get the opportunity to meet users of the AWS community, learn use-cases and best-practices from many companies, and even get certified.
If you will be attending AWS re:Invent this year and you would like to meet up with us, feel free to contact us and we can arrange a time during that week.
Today, Amazon announced the opening of a new AWS region in Germany. Please see the following blog post for more details about the new region.
We are happy to say that Skeddly now fully supports the new region as well. You can start and stop your EC2 instances, create and copy EBS snapshots, AMI images, and RDS snapshots. In addition, our unique Backup MySql Server action is supported.
If you have expanded your AWS accounts into the new EU (Frankfurt) region, Skeddly is right there with you.
Yes, we received that notice too. Amazon is rebooting many of it’s EC2 instances over the next few days. This is to apply some patches to the underlying host systems. There are some articles written with additional details it.
Unfortunately, the time windows in which the updates are going to happen are inconvenient to say the least.
Below are some tips that we have for minimizing the impact of this event.
We are introducing a new Service Level Agreement. In basic terms, our commitment to all of our customers is the following:
If we don’t deliver on our commitments, then any delayed action executions will be free. You can read the details on our Service Level Agreement page.
This new Service Level Agreement is effective starting September 1, 2014.
In addition, in an effort to be completely transparent, we have set up a system status page. Similar to the system status pages for many other products, like Amazon Web Services, ours will give the current status for our various components. You can see the history of the last few days. If an event occurs, information will be posted there.
Previously, we mentioned that there were errors when copying EBS snapshots from one region to another when using third-party IAM roles. More information about that can be found at the following post.
We are happy to say that the issue has been resolved and EBS snapshot copying is fully functional for both access key and role credentials.
Yesterday, Amazon announced support for the new T2 node types for ElastiCache. These node types are supported for both Memcache nodes and Redis nodes. More information about that announcement can be found at https://aws.amazon.com/blogs/aws/elasticache-t2-support/.
Today, we are happy to say that Skeddly supports these new T2 node types for our ElastiCache actions. So now you can schedule the creation and deletion of a t2.medium ElastiCache cluster.
We recently discovered that EBS snapshots will not copy correctly if the copy command was executed using a third-party IAM role. The issue does not exist if the copy command was executed using access keys. This problem appears to have started July 30, 2014.
The symptoms of the issue are that the copy initiates, a new snapshot is created in the new region, but the new snapshot results in an “error” status.
We are working with AWS support to get this issue resolved as quickly as possible.
Once the issue is resolved, we will notify our customers.
In the meantime, if you are using an IAM role for your “Copy EBS Snapshots” action, you can switch your action to use IAM access keys instead. This is not an ideal situation since IAM roles are preferred over access keys, but it will work-around the problem until it is resolved.