Ntombizakhona Mabaso

for AWS Community Builders

Posted on Feb 1

Design Secure Access To AWS Resources

#aws #certification #cloud #solutionsarchitect

Exam Guide: Solutions Architect - Associate
🛡️ Domain 1: Design Secure Architectures
📘 Task Statement 1.1

🎯 Secure access means you can clearly answer:

1 Who is trying to access AWS?

2 What are they allowed to do?

3 Where are they allowed to do it (which account / which resources)?

4 How are they proving it’s really them (password, MFA, federation)?

5 How long should that access last (temporary vs long-term)?

This task is mostly about identity + permissions + multi-account setup.

Knowledge

1 | Access Controls And Management Across Multiple Accounts

As a company grows, a single AWS account gets messy:

Too many people and teams in one place
Permissions become inconsistent and hard to audit
Mistakes have a bigger blast radius
Separating dev/test/prod becomes harder

A multi-account strategy helps you isolate workloads (dev/prod), apply security rules consistently, and reduce risk.

Common Patterns

Pattern	What it solves	Beginner way to think about it
AWS Organizations + Organizational Units (OUs)	Managing many accounts as one family	A folder system for accounts + shared rules
AWS Control Tower	Setting up multi-account the standard way	A guided setup for a secure multi-account environment
SCPs (Service Control Policies)	Guardrails across accounts	“Even admins can’t do this” rules

SCPs do not grant permissions. They only set the maximum allowed actions in an account/OU. You still need IAM permissions to allow anything.

2 | AWS Federated Access And Identity Services

IAM & IAM Identity Center

Instead of creating an AWS username for every employee, many organizations use federation so people sign in with their existing company login.

IAM (Identity and Access Management): the core permissions engine, which has _users, groups, roles and policies _
IAM Identity Center (AWS SSO): central sign-in for workforce access across accounts, which is best when you have multiple accounts and want one place to manage access

Simple Comparison

Option	Best for	Why it’s safer
IAM Users (long-term)	Small/simple setups, limited cases	Works, but passwords/keys can spread and are harder to manage safely
Federation / IAM Identity Center	Teams, companies, multiple accounts	Central login, easier offboarding, fewer long-term credentials

Prefer roles + federation for humans, and avoid creating lots of IAM users with long-term credentials.

3 | AWS Global Infrastructure

Regions & Availability Zones

This shows up in access design because:
Some services are global: identity or permissions concepts apply broadly
Many resources are regional: they “live” in a Region

Your access rules may include where actions are allowed, for example:

“Only allow deployments in eu-west-1” or “Deny creating resources outside approved Regions”

4 | AWS Security Best Practices

Principle of least Privilege

Least privilege means:
1 Don’t give “admin” unless it’s truly needed

2 Grant only the actions required for the job

3 Limit access to specific resources, avoid Resource: "*"

Examples

Too open	Better
Can do anything in S3	Can read objects only in this bucket/folder
Can manage all EC2	Can start/stop only these instances

If you see broad permissions like Action: "*", the “best answer” is usually narrower permissions + conditions.

5 | The AWS Shared Responsibility Model

Security is Shared:

AWS secures the cloud infrastructure: the underlying platform
You secure your configuration and access: identity, permissions, data protection

AWS vs The Customer

AWS	Customer
Physical data centers, hardware	IAM permissions (who can access what)
Underlying service infrastructure	Your settings, encryption choices, network exposure
Availability of AWS services	Your architecture decisions (multi-AZ, backups, DR)

Skills

A | Apply Best Practices To IAM Users And Root Users

Multifactor Authentication (MFA)

The root user is the account’s master key.

Enable MFA on root
Don’t use root for daily work
Use roles or controlled identities for admin tasks

If a scenario says “root user used daily,” the fix is almost always: enable MFA and stop daily root usage.

B | Design A Flexible Authorization Model That Includes Users, Groups, Roles And Policies

1 Policies: the permission rules

2 Roles: job hats you wear temporarily

3 Users: individual logins
4 Groups: attach permissions to many IAM users at once

Humans: sign in via Identity Center / federation → assume roles
Apps/services: use roles because you don’t and should not store access keys in code.

C | Role-based Access Control Strategy

Role-based access control means you get access by assuming a role, not by permanently being an admin.

AWS STS (Security Token Service):

Issues temporary credentials
Reduces long-term secret exposure
Enables clean cross-account access

Cross-account Access

Users in Account A assume a role in Account B
No shared passwords
No copying access keys between accounts

D | Multi-Account Security Strategy

Control Tower & Service Control Policies

This is about controlling many accounts consistently:

Use a structured account layout (prod/dev/security)
Apply org-wide guardrails with SCPs
Keep shared security functions isolated

SCP Mindset

IAM Policies: what a principal can do
SCPs: what an account is ever allowed to do

So effective permissions are:

Allowed by IAM AND not blocked by SCP

E | Determine Appropriate Use of Resource Policies

Some services support resource-based policies, policy attached directly to the resource.
Common Examples:

S3 buckets,
SQS queues,
SNS topics,
KMS keys,
Lambda functions.

Resource policies are often used for:

Cross-account access to a bucket or queue or topic
Service-to-service permissions
Enforcing conditions like “HTTPS only”

Decision Table

You’re trying to…	Best tool
Give a user/role permissions generally	Identity-based policy (IAM policy)
Control access directly on the resource	Resource-based policy
Allow cross-account access cleanly	Often role assumption + sometimes a resource policy (depends on service)

F | Decide When To Federate A Directory Service With IAM Roles

Federation is ideal when:

People already have company accounts such as Google Workspace, Okta, Azure AD, AD, etc.
You want easy onboarding and offboarding
You want fewer long-term IAM users

Workforce (employees/contractors): federation / IAM Identity Center

Workloads (apps/services): IAM roles

Cheat Sheet

Scenario	Direction
Many AWS accounts	Organizations / Control Tower + SCPs
Employees use corporate login	Federation / IAM Identity Center
Third party needs access	Cross-account role + temporary credentials (STS)
Avoid storing keys in code	Use roles (temporary credentials)
Restrict actions across the org	SCP guardrails
Grant access to a specific resource	Resource-based policy (or resource policy + role)

Recap Checklist ✅

If you can explain these ideas in simple terms, you are well prepared for Task Statement 1.1:

1. [ ] The root user is protected with MFA and not used for daily work

2. [ ] IAM roles are preferred over long-term IAM users

3. [ ] Least privilege is applied: only needed actions, only needed resources
4. [ ] Multiple AWS accounts are managed centrally

5. [ ] Cross-account access uses role assumption: temporary credentials
6. [ ] Workforce access uses federation or IAM Identity Center

7. [ ] You understand when to use identity-based vs resource-based policies

AWS Whitepapers and Official Documentation

These are the primary AWS documents behind Task Statement 1.1.

You do not need to memorize them, use them to understand why AWS security works the way it does.