Nous préférons utiliser les AMI préparées par l'équipe Debian. Leurs identifiants sont disponibles sur le [Wiki Debian](https://wiki.debian.org/Cloud/AmazonEC2Image), en particulier celles pour [Stretch](https://wiki.debian.org/Cloud/AmazonEC2Image/Stretch).
En tant qu'utilisateur du service EC2 d'Amazon, on peut être amené à vouloir partager ses AMI (Amazon Machine Image) avec d'autres utilisateurs (amis, clients, etc) qui utilisent donc un autre compte Amazon. La procédure pour cela est très simple, et directement intégré à l'interface web :
* En premier lieu, il est nécessaire de connaître le Account Number du compte qui aura accès à notre AMI (il ne s'agit de l'email utilisé pour s'identifier). On trouvera cela dans Your account > Personal Information, en haut à droite de la page.
* Ensuite, il suffit de faire un clic droit sur notre AMI dans la vue correspondante, de sélectionner Edit permissions et d'ajouter un ou plusieurs Account Number dans les champs prévus à cet effet.
* Sur l'autre compte, l'AMI sera alors accessible dans la catégorie Private images.
### Gérer plusieurs sous-comptes sur Amazon AWS avec IAM
*<https://console.aws.amazon.com/iam/home>
*<http://aws.amazon.com/iam/>
IAM est un module qui permet de créer des sous-comptes (et même des groupes) et de leur donner des permissions spécifiques.
On peut ainsi créer plusieurs sous-comptes ayant un accès total, ou uniquement des permissions spécifiques (accès à certains modules : EC2, S3, etc. en read-only ou full access).
Ces utilisateurs peuvent avoir un access key (pour accéder à l'API Amazon AWS) et/ou un mot de passe (pour l'accès web).
Pour l'accès web, cela se passe sur une URL spécifique qui est : <https://account-identifier.signin.aws.amazon.com/console/ec2>
### Migrer une instance EBS d'un compte à un autre
La migration de l'instance ne se fait pas correctement, il est nécessaire de migrer le snapshot puis de recréer l'instance sur le nouveau compte.
Vous devez au préalable snapshoter le volume de l'instance, et partager cette snapshot avec l'ID du nouveau compte (cf. «Partager une AMI Amazon EC2», en adaptant aux snapshots).
Voici la procédure à suivre, avec $EC2_CERT et $EC2_PRIVATE_KEY contenant les clés du nouveau compte :
* Tout d'abord on ne peux pas avoir une instance qui utilise une snapshot partagée, il faut donc créer un volume à partir de cette snapshot, puis snapshoter ce volume :
Lorsqu'on fait un `lsblk`, on voit que la partition montée sur `/` est la première. On pourrait alors se dire qu'il n'est pas possible d'agrandir la partition.
~~~
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
xvda 202:0 0 20G 0 disk
├─xvda1 202:1 0 7.9G 0 part /
├─xvda14 202:14 0 3M 0 part
└─xvda15 202:15 0 124M 0 part /boot/efi
~~~
En réalité, la partition 1 est en dernier ! On peut le vérifier avec les secteurs de début et de fin des partitions.
~~~
# fdisk -l /dev/xvda
[…]
Device Start End Sectors Size Type
/dev/xvda1 262144 16775167 16513024 7.9G Linux filesystem
/dev/xvda14 2048 8191 6144 3M BIOS boot
/dev/xvda15 8192 262143 253952 124M EFI System
[…]
~~~
Dans ce cas, on peut agrandir la partition 1 sans problème.
**ATTENTION** Par défaut, le serveur SSH est configuré globalement avec le paramètre : `PasswordAuthentication no`. Cette ligne doit être commentée, si on utilise pas d'authentification par clé SSH.
Via l'interface web AWS, on a accès à un screenshot de l'écran actuel de la VM (en read-only).
Attention ! Il faut se méfier de ce screenshot qui peut ne pas réfléter l'état réel de la machine... exemple typique au démarrage d'une machine, vous verrez l'écran du "BIOS QEMU" avec "Loading initial ramdisk ..."
pourtant la VM n'est pas forcément dans cet état, il est probable qu'en fait elle est en cours de boot ou pire, que son boot a échoué pour une raison ou une autre POURTANT VOUS NEVERREZPAS CELA SUR LE SCREENSHOT !!
« L'équilibrage de charge » fonctionne sur le principe suivant.
- On crée un nouveau « Équilibreur de charge d'application » ;
- On choisi « l'écouteur » (HTTP ou HTTPS) (équivalent frontend) ;
- Si on a choisi HTTPS, on choisit un certificat (que l'on peut créer via Amazon) ;
- On rattache un groupe de sécurité (règles pare-feu) ;
- On crée un nouveau groupe cible qui contient la liste des backend avec le choix du protocole, HTTP, HTTPS ou TCP. On pourra spécifier une URI a surveiller ;
Les instances EC2 sont limitées en envoi de mail par le port 25. Il est possible de demander la levée de ces limites : <https://aws.amazon.com/fr/premiumsupport/knowledge-center/ec2-port-25-throttle/>
Il est également possible d'y accéder via un outil plus haut niveau, généralement préinstallés sur les images d'Amzon, ou disponibles via le paquet `cloud-guest-utils`.
La commande `configure` de stocker dans un fichier les valeurs par défaut pour 4 options courantes.
~~~
$ aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [None]:
Default output format [None]:
~~~
Si vous renseignez vos identifiants, ils seront stockés dans `~/.aws/credentials`. Vérifiez bien les permissions d'accès à ce fichier car ces identifiants donnent accès à l'ensemble des actions possibles sur AWS.
Il est possible de créer un ou plusieurs profils pour pré-enregistrer des options par compte. Il faudra ensuitre indiquer le nom du profil à utiliser au lancement des commandes.
L'option `--output` permet d'indiquer si on souhaite une sortie en `text`, `xml` ou `json`.
Lors des appels à des commandes, il peut être nécessaire de fournir l'identifiant de l'instance, le nom de la région… Si la commande est exécutée depuis une instance AWS, certaines de ces infos sont dynamiquement accessibles depuis [des API de méta-données](#meta-données).
