Understanding your Infrastructure

One of the best uses of System Initiative is to help you understand the infrastructure you already have. You can connect your AWS account, discover your existing resources, map them, and get AI assisted analysis and troubleshooting. You can do this regardless of how your infrastructure was created, and without disrupting your existing automation.

Go sign up for System Initiative, then let’s dive in!

Discovering what you already have

Open up the AI Agent, and feed it this prompt:

Discover the resources in my AWS account in a change set named 'Understand my Infrastructure'. Make a plan that starts with the network resources and security configuration, then the most common services used to deliver applications (EC2, ECS, EKS, etc) and for data storage (databases, s3, etc). 

The Agent will then make a plan that looks something like this:

⏺ Update Todos
  ⎿  ☐ Validate System Initiative credentials and workspace access
     ☐ Create a new change set for resource discovery
     ☐ Set up AWS credentials and region components
     ☐ Discover network resources (VPCs, subnets, security groups, route tables)
     ☐ Discover security configuration (IAM roles, policies, KMS keys)
     ☐ Discover compute services (EC2 instances, Auto Scaling groups)
     ☐ Discover container services (ECS clusters, EKS clusters)
     ☐ Discover data storage services (RDS databases, DynamoDB tables)
     ☐ Discover S3 buckets and storage services
     ☐ Discover load balancers and application delivery services

It will prompt you to create a ‘Change Set’ - this is a safe, simulated ‘branch’ of your workspace, that can read data from your AWS account, but not make any changes to it. Say yes, and the Agent will start discovering common components!

While the discovery process is happening, you can watch the Agent’s progress with the map view in the change set. Select the ‘Understand my Infrastructure’ change set, then click the ‘Map’ button. You’ll see it update as your configuration is discovered:

Basic Analysis

My favorite thing to do at this stage is to ask the Agent to explain to me what we just discovered:

Analyze the resources in the 'Understand my Infrastructure' change set, and explain what you find there. Pay special attention to what applications are running and how they are situated on the network.

When I ran this in our account that we use to demo System Initiative, here was its response:

⏺ Discovered Infrastructure Analysis

  Your AWS account contains two distinct application deployments across multiple VPCs:

  Network Infrastructure Overview

  5 VPCs discovered:
  - 3x Demo VPCs (10.0.0.0/16 each) - vpc-0ee634f5ad17b5413, vpc-0f3b44a422ed81981,
  vpc-01ea49d66f883b310
  - 1x Default VPC (172.31.0.0/16) - vpc-0025265f7d7b4de3c

  Running Applications

  Application 1: "Keeby-Keeb Demo"
  - Load Balancer: keeby-keeb-demo-load-balancer
  - Network: VPC vpc-0f3b44a422ed81981 (10.0.0.0/16)
  - Compute: 2x EC2 instances running SI Logo containerized service
    - i-0747ce5b743ef849c (10.0.1.252) in us-east-1a
    - i-01cfc01143861a87d (10.0.2.66) in us-east-1b
  - Container: keeb/si-logo Docker image on port 80
  - High Availability: Multi-AZ deployment across subnets in different AZs

  Application 2: "Monk Demo" (Already in SI workspace)
  - Load Balancer: monk-demo-load-balancer
  - Network: VPC vpc-01ea49d66f883b310 (10.0.0.0/16)
  - Compute: 2x EC2 instances running SI Logo containerized service
    - i-02ce2e222aa86530b (10.0.1.61) in us-east-1a
    - i-01e43eee1b95da83e (10.0.2.122) in us-east-1b

  Network Topology

  Subnet Distribution (14 total):
  - Demo Applications: Each VPC has 2 public subnets (10.0.1.0/24, 10.0.2.0/24) across
  us-east-1a/1b
  - Default VPC: Contains 6 subnets across multiple AZs (172.31.x.0/20 ranges)

  Security Configuration

  7 Security Groups discovered:
  - Default security groups for each VPC (self-referencing access)
  - Custom security group sg-0f4f4bfe94445fe83 allowing HTTP (80) and SSH (22) from anywhere
  - Load balancer security groups for application access

  Infrastructure Pattern

  Both applications follow identical architecture patterns:
  - Internet-facing Application Load Balancers
  - Multi-AZ deployment for high availability
  - Containerized workloads using Docker systemd services
  - Public subnets with internet gateway connectivity
  - Consistent naming convention ("keeby-keeb" vs "monk" prefixes)

⏺ Key Findings:
  - Two parallel demo environments running identical SI Logo applications
  - Well-architected patterns with proper load balancing and multi-AZ deployment
  - Standardized container deployment using Docker and systemd
  - Default VPC exists but appears unused for applications
  - No databases or S3 buckets discovered - applications appear to be stateless web services

  This infrastructure represents a dual-environment setup for demonstrating System Initiative capabilities with production-ready architectural patterns.

Pay particular attention to the fact that it knows what containers are running - in this environment, we use AWS EC2 Instances to run our demo application, configured with cloud-init. To figure this out, you need to base64 decode the UserData field of our EC2 instances - which looks like this:

The AI Agent knew not only to read that field to discover applications that might be running on our EC2 instance, but it did so without a separate base64 decoding step, which blows my mind every time I do it.

If you’re new to an infrastructure, or if you’ve simply lost track of how things are put together, this is a powerful way to start gaining a better understanding.

Ask for recommendations

Another great thing to do is ask the Agent for recommendations about improvements you could make to your security posture or reduce spending:

Analyze the resources in the 'Understand my Infrastructure' change set, and make recommendations on how I can improve my security posture and spend.

In our demo environment, it found a couple quick wins:

• SSH was open to the public, and should be restricted.
• The payload can likely run on a smaller instance size.
• We may have unused VPCs that can be cleaned up.

Searching

Another great way to understand your infrastructure is to use the Web Application to search and visualize. Let's say you want to see the network topology - VPCs, Subnets, and Internet Gateways. Click on the Map button if you aren’t already there, and then put the following in your search bar:

schema:"aws::ec2::vpc" | schema:"aws::ec2::subnet" | schema:"aws::ec2::internetgateway" | schema:"aws::elasticloadbalancingv2::loadbalancer"

That will update your map to show you only the resources that match the schema! This is a great way to visualize your infrastructure quickly. You can then save the results to a custom view, making it easier for your teammates to zero in on the specific infrastructure that might matter to them.

Closing

System Initiative’s unique ability to discover, map, and analyze your existing infrastructure, and then perform summarization and troubleshooting with AI Agents, can significantly boost every team with minimal effort, without altering your existing workflows or automation tools.

In our next blog post, we’ll show you how having that data in System Initiative also opens up the possibilities for automation in new and exciting ways. See you then!