Introducción

Este curso de aspectos fundamentales de AWS se diseñó para enseñarle los conceptos básicos que necesita para trabajar de manera efectiva en AWS.

Al principio, AWS puede parecer abrumador. Una infraestructura de creación de paradigma nativo en la nube puede ser una partida radical de la forma de hacer las cosas en las instalaciones tradicionales. E independientemente de si es la primera vez que trabaja con la infraestructura o ajustó los kernels de Linux en la última década, puede ser difícil saber dónde comenzar con la selección de AWS de más de 175 servicios.

El curso de aspectos fundamentales de AWS se diseñó para ayudarlo a comenzar con AWS sin considerar su experiencia. En este curso, le enseñaremos sobre los cinco pilares de AWS, que son modelos mentales para utilizar al pensar en la nube. También, aprenderá acerca de los conceptos fundamentales que se aplicarán en cualquier servicio que utilice.

 

Estructura

El curso de aspectos fundamentales de AWS se dividirá en cinco módulos. Cada módulo seguirá el siguiente formato:

  • Introducción: una breve descripción del pilar en el que nos centraremos
  • Modelo mental: un modelo mental guía para ayudarlo a comprender los conceptos presentados en cada pilar
  • Conceptos: conceptos claves que cubren temas básicos amplios para cada pilar
  • Conclusión: resumen de lo que debatimos
  • Más información: enlaces y recursos adicionales
 

Los cinco pilares

Los cinco pilares que se describen en el curso de aspectos fundamentales de AWS provienen del Marco de Buena Arquitectura de AWS. El marco de buena arquitectura es una síntesis de más de una década de experiencia en la creación de aplicaciones escalables en la nube.

Los cinco pilares incluyen las siguientes áreas:

  1. Seguridad
  2. Eficacia del rendimiento
  3. Fiabilidad
  4. Excelencia operativa
  5. Optimización de costos
 

Seguridad

El pilar se seguridad se centra en cómo asegurar la infraestructura en la nube. Los asuntos relacionados con la seguridad y la conformidad son una responsabilidad compartida entre AWS y el cliente. En este modelo de responsabilidad compartida, AWS es responsable por la seguridad de la nube. Esto incluye la infraestructura física, el software y las capacidades de red de los servicios en la nube de AWS. El responsable de la seguridad en la nube es el usuario. Esto incluye la configuración de servicios específicos en la nube, el software de la aplicación y la administración de los datos confidenciales.

Si las cargas de trabajo deben cumplir los requisitos de FedRAMP, DoD, SRG, ITAR, CJIS u otros requisitos de conformidad estrictos, o si contienen datos designados como información no clasificada controlada (CUI), consulte la sección AWS GovCloud (EE. UU.) del curso.

 

Modelo mental

A la hora de pensar en la seguridad en la nube, es útil adoptar el modelo zero trust.

En este modelo, todos los componentes y servicios de las aplicaciones se consideran entidades discretas y potencialmente maliciosas. Esto incluye el tejido de red subyacente, todos los agentes que tienen acceso a los recursos y el software que se ejecuta dentro del servicio.

 

Conceptos

