## page was renamed from Azure/WellArchitected
= Azure 2024 Well ARCHITECTED notes =
 * Links: [[Azure/AdoptCloud]]

== 5 x Pillars / Overview ==
 * WAF focus on Architecture not on Implementation.
   * [[https://learn.microsoft.com/en-us/training/modules/azure-well-architected-introduction/2-pillars]]
   * https://youtu.be/vTjasx3ahjM
   * Azure provides [[https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/checklist|checklists]] and [[https://learn.microsoft.com/en-us/azure/well-architected/cost-optimization/tradeoffs|tradeoffs]] !!!.
     * Tradeoffs, pick 2 from: Right, Fast, Cheap
 * In an ideal architecture, you'd build the most secure, high-performance, highly available, and efficient environment possible.
   * However, as with everything, there are tradeoffs.
   * build an environment with the highest level of all these pillars, there's a cost.
     * might be in money
     * time to deliver
     * operational agility.
 * Every organization has different priorities that affect the design choices that are made in each pillar.
   * As we design our architecture, we need to determine which trade-offs are acceptable and which aren't. 

== Work Flow ==
 1. This doc - WAF
 2. Workloads - Apps - Business service - etc.
 3. Checklist and tradeoffs
 4. Assessments
    * Gives Score and recommendations
    * Ongoing milestone's


=== 1. Cost optimization ===
 * Bill
 * Waste
 * Dynamic scale
 * Shutdown over night

== 2. Operational excellence - Test - Monitoring ==
 * Collect metrics at all levels - 
 * Automate
 * Test 
   * 

== 3. Performance efficiency ==
 * Match App with Demand
 * Scaling (Up or Out[Horizontal])
 * Identify bottlenecks
 * Increase app performance

== 4. Reliability ==
 * Define SLA
   * Examine HA - cluster, LB
 * Analyse possible data loss and major downtime scenarios.
   * include recovery strategies and the cost/benefit tradeoff for each
   * get insights into org priorities and role of app.
   * Include RPO (The maximum duration of acceptable data loss) e.g. 30 minutes of data.  Limit data loss, not data theft.
   * Include RTO (The maximume duration of acceptable downtime during disaster) e.g. 8h
     * With RPO and RTO you can design backup, restore, replications and recovery capabilities to meet these objectives.
   * Where possible use existing services and best practices, try to resist creating your own.

== 5. Security ==
 * Protecting data we use, store and transmit.
 * Might be subject to more stringent legal and regulatory requirements e.g. PCI

=== Defense in depth (onion) ===
 * multi layer creates a depth of protection if one layer fails or an attacker bypasses it.
 * Layers
   * Data
     * Encryption
   * Application
     * Malicious code injections and execution - e.g. SQL injection for cross-site scripting (XSS)
   * VM/compute
     * malware can lead to further attacks and lateral movement.
   * Networking
     * Open ports e.g. RDP or SSH
   * Perimeter
     * DOS - downtime
   * Policies and access
     * Auth - OpenID Connect, OAuth or Kerberos(AD)
     * Limit permissions
     * Monitoring
   * Physical security
     * Unauthorized access to facilities.