Laboratório prático — AIF-C01 AWS Certified AI Practitioner

Visão geral

Pré-requisitos

Passos

1. 1.Selecionar nossa versão do Terraform e região da AWS

   Antes de criarmos qualquer recurso, precisamos informar ao Terraform qual versão dele mesmo esperamos usar e qual provedor da AWS utilizaremos. Fixamos o provedor da AWS em ~> 5.60 porque todos os recursos relacionados ao Bedrock abordados neste laboratório foram lançados nessa linha, e implantamos tudo em us-east-1 — a AWS lança os modelos de fundação lá primeiro, e a maioria das perguntas do AIF-C01 assume a disponibilidade em us-east-1 quando fazem referência ao serviço "mais recente".

   Insira isso em um arquivo main.tf novo para começar. Tudo o que se segue no laboratório ficará no mesmo arquivo.

   Copiar

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.60"
       }
     }
   }
   
   provider "aws" {
     region = "us-east-1"
   }

2. 2.Fornecer às soluções de IA um local para ler entradas e gravar saídas

   Provisiona:

   • Amazon S3

   Cada serviço de IA da AWS que usaremos neste laboratório — o Bedrock hoje e o log de auditoria que conectaremos no Passo 5 — lê entradas e grava saídas por meio do Amazon S3, portanto, a primeira parte da infraestrutura real é um bucket. Voltaremos a ele em quase todas as etapas posteriores.

   Ativamos o controle de versão para que um upload corrompido possa ser revertido, bloqueamos o acesso público (esses são dados de entrada para treinamento e logs de invocação de modelo, não ativos de site) e ativamos a criptografia AES256 em repouso. Esse último ponto é importante para o AIF-C01 — o domínio Security, Compliance, and Governance for AI Solutions testa explicitamente se você opta por criptografia em repouso por padrão em qualquer armazenamento de dados de IA.

   Copiar

   resource "aws_s3_bucket" "ai_data" {
     bucket_prefix = "certlabpro-aif-c01-"
   }
   
   resource "aws_s3_bucket_public_access_block" "ai_data" {
     bucket = aws_s3_bucket.ai_data.id
   
     block_public_acls       = true
     block_public_policy     = true
     ignore_public_acls      = true
     restrict_public_buckets = true
   }
   
   resource "aws_s3_bucket_versioning" "ai_data" {
     bucket = aws_s3_bucket.ai_data.id
   
     versioning_configuration {
       status = "Enabled"
     }
   }
   
   resource "aws_s3_bucket_server_side_encryption_configuration" "ai_data" {
     bucket = aws_s3_bucket.ai_data.id
   
     rule {
       apply_server_side_encryption_by_default {
         sse_algorithm = "AES256"
       }
     }
   }

3. 3.Permitir que o Bedrock assuma uma identidade para poder executar nossas chamadas

   Provisiona:

   • AWS IAM

   O Bedrock não pode invocar um modelo por conta própria — ele precisa de uma função do AWS IAM que possa assumir. Criamos uma com uma política de confiança que indica bedrock.amazonaws.com como o único principal permitido e, em seguida, anexamos uma política de permissões mínimas: invocar qualquer modelo de fundação e ler/gravar apenas no bucket que criamos no Passo 2.

   Padrões de privilégio mínimo como este são um tema recorrente do AIF-C01. Observe que não concedemos s3:* — apenas as duas ações de objeto de que realmente precisamos, com escopo restrito a objetos dentro do nosso bucket. O exame recompensa a identificação desse mesmo padrão em cenários de múltipla escolha: quando duas opções de resposta "funcionam", a mais restrita quase sempre é a correta.

   Copiar

   resource "aws_iam_role" "bedrock_caller" {
     name = "certlabpro-aif-c01-bedrock-caller"
   
     assume_role_policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Effect    = "Allow"
         Principal = { Service = "bedrock.amazonaws.com" }
         Action    = "sts:AssumeRole"
       }]
     })
   }
   
   resource "aws_iam_role_policy" "bedrock_caller" {
     name = "bedrock-invoke"
     role = aws_iam_role.bedrock_caller.id
   
     policy = jsonencode({
       Version = "2012-10-17"
       Statement = [
         {
           Effect = "Allow"
           Action = [
             "bedrock:InvokeModel",
             "bedrock:InvokeModelWithResponseStream",
           ]
           Resource = "arn:aws:bedrock:*::foundation-model/*"
         },
         {
           Effect = "Allow"
           Action = [
             "s3:GetObject",
             "s3:PutObject",
           ]
           Resource = "${aws_s3_bucket.ai_data.arn}/*"
         },
       ]
     })
   }

