Forem: Vital F

AWS. GCP. Azure. Pocket vocabulary.

Vital F — Fri, 30 Jan 2026 23:00:32 +0000

This is a quick lookup sheet for abbreviations and cloud terms. Each entry aims to be: what it is, in plain English, plus when it matters.

Cloud names (obvious, but included for completeness)

AWS: Amazon Web Services.
GCP: Google Cloud Platform.
Azure: Microsoft Azure.

Identity, access, and governance

IAM (Identity and Access Management): The permission system: who/what can do what to which resource. Many cloud incidents boil down to IAM being too broad or attached at the wrong scope.
RBAC (Role-Based Access Control): A permission model where you assign roles (sets of permissions) to identities. It's the normal way teams grant access without hand-writing one-off permissions.
MFA (Multi-Factor Authentication): Logging in with a second factor (app code, hardware key) in addition to a password. It's one of the highest-ROI protections you can add to any account.
SSO (Single Sign-On): Log in once with your company identity and access multiple tools/services. It simplifies onboarding/offboarding and makes auditing access much easier.
Tenant (Azure): Your organization's top-level identity boundary in Microsoft Entra ID (directory). It's "where your users live," and where many org-wide controls begin.
Microsoft Entra ID (formerly Azure AD): Azure's identity directory service (users, groups, app registrations). It's the backbone for Azure authentication and lots of governance workflows.
AWS Organizations: AWS governance feature to group multiple AWS accounts and apply org-level controls. It's how larger AWS setups stop being "a pile of accounts" and start being manageable.
OU (Organizational Unit) - AWS Organizations: A logical grouping of AWS accounts inside an Organization. You typically group accounts by environment or business unit so you can apply the same guardrails to all of them.
SCP (Service Control Policy) - AWS Organizations: A policy that limits what an account is allowed to do, even if IAM would otherwise allow it. Think "safety rails" that prevent entire categories of mistakes.
Cloud Organization (GCP): The top-level GCP resource that represents your company. It enables org-wide policy and a clean hierarchy above projects.
Folder (GCP): A grouping layer between Organization and Projects. It's how you apply policy/IAM to many projects at once (for example: "everything under Prod").
Management Group (Azure): A governance grouping above subscriptions. It's commonly used to apply policy/RBAC across many subscriptions consistently.
Policy (generic): Rules/guardrails you apply to restrict or validate configurations (for example: "no public storage," "only approved regions"). Good policies prevent accidents instead of just detecting them later.

Billing / ownership "containers"

Account (AWS Account): A strong isolation boundary in AWS; often the unit for billing, IAM boundaries, and blast-radius control.
Project (GCP Project): The main unit where resources live and APIs are enabled. Projects often map cleanly to "one app" or "one environment."
Subscription (Azure Subscription): The main Azure billing and RBAC boundary. It's commonly used as an environment boundary (dev vs prod) when you want hard separation.
Resource Group (Azure): A group of Azure resources managed together (lifecycle, RBAC, and organization). A common pattern is "one resource group per app per environment," even within one subscription.
Quotas / limits: Per-service capacity limits (number of instances, IPs, API requests, etc.). Hitting a quota often looks like a mysterious outage if you're not watching for it.

Geography and availability

Region: A geographic area where cloud resources run (for example: "us-east-1"). Regions affect latency, data residency/compliance, and which services/features are available.
Location (Azure): Azure's term for a region. Many Azure resources have a "location" property.
AZ (Availability Zone) - AWS: A separate fault domain inside a region (independent power/cooling/building). High-availability designs often spread across 2-3 AZs.
Zone (GCP): Similar concept to AWS AZ: a fault domain inside a region. Many compute resources are zonal, so spreading across zones improves availability.
HA (High Availability): Designing systems to keep working through failures (instance failure, zone failure, etc.).

Networking (private networks and segments)

