After years working primarily in Azure-based enterprise environments, I decided to seriously invest in learning AWS. Not because Azure was inadequate—quite the opposite—but because I wanted to understand cloud computing principles beyond a single vendor’s perspective.

The journey from “I know what EC2 is” to passing the AWS Solutions Architect Associate exam taught me far more than service names and pricing tiers. It fundamentally changed how I think about system design, resilience, and infrastructure-as-code.

Here’s what I learned, how I approached it, and why it mattered.

Why Learn AWS When You Already Know Azure?

This is a fair question. I was productive in Azure, understood its services deeply, and could design production-grade architectures. Why invest hundreds of hours learning what felt like “the same thing with different names”?

Portability of Cloud Concepts

The real value wasn’t learning AWS-specific services—it was crystallising cloud-native patterns that apply universally:

• Eventual consistency vs. strong consistency (DynamoDB vs. RDS)
• Managed vs. self-managed infrastructure trade-offs (Lambda vs. EC2)
• Cost optimisation through tiered storage (S3 lifecycle policies)
• Resilience through multi-AZ and multi-region design

These patterns exist in Azure (and GCP), but AWS’s opinionated service design and extensive documentation forced me to think more deeply about why certain architectural decisions matter.

Broadening Career Options

Pragmatically, AWS dominates cloud market share. While Azure excels in enterprise and Microsoft-centric stacks, many startups, SaaS companies, and modern tech orgs default to AWS. Learning it opened doors to roles I wouldn’t have been competitive for otherwise.

Challenging Assumptions

Working exclusively in one cloud creates implicit biases. Azure’s integration with Active Directory, for instance, made me take identity management patterns for granted. AWS’s IAM forced me to think from first principles about policies, roles, and least-privilege access.

My Learning Approach: Certification as a Framework

I used the AWS Certified Solutions Architect – Associate exam as a structured learning path. While some criticise certifications as “checkbox exercises,” I found the exam blueprint useful for:

1. Scoping breadth: AWS has 200+ services—the exam focused on ~20 core ones
2. Forcing depth: Multiple-choice questions require understanding trade-offs, not just definitions
3. Validating knowledge: Passing gave me confidence I understood fundamentals, not just surface-level concepts

Study Resources I Used

1. AWS Documentation (Primary Source)

The official docs are exceptional. For each core service, I read:

• Getting Started Guides: Hands-on tutorials (e.g., deploying a static site to S3)
• Developer Guides: API references and SDK examples
• Best Practices Whitepapers: Architectural guidance (e.g., “Well-Architected Framework”)

2. Adrian Cantrill’s SAA-C03 Course

Adrian’s course is dense, technical, and excellent. Unlike many exam prep courses that teach to the test, Adrian teaches how AWS services actually work:

• Deep dives into VPC routing, subnet design, and NAT gateways
• Detailed explanations of S3 consistency models and replication
• Hands-on labs building production-like architectures

His “Animals4Life” demo project—building a multi-tier web app with RDS, S3, CloudFront, and Lambda—was worth the price alone.

3. AWS Skillbuilder (Free Labs)

AWS’s own Skillbuilder platform offers sandbox environments where you can experiment without cost concerns. I used it extensively for:

• IAM policy creation and testing
• VPC design and subnet routing
• Lambda function deployment and event triggers

4. Practice Exams (Tutorialsdojo)

Tutorialsdojo’s practice tests were invaluable for exam readiness. Their explanations for why wrong answers are wrong helped solidify concepts.

Time Investment

• ~3 months of part-time study (10-15 hours/week)
• ~120 hours total across video courses, documentation, labs, and practice exams
• Passed on first attempt with a score of 850/1000

Key Concepts That Changed How I Think

1. Infrastructure as Code (IaC) is Non-Negotiable

Azure Resource Manager templates felt verbose and clunky. AWS CloudFormation was similar. But learning AWS CDK (Cloud Development Kit) and Terraform showed me IaC done right.

Example: Deploying a Static Site with CDK (TypeScript)

import * as cdk from 'aws-cdk-lib';
import * as s3 from 'aws-cdk-lib/aws-s3';
import * as cloudfront from 'aws-cdk-lib/aws-cloudfront';
import * as origins from 'aws-cdk-lib/aws-cloudfront-origins';

export class StaticSiteStack extends cdk.Stack {
  constructor(scope: cdk.App, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // S3 bucket for static assets
    const bucket = new s3.Bucket(this, 'SiteBucket', {
      websiteIndexDocument: 'index.html',
      publicReadAccess: false,
      blockPublicAccess: s3.BlockPublicAccess.BLOCK_ALL,
    });

    // CloudFront distribution for CDN
    const distribution = new cloudfront.Distribution(this, 'SiteDistribution', {
      defaultBehavior: {
        origin: new origins.S3Origin(bucket),
        viewerProtocolPolicy: cloudfront.ViewerProtocolPolicy.REDIRECT_TO_HTTPS,
      },
      defaultRootObject: 'index.html',
    });

    // Output the CloudFront URL
    new cdk.CfnOutput(this, 'DistributionURL', {
      value: distribution.distributionDomainName,
    });
  }
}

This felt right—declarative, type-safe, reusable. It made me rethink how I’d been deploying Azure resources and pushed me toward ARM-equivalent tools like Bicep.

2. Serverless Changes Cost and Operational Models

AWS Lambda forced me to rethink “backend services.” Instead of running Node.js on an App Service instance 24/7, I could write functions that:

• Only ran when triggered (API Gateway request, S3 upload, DynamoDB change)
• Scaled automatically from 0 to thousands of concurrent executions
• Cost literally $0 when idle

