Skip to content

Configure Amazon DynamoDB reminders

Install the Microsoft.Orleans.Reminders.DynamoDB package and call UseDynamoDBReminderService on every silo.

A silo which uses DynamoDB for both membership and reminders configures the providers independently:

siloBuilder
.Configure<ClusterOptions>(options =>
{
options.ClusterId = "production";
options.ServiceId = "my-application";
})
.UseDynamoDBClustering(options =>
{
options.Service = region;
options.TableName = "OrleansCluster";
options.UseProvisionedThroughput = false;
})
.UseDynamoDBReminderService(options =>
{
options.Service = region;
options.TableName = "OrleansReminders";
options.UseProvisionedThroughput = false;
options.CreateIfNotExists = false;
options.UpdateIfExists = false;
});

DynamoDBClusteringOptions and DynamoDBReminderStorageOptions are separate typed options. Set the AWS region through each options instance, as shown above. A silo which uses another membership provider configures that provider alongside UseDynamoDBReminderService.

ServiceId identifies the application’s reminder records and must remain stable across deployments that share a reminder table. Use distinct table names for cluster membership and reminders because each provider manages a different schema.

When AccessKey and SecretKey remain unset, the AWS SDK for .NET credential and profile resolution chain supplies credentials. In production, prefer workload credentials such as an IAM role over long-lived keys. ProfileName, AccessKey, SecretKey, and Token support deployment environments which require explicit SDK configuration.

The example uses on-demand capacity and an infrastructure-managed table. Set UseProvisionedThroughput to true and configure ReadCapacityUnits and WriteCapacityUnits for provisioned capacity.

CreateIfNotExists and UpdateIfExists allow the provider to create the reminder table and update its provisioned capacity. Infrastructure-managed provisioning keeps table lifecycle and capacity changes in the deployment workflow.