How Outpost Works

Outpost (also called InHost) runs Relyance inventory and data inspection workers in your AWS account. You operate the EKS deployment and keep connection credentials in AWS Secrets Manager with In Host BYOK. Workers write inventory, indexed scan configuration and classification results to your S3 storage. Relyance copies completed inventory and results to hosted Google Cloud Storage (GCS) for processing and display. Metadata therefore leaves your AWS account.

This guide covers an existing EKS cluster, single-account AWS inventory, Amazon RDS including PostgreSQL, and ClickHouse Cloud. Relyance must set up your tenant and supply the complete deployment configuration before you install. Inventory stays off until that configuration is in place.

The setup uses these public, versioned references. Relyance supplies the complete tenant overlay or Helm values:

The Kustomize archive includes the tenant renderer at inhost/bin/render-tenant. The archive SHA-256 is e6bd3cc4dc7e26d965adc1f47d1ebec715d9a86ce6c8bdb9466e190507c0f0aa. Helm and Kustomize have separate version numbers; use the versions in your supplied package.

Step 3 includes both Kustomize and Helm procedures. Keep the management method, registered namespace and release name of an existing installation; agree any migration with Relyance.

#At a glance

1. Agree the resource scope. Complete the onboarding worksheet with your Relyance team using resource references only.
2. Prepare AWS access. Review the Terraform plan for the existing EKS cluster, S3 storage, IAM roles and KMS permissions.
3. Receive your deployment package. Relyance registers your AWS resources, provisions hosted routing and transfer access, and supplies the complete tenant values, including the runtime images.
4. Install and validate. Apply the package, create BYOK connections, and verify discovery, sampling and hosted results separately.

Relyance has no Kubernetes or console access and no inbound access to your cluster or private data-source network. The authorized transfer role reads agreed S3 outputs through the S3 API. You run the installation steps with your own tools and credentials. For the full commands, refer to Deployment plan.

#Design principles

#Architecture

Outpost has two parts: the components in your AWS account, and the Relyance platform.

#Inventory workers

Inventory runs as two Deployments, separate from the four scanner ScaledJobs:

• data-pipelines discovers the approved resources and writes inventory and indexed scan configuration to S3.
• gai-inventory-notifications picks up finished inventory and starts any supported data inspection.

Each runs one replica. KEDA, inhost-scaler and Redis still run the scanner jobs.

You can install the package before you create any connections; the workers stay idle until there is work. Then create and authenticate an In Host BYOK connection and start its scan in the Relyance web application. You do not need to list connections in your values or update the deployment for each new connection. If your existing values contain inventory.integration_ids, remove it; the current package rejects it.

Setting inventory.enabled: true on its own is not enough. Relyance prepares these settings with you and supplies them in your package:

• The AWS accounts for the deployment, inventory and Secrets Manager.
• The S3 bucket, owner, storage region and inventory prefix.
• The findings-bucket deletion permission and inventory.versioned_result_cleanup: true, described below.
• The runtime images, the queue settings and the workload identity settings.

Keep these values as supplied. Do not edit them or copy them from examples.

Scanner and inventory workers share the relyance Kubernetes service account. inhost-scaler has its own service account to read queue length. Your AWS Pod Identity role needs read access to Secrets Manager, decryption with any KMS keys involved, and the S3 output permissions.

Scanner workers can save refreshed OAuth tokens to Secrets Manager for authentication methods that need it. Keep byokSecretWriteBack consistent with the write-back permission in Terraform. Inventory workers only read secrets.

Before Relyance can show results, it also registers your output location and reader role and turns on the copy to hosted storage. Check these separately after the first scan: inventory is written to S3, the copy to Relyance completes, and the results appear in the application.

#How a scan works

The numbers match the arrows in the diagram.

