J'ai commencé à utiliser cet outil pour provisionner du ec2 avec vpc.
Je ne sais pas pour les autres providers de cloud mais ce que je vois c'est qu'ils vont très loin avec ec2 et aws en général:
sg, subnet, vpc, interface réseau, volume, role iam, snapshot, eip, instance, elb, s3, route53, ...
Tout y passe et c'est très agréable à utiliser.
J'aime beaucoup les fonctions 'plan' et 'destroy' :)

Comme tout ce qu'ils font, le développement est carré même s'ils releasent souvent de la feature.

On verra ce que ça donne sur la durée. En tout cas, ils sont forts chez hashicorp (vagrant, consul, packer, ...).

News et retours d'expérience autour d'Amazon ECS. Pour info, ils rejoignent l'Open Container Project.

Comme son nom l'indique. Bien pratique.

(C'est pour Amazon AWS...)

"""
If your database server is compromised, the attacker might delete the data in your database on that machine. He would also likely gain access to the AWS credentials you use to send backups to S3 - if this gives him access to also delete your backup, you’re in big trouble. With a policy like the one below, you can restrict users from deleting files, but actually they can still overwrite an existing file, rendering your backup useless. With versioning enabled, an attacker will be able to overwrite a file, but you will always be able to get the original file back. Only the owner of the S3 bucket can permanently delete an object in a versioned bucket.
"""
une bonne pratique sécurité par rapport à s3

Un article intéressant qui rappele qu'il faut dissocier

• timeout client (entre les clients et l'ELB): réglages au niveau du client + ELB (60 sec par défaut)
• timeout backend (entre les backends (nginx) et l'ELB): réglages au niveau de nginx + ELB (60 sec par défaut)

Il n'y a pas non plus de rapport 1 pour 1 entre les connexions tcp de part et d'autre de l'ELB. On a des choses différentes pour:

• nombre de connexions client: réglage au niveau du client
• nombre de connexions backend: pas de réglage

$ aws ec2 describe-security-groups --filter Name=ip-permission.cidr,Values=X.X.X. --query 'SecurityGroups[].GroupName'

Le pourquoi de sa méthode repose dans cette citation:
"""
In general there are two ways to build AMIs: Spinning up a new instance, customize it and create a snapshot or build the AMI from scratch.

The first option seems to be the most common case. There are several tools like packer or Netflix' aminator but since it requires to actually boot a existing AMIs, it has a few downsides. For once it requires a existing AMI which might include things you don't need but I'm more worried about the fact that it requires to actually boot a machine. This breaks the clean separation of build- and runtime and might mess up your build artefacts. Think logfiles, dhcp/cloud-init configuration and so on. Sure, you can clean up those things but I prefer avoiding it in the first place by never entering the runtime before actual deployment.
"""

Un petit VPN gratuit[1] chez AWS.
Je m'en suis créé un dans la région de Francfort.
Ça fonctionne bien.

A utiliser en connaissance de cause, car il ne faut pas oublier que Amazon a accès aux métadonnées de connexion, même si on ne fait que passer du TLS dans ce tunnel.

Autre chose, PPTP est troué. Privilégiez du L2TP sur IPSEC si vous pouvez.

Pour info, le fonctionnement est le suivant:

• Grâce à CloudFormation, ça spawn une t2.micro avec l'AMI ubuntu 14.04 standard fournie par amazon: http://cloud-images.ubuntu.com/releases/trusty/release-20150123/
• Ça passe des données (en l'occurrence, un script) à l'instance en question via 'UserData'. Voir https://s3.amazonaws.com/webdigi/VPN/Unified-Cloud-Formation.json

[1] le VPN est en fait une instance t2.micro. On a le droit de faire tourner 1 intance t2.micro gratuitement par compte AWS pendant 1 mois. 15 GB de BP gratuit par mois, au delà c'est $0.09 / GB.

Pas encore lu.
Complémentaire avec l'article d'instagram: https://jeekajoo.eu/links/?-zo-hA

pour faire du cross-account avec aws
pratique l'histoire des rôles quand on a plusieurs comptes.

edit: bon en fait c'est hyper relou de switcher entre des rôles cross-account aws
parce que t'es obligé de re-changer la région à chaque fois

ec2 standard -> ec2 vpc

certains tirent profits des ssd ephemeres fournis avec les c3 pour les mettre en tant que cache devant des ebs.

En marge de la vulnérabilité sur bash (et de la connerie d'utiliser du cgi en 2014 + avoir un user www-data dont le shell est capable de se logguer...), il y a celle de Xen.

Cette faille n'a pas encore été révélée publiquement. Il faudra attendre le 1er octobre pour qu'elle le soit. C'est pour laisser le temps à des acteurs comme amazon oracle citrix rackspace etc.. de patcher. voir pre-disclosure list complète: http://www.xenproject.org/security-policy.html

Il y a fort à parier qu'il s'agit là d'une très grosse faille que amazon ne souhaite pas laisser être exploitée. Ils ont donc pris la décision de patcher tous leurs hyperviseurs avant le 'disclosure'.

Les conséquences pour les clients, dont l'entreprise pour laquelle je bosse, sont désastreuses ; car il s'agit de redémarrer - sous 3 jours! - un nombre conséquents de serveurs. Même en redémarrant préventivement des vm, on est pas sur qu'elles arrivent sur un hyperviseur qui est patché ; et donc elles redémarreront suivant la maintenance qu'aura prévu Amazon (ce week-end pour ma boite)... Bref, grosse galère, surtout pour les serveurs dont les données sont sur des stockages éphémères..

Enfin pour ce qui est de la faculté pour amazon de faire de la migration live, je rejoins ce commentaire:
"""
I would be surprised if Amazon didn't have high availability and live migration in the background, allowing them to reboot individual hypervisor hosts. You would still be stuck in your pool, but then if a host dies/needs patching it doesn't affect the guest VMs.

My suspicion is that the patch requires updating paravirtualization drivers (xen tools), which run on the VM itself and thus might require a reboot to update.
"""

Comme on a aucune idée de connaitre les perfs disque et réseau des instances ec2 (sauf en testant par soi-même), certains on fait des benchs.
Les résultats de ces benchs, qui testent les perfs réseau, montrent qu'on a intérêt à faire attention dans les choix d'instance....
"""
In our experiment we saw that the network performance of m1.large was lower than that of m1.medium. As per AWS documentation, the network performance of both m1.medium and m1.large is ‘moderate’ so we expected it to be similar. We also see that the network bandwidth of m3.medium is less than that of m1.small even though AWS documentation says that the network performance m3.medium is ‘moderate’ while that of m1.small is ‘low’. Network performance often depends on various scenarios like the network load on the actual hardware on which the VM is running. This might be a possible reason for this anomaly.
"""

voir aussi https://jeekajoo.eu/links/?GblCKw pour des comparaisons perf cpu/mem/disk

Tip #1: Choosing an EC2 Instance
Tip #2: Disable Swapping
Tip #3: Redis Persistence with Elastic Block Store
Tip #4: For Datasets < 4GB, Use 32-Bit Instances
Tip #5: Use Sharding to Properly Utilize Multi-Core EC2 Instances

"""
At a high-level, Security Monkey consists of the following components:

Watcher - The component that monitors a given AWS account and technology (e.g. S3, IAM, EC2). The Watcher detects and records changes to configurations. So, if a new IAM user is created or if an S3 bucket policy changes, the Watcher will detect this and store the change in Security Monkey’s database.
Notifier - The component that lets a user or group of users know when a particular item has changed. This component also provides notification based on the triggering of audit rules.
Auditor - Component that executes a set of business rules against an AWS configuration to determine the level of risk associated with the configuration. For example, a rule may look for a security group with a rule allowing ingress from 0.0.0.0/0 (meaning the security group is open to the Internet). Or, a rule may look for an S3 policy that allows access from an unknown AWS account (meaning you may be unintentionally sharing the data stored in your S3 bucket). Security Monkey has a number of built-in rules included, and users are free to add their own rules.

"""

"""
At a high-level, Security Monkey consists of the following components:

Watcher - The component that monitors a given AWS account and technology (e.g. S3, IAM, EC2). The Watcher detects and records changes to configurations. So, if a new IAM user is created or if an S3 bucket policy changes, the Watcher will detect this and store the change in Security Monkey’s database.
Notifier - The component that lets a user or group of users know when a particular item has changed. This component also provides notification based on the triggering of audit rules.
Auditor - Component that executes a set of business rules against an AWS configuration to determine the level of risk associated with the configuration. For example, a rule may look for a security group with a rule allowing ingress from 0.0.0.0/0 (meaning the security group is open to the Internet). Or, a rule may look for an S3 policy that allows access from an unknown AWS account (meaning you may be unintentionally sharing the data stored in your S3 bucket). Security Monkey has a number of built-in rules included, and users are free to add their own rules.

"""

page officielle des coûts d'instance EC2 amazon
(quand http://www.ec2instances.info/ n'est plus à jour ><, comme aujourd'hui )