Amazon CloudWatch alarms are a powerful tool used to receive alerts when CloudWatch metrics meet or pass certain thresholds. For example, you can create a CloudWatch alarm that will trigger when an RDS instance’s available storage falls below 10%.
Sometimes, when AWS resources are deleted, old CloudWatch alarms may remain around. This causes two problems:
Skeddly has allowed you to add additional users to your Skeddly account for a while now. This allows you, as a Skeddly administrator, to give other members of your organization access to your Skeddly account.
And starting today:
We have added two new options to our “Copy AMI Images” action:
Copy Image Permissions
Launch permissions can be added to an AMI image to allow other AWS accounts to launch EC2 instances from your AMI image. If you have added launch permissions to your AMI, then those permissions can be copied to the target AMI image with this option enabled.
Copy Snapshot Permissions
Similarly, “Create Volume” permissions can be added to EBS snapshots that allow other AWS accounts access to EBS snapshots. If you have added permissions to the EBS snapshots associated with your AMI images, then those permissions can be copied to the target snapshots.
For many years, Skeddly has included a very powerful action: Stop Multiple EC2 Instances. Using this action, you can stop EC2 instances at a pre-defined time. Instances to be stopped can be selected based on different criteria:
For example, you can stop all EC2 instances each night. Or, you can stop specific EC2 instances based on their EC2 instance ID. Or you can stop EC2 instances that match specific EC2 tags.
With each Skeddly account, you have the ability to create an unlimited number of sub-users. This allows you to give access to your Skeddly account to additional members of your organization.
Starting now, you can also give your Skeddly account an alias, or “name”, that is displayed on the navigation bar.
AWS Elastic Beanstalk is a managed service for deploying your web-based applications. You can use many different development environments with Elastic Beanstalk: Node.js, PHP, Java, Ruby, .NET, and even Docker. Under the hood, AWS Elastic Beanstalk used CloudFormation, EC2, Auto Scaling, and Elastic Load Balancer to manage your web applications.
Elastic Beanstalk will store and maintain different application versions for you. So when you deploy a new version of your application, the old versions are maintained for easy roll-back. However, there is a limit of 500 versions (by default) per region per AWS account. Many Elastic Beanstalk users hit the limit and must delete old versions before new versions can be deployed. This must be done manually, or you must build it into your automated deployment process. Keeping older versions unnecessarily also bears a storage cost because the versions are stored in Amazon S3.
As actions execute, being notified of their success or failure could be critical. For example, if AMI images failed to be created, then you should be notified as soon as possible so that corrective action can be taken.
Until today, Skeddly included 3 ways to be notified:
Today, we’re happy to announce that we’ve expanded our notification options.
Scheduled Reserved Instances are a new feature of AWS where you can make a reserved instance purchased based on a recurring schedule rather than 24 hours a day for an entire year. An example where this may be useful could be an application that processes data for 4 hours each Saturday. Using Scheduled Reserved Instances, you can reserve an EC2 instance to run for 4 hours each Saturday. Because you’ve reserved it, it’s
The announcement from AWS about Scheduled Reserved Instances can be found here: https://aws.amazon.com/blogs/aws/new-scheduled-reserved-instances/.