Categories
General In detail

Algunas cosas de AWS que quizás no conoces

Aunque los competidores están empezando a coger carrerilla, decir hoy en día que Amazon Web Services es el proveedor de cloud más utilizado, con más funcionalidades y servicios interesantes es como decir que el cielo es azul. AWS se ha transformado en un monstruo en el que probablemente casi nadie puede estar al día de todos los cambios y funcionalidades en detalle que va adoptando. En este post vamos a ver algunas de las funcionalidades y características de AWS que probablemente si no has trabajado un poco con AWS no conozcas.
post

ALIAS

En route 53 podemos crear registros DNS con ALIAS, no penséis que Amazon ha reinventado el protocolo DNS ni nada por el estilo. Ésta característica ha salido por un lado porque al apex de un dominio (raíz), no se le puede asignar un registro CNAME y esto es un problema en un entorno cloud dónde las IPs no son fijas y todo puede cambiar. A parte también interesa tener registros DNS que apunten a componentes de AWS (como por ejemplo un ELB) y que en caso de que cambie la IP del componente en cuestión el registro sea actualizado.
Al crear un registro DNS , podemos configurar que sea de tipo ALIAS y el componente al que apunta, ésto nos permite apuntar a componentes con IP cambiante y a parte poder configurar un apex de un dominio como un registro que aunque sea de tipo A, es dinámico.

EC2 Metadata

Aunque probablemente todos los que hemos trasteado un poco con EC2 vemos que mágicamente se nos configuran algunos parámetros de la máquina automáticamente como el hostname, se ejecuta el user-data que le hemos pasado, se crea un usuario estándar con nuestra clave pública,… ¿De dónde proviene todo esto? ¿Como puedo recoger toda esta información y actuar si me preparo una AMI de zero?
La respuesta está en el servicio de metadatos, el servicio de metadatos es un servicio http que se encuentra en la dirección 169.254.169.254 de cada máquina. Si ejecutamos por ejemplo:

curl http://169.254.169.254/latest/meta-data/

Podremos ver todos los metadatos relacionados con la instancia. Si ejecutamos:

curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

Podremos ver la clave pública con la que AWS nos configura el usuario ec2-user.
Con ésto podemos ejecutar nuestros propios scripts para que nuestro servidor arranque con las configuraciones que nos interesen del meta-data. Otra posibilidad es instalar cloud-init, el cual nos permite configurar los parámetros del meta-data cómo queremos que se comporten. Las AMIs oficiales de AWS llevan cloud-init instalado por defecto.

ASG Termination Policy

En los autoscaling groups de Amazon se puede configurar la política para de terminar las máquinas virtuales. Por defecto siempre se borra la que más cerca de llegar a un numero entero de horas del Launch Configuration más viejo del Availability Zone en el que tengamos más máquinas.
Si queremos cambiar éste comportamiento, podemos cambiar la termination policy a uno de estos parámetros:

  • OldestInstance – Dentro del Auto Scaling group seleccionado (el que tenga más instancias) se selecciona la instancia más vieja.
  • NewestInstance – Se termina la instancia más recientemente creada.
  • OldestLaunchConfiguration – Se termina la instancia del Launch Configuration más viejo.
  • ClosestToNextInstanceHour – Se termina la instancia que más a punto está de cumplir un múltiplo de 60 minutos.
  • Default – Se termina con la política por defecto explicada más arriba.

ASG Health Checks

En los AutoScaling Groups, AWS utiliza health checks para detectar si una instancia está en buen estado. En caso de que una instancia no esté respondiendo, es terminada y en caso de que sea necesario escalará agregando nuevas instancias. Por defecto el health check se coge del estado general de EC2 y aunque es la configuración recomendada, en caso de tener un Elastic Load Balancer asociado al AutoScaling Group se puede hacer que los health checks se cojan del estado que está detectando el balanceador. Ésta última configuración puede dar raíz a problemas, imaginemos que de repente nos llega mucha carga y nuestras instancias dejan de responder un código 200 a los balanceadores que hemos configurado como healthcheck, ¿que pasará? El resultado será que en vez de escalar nuestro AutoScaling Group las instancias que no respondían serán eliminadas teniendo el efecto contrario al deseado. Más información aquí.

Multi-Factor Authentication

