Managed Instance Groups (MIG)

An instance group is a collection of VMs that you can manage as a single entity

An instance template is a resource that can be used to create VM instances and managed instance groups

Compute Engine/Instance Templates/Create Instance Template

Similar UI used for creating an instance

Instance templates are immutable

Instance group types

  • Managed — managed automatically, autoscales, etc.
    • requires an instance template to perform the autoscaling
    • deleting a managed instance group will delete all of its instances
  • Unmanaged — manually manage the instances within the group
    • deleting an unmanaged instance group will leave all of its instances behind


  • Instance Templates are much better than manually creating instances
    • Even via CLI - Can create Instance Templates via CLI
  • Managed Instance Groups much better than unmanaged ones
    • Unmanaged ones are more restricted and not nearly as useful
  • Autoscaling much better than manually managing instances
  • Treat most resources as ephemeral/expendable


CIA triad

  • Confidentiality
  • Integrity
  • Availability

AAA model of security

  • Authentication - Who are you?
  • Authorization - What are you allowed to do?
  • Accounting - What did you do?

OWASP "Security by Design" Principles

Key Security Products/Features — AuthN

  • Identity
    • Humans in G Suite, Cloud Identity
    • Applications & Sercives us Service Accounts
  • Identity hierarchy
    • Google Groups
  • Can use Google Cloud Directory Sync (GCDS) to pull from LDAP (no push)

Key Security Products/Features — AuthZ

  • Identity hierarchy (Google Groups)
  • Resource hierarchy (Organization, Folders, Projects)
  • Identity and Access Management (IAM)
    • Permissions
    • Roles
    • Bindings
  • GCS ACLs
  • Billing management
  • Networking structure & restrictions

Check out my wife's FREE UI designs at

Key Security Products/Features — Acct

  • Audit/Activity Logs (provided by Stackdriver)
  • Billing export
    • To BigQuery
    • To file (in GCS bucket)
      • Can be JSON or CSV
  • GCS Object Lifecycle Management

IAM: Resource Hierarchy

  • Resource
    • Something you create in GCP
  • Project
    • Container for a set of related resources
  • Folder
    • Contains any number of Projects and Subfolders
  • Organization
    • Tied to G Suite or Cloud Identity domain

IAM: Permissions and Roles


  • A Permission allows you to perform a certain action
  • Each one follows the form Service.Resource.Web
  • Usually correspond to REST API methods
    • Examples:
      • pubsub.subscriptions.consume
      • pubsub.topics.publish


  • A Role is a collection of Permissions to use or manage GCP resources
  • Primitive Roles — Project-level and often too broad
    • Viewer is read-only
    • Editor can view and change things
    • Owner can also control access & billing
  • Predefined Roles — Give granular access to specific GCP resources
    • E.g.: roles/bigquery.dataEditor, roles/pubsub.subscriber
  • Custom Role — Project or Organization level collection you define of granular permissions

IAM: Members and Groups

A member is some Google-known identity

Each Member is identified by a unique email address


  • user: Specific Google Account
    • G Suite, Cloud Identity, Gmail, or validated email
  • serviceAccount: Service account for apps/services
  • group: Google group of users and service accounts
  • domain: Whole domain managed by G Suite or Cloud Identity
  • allAuthenticatedUsers — Any Google account or service account
  • allUsers — Anyone on the Internet (Public)

Group should be one's default choice, always


  • A Google group is a named collection of Google accounts and service accounts
  • Every group has a unique email address that is associated with the group
  • You never act as the group
    • But membership in a group can grant capabilities to individuals
  • Can be used for owner when whithin an organization
  • Can nest groups in an organization
    • Example: one group for each department, all those in group for all staff

IAM: Policies (Bindings)


  • A Policy binds Members to Roles for some scope of Resources
  • Answers: Who can do what to which thing(s)?
  • Attached to some level in the Resource Hierarchy
    • Organization, Folder, Project, Resource
  • Roles and Members listed in policy, but Resources identified by attachment
  • Always additive ("Allow") and never substractive ("Deny")
    • Child policies cannot restrict access granted at a higher level
  • Once policy per resource
  • Max 1500 member bindings per policy
  • Usually takes less than 60s to apply changes (may take up to 7min)

Add policy binding

