Learn PowerShell - AWS & GCP Automation

#Introduction

After episode 27 automated Azure with PowerShell — creating resource groups, storage accounts, and VMs via Az.* cmdlets — it's time to open a wider map: AWS and GCP, the two largest clouds in the world. Both have different automation approaches. AWS provides a very mature official PowerShell module, complete with pipeline and object integration. GCP prefers a uniform command line: the Cloud SDK with gcloud. In this episode 28 you'll master both: authentication, core services — EC2, S3, IAM on AWS; Compute Engine and Storage on GCP — then close with an important decision you'll carry throughout your career: when to use a PowerShell module, when to use a CLI, and when to use an SDK.

#Getting to Know AWS Tools for PowerShell

AWS provides the official PowerShell module named AWS Tools for PowerShell, the successor to the popular AWSPowerShell.NetCore. Its most important change: modules are split per service into AWS.Tools.*. You install only the modules you use, not one giant package — like carrying a small suitcase that fits exactly, not dragging an entire wardrobe to the airport.

From PowerShell 7, installation is simply via Install-Module:

Install-Module -Name AWS.Tools.EC2 -Scope CurrentUser
Install-Module -Name AWS.Tools.S3 -Scope CurrentUser
Install-Module -Name AWS.Tools.IAM -Scope CurrentUser

#Authentication: Profiles and Credentials

Before AWS cmdlets work, you must provide identity. The three most common authentication methods:

1. Direct access keys — set the key and secret key via Set-AWSCredential in the session.
2. Profiles in the credentials file — fill ~/.aws/credentials with several named profiles, then select with the -ProfileName parameter.
3. Environment variables — AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are read automatically; best for CI/CD because secrets are never written in script files.

Example credentials file with two profiles:

[default]
aws_access_key_id = AKIA...
aws_secret_access_key = abc123...
 
[produksi]
aws_access_key_id = AKIA...
aws_secret_access_key = xyz789...

Then use it in scripts:

Set-DefaultAWSRegion -Region ap-southeast-1
Get-AWSCredential -ProfileName produksi
New-EC2Instance -ImageId ami-12345 -InstanceType t3.micro -ProfileName produksi

The pattern you must hold: credentials never live inside scripts. Profiles, environment variables, and secret managers keep credentials outside code, so scripts are safe to share, commit, and review.

#Managing EC2

EC2 is AWS's core virtual machine. With the AWS.Tools.EC2 module you run the full lifecycle — create, view, start, stop, and delete:

$image = Get-EC2Image -Owner self -Filter @{ Name = "name"; Values = "my-app-*" }
$instanceId = (New-EC2Instance -ImageId $image.ImageId -InstanceType t3.micro -KeyName my-keypair -SubnetId subnet-12345).Instances[0].InstanceId
 
Start-EC2Instance -InstanceId $instanceId
Stop-EC2Instance -InstanceId $instanceId
Get-EC2Instance -InstanceId $instanceId
Remove-EC2Instance -InstanceId $instanceId

Note the pattern: AWS cmdlets follow the naming conventions you've known since the series' early episodes — New-, Get-, Start-, Stop-, Remove-. There's no new syntax to memorize; only the objects being processed changed. Get-EC2Instance returns property-rich objects, so results can be piped straight to Select-Object or filtered in the pipeline.

#S3 Operations

S3 is object storage for files, build artifacts, and backups. Its operations are as natural as local file operations — imagine an S3 bucket as a warehouse: Write-S3Object puts items on the shelf, Get-S3Object lists the contents, Read-S3Object retrieves items:

New-S3Bucket -BucketName my-backup-bucket -Region ap-southeast-1
Write-S3Object -BucketName my-backup-bucket -Key backup.zip -File ./backup.zip
Get-S3Object -BucketName my-backup-bucket -KeyPrefix backup/
Read-S3Object -BucketName my-backup-bucket -Key backup.zip -File ./restored.zip

Because everything is .NET objects, you can aggregate directly through the pipeline — for example counting the total size of all backups:

Get-S3Object -BucketName my-backup-bucket -KeyPrefix backup/ |
    Measure-Object -Property Size -Sum

