How DynamoDB Source Authentication Works in Skippr

June 2026

DynamoDB source authentication uses the AWS default credential chain, so the real decision is which AWS principal will read the table now and, if needed later, consume Streams for CDC.

Short Answer

DynamoDB source authentication in Skippr uses the AWS default credential chain. There is no separate DynamoDB username or password field. Skippr will use standard AWS credentials such as access keys, IAM roles, instance profiles, task roles, AWS SSO, or shared config profiles to call DynamoDB on behalf of the source.

That makes the source easy to wire into real infrastructure, but it also means the auth model is permission-shaped. A batch read of customers-prod in us-east-1 only needs an AWS principal that can describe and scan that table in that region. If you later turn on cdc_enabled: true, the same auth story expands to DynamoDB Streams permissions because the pipeline is no longer just reading table state.

Why Teams Struggle with This

The common mistake is treating "AWS credentials exist" as if that settled source authentication. The docs tie auth to specific DynamoDB capabilities and specific AWS context, so the principal, region, table, and CDC intent all matter to whether the source is truly authorized.

• For batch reads, the AWS principal needs dynamodb:DescribeTable and dynamodb:Scan.
• For CDC, the docs explicitly add DynamoDB Streams permissions on top of the batch-read permissions.
• The configured region and optional endpoint_url decide where those credentials are applied, which matters immediately in multi-region or LocalStack setups.
• An IAM role that can read one table is often better than a broad account-wide principal because it matches the actual source boundary.

How Skippr Handles It

Skippr works well here because it follows the AWS model instead of wrapping it in another secret format. You declare table_name, region, and optional endpoint_url, and the runtime uses the credential chain that the host environment already trusts.

That gives teams a clean progression. Start with a narrow table scan under one IAM role or profile. If the use case becomes a final-state CDC pipeline, expand the same source with the extra Streams permissions the docs call out instead of replacing the source definition.

• Authentication through the AWS default credential chain rather than a connector-specific secret.
• A small source surface of table_name, region, and optional endpoint_url.
• Clear documentation separating batch-read permissions from DynamoDB Streams permissions.
• A source contract that aligns well with IAM roles in ECS, EC2, Lambda-adjacent runners, and CI.

What the First Useful Version Looks Like

The first useful version is one DynamoDB table, one AWS region, and one principal that can scan it. That tells you whether the identity and network context are correct before CDC enters the picture.

If the business really needs mutation-level freshness, add Streams permissions on purpose and test that behavior as a second step. The clean auth model is the one that matches the real ingestion mode.