MLOps e escalonamento na AWS

Um modelo que funciona em um notebook não é um sistema. No momento em que um segundo engenheiro precisa reproduzir a execução de treinamento, no momento em que o tráfego dobra às 09h, e no momento em que os dados de treinamento mudam de distribuição seis meses depois, você para de fazer machine learning e começa a fazer operações: e a AWS lhe dá duas famílias distintas de ferramentas para isso: uma camada de pipeline / registry / CI-CD que decide como um modelo chega à produção, e uma camada de escalonamento que decide quanta computação o serve. O exame AIF-C01 testa se você consegue nomear cada ferramenta com precisão, citar seus limites e recusar as opções que soam plausíveis, mas estão documentadas para outro serviço.

Ao final desta lição você será capaz de:

• posicionar uma prática de ML no modelo de maturidade de três níveis da AWS (0, 1, 2) e separá-lo das variantes Google, Azure e do blog da AWS do mesmo framework;
• ler um SageMaker Pipeline como um DAG JSON e dizer quais arestas carregam dados (properties) versus apenas ordenação (DependsOn);
• selecionar o tipo de etapa certo para uma tarefa, incluindo Condition, Fail, Callback, Lambda, ClarifyCheck e QualityCheck, e citar quantos tipos existem;
• configurar ParallelismConfiguration e cache de etapas (ExpireAfter em ISO 8601, apenas execuções bem-sucedidas) corretamente;
• dirigir o deployment através do Model Registry: numeração de versões, ModelApprovalStatus e as quatro transições de aprovação que iniciam (ou não) o CI/CD;
• construir ou adotar um SageMaker Project com CodePipeline / Jenkins, explicar por que os modelos de CodeCommit desapareceram em 28 de outubro de 2024 e nomear a tag CodeConnections e as ações IAM necessárias para GitHub;
• escolher entre Experiments (Studio Classic) e MLflow on SageMaker AI, e dizer onde os dados de rastreamento e os artefatos fisicamente vivem;
• configurar target tracking, step scaling e ações agendadas com o ServiceNamespace, ResourceId e ScalableDimension corretos, e fazer a aritmética de capacidade com divisão com arredondamento para cima;
• acordar um endpoint assíncrono a partir de zero com uma step policy mais um alarme HasBacklogWithoutCapacity;
• escolher a opção de inferência correta a partir do payload, latência, duração e requisitos do endpoint, e defender a escolha em termos de custo;
• ligar o flywheel de MLOps: Model Monitor → CloudWatch → EventBridge → StartPipelineExecution;
• defender o Veredito Comparativo: MLOps gerenciado vs scripts DIY vs operações manuais.

---

1. Maturidade de MLOps: nível 0, nível 1, nível 2

1.1 O padrão de três níveis da AWS

A AWS enquadra o MLOps como um modelo de maturidade de três níveis, e o exame espera que você reconheça o nível a partir de uma descrição e nomeie as ferramentas que levam até lá. A questão que distingue nunca é "quanto de ML você faz": é qual é o artefato implantado.

1.2 Onde isso aparece no exame

MLOps pertence ao Domínio 1, Tarefa 1.3 do guia AIF-C01. O exame em si é de 65 questões = 50 pontuadas + 15 não pontuadas, com sem penalidade por chute e pesos de domínio publicados de 20 / 24 / 28 / 14 / 14 %. A AWS publica apenas os pesos de domínio: a contagem de questões por tarefa não é publicada, então trate qualquer dimensionamento por tarefa que você leia em outro lugar como orientação, não como orçamento.

• 📚 Você sabia? As 15 questões não pontuadas de um exame AIF-C01 são indistinguíveis para você enquanto você faz o teste: elas estão intercaladas com as 50 pontuadas e são usadas para coletar estatísticas antes que um item seja qualquer vez pontuado. A consequência prática é um ponto de estratégia, não de curiosidade: nunca pule uma questão pensando "esta pode ser não pontuada". Cada questão consome o mesmo tempo, e apenas as 50 pontuadas decidem seu resultado, então o movimento racional é responder todas as 65 no máximo de sua capacidade.

---

2. SageMaker Pipelines: o contrato do DAG

2.1 O que é uma pipeline

