标签：#AWS

Auditing My Indie SaaS Subscriptions: 5 Alternatives That Cut $800/Year TL;DR Fixed costs for indie dev projects balloon through "subscriptions you signed up for and forgot." I switched 5 services to free tiers or self-hosted alternatives, cutting ¥10,000/month — ¥120,000/year (roughly $800). The short version: Before Monthly After Monthly Annual Savings Heroku Hobby (2 dynos + DB) ¥2,800 Fly.io / Railway free tier ¥0 ¥33,600 Vercel Pro ¥3,000 Cloudflare Pages ¥0 ¥36,000 Datadog (1 host) ¥2,300 Grafana Cloud Free ¥0 ¥27,600 Mailgun Foundation ¥1,400 Resend free tier ¥0 ¥16,800 Algolia Build overage ¥500 Meilisearch (self-host) ¥0 ¥6,000 At indie-project traffic levels, you're probably using less than 10% of what paid plans offer. The first step is auditing your usage and checking whether your actual numbers fit inside a free tier. The Approach: Measure First, Decide Second Cut decisions should be based on real data, not gut feeling. Start with a billing audit. # Export each service's plan and recent usage to a spreadsheet # Example: check request count for the last 30 days from nginx access log awk '{print $4}' access.log | grep -c " $( date +%d/%b/%Y ) " # → A few thousand requests/day fits comfortably inside almost every SaaS free tier The key is looking at actual traffic , not peak spikes. Most indie projects fit well within Vercel/Cloudflare free tiers (100k requests/month to unlimited bandwidth). Step-by-Step Migration 1. Hosting: Heroku → Fly.io # Deploy to fly.io — existing Dockerfile or buildpacks work as-is curl -L https://fly.io/install.sh | sh fly launch # interactively generates fly.toml fly deploy fly scale count 1 # 1 instance is enough for indie projects fly postgres create # small instance, effectively free The key to cost control: lock to fly scale count 1 and the minimum VM ( shared-cpu-1x ). 2. Frontend: Vercel Pro → Cloudflare Pages Unlimited bandwidth, generous build limits, and free equivalents of Pro features (Analytics, etc.) that most indie

T-Mobile wants Broadcom to keep supporting its VMware perpetual licenses.

AWS released Managed Knowledge Bases for Amazon Bedrock on 17 June 2026. The feature significantly reduces the operational complexity of building Retrieval-Augmented Generation (RAG) solutions by allowing Bedrock to manage the vector storage, indexing, embeddings, and retrieval infrastructure on your behalf. For teams looking to deliver an Agent Core proof of concept or their first production RAG workload quickly, this can be a compelling option. However, there are some important trade-offs to understand before committing to the managed approach. Traditionally, a Bedrock Knowledge Base required a customer-managed vector store such as: OpenSearch Serverless OpenSearch Managed Clusters Aurora PostgreSQL with pgvector Pinecone DocumentDB Other supported vector databases With a Managed Knowledge Base, Bedrock handles the underlying vector infrastructure and embedding model selection for you. Creating one from the AWS CLI is straightforward: aws bedrock-agent create-knowledge-base \ --name "my-managed-kb" \ --role-arn "arn:aws:iam:: ${ AWS_ACCOUNT_ID } :role/service-role/AmazonBedrockExecutionRoleForKnowledgeBase_ihv1p" \ --knowledge-base-configuration '{ "type": "MANAGED", "managedKnowledgeBaseConfiguration": { "embeddingModelType": "MANAGED" } }' Advantages Lower operational overhead There is no need to provision, secure, monitor, patch, or scale a separate vector database. Lower costs S3 storage is cheaper than database storage. Pay only for each ingestion and retrieval operation. Indexing and searching compute is free. No 24/7 server costs. Faster time-to-value Managed Knowledge Bases make it possible to stand up a RAG solution in minutes rather than days. Automatic embedding management Bedrock manages embedding selection and indexing, reducing the number of architectural decisions required from development teams. Cost-effective for smaller workloads The managed model can be attractive for: Proofs of Concept Departmental knowledge bases Agent Core pilots Workloads wi

