标签：#AWS

The 10-Minute Tax For many years, as a CDK developer, I'd run cdk synth , then cdk deploy , and then cross my fingers — either it deployed cleanly, or it failed somewhere in the middle of a CloudFormation run that had already been going for ten minutes: ❌ MyStack failed: UPDATE_ROLLBACK_COMPLETE Resource handler returned message: "The runtime parameter of nodejs16.x is no longer supported" (HandlerErrorCode: InvalidRequest) Ten minutes. For something CDK could have told you before it ever talked to CloudFormation. These days I let AI agents write a good chunk of my CDK code, which made this even worse — an agent can't iterate when every failed attempt costs it ten minutes. 🤖 AI Agent development loop: Attempt 1: cdk deploy → ⏱️ 10 min → ❌ deprecated runtime Attempt 2: cdk deploy → ⏱️ 10 min → ❌ invalid memory size Attempt 3: cdk deploy → ⏱️ 10 min → ❌ security group rule conflict Attempt 4: cdk deploy → ⏱️ 10 min → ✅ finally works Total time wasted: 30 minutes on things that were knowable at synth time. And if you're deploying something heavy like an Amazon EKS cluster, the penalty stretches to 25-30 minutes per failed attempt. What if the CDK could catch all of those on cdk synth — in seconds? The CDK Lifecycle: Where Validation Fits Before I show off the new validation, it helps to see where it plugs into the lifecycle every cdk deploy goes through: Stage What Happens Executed By 1. Construction Execute main.ts , call new Stack() , build the construct tree in memory CDK App (local) 2. Synth app.synth() traverses the tree, produces CloudFormation template to cdk.out/ CDK App (local) 3. Template Validation 🆕 Post-synth offline validation — default rule set + registered policy plugins CDK App (aws-cdk-lib, local) 4. Create Change Set 🆕 CloudFormation pre-deployment validation — 6 types of online checks against real account state CloudFormation (AWS) 5. Execute Change Set CloudFormation provisions/updates/deletes actual AWS resources CloudFormation (AWS) The gap was a

Aptoide has brought its games store back to Google Play after more than a decade, as court-ordered changes open Android to competing app stores.

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

If you are staring at An error occurred (AccessDenied) when calling the GetObject operation: Access Denied , this guide walks through every cause in the order you should check them, with the exact fix for each. I am a cloud associate and I debug this error often enough that I keep a mental checklist. Here it is, written down. Quick answer: the 8 most common causes of S3 Access Denied In Amazon S3, "Access Denied" means the request was authenticated but not authorized, or an explicit deny blocked it. In practice it is almost always one of these, roughly in order of frequency: The IAM identity (user or role) is missing the required s3: permission. The bucket policy does not allow the action, or explicitly denies it. S3 Block Public Access is on and you expected public/anonymous access. SSE-KMS : you have S3 permission but not kms:Decrypt on the encryption key. Missing s3:ListBucket , which turns a "key not found" into a 403. Cross-account access where only one side grants permission. An explicit Deny somewhere wins (SCP, permissions boundary, VPC endpoint policy, or bucket policy). Object ownership / ACLs after a cross-account upload. If you only remember one thing: an explicit Deny anywhere in the chain always beats an Allow . Start by finding a deny, then work down the list. Step 0: Confirm which identity is actually making the request Before touching any policy, confirm who you are. Most "but I have admin" cases are the wrong principal. aws sts get-caller-identity Check the Arn in the output. If it is a role you did not expect (an EC2 instance profile, a CI role, an assumed role), you have been debugging the wrong identity's permissions the whole time. This single command saves more time than any other step. Step 1: Does the IAM identity policy allow the action? S3 needs the specific action for the specific resource. The two resource types trip people up: Bucket-level actions ( s3:ListBucket , s3:GetBucketLocation ) target the bucket ARN: arn:aws:s3:::my-bucket Obj

