1 - Amazon S3 Files: now your bucket doubles as a file system
S3 Files simulates an S3 bucket as a file system, with full file system semantics and low latency, without you having to pull the data out of S3 to make that happen. Under the hood, it's built on top of Amazon EFS, so you get the performance and simplicity of a file system combined with the durability and cost profile of S3.
Official link: https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-s3-files/
What pain does it solve? If your company stores data in S3 (which is basically everyone, since it's the default market data lake), but has some tool, pipeline, or agent that only speaks file system (POSIX mount, not the S3 API), your options used to be: duplicate the data into an EFS or FSx and keep the two painfully in sync by hand, or rewrite the tool to talk to the S3 API. Both of those generate operational overhead, doubled storage costs, and a sync headache nobody wants to carry into production.
Bonus tip: S3 still isn't actually a file system. Even simulating/translating POSIX, it won't treat data as block storage. So use this technique with some restraint, since it can generate extra costs from GET and LIST calls.
2 - S3 Account Regional Namespaces: goodbye bucket-name fights
You can now create general purpose S3 buckets inside a reserved namespace scoped to your account, per region. This eliminates the need for a globally unique bucket name, which used to be a frustrating limitation.
Official link: https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-account-regional-namespaces/
What pain does it solve? Anyone who's ever tried to create a bucket named something obvious like logs-prod knows the frustration of getting hit with "name already exists." That happens because bucket namespace was global across every AWS account on the planet. This became a real problem in multi-tenant architectures, where you need to spin up a bucket per client or per team in an automated way. Your only options were inventing a hash or UUID naming scheme to guarantee uniqueness, or just hoping nobody had already grabbed the name.
3 - Database Savings Plans now covers OpenSearch Service and Neptune Analytics
Launched at re:Invent 2025, Database Savings Plans, which already covered RDS and Aurora, now also includes Amazon OpenSearch Service and Amazon Neptune Analytics. You commit to an hourly spend ($/hour) for a year, no upfront payment, and get a discount of up to 35%.
Official link: https://aws.amazon.com/about-aws/whats-new/2026/03/dbsp-opensearch-service-neptune-analytics/
What pain does it solve? If your search or graph workload ran on OpenSearch or Neptune Analytics, your only savings lever was a Reserved Instance tied to a specific instance family. That could be a real limiter, or even a dealbreaker, for anyone who needs to scale or switch instance types as load changes (which happens constantly in a search cluster), because you'd lose the discount the moment you migrated.
Top comments (0)