Introdução

Uma foundation em Oracle Cloud Infrastructure (OCI) é o conjunto de decisões, padrões e controles que prepara a nuvem para receber workloads com segurança, previsibilidade e capacidade de operação. Este guia percorre os componentes essenciais dessa base: regiões, compartments, IAM, rede, segurança, observabilidade, custos e infraestrutura como código de forma progressiva, com exemplos práticos e linguagem acessível. O objetivo não é criar uma arquitetura única para todos os cenários, mas oferecer um ponto de partida consistente, capaz de reduzir improvisos no provisionamento e facilitar a evolução do ambiente do nível inicial ao intermediário.

Neste post, vamos apresentar uma visão prática de como estruturar uma Foundation OCI para criar uma base segura, escalável e governada desde o início, com boas práticas para reduzir riscos e dar mais previsibilidade à evolução do ambiente.

1 – INTRODUÇÃO: O QUE É UMA FOUNDATION OCI?

Pense na foundation como a infraestrutura invisível que torna cada novo projeto mais fácil de entregar. Antes de uma máquina virtual, um banco ou um cluster ser criado, a organização precisa decidir onde o recurso ficará, quem poderá administrá-lo, como o tráfego será controlado, quais logs serão coletados, como o custo será atribuído e de que forma a configuração poderá ser reproduzida. Quando essas decisões são tomadas apenas durante cada implantação, surgem exceções, retrabalho e permissões amplas demais.

Na documentação da Oracle, uma landing zone reúne recursos e práticas de identidade, rede, segurança, monitoramento e governança para acelerar a adoção da OCI. Neste texto, o termo foundation é usado em sentido prático: a base mínima e evolutiva sobre a qual landing zones e workloads podem ser construídos. Ela não é um produto isolado nem um diagrama imutável; é um sistema de guardrails, automação e responsabilidades.

Uma boa foundation permite provisionar rápido sem abrir mão de segurança, rastreabilidade, recuperação e controle de custos.

2 – DECISÕES ANTES DO PRIMEIRO RECURSO

A qualidade do provisionamento começa antes do console. Para cada workload, registre um pequeno conjunto de decisões: owner técnico, owner de negócio, ambiente, criticidade, classificação dos dados, dependências externas, conectividade, expectativa de custo, janela de manutenção e objetivos de recuperação. Esse registro pode ser uma ficha de arquitetura simples; o importante é que ele exista e acompanhe o recurso durante todo o ciclo de vida.

2.1 Região, Availability Domains e Fault Domains

Uma região OCI é uma área geográfica localizada e pode conter um ou mais Availability Domains (ADs). Dentro de um AD, Fault Domains (FDs) oferecem isolamento lógico de hardware para reduzir o impacto de falhas e manutenções. A escolha da região deve considerar residência de dados, latência para usuários e sistemas integrados, disponibilidade dos serviços necessários, conectividade com o ambiente corporativo e estratégia de continuidade.

• Valide o catálogo regional antes de fechar a arquitetura.
• Distribua instâncias redundantes entre Fault Domains quando o serviço e a região permitirem, evitando concentrar uma aplicação inteira no mesmo domínio de falha.
• Defina RTO e RPO.
• RTO é o tempo máximo aceitável para restabelecer o serviço.
• RPO é a perda máxima de dados tolerável medida no tempo.
•  
• Quando a continuidade exigir outra região, planeje também replicação, DNS, chaves, limites, runbook de failover e teste periódico; criar recursos “de reserva” sem ensaio não constitui uma estratégia de recuperação.

2.2 Perguntas que evitam retrabalho

3 – GOVERNANÇA E IDENTIDADE: ORGANIZAR ANTES DE PERMITIR

3.1 Compartments como fronteiras operacionais

Compartments organizam recursos e servem de escopo para políticas, quotas e relatórios. Eles são lógicos e podem conter recursos de diferentes regiões. Um desenho inicial simples costuma funcionar melhor que uma árvore muito profunda: mantenha o root compartment para administração da tenancy e crie áreas separadas para segurança, rede, serviços compartilhados e workloads. Dentro de workloads, separe desenvolvimento, homologação e produção quando houver diferenças reais de acesso, risco ou custo.

Boa prática – evite criar workloads comuns diretamente no root compartment. O root deve concentrar somente o que precisa existir no nível da tenancy e políticas cuidadosamente revisadas.

