← Platform Foundations

▶ Play from here · 209 min

Starts this lesson and continues through 28 more to the end of the course.

Identity: the decisions you make once

The five-minute wizard you'll live with for years

Signing up takes about five minutes. In that time you choose an account name, a notification email, a Region for your SPICE capacity, and an authentication method.

Every one of those has long consequences, and the console does not warn you about any of them.

What the signup actually asks

From Signing up through the AWS Console (verified 2026-08-09), the steps are:

1. Open Quick from the AWS Management Console. "Your AWS account number is displayed for verification purposes."
2. "Enter a unique account name for Quick."
3. "Enter a notification email address for the Quick account owner or group. This email address receives service and usage notifications."
4. "Choose the AWS Region that you want to use for your initial data storage capacity, called SPICE."
5. "Choose an authentication method that you want to connect to Quick with."
6. Review, then Create account.

And the trial: "When you first sign up for Amazon Quick, you get a free trial subscription for twenty-five users for 30 days."

⚠️ Step 3 is the one people regret. That notification email receives service and usage notifications — including, in practice, the things you want to know about before your users do. Point it at a monitored distribution list, never at the individual who happened to run the wizard. When that person leaves, the notifications go with them.

⚠️ Step 4 sets the Region for your SPICE capacity, and capacity is allocated per Region (Q2, lesson 1). Getting this wrong doesn't block you — it just means the Region everyone works in has no capacity and somebody has to buy it separately later. Choose the Region your data is in.

The four authentication choices

Verbatim, the options offered:

• (Recommended) Password-based or Single-Sign On
• IAM Identity Center
• Single-Sign On Only
• Active Directory

⚠️ I could not verify from the pages fetched for this lesson whether the authentication method can be changed after account creation. The signup documentation does not say, and I am not going to guess about something this consequential. Treat it as effectively permanent until you have confirmed otherwise — and if this decision matters to your design, it is a good, narrow question to put to AWS Support before you sign up rather than after.

The decision that actually shapes your admin life

The identity choice determines whether you administer groups or individual users — and that is a much bigger deal day to day than the login experience.

From Managing user access inside Amazon Quick (verified 2026-08-09):

"For accounts that use IAM Identity Center or Active Directory, groups are assigned to Quick roles. Groups can be assigned the Admin, Author, Reader, Admin Pro, Author Pro, or Reader Pro roles."

"Amazon Quick accounts that use Quick and IAM users create users directly in Quick. These users and their roles are managed at the user level."

The opinionated take: if you have more than about twenty users, or any staff turnover at all, choose an identity-provider-backed method. User-level administration does not sound bad until you're the one auditing 300 individually-managed accounts against an HR leavers list, by hand, quarterly.

The failure mode of user-level administration is not inconvenience — it's orphaned accounts with live access to your data, discovered during an audit.

The same page confirms the mapping from lesson 2: "Reader Pro maps to Amazon Quick Professional subscription and Author Pro maps to Amazon Quick Enterprise subscription."

Permissions needed to sign up

The person running the wizard needs the right IAM permissions, and there are two documented ways this goes wrong:

"The person who signs up for Quick needs to have the correct AWS Identity and Access Management (IAM) permissions."

"check whether your AWS account is part of an organization based on the AWS Organizations service. If so and you sign in as an IAM user, make sure that you didn't inherit any IAM permissions that deny access to the required permissions."

⚠️ A Service Control Policy in AWS Organizations can block signup, and the failure will look like a permissions bug in Quick. If you're in a managed landing zone and signup fails inexplicably, check SCPs before you open a Quick support case — you'll be talking to the wrong team otherwise.

AWS suggests the IAM policy simulator to test this in advance. That's a five-minute check that can save a day.

Encryption defaults

"Your data is encrypted by default using AWS-managed keys. Admins can adjust settings for custom encryption in the admin portal after signing up."

Two things follow:

1. Encryption at rest is on by default with AWS-managed keys — you don't have to do anything to get baseline encryption.
2. Customer-managed keys are a post-signup change, made in the admin portal, and per lesson 2 that portal area is governed by IAM permissions, not the Quick admin role.

Note that Q2 lesson 1 recorded that SPICE encryption at rest is described as an Enterprise edition property. If you need CMK control, you need Enterprise and you need the IAM-side admin rights. Two prerequisites, both easy to discover too late.

The standalone path is a different product

Restating from lesson 1, because it belongs to the identity discussion: signing up at aws.com/quick uses "your email or social credentials (Google, Apple, Amazon, GitHub)" and requires no AWS account.

That is not an enterprise identity story. There is no IAM Identity Center, no Active Directory, no SCP, no IAM policy. If somebody in your organisation has been trialling on that, none of their setup transfers.

Check yourself

1. The person who ran the signup wizard has left the company. What did you probably just lose?
2. You have 300 users and heavy turnover. Which identity model, and what's the failure mode of the other one?
3. Signup fails with what looks like a permissions error in a managed AWS landing zone. Where do you look first?
4. Do you need to do anything to get encryption at rest?
5. Why is the SPICE Region choice at signup worth thinking about for more than two seconds?

Answers

1. The notification email — it receives service and usage notifications, and it was probably set to that individual. Repoint it at a monitored distribution list.
2. IAM Identity Center or Active Directory, so that roles are assigned to groups and directory changes flow through. The alternative manages users individually inside Quick, and its failure mode is orphaned accounts with live data access, found during an audit.
3. AWS Organizations Service Control Policies. An inherited deny can block the required permissions, and it will present as a Quick problem when it isn't one. Test with the IAM policy simulator.
4. No. Data is encrypted by default with AWS-managed keys. Customer-managed keys are an opt-in change made after signup — and they need Enterprise edition plus IAM-side admin rights.
5. Because it sets where your SPICE capacity is allocated, and capacity is per Region. Choose it wrong and the Region your team actually works in starts with none.

Teaching this section

• Open with the notification email. It's the smallest field on the screen and the one most likely to be wrong in the room's own account. Have people go and check theirs, live.
• Demo: the group-vs-user table, then ask "who removes a leaver's access, and how would we prove it happened?" Accounts on user-level administration rarely have a good answer.
• Good discussion: "Which of these four decisions could we reverse today?" Note honestly that the authentication method is undocumented on this point — modelling "we don't know, so we treat it as permanent" is itself the lesson.
• Watch for: treating a standalone aws.com/quick trial as evidence about enterprise identity. It carries none.
• Timing: 20 min presented, 15 discussion.