How I Learned AWS Coming from GCP as a Security Engineer

When I joined my new company, I was the GCP security guy, comfortable with GCP's Secops Ecosystem, and it's tidy global services. I thought AWS would be a breeze… until the console hit me. Suddenly every service needed a region, CloudTrail and CloudWatch were everywhere, and IAM policies felt like a PhD course. Two caffeine-fueled weeks later, things finally clicked. This is how a GCP SecOps engineer survived AWS's sprawl, and why cloud concepts translate better than you'd think.

But here's the thing about being thrown into the deep end. You either sink or learn to swim really, really fast. This is my story of how I navigated from GCP's organized simplicity to AWS's powerful complexity, and why it made me a better security engineer in the process.

The "Everything I Know Is Wrong" Phase

Embedded content

IAM: The Great Humbling

Remember GCP's beautiful hierarchical IAM where you could grant permissions at the organization level and watch them cascade down like a gentle waterfall? Well, AWS had other plans.

In GCP, I'd think: "Let me bind this user to the 'Compute Admin' role at the project level, and boom — they're good to go."

In AWS, I found myself staring at JSON policies that looked like they were written by someone with a grudge against readability:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:InstanceProfile": "arn:aws:iam::123456789012:instance-profile/MyProfile"
        }
      }
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ec2:DescribeInstances",
        "ec2:StartInstances",
        "ec2:StopInstances"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "ec2:InstanceProfile": "arn:aws:iam::123456789012:instance-profile/MyProfile"
        }
      }
    }
  ]
}

My first thought: "This can't possibly be the simplest way to do this."

The Service Sprawl Shock

Coming from GCP's streamlined service catalog, AWS felt like walking into a grocery store where every aisle had been designed by a different person. GuardDuty, Security Hub, Config, CloudTrail, Detective, Macie, WAF, Shield , it was like they took every possible security function and created a separate service for it.

The breaking point came when I spent two hours trying to figure out why CloudTrail logs weren't showing, only to discover they were in a completely different region. In GCP, global logging just… worked. In AWS, I had to explicitly enable CloudTrail in every single region I cared about.

Mental note: AWS really, really wants you to be intentional about everything.

The "Aha!" Moments (Or: When the Chaos Started Making Sense)

Embedded content

Understanding the AWS Philosophy

After a few weeks of fighting the system, I had my first major realization: AWS wasn't trying to be GCP. It was optimized for different things — mainly giving you every possible knob and dial to tune your environment exactly how you wanted it.

GCP's approach: "Here's a sensible default. Trust us, it's good." AWS's approach: "Here are 47 different ways to configure this. Choose wisely."

Once I stopped trying to make AWS behave like GCP and started appreciating its flexibility, everything clicked. That overwhelming service catalog? It meant I could solve security problems with surgical precision instead of broad-brush tools.

The Shared Responsibility Model Revelation

The shared responsibility model hit different in AWS. In GCP, it felt more abstract — Google handles infrastructure, you handle your code and data. Simple.

AWS made it visceral. Every service had its own security considerations:

• EC2: You're responsible for the guest OS, security patches, firewall configuration
• S3: You're responsible for bucket policies, encryption, access logging
• RDS: You're responsible for database security groups, parameter groups, backup encryption

It was overwhelming at first, but then I realized: this granular responsibility meant granular control. I could secure things exactly the way my organization needed them secured.

The Beautiful Complexity of AWS IAM

Embedded content

Here's where I'll probably get some hate mail, but after working with AWS IAM for a few months, I started to appreciate its complexity. Yes, it's harder to learn than GCP IAM. But once you understand it, you can do things that would require workarounds in other clouds.

Cross-account roles? Elegant. Temporary credentials through STS? Brilliant. Conditions in policies based on time, IP, MFA status? Chef's kiss

GCP vs AWS: Mapping the Services

A good way to start was building a mental map. Google Cloud's docs actually have a comparison chart of services cloud.google.com, and it closely matches my experience: many core concepts exist in both clouds under different names. For example:

[Embedded content: 81e50758b5513c008b3d3e487755d4cf]

These mappings explain a lot. Google's Organization Policy Service (GCP's built-in constraints) is roughly analogous to AWS's governance tools like AWS Config rules or Service Control Policies cloud.google.com. GCP's Cloud Logging is like AWS's CloudWatch Logs (for syslogs/metrics) and Cloud Audit Logs is more like CloudTrail (for user/API activity) cloud.google.com. Once I saw GuardDuty and Security Hub listed under SCC cloud.google.com, I realized GCP Security Command Center had been combining many AWS services under one umbrella. It also became clear that AWS often splits things that GCP bundles: in GCP one console sometimes covers several security features, whereas in AWS each feature (GuardDuty, Macie, Config, etc.) is its own product.