Um SageMaker Pipeline é um grafo acíclico direcionado expresso em JSON. Cada nó é uma etapa, cada aresta é uma dependência, e ciclos são rejeitados, um DAG que dá laços não é uma pipeline mais lenta, é uma definição inválida. A definição segue o SageMaker AI Pipeline Definition JSON Schema, e ela pode ser produzida por quatro produtores equivalentes: o editor visual no Studio, o SageMaker SDK, boto3 e AWS CloudFormation. As execuções da pipeline são cobradas como os jobs subjacentes (processing, training, transform) mais o uso do Studio, a camada de orquestração em si não é um SKU separado e pesado.

Existem dois tipos de aresta, e confundi-los é o erro arquitetural mais comum nesta área:

A regra prática: se o valor flui, é uma referência properties; se apenas o timing importa, é DependsOn. ParallelismConfiguration não é um mecanismo de ordenação: ela limita quantas etapas já elegíveis rodam ao mesmo tempo.

2.2 O DAG da pipeline

Esta é a forma canônica que o exame descreve: pré-processar → treinar → avaliar → registrar apenas se a métrica passar, caso contrário falhar com uma mensagem.

2.3 Exemplo resolvido 1, o gate de MSE, ponta a ponta

Uma pipeline de regressão para um modelo tabular estilo abalone, construída com o SageMaker SDK:

1. Parâmetros são declarados uma vez e reutilizados em todo lugar: processing_instance_count, instance_type, model_approval_status (padrão PendingManualApproval), input_data, batch_data, mse_threshold.
2. Process produz as saídas train_data e test_data. A etapa de treinamento as consome com step_process.properties.ProcessingOutputConfig.Outputs["train_data"].S3Output.S3Uri: essa string é a aresta do DAG, não um comentário.
3. Eval é uma etapa Processing com property_files, então sua saída evaluation.json (contendo regression_metrics.mse) é exposta às etapas posteriores como uma propriedade estruturada, e não como um caminho no S3 que você precisa analisar sozinho.
4. MSECond é uma etapa Condition: if_steps = [RegisterModel], else_steps = [Fail]. A etapa Fail carrega uma mensagem composta como "MSE above threshold " + mse_threshold e termina a execução com status Failed: a execução não "termina com um aviso".
5. .start() a executa. Passar ModelApprovalStatus="Approved" como valor de parâmetro torna o registro imediatamente implantável (um atalho de desenvolvimento/teste), e CacheConfig(enable_caching=True, expire_after="PT1H") permite que etapas inalteradas reutilizem suas saídas anteriores.

---

3. Os 16 tipos de etapa, e os dois que decidem os resultados

3.1 O mapa completo de etapas

A AWS documenta 16 tipos de etapa. Aprenda a tabela pela coluna "gancho de exame": o exame raramente pergunta "o que uma etapa Training faz", ele pergunta qual etapa deve ser usada para X.

3.2 Condition e Fail como gate de avaliação

O padrão documentado é mecânico e vale a pena memorizar:

1. A etapa Processing de avaliação declara property_files=["evaluation.json"].
2. A etapa Condition lê evaluation.json e compara um escalar: por exemplo regression_metrics.mse contra o parâmetro da pipeline mse_threshold.
3. Ramificação true → Register model (opcionalmente precedida por Create model, e seguida por uma etapa Transform para uma passagem de sanidade em lote).
4. Ramificação false → Fail com um error_message composto via Join(...), produzindo um status de execução Failed.

Uma segunda variante, igualmente comum, coloca uma etapa QualityCheck ou ClarifyCheck antes do registro: a baseline é produzida com register_new_baseline=true e skip_check=true na primeira execução, e execuções posteriores comparam contra aquela baseline. Mesma forma: um gate cuja ramificação falsa é uma etapa Fail.

• 📚 Você sabia? A etapa Fail não é uma falha bruta: é uma interrupção controlada. A etapa em si conclui com sucesso o trabalho dela, e é a execução da pipeline que termina como Failed, com sua mensagem anexada. Essa distinção importa quando você constrói uma regra do EventBridge: você reage ao status da execução, não a uma exceção lançada no seu código Python, então uma etapa Fail lhe dá um sinal limpo e estável em schema que um exit 1 de script de shell não dá.

---

4. Paralelismo e cache: as duas alavancas que mudam o custo de execução

4.1 O paralelismo é por execução, não por pipeline

Etapas independentes rodam em paralelo por padrão: qualquer uma que esteja elegível roda. Você limita isso com ParallelismConfiguration(MaxParallelExecutionSteps). Duas propriedades desta configuração importam para o exame:

• ela se aplica por execução: o exemplo documentado de 50 significa que uma execução roda no máximo 50 etapas concorrentemente, e duas execuções concorrentes podem portanto rodar 100 etapas ao mesmo tempo;
• ela pode ser sobrescrita no start, no retry e na atualização, então é um padrão de política, não uma propriedade imutável da pipeline.

Paralelismo não é um mecanismo de dependência. Definir MaxParallelExecutionSteps = 2 não faz a etapa B esperar a etapa A; apenas limita quantas etapas prontas executam simultaneamente.

4.2 O cache é opt-in, ISO 8601 e apenas para execuções bem-sucedidas

O uso prático é um loop de desenvolvimento: você reexecuta uma pipeline de cinco etapas após tocar apenas no relatório, e PT1H deixa Process, Train e Eval devolverem seus artefatos anteriores em segundos enquanto a etapa alterada executa de verdade.

---

5. Model Registry: versões e a aprovação que direciona o deploy

5.1 Estrutura do registry

O registry organiza modelos em model groups, e um grupo contém pacotes/versões. As versões são simples e estritamente ordenadas: elas começam em 1 e incrementam em 1 para cada pacote adicionado ao grupo. Um pacote versionado precisa pertencer a um grupo, e seu ARN carrega as coordenadas: …:model-package-group/name/version.

5.2 ModelApprovalStatus

Cada model package carrega um status extraído de exatamente três valores:

Um modelo versionado precisa estar Approved para ser implantado. O status pode ser definido através de update_model_package, através do Studio, através de uma etapa Condition dentro de uma pipeline, ou passado como um parâmetro da pipeline cujo padrão é PendingManualApproval.

5.3 As quatro transições de aprovação

Esta é a tabela de maior rendimento da lição, porque o exame pergunta "qual ação inicia o deployment?":

5.4 Exemplo resolvido 2: da aprovação à produção

1. Um SageMaker Project é criado a partir do template "Model building, training, and deployment with third-party Git repositories using CodePipeline", com dois repositórios GitHub e um ARN do CodeConnections com a tag sagemaker=true.
2. Um commit no repositório de modelagem dispara a ação de fonte (DetectChanges), que executa source → build: o CodeBuild cria ou atualiza o SageMaker Pipeline e o inicia.
3. A pipeline registra a versão 7 com ModelApprovalStatus = PendingManualApproval.
4. Um revisor vira a v7 para Approved (Studio, CLI ou uma etapa Condition alimentada por um parâmetro de aprovação).
5. A regra EventBridge do template inicia a pipeline de deploy: source → build → deploy-staging (stack do CloudFormation) → aprovação manual → deploy-prod.
6. Se o staging revelar um defeito e a v7 for virada de Approved → Rejected, o pacote ainda Approved mais recente é reimplantado: esse é o rollback documentado. Em um loop puro de dev/teste, você contorna as etapas 4 to 5 passando ModelApprovalStatus="Approved" como parâmetro da pipeline.

---

6. SageMaker Projects, Git e CI/CD

6.1 O que um Project realmente é

SageMaker Projects são produtos do AWS Service Catalog suportados por CloudFormation. Criar um provisiona, como uma unidade única: repositórios Git, um SageMaker Pipeline, CodePipeline ou Jenkins, um model group, um bucket S3, um registry ECR e regras do EventBridge. Existem duas formas canônicas:

As famílias de template fornecidas cobrem build/train/deploy com Git de terceiros (CodePipeline ou Jenkins), Model Monitor e construção de imagens (ECR + CodeBuild + EventBridge).

6.2 A mudança de CodeCommit de 28 de outubro de 2024

A mecânica da ação de fonte do GitHub vale a pena citar com precisão:

• a ação do CodePipeline é CodeStarSourceConnection;

• a conexão deve ser uma conexão CodeConnections com a tag sagemaker=true;

• o role da pipeline precisa de ambas codestar-connections:UseConnection e codeconnections:UseConnection;

• a detecção de mudanças é DetectChanges no commit, então o build começa sem um gatilho manual;

• o CloudFormation de um template personalizado deve declarar SageMakerProjectName e SageMakerProjectId.

• 📚 Você sabia? "CodeStar" sobrevive no nome da ação (CodeStarSourceConnection) muito tempo depois que o produto foi substituído pelo CodeConnections. É por isso que a política IAM precisa de duas ações quase idênticas: uma para o namespace legado e uma para o serviço atual. Candidatos que memorizam apenas uma das duas consistentemente falham neste item, e os próprios walkthroughs da AWS listam ambas.

---

7. Experiments e MLflow: onde o rastreamento de execuções vive hoje

7.1 A migração

A API SageMaker Experiments, CreateExperiment, Trials como grupos de execução, trial components como execuções individuais, é documentada como disponível apenas no Studio Classic. Para a nova experiência do Studio, a AWS recomenda MLflow on SageMaker AI. Em termos de exame: uma opção que descreve Trials e trial components como a maneira atual e recomendada de rastrear execuções está descrevendo uma superfície legada.

A divisão é o ponto do exame: a computação e o backend store rodam na conta de serviço do SageMaker, mas os artefatos vivem em um S3 que você possui e paga: que é exatamente o que um revisor de conformidade quer ouvir sobre reprodutibilidade.

---

8. Auto scaling de endpoints: target tracking, step scaling, ações agendadas

8.1 Os identificadores

O escalonamento de endpoints roda através do Application Auto Scaling (RegisterScalableTarget mais PutScalingPolicy) ou através do assistente do console. Cite as coordenadas com exatidão:

A AWS oferece três estratégias, target tracking (recomendado), step scaling e ações agendadas (CLI/API), e, para o target tracking, a AWS gerencia os alarmes para você.

8.2 As métricas

8.3 Exemplo resolvido 3: aritmética de capacidade do target tracking

A capacidade sempre arredonda para cima: esse é o comportamento de ajuste documentado, e é aritmética examinável:

1. Teste de carga mostra 210 invocações/min, alvo 70 → 210 / 70 = 3 instâncias.
2. O tráfego sobe para 351/min → 351 / 70 = 5,01, arredondado para cima → 6 instâncias (nunca 5).
3. Registre o destino: register_scalable_target(ServiceNamespace="sagemaker", ResourceId="endpoint/prod/variant/AllTraffic", ScalableDimension="sagemaker:variant:DesiredInstanceCount", MinCapacity=1, MaxCapacity=10).
4. Anexe a política: put_scaling_policy(PolicyType="TargetTrackingScaling", {"TargetValue": 70.0, "PredefinedMetricSpecification": {"PredefinedMetricType": "SageMakerVariantInvocationsPerInstance"}, "ScaleInCooldown": 600, "ScaleOutCooldown": 300}).
5. Efeito: scale-out dentro de cerca de um minuto; o cooldown de scale-in de 600 s suprime o flapping após um burst, e o cooldown de scale-out de 300 s evita over-provisioning durante um trem de picos.

8.4 Exemplo resolvido 4: aritmética de concorrência em alta resolução

1. Com ConcurrentRequestsPerModelHighResolution no alvo 5, uma carga de 18 requisições concorrentes → 18 / 5 = 3,6, arredondado para cima → 4 instâncias.
2. A métrica emite a cada 10 segundos em vez de a cada 1 minuto: detecção ~6× mais rápida para o scale-out; o timing de scale-in não muda.
3. Usando inference components? A métrica vira InferenceComponentConcurrentRequestsPerCopyHighResolution.
4. Múltiplas políticas de target tracking podem compartilhar um único destino escalável: adicione uma segunda política em CPUUtilization com TargetValue = 50, e ambas mantêm seus próprios alvos contra o mesmo DesiredInstanceCount.

8.5 A comparação das estratégias de escalonamento

---

9. Inferência assíncrona: escalonamento a partir de zero

9.1 Por que a assíncrona é especial

Endpoints assíncronos têm uma fila na frente deles, o que significa que o backlog, não a taxa de requisições, é o sinal que importa. A AWS documenta estas métricas de fila:

9.2 O design de escalonamento a partir de zero

9.3 Exemplo resolvido 5: aritmética da fila e o despertar

1. Configure MinCapacity=0, MaxCapacity=5 e uma política de target tracking em ApproximateBacklogSizePerInstance com TargetValue = 5.
2. Um burst enfileira 27 requisições em 1 instância em execução → 27 / 5 = 5,4, arredondado para cima → 6 → limitado a MaxCapacity = 5.
3. O tráfego para; o scale-in devolve o endpoint a 0 instâncias e o gasto ocioso vai a zero. Requisições que chegam nesse meio-tempo são enfileiradas, não perdidas: ApproximateAgeOfOldestRequest reporta há quanto tempo a mais antiga espera.
4. A próxima requisição após o idle: HasBacklogWithoutCapacity vira para 1, mantém por 2 períodos de avaliação de 60 s, dispara o alarme, a step policy adiciona +1 instância após o cooldown de 300 s, e o target tracking retoma.

---

10. Escolhendo a opção de inferência

10.1 As quatro opções e seus limites rígidos

Específicos do batch transform: MaxPayloadInMB no máximo 100, e MaxConcurrentTransforms × MaxPayloadInMB no máximo 100 MB.

Exclusões do serverless (memorize a lista): sem GPUs; sem imagens de Marketplace ou de registry privado; sem multi-model endpoints; sem configuração de VPC; sem data capture; sem Model Monitor; sem múltiplas variantes; sem inference pipelines; imagem do container no máximo 10 GB; converter um endpoint real-time existente para serverless é rejeitado; Provisioned Concurrency é opcional.

10.2 A decisão

10.3 Exemplo resolvido 6: 40 GB, toda noite, sem usuários

Uma equipe de fraude pede "um endpoint real-time para o nosso job de pontuação noturno de 40 GB". A resposta correta é batch transform:

1. Sem tráfego interativo → a única vantagem do real-time (latência) não tem valor, e sua forma de custo, pagar por instâncias provisionadas incluindo horas ociosas, é desperdício puro para um job que roda uma vez por dia.
2. 40 GB passa do teto de 4 MB do serverless e do teto de 1 GB do assíncrono; é território firme de "dados na escala de GB ao longo de dias".
3. O batch transform roda instâncias apenas para o job: MaxPayloadInMB ≤ 100 e MaxConcurrentTransforms × MaxPayloadInMB ≤ 100 MB mantêm cada requisição dentro dos limites, S3Output coleta os registros pontuados, e nenhum endpoint existe entre execuções: então nada é cobrado às 03h.
4. O monitoramento usa BatchTransformInput em vez do Model Monitor; se a equipe mais tarde quiser detecção de drift, essa é uma decisão separada sobre um endpoint real-time ou assíncrono.

• 📚 Você sabia? A orientação de otimização de custos da AWS para inferência se resume a uma frase: combine a opção com a forma do tráfego. A assíncrona é dimensionada para uma taxa de processamento ótima mais escala para zero; o serverless é por requisição; o real-time é capacidade provisionada; e em todas elas SageMaker Savings Plans podem ser comprados por 1 ou 3 anos e se aplicam sobre Studio, processing, training, inferência real-time e batch transform. Comprar um Savings Plan para um job que roda 20 minutos por noite é o desalinhamento clássico: o plano desconta uso comprometido, e um lote noturno quase não tem.

---

11. EventBridge e o flywheel de MLOps

11.1 O que a AWS envia, e para quê

O SageMaker emite eventos para o EventBridge em quase tempo real para jobs, endpoints, model packages, execuções e etapas de pipeline, e mudanças de imagem. Os alvos incluem Lambda, Step Functions, Kinesis e SNS: e, criticamente, o próprio SageMaker Pipelines é um alvo:

11.2 O flywheel

11.3 Exemplo resolvido 7: monitorar, alarmar, retreinar, aprovar, implantar

1. Habilite data capture no endpoint de produção para que requisições e respostas aterrissem no S3, e agende o Model Monitor de hora em hora (CronExpressionGenerator.hourly()).
2. Produza a baseline com uma etapa QualityCheck usando register_new_baseline=true e skip_check=true na primeira execução; execuções posteriores comparam contra ela.
3. Quando o drift exceder a restrição, o alarme do CloudWatch entra em ALARM → a regra EventBridge dispara → alvo = SageMaker Pipeline, invocando StartPipelineExecution com um SageMakerPipelineParameter mapeado.
4. A pipeline retreina, avalia, passa pela etapa Condition, registra uma nova versão como PendingManualApproval → a aprovação a vira para Approved → a regra do template de deploy atualiza o endpoint.
5. Execute o gatilho de calendário ao lado do gatilho de drift: cron(0 12 1 * ? *) retreina no dia 1 de cada mês às 12:00 UTC, ou use PipelineSchedule(name, cron="15 10 ? * 6L 2022-2023") para um agendamento com limite de tempo. Lembre-se de no máximo 5 alvos por regra e de nenhum agendamento em buses de eventos custom ou de parceiros.

11.4 Infrastructure as code para a stack inteira

Tudo nesta lição é descritível como código, e a orientação da AWS aponta para o CloudFormation diretamente ou através do AWS CDK: cdk synth emite um template do CloudFormation por stack, e os constructs L1 Cfn* cobrem a superfície: sagemaker.CfnEndpointConfig (incluindo AsyncInferenceConfig), sagemaker.CfnPipeline, mais os nativos AWS:SageMaker:Domain, AWS:SageMaker:UserProfile e AWS:SageMaker:Pipeline.

Codifique, no mínimo: VPC, KMS, o bucket S3, o role de execução da pipeline, o Model Package Group, CodePipeline + CodeBuild + CodeConnections, regras do EventBridge e o destino escalável com suas políticas. Para templates de projeto, a AWS prefere templates hospedados no S3 via CfnTemplateProvider a portfólios do Service Catalog, e um template personalizado deve expor SageMakerProjectName e SageMakerProjectId. Dividir a stack em DevStack e ProdStack permite testar a infraestrutura com unit tests antes que ela toque a produção.

11.5 Atualizações de 2026 (em outubro de 2026)

Três mudanças verificadas de 2025 to 2026 tocam o material das seções 8 até 13, e a AWS agora as anuncia através de vocabulário de ciclo de vida em vez de aposentadorias silenciosas. Todas as três são documentadas, datadas e examináveis.

1. O nome do produto mudou. A AWS documenta que "o Amazon SageMaker atual foi renomeado para Amazon SageMaker AI" (3 de dezembro de 2024), ao lado de uma geração separada de next-generation SageMaker (Unified Studio, Catalog, Lakehouse, zero-ETL). Uma opção de exame dizendo SageMaker AI é atual, não exótica: e os identificadores que você cita da seção 8 não mudaram com a renomeação: ServiceNamespace = sagemaker, ResourceId = endpoint/…/variant/…, SageMakerVariantInvocationsPerInstance e a ação do role SageMaker:StartPipelineExecution ainda são todos escritos do jeito antigo.

2. Model Monitor e Clarify estão em manutenção. O SageMaker AI End of Support Notice lista Model Monitor e Clarify: junto com Ground Truth, A2I, Studio Lab, Debugger, Role Manager, Geospatial e Mechanical Turk: como "não mais aberto a novos clientes a partir de 30 de julho de 2026". Leia essa frase com precisão: o status é manutenção = nenhum cliente novo, nenhum recurso novo, clientes existentes continuam usando-os. Não é um desligamento completo, e não é um rebranding para Bedrock Model Evaluations. O flywheel de drift de 11.2 portanto ainda roda para clientes existentes; para trabalho novo a AWS aponta para métricas e anomaly detection do CloudWatch, CloudWatch Evidently, EventBridge + Lambda, SHAP e, no lado generativo, Bedrock Model Evaluations: que é exatamente por que o exemplo 4.2.2 do guia do exame agora lê "Clarify plus Bedrock Model Evaluations".

3. O guia do exame mudou. O histórico de mudanças da AWS lista v1.0 publicada em 26 de março de 2026 e v1.1 publicada em 30 de abril de 2026, e afirma que atualizações aparecem no exame cerca de um mês após a publicação (trate a v1.1 como a âncora confiável; a data da v1.0 é uma republicação de documentação). Exemplos alterados que tocam esta lição: 1.1.3 (inferência assíncrona e serverless), 1.3.4 (Bedrock, Amazon Quick, Kiro, SageMaker AI) e 4.2.2 (Clarify mais Bedrock Model Evaluations). Inalterados, e portanto seguros de continuar citando: 65 questões (50 pontuadas + 15 não pontuadas), 90 minutos, aprovação 700 / 1.000, validade de 3 anos, domínios 20 / 24 / 28 / 14 / 14 %.

Vocabulário de ciclo de vida (AWS General Reference): Maintenance = nenhum cliente novo, nenhum recurso novo, ainda suportado · Sunset = fim de operações planejado, tipicamente cerca de 12 meses · Full Shutdown = removido do portfólio.

