What this gives you
- Faster Incident Response The core motivation is to grant Aspect engineers scoped access, which “greatly aids in speeding up investigations.”
- Default Alert Routing Workflows automatically sets up the credentials and routing necessary to send system alerts to Aspect upon the initial Terraform apply. Customers must explicitly opt-out if they don’t want alerts routed to Aspect.
- Strictly Scoped Access Any access granted to Aspect engineers via the defined roles is “strictly scoped to the resources Workflows creates and owns.”
Support role hierarchy
Aspect provides a tiered system of roles that define the level of access granted to its on-call engineers, ranging from read-only to co-maintainer capabilities.| Role | Access Level | Purpose & Key Permissions - AWS Examples |
|---|---|---|
| Support Role | Read-Only Access | Speeds up investigations during incidents. Allows Read/List on Systems Manager parameters, Describe on Auto Scaling Groups (ASGs), and Get on log streams with the aw_ prefix. |
| Operator Role | Read + Limited Write Access | A superset of the Support role. Allows management of EC2 hosts for rebooting/terminating and management of the Redis cache for update/delete/snapshot. It also allows Systems Manager access to running instances and port forwarding for Grafana, but is off by default. |
| Co-maintainer Role | Superset of Support & Operator | GCP only. Provides the highest level of access, allowing Aspect engineers to apply the Terraform workspace for your installation. |
Access management for Aspect engineers
Access request approval manages membership in the various levels of roles for on-call support, ensuring controlled access.- No Bazel CI on-call. Aspect handles the pages so your engineers don’t have to.
- Scoped access. Aspect’s on-call only sees Workflows-managed resources, never anything outside the module’s boundary.
- Auditable in your own cloud. Every Aspect action is logged in your AWS CloudTrail or GCP audit log; the trail is yours.