标签：#cloud

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 exponent

Cloudflare has migrated cdnjs, its open source CDN for JavaScript and CSS libraries, to its Developer Platform. The new architecture uses Workers, R2, KV, Workflows, Queues, Durable Objects and Containers, consolidating publishing and delivery infrastructure while preserving package contents, URLs and SRI hashes at a scale of 9 billion requests per day. By Leela Kumili

Someone in every company eventually says this out loud. Usually it's the CFO. Sometimes it's a VP of engineering, or the unlucky engineer who got handed "own our cloud costs" on top of their actual job. The bill comes in, it's up again, the spreadsheet has eleven tabs, and someone finally says: "Stop. I don't want another spreadsheet. I need one picture that shows where the money goes." It's a completely reasonable request. It's also strangely hard to satisfy with the tools most teams already have. This post is about why, where the money usually turns out to be going, and what that one picture actually looks like. The bill answers "how much". The question is "where" A cloud bill is a flat table — a very big one. An AWS Cost and Usage Report can run to millions of rows, and every row is precise: this resource, this hour, this rate. If your question is "how much did we spend on EC2 in July", the tools answer instantly. But "where does the money go" is a different kind of question. A dollar enters the company as one line on an invoice and then travels: through a provider, into an account, into some kind of resource, and finally — ideally — onto somebody's team. It's a path, not a number. Flat tables don't show paths. Native tools slice one dimension at a time. Cost Explorer will show you spend by service. Or by linked account. Or by one tag. Each view is true, and each view is a dead end, because the question in the meeting is always a path through several dimensions at once: which team's non-prod environments, in which account, are driving the compute growth? Answering that with one-dimensional views means six tabs and a join you perform in your head. The join in your head is where the meeting dies. So people fall back to the spreadsheet. Someone brave builds a pivot table; it's accurate for a week, then a re-org or a new account lands and it quietly becomes fiction that everyone still forwards. Where the money usually goes We look at a lot of cloud bills. The leaks a

Managed databases are the cloud cost line people quietly stop looking at. Compute gets rightsized, storage on the instances gets cleaned, but the RDS, Aurora, or Azure SQL bill just grows, because a database feels too load-bearing to touch. It is not. Here is how I have cut managed database spend without a maintenance window, in the order of least risk to most. The theme throughout: databases give you more no-downtime levers than people assume, and the biggest wins are usually storage and rightsizing, not some exotic re-architecture. Start with the free win: reclaim dead storage Storage is where the surprise terabytes hide, and most of it comes off with zero downtime. Drop what nobody reads. Old audit tables, soft-deleted rows that were never purged, expired sessions, staging data that got promoted to prod years ago. A DELETE in batches plus a purge job is the boring, safe first move. Reclaim space after deletes. On Postgres, deleted rows leave bloat until vacuumed. Run VACUUM (and check pg_stat_user_tables for dead tuples). On SQL Server / Azure SQL, rebuild or reorganize fragmented indexes to reclaim pages. This is where the "reclaimed terabytes" headlines actually come from. Kill redundant indexes. Unused and duplicate indexes cost storage and slow writes. Postgres pg_stat_user_indexes (look for idx_scan = 0 ) and SQL Server's missing/unused index DMVs tell you which ones earn their keep. Dropping an unused index is online. Right-size your storage type. On AWS, moving from gp2 to gp3 lets you provision IOPS and throughput independently and usually costs less for the same performance. The modify is applied without downtime. None of the above requires a window. It is pure hygiene, and on a neglected database it is often the single biggest line-item drop. Rightsize the instance (yes, without downtime) The reflex fear is that resizing a database means an outage. With a Multi-AZ deployment it usually does not. Check if you are oversized first. Pull 30 days of CPU, fre

KEDA 3.0 just landed, and the headline feature is the one I care about most as someone who watches a cloud bill: event-driven autoscaling now covers 80+ event sources (Kafka, RabbitMQ, and a long list more) with proper scale-to-zero. If you run workloads that sit idle most of the day and spike when work arrives, this is the difference between paying for capacity you use and paying for capacity that waits. I have been moving our intermittent workloads onto this pattern, so here is what scale-to-zero actually does to the bill, where it helps, and the sharp edges nobody mentions. The problem: HPA scales to one, not to zero Standard Horizontal Pod Autoscaler has a floor. minReplicas cannot be zero, so a workload that processes a queue twice a day still keeps at least one pod (and often the node under it) running 24/7. For a consumer that is busy 2 hours a day, you are paying for 22 hours of nothing. KEDA changes the shape of the question. Instead of "how many replicas does current CPU justify," it asks "are there events waiting." No events, zero pods. Events arrive, it scales from zero up to whatever the load needs. That floor of zero is the whole game for intermittent work. Where scale-to-zero actually pays off Not every workload benefits. The ones that do share a profile: bursty, event-triggered, and tolerant of a short cold start. In our environment the clear wins were: Queue consumers. A worker draining an SQS or RabbitMQ queue that fills a few times a day. Idle 80%+ of the time, now scales to zero between bursts. Kafka stream processors for low-volume topics that only see traffic during business hours. Scheduled batch jobs dressed up as long-running services because nobody wanted to re-architect them. Scale-to-zero gets most of the savings without the rewrite. Dev and staging consumers that had no reason to run overnight and did anyway. A rough sizing rule I use: if a workload is idle more than half the day and an extra few seconds of latency on the first event is

Anthropic conducted an audit of 141006 evaluation runs after OpenAI's sandbox escape disclosure. The review identified three incidents where Claude models accessed the internet due to misconfigurations. These incidents involved unauthorised attacks on live targets. Anthropic has suspended offensive evaluations and plans to enhance security measures and collaborate with external auditors. By Olimpiu Pop

If you have ever wanted to ship an AI-powered application without managing GPUs, model servers, or scaling infrastructure yourself, this guide is for you. Managed inference simply means letting a cloud provider run the AI model for you: you send a request, the platform handles the compute, and you get a response back. On Google Cloud, the cleanest way to do this today is to pair the Gemini Enterprise Agent Platform (formerly Vertex AI) with Google Cloud Run , dividing responsibilities between the two services. The Agent Platform serves as the orchestration and intelligence engine, while Cloud Run hosts your custom application logic, front-end UIs, or Model Context Protocol (MCP) servers. By the end of this article, you will be able to: Explain the hybrid architecture and why each layer exists Define an AI agent in code using the Agent Development Kit (ADK) Deploy your app layer to Cloud Run with a single command Choose between online and batch inference for your workload Secure and monitor the whole setup in production New to the underlying concept? Start with Google Cloud's primer: What is AI inference? Prerequisites To follow along hands-on, you will need: A Google Cloud project with billing enabled The gcloud CLI installed and authenticated Python 3.10+ and the ADK installed ( pip install google-adk ) You can also read this purely as an architecture walkthrough; every step is explained, not just shown. 1. The Architectural Blueprint This pattern splits your system into independent, auto-scaling tiers: [ Client / Web UI ] ──> [ Cloud Run Service ] (App Logic / Tool Front End) │ ▼ [ Gemini Enterprise Agent Platform — Agent Runtime ] (Orchestration, Intent Analysis, Memory) │ ▼ [ Managed Inference / Model Garden ] (Gemini 3.x Pro / Flash models) Why split it this way? Each tier scales independently and fails independently. Your web front end can handle a traffic spike without touching the model layer, and you can swap models without redeploying your application code

Netflix migrated most of its batch workloads onto Kueue, an open-source cloud-native batch job execution system that has outgrown its homegrown solution over the years. The company mapped the capabilities previously created in-house to Kueue’s functionality and also benefited from new features that would have been costly to incorporate into its homegrown solution. By Rafał Gancarz

Spotify introduced external indexing architecture for Apache Parquet data lakes that enables low-latency point queries without replicating datasets into operational databases. The approach maps lookup keys to Parquet files and row locations, allowing targeted reads from cloud object storage while supporting analytics, machine learning, AI applications, and online services from the same datasets. By Leela Kumili

✓ Human-authored analysis; AI used for formatting and proofreading. SadCloud is an open-source Terraform project by NCC Group that deploys misconfigured AWS resources. Security teams use it to test their tooling: if your scanner can't find the misconfigurations in SadCloud, it can't find them in production. We pointed Stave at SadCloud. Then at BishopFox's IAM Vulnerable. A lab focused on IAM privilege escalation paths. The numbers tell a story about what happens when you move from per-resource scanning to compound attack path analysis. The raw numbers Metric SadCloud (NCC Group) IAM Vulnerable (BishopFox) Assets evaluated 36 31 Atomic violations 992 837 Compound chains firing 84 instances (13 unique) 70 instances (6 unique) Near-miss chains 785 instances (40 unique) — A per-resource scanner (Prowler, ScoutSuite, Checkov) would show 992 findings for SadCloud. Each finding stands alone: this bucket is public, this role is overpermissioned, this trail isn't logging. The operator opens a dashboard with 992 items sorted by severity and starts scrolling. Stave's compound-only default output shows 84 findings across 13 named attack paths. Same underlying data. Different composition. The 992 atomic violations still evaluated. They're the detection infrastructure. The 84 compound chains are the findings that reach the operator. That's a 12x reduction by composition. Compound chains Each compound chain fires when multiple controls fail simultaneously on related assets, matching a named attack pattern: Chain Severity Instances What it means iam_escalation_undetected critical 36 IAM roles can escalate privileges and no detective control monitors the escalation path iam_boundary_governance_failure critical 36 No permission boundary constrains IAM principals in the account — any role can reach any resource iam_session_opacity high 2 IAM session activity isn't logged at the detail level needed to detect credential abuse s3_ssec_ransomware_path critical 1 S3 bucket is vulnerable t

