AWS Fundamentals

Overview

AWS resources live in an account and, for regional services, a selected region made of multiple Availability Zones. The account is the fundamental billing, quota, and security isolation boundary; regions contain service endpoints, and Availability Zones provide physically separate failure domains within a region. IAM decides who can call each service API, while services such as EC2, S3, RDS, Lambda, VPC, CloudWatch, and CloudTrail provide compute, storage, databases, networking, observability, and audit history.

AWS Organizations lets many accounts be managed together: organizational units (OUs) group accounts for policy application, and Service Control Policies (SCPs) cap the maximum permissions available underneath them, on top of, never instead of, IAM policies that grant access. Tags and AWS Resource Groups provide cross-resource visibility inside an account, but they are a query mechanism rather than an ownership or deletion boundary.

Quick Reference

The commands below are grouped by service, not an exhaustive reference (see the official AWS CLI command reference for every flag), but the set that covers nearly all day-to-day aws CLI work.

Syntax

aws organizations create-organizational-unit \
  --parent-id r-abcd --name Production

aws organizations create-account \
  --email prod-payments@example.com --account-name payments-prod

Examples

scp-deny-outside-approved-regions.json, an SCP that caps every identity in the attached OU to two approved regions, no matter what their own IAM policy allows:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["us-east-1", "eu-west-1"] }
      }
    }
  ]
}

Troubleshooting AWS CLI and Access

I start every investigation by proving the caller, account, and region:

aws configure list --profile production
aws sts get-caller-identity --profile production
aws configure get region --profile production

Then I I classify the failure:

1. Authentication or session: if the CLI cannot load credentials or reports an expired token, run aws sso login --profile <name> and retry with the profile explicitly selected.
2. Wrong context: compare the returned account ID, assumed-role ARN, and region with the resource ARN. A successful command against the wrong account or region often looks like a missing resource.
3. Authorization: read the entire AccessDenied message. Effective permission is the intersection of applicable identity policies, resource policies, permissions boundaries, session policies, and Organizations SCPs; an explicit deny overrides an allow.
4. Service boundary: if identity is correct and authorization allows the action, check service quotas, resource state, region support, and the service's own logs or events. I use CloudTrail event history and the request ID from the error to establish who called which API.

get-caller-identity is intentionally useful during failures: AWS STS returns the caller identity even when an explicit deny applies to that action. I do not debug access by attaching AdministratorAccess; identify the missing allow or explicit deny at the correct policy layer.

Visual Diagram

Common Mistakes

• Assuming AWS Resource Groups behave like an Azure resource group, a deletion/lifecycle boundary, when they're really just a saved tag-based query with no ownership semantics.
• Running an entire company, production included, out of a single AWS account instead of separating environments and teams by account.
• Writing an SCP and expecting it to grant access, then being confused when everything underneath it still returns access denied without a matching IAM allow.
• Assuming an org-wide SCP also restricts the management account itself; SCPs only ever apply to member accounts, never to the management account.
• Debugging with an implicit default profile or region, then changing permissions in an account that the failing command was not actually using.
• Creating long-lived IAM user access keys for people when IAM Identity Center can provide short-lived CLI sessions.
• Skipping AWS Organizations and centralized logging entirely, leaving no org-wide guardrail against an individual account drifting out of compliance.

Performance

• SCP evaluation happens alongside normal IAM policy evaluation and adds no meaningful latency, the real cost is organizational complexity if the OU/SCP structure isn't kept simple.
• Account creation and OU membership changes through AWS Organizations are eventually consistent, propagation to all regions/services can take a few minutes, don't assume it's instantaneous.

Best Practices

• Separate accounts by environment (production, staging, development) and by team or workload boundary, using AWS Organizations to manage them centrally rather than tags inside one account.
• Apply SCPs at the OU level for guardrails that should apply organization-wide (approved regions, disallowed services), rather than repeating them per account.
• I use a dedicated management account for billing/Organizations and a separate log-archive account for centralized CloudTrail logs, following the landing-zone pattern instead of overloading one account with every responsibility.
• Restrict access to the Organizations management account, keep workloads out of it, and delegate supported administration to member accounts.
• I use IAM Identity Center and short-lived role sessions for human CLI access; reserve IAM user access keys for exceptional legacy cases with an explicit rotation plan.
• I use tags and AWS Resource Groups for cross-resource visibility and cost allocation within an account, not as a substitute for real account-level isolation.
• Continue into AWS IAM, AWS Compute, AWS Storage, AWS Networking, and AWS Monitoring for service-specific depth.