• 📚 Você sabia? A AWS afirma que mudanças no guia do exame aparecem no exame no ar cerca de um mês após a publicação: então o material da v1.1 (30 de abril de 2026) era examinável a partir de finais de maio de 2026. O corolário corre nas duas direções: um recurso anunciado depois da versão do seu guia não é automaticamente testável, enquanto um exemplo alterado como 4.2.2 → Clarify mais Bedrock Model Evaluations é testável muito antes de qualquer data de aposentadoria importar. Leia o histórico de mudanças, não o blog de release.

---

12. Veredito comparativo: MLOps gerenciado vs scripts DIY vs manual

---

13. Armadilhas do exame e os números que valem a pena memorizar

Sinalizado como não verificado nesta lição (não os afirme no exame): a frase "requisições por destino" como ela aparece em alguns dumps de estudo, ela mapeia para o ALBRequestCountPerTarget genérico, que não é documentado para endpoints SageMaker, então trate-a como InvocationsPerInstance, a menos que haja um ALB na arquitetura; a contagem exata de templates de projeto fornecidos (a AWS enumera famílias, não uma lista numerada); o roadmap de multi-model endpoint (docs vivos e não descontinuados em outubro de 2026, mas sem página de roadmap pública); o peso das questões de MLOps especificamente (apenas pesos de domínio são publicados); qualquer data de fim de suporte do Experiments no Studio Classic; preços do servidor MLflow; os tamanhos de memória e concorrência máxima de endpoints serverless; quotas de endpoint (instâncias por variante, variantes por endpoint); o padrão numérico de MaxParallelExecutionSteps (docs mostram como defini-lo, exemplo 50, mas não publicam um padrão); e GitHub Actions como resposta de exame, ele aparece apenas em um blog e em um template personalizado de aws-samples, enquanto as respostas seguras são CodePipeline / CodeBuild e Jenkins.

• 📚 Você sabia? A etapa Lambda do SageMaker tem um timeout padrão de 2 minutos e permite até 10 minutos: um teto deliberadamente pequeno, porque a etapa existe para trabalho de orquestração leve (virar uma aprovação, chamar uma API, mover um arquivo), não para rodar um job de treinamento. Se a sua "etapa" precisa de uma hora, é uma etapa Processing fantasiada.

---

14. Casos Reais

A AWS publica histórias de clientes porque cada uma é uma versão documentada de uma decisão que esta lição ensinou no abstrato. Os cinco abaixo são os casos relevantes para MLOps, pipelines e inferência, citados com os serviços AWS exatos, os números exatos impressos e a página de origem: uma porcentagem sem origem é marketing, e uma porcentagem sem "antes" é pior.

14.1 Forethought: inferência é uma decisão de pipeline com uma conta anexada

• Serviços: multi-model endpoints do SageMaker, Serverless Inference e Model Deployment, substituindo um Amazon EKS auto-gerenciado.
• Números: −66% no custo de inferência com multi-model endpoints e melhor latência; ≈ −80% no Serverless Inference (manchete de até −80%); mais de 80% da inferência de GPU agora roda no SageMaker; 30 M de interações/ano; uma equipe de 3 pessoas que já não conseguia rodar os modelos e o Kubernetes (exceções de memória, indisponibilidades).
• Origem: aws.amazon.com/solutions/case-studies/forethought-technologies-case-study (a página não traz chip de ano: trate a data como não declarada).
• Ângulo de exame: esta é a seção 10 com uma fatura anexada. Capacidade de GPU compartilhada → multi-model endpoints; classificadores pequenos e esporádicos → serverless. O custo que eles apagaram foi o imposto de serving DIY: a coluna "scripts DIY" do Veredito Comparativo, aplicada à inferência em vez de ao CI/CD.

14.2 HAYAT HOLDING: treinamento e tuning gerenciados em vez de ambientes construídos à mão

• Serviços: AWS IoT Greengrass (SiteWise Edge Gateway) → SageMaker Model Training + Automatic Model Tuning + Model Deployment, com o SageMaker Edge Manager servindo o modelo no dispositivo.
• Números: 194 sensores transmitidos via OPC-UA; ambientes de ML auto-construídos eram "demorados e complicados"; resultado documentado de US$ 300.000 por ano economizados mais qualidade de painel maior.
• Origem: aws.amazon.com/blogs/machine-learning/hayat-holding-uses-amazon-sagemaker-to-increase-product-quality-and-optimize-manufacturing-output-saving-300000-annually (2023).
• Ângulo de exame: esta é maturidade de Nível 1 em uma fábrica: uma pipeline automatizada do sensor ao modelo ajustado, com o Automatic Model Tuning substituindo a varredura manual de hiperparâmetros em 194 entradas e o Edge Manager dono do caminho de deployment no dispositivo.

