Step 1 — Design Your Architecture on the Canvas
The canvas is the starting point for all work in PinPole. Services are added from the service palette and wired together to represent the intended traffic flow.
Adding services
The full AWS service catalogue — every service across API, network, compute, storage, database, messaging, security, and developer tooling categories — is available in the palette on the left. Search or browse by category to locate a service, then drag it onto the canvas.
Wiring services
Draw connections between services to represent traffic flow. PinPole enforces two rules in real time:
Compatibility — only architecturally valid connections are permitted. Attempting an incompatible wiring (for example, connecting DynamoDB directly to CloudFront) will be blocked before the connection is created.
Directionality — traffic flow direction is validated. Wiring in the wrong direction is blocked at the same point.
The canvas itself acts as a first layer of architectural review. If a connection you expect to be valid is blocked, PinPole is surfacing a misconfiguration before it reaches AWS.
Canvas best practices
Model the critical path first. Add the services that handle your primary traffic flow (e.g. Route 53 → API Gateway → Lambda → DynamoDB) before adding supporting services (logging, monitoring, security layers). This keeps the first simulation focused on what matters most.
Label your nodes. Each service node has a Display Label. Use meaningful names (e.g. api-gateway-prod, user-auth-lambda) so that simulation metrics and recommendations are easy to interpret at a glance.
Keep scope focused. If you are optimising a specific subsystem, canvas just that subsystem rather than your full environment. A smaller, focused canvas produces sharper simulation data and more targeted recommendations.
Check service quotas before simulating. Each node's configuration panel shows the applicable AWS service quotas for the chosen configuration. If you plan to simulate at 100K RPS and a service quota is set below that, the simulation will flag it — but it is better to identify this at configuration time than to interrupt a running simulation.
Use the Pro Tips section actively. These are distilled from real-world failure patterns at scale and are often the fastest route to avoiding common architectural pitfalls.
Current canvas capabilities
The canvas currently supports the following architectural pattern families:
| Pattern family | Current support |
|---|---|
| Linear and fan-out topologies | ✅ Full |
| Async / event-driven (SQS, SNS, EventBridge, Kinesis, Step Functions) | 🔶 Partial — nodes configurable, visual distinction between sync and async connections coming in Phase 2 |
| Caching layers (CloudFront, ElastiCache) | 🔶 Partial — nodes configurable, cache hit/miss path branching coming in Phase 2 |
| Resilience patterns (circuit breaker, DLQ, active-passive) | 🔶 Partial — AI recommendations generate correct node sets, visual standby/conditional edge types coming in Phase 2 |
| Containment hierarchy (VPC, AZ, Subnet, Security Group) | 🔴 Minimal — nodes available in catalogue, spatial nesting coming in Phase 1 |
| Network security zones | 🔴 Minimal — WAF, NAT, NACLs configurable, zone-envelope visualisation coming in Phase 2 |
| Cross-boundary (VPC peering, Transit Gateway, PrivateLink) | 🔴 Minimal — depends on containment hierarchy |
See Canvas Capabilities & Limitations for the full reference, and Upcoming Features for the roadmap timeline.