AWS CodeDeploy is a deployment management service offered by AWS. You can use it to deploy updates of your applications to your EC2 instances, Lambda functions, and on-premises servers. This can be a powerful tool in your CI/CD pipeline.
Today, I’m happy to announce a new action: Deploy CodeDeploy Application.
As your AWS usage grows, so will your stockpile of EBS snapshots and AMI images. Many of these are used for backups, while others are used to launch EC2 instances from Auto Scaling groups and EC2 launch templates.
As your collection of AMI images grows, you will need to start rotating out the old AMI images. However, in your zeal to delete old AMI images, if such an image is deleted while it’s being used by an Auto Scaling group, that Auto Scaling group won’t be able to launch a new EC2 instance should it need to scale up.
Today, we’ve added a new option to our “Deregister AMI Images” action: “Preserve Referenced Images”.
Today, we’re excited to announce support for Google Cloud Platform. Now, you can manage your Google Compute Engine virtual machine instances using the same advanced scheduling options already available in Skeddly.
Start and stop your VM instances to reduce your cloud costs.
Create and delete disk snapshots to implement your organization’s disaster recovery strategy.
Today, four new actions have been added:
When creating EBS snapshots, it’s important that the snapshots be “consistent”. This means that the data on the snapshot is whole and complete. An EBS snapshot can be considered “inconsistent” if not all data was flushed to the filesystem, and/or if an application running on the EC2 instance was mid-write when the EBS snapshot was initiated.
AWS recommends pausing all writes to the filesystem, and if that’s not possible, unmounting the volume from your EC2 instance when creating the EBS snapshot. However, that’s not possible for root EBS volumes.
For many years, Skeddly has included a “Stop Instance” consistency method when creating EBS snapshots. Stopping the EC2 instance is another way to ensure all data written to the EBS volume is flushed to the hardware. With this option enabled, Skeddly briefly shuts down the EC2 instance, initiates the EBS snapshot, then restarts the EC2 instance. Usually, the EC2 instance is stopped for only a minute or so. But, in some cases, even this brief moment of unavailability is not allowed.
If you are using Windows, you can use a feature called Volume Shadow Copy, or VSS for short, to help create consistent snapshots. AWS has an SSM document in AWS Systems Manager that you can use to create VSS-Enabled EBS snaphots.
Today, we’re making available a VSS option to our EBS snapshot actions that you can use to automate the creation of VSS-enabled EBS snapshots.
One difficult task for the AWS account administrator is to keep track of used and unused resources. That’s why we’re adding more actions to help track down unused resources.
Today, we’re happy to announce a new action: Delete Unused Elastic IP Addresses.
This week was very exciting at AWS re:Invent. There were many, many new services announced. One new service that was announced is called AWS Transfer for SFTP.
AWS Transfer for SFTP allows you to setup a managed SFTP server which will upload and download files to Amazon S3, using the SFTP protocol. This is a great way to transfer files in to and out of Amazon S3 using standard tools.
However, running an SFTP server can be expensive. In the Virginia region (us-east-1), the SFTP server costs $0.30 per hour to keep running. Data transferred is charged on top of that. The nice part: SFTP servers can be started and stopped. I think you can see where I’m going with this.
Today, I’m happy to announce a new action that has been added to Skeddly: Start Transfer for SFTP Servers.
This week is AWS re:Invent 2018. For the 7th time, it’s bigger than ever, spanning 7 hotels: The Venetian, The Mirage, Encore, Aria, MGM Grand, Bellagio, and Vdara. So plan your transitions well, make sure you have some good walking shoes, and take the AWS shuttles between hotels.
Like previous years, you’ll notice different coloured lanyards holding everyone’s badges. Here’s an updated list.
Last week, AWS announced a fantastic new feature for AWS CloudFormation, CloudFormation Drift Detection. Drift detection allows you to determine whether the AWS resources controlled by your CloudFormation stacks have drifted from their original configuration. This can happen if you manually adjust properties of your AWS resources.
Today, we’re excited to announce a new action to report on your CloudFormation drifted stacks: CloudFormation Stack Drift Report.
Still referencing Best Practices for Managing AWS Access Keys, best practices recommends that root access keys are never used and should be completely removed from your AWS account. Instead, IAM users with limited permissions should be used.
In fact, Skeddly even prevents root access keys from being registered with Skeddly. We always recommend using IAM third-party roles, however, access keys can still be used. And we only allow IAM user access keys to be registered.
Today, we’re happy to announce a new action to monitor for root access keys: Check Root Access Keys.
According to Best Practices for Managing AWS Access Keys, if you must utilize IAM access keys, it is best to remove or disable unused keys. This will close possible security holes in your AWS account.
Today, we’re happy to announce a new action to help with this task: Disable Unused IAM Access Keys.