AWS les bases : Region, IAM et les services principaux

1. Présentation générale

Cet article vous aide à maîtriser rapidement les trois piliers les plus importants quand on découvre AWS : region (choisir où héberger l’infrastructure), IAM (qui a le droit de faire quoi) et les services principaux (EC2, S3, RDS, Lambda, VPC…). Après l’avoir lu, vous comprendrez comment organiser votre compte AWS en toute sécurité, comment créer un IAM role pour votre application, et comment écrire du code Java pour appeler S3 via AWS SDK v2.

2. Région et Availability Zone

AWS divise son infrastructure en regions (zones géographiques, par exemple ap-southeast-1 à Singapour) et chaque région compte plusieurs Availability Zones (AZ) — des data centers indépendants en termes d’électricité et de réseau, situés près les uns des autres pour une latence basse mais toujours isolés en cas de panne (fault isolation).

aws ec2 describe-availability-zones --region ap-southeast-1

La commande ci-dessus liste les AZ de la région Singapour. Le résultat ressemble généralement à :

ZoneName: ap-southeast-1a
ZoneName: ap-southeast-1b
ZoneName: ap-southeast-1c

Quand vous concevez un système, vous devriez déployer sur au moins 2 AZ pour la haute disponibilité. Par exemple, un Auto Scaling Group ou une instance RDS Multi-AZ reposent tous deux sur ce principe.

Note : Certains services sont globaux (non liés à une région spécifique) comme IAM, Route 53, CloudFront. La plupart des autres services (EC2, S3, RDS…) sont régionaux — les données ne se répliquent pas automatiquement vers une autre région à moins que vous le configuriez.

2.1. Comment choisir une région

Trois critères principaux : latence (proximité avec vos utilisateurs), conformité (exigences de résidence des données), et coût (les prix des services varient selon les régions). Pour les utilisateurs au Vietnam, ap-southeast-1 (Singapour) est généralement le choix par défaut en raison d’une latence faible et d’une gamme de services complète.

3. IAM : User, Group, Role, Policy

IAM (Identity and Access Management) contrôle qui a accès à quelles ressources. Quatre concepts fondamentaux :