3.2 Nomes, defined tags e quotas

Nomes ajudam pessoas; tags sustentam automação e governança. Prefira defined tags, porque elas utilizam namespaces e chaves controladas, ao contrário de free-form tags. Tag defaults podem aplicar valores automaticamente quando um recurso é criado. Um conjunto enxuto evita campos abandonados: Environment, Owner, CostCenter, Application, DataClassification e ManagedBy normalmente cobrem os primeiros casos de uso.

Quotas de recursos podem limitar o consumo em compartments e ajudam a impedir que um ambiente de testes utilize toda a capacidade disponível na tenancy. Elas não substituem service limits: antes de uma implantação grande, verifique limites atuais, solicite aumentos com antecedência e valide novamente na região de destino.

Governança com compartments, tags, quotas e budgets

3.3 IAM: pessoas, grupos e workloads

A identidade começa nos identity domains, que organizam usuários, grupos, aplicações e configurações de autenticação. Para acesso humano, conceda permissões a grupos, não diretamente a usuários; habilite autenticação multifator (MFA), integre federação quando aplicável e mantenha contas de emergência com processo de uso e auditoria. A política deve refletir a função: quem administra rede não precisa, por padrão, administrar bancos ou segurança.

A sintaxe mental de uma política OCI é: permitir a um sujeito executar um verbo sobre um tipo de recurso em um local. Os verbos inspect, read, use e manage aumentam progressivamente a capacidade, mas o efeito exato depende do resource-type. Comece pelo menor nível funcional, teste em um compartment de desenvolvimento e revise políticas amplas como “manage all-resources”.

Exemplo 1 – Políticas IAM ilustrativas

Allow group grp-network-admins to manage virtual-network-family in compartment cmp-network
Allow group grp-auditors to read instance-family in compartment cmp-app-dev
Allow group grp-compute-operators to use instance-family in compartment cmp-app-dev
Allow group grp-security-reviewers to inspect virtual-network-family in compartment cmp-network

Adapte nomes e escopo à hierarquia real. Dependendo do fluxo, permissões adicionais podem ser necessárias para imagens, volumes, chaves ou outros recursos.

Para workloads, dynamic groups permitem agrupar instâncias ou outros recursos por regras, e políticas podem autorizar esse grupo a chamar serviços OCI sem distribuir credenciais de usuário. Esse padrão, conhecido como instance principals em Compute, é preferível a armazenar chaves de API dentro da aplicação.

Exemplo 2 – Regra de dynamic group e política

ALL {instance.compartment.id = 'ocid1.compartment.oc1..exemplo'}

Allow dynamic-group dg-app-dev to read objects in compartment cmp-app-dev

Use OCIDs e resource-types corretos do ambiente. O exemplo demonstra o padrão, não uma política pronta para produção.

Fluxos de identidade e acesso para pessoas e workloads

4 – REDE OCI: CONECTIVIDADE EXPLÍCITA E MENOR EXPOSIÇÃO

A Virtual Cloud Network (VCN) é a rede virtual definida por software da OCI. O planejamento deve começar pelo endereço CIDR, considerando crescimento e evitando sobreposição com redes on-premises, outras VCNs e parceiros. Corrigir sobreposição depois da implantação costuma ser caro; mantenha um registro corporativo de endereços e reserve blocos por região ou domínio.

4.1 Subnets, rotas e o que realmente torna uma rede pública

Uma subnet não se torna pública apenas pelo nome. A exposição depende da tabela de rotas, da existência de gateway apropriado, da atribuição de endereço público ao recurso e das regras de segurança. Para uma aplicação web tradicional, mantenha o load balancer na camada pública e as instâncias de aplicação e dados em subnets privadas, sem IP público.

• Internet Gateway: caminho para comunicação com a internet quando rota, endereço público e regras permitirem.
• NAT Gateway: permite que recursos privados iniciem conexões de saída para a internet sem aceitar conexões iniciadas da internet.
• Service Gateway: fornece acesso privado a serviços Oracle suportados, como Object Storage, sem atravessar a internet pública.
• Dynamic Routing Gateway (DRG): ponto de conexão para redes on-premises, FastConnect, VPN e topologias entre redes; trate propagação e segmentação de rotas como parte do desenho.
• OCI Bastion: oferece sessões temporárias e gerenciadas para alvos privados, reduzindo a necessidade de jump servers permanentes.
•  

