Why Alerts Are Not Enough for Teams
For an individual learner, email alerts are sufficient. For a team — even a small one — you need hard guardrails that prevent expensive actions from being taken in the first place, regardless of whether anyone reads their email.
Service Control Policies (SCPs) are AWS Organizations features that act as permission boundaries for entire accounts. Unlike IAM policies (which grant permissions to users), SCPs define the maximum permissions any identity in an account can ever have — even the root user.
Practical SCPs for Learning Environments
A learning account SCP might:
- Deny all regions except
us-east-1: Prevents accidental resource creation in expensive or unexpected regions. - Deny expensive instance types: Block
p3,p4,g4, and other GPU instance families that cost $3–$30/hour. - Deny Reserved Instance purchases: Prevents a learner from accidentally committing to a 1-year or 3-year contract.
- Deny specific services entirely: Block Amazon Redshift, EMR, or other enterprise services that have no place in a learning environment.
A typical instance-type SCP denies ec2:RunInstances unless the requested instance type matches an allowlist pattern like t2.*, t3.*, or t4g.*. Any attempt to launch a c5.4xlarge or p3.2xlarge is denied at the API level — before the instance ever starts, before any charge is incurred.
Account Isolation as a Strategy
A best practice for organizations is to use separate AWS accounts for different environments (development, staging, production). For learners, this means:
- Create a dedicated "sandbox" account for experimentation.
- Apply strict SCPs to that account.
- Set a hard monthly budget with automated stop actions.
- Never put production workloads or sensitive data in the sandbox.
AWS Organizations allows you to create member accounts at no additional cost. The sandbox account can have its own billing alerts, its own SCPs, and its own IAM users — completely isolated from any production account.