AWS Governance Guardrails

AWS Governance Guardrails

Purpose

This skill encodes organizational governance and compliance rules for AWS operations. It defines what must always be done, what must never be done, and how to validate compliance.

When to Use

• Validating any AWS operation before execution
• Planning new resources or changes
• Auditing existing resources
• Training new team members on policies

When NOT to Use

• Emergency break-glass situations (document exception, review after)
• Explicit management-approved exceptions (document decision)

Policy Categories

Never Do Policies

Security - Critical

### NEVER: Public S3 Buckets for Sensitive Data
- Do not create S3 buckets with public read/write
- Do not disable Block Public Access for data buckets
- Exception: Intentionally public static content (requires documented approval)

### NEVER: Wildcard IAM Permissions
- Do not use "Action": "*" in IAM policies
- Do not use "Resource": "*" without conditions
- Do not use "NotAction" without careful scoping

### NEVER: Root Account Usage
- Do not use root credentials for operations
- Do not create access keys for root
- Exception: Account recovery and specific console-only tasks

### NEVER: Long-Lived Credentials in Code
- Do not commit AWS access keys to repositories
- Do not embed credentials in application code
- Do not store credentials in environment variables long-term
- Use: IAM roles, Secrets Manager, Parameter Store

### NEVER: Unencrypted Sensitive Data
- Do not store PII/sensitive data without encryption
- Do not transmit sensitive data over unencrypted channels
- Do not use deprecated encryption (MD5, SHA1 for security)

### NEVER: Open Security Groups
- Do not allow 0.0.0.0/0 to SSH (22)
- Do not allow 0.0.0.0/0 to RDP (3389)
- Do not allow 0.0.0.0/0 to database ports (3306, 5432, 1433, etc.)

Operations - Critical

### NEVER: Direct Production Changes
- Do not modify production via AWS Console for infrastructure
- Do not run ad-hoc AWS CLI commands that mutate production
- Use: CI/CD pipelines, Infrastructure as Code

### NEVER: Skip Change Management
- Do not deploy to staging/production without change ticket
- Do not bypass approval workflows
- Do not deploy during change freeze without emergency approval

### NEVER: Delete Without Backup
- Do not terminate production instances without AMI/snapshot
- Do not delete databases without verified backup
- Do not empty S3 buckets without lifecycle consideration

### NEVER: Skip Plan-Execute Workflow
- Do not execute any state-changing operation without presenting a plan first
- Do not delegate mutations to sub-agents before user approval
- Do not treat tagging, config changes, or "fixes" as exempt from the workflow
- Exception: None. All state changes require explicit approval.

AI/Agent Services - Critical

### NEVER: Unrestricted Bedrock Model Access
- Do not request access to all Bedrock models — grant access per model family based on need
- Do not use wildcard model ARNs in IAM policies for bedrock:InvokeModel
- Do not invoke models without logging enabled (audit trail required)

### NEVER: Shared Agent Credentials
- Do not share IAM roles across different agent types (discovery agents vs mutation agents)
- Do not use the AgentCore execution role as the agent runtime role — these must be separate
- Do not hardcode API keys or tokens in agent container images or environment variables
- Use: AgentCore Identity (API key credentials, OAuth2 credentials) or IAM roles

### NEVER: Unmonitored Agent Sessions
- Do not deploy agent runtimes without CloudWatch logging in staging or above
- Do not deploy without session timeout configuration (prevents runaway sessions and cost)
- Do not allow unbounded session concurrency in staging or production

Cost - Important

### NEVER: Uncontrolled Spending
- Do not launch large instances without cost estimate
- Do not leave idle resources running indefinitely
- Do not skip cost tags on resources

Always Do Policies

Tagging - Mandatory

### ALWAYS: Apply Required Tags

All AWS resources MUST have:

| Tag Key | Description | Format |
|---------|-------------|--------|
| Environment | Deployment environment | sandbox, development, staging, production |
| Owner | Responsible team/person | team-name or user@domain |
| CostCenter | Cost allocation | CC-NNNN format |

Recommended additional tags:
| Tag Key | Description | Format |
|---------|-------------|--------|
| Project | Project name | project-name |
| DataClassification | Data sensitivity | public, internal, confidential, restricted |
| CreatedBy | Creation method | terraform, cdk, manual |
| ExpirationDate | For temporary resources | YYYY-MM-DD |

Security - Mandatory

### ALWAYS: Encryption

At Rest:
- Enable encryption for EBS volumes (KMS)
- Enable encryption for RDS (KMS)
- Enable encryption for S3 (SSE-S3 minimum, SSE-KMS for sensitive)
- Enable encryption for Secrets Manager, Parameter Store

In Transit:
- Use HTTPS/TLS for all external connections
- Enforce TLS 1.2 minimum
- Use SSL for database connections

### ALWAYS: Logging