Cuando pensamos en la seguridad en términos de zero trust, significa que tenemos que aplicar medidas de seguridad en todos los niveles de nuestro sistema. A continuación, se presentan tres conceptos importantes para asegurar los sistemas con zero trust en la nube:

  1. Identity and Access Management (IAM)
  2. Seguridad de la red
  3. Cifrado de datos

 

  • Identity and Access Management (IAM)

    IAM es el servicio responsable de realizar el seguimiento de las identidades y accesos en un sistema. Se administra en AWS a través del servicio llamado IAM. El acceso se administra mediante políticas de IAM que aplican los límites de acceso para los agentes dentro de AWS. Hay tres componentes fundamentales en una política de IAM:

    • los PRINCIPIOS especifican a QUIÉNES se les otorgan permisos
    • las ACCIONES especifican QUÉ es lo que se debe realizar
    • los RECURSOS especifican CUÁLES son las propiedades que se tienen que acceder

    Aplicar el modelo zero trust a IAM significa adoptar el principio de mínimo privilegio. Esto significa que cada agente solo debe tener los permisos mínimos necesarios para cumplir su función.

    Una política de IAM puede aplicarse a un principio o a un recurso de AWS. Las políticas asociadas a un principio se conocen como políticas basadas en identidades. Las políticas asociadas a un recurso se conocen como políticas basadas en recursos. Tenga en cuenta que sólo algunos servicios (por ejemplo, S3, KMS, SES) tienen políticas basadas en recursos.

    El hecho de que un principio tenga permiso con el fin de realizar una acción para un recurso determinado, depende de si su política basada en identidades le permite realizarla y de si la política basada en recursos (si existe) no le prohíbe llevarla a cabo.

    Tenga en cuenta que se trata de una simplificación importante del modelo de permisos de IAM. Hay muchos tipos de políticas adicionales que afectan a la posibilidad de conceder accesos. Estos pueden incluir límites de permisos, políticas de control de servicios de la organización, listas de control de acceso y políticas de sesión. Estos tipos de políticas adicionales van más allá del propósito de este curso. Puede obtener más detalles sobre ellos en la sección Más información de este módulo.

    Conclusiones

    • Las políticas de IAM determinan los límites de acceso para las entidades dentro de AWS
    • Las políticas de IAM consisten en PRINCIPIOS, ACCIONES y RECURSOS
    • Las políticas de IAM pueden utilizarse para aplicar el principio de mínimo privilegio
    • IAM tiene varios tipos de políticas: las basadas en identidades y las basadas en recursos, por ejemplo
    • IAM evalúa el acceso en función de la evaluación de todos los tipos de políticas aplicables a un determinado recurso
     

    Más información

  • Seguridad de la red

    La seguridad de la red abarca cualquier sistema, configuración o proceso que salvaguarde el acceso, la capacidad de uso y los recursos accesibles de la red. AWS proporciona una amplia gama de características para asegurar su red, tanto a nivel de red como a nivel de recursos.

    Un enfoque de zero trust en la seguridad de la red implica un enfoque de defensa en profundidad que aplica controles de seguridad en todas las capas de la red (en lugar de sólo la capa más externa).

    Seguridad a nivel de la red

    El primitivo principal a nivel de la red en AWS es Amazon Virtual Private Cloud (VPC). Se trata de una red lógica en la que se definen y se pueden aprovisionar recursos.

    Los siguientes son algunos de los componentes que componen la VPC:

    • Subredes: una serie de direcciones IP dentro de su VPC
    • Tablas de enrutamiento: un conjunto de reglas que determinan hacia dónde se dirige el tráfico
    • Gateway de Internet: un componente que permite la comunicación entre los recursos dentro de su VPC e Internet

    Para salvaguardar el tráfico de su VPC, puede dividir los recursos en internos y de acceso público. A fin de reducir la superficie expuesta a ataques, puede usar un servicio proxy como el balanceador de carga de aplicaciones (ALB) para manejar todo el tráfico que está conectado a Internet. Todos los servicios internos, como los servidores y las bases de datos, se pueden aprovisionar dentro de subredes internas que estén aisladas del acceso público directo a Internet.

    Además de las VPC, también puede utilizar AWS Web Application Firewall (WAF) para restringir aún más el tráfico en la red.

    Seguridad a nivel de recursos

    Los recursos individuales de AWS también tienen controles de seguridad de la red que puede configurar. El control más común se conoce como grupo de seguridad. Los grupos de seguridad son firewalls virtuales que puede utilizar a fin de controlar el tráfico que entra y sale de su recurso. Utilice grupos de seguridad para permitir solo tráfico de fuentes confiables y puertos específicos hacia su instancia. Puede adjuntar grupos de seguridad a recursos como las instancias EC2, instancias RDS y Lambda.

    Conclusiones

    • La seguridad de la red incluye mecanismos diseñados con el fin de salvaguarde el acceso, la capacidad de uso y los recursos accesibles de la red
    • Un enfoque de zero trust en la seguridad de la red consiste en implementar una defensa en profundidad en todas sus capas
    • VPC y WAF permiten aplicar medidas de seguridad a nivel de la red
    • Los grupos de seguridad permiten aplicar medidas de seguridad a nivel de recursos

    Más información

  • Cifrado de datos

    El cifrado de datos es el proceso de codificar la información de manera que sea ininteligible para cualquier tercero que no posea la clave que se requiere para descifrar los datos.

    Adoptar un modelo zero trust para los datos significa cifrar todos nuestros datos, tanto en tránsito como en reposo.

    Cifrado de datos en tránsito

    El cifrado de datos en tránsito implica la codificación de los datos mientras viajan entre sistemas. Todos los servicios de almacenamiento y de bases de datos dentro de AWS proporcionan puntos de enlace de HTTPS que permiten el cifrado de los datos en tránsito. AWS también le ofrece servicios de red que pueden ayudarlo a aplicar el cifrado de datos en tránsito para sus propios servicios. Por ejemplo, puede utilizar el balanceador de carga de aplicaciones (ALB) con el fin de aplicar una conexión a través del HTTPS hasta sus puntos de enlace.

    Cifrado de datos en reposo

    El cifrado de datos en reposo implica cifrar los datos dentro de los sistemas. Todos los servicios de almacenamiento y base de datos de AWS admiten el cifrado de datos en reposo. La mayoría de estos servicios cuentan con el cifrado de datos activado de forma predeterminada. No hay ningún cargo adicional por el cifrado de datos y sus gastos de rendimiento mínimos.

    La mayoría de los servicios de almacenamiento y bases de datos también se integran directamente con Amazon Key Management Service (KMS). Se trata de un servicio central de administración de claves que le permite crear claves administradas por el cliente (CMK) para cifrar los datos.

    El uso de una CMK le proporciona funcionalidades adicionales que van más allá del cifrado. Estas incluyen la posibilidad de utilizar su propio almacén de claves personalizadas, la capacidad de crear un seguimiento de auditoría para el recurso cifrado a través de integraciones con AWS CloudTrail y la aplicación de la rotación automática de claves.

    Conclusiones

    • El cifrado de datos es el proceso mediante el cual se codifica la información de tal manera que solo quienes tengan la clave correcta puedan descifrar la información
    • Datos seguros mediante el cifrado en tránsito y en reposo
    • Todos los servicios de almacenamiento y base de datos en AWS proporcionan cifrado de datos en reposo y en tránsito
    • Puede utilizar los servicios de la red de AWS como el ALB para aplicar el cifrado de datos en tránsito a sus propios servicios
    • Puede utilizar una CMK para desbloquear funcionalidades avanzadas, como la creación de seguimientos de auditoría, el uso de claves personalizadas y la rotación automática de claves

    Más información

    Características

     

    Servicios

     

    Referencias

     

     

Conclusión

En este módulo, aprendió sobre el pilar de seguridad de AWS. Aprendió acerca del modelo mental de zero trust. Aprendió acerca de IAM y el principio de mínimo privilegio. Aprendió acerca de la seguridad de la red de AWS y el principio de defensa en profundidad. Aprendió acerca del cifrado de datos y cómo aplicarlo en datos en tránsito y en reposo.

 

Más información

Eficacia del rendimiento

El pilar de eficacia del rendimiento se centra en cómo puede ejecutar los servicios de manera eficiente y escalable en la nube. Mientras la nube le brinda los medios para gestionar cualquier cantidad de tráfico, requiere que elija y configure los servicios con la escala en mente.

 

Modelo mental

A la hora de pensar en la eficiencia del rendimiento en la nube, es útil considerar a sus servicios como ganado, no mascotas.

En el modelo que implicaba llevar a cabo tareas en las instalaciones, los servidores eran caros y, a menudo, se implementaban y configuraban manualmente. Pueden pasar semanas antes de que se entregue un servidor y se conecte físicamente a su centro de datos. Debido a esto, los servidores fueron tratados como mascotas: cada uno era único y requería mucho mantenimiento. Algunos de ellos incluso tenían nombres.