Con Multi-Factor Authentication, AWS permite la autenticación con dos factores, por un lado tenemos el usuario y contraseña y por el otro tenemos el segundo factor que puede ser con dispositivos virtuales como Google Authenticator, o la virtual MFA de AWS. También se puede utilizar Gemalto como dispositivo físico, el cual  nos dará aún más seguridad que los dispositivos virtuales.

AWS Direct Connect

ADC_Connection_Map_v3_screen
Aunque el diagrama lo dice casi todo, DirectConnect trata de tener conectividad directa hacia los Centros de Datos de AWS, ¿como se hace esto? Pues básicamente debemos tirar un enlace a uno de los routers de Direct Connect y tenemos ancho de banda dedicado con AWS, la parte de conectividad del router a los centros de datos de AWS es gestionado por AWS. +Info aquí

Aplicación para dispositivos móviles

Y para terminar, y más como curiosidad que otra cosa, vemos que existe una aplicación de AWS para móviles. Se puede encontrar en el PlayStore de Android y en el AppStore de Apple. Después de probar la aplicación si que vemos que aunque es útil para visualizar el estado de nuestra infraestructura, no nos sirve para poder lanzar nueva infraestructura o cambiar configuraciones.
Esto es todo cloudadmins, si tienen cualquier duda o sugerencia pongan sus comentarios!
Saludos,
Oriol Marti
Cloud Admin

Categories
General Guide

Gestionar discos en Amazon Web Services (AWS)


Si trabajamos con Amazon Web Services, uno de los servicios que usaremos sin duda es EC2. Con EC2 podremos crear instancias (máquinas virtuales) con gran facilidad, y estas, están directamente ligadas al uso de volúmenes EBS (discos virtuales).
Una de las dudas con las que me encuentro a menudo usando instancias EC2 con volúmenes EBS, es elegir bien la capacidad que asignar al disco basándome en el uso que le voy a dar a esa instancia. Si que es verdad que podemos mas a o menos calcularlo, pero a veces nos podemos quedar cortos, ya que nunca sabes si en un futuro vas a implementar algo que pueda requerir mucho espacio… como una base de datos que puede ir creciendo.
Para evitar esto, y no tener que asignar muchísimo espacio que no vamos a usar a corto plazo (ya que el coste esta directamente relacionado con la capacidad asignada a un disco EBS) la mejor solución es usar LVM (Logical Volume Manager).
A continuación voy a explicar los pasos a seguir, mas comunes, para gestionar volúmenes EBS sobre una instancia EC2 ya creada.

Categories
General

Evento AWS en Barcelona by Capside

El  pasado lunes 24 estuvimos presentes en un evento de AWS organizado por Capside.
Captura de 2014-03-30 19:43:11
Repasado su web de manera rápida podemos comprobar porque se diferencian dentro del ecosistema de proveedores de servicios IT en el ámbito de la Infraestructura: sin duda se alinean a la explotación del modelo Cloud orientado a las necesidades del cliente. En definitiva expertos en arquitecturas de sistemas IT que las diseñan, subministran, mantienen y administran.
También me gustaría destacar que aseguran una visión de neutralidad trabajando con los proveedores Cloud que mejor se adaptan a los requerimientos técnicos y económicos de cada caso, proyecto o cliente. Visión que suena muy bien y que parece que encaja en este nuevo modelo de gestión de la infraestructura de TI.
Volviendo al evento después de un rodeo, su objetivo fue por un lado conocer novedades respecto a los servicios ofrecidos por AWS y por otro aportar conocimientos prácticos a través de casos reales en base a tres ejes :

  • Flexibilidad, escalabilidad y rendimiento: cómo diseñar arquitecturas elásticas y autoescalables, que le permitan ajustar sus sistemas dinámicamente a la demanda para optimizar costes garantizando siempre el mejor servicio.
  • Disponibilidad de su negocio: cómo tener sus servicios e infraestructuras siempre accesibles y operativas sin renunciar a un estricto control de costes.
  • Controlar y reducir costes TIC: al realizar la transición de servicios on-premise o físicos hacia “la nube” con arquitecturas elásticas.

