​

Doc Type: Component

Tier: Concepts & Architectures | Reader phase: Understanding
Back to tier overview: concepts-architectures/index.md

​

What it is

• Infrastructure components — Deployable Aviatrix constructs that occupy a specific place in the network: Transit Gateway, Spoke Gateway, Edge Gateway, Controller, CoPilot.
• Platform capabilities — Major features or enforcement models that run on infrastructure components and have their own distinct design model: Distributed Cloud Firewall (DCF), Network Segmentation, High-Performance Encryption (HPE), and similar. These are not standalone constructs, but they are significant enough from a platform design perspective to require a dedicated conceptual reference.

​

Goal

​

Primary personas

​

When to create a new Component document

• A new Aviatrix infrastructure construct is introduced that plays a distinct role in the platform
• A major Aviatrix platform capability has its own design model, its own set of concepts (SmartGroups, rules, enforcement points, etc.), and is referenced across multiple Architecture and Guide documents
• An existing infrastructure component or capability gains a significant enough new design model to require a standalone conceptual explanation

• Industry-standard protocols and technologies — BGP, BFD, OSPF, IPsec, TLS, and similar. These are not Aviatrix concepts. A one-paragraph introduction in the context of the relevant Guide or Configuration Guide is sufficient; link to external industry sources for depth. Do not create a dedicated page.
• Sub-features and minor settings — A single toggle, field, or configuration option does not warrant a Component page. If the subject is primarily explained by the steps to enable it, it belongs in a Configuration Guide (if multi-step) or a CoPilot UI Reference doc (if a single action or field).
• Configuration options or UI panels — these belong in CoPilot UI Reference docs.

​

Required sections

1. Overview — 3–5 sentences describing what this component or capability is, what role it plays in the platform, and what it enables. For infrastructure components: include what it connects or manages and the scale at which it operates. For platform capabilities: include which infrastructure components run it and what problem it solves at the platform level. End with a one-sentence “when to use this” guidance.
2. Design — How this component or capability is built and how it works. Use H3 subsections — the specific sub-sections and their names should suit the subject, but every Component document needs at minimum:
   • Core Design — The fundamental design model and the technical reasoning behind it. For infrastructure components: the topology model (hub-and-spoke, inline, distributed). For platform capabilities: the design approach (e.g., distributed enforcement, centralized policy management). Explain what the model is, what technical constraint or problem drove this design choice, and what it enables or prevents. This is technical reasoning — not the business case (that belongs in Solution docs), but the engineering rationale: why this mechanism rather than an alternative, and what that means in practice. Example: HPE exists because a single IPsec tunnel is bound to one CPU core regardless of instance size, which caps throughput; multiple tunnels over private links solve that specific constraint.
   • How It Works — For infrastructure components: where the component sits in the network and how it relates to adjacent constructs (VPCs, on-premises, other Aviatrix components). Include a diagram. For platform capabilities: which platform components execute the capability, how it is instantiated, and where in the data path it operates (e.g., “DCF policies are evaluated in the data plane of each gateway where the feature is enabled”). Include a diagram showing the relationship — a hierarchy, policy model, or annotated network flow as appropriate.
   • Operation Model — How the component or capability processes traffic or executes its function. For infrastructure components: describe the data plane and control plane roles. For platform capabilities: describe how the capability intercepts or acts on traffic, what happens at each stage, and what outcomes it produces (permit, deny, redirect, encrypt, etc.).
3. Key Features — The primary capabilities this subject provides, organized into 4–6 H3 subsections by capability domain. Each H3 contains a brief description (1–2 sentences) and a bullet list of specific capabilities. Keep bullets concrete and behavior-specific — describe what the system does, not what it is.
4. When to Use — 2–4 scenarios where this component or capability is the right choice. Each scenario is an H3 with: the situation (1–2 sentences), why this subject fits (2–3 sentences), and the key benefit. Cross-reference Architecture documents where appropriate.
5. Best Practices — 4–8 design-level recommendations. Focus on design decisions (e.g., sizing, redundancy, placement, rule structure, SmartGroup design) rather than configuration syntax. Each practice should explain why, not just what.

​

Optional sections

• Limitations — Known constraints or scale ceilings worth documenting at the conceptual level
• Integration Points — When this component has notable integration with cloud-provider-native services or third-party tools that affect design decisions
• Comparison with [Other Component] — When two components serve overlapping roles and architects need guidance on choosing between them

​

Tone & voice

• Business why (belongs in Solution): “DCF reduces lateral movement risk across your cloud environment, lowering breach costs and simplifying compliance.”
• Technical why (belongs here): “DCF evaluates policy at each gateway in the data path rather than hairpinning traffic to a central appliance, because a centralized model creates a throughput bottleneck and a single point of failure at scale.”

• “Spoke Gateways route traffic to the Transit Gateway for forwarding” — not “Spoke Gateways integrate with the Transit Gateway”
• “DCF evaluates rules in order and takes the action defined by the first matching rule” — not “DCF provides flexible policy enforcement”

​

Length guidance

​

Frontmatter

---
title: "[Component or Capability Name]"
description: "An overview of [Component or Capability Name] — how it is built, how it works, its key capabilities, and when to use it."
---

​

Mintlify components

​

Linking

• Link in from: Architecture documents (Components section), Validated Designs (Prerequisites), Solutions (Key Components section)
• Link out to: Architecture documents that feature this component, CoPilot UI Reference for the page where this component is configured, API/Terraform Reference for the component’s resource

​

Dos and don’ts