En la nube, los servidores se consideraban como ganado. Los servidores son recursos básicos que se pueden aprovisionar automáticamente en segundos. Ningún servidor único debe ser esencial para la operación del servicio.

 

Conceptos

Considerar los servidores como ganado brinda muchos beneficios relacionados con el rendimiento. En el modelo que administra servidores “como mascotas”, es bastante común usar el mismo tipo de servidor (o incluso el mismo servidor) para múltiples cargas de trabajo; era demasiado complicado ordenar y aprovisionar diferentes máquinas. En el modelo de administración “como ganado”, el aprovisionamiento es barato y rápido, lo que permite seleccionar el tipo de servidor que mejor se adapta a la carga de trabajo.

El modelo de administración “como ganado” también facilita el escalado del servicio. Debido a que cada servidor es intercambiable y rápido de implementar, la capacidad se puede escalar rápidamente mediante el agregado de más servidores.

Nos centraremos en los siguientes dos conceptos eficiencia del rendimiento:

  1. Selección
  2. Escalado
 
  • Selección

    La selección en AWS es la capacidad de elegir el servicio que más se alinea con la carga de trabajo. AWS tiene la selección más amplia de servicios, con más de 175 servicios distribuidos en más de dos docenas de categorías. Lograr el rendimiento a través de la selección significa poder elegir la herramienta adecuada para el trabajo.

    La carga de trabajo típica generalmente requiere la selección de alguna de las cuatro categorías principales de servicios en AWS: informática, almacenamiento, base de datos y red.

    • La informática involucra el servicio que procesará los datos (por ejemplo, máquina virtual)
    • El almacenamiento involucra el almacenamiento estático de datos (por ejemplo, almacenamiento de objetos)
    • La base de datos involucra el almacenamiento organizado de datos (por ejemplo, base de datos relacional)
    • La red involucra la forma en que se mueven los datos (por ejemplo, red de entrega de contenido)

    En este módulo, repasaremos la selección correcta en las tres primeras categorías. Consulte la sección Más información para obtener guías sobre cómo elegir entre las diferentes opciones de red.

    Independientemente de la categoría de servicio que elija, hay tres cosas que debe considerar.

    1. Tipo de servicio
    2. Grado de administración
    3. Configuración

    Tipo de servicio

    Cuando realiza una selección en una categoría, AWS ofrece muchas opciones para el tipo de servicio que puede usar. El tipo es único para cada categoría.

    Cuando seleccione un servicio de informática, decida si desea una informática basada en máquinas virtuales, en contenedores o sin servidor.

    • La informática basada en máquinas virtuales tiene el modelo mental más familiar para la mayoría de las personas, pero puede ser más costosa y requerir más mantenimiento
    • La informática basada en contenedores permite una división más fina de la carga de trabajo y puede escalar rápidamente, pero incluye una configuración adicional y complejidad de organización
    • La informática sin servidor elimina la mayoría de las complejidades de administración y escalado, pero tiene limitaciones estrictas de sistemas y requiere la adopción de nuevas cadenas de herramientas y procesos

    Cuando seleccione un servicio de almacenamiento, decida si necesita almacenamiento de archivos, en bloque, de objetos o de archivado.

    • Los servicios de almacenamiento en bloque, como EBS, son excelentes para conservar datos de una sola instancia EC2
    • Los sistemas de archivos, como EFS, son excelentes para dar acceso a múltiples clientes a los mismos datos
    • El almacenamiento de objetos, como S3, es excelente para grandes blobs de datos a los que los clientes necesitan acceder
    • El almacenamiento de archivos, como S3 Glacier, es ideal para grandes cantidades de datos a los que se debe acceder con poca frecuencia

    Cuando seleccione un servicio de base de datos, decida si necesita una base de datos relacional, una base de datos no relacional, una solución de almacenamiento de datos o una solución de indexación y búsqueda de datos.

    • Las bases de datos relacionales le permiten tener uniones y propiedades ACID, pero poseen un límite superior en el rendimiento y el almacenamiento de datos
    • Las bases de datos no relacionales tienen esquemas más flexibles y pueden escalar a límites mucho más altos que sus contrapartes relacionales, pero generalmente carecen de uniones y capacidades ACID completas
    • Las soluciones de almacenamiento de datos permiten análisis a gran escala a través del acceso rápido a petabytes de datos estructurados
    • Las soluciones de indexación y búsqueda de datos le permiten indexar y buscar datos de una amplia variedad de orígenes
     

    Grado de administración

    Después que decidió sobre un tipo de servicio, necesita limitarse aún más a un servicio específico, AWS a veces ofrece múltiples ofertas mediante tipos de servicios específicos. La principal diferencia entre varios servicios de AWS del mismo tipo radica en su grado de administración.

    Cuando utiliza servicios de informática y decide el tipo de máquina virtual, debe elegir entre EC2, Lightsail y Elastic Beanstalk. Cuando utiliza EC2 directamente le proporciona el mayor control, pero posee la administración mínima, mientras que cuando elije las operaciones de Lightsail en alguna personalización por una experiencia mucho más administrada. Elastic Beanstalk se encuentra en un punto intermedio, brinda un marco rígido para la arquitectura de su servicio, pero le permite personalizarlo a través de la configuración.

    Cuando utiliza servicios de almacenamiento, la selección de un servicio es más fácil ya que tiende a haber solo un servicio para cualquier tipo dado (por ejemplo, S3 para el almacenamiento de objetos y EFS para el almacenamiento de archivos).

    Cuando utiliza los servicios de base de datos y elije el tipo relacional, debe elegir entre RDS y Aurora. RDS le brinda más control sobre la base de datos subyacente y está disponible para la mayoría de las bases de datos relacionales. Aurora solo funciona con ciertas versiones de MySQL y PostgreSQL, pero se encarga de administrar el almacenamiento subyacente y tiene soporte de clúster integrado.

    Al final del día, la opción de un servicio específico depende en gran medida de su familiaridad con la tecnología subyacente y su preferencia por una experiencia más o menos administrada.

     

    Configuración

    Después de que optó por un servicio, deberá decidir cómo quiere configurarlo. La configuración depende de las características de rendimiento específicas que desea alcanzar, que difieren para cada categoría de servicio.

    Cuando evalúa las características de rendimiento por los servicios informáticos, un buen lugar para comenzar es buscar sus requisitos informáticos y de memoria:

    • Si utiliza informática basada en máquinas virtuales, memoria y CPU se ven afectadas por el tamaño de su instancia (por ejemplo, t3.small frente a t3.xlarge) y la familia de instancias (por ejemplo, r3.small frente a c5.small)
    • Si utiliza informática basada en contenedores, memoria y CPU se pueden configurar individualmente
    • Si utiliza informática sin servidor, solo se puede configurar directamente la memoria; el valor de la informática (así como otros recursos del sistema) aumenta linealmente a la cantidad de memoria disponible

    Tenga en cuenta que, en función de la carga de trabajo, existen restricciones de recursos adicionales que podrían afectarlo, como la capacidad de la red y la disponibilidad de ciertos recursos como el almacenamiento de la instancia.

    Cuando evalúe la característica de rendimiento para los servicios de almacenamiento, tenga en cuenta sus requisitos de latencia, rendimiento e IOPS:

    • Si utiliza un servicio de almacenamiento en bloque
      • La latencia se ve afectada por la selección del tipo de volumen (por ejemplo, unidad de estado sólido frente a unidad de disco duro)
      • El rendimiento es proporcional al tamaño del volumen para la mayoría de tipos de volúmenes
      • La capacidad de IOPS es proporcional al tamaño del volumen para la mayoría de los tipos de volumen
    • Si utiliza un servicio de sistema de archivos
      • La latencia y las IOPS se ven afectadas por su elección de modos de rendimiento
      • El rendimiento se ve afectado por su opción de capacidad de rendimiento aprovisionado
    • Si utiliza un almacenamiento de objetos
      • La latencia se ve afectada por la distancia geográfica al punto de enlace del bucket
      • El rendimiento se ve afectado por el uso del rendimiento optimizado de las API, como carga de múltiples partes
      • IOPS no es configurable
    • Si utiliza almacenamiento de archivo
      • La latencia se ve afectada por la distancia geográfica al punto de enlace del bucket y la elección del método de recuperación
      • El rendimiento se ve afectado por el uso del rendimiento optimizado de las API, como carga de múltiples partes
      • IOPS no es configurable

    Cuando evalúe la característica de rendimiento para los servicios de base de datos, tenga en cuenta los requisitos de recursos (por ejemplo, CPU, memoria, almacenamiento, etc.):

    • Si utiliza una base de datos relacional
      • Las capacidades de recursos están determinadas por su elección de instancia EC2
    • Si utiliza una base de datos no relacional, como DynamoDB
    • Si utiliza una solución de almacenamiento de datos como Redshift
      • Las capacidades de recursos están determinadas por su elección de la instancia EC2 subyacente
    • Si utiliza una solución indexada, como Elasticsearch Service
      • Las capacidades de recursos están determinadas por su elección de instancia EC2

     

    Conclusiones

    • AWS tiene muchos servicios y muchas maneras de alcanzar los resultados
    • La implementación de una carga de trabajo en AWS implica la selección de servicios mediante categorías de informática, almacenamiento, base de datos y red
    • En cada categoría puede seleccionar el tipo correcto de servicio en función de su caso de uso
    • En cada tipo, puede seleccionar el servicio específico en función de su grado de administración deseado
    • En cada servicio, puede seleccionar la configuración específica en función de las características de rendimiento que desea lograr
     

    Más información

  • Escalado

    Si bien elegir el servicio correcto es clave para comenzar, elegir como escala es importante para el rendimiento continuo.

    AWS posee dos medios primarios de escalado:

    1. Escalado vertical
    2. Escalado horizontal


    Escalado vertical

    El escalado vertical implica la actualización de la informática subyacente a un tipo de instancia más grande. Por ejemplo, supongamos que ejecuta una instancia t3.small. El escalado vertical de esta instancia puede ser actualizarla a t3.large.

    El escalado vertical suele ser más fácil de implementar ya que lo puede hacer sin que el servicio esté en un clúster. La desventaja es que se encuentra con un límite superior mucho más bajo (igual al tamaño máximo de la instancia de informática) en comparación con el escalado horizontal. También representa un punto único de error porque la interrupción de la instancia puede resultar en que el servicio no esté disponible.

     

    Escalado horizontal

    El escalado horizontal implica aumentar el número de instancias subyacentes. Por ejemplo, supongamos que ejecuta una instancia t3.small. El escalado horizontal de esta instancia implicaría el aprovisionamiento de dos instancias t3.small adicionales.

    El escalado horizontal implica más sobrecarga en la implementación. Esto es porque necesita un servicio proxy para direccionar el tráfico a su flota de servicios. También necesita llevar a cabo comprobaciones de estado para eliminar las instancias defectuosas del grupo de direccionamiento, así como también seleccionar un algoritmo de direccionamiento específico que sea óptimo para la carga de trabajo. A cambio, obtendrá un servicio mucho más resistente que puede escalar a límites más altos en comparación con su contraparte de escalado vertical.


    Conclusiones

    • El escalado vertical es más sencillo operativamente, pero representa un riesgo de disponibilidad y posee límites más bajos
    • El escalado horizontal requiere más sobrecarga, pero viene con mucha mejor fiabilidad y límites mucho más altos
     

    Más información

Conclusión

En este módulo, aprendió sobre el pilar de la eficacia del rendimiento de AWS. Aprendió sobre el modelo mental de tratar a sus servidores como ganado y no como mascotas. Aprendió cómo elegir el servicio correcto, así como también su configuración, en función de los objetivos de rendimiento. Aprendió sobre los servicios de escalado y las compensaciones entre el escalado vertical y el horizontal.

 

Más información

Fiabilidad

El pilar de fiabilidad se centra en cómo puede crear servicios que son resistentes a las interrupciones de infraestructura y servicio. Al igual que con la eficacia del rendimiento, mientras la nube le proporciona los medios para crear servicios resistentes que pueden soportar la interrupción, requiere que diseñe los servicios con la fiabilidad en mente.


Modelo mental

A la hora de pensar en la fiabilidad en la nube, es útil pensar en términos de radio de alcance. Se puede pensar en el radio de alcance como el impacto máximo que se puede soportar en caso de un error del sistema. Para crear sistemas fiables, se busca minimizar el radio de alcance de cualquier componente individual.

 

Conceptos

Cuando se piensa en términos del radio de alcance, el problema del error ya no es una cuestión de si va a ocurrir, sino de cuándo va a suceder. Para afrontar un error cuando ocurre, se pueden utilizar las siguientes técnicas para limitar el radio de alcance:

  1. Aislamiento de errores
  2. Límites


  • Aislamiento de errores

    El aislamiento de errores limita el radio de alcance de un incidente mediante el uso de componentes independientes redundantes que se separan a través de zonas de aislamiento de errores. Las zonas de aislamiento de errores contienen el impacto de cualquier error en el área dentro de la zona.

    AWS tiene zonas de aislamiento de errores en tres niveles:

    1. Recurso y solicitud
    2. Zona de disponibilidad
    3. Región

     

    Recurso y solicitud

    Los servicios de AWS dividen todos los recursos y solicitudes en una dimensión determinada, como el ID del recurso. A estas particiones se las conoce como celdas. Las celdas están diseñadas para ser independientes y contener los errores dentro de una sola. En segundo plano, AWS utiliza técnicas como la partición aleatoria para limitar el radio de alcance. Todo esto sucede de forma transparente cada vez que se realiza una solicitud o se crea un recurso y no se requiere ninguna acción adicional de su parte.


    Zona de disponibilidad

    Una zona de disponibilidad (AZ) de AWS es una instalación completamente independiente con capacidades dedicadas a la energía, el servicio y la red. Se encuentran geográficamente distantes de otras AZ para evitar errores relacionados con peligros del entorno, como incendios e inundaciones.

    El aislamiento de errores se logra a nivel de AZ mediante la implementación de instancias redundantes del servicio a través de diversas AZ. Hacerlo significa que un evento de energía en una AZ no afectará el tráfico en otra AZ.

    Y una nota sobre la latencia: a pesar de estar geográficamente separadas, las AZ están situadas lo suficientemente cerca unas de otras como para que la latencia de la red entre ellas sea mínima. Esto hace posible que ciertas características, como la replicación síncrona de datos, funcionen entre las AZ.


    Región

    Una región de AWS proporciona el aislamiento definitivo. Cada región es un centro de datos completamente autónomo, compuesto por dos o más AZ. El aislamiento de errores se consigue a nivel de región mediante la implementación de copias redundantes de los servicios en diferentes regiones de AWS (esto es incluso lo que AWS hace con sus propios servicios).

    Considere la posibilidad de implementar en diversas regiones si requiere niveles de disponibilidad muy altos. Tenga en cuenta que el funcionamiento de un servicio en diversas regiones tiene gastos generales considerables debido a la ausencia de una infraestructura compartida entre ellas. Hay servicios y características que pueden ayudarlo con las construcciones de regiones múltiples. Por ejemplo, puede usar Route53, el servicio DNS escalable de AWS, para enrutar el tráfico entre diferentes regiones. También puede utilizar características como las tablas globales de DynamoDB y la replicación entre regiones de S3 para replicar sus datos en todas las regiones.


    Conclusiones

    • Utilice zonas de aislamiento de errores para limitar el radio de alcance de las interrupciones del servicio o la infraestructura
    • El aislamiento de errores a nivel de recursos y solicitudes está incorporado en el diseño de cada servicio de AWS y no requiere acciones adicionales de su parte
    • El aislamiento de errores a nivel de AZ se logra mediante la implementación de los servicios a través de diversas AZ, lo que puede hacerse con un impacto mínimo de latencia
    • El aislamiento de errores a nivel de región se logra por medio de la implementación de los servicios a través de diversas regiones, lo que requiere una sobrecarga operacional considerable


    Más información

  • Límites

    Los límites son restricciones que pueden aplicarse para proteger a los servicios de una carga excesiva. Son un medio eficaz para limitar el radio de alcance tanto de incidentes externos (por ejemplo, un ataque DDoS) como internos (por ejemplo, una configuración incorrecta del software).

    Los servicios de AWS tienen límites específicos de servicio por cuenta y por región. A estos límites también se los conoce como cuotas de servicio. Estas son los valores máximos para ciertos recursos, acciones y elementos de su cuenta de AWS.

    Existen dos tipos de límites:

    • límites blandos que se pueden aumentar si se solicita un aumento a AWS
    • límites duros que no se pueden aumentar

    Cada servicio tiene límites diferentes. Para llevar un seguimiento de sus límites y solicitar aumentos, puede utilizar el servicio Service Quotas.

    Es importante monitorear los límites de servicio y saber cuándo se acerca al suyo a fin de evitar una interrupción. Para algunos recursos, como las ejecuciones simultáneas de Lambda, es posible realizar un seguimiento a través de CloudWatch. A otros recursos, como la cantidad de instancias EC2, se los deben rastrear en forma manual o por medio de scripts. Puede utilizar el servicio AWS Trusted Advisor para hacer un seguimiento de los límites si tiene un plan de soporte comercial o de soporte empresarial. Herramientas de código abierto como awslimitchecker también pueden ser utilizadas para automatizar el proceso.


    Conclusiones

    • Los límites son restricciones que pueden aplicarse para proteger a un servicio de una carga excesiva
    • Se pueden realizar seguimientos y administrar los límites de servicio de AWS mediante el servicio Service Quota
    • Hay límites blandos que se pueden aumentar y límites duros que no
    • Monitoree los límites de los servicios en uso y planifique los aumentos de los límites en consecuencia para evitar la interrupción del servicio


    Más información

