Prepare AWS Infrastructure :: Ataccama ONE Agentic

Prerequisites

An AWS account. We recommend using a dedicated account to isolate edge workloads.
IAM permissions to create VPCs, subnets, gateways, route tables, S3 buckets, and IAM roles.
A chosen AWS Region and three availability zones (AZ) within it. For example, us-east-1 with zones a, b, c.

Configure networking

Set up a virtual private cloud (VPC) with public and private subnets across three availability zones, an internet gateway for ingress/egress, and NAT gateways so private workloads can reach the internet.

Follow the AWS documentation to complete these steps, using the values from [Network configuration values]:

Create a VPC using the CIDR from CIDR allocation.
1. Enable DNS hostnames and DNS resolution.
Create three public and three private subnets, one pair per availability zone. See Subnet layout.
Create and attach an internet gateway to the VPC.
Allocate Elastic IPs, one per NAT gateway you plan to deploy.
Create NAT Gateways in the public subnets, attaching one Elastic IP each. See NAT gateway strategy.
Configure route tables:
1. The public route table sends 0.0.0.0/0 to the internet gateway; associate it with all public subnets.
2. Each private route table sends 0.0.0.0/0 to a NAT gateway; associate one with each private subnet.
Tag all resources according to Tagging.

The VPC provided must not contain VPC endpoints for the following AWS services, as these are created and managed by Ataccama:

S3
KMS
SecretsManager
SQS.

Networking configuration values

The following values apply to the edge networking layout.

CIDR allocation

A /16 VPC with /24 subnets provides ample headroom and avoids overlap with most corporate networks:

VPC: 10.0.0.0/16 (65,536 IPs)
Public subnets: 10.0.101.0/24, 10.0.102.0/24, 10.0.103.0/24
Private subnets: 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24

Ensure CIDR blocks don’t overlap with existing corporate networks or peered VPCs.

Subnet layout

Three public and three private subnets, one pair per availability zone.
Disable auto-assign public IPs on private subnets.
Enable auto-assign public IPs on public subnets only if needed for load balancers or bastion hosts.

NAT gateway strategy

Production: One NAT gateway per availability zone. Each private route table sends traffic to the NAT gateway in the same AZ to avoid cross-AZ data charges and dependencies.
Non-production: A single shared NAT gateway in one public subnet, used by all private subnets. Cheaper, but introduces a single point of failure.

Tagging

Apply consistent tags to all resources for cost tracking and automation:

Name
Environment (prod or nonprod)
Application=edge
Owner
CostCenter

Create the EFS service-linked role

The AWS account where the edge is deployed needs a service-linked role for Amazon Elastic File System (EFS):

aws iam create-service-linked-role --aws-service-name elasticfilesystem.amazonaws.com

For background, see Using service-linked roles for Amazon EFS.

Create the S3 bucket

The edge uses a customer-owned S3 bucket to store processing results and temporary data.

Follow the AWS documentation to create a bucket, using the values from S3 configuration values.

S3 configuration values

Bucket name

Use a name of the form <edge-instance-name>-s3-<random-suffix>. The random suffix ensures the required global uniqueness.

Bucket settings

Region: Match the AWS Region where you created the VPC.
Block Public Access: Keep all blocks enabled.
Versioning: Enable for audit trail and recovery.

Create the IAM role

Follow the AWS documentation to create a custom IAM role for the edge to use when reading from and writing to the S3 bucket.

When configuring the role:

Skip permissions selection.
Use the trust policy from Trust policy.
Name the role <edge-instance-name>-s3-role.
Attach the policy from S3 access policy as an inline policy named s3access.
Tag the role with ataccama:edge:customer-provided:instance-name: <edge-instance-name>.

Trust policy

This trust policy lets principals in your AWS account assume the role. Replace <ACCOUNT_ID> with your AWS account ID.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<ACCOUNT_ID>:root"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ]
    }
  ]
}

S3 access policy

This policy grants the edge the actions it needs against your bucket and its objects. Replace <BUCKET_NAME> with the bucket name.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:ListBucket",
        "s3:DeleteObject",
        "s3:AbortMultipartUpload"
      ],
      "Resource": [
        "arn:aws:s3:::<BUCKET_NAME>",
        "arn:aws:s3:::<BUCKET_NAME>/*"
      ]
    }
  ]
}

Verify the role

Open the role in the IAM console and confirm:

The trust policy matches Trust policy.
The s3access inline policy is attached.
The ataccama:edge:customer-provided:instance-name tag is set.

Record the role ARN for later configuration.

Required information for next steps

Record these values. You’ll need them when configuring the edge instance.

AWS account ID
AWS Region
VPC ID
Private subnet IDs (all three)
Public subnet IDs (all three)
S3 bucket name and Region
IAM role ARN

Next steps

Deploy your edge instance:

Prepare AWS Infrastructure