Дали Петер Мадяр е добра новина предстои да видим. Но при всички случаи разместването на пластове, утаявани в продължение на 16 години трябва да освежи унгарската политика и тамошния обществен дневен ред. Това е работа на унгарците оттук нататък. И шанс, който не бива да пропиляват.
Краят на Виктор Орбан е много добра новина за ЕС и всички, които оценяваме значението на това, този засега предимно икономически съюз, да съществува. Дано някой ден повече европейци осъзнаят ползите и от политическо обединение.
Краят на Виктор Орбан обаче отваря вратите пред следващите мераклии за титлата „троянски кон“ в ЕС. А у нас само след седмица предстоят избори, на които един политически опортюнист, комуто властта много се е усладила, се е засилил да грабне още от нея. Без ясни ангажименти, с кухи фрази и празни обещания. С хора в листите, събрани откъде ли не. И под прикритието на някаква "прогресивност".
Румен Радев няма да е добра новина нито за България, нито за ЕС. Нищо, че се опитва да се позиционира като алтернатива на Борисов и Пеевски. След невзрачното си президентстване и органичен дефицит на собствени политически идеи, той няма и много какво да предложи. Единственото, което е сигурно при него е неприкритото и непрекъснато залитане към интересите на Русия.
За промяна в Унгария може да се говори с надежда, защото мнозинството там категорично застана зад ясно декларирана проевропейска посока. А тук?
Политическото късогледство у нас плащаме с поколения.
Linus has released the 7.0 kernel after a
busy nine-week development cycle.
The last week of the release continued the same “lots of small
fixes” trend, but it all really does seem pretty benign, so I’ve
tagged the final 7.0 and pushed it out.
I suspect it’s a lot of AI tool use that will keep finding corner
cases for us for a while, so this may be the “new normal” at least
for a while. Only time will tell.
Cloudflare’s mission has always been to help build a better Internet. Sometimes that means building for the Internet as it exists. Sometimes it means building for the Internet as it’s about to become.
Today, we’re kicking off Agents Week, dedicated to building the Internet for what comes next.
The Internet wasn’t built for the age of AI. Neither was the cloud.
The cloud, as we know it, was a product of the last major technological paradigm shift: smartphones.
When smartphones put the Internet in everyone’s pocket, they didn’t just add users — they changed the nature of what it meant to be online. Always connected, always expecting an instant response. Applications had to handle an order of magnitude more users, and the infrastructure powering them had to evolve.
The approach the industry converged on was straightforward: more users, more copies of your application. As applications grew in complexity, teams broke them into smaller pieces — microservices — so each team could control its own destiny. But the core principle stayed the same: a finite number of applications, each serving many users. Scale meant more copies.
Kubernetes and containers became the default. They made it easy to spin up instances, load balance, and tear down what you didn’t need. Under this one-to-many model, a single instance could serve many users, and even as user counts grew into the billions, the number of things you had to manage stayed finite.
Agents break this.
One user, one agent, one task
Unlike every application that came before them, agents are one-to-one. Each agent is a unique instance. Serving one user, running one task. Where a traditional application follows the same execution path regardless of who’s using it, an agent requires its own execution environment: one where the LLM dictates the code path, calls tools dynamically, adjusts its approach, and persists until the task is done.
Think of it as the difference between a restaurant and a personal chef. A restaurant has a menu — a fixed set of options — and a kitchen optimized to churn them out at volume. That’s most applications today. An agent is more like a personal chef who asks: what do you want to eat? They might need entirely different ingredients, utensils, or techniques each time. You can’t run a personal-chef service out of the same kitchen setup you’d use for a restaurant.
Over the past year, we’ve seen agents take off, with coding agents leading the way — not surprisingly, since developers tend to be early adopters. The way most coding agents work today is by spinning up a container to give the LLM what it needs: a filesystem, git, bash, and the ability to run arbitrary binaries.
But coding agents are just the beginning. Tools like Claude Cowork are already making agents accessible to less technical users. Once agents move beyond developers and into the hands of everyone — administrative assistants, research analysts, customer service reps, personal planners — the scale math gets sobering fast.
The math on scaling agents to the masses
If the more than 100 million knowledge workers in the US each used an agentic assistant at ~15% concurrency, you’d need capacity for approximately 24 million simultaneous sessions. At 25–50 users per CPU, that’s somewhere between 500K and 1M server CPUs — just for the US, with one agent per person.
Now picture each person running several agents in parallel. Now picture the rest of the world with more than 1 billion knowledge workers. We’re not a little short on compute. We’re orders of magnitude away.
So how do we close that gap?
Infrastructure built for agents
Eight years ago, we launched Workers — the beginning of our developer platform, and a bet on containerless, serverless compute. The motivation at the time was practical: we needed lightweight compute without cold-starts for customers who depended on Cloudflare for speed. Built on V8 isolates rather than containers, Workers turned out to be an order of magnitude more efficient — faster to start, cheaper to run, and natively suited to the “spin up, execute, tear down” pattern.
What we didn’t anticipate was how well this model would map to the age of agents.
Where containers give every agent a full commercial kitchen: bolted-down appliances, walk-in fridges, the works, whether the agent needs them or not, isolates, on the other hand, give the personal chef exactly the counter space, the burner, and the knife they need for this particular meal. Provisioned in milliseconds. Cleaned up the moment the dish is served.
In a world where we need to support not thousands of long-running applications, but billions of ephemeral, single-purpose execution environments — isolates are the right primitive.
Each one starts in milliseconds. Each one is securely sandboxed. And you can run orders of magnitude more of them on the same hardware compared to containers.
Just a few weeks ago, we took this further with the Dynamic Workers open beta: execution environments spun up at runtime, on demand. An isolate takes a few milliseconds to start and uses a few megabytes of memory. That’s roughly 100x faster and up to 100x more memory-efficient than a container.
You can start a new one for every single request, run a snippet of code, and throw it away — at a scale of millions per second.
For agents to move beyond early adopters and into everyone’s hands, they also have to be affordable. Running each agent in its own container is expensive enough that agentic tools today are mostly limited to coding assistants for engineers who can justify the cost. Isolates, by running orders of magnitude more efficiently, are what make per-unit economics viable at the scale agents require.
The horseless carriage phase
While it’s critical to build the right foundation for the future, we’re not there yet. And every paradigm shift has a period where we try to make the new thing work within the old model. The first cars were called “horseless carriages.” The first websites were digital brochures. The first mobile apps were shrunken desktop UIs. We’re in that phase now with agents.
You can see it everywhere.
We’re giving agents headless browsers to navigate websites designed for human eyes, when what they need are structured protocols like MCP to discover and invoke services directly.
Many early MCP servers are thin wrappers around existing REST APIs — same CRUD operations, new protocol — when LLMs are actually far better at writing code than making sequential tool calls.
We’re using CAPTCHAs and behavioral fingerprinting to verify the thing on the other end of a request, when increasingly that thing is an agent acting on someone’s behalf — and the right question isn’t “are you human?” but “which agent are you, who authorized you, and what are you allowed to do?”
We’re spinning up full containers for agents that just need to make a few API calls and return a result.
These are just a few examples, but none of this is surprising. It’s what transitions look like.
Building for both
The Internet is always somewhere between two eras. IPv6 is objectively better than IPv4, but dropping IPv4 support would break half the Internet. HTTP/2 and HTTP/3 coexist. TLS 1.2 still hasn’t fully given way to 1.3. The better technology exists, the old technology persists, and the job of infrastructure is to bridge both.
Cloudflare has always been in the business of bridging these transitions. The shift to agents is no different.
Coding agents genuinely need containers — a filesystem, git, bash, arbitrary binary execution. That’s not going away. This week, our container-based sandbox environments are going GA, because we’re committed to making them the best they can be. We’re going deeper on browser rendering for agents, because there will be a long tail of services that don’t yet speak MCP, and agents will still need to interact with them. These aren’t stopgaps — they’re part of a complete platform.
But we’re also building what comes next: the isolates, the protocols, and the identity models that agents actually need. Our job is to make sure you don’t have to choose between what works today and what’s right for tomorrow.
Security in the model, not around it
If agents are going to handle our professional and personal tasks — reading our email, operating on our code, interacting with our financial services — then security has to be built into the execution model, not layered on after the fact.
CISOs have been the first to confront this. The productivity gains from putting agents in everyone’s hands are real, but today, most agent deployments are fraught with risk: prompt injection, data exfiltration, unauthorized API access, opaque tool usage.
A developer’s vibe-coding agent needs access to repositories and deployment pipelines. An enterprise’s customer service agent needs access to internal APIs and user data. In both cases, securing the environment today means stitching together credentials, network policies, and access controls that were never designed for autonomous software.
Cloudflare has been building two platforms in parallel: our developer platform, for people who build applications, and our zero trust platform, for organizations that need to secure access. For a while, these served distinct audiences.
But “how do I build this agent?” and “how do I make sure it’s safe?” are increasingly the same question. We’re bringing these platforms together so that all of this is native to how agents run, not a separate layer you bolt on.
Agents that follow the rules
There’s another dimension to the agent era that goes beyond compute and security: economics and governance.
When agents interact with the Internet on our behalf — reading articles, consuming APIs, accessing services — there needs to be a way for the people and organizations who create that content and run those services to set terms and get paid. Today, the web’s economic model is built around human attention: ads, paywalls, subscriptions.
Agents don’t have attention (well, not that kind of attention). They don’t see ads. They don’t click through cookie banners.
If we want an Internet where agents can operate freely and where publishers, content creators, and service providers are fairly compensated, we need new infrastructure for it. We’re building tools that make it easy for publishers and content owners to set and enforce policies for how agents interact with their content.
Building a better Internet has always meant making sure it works for everyone — not just the people building the technology, but the people whose work and creativity make the Internet worth using. That doesn’t change in the age of agents. It becomes more important.
The platform for developers and agents
Our vision for the developer platform has always been to provide a comprehensive platform that just works: from experiment, to MVP, to scaling to millions of users. But providing the primitives is only part of the equation. A great platform also has to think about how everything works together, and how it integrates into your development flow.
That job is evolving. It used to be purely about developer experience, making it easy for humans to build, test, and ship. Increasingly, it’s also about helping agents help humans, and making the platform work not just for the people building agents, but for the agents themselves. Can an agent find the latest most up-to- date best practices? How easily can it discover and invoke the tools and CLIs it needs? How seamlessly can it move from writing code to deploying it?
This week, we’re shipping improvements across both dimensions — making Cloudflare better for the humans building on it and for the agents running on it.
Building for the future is a team sport
Building for the future is not something we can do alone. Every major Internet transition from HTTP/1.1 to HTTP/2 and HTTP/3, from TLS 1.2 to 1.3 — has required the industry to converge on shared standards. The shift to agents will be no different.
Cloudflare has a long history of contributing to and helping push forward the standards that make the Internet work. We’ve been deeply involved in the IETF for over a decade, helping develop and deploy protocols like QUIC, TLS 1.3, and Encrypted Client Hello. We were a founding member of WinterTC, the ECMA technical committee for JavaScript runtime interoperability. We open-sourced the Workers runtime itself, because we believe the foundation should be open.
We’re bringing the same approach to the agentic era. We’re excited to be part of the Linux Foundation and AAIF, and to help support and push forward standards like MCP that will be foundational for the agentic future. Since Anthropic introduced MCP, we’ve worked closely with them to build the infrastructure for remote MCP servers, open-sourced our own implementations, and invested in making the protocol practical at scale.
Last year, alongside Coinbase, we co-founded the x402 Foundation, an open, neutral standard that revives the long-dormant HTTP 402 status code to give agents a native way to pay for the services and content they consume.
Agent identity, authorization, payment, safety: these all need open standards that no single company can define alone.
Stay tuned
This week, we’re making announcements across every dimension of the agent stack: compute, connectivity, security, identity, economics, and developer experience.
The Internet wasn’t built for AI. The cloud wasn’t built for agents. But Cloudflare has always been about helping build a better Internet — and what “better” means changes with each era. This is the era of agents. This week, follow along and we’ll show you what we’re building for it.
За този поздрав се вдъхнових от Полина Паунова. Според нея всички имаме точно толкова право да се назовем изпълняващи функцията главен прокурор, колкото и Борислав Сарафов, след като и Конституционният съд се произнесе, че той заема този пост нелегитимно.
И вие ли като мен въздъхнахте с предпазливо облекчение, че светът още си е на мястото, когато се събудихте в сряда? Тръмп не изпълни заканата си да изличи цяла цивилизация, никой не пусна атомна бомба. Засега. Още имаме някакъв шанс да остареем – както се казва във филма на Лина Кривошиева „Какво е да остарееш в България“, чиято премиера беше на 5 април: остаряването си е привилегия, до която не всички се домогват.
Разбира се, за всичко са виновни либералите, които прекалиха с равните права и политическата коректност и тласнаха махалото в обратната посока. Сега всички може да сме спокойни, че най-големият проблем на човечеството е решен – хора, родени с пениси, няма да пречат на жените в олимпийските спортове. Е, намираме се в нещо като трета световна война, свободното пътуване е все по-затруднено, нападението над Иран доведе до недостиг на горива в световен план и силно затрудни редица сектори, светът, какъвто го познавахме, се разпада… ама това са дреболии.
Изобщо, защо да се притесняваме за някакви си войни в навечерието на един от най-големите християнски празници – Великден? Ето, на Тръмп не му е проблем да заплашва празнично, в компанията на великденски заек. Независимо дали сте пропуснали тази история, или не, препоръчвам новия брой на бюлетина „Гласовете на Америка“ на Йоанна Елми, в който пише за бомбардировки, молитви, великденски традиции и политика, без да пропускаме заека.
В тези интересни времена човек все по-често си задава въпроса: какво ще стане, ако САЩ излязат от НАТО? Искрен Иванов не само пита, а и отговаря какво биха загубили от подобен ход и САЩ, и Европа, както и кой би спечелил. Добрата новина е, че това не е много лесно да стане, макар да е възможно. Лошата – че докато шантажира, че ще го направи, Тръмп склонява Европа към още и още компромиси.
Но ако си задаваме много въпроси за бъдещето, може да се поболеем от притеснение. Ако не си ги задаваме обаче и оставяме другите да вземат важните решения, самото бъдеще ще стане вредно за здравето ни. Като стана дума за здраве, гледахте ли разговора на Владислав Севов с журналистката Надежда Цекулова? След рубриката ѝ за женското здраве нямам търпение да чета нейните предстоящи статии за палиативните грижи за деца.
Впрочем какво пише в предизборните програми за женското здраве? И изобщо за жените? След като прегледах програмите на всички партии и коалиции, регистрирани за изборите, мога да ви кажа: почти нищо. Та се замислих, че жените се превръщат в нещо като новите гейове – защитата на правата им се възприема като токсична дори от смятащите се за демократични партии. От жените се иска да раждат деца и да си знаят мястото.
Докато четях политически програми, си припомних какви предизборни студиа и дебати имаше едно време. И те имаха значение – например Петър Стоянов загуби битката за втория си президентски мандат не на последно място защото се поддаде на активно мероприятие по време на дебат.
В тазседмичната си статия Емилия Милчева разсъждава защо вече няма лидерски дебати. Според нея това не е инцидент, а устойчив модел на политическо поведение – нещо, с което не мога да не се съглася. Вместо в политиката да има спорове по същество, тя е фиксирана в скандали, краткосрочни сметчици и договорки зад камерите – без публика и без въпроси. И смърди – като развалено яйце.
От яйцата пак стигнахме до Великден. Ако се чудите защо се пише „воскресе“, какво е „воистину“ и изобщо как да разбираме воскръсналите (по Великден) словеса, знаете кой най-добре може да намести тази религиозна лексика в главите ни – разбира се, Павлина Върбанова.
Вече минаха 10 дни, откакто е воскръснала и българската редакция на „Свободна Европа“, след като беше закрита поради липса на финансиране. Или може би е по-точно да кажа, че се е преродила, защото сега се подвизава на нов сайт и под името „Свободна точка“. Препоръката ми тази седмица е да ѝ ударите едно рамо (банковата сметка може да намерите най-долу на сайта), защото без „Свободна Европа“, пардон, „Свободна точка“, българската журналистика рязко ще осиротее.
Разбира се, препоръчвам да подкрепите и нас, понеже съществуваме само благодарение на вашите дарения.
И да, знам, че даренията от аудиторията идват от едни и същи джобове и че тези джобове не са бездънни. Но все пак предпочитам малкото независими медии да се подкрепяме, а да не се възприемаме като конкуренти.
С пожелание за светли празници, ако празнувате, а ако не – спокойни дни,
The South Pacific Regional Fisheries Management Organization (SPRFMO) oversees fishing across roughly 59 million square kilometers (22 million square miles) of the South Pacific high seas, trying to impose order on a region double the size of Africa, where distant-water fleets pursue species ranging from jack mackerel to jumbo flying squid. The latter dominated this year’s talks.
Fishing for jumbo flying squid (Dosidicus gigas) has expanded rapidly over the past two decades. The number of squid-jigging vessels operating in SPRFMO waters rose from 14 in 2000 to more than 500 last year, almost all of them flying the Chinese flag. Meanwhile, reported catches have fallen markedly, from more than 1 million metric tons in 2014 to about 600,000 metric tons in 2024. Scientists worry that fishing pressure is outpacing knowledge of the stock.
As usual, you can also use this squid post to talk about the security stories in the news that I haven’t covered.
Building memory-intensive applications with AWS Lambda just got easier. AWS Lambda Managed Instances gives you up to 32 GB of memory—3x more than standard AWS Lambda—while maintaining the serverless experience you know. Modern applications increasingly require substantial memory resources to process large datasets, perform complex analytics, and deliver real-time insights for use cases such as in-memory analytics, Machine Learning (ML) model inference, and real-time semantic search. AWS Lambda Managed Instances gives you a familiar serverless programming model and experience combined with the flexibility of being able to choose the underlying Amazon EC2 instance types and providing developers with access to large memory configurations.
In this post, you will see how AWS Lambda Managed Instances enables memory-intensive workloads that were previously challenging to run in serverless environments, using an AI-powered customer analytics application as a practical example. You’ll see cost savings of up to 33% compared to standard Lambda for predictable workloads, while eliminating the operational overhead of managing EC2 instances.
Understanding AWS Lambda Managed Instances
AWS Lambda Managed Instances runs your AWS Lambda functions on the Amazon EC2 instance types of your choice in your account, including Graviton4 and memory-optimized instance types. AWS handles underlying infrastructure lifecycle including provisioning, scaling, patching, and routing, while you benefit from Amazon EC2 pricing advantages like Savings Plans and Reserved Instances.
Key benefits include:
Flexible instance selection: Choose from compute-optimized (C), general-purpose (M), and memory-optimized (R) instance families
Configurable memory-CPU ratios: Optimize resource allocation for your workload
Multi-concurrent invocations: One execution environment handles multiple invocations simultaneously, improving utilization for I/O-heavy applications
Dynamic scaling: Instances scale based on CPU utilization without cold starts
AWS Lambda Managed Instances is best suited for high-volume, predictable workloads that benefit from sustained compute capacity and larger memory configurations.
Memory-Intensive Workloads Work Best with AWS Lambda Managed Instances
This blog focuses on one of AWS Lambda Managed Instances’ most powerful capabilities: running memory-intensive workloads that require more than the standard AWS Lambda’s 10 GB memory and 250MB ZIP limits. Here are the use cases where AWS Lambda Managed Instances helps:
In-Memory Analytics — Load gigabytes of structured data into memory at initialization and serve sub-millisecond analytical queries across thousands of invocations
ML Model Inference — Keep large model weights resident in memory across invocations for consistent, low-latency inference without a dedicated endpoint.
Real-Time Semantic Search — Build vector similarity search over large embedding indexes held entirely in memory, enabling natural language queries over millions of records without an external vector database.
Graph Processing — Hold large graph structures in memory for traversal algorithms that require the full graph to be accessible at once.
Scientific & Numerical Computing — Run simulations, Monte Carlo methods, and large matrix operations that require substantial working memory and benefit from memory-optimized Amazon EC2 instance families.
Large-Scale Report Generation — Aggregate and transform multi-gigabyte datasets in memory to generate complex reports or dashboards on demand, without staging data through intermediate storage.
Use Case: AI-Powered Customer Analytics with AWS Lambda Managed Instances
To demonstrate the power of AWS Lambda Managed Instances for memory-intensive applications, we built an AI-Powered Customer Analytics application that combines in-memory data processing with ML-based semantic search. The application loads in memory 1 million customer behavioral records (sessions, purchases, browsing patterns) from a Parquet file in S3 into a Pandas DataFrame and an embeddings cache consuming 200MB, then responds for analytics queries:
Customer Analysis — Deep-dive into individual customer behavior: engagement scores, conversion rates, purchase patterns, and AI-generated customer segments
Semantic Search — Natural language queries powered by FastEmbed (sentence-transformers/all-MiniLM-L6-v2) that find similar customers using vector similarity
Cohort Analysis — Real-time segmentation by device, country, age group with aggregated metrics
Architecture Overview
Our AI-powered customer analytics application demonstrates this in practice: 1 million records in memory (200MB), a compact sentence transformer model for semantic search, sub-second query performance, and zero infrastructure to manage. The solution uses a simple, serverless architecture:
Customer transaction data (Parquet format) is stored in Amazon S3
Amazon Cognito User Pool authenticates users and issues JWT tokens for API access
Amazon API Gateway routes requests with Cognito authorizer validation, rate limiting (5 requests/second, burst 10), X-Ray tracing, and access logging
AWS Lambda function with AWS Lambda Managed Instances loads the entire dataset (200MB) and all-MiniLM-L6-v2 model (900MB) into memory during initialization while also performing a threaded embeddings cache generation. This step can consume about 14GB of the allocated memory, exceeding standard AWS Lambda’s 10 GB limit
Analytics queries execute against the in-memory data using the model
Results are returned in milliseconds for interactive analysis
Deploy the Application
The below steps walk you through deploying the application to AWS using the AWS Serverless Application Model (SAM). The deployment process packages your Lambda function code, uploads artifacts to Amazon S3, and provisions all required AWS resources including Lambda functions, IAM roles, and any configured VPC networking via AWS CloudFormation.
Prerequisites
Make sure you have the following tools installed locally:
The complete source code for this application is available in our GitHub repository. To deploy it yourself follow the below steps and refer to the full deployment instructions hosted on GitHub.
This script will create an S3 bucket (if needed), generate 1M rows of sample data, and upload the data to S3.
4. Build and deploy the Lambda function
./deploy-lambda.sh
This script will build the container image with FastEmbed, push it to ECR, and deploy the Lambda function along with Capacity Provider, API Gateway, and Cognito User Pool. After deployment, it automatically generates the UI authentication configuration and prompts you to create a test user.
Run the Application
1. Start the UI
The application includes a simple HTML-based UI through which you can test the AWS Lambda function using Amazon API Gateway:
cd ui && python3 -m http.server 8000
2. Open your browser at http://localhost:8000 and click ‘Sign In’ to authenticate via Cognito using the username/password that you created during deployment
3. Enter your API endpoint URL. Test connection and click system Info.
Test the Application
a. Customer Analysis — Enter one or more User IDs to get more information on the customer behavior: engagement scores, conversion rates, purchase patterns, and AI-generated customer segments
b. Semantic Search – Enter natural language queries like “list high value customers from USA” in the Semantic Search and verify the results. Note that the response is very fast as the analytics data and FastEmbed models are loaded into memory during init stage
c. Cohort Analysis — Enter the query data to get Real-time segmentation by device, country, age group with aggregated metrics
Observability
AWS Lambda Managed Instances automatically publishes metrics to Amazon CloudWatch, giving you visibility into function performance and capacity utilization. Monitor InitDuration to track dataset and model load time at startup, MaxMemoryUsed to confirm your data fits within configured memory, and ProvisionedConcurrencySpilloverInvocations to detect when AWS Lambda Managed Instances capacity is exhausted.
Enable AWS Lambda Insights for enhanced per-invocation metrics including CPU time and memory utilization over time. Use Amazon CloudWatch Log Insights to query INIT_START, INIT_END, and REPORT log entries for initialization and memory details per invocation.
What Makes This Better with AWS Lambda Managed Instances
Without AWS Lambda Managed Instances, building this same application would require one of these alternatives:
Option A: EC2 with auto-scaling — Full control, full responsibility: patching, scaling policies, load balancing, and deployment pipelines — all on you.
Option B: Redesign for standard Lambda — Swap in-memory data for an external database and replace the ML model with Amazon SageMaker endpoint. More latency, more cost, more complexity.
With AWS Lambda Managed Instances, you write a single AWS Lambda function, define a Capacity Provider, and deploy with SAM. AWS Lambda handles the Amazon EC2 instances, scaling, and lifecycle, giving you the memory you need with the operational simplicity you want. The in-memory approach eliminates network latency and disk I/O, delivering consistent sub-200ms response times for complex analytics.
Cost Considerations
AWS Lambda Managed Instances uses Amazon EC2-based pricing with a management fee. For predictable workloads, you can leverage Amazon EC2 Savings Plans or Reserved Instances to reduce costs significantly.
Example cost comparison (us-east-1, 32 GB memory, 1M invocations/month):
The cost benefits increase with higher memory configurations and sustained workloads that can take advantage of Amazon EC2 pricing discounts.
Best Practices
Based on experience building this solution, here are key recommendations:
Memory sizing: Start with your dataset size plus 50% overhead for processing. Monitor Amazon CloudWatch metrics to optimize.
Initialization strategy: Load large datasets during the init phase to amortize the cost across multiple invocations.
Concurrency configuration: Set PerExecutionEnvironmentMaxConcurrency based on your workload’s I/O characteristics. Higher values work well for I/O-bound analytics.
Data format: Use columnar formats like Parquet for efficient memory usage and fast loading.
Monitoring: Track initialization duration, memory utilization, and invocation latency in Amazon CloudWatch to identify optimization opportunities.
Cleanup
When you’re done exploring the solution, it’s good practice to remove all provisioned resources to avoid ongoing charges. For the full cleanup commands and exact steps, refer to the project’s README.md in GitHub repository.
Conclusion
AWS Lambda Managed Instances opens up a new class of serverless applications that support larger AWS Lambda layer packages and more memory. Memory-intensive workloads — in-memory analytics, ML inference, graph processing, scientific computing — can now run with the simplicity of AWS Lambda and the resources of Amazon EC2. The customer analytics example demonstrates how in-memory processing with AWS Lambda Managed Instances delivers performance improvements over traditional database queries while maintaining serverless benefits like automatic scaling and pay-per-use pricing.
This week, we have added new modules to Metasploit Framework targeting Cisco Catalyst SD-WAN controllers and osTicket as well as updates and improvements to Windows service-for-user persistence, and LDAP/ADCS-related modules to automatically report related services resulting in an improved data stream, which can be queried by using the services command.
We also landed an improvement to msfvenom’s bootup time, thanks to bcoles, resulting in an approximate two-times speedup.
New module content (4)
AD/CS Authenticated Web Enrollment Services Module
Authors: Spencer McIntyre, bwatters-r7, and jhicks-r7
Description: This adds a new auxiliary/admin/http/web_enrollment_cert modules that allows certificates to be issued from an Active Directory Certificate Services Web Enrollment portal. Its usage is the same as the auxiliary/admin/http/icpr_cert module but enables operators to issue certificates when the web enrollment portal is accessible but the MS-ICPR service is not.
Description: This adds an auxiliary module to exploit an authentication bypass vulnerability, CVE-2026-20127, affecting Cisco Catalyst SD-WAN Controller. Recently exploited in the wild as a zero-day.
osTicket Arbitrary File Read via PHP Filter Chains in mPDF
Authors: Arkaprabha Chakraborty <@t1nt1nsn0wy> and HORIZON3.ai Team
Description: Updates the Windows service-for-user persistence technique.
Enhancements and features (5)
#20973 from bitstr3m-48 – This release enables command execution for non-interactive HWBridge sessions via the sessions -c flag. Additionally, the hwbridge/connect module now preserves parsed JSON error bodies from failed HTTP responses, which improves error messaging.
#20977 from g0tmi1k – This updates the exploit/unix/webapp/php_eval module to have a FORMDATA datastore option, which adds HTTP POST-request support and makes the HEADERS datastore option consistent with other modules.
#20979 from g0tmi1k – This updates the exploit/unix/webapp/php_include module with additional datastore options and make its usage more consistent with the similar exploit/unix/webapp/php_eval module.
#21031 from zeroSteiner – Enhances the Metasploit’s LDAP/ADCS-related modules to automatically report related services (LDAP, DCERPC/ICertPassage/ADCS CA) and to improve vulnerability reporting by associating findings with the affected LDAP object’s DN (and, for ADCS template findings, the template name) so results are uniquely keyed and easier to interpret.
#21229 from bcoles – This updates the msfvenom utility to use the metadata cache. The result is roughly 2x faster execution times when listing modules.
Bugs fixed (1)
#21153 from Nayeraneru – This fixes an issue with some mutable constant datastore options. Using shared options like CHOST or CPORT are not changing visibility across modules anymore.
Documentation added (1)
#21221 from cgranleese-r7 – This PR improves module_doc_template.md with examples to better guide contributors.
You can always find more documentation on our docsite at docs.metasploit.com.
Missing rn-* label on Github (3)
PLEASE ADD RN-TAGS TO THESE PULL REQUESTS BEFORE RELEASING THE WRAP UP, AND RERUN THE WRAPUP SCRIPT
#7 from scriptjunkie – Not written – add release notes directly to the pull request, then regenerate. Do not edit manually without ensuring the pull request has the release note present.
#20814 from h00die – Not written – add release notes directly to the pull request, then regenerate. Do not edit manually without ensuring the pull request has the release note present.
#21143 from SaiSakthidar – This bumps the Metasploit payloads to include changes that enable the PHP Meterpreter to open TCP server sockets. This enables operators to listen for inbound connections on compromised hosts and closes a feature gap between PHP and the other Meterpreters.
Get it
As always, you can update to the latest Metasploit Framework with msfupdate and you can get more details on the changes since the last blog post from GitHub:
Cloudflare’s network recently passed a major milestone: we crossed 500 terabits per second (Tbps) of external capacity.
When we say 500 Tbps, we mean total provisioned external interconnection capacity: the sum of every port facing a transit provider, private peering partner, Internet exchange, or Cloudflare Network Interconnect (CNI) port across all 330+ cities. This is not peak traffic. On any given day, our peak utilization is a fraction of that number. (The rest is our DDoS budget.)
It’s a long way from where we started. In 2010, we launched from a small office above a nail salon in Palo Alto, with a single transit provider and a reverse proxy you could set up by changing two nameservers.
The early days of transit and peering
Our first transit provider was nLayer Communications, a network most people now know as GTT. nLayer gave us our first capacity and our first hands-on company experience in peering relationships and the careful balance between cost and performance.
From there, we grew city by city: Chicago, Ashburn, San Jose, Amsterdam, Tokyo. Each new data center meant negotiating colocation contracts, pulling fiber, racking servers, and establishing peering through Internet exchanges. The Internet isn’t actually a cloud, of course. It is a collection of specific rooms full of cables, and we spent years learning the nuances of every one of them.
Not every city was a straightforward deployment, having to deal with missing hardware, customs strikes, and even dental floss. In a single month in 2018, we opened up in 31 cities in 24 days: from Kathmandu and Baghdad to Reykjavík and Chișinău. When we opened our 127th data center in Macau, we were protecting 7 million Internet properties. Today, with data centers in 330+ cities, we protect more than 20% of the web.
When the network became the security layer
As our footprint grew, customers asked for more than just website caching. They needed to protect employees, replace aging Multiprotocol Label Switching (MPLS) circuits, and secure entire enterprise networks. Instead of traditional appliances, we built systems to establish secure tunnels to private subnets and advertise enterprise IP space directly from our global network via BGP.
The scale of threats grew in parallel. In 2025, we mitigated a 31.4 Tbps DDoS attack lasting 35 seconds. The source was the Aisuru-Kimwolf botnet, including many infected Android TVs. It was one of over 5,000 attacks we blocked that day. No engineer was paged.
A decade ago, an attack of that magnitude would have required nation-state resources to counter. Today, our network handles it in seconds without human intervention. That is what operating at a 500 Tbps scale requires: moving the intelligence to every server in our network so the network can defend itself.
How our network responds to an attack
Here is what actually happens when an attack hits our network. Packets arrive at the network interface card (NIC) and immediately enter an eXpress Data Path (XDP) program chain managed by xdpd, running in driver mode. Among the first programs in that chain is l4drop, which evaluates each packet against mitigation rules in extended Berkeley Packet Filter (eBPF). Those rules are generated by dosd, our denial of service daemon, which runs on every server in our fleet. Each dosd instance samples incoming traffic, builds a table of the heaviest hitters it sees, and broadcasts that table to every other instance in the colo. The result is a shared colo-wide view of traffic, and because every server works from the same data, they reach the same mitigation decision.
When dosd detects an attack pattern, the resulting rule is applied locally via l4drop and propagates globally via Quicksilver, our distributed key-value (KV) store, reaching every server in every data center within seconds. Only after surviving l4drop do packets reach Unimog, our Layer 4 (L4) load balancer, which distributes them across healthy servers in the data center. For Magic Transit customers routing enterprise network traffic through our edge, flowtrackd adds a further layer of stateful TCP inspection, tracking connection state and dropping packets that don’t belong to legitimate flows.
The 31.4 Tbps attack we mitigated followed exactly this path. No traffic was backhauled to a centralized scrubbing center. No human intervened. Every server in the targeted data centers independently recognized the attack and began dropping malicious packets at line rate, before those packets consumed a single CPU cycle of application processing. The software is only half the story: none of it works if the ports aren’t there to absorb the traffic in the first place.
A distributed developer platform
Running code on every server in our network was a natural consequence of controlling the full stack. If we already ran eBPF programs on every machine to drop attack traffic, we could run customer application code there too. That insight became Workers, and later KV and Durable Objects.
Our developer platform runs in every city we operate in, not in a handful of cloud regions. In 2025, we added Containers to Workers, so heavier workloads can run at the edge too. V8 isolates and custom filesystem layers minimize cold starts. Your code runs where your users are, on the same servers that drop attack traffic at line rate via l4drop. Attack traffic is dropped before it reaches the network stack. Your application never sees it.
Forward-looking protocols: IPv6, RPKI, ASPA
We were early adopters of IPv6 and Resource Public Key Infrastructure (RPKI). BGP hijacks cause real outages and security breaches. RPKI allows us to drop invalid routes from peers, ensuring traffic goes where it is supposed to. We sign Route Origin Authorizations (ROAs) for our prefixes and enforce Route Origin Validation on ingress. We reject RPKI-invalid routes, even when that occasionally breaks reachability to networks with misconfigured ROAs.
Autonomous System Provider Authorization (ASPA) is next. RPKI validates who owns a prefix. ASPA validates the path it took to get here. RPKI is a passport check at the destination, confirming the right owner, while ASPA is a flight manifest check: it verifies every network the traffic passed through. A route leak is like a passenger who boarded in the wrong city; RPKI would not catch it, but ASPA will.
Current ecosystem adoption for ASPA looks like RPKI did in 2015. We were one of the first networks to deploy RPKI at scale, and today, 867,000 prefixes in the global routing table have valid RPKI certificates, up from near zero a decade ago. At our scale, the protocols we choose have real consequences for the broader Internet. We push for adoption early because waiting means more hijacks and more leaks in the meantime.
AI agents and the evolving Internet
AI has changed what it means to have a presence on the web. For most of the Internet’s history, traffic was human-generated, by people clicking links in browsers. Today, AI crawlers, model training pipelines, and autonomous agents now account for more than 4% of all HTML requests across our network, comparable to Googlebot itself. “User action” crawling, where an AI visits a page because a human asked it a question, grew over 15x in 2025 alone.
AI crawlers behave differently than browsers at the infrastructure level. Browsers load a page and stop. Crawlers instead fetch every linked resource at maximum throughput with no pause between requests. At our scale, distinguishing legitimate AI crawling from actual attacks is a real engineering problem. Our detection systems use a combination of verified bot IP ranges, TLS fingerprinting, behavioral analysis, and robots.txt compliance signals to make that distinction, and to give site owners the data they need to decide which crawlers to allow.
At the TLS layer, for example, a legitimate browser presents a ClientHello with a predictable set of cipher suites, extensions, and ordering that matches its declared User-Agent. A crawler spoofing that User-Agent but using a stripped-down TLS library will present a different fingerprint, and that mismatch is one of the signals our systems use to classify the request before it reaches the origin.
Help us build the next 500 Tbps
What started above a nail salon in Palo Alto is now a 500 Tbps network in 330+ cities across 125+ countries, where every server runs our developer platform and security services, not just cache. That is sixteen years of architectural decisions compounding, and we owe it to the 13,000+ networks and partners who peer with us. We are not done.
If you are a network operator, peer with us. Our peering policy and interconnection details are on PeeringDB. If you are interested in embedding Cloudflare infrastructure directly within your network, reach out to our team at [email protected], to join the Edge Partner Program.
When members log into Netflix, one of the hardest choices is what to watch. The challenge isn’t a lack of options — there are thousands of titles — but finding the most intriguing one is complex and deeply personal. To help, we surface personalized promotional assets, especially the show synopsis — a brief description highlighting key plot elements, with cues like genre or talent.
Strong synopses help members scan, understand, and choose. Poor synopses frustrate, mislead, and drive abandonment. Ensuring high-quality synopses is essential, but scaling quality validation is hard. We host hundreds of thousands of synopses, usually with multiple variants per show. We need to ensure quality at scale so every member gets a consistently great experience every time they read a synopsis. This approach helps us scale high‑quality synopsis coverage for our rapidly expanding catalog, enabling greater speed and coverage without sacrificing quality.
This report outlines our LLM-based approach for evaluating synopsis quality. Using recent advances in agents, reasoning, and LLM-as-a-Judge, we score four key synopsis quality dimensions, achieving 85%+ agreement with creative writers. Additionally, we show that higher LLM judge quality is correlated with key streaming metrics, allowing us to proactively identify and fix impactful issues weeks or months before a show debuts on Netflix.
The Making of a “Good” Synopsis
Writing high-quality synopses requires creative expertise. Our expert creative leads are best positioned to craft the creative approaches and define quality standards. However, AI can help us consistently evaluate these expert-driven quality criteria at scale. Synopsis quality at Netflix, which our system aims to predict, is viewed along two dimensions:
Creative Quality: members of our creative writing team assess synopsis quality according to our internal writing guidelines and rubrics.
Member Implicit Feedback: we measure the relative impact of a particular show synopsis on core streaming metrics.
These two definitions of quality capture distinct and important aspects of quality, one focused upon creative excellence and the other upon utility to members.
Creative Quality
For this project, we evaluate synopses against a subset of our creative writing quality rubric — the same criteria to which human writers would adhere. These quality rubrics change over time, and more details on the current quality standards can be found in our Editorial Style Guide and Technical Style Guide. Given Netflix’s distinctive voice and elevated editorial standards, the quality bar is high. Each criterion has extensive guidelines with examples across regions, genres, and synopsis types.
Human evaluation. We began by partnering with a group of creative writing experts to iteratively refine our definition of creative quality. We initially labeled ~1,000 diverse synopses, where three expert writers scored each against the criteria and explained their ratings. Due to the subjectivity of the task, early instance-level agreement was low. To reach a better consensus, we conducted calibration rounds (~50 synopses per round), surfaced disagreements, and evolved our quality scoring guidelines. Key interventions that were found to improve agreement include:
Using binary scores (instead of 1–4 Likert scores).
Allowing writers to reference past examples.
Maintaining a searchable taxonomy of common errors.
Golden evaluation data. After eight calibration rounds, writer agreement reached ~80%. To further stabilize labels, we used a model-in-the-loop consensus where:
Multiple writers score each synopsis.
An LLM, guided by the rubric, aggregates to a final label.
Writers review cases with substantial disagreement.
The result is a golden set of ~600 synopses with binary, criteria-level scores and explanations — our North Star for aligning an LLM judge with expert opinion.
Member Implicit Feedback
Netflix gauges implicit member feedback on a synopsis with two metrics:
Take Fraction: how often members who see a title’s synopsis choose to start watching it.
Abandonment Rate: how often members start a title but stop watching soon after.
Higher take fraction indicates more choosing, while lower abandonment suggests authentic, non-misleading presentation. Both of these metrics have been validated via A/B testing to serve as short-term behavioral proxies for long-term member retention. As part of evaluating our system, we also study the ability of LLM-derived quality scores to predict short-term engagement metrics. This step confirms that our scores capture behaviorally meaningful signals and assesses our ability to forecast member response to a given synopsis.
Scaling Quality Scoring with LLM-as-a-Judge
We begin our experiments by creating simple, per-criteria prompts that:
Using a single prompt to evaluate all quality criteria is found to overload the LLM and yields poor performance — dedicated judges for each criteria perform better. Because criteria are unique, each task has its own setup, but there are some shared components:
We use the same LLM for all criteria.
The judge always outputs an explanation before its final score.
Final scores are binary.
Due to our use of binary scoring, judges can be evaluated with simple accuracy metrics over the golden dataset. Next, we summarize the experiments that led to our final system.
Prompt optimization. Because LLMs are sensitive to prompt phrasing, we apply Automatic Prompt Optimization (APO) over a ~300-sample dev set. Scoring guidelines are provided as additional context to the prompt optimizer. After APO, we manually refine candidate prompts with the help of an LLM, yielding initial prompts with accuracies shown below. These prompts work well for some criteria (e.g., precision) but poorly for others (e.g., clarity), highlighting criterion-specific nuances.
Improved reasoning. Many failures of our initial system arise due to a lack of accurate reasoning through highly-subjective evaluation examples. To improve reasoning accuracy, we leverage two forms of inference-time scaling:
Longer rationales: increase the length of the rationale or explanation generated by the LLM prior to producing a final score.
Consensus scoring: sample several outputs from the LLM and aggregate their scores to produce the final result.
Tiered rationales. Using tone as an example, we tested whether longer rationales are helpful by defining three rationale length tiers (shown above) and comparing their accuracies. Accuracy rises with longer rationales but returns are diminishing. Medium rationales noticeably outperform short ones, while long rationales offer only a slight additional gain; see below.
Longer rationales improve performance but degrade human-readability, which is problematic given that explanations are key pieces of evidence for creative experts. As a solution, we adopt tiered rationales: the judge reasons at any length but concisely summarizes its reasoning process prior to the final score. Tiered rationales preserve the benefits of extended reasoning, make outputs easier to inspect, and even benefit scoring accuracy. For example, our tone evaluator improves from 86.55% to 87.85% binary accuracy when using tiered rationales.
Consensus scoring. We can also allocate more inference-time compute by sampling multiple outputs per synopsis and aggregating their scores. We aggregate via a rounded average to ensure that the final score remains binary. For tone and clarity criteria with tiered rationales, 5× consensus scoring yields a clear accuracy boost as shown below.
Consensus scoring on the precision evaluator, which uses a vanilla (short) chain-of-thought, yields no benefit. As an explanation, we notice that longer rationales increase variance in scores across multiple outputs, while short rationales yield consistent scores. Consensus may be most useful for evaluators with longer rationales, where it helps to stabilize score variance. When shorter rationales are used, all scores tend to be the same, making consensus less meaningful.
What about reasoning models? While our setup elicits reasoning from a standard LLM, we also explored quality scoring with true reasoning models (i.e., models that generate long reasoning trajectories prior to final output). For tone, using a reasoning model with 5× consensus yields improving accuracy with increasing reasoning effort, even outperforming tiered rationales at the highest reasoning effort; see below. However, we skip reasoning models in our final system, as they significantly increase inference costs for only a marginal performance gain.
Agents-as-a-Judge for factuality. Synopses have four common types of factuality errors:
Detecting these factuality errors requires comparing the synopsis to ground-truth context, where necessary context varies per criteria. For example, plot information requires a plot summary or script, while award information needs a list of awards. As we have learned, simplicity drives reliability: too much context or too many criteria harms accuracy. Motivated by this idea, we adopt factuality agents, where each agent evaluates one narrow aspect of factuality.
An agent receives context tailored to one facet of factuality and produces both a rationale and a binary factuality score. The final score of the Agents-as-a-Judge system is the minimum factuality score across agents — any failed aspect yields an overall fail. All rationales are fed to an LLM aggregator to produce a combined rationale to accompany the final score. As shown below, leveraging factuality agents significantly benefits scoring accuracy. Further benefits are achieved by using tiered rationales and consensus scoring within each agent.
Final system. In summary, our automatic evaluation system uses a combination of standard LLM-as-a-Judge, tiered rationales, consensus scoring, and Agents-as-a-Judge to maximize binary scoring accuracy for each criteria. A summary of the techniques used for each criteria and the associated binary scoring accuracy is provided below.
Member Validation of LLM-as-a-Judge
Beyond expert agreement, we also study how LLM-as-a-Judge scores relate to member behavior. This analysis serves two goals:
Further validating LLM-judge accuracy.
Linking creative quality to member-perceived quality.
Framed as predictors of member outcomes, LLM judges help us assess how promotional assets affect viewing and determine which creative attributes matter most to members discovering content they enjoy. To perform this analysis, we take advantage of the fact that most shows have multiple, personalized synopses (i.e., a synopsis “suite”). Using this suite, we can measure the causal effect of synopsis selection on metrics like take fraction and abandonment rate.
Our methodology. We correlate synopsis performance (take fraction or abandonment) with LLM quality scores. Specifically, within each show s, we relate changes in a synopsis’s LLM score to changes in its performance, normalizing by the show-level standard deviation and clustering standard errors by show; see below.
β captures the average association between within-show changes in LLM score and changes in performance. While we don’t have clean, experimental variation in LLM scores, this analysis still validates predictive value and practical utility.
Member-focused results. We report correlations for individual LLM criteria and a “Weighted Score” that combines all criteria to reduce noise and maximize signal from behavioral data. As shown below, results show promising prediction of take fraction and abandonment. Precision and clarity are especially predictive, and the weighted score provides a statistically useful signal of higher take and lower abandonment. In short, LLM evaluators capture factors that matter to members, making them a valuable tool for monitoring synopsis quality and engagement.
Closing Remarks
The LLM-as-a-Judge system used to evaluate show synopses at Netflix is the result of extensive experimentation grounded in both creative expertise and member outcomes. Building an automatic evaluation system that works reliably in practice is hard, and the approach we have described reflects countless lessons learned through iteration to improve accuracy and scalability. We have validated the system extensively with human evaluation at both the system and component levels, and we have shown that its outputs correlate with key streaming metrics. As a result, we are confident that it captures the dimensions of synopsis quality that matter most — both creatively and from the member perspective — which has driven its widespread adoption in the Netflix synopsis authoring workflow.
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.