# Amazon Connect + AVD: Otimização de Áudio VDI em Ambientes Financeiros

A suporte nativo de redirecionamento de mídia do Amazon Connect para Azure Virtual Desktop e Windows 365 Cloud PC fecha uma lacuna operacional crítica em contact centers financeiros que já migraram agentes para VDI híbrido. O mecanismo usa Microsoft Multimedia Redirection (MMR) para desviar o processamento de áudio WebRTC do session host para o dispositivo local do agente — reduzindo latência percebida e eliminando a dupla codificação que degrada a qualidade de voz. Este artigo detalha o que muda na arquitetura, os gotchas de implantação e um checklist acionável para equipes de plataforma.

- URL: https://fernando.moretes.com/blog/amazon-connect-avd-otimizacao-de-audio-vdi-em-ambientes-financeiros-amazon-conne

- Markdown: https://fernando.moretes.com/blog/amazon-connect-avd-otimizacao-de-audio-vdi-em-ambientes-financeiros-amazon-conne/article.md?lang=pt

- Published: 2026-07-25T09:03:47.559Z

- Category: IA & Agentes

- Tags: amazon-connect, vdi, azure-virtual-desktop, audio-optimization, contact-center, webrtc, financial-grade, hybrid-cloud

- Reading time: 11 min

- Source: [Amazon Connect now supports audio optimization for Azure Virtual Desktop and Windows 365 Cloud PC](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-connect/)

---

Quando um agente de contact center financeiro não consegue ouvir claramente um cliente durante uma disputa de transação, o custo não é apenas operacional — é regulatório. A otimização de áudio do Amazon Connect para Azure Virtual Desktop e Windows 365 Cloud PC, anunciada em julho de 2026, não é um feature de conforto: é infraestrutura crítica para organizações que consolidaram desktops em VDI mas ainda dependem de voz como canal primário de resolução.

## O Problema Real: Dupla Codificação e Latência Acumulada em VDI

Em um ambiente VDI sem redirecionamento de mídia, o fluxo de áudio de uma chamada Amazon Connect percorre um caminho patologicamente longo. O áudio capturado pelo microfone local do agente é primeiro codificado pelo cliente RDP/AVD, transmitido pelo protocolo de remoting até o session host na nuvem Azure, decodificado ali, recodificado pelo stack WebRTC do Connect Customer rodando no browser dentro da sessão virtual, e então enviado pela internet até a infraestrutura de mídia do Amazon Connect. Na direção inversa, o áudio do cliente percorre o caminho oposto. Cada salto de codificação introduz latência de processamento (tipicamente 20-40ms por codec hop) e degradação de qualidade por transcodificação — o que os engenheiros de voz chamam de *tandem encoding loss*.

O resultado prático em redes corporativas com RTT de 40-80ms entre o endpoint do agente e o datacenter Azure é um MOS (Mean Opinion Score) que frequentemente cai abaixo de 3.5 — o limiar abaixo do qual usuários reportam a chamada como "difícil de entender". Em contact centers financeiros, onde conformidade com gravações e inteligibilidade são requisitos de auditoria, isso não é aceitável.

O Microsoft Multimedia Redirection (MMR) resolve isso interceptando o processamento de mídia antes que ele entre no pipeline de remoting. Com MMR habilitado, o Connect Customer detecta o contexto VDI e instrui o stack WebRTC a operar no dispositivo local do agente, não no session host. O session host torna-se apenas um relay de sinalização — o RTP media path é estabelecido diretamente entre o dispositivo local e os media servers do Amazon Connect, eliminando os dois saltos de codificação desnecessários.

## Fluxo de Mídia: Com e Sem Redirecionamento MMR

Comparação do caminho de áudio RTP antes e depois da habilitação do MMR no Azure Virtual Desktop com Amazon Connect. O redirecionamento elimina dois saltos de codificação e move o processamento WebRTC para o dispositivo local do agente.

### 🧑 Agent Endpoint

- Agent Local Device (user)
- AVD Client (RDP/MMR) (frontend)
- WebRTC (MMR redirect) (compute)

### ☁️ Azure VDI Layer

- AVD Session Host (Win 365 / AVD) (compute)
- Connect CCP in Browser (frontend)

### 🔒 Network Path

- Signaling Only (HTTPS/WSS) (network)

