1. Firewall
   1. Overview
      1. Firewall rules allow or deny traffic to and from VMs based on configuration
      2. Firewall rules are always enforced
      3. Firewall rules are stateful
      4. Defined at the network level, but enforced at the instance level
      5. Enforced between instances and other networks, as well as between instances on the same network
      6. Every network has an implied allow egress rule and an implied deny ingress rule
      7. GRE traffic is always blocked
      8. Protocols other than TCP, UDP, ICMP and IPIP is blocked
      9. Egress traffic on TCP port 25 (SMTP) is blocked
      10. DHCP, DNS, Instance metadata (169.254.169.254) and NTP is always allowed
   2. Components
      1. Lowest priority number is the highest priority
      2. Direction of travel is ingress or egress
      3. Action on match is Allow or Deny
      4. Target can be all instances, tagged instances, or service accounts
      5. Source or Destination can be specified for applied rules
      6. Protocol and port can be specified for TCP, UDP, ICMP, SSH
      7. Enforcement status can be Enabled or Disabled
   3. Network Tags
      1. Text attributes for Compute Engine instances
      2. Allows users to apply firewall rules and routes to specific instances or set of instances
      3. Only apply to the VPC network where the instance's primary interface is located
      4. Can be used in different networks for different purposes
      5. Don't have to be unique
2. Shared VPC
   1. Overview
      1. Shares a VPC across multiple projects within an organization
      2. Host project serves the shared VPC
      3. Service project has permission to use Shared VPC
      4. Shared VPC can be controlled by different departments
      5. Ownership of resources in shared VPCs maintained by Service projects
      6. Standalone projets do not use the shared VPC
      7. Separate projects for access control and billing
      8. Only within a single GCP organization
      9. Service projects linked to single host project
      10. Projects cannot be in host and service project
      11. Existing projects can use shared VPC but existing instances cannot
      12. Reserved (static IP) can be associated with and billed to Service project
   2. Roles
      1. Creating a Shared VPC requires Organization or Folder roles
      2. Create organization policy to prevent host project deletion
      3. Shared VPC Admin
         1. Assigned at organization or folder layer
         2. Enables Shared VPC for host project
         3. Attaches service projects
         4. Assigns access to subnets shared by Shared VPC (Network User)
      4. Service Project Admin
         1. Owner/Editor/Compute Instance Admin/Network User of Service Project
         2. Assignment of Network User role in Host Project
         3. Allows Service Project users to access Host Project networks/subnets
         4. Assign for each shared subnet
         5. Ability to discover and use Shared VPC assets
   3. Hybrid
      1. VPN gateway connection to single shared VPC
      2. Access restricted by different projects
      3. Interconnect/VPN connects to Host Project
   4. NICs
      1. Multiple VPCs in Host Project (some shared)
      2. Multiple NIC appliance in Host Project
      3. Service project instance custom routes
         1. Tagged instances
         2. vm-appliance as next hop
         3. 0.0.0.0/0 as destination
   5. Resources
      1. Compute Engine instances
      2. Compute Engine instance Templates
      3. Compute Engine instance Groups
      4. Kubernetes Engine Clusters
      5. Internal IP Addresses
      6. Internal DNS
      7. Cloud DNS Private Zones
      8. Load Balancer
