Amazon SAA-C03: Analytics, Data Lake, ML e Cargas de Trabalho Especializadas — Guia de estudos

By Laurynas Brazys · 18 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Faz parte do AWS SAA-C03 — Guia de estudos completo. Pratique com respostas verificadas no centro de exames da Amazon, ou faça testes cronometrados no ExamRoll.io.

Fundamentos de Data Lake: Lake Formation e o Glue Data Catalog

O ponto central para analytics na AWS é o AWS Glue Data Catalog — um metastore compatível com o Hive metastore que o Athena, Redshift Spectrum, EMR e Glue ETL consomem. Toda definição de tabela, partição, tipo de coluna e configuração de SerDe reside aqui, e todo mecanismo consumidor lê a partir dele. Se dois caminhos de ingestão (digamos, um crawler do Glue e uma instrução manual CREATE EXTERNAL TABLE) discordarem sobre o esquema do mesmo prefixo do S3, as consultas retornam silenciosamente resultados incorretos ou falham. O padrão correto é designar uma única autoridade por tabela: ou o crawler é o dono do esquema, ou seu job de ETL escreve via glueContext.write_dynamic_frame.from_catalog, mas nunca ambos sem uma estratégia de mesclagem. Quando o ETL em lote, a conversão para Parquet do Firehose e DDLs manuais escrevem na mesma tabela, o desvio de catálogo (catalog drift) é o assassino silencioso. Imponha um único dono por tabela, use o Glue Schema Registry para produtores de streaming e execute crawlers no modo LOG (não UPDATE_IN_DATABASE) em tabelas que pertencem a jobs de ETL para que eles exponham o desvio sem sobrescrever esquemas curados.

O AWS Lake Formation fica acima do Data Catalog e substitui o modelo de políticas de bucket IAM/S3 de granularidade grossa por uma camada de permissões no estilo de banco de dados. Em vez de conceder s3:GetObject em um prefixo, você executa GRANT SELECT ON customers.orders TO role/AnalystRole, e o Lake Formation fornece de forma transparente credenciais de curta duração quando o Athena ou o Redshift Spectrum acessam os objetos subjacentes. Seu valor real é a autorização de granularidade fina: filtragem em nível de coluna, segurança em nível de linha através de filtros de dados e controle de acesso baseado em tags (LF-Tags) que escalam para milhares de tabelas. Uma plataforma de varejo com PII (Informações de Identificação Pessoal) em uma tabela customers pode conceder aos analistas acesso a customer_id, region, signup_date enquanto bloqueia email e ssn — aplicado em tempo de consulta, sem a necessidade de proliferação de views.

A configuração canônica para um data lake governado:

1. Register S3 locations with Lake Formation (removes IAMAllowedPrincipals default).
2. Create databases and let Glue crawlers populate tables.
3. Define LF-Tags (e.g., Classification=PII, Domain=Sales).
4. Grant tag-based permissions to IAM principals.
5. Point Athena/Redshift/QuickSight at the catalog — permissions flow through.

Os blueprints do Lake Formation são templates de workflow pré-construídos que conectam crawlers, jobs e triggers para ingerir dados de fontes JDBC ou do S3 para um data lake curado — reduzindo o que seriam dezenas de recursos do Glue configurados manualmente a um fluxo guiado por um assistente (wizard).

Um erro frequente é tentar aplicar restrições em nível de coluna apenas no QuickSight. O QuickSight possui segurança em nível de linha e coluna vinculada a datasets, mas protege apenas a superfície do QuickSight — qualquer pessoa com acesso direto ao Athena ou S3 contorna essa proteção. O controle em nível de coluna deve ser aplicado na camada de dados (permissões do Lake Formation ou separando fisicamente as colunas durante o ETL), e o QuickSight herda essa postura através de sua IAM role.

Athena: SQL Serverless Sobre o S3

O Athena é um mecanismo Presto/Trino serverless e com pagamento por consulta que lê diretamente do Amazon S3. Sem cluster para provisionar, sem etapa de ETL necessária antes de consultar e sem custo quando ocioso — você paga apenas pelos bytes escaneados (normalmente $5/TB). Isso torna o Athena a escolha canônica para análise ad-hoc de arquivos que já estão no S3, sejam logs de aplicação em JSON, exportações em CSV ou tabelas de fatos em Parquet. O Athena precisa de um esquema e de um layout de partição, que residem no Glue Data Catalog.

Como o Athena cobra por terabyte escaneado, o formato de armazenamento tem um impacto desproporcional no custo e na latência. As duas alavancas são o formato e o particionamento:

• Formatos colunares (Parquet, ORC) permitem que o Athena elimine colunas e grupos de linhas (row groups). Uma consulta como SELECT sum(amount) FROM orders WHERE region='us-east-1' em Parquet lê apenas as duas colunas referenciadas; em CSV, ele lê cada byte de cada linha.
• Particionamento em colunas de alta seletividade (por exemplo, dt=2024-03-11/) reduz uma varredura de tabela completa (full-table scan) a uma leitura direcionada. Em logs de múltiplos terabytes (CloudFront, ALB, VPC Flow Logs), essa é a diferença entre uma consulta de $0,15 e uma de $30.

Converter JSON ou CSV brutos em Parquet particionado e com compressão Snappy é quase sempre a primeira alavanca de custo a ser acionada. Combinado com o pushdown de LIMIT, o Athena atende à maioria das necessidades de análise no S3 com zero infraestrutura.

Um padrão de custo-benefício para uma tabela de “leituras” armazenada como Parquet particionado:

CREATE EXTERNAL TABLE readings (
  station_id string,
  reading_ts timestamp,
  temp_c    double
)
PARTITIONED BY (dt string)
STORED AS PARQUET
LOCATION 's3://weather-lake/readings/'
TBLPROPERTIES ('has_encrypted_data'='true');

SELECT station_id, AVG(temp_c) OVER (
         PARTITION BY station_id
         ORDER BY reading_ts
         ROWS BETWEEN 6 PRECEDING AND CURRENT ROW) AS moving_avg
FROM readings
WHERE dt = '2024-03-11';

Pular o crawler é um erro comum. Sem uma entrada no catálogo, ou você escreve DDLs CREATE EXTERNAL TABLE manuais (frágeis à medida que os esquemas evoluem) ou usa soluções improvisadas de schema-on-read que escaneiam todos os arquivos. Pior, sem MSCK REPAIR TABLE ou projeção de partição, o Athena escaneia o prefixo inteiro em cada consulta. Os crawlers do Glue detectam novas partições de forma agendada e atualizam o catálogo atomicamente.

Athena em dados criptografados no S3. O Athena suporta SSE-S3, SSE-KMS e CSE-KMS, mas apenas se o chamador tiver as permissões corretas do KMS e o workgroup ou o cliente estiver configurado para o modo de criptografia em uso. Para CSE-KMS, o arquivo é criptografado no lado do cliente antes do upload; o principal do IAM que executa a consulta precisa de kms:Decrypt e kms:GenerateDataKey na CMK, e a política da chave deve corresponder. Um modo de falha comum: carregar Parquet com CSE-KMS, conceder à role do Athena apenas permissões de leitura do S3 e, em seguida, receber erros opacos como AccessDenied ou HIVE_CANNOT_OPEN_SPLIT — o objeto é legível, mas o texto cifrado não pode ser desembrulhado. Outro erro frequente é registrar a tabela com o modo de criptografia errado (SSE-KMS nas propriedades da tabela quando os objetos foram escritos com CSE-KMS); o Athena tenta a descriptografia no lado do servidor durante o GetObject e a carga útil (payload) retorna como texto cifrado bruto que falha nas verificações de número mágico (magic-number) do Parquet.

As consultas federadas do Athena permitem unir dados do S3 com armazenamentos operacionais (DynamoDB, RDS) sem mover os dados. Reserve o Athena para análises ad-hoc orientadas à leitura; use jobs do Glue para a modelagem agendada de zonas curadas.

Glue Crawlers, ETL Jobs e Job Bookmarks

Os crawlers do Glue varrem caminhos do S3, inferem o esquema (incluindo chaves de partição da estrutura de diretórios, como year=2024/month=01/) e registram ou atualizam tabelas no catálogo. Eles são a resposta low-code para o problema “colocamos arquivos no S3, torne-os consultáveis”. Agende um crawler para rodar de hora em hora em um bucket de recebimento (landing bucket) e o Athena verá imediatamente as novas partições.

aws glue create-crawler \
  --name logs-crawler \
  --role AWSGlueServiceRole-Logs \
  --database-name analytics_db \
  --targets '{"S3Targets":[{"Path":"s3://acme-logs/app/"}]}' \
  --schedule "cron(0 * * * ? *)"

Os jobs de ETL do Glue (Spark, Python shell ou Ray) cuidam da parte de transformação. O Glue é serverless — você paga por DPU-hora com um mínimo de um minuto — e o tempo de execução escala os workers automaticamente. O padrão dominante é a entrada de CSV/JSON e a saída de Parquet particionado:

import sys
from awsglue.context import GlueContext
from pyspark.context import SparkContext

glueContext = GlueContext(SparkContext.getOrCreate())
df = glueContext.create_dynamic_frame.from_catalog(
    database="raw", table_name="reports_csv")
glueContext.write_dynamic_frame.from_options(
    frame=df,
    connection_type="s3",
    connection_options={"path": "s3://curated/reports/",
                        "partitionKeys": ["report_date"]},
    format="parquet",
    format_options={"compression": "snappy"})

A característica operacional crítica é o job bookmark: o Glue persiste o estado sobre quais arquivos ou partições ele já processou, para que as execuções subsequentes leiam apenas os dados novos. Esquecer de habilitar os bookmarks significa que cada execução reprocessará todo o conjunto de dados desde o início, inflando o custo e o tempo de execução linearmente e, muitas vezes, produzindo saídas duplicadas. Os bookmarks são habilitados por job e devem ser combinados com opções de origem que os suportem (fontes S3 através do leitor Glue DynamicFrame suportam; leituras Spark arbitrárias não). Os bookmarks exigem um argumento transformation_ctx em cada fonte e o uso de job.init(...) / job.commit() para delimitar o processo:

job = Job(glueContext)
job.init(args['JOB_NAME'], args)   # bookmark state loaded

datasource = glueContext.create_dynamic_frame.from_catalog(
    database="analytics_db",
    table_name="app_logs",
    transformation_ctx="datasource"   # required for bookmarking
)
# ... transforms ...
job.commit()                          # bookmark state persisted

Para conversão de formato pura, sem lógica, a opção de menor esforço geralmente é um crawler do Glue nos dados brutos mais um job do Glue criado no editor visual (ou uma receita do DataBrew) — nenhum código Spark é necessário. Clusters EMR personalizados ou conversores Lambda adicionam uma sobrecarga operacional que o modelo serverless do Glue elimina.

Um job diário típico que organiza dados do S3 e carrega no Redshift Serverless:

# Glue 4.0 PySpark: S3 raw -> curated -> Redshift Serverless
df = glueContext.create_dynamic_frame.from_catalog(
        database="raw", table_name="orders").toDF()
df = df.filter("order_status <> 'CANCELLED'") \
       .withColumn("order_date", to_date("order_ts"))

glueContext.write_dynamic_frame.from_jdbc_conf(
    frame       = DynamicFrame.fromDF(df, glueContext, "out"),
    catalog_connection = "redshift-serverless-conn",
    connection_options = {"dbtable": "fact_orders", "database": "analytics"},
    redshift_tmp_dir   = "s3://stg/redshift-tmp/")

Glue Security Configurations e ETL Multi-Tenant

Crawlers e jobs do Glue precisam da mesma consciência sobre criptografia que o Athena. As security configurations (configurações de segurança) do Glue são pacotes nomeados que especificam como os alvos do S3, os logs do CloudWatch e os job bookmarks são criptografados — incluindo CSE-KMS com uma CMK específica. Um job associado a uma security configuration descriptografa de forma transparente a entrada CSE-KMS e criptografa as saídas da mesma maneira, desde que a IAM role do job tenha permissões no KMS para as chaves referenciadas.

Para ETL multi-tenant — uma plataforma SaaS processando os dados de cada cliente com a CMK daquele cliente — o padrão correto é uma security configuration por cliente (ou um parâmetro de job selecionando a CMK) mais uma IAM role com escopo para aquela CMK. Processar todos os clientes através de um único job com uma única chave compartilhada anula a garantia de isolamento que o CSE-KMS se destina a fornecer.

