AWS Training
Modules Listen Certification

← Data Sources and Connectivity

Starts this lesson and continues through 23 more to the end of the course.

The AWS-managed sources — Athena, S3, and the two roles

The authorization model nobody explains

Connecting Quick Sight to MySQL is symmetric: you give it a host, a port, a username, a password. Connecting it to Athena or S3 is not. There's no password. Instead, Quick Sight assumes IAM roles in your account, and an account-level allowlist decides which AWS services those roles may touch.

That allowlist lives at Manage Quick → Security & permissions → QuickSight access to AWS services (console path verbatim from Accessing AWS resources, verified 2026-08-16). Checking a box there is not decoration — it edits IAM policies on the service roles. Which is why the failure modes in this lesson are IAM failure modes wearing a BI costume.

Administering that screen itself requires IAM actions (verbatim from the same page): quicksight:AccountConfigurations (default resource access) and quicksight:ScopeDownPolicy (scoping policies). You can also bring your own roles ("Passing IAM roles to Amazon Quick" — security-create-iam-role.html), which pairs with the RoleArn fields you saw in lesson 2.

The two roles

From Insufficient permissions when using Athena (verified 2026-08-16), verbatim:

"For Amazon Athena, Amazon S3, and Athena Query Federation connections, Quick Sight uses the following IAM role by default: arn:aws:iam::<account-id>:role/service-role/aws-quicksight-s3-consumers-role-v0 If the aws-quicksight-s3-consumers-role-v0 is not present, then Quick Sight uses: arn:aws:iam::<account-id>:role/service-role/aws-quicksight-service-role-v0"

This fallback is the fact to carry out of this lesson. Two accounts, same checkbox settings, different behavior — because one has the s3-consumers role and the other doesn't. Every Athena-permissions investigation starts with: which of the two roles actually exists here?

aws iam get-role --role-name aws-quicksight-s3-consumers-role-v0   # 1st: does it exist?
aws iam get-role --role-name aws-quicksight-service-role-v0        # the fallback
aws iam list-attached-role-policies \
  --role-name aws-quicksight-s3-consumers-role-v0                  # then: what can it do?

If the consumers role exists, it is what needs S3/Athena/KMS access for those connections — policies attached to the fallback role won't help. Fixes applied to the wrong role of this pair are a rich source of "we already granted that" support cases.

A third role from lesson 2 completes the set: aws-quicksight-secretsmanager-role-v0, created when an admin grants secret access. Three roles, three jobs; none of them interchangeable.

The Athena "insufficient permissions" runbook

The troubleshooting page prescribes, in order (paraphrased from the verified steps):

  1. Re-grant bucket access. Security & permissions → AWS resources → find Athena, uncheck it, re-check it, "Connect both", then select the S3 buckets — including the Athena workgroup's query-results bucket, not just the data bucket. Athena needs read on the data and write/read on results; the results bucket is the one everybody forgets.

  2. KMS. If the data is encrypted with a KMS key, the Quick Sight role needs to decrypt it. Verbatim command from the page:

    aws kms create-grant \
      --key-id <AWS KMS key ARN> \
      --grantee-principal <Your Amazon QuickSight Role ARN> \
      --operations Decrypt
    

⚠️ The bucket checkboxes are shared account-wide state. The page warns, verbatim: "Be careful that you don't inadvertently disable a bucket that someone else uses." Unchecking a bucket while fixing your dashboard breaks every other team's datasets reading it — arguably the most effective friendly-fire mechanism in the whole service.

⚠️ Also from the accessing-data-sources page: if one of the managed policies is edited by hand in IAM, the console locks you out of the whole screen with "This policy used by Amazon Quick for AWS resource access was modified outside of Amazon Quick…" — the fix it prescribes is for an admin to delete the named policy and reload Security & permissions. Budget for the panic that "just delete the policy" causes in a locked-down account.

RDS and Redshift

The same Security & permissions screen governs RDS and Redshift enablement, and the parameter shapes from lesson 2 (RdsParameters.InstanceId, RedshiftParameters.ClusterId + IAMParameters) are the API face of it. Two practical notes, both anchored to pages already cited:

Check yourself

  1. Athena queries fail from Quick Sight with "insufficient permissions", but the data-lake bucket is definitely granted. What's the classically forgotten bucket?
  2. Both service roles exist in the account. You attach an S3 policy to aws-quicksight-service-role-v0 and nothing changes for Athena connections. Why?
  3. What does the checkbox screen actually modify when you toggle a service?
  4. An admin "cleaned up" a AWSQuickSightS3Policy in IAM directly. What happens to the Security & permissions screen, and what's the documented fix?
  5. Write the command that lets Quick Sight decrypt KMS-encrypted Athena data.
Answers
  1. The Athena workgroup's query-results bucket. Athena writes results there and Quick Sight must read them; granting only the data bucket fails.
  2. Because when aws-quicksight-s3-consumers-role-v0 exists, it — not the fallback service role — is used for Athena/S3/Athena Federation connections. The policy went to the wrong role.
  3. IAM policies attached to the Quick Sight service roles. The console is an IAM policy editor in disguise.
  4. The screen refuses to manage the modified policy ("modified outside of Amazon Quick"). The documented fix: delete that IAM policy and reload Security & permissions.
  5. aws kms create-grant --key-id <key ARN> --grantee-principal <QuickSight role ARN> --operations Decrypt

Teaching this section

← PreviousCreating data sources through the APINext →VPC connections — how the packets actually move