Conceptos de la nube y responsabilidad compartida

La computación en la nube (クラウドコンピューティング) es un modelo de uso en el que los recursos de TI no se poseen, sino que se toman en alquiler solo cuando se necesitan, en la cantidad necesaria, y se pagan según el uso. El tiempo entre la solicitud y la disponibilidad es corto, y la facturación se detiene en el momento en que se devuelven los recursos. Fijar la cantidad necesaria antes de la implantación y comprar el equipo, así como gestionar en la propia empresa incluso la electricidad y la climatización, son formas de trabajar propias de on-premises (オンプレミス), y como la cantidad debe decidirse de antemano, provocan sobreaprovisionamiento (過剰プロビジョニング) o falta de capacidad. La descripción de que la cantidad no puede cambiarse durante el período del contrato es lo contrario de la premisa de la nube, según la cual puede aumentarse o reducirse más adelante.

Pay-as-you-go (従量課金) es el principio de pagar solo por lo que realmente se usa, sin pago por adelantado ni compromiso a largo plazo. Como permite escalar según la demanda real y no según una previsión, reduce el riesgo de sobreaprovisionamiento (過剰プロビジョニング). Bajar el precio unitario a cambio de comprometerse con un nivel de uso durante un plazo determinado es Save when you commit; que el precio unitario baje a medida que aumenta el uso es Pay less by using more; y agrupar en un importe mensual fijo sin cargos por excedente es Flat rate: todos ellos se refieren a principios distintos.

Pay less by using more (使うほど安くなる) es el principio según el cual se aplica una estructura de precios escalonada (段階的な料金体系) a elementos como S3 y la transferencia de datos, de modo que el precio unitario por GB baja a medida que aumenta el uso. Bajar el precio unitario a cambio de comprometerse con un nivel de uso durante un plazo determinado es Save when you commit, del que Savings Plans es un ejemplo. Pagar cada vez solo por lo que realmente se ha usado es Pay-as-you-go, y agrupar en un importe mensual fijo sin cargos por excedente es Flat rate. Los cuatro principios tienen fines distintos, por lo que no se excluyen entre sí y se usan combinados.

Save when you commit (コミットして節約) es el principio según el cual, como ocurre con Savings Plans, los precios de los servicios de computación o de aprendizaje automático se descuentan a cambio de comprometerse con un nivel de uso específico durante un plazo de 1 o 3 años. Fijar el importe mensual para que no haya cargos por excedente, sin ningún mecanismo de traslado al mes siguiente, es Flat rate. Una estructura escalonada en la que el precio unitario baja a medida que aumenta el uso es Pay less by using more. Poder dejar de usar en cualquier momento sin compromiso es una propiedad de Pay-as-you-go, cuya premisa es la opuesta a la de este principio basado en el compromiso.

A agosto de 2026, la lista oficial de guías de examen sitúa dos certificaciones en el nivel Foundational: AWS Certified Cloud Practitioner (CLF-C02) y AWS Certified AI Practitioner (AIF-C01). Developer - Associate (DVA-C02) y Data Engineer - Associate (DEA-C01) son ambas de nivel Associate, y Advanced Networking - Specialty (ANS-C01) es de nivel Specialty. En las certificaciones cuyo nombre termina con el nombre de un nivel, eso es una pista útil, pero Cloud Practitioner y AI Practitioner no llevan nombre de nivel, así que recuerde que estas dos son las de nivel Foundational.

CLF-C02 es el código de examen (試験コード) de AWS Certified Cloud Practitioner. CLF significa Cloud Practitioner, y el C02 final indica la generación de la revisión. El código de AWS Certified AI Practitioner es AIF-C01; el de AWS Certified Developer - Associate, DVA-C02; y el de AWS Certified Data Engineer - Associate, DEA-C01. Los nombres de las certificaciones a veces cambian, pero el código de examen no cambia hasta que se revisa, por lo que comprobar el código es una forma fiable de confirmar si el material de estudio está actualizado.

El código de examen de AWS Certified Solutions Architect - Professional es SAP-C02. SAA-C03 es el nivel Associate de la misma ruta de Solutions Architect, SOA-C03 es CloudOps Engineer - Associate y SCS-C03 es Security - Specialty. Las tres primeras letras se parecen y pueden confundir, pero ayuda recordar que SAA corresponde a Associate y SAP a Professional.

