Comment estimer une facture AWS Client VPN depuis la console
Un parcours d'estimation AWS Client VPN : comptez les associations, dérivez les heures de connexion des journaux de session, puis ajoutez les frais hors de la redevance du point de terminaison.
Le mois dernier, j'ai monté une estimation Client VPN dans un tableur, je l'ai envoyée à un client, puis je l'ai révisée deux fois : une fois parce que j'avais multiplié les associations par les sous-réseaux, et une fois parce que j'avais utilisé le nombre de personnes au lieu des données de session. La version qui a survécu à la relecture repose sur deux compteurs horaires et une courte liste de frais annexes. Vous pouvez la reconstruire depuis la console et un export de journal, sans calculateur de tarifs.
Deux compteurs, et rien d'autre sur le point de terminaison
AWS facture un point de terminaison Client VPN sur les heures d'association et les heures de connexion. Les heures d'association tournent pour chaque réseau cible rattaché au point de terminaison, jour et nuit, que quelqu'un se connecte ou non. Les heures de connexion tournent par client connecté, aussi longtemps que la session reste active.
| Meter | What increments it | What does not change it |
|---|---|---|
| Association-hours | Each associated subnet or Transit Gateway attachment, per hour, 24/7 while attached | Number of users, traffic volume |
| Connection-hours | Each active client session, per hour | How many subnets that client can reach |
Deux conséquences découlent directement de ce tableau. Un point de terminaison sans personne dessus coûte quand même de l'argent, et une personne qui fait tourner un ordinateur portable et un téléphone en même temps produit deux connexions.
Comptez les associations dans la console, pas les sous-réseaux du VPC
Ouvrez VPC, puis Client VPN endpoints, puis votre point de terminaison, puis l'onglet Associations. Chaque ligne y est un rattachement de sous-réseau, et ce nombre de lignes est votre multiplicateur d'associations. Le nombre de sous-réseaux applicatifs derrière le VPC n'a rien à voir.
Une association suffit pour atteindre un réseau VPC autorisé dès que les routes du point de terminaison et les règles d'autorisation couvrent la destination. Les associations supplémentaires achètent de la résilience de zone de disponibilité, pas de la portée supplémentaire. Un design à deux AZ double donc les heures d'association, alors qu'un VPC applicatif à huit sous-réseaux ne multiplie rien par huit.
Notez le type d'association pendant que vous êtes sur cette page. Une association de sous-réseau VPC et une association directe Transit Gateway sont des montages différents avec des lignes différentes, alors ne transportez pas un modèle dans le devis de l'autre. Et ne testez pas le décompte en détachant des choses : retirer le dernier réseau cible met fin aux sessions actives et bloque les nouvelles connexions jusqu'à ce que quelque chose soit associé de nouveau.
Dérivez les heures de connexion des données de session
Le nombre de personnes est la mauvaise entrée, et il est faux dans les deux sens. Dix personnes qui gardent chacune trois appareils connectés, cela fait trente connexions. Cent personnes qui se connectent vingt minutes par jour ne produisent pas du tout cent sessions simultanées.
Les journaux de connexion Client VPN enregistrent les événements de connexion et de déconnexion par client, soit exactement l'appariement qu'il vous faut. Exportez une semaine représentative, appariez les événements et additionnez les durées :
connection-hours = sum of (disconnect_time - connect_time) per session
sessions = one per client connection, not per personCorrigez ensuite deux habitudes. Les sessions laissées connectées pendant le déjeuner, la nuit ou une mise en veille d'ordinateur qui n'a jamais coupé le tunnel sont quand même facturées, et elles sont invisibles dans un décompte de personnes. La mesure est aussi horaire, alors budgétez une session de vingt minutes comme une heure pleine au lieu de supposer une facturation proportionnelle ; si la facture arrive plus basse, traitez cela comme une marge et non comme une donnée de planification.
Faites le calcul avec les tarifs de votre région
Les tarifs diffèrent selon la région, alors prenez-les sur la page de tarifs AWS VPN pour la région où vous déployez et collez-les dans la feuille comme entrées. À titre d'illustration seulement, prenez un tarif d'association de 0.10 dollar par heure et un tarif d'heure de connexion de 0.05 dollar, puis chiffrez un mois de 30 jours avec deux associations tenues tout le mois et 100 personnes connectées six heures sur 20 jours ouvrés :
association-hours = 2 * 24 * 30 = 1,440
association fee = 1,440 * 0.10 = 144.00
connection-hours = 100 * 6 * 20 = 12,000
connection fee = 12,000 * 0.05 = 600.00
Client VPN subtotal = 744.00Déplacez maintenant une entrée à la fois et regardez quelle ligne réagit. Doubler les associations ajoute ici 144 dollars ; doubler la durée moyenne de session ajoute 600. Ce rapport tranche généralement le débat de conception pour vous : coupez la redondance que vous ne pouvez pas justifier, ou attaquez les sessions inactives, selon le chiffre le plus grand. Écrivez la région et la date des tarifs à côté du résultat, car un devis sans elles ne peut pas être reproduit six semaines plus tard.
Ajoutez les frais que le sous-total omet
La redevance du point de terminaison paie le point de terminaison. Tout ce que le trafic touche ensuite a son propre compteur, et c'est sur ces lignes que les estimations VPN optimistes s'effondrent.
- Sortie internet pour le trafic qui sort par le point de terminaison, facturée au GB.
- Adresses IPv4 publiques, qui portent leurs propres frais horaires indépendamment du VPN.
- Ingestion et stockage CloudWatch Logs pour les journaux de connexion que vous venez d'exporter.
- Invocations Lambda si vous exploitez un gestionnaire client-connect.
- Directory Service ou votre fournisseur d'identité SAML, si c'est ainsi que les utilisateurs s'authentifient, plus les frais ACM Private CA si vous y émettez des certificats.
- Heures NAT Gateway et traitement des données, et heures de rattachement Transit Gateway plus traitement des données, chaque fois que le chemin les utilise.
Rien de tout cela n'évolue avec le nombre d'associations, c'est pourquoi un chiffre par utilisateur assemblé uniquement à partir des redevances de point de terminaison semble correct sur le papier puis grandit dès que le trafic réel apparaît. Mettez-les sur des lignes séparées même quand vous devez les estimer, pour que le lecteur voie quelles parties sont mesurées et lesquelles sont des suppositions.
Vérifiez la feuille avant de l'envoyer
Quatre contrôles attrapent les erreurs que j'ai réellement commises : le décompte d'associations correspond exactement à l'onglet Associations, les heures de connexion viennent d'événements de journal appariés et non d'un décompte de personnes, la région et la date des tarifs sont écrites, et chaque frais annexe a sa propre ligne. S'il manque l'un des quatre, vous avez une supposition avec de la mise en forme.
Tirez d'abord l'export du journal. C'est la seule entrée que vous ne pourrez pas reconstruire de mémoire plus tard, et il vous dit aussi si le problème des sessions inactives vaut la peine d'être corrigé avant la première facture.