These notes were written while working through the A Cloud Guru AWS Certified Solutions Architect - Associate online course. These notes are partly from the videos, and also from various other online sources. Primarily, they’re notes for me, but you might find them useful too.

Since the AWS platform is changing so quickly, it’s possible that some of these notes may be out of date, so please take that into consideration if you are reading them.

Please let me know in the comments below if you have any corrections or updates which you’d like me to add.

IAM (Identity and Access Management)


  • Gives you centralised control of an AWS account
  • Is global - there is no concept of regional IAM at this time; all users, groups, policies, etc are available in all regions.
  • Supports Identity Federation which can be used for Single Sign-on i.e. via SAML
  • Can be used to give temporary access

IAM consists of Users, Groups Roles, and Policy Documents


Are the individual accounts.

By default, new users don’t have access to any AWS services.

Always set up MFA (Multifactor Authentication) on your root account.

IAM can be used to create and customise password rotation policies.

There are two ways to access AWS:

  • Username + Password
  • Access Key ID + Secret Access Key

Username and Password

  • Cannot be used to interact with the API
  • Can be used to sign in via a custom sign-in link which you can create via the IAM console i.e.

AWS sample policy document

Access Key ID and Secret Access Key

  • Assigned on user creation
  • Can be used to interact via the AWS command line, SDKs, or APIs.
  • Not the same as Username and Password.
  • Can only be viewed once. If you lose them, they need to be regenerated. Save them in a secure location.


Are a collection of IAM users, simplifying the assigning of permissions. i.e. you can have groups for different departments such as Sales, Developers, HR, etc, which may all require different levels of AWS access.

  • A user can belong to multiple groups
  • Groups cannot belong to other groups


You can create roles, then assign them to AWS resources.

i.e. you might have an EC2 instance, and give it a role saying it can access S3. That way the EC2 instance can directly access S3 without having to manage usernames, passwords, etc.

Limited to 500 IAM roles under your AWS account. The course states up to 250.

Role types:

  • AWS Service
  • Another AWS Account (allows entities in other accounts to perform actions in the current account)
  • Web Identity (Amazon, Cognito, Facebook, Google)
  • SAML / OpenID Connect

Policy Documents

An IAM policy is a document which formally defines permissions, and can be attached to users, groups, and roles.

The “ PowerUserAccess” policy provides full access to AWS services and resources, but does not allow management of users and groups.

For example, here’s one of the default AWS policy documents for assigning full access to S3:

AWS sample policy document

STS (Secure Token Service)

STS is used for requesting temporary, limited-privilege credentials for AWS IAM users or for federated users which you authenticate.

Supports the following sources:

  • Federation (typically Active Directory)
    • Uses SAML
    • Allows you to use credentials from another provider (i.e. Active Directory) - does not need to be IAM credentials
    • Does not need to be a user in IAM, or need any IAM credentials
  • Federation with mobile apps
    • Using Facebook/Amazon/Google or other OpenID provider to log in
  • Cross-account access - allowing users from AWS account to access resources in another

To use STS Federation, you must implement the following steps in the following order:

  • Develop an Identity Broker to communiate with LDAP (Lightweight Directory Access Protocol, one of the protocols that you can use to talk to Active Directory) and STS
  • Identity Broker always authenticates with LDAP first, THEN with AWS STS
  • Application then gets temporary access to AWS resources