Praxislabor — SAA-C03 AWS Certified Solutions Architect Associate

Übersicht

Voraussetzungen

Schritte

1. 1.Unsere Terraform-Version und AWS-Region auswählen

   Wir verwenden den AWS-Provider ~> 5.60 und wählen us-east-1 (jede Region mit mindestens zwei AZs funktioniert). Der data-Block ruft die Liste der verfügbaren AZs zur Planungszeit ab – das Festkodieren von AZ-Namen wie us-east-1a ist ein SAA-C03-Anti-Muster, da die Zuordnung von AZ-Namen zu physischen Zonen kontospezifisch ist (Ihre us-east-1a kann eine andere physische AZ sein als meine).

   Alle Ressourcen, die wir nachfolgend erstellen, werden über default_tags einem einzigen Projektnamen zugeordnet – Cost Explorer und AWS Config-Regeln funktionieren beide mit Tags, und die Prüfung erwartet von Ihnen, alles zu taggen.

   Kopieren

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       aws = {
         source  = "hashicorp/aws"
         version = "~> 5.60"
       }
     }
   }
   
   provider "aws" {
     region = "us-east-1"
   
     default_tags {
       tags = {
         Project   = "certlabpro-saa-c03"
         ManagedBy = "terraform"
       }
     }
   }
   
   data "aws_availability_zones" "available" {
     state = "available"
   }

2. 2.Eine Multi-AZ-VPC mit öffentlichen und privaten Subnetzen erstellen

   Ressourcen:

   • Amazon VPC

   Jede SAA-C03-Hochverfügbarkeitsfrage geht davon aus, dass Sie die Arbeitslast auf mindestens zwei Availability Zones verteilen. Wir erstellen eine /16 VPC und schneiden vier /20 Subnetze aus – zwei öffentliche (für den ALB), zwei private (für die EC2-Instanzen und RDS). Das Internet-Gateway wird an die VPC angehängt; die öffentliche Routing-Tabelle leitet 0.0.0.0/0 darüber.

   Die privaten Subnetze haben in diesem Lab absichtlich KEIN NAT-Gateway – NAT-GWs kosten im Leerlauf ca. 32 $/Monat (pro AZ) und SAA-C03 testet diesen Kompromiss explizit in Kostenfragen. Wenn Ihre Anwendung in der Produktion ausgehenden Internetzugang von privaten Subnetzen benötigen würde, würden Sie ein NAT (oder eine NAT-Instanz, die günstigere SAA-C03-Alternative) hinzufügen.

   Die VPC + Subnetze + IGW + Routing-Tabelle aus diesem Schritt bilden die Grundlage für alles Folgende – der ALB wird in die öffentlichen Subnetze integriert, die ASG-Instanzen befinden sich in den privaten und die RDS-Subnetzgruppe in Schritt 5 erstreckt sich über beide privaten AZs.

   Kopieren

   resource "aws_vpc" "main" {
     cidr_block           = "10.0.0.0/16"
     enable_dns_hostnames = true
   
     tags = { Name = "certlabpro-saa-c03-vpc" }
   }
   
   resource "aws_subnet" "public" {
     count                   = 2
     vpc_id                  = aws_vpc.main.id
     cidr_block              = "10.0.${count.index}.0/24"
     availability_zone       = data.aws_availability_zones.available.names[count.index]
     map_public_ip_on_launch = true
   
     tags = { Name = "certlabpro-saa-c03-public-${count.index}" }
   }
   
   resource "aws_subnet" "private" {
     count             = 2
     vpc_id            = aws_vpc.main.id
     cidr_block        = "10.0.${count.index + 10}.0/24"
     availability_zone = data.aws_availability_zones.available.names[count.index]
   
     tags = { Name = "certlabpro-saa-c03-private-${count.index}" }
   }
   
   resource "aws_internet_gateway" "main" {
     vpc_id = aws_vpc.main.id
   }
   
   resource "aws_route_table" "public" {
     vpc_id = aws_vpc.main.id
   
     route {
       cidr_block = "0.0.0.0/0"
       gateway_id = aws_internet_gateway.main.id
     }
   }
   
   resource "aws_route_table_association" "public" {
     count          = 2
     subnet_id      = aws_subnet.public[count.index].id
     route_table_id = aws_route_table.public.id
   }

