awsMay 27, 2026

Meet Our Newest AWS Heroes – May 2026 | Amazon Web Services (opens in new tab)

AWS has named four new Heroes for May 2026, recognizing leaders who advance cloud, AI, serverless, and community education. Their work ranges from building Amazon Bedrock-powered tools and contributing to AWS certifications to organizing major user groups and events across Europe and Latin America. Together, they demonstrate how technical expertise and community leadership can help more builders adopt AWS. ## Damiano Giorgi — Pavia, Italy - An Artificial Intelligence Hero and Cloud Solutions Architect specializing in AI. - Helps organize AWS User Groups in Pavia and Milan. - Created the “Unofficial post:Invent Session Suggester,” using Amazon Bedrock and Amazon Nova to recommend re:Invent sessions. - Shares knowledge through his “Bass and Bytes” blog and conferences across Europe. ## Darryl Ruggles — Ottawa, Canada - A Serverless Hero and Cloud Solutions Architect with a background in software development. - Focuses on AWS application architecture, AI/ML, serverless, containers, and FinOps. - Publishes blog posts, LinkedIn content, and open projects. - Participates actively in online communities such as “Believe In Serverless” and in-person AWS events. ## Ricardo Daniel Ceci — Buenos Aires, Argentina - An Artificial Intelligence Hero leading the AWS User Group Buenos Aires, with nearly 2,400 members. - Principal organizer of AWS Community Day Argentina. - Named AWS Community Leader of the Year 2025 for Latin America. - Hosts a podcast with cloud experts, AWS Heroes, and developer advocates. - Works to make cloud and AI more accessible to Spanish-speaking builders across LATAM. ## Matias Kreder — Buenos Aires, Argentina - An Artificial Intelligence Hero and AWS Certification Subject Matter Expert. - Contributed to AI/ML certifications, including the AWS Certified AI Practitioner exam. - Began his community involvement through AWS DeepRacer, qualifying as a finalist three times. - Organizes racing events, ML talks, and AWS community activities across Latin America. - Helped organize AWS Community Day Argentina 2025 and speaks at regional events. These new Heroes illustrate the value of combining AWS expertise with mentorship, content creation, certification work, and community organizing. Builders can learn more or connect with regional leaders through the AWS Heroes program.

containersaimachine-learningaws+4

cloudflareApr 13, 2026

Agents have their own computers with Sandboxes GA (opens in new tab)

Cloudflare has made Sandboxes and Cloudflare Containers generally available for running AI agents in persistent, isolated computer environments. The platform addresses the operational challenges of agent workloads—including bursty demand, fast state restoration, secure authentication, lifecycle control, and developer-friendly tooling. Recent additions make Sandboxes more capable for coding agents while reducing the cost of running them at scale. ## Why Agents Need Full Computers - Coding agents often need to clone repositories, build software, run development servers, and work across multiple languages. - Existing VM and container approaches must handle: - Rapidly creating many session-specific environments without paying for idle capacity. - Quickly restoring previous session state. - Giving agents access to services without exposing credentials. - Programmatic control over commands, files, and sandbox lifecycles. - Simple interfaces for both human developers and agents. - Figma is using Cloudflare Containers to run untrusted agent- and user-authored code for Figma Make. ## Sandboxes 101 - A Sandbox is a persistent, isolated environment powered by Cloudflare Containers. - Sandboxes are addressed by name: - Running sandboxes are reused. - Inactive sandboxes sleep automatically. - Requests wake sleeping sandboxes on demand. - The same sandbox can be accessed from anywhere using its ID. - The API supports operations such as: - `exec` for running commands. - `gitCheckout` or `gitClone` for retrieving repositories. - `writeFile` for managing files. - Command output can be streamed in real time, such as when running `npm test`. ## Secure Credential Injection - Agents may need to call private services but should not receive raw credentials. - Sandboxes inject credentials at the network layer through a programmable egress proxy. - Custom outbound rules can add authentication headers to requests based on the destination host. - This allows authenticated access while keeping secrets outside the agent’s environment. - Authentication logic can be customized for identity-aware access, dynamic rules, and Workers bindings. ## Real Terminal Access with PTY - Early agent interfaces treated shell commands as isolated request-response operations. - PTY support provides a more realistic terminal experience: - Output streams continuously. - Processes can be interrupted. - Sessions can be reconnected later. - Sandbox terminal sessions are proxied over WebSockets and are compatible with `xterm.js`. - Applications can expose the backend through `sandbox.terminal`. ## Features for Agent Development - **Persistent code interpreters:** Stateful Python, JavaScript, and TypeScript execution is available out of the box. - **Background processes:** Development servers and other long-running commands can continue running independently. - **Live preview URLs:** Agents and users can inspect development servers and verify changes while they are in progress. - **Filesystem watching:** Faster feedback as agents modify files. - **Snapshots:** Coding sessions can be quickly recovered from saved state. - **Higher limits and Active CPU Pricing:** Fleets of agents can scale without paying for unused CPU cycles. Cloudflare’s GA release positions Sandboxes as a managed environment for agent-driven software development: persistent when state matters, isolated when code is untrusted, and cost-efficient when workloads are intermittent.

containersauthenticationcloudflare-sandboxesagent-systems+4

cloudflareApr 12, 2026

Welcome to Agents Week (opens in new tab)

Cloudflare argues that AI agents require a fundamental shift in Internet and cloud infrastructure. Unlike traditional one-to-many applications, agents create unique, ephemeral execution environments for individual users and tasks, making current container-based economics and scaling inadequate. The company positions lightweight V8 isolates, alongside containers and browser support, as the foundation for making agents practical at global scale. ## The Internet Was Built for Applications, Not Agents - Cloud infrastructure evolved during the smartphone era to serve many users through a finite number of application instances. - Microservices, containers, Kubernetes, load balancing, and replication all support this one-to-many model. - Agents differ because an LLM dynamically determines code paths, tool usage, and task duration. ## One User, One Agent, One Task - Each agent may need its own execution environment, filesystem, tools, and state. - Coding agents currently use containers with access to Git, Bash, filesystems, and arbitrary binaries. - As agents spread to assistants, analysts, customer service, and planning tasks, the number of simultaneous environments could grow dramatically. ## The Scale Challenge - If 100 million US knowledge workers used agents at 15% concurrency, infrastructure would need about 24 million simultaneous sessions. - At 25–50 users per CPU, that implies roughly 500,000 to 1 million server CPUs in the US alone. - Multiple agents per person and global adoption would increase demand by orders of magnitude. ## Isolates as Agent Infrastructure - Cloudflare’s Workers platform uses V8 isolates instead of containers. - Isolates start in milliseconds, use only a few megabytes of memory, and provide secure sandboxing. - They can be up to 100 times faster to start and up to 100 times more memory-efficient than containers. - Dynamic Workers can create execution environments on demand, run code, and discard them at a scale of millions per second. - This efficiency could make one-agent-per-user economics viable beyond expensive coding assistants. ## The “Horseless Carriage” Phase - Early agent infrastructure often adapts existing systems instead of using designs built specifically for agents. - Agents use headless browsers to navigate human-oriented websites, though structured protocols such as MCP could provide direct service access. - Many MCP servers simply wrap REST APIs, despite LLMs often being better at writing and executing code than making long sequences of tool calls. - CAPTCHAs and behavioral fingerprinting ask whether a requester is human, while agent systems need identity, authorization, and permission controls. - Full containers are frequently used for tasks that require only a few API calls and a response. ## Supporting Both Old and New Models - Infrastructure transitions rarely happen all at once; technologies such as IPv4/IPv6, HTTP/2/HTTP/3, and TLS 1.2/1.3 coexist. - Cloudflare plans to support existing agent workloads while developing more efficient primitives. - Containers remain important for coding agents that need filesystems, Git, Bash, and arbitrary binaries. - Cloudflare is also expanding container-based sandbox environments and browser-rendering capabilities for services that do not yet support agent-native protocols. Cloudflare’s broader recommendation is to build infrastructure that can serve today’s container-based agents while moving toward lightweight, ephemeral isolates designed for billions of specialized agent sessions.

containersdatabase-designllmk8s+4

figmaAug 7, 2024

How We Migrated onto K8s in Less Than 12 months | Figma Blog (opens in new tab)

Figma migrated most of its core services from AWS ECS to Kubernetes in under 12 months because ECS was increasingly limiting its platform ambitions. Kubernetes offered better support for stateful workloads, Helm-based software, autoscaling, service networking, and the broader CNCF ecosystem. The migration was considered worthwhile because Figma had relatively few core services and had already containerized its workloads, making the transition more manageable. ## Figma’s Existing Compute Platform - By early 2023, Figma was already running all services in containers on Amazon ECS. - ECS had enabled rapid adoption of containerized workloads, but Figma’s growing infrastructure team began evaluating a more capable long-term platform. - Figma is not organized around thousands of microservices: - A small set of powerful core services provides modularization and traffic isolation. - New product capabilities are usually added to existing services rather than creating new ones. - This limited service count made a Kubernetes migration more practical. ## Limitations of ECS - ECS lacked Kubernetes primitives needed for complex workloads. - Running `etcd` on ECS required fragile custom startup code to manage cluster membership because ECS does not provide StatefulSets or persistent pod identity. - Kubernetes StatefulSets provide stable identities and stateful networking for systems such as `etcd`. - ECS did not natively support deploying groups of services packaged as Helm charts. - Open-source tools such as Temporal would require manual conversion into Terraform configurations. - This increased installation and maintenance effort. - ECS also made routine infrastructure operations more cumbersome. - For example, safely removing a malfunctioning EC2 instance was difficult. - EKS can cordon a node and move its pods elsewhere while respecting graceful shutdown behavior. ## Access to the CNCF Ecosystem - Kubernetes would give Figma access to a larger ecosystem of open-source cloud-native tools. - Autoscaling was a major motivation: - Figma was provisioning services for peak demand, wasting resources during lower-traffic periods. - Kubernetes tooling such as KEDA supports scaling based on CPU, SQS queue length, and custom Datadog metrics. - Figma expected to adopt a service mesh eventually. - Existing AWS load balancer routing created operational drawbacks: - Network Load Balancers could take several minutes to register or remove targets. - This slowed emergency deployments and increased incident remediation time. - Envoy offered more customization than AWS load balancers, including custom filters for shedding load during incidents. - Figma had already deployed standalone Envoy machines for a major service and saw Kubernetes ecosystems such as Istio as a path toward fleet-wide service-mesh adoption. Figma’s experience suggests that Kubernetes was justified not simply as a replacement for ECS, but as a foundation for more capable operations and broader platform tooling. Organizations considering a similar move should first assess their workload complexity, existing container maturity, and whether Kubernetes capabilities will materially reduce infrastructure work.

containersk8sterraformhelm+4

figmaOct 23, 2023

Server-side Sandboxing: An Introduction | Figma Blog (opens in new tab)

Server-side sandboxing helps contain the damage caused by vulnerabilities in software that processes untrusted user input. This is especially important for image processing, parsing, compression, and thumbnailing libraries often written in memory-unsafe languages, as demonstrated by ImageTragick. Figma argues that sandboxing complements—rather than replaces—secure coding by limiting a compromised workload’s access to data, services, and infrastructure. ## Why Server-Side Sandboxing Matters - Modern SaaS applications must process user-generated content using complex libraries. - Many of these libraries are written in C or C++, which are vulnerable to memory-corruption bugs. - ImageTragick showed how a vulnerability in ImageMagick could enable remote code execution when processing user-supplied images. - Preventing every vulnerability through rewrites, memory-safe languages, or program analysis is expensive and imperfect. - Sandboxing provides defense in depth by containing failures when vulnerabilities are exploited. ## Figma’s Server-Side Risk - Figma uses server-side components such as RenderServer, a C++ version of the editor, along with third-party libraries for graphical data. - Malicious input processed directly inside production infrastructure could allow an attacker to: - Access data belonging to other jobs - Make requests to internal production services - Move laterally through the environment - Compromise additional systems - Sandboxing reduces the external interfaces and resources available to potentially compromised workloads. ## Common Sandboxing Approaches - The article introduces three major sandboxing primitives: - **Virtual machines (VMs):** Isolate workloads through a hypervisor and separate guest operating systems. - **Containers:** Isolate workloads using operating-system-level mechanisms and container engines. - **Seccomp:** Restricts the system calls a program is permitted to make. - Each approach involves trade-offs in security properties, operational complexity, performance, and suitability for different workloads. - The article’s broader goal is to help teams compare these options and select an appropriate combination of isolation techniques. ## Choosing an Appropriate Strategy - Sandboxing technologies have historically been expensive, immature, or difficult to operate at scale. - Recent improvements have made virtualization, containment, and workload isolation more practical for a wider range of security teams. - Teams should evaluate sandboxing based on their workload’s risk, required interfaces, resource needs, and acceptable operational trade-offs. Teams should treat sandboxing as a practical layer of defense around risky processing workloads, rather than relying solely on preventing vulnerabilities.

containerswebassemblyc++application-security+3