aws_dynamodb
Inserts items into a DynamoDB table.
-
Common
-
Advanced
outputs:
label: ""
aws_dynamodb:
table: "" # No default (required)
string_columns: {}
json_map_columns: {}
max_in_flight: 64
batching:
count: 0
byte_size: 0
period: ""
check: ""
processors: [] # No default (optional)
outputs:
label: ""
aws_dynamodb:
table: "" # No default (required)
string_columns: {}
json_map_columns: {}
ttl: ""
ttl_key: ""
max_in_flight: 64
batching:
count: 0
byte_size: 0
period: ""
check: ""
processors: [] # No default (optional)
region: "" # No default (optional)
endpoint: "" # No default (optional)
tcp:
connect_timeout: 0s
keep_alive:
idle: 15s
interval: 15s
count: 9
tcp_user_timeout: 0s
credentials:
profile: "" # No default (optional)
id: "" # No default (optional)
secret: "" # No default (optional)
token: "" # No default (optional)
from_ec2_role: "" # No default (optional)
role: "" # No default (optional)
role_external_id: "" # No default (optional)
max_retries: 3
backoff:
initial_interval: 1s
max_interval: 5s
max_elapsed_time: 30s
The field string_columns is a map of column names to string values, where the values are function interpolated per message of a batch. This allows you to populate string columns of an item by extracting fields within the document payload or metadata like follows:
string_columns:
id: ${!json("id")}
title: ${!json("body.title")}
topic: ${!meta("kafka_topic")}
full_content: ${!content()}
The field json_map_columns is a map of column names to json paths, where the dot path is extracted from each document and converted into a map value. Both an empty path and the path . are interpreted as the root of the document. This allows you to populate map columns of an item like follows:
json_map_columns:
user: path.to.user
whole_document: .
A column name can be empty:
json_map_columns:
"": .
In which case the top level document fields will be written at the root of the item, potentially overwriting previously defined column values. If a path is not found within a document the column will not be populated.
Credentials
By default Redpanda Connect will use a shared credentials file when connecting to AWS services. It’s also possible to set them explicitly at the component level, allowing you to transfer data across accounts. You can find out more in Amazon Web Services.
Performance
This output benefits from sending multiple messages in flight in parallel for improved performance. You can tune the max number of in flight messages (or message batches) with the field max_in_flight.
This output benefits from sending messages as a batch for improved performance. Batches can be formed at both the input and output level. You can find out more in this doc.
Fields
backoff.initial_interval
The initial period to wait between retry attempts. The retry interval increases for each failed attempt, up to the backoff.max_interval value. This field accepts Go duration format strings such as 100ms, 1s, or 5s.
Type: string
Default: 1s
backoff.max_elapsed_time
The maximum period to wait before retry attempts are abandoned. If zero then no limit is used.
Type: string
Default: 30s
batching
Allows you to configure a batching policy.
Type: object
# Examples:
batching:
byte_size: 5000
count: 0
period: 1s
# ---
batching:
count: 10
period: 1s
# ---
batching:
check: this.contains("END BATCH")
count: 0
period: 1m
batching.byte_size
An amount of bytes at which the batch should be flushed. If 0 disables size based batching.
Type: int
Default: 0
batching.check
A Bloblang query that should return a boolean value indicating whether a message should end a batch.
Type: string
Default: ""
# Examples:
check: this.type == "end_of_transaction"
batching.count
A number of messages at which the batch should be flushed. If 0 disables count based batching.
Type: int
Default: 0
batching.period
A period in which an incomplete batch should be flushed regardless of its size.
Type: string
Default: ""
# Examples:
period: 1s
# ---
period: 1m
# ---
period: 500ms
batching.processors[]
A list of processors to apply to a batch as it is flushed. This allows you to aggregate and archive the batch however you see fit. Please note that all resulting messages are flushed as a single batch, therefore splitting the batch into smaller batches using these processors is a no-op.
Type: processor
# Examples:
processors:
- archive:
format: concatenate
# ---
processors:
- archive:
format: lines
# ---
processors:
- archive:
format: json_array
credentials
Optional manual configuration of AWS credentials to use. More information can be found in Amazon Web Services.
Type: object
credentials.from_ec2_role
Use the credentials of a host EC2 machine configured to assume an IAM role associated with the instance.
Type: bool
credentials.secret
The secret for the credentials being used.
|
This field contains sensitive information that usually shouldn’t be added to a configuration directly. For more information, see Manage Secrets before adding it to your configuration. |
Type: string
credentials.token
The token for the credentials being used, required when using short term credentials.
Type: string
json_map_columns
A map of column keys to field paths pointing to value data within messages.
Type: string
Default: {}
# Examples:
json_map_columns:
user: path.to.user
whole_document: .
# ---
json_map_columns:
"": .
max_in_flight
The maximum number of messages to have in flight at a given time. Increase this to improve throughput.
Type: int
Default: 64
max_retries
The maximum number of retries before giving up on the request. If set to zero there is no discrete limit.
Type: int
Default: 3
string_columns
A map of column keys to string values to store. This field supports interpolation functions.
Type: string
Default: {}
# Examples:
string_columns:
full_content: ${!content()}
id: ${!json("id")}
title: ${!json("body.title")}
topic: ${!meta("kafka_topic")}
tcp
Configure TCP socket-level settings to optimize network performance and reliability. These low-level controls are useful for:
-
High-latency networks: Increase
connect_timeoutto allow more time for connection establishment -
Long-lived connections: Configure
keep_alivesettings to detect and recover from stale connections -
Unstable networks: Tune keep-alive probes to balance between quick failure detection and avoiding false positives
-
Linux systems with specific requirements: Use
tcp_user_timeout(Linux 2.6.37+) to control data acknowledgment timeouts
Most users should keep the default values. Only modify these settings if you’re experiencing connection stability issues or have specific network requirements.
Type: object
tcp.connect_timeout
Maximum amount of time a dial will wait for a connect to complete. Zero disables.
Type: string
Default: 0s
tcp.keep_alive.count
Maximum unanswered keep-alive probes before dropping the connection. Zero defaults to 9.
Type: int
Default: 9
tcp.keep_alive.idle
Duration the connection must be idle before sending the first keep-alive probe. Zero defaults to 15s. Negative values disable keep-alive probes.
Type: string
Default: 15s
tcp.keep_alive.interval
Duration between keep-alive probes. Zero defaults to 15s.
Type: string
Default: 15s
tcp.tcp_user_timeout
Maximum time to wait for acknowledgment of transmitted data before killing the connection. Linux-only (kernel 2.6.37+), ignored on other platforms. When enabled, keep_alive.idle must be greater than this value per RFC 5482. Zero disables.
Type: string
Default: 0s