NexOps: Build CloudOps Agent Using Strands+Bedrock+Terraform

DevArt keeps this article discoverable at a fast, self-canonical URL and links clearly to the original DEV publication.

Overview of NexOps

NexOps is a cloud operations assistant that lets users ask questions about AWS infrastructure in plain language. It combines a lightweight web interface with an AI agent that can inspect selected AWS services, gather operational evidence, and explain findings in a clear and practical way.

The backend uses the Strands Agents framework and Amazon Bedrock. For each chat request, it creates a fresh agent instance and gives it a set of service-specific tools implemented with Boto3. The application is designed to support operations teams with investigation and routine administration while keeping the scope of available actions explicit.

Ask questions about infrastructure, health, security posture, and costs.
Gather details from supported AWS services through dedicated tools.
Receive summaries that distinguish observed facts from possible causes.
Use gated EC2 lifecycle and Systems Manager operations when the deployment is configured to allow them.

NexOps is not an unrestricted AWS command runner. Tool coverage depends on the AWS account, region, IAM permissions, and service prerequisites available to the running application.

Business Problems

Cloud teams often need to inspect several consoles and services to answer a basic operational question. During an incident, switching between instance state, monitoring data, logs, alarms, and recent changes can slow down diagnosis and make it harder to share a concise summary with the rest of the team.

NexOps brings selected checks together behind a conversational interface. It can help reduce repetitive lookup work and make operational information more accessible, while leaving decisions and approvals with the people responsible for the environment.

Scattered operational data: Relevant details may live in EC2, CloudWatch, CloudTrail, AWS Config, IAM, and other service views.
Slow first-pass investigation: Engineers may repeat the same inventory and health checks before they can focus on likely causes.
Hard-to-summarize findings: Raw service responses can be lengthy and difficult to turn into a useful incident update.
Security review overhead: Teams need a convenient way to inspect selected IAM, encryption, access, and network controls.
Cost visibility: Service costs and low-utilization candidates can be difficult to spot during routine operations.

The application supports these workflows by collecting targeted evidence and presenting it in natural language. Findings such as low CPU, aged access keys, or broad policy statements are review signals; they are not automatic judgments or remediation decisions.

Architecture

NexOps separates the user interface, request routing, and AWS operations into deployable components. The browser loads a static frontend served by NGINX on ECS Fargate. Chat requests pass through Amazon API Gateway and a private integration to the backend Application Load Balancer, which forwards them to the FastAPI service running in ECS Fargate.

For each chat request, FastAPI validates the input and optional region, constructs a Strands agent backed by Amazon Bedrock, and returns the agent's response. The agent selects from registered Python tools; those tools use Boto3 to call supported AWS APIs. The AWS identity available to the task, typically through its ECS task role, determines which calls succeed.

Frontend: Static HTML, CSS, and JavaScript served by NGINX in a Fargate task.
Request entry: Public frontend Application Load Balancer; API Gateway HTTP API for chat traffic.
Private backend path: API Gateway VPC Link to an internal Application Load Balancer and backend ECS service.
Agent service: FastAPI endpoints, Strands orchestration, and service-specific Boto3 tools.
Model: Amazon Bedrock, using the configured model ID (Nova Micro by default in the application).
Infrastructure: Terraform definitions for ECR, ECS, load balancers, API Gateway, logging, and supporting resources.

The backend creates a new agent for every request, so chat history is not persisted across requests. The frontend and API deployment settings, including API URL, CORS origins, authentication, and network access, must be aligned for a production deployment.

What This Application Does

NexOps translates an operator's question into one or more targeted tool calls and then summarizes the returned evidence. The registered tools cover selected parts of AWS rather than every service or every resource in an account.

Inventory: Inspect supported EC2, EBS, VPC, security group, S3, Lambda, RDS, and ECS resources.
Monitoring and troubleshooting: Query CloudWatch metrics, alarms, log groups, and logs; inspect EC2 status and console output; and gather recent CloudTrail changes.
Security and compliance review: Inspect selected IAM users, groups, roles, policies, MFA and access-key metadata, security group rules, encryption settings, and AWS Config results.
Cost analysis: Review Cost Explorer service costs, supported resource-level EC2 costs, and low-CPU candidates.
Approved operations: Start, stop, or reboot EC2 instances and invoke restricted Systems Manager actions when the relevant application gates, allowlists, IAM permissions, and AWS prerequisites are satisfied.
Result verification: Where supported, inspect the resulting state after an operation and report whether it completed, failed, or remains in progress.

The agent is instructed to use evidence for live AWS claims, report the region and scope it checked, and identify uncertainty. It does not provide a generic AWS API executor, IAM write tools, resource deletion, or arbitrary shell access. A tool being available also does not mean that the task role has permission to use it.