Respecto a las novedades de AWS, Tiago Henriques ( Amazon Solutions Architect) realizó una presentación de como utilizan los clientes sus servicios dónde hizo especial mención de Cloud Formation en su apuesta de la definición de servicios en base a plantillas llegando a facilitar una solución deseada por todos como es el verdadero “reversionado” de entornos y las posibilidades que esto ofrece en el ámbito de las simulaciones junto con el paradigma de la integración continua. Uff… de verdad que como mínimo suena muy bien.
Captura de 2014-03-30 19:51:41
Tiago también repasó  DYNAMODB su servicio de bases de datos NoSQL dónde destacó aspectos como el rendimiento dónde utilizar tecnología SSD asegura tiempos de lecturas por debajo de los 5ms i escrituras por debajo de los 10ms. Ya casi al final de su intervención se introdujo como novedad Redshift como su solución de servicio de “data warehouse” con capacidades de Petabyte que según su web convierte el proceso de almacenamiento y análisis de enormes cantidades de datos en una tarea fácil ya que permite utilizar tus propias herramientas de “business intelligence” facilitando el acceso mediante conectores ya disponibles como los típicos JDBC, ODBC,…
En la parte central del evento vimos diferentes casos de éxito con empresas que por naturaleza necesitan muchísima flexibilidad en sus servicios/aplicaciones como el de Eduard Giménez, Co-fundador de la start-up Emtrics / Keweno y Raquel Priego, Corporate Communication Manager de ByHours que actualmente utilizan los servicios de Capside sobre AWS.
Ya para finalizar José Luís Martínez, CTO de CAPSiDE y Josep Ruano, CEO de CAPSiDE nos deleitaron arriesgando contra “efectos demo” una específica de las posibilidades de Autoscaling mediante EC2 sobre un escenario típico de aplicación de tres capas.
Y hasta aquí la crónica del evento. Buen vuelo!
Cloudadmins.org

Categories
General In detail

Rotando logs de apache a S3

Con la llegada de Amazon AWS y conceptos como el autoescalado nos surge un reto al que tenemos que enfrentarnos: como guardamos los logs de las máquinas que pueden ser creadas y borradas en cualquier momento?
AmazonS3-Multifile2

Soluciones

Para solventar este problema las soluciones son varias. A continuación se enumeran las virtudes y defectos de algunas de ellas y veremos como poner en marcha la solución de rotar los logs a un storage basado en objetos como S3.

  • Servicio de logs en cloud: Hay muchos servicios de este tipo: loggly, sumologic, papertrail, …. Las ventajas de un servicio de estas características es que nos despreocupamos de un componente de nuestra arquitectura y nos ahorramos dolores de cabeza, a parte de las funcionalidades extras para la visualización y análisis de logs. El problema pero cómo podéis ver en los enlaces de tarifas de loggly y papertrail son los precios, sobretodo si tenemos un volumen considerable de logs.
  • FIleSystem Compartido: Esta solución tiene la desventaja que tenemos un punto más de fallo en nuestra arquitectura.
  • Syslog-ng: Con esta solución la ventaja es que tenemos una máquina con los logs centralizados, pero tenemos que tener un servicio mas corriendo y si no tenemos muchas máquinas corriendo no es una solución muy óptima por los costes añadidos.
  • Rotación de logs a storage basado en objetos: Las ventajas de esta solución es que es económica y sencilla, a parte de no tener dependencias de servicios que puedan fallar al tratarse de S3 el cual tiene una disponibilidad de 99,99% y una durabilidad de un 99.999999999%. Cómo desventajas destacaría su tratamiento que como veremos existe una alta fragmentación y que existe la posibilidad aunque sea poco probable  de perder logs .

Rotación de logs a S3

log-rotate-300x299
Para rotar los logs de apache a S3 utilizaremos la herramienta logrotate, la idea es rotar los logs cada hora y sincronizarlos con un bucket de S3 con el comando s3cmd. A parte de rotar los logs cada hora, tenemos el añadido de que si nuestra máquina está corriendo en un autoescaling group, ésta puede ser eliminada en cualquier momento. Teniendo en cuenta que primero las máquinas són paradas con un soft shutdown, podemos crear un servicio que cuando la máquina sea parada fuerce a rotar los logs para no perderlos. En caso de que la sincronización tardara demasiado Amazon haría un hard shutdown y podríamos perder los logs de las últimas dos horas.

Instalación s3cmd

En primer lugar vamos a instalar s3cmd.
El primer paso es añadir los repositorios de epel para instalar pip:

# rpm -ivh http://mirror-fpt-telecom.fpt.net/fedora/epel/6/x86_64/epel-release-6-8.noarch.rpm

Desactivamos el repositorio epel, para que sólo sea utilizado cuando lo indiquemos explícitamente en yum.

# sed -i "s/enabled=1/enabled=0/g" /etc/yum.repos.d/epel.repo