• User : une identité spécifique (personne ou service) avec ses propres credentials.
• Group : un ensemble d’utilisateurs auxquels vous attachez une policy commune pour simplifier la gestion.
• Role : un ensemble de permissions temporaires sans credentials fixes — utilisé pour EC2, Lambda, ou l’accès cross-account.
• Policy : un document JSON décrivant les permissions (allow/deny) sur les actions et ressources.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::order-invoices-bucket/*"
    }
  ]
}

Cette policy permet de lire/écrire des objets dans le bucket order-invoices-bucket. Attachez la policy à un role puis attachez ce role à une instance EC2 ou une fonction Lambda exécutant le service InvoiceStorageService — l’application aura automatiquement les permissions sans avoir besoin de hard-coder access key/secret key.

aws iam create-role \
  --role-name InvoiceServiceRole \
  --assume-role-policy-document file://trust-policy.json

aws iam attach-role-policy \
  --role-name InvoiceServiceRole \
  --policy-arn arn:aws:iam::123456789012:policy/InvoiceBucketAccess

La première commande crée un role avec trust-policy.json qui définit qui peut « assume » ce role (par exemple le service EC2). La deuxième commande attache la policy de permissions spécifiques au role.

Note : Ne mettez jamais les access key/secret key directement dans le code ou dans Git. Utilisez IAM Role (pour les ressources exécutées sur AWS) ou IAM Identity Center/SSO (pour les utilisateurs).

3.1. Principe du moindre privilège

N’accordez que les permissions strictement nécessaires, ne utilisez pas la policy AdministratorAccess pour les comptes de service. Par exemple, si une Lambda ne doit que lire un bucket, ne lui accordez pas s3:* sur tout le compte.

{
  "Effect": "Deny",
  "Action": "s3:DeleteBucket",
  "Resource": "*"
}

Une déclaration Deny est toujours prioritaire par rapport à Allow en cas de conflit — c’est un moyen d’ajouter un « filet de sécurité » contre la suppression accidentelle de buckets importants.

4. Les services principaux

4.1. Calcul

• EC2 : machines virtuelles louées à l’heure/à la seconde, vous gérez l’OS vous-même.
• Lambda : exécute du code déclenché par des événements (event-driven), pas de gestion de serveur, facturé selon le nombre d’appels et le temps d’exécution.
• ECS/EKS : exécute des conteneurs (Docker) avec orchestration.

aws lambda invoke \
  --function-name CalculateOrderTotal \
  --payload '{"orderId":"ORD-1001"}' \
  response.json

Cette commande invoque la fonction CalculateOrderTotal avec une payload JSON, le résultat est écrit dans response.json.

4.2. Stockage

• S3 : stockage d’objets, stockez n’importe quel fichier (images, logs, sauvegardes), durabilité de 99.999999999%.
• EBS : stockage bloc attaché aux instances EC2.
• EFS : système de fichiers partagé que plusieurs EC2 peuvent monter.

4.3. Base de données

• RDS : base de données relationnelle gérée (MySQL, PostgreSQL…), sauvegarde et correctifs automatiques.
• DynamoDB : NoSQL, scaling horizontal automatique, latence de quelques millisecondes.

4.4. Réseau

• VPC : réseau privé virtuel, vous définissez les subnets, les tables de routage, les security groups.
• Security Group : pare-feu stateful au niveau de l’instance.

Resources:
  OrderServiceSG:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Allow HTTPS inbound
      VpcId: vpc-0123456789abcdef0
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: 443
          ToPort: 443
          CidrIp: 0.0.0.0/0

Ce fichier CloudFormation crée un Security Group nommé OrderServiceSG, qui ouvre uniquement le port 443 (HTTPS) à tous les IPs — les autres règles inbound sont refusées par défaut.

5. Appeler S3 depuis une application Java

Cette section montre comment un service Spring Boot envoie des fichiers vers S3 via AWS SDK for Java v2.

<dependency>
    <groupId>software.amazon.awssdk</groupId>
    <artifactId>s3</artifactId>
    <version>2.25.16</version>
</dependency>

public class InvoiceStorageService {

    private final S3Client s3Client;
    private final String bucketName;

    public InvoiceStorageService(S3Client s3Client, String bucketName) {
        this.s3Client = s3Client;
        this.bucketName = bucketName;
    }

    public void uploadInvoice(String orderId, byte[] content) {
        PutObjectRequest request = PutObjectRequest.builder()
                .bucket(bucketName)
                .key("invoices/" + orderId + ".pdf")
                .build();

        s3Client.putObject(request, RequestBody.fromBytes(content));
    }
}

S3Client est injecté via le constructeur (il récupère automatiquement les credentials d’IAM Role s’il s’exécute sur EC2/Lambda, pas besoin de hard-coder). La méthode uploadInvoice crée une PutObjectRequest où key est le chemin de l’objet dans le bucket, puis appelle putObject pour envoyer le contenu à S3.

Configuration du bean S3Client :

@Bean
public S3Client s3Client() {
    return S3Client.builder()
            .region(Region.AP_SOUTHEAST_1)
            .build();
}

Pas besoin de passer explicitement credentialsProvider — le SDK utilise automatiquement la Default Credentials Provider Chain : il cherche dans l’ordre les variables d’environnement, le fichier ~/.aws/credentials, puis le IAM Role attaché à EC2/ECS/Lambda.

5.1. Test avec un mock S3Client

@Test
void shouldCallPutObjectWithCorrectKey() {
    S3Client mockS3 = mock(S3Client.class);
    InvoiceStorageService service = new InvoiceStorageService(mockS3, "order-invoices-bucket");

    service.uploadInvoice("ORD-1001", "contenu de la facture".getBytes());

    ArgumentCaptor<PutObjectRequest> captor = ArgumentCaptor.forClass(PutObjectRequest.class);
    verify(mockS3).putObject(captor.capture(), any(RequestBody.class));

    assertThat(captor.getValue().bucket()).isEqualTo("order-invoices-bucket");
    assertThat(captor.getValue().key()).isEqualTo("invoices/ORD-1001.pdf");
}

Ce test mock S3Client (avec Mockito) pour ne pas appeler AWS réellement lors de l’exécution des tests CI. ArgumentCaptor capture la PutObjectRequest réelle qui a été envoyée, puis AssertJ vérifie que bucket et key sont corrects — cela garantit que la logique de construction de la requête est bonne sans dépenser de bande passante.

Note : Pour un test d’intégration réel avec S3, utilisez LocalStack ou Testcontainers au lieu d’appeler un bucket réel en production — cela évite les frais supplémentaires et les risques de sécurité des données.

6. Erreurs courantes

• Laisser un bucket S3 public par inadvertance : activez toujours « Block Public Access » au niveau du compte sauf si vous avez vraiment besoin d’un bucket public (par exemple pour un site statique).
• Attacher une policy trop large ("Action": "*", "Resource": "*") à un role de test puis oublier de la retirer avant la production.
• Ne pas activer MFA pour le compte root : le compte root a tous les droits, perdre l’accès au root est le risque le plus grave.
• Hard-coder les access keys dans le code : utilisez plutôt IAM Role, Secrets Manager, ou des variables d’environnement via les secrets CI/CD.
• Choisir la mauvaise région entraîne une latence élevée pour les utilisateurs finaux, ou viole les exigences de résidence des données.

7. Conclusion

La région vous aide à choisir le bon emplacement pour votre infrastructure en équilibrant latence, coût et conformité. IAM est la première et la plus importante couche de sécurité — appliquez toujours le principe du moindre privilège et préférez les Roles aux access keys statiques. Maîtriser l’ensemble des services principaux (EC2, S3, RDS, Lambda, VPC) et leur intégration via AWS SDK vous donne les bases nécessaires pour commencer à déployer des systèmes réels sur AWS.