AWS / Guide 1

Getting started

AWS Tools for PowerShell, signing in with IAM Identity Center, working across accounts and regions, and AWS Config queries.

Everything in these AWS notes can be done in the console, but repeatable work belongs in scripts. This guide sets up the AWS Tools for PowerShell, explains how sign-in, profiles, accounts and regions work, and shows the two services that make reporting across many accounts practical: AWS Config advanced queries and AWS Resource Explorer.

About the example names

All examples use one test environment. Replace the names with your own. The full list is on the example environment page.

Hands-on examples for 58 AWS services (CloudFormation templates, CLI scripts, Terraform and SDK samples) are on aws.ravindran.in. These notes are the operations side: how to run what those examples build. Each guide ends with the examples that go with it.

Tip 1 – Pick your tool

Tip 2 – Install the modules you need

Use the modular AWS.Tools packages (one module per service), not the old single AWSPowerShell module. They load faster, and the installer keeps them on the same version.

Install-Module AWS.Tools.Installer -Scope CurrentUser
Install-AWSToolsModule AWS.Tools.EC2, AWS.Tools.S3, AWS.Tools.IdentityManagement, AWS.Tools.SecurityToken, `
    AWS.Tools.SSO, AWS.Tools.SSOOIDC, AWS.Tools.ConfigService -CleanUp

# Later: update everything together
Update-AWSToolsModule -CleanUp

Version 5 of the tools (June 2025) changed a few behaviours that matter in scripts: empty lists now come back as $null instead of an empty collection, every list cmdlet pages through all results by default, and -PassThru is replaced by -Select. Wrap results in @() before counting them and your scripts work on both versions.

Tip 3 – Sign in with IAM Identity Center

Don't create IAM users with access keys for people. Sign in through IAM Identity Center and let the tools get short-lived credentials. The easiest way to create the profile is the CLI's wizard; PowerShell reads the same profile file.

# One-time: create the profile (asks for the portal URL, region, account and role)
aws configure sso --profile notes-test

# Each session: sign in through the browser, then use the profile
Invoke-AWSSSOLogin -ProfileName notes-test
Set-AWSCredential -ProfileName notes-test
Set-DefaultAWSRegion -Region us-east-1

# Who am I, and in which account?
Get-STSCallerIdentity

If you'd rather stay in PowerShell, Initialize-AWSSSOConfiguration creates the same profile. Either way, the credentials last as long as the session duration set on the permission set (one hour by default), and nothing long-lived is stored on your machine.

Tip 4 – Loop over accounts and regions

Most AWS services are regional: Get-EC2Instance only shows the region you ask for. Forgetting that is how instances in ap-south-1 run for a year unnoticed. Loop over the enabled regions, and over one profile per account:

$profiles = 'notes-test', 'notes-prod'          # one Identity Center profile per account
foreach ($p in $profiles) {
    Set-AWSCredential -ProfileName $p
    $account = (Get-STSCallerIdentity).Account
    $regions = (Get-EC2Region -Region us-east-1).RegionName   # regions enabled in this account
    foreach ($r in $regions) {
        $instances = @((Get-EC2Instance -Region $r).Instances)
        if ($instances.Count) { '{0} {1}: {2} instance(s)' -f $account, $r, $instances.Count }
    }
}

Global services (IAM, Organizations, Route 53, CloudFront) don't take a region; call them once per account. S3 lists every bucket from any region, but each bucket's settings are read from the bucket's own region.

Tip 5 – Query everything with AWS Config

Looping over every region and account works, but it's slow. If AWS Config is recording (and it should be; see Guide 3), you can query the configuration of every resource with SQL-like advanced queries, and across the whole organisation through an aggregator:

# EC2 instances by type in this account and region
Select-CFGResourceConfig -Expression "SELECT configuration.instanceType, COUNT(*)
  WHERE resourceType = 'AWS::EC2::Instance' GROUP BY configuration.instanceType" |
  ForEach-Object { $_ | ConvertFrom-Json }

# Unattached EBS volumes across every account and region in the organisation
Select-CFGAggregateResourceConfig -ConfigurationAggregatorName 'org-aggregator' -Expression "SELECT accountId, awsRegion,
  resourceId, configuration.size WHERE resourceType = 'AWS::EC2::Volume' AND configuration.state.value = 'available'" |
  ForEach-Object { $_ | ConvertFrom-Json }

AWS Resource Explorer is the other option: a free search index of resources across regions (and the organisation), good for "where is that bucket?" questions from the console. Config is better for reports because it knows each resource's settings.

Tip 6 – Use roles for automation

Scheduled scripts shouldn't use your sign-in or an IAM user's access keys. Run them where AWS provides credentials automatically:

• On EC2: an instance profile (an IAM role attached to the instance). The tools pick the credentials up with no configuration.
• In Lambda or Systems Manager Automation: the function's or runbook's execution role.
• In a CI/CD pipeline outside AWS (GitHub Actions, Azure DevOps): an IAM role trusted through OIDC federation, not stored keys.
• Across accounts: a read-only role in each account (deployed with CloudFormation StackSets) that the automation account can assume.

Tip 7 – Keep a transcript, and use -WhatIf

Start-Transcript -Path ".\aws-$(Get-Date -Format yyyyMMdd-HHmm).log"
.\Invoke-AwsEC2PowerSchedule.ps1 -Action Stop -WhatIf   # see what it would do
Stop-Transcript

Every script on this site that changes something supports -WhatIf. Reports are read-only and need only the ReadOnlyAccess (or ViewOnlyAccess plus SecurityAudit) permission set.

Examples to try

From aws.ravindran.in: AWS CLI and API techniques (filters, JMESPath queries, jq, waiters), STS for assuming roles, and S3 PowerShell scripts.