VPC (Virtual Private Cloud) - AWS: Your private network boundary (routing, subnets, connectivity) in AWS.
VPC Network - GCP: GCP's VPC. Key difference: it is global within a project; subnets are regional.
VNet (Virtual Network) - Azure: Azure's private network boundary (similar role to AWS VPC).
Subnet / Subnetwork: A smaller IP range "inside" your VPC/VNet/VPC Network used for segmentation.
- Notes: AWS subnets are AZ-scoped; GCP subnetworks are region-scoped.
CIDR (Classless Inter-Domain Routing): The notation for an IP range (example: 10.0.0.0/16). Your CIDR choices determine how many IPs you have and whether networks can be connected cleanly later.
Routing / route table: Rules that decide where traffic goes (internet, NAT, peered network, etc.).
NAT (Network Address Translation): A way for private IPs to reach the internet without being directly reachable from the internet. Commonly used for "private subnets that still need outbound access."
Peering: Connecting two private networks so they can route traffic to each other. It's how you get private service-to-service communication across network boundaries.
VPN (Virtual Private Network): Encrypted tunnel over the internet between networks (office ↔ cloud, cloud ↔ cloud).
AWS Direct Connect: Dedicated private connectivity from your datacenter/office to AWS. It gives more predictable performance than a VPN and can be cheaper at scale.
Azure ExpressRoute: Dedicated private connectivity to Azure (similar role to Direct Connect).

Security controls at the network layer

Security Group (AWS): Stateful firewall rules attached to network interfaces/resources. It's one of the most common "allow/deny" controls for AWS workloads.
Firewall rules (GCP): Network-level firewall rules with targets (tags/service accounts) rather than a single "security group object." This different attachment model changes how you group and reason about access.
NSG (Network Security Group) - Azure: A set of allow/deny rules attachable to subnets and/or NICs. It's a common access control layer for Azure networks.
NIC (Network Interface Card) / network interface: The virtual network adapter attached to a VM or similar resource.
ENI (Elastic Network Interface) - AWS: AWS's name for a virtual network interface.

Storage (mentioned in examples)

S3 (Amazon Simple Storage Service): AWS's object storage service.
Bucket (S3 bucket): A named container in object storage that holds objects (files) and metadata. The "public bucket" mistakes people talk about are usually bucket policies/ACLs set too open.

Data and analytics (common "cloud data" vocabulary)

Amazon Redshift (often said as "Redshift"): AWS managed data warehouse for analytics SQL (reporting/BI). Common equivalents are BigQuery (GCP) and Azure Synapse / Fabric Warehouse (Azure).
Data warehouse: A database optimized for analytics queries (lots of reads, big scans, aggregations) rather than app transactions.
OLTP (Online Transaction Processing): App-style databases optimized for many small reads/writes (orders, users, payments).
OLAP (Online Analytical Processing): Analytics-style queries optimized for reporting and aggregation ("show revenue by region for the last 12 months").
Data lake: A storage-based approach where raw/curated data lives in object storage (like S3) and multiple tools query/process it.
ELT / ETL: Two ways to move/transform data. ETL transforms before loading into the warehouse; ELT loads first, then transforms inside/near the warehouse.

Kubernetes (only if you use Kubernetes)

Kubernetes (K8s): An orchestration system for running containers at scale (scheduling, scaling, rollout, service discovery).
EKS (Elastic Kubernetes Service) - AWS: Managed Kubernetes on AWS.
GKE (Google Kubernetes Engine) - GCP: Managed Kubernetes on GCP.
AKS (Azure Kubernetes Service) - Azure: Managed Kubernetes on Azure.
Cluster: The Kubernetes control plane + worker nodes that run your workloads. It's a major operational boundary (upgrades, policies, networking modes, cost allocation).
Namespace: A logical partition inside a cluster. It helps organize teams/apps and apply quotas/RBAC, but it's not "hard isolation."
Pod: The smallest schedulable unit in Kubernetes (one or more containers sharing networking/storage context).
Deployment: Kubernetes controller for stateless replicated pods with rolling updates.
StatefulSet: Controller for workloads that need stable identity and stable storage patterns.
DaemonSet: Controller that runs one pod per node (often for agents like logging/monitoring).
Ingress: Kubernetes API/resource pattern for HTTP routing into services (usually implemented by an ingress controller).
CNI (Container Network Interface): The plugin system that provides pod networking. CNI differences affect IP consumption, networking limits, and migration surprises.