gcloud <group> add-iam-policy-binding <resource_name> --role <role_id_to_grant> --member user:<user_email>

Remove policy binding

gcloud <group> remove-iam-policy-binding <resource_name> --role <role_id_to_revoke> --member user:<user_email>


gcloud beta compute instances add-iam-policy-binding myvm --role roles/compute.instanceAdmin --member

Using IAM Securely

Billing Access Control

Billing Accounts

  • A Billing Account represents some way to pay for GCP service usage
  • Type of Resource that lives outside of Projects
  • Can belong to an Organization (i.e. be owned by it)
    • Inherits Organization level IAM policies
  • Can be linked to projects
    • But does not own them
      • No impact on project IAM

Billing IAM Roles

  • Billing Account Creator - Create new self-serve billing accounts
  • Billing Account Administrator - Manage billing accounts (but not create them)
  • Billing Account User - Link projects to billing accounts.
  • Billing Account Viewer - View billing account cost information and transactions
  • Project Billing Manager - Link/unlink the project to/from a billing account



  • Latency reduction
    • Use servers physically close to clients
  • Load balancing
    • Separate from auto-scaling
  • System design
    • Different servers may handle different parts of the system
    • Especially when using microservices (instead of monolith)

Load Balancing Methods

  • Cross-Region Load Balancing (with Global Anycast IPs)
  • Cloud Load Balancer (all types, internal and external)
  • HTTP(S) Load Balancer (with URL map)

Unicast vs Anycast IP addresses

  • Unicast - There is only one unique device in the world that can handle this; send it there
  • Anycast - There are multiple devices that could handle this; send it to any of them - but ideally the closest

Layer 4 vs. Layer 7

  • TCP (of TCP/IP) is usually called Layer 4 (L4)
    • It works solely with IP addresses
  • HTTP and HTTPS work at Layer 7 (L7)
    • These know about URLs and paths
  • Each layer is built on the one below it
  • Therefore:
    • To route based on URL paths, routing needs to understand L7
    • L4 cannot route based on the URL paths defined in L7


  • Name resolution (via the Domain Name System) can be the first step in routing
  • But that comes with a number of problems
    • Layer 4 - Cannot route L4 based on L7's URL paths
    • Chunky - DNS queries often cached and reused for huge client sets
    • Sticky - DNS lookup "locks on" and refreshing per request has high cost
      • Extra latency because each request includes another round-trip!
      • More money for additional DNS request processing
    • Not Robust - Relies on the client always doing the right thing
      • Spoiler: They don't
    • Premium tier "cold potato" routing with global anycast IPs avoid these problems

Routing Among Resources

  • VPC (global) is Virtual Private Cloud — Your private SDN space in GCP
    • Not just resource-to-resource — Also manages the doors to outside & peers
  • Subnets (regional) create logical spaces to contain resources
    • All Subnets can reach all others — globally, without any need for VPNs
  • Routes (global) define "next hop" for traffic based on destination IP
    • Routes are global and apply by Instance-level Tags, not by Subnet
    • No route to the internet gateway means no such data can flow
  • Firewall Rules (global) further filter data flow that would otherwise route
    • All Firewall Rules are global and apply by Instance-level Tags or Service Account
    • Default Firewall Rules are restrictive inbound and permissive outbound

IPs and CIDRs

  • IP address is abc.def.ghi.jkl (dotted quad) where each piece is 0-255
  • CIDR block is group of IP addresses specified in IP/xy notation
    • Turn IP address into a 32-bit binary number
      • e.g. -> 0001010 00001010 00000000 11111110
      • /xy in CIDR notation locks highest (leftmost) bits in IP address (0-32)
      • abc.def.ghi.jkl/32 is single IP address because all 32 bits are locked
      • abc.def.ghi.jkl/24 is 256 IP addresses because last 8 bits (jkl) can vary
      • means "any IP address" because no bits are locked
      • RFC1918 defines private (i.e. non-Internet) address ranges you can use:
        •,, and

Shared VPC

  • In an Organization, you can share VPCs among multiple projects
    • Host Project: One project owns the Shared VPC
    • Service Projects: Other projects granted access to use all/part of Shared VPC
  • Lets multiple projects coexist on same local network (private IP space)
  • Lets a centralized team manage network security