### 📞 Amazon Connect

- Connect Media Servers (RTP) (messaging)
- Connect Control Plane / CCP API (compute)
- Connect Streams JS Library (frontend)

### Fluxos

- agent_device -> avd_client: microfone/alto-falante
- avd_client -> session_host: protocolo AVD (display+input)
- session_host -> ccp_browser: renderiza UI do CCP
- ccp_browser -> connect_ctrl: sinalização WebSocket
- avd_client -> webrtc_local: MMR intercepta mídia
- webrtc_local -> connect_media: RTP direto (SRTP/DTLS)
- session_host -> signaling: apenas sinalização (sem RTP)
- signaling -> connect_ctrl: controle de chamada
- connect_ctrl -> connect_streams: eventos de chamada

## Arquitetura de Rede: O Que Muda nos Requisitos de Firewall e QoS

A mudança mais subestimada que o MMR introduz é no modelo de rede. Sem redirecionamento, o tráfego RTP do Amazon Connect saía do session host Azure — portanto, as regras de firewall e políticas de QoS precisavam ser aplicadas no nível da VNet Azure. Com MMR ativo, o tráfego RTP passa a originar do dispositivo local do agente, que pode estar em uma rede doméstica, em um escritório corporativo com SD-WAN, ou em uma filial com controles de rede completamente diferentes.

Isso tem implicações diretas para equipes de segurança em instituições financeiras reguladas. Os endpoints locais dos agentes precisam ter acesso de saída às portas UDP utilizadas pelo Amazon Connect para mídia — tipicamente UDP 3478 e o range 49152-65535 para SRTP/DTLS. Se a política de segurança corporativa bloqueia UDP de saída em endpoints de usuário (o que é comum em ambientes de alta segurança), o MMR vai silenciosamente fazer fallback para o caminho de áudio via session host, anulando os benefícios.

Para ambientes financeiros com Zero Trust Network Access (ZTNA), o modelo de acesso precisa ser revisado: o agente local agora é um endpoint de mídia de produção, não apenas um thin client de display. Isso significa que políticas de Device Trust, EDR coverage e Network Access Control precisam ser verificadas para os dispositivos físicos dos agentes, não apenas para os session hosts. Em termos de QoS, DSCP marking para Expedited Forwarding (EF, DSCP 46) precisa ser configurado no roteador/switch local do agente para garantir que o tráfego RTP não compita com tráfego de backup ou atualização de software no mesmo uplink.

## Playbook de Implantação: Da Configuração MMR ao Go-Live em Produção

1. **1. Validar pré-requisitos de versão e licença** — Confirme que os session hosts AVD executam Windows 10/11 multi-session com a extensão MMR instalada (pacote WebRTC Redirector Service, versão mínima compatível com a feature de junho de 2026). Para Windows 365 Cloud PC, verifique que o plano de licença inclui suporte a MMR — planos Business básicos podem não incluir. Valide também que o Connect Customer (CCP) está na versão que suporta detecção de contexto VDI para AVD/W365.

2. **2. Configurar Group Policy para habilitar MMR no session host** — No session host, habilite a política 'Enable Multimedia Redirection for Azure Virtual Desktop' via GPO ou Intune Configuration Profile. Defina o allowlist de URLs para incluir os domínios do Amazon Connect CCP (*.awsapps.com, *.connect.aws). Sem esse allowlist explícito, o MMR não interceptará o tráfego de mídia do Connect Customer mesmo com a política global habilitada — esse é o gotcha mais comum em implantações iniciais.

3. **3. Instalar a extensão MMR no cliente AVD do endpoint local** — O redirecionamento MMR requer o componente cliente instalado no dispositivo local do agente — não apenas no session host. Distribua o pacote 'Remote Desktop WebRTC Redirector Service' via SCCM, Intune ou script de bootstrap. Em ambientes financeiros com imagens gerenciadas de endpoint, inclua esse pacote no golden image e valide via compliance report do Intune antes de habilitar em produção.

4. **4. Abrir portas de mídia no firewall do endpoint local** — Crie regras de firewall de saída para UDP 3478 (STUN/TURN) e UDP 49152-65535 (SRTP) nos endpoints dos agentes, com destino aos ranges de IP publicados pelo Amazon Connect para sua região AWS. Para ambientes com ZTNA (Zscaler, Netskope, Cloudflare Access), crie bypass rules para esse tráfego UDP — proxies TLS não processam UDP e causarão falha silenciosa do ICE negotiation.