#IAM Management

IAM governs who can do what in an AWS account — users, groups, roles, and policies. Managing IAM via scripts ensures the process is consistent, repeatable, and auditable:

$user = New-IAMUser -UserName deploy-bot
New-IAMUserPolicy -UserName deploy-bot `
    -PolicyName S3ReadOnly `
    -PolicyDocument (ConvertFrom-Json '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Action":"s3:GetObject","Resource":"*"}]}')
 
Get-IAMUser

The same principle as the access-management material in earlier episodes applies here: least privilege. A deploy bot gets read access to one bucket, not the whole account's admin keys. Smaller permissions mean a smaller blast radius when something goes wrong.

#GCP: Cloud SDK and gcloud

Unlike AWS, Google doesn't provide an official PowerShell module as complete as AWS.Tools. Its official approach is the Cloud SDK — a set of command-line tools with gcloud at the center and gsutil for Storage. This choice makes sense: gcloud runs equally well from PowerShell and bash, so one skill applies across many shells.

Authentication starts with interactive login:

gcloud auth login
gcloud config set project my-project-123
gcloud auth application-default login

gcloud auth login authorizes a user account; gcloud config set project sets the default project so the --project flag needn't be written every time; and gcloud auth application-default login creates credentials for applications using client libraries — important when your scripts call Google libraries.

For automation without interactive login, create a service account — a machine identity analogous to an IAM role in AWS:

gcloud iam service-accounts create deploy-bot
gcloud iam service-accounts keys create deploy-bot.json \
    --iam-account deploy-bot@my-project-123.iam.gserviceaccount.com

Service account key files are treated like secrets: never commit them to git, limit their permission scope, and rotate regularly.

#Compute Engine

Compute Engine is GCP's EC2 equivalent. With gcloud you manage VMs via explicit, consistent flags:

gcloud compute instances create web-01 \
    --zone asia-southeast1-a \
    --machine-type e2-small \
    --image-family ubuntu-2204-lts \
    --image-project ubuntu-os-cloud
 
gcloud compute instances start web-01 --zone asia-southeast1-a
gcloud compute instances stop web-01 --zone asia-southeast1-a
gcloud compute ssh web-01 --zone asia-southeast1-a
gcloud compute instances delete web-01 --zone asia-southeast1-a

#Storage in GCP

Storage in GCP is reached via gsutil — or gcloud storage on newer SDK versions that combine its functionality:

gsutil mb gs://my-backup-bucket
gsutil cp ./backup.zip gs://my-backup-bucket/backup/
gsutil ls gs://my-backup-bucket/backup/
gsutil cp gs://my-backup-bucket/backup/backup.zip ./restored.zip

The gs:// URI is how GCP names buckets — analogous to s3:// in AWS. The operation pattern is the same: create a bucket, upload, list, and download. Once comfortable with one cloud, learning another is about translating vocabulary, not learning from scratch.

#AWS CLI, SDK, and PowerShell Modules: When to Use Which

The rule of thumb: if your automation already lives in the PowerShell ecosystem — for example combined with Active Directory and Task Scheduler — the AWS.Tools modules feel most natural because results are directly objects. If your scripts are bash-first or run on cross-platform CI runners, the AWS CLI is more universal. And when infrastructure must be created declaratively and audited, move up to IaC like Terraform.

#Conclusion

Episode 28 unites two cloud worlds. On AWS, you've mastered the AWS.Tools.* modules: per-service installation, profile- and environment-variable-based authentication, and EC2, S3, and IAM management flowing through the pipeline. On GCP, you've mastered the Cloud SDK: gcloud for authentication, Compute Engine, and Storage via gsutil. In the middle is one decision you take home: choose the tool that blends with your automation ecosystem, not the shiniest one — PowerShell modules for Windows-centric automation, CLIs for cross-platform scripts, and IaC for infrastructure needing audit.

In the next episode, episode 29, we return to the core machine: modern PowerShell 7 features — pipeline parallelization, ternary and null-coalescing operators, command chaining, concise error views, and full support on Linux and macOS. See you there!