AWS Cloud

The AWS Cloud connector reads the resource inventory of an AWS account (read-only, via an IAM user you create) and maps it to your architecture model: the as-built view of what is actually running. See Connectors for the general workflow.

Prerequisites

You need an IAM user with programmatic access and read-only permissions.

1. In the AWS console, go to IAM → Users → Create user. Name it (e.g. archngn-discovery) and do not give it console access.

2. Attach permissions: the simplest option is the AWS-managed ReadOnlyAccess policy. For least privilege, attach a custom policy with only the actions the connector uses:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "tag:GetResources",
           "ec2:DescribeRegions",
           "ec2:DescribeInstances",
           "ec2:DescribeSubnets",
           "rds:DescribeDBInstances",
           "ecs:ListClusters",
           "ecs:ListServices",
           "ecs:DescribeServices",
           "ecs:DescribeTaskDefinition",
           "eks:ListClusters",
           "lambda:ListFunctions",
           "lambda:ListEventSourceMappings",
           "sns:ListTopics",
           "sqs:ListQueues",
           "dynamodb:ListTables",
           "elasticloadbalancing:DescribeLoadBalancers",
           "elasticloadbalancing:DescribeTargetGroups",
           "elasticloadbalancing:DescribeTargetHealth"
         ],
         "Resource": "*"
       }
     ]
   }

   A missing permission never fails the run; it only reduces the detail discovered (e.g. no load-balancer routing without the elasticloadbalancing:* reads).

3. Open the user → Security credentials → Create access key (use case: third-party service). Copy the Access key and Secret access key. AWS shows the secret only once.

Configuration

Field	Value
Access Key	The IAM user’s access key (AKIA…)
Secret Key	The IAM user’s secret access key

Both keys are stored together in an encrypted secrets store and never shown again. To rotate, create a new access key in IAM, enter it over the placeholder, and delete the old key in AWS.

What a Run Produces

The connector sweeps every enabled region via the Resource Groups Tagging API, enriched with network topology (VPCs and subnets), load-balancer routing, ECS container images, and Lambda event-source mappings. The AI then maps the inventory to your metamodel:

• Objects on the Technology and Data layers only: managed services become Technology Service, VMs/containers/serverless become Compute, VPCs and load balancers become Network, databases and storage become Data Store. Well-known resource types are classified deterministically from the resource ARN.
• Associations backed by concrete evidence: request routing (Routes To), messaging (Publishes To / Consumes From), data access (Uses), configuration bindings (Configures), and network membership (Resides In). No evidence, no edge.
• Cross-layer links: container images and resource tags are captured so as-built Compute/Technology objects can be linked (Deployed To) to the Application objects discovered by the GitHub connector.

Your Application and Business layers are never invented from infrastructure. The logical view comes from code and document sources and is linked to the as-built objects instead.

Tips for Better Results

• Tag your resources. Resources are grouped by VPC, then by deployment tags (CloudFormation stack, app, project). Consistent tags give the mapper stronger grouping and linking signals, especially for serverless estates with no VPC.
• Re-runs are stable: resources are matched by ARN, so renames update objects in place.
• Each cloud account is its own estate. Same-named workloads in different clouds or accounts are kept as separate objects, never merged.