5. **5. Configurar DSCP marking e QoS no uplink local** — Configure DSCP EF (46) para tráfego UDP originado pelo processo do WebRTC Redirector no endpoint local. Em roteadores Cisco/Meraki, use NBAR para identificar o tráfego por porta de destino e aplicar o marking. Em ambientes com agentes remotos (home office), considere SD-WAN com políticas de QoS baseadas em aplicação — a ausência de QoS em uplinks de 50Mbps compartilhados é a causa mais frequente de degradação de MOS em produção.

6. **6. Validar detecção de contexto VDI no Connect Customer** — Após a configuração, abra o Connect Customer dentro da sessão AVD e inspecione o console do browser para o log de inicialização. O CCP deve logar 'VDI environment detected: AVD/MMR' e indicar que o processamento de áudio foi redirecionado para o dispositivo local. Se esse log não aparecer, o MMR não está ativo — verifique a versão do WebRTC Redirector Service e o allowlist de URLs na GPO.

7. **7. Estabelecer baseline de métricas de qualidade de voz** — Antes de liberar para produção, execute chamadas de teste e capture métricas de qualidade via Amazon Connect Contact Lens ou via a API GetMetricData. Registre MOS score, packet loss, jitter e RTT como baseline. Configure alarmes no CloudWatch para MOS < 3.5 e packet loss > 1% — esses thresholds são referência para contact centers financeiros regulados. Compare com o baseline pré-MMR para validar o ganho real.

> **Teste de Fallback Silencioso é Obrigatório:** O MMR falha silenciosamente — quando as condições não são atendidas (versão incorreta, porta bloqueada, URL não na allowlist), o Connect Customer simplesmente processa o áudio pelo session host sem alertar o agente. Implemente um health check automatizado que verifica o log de contexto VDI do CCP e alerta a equipe de plataforma via CloudWatch Synthetics ou script de monitoramento rodando no session host. Não confie no agente para reportar degradação de áudio — em ambientes financeiros de alto volume, o agente vai atribuir a qualidade ruim à 'rede' e seguir em frente.

## Implicações de Segurança e Conformidade em Ambientes Financeiros Regulados

A expansão do perímetro de mídia para o dispositivo local do agente cria novos vetores de risco que equipes de segurança em bancos e fintechs precisam endereçar explicitamente. O primeiro é o risco de gravação não autorizada: com o processamento de áudio ocorrendo localmente, um malware no endpoint do agente pode interceptar o stream de áudio antes que ele seja criptografado pelo DTLS. Isso é diferente do modelo anterior onde o áudio nunca saía do ambiente controlado do session host. A resposta arquitetural é garantir que os endpoints dos agentes estejam sob cobertura de EDR (CrowdStrike, SentinelOne) com detecção de acesso a dispositivos de áudio por processos não autorizados.

O segundo vetor é o de compliance de gravação. O Amazon Connect grava chamadas no lado do servidor (Contact Lens, S3), então o fato do áudio ser processado localmente não afeta a cadeia de custódia da gravação — o áudio ainda chega aos media servers do Connect e é gravado lá. Mas equipes de compliance precisam documentar isso explicitamente em suas políticas de controle de dados, especialmente para regulações como LGPD (Brasil), GDPR e MiFID II (para operações europeias). A afirmação de que "o áudio nunca sai do ambiente controlado" deixa de ser verdadeira com MMR.

O terceiro ponto é o de auditoria de configuração. Em ambientes financeiros com múltiplos tipos de VDI (WorkSpaces, AVD, Citrix, Omnissa — todos agora suportados pelo Connect), a configuração de MMR pode variar por plataforma. Recomendo fortemente que a configuração de MMR seja tratada como infraestrutura como código (Terraform para políticas Intune, scripts de validação em pipeline CI/CD) e que auditorias de conformidade incluam verificação do estado de MMR como um controle de qualidade de serviço, não apenas de segurança.

## Comparação de Plataformas VDI Suportadas pelo Amazon Connect
| Critério | Plataforma VDI | Mecanismo de Redirecionamento | Configuração de Setup | Controle de Rede no Endpoint | Disponibilidade GovCloud |
| --- | --- | --- | --- | --- | --- |
| Amazon WorkSpaces | WebRTC Redirection nativo AWS | Baixa — integração nativa | Total (VPC, Security Groups) | Sim | — |
| Azure Virtual Desktop (AVD) | Microsoft MMR + WebRTC Redirector | Média — GPO + extensão cliente | Parcial (Azure NSG + endpoint local) | Não | — |
| Windows 365 Cloud PC | Microsoft MMR (mesmo mecanismo AVD) | Média — Intune + extensão cliente | Parcial (Intune + endpoint local) | Não | — |
| Citrix Cloud | Citrix HDX RealTime Optimization Pack | Alta — RealTime Connector + Media Engine | Parcial (Citrix Gateway + endpoint) | Verificar documentação | — |
| Omnissa (ex-VMware Horizon) | Omnissa Horizon Media Optimization | Alta — Horizon Client + plugin | Parcial (NSX + endpoint) | Verificar documentação | — |

## Observabilidade: Monitorando Qualidade de Voz em Ambientes Multi-VDI

Um dos problemas mais difíceis em contact centers financeiros com múltiplas plataformas VDI é correlacionar degradação de qualidade de voz com a causa raiz. Quando um supervisor recebe reclamações de agentes sobre qualidade de áudio, a investigação precisa responder: o problema é no path de rede do endpoint local, no session host, na configuração MMR, ou nos media servers do Amazon Connect?

A estratégia de observabilidade que recomendo tem três camadas. Na camada do Amazon Connect, habilite Contact Lens para análise em tempo real e configure métricas de qualidade via CloudWatch — especificamente as métricas `VoiceCallRecordingUploadError`, `ContactFlowErrors` e as métricas de qualidade de chamada disponíveis via Connect Metrics API. Configure dashboards separados por tipo de VDI usando tags de contato customizadas (defina um atributo de contato `vdi_type` no início do fluxo, populado via Lambda que consulta o perfil do agente).

Na camada do endpoint, implante um agente de monitoramento leve (CloudWatch Agent ou Datadog Agent) nos session hosts que coleta métricas de CPU/memória do processo WebRTC Redirector e logs de eventos de MMR do Windows Event Log. Correlacione esses dados com as métricas de qualidade do Connect usando o Contact ID como chave de correlação — isso permite identificar se a degradação de MOS coincide com picos de CPU no session host (indicando que o MMR não está ativo e o processamento voltou para o host) ou com perda de pacotes no uplink local.

Para ambientes financeiros com SLOs de qualidade de voz (e você deveria ter um — sugiro 95% das chamadas com MOS ≥ 3.8), configure error budgets no CloudWatch com alarmes compostos que agregam métricas de todas as plataformas VDI. Um SLO de qualidade de voz é tão legítimo quanto um SLO de latência de API — e em contact centers regulados, é frequentemente mais impactante para o cliente.

## Anti-Padrões Comuns na Implantação de MMR para Amazon Connect

- Habilitar MMR globalmente sem URL allowlist: a política global sem allowlist de domínios do Connect Customer não intercepta o tráfego de mídia correto — resultado é zero benefício com a falsa impressão de que o recurso está ativo.
- Ignorar o componente cliente no endpoint local: instalar apenas o componente do session host é um erro comum. O MMR requer o WebRTC Redirector Service no dispositivo físico do agente — sem ele, o redirecionamento não ocorre independentemente da configuração do host.
- Assumir que ZTNA/proxy corporativo é transparente para UDP: proxies TLS (Zscaler, Netskope) não processam UDP. Tráfego SRTP enviado pelo endpoint local será bloqueado ou corrompido se não houver bypass rules explícitas para as portas de mídia do Connect.
- Não revisar políticas de DLP no endpoint: com o áudio processado localmente, soluções de DLP baseadas em endpoint que monitoram acesso a dispositivos de áudio podem gerar alertas falsos ou, pior, bloquear o acesso do WebRTC Redirector ao microfone.
- Misturar agentes MMR e não-MMR no mesmo queue sem visibilidade: em períodos de rollout gradual, agentes com e sem MMR ativo podem estar no mesmo queue. Sem tags de contato que identifiquem o tipo de VDI, é impossível correlacionar reclamações de qualidade com o grupo correto.
- Negligenciar o teste em condições de rede degradada: testar MMR apenas em redes corporativas com QoS não revela o comportamento em home office com uplink compartilhado. Simule 5% de packet loss e 50ms de jitter adicional antes de aprovar o rollout para agentes remotos.