Observability and operations (mentioned or commonly paired)

Audit logs: Records of "who did what" actions in the cloud control plane.
- AWS example: CloudTrail (see below).
CloudTrail (AWS): AWS service that records API calls and account activity. It's foundational for investigations and compliance.
CI/CD (Continuous Integration / Continuous Delivery): Automated build/test/deploy pipelines. It's how most teams ship changes safely and repeatedly.

Billing, pricing, and "usage" vocabulary

Metered billing / pay-as-you-go: You pay based on measured usage (time running, requests, GB stored, GB transferred).
Usage: The measurable thing that gets billed (hours, requests, GB-months, vCPU-seconds, etc.).
Billing period: The time window for an invoice (often monthly).
Invoice: The official bill for a billing period.
Line item: One charge on an invoice (for a specific service, region, SKU, or usage type).
SKU: A specific priced unit/variant of a service (often how providers break down billing).
Rate card / price sheet: A list of prices per SKU/usage type (often region-specific).
Free tier: "Free within limits" pricing (limited time, limited usage, or specific services). It's easy to exceed quietly if you don't set budgets/alerts.
Credits: Promotional or contract credits that offset charges on the invoice.
Budget: A spending target with alerts when you're trending over it.
Cost allocation: The practice of mapping spend to teams/apps/environments (usually via tags/labels and account structures).
Tagging (AWS tags) / Labels (GCP labels) / Tags (Azure tags): Key/value metadata used for organization, automation, and cost reporting.
Chargeback / showback: Internal accounting patterns. Showback reports cost per team; chargeback actually bills teams internally.
Commitment / reserved capacity: You commit to a certain spend or capacity in exchange for a discount.
- AWS examples: Reserved Instances (RIs), Savings Plans.
- GCP examples: Committed Use Discounts (CUDs).
- Azure examples: Reserved Instances / Reserved Capacity, Savings Plan (Azure).
On-demand: Default pricing with no long-term commitment (usually the highest unit price, but most flexible).
Spot (AWS) / Preemptible (GCP) / Spot (Azure): Deeply discounted compute that can be interrupted. Great for batch jobs; risky for always-on services unless designed for interruption.
Amortization: Spreading the cost of a commitment (like a 1-year reservation) across the time it benefits, so reports reflect "true" monthly cost.
Blended vs unblended rates (AWS Cost concept): Different ways to compute unit cost when discounts/commitments are involved; the "right" view depends on whether you're allocating shared discounts across accounts.
FinOps: The discipline/practice of managing cloud cost with shared ownership between engineering, finance, and product.
vCPU: "Virtual CPU" - a billing/performance unit for compute. It's not always a perfect match to a physical core, but it's commonly used in pricing.
GB-month / GiB-month: Storage pricing unit meaning "this many gigabytes stored for a month" (often prorated by day/hour).
IOPS: Input/Output Operations Per Second (common in disk pricing/performance).
Data transfer: Network traffic that is often billed separately from compute/storage.
- Ingress: data coming into a cloud/provider (often free, but not always).
- Egress: data leaving a cloud/provider (commonly billed, sometimes expensive).
Cross-zone / inter-AZ traffic: Traffic between zones inside a region; often billed in some clouds/services.
Inter-region transfer: Traffic between regions; commonly billed and relevant to DR/multi-region designs.
API request / API call: A billed operation for some services (for example: "requests to object storage," "reads/writes," "list operations").
Quotas / limits: Provider-enforced caps on usage (also relevant for cost control and safety).
AWS CUR (Cost and Usage Report): AWS's detailed billing export used for deeper analysis and FinOps tooling.