La Exam Guide de CLF-C02 fija la ponderación en el examen (出題比率) así: a Cloud Concepts el 24 por ciento, a Security and Compliance el 30 por ciento, a Cloud Technology and Services el 34 por ciento y a Billing, Pricing, and Support el 12 por ciento. Por lo tanto, el mayor es Cloud Technology and Services y el menor, Billing, Pricing, and Support. Al tratarse de una certificación de nivel inicial, cabría suponer que los conceptos tienen el mayor peso, pero en realidad el dominio que evalúa el conocimiento de los servicios es el mayor, seguido de la seguridad. Conviene distribuir el tiempo de estudio siguiendo esta misma proporción.

La Exam Guide de SAA-C03 asigna a Design Secure Architectures el 30 por ciento, a Design Resilient Architectures el 26 por ciento, a Design High-Performing Architectures el 24 por ciento y a Design Cost-Optimized Architectures el 20 por ciento. El mayor es el diseño de arquitecturas seguras. Los nombres de los cuatro dominios son fáciles de recordar si se relacionan con los pilares de Well-Architected, lo que muestra que siguen el orden seguridad, fiabilidad, eficiencia del rendimiento y optimización de costos.

La certificación Associate orientada a operaciones cambió de nombre, de SysOps Administrator a CloudOps Engineer, y su código de examen también pasó de SOA-C02 a SOA-C03. El último día para presentar el examen con el código antiguo fue el 29 de septiembre de 2025, y el nuevo código comenzó el 30 de septiembre de 2025. Data Engineer - Associate y Machine Learning Engineer - Associate no son sucesoras de la ruta de operaciones, sino certificaciones distintas creadas recientemente en los ámbitos de datos y de ML, respectivamente. DevOps Engineer - Professional es una certificación de nivel Professional que ya existía y que corresponde a otro nivel.

AWS llama oficialmente a su propia responsabilidad "Security of the Cloud" (seguridad de la nube), y la define como la protección de la infraestructura que ejecuta todos los servicios ofrecidos en la nube de AWS, es decir, el hardware, el software, las redes y las instalaciones. Corregir las vulnerabilidades de una aplicación instalada en una instancia es responsabilidad del cliente cuando se elige EC2. Elegir las opciones de cifrado de datos y otorgar permisos mediante IAM siguen siendo tareas del cliente sea cual sea el servicio elegido, y ambas pertenecen al lado de "Security in the Cloud" (seguridad en la nube).

AWS afirma explícitamente que "la responsabilidad del cliente estará determinada por los servicios de la nube de AWS que seleccione". Esto significa que la cantidad de trabajo de configuración que el cliente debe realizar, como parte de su responsabilidad de seguridad, varía según el servicio elegido. Un plan de soporte determina cómo se recibe la asistencia técnica y no desplaza la línea de responsabilidad. La Región y la zona de disponibilidad (アベイラビリティゾーン) tienen que ver con la ubicación, y la duración del uso o el gasto tienen que ver con la facturación: ninguno de ellos determina el alcance de la responsabilidad.

AWS afirma oficialmente que, en los servicios que requieren configuración como EC2, el cliente gestiona "los sistemas operativos invitados (incluidas las actualizaciones y los parches de seguridad), cualquier software de aplicación o utilidad instalados en las instancias y la configuración de los grupos de seguridad". Por lo tanto, aplicar parches al sistema operativo invitado (ゲストOS) es responsabilidad del cliente. En EC2, lo que opera AWS llega solo hasta la infraestructura física y la capa de virtualización, no al sistema operativo dentro de la instancia. Un plan de soporte es un contrato para recibir asistencia técnica y no cambia a quién corresponde la responsabilidad.

Respecto de los servicios abstractos o administrados (マネージドサービス), AWS afirma que "AWS opera la capa de infraestructura, el sistema operativo y las plataformas, y los clientes acceden a los puntos de enlace para almacenar y recuperar datos". Lo que queda en manos del cliente es gestionar sus propios datos (incluidas las opciones de cifrado), clasificar los activos y aplicar los permisos adecuados mediante las herramientas de IAM. El cliente no realiza las actualizaciones del sistema operativo ni opera la plataforma, pero la clasificación de datos y la configuración de permisos nunca dejan de estar en manos del cliente, sea cual sea el servicio.

La línea del modelo de responsabilidad compartida (責任共有モデル) no es fija, sino que se mueve según el servicio elegido. En un servicio como EC2, en el que el cliente gestiona el sistema operativo invitado, aplicar parches es responsabilidad del cliente, pero en un servicio como S3 o DynamoDB, en el que AWS opera todo hasta el sistema operativo y la plataforma, pasa a ser responsabilidad de AWS. Por lo tanto, ni "siempre AWS" ni "siempre el cliente" es correcto. La Región es una elección de ubicación y no cambia la división de responsabilidades. Si tiene presente este punto, podrá estimar dónde está la línea en un servicio que no conoce con solo preguntarse si se parece más a EC2 o a S3.

Las instalaciones figuran explícitamente en "Security of the Cloud" como parte de la infraestructura que ejecuta los servicios de la nube de AWS, por lo que siempre son responsabilidad de AWS, sin importar qué servicio se use. Los clientes no pueden auditar este ámbito por sí mismos ni entrar en las instalaciones para inspeccionarlas; en su lugar, lo comprueban mediante las certificaciones de terceros y los informes de auditoría que publica AWS. Esto corresponde a la categoría de control llamada Inherited Controls (controles heredados, 継承されるコントロール) dentro de las tres clasificaciones de controles: la parte que los clientes heredan por completo de AWS. Lo que se mueve según el servicio elegido es la capa del sistema operativo y del middleware, no la capa física.

AWS afirma explícitamente que gestionar los propios datos (incluidas las opciones de cifrado), clasificar los activos y aplicar los permisos adecuados mediante las herramientas de IAM siguen siendo tareas del cliente incluso cuando se usan servicios abstractos. Como esto nunca deja de estar en manos del cliente, sea cual sea el servicio elegido, sirve como punto fijo para pensar dónde cae la línea. Sustituir un servidor físico y proteger la red troncal (バックボーンネットワーク) son cuestiones de instalaciones y hardware, y siempre corresponden al lado de AWS. El sistema operativo subyacente de un servicio administrado lo opera AWS, por lo que aplicarle parches no es tarea del cliente.

Los Inherited Controls (controles heredados, 継承されるコントロール) se definen oficialmente como los controles que el cliente hereda por completo de AWS, y los controles físicos y ambientales entran en esta categoría. Los controles que se aplican por separado tanto a la capa de infraestructura como a la capa del cliente son los Shared Controls (controles compartidos), y los controles que son por completo responsabilidad del cliente, como la seguridad de servicios y zonas, son los Customer Specific Controls (controles específicos del cliente). La herencia va en una sola dirección, de AWS al cliente; no es una relación en la que AWS mantenga la propia configuración del cliente.

AWS cita Patch Management (gestión de parches), Configuration Management (gestión de la configuración) y Awareness & Training (concienciación y formación) como sus tres ejemplos de Shared Controls (controles compartidos, 共有コントロール). Lo que tienen en común es que la misma actividad se lleva a cabo en paralelo tanto en la capa de infraestructura como en la capa del cliente; en la gestión de parches, por ejemplo, AWS aplica parches a su propia infraestructura mientras que el cliente los aplica por separado al sistema operativo invitado y a las aplicaciones. El control de entradas y salidas, la redundancia eléctrica y la adquisición y eliminación de hardware son controles físicos y ambientales, que el cliente hereda de AWS. La seguridad de servicios y zonas es un ejemplo de Customer Specific Controls.

DynamoDB es un servicio abstracto, por lo que AWS opera todo, incluidas la capa de infraestructura, el sistema operativo y la plataforma. La aplicación de parches al sistema operativo invitado (ゲストOS), de la que se encargaba el cliente con EC2, pasa a ser tarea de AWS tras la migración. En cambio, clasificar los datos, elegir las opciones de cifrado y otorgar permisos mediante IAM siguen en manos del cliente sea cual sea el servicio elegido. La protección de las instalaciones físicas ya es siempre responsabilidad de AWS, por lo que nunca pasa al cliente con una migración. Ayuda organizarlo así: lo que se mueve es la capa del sistema operativo y de la plataforma, y lo que no se mueve son los datos y los permisos.