One fun default difference: GCP's firewall rules and IAM were global (no region needed), but AWS made me explicitly enable CloudTrail in all regions. (AWS recommends a multi-region trail so you don't miss anything docs.aws.amazon.com.) It was a bit jarring at first. Overall, having this table saved me from confusion — I literally had it open while I clicked around: "Ah, GCS → S3, OK… Cloud Armor → WAF+Shield… got it."

My AWS Learning Roadmap

I decided to tackle AWS in phases, building confidence layer by layer — much as I would architect cloud security in any setting:

1. Core Infrastructure: Focus on the foundation: EC2 (compute), S3 (storage), VPC (networking), and IAM. I spun up a simple VPC with public and private subnets, an EC2 in each, and practiced controlling traffic with SGs/NACLs. I enabled CloudTrail for my account (multi-region) and set up an S3 bucket for logs. Hands-on: create an EC2, lose SSH access by misconfiguring a security group, debug, fix. (Breaking things and fixing them cemented learning.)
2. Security Services: Once I had the basics, I dove into AWS-native security. I enabled GuardDuty and Security Hub in all accounts. I experimented with AWS WAF (set up a WebACL and saw logging). I created a KMS CMK and tried encrypting an S3 bucket and an EBS volume with it. I looked at AWS Config rules: e.g. required-tags, prohibited-public-s3, root-MFA-enabled, rotated-keys, and wrote a couple of simple rules of my own. For each, I did the "GCP analogy" check: e.g. Cloud Armor → WAF, SCC → GuardDuty+Hub.
3. Monitoring & Response: Last came the detective and response tools. I configured CloudWatch Logs and Metrics to alert on suspicious events (like unauthorized API calls). I played with EventBridge rules for automated remediation (e.g. if a bucket went public, notify me via Lambda). I hooked up AWS SNS/email notifications. I even integrated one of my GCP SIEM playbooks: pushing AWS CloudTrail logs into our on-prem SIEM via Firehose. During this phase, I referred to the AWS Well-Architected Security Pillar for guidance on best practices docs.aws.amazon.com and made sure I was covering all the recommended controls.

Throughout, I relied on AWS's free tier and labs. I followed tutorials on AWS Skill Builder (free courses) and Qwiklabs scenarios for setting up GuardDuty or WAF. Breaking things in a sandbox account was invaluable (and cheap). After about a week to ten days of this crash course, the AWS security landscape started looking familiar, just with different names.

AWS Security Essentials: A Security Engineer's Perspective

As a security engineer, some AWS fundamentals jumped out fast:

