Skipping “what is app streaming” — this chapter covers the concepts that actually shape a working deployment.

Image Builder vs Fleet: Two Different Machines, Two Different Jobs

An Image Builder is a temporary, interactive Windows or Linux instance you log into to install and configure applications, then capture as a reusable AppStream image. A Fleet is the pool of instances that actually serve end users, built from that captured image. Conflating the two is a common intermediate mistake: you never point end users at an Image Builder, and you never manually configure software directly on fleet instances — all fleet configuration flows from the image they were built from.

Fleet Types: Always-On, On-Demand, and Elastic

Always-On fleets keep instances running continuously, giving near-instant session starts at the cost of paying for idle capacity. On-Demand fleets keep instances in a stopped-but-ready state and start them on user connection, trading a short startup delay for lower idle cost. Elastic fleets are a newer, fundamentally different model: instead of a fixed pool of persistent instances, AWS provisions capacity from a shared pool on demand and destroys it after the session, eliminating almost all idle cost but changing how session persistence and custom scripts must be handled.

Stacks: The User-Facing Configuration Layer

A Stack is the entity that actually binds a Fleet to end-user access — it defines storage connectors (Home Folders via S3, Google Drive, OneDrive), user settings (clipboard, file transfer, printing permissions), and the access portal or SAML-based entry point. One Fleet can be associated with multiple Stacks, letting the same underlying application pool serve different user populations under different policy sets.

Session Persistence Models

By default, AppStream sessions are non-persistent — a user’s fleet instance is recycled after disconnect, so anything saved outside a connected storage location vanishes. Home Folders (backed by S3) and persistent application settings (an AppStream feature that snapshots and restores user-specific app configuration, like Office ribbon customizations) are the two mechanisms that give users continuity across otherwise-stateless sessions.

AppStream’s architecture separates the streaming control plane from the compute fleet that actually runs applications.

flowchart TB
    USER["User Browser (HTML5 Client)"] --> GW["AppStream Streaming Gateway"]
    GW --> FLEET["Fleet Instance (Windows/Linux VM)"]
    FLEET --> APP["Streamed Application"]
    FLEET --> AGENT["AppStream Agent"]
    AGENT --> GW
    STACK["Stack Configuration"] --> GW
    IB["Image Builder"] -->|captures| IMG["AppStream Image"]
    IMG --> FLEET
    FLEET --> S3["S3 Home Folders"]
    IDP["SAML 2.0 Identity Provider"] --> PORTAL["Access Portal"]
    PORTAL --> GW
    FLEET --> VPC["Customer VPC (ENI attached)"]
    

The Streaming Gateway

This is the AWS-managed layer that authenticates the user, selects an available fleet instance, and brokers the actual video/input stream between the browser and that instance. It handles protocol negotiation for AppStream’s streaming protocol, which carries compressed frame updates to the client and keyboard/mouse/clipboard events back to the instance.

Fleet Instances and VPC Attachment

Every fleet instance gets an elastic network interface attached directly into a VPC subnet you specify — this is what allows a streamed application to reach internal resources (a license server, an internal database, a file share) exactly as if it were any other EC2 instance on your network, subject to the same security groups and route tables.

You may likeAmazon FSx→

What happens, step by step, from a user’s click to a rendered application frame.

Tracing what actually moves across the network during a live streaming session.

sequenceDiagram
    participant B as Browser Client
    participant GW as Streaming Gateway
    participant FI as Fleet Instance
    participant S3 as S3 Home Folder
    B->>GW: Authenticated session request
    GW->>FI: Assign instance, launch app
    FI->>S3: Mount user home folder
    FI->>GW: Ready signal
    GW->>B: Stream connection established
    loop Live Session
        FI->>GW: Compressed frame delta
        GW->>B: Frame delta
        B->>GW: Input event (keyboard/mouse)
        GW->>FI: Input event
    end
    B->>GW: Disconnect
    FI->>S3: Sync home folder changes
    GW->>FI: Recycle instance
    

The critical architectural property here — and the one that differentiates AppStream from a VPN-plus-remote-desktop setup — is that application data never traverses the public internet at all. The application runs entirely inside the fleet instance, inside your VPC; what reaches the user’s browser is pixels, and what returns is input events. This is why AppStream is frequently chosen specifically for regulated or sensitive-data workloads: a user viewing a spreadsheet full of confidential records is receiving a video stream of that spreadsheet, not a copy of the file.

Home Folder Sync Timing

Home Folder changes sync to S3 continuously during an active session, not only at disconnect, but the final sync on session end is what guarantees durability before a non-persistent instance is recycled — an abrupt network failure mid-session can, in edge cases, lose the last few seconds of unsynced changes, which is a real operational consideration for write-heavy workflows.

The Core Trade-off: Centralization vs Latency Sensitivity

AppStream trades local execution for centralized control — you gain a single point of patching, licensing, and data governance, but you introduce network round-trip latency into every keystroke and mouse movement. For most productivity and business applications this trade is invisible; for applications demanding sub-frame input latency (competitive gaming, precision CAD manipulation over poor connections) it becomes a real, perceptible cost. Choosing AppStream well means matching the fleet instance family and user network conditions to the application’s actual interactivity demands, not defaulting to the cheapest instance type available.

Fleet scaling in AppStream is governed by capacity settings — desired instance count, or for Auto Scaling-enabled fleets, min/max/target capacity tied to utilization metrics like the percentage of in-use capacity. A fleet undersized for peak concurrent users produces a visible symptom: users queue waiting for an available instance rather than experiencing degraded performance within a session — capacity and per-session performance are entirely separate scaling dimensions.