Los pilares actuales son seis: Excelencia operativa, Seguridad, Fiabilidad, Eficiencia del rendimiento, Optimización de costos y Sostenibilidad (持続可能性). La Sostenibilidad se añadió como sexto pilar en 2021, por lo que una lista de solo cinco pilares sin ella refleja información desactualizada de antes de esa incorporación. La Interoperabilidad y la Portabilidad no figuran como pilares del marco; ninguna de las dos aparece en la lista oficial. Una explicación con un número de pilares desactualizado probablemente también tenga nombres de servicios o códigos de examen desactualizados, por lo que puede servir como indicador de lo actualizado que está un material de estudio.

La Excelencia operativa (運用上の優秀性) es el pilar que se centra en ejecutar y supervisar los sistemas, y en mejorar continuamente los procesos y procedimientos. Esto incluye automatizar las implementaciones, actualizar los procedimientos a partir de las revisiones posteriores a los incidentes y hacer los cambios en pasos pequeños y frecuentes. Proteger la información y los sistemas corresponde a Seguridad; optimizar la asignación de recursos y seleccionar los tipos de recursos, a Eficiencia del rendimiento; y eliminar el gasto innecesario y ajustar el tamaño de los recursos, a Optimización de costos: todos ellos remiten a pilares distintos.

El pilar de Seguridad (セキュリティ) se centra en proteger la información y los sistemas, con la integridad de los datos y el control de acceso como eje. El cifrado y el control de acceso basado en el mínimo privilegio (最小権限) encajan de lleno en él. Detener los recursos que no se usan y ajustar el tamaño de las instancias corresponde a Optimización de costos; automatizar la implementación y actualizar los manuales de operación tras las revisiones de incidentes, a Excelencia operativa; y medir y reducir el impacto ambiental, a Sostenibilidad. La mayor parte de lo que sigue siendo responsabilidad del cliente en el modelo de responsabilidad compartida se trata dentro de este pilar de Seguridad.

La Fiabilidad (信頼性) es el pilar que se centra en que una carga de trabajo cumpla la función prevista y en la rapidez con que se recupera de las fallas. Aquí entran la distribución en varias zonas de disponibilidad, la recuperación automática y la verificación de los procedimientos de copia de seguridad y recuperación. Su rasgo distintivo es que abarca no solo evitar que algo se rompa, sino también recuperarse rápidamente una vez que se ha roto. Optimizar la asignación de recursos corresponde a Eficiencia del rendimiento; ejecutar, supervisar y mejorar continuamente los procedimientos, a Excelencia operativa; y minimizar el impacto ambiental, a Sostenibilidad.

La Eficiencia del rendimiento (パフォーマンス効率) es el pilar que se centra en optimizar la asignación de los recursos de TI y en seleccionar el tipo de recurso que se ajusta a las necesidades de la carga de trabajo. Volver a seleccionar un tipo de recurso para cumplir un requisito encaja de lleno en él. La Optimización de costos puede parecer una actividad similar, pero su objetivo es eliminar el gasto innecesario, mientras que aquí la motivación es cumplir un requisito de latencia (レイテンシ), por lo que el enfoque es distinto. La Fiabilidad se fija en la resistencia a las fallas y la Excelencia operativa, en la mejora de los procedimientos: ninguna de las dos es la preocupación principal en este caso.

La Optimización de costos (コスト最適化) es el pilar que se centra en eliminar el gasto innecesario y ajustar el tamaño de los recursos a los requisitos del negocio. Aquí entran decisiones como detener los recursos que no se usan, corregir las instancias sobredimensionadas y elegir los modelos de precios adecuados. Lo esencial no es simplemente reducir al mínimo el costo, sino preguntarse si se obtiene un valor acorde con lo que se gasta. Proteger la información y los sistemas corresponde a Seguridad; cumplir la función prevista y recuperarse, a Fiabilidad; y minimizar el impacto ambiental, a Sostenibilidad.

