AWS Cloud

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

Cloud accounts are an estate source, like repositories. A workspace takes its estate from one or the other, not both, so connect cloud accounts in a workspace of their own. See One estate source per workspace.

How access works

ArchNGN never holds a key to your account. You create a read-only IAM role that trusts ArchNGN, and each run assumes it with sts:AssumeRole. The credentials that returns expire within the hour and are not stored.

The trust policy pins an external ID that ArchNGN generates for each connector. It never changes, and you cannot choose it. That is what stops another ArchNGN customer’s connector from assuming your role, even if they know its ARN.

AWS Cloud connectors do not accept access keys.

Set up the connector

Create the connector first. In Integrations → Connectors, click Add New Connector, choose AWS Cloud, and enter the ARN the role will have, e.g. arn:aws:iam::123456789012:role/ArchNGNReadOnly. Save.

Copy the trust policy. Re-open the connector. It shows the trust policy with ArchNGN’s principal and this connector’s external ID:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "<ArchNGN principal, shown in the connector>" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "<external ID, shown in the connector>" } }
  }]
}

Create the role in AWS. Go to IAM → Roles → Create role → Custom trust policy, paste the policy, and give the role the name in your ARN.

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).

Run the connector. If the role cannot be assumed, the run fails with a message naming the role and the external ID to check in its trust policy.

Configuration

Field	Value
Role ARN	The ARN of the read-only role, `arn:aws:iam::<account id>:role/<name>`
External ID	Generated by ArchNGN when you save; shown in the trust policy. Fixed for the life of the connector

To revoke access, delete the role or remove ArchNGN’s principal from its trust policy. Nothing needs rotating.

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: request routing (Routes To), messaging (Publishes To / Consumes From), data access (Uses), configuration bindings (Configures), and network membership (Resides In). Edges the inventory proves are labelled Observed; edges inferred from co-location (a shared VPC, tag or resource group) are labelled Inferred so you can confirm or reject them. See Link evidence.
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.