14.3 RareJob: treinamento spot resolveu um problema de fila, não de modelo

• Serviços: treinamento SageMaker em managed spot, alimentado por AWS Glue e Amazon Athena, substituindo um PC local e depois uma configuração EC2/ECS com gargalo.
• Números: −25% no tempo de treinamento, mais de 10× de eficiência de desenvolvimento, 100 horas por mês economizadas, resultados de pontuação em 2 to 3 minutos; um modelo por desenvolvedor era o teto antes da mudança.
• Origem: aws.amazon.com/solutions/case-studies/rare-job-case-study (2020).
• Ângulo de exame: o gargalo era o throughput de experimentos, não a precisão. Jobs de spot paralelos são a alavancagem de custo documentada para treinamento: e a mesma lógica de "pagar por capacidade interrompida com desconto" que torna um Savings Plan ou estratégia de spot uma resposta do Domínio 4 (custo).

14.4 Chronomics: quatro meses de DIY contra três semanas de AutoML gerenciado

• Serviços: Amazon Rekognition Custom Labels (AutoML), pontuado com DetectCustomLabels.
• Números: 4 meses de visão computacional custom in-house nunca atingiram a meta; Custom Labels entregue em 3 to 4 semanas com 96,5% de precisão / F1 de 97,9%. Elevar o limiar de confiança para 0,99 dá 99,6% de precisão enquanto descarta 5% das previsões; 0,999 dá 99,87% enquanto descarta 27%.
• Origem: aws.amazon.com/blogs/machine-learning/chronomics-detects-covid-19-test-results-with-amazon-rekognition-custom-labels (2022).
• Ângulo de exame: duas lições. Primeiro, para uma tarefa de visão estreita, o nível gerenciado supera uma construção in-house: o padrão de falha documentado é CV DIY. Segundo, cada limiar que você eleva cria uma cauda descartada que precisa de um caminho humano (a razão pela qual o A2I existe), então uma questão de precisão é sempre também uma questão de cobertura.

14.5 Sun Finance: uma pipeline multi-etapas cujo primeiro protótipo foi rejeitado

• Serviços: Amazon Textract (OCR) → Amazon Rekognition (fallback e checagens de rosto) → Claude Sonnet 4 (apenas estruturamento) → regras de validação → Amazon Titan Multimodal Embeddings em S3 Vectors para similaridade de fraude; construído com o AWS Generative AI Innovation Center, avaliado em 585 imagens.
• Números: precisão 79,73% → 90,80% (número de ID 74,32 → 89,40%, tipo de documento 78,43 → 96,40%), −91% no custo por documento, 20 horas → menos de 5 segundos, detecção de fraude 81%. Tentativa 1, apenas Claude Sonnet 4, pontuou 61,8% no geral e 43% no número de ID e foi rejeitada.
• Origem: aws.amazon.com/blogs/machine-learning/sun-finance-automates-id-extraction-and-fraud-detection-with-generative-ai-on-aws (2026).
• Ângulo de exame: esta é uma mentalidade de etapa Condition em forma de produção: construa a baseline, meça, rejeite a tentativa que falha, re-arquitete (separe OCR de raciocínio), meça novamente. Avaliação é uma fase, não uma caixa de seleção: e a extração de PII só com LLM é o protótipo falhado documentado.

Tabela 14-A: Antes / depois, exatamente como a AWS imprimiu

Tabela 14-B: Escolhendo o nível: pré-construído → custom gerenciado → generativo

• 📚 Você sabia? A AWS publica exatamente um número de taxa de produção para o próprio trabalho de IA generativa: 65% dos projetos do Generative AI Innovation Center chegaram à produção em 2025, de mais de 1.000 implementações, com o mais rápido em 45 dias: e a AWS enquadra o método como os Cinco Vs: Value → Visualize → Validate → Verify → Venture. O número que vale a pena internalizar é os outros 35%: a AWS espera que você planeje para projetos que estagnam, e é por isso que baseline antes de construir e avaliação como fase aparecem em cada caso acima.

---

Perguntas de Prática (Practice Questions)

---