Onica’s Announcements At A Glance series analyzes the latest AWS news and announcements, simplifying and explaining the significance for AWS consumers.
The month of July was no disappointment in terms of new features and service announcements from AWS. There were many new announcements made at the AWS New York Summit 2019, as well as a steady stream of features and innovations through the normal channels. This blog highlights a few of the announcements that we feel could benefit the enterprise thought leader working to drive cloud adoption and efficiency within their organization. Some are helpful, some are vital, and some are just plain interesting. Let’s dive into looking at a way to clone Amazon Aurora databases cross-account or even cross-organization, how to roll out AWS Config rules globally to your organization member accounts from the Master organization account, a way to glue SaaS events to AWS-deployed applications and services, and an interesting new preview that leverages machine learning to find anomalies.
Amazon Aurora Cross-Account Cloning
So you need to implement a new feature into production for your application that is backed by Amazon Aurora. For development and testing, you’ll need a copy of the production Amazon Aurora database to be successful. You also work at the enterprise scale, so multi-account is a reality for you. How do you easily and quickly get a clone of the production database from production into your testing or development account, without disrupting production?
In July, AWS announced the ability to clone Amazon Aurora databases cross-account. The interesting thing is that the clone doesn’t have to be within the same AWS Organization! So while the example above is common, it is also a useful tool for those who need to share a production database with Data Science vendor for the training of a machine learning model on that production data, or any enterprise that needs to share their production Amazon Aurora database with another AWS account for any reason.
When sharing cross-account and cross-organization, the normal sharing constructs you’re used to seeing for cross-account authorization are in play. The share has to be requested or offered and then granted or accepted, leaving the account that owns the primary Amazon Aurora in control of all cloned access. There is no added data cost unless of course you make changes to the data in the clone. Or if the primary gets deleted, the cost gets spread evenly across existing clones. However, there are other important considerations that enterprises should be aware of. For instance, you can’t share or clone a clone, if the primary is encrypted, the clone has to be encrypted too, though a different key can be used, and other important considerations that can be found here: Amazon Aurora user guide.
Roll out AWS Config Rules to Your Entire Organization from the Master Account
A particularly helpful feature announced in July was the addition of a new set of APIs that allow enterprises to roll out AWS Config rules to the entire organization with one action in the Master account. You can also specify which accounts should not receive the AWS Config rules that you are rolling out. This is particularly useful when common AWS Config rules need to be enforced across an organization. You can also enforce governance by using the API calls from the organization’s master account, ensuring that member accounts don’t have the access to make changes to the AWS Config rules once deployed. These APIs work for both managed and custom AWS Config rules. The additional API calls are:
- PutOrganizationConfigRule
- DescribeOrganizationConfigRules
- GetOrganizationConfigRuleDetailedStatus
- DescribeOrganizationConfigRuleStatuses
- DeleteOrganizationConfigRule
To get started and learn more about the APIs mentioned above, click here: Enabling AWS Config Rules.
Amazon EventBridge – Serverless event bus
Stop me if you’ve heard this one before. A ticketing system, an incident response system, and a real-time monitoring system walk into a bar, or, uh, need to be integrated as SaaS offerings with applications hosted in AWS. If only there were an event bus that could build on the already powerful event processing model that forms the basis for Amazon CloudWatch Events that these SaaS offerings could publish events to for consumption in AWS. Enter Amazon EventBridge. The asynchronous model allows for complete decoupling and is independent of any specific communication protocol, runtime, or programming language.
In addition to the existing default event bus, a subscription to each partner application will create an event source that can be associated with an event bus in your AWS account. How about storing ticket data in Amazon Redshift? Or routing customer service inquiries to a machine learning model? The decoupled nature make the “bridge” between SaaS tools and AWS applications seamless. But won’t that get expensive? How about a modest $1 for every million events?
More information can be found in the announcement post: Amazon EventBridge.
Amazon CloudWatch Anomaly Detection
An interesting preview announcement in July was Amazon CloudWatch Anomaly Detection. The name really gives it away. Amazon CloudWatch Anomaly Detection applies machine learning to continuously analyze application and system metrics to establish a baseline. You can apply it to custom and service metrics in your account. The service will then establish what “normal” looks like and surface via Amazon CloudWatch Alarms any deviations from the norm for you to review. You can tune detection via data exclusion periods, sensitivity, and other parameters, and visualize the expected “normal” behavior on a graph. You can find pricing here, and enable Anomaly Detection via the AWS Management Console, AWS Command Line Interface, and AWS SDKs. It’s in preview in most regions.
You can dive deeper in the documentation here: Amazon CloudWatch Anomaly Detection.
To follow these updates and gain insights on how they can impact your business, subscribe to our blog!
