Resource ARN mismatch during Point-in-Time Recovery (PITR) restore

Amazon DynamoDB Point-in-Time Recovery (PITR) allows for the restoration of table data to a specific timestamp within a 35-day window. However, the restoration process creates a completely new table with a unique Amazon Resource Name (ARN) rather than restoring data into the existing table structure.

In environments where application configurations, IAM policies, or CloudFormation stacks are tightly coupled to a specific table ARN, this behavior introduces a synchronization gap. Since the original table remains intact and the restored table is a separate entity, the application must be manually or programmatically updated to point to the new resource.

• How can the transition to a new restored table ARN be managed without causing application downtime?
• Is there a documented method to maintain consistent IAM policy associations when the target table resource changes during a PITR event?