Re: [FRnOG] [TECH] Retour d'expériences AWS
Hello, Ma contribution à ce fil intéressant : Si ton "copain" compte migrer des workloads VMWARE sur AWS qu'il héberge en on-prem , y'a possibilité de le faire en mode SDDC hébergé : https://aws.amazon.com/vmware/faqs/ Et avec ce mode de "migration", y'a possibilité de faire des extensions de VLAN en mode hybride (L2VPN / HCX) soit via Internet soit via un DirectConnect : https://aws.amazon.com/blogs/apn/options-for-extending-layer-2-on-premises-networks-to-vmware-cloud-on-aws/ Y'a aussi quelques restrictions qui, comme souvent, se contournent avec la multiplication d'instances ou de PaaS, mais ça pourrait valoir le coup de se pencher sur la question, non ? Un de nos clients fait tourner genre 40 VMs dans ce mode-là, le plus "fun" étant que les passerelles des serveurs sont toujours dans son on-prem. Bonne nuit, et salutations du Québec ! Geoffray Le lun. 23 nov. 2020 09 h 39, Mickael Hubert a écrit : > Bonjour à tous, > j'aimerais vous demander un retour d'expérience de l'hébergeur AWS. Car il > se peut qu'une éventualité arrive pour qu'un copain (pas moi ;) ) doive > migrer toute ou partie de ses services chez AWS. > > déjà niveau réseau, comment cela s'organise ? Actuellement, nous avons 2 DC > avec du L2 et avons créé notre propre L3 avec routage OSPF, BGP pour les > interco client, QOS entre les 2 DC, etc ... > > Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2 > par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un > partenaire à eux (j'ai peur de votre réponse ...) ? > > Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap > IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits > avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à > nos VM ? > > A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il > pouvoir router soi-même ... ? > > Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS. > Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais > d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien > ? > > Merci d'avance pour votre aide ! > > ++ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
[TECH] RE: [FRnOG] [TECH] Retour d'expériences AWS
Hello, Tu n'as pas la notion de VLAN sur un VPC AWS. Donc propager un L2 ... voila ;) Comment se passe les interco : T'en a 2 type : - les dédiées - les managées La dédié, c'est une interco ou tu vas demander un port dédié à AMAZON pour venir connecter ton opérateur dessus. Le port c'est 1G ou 10G. Par-dessus ce port tu pourras y connecter des circuits/VLAN via une Virtual-Interface sur AWS. Cette Virtual-Interface sera connectée à un Virtual Private Gateway et tu devras ensuite configurer un BGP entre AWS et toi... et donc un L3 et pas un L2. La managé, c'est l'opérateur qui possède le port AWS, et il te vend juste le circuit/VLAN. Dans ta souscription tu vois une virtual interface qui apparait et qui est dispo. Tu n'a juste qu'à la brancher sur ta gateway et monter le BGP par-dessus. Bref, oublie le L2 avec les cloud public, de mémoire (vous me corrigez si je dis une bêtise), seul le dedicated connect de chez OVH te permet l'extension L2 d'un VLAN en DC de chez toi et tes LAN cloud OVH (sur un PCC) Laurent GUINCHARD -Message d'origine- De : frnog-requ...@frnog.org De la part de Mickael Hubert Envoyé : lundi 23 novembre 2020 15:38 À : frnog-tech Objet : [FRnOG] [TECH] Retour d'expériences AWS Bonjour à tous, j'aimerais vous demander un retour d'expérience de l'hébergeur AWS. Car il se peut qu'une éventualité arrive pour qu'un copain (pas moi ;) ) doive migrer toute ou partie de ses services chez AWS. déjà niveau réseau, comment cela s'organise ? Actuellement, nous avons 2 DC avec du L2 et avons créé notre propre L3 avec routage OSPF, BGP pour les interco client, QOS entre les 2 DC, etc ... Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2 par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un partenaire à eux (j'ai peur de votre réponse ...) ? Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à nos VM ? A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il pouvoir router soi-même ... ? Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS. Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien ? Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
> Le 25 nov. 2020 à 17:24, Alain Bieuzent a écrit : > > Change potes !!! Exactement! mais pas que... Il m’arrive très souvent d’arrêter d’être client d’entreprises qui ne voient que par le cloud US... fournisseur d’élect, comptable,... Et au final c’est le client qui a le plus son mot à dire. Sauf que ça reste marginal malheureusement, mais je constate que ca va dans le bon sens depuis quelques années. > > Le 25/11/2020 16:31, « Mickael Hubert » mick...@winlux.fr> a écrit : > >Bonjour à tous et merci pour vos réponses, cela va bien nous aider. >Je préciserai que je suis 100% d'accord pour consommer Français, mais comme >dirait un "autre" copain à moi (qui se reconnaîtra): >"Une entreprise n'est pas une démocratie et tu fais ce qu'on te demande" ;) > >++ > >>Le mar. 24 nov. 2020 à 09:50, Wallace a écrit : >> >> >>> Le 23/11/2020 à 23:31, Raphael Mazelier a écrit : >>> >>> Par exemple : LB , pas de problème il s'agit de reverse proxy https >>> classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque >>> c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à >>> toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as >>> plus intéressant, car utiliser un cloud publique sans utiliser son >>> object storage c'est se passer d'une ressource plus qu'avantageuse. >>> L'ennui c'est que S3 est devenu un standard de facto (voir Minio par >>> exemple) mais pas disponible partout (notamment sur Azure). Résultat >>> ma recommandation la dessus serait de l'utiliser mais avec une petite >>> couche d'abstraction. Pour le reste des autres services types DynamoDB >>> (pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car >>> c'est en effet trop se locker. >>> >> Déployer un haproxy / nginx reverse ssl / traefik c'est pas bien >> compliqué pour un faire un LB. Les bases de données pour moi c'est nogo >> tout est en clair ils ont toutes tes données, tu ne pourra jamais être >> certifiable et pour assurer une protection rgpd bon courage. >> >> Pour l'object storage oui c'est à utiliser et on en trouve sur tous les >> clouds et sur openstack donc rien à redire là dessus si ce n'est faites >> gaffe à ce que vous mettez dessus :) >> >> Quand on déploie pour des clients dans ces clouds on fait que des >> instances sur lesquels les disques sont chiffrés et on déploie les >> services voulu, ça n'empêche pas d'être elastic à la charge mais >> l'intelligence est gérée dans les CI/CD de notre côté pas côté cloud. Y >> a aussi les containers pour être élastic. >> >> >> --- >> Liste de diffusion du FRnOG >> http://www.frnog.org/ >> > >--- >Liste de diffusion du FRnOG >http://www.frnog.org/ > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
> Je répondrais une phrase de Steve Jobs qui devrait guider tous les > patrons : +1000 Je n'aimais pas le bonhomme mais le NeXT Cube est un chef-d'œuvre. Effectivement, il n'a ni fait l'OS, ni le fantastique env. de dev, ni le hardware, ni l'architecture géniale tout PS, de l'écran à l'imprimante. Pourtant, sans lui, il n'y aurait pas eu de NeXT Cube. -- Be Seeing You Number Six --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Change potes !!! Le 25/11/2020 16:31, « Mickael Hubert » a écrit : Bonjour à tous et merci pour vos réponses, cela va bien nous aider. Je préciserai que je suis 100% d'accord pour consommer Français, mais comme dirait un "autre" copain à moi (qui se reconnaîtra): "Une entreprise n'est pas une démocratie et tu fais ce qu'on te demande" ;) ++ Le mar. 24 nov. 2020 à 09:50, Wallace a écrit : > > Le 23/11/2020 à 23:31, Raphael Mazelier a écrit : > > > > Par exemple : LB , pas de problème il s'agit de reverse proxy https > > classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque > > c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à > > toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as > > plus intéressant, car utiliser un cloud publique sans utiliser son > > object storage c'est se passer d'une ressource plus qu'avantageuse. > > L'ennui c'est que S3 est devenu un standard de facto (voir Minio par > > exemple) mais pas disponible partout (notamment sur Azure). Résultat > > ma recommandation la dessus serait de l'utiliser mais avec une petite > > couche d'abstraction. Pour le reste des autres services types DynamoDB > > (pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car > > c'est en effet trop se locker. > > > Déployer un haproxy / nginx reverse ssl / traefik c'est pas bien > compliqué pour un faire un LB. Les bases de données pour moi c'est nogo > tout est en clair ils ont toutes tes données, tu ne pourra jamais être > certifiable et pour assurer une protection rgpd bon courage. > > Pour l'object storage oui c'est à utiliser et on en trouve sur tous les > clouds et sur openstack donc rien à redire là dessus si ce n'est faites > gaffe à ce que vous mettez dessus :) > > Quand on déploie pour des clients dans ces clouds on fait que des > instances sur lesquels les disques sont chiffrés et on déploie les > services voulu, ça n'empêche pas d'être elastic à la charge mais > l'intelligence est gérée dans les CI/CD de notre côté pas côté cloud. Y > a aussi les containers pour être élastic. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Le 25/11/2020 à 16:29, Mickael Hubert a écrit : Bonjour à tous et merci pour vos réponses, cela va bien nous aider. Je préciserai que je suis 100% d'accord pour consommer Français, mais comme dirait un "autre" copain à moi (qui se reconnaîtra): "Une entreprise n'est pas une démocratie et tu fais ce qu'on te demande" ;) Je répondrais une phrase de Steve Jobs qui devrait guider tous les patrons : Cela n'a pas de sens d'embaucher des gens intelligents et de leur dire quoi faire ; nous embauchons des gens intelligents pour qu'ils nous disent ce qu'il faut faire. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Bonjour à tous et merci pour vos réponses, cela va bien nous aider. Je préciserai que je suis 100% d'accord pour consommer Français, mais comme dirait un "autre" copain à moi (qui se reconnaîtra): "Une entreprise n'est pas une démocratie et tu fais ce qu'on te demande" ;) ++ Le mar. 24 nov. 2020 à 09:50, Wallace a écrit : > > Le 23/11/2020 à 23:31, Raphael Mazelier a écrit : > > > > Par exemple : LB , pas de problème il s'agit de reverse proxy https > > classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque > > c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à > > toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as > > plus intéressant, car utiliser un cloud publique sans utiliser son > > object storage c'est se passer d'une ressource plus qu'avantageuse. > > L'ennui c'est que S3 est devenu un standard de facto (voir Minio par > > exemple) mais pas disponible partout (notamment sur Azure). Résultat > > ma recommandation la dessus serait de l'utiliser mais avec une petite > > couche d'abstraction. Pour le reste des autres services types DynamoDB > > (pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car > > c'est en effet trop se locker. > > > Déployer un haproxy / nginx reverse ssl / traefik c'est pas bien > compliqué pour un faire un LB. Les bases de données pour moi c'est nogo > tout est en clair ils ont toutes tes données, tu ne pourra jamais être > certifiable et pour assurer une protection rgpd bon courage. > > Pour l'object storage oui c'est à utiliser et on en trouve sur tous les > clouds et sur openstack donc rien à redire là dessus si ce n'est faites > gaffe à ce que vous mettez dessus :) > > Quand on déploie pour des clients dans ces clouds on fait que des > instances sur lesquels les disques sont chiffrés et on déploie les > services voulu, ça n'empêche pas d'être elastic à la charge mais > l'intelligence est gérée dans les CI/CD de notre côté pas côté cloud. Y > a aussi les containers pour être élastic. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Le 23/11/2020 à 23:31, Raphael Mazelier a écrit : Par exemple : LB , pas de problème il s'agit de reverse proxy https classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as plus intéressant, car utiliser un cloud publique sans utiliser son object storage c'est se passer d'une ressource plus qu'avantageuse. L'ennui c'est que S3 est devenu un standard de facto (voir Minio par exemple) mais pas disponible partout (notamment sur Azure). Résultat ma recommandation la dessus serait de l'utiliser mais avec une petite couche d'abstraction. Pour le reste des autres services types DynamoDB (pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car c'est en effet trop se locker. Déployer un haproxy / nginx reverse ssl / traefik c'est pas bien compliqué pour un faire un LB. Les bases de données pour moi c'est nogo tout est en clair ils ont toutes tes données, tu ne pourra jamais être certifiable et pour assurer une protection rgpd bon courage. Pour l'object storage oui c'est à utiliser et on en trouve sur tous les clouds et sur openstack donc rien à redire là dessus si ce n'est faites gaffe à ce que vous mettez dessus :) Quand on déploie pour des clients dans ces clouds on fait que des instances sur lesquels les disques sont chiffrés et on déploie les services voulu, ça n'empêche pas d'être elastic à la charge mais l'intelligence est gérée dans les CI/CD de notre côté pas côté cloud. Y a aussi les containers pour être élastic. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Retour d'expériences AWS
> Mickael Hubert a écrit : > j'aimerais vous demander un retour d'expérience de l'hébergeur AWS. Car il se > peut qu'une éventualité > arrive pour qu'un copain (pas moi ;) ) doive migrer toute ou partie de ses > services chez AWS. Déjà > niveau réseau, comment cela s'organise ? Actuellement, nous avons 2 DC avec > du L2 et avons créé notre > propre L3 avec routage OSPF, BGP pour les interco client, QOS entre les 2 DC, > etc ... Avec 2 fois le temps, 3 fois le boulot, et 4 fois les emmerdes tu peux faire çà dans le cloud. A noter que je ne tape pas sur AWS; il y a pire. Ceci étant dit, çà reste une usine à gaz sans grande valeur : ton infra AWS ou autre vendeur, elle ne vaut pas un caramel mou, car la bouger ailleurs coute plus cher que de refaire du neuf. Alternative pour ton copain : aller bosser quelque part ailleurs. Pour l'infrastructure L2 entre 2 DC, euh > Wallace a écrit : > Le privacy shield a sauté entre l'EU et les USA, héberger des données aux USA > devient de facto illégal. N'ayant pas le problème, je vous plains de tout coeur. > Avec une solution maitrisée en interne tu peux rapidement réinstaller > dans un autre cloud avec une simple migration dns et des données. Justement si tu fais çà (j'approuve), il ne faut pas penser cloud. Il faut penser hébergement / colo / datacenter. > Quand tu utilises la base de donnée managé, le load balancer, le ... ben t'es > bien coincé. C'est bien le but du jeu : l'infrastructure cloud n'a aucune valeur en dehors du cloud dans laquelle elle existe (va essayer de migrer de Azure vers AWS ou l'inverse), donc le fournisseur de cloud te tiens par les coucougnettes ad vitam eternam. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
On 23/11/2020 18:50, Wallace wrote: En dehors de ce problème légal, attention à l'utilisation des fonctionnalités avancées des clouds, il vaut mieux déployer ses propres instances avec les services que l'on veut et que l'on maîtrise plutôt que de s'enfermer dans une solution AAS et ne plus pouvoir bouger à moins de redévelopper les connecteurs API et souvent les applis. Avec une solution maitrisée en interne tu peux rapidement réinstaller dans un autre cloud avec une simple migration dns et des données. Quand tu utilises la base de donnée managé, le load balancer, le ... ben t'es bien coincé. Plutôt pour Frsag mais c'est intéressant. En effet c'est une des grosses questions qu'il faut se poser quand on va dans l'un des trois gros cloud publique. Quel degré d'adhérence tolérer pour mon déploiement ? D'un coté tu voudrais avoir le moins d'adhérence possible, donc en faisait du pur IaaS. D'un autre coté utiliser un cloud sans ses services managés c'est perdre une grande partie de son intérêt. Ce que je préconiserais c'est d'utiliser les services managés avec parcimonie, et de surtout regarder leur compatibilité. Par exemple : LB , pas de problème il s'agit de reverse proxy https classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as plus intéressant, car utiliser un cloud publique sans utiliser son object storage c'est se passer d'une ressource plus qu'avantageuse. L'ennui c'est que S3 est devenu un standard de facto (voir Minio par exemple) mais pas disponible partout (notamment sur Azure). Résultat ma recommandation la dessus serait de l'utiliser mais avec une petite couche d'abstraction. Pour le reste des autres services types DynamoDB (pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car c'est en effet trop se locker. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Bonsoir, Le privacy shield a sauté entre l'EU et les USA, héberger des données aux USA devient de facto illégal. Plusieurs DSI de cac40 et la Syntec ont appelé l'EU a revenir à la table des négociations, fin de non recevoir opposée, les USA doivent adapter leurs garanties et leurs législations, ce n'est pas prêt d'arriver. C'est devenu illégal d'aller dans les cloud US SAUF à obtenir de leurs parts des garanties entre ton entreprise et les leurs qui sont contraires à leurs propres droits, autant dire personne ne peut les obtenir. https://www.cnil.fr/fr/invalidation-du-privacy-shield-la-cnil-et-ses-homologues-analysent-actuellement-ses-consequences https://www.latribune.fr/opinions/tribunes/le-transfert-de-donnees-personnelles-entre-les-etats-unis-et-l-europe-illegal-on-fait-quoi-855077.html https://www.nextinpact.com/article/43466/apres-invalidation-privacy-shield-insecurite-juridique-totale-selon-me-ricouart-maillet En dehors de ce problème légal, attention à l'utilisation des fonctionnalités avancées des clouds, il vaut mieux déployer ses propres instances avec les services que l'on veut et que l'on maîtrise plutôt que de s'enfermer dans une solution AAS et ne plus pouvoir bouger à moins de redévelopper les connecteurs API et souvent les applis. Avec une solution maitrisée en interne tu peux rapidement réinstaller dans un autre cloud avec une simple migration dns et des données. Quand tu utilises la base de donnée managé, le load balancer, le ... ben t'es bien coincé. Et consommer EU oui ça peut faire du bien aussi :) Le 23/11/2020 à 15:38, Mickael Hubert a écrit : Bonjour à tous, j'aimerais vous demander un retour d'expérience de l'hébergeur AWS. Car il se peut qu'une éventualité arrive pour qu'un copain (pas moi ;) ) doive migrer toute ou partie de ses services chez AWS. déjà niveau réseau, comment cela s'organise ? Actuellement, nous avons 2 DC avec du L2 et avons créé notre propre L3 avec routage OSPF, BGP pour les interco client, QOS entre les 2 DC, etc ... Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2 par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un partenaire à eux (j'ai peur de votre réponse ...) ? Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à nos VM ? A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il pouvoir router soi-même ... ? Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS. Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien ? Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Hello réponse inline de ce que j'en connais. On 23/11/2020 15:38, Mickael Hubert wrote: Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2 par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un partenaire à eux (j'ai peur de votre réponse ...) ? Nope. No way. Déjà chez en interne chez AWS il n'y a pas de L2 étendu entre AZ et encore moins entre région, alors avec l'extérieur. Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à nos VM ? Coté réseau et vpn oui tu peux/doit créer ton propre plan d'adressage avec toutes les IPs rfc1918 à disposition. Coté VPN tu peux même faire un peu de BGP pour échanger tes routes. A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il pouvoir router soi-même ... ? Auparavant ce n'était pas possible du tout, tu étais obligé d'utiliser les boites noires AWS, aws-gateway ou aws-nat-gateway. Depuis la situation a évolué pour permettre d'utiliser tes propres gateway sur une instance ec2 (principalement pour autoriser la vente d'appliance sur la market place je dirais). Une nouvelle feature vient même de sortir permettant de redonder/load balancé ces gw : https://aws.amazon.com/fr/elasticloadbalancing/gateway-load-balancer/ En revanche pose toi bien la question de pourquoi tu voudrais faire ça. Généralement la seule bonne raison valable serait de faire de l'inspection de trafic centrale ou de mettre un firewall centralisé (ce qui est à l'opposé du modèle de sécurité AWS) Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS. Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien ? Tu peux tout à fait associer une IP publique à une instance. Deux mode soit tu laisses AWS choisir, le mode par défaut, mais dans ce cas il s'agit d'une IP aléatoire à chaque ré-initialisation de l'instance, soit tu attaches une Elastic IP à une instance qui ne changera jamais. Pas besoin de NAT in sur AWS généralement. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Le 23/11/2020 à 16:17, Sébastien Lesimple a écrit : Je faire mon chauvin, achetes français au lieux de refiler des ressources aux rican d'AWS! Outscale a la même API qu'AWS, la gestion reseau est mieux foutue qu'AWS. Tu peux jouer avec tes VM comme tu veux, idem avec tes subnets et passer de l'IPv6 en utilisant un routeur virtuel. Direct link ce possible mais ca pique les yeux coté coûts. VoIP marche, j'ai fais un démonstrateur il y a 2 ans. https://youtu.be/10qjZW-zwk0 Bref, regardez les alternatives IaaS françaises avec présence int'l pour une fois. Seb. Hello, As-tu pu mettre en oeuvre du WAF et/ou des appliances firewall solides chez Outscale ? Parce que là on est en train de l'exclure d'une solution à cause de ce genre de soucis (perso pas d'expérience), du coup preneur de retours. Et si l'API est très semblable, je ne suis pas sur que l'on soit à une parité 1-1 des services offerts...enfin moi je dis ça Cordialement, JYL --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Retour d'expériences AWS
Je faire mon chauvin, achetes français au lieux de refiler des ressources aux rican d'AWS! Outscale a la même API qu'AWS, la gestion reseau est mieux foutue qu'AWS. Tu peux jouer avec tes VM comme tu veux, idem avec tes subnets et passer de l'IPv6 en utilisant un routeur virtuel. Direct link ce possible mais ca pique les yeux coté coûts. VoIP marche, j'ai fais un démonstrateur il y a 2 ans. https://youtu.be/10qjZW-zwk0 Bref, regardez les alternatives IaaS françaises avec présence int'l pour une fois. Seb. Le 23/11/2020 à 15:38, Mickael Hubert a écrit : > Bonjour à tous, > j'aimerais vous demander un retour d'expérience de l'hébergeur AWS. Car il > se peut qu'une éventualité arrive pour qu'un copain (pas moi ;) ) doive > migrer toute ou partie de ses services chez AWS. > > déjà niveau réseau, comment cela s'organise ? Actuellement, nous avons 2 DC > avec du L2 et avons créé notre propre L3 avec routage OSPF, BGP pour les > interco client, QOS entre les 2 DC, etc ... > > Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2 > par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un > partenaire à eux (j'ai peur de votre réponse ...) ? > > Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap > IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits > avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à > nos VM ? > > A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il > pouvoir router soi-même ... ? > > Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS. > Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais > d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien ? > > Merci d'avance pour votre aide ! > > ++ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Retour d'expériences AWS
Bonjour à tous, j'aimerais vous demander un retour d'expérience de l'hébergeur AWS. Car il se peut qu'une éventualité arrive pour qu'un copain (pas moi ;) ) doive migrer toute ou partie de ses services chez AWS. déjà niveau réseau, comment cela s'organise ? Actuellement, nous avons 2 DC avec du L2 et avons créé notre propre L3 avec routage OSPF, BGP pour les interco client, QOS entre les 2 DC, etc ... Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2 par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un partenaire à eux (j'ai peur de votre réponse ...) ? Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à nos VM ? A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il pouvoir router soi-même ... ? Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS. Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien ? Merci d'avance pour votre aide ! ++ --- Liste de diffusion du FRnOG http://www.frnog.org/
