Utiliser la Wavelength Zone de Casablanca

Vos utilisateurs sont principalement basés au Maroc ou en Afrique du Nord ? Vos applications nécessitent une très faible latence ou doivent respecter des contraintes de résidence des données ? auparavant, il fallait choisir entre déployer ses applications dans une région AWS proche telque Madrid ou Paris ou investir dans un Datacenter local.

Avec la disponibilité générale de la AWS Wavelength Zone de Casablanca, en partenariat avec Orange Maroc, il est désormais possible de déployer des ressources AWS directement au plus près des utilisateurs marocains, tout en continuant à bénéficier des services, des API et des outils de la plateforme AWS.

Dans cet article, nous allons découvrir le fonctionnement des Wavelength Zones, les différences avec les Availability Zones et les Local Zones, puis ultérieurement, on va déployer notre première instance Amazon EC2 dans la Wavelength Zone de Casablanca.

Qu'est-ce qu'une AWS Wavelength Zone ?

Normalement, une région est composée d'au moins 3 zones de disponibilité, chacune correspondant à un ou plusieurs data centers.

AWS Wavelength est une extension d'une région AWS déployée directement dans le réseau d'un opérateur télécom, tel que Orange ou Vodafone.

Le data center de la zone de disponibilité est géré par AWS, alors que celui de la Wavelength Zone est géré par un opérateur. Donc les machines créées dans une Wavelength Zone sont démarrées dans le data center de l'opérateur et ne quittent jamais ce data center.

La Wavelength Zone de Casablanca

La première Wavelength Zone d'Afrique du Nord est hébergée à Casablanca en partenariat avec Orange Maroc.

Elle est rattachée à la région Europe (Paris) :

• Région parente : eu-west-3

• Wavelength Zone : eu-west-3-cmn-wlz-1a

L'ensemble des ressources créées dans cette zone est donc administré depuis la région Paris.

Services disponibles

Toutes les ressources AWS ne sont pas disponibles dans une Wavelength Zone.

Les principaux services disponibles sont :

• Amazon EC2 (certains types d'instances uniquement)

• Amazon EBS

• Amazon VPC

• Carrier Gateway

• Amazon ECS

• Amazon EKS

• EC2 Auto Scaling

• Elastic Load Balancer

La disponibilité exacte des services peut évoluer selon les Wavelength Zones.

Activer la Wavelength Zone

Les Wavelength Zones doivent être activées (Opt-in) avant de pouvoir être utilisées. Pour se faire:

Depuis la console AWS

Allez dansla console Amazon EC2, Sélectionnez la région (Paris), cliquez sur le menu Dashboard, puis Cliquez sur Zones dans la section sur Account attributes .

Dans l'onglet Wavelength Zones, cherchez eu-west-3-cmn-wlz-1a et activez la en cliquant sur Opt-in

Depuis AWS CLI

aws ec2 modify-availability-zone-group --region eu-west-3 --group-name eu-west-3-cmn-wlz-1 --opt-in-status opted-in

Vérification :

aws ec2 describe-availability-zones --region eu-west-3 --all-availability-zones --filters Name=zone-type,Values=wavelength-zone

La sortie doit afficher la zone eu-west-3-cmn-wlz-1a avec le statut Opted-in

Conclusion

Avec la disponibilité de la Wavelength Zone de Casablanca, les entreprises marocaines et nord-africaines peuvent désormais déployer des charges de travail critiques à très faible latence, tout en conservant les mêmes outils, les mêmes API et les mêmes pratiques opérationnelles qu'au sein d'une région AWS classique.

Dans le prochain article, nous verrons comment créer l'ensemble de l'architecture réseau nécessaire (VPC, sous-réseau Wavelength, Carrier Gateway et tables de routage) avant de déployer une application complète dans la Wavelength Zone de Casablanca.

Read More

Amazon ECS : de la théorie au déploiement d'un service

Amazon Elastic Container Service (ECS) est un service d'orchestration de conteneurs entièrement géré par AWS. Il permet de déployer, faire évoluer et gérer des applications conteneurisées sans avoir à installer ni administrer soi-même un orchestrateur.

ECR (vu dans les articles précédents) se contente de stocker les images Docker, ECS s'occupe de les exécuter : il décide sur quelle machine lancer un conteneur, combien d'instances faire tourner, comment les remplacer en cas de panne, et comment les exposer au trafic réseau.

ECS peut être vu comme une alternative plus simple et plus intégrée à AWS que Kubernetes (ou son équivalent managé, EKS) : moins de concepts à apprendre, une intégration native avec IAM, VPC, CloudWatch et les load balancers AWS, au prix d'une portabilité moindre en dehors d'AWS.

Les deux modes de calcul : EC2 et Fargate

ECS ne fournit pas lui-même la puissance de calcul : il orchestre des conteneurs sur une infrastructure sous-jacente, qui peut être de deux natures.

Mode EC2

Les conteneurs s'exécutent sur des instances EC2 que vous provisionnez et gérez vous-même. Ces instance font tourner un agent ECS qui communique avec le control plane ECS pour recevoir et exécuter des tâches. Ce mode offre plus de contrôle (choix du type d'instance, accès SSH, optimisation fine des coûts avec des réservations ou du spot) mais implique aussi de gérer le patching, le scaling et le dimensionnement du cluster.