## Perguntas Frequentes de Arquitetos e Equipes de Plataforma

### O MMR funciona com interfaces customizadas construídas com o Amazon Connect Streams JS?

Sim. O anúncio confirma suporte tanto para o workspace nativo do Connect Customer quanto para interfaces customizadas via Amazon Connect Streams (open-source JavaScript library). O mecanismo de detecção de contexto VDI opera no nível do runtime WebRTC, independentemente da UI que o envolve. Valide que sua versão da biblioteca Streams está atualizada para a versão que inclui a detecção de contexto AVD/W365.

### Qual o impacto no consumo de CPU do session host com MMR ativo?

Com MMR ativo, o processamento de áudio WebRTC é removido do session host — o que tipicamente representa 15-25% do consumo de CPU por sessão de agente em chamadas ativas. Em session hosts com alta densidade de agentes (20-30 sessões por VM), isso pode reduzir significativamente o custo de compute Azure ou permitir maior densidade por host. Monitore a métrica de CPU do processo `msrdc.exe` no session host antes e depois para quantificar o ganho real no seu ambiente.

### A feature está disponível em todas as regiões AWS onde o Connect opera?

Conforme o anúncio oficial, o suporte está disponível em todas as regiões AWS onde o Amazon Connect Customer é oferecido, com exceção do AWS GovCloud (US-West). Para organizações com requisitos de soberania de dados que operam exclusivamente em GovCloud, essa limitação é relevante — a alternativa é Amazon WorkSpaces, que mantém suporte em GovCloud.

### Como garantir que gravações de chamadas (Contact Lens, S3) não são afetadas pelo redirecionamento?

As gravações do Amazon Connect são capturadas nos media servers do serviço, após o áudio chegar via RTP do dispositivo local do agente. O redirecionamento MMR não afeta o ponto de captura da gravação — o áudio ainda transita pelos media servers do Connect antes de ser gravado em S3. O que muda é o path de rede do agente até esses media servers. Valide isso executando chamadas de teste com Contact Lens habilitado e verificando que as transcrições e gravações são geradas normalmente após a ativação do MMR.

### Existe suporte para TURN relay quando UDP direto não é possível?

O Amazon Connect suporta TURN relay via TCP/TLS como fallback quando UDP está bloqueado, mas com penalidade de latência e qualidade. Em ambientes financeiros onde UDP está bloqueado por política, o TURN relay pode manter a chamada funcional, mas o MOS será inferior ao caminho UDP direto. A recomendação é sempre priorizar a abertura de UDP para os ranges de IP do Connect — o TURN relay é um safety net, não uma solução de design.

## O Contexto Maior: Convergência Multi-VDI e o Futuro do Contact Center Híbrido

A adição de suporte a AVD e Windows 365 completa um quadro importante: o Amazon Connect agora suporta otimização de áudio nativa para as quatro principais plataformas de VDI corporativo — WorkSpaces, AVD/W365, Citrix e Omnissa. Isso não é coincidência; é o reconhecimento de que contact centers financeiros modernos não têm uma única plataforma de desktop. É comum encontrar bancos onde agentes de operações críticas usam WorkSpaces (por controle de dados e integração AWS), agentes de back-office usam Windows 365 (por simplicidade de gestão via Intune), e agentes legados ainda em Citrix aguardando migração.

Essa heterogeneidade de VDI cria um desafio de gestão de plataforma que vai além da configuração de MMR. Cada plataforma tem seu próprio modelo de autenticação, ciclo de atualização, e comportamento de rede. A estratégia que recomendo para equipes de plataforma em grandes contact centers financeiros é tratar a configuração de otimização de áudio do Connect como uma camada de abstração gerenciada centralmente — independentemente da plataforma VDI subjacente, o resultado esperado é o mesmo: processamento de áudio local, MOS ≥ 3.8, e visibilidade de qualidade por agente.

