**Ayude a mejorar esta página**
Para contribuir a esta guía del usuario, elija el enlace **Edit this page on GitHub** que se encuentra en el panel derecho de cada página.
# Creación de nodos con AMI de Amazon Linux optimizadas
Amazon Elastic Kubernetes Service (Amazon EKS) proporciona imágenes de máquina de Amazon (AMI) especializadas optimizadas para ejecutar nodos de trabajo de Kubernetes. Estas AMI de Amazon Linux (AL) optimizadas para EKS vienen preconfiguradas con componentes esenciales, como `kubelet`, Autenticador de AWS IAM y `containerd` para garantizar la seguridad y una integración sin problemas en sus clústeres. En esta guía, se detallan las versiones de AMI disponibles y describe las opciones especializadas para la computación acelerada y las arquitecturas basadas en Arm.
## Consideraciones
+ Puede realizar un seguimiento de los eventos de seguridad o privacidad de Amazon Linux en el [Centro de seguridad de Amazon Linux](https://alas.aws.amazon.com/) seleccionando la pestaña de la versión que desee. También puede suscribirse a la fuente RSS correspondiente. Los eventos de seguridad y privacidad incluyen información general del problema, qué paquetes están afectados y cómo actualizar las instancias para corregir el problema.
+ Antes de implementar una AMI de Arm o acelerada, revise la información de [AMI de Amazon Linux aceleradas optimizadas para Amazon EKS](#gpu-ami) y [AMI de Amazon Linux de Arm optimizadas para Amazon EKS](#arm-ami).
+ Las instancias `P2` de Amazon EC2 no son compatibles con Amazon EKS ya que requieren la versión 470 del controlador `NVIDIA` o anterior.
+ A partir de la versión `1.30` o posterior, todos los grupos de nodos administrados recién creados utilizarán automáticamente AL2023 como sistema operativo de nodos de forma predeterminada.
## AMI de Amazon Linux aceleradas optimizadas para Amazon EKS
Las AMI de Amazon Linux (AL) aceleradas optimizadas para Amazon EKS se crean sobre las AMI de Amazon Linux optimizadas para EKS estándar. Están configuradas para actuar como imágenes opcionales para que los nodos de Amazon EKS admitan cargas de trabajo basadas en GPU, [Inferentia](https://aws.amazon.com/machine-learning/inferentia/) y [Trainium](https://aws.amazon.com/machine-learning/trainium/).
Para obtener más información, consulte [Uso de AMI aceleradas optimizadas para EKS para instancias de GPU](ml-eks-optimized-ami.md).
## AMI de Amazon Linux de Arm optimizadas para Amazon EKS
Las instancias Arm ofrecen un importante ahorro de costos para aplicaciones de escalado horizontal y aplicaciones basadas en Arm, como servidores web, microservicios en contenedores, flotas de almacenamiento en caché y almacenes de datos distribuidos. Al agregar nodos de Arm al clúster, tenga en cuenta las siguientes consideraciones.
+ Si el clúster se implementó antes del 17 de agosto de 2020, debe realizar una actualización única de los manifiestos complementarios de clúster críticos. Esto es para que Kubernetes pueda extraer la imagen correcta para cada arquitectura de hardware que se utilice en el clúster. Para obtener más información acerca de la actualización de complementos de clúster, consulte [Paso 1: preparación para la actualización](update-cluster.md#update-existing-cluster). Si implementó el clúster a partir del 17 de agosto de 2020, significa que su CoreDNS, `kube-proxy` y los complementos CNI de Amazon VPC para los complementos de Kubernetes ya son aptos en múltiples arquitecturas.
+ Las aplicaciones implementadas en los nodos de Arm deben compilarse para Arm.
+ Si tiene algún DaemonSet que está implementado en un clúster existente o desea implementarlos en un clúster nuevo en el que también quiera implementar nodos de Arm, compruebe que el DaemonSet se pueda ejecutar en todas las arquitecturas de hardware del clúster.
+ Puede ejecutar grupos de nodos de Arm y grupos de nodos x86 en el mismo clúster. Si lo hace, considere la posibilidad de implementar imágenes de contenedor de varias arquitecturas en un repositorio de contenedores como Amazon Elastic Container Registry y, a continuación, agregar selectores de nodo a los manifiestos para que Kubernetes sepa en qué arquitectura de hardware se puede implementar un pod. Para obtener más información, consulte [Introducir una imagen de varias arquitecturas](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-multi-architecture-image.html) en la *Guía del usuario de Amazon ECR* y en la publicación del blog [Introducing multi-architecture container images for Amazon ECR](https://aws.amazon.com/blogs/containers/introducing-multi-architecture-container-images-for-amazon-ecr).
## Más información
Para obtener más información sobre el uso de las AMI de Amazon Linux optimizadas para Amazon EKS, consulte las siguientes secciones:
+ Para usar Amazon Linux con grupos de nodos administrados, consulte [Simplificación del ciclo de vida de los nodos con grupos de nodos administrados](managed-node-groups.md).
+ Para lanzar nodos autoadministrados de Amazon Linux, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md).
+ Para obtener información sobre la versión, consulte [Obtención de información acerca de la versión de la AMI de Amazon Linux](eks-linux-ami-versions.md).
+ Para recuperar los ID más recientes de las AMI de Amazon Linux optimizadas para Amazon EKS, consulte [Obtención de los ID de AMI de Amazon Linux recomendados](retrieve-ami-id.md).
+ Para los scripts de código abierto que se utilizan para crear las AMI optimizadas para Amazon EKS, consulte [Creación de una AMI de Amazon Linux optimizada para EKS personalizada](eks-ami-build-scripts.md).
# Actualización de Amazon Linux 2 a Amazon Linux 2023
**aviso**
Amazon EKS dejó de publicar las AMI optimizadas para EKS de Amazon Linux 2 (AL2) el 26 de noviembre de 2025. Las AMI basadas en AL2023 y Bottlerocket para Amazon EKS están disponibles para todas las versiones de Kubernetes compatibles, lo que incluye la versión 1.33 y posteriores.
AL2023 es un sistema operativo basado en Linux diseñado para proporcionar un entorno seguro, estable y de alto rendimiento para las aplicaciones en la nube. Es la próxima generación de Amazon Linux de Amazon Web Services y está disponible en todas las versiones compatibles de Amazon EKS.
AL2023 ofrece varias mejoras con respecto al AL2. Para obtener una comparación completa, consulte [Comparación de AL2 y Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/ug/compare-with-al2.html) en la *Guía del usuario de Amazon Linux 2023*. Se han añadido, actualizado y eliminado varios paquetes de AL2. Se recomienda encarecidamente probar las aplicaciones con AL2023 antes de realizar la actualización. Para ver una lista de todos los cambios de paquetes en AL2023, consulte [Cambios de paquetes en Amazon Linux 2023](https://docs.aws.amazon.com/linux/al2023/release-notes/compare-packages.html) en las *Notas de la versión de Amazon Linux 2023*.
Además de estos cambios, debe tener en cuenta lo siguiente:
+ AL2023 presenta un nuevo proceso de inicialización de nodos `nodeadm` que utiliza un esquema de configuración YAML. Si utiliza grupos de nodos autoadministrados o una AMI con una plantilla de lanzamiento, ahora tendrá que proporcionar metadatos del clúster adicionales de forma explícita cuando cree un nuevo grupo de nodos. A continuación, se muestra un [ejemplo](https://awslabs.github.io/amazon-eks-ami/nodeadm/) de los parámetros mínimos necesarios, en los que ahora se necesitan `apiServerEndpoint`, `certificateAuthority` y el servicio de `cidr`:
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
```
En AL2, los metadatos de estos parámetros se descubrieron a partir de la llamada a la API `DescribeCluster` de Amazon EKS. Con AL2023, este comportamiento ha cambiado, ya que la llamada a la API adicional corre el riesgo de limitarse durante los escalados verticales de nodos a gran escala. Este cambio no le afecta si utiliza grupos de nodos administrados sin una plantilla de lanzamiento o si utiliza Karpenter. Para obtener más información sobre `certificateAuthority` y el servicio `cidr`, consulte [https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html) en la *Referencia de la API de Amazon EKS*.
+ En el caso de AL2023, `nodeadm` también cambia el formato para aplicar los parámetros al `kubelet` para cada nodo que utilice [https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec](https://awslabs.github.io/amazon-eks-ami/nodeadm/doc/api/#nodeconfigspec). En AL2, esto se hizo con el parámetro `--kubelet-extra-args`. Se suele utilizar para agregar etiquetas y taints a los nodos. En el siguiente ejemplo, se muestra cómo aplicar `maxPods` y `--node-labels` al nodo.
```
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: test-cluster
apiServerEndpoint: https://example.com
certificateAuthority: Y2VydGlmaWNhdGVBdXRob3JpdHk=
cidr: 10.100.0.0/16
kubelet:
config:
maxPods: 110
flags:
- --node-labels=karpenter.sh/capacity-type=on-demand,karpenter.sh/nodepool=test
```
+ Se requiere la versión `1.16.2` o posterior de CNI de Amazon VPC para AL2023.
+ De forma predeterminada, AL2023 requiere `IMDSv2`. `IMDSv2` tiene varios beneficios que ayudan a mejorar la postura de seguridad. Utiliza un método de autenticación orientado a la sesión que requiere la creación de un token secreto en una solicitud sencilla de HTTP PUT para iniciar la sesión. El tiempo de validez de un token de sesión puede oscilar entre 1 segundo y 6 horas. Para obtener más información sobre cómo realizar la transición de `IMDSv1` a `IMDSv2`, consulte [Transición a la versión 2 del servicio de metadatos de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-metadata-transition-to-version-2.html) y [Cómo aprovechar todos los beneficios de IMDSv2 e inhabilitar IMDSv1 en toda la infraestructura de AWS](https://aws.amazon.com/blogs/security/get-the-full-benefits-of-imdsv2-and-disable-imdsv1-across-your-aws-infrastructure). Si desea utilizar `IMDSv1`, puede hacerlo si anula de manera manual la configuración mediante las propiedades de inicio de la opción de metadatos de la instancia.
**nota**
Para el `IMDSv2` con AL2023, el recuento de saltos predeterminado para los grupos de nodos administrados puede variar:
Cuando no se utiliza una plantilla de lanzamiento, el valor predeterminado es `1`. Esto significa que los contenedores no tendrán acceso a las credenciales del nodo mediante IMDS. Si necesita acceso del contenedor a las credenciales del nodo, puede hacerlo usando una [plantilla de lanzamiento personalizada de Amazon EC2](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ec2-launchtemplate-metadataoptions.html).
Cuando se utiliza una AMI personalizada en una plantilla de lanzamiento, el valor predeterminado de `HttpPutResponseHopLimit` es `2`. Puede anular manualmente el `HttpPutResponseHopLimit` en la plantilla de lanzamiento.
Como alternativa, puede utilizar [Pod Identity de Amazon EKS](pod-identities.md) para proporcionar credenciales en lugar de `IMDSv2`.
+ AL2023 presenta la siguiente generación de jerarquías de grupos de control unificados (`cgroupv2`). `cgroupv2` se utiliza para implementar un tiempo de ejecución de contenedores y por `systemd`. Si bien AL2023 sigue incluyendo un código que puede hacer que el sistema funcione mediante `cgroupv1`, esta configuración no se recomienda ni se admite. Esta configuración se eliminará por completo en una futura versión importante de Amazon Linux.
+ Se requiere una versión de `eksctl` `0.176.0` o superior para que `eksctl` sea compatible con AL2023.
En el caso de los grupos de nodos administrados que existían con anterioridad, puede realizar una actualización local o una actualización azul/verde, según cómo utilice la plantilla de lanzamiento:
+ Si utiliza una AMI personalizada con un grupo de nodos administrado, puede realizar una actualización local si intercambia el ID de la AMI en la plantilla de lanzamiento. Debe asegurarse de que las aplicaciones y cualquier dato de usuario se transfieran primero a AL2023 antes de llevar a cabo esta estrategia de actualización.
+ Si utiliza grupos de nodos administrados con la plantilla de lanzamiento estándar o con una plantilla de lanzamiento personalizada que no especifica el ID de la AMI, deberá actualizar mediante una estrategia azul/verde. Una actualización azul/verde suele ser más compleja e implica la creación de un grupo de nodos completamente nuevo en el que se especificará AL2023 como tipo de AMI. Luego, será necesario configurar con cuidado el nuevo grupo de nodos para garantizar que todos los datos personalizados del grupo de nodos de AL2 sean compatibles con el nuevo sistema operativo. Una vez que el nuevo grupo de nodos se haya probado y validado con sus aplicaciones, podrá migrar pods del grupo de nodos anterior al nuevo grupo de nodos. Una vez completada la migración, puede eliminar el grupo de nodos anterior.
Si utiliza Karpenter y quiere utilizar AL2023, deberá modificar el campo de `EC2NodeClass` `amiFamily` con AL2023. De forma predeterminada, la desviación está habilitada en Karpenter. Esto significa que, una vez que se haya cambiado el campo `amiFamily`, Karpenter actualizará automáticamente los nodos de trabajo a la AMI más reciente cuando esté disponible.
## Información adicional sobre nodeadm
Al utilizar una AMI optimizada para EKS basada en Amazon Linux 2023 o al crear una AMI personalizada de EKS basada en Amazon Linux 2023 mediante los scripts de Packer proporcionados en el repositorio oficial de GitHub amazon-eks-ami, debe evitar ejecutar explícitamente nodeadm init dentro de los datos de usuario de EC2 o como parte de la AMI personalizada.
Si desea generar un NodeConfig dinámico en los datos de usuario, puede escribir esa configuración en un archivo yaml o json de configuración complementario en `/etc/eks/nodeadm.d`. Estos archivos de configuración se combinarán y se aplicarán al nodo cuando nodeadm init se inicie automáticamente más adelante en el proceso de arranque. Por ejemplo:
```
cat > /etc/eks/nodeadm.d/additional-node-labels.yaml << EOF
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
kubelet:
flags:
- --node-labels=foo=bar
EOF
```
Las AMI optimizadas para EKS basadas en Amazon Linux 2023 ejecutan automáticamente nodeadm init en dos fases mediante servicios de systemd independientes: nodeadm-config se ejecuta antes de la ejecución de los datos de usuario, mientras que nodeadm-run se ejecuta después. El servicio nodeadm-config establece las configuraciones básicas de containerd y kubelet antes de que se ejecuten los datos de usuario. El servicio nodeadm-run ejecuta determinados daemons del sistema y completa cualquier configuración final después de la ejecución de los datos de usuario. Si el comando nodeadm init se ejecuta una vez adicional, mediante los datos de usuario o una AMI personalizada, puede alterar el orden previsto de ejecución, lo que podría generar resultados inesperados, incluida una configuración incorrecta de las interfaces de red elásticas.
# Obtención de información acerca de la versión de la AMI de Amazon Linux
Las AMI de Amazon Linux optimizadas para Amazon EKS están versionadas por la versión de Kubernetes y la fecha de lanzamiento de la AMI en el siguiente formato:
```
k8s_major_version.k8s_minor_version.k8s_patch_version-release_date
```
Cada versión de AMI incluye varias versiones de [kubelet](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/), el kernel de Linux y [containerd](https://containerd.io/). Las AMI aceleradas también incluyen varias versiones del controlador de NVIDIA. Puede encontrar la información de esta versión en [Changelog](https://github.com/awslabs/amazon-eks-ami/blob/main/CHANGELOG.md) en GitHub.
# Obtención de los ID de AMI de Amazon Linux recomendados
Al implementar nodos, puede especificar un ID de una imagen de máquina de Amazon (AMI) optimizada para Amazon EKS previamente creada. Para recuperar un ID de AMI que se ajuste a la configuración deseada, consulte la API del almacén de parámetros de AWS Systems Manager. Al utilizar esta API, se elimina la necesidad de buscar manualmente los ID de AMI optimizados para Amazon EKS. Para obtener más información, consulte [GetParameter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_GetParameter.html). La [entidad principal de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que utiliza debe tener el permiso `ssm:GetParameter` de IAM para recuperar los metadatos de la AMI optimizada para Amazon EKS.
Puede recuperar el ID de imagen de la última AMI de Amazon Linux optimizada para Amazon EKS recomendada con el siguiente comando, que usa el parámetro secundario `image_id`. Realice las siguientes modificaciones en el comando según sea necesario y, a continuación, ejecute el comando modificado:
+ Reemplace `` por una [versión compatible de Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Reemplace *ami-type* por una de las siguientes opciones: Para obtener más información sobre los tipos de instancias de Amazon EC2, consulte [Tipos de instancias de Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html).
+ Use *amazon-linux-2023/x86\$164/standard* para instancias basadas en Amazon Linux 2023 (AL2023) `x86`.
+ Use *amazon-linux-2023/arm64/standard* para instancias ARM AL2023, como las instancias basadas en [AWS Graviton](https://aws.amazon.com/ec2/graviton/).
+ Use *amazon-linux-2023/x86\$164/nvidia* para las instancias aprobadas más recientes de NVIDIA AL2023 basadas en `x86`.
+ Use *amazon-linux-2023/arm64/nvidia* para las instancias aprobadas más recientes de NVIDIA AL2023 basadas en `arm64`.
+ Use *amazon-linux-2023/x86\$164/neuron* para las instancias más recientes de [AWS Neuron](https://aws.amazon.com/machine-learning/neuron/) AL2023.
+ Reemplace `` por una [región de AWS compatible con Amazon EKS](https://docs.aws.amazon.com/general/latest/gr/eks.html) para la que desee el ID de la AMI.
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami///recommended/image_id \
--region --query "Parameter.Value" --output text
```
A continuación, se muestra un comando de ejemplo después de reemplazar los marcadores de posición.
```
aws ssm get-parameter --name /aws/service/eks/optimized-ami/1.31/amazon-linux-2023/x86_64/standard/recommended/image_id \
--region us-west-2 --query "Parameter.Value" --output text
```
Un ejemplo de salida sería el siguiente.
```
ami-1234567890abcdef0
```
# Creación de una AMI de Amazon Linux optimizada para EKS personalizada
**aviso**
Amazon EKS dejó de publicar las AMI optimizadas para EKS de Amazon Linux 2 (AL2) el 26 de noviembre de 2025. Las AMI basadas en AL2023 y Bottlerocket para Amazon EKS están disponibles para todas las versiones de Kubernetes compatibles, lo que incluye la versión 1.33 y posteriores.
Amazon EKS proporciona scripts de creación de código abierto en el repositorio de [especificaciones de creación de la AMI de Amazon EKS](https://github.com/awslabs/amazon-eks-ami) que podrá utilizar para ver las configuraciones de `kubelet`, el tiempo de ejecución y el autenticador de AWS IAM para Kubernetes, así como crear su propia AMI basada en AL desde cero.
Este repositorio contiene el [script de arranque para AL2](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) especializado y la [herramienta nodeadm para AL2023](https://awslabs.github.io/amazon-eks-ami/nodeadm/) que se ejecuta en el momento del arranque. Estos scripts configuran los datos de certificado de la instancia, el punto de conexión del plano de control, el nombre del clúster, etcétera. Estos scripts se consideran el origen de información verdadera para las creaciones de la AMI optimizada para Amazon EKS, de modo que puede seguir el repositorio de GitHub para supervisar los cambios en nuestras AMI.
Al crear AMI personalizadas con las AMI optimizadas para EKS como base, no se recomienda ni se admite ejecutar una actualización del sistema operativo (por ejemplo, `dnf upgrade`) ni actualizar cualquiera de los paquetes de Kubernetes o GPU que se incluyen en las AMI optimizadas para EKS, ya que se corre el riesgo de interrumpir la compatibilidad de los componentes. Si actualiza el sistema operativo o los paquetes que se incluyen en las AMI optimizadas para EKS, se recomienda llevar a cabo pruebas exhaustivas en un entorno de desarrollo o ensayo antes de implementarlas en producción.
Al crear AMI personalizadas para instancias de GPU, se recomienda crear AMI personalizadas independientes para cada familia y generación del tipo de instancia que vaya a ejecutar. Las AMI aceleradas optimizadas para EKS instalan de forma selectiva los controladores y paquetes en tiempo de ejecución en función de la familia y generación del tipo de instancia subyacentes. Para obtener más información, consulte los scripts de AMI de EKS para la [instalación](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/provisioners/install-nvidia-driver.sh) y el [tiempo de ejecución](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2023/runtime/gpu/nvidia-kmod-load.sh).
## Requisitos previos
+ [Instalar la CLI de AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)
+ [Instalar HashiCorp Packer v1.9.4\$1](https://developer.hashicorp.com/packer/downloads)
+ [Instalar GNU Make](https://www.gnu.org/software/make/)
## Inicio rápido
En este inicio rápido, se muestran los comandos para crear una AMI personalizada en su cuenta de AWS. Para obtener más información sobre las configuraciones disponibles para personalizar la AMI, consulte las variables de plantilla en la página [Amazon Linux 2023](https://awslabs.github.io/amazon-eks-ami/usage/al2023/).
### Requisitos previos
Instale el [complemento de Amazon](https://developer.hashicorp.com/packer/integrations/hashicorp/amazon) necesario. Por ejemplo:
```
packer plugins install github.com/hashicorp/amazon
```
### Paso 1. Configure su entorno
Clone o bifurque el repositorio de AMI oficial de Amazon EKS. Por ejemplo:
```
git clone https://github.com/awslabs/amazon-eks-ami.git
cd amazon-eks-ami
```
Compruebe que Packer esté instalado:
```
packer --version
```
### Paso 2. Para crear una AMI de personalizada
A continuación, se muestran ejemplos de comandos para varias AMI personalizadas.
**AMI de NVIDIA AL2 básica:**
```
make k8s=1.31 os_distro=al2 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**AMI de NVIDIA AL2023 básica:**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=nvidia \
nvidia_driver_major_version=560 \
enable_efa=true
```
**AMI de Neuron AL2023 compatible con STIG:**
```
make k8s=1.31 os_distro=al2023 \
enable_accelerator=neuron \
enable_fips=true \
source_ami_id=ami-0abcd1234efgh5678 \
kms_key_id=alias/aws-stig
```
Tras ejecutar estos comandos, Packer hará lo siguiente: \$1 Lanzará una instancia temporal de Amazon EC2. \$1 Instalará los componentes, los controladores y las configuraciones de Kubernetes. \$1 Creará la AMI en su cuenta de AWS.
El resultado esperado debe tener el siguiente aspecto:
```
==> Wait completed after 8 minutes 42 seconds
==> Builds finished. The artifacts of successful builds are:
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
--> amazon-ebs: AMIs were created:
us-west-2: ami-0e139a4b1a7a9a3e9
```
### Paso 3. Vea los valores predeterminados
Para ver los valores predeterminados y las opciones adicionales, ejecute el siguiente comando:
```
make help
```