Infrastructure Architecture Playground
Place components, connect them, and read the architecture back in three views. The analyzer is rule-based and every rule is listed below, so you can see why a finding fired instead of trusting a verdict.
A public entry point, private compute and private data. The common shape most services should start from.
Every request passes through this component and there is only one of it. A restart, a bad deploy or a host failure is a full outage.
Rule: A request-path component with no redundant peer and no "redundant" marker.
Fix: Run at least two instances across two availability zones, and mark the component redundant.
lesson →A single database or volume means a host failure is downtime and, without backups, potentially data loss. A standby in another zone turns an outage into a failover.
Rule: A persistent data component with no peer and no "redundant" marker.
Fix: Enable a standby replica in a different availability zone, and confirm it is genuinely in a different failure domain.
lesson →Compute that reaches a database, a bucket or a secret store is authenticating as something. If that something is not a scoped workload identity, it is usually a long-lived key or a human's credentials — which breaks attribution, offboarding and least privilege at once.
Rule: At least one compute component and no IAM role.
Fix: Give each workload its own role with short-lived credentials, and stop using static keys.
lesson →Public entry points are limited to components whose job is to accept public traffic. That is the design, not a finding — a load balancer on 443 is supposed to be public.
Rule: No data component has exposure = public.
Fix: Nothing to fix. Keep it that way as components are added.
lesson →How the evaluation works
Rule-based, transparent, and opinionated in favour of the simplest architecture that meets the requirement.
- Public exposure is judged by what the component is. A load balancer, CDN, DNS record or NAT gateway with a public address is the design and is never flagged. A database, cache, queue, volume, secret store or control plane with a public address is a finding, and public compute is a warning because its safety then rests entirely on firewall configuration.
- A single point of failure is a request-path component with no peer of the same kind and no redundancy marker. A NAT gateway is called out separately because it is zonal and because its failure leaves every health check green.
- Missing redundancy fires for a persistent store with no standby, and for a canvas with more than three components, fewer than two zones and nothing marked redundant — because three replicas in one zone is one failure domain.
- Over-privileged identity fires on a role marked broad, and separately when compute exists with no workload identity at all, since that usually means a static key or a human's credentials.
- Missing observability fires above two components; missing backup fires whenever a persistent store has no backup, because managed storage protects against hardware failure and not against a bad migration or a credential that can delete it.
- Cost risks fire for object storage reachable only through a NAT gateway, for more than one region, and for three or more data stores — each of which is a separate backup, scaling and billing story.
- Unnecessary complexity fires for Kubernetes on a small system, for a queue with nothing consuming it, and for a total qualitative weight of 16 or more. Those weights are a teaching device, not a universal truth.
- Findings marked *info* are not problems.
Data stores are not directly reachable from the internetis there to show you a rule that passed.