On a near daily basis, AWS will release new services or new features for a service (see my previous article for methods to keep track of AWS updates and news. In the days preceding reInvent and during the event, the number of updates is just staggering. The goal of this post is to highlight how I deal with AWS services updates and new features.

1. Do I use the service?
If the update is for a service I currently use or am very familiar with, I will read the associated blog post to digest the news. I will imagine use cases where this new offering can be applied in my world. Don't get me wrong; there are plenty of updates released for services I am familiar with that I don't give much time to. Occasionally, a new update will catch my attention. If I find the service useful or it could have potential benefits for my project or team, I will take note of it and schedule time to perform a proof of concept (POC).

2. I don’t use the service or have never used the service
For updates to services I don’t use, I tend to read the headline, try to understand the update quickly, and mentally log it. I may not use the service now, but I might in the future (I’ve been saying this about SageMaker updates for a while now). For these sorts of updates, I feel it’s best to stay informed about what’s happening in a given area. You never know when a new requirement might make that small piece of knowledge relevant. Another colleague in your organization might also be working in this area, and you can share the information with them.

3. Announcing the new AWS Region
These are massive updates that always gather my attention. I usually wake up to these announcements, followed by a blog post from Jeff or a LinkedIn announcement from Matt. The latest new region is in Thailand. While it doesn’t impact me, it’s great news for folks running workloads in that part of the world. Keeping up with new region announcements is worthwhile—you never know when new requirements might land on your desk.

4. AWS announces new AWS Direct Connect location and expansion in
I usually brush these updates aside. Direct Connect—when will I ever work with that? Will I ever work with this service? It’s funny because, in the past few weeks, I’ve actually looked at this service for the first time. Again, these updates are useful for folks in or near the region where the expansion occurs.

5. Amazon/AWS is now available in the AWS Region
This is probably an update I overlook regularly. I do a lot of my work in us-east-1 and eu-west-1, which already have most services available (except Bedrock in eu-west-1). If a new feature or service is released by AWS, I usually assume it’s available in the regions I work in. Many folks, however, work in regions closer to them for latency, data sovereignty, or other reasons. Before committing to a service in your architecture, it’s important to verify that it’s available in your region.

6. is being deprecated by
These announcements don’t get much publicity. AWS used to pride itself on not deprecating services—SimpleDB held on like a cat dangling from a tree for years—but that’s no longer the case. Unfortunately, more services are being deprecated, and it’s just a question of which one is next. It crosses my mind now when choosing a service: Will this service still be around in a year with no deprecation warnings? If a service is constantly updated, I assume it’s safe from deprecation, but that’s not guaranteed.

We’ve heard the news—the service/feature is available in my region. Should I use it?
The answer is definitely: try it out, build, give it a go—but be prudent.

1. Don’t forget to remove resources after creation. You don’t want to be left with a huge bill for something you’re not using.
2. Does the service satisfy all your needs and edge cases? The last thing you want is to refactor your code to use a third-party service only to find it doesn’t cover all scenarios.
3. Are you okay with the pricing model for the service? Some services are pricey (I’m looking at you, DocumentDB and OpenSearch). Evaluate whether you’ll get full value from the service for the price.
4. Do you really need a net-new service? Could the problem you’re solving be addressed with a few extra lines of code? Costs need to be managed—just because a service exists doesn’t mean you have to use it.
5. What is the Infrastructure-as-Code (IaC) support like? Are there Terraform resources available for the service? Can you automate the resource lifecycle? If not, are you okay disrupting a fully IaC-covered architecture by introducing manual steps (a.k.a. “clickops”)? I’m not a fan of this, but it’s something to consider.

In conclusion:
This is how I evaluate new features and services. You might think I’m overly cautious, putting all my projects on micro EC2 instances and never trying new features. That’s not the case. When it comes to architecture, I believe simplicity is best. Avoid using technologies just for the sake of it. Every AWS release is designed to meet some customer demand. While it might not be what you need now, next week, or next year, it could still help your colleagues worldwide.

Happy building!