Last week we kicked off a series covering the (data/storage/network) announcements that, in my view, had the most impact. This week I'm bringing 5 more recent launches to run through the fine-tooth comb. Description, the pain point it solved, and my critical take on each one.
1. Aurora DSQL lands in five more regions
What it is: Aurora DSQL, AWS's distributed, serverless SQL database, is now available in Asia Pacific (Hong Kong), Asia Pacific (Mumbai), Asia Pacific (Singapore), Europe (Stockholm), and South America (São Paulo). With this launch, it now covers 19 regions total.
Official link: https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-aurora-dsql-five-additional-aws-regions/
How it used to be (the pain point): Until now, if you wanted to run Aurora DSQL with decent latency for users in Brazil, there was no regional option here. You either accepted the latency of hitting us-east-1 (an ugly phrase for a transactional application to hear) or gave up on DSQL entirely and went with a traditional Aurora PostgreSQL, purely for geographic proximity.
My take: region expansion is the kind of announcement that isn't sexy, but it's what decides whether a service actually goes into production or stays a showcase item. With São Paulo on the list, the main adoption blocker for DSQL around here (latency) drops significantly. That said, it's worth remembering DSQL is still a relatively young product, with compatibility limitations against full PostgreSQL (extensions, certain data types, certain transactional features). Regional presence solves latency, it doesn't solve feature-set maturity. Those are two separate conversations.
2. Aurora DSQL gets a native PHP connector
What it is: launch of the Aurora DSQL connector for PHP (PDO_PGSQL), which handles IAM authentication natively: generates a token per connection, guarantees the valid token gets used, and keeps full compatibility with the PDO_PGSQL that the PHP ecosystem already knows. It also brings retry with exponential backoff for optimistic concurrency control (OCC), plus support for custom IAM credential providers.
Official link: https://aws.amazon.com/about-aws/whats-new/2026/04/aurora-dsql-connector-for-php/
How it used to be (the pain point): before this connector, authenticating a PHP application against Aurora DSQL via IAM was a hand-rolled hack: you had to orchestrate temporary token generation yourself, make sure it got renewed before expiring, and still handle retries for optimistic concurrency conflicts, which is a defining characteristic of distributed databases like DSQL. One mistake in that logic and your application starts silently dropping connections in production.
My take: this is AWS paying down technical debt it created itself by launching DSQL without mature language coverage. PHP still powers a massive slice of backend in the world (WordPress, Laravel, legacy systems at companies of every size), and not having an official connector was a clear signal that DSQL was born prioritizing Java, Python, and Go. Good to see the gap closed, but note that the connector solves authentication and retry, it doesn't solve DSQL's SQL compatibility limitations against traditional Postgres. If your PHP stack depends on a specific unsupported feature, the connector doesn't change that.
3. Amazon Quick integrates with New Relic for observability agents
What it is: Amazon Quick now talks to New Relic's AI agents via MCP (Model Context Protocol). You can investigate an incident, generate root cause analysis (RCA) with linked evidence, run NRQL queries in natural language, and trigger a triage runbook, all inside the Quick chat, without switching tools.
Official link: https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-quick-new-relic/
How it used to be (the pain point): investigating an incident today on any SRE or on-call team means opening five tabs: the observability dashboard, the runbook in the internal wiki, the alert history, the ticketing tool, and sometimes Slack too, just to check if someone already touched something. Every context switch is time lost during an incident, which is exactly the moment you have the least time to spare.
My take: this is an integration that makes sense for the right reason, reducing context switching during an incident is a real, measurable gain (genuinely lower MTTR, not just a sales slide number). The thing to watch is the dependency on the quality of the runbook and internal documentation Quick uses as context (the official announcement mentions this explicitly). If your internal knowledge base is bad or outdated, the agent will answer with the same bad quality, just faster. Generative AI on top of observability amplifies what you already have, it doesn't replace the operational maturity you're missing.
4. Amazon Quick gets Free and Plus plans
What it is: Amazon Quick now has two new entry-level plans, Free and Plus, with sign-up via personal email or social login (Google, Apple, GitHub, Amazon), no AWS account required. Guided onboarding promises to show value in under 5 minutes, with ready-made workflows for sales, marketing, finance, and operations.
Official link: https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-quick-free-plus/
How it used to be (the pain point): before this, Quick required an AWS account just to try it out, which is a real barrier for anyone who just wants to test a productivity assistant and doesn't want to deal with the console, billing, IAM, and the rest of the AWS apparatus just to see if the tool fits their needs.
My take: this is AWS playing in Copilot's, ChatGPT Team's, and similar tools' field, an end-user productivity product, not an infra engineer's tool. And it's a notable tone shift for a company that historically sells to people already inside its ecosystem. Makes sense strategically (land and expand: get in for free, use it, then convince the whole team to move to Professional or Enterprise). Just don't confuse this with an infrastructure product, it's a personal productivity tool disguised as an AWS announcement, and the evaluation bar is different here: usability and integration with everyday tools matter more than SLA and granular IAM in this case.
5. Valkey 9.0 lands in Amazon ElastiCache
What it is: ElastiCache now supports Valkey 9.0, bringing hybrid and real-time full-text search (on top of the already-existing vector similarity search), up to 40% more throughput on pipelined workloads, field-level expiration inside a hash (granular TTL), and support for multiple logical databases in cluster mode.
Official link: https://aws.amazon.com/about-aws/whats-new/2026/05/valkey-amazon-elasticache/
How it used to be (the pain point): anyone who needed full-text or hybrid search on top of a cache would normally run a separate search service (OpenSearch, for example) in parallel, with the full pain of syncing data between the cache and the search index. And without granular per-field TTL inside a hash, you had to manage expiration at the level of the entire key, forcing a coarser data model than ideal for multi-tenant use cases.
My take: Valkey keeps proving itself to be the right fork at the right time. Since becoming a Linux Foundation project after Redis's license change, it's been shipping relevant features fast, and this release combines vector search with full-text in the same cache engine, which is a real draw for AI workloads (RAG, for example) that today need to maintain cache and search as separate services. The skepticism here is around the project's long-term governance: Valkey is still young as a fork, and it's worth watching whether this pace of innovation holds up, or whether this is just the initial burst of post-Redis-split energy.
Sources: AWS What's New (official links in each section).
Top comments (0)