For those of you who don’t know, Amazon Web Services allows you to change the EC2 instance type of your EC2 instances. This means that you can change your existing t2.micro to an m4.large if you want. This change can be accomplished using the AWS Management Console, the AWS CLI, or any of the AWS SDKs.
For many years, Skeddly has included the “Change EC2 Instance Type” action to automate this process. It’s a great way to lower your AWS costs, while keeping your EC2 instances available 24 hours a day. Many of our customers have had great success at lowering their AWS costs by changing the instance type of their EC2 instances at key times of the day or week.
Starting today, you are now able to reduce your AWS costs the same way but with an easier workflow.
Back in June, we announced our new Tag EBS Volumes action. Continuing with the theme of tagging, we’ve added a similar action for your EBS snapshots.
Amazon WorkSpaces is Amazon’s managed desktop service. Using Amazon WorkSpaces, you can have a cloud-managed Windows desktop available using clients for Windows, Mac, Linux and tablets. We use WorkSpaces for our development environments.
Today, we have two new actions available to help manage your Amazon WorkSpaces workspaces:
We have added a new action to our list of reporting actions: EC2 Instances Report.
You can use this action to select some or all of your EC2 instances, and generate a report of their configurations which is then emailed to you.
Resource tagging is an important strategy for managing your AWS accounts. By adding tags to your AWS resources, you can:
Most DevOps strategies utilizing AWS use resource tags extensively. Tagging is so important these days that Amazon has added a dedicated Resource Tag Editor in the main AWS Management Console.
EBS volumes are a difficult resource to keep tagged. While they support tagging, EBS volumes are often secondary resources to EC2 instances. Because of this, they often are left untagged. Check out your own list of EBS volumes in the AWS Management Console. How many of them have any tags at all?
Often, there comes a day when you’ve come across a killer SaaS or product that will work with your AWS account. It could be an automation tool (like Skeddly, a cost monitoring tool, a security tool, or any one of the many other products designed to work with your AWS account. Whatever the case, in order to read or modify information in your AWS account, you must provide credentials with which it will use to access your AWS account.
As a third-party vendor, we want you to be as safe with your AWS account as possible. So we’ve compiled some tips and best-practices to put in place when working with third-parties that are going to access your AWS account.
We’re excited to announce a new action in our ever-growing list of actions: Apply S3 Bucket Policy.
Using this new action, you can apply a bucket policy to one or more of your Amazon S3 buckets. The policy can be one of our built-in policies, or it can be a custom policy of your own. AWS has supplied many example bucket policies. Some examples include:
Today, we’ve made available an updated version of our “Update Auto Scaling Group” action. The updated version functions identically to the old version except that it can update multiple groups at the same time. The new action is called “Update Auto Scaling Groups” (note the plural version of “Group”).
Amazon Elastic Load Balancing is used to manage inbound TCP/IP connections and forward them to EC2 instances waiting to process the connections. Elastic Load Balancing provides a robust way to distribute traffic across multiple availability zones. Any number of EC2 instances can be used with your load balancer.
However, leaving an Elastic Load Balancer idle without any EC2 instances behind it, is simply wasting money. In the US East (Virginia) region, an unused Elastic Load Balancer will waste over $18 every month. You’ll waste over $24 a month in Sao Paulo.
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: