Author: Steef-Jan Wiggers

Google Cloud has recently introduced a new feature, Cloud Storage bucket relocation, designed to simplify the process of moving data buckets to different geographical locations without disrupting applications significantly.

The way this feature works is that the name of the bucket and all associated object metadata will remain unchanged during the relocation process. This means there will be no alterations to paths, ensuring that applications experience minimal downtime while the storage is being moved. Additionally, the objects will retain their original storage class (such as Standard, Nearline, Coldline, or Archive) and will keep their time-in-class in the new location. This meticulous preservation is crucial for maintaining established data governance, ensuring the continued operation of object lifecycle management rules, and simplifying application integration, as no changes to access paths or configurations are required after migration.

The new bucket relocation capability is integrated within Google Cloud’s Storage Intelligence suite, working alongside tools like Storage Insights, which offer deep visibility into storage landscapes and identify optimization opportunities. Vaibhav Khunger, a senior product manager, Google Cloud, explains the synergy:

Bucket relocation then lets you act on these insights, and move your data between diverse Cloud Storage locations — regional locations for low latency, dual-regions for high availability and disaster recovery, or multi-regions for global accessibility.

Bucket relocation employs two key techniques: asynchronous data copy and metadata preservation. The asynchronous data copy enables data transfer in the background, minimizing disruptions to ongoing operations such as writing, reading, and updating. On the other hand, Metadata preservation ensures that all associated information, including storage class, bucket, and object names, timestamps, access control permissions, and custom metadata, is seamlessly transferred without alteration. This approach reduces risks and overhead typically involved in manual migrations, allowing applications to function without modifications, as the bucket name remains unchanged throughout the process.

Abdel Shiouar, a Google senior cloud developer advocate, comments on LinkedIn:

While Google Cloud Storage had a transfer service for a while, it did not help moving and preserving some metadata (lifecycle for example). The relocation feature is an industry unique non-disruptive bucket migrations tool that syncs up the source and destination and help move metadata including any custom ones.

While the non-disruptive nature of bucket relocation offers significant advantages, some early community discussions have highlighted potential considerations regarding its pricing model and administrative overhead for certain organizational structures. A Reddit user commented:

Definitely neat, but the list of billed items is unfortunate (per GiB for the relocation, per GiB for egress, per GiB for replication, class A operation per object, Management hub subscription per million objects). Granted, the delta between do-it-yourself and this is the per GiB for relocation and the Management hub subscription, but that per GiB for relocation will add up quickly and management hub being a per org subscription could trip things up bureaucratically – e.g., if I’m in a product team I’ll need to hunt down the org admin to turn on management hub and then ensure they set it up to only include my bucket so we don’t get hit with a potentially huge bill and only then can I relocate my bucket… It’s just unfortunate.

Lastly, users can learn more through the bucket relocation documentation and the Storage Intelligence overview.

Figma recently revealed its cloud computing costs in its initial public offering (IPO) filing, revealing a daily expenditure of around $300,000 on Amazon Web Services (AWS). As a result, the company allocates approximately $100 million each year, which accounts for about 12% of its reported revenue of $821 million.

Figma, a widely used interface design tool, relies entirely on AWS for its “computing, storage capabilities, bandwidth, and other services.” The S-1 filing further details a renewed hosting agreement with AWS, signed on May 31, 2025, which commits Figma to a minimum spend of $545 million in cloud hosting services over the next five years. However, the filing doesn’t break down how these costs are allocated across specific services, such as storage, compute, or bandwidth.

In addition to a substantial financial investment, Figma’s filing emphasizes the risks associated with extensive cloud integration. The company acknowledges its complete reliance on AWS’s performance, which makes it vulnerable to potential outages. Furthermore, AWS has the authority to change and interpret its terms of service and other policies, including during contract renewals, which could negatively affect Figma’s business operations. If AWS were to cancel the contract entirely, it would create significant challenges for Figma, as its cloud service infrastructure is specifically designed to operate within the AWS ecosystem.

Per Borgen, a CEO at Scrimba, posted on LinkedIn:

For comparison, at Scrimba, we spend far less than 1% of our revenue on infrastructure. This is because we skipped the cloud and run on dedicated servers instead. But it’s not just about cost. Figma’s infra is tightly coupled to AWS. If Amazon changes terms or pulls the plug, they’re in trouble. And it’s all by their own admission. So the question isn’t just “Is it expensive?”  It’s also “How much control are you giving up?”

The deep entanglement of Figma with a cloud provider goes far beyond simply using virtual machines. As one insightful commenter on Hacker News, nevon, explained:

A common misconception about moving off the cloud is viewing it solely as a VM provider. In reality, the cloud integrates deeply into your systems. Your permissions rely on cloud identities, firewalls use security group references, and cross-region connectivity depends on cloud networking. You manage secrets with cloud tools, monitor metrics through cloud observability, and often utilize whitelisted IP ranges provided by the provider. Additionally, database upgrades, VM images, and auditing are tied to the cloud services. Even your applications may depend on cloud-managed containers and event buses, while disaster recovery plans hinge on the provider’s backup and failover capabilities.

The explanation of nevon clarifies why migrating from a cloud platform, even for a large company like Figma, is not a quick or simple task.

Figma’s revelation adds to the ongoing industry discussion about the escalating costs of cloud computing as companies scale. This has led some organizations exploring the repatriation of specific workloads or data from the public cloud to on-premises or co-located infrastructure. A prominent example is 37signals, whose CTO, David Heinemeier Hansson, has been a vocal advocate for exiting the cloud. They initiated their repatriation efforts in 2022, when their annual cloud bill exceeded $3.2 million. By October 2024, 37signals estimated a $2 million savings that year by moving away from cloud services. Their latest phase involves exiting AWS’s S3 storage service, which Heinemeier Hansson anticipates will save the company around $1.3 million annually.

Ultimately, Figma’s substantial cloud bill serves as a stark reminder of the core dilemma facing modern tech companies: the trade-off between the agility and convenience offered by hyperscale cloud providers versus the escalating costs and the inherent risks of deep vendor lock-in.

AWS has announced key components of its independent European governance for the AWS European Sovereign Cloud, including a new EU-controlled parent company and a dedicated Security Operations Center. With this strategic move, AWS aims to launch its first region in Brandenburg, Germany, by the end of 2025, specifically to meet the stringent digital sovereignty requirements of European governments and enterprises.

The AWS European Sovereign Cloud is designed to combine operational autonomy with the expansive service portfolio of the AWS Cloud. AWS emphasizes its long-standing “sovereign-by-design” approach, where customers control data location and movement. These stringent requirements are primarily driven by industry concerns over data access and extraterritorial laws, such as the U.S. CLOUD Act. This new cloud builds on that commitment, offering the same performance, innovation, security, and scale AWS customers expect.

A new European organization and operating model will be established for the AWS European Sovereign Cloud, comprising a new parent company and three subsidiaries incorporated in Germany, all of which will be led by EU citizens residing in the EU and subject to local laws. Kathrin Renz, currently vice president of AWS Industries, will serve as the company’s first managing director, legally bound to act in the best interest of the AWS European Sovereign Cloud.

Furthermore, the model ensures that customer content and metadata remain within the EU, with operations managed exclusively by personnel residing in the EU. Its dedicated infrastructure will be entirely located within the EU, physically and logically separate from other AWS regions, with no critical dependencies on non-EU infrastructure. It will also feature independent services, such as its own Amazon Route 53 (utilizing European Top-Level Domains) and a dedicated “root” European Certificate Authority for SSL/TLS certificates, alongside Euro currency billing.

An independent advisory board, comprising at least four EU citizens (including one independent member not affiliated with Amazon), will be established. This board will provide expertise and accountability on sovereignty-related aspects and act in the best interest of the AWS European Sovereign Cloud. The design also enables continuous operation even in the event of a connectivity interruption with the rest of the world.

The AWS European Sovereign Cloud will feature a dedicated European Security Operations Center (SOC) mirroring global security practices. This SOC will be led by an EU citizen residing in the EU, who will be responsible for advising the managing director and supporting customers and regulators on security matters.

AWS has also closely collaborated with European regulators, including the German Federal Office for Information Security (BSI), signing a co-operation agreement to further governance and technical standards for operational separation and data flow management. To provide verifiable trust and adherence to sovereignty controls, AWS is introducing the Sovereign Requirements Framework (SRF). The AWS European Sovereign Cloud will maintain key certifications, including ISO/IEC 27001:2013, SOC 1/2/3 reports, and BSI C5 attestation, with independent third-party audits based on the SRF, available via AWS Artifact.

(Source: About Amazon News)

The AWS European Sovereign Cloud initiative comes amidst a significant and ongoing push in Europe for greater technological sovereignty. David Linthicum, a prominent industry analyst, commented on this broader trend in a tweet on X:

The growing push in Europe to reduce reliance on US-based cloud providers is a bold and important move toward technological sovereignty. By promoting homegrown solutions, the EU is striving for greater control over sensitive data and reduced dependency on external powers. However, this shift raises an important question: Could Europe be sacrificing access to the advanced capabilities offered by leading US cloud providers in the process? US cloud giants have set the standard for cutting-edge innovation in areas such as artificial intelligence, machine learning, and scalable global infrastructure.

Linthicum further noted that while Europe’s push to develop its own cloud ecosystem (citing initiatives like Gaia-X) is a step in the right direction, it faces “steep challenges in terms of infrastructure investment, scalability, and competing with over a decade of expertise and innovation.” He concluded that:

Striking the right balance will be critical. Europe must ensure its sovereignty efforts don’t unintentionally limit access to crucial capabilities that drive innovation and competitive advantage in a globally connected economy.

This initiative from AWS comes as other major cloud providers are also making significant commitments to address European concerns about digital sovereignty. For instance, Microsoft recently announced five digital commitments to strengthen its support for Europe’s technological landscape, including a 40% expansion of its European datacenter capacity, a pledge to uphold digital resilience (including a “European cloud for Europe” overseen by a European board), and the completion of its EU Data Boundary project.

The first AWS European Sovereign Cloud Region is set to launch in the State of Brandenburg, Germany, by the end of 2025, backed by a €7.8 billion investment – a commitment that ensures customers can meet their evolving digital sovereignty needs without compromising on the full power of AWS.

It will offer a comprehensive suite of services, including artificial intelligence (Amazon Bedrock, Amazon Q, Amazon SageMaker), compute, containers, database, networking, and security. These services, built on AWS’s sovereign-by-design foundation, will simplify how customers achieve digital sovereignty while gaining the security, control, compliance, and resilience they need. Customers will also benefit from a wide range of AWS Partner Solutions. Once launched, the AWS European Sovereign Cloud will be open to all customers and partners, reinforcing AWS’s long-term commitment to Europe’s digital future.

AWS has released a set of open-source Model Context Protocol (MCP) servers on GitHub for Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Kubernetes Service (Amazon EKS), and AWS Serverless. These are specialized servers that enhance the capabilities of AI development assistants, such as Amazon Q Developer, by providing them with real-time, contextual information specific to these AWS services.

While Large Language Models (LLMs) within AI assistants typically rely on general public documentation, these MCP servers offer current context and service-specific guidance. Hence, developers can receive more accurate assistance and proactively prevent common deployment errors when building and deploying applications on AWS.

Hariharan Eswaran concluded in a Medium blog post:

The launch of MCP servers is about empowering developers with tools that keep up with the complexity of modern cloud-native apps. Whether you’re deploying containers, managing Kubernetes, or going serverless, MCP servers let your AI assistant manage infrastructure like a team member — not just a chatbot.

Furthermore, according to the company, leveraging these open-source solutions allows developers to accelerate their application development process by utilizing up-to-date knowledge of AWS capabilities and configurations directly within their integrated development environment (IDE) or command-line interface (CLI). Moreover, the key features and benefits include:

• Amazon ECS MCP Server: Simplifies containerized application deployment to Amazon ECS by configuring necessary AWS resources like load balancers, networking, auto-scaling, and task definitions using natural language. It also aids in cluster operations and real-time troubleshooting.
• Amazon EKS MCP Server: Provides AI assistants with up-to-date, contextual information about specific EKS environments, including the latest features, knowledge base, and cluster state. This enables more tailored guidance throughout the Kubernetes application lifecycle.
• AWS Serverless MCP Server: Enhances the serverless development experience by offering comprehensive knowledge of serverless patterns, best practices, and AWS services. Integration with the AWS Serverless Application Model Command Line Interface (AWS SAM CLI) streamlines function lifecycles and infrastructure deployment. It also provides contextual guidance for Infrastructure as Code decisions and best practices for AWS Lambda.

The announcement details practical examples of using the MCP servers with Amazon Q CLI to build and deploy applications for media analysis (serverless and containerized on ECS) and a web application on EKS, all through natural language commands. The examples showcase the AI assistant’s ability to identify necessary tools, generate configurations, troubleshoot errors, and even review code based on the contextual information provided by the MCP servers.

The announcement has already garnered positive attention from the developer community. Maniganda, commenting on a LinkedIn post, expressed enthusiasm:

The ability for AI to interact with AWS compute services in real-time will undoubtedly streamline operations and enhance efficiency. I’m looking forward to seeing how the open-source framework evolves and the impact it will have on Kubernetes management.

Users can get started by visiting the AWS Labs GitHub repository for installation guides and configurations. The repository also includes MCP servers for transforming existing AWS Lambda functions into AI-accessible tools and for accessing Amazon Bedrock Knowledge Bases. Deep-dive blogs are available for those wanting to learn more about the individual MCP servers for AWS Serverless, Amazon ECS, and Amazon EKS.

Virt8ra, a significant European initiative positioning itself as a major alternative to US-based cloud vendors, has announced a substantial expansion of its federated infrastructure. The platform, which initially included Arsys, BIT, Gdańsk University of Technology,  Infobip, IONOS, Kontron, MONDRAGON Corporation, and Oktawave, coordinated by OpenNebula Systems, has now been joined by six new cloud service providers: ADI Data Center Euskadi, Clever Cloud, CloudFerro, OVHcloud, Scaleway, and Stackscale.

Quentin Adam, CEO of Clever Cloud, commented:

By championing open source and empowering local providers across the EU, Virt8ra is not only helping to reduce our continent’s reliance on hyperscalers and Big Tech vendors, but also laying foundations for a truly autonomous and innovative digital future.

Launched in January 2025 by a consortium of eight European tech organizations coordinated by OpenNebula Systems, Virt8ra aims to establish a sovereign and interoperable cloud ecosystem across the European Union. Leveraging the open-source OpenNebula cloud technology, the initiative prioritizes data localization, flexibility, and vendor independence. The initial phase offered compute and storage resources across six EU member states: Croatia, Germany, the Netherlands, Poland, Slovenia, and Spain.

A commenter on Reddit pointed out the broader challenge, stating:

Infrastructure AND the associated software, if I may add! One of the strengths of Azure and AWS, justifying their services, which are 10 times as expensive as those of OVH or Scaleway, is the huge software suite that comes with it. With LLMs and the associated productivity gains, I guess Europe could catch up quite quickly. However, we need to create strong incentives for European companies to switch to European cloud providers.

Just three months later, this expansion significantly broadens Virt8ra’s reach and capacity. Dr. Ignacio M. Llorente, CEO of OpenNebula Systems and Chair of the Cloud-Edge Working Group at the European Alliance for Industrial Data, Edge, and Cloud, emphasized Virt8ra’s importance as “a key step toward building a sovereign and interoperable cloud ecosystem in Europe.”

Furthermore, Virt8ra is designed to facilitate the easy deployment of distributed applications spanning the cloud-edge continuum, with a strong emphasis on AI and machine learning. The infrastructure is currently being validated through enterprise use cases that demonstrate innovations in AI-enabled orchestration, mechanisms for Data Act-compliant cloud migration and data egress, and the future potential for multi-tenant “AI-as-a-Service” offerings for both inference and training.

In addition, the collaborative effort is taking place within the framework of the Important Project of Common European Interest on Next Generation Cloud Infrastructure and Services (IPCEI-CIS). The IPCEI-CIS, approved by the European Commission in December 2023 and supported by 12 EU Member States, represents the European Union’s largest open-source project to date, backed by over €3 billion in public and private funding. Dr. Alberto P. Martí, chair of the IPCEI-CIS Industry Facilitation Group, commented:

I’m proud to see the EU industry finally taking the lead in developing strategic open-source technologies and delivering tangible solutions for creating sovereign digital infrastructure across Europe.

The ultimate objective of Virt8ra is to integrate and validate a European sovereign virtualization stack built around OpenNebula, delivering an open-source, vendor-neutral solution for managing the entire cloud-edge continuum. An objective that might empower EU businesses and public organizations, strengthen their digital sovereignty, and reduce their reliance on non-European hyperscalers and Big Tech vendors.

AWS recently launched its Product Lifecycle page, a new centralized resource providing comprehensive information on service availability changes. With this initiative, the company aims to streamline how customers track service deprecations, end-of-support timelines, and restrictions on new customer access.

The AWS Product Lifecycle page consolidates information into three key categories: services closing access to new customers, services announcing end of support (including migration paths and timelines), and services already reaching their end-of-support date.

Wojtek Szczepucha, a solution architect at AWS, posted on LinkedIn:

Now, you can check if and which services will reach the end-of-support. However, it’s not only that, with the AWS Product Lifecycle page, you will know:

– WHY has this decision been made?

– HOW can you handle this situation? With the alternate solutions proposed.

Adding to the positive reception, cloud economist Corey Quinn offered his analysis, stating he was “happier” about this round of deprecations for two reasons. Firstly, he noted the benefit of a consolidated announcement of multiple deprecations, contrasting it with the potentially unsettling “drip-drip-drip” of individual deprecations seen previously. In addition, Quinn argued that this batching, coupled with clear rationales and transition plans (as highlighted by Szczepucha), builds customer confidence.

Secondly, Quinn emphasized the significant improvement in having a unified location for service and feature deprecation information, moving away from a fragmented landscape of blog posts and documentation updates.

This sentiment was echoed by Luc van Donkersgoed, an AWS Serverless Hero, in a LinkedIn post:

AWS is finally taking a mature stance on service deprecations!

Currently, the new page lists initial updates for services like Amazon Timestream for LiveAnalytics (closing to new customers), Amazon Pinpoint, and others reaching the end of support.

With the new page, the company follows up with Microsoft Azure and Google Cloud practices, offering mechanisms for communicating service lifecycles through platforms like Azure’s Lifecycle Policy and Google Cloud’s documentation and release notes.

For instance, Microsoft Azure provides its Microsoft Lifecycle Policy page, offering searchable information on support timelines, and Azure Updates for broader announcements. At the same time, Google Cloud communicates through service-specific documentation, release notes, and defined Product Launch Stages.

Lastly, the authors of the AWS News blog post on the new page recommend bookmarking the page and checking out What’s New with AWS? for upcoming AWS service availability updates.

Microsoft recently announced the general availability (GA) of the Azure AI Foundry Agent Service at its annual Build conference, a flexible, use-case-agnostic platform for building, deploying, and managing AI agents, designed as microservices (benefiting from modularity and scalability), for a wide range of applications.

The company first introduced the service at Ignite as Azure AI Agent Service, which sits within Azure AI Foundry, allowing developers to create and run an agent using either OpenAI SDKs or Azure AI Foundry SDKs with just a few lines of code. It was later available in public preview in the Azure AI Foundry SDK and the Azure AI Foundry portal. Moreover, with the GA release, the company states that it is introducing several powerful new features and integrations that make it even easier for developers to build and scale their agent solutions.

(Source: Microsoft Learn documentation)

One of the key enhancements in the GA release is the robust support for Multi-Agent Orchestration that coordinates specialized agents to perform structured, long-running tasks. The orchestration capability is built around two core components: first, Connected Agents (preview) enable point-to-point interactions, allowing agents to call upon other specialized agents as tools for task delegation, modular processing, and context-specific workflows where each contributes independently to the solution; and second, Multi-Agent Workflows (preview) offer a structured, stateful orchestration layer that coordinates multiple agents through complex, multi-step processes by handling context management, error recovery, and long-running durability, making them ideal for scenarios requiring agents to maintain context across multiple steps, like customer onboarding or supply chain automation.

The Foundry Agent Service integrates directly with the converged runtime for Semantic Kernel and AutoGen to support advanced multi-agent orchestration.

Recognizing that AI agents thrive within interconnected ecosystems, the GA release of Azure AI Foundry Agent Service strongly emphasizes open and interoperable tools. Developers can now leverage the extensive library of over 1,400 Azure Logic Apps workflows as tools for their agents, enabling seamless automation of complex business processes and even triggering agents directly from Logic Apps.

Furthermore, the platform significantly expands its knowledge integration capabilities by adding SharePoint as a first-party tool alongside Microsoft Fabric and Bing Search, providing agents with richer, context-aware insights. The ecosystem is further enriched through access to a growing catalog of partner tools from various domains and a library of reusable agent code samples from Microsoft and the community, accelerating development and expanding agent capabilities.

A key aspect of this open approach is the introduction of the Agent2Agent (A2A) API head, which enables interoperability with other agent platforms – allowing open-source orchestrators with A2A connectors to utilize Foundry Agent Service agents without requiring custom integrations, facilitating multi-turn conversations between diverse agents. Moreover, the commitment to open protocols extends to multi-cloud scenarios, allowing developers to connect Foundry agents with agents from platforms like SAP Joule and Google Vertex AI. Furthermore, Azure AI Foundry Agent Service integrates with popular agent orchestration frameworks like Crew AI, LangGraph, and LlamaIndex.

In addition, the GA release of Azure AI Foundry Agent Service incorporates robust features for evaluation, monitoring (AgentOps), governance, and safety. Built-in evaluation tools allow developers to assess agent performance across key metrics like accuracy and efficiency. At the same time, integrated tracing provides detailed insights into agent processing workflows for optimization.

Daniel Christian, a Microsoft MVP and certified trainer, emphasized this open approach on X:

Models, Models, everywhere, but they are all available to connect with the Azure AI Foundry Agent Service.

In addition, Jiadong Chen, a Cloud architect and Microsoft MVP, tweeted:

AI agents are quietly transforming industries. With Azure AI Foundry and Azure AI Agent Service, businesses deploy LLM-powered multi-agent systems to handle everything from real-time analytics to customer interactions. Picture a retail chain using AI agents to predict inventory shortages or a hospital automating patient triage — all while Azure’s scalable infrastructure keeps data secure. The result? Productivity spikes, costs plummet, and innovation accelerates.

Lastly, Microsoft envisions the Azure AI Foundry Agent Service as a dynamic foundation for intelligent agent ecosystems, with ongoing efforts focused on unifying the Semantic Kernel and AutoGen SDKs, integrating containerized agents for streamlined orchestration, and broadening support for an even wider array of external agents.

At the annual Build conference, Microsoft announced agent loop, a new capability within Azure Logic Apps that allows developers to build AI agents directly into their enterprise workflows.

Agent loop is a central component for AI Agent development within Logic Apps. It is a new action type integrating a chosen AI model (like Azure OpenAI), domain-specific tools (via Logic Apps connectors), and enterprise knowledge sources. With the component, developers can create various types of AI agents, including autonomous agents for tasks like loan approvals, conversational agents for customer support, and multi-agent systems for coordinated activities such as sales report generation.

(Source: Microsoft Tech community blog post)

Built upon the kernel object in the Semantic Kernel, the agent loop leverages an LLM to determine the necessary steps. At the same time, the Azure Logic Apps runtime handles the execution of these plans. This approach offers significant flexibility, allowing for the creation of both conversational and fully autonomous agents that can respond to real-time events via Logic Apps’ extensive library of connectors.

Divya Swarnkar, a program manager at Microsoft, told InfoQ :

With over 1,400 connectors, Logic Apps is uniquely positioned to power AI Agents with rich context and seamless access to enterprise systems and APIs, enabling them to reason and act reliably.

Agent loop operates through an iterative “Think, Act, and Learn cycle.” The AI agent reasons about its goal and context, takes action by invoking connectors, and then reflects on the results to adjust its plan if needed. Azure Logic Apps manages this cycle automatically.

Microsoft highlights several potential use cases for AI Agents built with agent loop, including:

• Product Return Agent: Verifying order details, return eligibility, and processing refunds or requesting further information.
• Loan Approval Agent: Evaluating credit scores, income, and risk profiles to auto-approve or route applications.
• Recruiting Agent: Screening resumes, summarizing qualifications, and drafting personalized outreach.
• Sales Report Generation Workflow: Utilizing multiple agents for drafting, reviewing, and publishing reports.
• IT Operations Agent: Triaging alerts, checking changes, and resolving common issues or escalating when necessary.
• Multi-Agent Retail Supply Chain Solution: Coordinating inventory and logistics agents for timely restocks and optimized fulfillment.

Furthermore, the key benefits of building AI Agents in Logic Apps with agent loop include declarative orchestration, code extensibility, access to a vast library of integrated tools, observability with full traceability of agent decisions, enterprise-grade governance inheriting the security and compliance of Azure Logic Apps, straightforward human-in-the-loop and multi-agent coordination, and faster time to value by abstracting away the boilerplate of agent architecture.

Kent Weare, a Principal Program Manager for Logic Apps at Microsoft, states:

Building agents or workflows isn’t a binary choice. The most effective solutions often combine both — and that’s where Logic Apps excels. With Agent Loop, customers have full control to dial up the level of agentic automation that fits their needs. Logic Apps is where traditional workflows and AI agents come together, combining forces to solve complex business problems — all within a trusted, enterprise-grade platform. I don’t think any other platform offers this!

In addition, further emphasizing the potential, Cameron McKay, an Azure Application Architect, concluded in a LinkedIn blog post about the agent loop feature in Logic Apps:

This functionality has a lot of potential, and the number of use cases is up to the business and implementer; a few use cases include responding to error events and performing processes based on conversations with humans. I’m excited to see how the use cases for this functionality evolve; without a doubt, this is a highly transformative and useful piece of functionality being added to the Azure Logic Apps toolkit.

Agent loop is available in Azure Logic Apps Standard, and the company has provided documentation and demos to help developers get started. It has also outlined future plans for multi-agent hand-off support, A2A (Agent-to-Agent) protocol support, and OBO Auth for Logic Apps Agents.

Cloudflare’s new Vite plugin (v1.0) streamlines web application development on Cloudflare Workers by integrating the Workers runtime directly into the Vite build process and adding official support for React Router v7.

The plugin leverages Vite 6’s Environment API to allow developers to run Worker code within the workerd runtime, aligning development and production environments. Michal Kuncio, a senior frontend engineer, noted on X:

By leveraging the @vite_js Environment API, you can now use Cloudflare Workers on your development server to mimic production behavior.

Moreover, this integration builds on Vite’s popularity as a fast build tool. Developers like Shivani Sharma on LinkedIn praise it for its superior speed, bundling, and configuration flexibility compared to Create React App and its efficient hot module replacement and robust plugin ecosystem.

Vite 6 introduces the Environment API, a significant architectural change that enables the Vite dev server to interact with various custom runtime environments, including workers. Cloudflare collaborated with the Vite team on this API.

(Source: Cloudflare blog post)

The Cloudflare Vite plugin supports single-page applications (SPAs) built with frameworks like React, Vue, and Svelte. Developers can create new React SPAs using the create-cloudflare CLI, which handles create-vite and configures the Cloudflare Vite plugin. Existing Vite SPA projects can be updated by adding the @cloudflare/vite-plugin dependency and a wrangler.jsonc configuration file.

The plugin integrates the Vite dev server with Workers Assets for front-end applications. In addition, the plugin streamlines the development and deployment workflow for applications with a Worker backend. The Vite development server runs the Worker in the Cloudflare Workers runtime. Developers can modify Worker code (e.g., in api/index.ts) and see changes without losing UI state. The plugin also simplifies the build and deployment process: vite build outputs both client and server code, vite preview allows previewing the build in the Workers runtime, and wrangler deploys the application directly.

The Cloudflare Vite plugin also supports React Router v7. Developers can create new React Router applications using the create-cloudflare CLI. Ardizanki, a software engineer specializing in the React ecosystem, tweeted:

React Router is the best bridge from React 18 to 19. Use it as a full framework or as a library within your own architecture.

The plugin simplifies the Worker’s configuration, giving developers more control.

Lastly, the plugin supports the complete Cloudflare Developer Platform, including KV, D1, Service Bindings, RPC, Durable Objects, Workflows, and Workers AI. Existing Workers can be adapted for Vite by installing the @cloudflare/vite-plugin dependency and adding a Vite configuration.

AWS has announced significant updates to Lambda logging, introducing volume-based tiered pricing for Amazon CloudWatch Logs and adding Amazon S3 and Amazon Data Firehose as new, cost-effective destinations for Lambda logs. Effective May 1st, 2025, these changes aim to reduce logging costs for high-volume Lambda deployments and offer greater flexibility in integrating with a broader range of monitoring tools.

The move to tiered pricing is particularly welcome news for AWS customers who have experienced the often-hidden costs associated with CloudWatch Logs. As senior cloud architect Mark Lambert noted on LinkedIn:

CloudWatch logs are a common hidden cost gotcha for new AWS customers. Without a strategy, you can quickly burn through your cloud budget and erode stakeholder trust.

The company categorizes the new tiered pricing model for Lambda logs in CloudWatch Logs as Vended Logs, offering progressively lower per-GB costs as log volume increases. For example, in the US East (N. Virginia) region, costs can decrease from $0.50 per GB for the first 10 TB to as low as $0.05 per GB for over 50 TB monthly. As Sandro Volpicella, a freelance software developer, noted on X:

Your CloudWatch Costs could go down by themselves with this launch. AWS counts Logs coming from Lambda now as ‘vented logs,’ and they come with a volume-tiered pricing model.

(Source: Tweet from Sandro Volpicella)

In addition, in a recent Duckbill Group blog post, Eric Pullen notes that while this is a significant benefit for heavy loggers, those using under 10 TB per month per account will see no immediate change, as the first tier matches the previous flat rate.

Adding S3 and Firehose as direct logging destinations for Lambda functions is also a key development. Pullen highlights that this eliminates the need for complex Lambda-based forwarders and unlocks use cases like long-term compliance archiving on S3, advanced analytics, and easier integration with third-party observability platforms via Firehose. However, he hopes that the pricing for these new destinations will become more competitive to encourage broader adoption.

According to Shridhar Pandey and Matthew Barker in the AWS blog post:

These enhancements provide a more straightforward and more cost-effective logging experience for Lambda users.

Pullen echoes this sentiment, emphasizing the potential for substantial cost savings for large enterprises. He also cautions that:

Any custom-written CloudWatch Log reports will need updating due to the pricing change. Additionally, he reminds users that the tiered pricing applies per AWS account, potentially influencing multi-account strategies.

While CloudWatch Logs remains the default logging destination, users can now configure S3 or Firehose as alternatives. AWS encourages users to review the documentation and pricing details to optimize their Lambda logging strategies, including considering log levels and retention policies to maximize cost savings from the new tiered pricing.

(Source: Amazon Compute blog post)

The new logging features are available in all commercial AWS regions that Lambda and CloudWatch Logs support. Configuration for S3 and Firehose destinations in the Lambda console is initially available in select regions, with more to follow.