AWS

AWS, managed with guardrails.

Inventory every region, see what depends on what before you touch it, check configuration against cited benchmarks, reach instances without opening a port, and run Terraform from a repository behind an approval step. The deepest of the four cloud managers.

Install itSee the security model
EC2 · S3 · RDS · Route 53·IAM · CloudTrail · Config facts·SSM · Secrets Manager · Backup·Terraform · GitHub·EKS · ECR · Lambda

SEE IT RUN

AWS in Talos5:04

THE MANUAL WAY

What running AWS from the console looks like.

THE DELETE THAT TOOK THREE THINGS WITH IT

A security group looked unused. It was referenced by a launch template, which fed an Auto Scaling group, which kept checkout running. The console showed you the group, not what depended on it.

THE BASTION NOBODY WANTS TO OWN

To reach a private instance you keep a jump host with port 22 open to an office range that changed twice. Everyone knows it is a risk; it is also the only way in.

THE CLEAN REPORT THAT CHECKED NOTHING

A compliance scan came back with no findings. It had not been able to read half the regions, and it did not say so. Silence looked exactly like a pass.

WHAT TALOS DOES

Six things Talos makes visible in AWS.

Every region, and the global scope

Inventory sweeps each enabled region plus the global services separately. A region that could not be read is named as missing, and a partial sweep never overwrites a complete one.

Ownership and tombstones

Each resource records who is allowed to change it (Talos, a Terraform stack or someone else), and a resource that vanishes from a sweep is marked absent, not quietly deleted.

Resource graph and blast radius

Relationships between instances, groups, subnets, load balancers and roles are collected, so a destructive action shows what depends on its target before it is allowed to run.

Posture with cited severity

S3 and IAM configuration checked against published controls. Every finding links its source and the framework version, and a check that could not run says NOT EVALUATED rather than pass.

Fleet operations without inbound ports

Port-forward to an instance through Session Manager, run commands from an allow-list of documents, and rotate secrets. All three are off until enabled per account, scoped to tagged instances, and never show a secret’s value.

Terraform from your repository

Connect a repository, plan it through the queue, review the plan, and apply exactly that saved plan after approval. Drift is checked on a schedule, so changes made outside Terraform surface early.

talos.internal/aws/graph
Servers
Cloud
Kubernetes
Docker
Databases
Frappe
Pipelines
Monitoring
MLOps
Proxy
DNS & SSL
MCP
Impact previewsg-0a41… · 3 dependents
sg-0a41 · web-ingressTARGET
target of the requested delete
lt-checkout · v14DEPENDS
references sg-0a41
asg-checkoutDEPENDS
uses lt-checkout · 6 instances
eu-west-1 · globalCOMPLETE
both scopes reported this sweep
$ aws impact delete sg-0a41
→ graph from sweep completed 04:12 · 2 scopes
! referenced by lt-checkout → asg-checkout
! 6 running instances inherit this group
⏸ delete held · impact must be acknowledged

HOW IT RUNS

Every action is a tracked job.

Requestyou, API or schedule
Queueapproval if required
Job runnerbackground worker
ExecutionSSH · Ansible · Terraform · API
Your infrastructurelogs stream back live

WHAT MAKES THIS DIFFERENT

A check that could not run is not a pass, and a missing resource is not a deleted one.

Talos reports coverage as well as results: a region it could not read and a resource it did not see are each recorded as findings, never treated as empty or deleted. Every check reports PASS, FAIL or NOT EVALUATED with a reason. A scan is only complete if every scope it was meant to cover reported, and an incomplete one never supersedes a complete one’s verdict. Write access is limited the same way. Fleet writes are off for an account until someone turns them on, and the IAM policy Talos generates scopes sessions and commands to instances tagged ManagedBy=talos, so the limit is enforced by AWS, not only by Talos’s own code.

The resource graph, posture checks, fleet operations and repository-driven Terraform have each been run against a real, sandboxed AWS account, including proof that AWS itself refuses a session or command on an untagged instance.
Secrets Manager values are never read: the permission to fetch one is absent from every policy Talos generates, not just unused by its code.
Command execution is limited to an allow-list of documents, pinned in the IAM grant as well as in Talos. A raw shell document is deliberately not on it.
coverage · what shipped
✓
Core
EC2 · EBS · S3 · RDS · Route 53 · ACM · CloudWatch · cost · Lambda · ECR · EKS
BUILT
✓
Observation
ownership · graph · blast radius · change history · CloudTrail
LIVE-TESTED
✓
Posture
S3 · IAM · cited severity · NOT EVALUATED with reasons
LIVE-TESTED
✓
Fleet operations
port forwarding · allow-listed commands · secret rotation · backup reads
LIVE-TESTED
✓
IaC
repository plans · scheduled drift · gated apply of a saved plan
LIVE-TESTED
◐
Pull-request flow
built; not yet validated against real GitHub
BETA
✕
Backup restore
deliberately not built until it can be scoped safely
NOT BUILT

RELATED CAPABILITIES

Cloud overview

What AWS shares with Azure, GCP and Oracle.

explore →

Kubernetes

EKS clusters bridge in as Kubernetes projects.

explore →

DNS & SSL

Route 53 zones and ACM certificates in one estate view.

explore →

Attach one account, read-only.

Talos generates the IAM policy it needs. The first sweep writes nothing and tells you which scopes it could not read.

Install in one commandSee every capability →