Instance Family Selection Drives Real Performance

Because each user session occupies an entire instance (not a shared slice of one), the instance family chosen for a Fleet directly determines per-user performance. Graphics-intensive applications (CAD, 3D modeling, video editing) need Graphics Design or Graphics Pro instance families with dedicated GPU resources; standard office and line-of-business applications run comfortably on General Purpose instances at a fraction of the cost. Under-provisioning instance type for the workload is a common, expensive-to-diagnose performance complaint.

Elastic Fleets and Scale-to-Zero

Elastic fleets solve a specific scaling problem: unpredictable, bursty, or low-and-intermittent usage patterns where paying for any standing Always-On capacity is wasteful. Capacity is drawn from a shared AWS-managed pool per session and released afterward, effectively giving scale-to-zero behavior that a fixed Fleet cannot match — at the cost of slightly longer session start times and some constraints on custom startup scripts compared to a dedicated Fleet.

Fleets can span multiple Availability Zones within a Region, and AWS recommends configuring at least two subnets in different AZs for any production Fleet — if one AZ experiences issues, the Fleet continues serving sessions from healthy instances in the remaining AZ. This is a configuration choice, not an automatic default, and a Fleet deployed into a single subnet forfeits this resilience entirely.

Health Checks and Instance Replacement

The AppStream service continuously health-checks fleet instances; an instance that fails to respond correctly is automatically terminated and replaced with a fresh instance built from the same image, without manual intervention. For non-persistent fleets this is largely invisible to users beyond the affected session; for workflows relying heavily on long-running sessions, understanding that instance replacement is expected behavior (not a fault) matters for operational runbooks.

What AppStream Does Not Solve

Cross-Region failover is not automatic — a Region-level outage affecting the Region hosting a Fleet is a genuine availability gap. Organizations with strict continuity requirements deploy parallel Stacks and Fleets in a second Region with DNS-based routing in front, similar in spirit to multi-Region patterns used elsewhere in AWS, but this requires deliberate design rather than being a built-in AppStream capability.

Data Never Leaves the Instance

The foundational security property of AppStream is that application execution and data reside entirely on the fleet instance inside your VPC — the client device receives only rendered pixels. This means device-level compromise, loss, or an unmanaged personal laptop poses a fundamentally lower data-exfiltration risk than a traditional model where the application and its files are downloaded locally.

Granular Session Controls

Stacks expose fine-grained toggles for clipboard (copy in/out independently), local file upload/download, printing to a local printer, and camera/microphone redirection. A regulated-data deployment typically disables file transfer and clipboard-out entirely, permitting only the rendered application view — a level of control that’s difficult to enforce consistently on locally-installed software.

Network Isolation via Security Groups

Because fleet instances attach directly to your VPC, standard security group and NACL rules apply exactly as they would to any EC2 instance, letting you restrict a Fleet’s outbound reach to only the specific internal resources (a license server, a database) the streamed application legitimately needs.

SEC-01Anti-Pattern

Problem

Leaving file transfer and clipboard permissions enabled by default for a Stack serving sensitive or regulated data.

Why It Fails

Default Stack settings are permissive; an administrator who assumes “streaming = automatically secure” without reviewing session permission settings leaves an unintended exfiltration path open through ordinary copy-paste or file download.

Correct Approach

Explicitly review and restrict each Stack’s user settings (clipboard, file transfer, printing) to the minimum required for the specific user population it serves.

You may likeAmazon DynamoDB→

AppStream publishes fleet-level metrics to CloudWatch, including capacity utilization, in-use vs available instance counts, and session-related counters — the same metrics that drive Auto Scaling policies are available for operational dashboards and alarms. Session connection logs, application usage logs, and streaming diagnostic logs can additionally be configured to export to CloudWatch Logs or S3 for auditing and troubleshooting.

What to Actually Watch

For an intermediate operator running production Fleets, the signals that matter most are capacity utilization (sustained near-100% utilization means users are queuing for sessions), instance health check failures (a leading indicator of image or instance-family problems), and session duration distribution (unexpectedly short sessions often point to idle-timeout misconfiguration rather than genuine user behavior).

flowchart LR
    IB["Image Builder"] -->|install apps, configure| CAPTURE["Capture Image"]
    CAPTURE --> V1["Image v1"]
    V1 --> FLEET1["Fleet (v1)"]
    CAPTURE -->|update apps, recapture| V2["Image v2"]
    V2 --> FLEET2["Fleet (v2) — rolling update"]
    FLEET1 -.->|retire after cutover| RETIRE["Decommissioned"]
    FLEET2 --> STACK["Stack"]
    STACK --> USERS["End Users"]
    

Image Versioning as the Deployment Unit

Unlike services where you patch a running instance in place, the standard AppStream deployment pattern is to build a new Image version, create a new Fleet from it, validate the new Fleet, then repoint the Stack to the new Fleet before decommissioning the old one. This gives a clean rollback path — if the new image has a problem, the Stack simply repoints back to the previous Fleet — at the cost of requiring a deliberate image-lifecycle discipline rather than ad hoc patching.

Integration with Directory Services

AppStream integrates with AWS Directory Service or an on-premises Active Directory (via AD Connector) to join fleet instances to a domain, enabling applications that depend on domain authentication or Group Policy to function exactly as they would on a traditional corporate desktop.

Programmatic Session Creation

Beyond the SAML-based access portal, AppStream supports generating time-limited, IAM-authenticated streaming URLs programmatically — the mechanism that lets a custom internal portal or a SaaS product embed an AppStream session directly rather than sending users to AWS’s own access portal page.