Problem Statement
Amazon QuickSight licensing is costly.
We had multiple lower environments (dev, qa, pre-prod), each in separate AWS accounts. If we deployed QuickSight in every account, it would significantly increase recurring cost.
The requirement was:
-
Keep databases in their respective AWS accounts.
-
Do not expose databases publicly.
-
Maintain account isolation.
-
Enable secure cross-account access.
However:
QuickSight cannot be shared across AWS accounts. It also cannot directly access databases in other accounts without proper networking and IAM configuration. So we needed a secure cross-account solution.
What Was Tried
We evaluated a few options:
- Deploy QuickSight in each account
→ Rejected due to cost. - Expose databases publicly and restrict via IP
→ Rejected due to security risk. - Replicate data into a centralized analytics account
→ Adds operational overhead and data sync complexity. - Keep one QuickSight (in a single account) and allow it to securely access databases in other AWS accounts
→ Selected approach.
To enable this, we implemented:
-
VPC Peering between accounts
-
Cross-account IAM roles
-
Secrets Manager with KMS policies
-
Athena as the query abstraction layer
What Worked
Single QuickSight Account
We kept QuickSight deployed only in one account (Analytics Account).
This immediately reduced:
-
Licensing cost
-
Operational overhead
-
Environment duplication
VPC Peering Between Accounts
We established VPC peering between:
Analytics Account (QuickSight + Athena)
and
Environment Accounts (DocumentDB)
Configured:
-
Peering request & acceptance
-
Route table updates
-
Security group rules
-
Restricted database ports only
-
No public exposure
Result:
Private network connectivity between accounts.
Credentials Stayed in Source Account
Database credentials remained in each environment account.
Implemented:
-
KMS encryption
-
Secrets Manager secret in the DB account
-
Resource policy allowing cross-account IAM role access
-
KMS key policy permitting decrypt from specific role
This ensured:
-
No duplication of secrets
-
No hardcoded credentials
-
Least-privilege access
Athena as the Abstraction Layer
Since QuickSight cross-account direct DB connectivity is not cleanly supported, we introduced Athena in the QuickSight account.
Architecture Flow:
QuickSight
→ Athena
→ (VPC Peering)
→ DocumentDB (in other account)
Athena acts as the query layer, and QuickSight connects to Athena natively.
Benefits:
-
Centralized analytics
-
Clear separation between operational DB and BI layer
-
No public database exposure
What Didn’t Work / Challenges
-
VPC peering requires careful CIDR planning.
-
Route tables and security groups must be correctly aligned.
-
Cross-account IAM + KMS policies are sensitive to misconfiguration.
-
Debugging cross-account authentication can take time.
-
Observability across multiple accounts needs structured logging.
The most time-consuming part was aligning IAM trust policies and KMS permissions correctly.
Final Outcome / Learning
We successfully:
-
Reduced QuickSight licensing cost by centralizing it.
-
Enabled secure cross-account database access.
-
Maintained strict account isolation.
-
Avoided public exposure of databases.
-
Implemented least-privilege cross-account access.
Key learnings:
-
Cost optimization sometimes requires architectural redesign.
-
Multi-account AWS setups require deliberate IAM trust design.
-
Network connectivity alone is not sufficient — IAM and KMS alignment are critical.
-
Athena works effectively as a centralized analytics abstraction layer.
The solution balanced cost control with security and scalability.
If there are alternative approaches to reducing tool licensing costs or more efficient patterns instead of using VPC peering, please feel free to share your suggestions.
We’re open to refining this architecture further if there is a simpler, more scalable, or more cost-effective solution.