Quick "overlay" concept (important for the article's mental model)

"Policy overlay": A way to think about security rules (SG/Firewall/NSG, org policies, etc.) as layers that can apply across many resources rather than a neat nested folder. This mental model helps during migrations because you stop hunting for a perfect 1:1 "container equivalent."

SVG vs Canvas vs WebGL for Diagram Viewers: Tradeoffs, Bottlenecks, and How to Measure

Vital F — Wed, 31 Dec 2025 17:14:35 +0000

Building an interactive diagram viewer isn’t just “draw some boxes and lines.” In real life you’ve got thousands of shapes, labels everywhere, selection handles, arrows, hover states, drag interactions, pan/zoom, maybe a minimap, plus hit-testing that needs to feel instant. Sometimes you also have auto-routing that wants to run right when the user drops a node. So when folks ask “SVG or Canvas or WebGL?”, what they’re really asking is: who owns the scene graph and the interaction model: you or the browser, – and what kind of workload are you optimizing for? Let’s break it down, nice and practical.

DoiT - CloudDiagrams

1. The mental model: what a diagram viewer is actually doing

Most diagram viewers have three layers whether you call them that or not:

Scene graph: your nodes/edges/labels, geometry, styles, z-order.
Interaction: hit-testing (click/hover), dragging, selection boxes, snapping, keyboard shortcuts.
Redraw strategy: how you repaint when the user pans/zooms, drags one thing, or updates a subset of edges.

SVG, Canvas, and WebGL differ mainly in this: SVG gives you a built-in retained-mode scene graph (DOM), while Canvas and WebGL are immediate-mode and you manage the data + picking yourself.

2. SVG: the “it just works” option … until it doesn’t

When SVG is the right call

Small to medium diagrams (think: hundreds to a few thousand DOM elements, – depends on browser and styling).
Text-heavy diagrams where labels matter and you want decent typography without building a text engine.
You want simple events: click/hover handlers attached to elements, easy accessibility hooks, CSS theming.
You want fast iteration: it’s a great way to ship an MVP.
You want clean exports: SVG for lossless scaling and easy post-processing, with raster formats available when you need flat images. SVG is an image format itself, with broad native support across all platforms.

Where SVG usually bottlenecks

DOM size: every node/edge/label/handle is a DOM element. Too many and the browser starts paying for it in layout/paint/compositing.
Frequent attribute updates: if you’re updating transform, path d, x/y, classes, styles every frame, you’ll feel it.
Expensive visuals: filters (blur/shadow), lots of strokes, dash patterns on thousands of paths can get rough.
Text churn: measuring and re-rendering lots of text on zoom/drag adds up.

Practical SVG tips

Pan/zoom on one parent , not on every element.
Avoid “always-on” UI chrome (handles/guides) for every node. Render that only for selection/hover.
Keep heavy filters rare. Use them surgically.
Cache text measurements and don’t re-measure every tick.

SVG can feel buttery for the right scale. Past a point, the DOM becomes your tax bill.

3. Canvas 2D: fast drawing, but you own the engine

Canvas is immediate-mode: you redraw what you want each frame. It can be very fast for big scenes, but you’re responsible for the stuff SVG gives you for free.

When Canvas is the right call

You’re hitting SVG/DOM limits and pan/zoom/drag needs to stay smooth.
You’re fine implementing picking (hit-testing), selection, and a scene structure yourself.
You want predictable performance: fewer DOM nodes, more “just pixels.”

Common Canvas bottlenecks

Full-scene redraw: naive implementations repaint everything every frame. Sometimes that’s okay; sometimes it’s your biggest cost.
Text: often the first thing to hurt. measureText, lots of labels, and zooming text are expensive.
Complex paths: thousands of polylines, arrowheads, and strokes can get heavy if you rebuild them constantly.
Hit-testing: doing a linear scan of every object on every mousemove will absolutely cook your CPU.

Practical Canvas tips

Use layers: one canvas for the “base scene,” one for interactions (selection box, guides, hover glow).
Add a spatial index: grid/quadtree/R-tree so you only consider nearby objects for hit-testing and visibility.
Cache geometry: precompute Path2D where it helps, cache arrowheads/icons.
Consider OffscreenCanvas/Workers when feasible for heavy redraw or routing work.

Canvas is usually the best “grown-up step” when SVG is struggling. Just know you’re signing up to build more infrastructure.

4. WebGL: the throughput king (with a big engineering price tag)

WebGL shines when you have a lot of primitives and need to push them efficiently on the GPU.

When WebGL is the right call

Very large scenes: tens/hundreds of thousands of primitives.
You need GPU-friendly effects and smooth zooming/panning at scale.
You’re willing to build a rendering pipeline (batching, buffers, shaders).

Common WebGL bottlenecks

CPU → GPU uploads: if you rebuild and upload massive buffers every frame, you lose the whole point.
Too many draw calls/state changes: lack of batching/instancing kills performance.
Text: you’ll likely need SDF (Signed Distance Field) fonts, glyph atlases, or a hybrid approach.
Picking: you’ll implement CPU indexing, or color picking, or both.

Practical WebGL tips

Batch and instance aggressively.
Keep buffers stable and update only what changed.
Go hybrid: WebGL for geometry, DOM/SVG/HTML overlay for editable text and UI controls is a very common “best of both worlds” move.

WebGL pays off when you’re truly operating at scale. For many viewers, it’s overkill unless you know your targets.

5. Choosing quickly: some solid rules of thumb

Shipping fast + lots of labels: start with SVG, maybe with a plan to hybridize later.
You need consistent 60 FPS on moderately large scenes: Canvas 2D (with indexing + layers).
You’re aiming at huge graphs or GPU-level visuals: WebGL, often hybridized for text/UI.

And yeah, hybrids are normal:

Canvas/WebGL for the scene + HTML/SVG for labels and UI
SVG for editing overlays + Canvas for the heavy background layer

6. Where diagram viewers actually bottleneck (the usual suspects)

In practice, it’s rarely “drawing one line” that hurts. It’s stuff like:

Hit-testing on mousemove without a spatial index
Text layout/measurement and label placement churn
Mass style effects (shadows, blurs, opacity layers)
Huge DOM updates (SVG) during drag/zoom
Heavy computations on the main thread (routing/layout) without worker/batching
GC pressure from allocating tons of temporary objects per frame

If your viewer “feels laggy,” one of these is usually the culprit.

7. How to measure (so you’re not arguing vibes)

7.1 Define workloads

Pick 3-5 scenarios and fix the scale (N nodes, M edges, labels per node):

Pan/zoom around a dense diagram
Drag a node (update connected edges)
Box selection over many elements
Hover highlight (mousemove)
Auto-route/reroute (if applicable)

7.2 Track the right metrics

Frame time: average plus p95/p99 (60 FPS target is ~16.6ms per frame)
Long tasks: anything over 50ms on the main thread
Input latency: how long between pointer move and visible response
Memory & GC: heap growth, GC spikes
CPU vs GPU: what’s dominating in the profile

7.3 Use the right tools

Chrome DevTools Performance: record pan/zoom/drag and inspect Main + Rendering/Paint.
performance.mark() / performance.measure() for your own hotspots (routing, redraw, hit-test).
PerformanceObserver for long tasks.
Optional: a simple FPS overlay, but treat it as secondary to frame-time percentiles.

7.4 Benchmark fair

Warm up once (first render is often slower).
Measure with DevTools closed for “final numbers” (DevTools adds overhead).
Compare apples-to-apples UX (SVG gives event handling “for free”; Canvas/WebGL need picking logic, include that cost).

8. The bottom line

SVG is fantastic for shipping quickly and for text-heavy diagrams, until DOM + paint cost catches up.
Canvas 2D is the practical performance workhorse if you can own hit-testing and scene management.
WebGL is what you reach for when your scene is big-big and you’re ready to build a rendering pipeline, often paired with DOM for text/UI.