Category: OpsWorks

AWS CloudTrail records the API calls made in your AWS account and publishes the resulting log files to an Amazon S3 bucket in JSON format, with optional notification to an Amazon SNS topic each time a file is published.

Today I’m writing to provide you with more information on new releases from CloudTrail and to share some really cool tools and use cases that have been implemented by some of the CloudTrail Partners.

Regional Expansion
Effective immediately, CloudTrail is now available in three more AWS Regions. Here is the complete list:

• US East (Northern Virginia)
• US West (Northern California)
• US West (Oregon)
• Asia Pacific (Sydney)
• EU (Ireland)
• Asia Pacific (Tokyo) – New!
• Asia Pacific (Singapore) – New!
• South America (So Paulo) – New!

The Big Picture, Once More
Here’s the latest and greatest version of the diagram that I first presented when we launched CloudTrail:

As you can see, CloudTrail can now record API calls made by eighteen AWS services! Earlier this month, we quietly added support for Amazon CloudFront and AWS CloudTrail.

Logentries and CloudTrail
Logentries is designed to make business insights from machine-generated log data easily accessible to development, IT, and business operations teams of all sizes. The Logentries architecture is designed to manage and provide insights into huge amounts of data across their diverse, global user community. You can sign up for a free Logentries trial and be up and running within minutes.

The Logentries team shared a cool, security-oriented use case that is made possible by their integration with AWS CloudTrail (read the Logentries CloudTrail Integration Documentation to learn more). Logentries provides pre-defined queries for important events so that you do not have to write complex queries. Additionally, Logentries provides out of the box tagging and alerting to highlight and notify you when an important security event takes place. For example, you can get notified via email or iPhone alert or you can have a message sent to a third-party service or API such as Pagerduty, Hipchat, or Campfire when any of the following occur:

• EC2 Security Group created, deleted, or edited
• New IAM user is created
• User’s IAM permissions are changed

Here is a screenshot of the alerts that Logentries provides out of the box:

And here’s a short video of Logentries in action:

Datadog and CloudTrail
Datadog is a cloud monitoring service for IT, operations and development teams who run applications at scale. Datadog allows users to quickly troubleshoot availability and performance issues by automatically correlating change events and performance metrics from AWS CloudTrail, AWS Cloudwatch and many other sources.

Datadog can overlay CloudTrail logs with metric collected from other systems to show how the metrics respond to AWS events. This allows you to investigate and understand cause and effect relationships.

Datadog can quickly find specific CloudTrail events and put them in context for you. You can collaborate with teammates using threaded discussions that are linked to CloudTrail logs:

— Jeff;

AWS OpsWorks is an application management service. You define your application as a set of layers within a stack. Each stack provides information about the packages to be installed and configured, and can also provision any necessary AWS resources, as defined within a particular OpsWorks Layer. OpsWorks also scales your application as needed, driven by workload or on a predefined schedule.

The Amazon Relational Database Service (RDS) takes care of all of the tedious, low-level system and database management work that you would end up doing yourself if you were hoping to use MySQL, Oracle Database, SQL Server, or PostgreSQL. You can let RDS handle the hardware provisioning, the operating system and database installation, setup, and patching, scaling, backups, fault detection and failover, and much more.

Today we are marrying OpsWorks and RDS, giving you the ability to define and use an RDS Service Layer to refer to an RDS database instance that you have already created within the AWS Region that serves as home to the OpsWorks stack for your application. This is in addition to the existing OpsWorks support for MySQL layers.

You can define an RDS Server Layer from within the AWS Management Console like this:

You will need to know the user name and password for the database instance in order to create the RDS Service Layer (this information is passed along to the application). You can always edit the layer later if you don’t have this information handy or if you change the user name and/or password in the future.

Note: Because all OpsWorks stacks access AWS resources and services through an IAM (Identity and Access Management) role, you may need to update the role accordingly. OpsWorks will detect this situation and offer to address it.

After you add the RDS Service Layer to the stack, OpsWorks will assign it an ID and add information about the database instance to the stack configuration and to the deployment JSON, where it can be accessed through the [:database] attribute. OpsWorks also provides helper functions to provide access to the connection details when used in conjunction with the Ruby, PHP, and Java application server layers.

As usual, this new feature is available now and you can start using it today. Consult the Database Layers section of the OpsWorks User Guide to learn more.

— Jeff;