Kosuke ENOMOTO for AWS Community Builders

Posted on Nov 30

AWS Security Fundamentals with AWS BuilderCards Security Expansion Pack

#aws #awsbuildercards #security

TL;DR

Let’s learn the Security pillar of the AWS Well-Architected Framework by using AWS security services to prepare for mischief caused by threat actors—depicted here as adorable “pet actors”—and the security incidents they trigger.

drawn by @komakichidev

$ whoami

My name is coosuke (Kosuke Enomoto). Some people call me Kosuke, others Koske.

{
    "Name":"Kosuke Enomoto",
    "Bio":"https://linktr.ee/coosuke",
    "Job":"PO of Global CCoE",
    "SNS":[
          {
              "LinkedIn":"https://www.linkedin.com/in/kosuke-enomoto/",
              "X (formerly Twitter)":"@coosuke",
              "mixi2":"@coosuke",
              "Instagram":"@coskenomoto"
          }
      ],
    "Communities":[
        "Organizer, JAWS-UG Chiba Chapter",
        "AWS Community Builder",
        "AWS BuilderCards Japanese Edition Developer"
    ],
    "My Family":[
        "Wife","Black cat(5yo)","Kid(4yo)"
    ],
    "Hobbies":[
        "Sauna","Cooking","Photography"
    ]
}

You can find all my social links here—let’s connect!

https://linktr.ee/coosuke

What This Post Covers (and What It Doesn’t)

This post covers:

Why AWS BuilderCards is awesome
Why the AWS BuilderCards Security Expansion Pack is even more awesome

This post does not cover:

Deep explanations of AWS security services or implementation details
Detailed rules of the BuilderCards base game

Introduction

In this post, I’ll introduce the new AWS BuilderCards Security Expansion Pack, which I contributed translation and localization for the Japanese edition.

At AWS re:Invent 2025 in Las Vegas, the BuilderCards booth is open again this year.

AWS BuilderCards Booth at AWS re:Invent 2025

📍 Location: Caesar’s Forum (alcove, below the escalators)
🕐 Opening Hours:
- Sun, Nov 30 — 10 AM–6 PM
- Mon, Dec 1 — 9 AM–5 PM
- Tue, Dec 2 — 9 AM–5 PM
- Wed, Dec 3 — 9 AM–5 PM
- Thu, Dec 4 — 9 AM–4 PM
Japanese-speaking AWS SAs will be available at the booth!

If you’re attending re:Invent, you may already have visited the booth and picked up the cards. In this article, I’ll introduce the new expansion pack from the perspective of a BuilderCards translator and contributor—who is, admittedly, not a hardcore security expert.

What Is the AWS Well-Architected Framework?

Before diving into the expansion pack, let’s briefly revisit what the AWS Well-Architected Framework is.

AWS Well-Architected Framework

In my view, the Well-Architected Framework is essentially a collection of cloud best practices—guidance that remains universal regardless of company size, team structure, or workload type. While not mandatory, following it leads to higher ROI and more resilient architectures.

(And yes, Google Cloud and Azure also provide their own Well-Architected frameworks. Comparing them is fascinating!)

The Six Pillars of the AWS Well-Architected Framework

Operational Excellence
Security
Reliability
Performance Efficiency
Cost Optimization
Sustainability

This year’s new expansion pack focuses on learning the Security pillar.

The Security Pillar

Before we jump into the cards themselves, let’s briefly walk through what the Security pillar of the AWS Well-Architected Framework actually says.

In the official documentation, it is organized into:

7 security design principles
6 focus areas (best practices)

These form the mental model behind the AWS BuilderCards Security Expansion Pack.

7 Security Design Principles

These principles are high-level guidelines for how to think about cloud security.

Implement a strong identity foundation

Apply the principle of least privilege and enforce separation of duties.

Prefer role-based and temporary credentials instead of long-lived, user-bound access keys.
Enable traceability

Monitor, alert on, and audit all actions and changes in your environment.

Centralize logs and metrics so you can investigate issues in (near) real time.
Apply security at all layers

Don’t rely only on a perimeter firewall.

Use defense in depth across VPCs, subnets, load balancers, instances, operating systems, and applications.
Automate security best practices

Manage security controls as code (IaC) and keep them in version control.

Automation reduces human error and helps you scale securely as your workloads grow.
Protect data in transit and at rest

Classify data by sensitivity, then protect it with encryption, tokenization, and access control.

Consider both live data and backups, as well as internal and external access paths.
Keep people away from data

Minimize direct human access to production data.

Use tools, workflows, and automation so operations can be performed without engineers touching raw data, reducing the risk of mistakes and leaks.
Prepare for security events

Define and document an incident response process.

Regularly run simulations or game days to validate that your detection, investigation, containment, and recovery steps actually work and are fast enough.

6 Focus Areas (Best Practices)