Exam Guide: Developer - Associate 🏗️ Domain 3: Deployment 📘 Task 1: Prepare Application Artifacts To Be Deployed To AWS Before you can deploy anything to AWS, you need to package it properly. This task covers Lambda deployment packaging (zip vs container), managing dependencies, structuring projects for multi-environment deployment, and using AWS AppConfig for runtime configuration. 📘Concepts Lambda Deployment Packaging Options Option Max Size Build Complexity Cold Start Best For Zip Package (inline editor) 3 MB (editor limit) None Fastest Simple functions, no dependencies Zip Package (upload) 50 MB compressed / 250 MB uncompressed Low Fast Most Lambda functions Zip + Lambda Layers 250 MB total (function + all layers) Medium Fast Shared dependencies across functions Container Image 10 GB Higher Slower (first invoke) ML libraries, large dependencies, custom runtimes 💡 If a scenario is about a deployment package exceeding 250 MB, the answer is container images. If it mentions sharing dependencies across multiple functions, the answer is Lambda Layers. Zip is the default for most workloads. Lambda Layers Aspect Detail What They Are Zip archives containing libraries, custom runtimes, or other dependencies Max Layers Per Function 5 Size Limit 250 MB total (function code + all layers uncompressed) Versioning Each publish creates an immutable version Sharing Can be shared across functions, accounts, or made public Path Contents extracted to /opt in the execution environment Dependency Management Strategies Strategy How It Works Pros Cons Bundle In Zip Install deps into package directory, zip together Simple, self-contained Larger package, duplicated across functions Lambda Layers Package deps as a layer, attach to functions Shared across functions, smaller deploys Layer version management, 5-layer limit Container Image Install deps in Dockerfile Full control, large deps supported Slower cold starts, ECR management sam build SAM resolves deps from requirements.txt automatic

AWS Blocks handles authentication, databases, file storage, AI agents and more out of the box. But...

Quick Answer (TL;DR) Modifying an RDS instance class in place causes 5 to 15 minutes of downtime while AWS reboots the database. To right-size without downtime, use RDS Blue/Green Deployments (fastest, cleanest), a read-replica promotion (works on older engines), or a Multi-AZ failover to a resized standby. Blue/Green is the 2026 default for most workloads on MySQL, MariaDB, Postgres, and now SQL Server. Why this happens RDS instances are Managed EC2 hosts running the DB engine, and a class change (say db.m6i.large to db.m6i.xlarge ) requires stopping the process, migrating the EBS volumes to a new host, and restarting. AWS's default "modify" workflow does this in place and warns you about downtime. The workarounds exist because that reboot is unacceptable for user-facing services, so you build the new instance alongside the old one and cut over. Fix #1: Use RDS Blue/Green Deployments The 2026 default. Available for RDS MySQL, MariaDB, PostgreSQL, and SQL Server (added mid-2025). Steps: In the RDS console, select the instance and choose Actions → Create Blue/Green Deployment . Set the Green instance to your target instance class. AWS creates a full standby using logical replication, keeps it in sync, and validates health. When ready, click Switch over . Cutover typically takes under 60 seconds. Applications reconnect using the same endpoint. Command-line equivalent: aws rds create-blue-green-deployment --blue-green-deployment-name resize-prod --source arn:aws:rds:... --target-db-instance-class db.m6i.xlarge Best when: your engine supports it and you can tolerate the extra cost of running two instances for the sync window. Fix #2: Read-replica promotion For engines or versions that do not yet support Blue/Green, or for cross-region resizing. Steps: Create a read replica with the desired new instance class. Wait for the replica to catch up (near-zero lag). Point application writes to the read replica endpoint (requires connection-string change or DNS switch). Promote

Quick Answer (TL;DR) EC2 Spot lists at up to 90% off On-Demand , but the effective savings after accounting for interruptions, engineering overhead, and workload retries land closer to 40 to 60% for most teams in 2026. Spot wins for stateless, retryable, or checkpointable workloads. It loses money on single-instance stateful services with strict SLAs. The honest formula: True savings = Spot discount × Utilization ÷ (1 + Interruption overhead) . Why the sticker discount is misleading The Spot price is a market price. AWS sets it against unused capacity in a given instance family, region, and Availability Zone, and it can move in minutes. The 90% headline is the maximum discount for a rarely-used instance family in an off-peak region. The workhorses ( m6i , c7i , r7g in us-east-1 ) usually sit at 55 to 75% off. Then there is the hidden cost of interruption. AWS gives a 2-minute warning before reclaiming a Spot instance. Handling that gracefully requires either a stateless workload, a checkpointed job, or careful autoscaler wiring. Teams that do not build for interruption end up with retries, half-finished batches, and engineering time that erases the savings. Fix #1: Diversify across instance types and AZs The single most effective way to reduce Spot interruption rate. Instead of asking for m6i.large specifically, ask for "any of m6i.large , m6a.large , m7i.large , m7a.large in any AZ." AWS pools capacity across the diversification pool. With Karpenter or Auto Scaling Groups: Set the NodePool or ASG's requirements to allow 5 to 15 instance types across families. Include both x86 and ARM (Graviton) options when your workload runs on both. Enable capacity-optimized-prioritized allocation strategy, which picks the deepest capacity pool at launch. Result: interruption rate drops from ~5% per instance-hour to under 1% on most workloads. Fix #2: Use Spot for the right workload shape Not every workload should be on Spot. The rule I use: Great fits : batch processing, data pi

Part of my AWS learning journey — transitioning from Systems Engineer to Cloud/DevOps. This session covers Amazon EFS — shared storage that multiple EC2 instances can read/write simultaneously. 📋 Topics Covered # Topic Type 1 What is Amazon EFS Concept 2 EFS vs EBS vs S3 Concept + Interview 3 EFS Architecture (Mount Targets, AZs, NFS) Concept + Cert 4 Mounting — What It Means Concept 5 Mount Targets & Security Group Config Concept + Lab 6 EFS Storage Classes Concept + Cert 7 EFS Lifecycle Management & Policies Concept + Cert 8 EFS Performance Modes & Throughput Modes Concept + Cert 9 Benefits of EFS Concept 10 Security & Encryption Concept + Interview 11 EFS Pricing & Cost Optimization Concept 12 Lab: Launch 2 EC2 Instances Lab 13 Lab: Create & Configure EFS Lab 14 Lab: Mount EFS on Both Instances Lab 15 Lab: Demonstrate File Sharing Lab 16 Cleanup Checklist Lab 17 Assignment — Independent Repeat Practice What is Amazon EFS? EFS = Elastic File System — a fully managed, auto-scaling shared file system that multiple EC2 instances can mount and use at the same time , both reading and writing. Analogy: Think of EBS as a personal hard drive — it belongs to one laptop only. EFS is like a shared Google Drive folder that your entire team can open simultaneously from different computers, see the same files, and edit them in real time. Key characteristics: Uses the NFS 4.1 protocol (Network File System — standard Linux file sharing) Serverless — no capacity to provision, no servers to manage Auto-scales — grows from KB to PB automatically, shrinks when files are deleted Highly available — data replicated across multiple AZs in a Region Pay-as-you-go — billed per GB actually stored, no pre-provisioning EFS vs EBS vs S3 — The Big Comparison This is one of the most commonly tested comparisons in AWS certifications. Feature EBS EFS S3 Access Single EC2 instance only Multiple EC2 instances simultaneously Internet / API, unlimited clients Protocol Block storage NFS v4.1 HTTP/REST (

