What is the minimum viable IAM policy for Snowplow operation?


Not that we don’t trust that our Snowplow installation won’t go rogue, but you can never be too careful with your data, right? The IAM setup page gives a rather permissive policy to get things going, but how much can it be restricted? From a very out-of-date setup, we give our snowplow_operator:

    "Action": [
    "Resource": [
    "Effect": "Allow"
    "Action": [
    "Resource": [
    "Effect": "Allow",
    "Condition": {
        "StringEquals": {
            "ec2:Region": "us-west-2"
    "Action": [
    "Effect": "Allow",
    "Resource": [
# and S3 stuff for ETL...

Is this the best we can do? Particularly the *s for EMR, Cloudwatch, and SDB seem large, with the EC2 * being marginally better in that it’s restricted to a particular region. (Note that I’m not even sure that these permissions are sufficient for late-model Snowplows, since we’re so far behind the times.)


Hi @alexc-sigfig - here is our wiki page for the Snowplow operator’s permissions: Setup IAM permissions for operating Snowplow.

Snowplow necessarily requires a lot of AWS permissions to run - it is strongly recommended to setup Snowplow in an exclusive AWS sub-account.


This is maybe more of an AWS question than a Snowplow question, but which resources need to be under the same AWS account? Can I get away with setting up a new collector and emr-etl-runner (and their associated S3 buckets) in a sub-account, but send the data into Redshift owned by another AWS account?


Yes sure - you can keep Redshift in a separate AWS account (many of our customers do).