The pillar also breaks security down into concrete implementation categories.

Security Foundations
- Understand the shared responsibility model so you know what AWS secures vs. what you must secure.
- Structure your AWS accounts (for example, multiple accounts per workload) and manage them centrally with services like AWS Organizations.
Identity and Access Management (IAM)
- Manage identities for both humans and machines in a consistent, centralized way.
- Enforce least privilege so every identity only has the permissions it needs, only when it needs them.
Detection
- Turn on services such as AWS CloudTrail (API activity), AWS Config (configuration changes), and Amazon GuardDuty (threat detection).
- Build alerting so the right teams are notified automatically when suspicious activity occurs.
Infrastructure Protection
- Protect your networks using VPCs, security groups, network ACLs, AWS WAF, and related services.
- Protect your compute layer with OS patching, vulnerability scanning, and container security controls.
Data Protection
- Classify data (for example: public, internal, confidential, highly confidential).
- Encrypt data at rest and in transit using services like AWS KMS, and protect backups with the same level of care as production data.
Incident Response
- Prepare: Establish runbooks, playbooks, communication channels, and tools in advance.
- Operate: Use automated playbooks to move quickly from detection to containment and recovery.
- Learn: Run post-incident reviews (post-mortems) and improve your processes and controls based on what you learned.

There is also a cross-cutting area of Application Security, which means:

Building security into the entire software development lifecycle (“shift left”)
Running regular security testing such as SAST/DAST and other application-focused assessment

The Four + One Key Concepts of Security Implementation

After reading the Security Pillar, I believe the essential points of cloud security can be summarized into 4+1:

Access Management — Authentication & authorization based on least privilege
Defense — Multi-layered protection across networks, data, and applications
Detection — Monitoring and logging to identify anomalies
Response — Processes to contain and recover from incidents
Learning — Post-incident reviews and continuous security testing　*This is "+1" because this should be the different aspect than the others 4.

Simulating failures Chaos Engineering–style is valuable—but doing it in production could be career-ending! Even staging environments require careful preparation.

But with AWS BuilderCards, you can simulate this safely—right at the table.

What Is AWS BuilderCards?

AWS BuilderCards is a board-game-style learning tool for the Well-Architected Framework.
There are two categories:

Base game
Expansion packs

Base Game

The base game teaches cloud migration and architecture design using Well-Architected principles. Both 1st and 2nd editions exist—the 2nd edition is available at re:Invent, and amazon.com in some countries!

Expansion Packs

Expansion packs add new learning themes on top of the base game. They cannot be played alone.
Past expansions include:

Generative AI (for 1st edition)
Resilience (for 2nd edition)

This article introduces the Security Expansion Pack, the brand-new expansion.

Another expansion pack, Builder’s Galore, also debuts at re:Invent—a "strong-and-new-game" style experience focused purely on cloud-native architectures.

Why We Created the Japanese Edition

BuilderCards was originally created by David Heidt, Game Tech Solutions Architect at AWS Germany. After it was showcased at re:Invent 2023, AWS Heroes and community members collaborated to localize it into Japanese.

Learn more from AWS Hero Yamaguchi’s article:

楽しみながら学べる AWS BuilderCards の遊び方、そして日本語化に込めた思い *Japanese

Here is my past blog how we localize BuilderCards into Japanese.
AWS BuilderCards Japanese Edition for JAWS DAYS

Learn more from an interview with David-how he inspired BuilderCards, develop and spread it.
The unexpected game designer: how a happy coincidence sparked a popular AWS card game

Learning AWS Security Fundamentals with the Security Expansion Pack

Thanks for reading this far—we’re finally at the main topic!

The Security Expansion Pack is designed around the 4+1 concepts introduced earlier.

Understand Security Threats

Threat actors are represented as “pet actors”—cute animals that “attack” the AWS environment players build.

Polly Packet (Bird) — Network & Infrastructure

As former companion of a network engineer, Polly learned all about protocols by listening to countless troubleshooting calls. Now she uses that knowledge to probe network defenses, repeating packets instead of phrases. Known for saying "Pretty payload!" while launching DDoS attacks. Believes that sometimes you need to overwhelm a network to show its weakness.

Zero-Day Raccoon — Applications & Runtime

Originally started by digging through developers' discarded code printouts in dumpsters, Zero-Day Raccoon discovered a talent for finding vulnerabilities others missed. Works at night, testing applications and leaving behind detailed bug reports along with scattered coffee cups and keyboard crumbs. It's called trash can - not trash can't!

Inside Cat — Data & Databases

Started her career as a data center cat catching mice, but became more interested in catching data instead. Specialized in quietly sitting between systems, proving that if she can intercept the data, so can others. Known for leaving "gifts" of exposed data on doorsteps. Favorite napping spot: Right on top of the most critical servers.

Bad Doggo — Identity & Access Management

After years of watching security guards use weak passwords and share credentials "just this once", Bad Doggo couldn't take it anymore. Originally trained as a security K-9 unit, he now specializes in breaking authentication systems to prove how easily treats... err, threats... can get in. Is it his fault, that humans always trust a friendly face with a wagging tail? His motto: "Who's a bad doggo? I am, but for he right reasons!"

These pet actors represent threats targeting access management and defense, the first two of the 4+1.

Detect & Respond Using AWS Security Services

AWS provides many security services for:

DETECTION — Discovering threats
RESPONSE — Taking corrective action

Both are essential.

The expansion pack includes BuilderCards representing these AWS security services.
Whether a threat is mitigated depends on whether your built architecture includes the relevant security cards.

Example: Pet Actor Mischief – How Detection and Response Change the Outcome

In the Security Expansion Pack, pet actor mischief is triggered when a player buys a Well-Architected Point card during the Cloud-Adoption (purchase) phase.

Event cards include some sections:

Event name
Description
DETECTION
RESPONSE
IMPACT based on whether detection/response conditions are met

If you fail both detection and response → you receive a PWNED card, which deducts one Well-Architected point.

The image above shows an example of a mischief event caused by Polly Packet. In the Security Expansion Pack, these kinds of incidents are represented as Event Cards.

Each Event Card is structured as follows (from top to bottom):

Event name
Event description – what kind of “mischief” is happening
DETECTION
RESPONSE
IMPACT

The most important parts to pay attention to are the bottom three: DETECTION, RESPONSE, and IMPACT.

Earlier, I wrote that in both the real world and in the Security Expansion Pack, resolving a threat (a pet actor’s mischief) requires both detection and response. The card text reflects exactly that: whether you can mitigate the incident depends on whether your built architecture includes the services listed under DETECTION and/or RESPONSE.

Using this Event Card as an example:

To detect this event (DETECTION), you need Amazon CloudWatch.
To respond to this event (RESPONSE), you need any one of the following:
- AWS Shield Advanced
- AWS Network Firewall
- Amazon EventBridge + AWS Lambda

Some notation rules:

A bulleted list under RESPONSE means OR (any one is enough).
A “+” sign means AND (you need those services together).

In other words, whether you have zero, one, or both of DETECTION and RESPONSE implemented will change the outcome described in IMPACT.

Let’s look at the IMPACT section of this Event Card and see what happens when Polly Packet attacks:

❌ If you have neither DETECTION nor RESPONSE

→ You must take 1 PWNED card.
⚠️ If you have only one of DETECTION or RESPONSE (not both)

→ On your next turn, your hand size is reduced to 4 cards (instead of the usual 5).
✅ If you have both DETECTION and RESPONSE

→ You may perform the Cloud-Adoption (purchase) action one more time.

In this way, the game rewards architectures that are designed to both see incidents and act on them.

What Does “PWNED” Mean? And What Is the Penalty?

pwn is a term commonly used in CTF (Capture the Flag) competitions—a category of security challenges where you exploit vulnerabilities in an application or system to “take over” a target and capture a flag.

There’s also another meaning of pwn in online gaming slang: “to beat or dominate someone.”

In either sense, being PWNED means “you got owned” or “you were defeated.”

In the Security Expansion Pack, if you fail to both detect and respond to an event, you receive a PWNED card as a penalty.

Each PWNED card you hold reduces your total Well-Architected Points by 1.
Some events are severe enough that you may have to take 2 PWNED cards at once.

So, as you can imagine, ignoring detection and response is costly—not just in real-world security, but even in this tabletop simulation.

Learn Without Risking Your Real Environment

This corresponds to the final “+1” of the 4+1: learning.

BuilderCards Is Not Just a Game—It’s a Learning Tool

The base game teaches Well-Architected concepts; expansion packs teach deeper technical domains.

For the Security Expansion Pack, I recommend learning foundational AWS security concepts first (Level 200–300).

Resources I personally recommend:

https://dev.classmethod.jp/articles/aws-summit-japan-2024-community-stage-security/

https://business.ntt-east.co.jp/content/cloudsolution/ihcm_column-04.html

https://www.shoeisha.co.jp/book/detail/9784798190853

Security Expansion Pack Rulebook (Japanese)

Created by JAWS-UG Chiba:

https://drive.google.com/file/d/1EZ2A2ixkde1GoalvvUanH7TpTcDhXzI3/view?usp=sharing

Can You Get BuilderCards in Japan?

Short answer: Not on Amazon Japan, but you may receive them at JAWS-UG BuilderCards workshops.

Follow these accounts for event information:

X: @jawsdays
JAWS-UG Event Calendar: https://jaws-ug.jp/calendar/
AWS Community Manager Numaguchi-san’s note: https://note.com/s_numaguchi

DEV Community