Mode Fargate

Fargate est un mode d'exécution serverless : AWS provisionne et gère automatiquement l'infrastructure nécessaire pour exécuter les conteneurs. Il n'y a plus d'instances EC2 à gérer, plus de capacité à dimensionner à l'avance. La facturation se fait à la ressource réellement consommée (vCPU/mémoire) pendant la durée d'exécution des contenaires.

Les composants clés d'ECS

Les principaux composants d'ECS

• Cluster : espace logique qui regroupe les ressources sur lesquelles les conteneurs seront exécutés.
• Task Definition : modèle décrivant l'application à exécuter (image Docker, CPU, mémoire, ports, variables d'environnement, etc.).
• Task : instance en cours d'exécution d'une Task Definition.
• Service : maintient un nombre défini de tâches en fonctionnement et permet leur intégration avec un Load Balancer ainsi que la mise à l'échelle.

Dans cet article, nous créerons un cluster ECS utilisant AWS Fargate, puis nous déploierons l'image Docker publiée précédemment dans Amazon ECR afin de rendre notre application accessible via un Application Load Balancer (ALB).

Déploiement

Cluster

On commence par la création d'un Cluster.

Dans le service Elastic Container Service, cliquez sur Clusters, puis sur Create cluster.

Donnez un nom à votre cluster, par exemple demo-cluster.
Dans la section Infrastructure, sélectionnez le type de capacité souhaité. ici je selectionne Fargate and self-managed instances qui permet d'utiliser Farget et aussi avoir des instances EC2 que je gère moi-même.

Enfin Cliquez sur Create.

Task Definition

Une fois le cluster créé, on définit la Task Definition qui décrit comment exécuter notre conteneur demo-app (l'image poussée sur ECR dans l'article précedent).

Dans le menu de gauche, cliquez sur Task definitions, puis sur Create new task definition.

Donnez un nom, par exemple demo-app-task, choisissez le type de lancement : AWS Fargate.
Configurez la taille de la Task :

• CPU : par exemple 0.5 vCPU.
• Mémoire : par exemple 1 GB.

Dans la section Container details, ajoutez un conteneur :

• Name : demo-app.
• Image URI : <account_id>.dkr.ecr.eu-west-3.amazonaws.com/demo-app:latest.
• Container port : le port exposé par l'application, par exemple 80.

Cliquez sur Create.

Service:

Maintenant on lance des containers.

Depuis la page du cluster demo-cluster, allez dans l'onglet Services, puis cliquez sur Create.

Selectionnez la task definition

Dans deployment configuration, on specifier le nombre de contenairs à créer

Dans Networking, choisissez le VPC et les subnets, et un security group autorisant le trafic sur le port du conteneur (80).

Dans Load balancing, vous pouvez associer un Application Load Balancer existant (ou en créer un) pour répartir le trafic entre les load balancers. 

enfin cliquez sur Create.

Vous trouverez un Load balancer en cours de création

C'est en utilisant le DNS du load balancer qu on peu acceder à l'appli qui toune dans des containers

Et voila tout est ok

Read More

Amazon ECR : stocker et gérer vos images Docker sur AWS

