Deploy a Self-Managed Edge

Install the following on the machine where you will run Terraform — your workstation or a CI/CD runner:

Confirm the AWS CLI is authenticated before proceeding:

The machine running Terraform needs outbound HTTPS access to:

The IAM principal used to run Terraform needs administrative access to the target AWS account, or at minimum permissions to create and manage the following resources:

The edge deployment ZIP contains all Terraform configuration and component definitions.

Extract the edge deployment ZIP, open registry.auto.tfvars.json, and fill in the credentials provided by Ataccama:

The deployment runs without any changes for most environments. Some AWS accounts have organizational requirements that need an additional variable to be set.

Set optional parameters by creating a new *.auto.tfvars.json file in the bundle root. Terraform automatically loads any file matching *.auto.tfvars.json, so you don’t need to edit the pre-populated variable files.

If none of the following applies to your environment, continue to the next step.

Configure a Terraform backend according to your organization’s standards — for example, an S3 backend with DynamoDB state locking. Add a backend block to terraform.tf or create a separate backend configuration file.

This stores your Terraform state remotely and enables collaboration and state locking.

From the root of the extracted bundle directory:

The Ataccama edge module is bundled locally; no external module registry access is required. However, access to the public Terraform Registry is required to download Terraform providers (such as the AWS provider).

Review the planned resources. Terraform creates resources in your AWS account only, including:

When satisfied with the plan, apply it:

Deployment typically completes in 10–20 minutes. Don’t interrupt the process once it has started.

Terraform waits for ECS tasks to start successfully before completing.

After terraform apply completes:

Ataccama will verify control plane connectivity and confirm the edge is registered.

Data sources must be reachable from the edge’s ECS security group on the appropriate port.

Terraform doesn’t configure this connectivity — you’re responsible for routing and firewall rules between the edge VPC and your data source endpoints.

Only the configuration you added on top of the bundle moves from development to production, never the bundle itself. Everything pre-populated in the package is environment-specific or release-specific and always comes from the new environment’s own package (in the derivation flow, verified against it).

Copy the following from development and then adjust:

Recreate the following with production values:

Changes made directly to pre-populated files or to the bundled module are neither supported nor carried over. Move such values into your own *.auto.tfvars.json files where a variable exists, or contact Ataccama where none does. The derivation flow (Derive the production deployment from the development bundle) flags every such change in its verification diff.

A deployment package is generated at the release selected at registration, by default the latest. If the development edge was deployed some time ago, a default production registration therefore produces a newer release than the one you reviewed in development.

To promote a reviewed configuration unchanged:

A matching package does not make the environments identical. The package encodes only what you provided at registration; the infrastructure you built following Prepare AWS Infrastructure lives outside it and can differ between the two accounts (for example, in VPC endpoints and their endpoint policy, egress routing and firewall rules, the registry mirror and its repository settings, and organization-level controls such as service control policies or policy checks on your Terraform runs). Verify the production account against the same Prepare AWS Infrastructure checklist you used for development rather than relying on the package comparison.

The standard flow in Deploy the production edge starts from the production package.

If your change management requires proof that production runs the artifact validated in development, derive the production deployment from the development bundle instead. With both edge instances on the same release, the two flows produce the same content, and the final diff is the proof:

The environment identity of a deployment package is contained in two files:

All remaining pre-populated files are release-specific (component versions and Lambda artifact references), not environment-specific.

Run terraform init from the root of the extracted directory, where main.tf is located. The terraform-aws-edgeinstance/ subdirectory must be present alongside main.tf.

Run aws sts get-caller-identity to confirm which IAM principal is active. Verify it has the permissions listed in IAM permissions for Terraform.

Running terraform apply fails with an AccessDenied error while creating aws_s3_bucket_public_access_block when your organization denies the s3:PutBucketPublicAccessBlock action through a Service Control Policy (SCP).

Opt out by setting s3_block_public_access to false, then run terraform apply again. For instructions, see (Optional) Disable the S3 public access block.

Check CloudWatch Logs for the affected task. Common causes include:

Check CloudWatch Logs for SQS connectivity errors.

Contact Ataccama Support with your edge name and the relevant log output.

When contacting Ataccama Support, provide:

Terraform creates the IAM roles needed for services to function and communicate. No IAM role is granted to Ataccama inside the customer account.