← All guides

Reference

Every AWS connection Korve can wire, and exactly what each one creates

A complete reference for all 15 wiring templates — the IAM roles, security group rules, event source mappings and alias records Korve creates when you draw a line between two services, plus how each is verified and undone.

Updated 2026-08-02

In Korve, a line between two nodes is not decoration. Each connection maps to a wiring template: a piece of code that knows the real AWS chain those two services need, creates it on deploy, verifies it afterwards, and can take it back apart cleanly.

This page documents all fifteen, what each actually creates in your account, and how to check the result yourself with the AWS CLI.

The full matrix

Direction matters. (A, B) is not (B, A). sqs → lambda means the queue triggers the function; lambda → sqs means the queue is the function's dead-letter destination. Two different lines, two different pieces of infrastructure. Draw the one that matches the direction data flows.

The three categories

Every template falls into one of three shapes, and knowing which you're drawing tells you what to expect.

Permission wiring creates IAM. ec2 → s3, lambda → dynamodb, lambda → s3, lambda → sns, iam → ec2, iam → lambda. Nothing about the network changes; what changes is who is allowed to call what.

Network wiring creates security group rules. ec2 → rds is the clearest case: no IAM is involved at all, because RDS authentication is a database concern. What was missing was a path through the firewall.

Event wiring creates the plumbing that makes one service invoke another. sqs → lambda builds an event source mapping. sns → lambda creates a subscription plus the resource policy that lets SNS call the function. cloudwatch → sns sets the alarm's action.

Permission wiring, in detail

ec2 → s3

An EC2 instance cannot be handed a policy directly. AWS requires a chain: a role the instance can assume, an instance profile that carries that role onto the instance, and a permissions policy scoped to the bucket. Korve builds all three, then attaches the profile.

The policy is scoped to the specific bucket ARN and its objects — arn:aws:s3:::your-bucket and arn:aws:s3:::your-bucket/ — not s3: on *. That distinction is the entire point. The hand-rolled version of this task, spread across four console screens, is where people give up and use a wildcard.

Verify it:

aws ec2 describe-instances --instance-ids i-0123456789abcdef0 \
  --query 'Reservations[].Instances[].IamInstanceProfile'

lambda → dynamodb and lambda → s3

A Lambda function already has an execution role from the moment it is created, so there is no role to build. Korve attaches an inline policy to that existing role, scoped to the one table or bucket you connected.

Inline rather than managed is deliberate: an inline policy is owned by the role and dies with it, so undo is exact and nothing is left orphaned in your account.

aws iam list-role-policies --role-name your-function-role

iam → ec2 and iam → lambda

These are the explicit versions of the above: you have a role you want used, and you say which compute uses it. iam → ec2 creates the instance profile if it does not exist and attaches it. iam → lambda updates the function's execution role.

Network wiring: ec2 → rds

This is the connection people most often get wrong by hand, because the failure mode is a hang rather than an error.

Korve reads the security groups actually attached to the instance, reads the ones attached to the database plus the port the database is really listening on, then authorises ingress on the RDS security group from the EC2 security group — one rule per pair.

Two details worth internalising:

• The rule references the EC2 security group as the source, not an IP address. Instances change addresses; group membership does not. This is the difference between a rule that survives a restart and one that quietly stops matching.
• The port is read from the live database description, not assumed. Postgres on 5432 and MySQL on 3306 are conventions, not guarantees, and a database moved to a non-standard port is exactly the case a hardcoded rule breaks on.

If the rule already exists, AWS returns InvalidPermission.Duplicate, which Korve treats as success. Any other error propagates rather than being swallowed — a wiring step that silently half-worked is worse than one that fails loudly.

aws ec2 describe-security-groups --group-ids sg-rds123 \
  --query 'SecurityGroups[].IpPermissions'

Event wiring

sqs → lambda

Creates an event source mapping, and grants the function's role the queue permissions the poller needs: sqs:ReceiveMessage, sqs:DeleteMessage, sqs:GetQueueAttributes. Miss the IAM half and the mapping exists but never delivers, which looks like a broken queue.

sns → lambda

Two pieces: a subscription from topic to function, and a resource-based policy statement on the function allowing lambda:InvokeFunction from that topic ARN. This is the one people forget, because the subscription appears healthy in the console while every publish is silently denied.

lambda → sqs

The reverse direction, and a different feature: this sets the queue as the function's dead-letter destination for failed asynchronous invocations, and grants sqs:SendMessage so the function can actually deposit failures there.

cloudwatch → sns

Adds the topic ARN to the alarm's actions, so a state change publishes a notification.

Routing and TLS

route53 → alb creates an alias A record — not a CNAME — pointing at the load balancer's hosted zone. Alias records resolve at the zone apex, which CNAMEs cannot, and cost nothing to query.

acm → alb attaches a certificate to the HTTPS listener, creating the listener if it does not exist.

Verify and undo

Every one of the fifteen templates ships with a verify function. After wiring, Korve re-reads the live account and confirms the thing it created is actually there and shaped correctly. A template that returns success without verification is only telling you the API call did not error, which is a much weaker claim.

Undo is equally precise, because each template records exactly what it created — the specific rule, the specific inline policy name, the specific mapping id. Removing a connection reverses only that, and never touches something that happened to be adjacent.

This is why removing a line is safe in a way that "delete the resources and start over" is not. If you connected ec2 → rds and later remove it, the security group rule Korve added is revoked; rules you added yourself remain untouched.

When there is no template

Korve does not invent wiring it does not understand. Drawing a line between two services with no registered template leaves the line as a visual annotation — no infrastructure is created, and nothing is silently approximated. That is deliberate: a tool that guesses at IAM is worse than one that admits it does not know.

The fifteen here cover the connections that make up most real architectures. The list grows as each new one is implemented, verified against a live account, and given a working undo — not before.