Segmentação e conectividade de uma VCN

4.2 NSG ou Security List?

Network Security Groups (NSGs) associam regras a VNICs ou recursos suportados e começam vazios. Security Lists aplicam regras a todas as VNICs de uma subnet. Para workloads, NSGs normalmente dão granularidade melhor e permitem expressar fluxos entre grupos, como “load balancer para aplicação”, sem depender de endereços IP. Security Lists podem permanecer como baseline de subnet, desde que sejam mínimas e intencionais.

4.3 Exemplo de arquitetura em três camadas

Aplicação OCI em três camadas

No exemplo, o tráfego de usuário chega ao load balancer por HTTPS. O NSG do load balancer encaminha somente a porta de aplicação necessária ao NSG da camada app. As instâncias de aplicação não recebem IP público; saídas para atualização podem seguir pelo NAT Gateway, e o acesso a serviços Oracle suportados pode usar o Service Gateway. O banco ou serviço de dados aceita apenas a porta específica a partir do NSG de aplicação. Portas, CIDRs e protocolo devem ser adaptados ao produto utilizado; “liberar tudo temporariamente” quase sempre vira dívida permanente.

5 – ROTEIRO DE PROVISIONAMENTO: DA BASE AO PRIMEIRO WORKLOAD

A sequência abaixo funciona como um runbook inicial. Ela prioriza dependências e evidências: primeiro a organização e os acessos, depois a conectividade, então o compute/storage e, por fim, validação e operação. Em ambientes maduros, a maior parte deve ser executada por Terraform ou Resource Manager; no aprendizado inicial, reproduzir o fluxo em um compartment de laboratório ajuda a compreender cada componente.

1. Preparar governança — Criar ou validar compartments, tags obrigatórias, quotas, grupos, MFA e políticas mínimas. Registrar owner e classificação do workload.

2. Desenhar endereçamento — Reservar o CIDR da VCN e subnets sem sobreposição. Para o exemplo: VCN 10.20.0.0/16; pública 10.20.10.0/24; app privada 10.20.20.0/24; dados privados 10.20.30.0/24.

3. Criar conectividade — Provisionar gateways necessários, tabelas de rotas por subnet e DNS. Não associe Internet Gateway às camadas privadas por conveniência.

4. Criar NSGs — Modelar fluxos por função: nsg-lb, nsg-app e nsg-db. Documentar porta, origem, destino e justificativa.

5. Provisionar serviços — Criar load balancer, instâncias/serviço de aplicação, volumes e camada de dados. Desabilitar IP público onde não for necessário e distribuir réplicas entre Fault Domains.

6. Configurar recuperação — Aplicar políticas de backup, retenção e cópia/replicação quando requerida. Executar um restore de teste e guardar a evidência.

7. Ativar operação — Habilitar logs, métricas, alarmes, notificações, budget, Cloud Guard e responsáveis. Um recurso sem monitoramento ainda não está pronto para produção.

8. Validar e entregar — Testar health checks, conectividade permitida e bloqueada, acesso administrativo, failover previsto, tags, custo estimado e plano de reversão.

5.1 Matriz de fluxo mínima do exemplo

Teste negativo também é requisito – além de comprovar que o fluxo necessário funciona, valide que portas não previstas, origem pública para a camada app e acesso lateral indevido estão bloqueados.

6 – COMPUTE E STORAGE: DIMENSIONAR, AUTOMATIZAR E RECUPERAR

6.1 Compute sem “tamanho definitivo”

Shapes flexíveis permitem ajustar OCPUs e memória em famílias compatíveis. Para começar, dimensione com base na necessidade conhecida, não no pico imaginado; colete métricas e faça rightsizing. Separe escalabilidade vertical, que altera a capacidade de uma instância, de escalabilidade horizontal, que adiciona réplicas e normalmente exige balanceamento e aplicação stateless.

• Use cloud-init ou automação de configuração para bootstrap repetível; scripts devem ser idempotentes e produzir logs.
• Não coloque senhas, tokens ou chaves privadas em user data, repositórios ou arquivos tfvars. Busque segredos em serviço apropriado no tempo de execução.
• Padronize imagem, agente, timezone, NTP, patching, logging e hardening. Registre o que é responsabilidade da plataforma e o que pertence ao time da aplicação.
• Quando houver múltiplas instâncias, distribua-as entre Fault Domains e use health checks que representem a saúde real da aplicação, não apenas uma porta aberta.

 Compute com alta disponibilidade e escalabilidade