1. The cluster pulls the scanner images from the Relyance container registry.
2. Relyance puts a scan command in the command queue. The autoscaler sees the waiting command and starts scanner workers. A scanner worker pulls the command.
3. The scanner gets the connection settings from the control plane API. During the scan, it reports progress and completion to the same API. These reports contain status and counts, not your data.
4. The scanner reads the credentials for the data source from the secret store.
5. The scanner connects to the data source and reads samples for local classification. Review the agreed output policy under What Relyance receives.
6. Workers keep temporary scan data in the work bucket. Inventory workers write their inventory datasets and indexed scan configuration to the agreed S3 output prefix; those configurations retain the original S3 source references.
7. The scanner classifies samples in EKS and writes results to S3. Inventory finalization and scan completion trigger the hosted transfer path.
8. GAIOT reads the completed S3 outputs with the scoped reader role and copies them to hosted GCS. Hosted data security and identity services use the hosted copy with their existing processing paths. Results appear after transfer and processing complete; local worker completion alone does not prove that they are visible.

#Deployment plan

#Onboarding worksheet

Share resource references through your agreed onboarding channel. Do not include passwords, API keys, secret JSON, database records or a Terraform state file.

Use existing approved infrastructure wherever possible. The public AWS module can reuse EKS, but still creates its S3 buckets, KMS key and IAM roles. It has no input for reusing arbitrary existing buckets or an existing bucket-encryption key. If those resources already exist, review their ownership and Terraform state with your infrastructure team before applying; use the Relyance-reviewed resource mapping rather than creating parallel storage or replacing resources.

#Who does what

Do not construct tenant identity values from examples. Confirm that Relyance has qualified the supplied inventory images and enabled inventory for your tenant before starting an AWS inventory scan. Installing a manifest or saving a connection is not acceptance of the deployment.

#Before you start

#Step 1: Create the AWS resources

Add the module to a Terraform configuration. Replace the example account, region and cluster name with the worksheet values. Set the AWS provider's allowed_account_ids to the deployment account so Terraform refuses credentials for a different account. This is separate from assumable_account_ids, which controls the source accounts the scanner may access. Use your own AWS credentials and review the plan before applying it.

The module supports AWS provider versions >= 5.79, < 7.0. The example below selects AWS provider 6.x.

To use an existing EKS cluster:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 6.0, < 7.0"
    }
  }
}

module "outpost" {
  source  = "Relyance-Ext/sierra/aws"
  version = "0.9.0"

  create_vpc_and_eks        = false
  existing_eks_cluster_name = "my-cluster"

  # The AWS accounts whose IAM roles the scanner can assume to read data sources.
  # Set this, or set assume_all_roles = true.
  assumable_account_ids = ["111122223333"]

  # The manifests deploy into the "inhost" namespace.
  additional_service_account_namespaces = ["inhost"]

  # Optional: secrets for In Host BYOK connections.
  byok_secret_arn_patterns = [
    "arn:aws:secretsmanager:us-west-2:111122223333:secret:relyance/inhost/*",
  ]
}

provider "aws" {
  region = "us-west-2"
  # Your Outpost deployment account from the worksheet, not a source account.
  allowed_account_ids = ["111122223333"]
  default_tags {
    tags = module.outpost.default_tags
  }
}

output "outpost" {
  description = "Send this output to Relyance"
  value       = module.outpost
}

To create a new EKS cluster, replace the cluster settings with the network ranges for the new VPC:

  create_vpc_and_eks = true
  vpc_cidr           = "172.30.0.0/16"
  service_cidr       = "10.100.0.0/16"
  nat_subnet_cidr    = "172.30.255.0/24"
  subnet_cidrs = {
    usw2-az1 = "172.30.0.0/20"
    usw2-az2 = "172.30.16.0/20"
    usw2-az3 = "172.30.32.0/20"
    usw2-az4 = "172.30.48.0/20"
  }

  # Empty means the cluster API endpoint is private only.
  eks_public_access_cidrs = []

For a new cluster, set one subnet for each availability zone ID in the region. For either deployment path, confirm that the account returned below matches the deployment account in your worksheet before you plan:

