Exploring the new AWS Sign Up experience

What it is

Analysis of AWS's new sign-up experience (branded "Project"), which replaces the root-user-first model with a Builder ID login and drops you into a restricted sandbox account rather than a full account. Beyond what the catalog summary notes, the page names the specific policies AWS silently applies and identifies logging gaps that matter for incident response.

How it works

Sign-up provisions a three-account Organization: a hidden management account, a hidden identity account, and the member (sandbox) account you get. The management account applies SCPs/RCPs to the sandbox. Access is granted via an AccountFullAccessRole whose trust policy points at the service principal account-access.amazonaws.com; you invite users through Account Access, and everyone gets admin. Login sends an email verification code every time, giving a default second factor.

Policies applied to the sandbox:

• FreeTierSCP (removed on upgrade) — a Deny-with-NotAction allowlist, which is why unlisted services (GuardDuty, SecurityHub, Detective, Inspector, Macie, Access Analyzer) are blocked; also denies s3:PutObject with the Glacier storage class and various capacity reservations.
• ManagedAccountSecurityControlPolicy (persists) — blocks leaving the Org, protects AWSManagedAccountManagementAccessRole.
• AdvancedModeRegionRestrictionSecurityControlPolicy (persists) — pins you to a single AWS region.
• A budget SCP BudgetsSpendLimitDenyNewWorkloads, triggered by a $20/month budget, denies 100+ actions (mostly compute creation); removed on upgrade.

Preconditions / Affected

Anyone creating an AWS account through the new experience. Security-relevant gaps while in the sandbox:

• No CloudTrail configured at account or Org level — only CloudTrail Event History (90 days, limited UI). AWS Config and CloudTrail are allowed but not enabled.
• S3 Public Block Access is not set at the account level (only default-on per new bucket), so a public bucket is still reachable by disabling the bucket-level setting.
• No API visibility into who has account access; you must use the settings.aws.com web UI.

What to do

The page's operative point: a real security posture requires upgrading out of the sandbox, which grants access to the previously hidden Org management account. After upgrading:

• Enable CloudTrail at the Org level (not done for you).
• Enable account-level S3 Public Access Block.
• Modify the data-perimeter RCP so vendor sts:AssumeRole works — otherwise vendors may fall back to IAM user access keys.
• Review IAM Role Manager: it attaches near-admin PowerUserAccess to console-created roles, so you must retroactively reduce privileges.

Caveats

The sandbox's goal is cost containment and simplicity, not Control Tower-style security; some defaults (default 2FA, no shared root, per-bucket public block) are genuine improvements. The author notes the allowlist strategy will silently deny future AWS service launches until AWS updates it.