Conclusión

En este módulo, aprendió sobre el pilar de fiabilidad de AWS. Aprendió acerca del modelo mental para considerar las operaciones en términos de radio de alcance. Aprendió a utilizar las zonas de aislamiento de errores a fin de limitar el radio de alcance. Aprendió sobre los límites de servicios y cómo aumentar los suyos para evitar una interrupción.

 

Más información

Excelencia operativa

El pilar de excelencia operativa se centra en cómo puede mejorar de manera continua su habilidad para ejecutar sistemas, crear mejores procedimientos y obtener información.


Modelo mental

A la hora de pensar en la excelencia operativa en la nube, es útil pensarla en términos de automatización.

El error humano es la principal causa de defectos e incidentes operativos. Cuantas más operaciones automatizadas, menos probabilidades de error humano.

Además de evitar errores, la automatización ayuda a mejorar constantemente los procesos internos. Estos promueven un conjunto de prácticas recomendadas recurrentes que se pueden implementar en toda la organización.


Conceptos

Cuando piensa en las operaciones como automatización, debe centrar la atención en las áreas que actualmente requieren la mayor parte del trabajo manual y que podrían conllevar el mayor nivel de error. También es fundamental implementar un proceso mediante el que se pueda supervisar, analizar y mejorar el trabajo operativo.