aws sts get-caller-identity --query Account --output text
terraform init
terraform plan -out=outpost.tfplan
terraform apply outpost.tfplan
terraform output -json outpost

For all inputs, refer to the module documentation.

#What the module creates

The module creates its own KMS key. It does not accept an existing key. For existing approved storage, review the bucket and key policies with Relyance rather than substituting names in the module. The module's S3 policy gives a reader s3:ListBucket, s3:GetObject and s3:GetObjectVersion; the hosted transfer must retain those reads on the agreed outputs, plus decryption with the output key. The EKS workload needs the S3 read/write and multipart-upload permissions for its approved output/work prefixes. Secret read/decrypt permissions are separate and are detailed in the BYOK access guide.

#Findings-bucket deletion permission

The supporting Terraform module grants the scanner role s3:DeleteObject and s3:DeleteObjectVersion throughout the dedicated findings bucket. This includes intermediate results, Delta files, journals and other findings objects. The permission is for that findings bucket, not unrelated customer S3 buckets. Version deletion is permanent and applies to every matching version accessible to the role, including existing sessions. Review this access before applying the module.

The applied module emits findings_object_deletion with enabled, account_id and bucket. Relyance validates these facts against your AWS account and findings bucket. Enabled capability sets GAI_INHOST_FINDINGS_DELETION_ENABLED to "true" for the GAI sampler/analyzer workers. An older module without this output leaves the new deletion gate disabled. Inventory cleanup also requires the explicit deployment choice inventory.versioned_result_cleanup: true before DP_INHOST_VERSIONED_RESULT_CLEANUP is set to "true". Module 0.9.0 emits this capability. Use the applied module output and a reviewed runtime package before activation.

The application still chooses the objects it owns and must prove captured-version cleanup, replacement preservation and Delta maintenance in the normal deployment rehearsal. Keep credentials in AWS Secrets Manager. Findings-bucket deletion does not change credential custody or the hosted GCS handoff.

#Optional rehearsal subscriptions and query regions

For an approved rehearsal, Relyance can supply an explicit tenant-owned subscription selector. It selects fresh DP and inventory-notification subscriptions in your trusted project on the existing canonical topics. The package keeps the normal worker entrypoints and requires a released notifier image that supports the selector. Review the exact subscription/topic bindings and subscriber permissions before activation. Fresh subscriptions leave old canonical queues intact and receive new topic traffic from all producers. Verify producer quiescence and zero eligible pending transfers before the rehearsal; a successful rehearsal does not qualify old queue contents.

Agree inventory.query_regions independently from the bucket's storage region. An explicit nonempty list, such as [us-west-2], bounds regional API discovery after the runtime checks enabled/supported regions. Omission keeps the account-enabled regional defaults. IAM and S3 discovery remain account-global. The package does not infer discovery scope from the S3 bucket region.

#Step 2: Send the output to Relyance

Send only the outpost module output to your Relyance team through the agreed onboarding channel. It contains resource and access references, including the reader external ID. Do not send the Terraform state or credential secret values. Relyance uses these values:

Relyance then sends you a complete Kustomize folder or full Helm values.yaml. It contains your routing, storage, identity and runtime image settings. When you upgrade, use the image settings from the new package; the chart version alone does not choose the images. Ask Relyance to confirm the inventory settings before you apply it. Do not build these values from examples or put connection credentials in them.

#Step 3: Install the cluster components

Use the version and complete configuration supplied for your tenant. Check the context and review cluster-scoped changes, including KEDA CRDs, the jobs NodePool and StorageClass, before applying. The default AWS package requires EKS Auto Mode, its default NodeClass and the Auto Mode EBS CSI provisioner. For standard EKS, obtain a reviewed node/storage configuration first.

Allow outbound traffic to the supplied ECR registry and its S3 image layers, the API hosts in the values file, sts.googleapis.com, iamcredentials.googleapis.com, pubsub.googleapis.com, monitoring.googleapis.com, the required AWS APIs, and your approved source endpoints. Verify DNS, routing and source security groups separately.

