AWS Directory Service is a managed Microsoft Active Directory solution. Using this service, you can manage the identities for your organization, and by joining EC2 instances to your directory domain, authorize access to your AWS resources.
AWS Elastic Beanstalk is a deployment service for your web applications. By configuring your Elastic Beanstalk environment, AWS can manage the scaling and high-availability for your web application. Supported environments include NodeJS, Ruby, and .NET, among others.
If you have an existing .NET application, or are building one that utilizes “Windows Authentication”, you can deploy your application using Elastic Beanstalk, and use Directory Service as your Windows authentication directory.
Ideally, we would implement this combination using off-the-shelf Elastic Beanstalk AMI images. However, due to an issue with Elastic Beanstalk hostnames being re-used, we’ll need to create a custom AMI image to be used by our Elastic Beanstalk applications.
The custom AMI will only address the hostname issue. This way, once AWS fixes it on their end, the custom AMI can be done away with.
We have employed these techniques in our own internal applications and we wanted to share them with anyone else who wanted to do the same.
This article will walk you through these steps:
Today, we are excited to unveil Action Exclusions. Action Exclusions are a way to exclude certain AWS resources from being acted upon by Skeddly actions. This allows you to take a subset of your AWS resources out of Skeddly control for a short or long period of time.
For example, you can exclude an EC2 instance from being stopped by Skeddly for the next 12 hours.
Identity Federation is the ability to access Service Providers (such as Skeddly) using an existing Identity Provider (such as Active Directory Federation Services). It uses your existing users when accessing the Service’s resources, and eliminates the need to provision new user credentials for the Service Provider.
Today, we’re happy to announce that you can now use your existing SAML 2.0 compliant Identity Providers to access your Skeddly accounts.
For the second year, we’re excited to be sponsoring AWS re:Invent in Las Vegas.
Where: AWS re:Invent 2016, Booth #919
When: November 28 - December 2, 2016
This year’s event is expected to be bigger and better than last year’s. There is an entire extra day of sessions, a bigger expo, and the return of “reserved seating” (ooooooooh).
Skeddly will be at booth #919 in the expo hall not far from the main AWS booth. Stop by the booth to:
Skeddly includes an action called “Delete EBS Snapshots” which can be used to remove old EBS snapshots based on matching criteria and minimum age. It can also ensure that a minimum number of EBS snapshots are preserved.
Today, we’ve made two new enhancements to this action available:
Security groups are a fundamental building block of your AWS account. Using security groups, you can permit access to your instances for the right people. Misusing security groups, you can allow access to your databases for the wrong people.
Using Skeddly’s “Add EC2 Security Group Rule” action, you can automatically add and revoke security group rules based on your desired schedule.
For many AWS customers, Skeddly has become a cornerstone tool in reducing AWS costs. One key method they’re using to reduce their AWS costs is by stopping their EC2 instances at times when the EC2 instances are not needed. Using Skeddly’s reliable scheduling system, they can start the instances in the morning, and stop them in the evening.
Skeddly includes many actions that can be used to stop and restart your EC2 instances:
Any of these actions can be used to reduce your AWS costs. The actions you choose to use depend on your desired workflow.
Until now, if you wanted to both start and stop your EC2 instances with a single action, you would use one of the “Start” actions. However, what if your desired workflow were to stop the instance at key times. Using the “Start” actions may work, but they may not be the exact fit for your workflow.
We have enhanced our “Stop EC2 Instance” and “Stop Multiple EC2 Instances” actions to better fit some workflows.
Skeddly includes an action called “Delete EBS Snapshots” which can be used to delete old EBS snapshots. The snapshots that can be deleted can be selected based on their description, originating EBS volume ID, or resource tag. When the deletion process runs, snapshots can be preserved if they are younger than a desired snapshot age, and you can choose to preserve a minimum number of the most recent snapshots.
For example, you can choose to delete any snapshot older than 7 days, but preserve a minimum of 10 snapshots. This will preserve the 10 most recent EBS snapshots across all matching EBS snapshots.
But what if you want to preserve 5 snapshots from each of 2 projects? The 10 most recent snapshots may not be the 5 most recent snapshots from each of the 2 projects.
Many of our customers use Skeddly to managed multiple AWS accounts. Whether those are production vs. development accounts, accounts for multiple clients, or other single-purpose AWS accounts. For a while, Skeddly has included the ability to view monthly charges split by credentials. This allows you to see how the charges are distributed across different AWS accounts.
We have also heard from customers asking to view monthly charges split by action. Available now, you can view your monthly Skeddly charges split by action.
Amazon CloudTrail records a history of all API calls that occur in your AWS account. Whether operations are performed using the AWS Management Console, AWS CLI, or any of the various SDKs, Amazon CloudTrail will record details about the API calls.
Recording of action data is important for the following reasons: