Isolamento de custos multiorganização com Cloud Intelligence Dashboards

Por Eduardo Inoue (Technical Account Manager), Fabio Agarie (Senior Partner Technical Account Manager) e Liz Menichetti (Technical Account Manager),

Como o CUR 2.0 (AWS Data Exports) e Row-Level Security do Amazon Quick podem aplicar o menor privilégio à visibilidade de custos em escala

Imagine uma empresa que administra três organizações AWS independentes — subsidiárias adquiridas, cada uma com faturamento consolidado, Savings Plans e Reserved Instances próprios. A área financeira precisa de um painel único de custos, mas por exigência de conformidade um usuário de uma organização não pode enxergar — nem inferir — os custos das outras. Como entregar essa visibilidade centralizada sem que os dados de uma organização vazem para a outra?

Este post mostra como responder a essa pergunta combinando duas técnicas complementares no Cloud Intelligence Dashboards (CID): a filtragem de dados na origem com AWS Data Exports (CUR 2.0) e o Row-Level Security (RLS) do Amazon Quick. Uma isola os dados antes de eles chegarem ao painel; a outra controla, dentro de um conjunto de dados compartilhado, o que cada usuário vê. Juntas, elas permitem aplicar o princípio do menor privilégio à governança de custos em escala.

O desafio: visibilidade de custos sem abrir mão da governança

O Cloud Intelligence Dashboards (CID) — que inclui o Cost and Usage Dashboards Operations Solution (CUDOS) — fornece aos clientes AWS uma visão unificada de custos, uso e métricas operacionais de todo o ambiente. Com um template de AWS CloudFormation e poucos cliques, a organização passa a enxergar seu gasto de nuvem de ponta a ponta.

Essa visibilidade, porém, cria uma tensão com a governança de dados. À medida que a empresa cresce, o menor privilégio exige que cada pessoa ou times acessem apenas o que é relevante para a sua responsabilidade. Times financeiros de uma unidade de negócio precisam ver seus custos isolados. Times de segurança querem insights operacionais sem expor dados sensíveis entre contas. E o time de plataforma precisa governar esse acesso sem reconstruir painéis a cada mudança. É esse conjunto de requisitos que as duas técnicas a seguir endereçam.

Row-Level Security no Amazon Quick: controle de acesso por linha

O Row-Level Security (RLS) é um recurso do Amazon Quick disponível na edição Enterprise, que restringe quais linhas de um conjunto de dados cada usuário vê, com base em sua identidade ou grupo. Em vez de manter um painel separado por time, você mantém um único painel que filtra os dados dinamicamente por usuário. No CID isso é valioso porque centraliza a camada de governança: todos se conectam ao mesmo painel, mas cada pessoa ou grupo enxerga somente as contas AWS que está autorizado a ver.

A implementação do RLS no CID se apoia em um conjunto de dados de permissões no Amazon Quick, que mapeia usuários e grupos às contas AWS. Esse mapeamento tem quatro campos essenciais:

1. UserName (identificador do usuário no Amazon Quick, que deve corresponder exatamente ao nome cadastrado);
2. GroupName (identificador do grupo no Amazon Quick);
3. account_id (lista de contas AWS separadas por vírgula que o usuário/grupo pode acessar); e
4. payer_account_id (ID da conta de gestão — a management account do AWS Organizations, que paga os custos de todas as contas da organização. Conceder acesso a este campo é o que dá visibilidade a todas as contas vinculadas àquela organização, não apenas às contas-membro individuais).

Há três formas de definir esse mapeamento de permissões, cada uma adequada a um cenário: tags de AWS Organizations, quando você quer herança hierárquica de permissões a partir de Organization Units (OUs) e contas (requer acesso à conta de gestão); tabelas inline no Amazon Athena, quando você prefere simplicidade e não tem acesso à conta de gestão; e arquivos CSV no Amazon S3, quando quer integrar com um provedor de identidade ou banco de dados de gerenciamento de configuração (CMDB) e automatizar mudanças via pipeline de continuous integration/continuous delivery (CI/CD).

Com o conjunto de permissões definido, o CID aplica as seguintes regras de acesso:

Quando o RLS não basta: o gap de conformidade multi-organização

O RLS resolve muito bem a filtragem por conta para usuários dentro de uma mesma organização AWS. Mas empresas que operam múltiplas organizações AWS simultaneamente — subsidiárias adquiridas ou unidades federadas, cada uma com faturamento, Savings Plans e Reserved Instances próprios — esbarram em um limite importante.