6.2 Volumes, backups e Object Storage

Boot e Block Volumes devem ter política de backup coerente com RPO, retenção e criticidade. Backups de volumes são armazenados de forma regional no Object Storage e são criptografados. Políticas podem automatizar a frequência, mas a validação só termina quando um volume ou instância é restaurado e o serviço é verificado. Para dados em Object Storage, regras de Lifecycle podem mover objetos para Archive ou excluí-los conforme idade e prefixo.

Regra operacional – backup não é sinônimo de recuperação. Defina frequência, retenção, local, acesso, responsável, tempo de restauração e evidência de teste.

Armazenamento, backup e recuperação

7 – SEGURANÇA, OBSERVABILIDADE E FINOPS DESDE O DIA 1

7.1 Controles preventivos e detectivos

Cloud Guard monitora a postura de segurança e pode detectar problemas e atividades de risco, com recipes e responders configuráveis. Security Zones acrescentam políticas preventivas que impedem operações incompatíveis com a zona e dependem do Cloud Guard habilitado. O uso deve começar em escopo controlado, com responsáveis e tratamento de findings; ativar uma ferramenta sem processo de resposta apenas aumenta o ruído.

Para credenciais de aplicações, o Secret Management Service armazena e gerencia segredos como senhas, tokens e chaves de API; para chaves criptográficas, use os recursos de Key Management/Vault conforme o requisito. Acesso a segredos deve ser concedido a dynamic groups ou funções específicas, com rotação e auditoria. O serviço Audit registra atividades de API na tenancy e é uma fonte essencial para investigação e conformidade.Controles de segurança e conformidade

7.2 Logs, métricas, alarmes e notificação

Observabilidade precisa responder a três perguntas: o serviço está saudável, o usuário está sendo impactado e alguém foi avisado? OCI Logging centraliza logs de serviços e custom logs; Monitoring trabalha com métricas e alarms; Notifications distribui mensagens por topics e subscriptions para canais suportados. Configure alarmes com severidade, limiar, janela, ausência de dados, owner e runbook. Um alarme sem ação definida é apenas uma mensagem.

Observabilidade e resposta operacional

7.3 Custos: visibilidade antes da fatura

Budgets acompanham o consumo e enviam alertas por valor ou previsão, mas são limites informativos: não desligam automaticamente os recursos. Combine budgets com cost-tracking tags, Cost Analysis e revisão periódica. Cloud Advisor pode apontar oportunidades de economia, que precisam ser avaliadas com o contexto de desempenho e continuidade.

• Crie budget por área ou ambiente relevante e inclua alertas graduais, por exemplo 50%, 80% e 100%, além de previsão quando aplicável.
• Torne CostCenter, Owner e Environment obrigatórios por processo e tag defaults; recursos “sem dono” devem entrar em uma fila de correção.
• Revise instâncias ociosas, volumes órfãos, backups antigos, IPs reservados, load balancers subutilizados e ambientes não produtivos fora de horário.
• Atribua cada recomendação a um responsável e registre decisão: aplicar, adiar com justificativa ou rejeitar por requisito técnico.

Ciclo FinOps para custos e controles

8 – INFRAESTRUTURA COMO CÓDIGO E CICLO DE VIDA

Terraform transforma a configuração em código versionável. O OCI Resource Manager é um serviço gerenciado pela Oracle para executar stacks Terraform, armazenar estado e organizar jobs de plan/apply. Mesmo em ambientes pequenos, IaC reduz divergência entre desenvolvimento, homologação e produção e cria trilha de revisão. A meta não é automatizar tudo de uma vez, e sim evitar que o conhecimento fique preso a cliques e memória.

O estado Terraform é sensível porque pode conter identificadores e valores retornados por recursos. Proteja o backend, limite acesso, mantenha versionamento/locking quando aplicável e nunca publique state em repositório. Fixe versões aprovadas de providers e módulos, execute validações e security scans, revise o plan e separe aprovação de aplicação em produção.

Exemplo 3 – Trecho Terraform para uma VCN básica