La Sostenibilidad (持続可能性) es el pilar que se centra en minimizar el impacto ambiental de ejecutar una carga de trabajo en la nube. Es el pilar más reciente, añadido como sexto en 2021, y su presencia o ausencia marca la línea entre el material de estudio actual y el desactualizado. Optimizar la asignación de recursos y seleccionar los tipos de recursos corresponde a Eficiencia del rendimiento; ejecutar, supervisar y mejorar continuamente los procedimientos, a Excelencia operativa; y cumplir la función prevista y recuperarse de las fallas, a Fiabilidad: todos ellos remiten a pilares distintos.

El que falta es la Sostenibilidad (持続可能性), el pilar que trata de minimizar el impacto ambiental de ejecutar una carga de trabajo en la nube. Como se añadió como sexto pilar en 2021, los artículos escritos antes de esa fecha siguen enumerando solo cinco. La Excelencia operativa, la Eficiencia del rendimiento y la Fiabilidad ya existían antes de esa incorporación, por lo que aparecen incluso en un artículo que enumera cinco pilares. Cuando un dato básico como el número de pilares está desactualizado en un artículo, es probable que el resto de su contenido también lo esté.

Los pilares actuales son seis: Excelencia operativa, Seguridad, Fiabilidad, Eficiencia del rendimiento, Optimización de costos y Sostenibilidad, y la Interoperabilidad (相互運用性) no está incluida en esta lista. Que distintos sistemas puedan conectarse entre sí es una preocupación de diseño importante, pero el Well-Architected Framework no la establece como un pilar independiente. La Optimización de costos, la Excelencia operativa y la Eficiencia del rendimiento son miembros legítimos de los seis. Memorizar como si fuera un pilar un término que no está en el marco se convierte en una fuente de confusión al descartar opciones de respuesta.

Eliminar el gasto innecesario y ajustar el tamaño de los recursos a los requisitos del negocio es el enfoque de la Optimización de costos (コスト最適化), no de la Fiabilidad (信頼性). La Fiabilidad es el pilar que se centra en que una carga de trabajo cumpla la función prevista y en la rapidez con que se recupera de las fallas. Las otras tres combinaciones coinciden con las descripciones oficiales. Como los nombres de los pilares se parecen a palabras cotidianas, relacionarlos solo por la impresión que dan invita a cometer errores; memorizarlos junto con la frase que describe su enfoque evita tropezar con este tipo de pregunta.

Una Región (リージョン) es una ubicación física en el mundo donde AWS tiene varias zonas de disponibilidad. Las Regiones tienen nombres como us-east-1 o ap-northeast-1, y se eligen en función de los requisitos de residencia de datos y normativos, la distancia a los usuarios y los precios. Una unidad para aislar fallas formada por uno o más centros de datos independientes corresponde a la descripción de una zona de disponibilidad (アベイラビリティゾーン). Una ubicación donde CloudFront almacena en caché y entrega contenido es una ubicación de borde (Edge Location, エッジロケーション), y una zona ubicada dentro de la red de un operador de telecomunicaciones es una Wavelength Zone.

Una zona de disponibilidad (アベイラビリティゾーン) se define como un conjunto de uno o más centros de datos independientes, cada uno con alimentación eléctrica, redes y conectividad redundantes, alojados en instalaciones separadas. Los puntos clave son que no equivale a un solo edificio de centro de datos, sino a una agrupación, y que se encuentra en un edificio distinto al de las demás zonas. Una capa intermedia entre una ubicación de borde y el origen es una Regional Edge Cache (caché de borde regional, リージョナルエッジキャッシュ), y un lugar en una ciudad cercana a los usuarios para ejecutar aplicaciones corresponde a la descripción de Local Zones: ambos remiten a mecanismos distintos.

AWS afirma oficialmente que cada Región está compuesta por "un mínimo de tres zonas de disponibilidad aisladas y físicamente separadas". Como el número total de Regiones y de zonas no deja de crecer, memorizar esos totales tiene poco valor, pero la regla sobre cuántas zonas tiene como mínimo una sola Región es estable y puede usarse directamente como premisa de diseño. Estar ubicadas dentro de la misma instalación contradice la definición de estar alojadas en instalaciones separadas. Las zonas no son algo que los clientes soliciten para aumentarlas, ni hay solo una por Región.