Se você usar um único painel CUDOS com RLS, o painel consulta um CUR unificado que reúne os dados das três organizações — cada organização com seu Data Export consumidos por um mesmo conjunto de Dataset, não há consolidação de faturamento. O RLS filtra quais linhas cada usuário vê, mas o conjunto de dados subjacente combina tudo em uma consulta só — e os Savings Plans e Reserved Instances compartilhados são alocados proporcionalmente sobre essa visão unificada. Já a alternativa de manter um painel separado por organização entrega isolamento completo, mas multiplica a complexidade operacional: três painéis, três ciclos de manutenção, três conjuntos de alertas.

É aqui que a filtragem de dados na origem entra. O AWS Data Exports permite especificar uma cláusula WHERE no momento de criar o export, filtrando quais linhas de faturamento a AWS grava no seu bucket S3. Um exemplo de filtro por conta:

WHERE line_item_usage_account_id IN ('111111111111', '222222222222', '333333333333')

Confira neste blog Automating filtered Cost and Usage Report exports with AWS Data Exports como listar contas num arquivo CSV.

Com isso, o isolamento de custos deixa de ser uma preocupação da camada de painel e passa a ser uma decisão de arquitetura de dados: os dados de faturamento da Organização A simplesmente não aparecem no prefixo S3 da Organização B — não existem no banco, no resultado da consulta nem no painel. É a diferença entre esconder o dado e não tê-lo.

CUR 2.0 e Data Exports: segregação de dados na origem