Enable for all accounts:
- CloudTrail (all regions, management + data events for sensitive)
- VPC Flow Logs (all VPCs)
- S3 Access Logs (for data buckets)
- Application logging to CloudWatch

### ALWAYS: Least Privilege IAM

- Scope permissions to specific resources
- Use conditions where appropriate
- Prefer managed policies over inline
- Regular access reviews (quarterly minimum)

### ALWAYS: Network Segmentation

- Use private subnets for databases and internal services
- Implement security groups with minimal required access
- Use NACLs for additional defense in depth
- Document allowed traffic flows

Operations - Mandatory

### ALWAYS: Infrastructure as Code

- Define infrastructure in CDK, Terraform, or CloudFormation
- Store IaC in version control
- Deploy via CI/CD pipelines
- Maintain drift detection

### ALWAYS: Documentation

- Document architecture decisions
- Maintain runbooks for operations
- Keep deployment documentation current
- Record change rationale

### ALWAYS: Backup and Recovery

- Automated backups for databases
- Snapshot critical EBS volumes
- Test recovery procedures quarterly
- Document RPO/RTO for each service

Environment-Specific Policies

Sandbox

## Sandbox Environment

Permissions:
- AWS CLI mutations: Allowed
- Direct console changes: Allowed
- Approval required: None

Restrictions:
- No production data
- Budget capped at $X/month
- Resources may be auto-terminated
- No connectivity to other environments

Development

## Development Environment

Permissions:
- AWS CLI mutations: Allowed with tagging
- Direct console changes: Discouraged
- Approval required: Destructive operations only

Restrictions:
- No production data
- Budget alerts at 80%
- Scheduled scaling down after hours (optional)

Staging

## Staging Environment

Permissions:
- AWS CLI mutations: Via IaC preferred
- Direct console changes: Emergency only
- Approval required: All mutations

Restrictions:
- No production data (use anonymized)
- Configuration must match production
- Change windows may apply

Production

## Production Environment

Permissions:
- AWS CLI mutations: Prohibited (except discovery)
- Direct console changes: Emergency only with ticket
- Approval required: CAB for significant changes

Requirements:
- All changes via CI/CD pipeline
- Change ticket required
- Rollback plan documented
- Post-deployment validation

Validation Rules

Pre-Execution Checks

## Guardrail Validation Checklist

### Tagging
- [ ] Required tags present (Environment, Owner, CostCenter)
- [ ] Tag values match allowed patterns
- [ ] DataClassification if data-storing resource

### Security
- [ ] Encryption enabled (at rest)
- [ ] TLS/SSL configured (in transit)
- [ ] Security groups least-privilege
- [ ] No public access unless intentional
- [ ] IAM follows least privilege

### Network
- [ ] Correct VPC and subnet placement
- [ ] Security group rules documented
- [ ] No 0.0.0.0/0 to sensitive ports

### Compliance
- [ ] Logging enabled
- [ ] Backup configured
- [ ] Matches environment policies
- [ ] Change management followed

Automated Checks

# AWS Config Rules (examples)
- s3-bucket-public-read-prohibited
- s3-bucket-ssl-requests-only
- encrypted-volumes
- rds-storage-encrypted
- ec2-imdsv2-check
- iam-user-no-policies-check
- root-account-mfa-enabled
- cloudtrail-enabled

# Custom Rules
- required-tags-check
- security-group-ingress-check
- vpc-flow-logs-enabled

Exception Process

Requesting an Exception

## Exception Request Template

### Finding
[What policy is being excepted]

### Justification
[Why exception is necessary]

### Duration
[Temporary (with date) or permanent]

### Compensating Controls
[Alternative security measures in place]

### Risk Acceptance
[Who is accepting the risk]

### Approval
- [ ] Technical Lead
- [ ] Security Team (if security-related)
- [ ] Documented in change ticket

Exception Documentation

All exceptions must be:

1. Documented in writing
2. Approved by appropriate authority
3. Time-limited where possible
4. Reviewed periodically
5. Tracked for eventual remediation

Compliance Reporting

Regular Reviews

Compliance Metrics

## Key Compliance Indicators

- % of resources with required tags
- # of open security findings
- # of non-compliant resources
- # of active exceptions
- Mean time to remediate findings

Customization Guide

To customize this skill for your organization:

1. Update tagging requirements in the "Always Do" section
2. Add organization-specific security policies
3. Define environment-specific rules for your tiers
4. Document your exception process
5. Add compliance framework requirements (HIPAA, PCI, SOX, etc.)

Store policy details in:

• policies/iam-policies.md
• policies/network-policies.md
• policies/data-policies.md
• policies/tagging-policies.md

Related Skills

• aws-org-strategy — Organizational context
• aws-well-architected — Security pillar alignment
• aws-observability-setup — Logging requirements
• aws-cli-playbook — Validation commands

Converted and distributed by TomeVault — claim your Tome and manage your conversions.