Las ubicaciones de borde (エッジロケーション) son la red mundial de centros de datos desde la que CloudFront entrega el contenido. Las solicitudes se dirigen a la ubicación de borde con la menor latencia (レイテンシ), y la entrega se realiza desde allí. El punto clave es que no se trata de una unidad de redundancia para aumentar la disponibilidad, sino de una ubicación de caché para volver a entregar el contenido más cerca del usuario. Aislar las fallas es la función de una zona de disponibilidad; dividir los rangos de direcciones IP, la de una subred (サブネット); y ejecutar aplicaciones dentro de las instalaciones de un operador, la de Wavelength Zones.

Una solicitud se dirige a la ubicación de borde con la menor latencia y, si el contenido ya está allí, se entrega de inmediato. Si no está, se obtiene de un origen (オリジン), como un bucket de S3 o un servidor HTTP, se entrega y además se guarda en la caché. Por eso las solicitudes posteriores pueden responderse directamente desde la ubicación cercana. La ausencia de una entrada en la caché no se convierte en un error, ni se deja al usuario esperando. El reenvío a una zona de disponibilidad es un mecanismo de aislamiento de fallas y no tiene relación con el flujo de entrega de contenido.

Una Regional Edge Cache (caché de borde regional, リージョナルエッジキャッシュ) es una capa de caché situada entre una ubicación de borde y el origen. Su función es reducir el número de veces que una solicitud tiene que llegar hasta el origen cuando no se encuentra en el borde. Una unidad de gestión que agrupa zonas de disponibilidad es una Región, y las zonas ubicadas dentro de la red de un operador de telecomunicaciones son las Wavelength Zones: ambos son conceptos distintos. El almacenamiento en caché en el propio dispositivo del usuario no es un mecanismo de AWS, sino una función del navegador o del sistema operativo.

Una zona de disponibilidad (アベイラビリティゾーン) es una unidad de aislamiento de fallas alojada en una instalación separada, con alimentación eléctrica y redes redundantes. Colocar recursos con la misma función en varias zonas significa que, aunque una zona deje de funcionar por completo, las demás pueden seguir procesando. Esta es una configuración Multi-AZ (マルチAZ) y es el punto de partida del diseño de disponibilidad. Entregar desde la ubicación más cercana es la función de una ubicación de borde; la residencia de los datos es un factor para elegir una Región; y reducir el precio unitario mediante un compromiso de uso es una cuestión de precios: ninguno de ellos es el motivo para distribuir en varias zonas.

Local Zones es un mecanismo que permite ejecutar aplicaciones en infraestructura de AWS más cerca de los usuarios finales o de las cargas de trabajo, ubicado en ciudades alejadas de una Región. Se parece a las ubicaciones de borde (エッジロケーション) en que trata de lo "cercano", pero la diferencia es que ejecuta la propia aplicación en lugar de servir como caché para la entrega de contenido. Aislar las fallas dentro de una Región corresponde a una zona de disponibilidad; una ubicación dedicada solo a la entrega, a una ubicación de borde; y una caché intermedia delante del origen, a una Regional Edge Cache.

Las Wavelength Zones son zonas ubicadas dentro de la red de un operador de telecomunicaciones (通信キャリア). Al igual que Local Zones, son un mecanismo para ejecutar la propia aplicación cerca de los usuarios, lo que difiere en propósito de una ubicación de borde, que es un punto de entrega de una caché de contenido. Lo que se ubica entre una ubicación de borde y el origen es una Regional Edge Cache; una unidad de aislamiento de fallas dentro de una Región es una zona de disponibilidad; y dividir el rango de direcciones IP de una VPC es una subred.

Una zona de disponibilidad (アベイラビリティゾーン) es una unidad de aislamiento de fallas alojada en una instalación separada, por lo que prepararse ante la caída de una zona entera requiere colocar los recursos en varias zonas. Como cada Región está compuesta por al menos tres zonas aisladas, es posible distribuir en varias zonas dentro de la misma Región. Añadir más servidores dentro de la misma zona no cumple el requisito, ya que, si esa zona cae, todos caen a la vez. CloudFront acelera la entrega, pero si el origen se detiene, el procesamiento dinámico no puede continuar. Cambiar el plan de precios es una cuestión de costos que no tiene relación con la disponibilidad (可用性).