- 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
71 lines
2.8 KiB
Markdown
71 lines
2.8 KiB
Markdown
# 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 | ~$5–20 | 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 | ~$10–30 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.
|