Amazon Quick now supports Live Data in Apps, a capability that replaces the previous build‑time snapshot model with real‑time queries against governed Quick Sight datasets. Practitioners can rely on AI‑generated Quick applications to fetch current metrics at view time, while the underlying row‑level and column‑level security policies continue to enforce data access.
What Changed: Live Data in Apps
Earlier Quick apps embedded static data that was frozen when the app was published. The new flow generates the required SQL during the build phase, but the same query is executed each time a user opens the app. Both SPICE (in‑memory) and Direct Query dataset modes are supported, and the query runs under the identity of the viewer, ensuring that each user only sees rows and columns they are permitted to view.
Implications for Engineering Roles
AI engineers can now rely on live data when prompting the Quick agent, removing the need to design separate data refresh pipelines. Cloud and platform engineers must verify that the target data sources are compatible with Direct Query and that the Quick environment has network access to those sources. DevOps and SRE teams should anticipate additional runtime query load, instrument latency metrics, and include the Quick app deployment in existing monitoring stacks. Security engineers need to confirm that existing row‑level security (RLS) and column‑level security (CLS) rules are correctly applied at query time and that consent enforcement is active for every dataset access.
Operational and Architectural Considerations
- Prerequisites: Users must have access to governed datasets, and the datasets must be configured with RLS/CLS as needed. Both SPICE and Direct Query modes are accepted, but the list of supported Direct Query sources should be checked.
- Consent model: The first time a viewer runs a live‑data app, they must consent to each dataset. Builders approve datasets during the build step, but consent is re‑validated on every query execution.
- Authentication requirement: Only authenticated Quick users can view live‑data apps; anonymous or public access is explicitly blocked at multiple layers.
- Role minimum: The builder and any subsequent user need at least the Reader Pro role.
- Performance impact: Because queries execute on demand, latency will depend on the underlying data source and the complexity of the generated SQL. Monitoring should capture query duration and error rates.
- Governance continuity: Since queries run as the viewer, existing RLS/CLS policies remain the primary authorization mechanism. No new permission model is introduced.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Validate that all target datasets have appropriate RLS/CLS configurations and that they are accessible via Direct Query if needed. Ensure every intended viewer holds an authenticated Quick account with at least Reader Pro rights. Incorporate consent collection into the user onboarding flow for any new live‑data app. Extend monitoring dashboards to capture on‑demand query latency and failures, and test the end‑to‑end flow with both SPICE and Direct Query datasets to confirm performance expectations. Finally, update documentation and runbooks to reflect that data freshness is now guaranteed at view time, eliminating the need for separate snapshot refresh processes.
