Cloud seed samples
Every sample below applies cleanly against the offline AWS region (Terraform 1.16.4). Add one from the Cloud VPC panel with Browse samples, or ask Oracle to add it.
Enterprise baseline
Section titled “Enterprise baseline”| Sample | What it builds | Services |
|---|---|---|
| Billing alarm with SNS email notification | A CloudWatch estimated-charges alarm that notifies an SNS topic when the monthly bill crosses a threshold, with an email subscription. The budget-guardrail pattern using billing metrics. | CloudWatch, SNS |
| CloudTrail writing to a KMS-encrypted log bucket | A multi-region CloudTrail trail delivering to a private S3 bucket encrypted with a customer KMS key, with a bucket policy for CloudTrail delivery and public access blocked. The standard audit-logging baseline. | CloudTrail, S3, KMS |
| CloudWatch log groups with retention and KMS encryption | A set of application, audit and access log groups with explicit retention periods (30, 365 and 90 days) and a KMS key on the audit group. Fixes the never-expire default and gives you groups to query and inspect. | CloudWatch, KMS |
| KMS customer keys with rotation, aliases and a key policy | Three customer-managed KMS keys (data, secrets, logs) with automatic rotation, friendly aliases and a key policy that delegates to IAM. A typical key inventory to list and describe with the AWS CLI. | KMS |
| Consistent tagging baseline across S3, DynamoDB, SNS and IAM | A shared tag map (owner, cost-center, environment, data-class) applied through locals to an S3 bucket, a DynamoDB table, an SNS topic and an IAM role. Good for practicing tag queries and cost allocation by tag. | S3, DynamoDB, SNS, IAM |
| S3 server access logging to a dedicated log bucket | A private log bucket that receives S3 server access logs from an application data bucket, with encryption, public access blocked and a lifecycle rule that expires old logs. The standard S3 access-audit pattern. | S3 |
| Versioned, encrypted S3 bucket | A private bucket with versioning, default SSE-KMS encryption and public access blocked. | S3, KMS |
| Secrets Manager secret with KMS key and rotation policy | A database-credentials secret encrypted with a customer KMS key, a JSON secret version, a rotation-ready resource policy and a Lambda-style rotation role. Shows how a rotatable secret is laid out. | SecretsManager, KMS, IAM |
| Encrypted SNS security-alerts topic with access policy | A KMS-encrypted SNS topic for security alerts with a topic policy limited to the account, an email subscription and a CloudWatch alarm that publishes to it. A common notification backbone for an enterprise baseline. | SNS, KMS, CloudWatch |
| SSM Parameter Store hierarchy for an application | A /ebssm/ | SSM, KMS |
Networking
Section titled “Networking”| Sample | What it builds | Services |
|---|---|---|
| Elastic IPs bound to network interfaces | A public subnet with two fixed-IP network interfaces behind an HTTPS-only security group, one Elastic IP attached to the primary interface and a spare EIP held in reserve. Good for learning failover-friendly public addressing. | VPC, EC2 |
| Network ACLs for a public and a data subnet | A VPC with a public and a data subnet, each with its own stateless network ACL. The public ACL allows HTTPS and ephemeral replies; the data ACL allows only database traffic from the public subnet and explicitly denies SSH. Good for learning rule ordering. | VPC, EC2 |
| Route 53 private hosted zone with internal records | A VPC with a private Route 53 hosted zone holding A, CNAME and TXT records for internal services such as db and api. Good for exploring split-horizon style internal DNS with the AWS CLI. | Route53, VPC |
| Chained security groups for web, app and database tiers | Three security groups where each tier only accepts traffic from the tier above, using security group references instead of CIDR ranges. Egress is restricted too. Good for learning least-privilege network rules. | VPC, EC2 |
| Highly available VPC with a NAT gateway per zone | A VPC with public and private subnets in two zones, each zone with its own Elastic IP, NAT gateway and private route table. Good for studying zone-resilient egress and EIP allocation. | VPC, EC2 |
| VPC flow logs delivered to CloudWatch Logs | A VPC and subnet with two flow logs (all traffic on the VPC, rejects only on the subnet) delivered to a CloudWatch log group through a least-privilege delivery role. Good for learning network visibility and traffic logging. | VPC, EC2, CloudWatch, IAM |
| VPC with interface endpoints for Secrets Manager and SSM | A VPC with two endpoint subnets, a security group allowing HTTPS from inside the VPC, and interface endpoints for Secrets Manager and SSM with private DNS. Good for learning PrivateLink-style access to AWS APIs without internet egress. | VPC, EC2, SecretsManager, SSM |
| Isolated VPC with no internet path | A fully isolated VPC for sensitive data: two data subnets and a small management subnet, no internet gateway or NAT, one route table with only the local route, and a locked-down default security group. Good for exploring air-gapped network design. | VPC, EC2 |
| Two VPCs joined by VPC peering | An application VPC and a shared-services VPC with non-overlapping ranges, an accepted peering connection and routes in both directions. Good for learning peering and why route tables matter on both sides. | VPC, EC2 |
| VPC with public and private subnets | A VPC with two public and two private subnets across two zones, an internet gateway, a NAT gateway and routing. A solid base for placing servers behind a NAT. | VPC, EC2 |
| VPC with an S3 gateway endpoint | A private subnet with an S3 gateway endpoint on its route table, plus a bucket whose policy denies requests that do not come through that endpoint, with the account’s own principals exempt. Good for learning private S3 access paths. The emulator sends no traffic through endpoints and never sets aws:SourceVpce, so here the policy denies every caller outside the account, endpoint or not. | VPC, EC2, S3 |
| Three-tier VPC across two zones | A VPC with web, app and database subnet pairs in two availability zones. Only the web tier routes to the internet gateway; app and database tiers have local-only routing. Good for practising tier isolation with the AWS CLI. | VPC, EC2 |
Compute
Section titled “Compute”| Sample | What it builds | Services |
|---|---|---|
| Application load balancer with target group and listener | An internet-facing ALB across two subnets, an HTTP target group with health checks, a listener that forwards to it, and two registered instances. Good for describing load balancer, listener and target health. | EC2, VPC |
| Auto Scaling group from a launch template with scaling policy | An Auto Scaling group spread across two subnets that launches from a launch template, with a target-tracking CPU policy. Good for exploring group sizing, templates and policies. | EC2, VPC |
| Data and logs EBS volumes attached to an instance | An instance with two extra encrypted EBS volumes (data and logs) attached as separate devices. Good for exploring volume attachments, types and encryption with the AWS CLI. | EC2, EBS, KMS |
| Web and app instances in separate subnets | A VPC with a web subnet and an app subnet, one instance in each, with security groups so only the web tier can reach the app tier. Good for listing instances by subnet and tier. | EC2, VPC |
| EC2 key pair and an SSH-only bastion instance | Registers an SSH key pair, a security group that allows SSH only from a management range, and an instance launched with that key. Good for practising key pair and security group lookups. | EC2, VPC |
| Instance configured by user-data and an instance profile | An instance with a user-data script that writes config and a banner at first boot, plus a role and instance profile it runs under. Good for reading user-data and instance attributes with the AWS CLI. | EC2, IAM, VPC |
| Hardened EC2 launch template with IMDSv2 and encrypted disk | A reusable EC2 launch template that requires IMDSv2, encrypts the root volume, turns on detailed monitoring and tags every instance. Good for exploring template versions and defaults with the AWS CLI. | EC2, VPC |
| Network load balancer with a TCP listener | An internal network load balancer across two subnets with a TCP target group (HTTP health check), a listener on port 443 and two registered instances. Good for comparing NLB and ALB settings. | EC2, VPC |
Storage
Section titled “Storage”| Sample | What it builds | Services |
|---|---|---|
| S3 bucket notifications to an SQS queue | A bucket that sends object-created events for an uploads prefix to an SQS queue, with the queue policy that allows S3 to deliver them. Good for exploring event-driven ingest. | S3, SQS |
| S3 bucket policy: TLS only, with default encryption | A bucket with default encryption (AES256), ownership controls, full public access blocking and a policy that denies requests not sent over TLS. A baseline hardening pattern for data buckets. The emulator serves plain HTTP and never sets aws:SecureTransport, so the TLS rule blocks nothing here, and it records default encryption without marking uploads encrypted. | S3 |
| S3 bucket with CORS rules | A bucket for browser uploads with CORS rules for a web origin (GET and PUT with exposed headers) and a stricter rule set for read-only access, plus public access blocked. Good for exploring cross-origin settings. | S3 |
| S3 inventory and analytics reporting | A data bucket that writes a daily S3 Inventory report and storage-class analytics to a separate reports bucket, with the bucket policy S3 needs to deliver them. Good for auditing what is stored. | S3 |
| S3 bucket with lifecycle rules | A logs bucket with lifecycle rules that move objects to cheaper storage classes, expire them, clean up old versions and abort stale multipart uploads. Good for exploring cost control with the lifecycle CLI calls. | S3 |
| S3 bucket with Object Lock retention | A bucket created with Object Lock enabled and a default compliance-style retention rule, so written objects cannot be deleted or overwritten until retention ends. Good for exploring WORM storage and legal hold. | S3 |
| Source and destination S3 buckets for replication | A versioned source and destination bucket pair with an IAM replication role and a replication rule. A model of how cross-bucket replication is wired for disaster recovery. | S3, IAM |
| Static website S3 bucket | A bucket configured for static website hosting with index and error pages, a public-read bucket policy scoped to the site content, and uploaded sample pages. A model of simple static hosting. | S3 |
| Sample | What it builds | Services |
|---|---|---|
| Analytics data lake with raw, curated and scratch buckets | Three S3 buckets for the raw, curated and scratch zones of a data lake, each with a placeholder prefix layout, encryption and public access blocked, and a lifecycle rule that expires scratch data after seven days. A common analytics storage layout. | S3 |
| Athena workgroup with an encrypted results bucket | An Athena workgroup that enforces its configuration and writes query results to a dedicated, encrypted S3 bucket, with a per-query scan limit, alongside a Glue database to query. Shows how analysts are kept inside controlled query settings. | Athena, S3, Glue |
| DynamoDB product catalog seeded with items | A DynamoDB table of products with a category index, pre-loaded with five catalog items through aws_dynamodb_table_item. Handy for practising scan, query and get-item calls against real data. | DynamoDB |
| DynamoDB table with streams and a local secondary index | A sessions table with a range key, a local secondary index, DynamoDB Streams (new and old images) and a TTL attribute, plus a second on-demand audit table. Good for exploring change capture and alternate sort keys with the AWS CLI. | DynamoDB |
| DynamoDB table with a global secondary index | An on-demand DynamoDB table with hash and range keys, one global secondary index, a TTL attribute and point-in-time recovery. A starting point for app data. | DynamoDB |
| ElastiCache Redis cache in private subnets | A small VPC with two private subnets, an ElastiCache subnet group, a security group limited to the VPC range on port 6379 and a single-node Redis replication group. A typical cache tier for an application stack. | ElastiCache, EC2 |
| Kinesis Firehose delivery stream into S3 | A Firehose delivery stream that buffers events into a landing S3 bucket under a date-partitioned prefix, with its IAM role and a CloudWatch log group for delivery errors. A standard ingest pipeline for logs and clickstream data. | Firehose, S3, IAM, CloudWatch |
| Glue catalog database with a partitioned table | A Glue Data Catalog database holding a partitioned Parquet table for web logs, backed by an S3 bucket. Gives Athena-style queries a schema to work against and shows how a catalog describes data in S3. | Glue, S3 |
| Kinesis data stream with producer and consumer roles | A provisioned two-shard Kinesis stream with 48-hour retention, plus separate IAM roles and policies for a producer (put only) and a consumer (read only). Shows least-privilege access to a streaming pipeline. | Kinesis, IAM |
| RDS PostgreSQL instance in private subnets | A VPC with two private subnets, an RDS subnet group, a database security group open only to the VPC range on 5432 and a small encrypted PostgreSQL instance. The usual starting point for an application database tier. | RDS, EC2 |
| Seeded CloudTrail log corpus for detection practice | A detection and log-analysis lab: an S3 bucket seeded with CloudTrail-style JSON events that tell a short attack story (recon, access-key creation, an admin policy change, then data exfil), a Glue database and table over the logs, and an Athena workgroup with an encrypted results bucket. Good for practising threat hunting with Athena SQL against trail data. | CloudTrail, S3, Glue, Athena |
Messaging
Section titled “Messaging”| Sample | What it builds | Services |
|---|---|---|
| EventBridge custom bus with a rule targeting SQS | A custom EventBridge event bus, a rule matching order-placed events, and an SQS queue target with the queue policy EventBridge needs on AWS (the emulator delivers without checking it). Good for exploring event routing with put-events and event patterns. | EventBridge, SQS |
| EventBridge rule streaming events into Kinesis | A Kinesis data stream fed by an EventBridge rule that matches audit events, using an IAM role EventBridge assumes to put records. Good for exploring event-to-stream pipelines and the role trust and permission pair. | EventBridge, Kinesis, IAM |
| Scheduled EventBridge rule publishing to SNS | A cron-style EventBridge rule that fires every weekday morning and publishes a fixed payload to an SNS topic, plus a rate-based rule for a heartbeat. Good for exploring scheduled automation without compute. | EventBridge, SNS |
| SNS topic fanned out to two SQS queues | An SNS topic with two SQS subscriptions (billing and shipping), each queue carrying a policy that lets only that topic send to it. Good for exploring publish/subscribe fan-out and queue policies. The queue policies state the intent: the emulator never checks them, so it does not gate sends by them. | SNS, SQS |
| SNS topic with filtered SQS subscriptions | One SNS topic feeding two SQS queues through subscription filter policies: one queue receives only critical alerts, the other only info-level ones. Good for practising message attributes and attribute-based routing. | SNS, SQS |
| KMS-encrypted SNS topic with an SQS subscriber | A customer-managed KMS key with rotation and an alias, an SNS topic encrypted with it, and an SQS queue subscribed to the topic. The key policy lets SNS use the key. Good for exploring encryption at rest for messaging. | SNS, SQS, KMS |
| FIFO SQS queue with content deduplication and FIFO DLQ | A first-in-first-out SQS queue with content-based deduplication and per-message-group throughput, backed by a FIFO dead-letter queue. Good for practising ordered delivery and exactly-once style processing. | SQS |
| SQS queue with dead-letter queue | A main SQS queue that moves a message to a dead-letter queue after five failed receives, with a redrive allow policy on the dead-letter queue. Good for practising retry and poison-message handling. | SQS |
Serverless
Section titled “Serverless”| Sample | What it builds | Services |
|---|---|---|
| API Gateway usage plan with quota and key-required method | A REST API whose GET /quotes method requires an API key, bound to a usage plan with a daily quota and burst and rate throttling, deployed to a prod stage. Good for exploring how usage plans, stages and key requirements relate; create keys yourself with the CLI. | APIGateway |
| HTTP API with CORS, routes and an auto-deploy stage | An API Gateway v2 HTTP API with a proxy integration, three routes (list, get and create items), CORS settings and an auto-deployed prod stage. Good for listing routes and integrations with the AWS CLI. | APIGateway |
| REST API with a MOCK integration and deployed stage | An API Gateway REST API with a GET /health method answered by a MOCK integration with a canned JSON response, deployed to a v1 stage. Good for exploring resources, methods, integrations and stages with the AWS CLI without any backend. | APIGateway |
| EventBridge rule that starts a Step Functions workflow | A custom event bus with a pattern-matching rule that starts a Step Functions state machine, using a least-privilege events role that may only call StartExecution on that one workflow. Good for event-driven serverless practice. | EventBridge, StepFunctions, IAM |
| EventBridge Scheduler group with cron and rate schedules | An EventBridge Scheduler schedule group with a daily cron schedule and an hourly flexible-window schedule, both publishing to an SNS topic through a scheduler execution role. Good for learning how schedules, groups and target roles fit together. | EventBridge, SNS, IAM |
| Lambda execution roles scoped to a table, log group and queue | Two IAM execution roles that Lambda can assume: one limited to its own log group and a DynamoDB table, the other limited to consuming one SQS queue. A model of per-function least privilege for serverless code. | IAM, Lambda, DynamoDB, SQS, CloudWatch |
| Lambda function with an S3 upload trigger | A Python 3.12 function deployed from a zip in S3, with an execution role, a log group, and an S3 bucket notification that invokes it on every new object. The function runs for real in the region, so you can invoke it and read the result. | Lambda, S3, IAM, CloudWatch |
| Express Step Functions workflow with CloudWatch logging | An EXPRESS state machine that tags a record, branches with a Choice state to Succeed or Fail, and logs every execution to a CloudWatch log group through a dedicated role. Good for practicing logging configuration and Succeed/Fail states. | StepFunctions, CloudWatch, IAM |
| Step Functions order routing with Pass, Choice and Wait | A standard state machine that normalizes an order, branches on its total with a Choice state, and either auto-approves it or waits before approving. Includes the states execution role. Good for practicing start-execution and describe-execution from the CLI. | StepFunctions, IAM |
Identity
Section titled “Identity”| Sample | What it builds | Services |
|---|---|---|
| Cognito user pool with app client and groups | A Cognito user pool with a password policy, an app client, admin and reader groups, and two users placed into those groups. Good for exploring user pool, group and user commands. | Cognito |
| IAM ABAC: principal tags matched to S3 object and bucket tags | Attribute-based access control: an IAM policy lets a user read S3 objects whose project tag (s3:ExistingObjectTag/project) matches the caller’s aws:PrincipalTag/project, and bucket tags the same way. Users may also tag themselves, so either can rewrite its own project tag. The emulator never sets aws:PrincipalTag, so the grant never matches here; the lab shows the policy and the self-tag step. | IAM, S3 |
| Read-only security auditor role | A read-only auditor role with IAM, S3 and EC2 describe permissions, trusted by a named auditor user, with an explicit deny on secret-reading actions. Good for modelling an access review or Access Analyzer-style audit identity. | IAM |
| Account password policy with a user and group | A strict IAM account password policy (length, complexity, rotation, reuse prevention) plus a group and a user it applies to. Good for practising account-level IAM settings. | IAM |
| Break-glass admin role with tight trust | An emergency administrator role that only a named break-glass user can assume, with a one-hour session cap and a log group for access notes. Good for modelling emergency access. On AWS you would also require MFA in the trust policy. The emulator never sets aws:MultiFactorAuthPresent, so this trust leaves it out, and the emulator does not hold sessions to the one-hour cap. | IAM, CloudWatch |
| Cross-account style assume-role with external ID | A role whose trust policy lets another account’s principals assume it only when an external ID is presented, plus a caller user allowed to call sts:AssumeRole. Good for practising role chaining and trust policy reading. | IAM, STS |
| Group policy that denies everything without MFA | An IAM group whose policy allows self-service MFA setup and denies every other action unless the caller signed in with MFA, plus a user in the group. The emulator never sets aws:MultiFactorAuthPresent, so here every caller counts as signed in without MFA: the user can set up MFA and every other call is denied. Good for practising the deny side of the condition. | IAM |
| OIDC provider and role for GitHub Actions | An IAM OIDC identity provider for GitHub Actions and a role that web-identity federation can assume only from one repository and branch. Good for studying keyless CI/CD federation trust conditions. | IAM, STS |
| Permission boundary capping a developer role | A developer role with broad inline permissions, capped by a permission boundary that only allows S3, SQS and DynamoDB, plus a user with the same boundary. Good for showing how boundaries limit effective access. | IAM |
| Least-privilege EC2 role for one S3 bucket | An IAM role EC2 can assume, with an inline policy that only reads one S3 bucket, plus an instance profile. A model of least-privilege access for a server. | IAM, S3, EC2 |
| Service roles for Lambda, ECS tasks and Glue | Three IAM roles under the /service-role/ path, each trusted by one AWS service and attached to its AWS-managed policy style permissions. Good for comparing service trust policies and role paths. | IAM |
| IAM users in groups with managed policies | Three IAM users spread across developers, operators and auditors groups, each group with its own customer-managed policy. Good for practising user, group and policy membership queries with the AWS CLI. | IAM |
| EC2 role and profile for SSM Session Manager | An EC2 role with SSM core agent permissions, an instance profile, and three SSM parameters an operator would read. Good for exploring SSM-managed instance setup and parameter paths. | IAM, SSM, EC2 |
Monitoring
Section titled “Monitoring”| Sample | What it builds | Services |
|---|---|---|
| Detect access-key abuse and credential persistence | A detection lab pairing with security-lab-iam-access-key-backdoor. Seeds CloudTrail-shaped JSON logs in S3 with CreateAccessKey, CreateLoginProfile and UpdateLoginProfile events on privileged users, a Glue table and Athena workgroup for SQL hunting, plus an EventBridge rule routing those IAM calls to an SNS topic. The learner spots backup credentials planted to survive a key rotation. | CloudTrail, S3, Glue, Athena, EventBridge, SNS, IAM |
| Detect CloudTrail tampering (StopLogging and DeleteTrail) | A detection lab pairing with security-lab-cloudtrail-stoplogging. Seeds CloudTrail-shaped JSON logs in S3 with StopLogging, DeleteTrail, PutEventSelectors and UpdateTrail events, a Glue table and Athena workgroup for SQL hunting, plus an EventBridge rule routing those trail-tampering calls to an SNS topic. The learner spots anti-forensics: an attacker blinding the trail. | CloudTrail, S3, Glue, Athena, EventBridge, SNS |
| Detect IAM privilege escalation by policy edit | A detection lab pairing with the privesc labs (security-lab-iam-privesc-policy-write and -passrole-escalation). Seeds CloudTrail-shaped JSON logs in S3 with AttachUserPolicy, PutUserPolicy, CreatePolicyVersion and SetDefaultPolicyVersion events, a Glue table and Athena workgroup for SQL hunting, plus an EventBridge rule routing those IAM calls to an SNS topic. The learner spots self-granted admin. | CloudTrail, S3, Glue, Athena, EventBridge, SNS, IAM |
| Detect root usage and risky console sign-ins | A detection lab for risky authentication. Seeds CloudTrail-shaped JSON logs in S3 with root-account usage and ConsoleLogin events where MFA was absent (plus a failed root sign-in), with a Glue table and Athena workgroup for SQL hunting, plus an EventBridge rule routing console sign-in events to an SNS topic. The learner spots root logins and no-MFA sign-ins that signal account takeover. | CloudTrail, S3, Glue, Athena, EventBridge, SNS |
| Detect S3 public-exposure changes from CloudTrail | Detection lab pairing security-lab-public-s3-bucket. An S3 bucket is seeded with CloudTrail-style JSON of a bucket being made public (public-access-block off, a Principal * PutBucketPolicy, a public-read PutBucketAcl) then anonymous reads, with a Glue table and Athena workgroup over the logs and an EventBridge rule on those events to SNS. The learner hunts the exposure in Athena. | CloudTrail, S3, Glue, Athena, EventBridge, SNS |
| Detect credential harvesting from secret-access logs | Detection lab pairing the secrets labs (open Secrets Manager secret, leaked SSM keys). An S3 bucket is seeded with CloudTrail-style JSON where one principal reads every secret and decrypts every SSM parameter in a short burst against normal use. A Glue table and Athena workgroup cover the logs; an EventBridge rule on GetSecretValue and GetParameter routes to SNS. The learner spots the burst. | CloudTrail, SecretsManager, SSM, S3, Glue, Athena, EventBridge, SNS |
| Athena IR hunt pack over a seeded intrusion | Incident-response lab pairing seed-cloudtrail-log-corpus. An S3 bucket is seeded with CloudTrail-style JSON of a full intrusion: recon from an outside IP, access-key creation, an admin policy change, crown-jewels access and copy-out, then StopLogging and DeleteTrail. A Glue table and Athena workgroup sit over the logs, with a six-step .sql hunt-query pack. The learner runs them to reconstruct it. | CloudTrail, S3, Glue, Athena |
| Triage and route seeded GuardDuty-style findings | Managed-detection triage lab. Seeded findings: there is no live detection engine, so this teaches triage and routing, not detection. Five GuardDuty-shaped findings sit in S3 as JSON and a DynamoDB table holds a row per finding (severity, type, resource) with a GSI on severity label. An EventBridge rule and SNS topic show how real findings would route. The learner triages and prioritizes them. | S3, DynamoDB, EventBridge, SNS |
| CIS-style detections as EventBridge rules | Four EventBridge rules on CloudTrail events (denied API calls, security group changes, S3 policy changes, console login without MFA) that notify an SNS security topic. A compact take on the CIS monitoring controls without metric filters. | EventBridge, CloudTrail, SNS |
| EventBridge rules on CloudTrail IAM and root-login events | Two EventBridge rules that match CloudTrail records (IAM policy and key changes, and root console sign-in) and send them to an SNS security topic whose policy allows EventBridge. A starting point for detection-as-code. | EventBridge, CloudTrail, SNS |
| CloudWatch agent configs in SSM parameters | Linux and Windows CloudWatch agent configurations stored as SSM parameters, the log groups they ship to, and an instance profile with the CloudWatch agent policy. Good for exploring how server telemetry is configured. | CloudWatch, SSM, IAM |
| CloudWatch dashboard with metric and alarm widgets | A CloudWatch dashboard for a checkout service with text, latency, error and alarm-status widgets, backed by two metric alarms and an SNS topic. Good for exploring dashboards and alarms with the AWS CLI. | CloudWatch, SNS |
| KMS-encrypted CloudWatch log groups | A rotating customer-managed KMS key with a policy that lets CloudWatch Logs use it, an alias, and two log groups (app and audit) encrypted with it. A baseline for encrypting logs at rest. | CloudWatch, KMS |
| Metric math error-rate alarm and traffic-drop alarm | An alarm that computes an error percentage from two custom metrics with metric math, a second alarm that fires when traffic drops, an SNS topic for alerts, and an application log group. Good for learning alarm expressions. | CloudWatch, SNS |
| Alarms on DynamoDB and SNS built-in metrics | A DynamoDB orders table with alarms on throttled requests and system errors, an SNS ops topic with a delivery-failure alarm, and a dashboard showing all alarm states. A model of watching managed-service health. | CloudWatch, DynamoDB, SNS |
| SNS alarm topic with CloudWatch publish policy | An SNS topic that only CloudWatch in this account may publish to, an email subscription for the on-call address, and two alarms (backlog depth and missing heartbeat) that notify it. Good for practising alarm routing. | SNS, CloudWatch |
Security labs
Section titled “Security labs”| Sample | What it builds | Services |
|---|---|---|
| Security lab: CloudTrail trail with logging switched off | A deliberately vulnerable lab: a CloudTrail trail exists but logging is stopped, and its log bucket has no versioning or encryption. Teaches checking get-trail-status, not just trail existence, and why a silent trail leaves an attacker’s actions unrecorded. | CloudTrail, S3 |
| Security lab: attacker who can switch off CloudTrail | A deliberately vulnerable lab: an enabled multi-region CloudTrail trail writes to an S3 bucket seeded with log-shaped objects, and an IAM user may call cloudtrail:StopLogging, cloudtrail:DeleteTrail and s3:DeleteObject on the log bucket. Teaches anti-forensics: an attacker with these rights blinds detection and erases evidence, so trail controls and log buckets need their own guardrails. | CloudTrail, S3, IAM |
| Security lab: self-signup Cognito with an over-privileged role | A deliberately vulnerable lab: a Cognito user pool that lets anyone self-register, an identity pool federating it, and an authenticated IAM role that grants broad S3 read across every bucket. Teaches how open sign-up plus a loose identity-pool role lets any stranger mint real AWS credentials and reach data, including a flag object, that the app role should never expose. | Cognito, IAM, S3 |
| Security lab: IAM access-key and login-profile backdoor | A deliberately vulnerable lab: a low-privilege user is allowed iam:CreateAccessKey and iam:CreateLoginProfile on an admin user, so it can mint a second key or a console password for that admin and take over. The admin already carries one stale, forgotten key to discover. Teaches credential-based persistence and least privilege on IAM write actions. | IAM |
| Security lab: four bypassable IAM policy conditions | A deliberately vulnerable lab: four S3 grants are each guarded by a condition written the wrong way. ForAllValues passes on an empty key set, a Null check is inverted, a StringLike ARN wildcard is too broad, and StringEqualsIfExists fails open for untagged callers. Teaches how each operator is bypassed. The emulator never sets aws:PrincipalTag, so the fourth guard passes every caller. | IAM, S3 |
| Security lab: iam:PassRole privilege escalation path | A deliberately vulnerable lab: a low-level developer user may iam:PassRole on any role and create Lambda functions, and an admin-powered Lambda execution role exists. Teaches the PassRole escalation path and why PassRole must be scoped to specific role ARNs. | IAM, Lambda |
| Security lab: six IAM policy-write privilege escalation primitives | A deliberately vulnerable lab: six low-privilege users each hold exactly one IAM write primitive (CreatePolicyVersion, SetDefaultPolicyVersion, AttachUserPolicy, PutUserPolicy, AddUserToGroup, UpdateAssumeRolePolicy) that escalates to admin. Access keys for all six are sensitive outputs, and a flag sits in an SSM parameter only an admin can read. Teaches that write access to IAM is admin access. | IAM, SSM |
| Security lab: EC2 instance with IMDSv1 and a powerful role | A deliberately vulnerable lab: an instance with the metadata service set to optional tokens (IMDSv1) and an instance profile that can read a bucket of fake secrets. Teaches why SSRF plus IMDSv1 leaks role credentials. The instance is a record with no VM, so describe-instances shows the setting; live theft needs a VM added with register-as-instance, which allows IMDSv1 by default. | EC2, IAM, S3 |
| Security lab: over-broad KMS grant hidden from an IAM review | A deliberately vulnerable lab: a KMS key whose policy delegates to IAM, set as a records bucket’s default encryption, an analytics role with no KMS rights in IAM, and an over-broad grant giving that role Decrypt and Encrypt. On AWS the grant is a second door an IAM review misses. The emulator stores grants and key policies but never checks them, so here the lab is finding the grant (list-grants). | KMS, IAM, S3 |
| Security lab: Lambda code-overwrite persistence | A deliberately vulnerable lab: a real Python 3.12 function runs on an over-broad execution role, carries a secret in an environment variable and is invoked on an EventBridge schedule. Anyone who can update the function code inherits the role and a recurring trigger, so overwriting the code is durable persistence. Teaches why update-code rights plus a wide role plus a schedule equal a backdoor. | Lambda, IAM, EventBridge, S3, CloudWatch |
| Security lab: live Lambda iam:PassRole escalation to admin | A deliberately vulnerable lab: a developer user may iam:PassRole an admin role and create or update Lambda functions, and that admin role can read a flag in SSM. A real Python 3.12 function is already deployed on the admin role, so the learner can overwrite its code or deploy a new function to run as admin and read the flag. Teaches why PassRole must be scoped to specific role ARNs. | IAM, Lambda, SSM, S3 |
| Security lab: fake access keys leaked in SSM parameters | A deliberately vulnerable lab: fake, scanner-safe access keys and a database password sit in plain String SSM parameters that a broad read policy exposes. Teaches why secrets belong in SecureString or Secrets Manager and how to hunt for them with ssm get-parameters-by-path. | SSM, IAM |
| Security lab: Secrets Manager secret readable by any principal | A deliberately vulnerable lab: a database credential secret whose resource policy allows secretsmanager:GetSecretValue to Principal *, plus a second secret for comparison. Teaches auditing secret resource policies and why access should be limited to named roles. The emulator stores secret policies but never checks them, so here a caller’s IAM policy alone decides who reads a secret. | SecretsManager |
| Security lab: SQS queue open to any principal | A deliberately vulnerable lab: an orders queue whose policy allows send, receive and delete from Principal *. Teaches spotting an open queue policy, which on AWS lets outsiders read or poison messages, and why queue policies should name specific principals. The emulator stores queue policies but never checks them, so here a caller’s IAM policy alone decides who uses the queue. | SQS, IAM |
| Security lab: SSH and RDP open to the whole internet | A deliberately vulnerable lab: a VPC with a public subnet, a security group allowing SSH and RDP from 0.0.0.0/0, and an instance behind it. Teaches how to spot world-open admin ports with describe-security-groups and why access should come from a bastion or VPN range. | VPC, EC2 |
| Security lab: KMS key whose policy trusts any principal | A deliberately vulnerable lab: a customer-managed KMS key whose key policy allows kms:* to Principal *, set as the default encryption of a bucket of fake records. Teaches spotting a key policy that trusts everyone and why key policies should name specific roles. The emulator stores key policies but never checks them, so here a caller’s IAM policy alone decides its KMS access. | KMS, S3 |
| Security lab: publicly exposed S3 bucket | A deliberately vulnerable lab: a bucket with public access block off, a public-read policy and a fake credentials.txt object. Use it to practise finding and fixing storage exposure. | S3 |
| Security lab: SNS topic open to any principal | A deliberately vulnerable lab: an alerts topic whose policy lets any principal publish and subscribe, next to a properly locked topic for comparison. Teaches how Principal * on a topic policy lets outsiders spoof alerts or read them, and how to fix it with account conditions. | SNS |
| Security lab: an estate of guessable backup buckets | A deliberately vulnerable lab: five S3 buckets with predictable names holding fake backups, SQL dumps and snapshots, a replication-style copy in a dr bucket, and a versioned dump whose current object looks sanitized while an older retained version still holds a secret. Teaches bucket-name enumeration and digging through object versions with list-object-versions to recover a flag. | S3 |
| Security lab: hardcoded secrets in user-data, Lambda env, and SSM | A deliberately vulnerable lab: the same style of credential is leaked three ways, in an EC2 launch template’s user-data script, in a Lambda environment variable, and in a plain SSM String parameter. A reader user can describe the template, read the function config, and get the parameter. All values are fake placeholders. Teaches where secrets hide and why they belong in a secrets store. | EC2, Lambda, SSM, IAM, S3 |
| Security lab: data stores full of fake PII | A deliberately vulnerable lab: a DynamoDB table loaded with fake customer PII rows (names, emails, fake SSNs and card numbers) including a flag item, a real small RDS PostgreSQL instance in private subnets, and a read-scoped IAM user. Teaches locating and reading sensitive records with scan and query, and why read access to a data store is enough to exfiltrate it all. | DynamoDB, RDS, IAM, EC2 |
| Security lab: open SNS and SQS loaded with real messages | A deliberately vulnerable lab: an SNS topic and an SQS queue whose policies both allow Principal *, joined by a subscription, and a Lambda that publishes sensitive-looking messages on invoke. The emulator checks the topic policy, so anyone can subscribe an endpoint of its own to read messages or publish spoofed ones. It never checks the queue policy, so reading the queue takes an IAM grant. | SNS, SQS, Lambda, IAM |
| Security lab: three-hop STS role chain with a confused-deputy variant | A deliberately vulnerable lab: a user assumes role A, A assumes role B (gated by an sts:ExternalId), B assumes role C, and C reads a flag object in a bucket. Beside the correct hop sits a confused-deputy role that trusts a vendor account with no ExternalId, so any tenant the vendor serves can assume it and reach the flag. Teaches role chaining and why cross-account trust needs ExternalId. | STS, IAM, S3 |
| Security lab: unencrypted bucket of fake PII | A deliberately vulnerable lab: an S3 bucket with no default encryption, no versioning and no access logging, holding an obviously fake customer CSV and a fake HR file. Teaches data-at-rest, data classification and how to audit buckets for missing controls. | S3 |
| Security lab: IAM user with wildcard admin policy | A deliberately vulnerable lab: an IAM user holds Action * on Resource * via a managed policy, and an intern inherits the same power through a group. Teaches why wildcard admin policies defeat least privilege and how to find them with IAM policy reviews. | IAM |
| Security lab: public-write bucket serving a static site | A deliberately vulnerable lab: an S3 static website whose bucket policy grants s3:GetObject and s3:PutObject to Principal * with no Deny, so anyone can overwrite the served app.js. Teaches a client-side supply-chain attack where an attacker tampers with content delivered to every visitor, and why write must never be public. A flag sits in the page. | S3 |
DevOps
Section titled “DevOps”| Sample | What it builds | Services |
|---|---|---|
| CI artifact bucket encrypted with KMS | A versioned, public-blocked S3 artifact bucket for build pipelines, encrypted with a rotating KMS key, with a 30-day lifecycle on builds and a CodeBuild-style pipeline role limited to that bucket and key. | S3, KMS, IAM |
| ECS cluster with a Fargate task definition | An ECS cluster with Fargate capacity providers, task execution and task roles, a log group, and a Fargate task definition for an nginx container. No service is created, so it is a registry of what could run. | ECS, IAM, CloudWatch |
| Release event bus with SNS and log notifications | A custom EventBridge bus with a rule that matches deployment succeeded or failed events and fans them out to an SNS topic and a log group. A small release-notification path for CI/CD ranges. | EventBridge, SNS, CloudWatch |
| SSM parameters as release configuration | A /dvrel/release parameter tree holding the current and previous version, canary percentage, rollout strategy and feature flags, plus an encrypted deploy token and a read-only IAM policy. Shows release config kept out of code. | SSM, IAM |
| Terraform from an archive in Images and files | Applies every Terraform archive (name.tf.tgz or name.tf.tar.gz) uploaded to the VPC’s Images and files with terraform init and apply on the region box, offline with hashicorp/aws 6.66.0 and the region box’s provider settings (an aliased aws provider gets none), keeping each archive’s state between builds. By hand: CLOUD_FILES_DIR=/path/to/uploads bash terraform-from-files.sh. | S3 |
Kubernetes
Section titled “Kubernetes”| Sample | What it builds | Services |
|---|---|---|
| EKS cluster for the mesh samples | The EKS cluster mesh (Kubernetes 1.35) that every Kubernetes sample installs into; add it first. By hand: terraform init && terraform apply, bash eks-cluster.sh, then bash /opt/roguecloudos/eks-checks/eks-cluster-check.sh. Measured offline: the empty cluster peaks at 0.70 GiB of memory; all eight Kubernetes samples together peak at 3.46 GiB with the region; CPU needs size Large. | EKS, VPC, IAM |
| Envoy mTLS with RBAC and ext_authz on caller identity | Envoy mTLS sidecars where RBAC authorizes callers by SPIFFE URI SAN or by subject (CN, OU), plus an ext_authz variant that asks a small policy service. Needs eks-cluster. By hand: bash envoy-authz.sh, then bash /opt/roguecloudos/eks-checks/envoy-authz-check.sh. Measured offline with eks-cluster: 1.59 GiB peak memory with the region; fits region size Standard. | EKS |
| Envoy sidecars with cert-manager certificates and SDS rotation | Envoy with 1-hour cert-manager certificates (csi-driver) reloaded by file SDS; the check rolls the CA over under traffic. Needs eks-cluster. By hand: bash envoy-cert-manager-sds.sh, then bash /opt/roguecloudos/eks-checks/envoy-cert-manager-sds-check.sh. Measured offline with eks-cluster: 1.99 GiB peak memory with the region; CPU needs size Large. | EKS, ECR |
| Envoy node proxy with CRL revocation (Stripe-shaped) | One Envoy per node (DaemonSet, host network) reached by pods over a Unix socket; subject identity (CN service, OU role) and a CRL revocation drill. Needs eks-cluster. By hand: bash envoy-node-proxy.sh, then bash /opt/roguecloudos/eks-checks/envoy-node-proxy-check.sh. Measured offline with eks-cluster: 1.48 GiB peak memory with the region; fits region size Standard. | EKS |
| Envoy sidecars with static mTLS certificates | Envoy sidecars with mutual TLS on a three-service demo app; openssl mints the CA and SPIFFE certificates, mounted as files. Needs eks-cluster. By hand: bash envoy-sidecar-static.sh, then bash /opt/roguecloudos/eks-checks/envoy-sidecar-static-check.sh. Measured offline with eks-cluster: 1.53 GiB peak memory with the region; fits region size Standard. | EKS |
| Envoy with an xDS control plane on Consul (Stripe-shaped) | Consul and meshcp, an ADS control plane that validates each config with Envoy before pushing and restores from S3. Needs eks-cluster. By hand: terraform init && terraform apply, bash envoy-xds-consul.sh, then bash /opt/roguecloudos/eks-checks/envoy-xds-consul-check.sh. Measured offline with eks-cluster: 1.97 GiB peak memory with the region; fits region size Standard. | EKS, ECR, S3 |
| Istio with strict mTLS and service-account authorization | Istio with strict mutual TLS on the demo app and an AuthorizationPolicy per service allowing only its caller’s service account. Needs eks-cluster. By hand: bash istio-strict.sh, then bash /opt/roguecloudos/eks-checks/istio-strict-check.sh. Measured offline with eks-cluster: 2.00 GiB peak memory with the region; fits region size Standard. | EKS, ECR |
| Smokescreen egress proxy with mTLS client roles | Smokescreen as the only egress, enforced by a NetworkPolicy; the mTLS client’s CN picks an allow-list that moves from report to enforce. Needs eks-cluster. By hand: bash smokescreen-egress.sh, then bash /opt/roguecloudos/eks-checks/smokescreen-egress-check.sh. Measured offline with eks-cluster: 1.44 GiB peak memory with the region; fits region size Standard. | EKS |