3. 3.Den Stack mit einem internetseitigen ALB über beide AZs absichern

   Ressourcen:

   • Elastic Load Balancing

   Ein Application Load Balancer ist der Load Balancer, den SAA-C03 von Ihnen erwartet, wenn die Frage „HTTP / HTTPS“ oder „pfadbasiertes Routing“ oder „einen bestimmten Dienst ansprechen“ besagt. Network Load Balancer handhaben TCP/UDP und extrem niedrige Latenz; Classic ist veraltet. Es ist also ein ALB.

   Der ALB befindet sich in den beiden öffentlichen Subnetzen aus Schritt 2 – das bedeutet strukturell „Multi-AZ“. Seine Sicherheitsgruppe akzeptiert HTTP (Port 80) von überall; die Zielgruppe erhält ihre Mitglieder von der ASG, die wir in Schritt 4 erstellen. Der Health Check ist der Vertrag zwischen dem ALB und dem Ziel – wenn / keinen 200er-Code zurückgibt, sendet der ALB keinen Traffic mehr an diese Instanz.

   Kein HTTPS in diesem Lab – dafür wären ein ACM-Zertifikat und ein DNS-Name erforderlich, was zwei weitere Dienste sind, die wir nicht benötigen, um das HA-Muster sichtbar zu machen. Fügen Sie ACM in der Produktion hinzu.

   Kopieren

   resource "aws_security_group" "alb" {
     name        = "certlabpro-saa-c03-alb"
     description = "ALB ingress on port 80 from the internet"
     vpc_id      = aws_vpc.main.id
   
     ingress {
       from_port   = 80
       to_port     = 80
       protocol    = "tcp"
       cidr_blocks = ["0.0.0.0/0"]
     }
   
     egress {
       from_port   = 0
       to_port     = 0
       protocol    = "-1"
       cidr_blocks = ["0.0.0.0/0"]
     }
   }
   
   resource "aws_lb" "web" {
     name               = "certlabpro-saa-c03-alb"
     load_balancer_type = "application"
     internal           = false
     subnets            = aws_subnet.public[*].id
     security_groups    = [aws_security_group.alb.id]
   }
   
   resource "aws_lb_target_group" "web" {
     name        = "certlabpro-saa-c03-tg"
     port        = 80
     protocol    = "HTTP"
     target_type = "instance"
     vpc_id      = aws_vpc.main.id
   
     health_check {
       path                = "/"
       matcher             = "200-299"
       interval            = 30
       timeout             = 5
       healthy_threshold   = 2
       unhealthy_threshold = 3
     }
   }
   
   resource "aws_lb_listener" "http" {
     load_balancer_arn = aws_lb.web.arn
     port              = 80
     protocol          = "HTTP"
   
     default_action {
       type             = "forward"
       target_group_arn = aws_lb_target_group.web.arn
     }
   }

4. 4.Eine Auto Scaling Group in den privaten Subnetzen hinter dem ALB hinzufügen

   Ressourcen:

   • Amazon EC2 Auto Scaling

   Auto Scaling ist die „Elastizitäts“-Säule von AWS Well-Architected und nach Multi-AZ das zweithäufigste Thema in SAA-C03. In Kombination mit dem ALB aus Schritt 3 bietet eine ASG sowohl Fehlertoleranz (Instanzen werden bei Ausfall ersetzt) als auch Skalierbarkeit (Instanzanzahl folgt der Nachfrage) – die beiden Ergebnisse, nach denen SAA-C03 immer wieder fragt.

   Das Start-Template definiert, wie jede neue Instanz aussieht. Wir verwenden das neueste Amazon Linux 2023 AMI, eine t3.micro, die der SG aus Schritt 2 entsprechende Sicherheitsgruppe, die Traffic nur von der ALB-SG akzeptiert (geringstes Privileg auf der Netzwerkschicht), und minimale Benutzerdaten, die Nginx starten, damit der Health Check erfolgreich ist.

   Die ASG verbindet drei Dinge: wo Instanzen laufen (vpc_zone_identifier = unsere privaten Subnetze, beide AZs), wie viele existieren sollen (min_size = 2, max_size = 4 – zwei für HA, Spielraum für Skalierung) und wie neue Instanzen dem Load Balancer beitreten (target_group_arns). Wenn die ASG eine Instanz startet, wird diese automatisch bei der Zielgruppe aus Schritt 3 registriert.

   Kopieren

   resource "aws_security_group" "app" {
     name        = "certlabpro-saa-c03-app"
     description = "App instances accept traffic only from the ALB SG"
     vpc_id      = aws_vpc.main.id
   
     ingress {
       from_port       = 80
       to_port         = 80
       protocol        = "tcp"
       security_groups = [aws_security_group.alb.id]
     }
   
     egress {
       from_port   = 0
       to_port     = 0
       protocol    = "-1"
       cidr_blocks = ["0.0.0.0/0"]
     }
   }
   
   data "aws_ami" "al2023" {
     most_recent = true
     owners      = ["amazon"]
   
     filter {
       name   = "name"
       values = ["al2023-ami-*-kernel-6.1-x86_64"]
     }
   }
   
   resource "aws_launch_template" "app" {
     name_prefix   = "certlabpro-saa-c03-app-"
     image_id      = data.aws_ami.al2023.id
     instance_type = "t3.micro"
   
     vpc_security_group_ids = [aws_security_group.app.id]
   
     metadata_options {
       http_tokens = "required"
     }
   
     user_data = base64encode(<<-EOT
       #!/bin/bash
       dnf install -y nginx
       systemctl enable --now nginx
     EOT
     )
   }
   
   resource "aws_autoscaling_group" "app" {
     name                = "certlabpro-saa-c03-app-asg"
     vpc_zone_identifier = aws_subnet.private[*].id
     target_group_arns   = [aws_lb_target_group.web.arn]
     health_check_type   = "ELB"
     min_size            = 2
     max_size            = 4
     desired_capacity    = 2
   
     launch_template {
       id      = aws_launch_template.app.id
       version = "$Latest"
     }
   }