Na prática, a filtragem funciona assim: você cria um Data Export (no console de Billing and Cost Management, ou via AWS CLI/SDK); define um QueryStatement — a instrução SQL — que consulta a tabela CUR 2.0 chamada COST_AND_USAGE_REPORT, incluindo a cláusula WHERE que filtra por line_item_usage_account_id; aponta um prefixo S3 de saída por organização (por exemplo, s3://amzn-s3-demo-bucket/org-a/); e de acordo com a configuração é gerado arquivos Parquet contendo apenas as linhas filtradas, particionados por período de faturamento.

Uma das features do AWS Data Exports com o CUR 2.0 é a possibilidade de entregar o arquivo diretamente na conta destino em um bucket do Amazon S3, sem armazenamento local.

Um ponto importante sobre a interface: o console do Data Exports monta o SQL a partir de seleções guiadas (principalmente seleção de colunas). Para escrever um SQL próprio com uma cláusula WHERE de filtragem por linha, use a AWS CLI ou o AWS SDK — é o caminho que dá controle total sobre o QueryStatement. Vale também lembrar que o Data Exports suporta apenas um subconjunto do SQL: seleção de colunas, filtragem de linhas e alias; não há agregações.

As vantagens sobre usar apenas o RLS são diretas: o isolamento é completo, porque o dado sensível de outras organizações nunca é exportado nem consultado; a consolidação de faturamento é preservada, já que cada organização continua compartilhando Savings Plans e Reserved Instances dentro do seu próprio domínio; a escalabilidade melhora, porque adicionar uma organização exige apenas um novo export, sem redesenhar painel (respeitando a quota de 5 exports de CUR 2.0 por conta); e a conformidade fica mais simples de auditar, pois a trilha mostra que o dado foi filtrado na origem.

Caminho recomendado de automação: a AWS publicou a solução de exemplo sample-cur-filtered-data-exports (blog AWS Cloud Financial Management), que empacota esse padrão em um template de CloudFormation. Você informa os IDs de conta em um arquivo accounts.csv, o script monta a cláusula WHERE e faz o deploy do export filtrado a partir da conta de gestão É a forma mais simples de operacionalizar o padrão descrito aqui.

Arquitetura de referência

O fluxo por organização é simétrico e independente: o faturamento (CUR 2.0) de cada organização é filtrado por sua cláusula WHERE e gravado em um prefixo Amazon S3 dedicado; um AWS Glue Crawler cataloga aquele prefixo em um banco de dados segregado; o Amazon Athena consulta esse banco; e o Amazon Quick monta o conjunto de dados com RLS que alimenta o painel CUDOS daquela organização — e somente dela.

Organização A: Billing (CUR 2.0) → WHERE contas da Org A → S3 /org-a/ → Glue Crawler → banco cid_org_a → Athena → Amazon Quick + RLS → CUDOS (somente Org A).

Organização B: Billing (CUR 2.0) → WHERE contas da Org B → S3 /org-b/ → Glue Crawler → banco cid_org_b → Athena → Amazon Quick + RLS → CUDOS (somente Org B).

Implementação passo a passo

1. Criar os Data Exports com filtragem SQL

Crie um export por organização, filtrando as contas de cada uma para o prefixo correspondente. Via AWS CLI (bcm-data-exports create-export), o QueryStatement seleciona as colunas de COST_AND_USAGE_REPORT com a cláusula WHERE line_item_usage_account_id IN (…), e o destino S3 aponta para o prefixo da organização (por exemplo, exports/org-a/), com saída em Parquet e cadência diária. Repita para a Organização B, filtrando outras contas para exports/org-b/.

Exemplo de QueryStatement:

SELECT ... FROM COST_AND_USAGE_REPORT WHERE line_item_usage_account_id IN ('111111111111','222222222222','333333333333')

2. Atualizar os AWS Glue Crawlers

Aponte o crawler (por exemplo, cid-DataExportCUR2Crawler) para o prefixo S3 específico da organização — de s3://meu-bucket/cur2/ para s3://meu-bucket/exports/org-a/ — e direcione a saída para um banco de dados segregado, como cid-org-a.

3. Conferir o LOCATION das tabelas no Athena

Depois que o crawler terminar de executar, verifique com SHOW CREATE TABLE que o LOCATION da tabela aponta para o prefixo correto (s3://meu-bucket/exports/org-a/). Se estiver desalinhado, corrija com ALTER TABLE … SET LOCATION e rode MSCK REPAIR TABLE para registrar as partições. Um LOCATION desalinhado é uma causa comum de painel que consulta com sucesso mas retorna zero linhas.

4. Implantar o painel CUDOS e aplicar o RLS

Use a ferramenta cid-cmd para implantar o CUDOS apontando para o banco segregado (por exemplo, cid-cmd deploy –athena-database cid_org-a) e aplicar o RLS aos conjuntos de dados (cid-cmd update –recursive –rls ENABLED).

5. Configurar as permissões de RLS

Defina as views de permissão no banco Athena da organização — usuários e/ou grupos com acesso total e o mapeamento por conta (account_id, payer_account_id e as identidades autorizadas). A ferramenta cid-cmd constrói a rls_view final a partir desses componentes. Lembre-se de que os identificadores de usuário precisam corresponder exatamente aos do Amazon Quick.

Conclusão

Governança de custos é tão crítica para a adoção da AWS quanto desempenho ou segurança. Ao filtrar os dados na origem com AWS Data Exports e controlar o acesso por linha com o Row-Level Security do Amazon Quick, você aplica o menor privilégio de ponta a ponta na sua plataforma de inteligência de custos: use a filtragem de CUR 2.0 quando precisar de isolamento por organização ou unidade de negócio; use o RLS para gerenciar o acesso por usuário e por time dentro de um conjunto de dados compartilhado; e combine os dois quando quiser governança completa — fontes de dados filtradas na origem somadas a permissões granulares por usuário.

Comece pela estrutura da sua organização, escolha a abordagem que corresponde aos seus requisitos de conformidade. A documentação da AWS, a comunidade do CID e os Well-Architected Labs oferecem implementações de referência.

Referências

• AWS Data Exports — Data query (SQL): https://docs.aws.amazon.com/cur/latest/userguide/dataexports-data-query.html
• AWS Data Exports — Quotas e restrições: https://docs.aws.amazon.com/cur/latest/userguide/dataexports-quotas.html
• Migrar de CUR para Data Exports CUR 2.0 (tabela COST_AND_USAGE_REPORT): https://docs.aws.amazon.com/cur/latest/userguide/data-exports-migrate-one.html
• Automating filtered Cost and Usage Report exports with AWS Data Exports (blog + repo de exemplo): https://aws.amazon.com/blogs/aws-cloud-financial-management/automating-filtered-cost-and-usage-report-exports-with-aws-data-exports/
• Amazon Quick — Row-Level Security (Enterprise edition): https://docs.aws.amazon.com/quick/latest/userguide/row-level-security.html
• Cloud Intelligence Dashboards (cid-cmd): https://github.com/aws-solutions-library-samples/cloud-intelligence-dashboards-framework/

Autores

	Liz Menichetti é Technical Account Manager na AWS. Desde 2019 auxilia os clientes da AWS com arquitetura e projetos de destaque nas mais variadas verticais da indústria, não só dando suporte aos clientes, mas também trazendo valor ao negócio com boas práticas de segurança, escalabilidade, resiliência, performance e excelência operacional.
	Eduardo Kinishi Inoue é Technical Account Manager na AWS, apoia clientes na construção de ambientes resilientes, seguros e otimizados em nuvem. Desde 2011 trabalhando com tecnologia — de infraestrutura on-premises a arquiteturas cloud-native — e a curiosidade por aprender continua a mesma desde o primeiro dia. Foco atual: Segurança, FinOps e adoção de IA generativa no setor financeiro.
	Fabio Agarie é Senior Partner Technical Account Manager na AWS auxiliando parceiros LATAM e seus clientes com performance de ambientes, arquitetura de dados e melhoria de custos. Atuando na área de tecnologia desde 1997, é Pós-graduado em Databases, membro ativo da comunidade técnica de Databases e de Cloud Operations contribuindo com conhecimento técnico e ministrando workshops em eventos.