Functional Workflow

The workflow begins when a user enters a question in the web application. The frontend sends the message and, optionally, a region to the API Gateway endpoint. API Gateway routes the request over its VPC Link to the backend service.

FastAPI validates the request and applies the configured API-token behavior. It then creates a Strands agent using the configured Bedrock model and gives the agent the supported tool set and operational system prompt. The agent chooses relevant read-only checks first for investigative requests, calls AWS through Boto3, and uses the returned results to produce a concise response.

The user submits a natural-language question and optional AWS region.
The frontend posts the request to the API Gateway chat route.
API Gateway forwards it through the VPC Link and internal load balancer to FastAPI.
The backend validates the input and creates a request-scoped agent.
The agent selects the narrowest relevant AWS tools and gathers results.
For a clearly authorized state change, the agent may call a gated operation if deployment policy permits it.
The agent summarizes evidence, limitations, errors, and action status for the frontend.

The health endpoint provides a liveness response and does not contact AWS or Bedrock. Chat calls do not share persisted conversation history. An accepted AWS operation is reported as submitted until a verification check confirms its resulting state.

AWS Components

The infrastructure uses managed AWS services to host the frontend and backend, expose their HTTP entry points, and connect the agent to AWS operations and model inference.

Amazon ECS on AWS Fargate: Runs the NGINX frontend container and FastAPI backend container without managing EC2 hosts.
Amazon ECR: Stores the frontend and backend container images; the Terraform configuration enables image scanning on push.
Elastic Load Balancing (Application Load Balancer): A public-facing frontend ALB serves the web tier, while an internal ALB receives backend traffic from API Gateway.
Amazon API Gateway HTTP API: Exposes the chat route and connects privately to the backend through a VPC Link.
Amazon Bedrock: Provides model inference for the Strands agent. The model ID and Bedrock region are runtime configuration.
AWS IAM: The ECS task role supplies the application's AWS permissions; the execution role supports ECS task startup integrations such as image pulls and log delivery.
Amazon CloudWatch Logs: Receives container logs and supports the application's monitoring and log-search tools.
AWS KMS: Supplies keys referenced by ECS execute-command logging configuration.
Amazon VPC: Places ECS tasks and the internal backend path in private subnets, with security groups controlling connectivity.
Amazon S3: Stores Terraform state through the configured remote backend; the state bucket must already exist and be accessible.
AWS Systems Manager, AWS Config, AWS CloudTrail, and Cost Explorer: Supply operational, compliance, change-history, and cost data when enabled and permitted.

Security Groups

Public Frontend ALB Security Group:

Name: Public-CloudOps-Webapp-LB
Inbound: HTTPS from Anywhere
Outbound: Default

Frontend ECS Security Group:

Name: CloudOps-Web-App
Inbound: TCP at 8080 port from Public-CloudOps-Webapp-LB
Outbound: Default

VPC Link Security Group:

Name: cloudops-vpc-link-sg
Inbound: HTTPS from CloudOps-Web-App
Outbound: HTTPS to ALBSG (Internal ALB)

Internal ALB Security Group:

Name: InternalALBSG
Inbound: HTTPS from cloudops-vpc-link-sg
Outbound: Default

Backend ECS Security Group:

Name: StrandsAgentSG
Inbound: TCP at 8000 port from InternalALBSG
Outbound: Default

Some resources and IAM roles are looked up by Terraform rather than created by these modules. Operators must review the configured role policies, network rules, model access, and service prerequisites for their own AWS environment.

Implementation Steps

NexOps is implemented as two application components: a Python backend and a static web frontend. The backend builds a request-scoped Strands agent and registers the AWS tools it can use. The frontend is served by NGINX and proxies chat requests to the API Gateway endpoint configured for its container.

Complete Repository Folder Structure

The tree below shows the files tracked in the repository and how the frontend, backend, AWS tools, Terraform infrastructure, and CI pipelines are organized.

