Option A is the most cost-effective because it enables seamless integration by allowing analysts to access and join external relational data directly from within Amazon Redshift for reporting, without building and operating a separate ingestion pipeline for a one-time (annual) workload. The study material frames Amazon Redshift as the centralized analytics store for complex queries and reporting, making it the natural place to perform the final transformations and analysis.

The alternatives introduce extra operational steps and recurring costs. Option B requires exporting large historical datasets to S3 and then loading them into Redshift, which increases data movement and operational complexity. Option C adds ETL job development, scheduling, retries, and monitoring overhead that is unnecessary if the primary goal is integrated querying for an annual report. Option D (DMS) is best when you need ongoing migration or continuous replication; it is typically more operationally heavy than needed for “query across sources” use cases and still requires additional setup and maintenance.

Because all databases are already in the same VPC and the analytics platform is Redshift, federated querying provides the most direct, lowest-operations path to integrate and analyze the data where it already needs to be consumed.