4. 4.Adicionar uma barreira de proteção para impedir o modelo de emitir PII ou tópicos proibidos

   Provisiona:

   • Amazon Bedrock Guardrails

   Um modelo do Bedrock sozinho responderá de bom grado a qualquer coisa que seus dados de treinamento permitirem. Os Guardrails atuam antes de cada chamada de modelo e aplicam políticas de conteúdo + PII independentemente de qual modelo de fundação você usa — o que significa que uma única barreira de proteção cobre Claude, Llama, Titan e qualquer modelo futuro.

   Aqui, configuramos duas camadas. Um filtro de conteúdo bloqueia discurso de ódio / violência / conteúdo sexual de alta gravidade tanto em prompts e em respostas, e uma política de informações confidenciais impede o vazamento de e-mails, números de telefone e números de Seguro Social dos EUA (SSN). Isso se mapeia diretamente ao domínio Guidelines for Responsible AI do AIF-C01 — a filtragem de conteúdo e o tratamento de PII são os dois pilares nomeados aqui.

   Com a barreira de proteção implementada, a função que criamos no Passo 3 pode invocar um modelo e o resultado é filtrado antes de chegar ao chamador.

   Copiar

   resource "aws_bedrock_guardrail" "safety" {
     name                      = "certlabpro-aif-c01-safety"
     description               = "Default safety rails for the lab."
     blocked_input_messaging   = "I can't help with that."
     blocked_outputs_messaging = "I can't share that response."
   
     content_policy_config {
       filters_config {
         input_strength  = "HIGH"
         output_strength = "HIGH"
         type            = "HATE"
       }
       filters_config {
         input_strength  = "HIGH"
         output_strength = "HIGH"
         type            = "VIOLENCE"
       }
       filters_config {
         input_strength  = "HIGH"
         output_strength = "HIGH"
         type            = "SEXUAL"
       }
     }
   
     sensitive_information_policy_config {
       pii_entities_config {
         action = "BLOCK"
         type   = "EMAIL"
       }
       pii_entities_config {
         action = "BLOCK"
         type   = "PHONE"
       }
       pii_entities_config {
         action = "BLOCK"
         type   = "US_SOCIAL_SECURITY_NUMBER"
       }
     }
   }

5. 5.Ativar os logs para ter uma trilha de auditoria de cada prompt e resposta

   Provisiona:

   • Amazon Bedrock
   • Amazon CloudWatch Logs
   • AWS IAM

   O log de invocação do Bedrock captura o prompt completo, a resposta e o payload de incorporação (embedding) de cada chamada de modelo na conta e região. Ele grava no CloudWatch Logs (bom para pesquisas ad-hoc com grep) e no Amazon S3 (bom para retenção de longo prazo) — conectamos ambos. A função que anexamos concede exatamente as ações de que o serviço do Bedrock precisa e nada mais.

   Um detalhe relevante para o AIF-C01 que vale a pena saber: o log de invocação é um singleton — uma configuração por conta e por região. Se você executar este laboratório uma segunda vez em us-east-1, o Terraform não relatará alterações, mas a configuração existente será vinculada novamente. Destrua antes de executar novamente se você alterar os destinos de log.

   Com os logs configurados, cada chamada de modelo que fazemos com a função do Passo 3, por meio do guardrail do Passo 4, acaba arquivada no bucket do Passo 2. Essa é a cadeia de auditoria completa — exatamente o tipo de cenário "mostre-me as evidências" que o exame espera que você saiba descrever.

   Copiar

   resource "aws_iam_role" "bedrock_logging" {
     name = "certlabpro-aif-c01-bedrock-logging"
   
     assume_role_policy = jsonencode({
       Version = "2012-10-17"
       Statement = [{
         Effect    = "Allow"
         Principal = { Service = "bedrock.amazonaws.com" }
         Action    = "sts:AssumeRole"
       }]
     })
   }
   
   resource "aws_cloudwatch_log_group" "bedrock_invocations" {
     name              = "/aws/bedrock/invocations"
     retention_in_days = 30
   }
   
   resource "aws_iam_role_policy" "bedrock_logging" {
     name = "write-logs-and-s3"
     role = aws_iam_role.bedrock_logging.id
   
     policy = jsonencode({
       Version = "2012-10-17"
       Statement = [
         {
           Effect = "Allow"
           Action = [
             "logs:CreateLogStream",
             "logs:PutLogEvents",
           ]
           Resource = aws_cloudwatch_log_group.bedrock_invocations.arn
         },
         {
           Effect   = "Allow"
           Action   = "s3:PutObject"
           Resource = "${aws_s3_bucket.ai_data.arn}/bedrock-invocations/*"
         },
       ]
     })
   }
   
   resource "aws_bedrock_model_invocation_logging_configuration" "this" {
     logging_config {
       embedding_data_delivery_enabled = true
       image_data_delivery_enabled     = true
       text_data_delivery_enabled      = true
   
       cloudwatch_config {
         log_group_name = aws_cloudwatch_log_group.bedrock_invocations.name
         role_arn       = aws_iam_role.bedrock_logging.arn
       }
   
       s3_config {
         bucket_name = aws_s3_bucket.ai_data.bucket
         key_prefix  = "bedrock-invocations/"
       }
     }
   }

Limpeza