3. VPN
   1. Overview
      1. Low cost private, encrypted tunnel to GCP VPC over public Internet connection
      2. Available from any location with Internet connection
      3. Ideal for low volume data connections
      4. Supports Site to Site VPN connection over IPSec
      5. Cloud VPN gateways are regional resource
      6. Can serve other regions in VPC
      7. Up to 3 Gbps per tunnel
      8. Best performance over Cloud Peering connection
      9. Can use multiple (up to 8) tunnels for increased performance
      10. 3 Gbps x8 = 24 Gbps per gateway combined
      11. Static and dynamic routes using Cloud Router
      12. Supports IKEv1 and IKEv2 using shared secret
      13. Site to site connectivity only
   2. Routing
      1. Dynamic
         1. Routes are created and updated automatically
         2. Requires Cloud Router service and peer connection that supports BGP
         3. Cloud Router exchanges BGP routes with peer router/gateway
         4. Subnets/routes are automatically discovered and updated when changed
      2. Static
         1. Local and peered routes are manually created and updated
         2. Higher admin overhead
         3. Used when BGP is not available
         4. Route based
            1. Specify remote (peer) IP ranges to connect to
            2. Preferred over policy routes
         5. Policy based
            1. Specify both local ranges and remote range
            2. Used for peer routers that require it
   3. BGP
      1. Anatomy
         1. Private Autonomous System Number (ASN) for both Cloud Router and Peer Gateway
         2. Linked-local IP address for Cloud Router and Peer Gateway, e.g. 169.254.1.1 and 169.254.1.2
      2. Routing
         1. Regional mode (default) advertises learned routes for its own region
         2. Global mode advertises learned routes for all regions in the VPC
         3. Applied across entire VPC
         4. Regional dynamic routing is useful for regional services, such as Internal Load Balancer
         5. By default, Cloud Router advertises all known routes/subnets to peer network
         6. Can limit advertised routes by selecting subnets to be advertised
         7. Must manually update newly needed routes / subnets
         8. Does not affect learning new peer network routes
      3. Firewall
         1. BGP operates over TCP port 179
         2. Most peer gateways enable it automatically
         3. No need to configure on GCP
   4. High Availability
      1. Overview
         1. Enables redundancy, failover and enhanced throughput
         2. Allows for the interruption of individual gateways and/or tunnels
      2. HA mode
         1. Overview
            1. Enables easy management of redundant gateways
            2. Requires Cloud Router
         2. Types
            1. Single gateway/two tunnels
            2. Two gateways/one tunnel each
            3. Two gateways/two tunnel each
         3. Peer Gateway Requirements
            1. Multiple IP peer IP Addresses
            2. Peer supports multi-path routing
         4. Failover
            1. Assign one router/tunnel higher priority
            2. If it fails, VPN service failover to secondary route
         5. Load Balance
            1. Assign each route/tunnel same priority
            2. Load is balanced across tunnels increasing throughput
      3. Classic mode
         1. Refers to regular VPN
      4. Deployments
         1. Single gateway, two tunnels
            1. Require two different peer network IPs
         2. Two gateways, one tunnel each
            1. Two gateways in the same region
            2. Each tunnel connects to the same Peer IP
            3. Peer gateway must support multi-path routing
         3. Two gateways, two tunnels each
            1. Each Cloud VPN gateway connects to each peer gateway
            2. Highest redundancy and throughput
4. Instance Groups
   1. Overview
      1. Group of instances managed as a group
      2. Managed and unmanaged varieties
      3. Works with load balancers
      4. Automatically scale
      5. Unmanaged ideal for group with different machine types
   2. Configuration
      1. Create global instance template
      2. Can reference zonal resource
      3. Define autoscaling group configuration
      4. Machine type, zone, image, scripts
      5. Create regional managed instance group from template
   3. Update Rollout
      1. Deploy inside existing managed instance group
      2. Rollout happens automatically
      3. Control the pace of update rollout
      4. Perform partial rollout for canary testing
      5. Updates the entire group, not just one instance
   4. Customization
      1. Startup script is easy and quick to configure
      2. Requires time to start-up and ready
      3. Images require more investment to setup
      4. VM is ready for use right away
   5. Load Balancing
      1. Distributes traffic across instances in the group
      2. Load balancer must be assigned to a backend target pool or instance group
      3. HTTP load balancer must use instance group
      4. Load balancer contains one of backend service
      5. Backend service links to one or more backends
      6. Backend service knows which backend to use
      7. Backend links to one or more instance groups
      8. Traffic is allowed subject to firewall rules
      9. Firewall rules applied to instances, not load balancers
   6. Autohealing
      1. Health checks with auto-healing groups
      2. Deletes and replaces failed instances with an indentical instance
      3. Managed instance groups only