# Computação de Baixo Carbono com Dispositivos Reutilizados: Arquitetura Edge Real

Reutilizar smartphones descartados como nós de computação edge não é apenas uma aposta de sustentabilidade — é uma decisão arquitetural com implicações sérias em confiabilidade, segurança e custo operacional. Neste artigo, analiso os mecanismos reais, os modos de falha e os trade-offs de engenharia que separam um experimento de laboratório de uma plataforma de produção.

- URL: https://fernando.moretes.com/blog/computacao-de-baixo-carbono-com-dispositivos-reutilizados

- Markdown: https://fernando.moretes.com/blog/computacao-de-baixo-carbono-com-dispositivos-reutilizados/article.md?lang=pt

- Published: 2026-05-20T12:00:00.000Z

- Category: Dados & Plataformas

- Tags: edge-computing, sustainability, aws-greengrass, iot, low-carbon, fleet-management, observability, financial-grade

- Reading time: 8 min

- Source: [Low-carbon computing with retired phones](https://research.google/blog/)

---

Quando o Google Research publica sobre computação de baixo carbono com telefones descartados, a reação instintiva da maioria dos arquitetos é tratá-la como curiosidade acadêmica. Cometo esse erro raramente. Depois de 16 anos desenhando plataformas financeiras onde cada decisão de infraestrutura tem custo de capital, custo regulatório e custo de carbono — cada vez mais monitorado por auditorias ESG — reconheço o sinal técnico real aqui: a ideia de que hardware com carbono incorporado já pago pode ser reaproveitado como substrato de computação edge heterogênea, reduzindo tanto o custo marginal de expansão quanto a pegada de carbono operacional. O problema não é a visão. O problema é a engenharia que transforma essa visão em algo que sobrevive ao contato com a realidade de produção.

## O Carbono Incorporado é o Custo Oculto que a Maioria dos Arquitetos Ignora

A métrica de sustentabilidade que domina as conversas de cloud é o carbono operacional — a emissão associada ao consumo de energia em tempo de execução. Mas para dispositivos de hardware, especialmente smartphones, o carbono incorporado (*embodied carbon*) — emitido durante fabricação, mineração de materiais e logística — representa entre 70% e 80% do ciclo de vida total de emissões do dispositivo, segundo estudos de ciclo de vida publicados pela própria indústria de semicondutores.

Isso muda o cálculo arquitetural de forma não trivial. Quando você provisiona uma nova instância EC2 `c6g.xlarge` para uma carga de trabalho edge, você está adicionando demanda incremental que, em última análise, pressiona a fabricação de novos chips. Quando você reutiliza um smartphone descartado que já teria ido para reciclagem — ou pior, para aterro — você está amortizando um custo de carbono já incorrido sobre mais ciclos de computação úteis.

No contexto de plataformas financeiras, isso começa a aparecer em relatórios de escopo 3 de emissões de carbono, exigidos por frameworks como TCFD e, no Brasil, pelas diretrizes do Banco Central no contexto de risco climático. Arquitetos que ignoram isso hoje vão redesenhar sistemas amanhã sob pressão regulatória. Prefiro fazer a análise agora, com calma, do que em um sprint de conformidade.

## Arquitetura de Frota Edge com Dispositivos Reutilizados e Orquestração AWS

Fluxo completo desde o dispositivo reutilizado até o processamento em nuvem, mostrando camadas de orquestração, segurança e observabilidade.

### 📱 Edge Fleet — Retired Devices

- Retired Phone Greengrass Core v2 (edge)
- Retired Phone Local ML Inference (edge)
- Retired Phone Sensor Aggregator (edge)

### 🔒 Security Layer — Zero Trust Edge

- AWS IoT Core X.509 + mTLS (security)
- IoT Role Alias Least-privilege IAM (security)

### 🟧 AWS — Orchestration & Streaming

- Greengrass Fleet Provisioning + OTA (compute)
- Amazon MSK Kafka topic/partition (messaging)
- Lambda Event processor (compute)

### 📊 AWS — Observability & Storage

- CloudWatch SLO dashboards + alarms (data)
- S3 Raw telemetry + Parquet (storage)
- DynamoDB Device state + health (data)

### Fluxos

- phone1 -> cert: mTLS autenticação
- phone2 -> cert: mTLS autenticação
- phone3 -> cert: mTLS autenticação
- cert -> iam_role: assume role via alias
- iam_role -> gg_cloud: autorização
- gg_cloud -> phone1: OTA deploy componente
- phone1 -> msk: publica telemetria
- phone2 -> msk: publica inferência
- msk -> lambda: trigger por partição
- lambda -> s3: persiste raw
- lambda -> dynamo: atualiza estado
- lambda -> cw: métricas custom
- gg_cloud -> cw: fleet health

## Como Funciona de Verdade: Greengrass v2, Identidade de Dispositivo e o Problema da Heterogeneidade

A espinha dorsal técnica de qualquer frota edge com dispositivos heterogêneos no ecossistema AWS é o **AWS IoT Greengrass v2**. Diferente da versão 1, o Greengrass v2 adota um modelo de componentes desacoplados — cada função (inferência local, coleta de telemetria, sincronização de sombra) é um componente independente com seu próprio ciclo de vida, política de reinicialização e dependências declaradas em um manifesto de receita (*recipe*). Isso é crítico para smartphones reutilizados porque você não controla o hardware: um Snapdragon 660 e um Exynos 9810 têm capacidades de memória, aceleração de ML e consumo de bateria completamente diferentes.

O provisionamento de identidade é onde a maioria dos projetos de IoT falha em escala. Para uma frota de dispositivos reutilizados, o mecanismo correto é o **Fleet Provisioning via JITP** (Just-In-Time Provisioning) com templates de provisionamento que emitem certificados X.509 únicos por dispositivo, associados a um IoT Role Alias que mapeia para uma IAM Role com permissões mínimas — apenas `iot:Publish` nos tópicos específicos do dispositivo, `greengrass:GetDeployment` e `s3:GetObject` no bucket de artefatos de componente.

O ponto de falha crítico aqui é o **rotation de certificados**. Dispositivos edge com conectividade intermitente — e smartphones reutilizados em locais com Wi-Fi instável são o caso típico — podem perder a janela de rotação. Você precisa de uma política de renovação com sobreposição (*overlap*) de validade de pelo menos 30 dias e um mecanismo de re-provisionamento automático via MQTT retained message quando o dispositivo reconecta após período prolongado offline.

> **O Modelo de Custo Real: Carbono vs. Confiabilidade vs. Operações:** Um smartphone reutilizado tem custo de hardware próximo de zero, mas o custo operacional de gerenciar um nó edge heterogêneo — provisionamento, monitoramento, atualização de firmware, substituição de bateria degradada — pode facilmente superar o custo de uma instância EC2 Graviton3 em 12 meses. O break-even real depende de três variáveis: densidade de dispositivos por engenheiro de operações, frequência de falhas de hardware e valor da latência local reduzida. Para cargas de trabalho financeiras onde latência de inferência abaixo de 50ms é um requisito de negócio, o edge justifica o custo operacional. Para processamento batch que tolera 500ms+, não justifica.

## Modos de Falha que Experimentos de Laboratório Não Revelam

A diferença entre um paper de pesquisa e uma plataforma de produção é a lista de modos de falha que só aparecem em escala e no tempo. Para frotas de dispositivos reutilizados, identifiquei quatro categorias críticas:

**1. Degradação de bateria não linear.** Smartphones com 500+ ciclos de carga têm capacidade de bateria reduzida em 20-40%. Sob carga de computação contínua, isso significa desligamentos inesperados em 4-6 horas em vez de 10-12. O Greengrass v2 não tem visibilidade nativa de estado de bateria — você precisa de um componente customizado que leia `/sys/class/power_supply/battery/capacity` e publique em um tópico MQTT de saúde, com alarme no CloudWatch quando `battery_level < 20%` por mais de 15 minutos.

**2. Throttling térmico silencioso.** SoCs móveis reduzem clock automaticamente sob temperatura elevada. Uma inferência que leva 45ms a 25°C pode levar 120ms a 42°C — sem nenhum erro, apenas latência degradada. Sem instrumentação de temperatura via OpenTelemetry exportando para CloudWatch custom metrics, você nunca vai correlacionar esse comportamento com horários de pico de uso.

**3. Fragmentação de SO e API.** Android 8, 9, 10 e 11 têm comportamentos diferentes para background process limits, Doze mode e network access restrictions. Um componente Greengrass que funciona perfeitamente no Android 11 pode ser morto pelo sistema em Android 8 após 10 minutos em background. A solução é usar um Foreground Service com notificação persistente — feio, mas necessário.

**4. Drift de relógio em dispositivos offline.** Dispositivos sem NTP sincronizado por mais de 2 horas podem ter drift de relógio de 30-60 segundos. Para dados de telemetria financeira onde o timestamp é parte do registro de auditoria, isso é inaceitável. A solução é timestamp no servidor (MSK broker time) como fonte autoritativa, com o timestamp do dispositivo como metadado secundário.

## Números Reais: O Que Esperar de uma Frota de Dispositivos Reutilizados

- **~75%** — Redução de carbono incorporado vs. hardware novo. Amortização do carbono já emitido na fabricação; válido apenas se o dispositivo substituiria hardware novo equivalente
- **3-5x** — Aumento de custo operacional vs. instância EC2 equivalente. Inclui tempo de engenharia para provisionamento, monitoramento e substituição de dispositivos com falha em frotas pequenas (<500 nós)
- **<50ms** — Latência de inferência local em SoCs móveis modernos (Snapdragon 865+). Para modelos quantizados INT8 com aceleração via NNAPI; degrada para 80-150ms em SoCs de 2017-2018 sob carga térmica

## Orquestração de Frota em Escala: Deployment, OTA e Particionamento de Kafka

Para uma frota com centenas ou milhares de dispositivos reutilizados, a estratégia de deployment de componentes Greengrass precisa ser tratada com o mesmo rigor que um deployment de microsserviços em EKS. O Greengrass v2 suporta **deployment groups** baseados em atributos de dispositivo (*thing attributes* no IoT Registry), o que permite fazer canary deployments — por exemplo, primeiro em dispositivos com Android 11 e bateria acima de 80%, depois expandir progressivamente.

O pipeline de OTA precisa considerar a janela de conectividade. Dispositivos em locais com Wi-Fi intermitente devem receber atualizações em horários de baixo tráfego, configurados via **IoT Jobs** com `schedulingConfig.startTime` e `timeoutConfig`. O artefato do componente no S3 deve usar **S3 Transfer Acceleration** para dispositivos geograficamente distribuídos, e o bucket deve ter política de ciclo de vida que expire versões antigas após 90 dias para controle de custo.

No lado do streaming, o particionamento do MSK é a decisão arquitetural mais impactante. Usar `device_id` como chave de partição garante ordenação por dispositivo mas cria hot partitions se a distribuição de dispositivos ativos for desigual — o que é garantido em uma frota heterogênea onde alguns dispositivos ficam offline por horas. A solução que uso é uma chave composta `{region}#{device_tier}` onde `device_tier` é calculado pela capacidade do dispositivo (SoC generation, RAM), distribuindo a carga de forma mais uniforme. O número de partições deve ser dimensionado para `max_throughput / 1MB/s` por partição, com headroom de 30% para picos de reconexão de frota após outage de rede.

Para idempotência no consumidor Lambda, o `event_id` deve ser gerado no dispositivo como `SHA256(device_id + timestamp_ms + sequence_number)` e verificado contra uma tabela DynamoDB com TTL de 24 horas antes do processamento — o custo de 2 leituras DynamoDB por evento é insignificante comparado ao custo de processar duplicatas em sistemas financeiros.

## Segurança em Frota Heterogênea: Zero Trust Não é Opcional

Dispositivos reutilizados introduzem uma superfície de ataque que hardware corporativo novo não tem: histórico de uso desconhecido, potencial de software malicioso pré-instalado e ausência de Secure Enclave em modelos mais antigos. Para ambientes financeiros, isso exige uma postura de Zero Trust mais rigorosa do que a maioria dos deployments IoT.

O modelo que implemento tem três camadas. Na camada de identidade, cada dispositivo recebe um certificado X.509 único emitido pela AWS IoT CA privada, com validade de 365 dias e rotação automática via Lambda trigada por EventBridge Scheduler. A IoT Policy associada usa condições `iot:Connection.Thing.ThingName` para garantir que o certificado só pode ser usado pelo dispositivo para o qual foi emitido — isso previne reutilização de certificados comprometidos.

Na camada de dados, toda telemetria em trânsito usa TLS 1.3 obrigatório (configurado na IoT Core endpoint policy). Dados em repouso no S3 usam SSE-KMS com uma CMK dedicada por ambiente, com rotação anual automática. O DynamoDB usa criptografia com CMK e a tabela de estado de dispositivo tem uma resource-based policy que nega acesso a qualquer principal fora da conta AWS específica.

Na camada de detecção, o **AWS IoT Device Defender** é configurado com audit checks para certificados expirados, políticas IoT com wildcard excessivo e conexões de IPs anômalos. As findings são roteadas via EventBridge para uma fila SQS consumida por um Lambda que atualiza o status do dispositivo no DynamoDB e, se a severidade for `CRITICAL`, revoga o certificado via `iot:UpdateCertificate` com status `REVOKED`. Esse loop de resposta automática é o que diferencia uma frota segura de uma frota monitorada.

## Anti-Padrões que Destroem Frotas de Dispositivos Reutilizados em Produção

- **Certificado compartilhado entre dispositivos**: usar um único certificado para toda a frota elimina a capacidade de revogar um dispositivo comprometido individualmente e viola o princípio de menor privilégio em IoT.
- **Ignorar o Doze Mode do Android**: componentes Greengrass sem Foreground Service em Android 6+ são suspensos pelo sistema após 30-60 minutos de inatividade de tela, causando gaps silenciosos na coleta de telemetria.
- **Usar timestamp do dispositivo como fonte autoritativa**: relógios de dispositivos edge derivam; em sistemas financeiros, o timestamp do broker Kafka (server-side) deve ser a fonte de verdade para ordenação e auditoria.
- **Dimensionar partições Kafka por contagem de dispositivos, não por throughput**: uma frota de 1000 dispositivos que envia 1 evento/minuto cada não justifica 1000 partições — o overhead de coordenação do consumer group supera o benefício de paralelismo.
- **Deployments OTA sem canary e sem rollback automático**: em hardware heterogêneo, um componente que passa em testes em 5 dispositivos pode falhar em 20% da frota por diferenças de SoC. Sem rollback automático via IoT Jobs `abortConfig`, você pode derrubar centenas de nós simultaneamente.
- **Tratar sustentabilidade como marketing sem instrumentação de carbono real**: sem métricas de consumo energético por dispositivo (via `/sys/class/power_supply`) e cálculo de emissão baseado no fator de emissão da rede elétrica local, a narrativa de 'baixo carbono' é inauditável e indefensável em relatórios ESG.

## Avaliação pelos Pilares do AWS Well-Architected

- **security**: Zero Trust obrigatório: certificados X.509 por dispositivo via Fleet Provisioning, IoT Role Alias com IAM de menor privilégio, Device Defender com resposta automática de revogação, SSE-KMS em todos os dados em repouso. Risco residual: dispositivos com SO desatualizado sem patches de segurança — mitigar com política de versão mínima de Android no template de provisionamento.
- **reliability**: Projetar para falha de dispositivo como evento normal, não exceção: health checks via MQTT LWT (Last Will and Testament) com timeout de 90 segundos, reconexão exponencial com jitter no cliente Greengrass, idempotência no consumidor Kafka via DynamoDB dedup table. SLO de disponibilidade de frota deve ser definido por percentil (ex: 95% dos dispositivos ativos em qualquer janela de 1 hora), não por disponibilidade individual.
- **performance**: Inferência local apenas para modelos que justificam a latência: use NNAPI para aceleração em SoCs com DSP/NPU (Snapdragon 845+), TFLite CPU fallback para dispositivos mais antigos. Monitore p99 de latência de inferência por modelo e por SoC via CloudWatch custom metrics — o p99 é o número que importa em sistemas financeiros, não a média.
- **sustainability**: Instrumentar consumo energético por dispositivo e calcular emissão usando o fator de emissão da rede elétrica local (disponível via API do US EPA ou equivalentes regionais). Publicar métricas de carbono no CloudWatch e incluir em dashboards de FinOps. Definir critério de descomissionamento baseado em eficiência energética: dispositivos com consumo por operação acima de threshold devem ser substituídos, mesmo que ainda funcionem.

## Dispositivos Reutilizados vs. Alternativas de Computação Edge
| Critério | Dimensão | Smartphones Reutilizados | AWS Wavelength / Outposts | Raspberry Pi / ARM SBC |
| --- | --- | --- | --- | --- |
| Custo de hardware | ~$0 (já pago) | Alto (CAPEX ou OPEX AWS) | Baixo ($35-$80) | — |
| Custo operacional | Alto (heterogeneidade) | Baixo (gerenciado AWS) | Médio (homogêneo) | — |
| Carbono incorporado | Zero marginal (já emitido) | Alto (novo hardware) | Médio (novo hardware) | — |
| Capacidade de ML local | Alta (NPU/DSP em SoCs modernos) | Muito alta (GPU dedicada) | Baixa (sem acelerador) | — |
| Adequação financeira/regulatória | Média (requer Zero Trust rigoroso) | Alta (SLA AWS, compliance nativo) | Média (depende de hardening) | — |

> **Minha Perspectiva: Quando Eu Usaria Isso em Produção:** Implementaria essa arquitetura em produção em exatamente dois cenários: (1) quando a latência de inferência local abaixo de 50ms é um requisito de negócio não negociável e o custo de AWS Wavelength ou Outposts é proibitivo, e (2) quando a organização tem um mandato ESG auditável que exige redução de carbono incorporado e tem os dispositivos disponíveis internamente — por exemplo, um banco renovando sua frota de smartphones corporativos. A lição mais dura que aprendi em projetos de IoT em escala é que o custo de operações de frota heterogênea é sistematicamente subestimado em 3-5x nas fases de planejamento; automatize o provisionamento, a remediação e o decommissioning desde o dia zero, ou o custo operacional vai consumir toda a economia de carbono e hardware em 18 meses. E nunca, jamais, use timestamp de dispositivo como fonte autoritativa em sistemas financeiros.

## Veredicto: Potencial Real, Complexidade Operacional Não Trivial

Computação de baixo carbono com dispositivos reutilizados é uma ideia arquiteturalmente legítima, não um experimento acadêmico — mas ela só se justifica quando a análise de custo total inclui o custo operacional de gerenciar hardware heterogêneo, o custo de segurança de uma superfície de ataque ampliada e o custo de engenharia de instrumentar carbono de forma auditável. Para organizações financeiras com mandatos ESG crescentes e frotas de dispositivos disponíveis internamente, a combinação de AWS IoT Greengrass v2, Fleet Provisioning, IoT Device Defender e MSK com particionamento cuidadoso oferece uma base técnica sólida. A recomendação prática: comece com um piloto de 50-100 dispositivos homogêneos (mesma geração de SoC, mesmo SO), instrumente tudo desde o início com OpenTelemetry e CloudWatch custom metrics, defina SLOs de frota por percentil, e só escale para hardware heterogêneo depois de ter o playbook operacional validado. A sustentabilidade real exige engenharia rigorosa, não apenas boa intenção.

## Referências e Leitura Adicional

- [AWS IoT Greengrass v2 Developer Guide](https://docs.aws.amazon.com/greengrass/v2/developerguide/what-is-iot-greengrass.html)
- [AWS IoT Fleet Provisioning](https://docs.aws.amazon.com/iot/latest/developerguide/provision-wo-cert.html)
- [AWS IoT Device Defender](https://docs.aws.amazon.com/iot/latest/developerguide/device-defender.html)
- [Amazon MSK Best Practices](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html)
- [AWS Well-Architected Sustainability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/sustainability-pillar/wellarchitected-sustainability-pillar.pdf)
- [Google Research: Low-carbon computing with retired phones](https://research.google/blog/)
- [Greening the Beast: Lifecycle Carbon in Mobile Devices (ACM)](https://dl.acm.org/doi/10.1145/3485447.3512188)
- [OpenTelemetry for IoT and Edge](https://opentelemetry.io/docs/)