Instalamos pip  y python-magic indicando que nos active temporalmente el repositorio epel.

# yum -y install python-pip python-magic --enablerepo=epel

Instalamos s3cmd:

# pip install s3cmd

Para la configuración del s3cmd creamos el fichero de configuración correspondiente en /root/.s3cfg, sustituyendo <acces_key> y <secret_key> por las credenciales correspondientes a nuestro usuario:

[default]
access_key = <acces_key>
access_token =
add_encoding_exts =
add_headers =
bucket_location = EU
cache_file =
cloudfront_host = cloudfront.amazonaws.com
default_mime_type = binary/octet-stream
delay_updates = False
delete_after = False
delete_after_fetch = False
delete_removed = False
dry_run = False
enable_multipart = True
encoding = UTF-8
encrypt = False
follow_symlinks = False
force = False
get_continue = False
gpg_command = /usr/bin/gpg
gpg_decrypt = %(gpg_command)s -d --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_encrypt = %(gpg_command)s -c --verbose --no-use-agent --batch --yes --passphrase-fd %(passphrase_fd)s -o %(output_file)s %(input_file)s
gpg_passphrase = testtt
guess_mime_type = True
host_base = s3.amazonaws.com
host_bucket = %(bucket)s.s3.amazonaws.com
human_readable_sizes = False
invalidate_default_index_on_cf = False
invalidate_default_index_root_on_cf = True
invalidate_on_cf = False
list_md5 = False
log_target_prefix =
mime_type =
multipart_chunk_size_mb = 15
preserve_attrs = True
progress_meter = True
proxy_host =
proxy_port = 0
recursive = False
recv_chunk = 4096
reduced_redundancy = False
secret_key = <secret_key>
send_chunk = 4096
simpledb_host = sdb.amazonaws.com
skip_existing = False
socket_timeout = 300
urlencoding_mode = normal
use_https = True
verbosity = WARNING
website_endpoint = http://%(bucket)s.s3-website-%(location)s.amazonaws.com/
website_error =
website_index = index.html

Para testear que funciona bien el s3cmd, vamos a sincronizar un archivo, supondremos que ya tenemos creado un bucket de nombre logs:

# mkdir test
# cd test
# echo "This is a test" > test
# s3cmd sync . s3://logs/

En este punto deberíamos ver cómo se ha sincronizado nuestro fichero con el bucket. Para verlo con el s3cmd:

# s3cmd ls s3://logs/

Configuración logrotate

Vamos a configurar el logrotate para que al rotar los logs del apache sincronice estos con nuestro bucket de S3. Sustituimos el fichero /etc/logrotate.d/httpd con el siguiente contenido:

