Ataccama ONE Agentic ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
Downloads

Edge Processing

Edge processing lets you use Ataccama for data quality, profiling, and other processing tasks without moving sensitive data out of your environment.

Processing components run inside your own infrastructure: an AWS account or a Kubernetes cluster you operate. Your sensitive data and processing results stay in your storage — Ataccama ONE securely loads them on demand and doesn’t retain them.

When to use edge processing

Choose an edge deployment when:

  • Data residency, sovereignty, or regulatory rules prevent moving data to Ataccama-hosted infrastructure.

  • Your security model requires that sensitive data and processing results stay within your network boundary.

  • You want full control over the storage and compute that touch your data, while still using Ataccama’s runtime for metadata, rules, and orchestration.

If none of these apply, the standard deployment, where Ataccama hosts the full processing stack, is usually simpler.

How edge processing works

Edge architecture separates processing and data management into four parts:

  • The edge compute runs inside your own infrastructure and processes data from your sources without storing it.

  • The data sources are the storage you own that holds primary data and processing results.

  • The control plane runs in Ataccama, where you browse metadata, define rules, and view results.

  • The Ataccama Cloud Portal runs in Ataccama. From there you manage edge instances and access deployment artifacts and upgrades.

All communication between cloud and edge components is encrypted with TLS 1.3. Sensitive data and processing results are additionally encrypted at the application level at rest. On the Kubernetes edge, this encryption is optional; see Key Vault key. All edge traffic is outbound only — no inbound access to your network is required.

Private connectivity between the edge and your data sources depends on your existing network setup, such as routing, peering, and firewall configuration. Data exchange with the control plane uses private AWS networking when the edge runs in the same AWS region as your Ataccama environment; for other regions, contact your Ataccama Customer Success Manager to discuss connectivity options. For the Kubernetes edge on Azure, traffic to the control plane goes through the Ataccama Edge gateway over Azure Private Link.

On AWS, some supporting traffic leaves your VPC through your NAT gateway over the public internet (TLS-encrypted): container image pulls from the Ataccama registry and some AWS service API calls. For self-managed deployments and for the Kubernetes edge, you can pull images through your own registry or pull-through cache instead, giving you control over how that traffic is routed.

For the full breakdown of communication patterns, see Edge Architecture.

Deployment options

Edge instances come in three variants. Choose based on where the edge compute runs and how much of the underlying infrastructure you want to manage directly.

Option Runs in Compute Who operates it

Ataccama-managed on AWS

AWS account you own.

Amazon Elastic Container Service (ECS) tasks on AWS Fargate.

Ataccama provisions, upgrades, and configures through automation.

Self-managed on AWS

AWS account you own.

ECS tasks on AWS Fargate.

You run the deployment and lifecycle using Terraform artifacts distributed by Ataccama.

Kubernetes edge

Azure Kubernetes Service (AKS) cluster you operate.

Pods on your cluster’s nodes.

You run the deployment and lifecycle using the Kubernetes edge Helm chart distributed by Ataccama.

Ataccama-managed on AWS

Ataccama deploys and operates the edge compute inside an AWS account you provide. You set up networking and storage; Ataccama handles provisioning and upgrades through automation.

Choose this when your sensitive data lives in AWS and you want Ataccama to operate the edge compute for you.

Self-managed on AWS

You run the edge compute on infrastructure you own and operate end-to-end. Ataccama provides the software, deployment artifacts, and upgrade packages.

Choose this when you require full operational control over every component of the deployment.

Kubernetes edge on Azure

You run the edge compute on an Azure Kubernetes Service (AKS) cluster you operate, using the Kubernetes edge Helm chart. Ataccama provides the chart, the container images, and the upgrade releases.

Choose this when your sensitive data lives in Azure and you want to operate the edge on your own Kubernetes cluster. See Kubernetes Edge.

Shared responsibility model

Edge instances follow a shared responsibility model: Ataccama provides the platform and software; you own the cloud account or cluster, the network, and the data.

Ataccama staff have no direct access to your edge environments.

For the full breakdown, see Shared Responsibility Model.

Next steps

  1. Decide which deployment option fits your environment.

  2. Follow the guide for your option:

Was this page useful?