With the endless flood of new products, features and changes from AWS and its surrounding ecosystem, it can be easy to miss an update. Our monthly round up highlights major AWS news, announcements, product updates and behind the scenes changes we think are most relevant.

April continued its trend as the month AWS releases low-key features that you’ll use every day and take for granted.

IAM Access Analyzer

For a while now, IAM has supported showing when a role or access key was last used but not when a policy or action was last used. This makes it difficult to tell when a particular privilege is needed. Last year, AWS rolled out support for seeing when S3 bucket/object policies were last accessed, which was a bit of a tease. That has been expanded to include IAM, EC2 and Lambda–conveniently the 2nd, 3rd and 4th most over-permissioned resources in AWS (S3 wins the prize). This is incredibly useful, as you can continually refine your policies to only allow the actions that are actually being used.

To see this in action, go to any user, group, role or policy and click Access Advisor. You’ll see a list of services and when they were last accessed. For supported services, you’ll be able to click to see the actual actions that were invoked:

Even cooler than this is that you can go to the Permissions tab and click Generate Policy to create a sample policy that covers all recently used actions. Of course this needs to be handled with care, but it is a great way to create tight IAM policies. Coupled with monitoring for unauthorized CloudTrail events, it is possible to create very fine-grained access policies without meaningful overhead.

Read more about IAM Access Analyzer.

Warm Pools with EC2 Auto Scaling

EC2 Auto Scale Groups can now configure Warm Pools. Warm Pools are a great option for instances that take a long time to initialize. Warm Pools are also super simple to get started with. You can add a warm pool to an existing group, at which point EC2 will automatically have a pool of initialized, stopped instances running at all times. By default, the number of instances is the difference between the current desired size and max size of your ASG, though you can override this behavior with a “prepared” size. It’s important to remember that your warm pool instances will be stopped after provisioning, so your services will need to come up automatically on boot, along with any file mounts, etc.

When to use Warm Pools:

• When your instances initialize slow enough that you might not be able to scale out fast enough. In the past, you would have to have excess servers at any given time to deal with this, which adds to cost.
• When you can’t reduce the initialization time by baking that work into your image.
• When you aren’t using ephemeral storage on the instance in the initialization process.

The latter point is important to consider. Many steps can be automated using EC2 Image Builder (or tools like Packer). If you’re doing heavy lifting during instance provisioning, there’s a good chance that’s an anti-pattern.

Read more about Warm Pools.

CloudFormation (Finally) Supports “Latest” Version for Parameters

CloudFormation has allowed you to dynamically reference Parameter Store values since 2017, but you had to hardcode the version of the value you wanted–you couldn’t simply pull the latest version. As a result, this feature was crippled for storing secrets, dynamic parameters of any kind, and really anything that you were trying to avoid hardcoding in your stack.

Adding an improvement to existing functionality would not normally rate as a “featured story” for our Round Up, but in this case it does because as far as we’re concerned, dynamic referencing was useless at best and dangerous at worst due to this limitation. This is a huge win for building CloudFormation stacks with externalized configuration.

Miscellaneous News

• Public Parameters can now be queried. This announcement is both poorly named and undersold. AWS exposes a ton of useful things as public parameters in System Manager Parameter Store, and occasionally reference them in their documentation. There’s never been a way to catalog all of the public parameters available–and there’s a ton.
• AWS ElasticSearch now supports async queries. This is a neat feature that lets you run long-running queries in the background, but the bigger story here is the start of drift between the open source ElasticSearch and Amazon’s fork of it.
• EC2 Image Builder supports Auto Scaling launch template. EC2 Image Builder is incredibly useful but also very incomplete. We use it aggressively but also eagerly anticipate the day when it’s “feature complete” An example is how difficult it was to automatically update launch templates. Previously, Lambda, SNS and a lot of hard wiring was required. Now, you can automatically update launch template when new versions come out. Depending on your ASG’s launch policy, this may or may not cause automatic deployment of new instances so be sure you have the settings that make sense for your use case before using this.
• Announcing general availability of Amazon Redshift native JSON and semi-structured data support. Redshift now integrates native JSON query functionality. The most important thing to keep in mind about this feature is that you probably shouldn’t be using it. But it is neat.
• Amazon EC2 supports replacing root volumes. This is one of those features that we would’ve used a thousand times over the years if it were available. Every once in a while, a root volume gets hosed. Sometimes, it’s AWS’ fault (EBS volume corruption, etc). Sometimes, it’s your fault (fat fingers in auth config files). Either way, the time consuming dance required to fix the problem could take an hour or more. Now, you can do it without even rebooting the instance.
• AWS Patch Manager now supports reporting. AWS Patch Manager has been “almost useful” for years. With reporting, Patch Manager now deserves serious consideration as a way to handle patching in the cloud–and even on prem if needed.
• IAM can now tie events to corporate identities. For many who are using SSO solutions such as AWS SSO, ADFS or SAML, it can be difficult to precisely tie CloudTrail events to a specific user. You can now configure your SSO platform to specify the exact username, which will be logged (and searchable) in CloudTrail. Read the docs on Source Identity to learn more.
• VPC Flow Logs adds seamless Athena support. VPC Flow Logs, S3/ELB access logs and even CloudTrail logs can be incredibly difficult to search on. Athena has always provided a powerful search interface that can sit on top of the raw data in S3, but it can be intimidating (and manual) to configure. This can now be configured automatically for VPC Flow Logs, and we hope access logs are next in line.