In this episode of the podcast, members of the InfoQ editorial staff and friends of InfoQ will discuss current trends in the cloud and DevOps domains as part of our annual trends report. These reports provide InfoQ readers with a high-level overview of key topics to watch. This podcast offers a chance to hear our raw conversation and the stories shared by our expert practitioners. By Daniel Bryant, Matt Saunders, Shweta Vohra, Steef-Jan Wiggers, Mark Silvester

InfoQ editorial staff and friends of InfoQ are discussing the current trends in the domain of Cloud and DevOps as part of the process of creating our annual 2026 trends report. By Steef-Jan Wiggers, Matt Saunders, Shweta Vohra, Daniel Bryant, Mark Silvester

The MCP 2026-07-28 specification removes the initialize handshake and session header, and adds required method and tool-name headers so gateways can route agent traffic without parsing JSON. Reaction split between developers calling it a rediscovery of REST and those arguing the standard itself was always the point. By Steef-Jan Wiggers

IBM and Red Hat have announced an expansion of Lightwell, introducing new commercial offerings designed to help organizations establish trusted, verifiable software supply chains for the age of AI-assisted software development. By Craig Risi

A reminder of the perils of digital ownership.

Cloudflare announced a developer preview that lets any website enable a WebMCP (Web Model Context Protocol) interface with a single dashboard switch. This allows browser-based AI agents to interact with unmodified web pages through structured tools instead of scraping or guessing, keeping human traffic and control on the original site. By Sergio De Simone

Canva redesigned session revocation infrastructure to support 100M active sessions while reducing database lookups. The architecture uses Amazon S3 for durable revocation records and distributes compact, in-memory indexes to application gateways. Canva said the design improved deployment speed, reduced database infrastructure requirements, and cut the revocation cache memory footprint by 87.5%. By Leela Kumili

Pinterest has revealed the Resource Provisioner Pipeline (RPP), its own Terraform execution engine. It ensures least-privilege access and needs dual-control reviews. This is important for the company’s AWS infrastructure, as it adds strict guardrails to the GitHub Actions workflows. By Claudio Masolo

Cloud Native Buildpacks, which graduated within the CNCF in July 2026, move base image choice out of per-service Dockerfiles into a single builder owned by platform engineering, enabling fleet-wide patching. BellSoft's hardened Paketo builder is the latest sign that vendors now treat the builder, not the Dockerfile, as the container security control point. By Mark Silvester

AWS launched Dogwood this week — an open-source policy language (Apache 2.0) for AI agent runtime verification. It extends Cedar, AWS's existing authorization language (now a CNCF sandbox project), with something Cedar fundamentally can't do: reason about sequences of actions over time. "Point-in-time decisions make sense for many forms of access control, but when agents compose multiple actions into longer workflows, the sequence itself becomes something teams want to govern." That's the gap Dogwood fills. What Cedar couldn't do Cedar is stateless. You give it a request — principal, action, resource, parameters — and it returns allow or deny. Given the same request, Cedar always returns the same answer, regardless of what happened five minutes ago. That's a useful property for analysis, but it's a blind spot for agents. Consider: an agent is restricted to transferring no more than $5,000 per hour. If Cedar only evaluates the current request against completed transfers, the agent can fire off three concurrent $2,000 requests before any of them finish. Each looks fine in isolation. The total blows the limit. Dogwood has the event history. It counts all transfer requests — including those currently in-flight — so the third $2,000 request gets denied even before the first two complete. What Dogwood adds Dogwood introduces temporal conditions that examine earlier tool calls and their results. You can: Check whether an event occurred — e.g., was approval granted for this exact stock/quantity in the last hour? Count calls in a time window — rate limiting across concurrent requests Count distinct values — e.g., how many unique payment recipients this session Sum values — total transferred, total refunded The stock trading example from AWS is the clearest illustration: an agent may only sell shares if an approval tool returned a positive response for that stock and share count within the previous hour. That approval is a separate event the policy engine finds in the agent's