Redshift roles were a recent (2022) addition to Redshift. Prior to adding this feature Redshift groups where used for the same purpose. Redshift groups are not hierarchial in nature, a group cannot be granted to a group. But a role can be granted to a role making Redshift roles much more valuable (and inheritable) than groups. I suggest using roles, instead of groups going forward.
sys:monitor | This role has the permission to access catalog or system tables. |
sys:operator | This role has the permissions to access catalog or system tables, analyze, vacuum, or cancel queries. |
sys:dba | This role has the permissions to create schemas, create tables, drop schemas, drop tables, and truncate tables. It has the permissions to create or replace stored procedures, drop procedures, create or replace functions, create or replace external functions, create views, and drop views. Also, this role inherits all the permissions from the sys:operator role. |
sys:superuser | This role has all the supported system privileges defined in System permissions for RBAC. |
sys:secadmin | This role has the permissions to create users, alter users, drop users, create roles, drop roles, and grant roles. This role can have access to user tables only when the permission is explicitly granted to the role. |
Curtosy of AWS.
Note: the “sys:” prefix is not allowed for user defined roles.