Docs: Improve modules/vdi/README.md: Add context and production considerations

[gabebatista]

What were you searching in the docs?

Context on why VDI is needed for game development and production considerations.

Is this related to an existing documentation section?

modules/vdi/README.md - proposing minimal additions for consistency with other modules. Note: VDI README is already excellent and serves as the standard for other modules.

How can we improve?

The VDI README is comprehensive and well-documented. To maintain consistency with other module READMEs, we should add a "Why VDI?" section and a "Production Considerations" section.

Got a suggestion in mind?

1. Add "Why VDI for Game Development?" Section (After opening paragraph)

## Why VDI for Game Development?

Game development has unique requirements that make traditional desktop management impractical:

**Challenges VDI Solves**:
- **GPU requirements**: Artists need workstation-class GPUs (NVIDIA T4, A10G)
- **Remote work**: Global teams need secure access to high-performance workstations
- **IP protection**: Game assets and source code must stay in the cloud
- **Onboarding speed**: New developers need workstations provisioned in hours, not days
- **Cost optimization**: GPU instances stopped when not in use save significantly

**vs Traditional Workstations**:
| Factor | Physical Workstations | Cloud VDI (This Module) |
|--------|----------------------|------------------------|
| **Initial cost** | High upfront investment | $0 upfront |
| **Provisioning time** | Days (shipping, setup) | 15-30 minutes |
| **Remote access** | VPN + performance issues | Native (Amazon DCV) |
| **Scaling** | Order hardware weeks in advance | Scale in minutes |
| **Maintenance** | IT team manages hardware | AWS manages infrastructure |
| **Cost when idle** | Fixed | Stop instances = minimal cost |

**vs Other Cloud VDI Solutions**:
- **vs AWS WorkSpaces**: More control, GPU flexibility, cost-effective for variable usage
- **vs Third-party solutions**: Infrastructure control, no per-user licensing, AWS-native

**Best For**:
- Game studios with remote or hybrid teams
- Studios scaling team size frequently (contractors, seasonal)
- Teams requiring IP protection (work stays in AWS)
- Projects requiring GPU-accelerated workflows (Unreal, Unity, Blender)

---

2. Add "Production Considerations" Section (In appropriate location)

## Production Considerations

When preparing to deploy this module in a production environment, consider the following:

### Security
- Review and restrict \`allowed_cidr_blocks\` to specific IP ranges (avoid 0.0.0.0/0)
- Enable MFA for AWS IAM users with access to VDI infrastructure
- Configure VPN for private connectivity (or Direct Connect)
- Enable VPC Flow Logs for network traffic auditing
- Implement password rotation policies for workstation users
- Enable CloudTrail for API activity logging

### High Availability & Disaster Recovery
- Enable automated EBS snapshots for workstation volumes
- Test workstation restoration from snapshots
- Document user data backup procedures (where users should store critical work)
- Create runbooks for recovering from EC2 instance failures
- Define RTO and RPO requirements for workstation recovery

### Monitoring & Observability
- Set up CloudWatch alarms for instance CPU, memory, and disk usage
- Configure billing alerts for unexpected cost increases
- Monitor DCV connection quality and user experience
- Set up alerting for instance failures or connectivity issues
- Track workstation utilization to identify idle resources

### Performance
- Right-size instance types based on actual user workloads
- Test DCV connection quality from user locations (latency, bandwidth)
- Configure instance store for temporary files (if using g4dn instances)
- Enable EBS optimization for I/O-intensive workloads
- Monitor and optimize storage performance

### Cost Management
- Implement auto-stop policies for idle workstations
- Consider Savings Plans or Reserved Instances for long-running workstations
- Review storage utilization monthly and clean up unused volumes
- Monitor and optimize data transfer costs
- Establish policies for workstation lifecycle management

### Operations
- Document procedures for common operations (adding users, resizing volumes, instance type changes)
- Create incident response plan for workstation failures
- Train support team on AWS Console access and troubleshooting
- Establish SLA for new workstation provisioning time
- Plan for scaling and capacity management as team grows

[gabebatista]

📋 README Structure Template

To maintain consistency across all module READMEs, we're working towards a standardized structure. While we want to stick as closely to this template as possible, it's okay to make changes to fit the specific module's needs.

Template Structure:

```markdown

[Module/Service Name]

One-sentence description: Brief, clear statement of what this module does and its primary purpose.

Table of Contents

• Overview
• Why This Module?
• Architecture
• Cost Considerations
• Production Considerations
• Quick Start
• Usage Examples
• Configuration Reference
• Operations
• Troubleshooting

Overview

Brief 2-3 paragraph introduction covering:

• What this module deploys (high-level components)
• Primary use case(s)
• Target audience (game studios, indie developers, enterprise teams, etc.)

Why This Module?

Note: For modules with submodules (e.g., Perforce with P4 Server, P4 Auth, P4 Code Review), add a "Module Components" section here explaining what each component does and when to deploy them.

Problem Statement

What problem does this solve for game development teams?

Why [This Tool/Service]?

• vs Alternative 1: Key differentiator (e.g., "Perforce vs Git: Binary file handling")
• vs Alternative 2: Key differentiator (e.g., "Self-hosted vs SaaS: Control and compliance")
• vs Alternative 3: Key differentiator (e.g., "TeamCity vs Jenkins: UI polish vs flexibility")
• Best for: Team size, project type, specific requirements

Note: For modules with multiple alternatives (e.g., CI/CD options), include comparison tables in this section:

Factor	This Module	Alternative Module
Factor 1	Advantage	Trade-off
Factor 2	Trade-off	Advantage

When NOT to Use This Module

• Small teams (< X people) - simpler alternatives may suffice
• Text-only repositories - Git may be more cost-effective
• Teams without [specific requirement] - overhead not justified

Architecture

High-Level Architecture

\`\`\`
[Include diagram - keep it simple and focused on data flow]
\`\`\`

Key Components:

• Component 1: One-line purpose
• Component 2: One-line purpose
• Component 3: One-line purpose

Architecture Decisions

Why these choices matter: Understanding the rationale helps you customize safely and explain to stakeholders.

Use collapsible

Details

sections to keep README digestible:

Decision 1: Example Decision

Choice: What was chosen

Why:

• Reason 1
• Reason 2
• Reason 3

Trade-off:

• What you give up with this choice

When to override: When this choice might not fit your needs

Cost Considerations

Estimated Monthly Cost

Small Team (5-10 developers)

Component	Configuration	Cost
Compute	2x t3.medium (24/7)	$60
Storage	500GB EBS	$50
Network	NLB + 1TB transfer	$40
Total		~$150/month

Cost Optimization:

• Schedule dev environments to stop nights/weekends
• Use Savings Plans for steady-state workloads
• Right-size after 2 weeks based on metrics

Use AWS Pricing Calculator for accurate estimates.

Production Considerations

Note: This section provides guidance on things to consider when preparing for production deployment. It's ultimately up to you to determine what's appropriate for your specific environment and requirements.

When preparing to deploy this module in a production environment, consider the following:

Security

• Review and restrict access controls (security groups, CIDR blocks)
• Enable MFA for AWS IAM users with infrastructure access
• Configure VPC Flow Logs for network traffic auditing
• Implement secret rotation policies where applicable
• Enable CloudTrail for API activity logging
• Review IAM permissions for least privilege access

High Availability & Reliability

• Deploy across multiple Availability Zones where supported
• Enable automated backups with appropriate retention periods
• Test disaster recovery procedures (restoring from backups)
• Document runbooks for common failure scenarios

Monitoring & Observability

• Set up CloudWatch alarms for critical metrics
• Configure billing alerts for unexpected cost increases
• Implement centralized log aggregation
• Define and monitor relevant SLAs
• Set up alerting for service degradation or failures

Performance

• Right-size resources based on actual workload metrics
• Monitor performance metrics and adjust configurations as needed
• Plan for capacity growth as team/usage scales

Operations

• Document procedures for common operations
• Establish backup and retention policies
• Plan for version upgrades and patching
• Define incident response procedures
• Train operations team on troubleshooting and maintenance
  ```

Target Length

500-800 lines (excluding terraform-docs) to keep documentation digestible.