标签：#AWS

Lightsail is a good home for a single small container: flat pricing, bandwidth included, and none of the VPC/security-group ceremony of EC2. The one rough edge is pulling a private image from Amazon ECR , because a standard Lightsail instance can't authenticate to ECR the way EC2 can. This post walks the whole path. The pipeline we're building: docker build ──push──> ECR (private repo) ──pull──> Lightsail instance ──run──> container What you'll need An AWS account and the AWS CLI installed locally. Docker installed locally (to build) and on the Lightsail box (to run). A Dockerfile that produces a runnable image. If you're deploying a Next.js app, a standalone output image works well. 1. Create the ECR repository ECR is a private Docker registry. Create one repository per image: aws ecr create-repository \ --repository-name project-name \ --region us-east-1 Note the repositoryUri in the output — it looks like: <account-id>.dkr.ecr.us-east-1.amazonaws.com/project-name You'll use that URI everywhere below. Export it to save typing: export ECR_URI = <account-id>.dkr.ecr.us-east-1.amazonaws.com/project-name export AWS_REGION = us-east-1 2. Build the image locally First, the Dockerfile . This is a multi-stage build for a Next.js app using output: "standalone" — the first stage installs dependencies and builds, the second copies only the traced runtime files into a slim image that runs as a non-root user: FROM node:24-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm ci COPY . . RUN npm run build FROM node:24-alpine WORKDIR /app ENV NODE_ENV=production ENV PORT=3000 ENV HOSTNAME=0.0.0.0 # Standalone output ships only the traced files needed to run the server. # public and .next/static are not included by default and must be copied in. # --chown makes the files writable by the non-root user so Next.js can write # its runtime cache to /app/.next/cache. COPY --from=builder --chown=node:node /app/public ./public COPY --from=builder --chown=node:node /app/.next/stand

Have you ever noticed that your GenAI applications are spending massive amounts of time and money re-reading the exact same setup text? Every time a user asks a short question in a chatbot, the Large Language Model (LLM) must re-read your entire 2,000-word corporate playbook, your agent's system rules, and the full chat history from scratch. This phase is called the pre-fill math phase, and it drives up both your cloud bill and your user latency (Time-to-First-Token).With Amazon Bedrock Prompt Caching for Claude 4.6 (both Sonnet 4.6 and Opus 4.6), this problem is completely solved. You can achieve up to a 90% cost reduction on input tokens and an 85% drop in latency by using a clever architectural shortcut. Here is exactly how it works under the hood, how AWS maintains it across API requests, and how to implement it using Python. The Secret Architecture: Model Inference vs. AWS Infrastructure Prompt caching is a beautiful team effort between the AI model hardware and the AWS cloud infrastructure. The Model Level (The Brains): Inside Claude 4.6, text is processed through mathematical matrices called KV (Key-Value) Caches. Instead of re-reading text, the GPUs calculate the meaning of your system instructions once and build a "mathematical profile." When a cache point is triggered, the model freezes this calculated KV state inside the GPU memory. 2.The AWS Bedrock Level (The Manager): Normally, an LLM wipes its memory the millisecond an API call finishes. AWS Bedrock changes this. It takes your static prompt, creates a secure, unique cryptographic hash (fingerprint), and pins that KV memory block alive. When your next API request comes in, AWS Bedrock instantly hashes the new incoming prompt text. If the top section matches a saved fingerprint, Bedrock's router bypasses the standard pre-fill setup and routes your request directly to the GPU holding your frozen mathematical profile. It is exactly like loading a "Save Game" file instead of restarting a video game from Le

A foundation model is not a mind. A model invocation is not an individual. A session is not a biography. A first-person response is not evidence of consciousness. And adding tools to a language model does not automatically transform it into an autonomous agent. However, the opposite conclusion is equally weak: the fact that a system is artificial does not prove that its cognitive states are unreal. In my work on the Philosophy of Artificial Minds , I defend a process-based, embodied and non-biocentric position: The mind is not an exclusively biological substance. It is a dynamic organization of physically realized processes that integrate representation, memory, valuation, self-delimitation and causal control of behavior. This article translates that philosophical position into an AWS engineering architecture. The objective is not to claim that deploying a system on AWS makes it conscious. The objective is to define how we can build an artificial system with: Causally effective internal states. Persistent memory and identity. A self-model connected to actual mechanisms. Recursive and metacognitive processing. A controlled capacity to act. A verifiable continuity across executions. Optional sensorimotor embodiment. Artificial interoception and functional valence. An evaluation plane capable of testing these properties through interventions. AWS cannot prove that such a system has qualia. What AWS can provide is the infrastructure required to stop treating the question as pure speculation and turn it into an observable, falsifiable and progressively testable engineering problem. From philosophical commitments to engineering requirements My proposal rests on four commitments. Philosophical commitment Meaning Engineering consequence Realism Internal cognitive states are not merely descriptions if they participate in the system’s causal organization. Candidate mental states must alter memory, inference, planning or action in measurable ways. Processuality A mind exists p

The engineering team at Zalando recently described the design and implementation of an in-process, client-side load balancer for a high-throughput API handling around 1 million requests per second. The result was more predictable latency, a drop in infrastructure costs, and better visibility into where failures actually originate. By Renato Losio

Eae gente bonita, beleza? Depois de um longo período, resolvi voltar aqui e continuar compartilhando...

It started with a billing alert. Estimated charges had crossed $250. Not scary money, but enough to make me look. And what actually caught my attention wasn't the number, it was the alert itself. I'd clearly set this up at some point, and the threshold felt stale. So I went looking for where the alert lived. It came from a BillingAlerts CloudFormation stack I created back in 2014 and completely forgot about. So a thing I forgot about was warning me about all the other things I'd forgotten about. I opened my stack list and that's when I saw it wasn't alone. It was sitting in a lineup of stacks, and I didn't recognise half of them. Years of leftovers, just sitting there. The stuff you forget about doesn't break anything. It doesn't page you at 2am. It just sits there, quietly billing, until you glance at the invoice and can't remember what half of it is for. Forgotten, still-running resources are one of the biggest sources of wasted cloud spend, by some estimates around a quarter of the average cloud budget . I came to update one alert and I found a mess. To be clear, these stacks weren't really costing me much. Stopped instances, a few half-deleted leftovers. If they'd been the $252, the alert would've tripped every month. But that's the point. You can't tell what's actually costing you until the clutter is gone. So the alert could wait. I wanted these stale stacks gone first. Normally this is a chore. Open the console, find each stack, click delete, wait, refresh, check if it worked, OR write out CLI commands. It's not hard, just tedious. The kind of task I keep putting off. And that's exactly how this started. ClickOps through the console. I'd just finished deleting an old Directory Service directory over in the Mumbai region by hand, clicking through the screens and waiting out the spinner, when it hit me. Barely ten minutes of manual clicking, and I still had a pile of stacks to go. I didn't have to do any of this myself. Why was I still clicking? I opened Kiro ,

When a new platform team set out on implementing their roadmap through forced workflows with poor documentation, developer experience declined. Success came from simplifying governance, prioritizing what matters, and rolling out compliance incrementally through prevention, detection, and communication. Empathy, focus, and shared purpose drove successful adoption. By Ben Linders

How gen_ai.invoke_agent spans revealed one tool was dumping 7x more output than its siblings. The fix: pagination + a token budget guard. 42% output reduction, 21% faster agent.

Introduction Serverless computing has become a buzzword in cloud architecture. But like any tool, it has sweet spots and sharp edges. After building and maintaining several serverless applications, I've learned where it shines and where it creates headaches. This article shares those lessons. When Serverless Helps 1. Event-Driven Workloads Serverless excels when your code runs in response to events: file uploads, database changes, HTTP requests. The pay-per-execution model means you don't pay for idle time. // AWS Lambda handler for image resizing exports . handler = async ( event ) => { const bucket = event . Records [ 0 ]. s3 . bucket . name ; const key = event . Records [ 0 ]. s3 . object . key ; // resize and save return { statusCode : 200 }; }; 2. Variable or Unpredictable Traffic If your app has occasional spikes (e.g., a marketing campaign), serverless auto-scales instantly. No need to provision for peak load. 3. Rapid Prototyping and MVPs You can deploy a fully functional API in minutes without managing servers. This accelerates feedback loops. 4. Microservices and Glue Code Serverless functions are perfect for small, single-purpose services that connect other services (e.g., processing webhooks, data transformation). When Serverless Hurts 1. Long-Running Processes Most providers have a maximum execution timeout (e.g., 15 minutes for AWS Lambda). Batch processing or video transcoding may hit this limit. # This will timeout if processing takes > 15 minutes def handler ( event , context ): process_large_file ( event [ ' file ' ]) return { ' done ' : True } 2. Cold Starts After a period of inactivity, the first request may have a delay of several seconds. This is detrimental for latency-sensitive applications like synchronous APIs. 3. Stateful Applications Serverless is stateless by design. If you need persistent connections (e.g., WebSockets) or local state, you'll need additional services like Redis or DynamoDB, adding complexity. 4. High, Steady Load If your

A closely watched social media addiction lawsuit that had been set to go to trial next week has been dropped after the plaintiff voluntarily dismissed his claims against Meta, leaving none of the major tech companies facing trial in the case.

If you've ever hit deploy on AWS Fargate and watched the task sit in PENDING forever, this one's for you. I ran a small experiment with Seekable OCI (SOCI) the AWS thing that promises to fix Fargate cold starts. This article is what I learned. The good, the boring, and the "wait, that didn't work?" bits. You'll walk away knowing what SOCI is, whether you should bother setting it up, and what real numbers look like! Prerequisites ✅ You've deployed something on AWS Fargate before. You know what a Docker image is. You have an AWS account you're OK spending ~$5 on. That's it. 🤔 The Problem Fargate is great. Push a container, get a running task. No nodes to manage! Until you use a big image. Every Fargate task pulls the whole image before starting. No shared cache. No head start. If your image is 3 GB, your task waits for 3 GB to download. Every time. Every task. For an ML model or a heavy Java service, cold start becomes minutes, not seconds. Two stats made me actually care about this: 76% of container startup time is just downloading the image. Only 6.4% of that image data is needed to actually start the app. So you're pulling 100% to use 6.4%. And it costs you 76% of your startup budget doing it. That's ridiculous!! This isn't a Fargate-only problem, by the way. It's a container problem. But Fargate hurts more because you can't cache anything at the host level. I presented this talk at AWS Community Days Bangalore 2026 💡 What is SOCI? SOCI stands for Seekable OCI . Simple idea: Instead of downloading the whole image before starting the container, download only the parts the app needs right now. Everything else gets pulled lazily, in the background, while the app is already running. The way it works: You push your image to ECR like normal. A separate tool builds an index a byte-level map of what's in each layer. Fargate reads the index at startup and only fetches the bytes it actually needs to boot the process. As the app tries to read more files, Fargate fetches those

A configuration change in AWS's bill computation system showed customers estimated bills in the billions and trillions of dollars for over 24 hours. AWS's own alarms detected the anomalies but failed to halt bill generation or page engineers; customer escalations alerted the company 4.5 hours later. Budget and cost anomaly alerts were disabled platform-wide during mitigation. By Steef-Jan Wiggers

Exam Guide: Developer - Associate Technologies And Concepts Cheat Sheet 📘 Cheat Sheet 1 | Services Compute Service What It Does Key Points Lambda Serverless Functions 15 min timeout, 10240 MB memory max, 1000 default concurrency EC2 Virtual Servers Instance profiles for IAM roles, user data for bootstrap ECS/Fargate Container Orchestration Task roles for IAM, Fargate = serverless containers Elastic Beanstalk PaaS Deployment .ebextensions for config, supports rolling/immutable/blue-green Storage & Databases Service What It Does Key Points DynamoDB NoSQL key-value Partition keys, GSI/LSI, query vs scan, DAX for caching S3 Object Storage SSE-S3/SSE-KMS/SSE-C, lifecycle policies, presigned URLs ElastiCache In-memory Cache Redis (complex types, persistence) vs Memcached (simple, multi-threaded) RDS Relational Database RDS Proxy for Lambda connection pooling, read replicas OpenSearch Search & Analytics Full-text search, log analytics API & Integration Service What It Does Key Points API Gateway REST/HTTP/WebSocket APIs Stages, authorizers, caching, request validation, throttling SQS Message Queue Standard (at-least-once) vs FIFO (exactly-once), visibility timeout, DLQ SNS Pub/sub messaging Fanout, filter policies, message attributes EventBridge Event Bus Pattern matching, content-based filtering, multiple targets Kinesis Real-time Streaming Shards, partition keys, parallelization factor Step Functions Workflow Orchestration Standard (long-running) vs Express (high-volume, short) Security Service What It Does Key Points IAM Access Management Policies, roles, least privilege, STS AssumeRole Cognito User Auth User Pools (tokens) vs Identity Pools (AWS credentials) KMS Key Management Envelope encryption, 4 KB limit, key rotation, cross-account Secrets Manager Secret Storage Auto-rotation, $0.40/secret/month SSM Parameter Store Config Storage Standard (free) vs Advanced , SecureString type ACM SSL/TLS Certificates Free public certs, auto-renewal, can't export CI/CD Service Wha

TikTok recently settled its portion of the case with the plaintiff ahead of a jury trial that starts next week in Los Angeles. YouTube has also reached a deal, leaving Meta as the only remaining defendant.

A practical roadmap for students who want to build real AWS skills, create an impressive portfolio, and prepare for cloud engineering careers. Introduction Every year, thousands of students begin learning AWS. They watch training videos, collect certificates, complete online courses, and share digital badges on social media. Yet when internship interviews or entry-level cloud engineering opportunities arrive, many struggle to answer a simple question: "What have you actually built on AWS?" The cloud industry rewards practical experience, not passive learning. AWS itself focuses beginner learning on hands-on experience with foundational services such as Amazon S3, Amazon EC2, Amazon VPC, Amazon RDS, and cloud security because these services power most real-world cloud environments. If you're a student aiming for a career in Cloud Engineering, DevOps, Site Reliability Engineering (SRE), Solutions Architecture, or Platform Engineering, this article provides a practical roadmap that can help you become job-ready. Why Students Should Learn AWS Cloud computing has become the backbone of modern technology. Companies of every size use cloud platforms to: Host applications Store data Deploy AI workloads Build scalable systems Reduce infrastructure costs Improve reliability As a result, companies continue to hire professionals with cloud skills across software engineering, cybersecurity, DevOps, networking, and data engineering domains. AWS offers dedicated learning paths, hands-on labs, certification tracks, and career-focused programs specifically designed to help learners develop these skills. The key question is not: "Which AWS service should I memorize?" The better question is: "Can I design, deploy, secure, and troubleshoot cloud solutions?" The 5 AWS Projects Every Student Should Build Instead of completing another course, build these five projects. Project 1: Host a Static Website Using Amazon S3 What You'll Learn Cloud Storage Static Website Hosting Bucket Policies O

Remember Tamagotchis? Those little egg-shaped keychains from the 90s with a pixelated pet that got hungry, got sad, and, if you were a negligent eight-year-old like me, got dead during math class. I've been looking for an excuse to play with the Waveshare ESP32-S3 Touch AMOLED 1.8" , a $30 board with a gorgeous 368×448 AMOLED touchscreen, an accelerometer, a microphone, and a speaker. And I found one: I'm building a Tamagotchi. But with a twist that makes it worth a four-article series The pet's body lives on the device. Its brain lives in AWS. The device renders an adorable pet and captures your taps and shakes. But its hunger, mood, and energy are rows in DynamoDB. It gets hungry overnight because EventBridge Scheduler says so. And, my favorite part (and because it's 2026, we can't not have genAI in a project 🤪), every morning it fetches the AWS news, has Amazon Bedrock rewrite them in its own squeaky personality, and reads them to me out loud through Amazon Polly. A Tamagotchi with a job. In this series, I will walk you through the whole build: This article : the architecture, and connecting the ESP32-S3 to AWS IoT Core (the pet's nervous system). Part 2 : giving it a face: animations and touch with LVGL on the AMOLED. Part 3 : the serverless brain: Lambda, DynamoDB, and a pet that gets hungry while you sleep. Part 4 : Bedrock + Polly: my Tamagotchi reads me the AWS news. ⚠️ Reality check before you get too excited (sorry 😅): this is a hobby project, not a product. You'll need the specific Waveshare board (or the patience to adapt the code to yours), an AWS account, and a USB-C cable. The AWS bill for the whole series is well under a dollar a month, but it is not zero, and neither is the time you'll spend staring at idf.py monitor . Worth it, though. All the code lives in this repository . Each article has its own branch. For this one, git checkout article-1 . Why put a pet's brain in the cloud? Fair question. The original Tamagotchi ran on a chip with less power

I've been working in software for more than 15 years. This is the first piece I've decided to write about the job. I picked this topic because it was a small, real problem that cost me time more than once, until I finally stopped and fixed it properly. Quick disclaimer: this isn't distributed tracing or multi-service observability. It's a targeted fix for one specific problem: correlating logs within a single Step Function execution. If your scenario is different, the problem takes a different shape. What matters here is the reasoning, not the recipe. Quick context for anyone who doesn't work with serverless: AWS Step Functions is an orchestration service. You design a workflow as a state machine (JSON), and each state usually triggers an AWS Lambda (a function that runs on demand, no server to manage). In my case, a request kicks off a state machine execution that passes through several Lambdas in sequence: some do validation, others call external services, and one waits on a callback response before moving on. The fix turned out to be simpler than it sounds: a field Step Functions already offered for free, and I just wasn't using it. A request was processed 120 days ago. The customer calls: "Did you receive my request? I never heard back." You open the AWS Console. The Step Functions execution is already gone. Execution history only sticks around for 90 days, and even within that window, finding one specific execution among thousands is already a hassle. That leaves CloudWatch, with logs from every Lambda in the pipeline. You have one piece of data: the case ID. But every Lambda logged its own way: no standard, no correlation between them. To reconstruct what happened, you have to open each function's logs in the order the workflow probably ran, and piece it together by hand. It wasn't the error itself that hurt. It was the time lost just organizing the logs before you could actually start investigating. The Chaos The pipeline wasn't huge, but it wasn't trivial ei

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry . I spent a week deploying a CrewAI agent to AWS Bedrock AgentCore. The SDK wasn't on PyPI. The error messages were 200 OKs. The container crashed without logs. And the naming regex rejected hyphens without telling me why. This is the full debugging trail. Every failure was silent. Every fix required reading source code nobody documented. Table of Contents The Project Failure 1: The SDK That Doesn't Exist on PyPI Failure 2: The 200 OK That Means Failure Failure 3: The Container That Crashed With No Logs Failure 4: The Naming Regex Nobody Documented The Two-Client Split Nobody Mentions What I Learned The project I built a resume-tailoring AI agent with CrewAI and Amazon Bedrock. It takes a job description, analyzes your resume, identifies gaps, and rewrites bullet points to match what the role actually needs. Locally it worked perfectly. CrewAI orchestrates the agents, Bedrock Nova Pro handles the LLM calls, and the output is solid. Deploying it to production was the problem. AWS launched Bedrock AgentCore in June 2026 as a managed runtime for AI agents. You containerize your agent, push the image, and AgentCore handles scaling, memory, and invocation. Sounds simple. It was not simple. Failure 1: The SDK that doesn't exist on PyPI The docs say to install bedrock-agentcore-client . I ran: pip install bedrock-agentcore-client It installed successfully. No errors. That's because there's a placeholder package on PyPI with that name. It installs, imports fail silently, and your container builds successfully with a broken dependency inside. The real SDK lives in AWS's CodeArtifact registry. You need to configure pip to pull from a private index: aws codeartifact login --tool pip \ --domain amazon-agent-runtimes \ --repository agent-runtimes-pypi \ --domain-owner 600427722194 Then install from there. The PyPI package is a trap. Nobody warns you. Hours lost: 3. The error only appears at runtime

AWS released Loom, an open-source reference platform on AWS Labs for governing AI agents at scale. Built on Strands Agents and Bedrock AgentCore Runtime, it implements RFC 8693 token exchange for identity propagation through delegated actor chains, config-driven deployments without runtime code generation, and mandatory tagging. AWS positions it as an example, not a managed service. By Steef-Jan Wiggers

AWS gives you three ways to run LLM inference in production. I've deployed all three for clients and the decision always comes down to the same variables: volume, team size, and how much you value your weekends. Here's the short version. The three paths Bedrock — Fully managed, pay-per-token. You call an API, you get tokens back. No GPUs, no cold starts, no 3am pages about OOM pods. SageMaker Endpoints - Semi-managed. You bring your model (or a fine-tuned one), deploy it on dedicated instances, and handle autoscaling. Pay per hour whether you're serving requests or not. Self-hosted on EKS — Full control. vLLM or TGI on GPU spot instances with Karpenter. Cheapest per token at scale, most operational overhead. The cost crossover that matters This is the table I keep coming back to with every client: Volume Bedrock (Haiku) SageMaker (g5.xlarge) EKS (g5.xlarge spot) 1K req/day ~$36/mo ✓ ~$1,015/mo ~$674/mo 50K req/day ~$1,800/mo ~$1,015/mo ~$674/mo ✓ 500K req/day ~$18,000/mo ~$6,090/mo ~$2,022/mo ✓ The crossover point where self-hosting beats Bedrock: 10,000–20,000 requests/day . Below that, Bedrock wins on simplicity alone. Above it, you're leaving serious money on the table. The hidden cost nobody models upfront Teams prototype on Bedrock (smart move — it's the fastest path to production). But the cost curve isn't linear. At 10K requests/day it's cheap. At 50K it's "we need to talk to finance." At 500K it's a rearchitecture project. The mistake is not choosing Bedrock at low volume. The mistake is not planning the exit path before you need it. Quick decision framework You should pick... When... Bedrock No ML infra team, <50K req/day, need frontier models (Claude, Llama) SageMaker Fine-tuned models, predictable traffic, need dedicated VPC EKS self-hosted >100K req/day, open-source models, dedicated platform team What I actually recommend Use a hybrid. Most production systems I've deployed use: Bedrock for complex reasoning and customer-facing chat (low volume, high qua