Cómo preparé mi entorno de nube en Colombia

Hace poco di el paso de crear una nueva cuenta (tenant) en Oracle Cloud Infrastructure (OCI). Lo interesante es que, por primera vez, estoy desplegando recursos directamente en la región Colombia Central (Bogotá).

Mi objetivo no es migrar todo mi laboratorio a la nube —sigo siendo fiel a mi Home Lab local, mi Intel NUC—, sino apostar por un enfoque híbrido: la latencia mínima de tener la nube “en casa” combinada con la potencia de la infraestructura de Oracle.

Una de las grandes motivaciones para usar OCI son sus instancias Always Free, especialmente las basadas en procesadores ARM (Ampere). Ofrecen hasta 4 OCPUs y 24 GB de RAM

[NOTA: desde mediados de 2026 Oracle redujo este límite. La documentación oficial de Always Free Resources ahora indica 2 OCPUs y 12 GB de RAM en total para Ampere A1 (1.500 horas de OCPU y 9.000 GB-hora al mes), la mitad de lo que se ofrecía antes. Hay reportes de usuarios de pago (Pay As You Go) que siguen viendo 4 OCPUs/24 GB sin costo, pero la documentación vigente solo garantiza 2/12 GB para cuentas Always Free. Vale la pena que verifiques tu cupo actual en la consola antes de planear el tamaño de tu instancia].

Sin embargo, como consultor de seguridad sé que la nube no es segura por defecto: no se trata de lanzar una máquina virtual y empezar a instalar cosas sin más.

Antes de desplegar mi primera instancia me obligué a frenar, leer la documentación oficial y estructurar el tenant correctamente. Aquí te comparto el resumen de los 6 pasos de preparación y seguridad que aplicué antes de tocar una sola máquina virtual.

1. Define tu plan de organización (no uses el “root” para todo)

La tentación de crear todo en el compartimento raíz (root compartment) es grande, pero es mala práctica. La documentación de Oracle es clara en esto: necesitas estructura.

Lo primero que hice fue definir una jerarquía de compartimentos. Piénsalos como carpetas lógicas para aislar recursos.

  • Mi estrategia: creé compartimentos separados según el propósito —por ejemplo, un “Sandbox” para pruebas destructivas y otro para servicios estables.
  • ¿Por qué? Facilita la administración y, sobre todo, la seguridad. Si un script se vuelve loco en el entorno de pruebas, no toca los recursos estables.

2. Gestión de identidad (IAM): el principio de mínimo privilegio

Aunque soy el dueño de la cuenta, operar siempre como “administrador supremo” es un riesgo innecesario.

Configuré el IAM (Identity and Access Management) siguiendo el principio de segregación de funciones:

  • Creé grupos específicos (Administradores, Operadores de Red, Seguridad).
  • Evité las políticas genéricas. En lugar de dar acceso a todo, diseñé políticas que permiten solo lo necesario.

Consejo: nunca compartas usuarios. Incluso en un laboratorio personal, acostúmbrate a crear usuarios nominales y asignarlos a grupos, nunca a dar permisos directos al usuario.

3. Redes y conectividad: planificando la VCN

Antes de pensar en servidores hay que pensar en carreteras. En OCI eso es la VCN (Virtual Cloud Network).

Al crear mi VCN en la región de Bogotá tuve que decidir el diseño de las subredes. Aunque es un laboratorio, separar lo público de lo privado es vital:

  • Subredes públicas: para recursos que necesitan salir o recibir tráfico de internet (con sus respectivos Internet Gateways).
  • Subredes privadas: para bases de datos o servicios internos que no deben quedar expuestos.

Aquí también entran los Security Lists y los Network Security Groups (NSG). Configuré reglas de firewall estrictas desde el inicio —nada de 0.0.0.0/0 abierto al puerto 22 para todo el mundo.

4. Etiquetas y gobernanza de costos (cuidado con la tarjeta)

Aunque busquemos aprovechar la capa gratuita, las sorpresas en la facturación llegan si no tenemos cuidado: volúmenes de almacenamiento huérfanos, tráfico de salida que se nos pasa de la mano, etc.

Para mitigar esto en mi nueva región:

  • Tagging: definí un esquema de etiquetas para saber qué recurso pertenece a qué proyecto (por ejemplo, Entorno: Pruebas).
  • Budgets: configuré un presupuesto con alerta de consumo. Mi intención es gastar $0, pero quiero un correo si mi consumo proyectado supera los $10 USD. Mejor una alerta temprana que una factura inesperada a fin de mes.

5. Seguridad base y la cuenta “break-glass”

Más allá de los firewalls, hay configuraciones a nivel de tenant que no se pueden ignorar:

  • Cloud Audit: verifiqué que el servicio de auditoría esté registrando los eventos. Necesito saber qué pasó, cuándo y quién lo hizo.
  • Cuenta de emergencia (break-glass): siguiendo las guías de administración, configuré una cuenta de acceso de emergencia. Es un usuario con permisos máximos que se mantiene aislado, con una contraseña extremadamente compleja, para usar solo si pierdo el acceso a mi federación de identidad o a mis usuarios principales.

6. Revisión de límites de servicio (Service Limits)

Finalmente, antes de emocionarme lanzando la VM, fui a la consola a revisar los Service Limits para la región de Bogotá.

No hay nada más frustrante que configurar toda la red y, al momento de crear la instancia, recibir un error de “límite excedido”. Verifiqué que mi tenancy tuviera capacidad disponible —cupo de CPUs ARM y memoria— para lo que planeaba desplegar.

¿Qué sigue?

Con estos 6 pasos, mi entorno en Oracle Cloud quedó listo, seguro y organizado. Ya no es un terreno baldío, sino una base sólida para empezar a construir.

En la próxima entrada paso a la acción: te muestro cómo desplegué mi primera máquina virtual, los comandos que usé para actualizar el sistema operativo y qué servicios base instalé para dejarla 100% operativa.

¡Nos leemos en el siguiente post!