Availability SLA Tiers
| SLA Level | Uptime % | Max Downtime/Year | Max Downtime/Month | Typical Use Case |
|---|---|---|---|---|
| Two nines | 99% | 3.65 days | 7.3 hours | Development/test environments, non-critical internal tools |
| Three nines | 99.9% | 8.77 hours | 43.8 minutes | General business applications, non-revenue-critical systems |
| Four nines | 99.99% | 52.6 minutes | 4.4 minutes | Business-critical applications, e-commerce platforms |
| Five nines | 99.999% | 5.26 minutes | 26.3 seconds | Mission-critical: financial trading, emergency services, hospitals |
Resilience Metrics — MTTR, MTTF, MTBF
| Metric | Full Name | What It Measures | Better When | Relationship |
|---|---|---|---|---|
| MTTF | Mean Time to Failure | Expected operational lifetime before a component fails — a reliability measure for non-repairable components | Higher = more reliable hardware | MTBF = MTTF + MTTR |
| MTTR | Mean Time to Repair | Average time from failure detection to full restoration — the primary resilience metric | Lower = faster recovery | |
| MTBF | Mean Time Between Failures | Average time between end of one failure and start of next — overall system reliability | Higher = more reliable system |
Infrastructure Cost Components
| Cost Type | Description | On-Premises | Cloud | Accounting Treatment |
|---|---|---|---|---|
| Initial installation | Hardware, software licenses, deployment labor | High — hardware purchase + data center buildout | Low — no hardware; setup labor only | Capital expenditure (CapEx) — depreciated over time |
| Ongoing maintenance | Annual licensing, support contracts, staff time, monitoring | Medium-High — staff, hardware maintenance | Medium — subscription fees, managed services | Operational expenditure (OpEx) — expensed as incurred |
| Repair and replacement | Failed hardware replacement, emergency patches, redundant component costs | High — physical hardware replacement | Low — provider handles hardware; pay for capacity | Mixed: emergency CapEx or OpEx depending on classification |
| Indirect costs | Power, cooling, physical space, insurance | Present — data center costs | Included in provider pricing | OpEx — facility costs |
Recovery Method Comparison
| Method | Process | Time (Single System) | Time (50 Systems) | Requirements |
|---|---|---|---|---|
| Manual rebuild from original media | Boot from OS media → install OS → apply all patches → install applications → restore data | ~90 minutes | ~75 hours | Installation media only — no upfront investment |
| Corporate image deployment | Boot from network/USB image → image deploys pre-configured baseline → restore data | ~15 minutes | ~12.5 hours | Maintained image library — upfront investment, ongoing maintenance |
| Cloud instance restore from snapshot | Provision new instance from saved snapshot → data already included | ~5 minutes | ~4 hours (parallel) | Regular snapshot schedule, cloud infrastructure |
| Containerized application restart | Container orchestrator automatically restarts failed container from image | <1 minute (automated) | <5 minutes (parallel) | Containerized architecture, orchestration platform |
Patch Management Workflow
| Step | Action | Who | Security Consideration |
|---|---|---|---|
| 1 | Vendor releases patch (e.g., Patch Tuesday) | Vendor | Subscribe to vendor security advisories; evaluate CVSS severity score |
| 2 | Evaluate severity and applicability | IT Security team | Critical/High CVEs should enter emergency track; Medium/Low follow standard cycle |
| 3 | Test patch in non-production environment | IT/QA team | Verify patch does not break critical business applications; test for compatibility |
| 4 | Validate and approve for production | Change control board | Change management approval; rollback plan documented before deployment |
| 5 | Deploy to production | IT Operations | Deploy in waves (pilot group → broader rollout); monitor for issues |
| 6 | Verify and document | IT Security team | Confirm patch applied on all in-scope systems; update vulnerability scan baseline |
Inability to Patch — Compensating Controls
| Device Type | Why It Cannot Be Patched | Compensating Control | Notes |
|---|---|---|---|
| HVAC / building automation controllers | Embedded firmware, no update mechanism, proprietary hardware | Dedicated VLAN; firewall permitting only required protocols; no internet access | Physical access should also be restricted |
| Time clocks / access control panels | Purpose-built, closed firmware, vendor may no longer support | Isolated network segment; monitor for anomalous traffic at network boundary | Replace at end of vendor support lifecycle |
| Legacy medical devices (FDA-regulated) | Firmware updates require FDA re-approval; update process requires field engineer | Isolate on medical device VLAN; restrict communication to approved systems only; compensating controls documented for compliance | Work with vendor on update schedule; plan lifecycle replacement |
| Legacy industrial equipment (Windows XP/CE) | Application software incompatible with modern OS; vendor no longer supports | Air gap from corporate network; allow only required communications through strictly controlled interface | Budgeting for replacement is the long-term solution |
| End-of-support software | Vendor discontinued support; no patches will ever be released | Maximize other controls; isolate from internet and untrusted networks; plan replacement | Running end-of-support software is an accepted risk that must be explicitly documented |
Power Infrastructure Tiers
| Power Component | Function | Protection Against | Coverage Duration |
|---|---|---|---|
| Primary utility feed | Main electrical power from utility provider | N/A — this is what fails | Continuous when available |
| Dual utility feeds | Two independent power feeds from separate substations | Single substation failure; line fault on one feed | Continuous (one feed remains if other fails) |
| UPS | Battery-backed immediate power bridge | Momentary outages; power quality issues (sags, surges, noise); time to start generator | Minutes (5–30 min typical) |
| Generator | Diesel/natural gas backup power generation | Extended utility outages; sustained power failure | Hours to days (fuel-dependent) |
| UPS + Generator | Combined: UPS provides immediate power while generator starts | Any utility power failure of any duration | Indefinite (while fuel available) |
Scalability Security Requirement
| Infrastructure State | Security Coverage Required | Failure Mode if Not Addressed |
|---|---|---|
| Baseline (4 instances) | All 4 instances: SIEM logging, IDS, endpoint monitoring, firewall policy | N/A — baseline |
| Scale-out event (+12 instances = 16 total) | All 16 instances must be covered — auto-scaling must include security tool provisioning | 12 new instances invisible to SIEM; attackers can operate on new instances with no detection |
| Scale-in event (16 → 4 instances) | Terminated instances decommissioned from monitoring; no orphaned monitoring entries | Monitoring artifacts for decommissioned instances create alert noise; security tool licenses wasted |
| Orchestrated deployment (IaC) | Security tool installation and configuration included in the IaC template | Manually added security tools are not repeatable; some deployments will be missing controls |
The Twelve Infrastructure Considerations — Summary
| # | Consideration | One-Line Definition | Primary Metric |
|---|---|---|---|
| 1 | Availability | Systems accessible when needed, by authorized users only | Uptime % / SLA |
| 2 | Resilience | Ability to maintain and restore availability after failure | MTTR |
| 3 | Cost | Total financial impact including CapEx, OpEx, maintenance, and tax | Total Cost of Ownership (TCO) |
| 4 | Responsiveness | Speed of request-to-response; limited by the weakest component | Latency (ms) |
| 5 | Scalability | Ability to grow or shrink capacity to match demand | Scale time; max capacity |
| 6 | Elasticity | Automatic, real-time scaling in response to demand | Time to scale; cost efficiency |
| 7 | Ease of Deployment | How simply and reliably all components can be provisioned and configured | Deployment time; error rate |
| 8 | Risk Transference | Shifting financial consequences of security incidents to a third party | Insurance coverage limit |
| 9 | Ease of Recovery | Speed and simplicity of restoring systems after an incident | RTO (Recovery Time Objective) |
| 10 | Patch Availability | Vendor's ongoing release of security and bug-fix updates | Patch cycle frequency; time to remediate |
| 11 | Power | Reliable electrical supply including backup (UPS + generator) | Power uptime; UPS runtime |
| 12 | Compute | Processing capacity — single server to distributed multi-cloud | CPU/memory capacity; latency |