#Prepare the cluster

1. Set AWS_REGION, EKS_CLUSTER_NAME and INHOST_NAMESPACE in your shell from the supplied package. The published Kustomize base uses inhost; an existing registered Helm deployment may use sierra. Preserve the supplied namespace because workload identity registration depends on it. Confirm your Kubernetes context and AWS account match the worksheet.

   aws eks update-kubeconfig --region "$AWS_REGION" --name "$EKS_CLUSTER_NAME"
   kubectl config current-context
   kubectl get nodes

2. Install KEDA if it is not already installed. The bundle below contains KEDA 2.20.2. If KEDA is already installed, check that it supports ScaledJobs and the metrics-api and Redis scalers instead of installing a second copy.

   kubectl apply --server-side \
     -f https://assets.relyance.ai/inhost/k8s/v1.4.1/keda-aws-prod-v1.4.1.yaml
   kubectl wait --for=condition=Established --timeout=120s \
     crd/scaledjobs.keda.sh crd/triggerauthentications.keda.sh
   kubectl -n keda rollout status deployment/keda-operator --timeout=5m
   kubectl -n keda rollout status deployment/keda-metrics-apiserver --timeout=5m
   kubectl -n keda rollout status deployment/keda-admission --timeout=5m

3. Create the namespace if it does not already exist.

   kubectl create namespace "$INHOST_NAMESPACE" --dry-run=client -o yaml | kubectl apply -f -

#Kustomize installations

Render and validate the complete folder from Relyance, then apply it:

kubectl kustomize ./relyance-outpost > outpost-rendered.yaml
kubectl apply --dry-run=server -k ./relyance-outpost
kubectl diff -k ./relyance-outpost
kubectl apply -k ./relyance-outpost

kubectl diff returns exit code 1 when changes are present and greater than 1 for an error. Review the changes before applying. Check that the rendered file has your agreed account, regions, S3 prefixes, service accounts and runtime image settings, with no unresolved REPLACED-BY-TENANT-OVERLAY values. Keep the supplied image references and pull policies. Do not apply the following abbreviated example as a complete tenant package.

The scanner part of kustomization.yaml starts like this:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - https://assets.relyance.ai/inhost/k8s/v1.4.1/services-aws-prod-v1.4.1.yaml
patches:
  - path: patch-tenant-values.yaml
    target:
      version: v1
      kind: ConfigMap
      name: common-env
  # ...

To read the manifests before you apply them, download them and check them against the published checksums:

curl -fsSLO https://assets.relyance.ai/inhost/k8s/v1.4.1/services-aws-prod-v1.4.1.yaml
curl -fsSL https://assets.relyance.ai/inhost/k8s/v1.4.1/SHA256SUMS-v1.4.1.txt \
  -o SHA256SUMS-v1.4.1.txt
shasum -a 256 -c SHA256SUMS-v1.4.1.txt --ignore-missing

#Helm installations

Use the full values.yaml supplied by Relyance and Helm 3.14 or later. Set INHOST_VALUES to that file's path. Check helm list --namespace "$INHOST_NAMESPACE" and set INHOST_RELEASE to the existing release name. For a fresh installation, use inhost. Do not install a second release over existing resources or mix Helm and Kustomize ownership.

Download and verify the chart, then render, validate and review the proposed changes:

curl -fsSLO https://assets.relyance.ai/inhost/helm/inhost-1.3.0.tgz
curl -fsSLO https://assets.relyance.ai/inhost/helm/SHA256SUMS-chart-v1.3.0.txt
shasum -a 256 -c SHA256SUMS-chart-v1.3.0.txt --ignore-missing
printf '%s  %s\n' \
  78f1cc6c093bb58afc206a2dafefc16546aa78cfbb4315fe51c0b6419e32fda8 \
  inhost-1.3.0.tgz | shasum -a 256 -c -
