Base de connaissances
Créez une clé d'accès AWS autorisée à lire CloudFront et à créer des invalidations, puis connectez-la afin qu'un site puisse s'exécuter sur votre propre distribution CloudFront.
Connecter votre propre compte AWS vous permet de placer un site sur votre CDN plutôt que sur le nôtre. La zone, le trafic et la facture relèvent de votre compte, et vous pouvez toujours vider le cache et modifier les paramètres du CDN depuis votre tableau de bord Zinn® — sans basculer entre différents panneaux.
Un compte AWS. Créez un utilisateur IAM pour cette connexion dont la politique autorise l'accès en lecture à CloudFront et cloudfront:CreateInvalidation, ce dont le vidage du cache a besoin.
Pour desservir votre propre domaine, CloudFront a également besoin d'un certificat pour celui-ci dans AWS Certificate Manager de la région us-east-1. Les certificats de toute autre région sont invisibles pour CloudFront, quelle que soit la région dans laquelle vous travaillez par ailleurs.
Dans la console AWS, ouvrez IAM → Users, choisissez l'utilisateur qui doit servir de support à cette connexion (créez-en un dédié — n'utilisez jamais votre compte racine), ouvrez son onglet Security credentials et, sous Access keys, choisissez Create access key. Sélectionnez Other comme cas d'utilisation, continuez, et choisissez Create access key. Copiez l'Access key ID et la Secret access key — AWS n'affiche la clé secrète qu'une seule fois. Chaque utilisateur IAM peut détenir deux clés à la fois.
Ouvrez Integrations dans votre tableau de bord et choisissez Connect an account. Sélectionnez Your own CDN comme groupe et Amazon CloudFront comme compte, renseignez l'Access key ID et la Secret access key, puis appuyez sur Connect account.
Nous testons ce que vous collez avant que quoi que ce soit ne soit enregistré. Une clé qui ne fonctionne pas n'est jamais stockée, et la réponse indique ce qui n'allait pas. Une clé qui fonctionne est conservée de manière chiffrée dans notre coffre-fort de secrets — jamais dans notre base de données — et n'est plus jamais affichée, pas même pour vous.
apparaît comme destination. Choisissez-le et confirmez ; nous construisons la configuration du site sur votre compte, la vérifions, et ce n'est qu'alors que nous déplaçons le site, afin qu'il reste en ligne pendant le transfert.
compte.
détail, vider le cache, modifier les paramètres et — lorsque le fournisseur en dispose — les règles géographiques. La liste de contrôle située à côté de la connexion indique celles que nous avons pu confirmer, de sorte qu'une autorisation manquante est visible avant de déplacer un site sur le compte.
Votre domaine ne peut pas être rattaché. Il n'y a aucun certificat pour celui-ci dans us-east-1. Demandez-en un dans AWS Certificate Manager dans cette région, puis réessayez.
Le vidage échoue. La politique de l'utilisateur manque de cloudfront:CreateInvalidation. Ajoutez-la ; la clé ne change pas.
Il est indiqué que la clé a été rejetée. C'est presque toujours l'une de ces trois choses : un espace ou un saut de ligne copié avec elle, une clé qui a expiré, ou une clé qui a été révoquée ou régénérée après que vous l'avez copiée. Créez-en une nouvelle et collez-la à nouveau.
La connexion s'établit, mais un élément échoue par la suite. La clé s'authentifie mais manque d'une autorisation dont l'action a besoin. Créez une nouvelle clé avec les autorisations énumérées ci-dessus, puis déconnectez l'ancienne connexion et connectez la nouvelle clé.
Ouvrez Integrations, trouvez le compte et appuyez sur Disconnect. Cela supprime immédiatement la clé stockée. Tout ce qui l'utilisait s'arrête lors de sa prochaine action, et les écrans qui en dépendaient l'indiquent au lieu d'échouer silencieusement.
La déconnexion n'annule pas ce qui a déjà été fait — les enregistrements, déploiements ou paramètres que nous avons modifiés sur votre compte restent tels quels. Si vous pensez que la clé elle-même a pu fuiter, révoquez-la également auprès du fournisseur ; la déconnexion supprime notre copie, pas la sienne.
Ce que nous écrivons sur l'hébergement, le SEO et la gestion de sites à grande échelle.
Comment l'hébergement façonne l'indexation et la valeur des liens en 2026 : maintenir les pages indexées, auditer les domaines expirés avant de les exploiter, créer des liens sans laisser de traces, et un point de vue honnête sur ce que l'infrastructure peut et ne peut pas faire pour le référencement naturel.
Lire l'article →Une liste de contrôle pratique pour un WordPress rapide et sécurisé : mise en cache au niveau du serveur, cache d'objets par site, la poignée de plugins qui valent la peine d'être utilisés, mise à jour de la pile technique, et les pages WooCommerce à ne jamais mettre en cache.
Lire l'article →Ce qui distingue réellement un bon hébergement infogéré d'un serveur bas de gamme avec panneau de configuration — migrations, sauvegardes, isolation, véritable mise en cache et mise à l'échelle honnête — et comment l'évaluer avant de vous engager.
Lire l'article →Le support est inclus dans chaque forfait, le service est ouvert 24 heures par jour et vous pouvez nous écrire dans l'une de nos 58 langues ; nous vous répondons dans la vôtre.
Contacter le support → Tous les articles →