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:
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.