Hi @AnkitaaMishra ,
It is always exciting to bridge the gap between two clouds! @wardy912 shared some excellent official documentation, but coming from an Azure background, there are a few architectural "gotchas" you should be aware of when designing for AWS.
Here are the key patterns I have seen in the field:
1. The Connectivity Challenge (VPC vs. Public) Unlike Azure SQL where "Allow Azure Services" is a simple checkbox, AWS resources (Redshift, RDS, Athena) are often locked inside a private VPC.
The Architecture: You will likely need to deploy an On-Premises Data Gateway onto an EC2 instance inside that same VPC (or peered VPC). Power BI Service treats private AWS resources just like "On-Prem" data.
Performance: Make sure that EC2 instance has enough RAM if you are doing heavy mashups in Power Query, as the data has to pass through that node.
2. Amazon Athena (The Serverless Trap) Athena is fantastic for querying S3 data directly, similar to Serverless SQL Pool in Synapse.
Cost Warning: If you use DirectQuery with Athena, every visual interaction scans data on S3 and you get billed by AWS for data scanned. It can get expensive quickly.
Best Practice: Prefer Import Mode for Athena unless you need real-time data, or enforce strict partition filtering in your SQL queries to minimize scanning costs.
3. Amazon Redshift This is the closest experience to Azure Synapse. The native Redshift connector is mature and supports SSO (Single Sign-On) via Microsoft Entra ID (formerly Azure AD) if configured correctly on the AWS side. This is great for Row-Level Security (RLS).
In summary, plan your Gateway Strategy first. That is usually the piece that surprises Azure architects the most when moving to AWS data sources.
Hope this helps with your design!
If my response resolved your query, kindly mark it as the Accepted Solution to assist others. Additionally, I would be grateful for a 'Kudos' if you found my response helpful.
This response was assisted by AI for translation and formatting purposes.
