# Cloud Platform Kit > An AWS CDK platform kit for production systems in Jakarta: synthesis fails when a data store would sit outside approved regions, deploys need no stored keys, and SLOs alert by burn rate. Keep the data in Jakarta and the checks in code. - URL: https://weaveward.com/work/cloud-platform-kit-aws-jakarta - Year: 2026 - Industry: Technology - Capabilities: IT consulting, Business systems - Technologies: AWS CDK, TypeScript, cdk-nag, Zod, AWS Fargate, Amazon RDS for PostgreSQL, AWS KMS, AWS WAF, Amazon CloudFront, Amazon CloudWatch, GitHub Actions, OpenTelemetry ## The challenge Production systems on AWS need much the same secure foundation, yet teams usually rebuild it from scratch for each project. Indonesian companies also want personal data kept in an approved region, security baselines that pass review, deploys without long-lived keys and reliability they can measure. Where personal data may live is a recurring question under Indonesia's Personal Data Protection Law (UU PDP) and sector rules. A baseline should answer it in code, where every change is checked, and keep the cost of the platform visible from the start. ## What we built Cloud Platform Kit is an AWS CDK app in TypeScript that composes a secure baseline for production systems from six stacks, with policy checks, tests, runbooks and a scorecard alongside. - **Network.** A VPC across three availability zones with private subnets, NAT sized per environment, and VPC endpoints for S3, ECR, Secrets Manager and CloudWatch that keep that traffic off the NAT gateways - **Data.** RDS for PostgreSQL encrypted with customer-managed KMS keys and backed up automatically, with Multi-AZ and deletion protection in production - **Compute.** An ECS Fargate service behind an Application Load Balancer with AWS WAF managed rules, autoscaling on CPU and request count, and a deployment circuit breaker that rolls back a failing release - **Edge and security.** CloudFront serves static content from a private S3 origin through origin access control. CloudTrail writes to a locked bucket, secrets live in Secrets Manager, IAM roles follow least privilege, and GuardDuty is one switch in the configuration - **Observability and SLOs.** A CloudWatch dashboard and alarms, plus burn-rate alarms computed from the reference service's availability target - **A reference service.** A TypeScript Hono service with a versioned /health endpoint, structured logs and OpenTelemetry instrumentation, built by a multi-stage Dockerfile that runs as a non-root user. A Compose file defines a local observability stack with an OpenTelemetry Collector, Prometheus, Grafana and Jaeger - **Docs and a scorecard.** An architecture diagram generated from code as SVG, runbooks for deploy, rollback and restore drills with RPO and RTO targets per tier, a cost model that lists the assumptions to fill in instead of quoting prices, a threat model summary, and a platform scorecard page built from the synth output ## How it works ### Typed configuration first Dev, staging and prod are declared in TypeScript and validated with Zod, with the region pinned to Asia Pacific (Jakarta), ap-southeast-3. An invalid setting fails validation instead of reaching a stack. ### Checks at synthesis Synthesis applies cdk-nag's AwsSolutions rules, the custom Aspects and the data-residency guard to every stack. An error fails synthesis, so a failing check stops a change before anything is deployed. ### Tests without AWS credentials The app makes no context lookups, so it synthesises without an AWS account. Assertion tests then check encryption, Multi-AZ only in production, deletion protection, the WAF association, no public S3 buckets and mandatory tags, and confirm that the residency guard rejects other regions. The burn-rate maths and the reference service have tests of their own. ### Keyless, gated delivery GitHub Actions workflows assume AWS roles through OIDC, so no AWS keys are stored in CI. Pull requests show a cdk diff, container images are built and scanned, and production waits for a manual approval. ### Operate by error budget The SLO library turns the reference service's availability target into burn-rate alarms, a CloudWatch dashboard shows the platform's health, and runbooks cover deploy, rollback and a restore drill with RPO and RTO targets for each tier. ## Engineering insights The kit moves platform rules out of review checklists and into code that runs every time the app is synthesised. - **Residency fails the build.** The data-residency guard is a CDK Aspect that visits every construct. A data store outside the approved regions fails synthesis, so the mistake surfaces as a build error long before an audit could find it - **Verified without an AWS account.** Every stack synthesises from typed configuration alone, with no context lookups, so cdk-nag and the assertion tests run offline on any machine - **Exceptions carry their reasons.** A cdk-nag suppression is accepted only with a written reason, so each exception sits in the code next to the resource it excuses and is reviewed like any other change. Custom Aspects add the house rules: encryption, mandatory tags, no public buckets and deletion protection in production - **Alarms from the error budget.** Alarm thresholds are derived from the availability target with the multi-window, multi-burn-rate method from Google's SRE Workbook, not set by hand. A long window confirms that the budget is really burning, and a short window lets the alarm reset soon after the burn stops - **Safeguards follow the environment.** Multi-AZ, deletion protection and NAT capacity come from each environment's profile, so development stays lean while production gets the full safeguards. An assertion test checks that Multi-AZ appears only in production ## Design system Blueprint is a documentation-grade design language, calm like a printed engineering drawing, for the platform engineers, security reviewers and managers who read the kit's diagrams and scorecard. - **Colour.** Slate on paper, ruled with grid lines that carry no meaning. Sky marks compute and nothing else, and emerald, amber and rose are kept for passing checks, warnings and failing checks - **Typography.** Inter for text, and JetBrains Mono for resource names, which the generated diagram takes from the code itself - **Diagrams.** One consistent shape language across every diagram and no vendor logos, so each kind of resource looks the same wherever it appears - **Scorecard.** A static page renders the synthesised resources, the policy-check results and the SLO alarm table from the synth output, in the same tokens as the diagrams ## Where this fits Teams moving production systems to AWS can start from this baseline instead of rebuilding it for each project, then adapt it to their own accounts. Explore our [IT consulting](/services/it-consulting) and [business systems](/services/business-systems) services, or [talk to us about your platform](/contact).