Skeddly Blog

Skeddly news and announcements...

Manage Azure Disk Snapshots With Skeddly

Now that we’re all saving money on our Azure bills, it’s time to backup those Azure VM disks. Skeddly now supports the creation and deletion of Azure disk snapshots with our two new actions:

  • Backup Virtual Machines
  • Delete Disk Snapshots

Both of these actions work like their AWS counterparts.


Post Action Execution Triggers

Now you can trigger events when your action executions complete. This new feature gives you more flexibility and options when it comes to your action executions.

With post-execution triggers, more advanced workflows are now possible:

  • Chain actions together
  • Start or stop multiple resources in a given sequence
  • Execute a second function in response to a failed action execution, perhaps as a form of extra notification or recovery
  • Invoke an Amazon Lambda function to do anything else we haven’t thought of


Skeddly Now Supports Microsoft Azure

For 7 years, AWS users have been using Skeddly to lower their AWS bills by starting & stopping EC2 and RDS instances, along with Redshift and ElastiCache clusters. Now, Azure users can join the party too.

Today, we’re adding support for Microsoft Azure by adding two new actions:

  • Start Virtual Machines
  • Stop Virtual Machines

These are our first actions for Azure, launching our foray into multi-cloud management.

Similar to our actions for AWS, our Azure actions can start and stop your virtual machines in order to reduce your cloud costs. Used strategically, these can be used to reduce your Azure bills by up to 65%.


Start AppStream Fleets Action

Today, we’re adding support for another AWS service to Skeddly: Amazon AppStream 2.0.

Amazon AppStream is a service provided by Amazon Web Services that allows you to stream desktop applications through a web browser. Applications run on the Amazon servers, and you interact with the applications through your web browser.

Amazon AppStream is often forgotten when it comes to cost-saving strategies. Many times, these applications are line-of-business applications that only need to be available during business hours, Monday through Friday.

Today, we’re helping you achieve those cost savings by adding a new action: Start AppStream Fleets.


New Coverage Reports

Today we’re happy to announce two new reports available to Skeddly users:

  • Backup Coverage Report
  • Start/Stop Coverage Report

Both of these reports will cross-reference resources in your AWS account against actions in your Skeddly account to determine how “covered” you are.


AWS Secrets Manager

Last week, at the AWS Summit San Francisco, AWS unveiled the new AWS Secrets Manager service. This new service allows you to:

  • Save your secrets, passwords, and API keys in a KMS-encrypted storage service,
  • Retrieve your secrets from your applications using the AWS CLI and AWS SDKs, and
  • Automatically rotate your secrets on a custom schedule.

This service enables you to avoid storing database credentials and other secrets in configuration files on your servers. Secrets can be retrieved and used dynamically.

It’s basically doing for any secret what “IAM Roles for EC2 Instances” did for IAM access keys.

But the real power of the AWS Secrets Manager comes from the automated rotation. This allows you to change your passwords every 30 days (for example).


Longer Resource IDs for Amazon EC2

Back in 2016, AWS extended the resource ID length from 8 characters to 17 characters. Back then, this change applied to EC2 instances, EBS snapshots, EBS volumes, and EC2 instance reservation IDs.

Now they’re doing it again with the remainder of EC2 resource types, such as:

  • AMI images
  • Security groups,
  • VPCs,
  • Subnets,
  • Route tables,
  • Network interfaces,
  • VPN connections,
  • Internet gateways,
  • and many more.

For example, short AMI image IDs are like ami-12345678 and long AMI image IDs are like ami-12345678901234567.

Here’s what you need to know about the longer resource IDs and their impact.


Copying RDS Snapshots Between Regions

In our previous posts, I showed you how to copy your DB and Aurora snapshots to ensure they are preserved beyond the lifetime of your RDS instance. However, those copies were simply second copies in the same region as the original

In this post, I’ll show you how to copy your RDS snapshots to a second region for extra protection. Please note that I will restrict this post to unencrypted snapshots. Copying encrypted snapshots is more involved, so I’ll show that in a separate post.


Encrypting an Unencrypted RDS Snapshot

RDS snapshots can be unencrypted or they can be encrypted at rest. Today, best practice is to use encryption-at-rest on your RDS instances and clusters, and to encrypt your RDS snapshots.

When you create an RDS snapshot from an RDS instance or cluster, the resulting snapshot will be encrypted if the source instance or cluster is encrypted. But if the source is not encrypted, then your RDS snapshot is not encrypted. When you create an RDS snapshot, you are not given the option to encrypt it.

However, when you copy an RDS snapshot, you can add or change the KMS keys used. So, if you have an unencrypted RDS snapshot that you want to encrypt, you can encrypt it by copying it, encrypting it along the way.


RDS DB and Cluster Snapshots

Amazon RDS is an ever growing service. It includes many database engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server, and Aurora. However, not all database snapshots are treated equally.