AWS

The AWS integration allows agents to interact with your Amazon Web Services infrastructure. Its single aws tool spans EC2 compute, Lambda, S3 storage, CloudWatch monitoring, billing and cost reporting, SSM server access, and IAM — so your agents can answer questions about your infrastructure, check resource status, and perform routine management tasks.

Permission tiers

When you connect AWS, you choose a permission tier:

• Read-Only Monitoring — Agents can list and describe resources, read metrics and logs, and query billing, but cannot change anything.
• Full Management — Adds write actions such as starting and stopping instances, invoking Lambda functions, uploading to S3, running SSM commands, and updating alarms.

The tier you select in Sprigr Teams should match the permissions granted to the IAM role or user in AWS. You can also restrict the integration to specific regions and services.

Prerequisites

• An active AWS account with the resources you want agents to access.
• Permission to create IAM roles and run a setup stack in your AWS account (typically requires admin access).
• Admin or Owner role in your Sprigr Teams organisation.

How the setup works

The recommended setup uses a cross-account IAM role for secure, credential-free access. Instead of sharing API keys, you create a role in your AWS account that Sprigr Teams can assume via STS. This approach follows AWS security best practices:

• No long-lived credentials are stored or shared
• You control exactly what permissions the role has
• You can revoke access at any time by deleting the role
• All actions are logged in your AWS account’s audit trail

The setup process uses a guided wizard with an automated setup template that creates the IAM role with the correct permissions and trust policy.

Note

As an alternative to the assumed-role flow, you can supply a static IAM Access Key ID and Secret Access Key directly. The role-based flow is preferred because it avoids storing long-lived credentials.

Connecting AWS

1. Open the Integration Hub

   Sign in to team.sprigr.com and click Integrations in the sidebar.

2. Find AWS

   Locate the AWS card and click Connect. This opens the AWS setup wizard.

3. Generate an External ID

   The wizard generates a unique External ID for your organisation. This ID is used as an additional security measure to prevent confused deputy attacks. Copy this ID — you will need it in the next step.

4. Launch the setup template

   Click the Launch Stack button. This opens the AWS Console in a new tab with a pre-configured setup template. The template creates:

   • An IAM role with a trust policy that allows Sprigr Teams to assume it
   • A managed policy with read-only permissions for the services your agents will access

   Note

   Review the permissions in the template before creating the stack. By default, the template grants read-only access to EC2, Lambda, S3, CloudWatch, and other common services. You can customise the permissions by editing the template if needed.

   Acknowledge that the template will create IAM resources and click Create Stack. Wait for the stack creation to complete (usually under 2 minutes).

5. Enter the Role ARN

   Once the stack finishes creating, go to the Outputs tab and copy the Role ARN value. Return to the Sprigr Teams setup wizard and paste the Role ARN.

6. Test the connection

   Click Test Connection. Sprigr Teams will attempt to assume the role and make a basic API call. If the test succeeds, you will see a green success message. Click Save to finish the setup.

Caution

If the connection test fails, check that:

• The stack creation completed successfully in AWS
• The External ID matches what was generated in the wizard
• The role’s trust policy allows the correct principal to assume it

Available actions

The AWS integration is a single aws tool that takes an action parameter. Write actions (marked below) require the Full Management permission tier.

EC2 (Compute)

Action	Description
ec2_list_instances	List EC2 instances with optional filters
ec2_describe_instance	Get detailed information about a specific instance
ec2_start_instance	Start a stopped instance (write)
ec2_stop_instance	Stop a running instance (write)
ec2_reboot_instance	Reboot an instance (write)
ec2_get_console_output	Read an instance’s console output

Lambda (Serverless)

Action	Description
lambda_list_functions	List Lambda functions
lambda_get_function	Get details about a specific function
lambda_get_metrics	Get invocation metrics for a function
lambda_get_logs	View recent invocation logs
lambda_invoke	Invoke a Lambda function with a payload (write)
lambda_update_config	Update a function’s configuration (write)

CloudWatch (Monitoring)

Action	Description
cloudwatch_list_alarms	List CloudWatch alarms and their states
cloudwatch_get_metrics	Query CloudWatch metrics for any service
cloudwatch_query_logs	Query CloudWatch Logs
cloudwatch_put_alarm	Create or update a CloudWatch alarm (write)

Billing and cost

Action	Description
billing_get_costs	Get current-period cost data, broken down by service
billing_get_forecast	Get a cost forecast
billing_get_recommendations	Get cost-optimisation recommendations

S3 (Storage)

Action	Description
s3_list_buckets	List S3 buckets
s3_list_objects	List objects in a bucket with prefix filtering
s3_get_object	Read an object from S3
s3_put_object	Upload an object to S3 (write)

SSM (Systems Manager)

Action	Description
ssm_list_managed_instances	List instances managed by SSM
ssm_run_command	Run a command on a managed instance (write)
ssm_get_command_output	Retrieve the output of a previously run command

IAM and identity

Action	Description
iam_list_roles	List IAM roles
iam_list_users	List IAM users
iam_get_account_summary	Get an account-level IAM summary
sts_get_caller_identity	Verify which AWS account and role is being used

Try asking your agent

“Check the status of our EC2 instances and let me know if any are running above 80% CPU.”

Common use cases

• Infrastructure status checks — “Are all our production instances running?” — An agent queries EC2 and returns a quick summary of instance states.
• Billing monitoring — “How much have we spent on AWS this month?” — The agent pulls the current billing data and breaks it down by service.
• Alarm triage — “What CloudWatch alarms are firing right now?” — The agent lists all alarms in ALARM state and provides details about what triggered them.
• Log investigation — “Show me the recent errors for our payment-processor Lambda function” — The agent retrieves recent invocation logs and highlights errors.
• Daily infrastructure reports — A scheduled workflow queries key metrics, alarm states, and billing data, then sends a morning summary to the team.

Troubleshooting

“Access denied” or “AssumeRole failed” Verify that the Role ARN is correct and the trust policy includes the right External ID. Check the stack outputs in your AWS Console.

Missing resources in results The IAM role may not have permissions for the service or region you are querying. Check the policy attached to the role and ensure it covers the needed services.

Slow responses Queries across all regions can take longer. If possible, have the agent specify a region in the query to speed up results.

Stack creation failed Check the Events tab in the AWS Console for the specific error. Common issues include insufficient IAM permissions for the user creating the stack or a naming conflict with existing resources.

Next steps

• GCP — Connect Google Cloud Platform alongside or instead of AWS.
• Integrations Overview — See all available integrations.
• Workflows — Automate infrastructure checks and reporting with workflows.