• IAM and Least Privilege: AWS IAM is powerful but complex. Every user/role can have identity-based policies, and many resources have resource-based policies as well. The principle of least privilege is king here. In fact, AWS provides IAM Access Analyzer to find overly-permissive roles and suggest tighten-ups aws.amazon.com. One AWS blog stresses using fine-grained IAM and Access Analyzer to prune unused permissions aws.amazon.comaws.amazon.com. (In GCP, IAM felt simpler: roles are just bound to resources, whereas in AWS we juggle Users, Roles, Groups, and policies — a mental overhead.)
• Shared Responsibility Model: I already knew "security of the cloud vs in the cloud," but AWS's marketing says it explicitly: AWS covers the physical data centers, hardware, and "cloud network" docs.aws.amazon.com, while I'm responsible for my data, OS patches, keys, and configs. Google Cloud has a similar model, but with some differences: for example, GCP encrypts data by default at rest and in transit medium.com, whereas in AWS I must explicitly enable S3 default encryption or use KMS CMKs. AWS does provide KMS, WAF, Shield etc. medium.com; GCP has Armor and IAP medium.com. Understanding these parallels helped me see that nothing was fundamentally worse in AWS, just different.
• CloudTrail & Logging: In GCP I was used to a unified audit log; in AWS I learned to always enable CloudTrail (preferably one multi-region trail) to catch all account activity docs.aws.amazon.com. CloudWatch (metrics, logs, alerts) became my friend for things GCP Cloud Monitoring handled. I also set up a centralized log account early on: CloudTrail can deposit logs into a dedicated S3 bucket (in an "audit" account) so I have immutable records.
• S3 Security vs GCS: By default, AWS S3 buckets are private but easily made public. I quickly learned to block public access at the account or bucket level. (Most breaches happen from misconfigured buckets.) The Cloud Security Alliance warns that overly-permissive S3 ACLs/policies invite data leaks cloudsecurityalliance.org. Best practice: "Ensure your S3 buckets are not publicly accessible. Use S3 Block Public Access." cloudsecurityalliance.org. In GCP, I had to configure a Cloud Storage bucket for public use too, but AWS felt more granular (and easier to slip up on). I started using AWS-managed encryption and IAM roles for S3, whereas in GCP I was used to buckets being encrypted and V4-signed by default.
• GuardDuty, Security Hub, Config: These AWS security services filled the gap of GCP's SCC/Cloud Security Command Center. GuardDuty (threat detection) and Security Hub (posture management) can be enabled with a few clicks. AWS docs encourage using GuardDuty to "continuously monitor different log sources" for threats docs.aws.amazon.com, and Security Hub to aggregate compliance findings docs.aws.amazon.com. AWS Config is critical too — it's like GCP's Audit Config — but much more powerful with rules and Remediation actions. I turned on the managed Config rules for S3 public-read, internet gateways, unrestricted SSH, etc.
• Firewall Rules vs NACLs/Security Groups: In GCP, firewall rules were quite flexible (stateful, applied to tags or networks). In AWS I had to learn the two-tier model: Security Groups (stateful, at the instance level) and Network ACLs (stateless, at the subnet level) jayendrapatil.com. This was confusing at first. For example, AWS's default NACL allows all inbound/outbound traffic, then you lock it down manually googlecloudarchitect.us. GCP's default VPC firewall by contrast allows SSH/RDP from anywhere googlecloudarchitect.us — a scary default that I needed to tighten. I learned to treat SGs like host firewalls (only allow what's needed per instance) and NACLs as a coarse-grained perimeter. Mistake-proofing: I added AWS Network Firewall or Cloud Armor in front of public endpoints, just like I'd use GCP Armor for HTTP apps.
• Common Missteps: I had plenty. Loose IAM policies (e.g. "Resource:* Action:*") were quickly flagged by Access Analyzer aws.amazon.com. Forgetting to enable MFA on the root user (again, a hard mandate for me). Leaving EBS volumes or S3 buckets unencrypted. These felt like rookie moves – in GCP I had gotten into the habit of requiring MFA and encryption everywhere. AWS had its own gotchas: for instance, StsAssumeRole policies, or trusting the whole account ("root") too easily. I started doing weekly IAM audits and cleaning up unused keys/roles; an AWS Security blog even suggests rotating/archiving keys frequently aws.amazon.com (we can all skip a couple of steps with that).

Tips, Resources & References

What helped me most:

• AWS Official Docs & Whitepapers: The AWS Well-Architected Security Pillar lays out recommended practices docs.aws.amazon.com. AWS's own security and compliance whitepapers were also comforting reading (they reinforce shared responsibility and AWS's inherited controls docs.aws.amazon.com docs.aws.amazon.com).
• GCP-to-AWS Mappings: Google's documentation itself has a [GCP vs AWS services comparison table] cloud.google.com (I used it extensively for reference). Reviewing blog posts and medium articles on "GCP vs AWS security" gave me quick parallels.
• Hands-on Labs: AWS Skill Builder (free AWS courses) and Qwiklabs/Cloud Academy had practical labs. The AWS Security Specialty exam prep material, even if I didn't take the test, provided a structured learning path for deeper understanding.
• Community & Blogs: The AWS Security Blog is invaluable (for example, they recently wrote about IAM Access Analyzer for least privilege aws.amazon.com aws.amazon.com). I also found Medium articles by fellow engineers useful (sometimes directly in search results when mapping products). AWS re:Invent and security conference talks on YouTube filled in advanced tips.
• Experimentation: My best advice — spin up stuff in AWS and break it. If an S3 bucket is public, try to lock it down. If an IAM user has AdministratorAccess, try scoping them down. If a pipeline in AWS CodeBuild breaks, figure out the IAM role issue. This trial-and-error, paired with the official docs (and perhaps a quick search for answers like StackOverflow), accelerated my learning more than anything.

Certification Path (If You're Into That):

The AWS Certified Security: Specialty exam forced me to learn topics I might have skipped otherwise. It's not required, but it provides a good structured learning path and validates your knowledge.

Closing Thoughts: Embracing the Chaos

Embedded content

Six months into my AWS journey, I can honestly say I'm a better security engineer than I was in my GCP-only days. Not because AWS is superior (both clouds have their strengths), but because AWS forced me to think deeply about every security decision.

GCP's opinionated defaults made me lazy. AWS's flexibility made me intentional.

In GCP, I knew how to secure things the Google way. In AWS, I had to understand the underlying security principles well enough to choose from multiple approaches. That deeper understanding made me more adaptable and effective.

The biggest lesson? Being cloud-agnostic isn't just a career insurance policy , it's about understanding that different clouds optimize for different things. GCP optimizes for developer experience and elegant defaults. AWS optimizes for flexibility and comprehensive control.

As security engineers, we need both perspectives. We need to know when to apply opinionated security patterns and when to craft bespoke solutions. We need to understand when "secure by default" is enough and when we need to dig into the weeds of custom policies and configurations.

If you're making the jump from GCP to AWS, embrace the initial confusion. That overwhelming feeling of "there's a service for everything" will transform into appreciation for having the right tool for every job. Those complex IAM policies will become powerful instruments of precise access control.

And remember: every expert was once a beginner who felt completely lost. The key is to stay curious, keep experimenting, and never stop asking "but is it secure?"

P.S. — Yes, I know this article is longer than a CVE description.

About the author: I'm Mayank Joshi, a security engineer who made the jump from Google Cloud to AWS. Feel free to connect via LinkedIn.