<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>AWS CDK Reference Architectures</title>
    <link>https://ishiharatma.github.io/aws-cdk-reference-architectures/</link>
    <description>Newly published and newly deploy-verified AWS CDK reference architectures.</description>
    <language>en</language>
    <lastBuildDate>Fri, 23 Oct 2026 16:02:23 GMT</lastBuildDate>
    <item>
      <title>Amazon ECS Gateway: shared ingress owned by the platform team, opted into by services</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecs-gateway-shared-ingress</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecs-gateway-shared-ingress</guid>
      <pubDate>Fri, 23 Oct 2026 12:00:00 GMT</pubDate>
      <description>Two Amazon ECS Gateways (internet-facing with WAF, access logs and its own inbound security group; internal) are associated with one cluster, and Fargate services opt in with a gateway connector only. ECS provisions the shared ALBs, per-service ACM certificates, *.ecs.&lt;region&gt;.on.aws hostnames, listener rules and target groups. Written with CfnResource because aws-cdk-lib has no L1 yet.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>ECS</category>
      <category>ECS Gateway</category>
      <category>Fargate</category>
      <category>ALB</category>
      <category>AWS WAF</category>
      <category>ACM</category>
    </item>
    <item>
      <title>AWS WAF mitigations for PHP2Shell (CVE-2026-109618 / 109619) verified on CloudFront and ALB</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/waf-php2shell-mitigation</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/waf-php2shell-mitigation</guid>
      <pubDate>Thu, 22 Oct 2026 12:00:00 GMT</pubDate>
      <description>The four AWS WAF custom rules from the AWS Security Blog applied to both CloudFront (body inspection raised to 64 KB) and an ALB (fixed 8 KB) in front of a patched PHP-FPM 8.4.27 origin on a Lambda container image. Deploy-verified: rule conditions, the exact 8 / 16 / 64 KB inspection boundaries, false positives, per-layer oversize thresholds, rate-rule lag, origin lockdown with the CloudFront prefix list and a shared-secret header, and Count headers echoed by the origin.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>AWS WAF</category>
      <category>CloudFront</category>
      <category>ALB</category>
      <category>Lambda</category>
      <category>Lambda Web Adapter</category>
      <category>PHP</category>
      <category>Security</category>
    </item>
    <item>
      <title>Human-in-the-loop approval workflow on Lambda durable functions</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/lambda-durable-functions-approval</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/lambda-durable-functions-approval</guid>
      <pubDate>Wed, 21 Oct 2026 12:00:00 GMT</pubDate>
      <description>A submit / approve / expire business flow written as one Lambda durable function: executions start asynchronously with an idempotent DurableExecutionName through a published-version alias, wait up to 48 hours for an approver with waitForCallback (no compute while suspended) and resume from checkpoints when the decision API sends the callback. Shows the durable-specific rules in code and infrastructure: deterministic replay, retained versions for in-flight executions, at-least-once steps with conditional DynamoDB writes, a DynamoDB status projection instead of the 30 rps GetDurableExecution API, and failure detection through EventBridge status-change events plus a DLQ. Deploy-verified, including the observation that an asynchronous retry with a different payload is not rejected but lands in the DLQ. An optional demo web UI (Cognito managed login, identity pool roles per group, CloudFront + S3) calls the same IAM-authorized API with SigV4.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Lambda</category>
      <category>Lambda durable functions</category>
      <category>API Gateway</category>
      <category>DynamoDB</category>
      <category>SNS</category>
      <category>EventBridge</category>
      <category>Cognito</category>
      <category>CloudFront</category>
      <category>Serverless</category>
    </item>
    <item>
      <title>Lambda Web Functions (Express.js) behind CloudFront + OAC</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/lambda-web-functions-express</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/lambda-web-functions-express</guid>
      <pubDate>Thu, 15 Oct 2026 12:00:00 GMT</pubDate>
      <description>The same Todos REST API as the apigw-* series, served by a plain Express.js server running as an AWS Lambda Web Function: no API Gateway, no adapter, no handler. The IamAuth endpoint only accepts CloudFront OAC-signed requests and WAF sits on CloudFront. Deploy-verified: multi-concurrency (100 requests on 3 environments once warm), dynamic per-environment limits vs maxEnvironments throttling, SSE through CloudFront, 90/10 canary weights, a zero-error revision rollout, optional VPC egress through a network connector, and a head-to-head run against the API Gateway + Lambda Web Adapter version.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Lambda Web Functions</category>
      <category>Lambda</category>
      <category>CloudFront</category>
      <category>WAF</category>
      <category>DynamoDB</category>
      <category>Express</category>
      <category>Serverless</category>
    </item>
    <item>
      <title>ECS Blue/Green: Native versus CodeDeploy</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecs-blue-green-native-vs-codedeploy</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecs-blue-green-native-vs-codedeploy</guid>
      <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
      <description>The same application deployed blue/green with native ECS (deploymentStrategy BLUE_GREEN) and with CodeDeploy, side by side behind ALBs with a production and a test listener, and driven through the same four deployments: a good release, a failing lifecycle hook, a rollback during the bake period and a container that never starts. Deploy-verified with a 5 requests-per-second probe: no HTTP error on either flavor, rollback to the old version in 20 s (native) and 14 s (CodeDeploy), and neither gave up on the broken release within 7 minutes.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>ECS</category>
      <category>Fargate</category>
      <category>Blue/Green</category>
      <category>CodeDeploy</category>
      <category>ALB</category>
      <category>Deployment</category>
      <category>Lambda</category>
    </item>
    <item>
      <title>RDS Multi-AZ versus a Read Replica</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/rds-multiaz-vs-read-replica</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/rds-multiaz-vs-read-replica</guid>
      <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
      <description>The two RDS features people confuse most, side by side on one PostgreSQL database and measured by a probe Lambda in the VPC: the Multi-AZ standby is invisible and synchronous, the replica is readable and asynchronous (median 7 ms behind), refuses writes, survives a Multi-AZ failover of the primary (13 s write outage, 0 s read outage) and, once promoted, is an independent database. Documents why the ReplicaLag metric climbs on an idle PostgreSQL primary and what a heartbeat does to it.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>RDS</category>
      <category>PostgreSQL</category>
      <category>Multi-AZ</category>
      <category>Read Replica</category>
      <category>High Availability</category>
      <category>Lambda</category>
    </item>
    <item>
      <title>Data Lake with AWS Glue and Amazon Athena</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/data-lake-glue-athena</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/data-lake-glue-athena</guid>
      <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
      <description>Raw CSV to cleaned, de-duplicated, partitioned Parquet with a Glue workflow (crawler, Spark job, crawler), queried with an Athena workgroup that enforces encrypted results and a per-query scan limit. Deploy-verified with generated data: 59,770 valid orders from 60,600 raw rows, Parquet scanning 7% of the CSV bytes, partition pruning, and an idempotent rerun when a new day arrives. Documents why a crawler&apos;s string partition key rejects DATE literals.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Glue</category>
      <category>Athena</category>
      <category>Data Lake</category>
      <category>Parquet</category>
      <category>S3</category>
      <category>ETL</category>
      <category>Data Catalog</category>
    </item>
    <item>
      <title>Bedrock Knowledge Base RAG on Amazon S3 Vectors</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/bedrock-kb-rag-s3-vectors</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/bedrock-kb-rag-s3-vectors</guid>
      <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
      <description>A retrieval-augmented generation API on Amazon Bedrock Knowledge Bases with S3 Vectors as the vector store, so there is no idle vector cluster. A SigV4-signed HTTP API answers with citations, filters by a metadata attribute, keeps a conversation through a session ID and exposes retrieval alone for tuning. Deploy-verified with golden questions, an out-of-corpus question, the metadata filter and a follow-up turn; about 0.5 s per retrieval and 1.8 s per answer. Documents why Bedrock&apos;s chunk-text keys must be non-filterable and why a caller-supplied filter is not access control.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Bedrock</category>
      <category>Knowledge Bases</category>
      <category>RAG</category>
      <category>S3 Vectors</category>
      <category>Claude</category>
      <category>Lambda</category>
      <category>API Gateway</category>
    </item>
    <item>
      <title>Security Baseline: CloudTrail, Config, GuardDuty, Access Analyzer &amp; Security Hub</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/security-baseline</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/security-baseline</guid>
      <pubDate>Sat, 10 Oct 2026 12:00:00 GMT</pubDate>
      <description>A single-account security baseline in one CDK stack, with opt-in automatic remediation: a multi-Region CloudTrail trail and AWS Config recorder with managed rules delivering to a hardened S3 log archive, a GuardDuty detector with optional protection plans, IAM Access Analyzer, and Security Hub subscribed to AWS Foundational Security Best Practices, with new high-severity findings emailed through EventBridge and SNS. Deploy-verified end-to-end; the Config recorder/delivery channel are created via AwsCustomResource to work around a CloudFormation circular-dependency limitation. Automatic remediation (dry-run by default, skip tag) blocks S3 public access, revokes open SSH/RDP rules and isolates GuardDuty-flagged EC2 instances; verified with real resources and Security Hub findings.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Security</category>
      <category>CloudTrail</category>
      <category>Config</category>
      <category>GuardDuty</category>
      <category>Access Analyzer</category>
      <category>Security Hub</category>
      <category>Remediation</category>
      <category>Lambda</category>
      <category>EventBridge</category>
    </item>
    <item>
      <title>code-server on EC2 vs AWS Lambda MicroVMs: The Same Browser IDE on Two Compute Models, with Claude Code on Bedrock</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/code-server-ec2-vs-lambda-microvms</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/code-server-ec2-vs-lambda-microvms</guid>
      <pubDate>Thu, 08 Oct 2026 12:00:00 GMT</pubDate>
      <description>VS Code in the browser (code-server) on two compute models in one CDK app: an always-on EC2 instance behind CloudFront, and an on-demand AWS Lambda MicroVM that suspends when idle. A local relay injects the X-aws-proxy-auth token so a browser can reach the MicroVM endpoint, including WebSockets. Claude Code (CLI and extension) is wired to Amazon Bedrock through role credentials on both. Deploy-verified: MicroVM start in 3 to 16 seconds, resume after suspend in 0.65 seconds.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Lambda MicroVMs</category>
      <category>EC2</category>
      <category>CloudFront</category>
      <category>code-server</category>
      <category>Bedrock</category>
      <category>Secrets Manager</category>
      <category>Systems Manager</category>
    </item>
    <item>
      <title>Transfer Family SFTP with a Custom Identity Provider: SSH Key Auth + Source IP Allow List</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/transfer-sftp-custom-idp</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/transfer-sftp-custom-idp</guid>
      <pubDate>Tue, 06 Oct 2026 12:00:00 GMT</pubDate>
      <description>An AWS Transfer Family SFTP server on a PUBLIC endpoint where a Lambda custom identity provider authenticates SSH public keys from a DynamoDB user table (AWS custom IdP solution layout) and rejects logins from IPs outside each user&apos;s allow list. Per-user S3 isolation via LOGICAL home directories and a session policy, CloudShell shell scripts for user and key management, fail-closed behavior, three run modes (always on, scheduled, manual: the server is deleted while off because a stopped server is still billed), and alarms with SNS for auth failures, IP denials, IdP errors and transfer volume. Deploy-verified with 31 real SFTP checks.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Transfer Family</category>
      <category>SFTP</category>
      <category>Lambda</category>
      <category>DynamoDB</category>
      <category>S3</category>
      <category>Security</category>
      <category>CloudWatch</category>
      <category>EventBridge Scheduler</category>
    </item>
    <item>
      <title>Transit Gateway Centralized Inspection with AWS Network Firewall</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/tgw-network-firewall-inspection</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/tgw-network-firewall-inspection</guid>
      <pubDate>Sun, 04 Oct 2026 12:00:00 GMT</pubDate>
      <description>One AWS Network Firewall inspects both internet-bound and east-west traffic of two spoke VPCs that have no internet route of their own: a Transit Gateway with two route tables and an appliance-mode attachment hands every flow to an inspection VPC, where a domain allow list, east-west pass/drop rules and a NAT gateway apply. Deploy-verified over SSM: allowed domain 200, other domain blocked, east-west TCP passes, east-west ICMP dropped, both drops in the alert log. Documents why a domain allow list also drops east-west HTTP unless a pass rule precedes it.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Network Firewall</category>
      <category>Transit Gateway</category>
      <category>VPC</category>
      <category>NAT Gateway</category>
      <category>Security</category>
      <category>Networking</category>
    </item>
    <item>
      <title>Multi-Region Disaster Recovery: Four Strategies Compared</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/multi-region-dr-strategies</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/multi-region-dr-strategies</guid>
      <pubDate>Sun, 04 Oct 2026 12:00:00 GMT</pubDate>
      <description>The four AWS disaster recovery strategies (backup and restore, pilot light, warm standby, multi-site active-active) built for the same orders API in Tokyo and Osaka and measured with a drill script. Global tables replicate in about 1 s; measured RTO is about 34 s (active-active), 36 s (warm standby), 84 s (pilot light) and 6 minutes or more (backup and restore). Includes a strategy decision guide and idle-cost comparison.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Disaster Recovery</category>
      <category>DynamoDB</category>
      <category>Global Tables</category>
      <category>Route 53</category>
      <category>AWS Backup</category>
      <category>Multi-Region</category>
      <category>Lambda</category>
    </item>
    <item>
      <title>Route 53 Failover Routing with Health Checks</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/route53-failover-health-check</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/route53-failover-health-check</guid>
      <pubDate>Sat, 03 Oct 2026 12:00:00 GMT</pubDate>
      <description>DNS failover in its basic form: a PRIMARY record guarded by a Route 53 health check and a SECONDARY record that takes over when it fails, with two Lambda function URLs as endpoints and no domain or load balancer needed. A resolver Lambda inside the VPC resolves the private-zone record, and a check script breaks the primary and measures the switch. Deploy-verified: failover in 29 s and failback in 18 s with a 10 s interval, threshold 2 and TTL 10 s.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Route 53</category>
      <category>Health Check</category>
      <category>Failover</category>
      <category>DR</category>
      <category>Lambda</category>
    </item>
    <item>
      <title>API Gateway REST API to a Private ALB over a VPC Link (ECS Fargate)</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-vpclink-private-alb</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-vpclink-private-alb</guid>
      <pubDate>Sat, 03 Oct 2026 12:00:00 GMT</pubDate>
      <description>Publish a private ECS Fargate service only through API Gateway: a REST API with API key, usage plan and throttling reaches an internal ALB through a VPC link v2 with no NLB in between. The ALB&apos;s security group accepts the VPC link only, so the API key cannot be bypassed. Deploy-verified end to end with a check script: 403 without a key, 200 through the VPC link, load spread across tasks, ALB unreachable from outside, 429 under burst.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>API Gateway</category>
      <category>VPC Link</category>
      <category>ALB</category>
      <category>ECS</category>
      <category>Fargate</category>
      <category>Usage Plan</category>
      <category>Security</category>
    </item>
    <item>
      <title>FIS Chaos: RDS Multi-AZ DB Instance vs. Multi-AZ DB Cluster (PostgreSQL)</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-i-rds-multiaz</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-i-rds-multiaz</guid>
      <pubDate>Fri, 02 Oct 2026 12:00:00 GMT</pubDate>
      <description>Three AWS FIS chaos experiment templates comparing the two plain-RDS Multi-AZ topologies: forced failover of a Multi-AZ DB instance (aws:rds:reboot-db-instances, forceFailover=true), failover of a Multi-AZ DB cluster (aws:rds:failover-db-cluster), and a no-failover reboot as the control group. A VPC probe Lambda opens a new PostgreSQL connection per second to both endpoints and reports client-visible outage windows and server-IP changes. Deploy-verified: ~13-14 s for both failovers, 7 s for the plain reboot on idle small DBs.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FIS</category>
      <category>Chaos Engineering</category>
      <category>RDS</category>
      <category>PostgreSQL</category>
      <category>Multi-AZ</category>
      <category>Failover</category>
      <category>Lambda</category>
    </item>
    <item>
      <title>Serverless Codex App Server on AWS Lambda MicroVMs</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/lambda-microvms-codex-appserver</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/lambda-microvms-codex-appserver</guid>
      <pubDate>Sun, 27 Sep 2026 12:00:00 GMT</pubDate>
      <description>An on-demand, VM-isolated Codex App Server per session on AWS Lambda MicroVMs: a control plane of 10 Lambda functions (7 HTTP + 3 WebSocket) brokers session lifecycle, and output is delivered by both polling and a WebSocket push path. The MicroVM image and network connector are defined in CloudFormation. Deploy-verified end-to-end (session creation through a real codex app-server JSON-RPC handshake and DynamoDB event persistence), with 6 real bugs found and fixed.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Lambda</category>
      <category>MicroVMs</category>
      <category>API Gateway</category>
      <category>WebSocket</category>
      <category>Codex</category>
      <category>Serverless</category>
    </item>
    <item>
      <title>S3 + Amplify Static Website Hosting</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/s3-amplify-static-website</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/s3-amplify-static-website</guid>
      <pubDate>Sun, 27 Sep 2026 12:00:00 GMT</pubDate>
      <description>Static website hosting with AWS Amplify Hosting in manual deployment mode (no Git connection): site files are packaged as a CDK asset, and a Lambda-backed custom resource presigns an S3 URL for the zip and calls StartDeployment with it, avoiding a bucket policy on the shared CDK bootstrap bucket. Compared against the CloudFront + S3 pattern. Deploy-verified end-to-end, including a live HTTP 200 from the deployed site.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Amplify</category>
      <category>S3</category>
      <category>Custom Resource</category>
      <category>Lambda</category>
    </item>
    <item>
      <title>AWS Service EOL Monitor — Serverless EOL Watch with a Bedrock Digest</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/aws-eol-monitor</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/aws-eol-monitor</guid>
      <pubDate>Sun, 27 Sep 2026 12:00:00 GMT</pubDate>
      <description>A serverless pipeline that watches the awslabs/aws-service-eol-data dataset for AWS service/version end-of-life changes: EventBridge Scheduler triggers a Standard Step Functions workflow that diffs the dataset against a DynamoDB state table, asks Bedrock (Claude) to draft a prioritized Markdown digest only when something changed, and publishes it to SNS. Deploy-verified end-to-end, including a real Bedrock ConverseCommand call and SNS publish.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Step Functions</category>
      <category>EventBridge Scheduler</category>
      <category>Bedrock</category>
      <category>DynamoDB</category>
      <category>SNS</category>
      <category>Lambda</category>
    </item>
    <item>
      <title>ECS Fargate with ALB (CliCredentialsStackSynthesizer / PermissionsBoundary variant)</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecs-fargate-alb-StackSynthesizer</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecs-fargate-alb-StackSynthesizer</guid>
      <pubDate>Sat, 26 Sep 2026 12:00:00 GMT</pubDate>
      <description>A variant of the ECS Fargate + ALB reference for accounts that govern IAM with permissions boundaries: with CDK_USE_CALLER_ROLE=true it deploys via CliCredentialsStackSynthesizer instead of the bootstrap roles, and CDK_PERMISSIONS_BOUNDARY_POLICY_NAME applies a custom boundary (default: PowerUserAccess) to every IAM role in the stage. Deploy-verified, including a boundary on cfn-exec-role that denies roles created without it.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>ECS</category>
      <category>Fargate</category>
      <category>ALB</category>
      <category>StackSynthesizer</category>
      <category>PermissionsBoundary</category>
      <category>SCP</category>
    </item>
    <item>
      <title>Secrets Manager Rotation for Aurora (Single-User and Alternating Users)</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/secrets-rotation-aurora</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/secrets-rotation-aurora</guid>
      <pubDate>Fri, 25 Sep 2026 12:00:00 GMT</pubDate>
      <description>Automatic credential rotation for Aurora PostgreSQL Serverless v2 with Secrets Manager hosted rotation: single-user rotation for the master secret and alternating-user rotation for the application secret, in isolated subnets with a Secrets Manager interface endpoint instead of a NAT gateway. A Data API consumer never holds a password; an end-to-end script runs real rotations and proves the new credentials work with zero failed queries.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Secrets Manager</category>
      <category>Aurora</category>
      <category>RDS Data API</category>
      <category>Rotation</category>
      <category>VPC Endpoint</category>
      <category>Security</category>
    </item>
    <item>
      <title>EventBridge Custom Bus: Content-Based Routing with Archive &amp; Replay</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/eventbridge-custom-bus</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/eventbridge-custom-bus</guid>
      <pubDate>Fri, 25 Sep 2026 12:00:00 GMT</pubDate>
      <description>A custom Amazon EventBridge bus for an order domain: rules route by content (numeric, prefix, anything-but) to SQS with an input transformer, Lambda, and CloudWatch Logs directly, with bounded retries plus a DLQ, bus-level logging (source, destination and delivery), and a replayable archive. Includes an end-to-end script that proves which events land where, and which land nowhere.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>EventBridge</category>
      <category>SQS</category>
      <category>Lambda</category>
      <category>Event-Driven</category>
      <category>Archive</category>
      <category>Replay</category>
    </item>
    <item>
      <title>Cognito + API Gateway Authentication &amp; Authorization</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cognito-apigw-auth</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cognito-apigw-auth</guid>
      <pubDate>Fri, 25 Sep 2026 12:00:00 GMT</pubDate>
      <description>Protect a REST API with Amazon Cognito: a user pool (groups, optional TOTP MFA, hosted UI with authorization code + PKCE, machine client via client_credentials), an API Gateway Cognito authorizer with per-method OAuth scopes, and Lambda functions enforcing group membership and per-user data ownership. The managed counterpart to the Keycloak pattern, with an end-to-end token-type and scope check script.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Cognito</category>
      <category>API Gateway</category>
      <category>OAuth2</category>
      <category>Lambda</category>
      <category>DynamoDB</category>
      <category>Authorization</category>
    </item>
    <item>
      <title>CDK Pipelines: Self-Mutating Pipeline with Dev/Prod Promotion</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cdk-pipelines-self-mutating</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cdk-pipelines-self-mutating</guid>
      <pubDate>Fri, 25 Sep 2026 12:00:00 GMT</pubDate>
      <description>A self-mutating CDK Pipeline (aws-cdk-lib/pipelines) sourced from CodeCommit: the pipeline definition lives in the repository it builds, so a commit that changes the pipeline updates the pipeline itself. Build runs tsc + unit tests + CDK Nag, then Dev deploy with a smoke test, a manual approval, and Prod deploy. Includes an end-to-end check script that proves release and self-mutation.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>CDK Pipelines</category>
      <category>CodePipeline</category>
      <category>CodeBuild</category>
      <category>CodeCommit</category>
      <category>CI/CD</category>
      <category>Self-Mutation</category>
    </item>
    <item>
      <title>Semantic Search API with DynamoDB Native Vector Search</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/dynamodb-vector-search-semantic-api</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/dynamodb-vector-search-semantic-api</guid>
      <pubDate>Fri, 25 Sep 2026 12:00:00 GMT</pubDate>
      <description>A meaning-based search API on Amazon DynamoDB&apos;s native vector index (no OpenSearch): DynamoDB Streams triggers a Lambda that embeds each document with Bedrock Titan Text Embeddings V2, and SearchVectors with an inline category filter answers natural-language queries. Includes the CDK escape hatch for VectorIndexes and an end-to-end check script.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>DynamoDB</category>
      <category>Vector Search</category>
      <category>Bedrock</category>
      <category>Lambda</category>
      <category>API Gateway</category>
      <category>Semantic Search</category>
    </item>
    <item>
      <title>ALB OIDC Authentication with Keycloak on ECS Fargate + Aurora Serverless</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/alb-keycloak-auth</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/alb-keycloak-auth</guid>
      <pubDate>Sun, 20 Sep 2026 12:00:00 GMT</pubDate>
      <description>AWS ALB built-in OIDC authentication backed by Keycloak running on ECS Fargate with Aurora Serverless V2 (PostgreSQL) as the session store. Two patterns: Pattern A uses Keycloak as a direct OIDC provider; Pattern B adds SAML identity brokering so Keycloak acts as both an OIDC provider to ALB and a SAML service provider to a corporate IdP. Includes setup scripts for realm/client configuration and ECS Exec enabled for connection testing.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>ALB</category>
      <category>OIDC</category>
      <category>Keycloak</category>
      <category>ECS</category>
      <category>Fargate</category>
      <category>Aurora</category>
      <category>Serverless</category>
      <category>Security</category>
      <category>IAM</category>
      <category>SAML</category>
    </item>
    <item>
      <title>FIS Chaos: SQS + Lambda Event-Driven Consumer + DynamoDB</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-d-sqs-lambda</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-d-sqs-lambda</guid>
      <pubDate>Sun, 20 Sep 2026 12:00:00 GMT</pubDate>
      <description>Three AWS FIS chaos experiment templates for a serverless event-driven consumer, using the aws:lambda:function action family via the FIS Lambda extension: a 5-min invocation-error outage (short recovery), a 20-min invocation-error outage (forces DLQ routing past the visibility-timeout × maxReceiveCount threshold), and a 10-min invocation-add-delay throughput collapse — each with a CloudWatch Alarm stop condition on queue backlog depth.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FIS</category>
      <category>Chaos Engineering</category>
      <category>SQS</category>
      <category>Lambda</category>
      <category>DynamoDB</category>
      <category>Serverless</category>
      <category>DLQ</category>
    </item>
    <item>
      <title>FIS Chaos: Step Functions Saga + Lambda + DynamoDB</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-f-stepfunctions-saga</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-f-stepfunctions-saga</guid>
      <pubDate>Sun, 20 Sep 2026 12:00:00 GMT</pubDate>
      <description>Three AWS FIS chaos experiment templates for a Saga-pattern order workflow (Reserve Inventory → Process Payment → Confirm Order, each with Retry/Catch and compensating transactions): payment-step outage triggering inventory-release compensation, first-step outage with no compensation needed, and final-step outage triggering the two-stage refund-then-release compensation chain — each with a CloudWatch Alarm stop condition on Step Functions ExecutionsFailed. Uses the aws:lambda:function action family (invocation-error) via the FIS Lambda extension to drive Saga error handling indirectly, since FIS has no native Step Functions action.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FIS</category>
      <category>Chaos Engineering</category>
      <category>Step Functions</category>
      <category>Lambda</category>
      <category>DynamoDB</category>
      <category>Saga Pattern</category>
      <category>Serverless</category>
    </item>
    <item>
      <title>FIS Chaos: Multi-AZ Network Disruption — NLB + EC2 ASG + Aurora</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-g-multiaz-network</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-g-multiaz-network</guid>
      <pubDate>Sun, 20 Sep 2026 12:00:00 GMT</pubDate>
      <description>Four AWS FIS chaos experiment templates for a Multi-AZ resilient architecture: cross-AZ connectivity disruption (VPC-internal traffic only), full AZ isolation (all traffic blocked), Aurora writer→reader failover, and tagged EC2 instance termination — each with a CloudWatch Alarm stop condition on NLB UnHealthyHostCount. Centers on aws:network:disrupt-connectivity, the only FIS action for simulating AZ-level network partitions.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FIS</category>
      <category>Chaos Engineering</category>
      <category>Multi-AZ</category>
      <category>NLB</category>
      <category>EC2</category>
      <category>Auto Scaling</category>
      <category>Aurora</category>
      <category>Networking</category>
    </item>
    <item>
      <title>FIS Chaos: ARC Zonal Shift on Auto Scaling</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-h-zonal-shift</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-h-zonal-shift</guid>
      <pubDate>Sun, 20 Sep 2026 12:00:00 GMT</pubDate>
      <description>A direct follow-up to Architecture G&apos;s G-2 finding (Auto Scaling re-launches instances into the same network-partitioned AZ): the same NLB + EC2 ASG + Aurora Multi-AZ base, with the ASG registered for ARC zonal shift (AvailabilityZoneImpairmentPolicy). Deploy-verified, in the same live infrastructure, both with and without an active operator-triggered zonal shift: without it, the replacement lands back in the same broken AZ (reproducing G-2); with ReplaceUnhealthy active, it lands in the healthy AZ instead.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FIS</category>
      <category>Chaos Engineering</category>
      <category>ARC</category>
      <category>Zonal Shift</category>
      <category>Multi-AZ</category>
      <category>NLB</category>
      <category>EC2</category>
      <category>Auto Scaling</category>
    </item>
    <item>
      <title>Amazon Bedrock Agentic Code Review Gate for ECS Fargate CI/CD (ecspresso + CodePipeline)</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecspresso-bedrock-review</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecspresso-bedrock-review</guid>
      <pubDate>Sat, 19 Sep 2026 12:00:00 GMT</pubDate>
      <description>A CodeCommit/CodePipeline CI/CD reference for ECS Fargate that adds an Amazon Bedrock agentic code review gate between Build and Deploy: security/infra/quality/cost perspectives are reviewed in parallel against each push&apos;s git diff, and the pipeline blocks when the aggregated risk level reaches a configurable threshold. Deploys sample task/service definitions with ecspresso + jsonnet; this workspace has no real ECS cluster/service, so the Deploy stage only runs `ecspresso render` (no AWS API calls).</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>CodePipeline</category>
      <category>CodeBuild</category>
      <category>CodeCommit</category>
      <category>Bedrock</category>
      <category>ECS</category>
      <category>Fargate</category>
      <category>ecspresso</category>
      <category>Trivy</category>
      <category>Security Hub</category>
    </item>
    <item>
      <title>Cross-Account CI/CD from a Single CodeCommit Repository</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cicd-codecommit-cross-account</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cicd-codecommit-cross-account</guid>
      <pubDate>Thu, 10 Sep 2026 12:00:00 GMT</pubDate>
      <description>One CodeCommit repository in the dev account feeding three CodePipelines, each deployed into its own account (dev/stg/prd); only the Source stage crosses accounts, assuming a fixed-name IAM role while EventBridge forwards push events across accounts to trigger each pipeline.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>CodePipeline</category>
      <category>CodeBuild</category>
      <category>CodeCommit</category>
      <category>Cross-Account</category>
      <category>IAM</category>
    </item>
    <item>
      <title>FIS Chaos: CloudFront + Internal ALB + ECS Fargate + Aurora PostgreSQL</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-a-ecs-aurora</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-a-ecs-aurora</guid>
      <pubDate>Tue, 08 Sep 2026 12:00:00 GMT</pubDate>
      <description>Four AWS FIS chaos experiment templates for a container-based three-tier web architecture: Aurora writer→reader failover, ECS all-tasks stop (with CloudFront S3 fallback), ECS→DB network blackhole on TCP 5432, and ALB→ECS network blackhole on TCP 80 — each with an ALB 5xx CloudWatch Alarm stop condition.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FIS</category>
      <category>Chaos Engineering</category>
      <category>ECS</category>
      <category>Fargate</category>
      <category>ALB</category>
      <category>CloudFront</category>
      <category>Aurora</category>
      <category>PostgreSQL</category>
      <category>VPC Origin</category>
    </item>
    <item>
      <title>FIS Chaos: CloudFront + Internal ALB + EC2 Auto Scaling Group + Aurora PostgreSQL</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-c-ec2-asg-rds</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-c-ec2-asg-rds</guid>
      <pubDate>Tue, 08 Sep 2026 12:00:00 GMT</pubDate>
      <description>Four AWS FIS chaos experiment templates for an EC2-based three-tier web architecture: EC2 instance termination (50% PERCENT), CPU stress via SSM (all instances, 5 min), Aurora writer→reader failover, and EC2→DB network blackhole on TCP port 5432 — each with an ALB 5xx CloudWatch Alarm stop condition.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FIS</category>
      <category>Chaos Engineering</category>
      <category>EC2</category>
      <category>Auto Scaling</category>
      <category>ALB</category>
      <category>CloudFront</category>
      <category>Aurora</category>
      <category>PostgreSQL</category>
      <category>SSM</category>
    </item>
    <item>
      <title>FIS Chaos: CloudFront + API Gateway + Lambda + DynamoDB</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-b-apigw-lambda</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/fis-arch-b-apigw-lambda</guid>
      <pubDate>Tue, 08 Sep 2026 12:00:00 GMT</pubDate>
      <description>Four AWS FIS chaos experiment templates for a serverless CRUD API: DynamoDB internal errors (all ops), write-only throttle, read-only throttle, and Lambda concurrency exhaustion — each with a CloudWatch Alarm stop condition. Uses aws:fis:inject-api-* targeting the Lambda execution role to intercept DynamoDB calls at the control plane without touching function code.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FIS</category>
      <category>Chaos Engineering</category>
      <category>Lambda</category>
      <category>API Gateway</category>
      <category>CloudFront</category>
      <category>DynamoDB</category>
    </item>
    <item>
      <title>API Gateway + Single-Purpose Lambda</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-single-purpose-lambda</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-single-purpose-lambda</guid>
      <pubDate>Mon, 07 Sep 2026 12:00:00 GMT</pubDate>
      <description>A Todos REST API where every API Gateway method is backed by its own narrowly-scoped Lambda function, each with an independent IAM role, log group, bundle, and least-privilege DynamoDB grant (read-only for GET, write-only for POST/DELETE). One of three companion workspaces comparing API Gateway + Lambda integration styles against the same API.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>API Gateway</category>
      <category>Lambda</category>
      <category>DynamoDB</category>
      <category>Serverless</category>
    </item>
    <item>
      <title>API Gateway + Lambdalith (Hono)</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-lambdalith</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-lambdalith</guid>
      <pubDate>Mon, 07 Sep 2026 12:00:00 GMT</pubDate>
      <description>The same Todos REST API served by a single Lambda function, with routing done in-process by the Hono framework via its aws-lambda adapter and API Gateway reduced to a thin {proxy+} pass-through. One of three companion workspaces comparing API Gateway + Lambda integration styles against the same API.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>API Gateway</category>
      <category>Lambda</category>
      <category>DynamoDB</category>
      <category>Hono</category>
      <category>Serverless</category>
    </item>
    <item>
      <title>API Gateway + Lambda Web Adapter (Express.js)</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-lambda-web-adapter</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-lambda-web-adapter</guid>
      <pubDate>Mon, 07 Sep 2026 12:00:00 GMT</pubDate>
      <description>The same Todos REST API served by a single Lambda that runs a standard Express.js HTTP server, with the AWS Lambda Web Adapter layer translating the API Gateway proxy event into a real HTTP request so the identical image also runs on Fargate or a local node process. One of three companion workspaces comparing API Gateway + Lambda integration styles against the same API.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>API Gateway</category>
      <category>Lambda</category>
      <category>DynamoDB</category>
      <category>Lambda Web Adapter</category>
      <category>Express</category>
      <category>Serverless</category>
    </item>
    <item>
      <title>Route 53 Private Hosted Zone Delegation</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/route53-phz-delegation</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/route53-phz-delegation</guid>
      <pubDate>Mon, 31 Aug 2026 12:00:00 GMT</pubDate>
      <description>Parent private hosted zone system.example.com delegates dev.system.example.com and stg.system.example.com to two child VPCs using the June 2025 Route 53 Resolver DNS delegation feature (INBOUND_DELEGATION endpoints + DELEGATE resolver rules), with a fourth on-premises-role VPC and all four VPCs joined by one Transit Gateway.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Route 53</category>
      <category>Route 53 Resolver</category>
      <category>DNS Delegation</category>
      <category>Transit Gateway</category>
      <category>Networking</category>
    </item>
    <item>
      <title>Route 53 Resolver Inbound/Outbound Endpoints</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/route53-resolver-endpoints</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/route53-resolver-endpoints</guid>
      <pubDate>Mon, 31 Aug 2026 12:00:00 GMT</pubDate>
      <description>A verification VPC with the system.example.com private hosted zone and both a Resolver inbound endpoint (switchable via parameter between the default and the June 2025 INBOUND_DELEGATION type) and outbound endpoint, peered with an on-premises-role VPC running a BIND9 DNS server.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Route 53</category>
      <category>Route 53 Resolver</category>
      <category>Hybrid DNS</category>
      <category>VPC Peering</category>
      <category>Networking</category>
    </item>
    <item>
      <title>Multi-VPC Transit Gateway</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/transit-gateway</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/transit-gateway</guid>
      <pubDate>Sat, 29 Aug 2026 12:00:00 GMT</pubDate>
      <description>Three VPCs (10.0/16, 10.1/16, 10.2/16) joined into a full mesh by one Transit Gateway with a single, explicitly managed TGW route table (association + propagation on every attachment), plus one SSM-managed test instance per VPC for connectivity verification.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Transit Gateway</category>
      <category>VPC</category>
      <category>Networking</category>
      <category>EC2</category>
    </item>
    <item>
      <title>AWS Backup Cross-Region (Tokyo to Osaka)</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/aws-backup-cross-region</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/aws-backup-cross-region</guid>
      <pubDate>Fri, 21 Aug 2026 12:00:00 GMT</pubDate>
      <description>A single tag-based AWS Backup Selection protecting a sample EC2 instance, RDS database, S3 bucket, and an entire CloudFormation stack in Tokyo, with every recovery point copied cross-region to a pre-created secondary vault in Osaka.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>AWS Backup</category>
      <category>EC2</category>
      <category>RDS</category>
      <category>S3</category>
      <category>CloudFormation</category>
      <category>Multi-Region</category>
      <category>DR</category>
    </item>
    <item>
      <title>ECR Cross-Region Replication</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecr-cross-region-replication</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecr-cross-region-replication</guid>
      <pubDate>Thu, 20 Aug 2026 12:00:00 GMT</pubDate>
      <description>Amazon ECR cross-region replication from Tokyo to Osaka, with both repositories pre-created and independently lifecycle-managed so the replica keeps its own retention policy instead of inheriting none.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>ECR</category>
      <category>Replication</category>
      <category>Multi-Region</category>
    </item>
    <item>
      <title>WAF Log Reporting</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/waf-log-reporting</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/waf-log-reporting</guid>
      <pubDate>Sun, 16 Aug 2026 12:00:00 GMT</pubDate>
      <description>Daily WAF Count/Block activity reports built two ways from the same logs: CloudWatch Logs Insights + Lambda + SNS, and Athena + Lambda + SNS, either against a standalone sample Web ACL or an existing WAF.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>WAF</category>
      <category>Athena</category>
      <category>CloudWatch Logs</category>
      <category>Lambda</category>
      <category>SNS</category>
      <category>Security</category>
    </item>
    <item>
      <title>EC2 Dual ENI</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ec2-dual-eni</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ec2-dual-eni</guid>
      <pubDate>Thu, 13 Aug 2026 12:00:00 GMT</pubDate>
      <description>Single EC2 instance with two network interfaces: eth0 for internet-facing HTTP/HTTPS traffic (with Elastic IP), and eth1 for SSH management access restricted to specific CIDRs.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>EC2</category>
      <category>Networking</category>
      <category>Security</category>
    </item>
    <item>
      <title>API Gateway + S3 Stub API</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-s3-stub</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/apigw-s3-stub</guid>
      <pubDate>Sat, 08 Aug 2026 12:00:00 GMT</pubDate>
      <description>Build a Lambda-free mock/stub HTTP API by wiring API Gateway directly to S3 via an AWS Service integration, returning canned JSON files.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>API Gateway</category>
      <category>S3</category>
    </item>
    <item>
      <title>SNS Basic Fan-Out Patterns</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/sns-basic</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/sns-basic</guid>
      <pubDate>Sat, 08 Aug 2026 12:00:00 GMT</pubDate>
      <description>A single SNS topic fanned out to Email, SQS, Lambda, HTTPS (API Gateway to S3/DynamoDB) and Firehose subscriptions, plus a CloudWatch Logs to Lambda to SNS to Lambda alerting chain.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>SNS</category>
      <category>SQS</category>
      <category>Lambda</category>
      <category>API Gateway</category>
      <category>DynamoDB</category>
      <category>Firehose</category>
    </item>
    <item>
      <title>CloudFront S3 Static Website</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cloudfront-s3-static-website</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cloudfront-s3-static-website</guid>
      <pubDate>Wed, 05 Aug 2026 12:00:00 GMT</pubDate>
      <description>A static site served over HTTPS by CloudFront from a fully private S3 bucket (Origin Access Control), with a Content-Security-Policy response-headers policy, SPA-friendly 403/404-to-index rewrites, and an optional cross-region (us-east-1) WAFv2 Web ACL with an IP allow-list and redacted log fields.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>CloudFront</category>
      <category>S3</category>
      <category>WAF</category>
      <category>Security</category>
    </item>
    <item>
      <title>S3 Static Web Site</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/s3-static-web-site</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/s3-static-web-site</guid>
      <pubDate>Wed, 05 Aug 2026 12:00:00 GMT</pubDate>
      <description>The simplest static website on AWS: S3 static website hosting served straight from the bucket website endpoint, with Block Public Access left fully enabled and anonymous access limited to an allow-list of IPv4/IPv6 addresses via an aws:SourceIp bucket policy (auto-detecting the deploying operator&apos;s own global IP).</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>S3</category>
      <category>Storage</category>
    </item>
    <item>
      <title>CI/CD Pipeline for CloudFront &amp; S3</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cicd-cloudfront-s3</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cicd-cloudfront-s3</guid>
      <pubDate>Sun, 02 Aug 2026 12:00:00 GMT</pubDate>
      <description>A CodePipeline/CodeBuild pipeline that builds a static site from CodeCommit and deploys it to S3/CloudFront, with an S3 sync Lambda, an async CloudFront invalidation Lambda driven by the CodePipeline continuation-token pattern, and an opt-in manual approval gate.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>CodePipeline</category>
      <category>CodeBuild</category>
      <category>Lambda</category>
    </item>
    <item>
      <title>Budgets &amp; Cost Anomaly Detection</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/budgets-cost-anomaly-detection</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/budgets-cost-anomaly-detection</guid>
      <pubDate>Fri, 31 Jul 2026 12:00:00 GMT</pubDate>
      <description>Five FinOps alerting patterns with AWS CDK: threshold-based Budget alerts, ML-based Cost Anomaly Detection, a unified SNS topic with optional Slack delivery, the classic CloudWatch billing alarm, and a scheduled Step Functions cost digest to Slack/Microsoft Teams via AWS Chatbot.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>FinOps</category>
      <category>Cost Management</category>
      <category>Step Functions</category>
    </item>
    <item>
      <title>CloudFront with VPC Origin</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cloudfront-vpc-origin</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cloudfront-vpc-origin</guid>
      <pubDate>Sun, 19 Jul 2026 12:00:00 GMT</pubDate>
      <description>Configure CloudFront distribution with VPC origin using AWS CDK.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>CloudFront</category>
      <category>VPC</category>
    </item>
    <item>
      <title>CloudWatch Logs to S3 Archive</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cloudwatch-logs-s3-archive</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cloudwatch-logs-s3-archive</guid>
      <pubDate>Sat, 06 Jun 2026 12:00:00 GMT</pubDate>
      <description>Archive CloudWatch Logs to S3 using AWS CDK.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>CloudWatch</category>
      <category>S3</category>
    </item>
    <item>
      <title>EC2 Advanced Patterns</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ec2-advanced</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ec2-advanced</guid>
      <pubDate>Sat, 16 May 2026 12:00:00 GMT</pubDate>
      <description>Four EC2 deployment patterns using AWS CDK: Single Instance, Auto-Recovery, ASG Always-1, and ASG Multi-AZ with ALB. Covers IMDSv2, SSM Session Manager access, CloudWatch alarms, and operational notifications.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>EC2</category>
      <category>ASG</category>
      <category>ALB</category>
    </item>
    <item>
      <title>ECS Fargate with ALB</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecs-fargate-alb</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/ecs-fargate-alb</guid>
      <pubDate>Mon, 20 Apr 2026 12:00:00 GMT</pubDate>
      <description>Build a production-ready container application platform combining ECS Fargate and Application Load Balancer (ALB) using AWS CDK.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>ECS</category>
      <category>Fargate</category>
      <category>ALB</category>
    </item>
    <item>
      <title>SQS to Lambda to Kinesis Firehose</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/sqs-lambda-firehose</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/sqs-lambda-firehose</guid>
      <pubDate>Mon, 26 Jan 2026 12:00:00 GMT</pubDate>
      <description>Process messages from SQS queue using Lambda function and stream to Kinesis Firehose for data lake storage.</description>
      <category>CDK</category>
      <category>TypeScript</category>
    </item>
    <item>
      <title>VPC Peering Connection</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/vpc-peering</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/vpc-peering</guid>
      <pubDate>Wed, 31 Dec 2025 12:00:00 GMT</pubDate>
      <description>Establish VPC peering connection between two VPCs for private network communication.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Networking</category>
    </item>
    <item>
      <title>CDK Parameters Best Practices</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cdk-parameters</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/cdk-parameters</guid>
      <pubDate>Thu, 25 Dec 2025 12:00:00 GMT</pubDate>
      <description>Learn how to manage parameters and configurations in AWS CDK applications.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Best Practices</category>
    </item>
    <item>
      <title>VPC with NAT Instance</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/vpc-natinstance-v2</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/vpc-natinstance-v2</guid>
      <pubDate>Wed, 24 Dec 2025 12:00:00 GMT</pubDate>
      <description>Create VPC with NAT instance for cost-effective internet access from private subnets.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Networking</category>
    </item>
    <item>
      <title>VPC Basics with CDK</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/vpc-basics</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/vpc-basics</guid>
      <pubDate>Sun, 21 Dec 2025 12:00:00 GMT</pubDate>
      <description>Create a basic VPC infrastructure with public and private subnets using AWS CDK.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Networking</category>
    </item>
    <item>
      <title>IAM Basics with CDK</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/iam-basics</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/iam-basics</guid>
      <pubDate>Tue, 09 Dec 2025 12:00:00 GMT</pubDate>
      <description>Create IAM roles, policies, and users with AWS CDK following best practices.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Security</category>
    </item>
    <item>
      <title>S3 Basics with CDK</title>
      <link>https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/s3-basics</link>
      <guid isPermaLink="true">https://github.com/ishiharatma/aws-cdk-reference-architectures/tree/main/infrastructure/workspaces/s3-basics</guid>
      <pubDate>Sun, 07 Dec 2025 12:00:00 GMT</pubDate>
      <description>Create and configure S3 buckets with various settings using AWS CDK.</description>
      <category>CDK</category>
      <category>TypeScript</category>
      <category>Storage</category>
    </item>
  </channel>
</rss>
