Skip to content
Learning Outcomes
  • Understand the three ways a run can authenticate to AWS.
  • Know which mode a run environment uses and when each applies.
  • Understand what the organization "require role-based AWS auth" policy does and does not cover.

AWS Run Authentication Modes

When a pipeline run reads from or writes to AWS (for example an S3 work or publish directory, or an AWS Batch executor), it authenticates to AWS in one of three ways. The mode is determined by the run environment the run uses. See AWS Credentials for entering a personal key and Configure Run Environment for AWS Batch profiles.

Mode 1: Personal access keys

A personal AWS access key and secret key that you enter on the AWS Credentials page. The run environment references your saved key and the run uses it directly. This is the simplest mode and fits a single user working with their own bucket. Because the key is long-lived and tied to a person, some organizations restrict it (see the policy note below).

Mode 2: Assume-role credentials

An organization credential that names an AWS IAM role ARN rather than a stored key. At run time Foundry assumes that role and receives temporary, automatically expiring credentials for the run. Assume-role credentials are created in Organization Settings, and each role ARN must be approved by an organization admin before it can be used. This mode avoids sharing long-lived personal keys and is the recommended option for shared or regulated environments.

Mode 3: Cluster or instance IAM role

No credential is stored. The run environment relies on the IAM role attached to the compute that runs the job (for example an EC2 instance profile, an ECS task role, or an IRSA role on Kubernetes). Foundry uses the default AWS provider chain, so the attached role supplies the identity. Choose this mode when Foundry already runs inside your AWS account with a suitable role attached. In that case the Amazon Keys field on the run environment is left empty.

The "require role-based AWS auth" policy

Organization admins can turn on a policy that forbids personal access keys for runs. It is set in Organization Settings and is off by default.

When the policy is on:

  • The run environment form hides the personal access key option.
  • Saving a run environment that uses a personal key is rejected.
  • Launching a run with a personal key is rejected.
  • The run scheduler cannot poll cloud storage with a personal key.

Only Mode 2 (assume-role) and Mode 3 (instance role) are allowed while the policy is on. A run environment must use an approved role ARN or an attached instance role.

What the policy covers

The policy governs how a run authenticates to AWS: the credential injected at launch, the run environment save, and the scheduler's cloud polling. It does not change server-side operations such as signing a temporary download link for a run's own results, and it does not restrict free-form values you type into a run environment's Environment Variables field. If you set AWS_ACCESS_KEY_ID or similar variables there by hand, they are outside the credential model and are not checked by this policy.