Uma disciplina relacionada: tabelas analíticas de produção não devem ser o alvo direto de jobs ou notebooks exploratórios do Glue. Exporte um snapshot para um prefixo “analytics” no S3 e aponte o Athena ou o Spark para a cópia. Executar transformações experimentais na tabela ativa arrisca reescritas em nível de partição, corrupção de bookmarks e contenção de locks, além de borrar a fronteira de auditoria entre dados operacionais e derivados analíticos.

AWS Glue DataBrew

O DataBrew é o irmão low-code do Glue para usuários que não podem ou não devem escrever código Spark. Ele oferece uma interface no estilo de planilha com mais de 250 transformações pré-construídas (imputação, mascaramento de PII, agrupamento de outliers, parsing de datas). Seus diferenciais são as shared recipes (receitas compartilhadas) — artefatos JSON versionados que você pode publicar e reaplicar em vários projetos — e a data lineage visualization (visualização de linhagem de dados) que rastreia colunas desde os conjuntos de dados de origem, através de receitas e jobs, até os locais de saída. Escolha o DataBrew quando os analistas são donos da lógica de transformação; escolha o Glue Studio/scripts quando os engenheiros são os donos e o pipeline precisa de código personalizado, streaming ou joins complexos.

Amazon EMR: Batch Distribuído e Runtime Roles

O Amazon EMR é uma plataforma de cluster gerenciado que executa Spark, Hadoop, Hive, Presto, HBase e Flink. Seu ponto ideal (sweet spot) são cargas de trabalho em lote (batch) ou interativas, grandes e paralelizáveis, que leem conjuntos de dados em escala de petabytes no S3 e os unem a outro sistema de registro (frequentemente o Redshift) para enriquecimento. O EMR pode executar clusters transientes (iniciar, executar, terminar) ou de longa duração, e pode misturar instâncias On-Demand, Spot e Reserved por meio de instance fleets.

Um padrão canônico: um job Spark lê Parquet do S3, busca tabelas de dimensão do Redshift via UNLOAD-para-S3, une-as através dos executores e escreve a saída enriquecida de volta para o S3:

# Spark on EMR: enrich S3 events with Redshift dimensions
df_events = spark.read.parquet("s3://raw/events/dt=2024-11-01/")
df_dims = (spark.read
    .format("io.github.spark_redshift_community.spark.redshift")
    .option("url", "jdbc:redshift://cluster:5439/analytics")
    .option("dbtable", "public.customer_dim")
    .option("tempdir", "s3://staging/redshift-unload/")
    .load())

enriched = df_events.join(df_dims, "customer_id", "left")
enriched.write.mode("overwrite").partitionBy("region").parquet("s3://curated/events/")

O EMR se destaca aqui porque o Spark distribui o join por dezenas de nós, e o staging via S3 evita um gargalo single-threaded do JDBC. A armadilha é recorrer reflexivamente ao EMR sempre que dados no S3 precisam ser consultados. Para SQL ad-hoc em dezenas ou centenas de gigabytes, provisionar e ajustar um cluster Spark é pura sobrecarga operacional — dimensionamento do cluster, configuração do YARN, autoscaling, rotação de logs, aplicação de patches. O EMR só vale a pena quando o volume, o código personalizado ou a flexibilidade do motor de execução o justificam.

EMR runtime roles. Historicamente, todos os steps em um cluster herdavam o EC2 instance profile — uma única role associada aos nós subjacentes — o que significava que cada equipe compartilhando um cluster tinha a união de todas as permissões que qualquer equipe precisava. As runtime roles resolvem isso: quando um usuário submete um step, ele passa --execution-role-arn, e o EMR assume essa role durante a execução do step. A Equipe A pode ser restrita a s3://team-a/*, e a Equipe B a s3://team-b/*. O instance profile se torna uma role de bootstrap mínima que apenas busca os artefatos do cluster.

As runtime roles também são o mecanismo para bloquear o acesso ao IMDS. Quando habilitado (EMR 6.7+ com Spark/Hive no YARN), o código do usuário não consegue alcançar o serviço de metadados da instância — incluindo o IMDSv2 — porque a plataforma intercepta essas chamadas. Isso fecha o caminho de escalonamento de privilégios onde um job poderia, de outra forma, chamar http://169.254.169.254/latest/api/token e assumir o poderoso EC2 instance profile.