Nos centraremos en los siguientes dos conceptos de excelencia operativa:

  1. Infraestructura como código
  2. Observabilidad


  • Infraestructura como código

    Infraestructura como código (IaC) es el proceso de administración de la infraestructura mediante archivos de configuración de lectura automática. La IaC es la base que permite automatizar la infraestructura.

    En lugar de aprovisionar servicios manualmente, se crean plantillas que describen los recursos que desea. La plataforma de IaC se encarga de aprovisionar y configurar los recursos por usted.

    La IaC ofrece una forma declarativa y automatizada de aprovisionar infraestructura. Permite aplicar a la infraestructura las mismas herramientas (p. ej., Git) y procesos (p. ej., revisión de código) que ya aplica al código.

    La IaC en AWS implementó tradicionalmente mediante el servicio CloudFormation . CloudFormation requiere que declare los recursos mediante JSON o YAML. Si estos lenguajes de configuración no son de su interés, AWS también proporciona el Cloud Development Kit (CDK) que le permite crear plantillas de CloudFormation con lenguajes de programación nativos como JavaScript, Python y Java.

     

    Conclusiones

    • La IaC es el proceso de administración de la infraestructura mediante archivos de configuración de lectura automática
    • La IaC es una forma declarativa y automatizada de aprovisionar infraestructura
    • Permite aplicar a la infraestructura las mismas herramientas y procesos que ya aplica al código
    • Utilice servicios como CloudFormation y CDK para implementar la IaC en AWS
     

    Más información

  • Observabilidad

    La observabilidad es el proceso de medición del estado interno del sistema. Por lo general se realiza con el objetivo de optimizarlo para que alcance un estado final deseado.

    Cuando se trata de excelencia operativa, no se puede mejorar lo que no se mide. Crear una base sólida de observabilidad posibilita conocer el impacto de la automatización en el sistema y mejorarlo continuamente.

    Implementar la observabilidad incluye los siguientes pasos:

    1. Recopilación
    2. Análisis
    3. Acción


    Recopilación

    La recopilación es el proceso mediante el que se suman todas las métricas necesarias para evaluar el estado de un sistema.

    Estas métricas se dividen en las siguientes categorías:

    • Métricas a nivel de infraestructura
      • Las emite automáticamente servicios de AWS y las recopila CloudWatch
      • Algunos servicios también emiten registros estructurados que se pueden habilitar y recopilar con CloudWatch Logs
    • Métricas a nivel de aplicación
    • Métricas a nivel de cuenta
      • Las registra su cuenta de AWS y las recopila el servicio CloudTrail


    Análisis

    Para analizar las métricas recopiladas, puede utilizar una de las numerosas soluciones de bases de datos y análisis que ofrece AWS.

    La elección de la solución adecuada dependerá del caso de uso:

    • Para analizar los registros almacenados en CloudWatch Logs, considere usar CloudWatch Logs Insight, un servicio que le permite buscar y analizar de manera interactiva sus datos de registro de Cloudwatch
    • A fin de analizar los registros almacenados en S3, considere utilizar Athena, un servicio de consulta sin servidor
    • A fin de analizar datos estructurados, considere utilizar RDS, un servicio de base de datos relacional administrado
    • A fin de analizar grandes cantidades de datos estructurados, considere utilizar RedShift, un servicio de almacenamiento de datos en petabytes
    • A fin de analizar datos basados en registros, considere utilizar Elasticsearch Service, una versión administrada de Elasticsearch, el conocido motor de análisis de código abierto

     

    Acción

    Una vez que haya recopilado y analizado sus métricas, puede utilizarlas para lograr un resultado o proceso específico.

    Los siguientes son ejemplos de resultados y procesos:

    • Monitoreo y alarmas
      • Puede utilizar las Alarmas de CloudWatch para recibir notificaciones cuando un sistema haya incumplido el umbral de seguridad de una métrica específica
      • esta alarma puede activar un mecanismo manual o automático de mitigación.
    • Paneles
      • Con los Paneles de Cloudwatch puede crear paneles de sus métricas
      • Con estos paneles puede registrar y, con el tiempo, mejorar el rendimiento del servicio
    • Decisiones basadas en datos
      • A fin de tomar decisiones basadas en datos, puede registrar los KPI de rendimiento y del negocio

     

    Conclusiones

    • La observabilidad es el proceso de medición del estado interno del sistema para lograr un estado final deseado
    • La observabilidad consiste en recopilar métricas, analizarlas y tomar medidas en torno a ellas
    • Puede recopilar métricas en los niveles de servicio, aplicación y cuenta
    • Si necesita analizar métricas, puede hacerlo mediante servicios como CloudWatch Log Insight, Athena, Elasticsearch Service, RDS y Redshift
    • Puede tomar medidas en torno a las métricas por medio del monitoreo, la creación de alarmas y paneles y el seguimiento de KPI de rendimiento y del negocio

     

    Más información

Conclusión

