Compute Instances
Compute Instances: para controle do sistema operacional e formatos tradicionais.
Uma tenancy precisa crescer sem perder clareza sobre acesso, rede, custos e recuperação. A Add Solution transforma requisitos de workloads em uma arquitetura OCI governável, conectada e preparada para o ciclo operacional.
Tenancy, compartments, IAM, rede, dados, proteção, custos e operação como um único sistema.

OCI landing zones oferecem módulos Terraform para identidade, rede, segurança, observabilidade e governança. A referência acelera a implantação, mas precisa ser ajustada à organização, às regiões e aos workloads. Compartments organizam recursos e permitem aplicar políticas, quotas, tags e budgets em escopos lógicos. Eles não são fronteiras físicas. A proteção depende de políticas IAM, desenho de rede, chaves, configuração dos serviços e procedimentos. A landing zone é o começo de um modelo operacional, não a conclusão do projeto cloud.
OCI IAM combina identity domains, grupos, dynamic groups, compartments e policies. Usuários humanos podem ser federados ao provedor corporativo. Workloads compatíveis usam dynamic groups e resource principals para reduzir credenciais estáticas. A arquitetura separa administradores de tenancy, rede, segurança, banco e aplicações. Políticas amplas no root compartment são evitadas quando escopos menores atendem à função. Acesso emergencial, rotação, revisão e auditoria entram no ciclo operacional.
VCNs, subnets, route tables, security lists e NSGs definem a conectividade. Service Gateway permite acesso privado a serviços OCI suportados; NAT Gateway oferece saída para recursos privados; DRG conecta VCNs, regiões, VPNs e FastConnect conforme configuração. FastConnect fornece conectividade privada via parceiros ou colocation, mas redundância ponta a ponta exige avaliar circuitos, localidades, CPEs, providers, DRGs e rotas. VPN pode atuar como caminho principal ou contingência conforme capacidade e risco. O projeto valida endereçamento, DNS, ingress, egress, inspeção, assimetria, limites, latência e custo de transferência.
Sizing considera perfil de CPU, memória, I/O, rede, burst, disponibilidade de shapes e capacidade regional. Números de benchmark só são usados com configuração e condições reproduzíveis.
Compute Instances: para controle do sistema operacional e formatos tradicionais.
OKE: Kubernetes gerenciado, mantendo responsabilidade por nós, rede, add-ons, aplicações e políticas.
Functions e Container Instances: para cenários compatíveis com seus limites e execução.
Object, Block e File Storage: escolhidos por semântica, performance, lifecycle e recuperação.
Load Balancer e Network Load Balancer: selecionados por protocolo, terminação e requisitos do fluxo.
Base Database Service, Autonomous Database e Exadata Database Service atendem cenários distintos. Compatibilidade, versão, recursos, licenciamento, administração, janela de manutenção, backup, Data Guard, latência e integração orientam a escolha. Autonomous Database reduz tarefas específicas de administração, mas modelo de dados, acessos, dependências, performance, custos e recuperação continuam sob responsabilidade do projeto. Exadata exige sizing e validação comercial próprios; não é presumido como destino universal para bancos Oracle.
Cloud Guard identifica configurações e atividades relevantes por detector recipes e pode recomendar ou executar respostas configuradas. Security Zones aplicam recipes a compartments e podem negar operações incompatíveis. Vault gerencia chaves e secrets; Bastion oferece acesso temporário a recursos privados; Vulnerability Scanning cobre cenários suportados. Esses serviços não substituem classificação de dados, desenho IAM, segurança de aplicações ou resposta a incidentes. Cada finding recebe prioridade, responsável, exceção e procedimento.
Audit registra chamadas de API; Logging reúne logs de serviços e aplicações; Monitoring trabalha com métricas e alarms; Events reage a mudanças de estado; Notifications distribui mensagens; Connector Hub movimenta dados entre serviços suportados. A Add Solution define sinais por serviço crítico, retenção, acesso, integração e custo. Alarmes precisam chegar a um responsável com contexto e runbook. Coletar tudo sem hipótese operacional aumenta volume sem melhorar resposta.
Availability Domains e Fault Domains podem reduzir exposição a falhas conforme a região e o serviço. Nem todas as regiões possuem a mesma topologia ou oferta. A aplicação precisa operar durante a falha considerada. Backups, clones, replicação e Data Guard resolvem riscos diferentes. RPO, RTO, consistência, região de destino, capacidade, credenciais e dependências precisam ser documentados. Object Storage pode participar de retenção e cópias, condicionado a políticas, lifecycle e controles de exclusão. Restore, switchover, failover e failback precisam ser exercitados.
Compartments, tags e budgets apoiam alocação e alertas, mas não substituem responsáveis financeiros. Compute, storage, database, licenças, FastConnect, egress, logs e backups compõem o custo total. Service limits e quotas podem variar por região e tenancy. Shapes ou capacidades específicas podem exigir planejamento. Compromissos, licenças e descontos dependem de contrato vigente e não são presumidos nesta página.
OCI oferece padrões públicos, dedicados, Cloud@Customer e integrações multicloud. A escolha depende de residência, latência, operação, soberania, conectividade e contrato. Serviços disponíveis e responsabilidades mudam entre modelos. Integrações com outras clouds precisam tratar identidade, rede, DNS, observabilidade, transferência de dados e ownership de incidentes. “Multicloud” só agrega valor quando resolve requisito concreto.
O plano identifica aplicações, bancos, dados, integrações, licenças, dependências e janelas. Ferramentas de migração são selecionadas depois da estratégia por workload. Fluxo:
descobrir e classificar;
estabelecer landing zone;
validar conectividade e segurança;
pilotar workload representativo;
migrar por ondas com rollback;
estabilizar performance, backup, custos e observabilidade;
transferir runbooks e responsabilidades.
Regiões não possuem necessariamente os mesmos serviços, shapes ou capacidades. Oracle Database, Java, sistemas operacionais e softwares de terceiros exigem validação contratual. BYOL, license included e programas comerciais dependem do produto e dos termos vigentes. O suporte Add Solution cobre o escopo contratado com o cliente. Oracle Support e planos cloud são contratados separadamente e seguem seus próprios termos. A integração entre os fluxos precisa ser definida na operação.
Respostas objetivas para decisões de arquitetura, operação e continuidade em OCI.
Não. A referência é modular. O projeto seleciona componentes proporcionais a risco, escala e operação, preservando identidade, rede, logs, custos e recuperação mínimos.
Não. São escopos lógicos de organização e acesso. Isolamento de rede depende de VCNs, subnets, rotas, NSGs, gateways e políticas.
Não isoladamente. Circuitos, localidades, providers, CPEs, DRGs e rotas precisam formar o desenho resiliente.
Reduz tarefas da plataforma, mas não elimina modelagem, acesso, integração, performance, custo e recuperação.
Não. Elas aplicam policies de uma recipe a recursos suportados. Processos, aplicações, identidades e evidências continuam necessários.
Quando requisitos de workload, compatibilidade, consolidação, performance e operação justificarem o investimento e forem validados por sizing.
Não. Depende dos eventos de falha, residência de dados, RPO, RTO, custo e capacidade de recuperação.
assessment de tenancy e workloads;
landing zone e Terraform;
IAM, compartments e políticas;
VCN, DRG, VPN e FastConnect;
compute, OKE, storage e bancos;
segurança e observabilidade;
backup, DR e testes;
custos, quotas e capacity planning;
migração, documentação e sustentação.
Conecte tenancy, identidade, rede, bancos, proteção, custos e operação antes de ampliar o ambiente.