Example: S3 Upload Trigger

import boto3
import json

s3_client = boto3.client('s3')

def lambda_handler(event, context):
    """Triggered when a file is uploaded to S3"""
    for record in event['Records']:
        bucket = record['s3']['bucket']['name']
        key = record['s3']['object']['key']
        
        print(f"Processing file: {bucket}/{key}")
        
        # Example: Generate thumbnail or extract metadata
        process_file(bucket, key)
    
    return {
        'statusCode': 200,
        'body': json.dumps('Processing complete')
    }

This pattern—event-driven, pay-per-use, zero-ops—became my default mental model for background processing, ETL pipelines, and webhooks.

3. Multi-AZ Design is About Resilience, Not Redundancy

Azure’s “availability zones” and AWS’s “availability zones” sound the same, but AWS’s documentation drilled home the why behind multi-AZ:

• Failure domains: Hardware failures, power outages, network partitions
• Latency vs. durability trade-offs: Synchronous replication (RDS Multi-AZ) vs. asynchronous (read replicas)
• Cost implications: Running instances in multiple AZs doubles compute costs

Designing a production database on RDS taught me to ask:

• “What’s the acceptable data loss window (RPO)?”
• “What’s the acceptable downtime window (RTO)?”
• “Is this workload latency-sensitive or consistency-critical?”

These weren’t questions I’d asked rigorously before.

4. IAM Policies Are Code, Not Configuration

AWS IAM policies are JSON documents defining who can do what to which resources. Writing them felt like programming:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/uploads/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "ap-southeast-2"
        }
      }
    }
  ]
}

This level of granularity—specifying actions, resources, and conditions—taught me to think about security as least-privilege by default, not “grant broad access and hope for the best.”

Applying AWS Concepts to Real-World Projects

Personal Project: Re-architecting a Side Project

I had a side project (a booking platform) running on a single DigitalOcean droplet. After learning AWS, I re-architected it:

Before:

• 1 VM running Node.js + PostgreSQL + NGINX
• Manual deployments via SSH
• No CI/CD, no backups, no monitoring

After:

• Frontend: S3 + CloudFront (static Next.js build)
• Backend API: Lambda + API Gateway (serverless Node.js)
• Database: RDS PostgreSQL with automated backups and Multi-AZ
• CI/CD: GitHub Actions deploying to AWS via CDK
• Monitoring: CloudWatch dashboards and alarms

Results:

• 99.9%+ uptime (vs. ~95% on a single VM)
• ~$15/month cost (vs. $40/month for the VM)
• Zero-ops deployments (git push → automated tests → deployment)

Applying Patterns at Work

Even in Azure-heavy environments, AWS concepts transferred:

• Event-driven architectures: Used Azure Event Grid the way I’d use EventBridge
• Serverless functions: Applied Lambda mental models to Azure Functions
• IaC discipline: Pushed for Bicep adoption inspired by CDK’s type safety

What I Wish I’d Known Before Starting

1. You Don’t Need to Memorise Service Names

The exam doesn’t test trivia like “What year was S3 launched?” It tests architectural decision-making:

“You need low-latency, strongly-consistent key-value storage with automatic scaling. Which service?”
Answer: DynamoDB (not RDS, not S3)

Focus on service trade-offs, not encyclopaedic knowledge.

2. Hands-On Labs > Video Watching

I spent too long passively watching videos. The real learning happened when I:

• Broke VPC routing and debugged why instances couldn’t reach the internet
• Misconfigured IAM policies and got “Access Denied” errors
• Set up Lambda triggers and watched CloudWatch logs in real-time

Recommendation: For every hour of video, spend 2 hours in the console or writing code.

3. The Free Tier is Generous—Use It

AWS’s free tier includes:

• 750 hours/month of EC2 t2.micro (enough for 1 instance running 24/7)
• 5GB of S3 storage
• 1 million Lambda requests/month
• 750 hours of RDS t2.micro

I built and tested multiple projects without spending a cent (beyond exam fees).

4. Certification ≠ Production Expertise

Passing the exam meant I understood AWS concepts. Building production systems required:

• Debugging cryptic CloudFormation errors
• Optimising Lambda cold starts
• Designing disaster recovery strategies
• Navigating AWS support tiers and service limits

The cert was a foundation, not a finish line.

What’s Next: Deepening AWS Expertise

With the fundamentals solid, I’m exploring:

• Advanced networking: Transit Gateways, PrivateLink, VPC peering at scale
• Container orchestration: ECS vs. EKS trade-offs for microservices
• Advanced serverless: Step Functions for state machines, EventBridge for event routing
• Cost optimisation: Reserved Instances, Spot Instances, Savings Plans

Key Takeaways

1. Learn cloud for concepts, not vendor lock-in: AWS taught me patterns applicable everywhere
2. Certification provides structure: Use exam blueprints to scope learning, not as the end goal
3. Hands-on beats theory: Break things in sandbox environments—it’s the fastest way to learn
4. IaC is transformative: Treating infrastructure as code changes how you design and deploy systems
5. Serverless shifts mental models: Event-driven, pay-per-use architectures are now my default for many workloads

---

For engineers considering AWS learning: start with the free tier, pick a small project, and deploy it end-to-end. You’ll learn more in a weekend than a month of video courses.

What’s been your experience learning cloud platforms? Any resources or approaches that accelerated your learning? Let’s compare notes.

References:

• AWS Well-Architected Framework
• Adrian Cantrill’s SAA-C03 Course
• AWS CDK Documentation
• Tutorialsdojo Practice Exams