En este módulo, aprendió acerca del pilar de excelencia operativa. Aprendió acerca del modelo mental de ver las operaciones en términos de automatización. Aprendió acerca de la IaC y cómo se la puede utilizar para aprovisionar servicios automáticamente mediante las mismas herramientas y procesos que actualmente utiliza con el código. Aprendió acerca de la observabilidad y cómo recopilar las métricas, analizarlas y tomar medidas en torno a ellas a fin de mejorar continuamente el trabajo operativo.

 

Más información

Optimización de costos

El pilar de optimización de costos ayuda a lograr resultados empresariales mientra se minimizan los costos.


Modelo mental

Cuando pensamos en la optimización de costos en la nube, es útil considerar los gastos de la nube en términos de los gastos operativos en lugar de inversión de capital. El gasto operativo es un modelo de pago por uso continuo, mientras que la inversión de capital es un modelo de compra única.

Los costos tradicionales de TI en los centros de datos en las instalaciones fueron mayormente inversión de capital. Paga por toda la capacidad anticipadamente, sin tener en cuenta si terminó de utilizarla. La compra de nuevos servidores puede ser un proceso extenso que implicó obtener certificaciones de varias partes. Esto es porque los costos de los gastos operativos fueron generalmente significativos y los errores costosos. Después de haber hecho una compra, los servidores reales pueden demorar semanas en comenzar.

En AWS, los costos son gastos operativos. Paga sobre una base continua por la capacidad que utiliza. Los ingenieros pueden aprovisionar nuevos servidores en tiempo real sin necesidad de un proceso de aprobación extenso. Esto sucede porque los costos de los gastos operativos son mucho menores y se pueden revertir si los requisitos cambian. Porque paga solo por lo que utiliza, cualquier exceso de capacidad se puede detener e interrumpir de manera sencilla. Cuando decide utilizar un servicio, se puede aprovisionar en cuestión de segundos y minutos.


Conceptos

El traslado de un modelo de inversión de capital a uno de gasto operativo cambia totalmente el enfoque del costo de la infraestructura. En lugar de grandes pagos iniciales por costos fijos, piense en pequeños gastos variables continuos.

El modelo de pago por uso introduce los siguientes cambios al proceso de optimización de costos:

  1. Pago por uso
  2. Optimización de costos del ciclo de vida


  • Pago por uso

    Los servicios de AWS poseen un modelo de pago por uso en el que solo paga por la capacidad que utiliza. A continuación, hay cuatro maneras comunes de optimizar los gastos de la nube cuando paga por uso:

    1. Tamaño correcto
    2. Tecnología sin servidor
    3. Reservas
    4. Instancias de spot


    Tamaño correcto

    El tamaño correcto hace referencia a la coincidencia entre el aprovisionamiento del servicio y la configuración para la carga de trabajo. Para los servicios basados en EC2, esto significa elegir la familia y tamaño de instancia correcta. Si los recursos informáticos están mayormente inactivos, considere utilizar una instancia EC2 más pequeña. Si la carga de trabajo requiere muchos recursos del sistema concretos, considere cambiar a una familia de instancias optimizada para ese recurso.

    Para ayudar en este proceso, puede utilizar AWS Compute Optimizer a fin de obtener sugerencias de dimensionamiento óptimo de EC2 en función de las métricas del sistema pasado.


    Tecnología sin servidor

    Cuando utiliza tecnologías sin servidor, como Lambda, solo paga por lo que utiliza. Si no se ejecuta Lambda, no se le cobrará. La tecnología sin servidor es el mejor ejemplo de pago por uso. Cuando el caso de uso lo permite, elegir tecnología sin servidor puede ser la forma más rentable de crear su servicio.


    Reservas

    La solicitud de reservas implica comprometerse a pagar por cierta cantidad de capacidad a cambio de un descuento significativo. Para EC2, puede dar lugar a un descuento del 72 % para la informática.

    A fin de solicitar reservas para su informática, puede utilizar Savings Plans. Puede registrarse por un periodo de 1 o 3 años y el compromiso de utilizar una cantidad específica de cómputos a fin de obtener ahorros mediante EC2, Fargate y Lambda.

    Tenga en cuenta que las reservas no son exclusivas para EC2, ya que también puede solicitarlas para otros servicios, como RDS, DynamoDB y CloudFront.


    Instancias de spot

    Las instancias de spot de EC2 le permiten aprovechar la capacidad de EC2 que no utiliza para ejecutar instancias con hasta un 90 % de descuento cuando se las compara con precios bajo demanda. Esto puede producir enormes ahorros para sus cargas de trabajo tolerantes a errores.

    La compensación cuando se utiliza una instancia de spot es que EC2 puede reclamar la capacidad en cualquier momento. La aplicación obtendrá un aviso de finalización de dos minutos antes de que suceda.


    Conclusiones

    • Los servicios de AWS se pagan por lo que usa: se le cobrará por la capacidad que utiliza
    • Puede reestructurar las instancias a fin de ahorrar dinero en servicios que no coinciden con su carga de trabajo
    • Puede utilizar tecnologías sin servidor para garantizar que solo pague cuando los clientes utilizan el servicio
    • Puede usar reservaciones para obtener descuentos a cambio de un compromiso inicial
    • Puede utilizar las instancias de spot para obtener descuentos por ejecutar cargas de trabajo tolerantes a errores


    Más información

  • Optimización de costos del ciclo de vida

    La optimización de costos del ciclo de vida es el proceso continuo para mejorar el gasto en la nube a lo largo del tiempo.

    Consiste en el siguiente flujo de trabajo de tres pasos:

    1. Analizar
    2. Seguir
    3. Optimizar


    Analizar

    Antes de que pueda optimizar el gasto en la nube, primero necesita comprender de dónde viene.

    AWS Cost Explorer lo ayuda a visualizar y revisar el gasto de la nube a lo largo del tiempo. Puede desglosar el gasto mediante distintas facetas, como servicio y categoría. Utilice Cost Explorer para obtener información general de alto nivel, así como también informes detallados sobre su factura.

    Si solicita datos más minuciosos, puede obtener los conceptos cada hora con el informe de costo y uso de AWS.


    Seguir

    Cuando tenga información del gasto general de la nube, puede comenzar a agruparlo según las dimensiones que le interesen. Esto se hace con las etiquetas de asignación de costos. Es necesario que active cada etiqueta que desea seguir.

    Los siguientes son ejemplos comunes de categorías de etiqueta:

    • ID de la aplicación: identifica los recursos que se relacionan con una aplicación específica para un seguimiento sencillo del gasto de cambio y desvío al final del proyecto.
    • Automatización de inscripción o deshabilitación: indica si un recurso se debe incluir en una actividad automatizada, como las instancias de inicio, detención o redimensionamiento.
    • Centro de costo o unidad empresarial: identifica el centro de costo o unidad empresarial asociado con un recurso, normalmente para la asignación y seguimiento de costos.
    • Propietario: identifica quién es el responsable de los recursos. Normalmente es el propietario técnico. Si es necesario, puede agregar una etiqueta de propietario empresarial separada. Puede especificar el propietario como una dirección de correo electrónico. Con una dirección de correo electrónico se admiten notificaciones automatizadas tanto para los propietarios técnicos como empresariales según se requiera (p. ej. si el recurso es un candidato para la elasticidad o tamaño correcto).

    Además de las etiquetas, puede utilizar AWS Budgets a fin de crear objetivos presupuestarios. Con Budgets, puede monitorear su gasto mediante las dimensiones que les interesan. Budgets sigue y crea previsiones para su gasto de AWS actual según los filtros establecidos en el lugar.


    Optimizar

    Una vez que revisó y controló su gasto, puede optimizarlo. La optimización del gasto implica la implementación de técnicas sobre las que hablamos en Pago por uso. La optimización usualmente se realiza como parte de un objetivo presupuestario general.

    Los siguientes son ejemplos de objetivos de optimización:

    • Porcentaje de instancias EC2 que están cubiertas por un plan de ahorro de costos: su organización debe aspirar a una cobertura del 80 % al 90 %
    • Porcentaje de recursos en espera: la definición de porcentaje inactivo y exacto variará según su empresa


    Conclusiones

    • La optimización de costos del ciclo de vida es un proceso continuo para mejorar el gasto en la nube a lo largo del tiempo
    • La optimización de costos del ciclo de vida consiste en revisar, seguir y optimizar el gasto
    • La revisión del gasto implica el uso de herramientas, como Cost Explorer e informes de costo y uso a fin de comprender el gasto
    • El seguimiento del gasto implica el uso de presupuestos y etiquetas de asignación de costo a fin de filtrar los datos junto con las dimensiones relevantes para su empresa
    • La optimización del gasto implica el uso de técnicas de la sección anterior como parte de un objetivo presupuestario general


    Más información

