I came into AWS after more than 10 years of running Linux day to day — not professionally, just as someone who's always preferred the terminal to the alternative. What I noticed early on is that a lot of AWS services stopped feeling abstract the moment I mapped them to tools I already understood from the command line. A managed service is, most of the time, just someone else's version of a problem I've already solved locally.
Here's the mental map I actually use:
Backup & Recovery
| Linux | AWS |
|---|---|
| Timeshift / Btrfs snapshots | EBS Snapshots, RDS point-in-time recovery |
| rsync | AWS DataSync, aws s3 sync |
Storage
| Linux | AWS |
|---|---|
| LVM (resize volumes live) | EBS Elastic Volumes |
| NFS / Samba | EFS (Elastic File System) |
| RAID (mirroring/redundancy) | Multi-AZ RDS, S3 replication |
Networking & Security
| Linux | AWS |
|---|---|
| iptables / ufw | Security Groups, NACLs |
| fail2ban | GuardDuty, AWS WAF |
| Bind9 / dnsmasq | Route 53 |
| Squid (caching proxy) | CloudFront |
| HAProxy / Nginx load balancing | Elastic Load Balancer |
| /etc/passwd, sudoers | IAM users, roles, policies |
One caveat worth naming: fail2ban and GuardDuty aren't really the same kind of tool. fail2ban is reactive — it watches logs locally and bans an IP after it's already misbehaved. GuardDuty is anomaly detection across account activity, VPC Flow Logs, and DNS, with no real local equivalent — it's less "the managed version of fail2ban" and more a different category of tool that happens to sit in the same part of the stack. Most of these mappings hold up; that one's closer to an upgrade than a translation.
Monitoring & Logging
| Linux | AWS |
|---|---|
| journalctl / syslog | CloudWatch Logs |
| Nagios / Zabbix | CloudWatch Alarms + SNS |
| auditd | CloudTrail |
Compute & Orchestration
| Linux | AWS |
|---|---|
| Docker / LXC | ECS / Fargate |
| Kubernetes (self-hosted) | EKS |
| cron | EventBridge Scheduler |
| systemd (auto-restart services) | Auto Scaling |
Automation & Config
| Linux | AWS |
|---|---|
| Ansible / Puppet / Chef | Systems Manager, CloudFormation |
Where this actually showed up: a real NACL decision
The Security Groups/NACLs row above isn't theoretical — it's exactly the instinct I used on aws-enterprise-network. After adding a second Availability Zone to an internal NLB, the Console flagged a "Reachability may be impacted" warning on one subnet's Network ACL, because its outbound rule for port 80 didn't allow 0.0.0.0/0.
It didn't, on purpose — I'd scoped that outbound rule to 10.100.0.0/16 during an earlier security pass, because the traffic never needs to leave that range. That's the exact same tradeoff I'd make writing an iptables rule on a home server: an unrestricted ACCEPT is easy and makes warnings go away, but a rule scoped to the CIDR the traffic actually lives in is the same amount of effort and a smaller blast radius if something upstream gets compromised. The AWS Console's static analysis couldn't tell the difference between "wide open" and "deliberately narrow but sufficient" — it just checks for the unrestricted rule. Knowing that going in, from years of the same call on iptables, is what let me trust my own reasoning over the warning instead of loosening the rule just to silence it.
That's the real value of the mapping above, beyond vocabulary: half the AWS security decisions I've made so far weren't new decisions, they were old ones in a new interface.
None of this makes AWS identical to self-hosting on Linux — the managed side of things (durability guarantees, scaling, cross-AZ replication) is real engineering that's easy to take for granted. But having already built the mental model locally means I'm rarely learning a concept for the first time when I pick up a new AWS service — usually I'm just learning AWS's specific vocabulary and knobs for something I already understand.