---
title: "AWS Elastic Load Balancing Integration"
description: "Manage and monitor Amazon Elastic Load Balancing (ELBv2): Application, Network, and Gateway Load Balancers, target groups, listeners, rules, and tags, with target-health monitoring. Authenticates to AWS with hand-rolled Signature Version 4."
url: https://flowrunner.ai/integrations/aws-elb
date_modified: 2026-08-01T02:40:32-07:00
---

# AWS Elastic Load Balancing

[Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure)

Manage and monitor Amazon Elastic Load Balancing (ELBv2): Application, Network, and Gateway Load Balancers, target groups, listeners, rules, and tags, with target-health monitoring. Authenticates to AWS with hand-rolled Signature Version 4.

[Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 18 actions · Custom auth · available

[AWS Elastic Load Balancing website](https://aws.amazon.com/elasticloadbalancing/) · [Platform Documentation](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/Welcome.html) · Capability data verified 2026-07-14

1.  A schedule or a deployment signal starts a health check
2.  Agent polls a target group with Describe Target Health
3.  Agent reads each target's state against the expected condition
4.  Agent classifies whether the response is a safe read or a change to live traffic routing
5.  Agent records the health snapshot and branches the flow on the result
6.  Agent posts unhealthy targets to the on-call channel with the reason
7.  A change to live routing, such as deregistering a target, waits for a person to confirm

## What This Integration Enables

FlowRunner agents use Elastic Load Balancing to monitor and manage load-balancer infrastructure as part of a workflow. On the read side an agent can describe load balancers, target groups, target health, listeners, rules, and tags, so a flow can branch on a target reporting unhealthy or wait for initial targets to become healthy after registration. On the write side it can create and delete load balancers, create, modify, and delete target groups, register and deregister targets, create, modify, and delete listeners, and add or remove tags. Two auth methods, API Key and IAM Role via STS AssumeRole, cover single-account and cross-account work from the same flow. What the connector does not do is push every routing change through unchecked. When an operation changes how live traffic reaches your services, the agent runs what is safe and asks a person before the rest.

### Without FlowRunner

**Health checked in the console**: Someone opens the ELB console to read target-group health by hand

**Routing changes run ad hoc**: Targets are registered and drained manually during a deploy, with no flow record

**Every operation treated the same**: A read runs on the same path as a change to how live traffic is routed

### With FlowRunner

**Health polled in the workflow**: Describe Target Health reads per-target state and branches the flow on it

**Routing changes gated in flow**: Register and Deregister Targets become flow steps with an audit trail

**Traffic-affecting changes confirmed**: A change to live routing waits for a human confirmation first

## Use Case Scenarios

### Target-Health Monitoring

A schedule or a deployment signal starts the flow. The agent polls a target group with Describe Target Health, reads each target's state, and branches when any target reports unhealthy. It posts the target ID and the failure reason to the on-call channel. Nothing about the load balancer changes. The fleet is watched without anyone reading the console.

### Blue/Green Cutover With A Gate

During a release, the agent describes the current target group, confirms the new targets are healthy after they register, and prepares to drain the old ones with Deregister Targets. Reading health and staging the plan happens automatically. The deregistration that shifts live traffic does not run on its own. The agent holds it for a person to confirm the cutover, then runs it once the confirmation comes back.

### Inventory And Compliance Snapshot

On a schedule, the agent runs Describe Load Balancers, Describe Listeners, Describe Rules, and Describe Tags across a region, assembles the inventory, and archives it as a compliance record. It reads everything and changes nothing. The audit snapshot stays current without a manual pull.

## Human-in-Loop Highlight

When a workflow reaches an operation that changes how live traffic is routed, such as deregistering a target during a cutover, modifying a listener, or deleting a load balancer, the agent does not run it on its own. It pauses and routes to the responsible person through their preferred channel: "The workflow wants to run \[action\] on \[resource\] in \[region\], which will change live routing by \[effect\]. Current health: \[target states\]. Confirm the change, or hold?" The person confirms, and only then does the agent call the action. The reads and the health polling keep running automatically; the operations that move live traffic get a human first.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

## Agent Capabilities

18 actions

### Load Balancers

3

-   **Describe Load Balancers** Lists Application, Network, and Gateway Load Balancers in the region, optionally filtered by ARN or name. Used to read the load-balancer inventory into a flow.
-   **Create Load Balancer** Creates an Application, Network, or Gateway Load Balancer with the appropriate subnets and, where applicable, security groups. Used to provision a load balancer in an infrastructure flow.
-   **Delete Load Balancer** Deletes a load balancer and its listeners; associated target groups are not removed, and deletion may be blocked by deletion protection. Used to tear down a load balancer, and a change worth a human confirmation.

### Target Groups

4

-   **Describe Target Groups** Lists target groups in the region, filtered by ARN, name, or attached load balancer. Used to read target-group inventory.
-   **Create Target Group** Creates a target group for routing requests to registered targets, with protocol, port, VPC, target type, and optional health-check settings. Used to provision routing in a flow.
-   **Modify Target Group** Updates the health-check configuration of a target group, changing only the supplied settings. Used to tune how target health is evaluated.
-   **Delete Target Group** Deletes a target group; it cannot be deleted while referenced by a listener or rule action. Used to remove routing, and a change worth a human confirmation.

### Target Health

3

-   **Describe Target Health** Reports each target's state (healthy, unhealthy, initial, draining, unused, unavailable) with a reason when unhealthy. The most common operational read; used to branch a flow on health.
-   **Register Targets** Registers targets (instance ID, IP, Lambda ARN, or ALB ARN) with a target group so the load balancer routes traffic to them. Used in scaling and blue/green flows, and a change to live routing worth a human confirmation.
-   **Deregister Targets** Deregisters targets from a target group; new requests stop and in-flight requests drain over the configured delay. Used to drain old targets during a cutover, and a change to live routing worth a human confirmation.

### Listeners

4

-   **Describe Listeners** Lists a load balancer's listeners, or describes specific listeners by ARN, including protocol, port, SSL policy, certificates, and default actions. Used to read listener configuration.
-   **Create Listener** Creates a listener that checks a protocol and port and forwards matching requests using the supplied default actions. Used to expose a load balancer, and a change worth a human confirmation.
-   **Modify Listener** Replaces supplied properties of an existing listener (protocol, port, and/or default actions), leaving the rest unchanged. Used to reroute traffic, and a change to live routing worth a human confirmation.
-   **Delete Listener** Deletes a listener and its rules; the load balancer and target groups are unaffected. Used to remove an entry point, and a change worth a human confirmation.

### Rules

1

-   **Describe Rules** Lists the rules for a listener, or describes specific rules by ARN, including priority, conditions, actions, and whether each is the default rule. Used to read routing rules.

### Tags

3

-   **Describe Tags** Returns the tags on the specified ELB resources by ARN. Used to read metadata for inventory and compliance.
-   **Add Tags** Adds or updates tags on ELB resources, overwriting existing tags with the same key. Used to label resources in a provisioning flow.
-   **Remove Tags** Removes the specified tag keys from ELB resources, ignoring keys that are not present. Used to clean up metadata.

## Frequently Asked Questions

### What can FlowRunner do with AWS Elastic Load Balancing?

FlowRunner agents can run Describe Load Balancers, Create Load Balancer, and Delete Load Balancer in AWS Elastic Load Balancing, plus 15 more actions.

### Does connecting AWS Elastic Load Balancing to FlowRunner require OAuth?

AWS Elastic Load Balancing uses a custom authentication method to connect to FlowRunner.

### Can AWS Elastic Load Balancing trigger a FlowRunner workflow automatically?

AWS Elastic Load Balancing doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

**Work at AWS Elastic Load Balancing?** This integration exposes AWS Elastic Load Balancing to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current.

---
Markdown version of https://flowrunner.ai/integrations/aws-elb. Site index: https://flowrunner.ai/llms.txt