Conclusión

En este módulo, aprendió acerca del pilar de optimización de costos. Aprendió acerca de la aplicación de un modelo centrado en el gasto operativo para el gasto de la nube. Aprendió acerca de las técnicas de optimización de costos, como las instancias de spot, reservas, sin servidor y de tamaño correcto. Aprendió acerca de revisión, seguimiento y optimización de su presupuesto con servicios, como Cost Explorer, etiquetas y presupuestos.

 

Más información

AWS GovCloud (EE. UU.)

Esta sección es para aquellos cuyas cargas de trabajo deben cumplir los requisitos de FedRAMP, SRG de DoD, ITAR, CJIS u otros requisitos de conformidad estrictos, o contienen datos designados como información no clasificada controlada (CUI).

AWS GovCloud (EE. UU.) ayuda a abordar requisitos de conformidad específicos y las necesidades regulatorias de las agencias del gobierno de los Estados Unidos a nivel federal, estatal y local, así como de organizaciones comerciales de los Estados Unidos en los sectores como el aeroespacial, la fabricación para la defensa, la aplicación de la ley, la sanidad, los servicios financieros, la energía, y otros sectores regulados de forma estricta. Diseñadas para alojar datos confidenciales y cargas de trabajo reguladas en la nube, las regiones de AWS GovCloud (EE. UU.) son regiones aisladas de AWS operadas por empleados que son ciudadanos de los Estados Unidos sobre territorio estadounidense.

AWS GovCloud (EE. UU.) proporciona a los clientes del gobierno y sus socios la flexibilidad para diseñar la arquitectura de soluciones seguras en la nube que cumplen con la referencia de FedRAMP, la política de seguridad de los sistemas de información de la justicia penal del Departamento de Justicia, las regulaciones del tráfico internacional de armas (ITAR), las regulaciones de la administración de las exportaciones (EAR), la Guía de requisitos de seguridad de informática en la nube (SRG) del Departamento de Defensa (DoD) para los niveles de impacto 2, 4 y 5; FIPS 140-2; IRS-1075, y otros regímenes de conformidad.

Desde información no clasificada controlada (CUI), información de identificación personal (PII), registros médicos confidenciales de pacientes y datos financieros hasta datos de la aplicación de la ley, datos controlados de exportación y otras formas de CUI, las regiones de AWS GovCloud (EE. UU.) pueden ayudar a los clientes a abordar la conformidad en cada etapa del traspaso a la nube.

 

Más información

¡Felicitaciones!

Ahora ha completado el curso de aspectos fundamentales de AWS. En este curso, aprendió lo siguiente:

  • Los cinco pilares del Marco de Buena Arquitectura de AWS
  • Modelos mentales importantes que representan una forma de pensamiento nativa en la nube sobre los cinco pilares
  • Conceptos claves dentro de cada uno de los cinco pilares

En este punto, aprendió los aspectos fundamentales de la creación de servicios seguros, eficientes en el rendimiento, fiables, excelentes desde el punto de vista operativo y con costos optimizados en la nube. Apenas rozamos la superficie sobre lo que hay para saber, ahora tiene un punto de partida sólido para el resto de su trayecto en AWS. Ahora que completó el curso de aspectos fundamentales de AWS, avance y aplique lo que aprendió para crear su próximo gran servicio en AWS.