terraform {
  required_providers {
    oci = {
      source = "oracle/oci"
      # Fixe a versão aprovada pelo seu pipeline.
    }
  }
}

provider "oci" {
  region = var.region
}

resource "oci_core_vcn" "foundation" {
  compartment_id = var.network_compartment_id
  cidr_blocks     = ["10.20.0.0/16"]
  display_name    = "vcn-br-prod-01"
  dns_label       = "brprod01"

  defined_tags = {
    "Governance.Environment" = "prod"
    "Governance.Owner"       = "cloud-platform"
  }
}

O provider oficial da OCI e o Resource Manager possuem documentação específica. Use variáveis, módulos, validações e políticas de pipeline adequadas ao ambiente. O exemplo apresenta, de forma simplificada, o provisionamento de uma VCN IPv4 básica com Terraform. Ele pressupõe que o provider da OCI e o método de autenticação já estejam configurados. Para utilizar as defined tags apresentadas, o namespace Governance e as chaves Environment e Owner devem existir previamente na tenancy. Subnets, gateways, tabelas de rotas, Network Security Groups e demais componentes da rede devem ser provisionados separadamente, conforme os requisitos da arquitetura.

8.1 Fluxo mínimo de entrega

1. Código criado em branch, com convenções de nome, tags e módulos aprovados.
2. Validação de sintaxe, lint, testes e análise de segurança executados automaticamente.
3. Terraform plan ou job equivalente revisado por outra pessoa; alterações destrutivas são destacadas.
4. Apply autorizado no ambiente correto, com credencial de pipeline e escopo mínimo.
5. Testes pós-implantação, evidências, atualização de inventário e handover operacional.

Pipeline de infraestrutura como código com Terraform

9 – ERROS COMUNS E COMO CORRIGIR

10 – CHECKLIST DE FOUNDATION E TRILHA DE EVOLUÇÃO

Antes de aprovar o provisionamento □ Região, Availability/Fault Domains e disponibilidade dos serviços foram validados. □ Owner técnico, owner de negócio, ambiente, criticidade, RTO, RPO e classificação de dados estão registrados. □ Compartments, grupos, MFA, policies e dynamic groups seguem least privilege. □ CIDR não sobrepõe outras redes; subnets, rotas, gateways e DNS estão documentados. □ Matriz de fluxo define origem, destino, protocolo, porta, justificativa e expiração de exceções. □ Defined tags, tag defaults, quotas, service limits e budget foram verificados.

Antes de declarar o recurso “pronto” □ Aplicação e dados não possuem exposição pública desnecessária; acesso administrativo é temporário e auditável. □ Backups estão configurados e pelo menos um restore foi testado conforme o RTO/RPO. □ Logs, métricas, alarmes, Notifications e runbooks têm responsáveis e testes de entrega. □ Cloud Guard/Security Zones e gestão de segredos foram avaliados para o escopo. □ Código IaC, plan, aprovação, evidências e versão implantada estão armazenados. □ Custos iniciais foram revisados e existe processo de rightsizing, patching, revisão de acesso e desativação.

10.1 Trilha do nível inicial ao intermediário

11 CONCLUSÃO

Uma Foundation OCI eficaz não precisa nascer complexa. Ela precisa nascer explícita: responsabilidades conhecidas, acesso mínimo, rede planejada, recursos privados por padrão, backup testado, observabilidade ativa, custo atribuível e configuração reproduzível. Esses elementos criam segurança sem paralisar a entrega, porque reduzem decisões repetidas e tornam o caminho correto o caminho mais fácil.

O próximo passo é aplicar o checklist a um workload real de baixa criticidade, registrar as dificuldades e transformar aprendizados em módulos, políticas e runbooks. A maturidade surge dessa repetição controlada: cada implantação melhora a foundation, e a foundation melhora a próxima implantação. Para evoluir decisões de arquitetura, utilize também o OCI Well-Architected Framework e as arquiteturas de referência do Oracle Architecture Center.

As referências priorizam documentação oficial da Oracle. A disponibilidade, os limites e o comportamento dos serviços devem ser confirmados na região e na versão da documentação utilizadas no momento da implantação.

Mensagem final – provisionar é criar o recurso; entregar é deixá-lo seguro, observável, recuperável, custeável e sob responsabilidade definida.