helm lint ./inhost-1.3.0.tgz --values "$INHOST_VALUES"
helm template "$INHOST_RELEASE" ./inhost-1.3.0.tgz \
  --namespace "$INHOST_NAMESPACE" --values "$INHOST_VALUES" > outpost-rendered.yaml
kubectl --namespace "$INHOST_NAMESPACE" apply --dry-run=server -f outpost-rendered.yaml
kubectl --namespace "$INHOST_NAMESPACE" diff -f outpost-rendered.yaml

The server dry-run needs KEDA installed first. kubectl diff returns 1 when there are changes and more than 1 for an error; review the changes before you upgrade. The supplied values file is complete, so do not add another values file or use --reuse-values.

helm upgrade --install "$INHOST_RELEASE" ./inhost-1.3.0.tgz \
  --namespace "$INHOST_NAMESPACE" --create-namespace --values "$INHOST_VALUES" \
  --atomic --wait --timeout 40m
kubectl -n "$INHOST_NAMESPACE" rollout status deployment/data-pipelines --timeout=40m
kubectl -n "$INHOST_NAMESPACE" rollout status deployment/gai-inventory-notifications --timeout=10m

The two rollout checks apply when inventory is enabled. The 40-minute timeout gives a running inventory worker time to finish before it is replaced. Then continue with Step 5.

#What the manifests install

The services file contains no Role, ClusterRole or CRD, and no monitoring, log or telemetry agent. The KEDA file installs the standard KEDA components, with their own CRDs and cluster roles. The scanner ScaledJobs, inhost-scaler and Redis templates run as non-root with all Linux capabilities dropped, and meet the Kubernetes Restricted Pod Security Standard. Before inventory activation, Relyance must qualify the complete inventory overlay, including its images, identity and pod security settings.

#Step 4: Add connections

A connection tells the scanner how to reach one data source. Set its runtime mode to run the scan in Outpost:

New connections start as Relyance-hosted. Set the runtime mode on each Outpost connection. Use In Host BYOK to keep the credentials in your account.

In the web application, follow Store Outpost Credentials in a Customer-Managed Secret.

With Terraform, use the Relyance provider. Set RELYANCE_CLIENT_ID and RELYANCE_CLIENT_SECRET through your approved credential mechanism for an OAuth client with the Integration Configuration Management role. This example references an existing RDS credential secret. Create its value in AWS Secrets Manager using the supported JSON shape; do not put credential values in Terraform configuration or state.

If you keep this example in the same Terraform directory as Step 1, merge its relyance entry into the existing required_providers block.

terraform {
  required_providers {
    relyance = {
      source  = "Relyance/relyance"
      version = "1.1.1"
    }
  }
}

provider "relyance" {}

variable "rds_secret_arn" {
  type        = string
  description = "Full ARN of the existing credential secret in your deployment account"
}

resource "relyance_integration_connection" "rds" {
  vendor       = "aws_rds"
  name         = "RDS (Outpost)"
  runtime_mode = "IN_HOST_BYOK"
  connect_on_apply = false
  secret_ref   = var.rds_secret_arn

  auth = {
    method = "username-password"
  }

  scans = {
    "data-inspection" = { enabled = false }
  }
}

This example leaves the connection unconnected and data inspection disabled while you verify the deployment and source access. Save the raw-sample storage policy and review the separate sanitized-context setting under What Relyance receives before connecting or enabling a scan. With secret_ref, all credential fields, including endpoint, engine, username and scope, belong in the AWS secret. Keep auth.secrets_wo unset and put only top-level settings in auth.params. Authentication methods and scan capabilities come from the provider's relyance_integration_vendor data source. Use the BYOK guide for secret access and supported authentication methods.

#AWS single-account inventory