Olhando para frente, a integração de IA generativa no contact center (Amazon Connect com Bedrock para agentes assistidos por IA, análise em tempo real via Contact Lens) vai aumentar ainda mais a importância da qualidade de áudio. Modelos de speech-to-text e análise de sentimento têm performance significativamente melhor com áudio de alta qualidade — um MOS de 4.0 vs 3.2 pode significar a diferença entre 95% e 75% de acurácia de transcrição, o que impacta diretamente a qualidade das sugestões do assistente de IA ao agente. Qualidade de voz não é mais apenas conforto do agente — é infraestrutura para IA.

## Lente Well-Architected: MMR + Amazon Connect em Ambientes Financeiros

- **security**: O redirecionamento MMR expande o perímetro de mídia para endpoints locais — implemente EDR com detecção de acesso a dispositivos de áudio, revise políticas de DLP para não bloquear o WebRTC Redirector, e documente explicitamente o novo modelo de fluxo de dados nas políticas de conformidade (LGPD, GDPR, MiFID II). Use IAM conditions no perfil de instância do Connect para restringir acesso a recursos de gravação por região.
- **reliability**: Implemente fallback automático e monitorado: quando MMR não está ativo, o Connect deve continuar funcionando via session host com qualidade degradada — mas a equipe de plataforma deve ser alertada. Configure CloudWatch Synthetics para verificar o estado de MMR em session hosts de amostra a cada 5 minutos e alarmes compostos para detectar degradação de MOS em produção.

> **Nota do Arquiteto:** Na prática, o maior risco nessa feature não é técnico — é operacional: equipes assumem que habilitaram o MMR porque configuraram o session host, sem perceber que o componente cliente no endpoint local é igualmente obrigatório. Em todos os ambientes financeiros onde trabalhei com VDI e voz, a lição mais cara foi sempre a do fallback silencioso: o sistema funciona, mas não da forma que você imagina, e você só descobre quando o regulador pede as gravações e a qualidade está abaixo do limiar de inteligibilidade. Meu conselho prático: antes de qualquer rollout em produção, construa um smoke test automatizado que verifica o log de contexto VDI do CCP em um agente de teste real, e trate o resultado desse teste como gate obrigatório no seu pipeline de deploy de configuração. Qualidade de voz em contact center financeiro não é feature — é SLA.

## Veredicto: Implante, Mas Com Rigor de Engenharia

O suporte de otimização de áudio do Amazon Connect para Azure Virtual Desktop e Windows 365 é uma adição genuinamente valiosa para contact centers financeiros com footprint VDI híbrido. O mecanismo MMR é tecnicamente sólido e o benefício de qualidade de voz é real e mensurável. A recomendação é clara: implante em produção, mas trate a configuração com o mesmo rigor que você aplicaria a qualquer mudança de infraestrutura crítica. Isso significa IaC para a configuração, smoke tests automatizados para detecção de fallback silencioso, revisão de políticas de segurança de endpoint, e SLOs de qualidade de voz com monitoramento ativo. Para organizações em GovCloud (US-West), a limitação atual é relevante — Amazon WorkSpaces permanece a alternativa suportada. O timing também é estratégico: com a expansão de IA generativa no Connect (Contact Lens, assistentes Bedrock), qualidade de áudio se torna infraestrutura para IA — não apenas conforto do agente.

## Referências

- [Amazon Connect now supports audio optimization for Azure Virtual Desktop and Windows 365 Cloud PC — AWS What's New](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-connect/)
- [Amazon Connect Administrator Guide: Optimize audio for Azure Virtual Desktop (Step-by-step)](https://docs.aws.amazon.com/connect/latest/adminguide/using-ccp-vdi-azure-step-by-step.html)
- [Amazon Connect Release Notes — June 2026: AVD and Windows 365 audio optimization](https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-release-notes.html)
- [Optimize Amazon Connect audio for Amazon WorkSpaces cloud desktops](https://docs.aws.amazon.com/en_us/connect/latest/adminguide/using-ccp-vdi-workspaces.html)
- [Amazon Connect Streams — Open Source JavaScript Library (GitHub)](https://github.com/amazon-connect/amazon-connect-streams)
- [Microsoft Multimedia Redirection for Azure Virtual Desktop — Microsoft Docs](https://learn.microsoft.com/en-us/azure/virtual-desktop/multimedia-redirection-intro)
- [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)
- [Amazon Connect Contact Lens — Real-time analytics](https://docs.aws.amazon.com/connect/latest/adminguide/analyze-conversations.html)