domingo, 27 de julio de 2014

AWS: Convert T1 instances to T2

AWS released new T2 instance type recently. New instance type only support HVM virtualization. What happen if you have a T1 PVM instance and want to move to T2? Because  PVM virtualization is not supported in T2, you can't directly change instance type using AWS EC2 web console. But you can convert it! To do it, I suggest you to follow next guide.

NOTE: If you are going to use this guide with production instances is highly recommended to create an image before proceed.

The procedure has been tested using Amazon Linux instances, but should work with any other Linux flavors: Ubuntu, SUSE, Redhat, etc.

Imagine you have one T1 micro PVM instance with next characteristics:




First, login to the instance and ensure is updated. If not, I recommend you to update the instance to the latest stable version using apt-get/yum commands:




Wait until instance is updated and reboot, if needed. Verify everything is correct. I´m also going to create a file named info.txt just to know this is the root volume associated to my T1 PVM instance:




Now, launch a new T2 instance. Don't forget to:
  • Select a compatible T2 AMI closer to your current T1 AMI with same architecture (32 or 64bits)
  • Select same size for root volume
  • Select same instance type (if original T1 instance is t1.micro, select t2.micro)
  • Launch T2 instance in the same availability zone (AZ) of your current T1 instance
Example:




Stop both instances. Now, go to AWS EC2 web console, Volumes section and:
  • Set an easy-to-remember name for each volume
  • Review attachment information of T2 HVM root volume (at least) and take note of device name. In my example: /dev/xvda. We'll need this information later.
  • Detach both root volumes
After these steps, both volumes should be available in AWS console:





Now, we need to launch a new instance. We'll use this instance to perform required changes, so work instance seems a good name. Don't forget to launch this new instance in the same availability zone of T1 and T2 instances:




Attach T1 PVM and T2 HVM volumes as secondary volumes in work instance:




As you can see, T1 PVM volumes has been attached in /dev/sdf device and T2 HVM volume in /dev/sdg device. This information is important because will help us to identify volumes inside work instance.

Now, login to the work instance and run dmesg command to know how volumes are identified by the kernel:




According to dmesg information, /dev/sdf (PVM volume) is associated to /dev/xvdf and /dev/sdg (HVM volume) to /dev/xvdg1. Create two mountpoint directories, one for each device, and mount them. Required commands:
  • sudo mkdir /pvm
  • sudo mkdir /hvm
  • sudo mount /dev/xvdf /pvm
  • sudo mount /dev/xvdg1 /hvm

In the next step we're going to backup current HVM kernel. To ensure maximum compatibility, preserve current HVM kernel is recommended. You can skip this step if you're 100% sure PVM kernel will work with the new T2 HVM instance. You will need to backup /boot directory inside /hvm and modules associated to the running kernel. To know what is the active kernel, review /hvm/boot/grub/menu.lst file. Will give you the information to know what modules are required to backup:




For our example, next commands will be required:
  • sudo cp -prf /hvm/boot /tmp/
  • cat /hvm/boot/grub/menu.lst . Active kernel is tagged 3.10.42-52.145.amzn1.x86_64. So, command to backup modules will be:
  • sudo cp -prf /hvm/lib/modules/3.10.42-52.145.amzn1.x86_64 /tmp/

Next steps will be: remove all files from HVM volume, copy files from PVM volume to HVM and restore HVM kernel. The commands:
  • sudo rm -rf /hvm/*
  • sudo cp -prf /pvm/* /hvm/
  • sudo rm -rf /hvm/boot
  • sudo cp -prf /tmp/boot /hvm/
  • sudo cp -prf /tmp/3.10.42-52.145.amzn1.x86_64/ /hvm/lib/modules/




Important: review root label in kernel configuration, fstab file and root filesystem. In order to work, they need to be the same. In previous screenshot, volume labeled as / will be use as root device by kernel configuration and fstab file. Requesting information about HVM volume label, I get the same value. Finally, HVM volume filesystem is ext4. So, nothing additional is required in my example. If you find differences in your environment, you'll need to modify /hvm/boot/grub/menu.lst, /hvm/etc/fstab and/or HVM volume label to solve it. Otherwise, instance start-up will fail.

If all is correct, umount both volumes:
  • sudo umount /pvm
  • sudo umount /hvm
Go to AWS EC2 web console, Volumes section, and detach both secondary volumes (T1 PVM and T2 HVM volumes) from work instance.

Now, attach HVM volume as T2 instance root volume. In AWS EC2 web console, Volumes section (Important: don't forget to put as device name the value you copied previously. In my example: /dev/xvda):




Optional: If T1 instance has an Elastic IP assigned, I suggest you to associate this IP to the new T2 instance. To do it, just disassociate Elastic IP from T1 instance and associate to the new T2 instance in Elastic IPs section. Example:






All done. Now you can start and login to the new T2 instance using the old Elastic IP. As you can see in the next screenshot, files contained are the same T1 PVM root volume, but using the new T2 instance type:





If after procedure you experience issues during T2 instance start-up, in AWS EC2 web console select the instance, right click and select Get System Log. If there is any issue associated to the kernel, filesystem or volume label; useful information for troubleshooting will be displayed here.

When all work as expected, you can remove old T1 and work instance. Be sure you won't need them before remove because as soon as you delete them won't be able to access again.

domingo, 29 de junio de 2014

AWS: How to auto attach public IP from ElasticIP pool

When an EC2 instance is launched, you can select to attach a Public IP (or not). This Public IP is randomly selected. Here is an example:


i-cf27aa8d instance has 54.72.151.117 Public IP address assigned. This IP is taken from general AWS pool. If you stop and start the instance from AWS EC2 console, a different Public IP address will be selected.

Now, imagine instance launch is controlled by an auto-scaling policy. Following explained behavior, a new random Public IP address will be attached each time a new (or replacement) instance is launched attending auto-scaling group needs.

In the context of need a predictable Public IP addresses, general behavior doesn't fit our needs. When instance is launched manually is easy to resolve: you can attach an IP address from Elastic IP pool through AWS EC2 console, for example. But this could be difficult in an auto-scaling context.

A way to resolve this situation could be using ipassign script. Let verify this with an example!

Imagine previous instance (i-cf27aa8d). To use ipassign script we need to:

  • Verify AWS CLI and ec2-utils packages are installed. By default, Amazon Linux instances arrive with them pre-installed. For Ubuntu distributions, probably you'll need to install them manually using apt-get commands:

  • Login to the instance as root username. If role instance is not assigned, you need to configure AWS CLI with an IAM user allowed to execute describe-addresses, associate-address and disassociate-address EC2 actions.

  • Install ipassign script. Just follow next instructions:
  1. Download ipassign script and copy inside your instance in "/etc/init.d" directory
  2. Modify script permissions: chmod 755 /etc/init.d/ipassign
  3. Add script to instance startup process: chkconfig ipassign on
  • Review ipassign configuration. At the beginning of the script, there are two parameters you need to review and ensure are correctly configured:
  1. REGION: Defines the AWS region. Value must be the same used by instance. By default is set to eu-west-1 (Ireland) region.
  2. IPLOGFILE: Defines log file. By default is set to "/var/log/ipassign.log" and my suggestion is maintain this value.

Done! If we restart the instance, during startup process will try to attach a free Public IP address from Elastic IP pool. Imagine we have three IP address associated to our account, all of them are currently in use:


In this context, instance can't attach any Public IP. Script is designed to avoid changes if an IP from Elastic IP pool can't be attached. Next time we login to the instance, if we review log file will see an error message registered:


Just go to AWS EC2 web console and request a new Elastic IP:


Now (with a free Public IP in Elastic IP pool), if we restart instance again, we'll see ipassign script can find one free IP address in Elastic IP pool and attach it to the instance:


Login to the instance (now, using the new Public IP attached) and checking log file, next information is displayed:


Finally, in instance general information panel, we can review how the instance has a new Public IP address (54.76.166.221) from the Elastic IP pool correctly assigned:


By default, 5 Elastic IP addresses can be associated to an AWS account. But this limit could be increased, if needed.


viernes, 6 de junio de 2014

AWS: Convert root volume to XFS

By default, root volume in Amazon Linux instances uses EXT4 filesystem. But maybe you want to use another one, for example XFS. With next procedure you'll be able to convert default root volume filesystem of an existing instance to XFS. For our example, we've an instance named MyInstance using default Amazon Linux distribution:


After login, as you can see default root filesystem device (/dev/sda1 | /dev/xvda1) is EXT4:


Here is suggested steps to successfully achieve the filesystem conversion:
  • Login to the instance and become root
  • Install XFS utils: yum install xfsprogs xfsprogs-devel xfsdump
  • Stop the instance
  • Create a snapshot of root volume

  • Create a new volume from the snapshot. Make sure you don´t modify size and select same availability zone where original root volume of instance is hosted


  • Start the instance and wait until become available. After that, login to the instance and become root
  • Attach new volume as a secondary volume. By default, /dev/sdf device will be selected. This device is mapped as /dev/xvdf in modern kernels. Run dmesg command to review your kernel successfully detect the new attached volume

  • Install Development Tools: yum groupinstall 'Development Tools'
  • Download Fstransform toolkit from here
  • Uncompress, configure, compile and install Fstransform toolkit

  • Now, run: fstransform /dev/xvdf xfs
  • Previous command will convert /dev/xvdf from original EXT4 filesystem to XFS. Process will take time, depends on volume size. Be patient and make sure everything is correctly done. fstransform will provide detailed information about the process. Make sure everything is correctly done. 

  • Label /dev/xvdf device as '/'. Just run: xfs_admin -L \/ /dev/xvdf
  • Create a mountpoint directory, for example /xfs, and mount /dev/xvdf in /xfs directory. Edit fstab file associated to the new XFS volume (/xfs/etc/fstab) and make sure / is associated to volume labeled / and xfs filesystem is configured for root mountpoint

  • Stop the instance
  • Detach original root volume
  • Detach XFS volume
  • Attach XFS volume as root volume. Make sure you specify same device associated to the original root volume (for Amazon Linux instances usually is /dev/sda1
  • Start the instance
Now, your instance should start. Login and verify root volume now is XFS


If there is any issue during instance startup, review System Log in AWS EC2 web console. Useful information for troubleshooting will be provided (if required).

miércoles, 7 de mayo de 2014

Creating CloudWatch custom metrics

By default, AWS provides useful metrics of your services. But sometimes, this is not enough. For example, for an instance AWS provides next metrics:

  • CPUUtilization
  • DiskReadOps
  • DiskWriteOps
  • DiskReadBytes
  • DiskWriteBytes
  • NetworkIn
  • NetworkOut
  • StatusCheckFailed
  • StatusCheckFailed_Instance
  • StatusCheckFailed_System
For detailed information, read next link. As you can see, some useful metrics for instance health checks are not present, for example, disk usage. This kind of information are easy to obtain, for example with a simple 'df' command:


For this instance, root volume usage is 17%. One of the facilities AWS CloudWatch offers is the possibility to create custom metrics. Using AWS CLI and put-metric-data command from CloudWatch service you can populate data for a custom metric. Detailed process is explained here, but I think it´s easier to understand with an example. You´ll need to define (at least):
  • Metric name: The name of the metric
  • Name space: The namespace for the metric data
  • Timestamp: The time stamp used for the metric. If not  specified,  the  default  value  is  set  to  the  time  the metric data was received.
  • Value: The value for the metric
It´s easy to obtain percent disk usage for volume using shell-scripting, for example:


With this value and provided information, we can create a simple shell-script that obtain this value and push it as a custom metric in AWS CloudWatch:


Once shell-script is created, we need to run it each 5 minutes, using cron facility for example:


Now, if you open AWS web console, CloudWatch service. In 'Custom Metrics' tab you can select new custom metric. I recommend you to assign a representative name. For example, I select vol-bdcf2e92 as namespace (volume-id associated in AWS for this disk) and VolumeUsage as metric name:


Select metric name and registered values will appear:


Additionally, you can create alarms from custom metrics. To do this, just press Alarms -> Create Alarm, select custom metric and define alarm. For our example, we´re going to create an email alarm when disk usage associated to volume vol-bdcf2e92 is above 80% during 20 minutes:



As you can see, it´s easy to create custom metrics and associated alarms. For detailed information about CloudWatch pricing, please visit next url

lunes, 28 de abril de 2014

Test your ELB

ELB (Elastic Load Balancer) is a service provided by AWS to allow you include easily scalable load balancers in your architecture. But sometimes, you detect issues difficult to determinate if they are related with backend instances or ELB itself. Some alternatives in this situation: you can review your CloudWatch metrics trying to find any related issue or you can design a specific test to ensure your environment is working as expected.

In the second situation, several tools can be used to perform an in-depth test (jmeter, for example). But if you want to make an easy test based in a URL, testELB.sh could be what you need.

tesELB.sh will test an URL during a period (by default, ten minutes), making random queries through all associated IPs in your ELB. Additionally, will show you interesting information about:

  • Average response time
  • Maximum response time
  • Percentile 95 response time
  • Average payload size
  • Error request (including percent)
Here is an execution example:

testELB.sh output

Usage:

testELB.sh ELB [LOOP] [URL] [PORT] [PROTOCOL]

  ELB: DNS Name associated to ELB
  LOOP: Number of loops. Default value: 600 (ten minutes)
  URL: URL to check in ELB. Default value: /
  PORT: Port in ELB to check. Default value: 80
  PROTOCOL: Protocol to use. Default value: http

This shell script could be a good starting point to troubleshoot ELB issues. Fell free to use it!



lunes, 17 de febrero de 2014

AWS: Building blocks

AWS es principalmente conocido por sus máquinas virtuales, servicio formalmente conocido como EC2 (Elastic Cloud Computing). Pero AWS ofrece mucho mas. El set de servicios es extenso y crece cada día. En una serie de entradas en este blog me gustaría enseñar algunos de ellos partiendo de los mas simples y comunes hasta los mas complejos. El objetivo es obtener una visión general de lo que AWS puede ofrecernos desde una aproximación práctica y amena.

Pero dejemos de hablar y pongámonos manos a la obra. Primero necesitaremos establecer un entorno adecuado donde desplegar nuestra arquitectura. Partamos de un diseño de arquitectura tradicional con dos redes diferenciadas: una de frontend donde desplegaremos los servicios de cara al publico y otra de backend donde instalaremos los servicios de bases de datos. Esquemáticamente:

Diagrama general

Los elementos principales que deberemos definir son:

  • VPC (Virtual Private Cloud): Es el espacio reservado para nosotros donde desplegaremos toda la infraestructura. Piensa en ello como un trozo de AWS donde podrás definir todo lo que necesiten tus servicios. Usaremos para nuestra VPC un rango 10.0.0.0/16 que nos dará un amplio margen de direccionamiento.
  • Internet Gateway: Será nuestra punto de conexión entre la VPC e Internet
  • Public subnet: La subred pública. Con un rango de 10.0.0.0/24 pondremos dentro de esta subred todas las máquinas que ofrecerán servicio de cara al público (frontend)
  • Private subnet: La red privada. En esta subred contendrá todas las máquinas con información privada. Su acceso estará mas limitado y generalmente se utilizan para contener la información (backend)
  • NAT Instance: Las máquinas de backend por seguridad no deben conectarse directamente a Internet. Pero generalmente necesitarán hacer conexiones al exterior, por ejemplo para actualizar paquetes. La instancia de NAT nos permitirá poder hacer estas comunicaciones desde el backend de forma mas segura. 
  • Web Server: El servidor web que ofrecerá los servicios a nuestros clientes. 
  • DB Server: El servidor de base de datos que contendrá la información que use nuestro aplicativo.
Veamos cómo podemos crear y configurar este entorno de forma rápida y sencilla en AWS.

NOTA: Crear recursos en tu cuenta AWS puede tener asociado costes. Si no estas seguro consulta la tabla de precios para cada servicio antes de iniciar cualquier cambio que pueda derivar en un sobrecoste mensual inesperado.


Creación de la red y subredes

Creación de la VPC

Entramos en la consola AWS y seleccionamos el servicio VPC. En 'Your VPCs' nos aparecerán todas las VPC que tenemos creada para la región actual. Pulsamos el botón 'Create VPC' e introducimos los datos:


Una vez pulsado el botón 'Yes, Create' nos aparecerá nuestra nueva VPC dentro de la lista de VPCs disponibles:



Ahora nos vamos al apartado 'Subnets' y pulsamos el botón 'Create Subnet'. Deberemos repetir el proceso dos veces, una por cada subred que queremos crear:




Una vez hecho, nos deberán aparecer las dos nuevas subredes en la lista de subredes disponibles para la región:



Por último en el apartado de redes deberemos crear un Internet Gateway. Para hacerlo, nos vamos al apartado 'Internet Gateways' y pulsamos el botón 'Create Internet Gateway'. Ahora, pulsando botón derecho del ratón sobre el Internet Gateway que acabamos de crear, seleccionamos 'Attach to VPC' para asociarlo a nuestra VPC 10.0.0.0/16:


Una vez hecho, en la lista aparecerá asociado el Internet Gateway a la VPC:




Instancia NAT

NAT son las siglas de Network Address Translation y es un mecanismo usado por los routers para encaminar paquetes entre diferentes redes. Si recordais, tenemos dos subredes diferentes: una con los servidores de producción o frontend y otra con los servidores que contienen la información o backend. Por seguridad crearemos una instancia de NAT que colocaremos en la subred de frontend con dos funciones principales:
  1. Punto único de entrada para la administración: Habilitaremos reglas para poder acceder a esta instancia a tréves del puerto SSH (22/TCP) con el objetivo de administrar el entorno. Crear un único punto de entrada nos securizará el entorno y nos permitirá mas fácilmente controlar el acceso. En el resto de instancias nos ocuparemos de securizarlas para permitir solo accesos de administración desde la instancia de NAT y abrir los puertos de servicio requerido para clientes o internos, según el caso.
  2. Puente de comunicación para la red de backend: No es seguro que la red de backend se comunique directamente con Internet, pero puede que sea necesario para algunas labores como la actualización de paquetes por ejemplo. Para restringir este tráfico configuraremos para que el tráfico de las instancias de esta subred sea enrutado por la instancia de NAT.
Lo primero que necesitaremos será crear esta instancia de NAT. Amazon ya provee de una AMI enfocada a este propósito. En nuestra consola AWS iremos al servicio EC2 --> Instances y pulsaremos el botón 'Launch Instance'. En '1. Choose AMI' iremos a 'Community AMIs', marcaremos la casilla 'Amazon Linux' del apartado 'Operating System' y en el campo de búsqueda escribiremos 'NAT':




Seleccionaremos la AMI de fecha mas reciente. En '2. Choose Instance Type' elegiremos una t1.micro ya que el propósito de este artículo es demostrativo. Para un entorno productivo real deberíamos elegir un tipo de instancia adecuado al throughput de red que necesitemos.


Seguimos. En '3. Configure Instance' en los apartados 'Network' y 'Subnet' seleccionaremos la VPC 10.0.0.0/16 y la subred 10.0.0.0/24. De esta forma enmarcamos la instancia dentro de la subred de frontend:


Next, en '4. Add Storage' lo dejaremos por defecto. Esta instancia no necesita de almacenamiento adicional. Con el volumen raíz será suficiente. Siguiente, en '5. Tag Instance' como nombre le asignaremos el valor 'NAT instance'. De esta forma reconoceremos facilmente la instancia posteriormente. En '6. Configure Security Group' configuraremos un nuevo grupo de seguridad llamado 'NAT-Security-Group' y, por ahora, permitiremos el acceso SSH desde cualquier origen. Esto es inseguro y es altamente recomendable modificarlo para restringir el conjunto de IPs que puedan acceder a este puerto. Pero por ahora, y para facilitar la configuración, lo dejaremos así:


En el último apartado, '7. Review', revisaremos las opciones elegidas y si estamos conforme pulsaremos el botón 'Launch' para crear la nueva instancia:


Después de unos segundos nuestra nueva instancia NAT aparecerá disponible en la lista de instancias en ejecución para la región seleccionada.

Dado que nuestra instancia NAT necesitará comunicarse con Internet necesitará disponer de una IP pública. Para conseguirlo haremos uso de las EIP, Elastic IP. En la consola AWS iremos al servicio VPC, apartado 'Elastic IPs' y pulsaremos al botón 'Allocate New Address'. Una vez creada la IP pública pulsando sobre ella con el botón derecho del razón seleccionamos 'Associate' y la asociaremos a la instancia de NAT:



Con esto, ya tenemos una IP pública asociada a la instancia de NAT. En la consola AWS, vamos a EC2 --> Instances. En el apartado 'Security Groups' seleccionaremos el grupo de seguridad de nuestra instancia NAT y añadiremos una regla de entrada (Inbound) para permitir todo el tráfico desde la red VPC (10.0.0.0/16):


Esto permitirá a las máquinas de nuestra VPC comunicarse a través de la instancia de NAT. Podremos restringir esto mas adelante (de hecho es lo recomendable para aumentar la seguridad), pero por ahora lo dejaremos así. Solo resta deshabitar el chequeo de ip origen y destino en la instancia. Volvemos a EC2 --> Instances , botón derecho sobre la instancia NAT y seleccionamos 'Change Source/Dest. Check' para poner el valor a 'False':


Por defecto las instancias AWS tienen este chequeo activo por motivos de seguridad, denegando cualquier paquete en el que no aparezca la IP de la instancia como origen o destino. Pero dado que la instancia NAT va a realizar trabajo de enrutado de paquetes para otras instancias, si tiene activa esta comprobación no podrá enrutar el tráfico correctamente. Nuestra instancia NAT está lista para su uso:




Tablas de enrutado

Para nuestro entorno necesitaremos definir dos tablas de enrutado:
  • Main route table: O tabla de enrutado principal. Es la tabla de rutas por defecto que se genera cuando creamos nuestra VPC. Debemos definir esta tabla para que envie directamente por la interfaz el trafico local (10.0.0.0/16) y el resto de tráfico lo encamine hacia la instancia de NAT. Asociaremos esta tabla de enrutado a la subred de backend.
  • Custom route table: O tabla de enrutado personalizada. Será una nueva tabla de rutas que crearemos. Al igual que la anterior, el tráfico local se enviará directamente por la interfaz y el resto de tráfico se enviará al Internet Gateway que creamos al principio. Asociaremos esta tabla de enrutado a la subred de frontend.
Vemos el proceso de creación en la consola AWS. Iremos a servicios VPC --> Route Tables. Para nuestro ejemplo la tabla de rutas rtb-a8011eca es la principal asociada a la VPC 10.0.0.0/16. En la pestaña 'Routes' añadiremos la ruta por defecto (0.0.0.0/0) y como objetivo (Tarjet) seleccionaremos la instancia de NAT:


A continuación en la pestaña 'Associations' asociaremos la subred de backend (10.0.1.0/24) a la tabla de rutas principal:



Ahora añadiremos la tabla de enrutado personalizada pulsando el botón 'Create Route Table' y seleccionado nuestra VPC 10.0.0.0/16. Seleccionamos la nueva tabla de rutas y en la pestaña 'Routes' añadimos la ruta por defecto (0.0.0.0/16) hacia nuestro Internet Gateway creado en un apartado anterior:


De forma similar a lo realizado anteriormente, en la pestaña 'Associations' de la tabla de rutas asociaremos la subred de frontend (10.0.0.0/24):


Instancias de servicio

En este apartado voy a ser bastante mas escueto. Cread dos instancias t1.micro, usando como referencia los pasos seguidos para la instancia NAT. Una la llamaremos 'DB Server' y a la otra 'Web Server'. Como AMI recomiendo usar la estándar de Amazon para 64bits y como únicas recomendaciones afinad los security groups para permitir tráfico solo en los puertos y para las redes necesarias:

  • DB Server:

  • Web Server:


El servidor de base de datos, al estar en red de backend, no necesitará IP para comunicarse con Internet. Pero sí el servidor Web. Por lo que habrá que crear una EIP que asociar a la instancia 'Web Server'. Una vez concluido el proceso, deberemos tener tres instancias:



Para un testeo rápido que todo funciona:
  • Entrar en la instancia de NAT (debes adaptar el comando al uso de tu clave privada y EIP para la instancia de NAT): $ ssh -i TU_CLAVE_PRIVADA.pem ec2-user@TU_EIP
  • Actualizar paquetes (altamente recomendable por motivos de seguridad): $ sudo yum update;sudo yum upgrade
  • Desde la instancia de NAT acceder usando SSH a las instancias de base de datos y web. Para conocer las IP privadas de cada instancia usa la información que se muestra en la consola AWS. Actualizar los paquetes en cada instancia ($ sudo yum update;sudo yum upgrade) e instala MySQL y Apache respectivamente:
  • DB Server:
  • $ sudo yum install mysql-server
  • $ sudo chkconfig mysqld on
  • $ sudo service mysqld start

  • Web Server:
  • $ sudo yum install httpd
  • $ sudo chkconfig httpd on
  • $ sudo service httpd start

Si se ha configurado correctamente el entorno deberíamos poder ver la pagina web de ejemplo de nuestra instancia 'Web Server' desde cualquier navegador indicando su EIP asociada:


Lo dejaremos en este punto. En entregas posteriores aumentaremos la seguridad, incluiremos nuevos servicios y evolucionaremos nuestro entorno para hacer uso de algunas de las características mas interesantes y novedosas de AWS. 

Como podéis comprobar, definir y desplegar nuestra infraestructura de servicios en Amazon Web Services es fácil y rápido. Nos permite crear desde simples instancias virtuales para pocos servicios hasta complejas infraestructuras con alta disponibilidad, VPN y servicios de alta demanda con baja latencia a nivel global.