Follow the AWS inventory setup guide for Resource Explorer and discovery permissions. Choose Direct Connection, use In Host BYOK, and store role_arn, external_id and region_name in the AWS secret. The discovery role trusts the EKS workload role; the workload role must be allowed to assume it. Hosted trust examples in the integration guide require this adjustment for Outpost.

Use the agreed aggregator region and qualify every intended source region. A valid secret, an enabled AWS region, or a successful connection check does not establish complete inventory coverage. Begin with the approved resource types and a bounded scope; expand after the first successful scan. This path covers one AWS account, not an Organizations scan.

#PostgreSQL on Amazon RDS

Use the Amazon RDS guide for the engine and authentication setup. For direct PostgreSQL, set engine to postgres in the credential secret. Existing EKS-to-RDS routes, DNS and security groups must allow the database port. You do not need to make RDS public when EKS already has an approved private path.

For direct PostgreSQL, confirm approved CONNECT access to the postgres bootstrap database as well as the intended application databases; the RDS guide explains how to validate this access and coordinate a supported alternative if it is forbidden. Verify database-side read grants independently of AWS IAM. IAM authentication additionally needs rds-db:connect for the intended database user and PostgreSQL rds_iam membership. Discovering the RDS instance is separate from opening SQL sessions and reading tables.

#ClickHouse Cloud

Follow the ClickHouse guide. The Cloud API key discovers organizations and services; db_user and db_password authorize database inspection. Keep both sets in the AWS secret. Allow the ClickHouse Cloud API and each discovered service's HTTPS endpoint from EKS, using the service's TLS port. Native TCP connectivity alone does not validate the HTTP scanner path.

#Step 5: Check the deployment

First confirm the installed components using the namespace from your supplied package. With inventory enabled, data-pipelines and gai-inventory-notifications should each show one available replica.

kubectl get serviceaccounts,deployments,statefulsets,scaledjobs,pods -n "$INHOST_NAMESPACE"
kubectl rollout status deployment/inhost-scaler -n "$INHOST_NAMESPACE"
kubectl rollout status statefulset/gai-redis-master -n "$INHOST_NAMESPACE"
kubectl -n "$INHOST_NAMESPACE" get deployments data-pipelines gai-inventory-notifications
aws eks list-pod-identity-associations --cluster-name "$EKS_CLUSTER_NAME" --region "$AWS_REGION"

Compare the association's namespace, service account and role with the rendered pod specifications, and check that the running images match your package. An administrator's successful AWS CLI call does not prove the pod can access a secret or source. Scanner jobs are absent while idle; that is normal. The inventory Deployments should always be available.

Run one bounded scan per connection from the Relyance web application. Follow the scan status and warnings there, and observe workloads with kubectl get pods -n "$INHOST_NAMESPACE" -w. Check each layer:

Compare against a customer-maintained list of known resources. Empty results, an incomplete region, or a warning require investigation; they are not proof that the source contains no resources. Agree capacity after measuring a representative scan. Throughput and region coverage depend on the qualified deployment and scan scope.

#Scan progress and retry

Record the connection, scan time, visible status and affected resource/region. Check pod events and the relevant workload's logs locally while the scan is active. Correct permanent errors such as secret shape, denied permissions or missing routes before starting another scan. After rotation, allow up to five minutes for the cached credential value to refresh.

A local scan can finish before the hosted copy and processing finish. If output exists in S3 but results remain absent, ask Relyance to check the transfer and hosted processing for that scan before starting a duplicate. For a failed scan, use the scan action available on your connection after correcting the cause. Do not delete output prefixes or Kubernetes state to force a retry; Relyance can coordinate recovery of an interrupted transfer.

#What Relyance receives

The hosted copy includes resource metadata (such as account, database, table, column and file names), applicable identities and permissions, classification results, and scan status/counts. Metadata can itself be sensitive. Review the enabled connectors and the agreed output policy before activation.

