sns-network-solutions/infra/sns-digital/provider-roles.md
Samuel James b1a35783bb Consolidate 7 divisions to 3: Networking, Digital, Support
- Merge Infrastructure + Secure + Systems → SNS Networking (Business #1)
- Merge Web + Software + Cloud → SNS Digital (planned)
- SNS Support unchanged (planned)
- Add infra/ folder with 16 FOSS-first buildable designs
- Update all agent knowledge, division briefs, legal structure
- Restructure businesses/ from 7 to 3 operating folders
2026-07-18 13:08:23 -05:00

2.8 KiB
Raw Blame History

Provider Roles & Allocation — SNS Digital

Entity: SNS Digital · Status: Active (current layout)

What it is

Defines what each cloud/VPS provider is used for, why, and when to pick one over another. Keeps spend intentional and prevents provider sprawl.

Provider Matrix

Provider Role Monthly Budget Use When
Linode (Akamai) Bastion / jump host, WireGuard relay, light public-facing services ~$520 Need a stable public IP, low-latency relay to on-prem, or a small always-on service
Racknerd Cheap VPS for non-critical / experimental workloads ~$1030 total Disposable boxes, testing, overflow capacity, geo-diversity
AWS Enterprise workloads, managed services (S3, Route53, SES, Lambda) Pay-as-you-go Client requires AWS, need a managed service with no good self-hosted equivalent, or enterprise compliance

Current Allocation

Linode ($5 Nanode)
├── sam@172.238.163.85
├── Role: SSH bastion, WireGuard endpoint, Tailscale relay
├── ProxyJump target for all on-prem VMs (192.168.122.x)
└── Minimal attack surface: SSH + WireGuard only

Racknerd1 ($?)
├── root@172.245.72.108
└── Role: TBD / available capacity

Racknerd2 ($?)
├── root@192.3.165.113
└── Role: TBD / available capacity

AWS (free tier + selective services)
├── Route53: DNS hosting (cheap, reliable, no self-host headache)
├── S3: offsite backup target (encrypted, lifecycle policies)
├── SES: transactional email (when Google Workspace SMTP isn't appropriate)
└── Future: client-facing infra when contracts require it

Decision: When to go cloud vs. on-prem

Is it client-facing with an SLA you can't meet from home?
  YES → Cloud (Linode or AWS depending on complexity)
  NO  →
    Does it need a public IP 24/7 with guaranteed uptime?
      YES → Linode (simple) or AWS (complex)
      NO  →
        Is it throwaway / experimental?
          YES → Racknerd
          NO  → On-prem Proxmox

Cost Rules

  1. No idle AWS resources. If it's not serving traffic or storing data, shut it down.
  2. Linode stays small. It's a relay, not a compute platform. If workloads grow, they belong on-prem or on a dedicated Racknerd box.
  3. Racknerd is disposable. Don't put anything there that can't be rebuilt from Ansible in 15 minutes.
  4. AWS reserved instances / savings plans: Only after 3+ months of steady usage proves the workload is permanent.

Security Notes

  • Linode bastion: SSH key-only, UFW deny-all except 22 + WireGuard port.
  • Racknerd boxes: same hardening playbook as on-prem. No secrets stored locally.
  • AWS: IAM least-privilege, no root keys, MFA on console, service roles over user keys.