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/.
Chaos Monkey is a tool built by Netflix that randomly terminates instances within your infrastructure. The reason for doing this is to help ensure that your applications continue to run in times of instance failures.
By introducing “automated failure” into your infrastructure, you are forcing your DevOps, IT, and developers to plan for failure. This is one of the key mantras of cloud computing. By forcing an instance failure at known and/or friendly times, your team can react if your application does not behave positively.
Recently, we announced a new action called “Terminate EC2 Instances”. Using this new action, you can easily implement your own version of Chaos Monkey. Today, we’ll walk you through this process.
We have created a new-and-improved version of our “Terminate EC2 Instance” action called “Terminate EC2 Instances”. This new action allows you to terminate multiple EC2 instances based on various matching criteria:
We have created a new-and-improved version of our “Reboot EC2 Instance” action called “Reboot EC2 Instances”. This new action allows you to reboot multiple EC2 instances based on various matching criteria:
Last year, Amazon announced that longer EC2 resource IDs were coming. Today, they are available and you can opt-in. In December 2016, they will be turned on for anyone who has not opted-in yet. More information can be seen in their official announcement: