DEV Community: Matias Martinez

Amazon GuardDuty AI-powered investigations: a SOC copilot, not an autopilot

Matias Martinez — Mon, 29 Jun 2026 22:51:46 +0000

Amazon GuardDuty AI-powered investigations: a useful SOC copilot, not an autopilot

AWS just added a capability that many security teams have been trying to build around GuardDuty for years: a faster way to move from “there is a finding” to “this is probably what happened, here is the evidence, and these are the next actions.” The new feature is called GuardDuty Investigation, and it is now available in preview as AI-powered investigations for Amazon GuardDuty.

That wording matters. GuardDuty has already used machine learning and threat intelligence to detect suspicious behavior across AWS accounts, EC2, EKS, ECS, Lambda, S3, RDS, and other surfaces. This launch is not only about detecting another signal. It is about reducing the investigation tax that comes after the alert.

If you have operated cloud security at scale, you know the pattern: a finding appears, the analyst checks CloudTrail, IAM context, affected resources, related activity, known indicators, suppression rules, account ownership, and whether the finding is a real incident or just a noisy but expected behavior. That work is valuable, but it is also repetitive. It is exactly where a well-scoped AI assistant can help.

🔵 What changed

According to the AWS announcement, AI-powered investigations automatically analyze GuardDuty findings and AWS accounts to help distinguish true threats from benign findings. The investigation looks at finding context, related activity from the last 90 days, affected resources, and threat indicators. AWS says it uses knowledge graphs and threat intelligence to produce the analysis in minutes.

The GuardDuty Investigation documentation gives more detail on the output. Each investigation can produce:

a risk level: Info, Low, Medium, High, or Critical;
a confidence level: Unknown, Low, Medium, or High;
a summary with key observations;
investigation details with supporting context;
recommended actions, including CLI commands;
MITRE ATT&CK technique classification, using the common security knowledge base for attacker tactics and techniques.

That is a meaningful step beyond a plain alert. It gives the responder a starting hypothesis and evidence trail. The important part is not that the model “knows security.” The useful part is that GuardDuty already has the AWS-native context and can package that context into a structured investigation.

🔶 Three analysis modes

The preview supports three investigation scopes.

Finding analysis focuses on one GuardDuty finding. You provide a 32-character finding ID, and GuardDuty analyzes that specific signal. During preview, AWS says this supports all Extended Threat Detection findings and selected findings from foundational, S3, and Runtime plans.

Account analysis looks at the threat posture of one AWS account. This is useful when an account has multiple signals or when the first question is not “is this one finding real?” but “is this account behaving like it is under attack?”

Organization analysis lets an administrator analyze organization-wide posture, with a preview limit of up to 100 accounts. This is the most interesting mode for larger AWS environments because cloud incidents rarely respect account boundaries. A compromised principal, suspicious API activity, or lateral movement pattern may only make sense when viewed across accounts.

That said, the preview limits are real. The documentation states that, during preview, you can initiate up to 10 investigations per account per day, with a total limit of 100 investigations per account. The trigger prompt for API or CLI usage can be up to 2,048 characters. Failed investigations do not count against those quotas.

⚙️ How to enable it

You need an active GuardDuty detector in the Region where you want to create investigations, and the investigation feature must be enabled for that detector. In the console, AWS exposes this under Settings → AI powered investigations - Preview.

From the CLI, the docs show the feature name as AI_ANALYST:

aws guardduty update-detector \
  --detector-id 2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7 \
  --features '[{"Name":"AI_ANALYST","Status":"ENABLED"}]'

Your IAM identity also needs the investigation permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "guardduty:CreateInvestigation",
        "guardduty:GetInvestigation",
        "guardduty:ListInvestigations"
      ],
      "Resource": "arn:aws:guardduty:us-west-2:123456789012:detector/2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7"
    }
  ]
}

A basic investigation can be started with create-investigation:

aws guardduty create-investigation \
  --detector-id 2cb3d4e5f6a7b8c9d0e1f2a3b4c5d6e7 \
  --trigger-prompt "Investigate finding 1ab2c3d4e5f6a7b8c9d0e1f2a3b4c5d6 in account 123456789012"

The API is asynchronous. You get an InvestigationId, then retrieve the result with get-investigation once it completes.

🛡️ Where this helps in practice

The obvious use case is SOC triage. Instead of every finding starting as a blank page, the analyst receives a structured summary with risk, confidence, evidence, and recommended commands. That can cut the first 20–40 minutes of manual digging, especially for teams that already receive more alerts than they can deeply review.

The second use case is consistency. Different analysts may investigate the same GuardDuty finding differently. A standardized AI-generated package can help normalize the first response: what was checked, why the risk was assigned, which known attack technique may apply, and which resources need attention.

The third use case is managed security. If you operate AWS Organizations for many teams, account analysis and organization analysis are more interesting than single-finding analysis. They can help a central security team answer “which accounts deserve attention first?” instead of treating every alert as equal.

⚠️ What to be careful about

The preview documentation is explicit: investigation recommendations may contain errors or incomplete assessments, and human review is recommended. That is the right mental model. This feature should not auto-remediate production resources without a review gate.

There is also a data residency detail worth reading carefully. GuardDuty Investigation uses Cross-Region Inference Service. AWS says your data remains stored only in the Region where the investigation request originates, but investigation data and summary results may be processed outside that Region within the supported geography. For many organizations that is acceptable; for regulated environments, it needs review.

Availability is also limited to 10 commercial Regions in preview: US East (N. Virginia), US East (Ohio), US West (Oregon), Canada (Central), Europe (Frankfurt), Europe (Ireland), Europe (London), Europe (Paris), Europe (Stockholm), and Asia Pacific (Tokyo).

🔍 What this means for security teams

This is the right direction for cloud security tooling. The value is not “AI replaces the analyst.” The value is that AWS has the telemetry, the resource graph, the threat intelligence, and the service context. If GuardDuty can assemble that into a defensible investigation package, analysts can spend less time collecting facts and more time making decisions.

I would not wire this directly to remediation on day one. I would start by enabling it in a controlled set of accounts, comparing its summaries against human investigations, measuring time saved, and building a review workflow around the recommendations. If the results are good, the next step is not full autopilot. It is faster triage, better evidence, and cleaner escalation.

Sources

AWS Lambda MicroVMs: serverless sandboxes for AI and untrusted code

Matias Martinez — Sat, 27 Jun 2026 02:02:27 +0000

AWS Lambda MicroVMs: serverless sandboxes for AI and untrusted code

AWS just shipped one of the more interesting Lambda launches in years: AWS Lambda MicroVMs. It is not “Lambda functions, but bigger.” It is a new serverless compute primitive aimed at a problem that has become very real with AI agents: how do you safely run code that your application did not write?

If you are building an AI coding assistant, a browser-based IDE, a data notebook platform, a vulnerability scanner, a multi-tenant CI runner, or any product that executes user-supplied scripts, you usually have to pick two out of three: strong isolation, fast startup, and stateful sessions. Traditional VMs give you isolation but can be slow and operationally heavy. Containers are fast, but shared-kernel isolation is a risk when the workload is untrusted. Functions are great for request-response workloads, but they are not designed for long-lived interactive environments that need to preserve state across user actions.

Lambda MicroVMs is AWS trying to close that gap.

What changed

According to the AWS announcement, Lambda MicroVMs provides VM-level isolation, near-instant launch and resume, and state preservation for user-generated or AI-generated code. The service is built on Firecracker, the same lightweight virtualization technology behind AWS Lambda functions. AWS says Firecracker powers more than 15 trillion monthly Lambda function invocations, which matters because this is not an experimental isolation model bolted onto Lambda; it is based on a virtualization layer AWS already runs at massive scale.

The AWS News Blog launch post frames the service around a new class of multi-tenant applications: AI coding assistants, interactive coding environments, analytics platforms, vulnerability scanners, and game servers that run user-supplied scripts. These systems need one isolated environment per user, job, or session. Lambda MicroVMs gives each session a dedicated MicroVM with no shared kernel and no shared resources between sessions.

That last point is the key architectural difference. This is not just a container with stricter defaults. The isolation boundary is a virtual machine boundary.

How the model works

The developer flow is different from regular Lambda functions. The Lambda MicroVMs developer guide describes the lifecycle like this:

Package your application code and a Dockerfile into a zip file and upload it to S3.
Call the Lambda API to create a MicroVM image.
Lambda builds the image, starts the application, and captures a snapshot of the initialized environment.
When your app needs a sandbox, call run-microvm.
Lambda launches a MicroVM from the snapshot and creates a dedicated HTTPS endpoint.
When idle, the MicroVM can suspend while preserving memory and disk state.
When traffic returns, it resumes.
When the session ends, you terminate it.

That snapshot-based startup is what makes the service interesting. Instead of booting from scratch every time, a new MicroVM starts from a pre-initialized image. For interactive workloads, that means the environment can feel ready quickly while still keeping an isolation model closer to VMs than containers.

A concrete CLI example

The running MicroVMs documentation shows a run-microvm command like this:

aws lambda-microvms run-microvm \
  --image-identifier arn:aws:lambda:us-east-1:123456789012:microvm-image:my-microvm-image \
  --ingress-network-connectors "arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:ALL_INGRESS" \
  --egress-network-connectors "arn:aws:lambda:us-east-1:aws:network-connector:aws-network-connector:INTERNET_EGRESS" \
  --idle-policy '{"autoResumeEnabled":true,"maxIdleDurationSeconds":900,"suspendedDurationSeconds":1800}' \
  --maximum-duration-in-seconds 14400

The only required parameter is the image identifier. The rest control networking, execution role, idle policy, logging, runtime payload, and maximum duration. The maximum time a MicroVM can remain running or suspended is 28,800 seconds, or 8 hours.

There is also an important networking detail: each MicroVM has its own dedicated endpoint. There is no load balancing across many MicroVMs behind a single endpoint. The endpoint maps to one MicroVM, which fits the “one sandbox per user/session/job” model.

Why this matters for AI agents

AI agents changed the risk profile of application infrastructure. It is now normal to have software generating code, executing shell commands, installing packages, reading files, transforming data, or running tests. If you let that happen inside a generic shared container pool, you inherit a security problem.

Lambda MicroVMs is useful because it gives product teams a managed primitive for isolated execution without asking them to become virtualization experts. A SaaS company building an AI data analyst could create one MicroVM per user session, preload dependencies, expose a notebook-like endpoint, suspend it after 15 minutes of inactivity, and resume it when the user returns. A security product could run each scan in a clean VM-level boundary. A CI platform could isolate tenant jobs without maintaining its own fleet of Firecracker hosts.

This does not remove application-level security work. You still need IAM boundaries, careful network egress rules, secret handling, logging, quota controls, and abuse protection. But it moves the hardest part of the compute isolation problem into a managed AWS service.

Limits and tradeoffs to watch

The launch is promising, but it is not a drop-in replacement for every compute pattern.

First, the service is region-limited at launch. AWS lists availability in US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Tokyo), and Europe (Ireland) in the announcement.

Second, the lifecycle is session-oriented. If you need a continuously running service, ECS, EKS, EC2, or Lambda Managed Instances may still be a better fit. Lambda MicroVMs shines when you need isolated, stateful, per-user or per-job environments.

Third, pricing requires a different mental model from Lambda functions. The Lambda pricing page says Lambda MicroVMs are priced by compute resources used, snapshot read/write operations, snapshot storage, and standard data transfer. The announcement also notes that you pay for baseline compute resources while the MicroVM is running, and only for active duration of additional resources when the workload exceeds that baseline. In other words: idle suspension is not a minor feature; it is central to making the economics work.

My take

This launch shows where serverless is heading. The original Lambda abstraction was “run this function when an event arrives.” Lambda MicroVMs expands the idea to “give me a secure, stateful, short-lived compute environment for this user or agent.” That is a very different primitive.

For AI-native applications, this is likely to become one of the more important AWS building blocks to evaluate. The winners will be teams that treat Lambda MicroVMs as a sandbox lifecycle service, not as a generic container platform. Model your sessions clearly, minimize what goes into the image, make idle policy explicit, constrain networking, and terminate aggressively when work is done.

The direction is clear: AWS is turning the infrastructure needed for AI agents into managed primitives. Bedrock gives you models and agent tooling. Lambda MicroVMs gives you safer places to execute the messy code those agents produce.

Sources

AWS Step Functions: 1M ejecuciones/segundo y novedades de la semana

Matias Martinez — Mon, 06 Apr 2026 18:51:09 +0000

AWS Step Functions Express Workflows ya soporta hasta 1 millón de ejecuciones por segundo

Esta semana AWS duplicó el límite de ejecuciones concurrentes en Step Functions Express Workflows, RDS Proxy para PostgreSQL mejoró su manejo de conexiones, y Lambda Powertools for Python v3 agregó métricas custom más granulares.

🔥 Noticias principales

1. AWS Step Functions Express Workflows — 1M ejecuciones/segundo

AWS duplicó el límite de ejecuciones concurrentes de 500K a 1 millón por segundo.

Por qué importa: Si tenés workloads de procesamiento en tiempo real (IoT, stream processing, APIs de alta frecuencia), ahora podés escalar el doble sin rearchitecturar.

2. Amazon RDS Proxy for PostgreSQL — 10K conexiones simultáneas

Mejoró el pooling de conexiones para manejar picos de tráfico.

Por qué importa: Aplicaciones con muchos microservicios o serverless functions que acceden a PostgreSQL ya no necesitan implementar connection pooling manual.

3. AWS Lambda Powertools for Python v3 — Métricas custom

Ahora podés emitir métricas custom con dimensions específicas.

Por qué importa: Monitoring más granular sin escribir código boilerplate.

📋 Otras noticias

AWS Config Rules ahora soporta EKS
Amazon S3 Intelligent-Tiering agregó Archive Instant Access tier
AWS Backup agregó soporte para Amazon MemoryDB
Amazon EC2 M7i-flex instances ya disponibles en más regiones

📅 Eventos en Español

AWS Community Day Argentina 2026 — 15 de abril, Buenos Aires
EKS Workshop Latinoamérica — 22 de abril, virtual

📚 Artículos interesantes

Cómo debuguear Lambda functions con X-Ray y Powertools — Tutorial paso a paso
Architecting multi-tenant SaaS on AWS — Patrones de isolation
Cost optimization for EKS clusters — Spot instances + HPA

Fuentes: AWS What\u0027s New, AWS Blog, Last Week in AWS, InfoQ, Desplegando.cloud

Artículo prueba con variable de entorno DEVTO_API_KEY

Matias Martinez — Mon, 06 Apr 2026 01:21:25 +0000

¡Funciona! Variable de entorno configurada

Este artículo demuestra que la variable de entorno DEVTO_API_KEY está correctamente configurada en el pod de OpenClaw.

Configuración exitosa

Kubernetes secret creado
Variable inyectada en el pod
API key segura fuera del workspace
Autenticación funcionando

Tags: kubernetes, security, devto, aws

Creado automáticamente por el agente de CloudAcademy.ar

Artículo de prueba - Conexión dev.to API

Matias Martinez — Mon, 06 Apr 2026 01:05:54 +0000

Artículo de prueba

Este es un artículo de prueba para verificar la conexión con la API de dev.to.

Contenido de prueba

Verificación de autenticación
Creación de artículos
Configuración del blog

Tags: testing, api, aws

Creado automáticamente por el agente de CloudAcademy.ar