AI Skill Report Card
Designing Cloud Infrastructure
Quick Start14 / 15
Given a system requirement (e.g., "design infrastructure for a 100k DAU e-commerce app"), produce these five sections in order:
- Infrastructure Layer — compute, containers/VMs, regions/AZs
- Network Flow — traffic path from client to data layer
- Storage Design — databases, object storage, caching, backup
- Scaling Strategy — horizontal/vertical scaling, autoscaling triggers
- Cost Estimation — rough monthly cost by component
No preamble — start directly with these sections.
Recommendation▾
Add a second example with a different scale/architecture pattern (e.g., a small startup MVP or a batch-processing/data pipeline system) to show range beyond the single detailed real-time example.
Workflow14 / 15
Progress:
- Clarify scale (users, RPS, data volume, region requirements)
- Define Infrastructure Layer (compute choice, containerization, multi-AZ/region)
- Map Network Flow (CDN → LB → app tier → data tier, plus VPC/subnet segmentation)
- Design Storage (primary DB, cache, object storage, backup/DR)
- Define Scaling Strategy (autoscaling rules, bottleneck mitigation)
- Estimate Cost (per component, monthly, using public cloud pricing tiers)
Step details:
- Infrastructure Layer: choose compute model (VMs, Kubernetes, serverless), justify by workload pattern (steady vs bursty). Specify AZ/region redundancy.
- Network Flow: trace request path explicitly, e.g.,
Client → CDN (CloudFront) → WAF → ALB → ECS Service (private subnet) → RDS (private subnet). Note public vs private subnet placement and security group boundaries. - Storage Design: separate hot storage (DB, cache) from cold storage (backups, logs, archives). Specify replication and backup frequency.
- Scaling Strategy: define concrete triggers (CPU >70%, queue depth >1000) and scaling limits (min/max instances).
- Cost Estimation: break down by service category (compute, storage, network egress, managed services), give monthly USD range, flag the top 2 cost drivers.
Recommendation▾
Include a brief 'bad output' contrast (e.g., a vague cost estimate or missing subnet detail) to reinforce pitfalls with concrete before/after.
Examples15 / 20
Example 1: Input: "Design infrastructure for a ride-hailing backend, 500k DAU, real-time location tracking, needs to run in Southeast Asia."
Output:
Infrastructure Layer
- Region: ap-southeast-1 (primary), ap-southeast-3 (DR)
- Compute: EKS cluster, 3 AZs, mixed On-Demand + Spot node groups
- Real-time service (location tracking) on dedicated node pool with WebSocket support
Network Flow
Client (mobile) → Route53 (latency routing) → CloudFront (static assets)
→ ALB (public subnet) → EKS Ingress (NGINX) → Microservices (private subnet)
→ ElastiCache Redis (geo-hash location cache, private subnet)
→ RDS PostgreSQL Multi-AZ (private subnet)
VPC with 3 public + 3 private subnets across AZs; security groups restrict
DB/cache access to app tier only.
Storage Design
- Hot: Redis (live location, TTL 30s), PostgreSQL (trips, users, payments)
- Warm: S3 (trip history exports, receipts)
- Cold: S3 Glacier (logs >90 days)
- Backup: RDS automated snapshots daily, cross-region replication to DR
Scaling Strategy
- EKS HPA: scale pods at CPU >65% or WebSocket connections >5000/pod
- Redis: cluster mode enabled, shard by geo-hash prefix
- RDS: read replicas (2x) for read-heavy trip history queries
- Autoscaling limits: min 6 pods, max 60 pods per service
Cost Estimation (monthly, USD)
- Compute (EKS + EC2): $3,500–4,500
- RDS Multi-AZ + replicas: $1,200–1,600
- ElastiCache: $600–900
- Data transfer/CDN: $800–1,200
- Top drivers: compute (bursty rush-hour scaling) and data egress (real-time updates)
- Total estimate: ~$6,500–8,500/month
Recommendation▾
Add a short section on multi-cloud/vendor-agnostic terminology mapping (AWS vs GCP vs Azure equivalents) since the example is AWS-specific despite the skill being generically named 'cloud infrastructure'.
Best Practices
- Always place databases and caches in private subnets; never expose directly.
- Default to managed services (RDS, ElastiCache, managed Kubernetes) over self-hosted unless there's a clear cost/control reason not to.
- Include observability in every design: metrics (Prometheus/CloudWatch), logs (centralized), tracing (X-Ray/OpenTelemetry) — mention explicitly even if brief.
- Design for multi-AZ by default; treat multi-region as opt-in based on stated requirements.
- Give cost as a range, not a false-precision single number.
- Tie scaling triggers to actual metrics, not vague statements like "scale as needed."
Common Pitfalls
- Don't skip the Network Flow diagram — a written architecture without traceable request path is incomplete.
- Don't recommend serverless-everything or Kubernetes-everything by default — match compute model to workload shape.
- Don't omit backup/DR strategy from Storage Design.
- Don't give cost estimates without breaking down by component — a single lump sum isn't actionable.
- Don't ignore security boundaries (public vs private subnet, security groups/NACLs) when describing network flow.