AWS ECR Guide for ECS Fargate Teams Originally published at https://fortem.dev/blog/aws-ecr-guide AWS ECR from the ECS Fargate operator's seat: how pulls work, the execution-role IAM, why private-subnet tasks fail, real pricing, and the lifecycle policy that cuts the bill. Every ECS Fargate deploy pulls an image from ECR — and ECR is the part nobody owns until it breaks. A task in a private subnet throws ResourceInitializationError , or five years of untagged images quietly push the bill to $400/month. This is ECR from the ECS operator's seat: how pulls actually work, the IAM the execution role needs, what it costs at fleet scale, and the lifecycle, scanning, and replication settings that matter at 10+ environments — with the AWS-verified pricing nobody else itemizes. TL;DR ECR is AWS's managed container registry — the default image store for ECS and EKS. Registry → repository → image, with IAM-based access and a short-lived auth token per pull. The #1 ECR failure on Fargate is a private-subnet task that can't pull: it needs either a NAT gateway or three ECR VPC endpoints, plus AmazonECSTaskExecutionRolePolicy on the execution role. ECR storage is $0.10/GB-month; same-region pulls to Fargate are free. The hidden bill is old images — one team went from $400/mo to ~$15/mo with a 30-day lifecycle policy. At fleet scale three settings matter: lifecycle policies (cost), scan-on-push (security), and cross-account replication (multi-account image distribution). For ECR-heavy fleets in private subnets, VPC interface endpoints are often cheaper than routing every pull through a NAT gateway. Ready to use — copy this today Push an image, then a lifecycle policy that keeps the bill flat, then the exact networking + IAM a private-subnet Fargate task needs to pull: # 1. Authenticate Docker to your private ECR registry, then push aws ecr get-login-password --region us-east-1 \ | docker login --username AWS --password-stdin \ 123456789012.dkr.ecr.us-east-1.amazonaws.com docker tag

TL;DR — A Kafka + Flink + OTel ingestion pipeline cost us ~$700–800/month at 10 MB/s. We rebuilt it as a single binary where the data, the write-ahead log, and the Iceberg catalog all live in S3 alone — no Kafka, no local disks, no coordination service — for ~$100/month . Here's the design. Self-hosted observability sooner or later runs into the problem of storing state. Query load, CPU, and data volume can all be handled by scaling out, but the stateful layer is something you have to operate by hand. At first it's almost unnoticeable: a disk degrades here, replication falls behind there, a recovery hangs somewhere else. As the data grows, incidents stop being one-offs and start to recur. At some point your observability stack - whether it's Grafana Loki, Elastic, or ClickHouse - starts demanding the same attention as a full-blown database that you're on the hook for. Kubernetes operators cover some of these cases, but operating the state is still on you. Managed solutions take that burden away and bring their own: rising costs, ingestion-pipeline constraints, and limits on retention and cardinality. But if you'd rather not sign up for the constant operational grind - or live with the constraints of managed solutions - it's worth asking: can we take the stateful part out of operations entirely? Storage and format The first candidate for offloading storage responsibility is Amazon S3. S3 gives you what local disks can't: fault tolerance and practically unlimited scale, with no storage to manage yourself. It isn't free, though: data-access latency goes up, and you pick up separate costs for API operations. For OLTP workloads that's a dealbreaker. For observability workloads - which are dominated by sequential writes and analytical reads - these trade-offs are often acceptable. At first glance, this problem is already solved. Loki , for example, uses S3 as its primary storage. But according to Loki's public documentation (v3.6.x) at the time of writing, Loki doesn't re

I've been building on DynamoDB since around 2015, and these days I build tools for it: dynoxide , a DynamoDB engine, and Nubo , a native client. So I'm not neutral about it. It's the first database I reach for, and with reason - the operational overhead is close to nil, no connections to pool or instances to size, and it holds the same single-digit-millisecond reads whether the table has a thousand items or a billion. The data modelling is a craft, and a satisfying one. It's also one of the harder databases to learn, and that's the part I keep coming back to. DynamoDB punishes the instincts you bring from SQL. You don't normalise and join at read time; you work out the questions your app will ask first, and shape the data around those access patterns, until one table answers all of them. It's a real shift in how you think, and it's where a lot of people bounce off - it feels backwards right up until it clicks. The people who teach it best all teach it the same way. Alex DeBrie's The DynamoDB Book , the arc.codes team's examples, Rick Houlihan's re:Invent talks - the legendary ones, where he models half a dozen access patterns onto a single table at a hundred miles an hour - none of them hand you rules to memorise. They show you patterns and make you run them. I learned a lot of my DynamoDB from all three, and it stuck because I was building as I went. That last part is the bit that's hard to come by on your own. Reading about an access pattern and having it in your fingers are different things, and to run one - build the table, write the items, fire the query and see what comes back - you need an AWS account, or a local emulator installed and seeded. Enough friction that plenty of people read about single-table design without ever building one. There was a second thing pulling the same way. dynoxide had learned to run in the browser only last month, compiled to WebAssembly with no server behind it, and it was a preview I didn't fully trust. What it needed was a real

If you've let a coding agent loose on AWS, you've watched it guess. It invents API parameters that don't exist, or hands you an S3 bucket a security review will bounce on sight. The Agent Toolkit for AWS is built to stop that. By the end of this post you'll have it running in whatever editor you use, plus a tour of what's in it and three workflows worth pointing it at. I use Kiro day to day, so I'll walk through that setup first. It also works with Codex, Claude Code, Cursor, and any other agent that speaks MCP, the Model Context Protocol, which is the open standard agents use to connect to outside tools and data. I'll cover those too. What is the Agent Toolkit for AWS? The Agent Toolkit for AWS is a free, AWS-supported set of tools that gives AI coding agents secure access to AWS, current documentation they can read mid-task, and tested procedures for the work they tend to fumble. It plugs into the agent you already use rather than asking you to switch. In practice, that shows up in a few ways, all detailed in the AWS user guide . The agent stops guessing about APIs it never saw. The models behind these agents trained on data that's months or years old, so anything AWS shipped recently is missing or wrong in their heads, and the toolkit hands them current docs and references at request time. For multi-step work like least-privilege IAM or a production serverless stack, it follows a vetted skill instead of reconstructing the steps from half-memory. Every call goes through your own IAM credentials, shows up in CloudWatch, and gets logged to CloudTrail, so you can scope an agent to read-only even when your role can write. And the toolkit costs nothing on its own; you pay only for the AWS resources the agent creates. It's the successor to the MCP servers, skills, and plugins AWS shipped under AWS Labs in 2025. Two things make me reach for it over a raw MCP setup: condition keys that let a policy tell an agent apart from a human, and skills that have been evaluated end

AWS launched Lambda MicroVMs, a new serverless compute primitive that runs each user session or AI agent in its own Firecracker virtual machine with hardware-level isolation, snapshot-based rapid launch, and state preservation for up to eight hours. Reddit community analysis found the minimum setup costs $3.03/day, roughly 9x Fargate spot pricing. By Steef-Jan Wiggers

👋 Hey there, Tech Enthusiasts! I'm Sarvar, a Cloud Architect who loves turning complex tech problems...

The interesting part of OpenAI and Codex on AWS is not that another cloud menu got more model names. That part is useful. Enterprises want strong models. Developers want Codex closer to their infrastructure, data, and deployment machinery. The interesting part is that frontier AI is being pulled into the same boring machinery that already governs everything else companies run: procurement, IAM, billing commitments, region policy, audit logs, support contracts, data boundaries, and security review. That sounds like paperwork. It is also how enterprise software becomes real. model access was the easy problem For a while, AI adoption was framed as an access problem. Can we call the model? Can we get enough rate limit? Can we wire the SDK into our product? Can the coding assistant see enough of the repo to be useful? Those are real questions. They are not the end of the story. The next set is much more familiar to anyone who has operated software inside a company: which account owns this usage, which data can cross the boundary, who can create agents, which region runs inference, how the bill is allocated, and what evidence exists when an incident involves model output. That is the part where the demo becomes a platform. OpenAI on AWS matters because many companies already have that platform muscle in AWS. They have IAM, billing, private networking, audit trails, procurement paths, compliance evidence, cost allocation tags, and teams whose job is to make all of this survivable. Putting a frontier model behind that machinery does not make the hard parts disappear. It makes them legible. bedrock is a procurement surface Amazon Bedrock is usually described as a managed model service, which is true and also undersells the point. For enterprises, Bedrock is a procurement and control surface. If OpenAI models and Codex are available through Bedrock, a company can route adoption through an existing cloud relationship instead of creating a new vendor path for every team that wa

This blog post is created for the purposes of entering the Hack the Zero Stack with Vercel v0 and AWS Databases hackathon. #H0Hackathon Building Innward: A B2B Hospitality Operating System with Vercel and Amazon Aurora The hospitality industry is notorious for relying on "legacy" software—clunky, slow, and disconnected. For the Hack the Zero Stack hackathon, I set out to build Innward , a modern, AI-ready Property Management System (PMS) that proves you can build enterprise-grade B2B tools in record time using Vercel v0 and AWS Databases. The Vision: Moving Beyond the Spreadsheet Hotel managers don't just need a place to store "Room 101: Occupied." They need to solve the "Hidden Math" of revenue management. This means: Relational Complexity: Linking dates, room groups, and individual stays. Dynamic Pricing: Deriving rates based on occupancy and logic-based rules. Market Intelligence: Real-time benchmarking against competitors. The "Zero Stack": Vercel + Amazon Aurora To handle this complexity, I chose Amazon Aurora PostgreSQL (Serverless v2) . Why Aurora for B2B? In a B2B SaaS environment, data isolation and relational integrity are non-negotiable. Aurora provided the robust relational power needed to join complex pricing tables while scaling automatically as more hotels (tenants) join the platform. The Zero-Secret Architecture One of the most rewarding parts of this build was implementing the AWS RDS Signer . Following the "Zero Stack" philosophy, I moved away from static database passwords. Innward uses IAM-based authentication to communicate between Vercel and AWS. By utilizing the @aws-sdk/rds-signer , the application generates short-lived tokens on the fly. This means even if an environment variable were leaked, the database remains locked tight. // lib/db.ts snippet const signer = new Signer ({ credentials : awsCredentialsProvider ({ roleArn : process . env . AWS_ROLE_ARN ! , clientConfig : { region : process . env . AWS_REGION }, }), region : process . env .

I created this post for the purposes of entering the H0: Hack the Zero Stack with Vercel v0 and AWS Databases hackathon. #H0Hackathon Inspiration — this one's personal This started with my daughter. She's 13 and an aspiring actor — she's already worked on campaigns and shows from national commercials to a children's TV show, and walked NYC and Brooklyn fashion shows. Every time we went to an audition or recorded a self-tape, I saw how disconnected the whole process was: submissions over email, schedules buried in texts, files scattered across folders, and no clear view of where anything actually stood. I started talking to talent agencies in New York and LA, and they all said the same thing — they're still managing their talent by hand, and it doesn't scale. That's why I built Quudos. The problem Talent agencies run casting on a patchwork of spreadsheets, email threads, shared folders, and disconnected casting databases. Submissions get lost, callbacks slip, and there's no single place to see a campaign move from breakdown to booking. Quudos is the all-in-one operating system for talent agencies — manage your roster, launch casting campaigns, and track every submission through callback and booking. For this hackathon I put it on the zero stack : a front end on Vercel and Amazon Aurora PostgreSQL as the primary database. The architecture Frontend: an Angular single-page app on Vercel , with a v0-built marketing landing page in front of it. API: a NestJS (Node) service using node-postgres with pooling, transactions, and advisory locks. Primary database: Amazon Aurora PostgreSQL (Serverless v2) in us-east-1 — the system of record for every agency, talent profile, campaign, role, submission, and lifecycle event. Auth: a managed auth provider issues JWTs that the API verifies; all application data lives in Aurora. Why Aurora — and a deliberate data model Casting is inherently relational, so I modeled it that way: organizations (agencies) → users (admins + talent) → actor

I built this project as an entry for the H0: Hack the Zero Stack with Vercel v0 and AWS Databases Hackathon. #H0Hackathon Inspiration Justice moves slowly. I learned that firsthand as my family navigated a legal dispute. What struck me wasn't just the stress — it was that things were quite disorganised. Documents were paper-based or buried somewhere in emails. Updates came through WhatsApp messages. Simple documents took a really long time to draft and send. The system was fragmented and difficult to navigate. Companies like Harvey tackle document drafting well, but legal research tools and LLM wrappers can hallucinate case law, citing judgments that don't exist. I knew that if I was going to build something for this space, it had to be grounded in real, verifiable law. That led me to Laws Africa, which provides structured access to actual South African legislation and court judgments. I also noticed a problem that lawyers experience daily: the mechanical work. Logging into court portals to file a case. Hunting through OneDrive, Google Drive, and Dropbox for the right version of a document. Sifting through hundreds of emails to find something relevant to a matter. Onboarding a new client when the intake form is a PDF someone emails you. These are not AI problems. They are automation problems — and lawyers or their secretaries are doing them manually every single day. That became Agently. What Agently Does Agently is a legal workspace that handles the full lifecycle of a matter, from the moment a client submits an intake form to the day the case closes. Matter Management. Every client engagement lives in a structured matter. Documents, emails, notes, contacts, workflows, and AI conversations are all scoped to it. A lawyer can open a matter and immediately see everything relevant. AI Agent with Real Legal Research. The AI connects to Laws Africa's knowledge bases — South African legislation, court judgments, and municipal law — so research is grounded in actual legal

The access you revoked in your last review is probably still live. I know how that sounds, but it is how most access recertification actually works. A tool generates a list, an owner clicks approve or revoke, the cycle gets marked complete, and then nothing touches the real resources. The review produces a record. The permissions stay exactly where they were. You attested to a state that was never made true. That gap bothered me for a long time, so I built something to close it and open-sourced it on AWS's aws-samples org. It is called VIGIL. The core idea A normal review answers one question: should this access still exist? The owner says no, a ticket gets filed, and maybe someone actions it next quarter. Between the decision and the change, the risk just sits there. I wanted the decision and the change to be the same step. So VIGIL does four things: It discovers resources by their owner tag and works out who actually has access to each one. It asks the owner to keep, trim, or remove that access. It applies that decision on the live resource. It records what happened in a way you can later prove. The part I care about most: scoped enforcement The lazy way to revoke someone's access to one bucket is to detach their policies. That nukes their access to everything, and it is how you cause an incident while trying to improve security. VIGIL never does that. If the access came from a bucket policy, it removes just that principal, or just the specific actions, from that bucket's policy. If the access came from the principal's own IAM policy, it adds a resource-scoped explicit Deny instead of touching shared policy, so nothing else the principal can do is affected. In practice it can remove only s3:PutObject for one principal on one bucket and leave everything else alone. If a change cannot be made safely and narrowly, it raises a ticket instead of guessing. I would rather it do nothing than do something broad. Making enforcement durable Enforcement is not a synchronous c

I created Agentis Lux for the purposes of entering H0 Hackathon (Vercel + AWS Databases). #H0Hackathon See Agentis Lux's Devpost.com entry . It started with a comment at a hackathon. A you.com employee said the thing out loud: the web has a second audience now. When you ask ChatGPT or Perplexity a question, a retrieval agent fetches a page and reads its HTML to answer you. Not the laid-out site with the buttons and the hero image. The markup underneath. These agents arrive by the million, and many of them rely on the raw or minimally rendered HTML rather than running your JavaScript, so they often see far less of your page than a person does. That comment sent me to build. My first answer to it was Hermes Clew , for the GitLab Duo Agent Platform Challenge. Hermes lived inside GitLab Duo Chat, no frontend, no database: a Python engine that scanned the HTML, JSX, and TSX files in a repo, scored them across six categories, and let an LLM reason over the findings. It proved the core idea. It also told developers how to fix things, lived inside one vendor's chat, and only worked on files in a repo. Agentis Lux is what happened when I took that idea to the open web and rebuilt it with a different stance. Any live URL, not just repo files. Its own product on a real cloud architecture, not a chat window. And no fix suggestions, on purpose, where Hermes used to hand them out. Same six-category bones, a new body, a sharper philosophy. It scans your site and shows you what that second audience experiences when it tries to read it. What it does You paste a URL to Agentis Lux . You get a report. The report is written from the agent's point of view. Not "this is broken." More like: "an agent landing on this page can't tell which element starts checkout, because it's a styled div and not a button." It reports findings. It does not suggest fixes, and that is on purpose. I know what the agent sees, not what you should change. That is the whole value: visibility, and you decide what