5. 5.Eine Multi-AZ-RDS-Datenbank hinzufügen, mit der die App kommunizieren kann

   Ressourcen:

   • Amazon RDS

   Das Glanzstück jeder SAA-C03 Multi-AZ-Architektur ist eine Multi-AZ-RDS-Datenbank. Die Einstellung multi_az = true ist eines der am häufigsten getesteten Attribute der gesamten Prüfung: Sie weist RDS an, eine synchrone Standby-Replika in einer zweiten AZ bereitzustellen. Wenn das primäre System ausfällt, befördert RDS automatisch das Standby-System – ein typisches Failover dauert ~60 Sekunden ohne Datenverlust. Zwei Single-AZ-Datenbanken würden Ihnen das NICHT bieten; manuelle Replikation bietet Ihnen das NICHT. Multi-AZ ist die Antwort auf jede Frage nach „Failover unter einer Minute, kein Datenverlust“.

   Die DB-Subnetzgruppe benötigt Subnetze in mindestens zwei AZs – wir speisen sie mit den privaten Subnetzen aus Schritt 2. Die Sicherheitsgruppe akzeptiert den Datenbankport (5432 für PostgreSQL) nur von der App-SG, was dem mehrschichtigen Sicherheitspattern aus Schritt 4 entspricht.

   Mit diesem letzten Baustein ist der Stack komplett: Traffic gelangt in den ALB in einer der öffentlichen AZs, verteilt sich auf die ASG-Instanzen in einer der privaten AZs, und diese Instanzen kommunizieren mit dem RDS-Primärsystem (das ein Hot-Standby in der anderen AZ bereithält). Alles außer einem vollständigen Regionsausfall hat einen Wiederherstellungspfad.

   Kopieren

   resource "aws_db_subnet_group" "main" {
     name       = "certlabpro-saa-c03"
     subnet_ids = aws_subnet.private[*].id
   }
   
   resource "aws_security_group" "db" {
     name        = "certlabpro-saa-c03-db"
     description = "DB accepts traffic only from the app SG"
     vpc_id      = aws_vpc.main.id
   
     ingress {
       from_port       = 5432
       to_port         = 5432
       protocol        = "tcp"
       security_groups = [aws_security_group.app.id]
     }
   }
   
   resource "aws_db_instance" "main" {
     identifier             = "certlabpro-saa-c03"
     engine                 = "postgres"
     engine_version         = "16"
     instance_class         = "db.t3.micro"
     allocated_storage      = 20
     storage_encrypted      = true
     multi_az               = true # the SAA-C03 headline
     db_subnet_group_name   = aws_db_subnet_group.main.name
     vpc_security_group_ids = [aws_security_group.db.id]
   
     username = "appuser"
     password = "ChangeMe-Not-For-Prod-1234" # use Secrets Manager in production
   
     skip_final_snapshot = true # lab-only setting; never use on prod
     apply_immediately   = true
   }

Bereinigung