aws emr create-cluster \
  --release-label emr-6.15.0 \
  --applications Name=Spark Name=Hive \
  --security-configuration team-isolation-sc \
  --service-role EMR_DefaultRole \
  --ec2-attributes InstanceProfile=EMR_EC2_MinimalRole,...

aws emr add-steps --cluster-id j-XXXX \
  --steps Type=Spark,Name="TeamA-ETL",\
ActionOnFailure=CONTINUE,\
Jar=command-runner.jar,\
Args=[spark-submit,s3://team-a/jobs/etl.py] \
  --execution-role-arn arn:aws:iam::111122223333:role/TeamA-EMRRuntime

A security configuration é o que habilita a imposição da runtime role e o bloqueio do IMDS. Sem ela, assumir que as cargas de trabalho do EMR “usam automaticamente roles de privilégio mínimo” está errado — por padrão, elas compartilham o instance profile e o IMDS é acessível a partir do código do usuário.

Amazon Redshift e Redshift ML

O Redshift é um data warehouse colunar e MPP (Massively Parallel Processing) para cargas de trabalho de análise sustentadas que exigem dashboards com resposta em subsegundos, joins complexos em bilhões de linhas e latência consistente sob múltiplos usuários de BI concorrentes. Os nós RA3 desacoplam a computação do armazenamento gerenciado; o Redshift Serverless cobra em RPU-segundos com base em uma capacidade base configurada, escala sob carga e pausa quando ocioso, eliminando o problema tradicional de dimensionamento de cluster.

O Redshift participa de pipelines de análise em dois modos de enriquecimento:

• Como origem: O Spark no EMR extrai dimensões via UNLOAD-to-S3, ou o Glue lê através da Redshift Data API.
• Como destino: O Firehose ou um job do Glue executa um COPY dos dados enriquecidos para dentro do Redshift.

O Redshift Spectrum estende isso permitindo que o SQL do Redshift consulte o S3 diretamente através do Glue Data Catalog — o mesmo catálogo que o Athena usa — que é o que faz o padrão lake-house funcionar. Ideal quando você já tem um cluster Redshift e quer fazer join de fatos do warehouse com o histórico frio no S3 sem mover os dados.

Cargas em lote (batch) usam COPY a partir do S3, paralelizadas entre os nós de computação; os arquivos devem ser divididos em partes de tamanho aproximadamente igual (um múltiplo da contagem de slices) para paralelismo:

COPY events FROM 's3://acme-lake/events/dt=2024-05-12/'
IAM_ROLE 'arn:aws:iam::111:role/RedshiftLoader'
FORMAT AS PARQUET;

A ingestão de streaming normalmente flui através do Firehose (COPY em buffer) para uma entrega sem operações (zero-ops).

O Redshift ML permite que usuários de SQL criem, treinem e invoquem modelos via CREATE MODEL:

CREATE MODEL churn_predictor
FROM (SELECT tenure, plan, monthly_spend, churned FROM customers)
TARGET churned
FUNCTION predict_churn
IAM_ROLE default
SETTINGS (S3_BUCKET 'redshift-ml-artifacts');

SELECT customer_id, predict_churn(tenure, plan, monthly_spend)
FROM customers_current;

Por baixo dos panos, o Redshift exporta o conjunto de treinamento para o S3, invoca o SageMaker Autopilot (ou um algoritmo especificado como o XGBoost) e importa o modelo compilado para inferência dentro do banco de dados. É poderoso quando os analistas já vivem em SQL, mas não substitui uma plataforma completa de ML: a movimentação de dados para o S3 e a computação de treinamento do SageMaker são cobradas separadamente, grandes conjuntos de treinamento podem gerar custos significativos de egressão e de tempo de execução do Autopilot, e não há um fluxo de trabalho integrado para feature stores, rastreamento de experimentos ou implantação A/B. Trate o Redshift ML como uma forma de inferência democratizada sobre dados do Redshift, não como um serviço de treinamento de propósito geral.

Escolhendo entre Athena e Redshift

Ingestão de Streaming: Kinesis Data Streams, Firehose e MSK

Os três serviços de streaming da AWS resolvem problemas sobrepostos com garantias materialmente diferentes:

O Kinesis Data Streams usa shards (ou o modo on-demand); registros com a mesma chave de partição vão para o mesmo shard e são consumidos em ordem. Os consumidores usam o clássico GetRecords ou o Enhanced Fan-Out (2 MB/s dedicados por consumidor). Uma função Lambda anexada como fonte de evento é invocada com lotes (batches) por shard, preservando a ordem. Esta é a escolha correta quando a lógica downstream não é trivial, quando múltiplos consumidores independentes precisam reproduzir o histórico (replay), ou quando os volumes de clickstream são enormes — por exemplo, um site gerando 30 TB/dia fluiria através do KDS para o Firehose e pousaria no S3 para análise com Athena/Spectrum.

O Kinesis Data Firehose é uma entrega gerenciada do tipo “dispare e esqueça” (fire-and-forget): ele armazena em buffer por tamanho ou tempo (ex: 5 MB / 300 segundos), opcionalmente invoca uma Lambda para transformação, opcionalmente converte JSON para Parquet/ORC usando o esquema de uma tabela do Glue, e escreve no S3, Redshift (via S3 + COPY), OpenSearch ou Splunk. Ativar a conversão para Parquet no Firehose é a maneira de baixo esforço para depositar dados de streaming em formato otimizado para consulta sem um job do Glue downstream:

Firehose delivery stream → 
  Record transformation: Lambda (optional, for enrichment) →
  Format conversion: enabled, schema from Glue table "events.raw" →
  Destination: s3://lake/events/ partitioned by !{timestamp:yyyy/MM/dd}

O Firehose não tem garantia de ordenação de ponta a ponta, não pode suportar múltiplos consumidores com capacidade de replay, e seus destinos são sinks fixos. Escolher o Firehose quando o requisito diz “processar cada registro em ordem” ou “múltiplos consumidores independentes” está errado em ambos os casos. Da mesma forma, esperar que o Firehose sozinho realize transformações complexas é uma armadilha — seu único gancho (hook) de transformação é uma Lambda invocada por lote em buffer. Qualquer coisa que envolva enriquecimento externo, agregação de múltiplos registros ou roteamento condicional deve residir nessa Lambda ou ser movida para o Managed Service for Apache Flink.

O Amazon MSK é o Apache Kafka gerenciado. Escolha-o quando você já tiver produtores/consumidores Kafka, precisar de recursos específicos do Kafka (tópicos compactados, transações, Kafka Streams, Connect) ou exigir uma vazão (throughput) além do que o Kinesis baseado em shards entrega confortavelmente.

Usar SQS ou EventBridge como um caminho de ingestão para analytics é um erro: o SQS não é ordenado por stream e não tem capacidade de replay; o EventBridge é otimizado para roteamento de eventos, não para ingestão sustentada de múltiplos MB/s.

Pesquisa em Tempo Real: KDS + Firehose + OpenSearch + QuickSight

A substituição canônica para uma pilha Elasticsearch+Logstash on-premises é:

O Firehose armazena em buffer os registros do stream e os entrega diretamente a um domínio OpenSearch, cuidando de novas tentativas, backup no S3 e transformação opcional com Lambda. O OpenSearch Dashboards é integrado e gratuito com o domínio e é adequado para operadores que monitoram streams em tempo real. O QuickSight complementa isso para análises voltadas para o negócio — ele consulta diretamente o Athena, Redshift, RDS e OpenSearch, e seu mecanismo colunar em memória SPICE armazena em cache conjuntos de dados processados para um desempenho de dashboard de subsegundo.

Uma divisão típica: OpenSearch Dashboards para operadores; QuickSight para executivos que consomem conjuntos de dados agregados e selecionados, originados do data lake Athena/Glue. Ambos devem receber acesso de leitura do IAM e, quando aplicável, a permissão Decrypt do KMS nas CMKs que protegem o armazenamento subjacente — caso contrário, a camada de visualização renderiza painéis vazios com erros de permissão ocultos nos logs de consulta.

Controle de Acesso do QuickSight

O QuickSight cria datasets (consultas lógicas mais campos calculados e segurança em nível de linha), depois analyses (análises) sobre os datasets e, em seguida, publica dashboards (visualizações compartilháveis somente leitura). O controle de acesso é feito em camadas e deve ser aplicado na camada correta. A armadilha é conceder acesso amplo no nível do dashboard — compartilhando com um grupo de toda a organização quando apenas um subconjunto deveria ver os dados subjacentes.

O princípio do menor privilégio no QuickSight significa:

• Compartilhar o dataset apenas com os usuários/grupos que precisam dele.
• Aplicar segurança em nível de linha (row-level security) por meio de um dataset de permissões que filtra as linhas por nome de usuário ou grupo.
• Aplicar segurança em nível de coluna (column-level security) para ocultar campos sensíveis.
• Compartilhar dashboards com usuários, grupos ou (para análises embarcadas) namespaces específicos.

Tornar um dashboard público ou compartilhá-lo com toda a conta contorna a intenção dos controles no nível do dataset, porque quem visualiza o dashboard herda o acesso de leitura aos dados visualizados, independentemente das permissões da fonte subjacente. Lembre-se de que a segurança em nível de coluna do QuickSight protege apenas a superfície do QuickSight; qualquer pessoa com acesso direto ao Athena ou S3 a ignora, portanto, controles sensíveis devem estar no Lake Formation ou no ETL, e não apenas no QuickSight.

As funções (roles) do QuickSight — Admin, Author, Reader — controlam o que um usuário pode fazer, o que é diferente das permissões de compartilhamento que controlam o que ele pode ver. Um Reader consome a um custo por sessão mais baixo do que uma licença de Author, então as populações de visualizadores devem ser Readers por padrão, e o acesso deve ser concedido por meio de associação a grupos, em vez de atribuição individual.

Amazon Neptune para Workloads de Grafo

O Neptune é um banco de dados de grafo gerenciado que suporta o modelo de grafo de propriedades (Gremlin, openCypher) e RDF (SPARQL). Ele é projetado especificamente para dados altamente conectados — relacionamentos sociais, redes de fraude, grafos de conhecimento, mecanismos de recomendação — onde joins recursivos em um banco de dados relacional se tornam proibitivos. Uma plataforma social com usuários, seguidores, curtidas e posts mapeia-se naturalmente para vértices e arestas, e o Neptune responde a travessias de múltiplos saltos (“amigos de amigos que curtiram X”) em milissegundos.

O Neptune Streams expõe um log ordenado e baseado em tempo de cada mutação no grafo. Uma função Lambda ou uma aplicação que consulta o stream pode reagir a mudanças — recalcular recomendações, atualizar um índice de pesquisa, acionar alertas de fraude — sem um pipeline de captura de dados de alteração (change-data-capture) personalizado. Reproduzir isso no Aurora ou DynamoDB requer travessia de grafo no nível da aplicação, além de uma estrutura de CDC separada. Quando o enunciado do problema inclui tanto “analisar relacionamentos” quanto “monitorar mudanças”, o Neptune com Streams é a combinação direta.

SageMaker: ML Personalizado de Ponta a Ponta

O SageMaker oferece o ciclo de vida completo: notebooks do Studio, trabalhos de treinamento gerenciados (com suporte a instâncias spot), Model Registry, endpoints em tempo real e serverless, transformação em lote (batch transform) e Pipelines para MLOps. Um fluxo típico envolve o upload de dados de treinamento para o S3, o lançamento de um trabalho de treinamento especificando um algoritmo integrado ou um contêiner personalizado, e o SageMaker provisiona instâncias efêmeras, transmite logs para o CloudWatch e grava o artefato do modelo de volta no S3. A implantação é uma única chamada de API:

from sagemaker.estimator import Estimator
est = Estimator(image_uri=xgb_image, role=role,
                instance_count=2, instance_type="ml.m5.xlarge",
                output_path="s3://models/xgb/")
est.fit({"train": "s3://data/train/", "validation": "s3://data/val/"})
predictor = est.deploy(initial_instance_count=1, instance_type="ml.m5.large")

Não há Kubernetes, driver de GPU ou servidor de modelo para gerenciar. Para equipes cujo requisito é “treinar e expor um modelo”, o SageMaker é quase sempre a resposta com menor sobrecarga em comparação com a implementação de inferência em ECS/EC2 por conta própria.

Os SageMaker Savings Plans comprometem com um gasto de dólar por hora em componentes elegíveis (Studio, treinamento, processamento, inferência em tempo real) por 1 ou 3 anos, gerando até 64% de desconto sobre os preços sob demanda. Eles são flexíveis entre famílias de instâncias, tamanhos, regiões e componentes — mas não cobrem Ground Truth, armazenamento ou transferência de dados. Use os Savings Plans quando o uso de ML de base for previsível; deixe o treinamento em rajadas (burst) em instâncias spot para acumular ainda mais economia.

Serviços de IA Gerenciados Versus ML Personalizado

O Amazon Rekognition (imagens/vídeo: detecção de objetos e cenas, análise facial, moderação), o Textract (OCR mais extração de formulários e tabelas) e o Comprehend (NLP: reconhecimento de entidades, análise de sentimento, detecção de PII, classificação personalizada) expõem modelos pré-treinados por meio de APIs simples. O DetectEntities do Comprehend retorna entidades tipadas, incluindo a categoria COMMERCIAL_ITEM — perfeito para extrair nomes de ingredientes de textos de receitas e alimentar uma consulta no DynamoDB, sem dados de treinamento, sem hospedagem e com preço por solicitação:

aws comprehend detect-entities \
    --language-code en \
    --text "Combine 2 cups flour, 1 tsp salt, and 3 eggs..."

O modo de falha comum é o excesso de engenharia (over-engineering) — iniciar trabalhos de treinamento do SageMaker, rotular dados com o Ground Truth e hospedar endpoints quando um serviço gerenciado já atende ao requisito por uma fração do custo operacional. O ML personalizado só se justifica quando a precisão em dados específicos do domínio é significativamente maior, quando os tipos de entidade necessários não correspondem ao esquema gerenciado (o Comprehend Custom Classification/Entity Recognition ainda é mais barato que o SageMaker puro) ou quando as restrições de latência e residência de dados exigem um modelo privado.

Armazenamento e Rede para HPC: FSx for Lustre e EFA

Cargas de trabalho de HPC fortemente acopladas — CFD, dinâmica molecular, imageamento sísmico, treinamento em larga escala — têm dois requisitos não negociáveis: comunicação entre nós com latência extremamente baixa e armazenamento compartilhado de alta vazão (throughput).

O Elastic Fabric Adapter (EFA) é uma interface de rede disponível em famílias específicas de EC2 (hpc7a, hpc6id, c6in, p4d/p5, entre outras). Ele ignora a pilha TCP/IP do kernel usando o Libfabric com OS-bypass, permitindo que o MPI e o NCCL atinjam latências de microssegundos em centenas de nós. O EFA exige que as instâncias estejam na mesma Zona de Disponibilidade e, para máxima largura de banda, em um grupo de posicionamento de cluster (cluster placement group).

O FSx for Lustre é um sistema de arquivos paralelo gerenciado que oferece centenas de GB/s de vazão e latência de submilisegundos. Ele se integra nativamente com o S3: um sistema de arquivos FSx pode ser vinculado a um bucket para que os objetos apareçam como arquivos POSIX, e os resultados gravados no Lustre podem ser exportados de volta para o S3. Implantações com SSD do tipo Persistente são adequadas para armazenamento temporário (scratch) de longa duração; o tipo Scratch2 é mais barato para dados de trabalho efêmeros.

O padrão incorreto é usar o EFS para HPC. O EFS é baseado em NFS, otimizado para muitos clientes pequenos fazendo E/S de arquivo de uso geral; ele não consegue sustentar a vazão agregada ou o IOPS de metadados que um trabalho MPI de 500 nós necessita, e seu design multi-AZ adiciona latência. Usar o ENA padrão em vez do EFA limita o MPI às latências do TCP, multiplicando várias vezes os tempos de execução com uso intensivo de allreduce. A combinação correta é usar instâncias habilitadas para EFA em um grupo de posicionamento de cluster montando o FSx for Lustre, com o S3 como armazenamento frio (cold storage) durável vinculado ao sistema de arquivos.

← Bancos de Dados e Caching · Todos os domínios · Integração de Aplicações →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →

Navegar Amazon →