Raw matched values and stored source samples require explicit per-connection enablement where permitted; a missing setting or a tenant-wide default is not consent. Strict InHost mode blocks their egress even if store_samples="true". To disable raw-sample storage, save an explicit per-connection store_samples="false" setting before enabling data inspection, run a fresh scan on the verified InHost image, and check that raw sample and quote-value fields are absent. Changing the setting does not remove outputs from earlier scans.

Sanitized v2 surrounding context is separate from raw matched values and samples. Typed redaction and a shipped dictionary transform this context before storage; the existing Relyance-managed explainability setting (gai-explainability-context="quote") controls its use for hosted adjudication. When enabled on a qualified release, this context can be copied to hosted GCS and sent to the configured hosted model service, including with raw-sample storage disabled. Sanitization reduces exposure; it does not guarantee that every possible sensitive meaning is removed. Review this processing separately rather than assuming that disabling raw samples makes outputs context-free.

Release qualification. The current scanner baseline also suppresses surrounding context when store_samples="false". The update that separates sanitized v2 context from raw-sample storage still requires release qualification. Before activation, Relyance must verify both settings and the exact scanner and transfer images, including an output check for the agreed policy. Do not rely on an unshipped update or a tenant default.

Hosted processing includes adjudication of copied findings. Structural names, paths, identifiers and classifications may be sent to the configured hosted model service. Disabling sample storage does not disable that metadata processing. Agree the allowed data categories and processing destinations before activation; BYOK is a credential-custody choice, not an all-data-stays-in-AWS guarantee.

In Host BYOK keeps connection credential values in your AWS Secrets Manager; Relyance stores the ARN reference and connection settings. BYOK controls credential custody. It does not keep all derived metadata in AWS. Hosted data security and identity services consume the copied inventory/results in GCS, rather than reading your customer S3 bucket directly.

#Security

Identity. The Outpost components use short-lived credentials for AWS and Relyance workload access. The scanner pods get the Relyance_Sierra role through EKS Pod Identity. They sign in to the Relyance command queue and API with short-lived credentials from workload identity federation.

Credentials. With In Host BYOK, the credentials stay in a secret in your account. Relyance stores only the secret ARN and rejects credential values for these connections. The scanner reads the secret during the scan with its own role. For the setup steps, refer to Store Outpost Credentials in a Customer-Managed Secret.

Encryption. All connections to Relyance use TLS. A KMS key in your account encrypts the findings bucket and the work bucket.

Access. The module creates the read-only role Relyance_Sierra_Reader for the findings bucket, with the external ID from your module. For inventory, confirm that the hosted reader also has the approved output-prefix and KMS read access in the supplied deployment mapping. It must not gain access to connection secrets or temporary work data. Relyance has no Kubernetes or console access and no inbound access to your cluster or private data-source network. The separately authorized transfer role reads the findings bucket through the S3 API. When the module creates the cluster, it gives cluster administrator access only to the identity that applies it and to the identities that you list in eks_kubectl_admins.

Network. The cluster makes only outbound connections. The VPC that the module creates has outbound internet access through NAT gateways and no inbound path. To limit outbound traffic, allow these destinations:

#Data retention in your account

Versioning is on for both buckets. The lifecycle rules expire the current version of each object. Earlier versions of an object stay until you delete them, or until you add a lifecycle rule for noncurrent versions.

#Operations and support

#Troubleshooting

Updates. You operate deployment updates:

Moving the :release tag does not restart running pods. Running containers keep their current image. Long-lived data-pipelines and gai-inventory-notifications Deployments adopt the promoted image during your normal approved maintenance rollout or restart. Repeat the validation checks after an update and confirm the images used by the new pods.

Monitoring. The deployment sends no logs, metrics or telemetry to Relyance. Logs stay in your cluster. Use your own tools to collect them.

Support. Relyance collects no diagnostic data automatically. Relyance support uses only the diagnostic data that you decide to share.

#Related

• AWS inventory
• Amazon RDS
• ClickHouse Cloud
• How Relyance AI Works
• Store Outpost Credentials in a Customer-Managed Secret