Vous êtes sur AWS et vous cherchez où stocker vos images Docker ? Amazon Elastic Container Registry (ECR) est la réponse native d'AWS à ce besoin : un registre d'images de conteneurs entièrement géré, qui permet de stocker, gérer et déployer des images Docker (ou tout autre format compatible OCI)

Concrètement, ECR joue le même rôle que Docker Hub, mais avec une intégration native aux autres services AWS : IAM pour les permissions, ECS et EKS pour le déploiement, ou encore CloudTrail pour l'audit.

ECR propose deux types de repositories :

Type	Usage
Privé	Accessible uniquement par les principals IAM autorisés de votre compte (ou de comptes tiers explicitement autorisés)
Public	Accessible publiquement en lecture

Dans cette démo, nous allons nous concentrer sur un repository privé, cas d'usage le plus courant en entreprise.

Création d'un repository ECR

Via la console

Depuis la console AWS, ouvrez le service Amazon Elastic Container Registry (ECR). Dans le menu de gauche, sous la section Private registry, cliquez sur Repositories, puis sur Create repository.

Donnez un nom à votre repository, par exemple demo-app.
Laissez les autres paramètres par défaut et cliquez sur Create.

Une fois créé, le repository apparaît dans la liste avec son URI:

Création Via la CLI

La même opération peut être réalisée avec l'AWS CLI :

aws ecr create-repository \
  --repository-name demo-app \
  --region eu-west-3

Push des images

Avant de pousser une image, Docker doit s'authentifier auprès du registre ECR.

Authentification (console → récupération de la commande)

Depuis la console ECR, sélectionnez votre repository demo-app.
Cliquez sur View push commands en haut à droite.

Une fenêtre s'ouvre et affiche les commandes nécessaires pour authentifier Docker, taguer l'image et la pousser vers le registre.

La premiere commande permet d'authentifier Docker auprès d'ECR. cela génère un jeton d'authentification temporaire. Une fois l'authentification réussie, Docker est autorisé à interagir avec le registre ECR, notamment pour pusher ou puller des images Docker.

La dernière commande push l'image dans le registry

Une fois le docker push terminé, l'image apparaît dans le repository ECR. Elle est désormais disponible et peut être utilisée par des services AWS tels qu'Amazon ECS ou Amazon EKS pour déployer des conteneurs.

Conclusion

À ce stade, notre image Docker est stockée dans Amazon ECR et prête à être utilisée. Dans le prochain article, nous verrons comment déployer cette image sur Amazon Elastic Container Service (ECS) afin d'exécuter notre application dans des conteneurs, la rendre accessible via un Application Load Balancer et bénéficier des fonctionnalités de haute disponibilité et de montée en charge offertes par ECS.

Read More

AWS VPN Site to Site - Création via Terraform

Dans cet article, nous allons déployer un VPN Site-to-Site, en utilisant Terraform, afin de connecter un réseau on-premise à un VPC via une Virtual Private Gateway 

variables.tf

On commence par déclarer les variables pour rendre le code réutilisable :

variable "aws_region" {
  description = "Région AWS"
  type        = string
  default     = "eu-west-1"
}

variable "vpc_id" {
  description = "ID du VPC cible"
  type        = string
}

variable "onprem_ip" {
  description = "Adresse IP publique de l'équipement on-premise"
  type        = string
}

variable "onprem_cidr" {
  description = "CIDR du réseau on-premise"
  type        = string
  default     = "192.168.0.0/24"
}

variable "bgp_asn" {
  description = "ASN BGP du Customer Gateway"
  type        = number
  default     = 65000
}

terraform.tfvars

aws_region  = "eu-west-1"
vpc_id      = "vpc-0abc12345def67890"
onprem_ip   = "203.0.113.10"
onprem_cidr = "192.168.0.0/24"
bgp_asn     = 65000

main.tf

Dans le fichier main.tf, ou mettre les VPNs dans un autre fichier par exemple vpn.tf

#Provider AWS
terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
}

#Customer Gateway (CGW)
#Customer Gateway (CGW)
resource "aws_customer_gateway" "cgw" {
  bgp_asn    = var.bgp_asn
  ip_address = var.onprem_ip
  type       = "ipsec.1"

  tags = {
    Name = "cgw-onprem"
  }
}

#Virtual Private Gateway (VGW)
resource "aws_vpn_gateway" "vgw" {
  vpc_id = var.vpc_id

  tags = {
    Name = "vgw-production"
  }
}