/var/log/httpd/*log {
    daily
    rotate 4
    size 5k
    dateext
    dateformat +%Y-%m-%d.%s
    compress
    missingok
    sharedscripts
    postrotate
        /sbin/service httpd reload > /dev/null 2>/dev/null || true
        BUCKET=logs
        INSTANCE_ID=`/usr/bin/curl --silent http://169.254.169.254/latest/meta-data/instance-id`
        /usr/bin/s3cmd -c /root/.s3cfg -m text/plain sync /var/log/httpd/*gz* s3://${BUCKET}/${INSTANCE_ID}/ > /dev/null
    endscript
}

Con esta configuración, los parámetros a tener en cuenta son:

  • daily: Nos rotará los logs diariamente, aunque en nuestro caso los vamos a rotar cada hora si ocupan más de 5Kbytes. Más adelante veremos cómo.
  • rotate 4: Nos borrará los logs a partir de 4 rotaciones.
  • size 5k: Éste parámetro hace que los logs siempre sean rotados, aunque tengamos la política daily, si éstos ocupan más de 5KB.
  • dateext: Hace que los logs sean guardados poniendo la fecha en el nombre, el formato es el de dateformat.
  • dateformat +%Y-%m-%d.%s: Formato de la fecha: Año, mes, día del mes y segundos des de 1970.
  • compress: Al hacer la rotación los logs antiguos son comprimidos.
  • sharedscripts: Corre la sección de postrotate una sola vez para todos los ficheros.
  • postrotate: Sección a correr una vez se han rotado los logs, en nuestro caso se hace un reload del apache, se recoge el nombre de instancia de nuestra máquina en EC2 y se sincronizan los logs que están comprimidos con el bucket logs dentro de un directorio con nuestro nombre de instancia.

Tenemos que tener en cuenta, aunque la página del man diga lo contrario el postrotate es ejecutado antes de la compresión, por lo que no nos sincronizará los logs actuales hasta la siguiente rotación de logs, que como veremos será al cabo de una hora.
Debido a que la rotacion de logs ocurre una sola vez al dia, y en nuestro caso queremos que se haga cada hora, vamos a crear el fichero /etc/cron.hourly/1logrotatehttpd con el siguiente contenido:

#!/bin/sh
/usr/sbin/logrotate  /etc/logrotate.d/httpd >/dev/null 2>&1
EXITVALUE=$?
if [ $EXITVALUE != 0 ]; then
    /usr/bin/logger -t logrotate "ALERT exited abnormally with [$EXITVALUE]"
fi
exit 0

Le damos permisos de ejecución:

# chmod +x /etc/cron.hourly/1logrotatehttpd

Rotando logs al parar la máquina

Con lo que hemos visto hasta ahora, ya tenemos preparada nuestra máquina para que sincronice los logs cada hora, con la particularidad que siempre nos sincroniza los de la última hora y no los actuales. Si la máquina es borrada de nuestro autoscaling group perderemos nuestros logs, por lo que necesitamos crear un script en el /etc/init.d que sincronice los logs antes de apagar la máquina. Creamos el script /etc/init.d/s3sync con el siguiente contenido:

#!/bin/bash
#
# s3sync     Sync httpd logs to S3
#
# chkconfig: -  86 14
# description:	s3sync logs of apache
# processname: s3sync
#
#
### BEGIN INIT INFO
# Provides: s3sync
# Required-Start: $local_fs $remote_fs $network $named
# Required-Stop: $local_fs $remote_fs $network
# Short-Description: s3sync logs of apache
# Description: s3sync logs of apache
### END INIT INFO
# Source function library.
. /etc/init.d/functions
start() {
    touch /var/lock/subsys/s3sync
    return 0
}
stop() {
    /usr/sbin/logrotate -f /etc/logrotate.d/httpd
    BUCKET=logs
    INSTANCE_ID=`/usr/bin/curl --silent http://169.254.169.254/latest/meta-data/instance-id`
    /usr/bin/s3cmd -c /root/.s3cfg sync /var/log/httpd/*gz* s3://${BUCKET}/${INSTANCE_ID}/ > /dev/null
    return 0
}
restart() {
    stop
    start
}
case "$1" in
    start)
	start
	RETVAL=$?
	;;
    stop)
	stop
	RETVAL=$?
	;;
    restart)
	restart
	RETVAL=$?
	;;
    *)
	echo $"Usage: s3sync {start|stop|restart|condrestart|status|panic|save}"
	RETVAL=2
	;;
esac
exit $RETVAL

Hacemos ejecutable el script, lo configuramos para que arranque al arrancar la máquina y le hacemos un start:

# chmod +x /etc/init.d/s3sync
# chkconfig s3sync on
# service s3sync start

Como hemos visto mediante el logrotate no se rotan los últimos logs y en caso de que ocupen menos de 5k tampoco. Así pues necesitaremos hacer una sincronización después de rotados los logs. A parte para que los logs de menos de 5k sean también sincronizados necesitaremos ejecutar el logrotate con el flag -f (force). En CentOs para indicar que un servicio está corriendo y por lo tanto para que al parar la máquina ejecute el stop del servicio en cuestión se debe crear un fichero con el mismo nombre del fichero en /var/lock/subsys
Con esto ya tenemos nuestros logs de apache rotando a S3 y con el mínimo peligro de que se pierdan, como ya os podéis imaginar éste manual se podría aplicar a muchos otros servicios que tengan logs.
Un saludo cloudadmins !!
Oricloud

Categories
General Guide In detail

Automatizando copias de seguridad de volumenes EBS con boto y Python


Recientemente hemos visto como AWS ha acogido boto como API de facto para interactuar con muchos de sus servicios (Amazon S3, Amazon EC2, Amazon DynamoDB y muchos más). Boto nos facilita las tareas que realizamos habitualmente a través de CLI, entre ellas la de llevar a cabo una copia de seguridad de nuestros volúmenes EBS. En este artículo vamos describir los pasos para automatizar de forma fácil y sencilla este proceso.
Para empezar tendremos instalar boto a través pip. Pip es una utilidad de phyton para instalar paquetes.

pip install boto

A continuación debemos introducir nuestras credenciales en el archivo de configuración de boto.

export AWS_ACCESS_KEY_ID="..."
export AWS_SECRET_ACCESS_KEY="..."

Debemos utilizar una IAM que tenga como mínimo los siguientes privilegios

"Action": [
        "ec2:CreateSnapshot",
        "ec2:CreateTags",
        "ec2:DeleteSnapshot",
        "ec2:DescribeAvailabilityZones",
        "ec2:DescribeSnapshots",
        "ec2:DescribeTags",
        "ec2:DescribeVolumeAttribute",
        "ec2:DescribeVolumeStatus",
        "ec2:DescribeVolumes"
      ],

Seguidamente añadimos una notificación automática a través de SNS de AWS y añadimos la dirección de correo de la IAM que vayamos a utilizar para esta labor.
Una vez tengamos acceso a nuestros servicios en AWS y disponemos de un ARN válido, llevaremos a cabo las copias de seguridad utilizando esta simple herramienta llamada aws-snapshot-tool. La configuración es muy fácil, solo tenemos que editar el archivo config.py.

config = {
    'ec2_region_name': 'us-east-1',
    'ec2_region_endpoint': 'ec2.us-east-1.amazonaws.com',
    'tag_name': 'tag:MakeSnapshot',
    'tag_value':    'True',
    'keep_day': 5,
    'keep_week': 5,
    'keep_month': 11,
    'log_file': '/tmp/makesnapshots.log',
}

Finalmente solo nos falta etiquetar cada volumen EBS del que queramos obtener un respaldo y establecer la retención de estos.

# chmod +x makesnapshots.py
# crontab -e
30 1 * * 1-5 /opt/aws-snapshot-tool/makesnapshots.py day
30 2 * * 6 /opt/aws-snapshot-tool/makesnapshots.py week
30 3 1 * * /opt/aws-snapshot-tool/makesnapshots.py month

Le podemos encontrar algunas pegas, por ejemplo si disponemos de recursos en distintas regiones de AWS o si queremos aplicar políticas de retención diferentes a nuestros volúmenes EBS. Aún así hemos visto como con boto y Python tenemos una interfaz robusta, muy cómoda de utilizar que nos permite mantener y administrar varios aspectos de nuestros entornos alojados en AWS.
Otra opción es delegar en terceros como autosnappy 😉
Ivan Farré
Cloudadmins.org

Categories
DCIM General Hybrid Clouds

AWS y Eucalyptus : Apuesta de Amazon por el cloud híbrido

 
“A hybrid cloud is a composition of at least one private cloud and at least one public cloud. A hybrid cloud is typically offered in one of two ways: a vendor has a private cloud and forms a partnership with a public cloud provider, or a public cloud provider forms a partnership with a vendor that provides private cloud platforms.”
Des de la aparición de los servicios de infraestructura IT en su modalidad de pago por uso el planteamiento inicial de utilización de estos recursos ha ido cambiando en el tiempo.  A día de hoy, que una nueva organización se plantee disponer de una parte o incluso de todos sus recursos IT fuera de casa es sin duda una realidad… para muchos directores financieros nos encontramos delante de un commodity más, el cuál desde este punto de vista es  “equiparable”  al alquiler de sus propias oficinas. En esta línea y desde otro ángulo, entra la mirada del director de IT sobre  la palabra “todo” … al final en la mayoría de los casos ni para uno ni para otro… café para todos!
Aquí desde mi punto de vista entra en juego con fuerza el modelo de cloud híbrido que se complementa con los casos de organizaciones que ya llevan un recorrido y que han visto escenarios de todos los colores… centralizado… distribuido…  compartido…dentro…fuera… etc. Eso sí,  la eficacia de optar por este tipo de modelo viene en gran medida determinada por la capa de gestión utilizada, la cuál ha de permitir interactuar con nuestra infraestructura (cloud privado) y con la de los proveedores externos (clouds públicos) de manera uniforme.
Con este enfoque, el gigante Amazon colaborará con Eucalyptus Systems en aspectos como la compatibilidad entre APIs de gestión como en la mejora de movimientos de cargas de trabajo entre clouds privados y públicos.  En este caso hemos de recordar que la solución de Eucalyptus se basa también en la implementación de EC2 en sus servicios de cloud privado y público, protocolo de facto de AWS.
+ Info http://www.eucalyptus.com/resources/AmazonAWS