strands-cloudops-agent/
├── .gitlab-ci.yml
├── .gitlab-ci-backend.yml
├── .gitlab-ci-frontend.yml
├── Backend/
│   ├── .dockerignore
│   ├── .env.example
│   ├── .gitignore
│   ├── Dockerfile.backend
│   ├── README.md
│   ├── app.py
│   ├── agent/
│   │   ├── orchestrator.py
│   │   └── system_prompt.py
│   ├── services/
│   │   ├── __init__.py
│   │   ├── aws_clients.py
│   │   ├── policy.py
│   │   └── result_formatter.py
│   ├── tools/
│   │   ├── __init__.py
│   │   ├── cloudtrail_tools.py
│   │   ├── cloudwatch_alarms.py
│   │   ├── cloudwatch_logs.py
│   │   ├── cloudwatch_metrics.py
│   │   ├── cloudwatch_tools.py
│   │   ├── config_tools.py
│   │   ├── cost_optimization.py
│   │   ├── ebs_tools.py
│   │   ├── ec2_inventory.py
│   │   ├── ec2_lifecycle.py
│   │   ├── ec2_tools.py
│   │   ├── ecs_tools.py
│   │   ├── iam_tools.py
│   │   ├── lambda_tools.py
│   │   ├── network_tools.py
│   │   ├── policy_checks.py
│   │   ├── rds_tools.py
│   │   ├── remediation.py
│   │   ├── s3_tools.py
│   │   └── ssm_operations.py
│   ├── Backend_Infra/
│   │   ├── alb.tf
│   │   ├── apigateway.tf
│   │   ├── data.tf
│   │   ├── ecr.tf
│   │   ├── ecs.tf
│   │   ├── output.tf
│   │   ├── provider.tf
│   │   ├── terraform.tfvars
│   │   └── variable.tf
│   └── requirements.txt
├── Frontend/
│   ├── .dockerignore
│   ├── .gitignore
│   ├── Dockerfile.frontend
│   ├── README.md
│   ├── cloudopsweb/
│   │   ├── README.md
│   │   ├── app.js
│   │   ├── index.html
│   │   ├── nginx.conf
│   │   └── styles.css
│   └── Frontend_Infra/
│       ├── alb.tf
│       ├── data.tf
│       ├── ecr.tf
│       ├── ecs.tf
│       ├── output.tf
│       ├── provider.tf
│       ├── terraform.tfvars
│       └── variable.tf
├── PROJECT_BLOG.md
└── __pycache__/
    └── app.cpython-313.pyc

1. Configure the AWS environment: Choose the target account and region, confirm Bedrock model access, and prepare the VPC, subnets, security groups, Terraform state bucket, and required IAM roles.
2. Configure the backend: Set the Bedrock model and region, default AWS region, and any account or region restrictions. Grant the ECS task role only the AWS API permissions required by the tools to be enabled. Backend/agent/orchestrator.py constructs the Bedrock model and passes it, the registered tools, and system prompt to Strands:

model_id = os.getenv("BEDROCK_MODEL_ID", "us.amazon.nova-micro-v1:0").strip()
bedrock_region = os.getenv(
    "BEDROCK_REGION", os.getenv("AWS_REGION", "us-east-1")
).strip()
model = BedrockModel(
    model_id=model_id,
    region_name=bedrock_region,
    max_tokens=int(os.getenv("BEDROCK_MAX_TOKENS", "2048")),
)
return Agent(
    model=model,
    tools=TOOLS,
    system_prompt=SYSTEM_PROMPT,
    name="cloudops-agent",
)

3. Package the backend: Backend/Dockerfile.backend installs Python dependencies and runs the FastAPI service with Uvicorn on port 8000:

FROM python:3.12-slim

WORKDIR /app
COPY requirements.txt ./requirements.txt
RUN python -m pip install --no-cache-dir -r requirements.txt

COPY . .
EXPOSE 8000
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "1"]

4. Package the frontend: Frontend/Dockerfile.frontend uses NGINX to serve the browser UI. NGINX proxies /api/chat to the API Gateway endpoint provided to the frontend task as API_GATEWAY_URL:

FROM nginx:alpine

COPY cloudopsweb/nginx.conf /etc/nginx/templates/default.conf.template
COPY cloudopsweb/index.html /usr/share/nginx/html/
COPY cloudopsweb/styles.css /usr/share/nginx/html/
COPY cloudopsweb/app.js /usr/share/nginx/html/

EXPOSE 8080
CMD ["nginx", "-g", "daemon off;"]

5. Configure operational safeguards: Keep mutations disabled unless they are deliberately required. When enabled, restrict them to approved account IDs and regions; separately allowlist reviewed SSM documents. Configure API authentication and production mode before exposing chat to untrusted clients.
6. Build and publish images: Build the backend and frontend containers from their respective Dockerfiles, then push both images to their ECR repositories.
7. Deploy infrastructure: Review and apply Terraform in Backend/Backend_Infra and Frontend/Frontend_Infra. Confirm the looked-up roles, network resources, image names, frontend API endpoint, CORS origins, and load balancer health checks.
8. Verify the application path: Check backend /health, confirm ECS tasks become healthy, load the frontend through its ALB, and submit a chat request through API Gateway in a non-production environment.
9. Validate tool access and operations: Test read-only inventory and monitoring calls first. If lifecycle or SSM actions are needed, validate the gates, exact allowlists, IAM permissions, target state, and post-action verification behavior.
10. Operate and improve: Monitor container logs and service health, review IAM access periodically, and update model, infrastructure, and tool configuration as requirements change.

Registered Agent Tools