#Connexion VPN
resource "aws_vpn_connection" "vpn" {
  vpn_gateway_id      = aws_vpn_gateway.vgw.id
  customer_gateway_id = aws_customer_gateway.cgw.id
  type                = "ipsec.1"
  static_routes_only  = true

  tags = {
    Name = "vpn-onprem-to-aws"
  }
}

#Route statique vers le réseau on-premise
resource "aws_vpn_connection_route" "onprem_route" {
  vpn_connection_id      = aws_vpn_connection.vpn.id
  destination_cidr_block = var.onprem_cidr
}

Déploiement

$ terraform init
$ terraform plan
$ terraform apply

Résultat de la commande apply passe avec succès

Vérification depuis la console

On trouve bien la connexion VPN

Avec les deux Tunnels, et du coup les deux IPs à fournir à l'admin réseau on prem

Read More

AWS VPN Site to Site - Création via console

Dans le précédent article nous avons présenté le VPN Site-to-Site managé par AWS : son fonctionnement, ses composants clés (Customer Gateway, Virtual Private Gateway) et les deux architectures possibles — connexion directe à un VPC via une Virtual Private Gateway, ou connexion centralisée multi-VPC via un Transit Gateway.

Dans cet article, nous passons à la pratique. Nous allons créer pas à pas un VPN Site-to-Site depuis la console AWS, en suivant l'architecture la plus courante : un réseau on-premise connecté à un seul VPC via une Virtual Private Gateway.

Prérequis

Avant de commencer, assurez-vous d'avoir :

• Un VPC existant sur AWS
• L'adresse IP publique de votre équipement on-premise (routeur, firewall, appliance VPN)
• Le CIDR de votre réseau on-premise (ex. 192.168.0.0/24)

Étape 1 : Créer le Customer Gateway (CGW)

Le Customer Gateway représente votre équipement côté on-premise.

Depuis la console AWS → VPC → Customer Gateways → Create customer gateway :

On spécifie un nom et l'adresse IP publique de l'équipement on-prem

Étape 2 : Créer le Virtual Private Gateway (VGW)

Le Virtual Private Gateway est le point de terminaison VPN côté AWS.

Depuis VPC → Virtual Private Gateways → Create virtual private gateway

    

Il suffit de donner un nom signifactif et cliquer sur Create

Une fois créé, attachez le VGW à votre VPC : sélectionnez-le → Actions → Attach to VPC.

Et on choisit le VPC

Étape 3 : Créer la connexion VPN

Depuis VPC → Site-to-Site VPN Connections → Create VPN connection :

Donnez un nom, selectionnez la Virtual private Gateway et la Customer Private Gateway puis cliquez sur Create

La connexion passe en statut Pending pendant quelques minutes, puis Available.

AWS provisionne automatiquement deux tunnels IPsec, chacun avec une adresse IP publique distincte. Vous pouvez les consulter dans l'onglet Tunnel Details de la connexion.

Ces deux IPs sont les points de terminaison du CPN côté AWS. Il faut les communiquer à l'administrateur réseau on-premise, ainsi que les clés pré-partagées (PSK) correspondantes, pour qu'il puisse configurer l'équipement de son côté. 

Les PSK on peut les récupérer depuis onglet Tunnel Details → cliquez sur Edit tunnel options d'un tunnel → le champ Pre-Shared Key affiche la clé de ce tunnel.

tunnel → le champ Pre-Shared Key affiche la clé de ce tunnel.

Une fois cette configuration appliquée, les tunnels passent au statut UP.

Étape 4 : Vérification

Depuis l'onglet Tunnel Details de votre connexion VPN, les deux tunnels doivent afficher le statut UP.

Étape 5 : Configurer le routage dans le VPC

Pour que vos instances EC2 puissent atteindre le réseau on-premise, il faut propager les routes dans la table de routage du VPC.

Option A — Propagation automatique (BGP) : Depuis VPC → Route Tables → sélectionnez la table de routage de votre sous-réseau → onglet Route Propagation → Edit route propagation → activez le VGW.

Option B — Route statique : Dans l'onglet Routes → Edit routes → Add route :

• Destination : 192.168.0.0/24 (CIDR on-premise)
• Target : votre VGW

Read More