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