标签：#aws

The problem IAM wildcards and public S3 buckets keep slipping through Terraform code review. Tools like Checkov and tfsec exist but they live in CI, require config files, and developers ignore the output because it's not where they're working. What I built TerraWatch is a GitHub App that scans every pull request that touches .tf files automatically. If it finds a security issue it blocks the merge and posts the exact code fix as a PR comment. The developer sees something like this in their PR: ⚠️ PUBLIC_S3_BUCKET - main.tf (Line 6) Severity: HIGH Risk: S3 bucket allows public read access. Fix: acl = "public-read" acl = "private" block_public_acls = true restrict_public_buckets = true They copy the fix, push, and the merge unblocks automatically. How it's different No YAML, no CI config - installs in 2 minutes via GitHub App Fixes are hardcoded diffs, not AI generated Nothing auto-applied - you review every fix No Checkov dependency - own lightweight rules engine Only reads changed .tf files in the PR, never your full codebase 29 rules covering S3 public access, IAM wildcards, open ports (SSH/RDP/MySQL/Postgres), unencrypted EBS/RDS, public databases, hardcoded secrets, EKS public endpoints, CloudTrail disabled, IMDSv1, and more. Try it Free during beta - terrawatch.dev Also launching on Product Hunt today if you want to show some support!

A bot on Polymarket quietly extracted $32k in near risk-free profits by sniping “Will Company XYZ Beat Earnings?” markets. It waits for the official release, then instantly buys the winning side. Many limit orders from retail traders remain uncancelled, creating a post-announcement arbitrage window. Two developers decided to challenge it. Here’s what they learned while trying to build a faster version. Infrastructure Choices Location : Polymarket’s CLOB runs in AWS eu-west-2 (London). They deployed from Ireland (eu-west-1, Dublin) — the closest realistic option without IP tricks. UK IPs are blocked. Language : Rust for type safety and speed. The author notes you can achieve competitive latency in Python if you strip unnecessary network calls. Key Warning : Avoid the official Polymarket SDKs for ultra-low latency. They include helpful but slow pre-trade checks. Build lean custom clients. The Data Feed Challenge (The Real Bottleneck) The critical edge is getting earnings announcements faster than competitors. Source Performance Verdict Scraping Newswires Too slow Failed Benzinga Low-Latency Slower than manual clicking Failed Paid ultrafast feed ~500ms after release Still too slow EDGAR Consistently slower than newswires Backup only Even at 500ms, the order book was already swept by faster bots. The top players are likely using extremely expensive dedicated feeds or custom setups. Technical Lessons Learned Network > Code Most latency lives in the network round-trip, not in language choice. Optimize transport first. Custom Execution Layer Skip heavy SDK abstractions. Direct signed orders with minimal validation. Post-Event Sniping Logic Monitor newswire feeds aggressively Parse EPS vs. estimate instantly Place aggressive limit/market orders on the winning side Handle cases with ambiguity (multiple interpretations of “beat”) Reality Check They made some wins during EPS ambiguity or when faster bots hit size limits, but never won on pure speed against the leader. Why This

AWS Hero Vadym Kazulkin explains how to overcome Java’s enterprise hurdle on AWS Lambda: cold starts and memory footprints. He shares a technical deep dive into performance tuning, comparing fully managed AWS SnapStart (with pre-snapshot priming hooks) against GraalVM ahead-of-time compilation, while addressing the latest architectural implications of Project Leyden and Java 25. By Vadym Kazulkin

Introduction It's crazy to me that some GitHub repos, that were just created in the last...

On June 9, 2026, Anthropic launched Claude Fable 5, a model designed for long-horizon tasks, but it was taken offline shortly after due to a U.S. government export directive. It shares architecture with Claude Mythos 5, supporting extensive token usage. The model includes mandatory data retention requirements, which have affected its deployment with partners like Microsoft. By Andrew Hoblitzell

Cómo un backend de FastAPI + asyncpg comparte un solo Postgres chiquito con sus propios trabajadores en segundo plano y un segundo servicio, por qué el techo de conexiones, no el CPU, es lo que de verdad le pone tope a nuestro autoescalado, la caída en el cambio de hora que nos enseñó la cuenta, y una mirada honesta a RDS Proxy como la válvula de escape (incluyendo la trampa de asyncpg que lo puede dejar sin hacer nada). TL;DR Ajuste Valor Por qué Driver postgresql+asyncpg asíncrono hasta el fondo pool_size / max_overflow 8 / 12 (20 por proceso) subido desde 3/5 después de una caída pool_pre_ping True mata los sockets muertos tras un reinicio de RDS / inactividad pool_recycle 1800 s techo duro que el pre-ping no puede cubrir Tope de conexiones de RDS ~87 (t3.micro, menos las reservadas) la verdadera restricción de todo Pruebas NullPool sin pooling entre event loops en pytest La lección que replanteó todo el problema: en un RDS chico, tu cuenta máxima de tareas la fija max_connections , no el CPU ni la memoria. Un autoescalado que ignora el presupuesto de conexiones va a escalar directito hacia QueuePool limit reached , o peor, FATAL: too many connections del mismo Postgres. El pool, y la cuenta escondida adentro de él engine = create_async_engine ( settings . DATABASE_URL , connect_args = { " ssl " : " prefer " }, # negocia TLS en RDS, texto plano en local pool_pre_ping = True , pool_size = 8 , max_overflow = 12 , # 8 + 12 = 20 conexiones por proceso pool_recycle = 1800 , ) Veinte conexiones por proceso se ven modestas hasta que las multiplicas por cada capa entre ellas y la base de datos: pool_size + max_overflow = 20 por proceso de Python × 2 trabajadores de uvicorn = 40 por tarea de Fargate × 2 durante un despliegue rolling = 80 (tarea vieja drenando + tarea nueva arrancando) + servicio de inteligencia (3 + 7) = 10 sobre la misma base de datos + alembic / ad-hoc / psql ≈ unas pocas ---------------------------------------- ≈ 87 ← el techo de la t3.micro, con ~0 de

Most of the code in Quorum was written by directing Claude Code, an AI coding agent. That is not the interesting claim, and on its own it is not even a good one. An agent left to run unsupervised produces fast, plausible, locally-correct code that drifts into an incoherent system. The interesting part is the discipline that turned agent speed into a coherent, correct, multi-region database application. That discipline was an append-only architecture decision log. The failure mode of agent-built software An agent has no memory across sessions. It will happily contradict a decision it "made" yesterday, re-open a question that was settled last week, or quietly drift from the design because the local change in front of it looks fine. Each individual output is reasonable. The aggregate, without governance, is a system where the data model fights the access layer and the third change undoes the first. This is the part people underestimate when they talk about AI coding velocity. Speed without a source of truth does not get you to a good system faster. It gets you to entropy faster. A fast writer with no memory and no sense of consequence is a liability at scale unless something outside the agent supplies the continuity. The decision log Quorum carries a file of numbered architecture decisions, DEC-001 onward, now past two dozen. Each entry has the same shape: the context that forced the decision, the decision itself, references to the prior decisions it refines or interacts with, and a status. Three rules make it work: Append-only. Entries are never edited. A later decision can supersede an earlier one, but it does so as a new numbered entry that references the old one. The history of why the system is shaped the way it is stays intact and readable, including the choices that were later reversed and why. Committed separately from code. The decision and the code that implements it are different commits. The log reads as a clean narrative of intent, independent of the diffs

The thesis Quorum is built on is uncomfortable and true: the tools a team uses to coordinate an incident often live in the same region as the thing that is failing. When the region goes, the incident response goes with it. You are now coordinating a region outage over a status page that the region outage took down. Quorum is an incident command plane designed to survive a region loss. This post is about how the failover works, what the live demo does and does not prove, and where the survival story currently ends, because a database audience will ask all three and they deserve a straight answer. What DSQL gives you A multi-region DSQL cluster in the US set is three regions: two full regions, which for Quorum are us-east-1 and us-east-2, and a log-only witness in us-west-2 that has no cluster endpoint of its own. Both full-region endpoints present a single logical database with strong consistency, and the architecture is designed for 99.999% multi-region availability with no single point of failure and automated failure recovery . The behavior that matters for an incident tool is stated plainly in the GA announcement : applications can keep reading and writing with strong consistency even when they are unable to connect to a region's cluster endpoint, and the third region acts as a log-only witness with no cluster resource or endpoint. The survivor keeps serving; the witness holds the log so the surviving region keeps commit quorum. Quorum is, in effect, a live demonstration of that reference behavior with an incident-command product wrapped around it. Quorum's failover layer AWS's guidance for multi-region DSQL is to put routing in front of the endpoints: either DNS-based routing with Route 53, or application-level routing logic, so traffic redirects automatically when an endpoint becomes unreachable. This is laid out in Implement multi-Region endpoint routing for Amazon Aurora DSQL . Quorum, a Next.js app on Vercel, does the application-level version: it detects an

Quorum is an incident command plane built on Amazon Aurora DSQL. The failover story lives in another post. This one is about a narrower question that turned out to be the foundation: when several responders write to the same incident at the same moment, across regions, during the worst minutes of an outage, how do you guarantee the record never forks into two conflicting truths. The answer is two design choices that are really one choice seen from two angles: event sourcing, and DSQL's optimistic concurrency control. The data model is append-only Quorum is event-sourced across four tables. Every state change is an immutable event appended to a log, not an in-place update. The current state of an incident is a fold over its events. There is no UPDATE incidents SET status = ... ; there is an acknowledged event, a note event, a resolved event, and the status you render is computed from them. The event's UUID is its primary key and its idempotency key at the same time. A retried write carrying the same UUID cannot double-apply: the insert collides on the primary key and becomes a no-op. That property sounds minor until you remember what kind of system this is. A tool designed to survive network failure retries writes constantly, and "the responder tapped resolve twice because the first response was slow" must not produce two resolutions. Append-only also suits the domain directly. For an incident system the audit trail is the product, not a side effect. "Who acknowledged this, at what time, and what did the timeline look like at 02:14" is a first-class question for the post-incident review and a compliance requirement in regulated environments. Event sourcing gives you that for free. It also gives DSQL a write pattern it likes, which matters more than you would expect. The stack, briefly TypeScript end to end. Kysely as a typed query builder rather than an ORM, because I wanted type safety without surrendering control of the SQL: on a distributed database the exact shap

The laptop was never the interesting part of coding agents. It was just the first convenient runtime. Your laptop has the repository, the shell, the secrets, the package cache, the local database, the half-working dev server, and whatever credentials you forgot were still loaded in the background. So the early version of agentic coding naturally ran there. It was close to the work. It had all the messy context. It was also a very strange place to run something that might edit code for an hour while calling tools, installing dependencies, and touching private systems. AWS published a Bedrock AgentCore post this month with a very good hook: you should be able to close your laptop while the coding agent keeps working. That is the demo-friendly version. The more important version is this: once the agent leaves the laptop, "what happened?" becomes a production question. And that is where observability stops being a nice enterprise add-on and becomes part of the product. remote is not the same as trustworthy Moving a coding agent to a hosted runtime solves some obvious problems. The agent can keep running after your machine sleeps. Multiple agents can run in parallel without fighting over the same local Postgres port. The filesystem can persist between sessions. The environment can be isolated in a microVM or container instead of sharing your real shell with everything else you do all day. Good. But remote execution also removes a useful kind of accidental visibility. When the agent is on your laptop, you can at least see the terminal, notice the fan spin up, watch the test output, and feel the blast radius because it is your machine. In a hosted runtime, that little bit of intuition disappears. The agent is now somewhere else, with its own filesystem, network path, credentials, tools, retry behavior, and bill. So the platform has to replace intuition with evidence. Not a transcript pasted into a PR. Actual operational evidence: traces, logs, metrics, command history, too

There is common point of confusion. what's the different between REST API vs. HTTP API in AWS and what's the different between them and a traditional Rest API you write with e.g express in node in the broader software world, a "REST API" is just an architectural pattern built on top of HTTP requests. The confusion comes entirely from AWS-specific marketing terminology . When you are inside the AWS ecosystem, Amazon API Gateway is a specific managed service, and AWS chose to split that service into two different flavors (or software products): one called "REST API" and one called "HTTP API." Here is exactly how they work under the hood, how they differ internally, and how it compares to traditional servers. 1. How It Works: REST API vs. HTTP API (AWS Architecture) Think of Amazon API Gateway as a reverse proxy or a "front door" that sits in front of your Lambda functions. AWS REST API (The Heavyweight) When a request hits an AWS REST API, AWS passes that request through a massive feature pipeline before it ever touches your Lambda code. [Client Request] ──> [Authentication (Cognito/IAM)] ──> [Request Validation] ──> [Data Transformation (VTL)] ──> [Your Lambda] What happens: AWS decrypts the request, validates the JSON schema, checks API keys, runs any custom request transformations using a complex mapping language called VTL, and then invokes your Lambda function. Why it costs more: You are paying AWS for all that computing power happening inside the API Gateway layer itself. AWS HTTP API (The Express Lane) When a request hits an AWS HTTP API, AWS strips out almost the entire middle pipeline. [Client Request] ──> [JWT/OAuth2 Authorization Only] ──> [Your Lambda] What happens: The HTTP API acts as a lightning-fast router. It optionally checks a standard JWT token, converts the incoming HTTP request directly into a clean JSON object, and throws it straight into your Lambda function. Why it costs less: Because AWS is doing almost zero processing or data manipulation. Y

AWS has recently introduced durability for Amazon ElastiCache for Valkey, enabling reliable data retention across failures and expanding support beyond caching to persistent workloads. The feature offers new options that prioritize either minimizing data loss or maintaining lower write latency, expanding the range of use cases supported by the Redis fork. By Renato Losio

AWS recently announced CDK Mixins, a new AWS CDK feature that lets developers add reusable capabilities like security, monitoring, and configuration to AWS resources. Mixins work across different construct types, making infrastructure code more flexible and reusable. By Renato Losio

A quick note on the links below. The DigitalOcean and Vultr links in this article are referral links. If you sign up via them, you get a free credit on your new account (currently $200 over 60 days for DigitalOcean and up to $300 for Vultr) and the author of this article gets a small referral credit too, at no extra cost to you. AWS does not run an equivalent referral program, so the AWS links are normal links. The review below is the author's own evaluation; the credits do not change the recommendations. If you have ever spent a workday watching your website refuse to load, you are not alone. In a recent outage , a single building in Northern Virginia hosting one of Amazon's availability zones (the cloud-industry term for one campus's worth of servers in one region ) got too hot. The hardware shut itself down. AWS calls this a thermal event. Customers around the world have other names for it. Big enterprises ride out outages like this. They have multi-region setups, dedicated SRE teams, and SLA credits that will refund a small fraction of their monthly bill. Small and mid-size businesses do not. They lose a day of revenue, scramble to reassure customers, and then read a post-mortem in a few weeks that explains what went wrong in language that does not help them recover the lost revenue. The cloud was supposed to make small businesses look big. After each new outage, it is fair to ask: is AWS actually the right cloud for small businesses at all? Two providers worth a serious look, DigitalOcean and Vultr , are simpler, cheaper at the entry level, and built around use cases that more closely match what a small business actually needs. Here is what each one does, where AWS is still the right answer, and how to decide. Why AWS hits small businesses harder than big ones When a giant company has an AWS outage, three teams kick into gear. There is the engineering team that fails workloads over to a backup region. There is the customer-success team that updates the status p

Did chatbot abandon mental health guardrails when a vulnerable user pushed back?

Shifting from traditional application testing to serverless TypeScript engineering is all about shifting your perspective: you stop testing a running server, and you start testing how your function responds to events and SDK states. Here is a simple, practical example for each testing, using modern AWS SDK v3 syntax. 1. Unit Testing: Jest + Mock Payloads & SDK Client Mocking In unit tests, you don't call real AWS services. You pass a simulated API Gateway event to your handler, and you mock the AWS SDK so it returns predictable data instead of hitting live infrastructure. The Code Under Test ( src/handler.ts ) import { APIGatewayProxyEvent , APIGatewayProxyResult } from ' aws-lambda ' ; import { DynamoDBClient } from ' @aws-sdk/client-dynamodb ' ; import { DynamoDBDocumentClient , GetCommand } from ' @aws-sdk/lib-dynamodb ' ; const ddbClient = new DynamoDBClient ({}); const docClient = DynamoDBDocumentClient . from ( ddbClient ); export const handler = async ( event : APIGatewayProxyEvent ): Promise < APIGatewayProxyResult > => { const userId = event . pathParameters ?. id ; if ( ! userId ) { return { statusCode : 400 , body : JSON . stringify ({ message : ' Missing ID ' }) }; } // Fetch from DynamoDB const result = await docClient . send ( new GetCommand ({ TableName : process . env . USERS_TABLE , Key : { id : userId } })); if ( ! result . Item ) { return { statusCode : 404 , body : JSON . stringify ({ message : ' User not found ' }) }; } return { statusCode : 200 , body : JSON . stringify ( result . Item ), }; }; The Jest Unit Test ( tests/unit.test.ts ) Instead of the legacy aws-sdk-mock , the modern standard for AWS SDK v3 is aws-sdk-client-mock . import { handler } from ' ../src/handler ' ; import { APIGatewayProxyEvent } from ' aws-lambda ' ; import { mockClient } from ' aws-sdk-client-mock ' ; import { DynamoDBDocumentClient , GetCommand } from ' @aws-sdk/lib-dynamodb ' ; const ddbMock = mockClient ( DynamoDBDocumentClient ); describe ( ' Lambda Handler Unit

On June 9, 2026 (US time), two big announcements landed on the same day. At the keynote of Datadog's annual event DASH 2026 in New York, the Bits AI family expanded significantly: Detection, Investigation, Remediation, Infrastructure, Code, Release, Testing, Data Analysis, Chat, Memories, and Evals. Counting by agent, that is more than ten, with over 100 new features announced together. The full picture is laid out in the keynote roundup. https://www.datadoghq.com/blog/dash-2026-new-feature-roundup-keynote/ The same day, AWS announced FinOps Agent as a public preview. It bundles four data sources, Cost Explorer, Cost Anomaly Detection, Cost Optimization Hub, and Compute Optimizer, and delivers automated cost-anomaly investigation, natural-language cost questions, periodic cost reports, and aggregated optimization opportunities straight into Slack and Jira. The details are in the AWS blog. https://aws.amazon.com/blogs/aws-cloud-financial-management/aws-finops-agent-is-now-public-preview/ AWS DevOps Agent had already gone GA in March, handling incident response. With FinOps Agent now added, AWS-built standard agents line up across the main operational domains. That said, DevOps Agent also covers multicloud and on-premises environments, so its scope differs from FinOps Agent, which targets AWS cost data. https://aws.amazon.com/blogs/mt/announcing-general-availability-of-aws-devops-agent/ On the surface, this looks like two separate stories: Datadog the monitoring platform, AWS the cloud provider. But read the two announcements side by side, and you see both reaching for the same territory, Ops, through different entrances. Line up their features and most of them overlap, so a surface spec comparison won't show the difference. This article sorts out the same-day releases by the two companies' positioning, asks what these very similar agent lineups are actually fighting over, and goes as far as the axes for telling them apart and the predictions that follow. This is writ

In the previous post , we talked about context windows. The model has a fixed-size desk and everything has to fit on it at once. When too much is on the desk, things in the middle get missed. I ended that post with a promise: what if there was a way to give the model just the right piece, at the right time, from a document you've never even pasted in? That's this post. We're giving the model a search system. The problem: your document is too long You have a 2000-page document. An employee handbook, a product manual, internal documentation. You need one specific answer from it. You can't paste the whole thing into the model's context window. And even if you found a model with a window big enough, we learned what happens: attention degrades, things in the middle get missed, and the model answers confidently from the wrong section. So you need something different. A step that happens before the model sees anything. Something that finds the 2-3 paragraphs that actually answer your question, and passes only those to the model. That's retrieval. The full technique is called RAG: Retrieval-Augmented Generation . Search first, then generate. Three words, one loop Let's break the name down. Each word is a step. Retrieval. Go find relevant information. Think of it like checking the index of a textbook before diving into a chapter. You don't re-read the whole book. You find the right page first. Augmented. Add that retrieved info to the prompt. You're supplementing the model's built-in knowledge with fresh, specific context. Like handing someone a cheat sheet right before they answer a question. Generation. The model writes its response, but with the retrieved context sitting right there in the conversation. It generates an answer grounded in your actual data, not just its training. "Grounded" means the model has real evidence to point to. It's not guessing from memory. It's answering from something you gave it. The whole loop in one sentence: find the right chunks of informat

Modern enterprise order processing architectures must decouple synchronous client demands from asynchronous backend dependencies. Here I'll detail a highly scalable, fault-tolerant design built on AWS. By utilizing an automated API Gateway entry point, specialized Amazon Cognito authentication, optimized AWS Lambda logic blocks, an engineered RDS Proxy connection layer, and an event-driven SQS/EventBridge core, the design guarantees isolation, cost efficiency, and sub-millisecond structural routing. The Scenario User places an order → payment is processed → inventory updated → confirmation email sent Client → API Gateway (Cognito auth + validation) → Order Lambda (business logic + DynamoDB write) → SQS (payment queue) → Payment Lambda → EventBridge → Inventory Lambda → Notification Lambda (SES) 1- Entry Point — API Gateway REST endpoint: POST /orders Request validation via API Gateway models (reject malformed payloads instantly, no Lambda invoked) Auth via Cognito User Pool Authorizer — validates JWT token on every request How It Works The Request Hits: A client sends a POST /orders request with a JWT token in the header. Auth Check: API Gateway automatically intercepts the request and validates the JWT against the Cognito User Pool. If expired or spoofed, it returns 410 Gone / 401 Unauthorized right there. Payload Check: Next, it compares the body against your JSON Schema Model. If a required field like customer_id is missing, API Gateway instantly drops it with a 400 Bad Request. The Win: Your downstream services (like Lambda) are never invoked for bad/unauthorized requests, saving compute costs and protecting against basic DDoS or bad actor spam. Gotchas Cognito Latency: While Cognito authorizers are native, they can add a slight latency overhead to your API's P99 metrics during peak traffic. For massive global scale, some enterprises migrate to custom Lambda Authorizers that cache tokens in ElastiCache (Redis). Model Validation Limits: API Gateway's built-in val

OpenAI's GPT-5.5, GPT-5.4, and Codex are now generally available on Amazon Bedrock, one month after OpenAI revised its exclusive Azure arrangement. Pricing matches OpenAI's direct rates with usage counting toward AWS commitments. Codex shifts to pay-per-token billing with no seat fees. GPT-5.4 is the first OpenAI model available in AWS GovCloud. By Steef-Jan Wiggers