These are the functions registered in Backend/agent/orchestrator.py. The agent selects tools based on each request; it does not call every tool for every chat. Access also depends on IAM permissions and AWS service configuration.

EC2 and resource inventory: list_ec2_instances, get_ec2_instance_details, get_ec2_instance_state, get_ec2_instance_status, get_ec2_console_output, list_aws_resources, get_resource_tags.
CloudWatch: get_cloudwatch_metrics, list_cloudwatch_alarms, get_cloudwatch_alarm_history, search_cloudwatch_logs, list_cloudwatch_log_groups, get_cloudwatch_dashboard.
CloudTrail and AWS Config: get_recent_account_events, get_resource_event_history, list_config_rules, get_config_resource_history, get_config_compliance.
IAM inspection: get_iam_role_details, list_iam_role_policies, simulate_iam_policy, list_iam_users, list_iam_groups, get_iam_user_details, get_iam_group_details, get_group_members, list_user_groups, get_user_attached_policies, get_group_attached_policies, get_user_inline_policies, get_group_inline_policies, list_user_access_keys, list_user_mfa_devices, analyze_group_permissions, identify_empty_iam_groups, check_users_without_mfa, identify_groups_with_admin_access, check_user_access_key_age.
VPC and networking: list_vpcs, list_subnets, list_security_groups, list_route_tables, list_network_acls, check_security_group_rules.
EBS: list_ebs_volumes, get_ebs_volume_details, check_ebs_encryption, list_ebs_snapshots.
RDS: list_rds_instances, get_rds_instance_details, check_rds_encryption, get_rds_events.
S3: list_s3_buckets, get_s3_bucket_details, check_s3_encryption, check_s3_public_access, list_s3_lifecycle_rules.
Lambda: list_lambda_functions, get_lambda_function_details, get_lambda_function_errors, list_lambda_event_sources.
ECS: list_ecs_clusters, list_ecs_services, list_ecs_tasks, get_ecs_service_events.
Diagnosis and change verification: diagnose_ec2_health, analyze_cloudwatch_metrics, analyze_instance_logs, get_recent_resource_changes, verify_remediation_result.
Systems Manager: check_ssm_managed_status, check_patch_compliance, get_ssm_command_invocation, get_ssm_automation_execution, run_ssm_command, run_ssm_automation, restart_application_service.
EC2 lifecycle: start_ec2_instance, stop_ec2_instance, reboot_ec2_instance.
Security policy checks: check_iam_resource_policy, check_resource_encryption.
Cost analysis: get_service_costs, get_resource_costs, find_idle_resources, estimate_ec2_cost_impact.

The repository documents several deployment settings that need attention before production exposure. In particular, the backend Terraform task definition currently enables the mutation gate for a specific account and region, while it does not configure production authentication; the API Gateway CORS origin is set to http://localhost. Review and replace these values with environment-appropriate settings before deployment to a shared or public environment.

This is what frontend UI should look where users need to provide prompts -

Example: If we want to get list of running of instances name and instance types

Repository Link: https://github.com/dasanirban834/strands-cloudops-agent

Benefits

NexOps brings selected AWS operational checks into one conversational workflow. This can help engineers get to relevant evidence faster, especially when a question spans multiple services or requires a concise update for teammates.

Faster first-pass investigations: Operators can ask a question in plain language and have the agent gather relevant inventory, monitoring, log, and change-history details from supported tools.
Clearer operational summaries: Responses can turn service output into readable findings while calling out the region, scope, errors, and uncertainty involved.
Broader access to operational information: A conversational interface can make routine checks easier for team members who do not work in every AWS console each day.
Consistent review signals: Teams can use the same supported checks to spot items such as missing encryption, broad network rules, aged access keys, or low utilization for follow-up.
Controlled operational actions: Where enabled, lifecycle and Systems Manager actions are bounded by application gates, allowlists, IAM permissions, and AWS prerequisites, with verification available for supported operations.
Deployable, modular foundation: The separate frontend, backend, tools, and Terraform components provide a basis for adapting the application to an organization's account boundaries and operational practices.

These benefits depend on accurate IAM scoping, suitable AWS configuration, and human review. NexOps helps collect and explain evidence; it does not replace incident judgment, security approval, or environment-specific production controls.

Conclusion

NexOps demonstrates how a Strands-based agent can connect a natural-language interface to a focused set of AWS operations. It combines evidence gathering across supported services with readable summaries, while keeping state-changing capabilities explicitly gated.

The repository provides the core application and infrastructure needed to deploy and extend this approach. Before using it in a shared or production environment, teams should review authentication, CORS, IAM permissions, network access, Bedrock model availability, and mutation settings. With those controls configured for the target environment, NexOps can serve as a practical assistant for routine cloud operations and initial investigation.