The service was slow. Not down, just slow: p95 latency climbing well past where users notice, requests piling up, the kind of degradation that generates support tickets instead of alerts. And the autoscaler, the whole point of which is to add capacity when a service is under strain, sat there doing nothing. The metric it was watching said everything was fine. Average CPU utilization on the tasks was hovering around 30 percent, nowhere near the scale-out threshold. The dashboard was calm. The users were not. Both were right, and the gap between them is one of the most common autoscaling traps on a container platform. This is the first article in a series on running a multi-tenant SaaS on AWS at team scale. It is about a metric that lies, quietly, by design. Why 30 percent CPU meant 100 percent busy The service was a single-threaded application. A Node.js API, in this case, but the same is true of any process that does its real work on one thread: a classic Python or Ruby worker, most single-process runtimes. A single-threaded process can, by definition, saturate exactly one CPU core. The task it was running on had four vCPUs. So the arithmetic that matters is brutally simple: one core fully pegged / four vCPUs on the task = ~25% task-average CPU At full saturation, the busiest that process can ever make the task look is about 25 percent. Add a little async I/O overhead spread across the runtime and you land around 30 percent. That is not a service with headroom. That is a service redlining on the only core it can use, while three cores sit idle and drag the average down to a number that reads as "barely working." The autoscaling policy was tracking average CPU across the task's cores. For a workload that can only ever use one of them, that average is not a measure of load. It is a measure of load divided by four. The metric was answering a different question This is the real lesson, and it is not specific to AWS or ECS. Average CPU utilization answers "how much of th

The bug that isn't a bug On Tuesday you attach a dead-letter queue to orders-queue . On Wednesday a batch of messages disappears and you ask Claude Code what happened. It answers immediately: orders-queue has no DLQ configured, so failed messages are dropped after the maximum receive count. That answer is wrong, and it is also not a hallucination. The assistant read a real snapshot of your AWS account. The snapshot was taken Monday. This is the failure mode that shows up once you give an AI assistant deterministic infrastructure context instead of letting it guess. Guessing produces answers that feel uncertain, and you treat them accordingly. A stale snapshot produces answers that feel authoritative, with real table names, real queue names, real ARNs. Nothing in the response signals that the underlying facts expired. Infrawise extracts your DynamoDB tables, Lambda configs, queue settings, database schemas, and code-to-table access patterns into a graph, then serves that graph to AI editors over MCP. Everything below is about the part nobody asks for in a feature list: what happens to that graph when it gets old. Why the context has to be cached at all The obvious fix is to never cache. Answer every question from a live account read. That does not survive contact with an actual session. A full infrawise analyze walks every enabled service, paginating through DynamoDB DescribeTable , Lambda configurations and their event source mappings, SQS queue attributes, SNS subscriptions and filter policies, Secrets Manager rotation state, S3 versioning and public-access configuration, ElastiCache clusters, CloudWatch log groups, plus schema introspection against Postgres, MySQL, or MongoDB, plus a local IaC parse, plus an AST scan of the repository. Every extractor is dispatched through a single Promise.all , so wall-clock time is bounded by the slowest one rather than their sum, but it is still seconds, not milliseconds. An assistant calls get_infra_overview at the start of a

Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps. Route 53 is where networking meets the internet — how domain names reach your applications, how traffic gets distributed intelligently, and how AWS and on-premises networks resolve each other's names. 📋 Topics Covered # Topic Type 1 DNS Pre-Requisites — How DNS Works Concept 2 Complete DNS Resolution Flow Concept + Interview 3 What is Route 53 Concept 4 Hosted Zones — Public vs Private Concept + Lab 5 Hosted Zone ID Concept + DevOps 6 DNS Record Types and Use Cases Concept + Cert 7 NS and SOA Records — Auto-Created, Never Delete Concept + Interview 8 Alias Record — AWS-Specific Concept + Cert 9 Landing Zone — Brief Context Concept 10 Route 53 Routing Policies — All 8 Concept + Cert 11 Route 53 Traffic Policies Concept + DevOps 12 Route 53 Resolvers Concept + Interview 13 Inbound vs Outbound Resolver Endpoints Concept + Interview 14 Route 53 Forwarders Concept + Interview 15 Split-Horizon DNS Concept + Interview 16 Interview Questions Interview 17 Practice Tasks Practice DNS Pre-Requisites — How DNS Works DNS is the reason you type google.com instead of 142.250.195.46 . Before understanding Route 53, these fundamentals must be solid. Core Vocabulary Term What it means Domain Human-readable name — google.com , tejascloud.in IP Address Machine address — 54.21.11.90 — what computers actually use DNS The translation system — converts domain names → IP addresses TLD Top-Level Domain — the last part after the final dot TTL Time To Live — how long a DNS response is cached before re-querying Recursive Resolver Finds the answer for the client by querying other DNS servers, caches the result Authoritative DNS Server Stores the official DNS records for a domain — returns the definitive answer Common TLDs: .com → commercial · .org → organizations · .net → network · .in → India · .uk → United Kingdom · .edu → education · .gov → government The Complete DNS Resolution Flow This is the full journe

Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps. This session completes the database picture — Aurora's read/write architecture, ElastiCache caching strategies, and DynamoDB from table creation to production-ready query patterns. 📋 Topics Covered # Topic Type 1 Aurora Endpoints — Writer vs Reader Concept + Interview 2 What Happens When the Aurora Writer Fails Concept + Cert 3 ElastiCache Caching Patterns — Lazy Loading, Write Through, Session Store Concept + Interview 4 Cache Invalidation Concept + Interview 5 DynamoDB — What It Is and When to Use It Concept + Interview 6 DynamoDB Table Creation — Keys and Settings Concept + Lab 7 Table Classes — Standard vs Standard-IA Concept + Cert 8 Capacity Modes — On-Demand vs Provisioned Concept + Cert 9 Warm Throughput Concept + Cert 10 DynamoDB Items & Attributes — CRUD Operations Concept + Lab 11 Query vs Scan — The Critical Difference Concept + Interview 12 Local Secondary Index (LSI) vs Global Secondary Index (GSI) Concept + Cert 13 Bonus Concepts — Streams, DAX, Consistency, Transactions Concept + Interview 14 Interview Questions Interview 15 Practice Tasks Practice Aurora Endpoints — Writer vs Reader Aurora doesn't give you just one database endpoint — it gives you two, each serving a different purpose and routing to different parts of the cluster. Writer Endpoint (Primary Endpoint): Always points to the current primary/writer instance. All write operations (INSERT, UPDATE, DELETE) go here. If a failover happens and a replica is promoted, Aurora automatically redirects this endpoint to the new writer — your application's configuration never needs to change. Reader Endpoint: A load-balanced endpoint that distributes read-only queries (SELECT) across all available Aurora Replicas. You don't manage which replica serves each query — Aurora handles the routing, spreading read traffic evenly across however many replicas exist. Why this architecture matters: In a typical application, read

My Terraform drift pipeline could detect a manual EC2 tag change, classify it as LOW, and run Terraform to remove it. Then the pipeline moved on. The evidence existed, but it was spread across CodeBuild output, Lambda logs, and an SNS message. If I wanted to know what changed, how it was classified, and whether remediation started, I had to reconstruct the event from multiple AWS services. The pipeline could act on drift. It could not remember drift. Phase 4 added that memory: a durable DynamoDB record, a read only API, and a small dashboard that turns the event history into something I can inspect without opening three AWS consoles. The Stack Terraform drift event ↓ SNS ↓ Severity Lambda ├── classifies HIGH / MEDIUM / LOW ├── starts remediation for eligible LOW drift └── writes the audit event to DynamoDB ↓ API Gateway HTTP API ↓ Read only Lambda ↓ DynamoDB Query ↓ CloudFront → static dashboard ↑ private S3 bucket The browser receives static HTML, CSS, and JavaScript from CloudFront. JavaScript calls API Gateway, the API Lambda queries DynamoDB, and the returned JSON becomes the live dashboard. There is no EC2 web server and no application process running continuously. Step 1: Store Every Classified Event I created a DynamoDB table with a composite key: resource "aws_dynamodb_table" "drift_events" { name = "terraform-drift-events" billing_mode = "PAY_PER_REQUEST" hash_key = "project" range_key = "timestamp" attribute { name = "project" type = "S" } attribute { name = "timestamp" type = "S" } } project groups the history for one Terraform project. The ISO 8601 timestamp orders its events. DynamoDB only requires attribute definitions for keys and indexes. Fields such as high_count , changes , and status still belong in each item, but they do not belong in the table schema block. I passed the table name into the existing severity Lambda instead of putting it directly in the code: environment { variables = { DRIFT_EVENTS_TABLE = aws_dynamodb_table . drift_events . name

Before you start: This picks up where Part 1 left off. From part 1, you would've learned how to setup a Bedrock Knowledge Base in the console. In addition to that, you should have a general understanding of how the ingestion and query pipeline works. Introduction & Motivation I started this project with a singular goal: to build a comprehensive Terraform module that allows developers to deploy the entire infrastructure for a "Chat with PDF" application faster. When Amazon Bedrock was first unveiled in April 2023 , I jumped in immediately. Like many of you, I built several proof-of-concepts (PoCs) through the AWS Console. The UI is amazing for building quick pocs, but once I moved into experimentation, I realized it would be best to quickly setup and tear down the infra. An example use case was testing if there were any cost savings in using S3 Vectors vs OpenSearch and how much cost savings exactly. None of the Terraform modules I found on GitHub ( at the time ) seemed to cover the end-to-end pipeline I was looking for, so I decided to build mine. I'm also big on learning so why not. What Are We Building? A couple of terraform modules to automate everything we clicked through manually in Part 1. One terraform apply brings up the full stack: S3 Bucket : your document store. Encrypted at rest, versioning on, zero public access. OpenSearch Serverless : the vector database. Stores the embeddings Bedrock generates during ingestion. Bedrock Knowledge Base : orchestrates the chunking, embedding, and storage of documents, and retrieval at query time. Ingestion Lambda : triggered automatically when you upload a file to S3. Starts a Bedrock ingestion job so documents are chunked, embedded, and indexed without ClickOps. Query Lambda : accepts a natural language question, calls RetrieveAndGenerate , and returns an answer with source citations. Full source code + ReadMe: Bedrock Project . If you run into issues or want to extend the module, feel free to open an issue. Architectu

Newly filed court exhibits show OpenAI’s legal strategy in Apple’s trade secrets lawsuit: argue that Apple’s own security and offboarding practices — including allowing an Apple manager to access a former engineer’s iCloud account after he left the company —undermine its claims that the allegedly stolen information was properly protected.

Post 4 of 8 in the game-factory series. Icons are what people look at You can theme fonts, colors, win messages, and sound effects. Change all of it and the game still reads like the original with a skin on it. Swap the icons — the actual symbols spinning in the reels — and it reads like a different game. The casino template I built by hand uses cloud service logos. Replace those with golden scarabs and ankhs and it becomes an Egyptian game. Keep the logos and give it an Egyptian color scheme and it doesn't. A full theme has around thirty symbols. Each needs to be small enough to read at reel size, distinctive enough to tell apart mid-spin, and consistent enough that they look like they came from the same place. Getting that by hand for every theme is exactly what I wanted to avoid. So two agents handle the visual layer: Image-Gen and Background-Gen. They're the shortest story in the pipeline — almost identical code, real results, and one failure mode I still haven't fully solved. Two agents, one loop The Designer's spec carries everything the image agents need. Each symbol entry has an icon_prompt — a short text description the Designer wrote to describe that symbol's appearance. The spec also carries a single background_prompt for the full-page background. Image-Gen reads the spec, loops through every symbol, and for each one calls Stable Image Core on Bedrock with the symbol's prompt. It gets a PNG back, resizes it to 256×256 (the size the reels expect), and writes it into the app's public/images folder. After the icons are approved, it seeds DynamoDB — putting each symbol into a table the game queries at runtime to know which icons to load. Background-Gen does the same process exactly once, for the background image. That's the scope. I grouped them in one post because splitting them into two would mean writing the same agent story twice. They share the same architecture, the same failure modes, and the same lessons. The only thing different is the count of outpu

El AWS Summit Bogotá 2026 mostró que la infraestructura en la nube es cada vez más un entorno dominado por agentes autónomos, esquemas de seguridad multi-capa y modelos de resiliencia avanzada. En este post entregó un resumen de los temas que pude observar y que comparto con ustedes. Ecosistema agéntico y optimización en la nube La presentación principal destacó la evolución hacia sistemas autónomos apoyados por herramientas como Amazon Quick Desktop que es un agente de IA local, el cual llamo mi atención al ser capaz de construir un grafo de conocimiento a partir del contexto profesional. También fue relevante la optimización continua en arquitecturas DevSecOps, apoyados por la transición hacia el paradigma agéntico . Estas aproximaciones exigen marcos como AWS Bedrock AgentCore , en el cual se aplica el concepto de Harness , estructurando así la orquestación, observabilidad y límites de control de los agentes. En el ámbito financiero, Itaú presentó el uso de AWS Kiro en sus procesos de migración, mientras que Nequi expuso la evolución de sus sistemas bancarios digitales. Para gobernar estos desarrollos, la seguridad se reconfigura hacia modelos como AWS Continuum , integrando modelado de amenazas, revisión de código y análisis de vulnerabilidades asistido por inteligencia artificial en el ciclo de desarrollo. Arquitecturas para cargas de misión crítica y resiliencia El diseño de sistemas tolerantes a fallos se analizó bajo la premisa de que la alta disponibilidad debe evaluarse mediante métricas de observabilidad avanzadas y presupuestos de error, más allá de comparaciones binarias de operatividad. Casos prácticos y mecanismos de failover Yuno detalló su arquitectura para mantener un SLA de 99.95% mediante despliegues Canary y pruebas de ingeniería de caos con AWS Fault Injection Service (FIS) . En entornos de alta demanda, el aislamiento regional apoyado por Zonal Shifts permiten desplazar el tráfico ante la degradación de una zona de disponibilidad. Se debe dest

August 3, 2026Lockhead Taking feedback - so essential for AWS every other tech company or startups #culture #aws #devops #aws #building #oss #build-in-public Taking feedback - so essential for AWS every other tech company or startups There’s a reason for this post: Last week I gave feedback to a good friend. It was something around “this thing doesn’t work for me, can you fix this?” Within hours, Ran had taken my feedback and incorporated it into his website. This little story motivated me to write this blog as in our industry we start to forget the importance of human interactions and the power of feedback. Feedback: A gift and a curse Feedback is a gift. Every content creator and startup developer will agree: Any piece of feedback you can get helps to shape your future as a creator or builder. It’s a gift that too many of us have stopped giving in 2026 - either because we’re busy building our own SaaS or because we’re too distracted by AI in our day to day job. The gift of feedback has made AWS one of the biggest cloud vendors and has helped Google Cloud to quickly win shares of the cloud market: by making things simpler that AWS made too complicated in the past years. The gift of feedback can be a rant or a viral post where you expressed your problems or concerns that you faced when you were building something. Feedback is a gift if it is clear enough to help you change something. Feedback can be a curse if it is given in the wrong format or tone. It can be a curse if it becomes or is taken personal and when it negatively impacts the work. Feedback is a curse when it is given with wrong intentions. It is a curse when it is being ignored. Feedback makes a difference This week, a bunch of AWS Heroes meet and the whole week is about exactly this: giving feedback . It’s a week where we get to talk and discuss in person with the teams we work with (mainly behind the scenes) through the whole year. We share - and openly fight with each other - on current and future AWS

By Swetha Golla · 8 min read · Senior Application Architect 🔗 This post has a live interactive version with a clickable per-service verdict and the full comparison matrix: read it here TL;DR Need strict per-key ordering and replay? That's a log, not a queue — Kinesis or MSK. Pick MSK if you need real Kafka wire-protocol compatibility (existing clients, Kafka Streams, ksqlDB, Debezium); pick Kinesis if you'd rather AWS own shard mechanics and you're fine with its API. Need routing logic based on event content, not raw throughput? EventBridge — pattern-matching rules to many differently-interested targets, not identical delivery to everyone. Need a simple durable buffer between one producer and one consumer group? SQS. Need the same message fanned out to many independent subscribers? SNS — often paired with SQS underneath. Already running RabbitMQ, or need AMQP-specific routing? Amazon MQ for RabbitMQ is a lift-and-shift, not a rearchitecture. The expensive mistake isn't picking a slightly-suboptimal service — it's picking a queue when you needed a log, or the reverse. That's a rewrite, not a config change. The setup Scope note: this is a decision matrix for AWS's own catalog, not a survey of every messaging technology that exists. Self-hosted Kafka, Google Pub/Sub, Azure Service Bus, NATS, Pulsar, and plenty of others solve overlapping problems outside AWS's walls — worth knowing about, out of scope here. A platform team is replacing a single overloaded RabbitMQ broker that has become the answer to every "how do services talk to each other" question for three years running: order events, fraud signals, audit trails, third-party webhooks, and a slow-growing analytics pipeline all queue through it. It works, until it doesn't — a queue depth spike during a promotion in 2025 backed up every consumer behind it, including ones that had nothing to do with the promotion. The team's instinct is to "move it all to AWS-native," as one service. That instinct is the mistake. Thes

I'm a big fan of using Claude and Claude Code for development. Many organizations are currently using these tools to improve developer productivity and ultimately build better products. Our role and our tools have changed — we went from powerful autocomplete to autonomous agents that can refactor, review, and implement features, most of the time better than we can on our own. Authentication methods There are several authentication methods, each with different billing, cost tracking, and governance options. Depending on your organization, you will choose the one that fits best. Personal development — Anthropic API key I use this for experimenting with the Anthropic library for learning and prototyping. You set ANTHROPIC_API_KEY in your environment (or a .env file), and the SDK picks it up automatically. Pay-as-you-go per token, no infrastructure needed. from dotenv import load_dotenv load_dotenv () import json import anthropic client = anthropic . Anthropic () tools = [ { " name " : " get_weather " , " description " : ( " Returns current weather for a city. Use ONLY for weather queries. " " Input: city name (string). Output: temperature in Celsius and conditions. " ), " input_schema " : { " type " : " object " , " properties " : { " city " : { " type " : " string " }}, " required " : [ " city " ], }, }, { " name " : " get_time " , " description " : ( " Returns the current local time for a city. Use ONLY for time/timezone queries. " " Input: city name (string). Output: local time string. " ), " input_schema " : { " type " : " object " , " properties " : { " city " : { " type " : " string " }}, " required " : [ " city " ], }, }, ] def get_weather ( city : str ) -> dict : return { " city " : city , " temp_c " : 22 , " conditions " : " sunny " } def get_time ( city : str ) -> dict : return { " city " : city , " local_time " : " 14:35 " } TOOL_FUNCTIONS = { " get_weather " : get_weather , " get_time " : get_time , } def run_agent ( user_message : str ) -> str : messages =

AWS open-sourced a persistent workspace that coordinates AI coding agents across sessions, schedules, and repos. Here's what it actually does and why it matters.

AWS introduced Kiro Crew on Tuesday as a new open-source orchestration platform. This tool aims to help businesses shift from interactive AI coding assistants toward autonomous engineering workflows. The system manages tasks across various repositories and developer tools over multiple work sessions to increase overall efficiency. Orchestrating autonomous development cycles Kiro Crew goes beyond simple code generation by coordinating multiple AI agents simultaneously. It schedules recurring work and maintains project context even when a session ends. This allows the system to integrate with standard developer tools for investigating incidents or monitoring pull requests. It triages tickets and automates software engineering tasks while developers are away from their workstations. The platform functions as an application layer that turns AI coding agents into self-learning teammates. It features persistent memory and multi-agent orchestration tools to ensure continuity. Security remains a priority with features like sandboxing and signed audit logs. Users can monitor activity through a dedicated web and desktop dashboard designed for transparency. Before its public release, the project existed inside Amazon as an internal tool named MeshClaw. More than 39,000 Amazon builders adopted it in less than six months. This internal success paved the way for the current open-source offering. Companies can deploy the platform entirely within their own environments, such as on local laptops or virtual machines. Reference applications and practical use cases AWS launched several reference applications to show how the platform functions in real-world scenarios. DevFleets manages worktrees, while Issue Radar handles the triage of pull requests and tickets. Task Runner focuses on executing engineering tasks that require a long duration to complete. These apps use specific interfaces combined with the core orchestration engine. These tools are not standalone products but rather exam

Your AI bill tripled last quarter. Your CTO forwarded you an article about companies saving 70% by switching to open models. Now someone is asking you to figure out what that would actually look like. I spent the last few weeks digging into this. The numbers, the hardware, the real trade-offs. Here's what I found, with enough specifics that you can actually make a decision rather than just nodding along to another "open source is the future" think piece. What "Open Models" Actually Means When someone says "open model" they mean an AI model where the weights (the learned parameters that make the model work) are publicly downloadable. You grab the file, run it on your hardware, and you don't pay anyone per request. The big names right now: Meta's Llama 4, DeepSeek V4, Zhipu's GLM-5.2, Moonshot's Kimi K3, Alibaba's Qwen 3.5, and Google's Gemma 4. These aren't toys. Some of them genuinely compete with the frontier models on real benchmarks. Chinese open models now handle over 30% of enterprise traffic on OpenRouter, up from 4.5% in early 2025. That's a massive shift in barely a year. The Architecture: What You Actually Need You want your team to use an open model. Here's the stack, from bottom to top. Hardware (The Expensive Part) A model is a giant file. We're talking anywhere from 4 GB (a small 7B model, quantized) to 1.5 TB (Kimi K3, full weights). That entire file needs to sit in GPU memory to run fast. Why GPU memory specifically? Because generating each word in a response requires billions of multiply-and-add operations. GPUs do thousands of these in parallel. A CPU does them one at a time. The practical difference: a 7B model on a CPU generates 2-5 tokens per second (painfully slow for interactive use). The same model on a GPU generates 30-80 tokens per second (feels instant). For one person on a CPU, it might be tolerable. For a team of 10 all hitting the same endpoint? Unusable. Requests queue up and everyone waits 30-60 seconds for responses. Think of it like

Most companies we work with don't have a data inventory. When we ask "where's your data listed?" (where it lives, what it contains, who owns it), the answer is usually some version of "we don't have one." No comprehensive map of data locations. No business impact assessment for different data types. Unclear ownership and accountability. You can't protect what you haven't mapped. And you can't make good decisions about backup strategy when you don't know what you're backing up. Data Has a Half-Life Not all data ages the same way. Some data becomes stale quickly. If you're aggregating information from external sources like market data, business intelligence, or operational metrics, the value is often in the freshness. Yesterday's data might be useful for trends, but it's not the crown jewels. Source data and processed insights need different protection levels. The raw inputs you collect might be recreatable from upstream sources. The analysis and transformations you've built on top might take significant effort to reconstruct, or might be regenerated in hours if you have the pipeline intact. This changes the backup math. If your data pipeline gets destroyed but you can pull from upstream sources and recreate everything within an acceptable timeframe, maybe you don't need to back up the work product at all. Maybe you just need to protect the source data and the pipeline itself. Understanding your data's half-life helps you spend backup dollars where they actually matter. The Cost vs. Risk Conversation Backup costs can reach hundreds of thousands of dollars annually. Cross-region replication, long-term retention, disaster recovery infrastructure. It adds up fast. That's money not going to engineers or product development. A real tradeoff. The question is: what's the actual business impact if this data disappears? What's the downtime cost? What's your real risk tolerance? These are executive decisions, not just technical ones. They require someone to say "we're willing t