Skip to content

aws_sysops_cert_notes

Jump to bottom
Your Name edited this page Nov 22, 2020 · 1 revision

CCP

SysOps Associate

Diagram dostępny bez logowania: https://interactive.linuxacademy.com/diagrams/AWSSysOpsAdminFullDiagram.html

Spis treści

  1. Storage and Data Management
  • S3
  • S3 Lifecycle policies
  • S3 MFA Delete
  • S3 Encryption
  • EC2 Volume types
  • Encryption & Downtime
  • KMS & Cloud HSM
  • AMIs
  • sharing AMIs
  • Snowball & Snowball Edge
  • Storage Gateway
  • Athena
  • EFS
  1. Security

CloudWatch

  • domyślna rozdzielczość: 5 minut
  • minimalna rozdzielczość: 1 minuta
  • domyślne metryki dla EC2: CPU, sieć, dysk (wydajność, nie zajętość), host status
  • dashboardy sa globalne, ale dodawać można tylko wykresy z aktualnego regionu

Organizations

  • organizacja może być typu pełnego (kontrola nad potomkami) lub tylko consolidated billing
  • root account, hierarchia OU (Org Units), inne konta podpięte pod OU
  • można przypinać policy do OU i do kont-liści
  • consolidated billing: wspólny rachunek za wiele kont, umożliwia korzystanie z rabatów za duże zużycie

EC2

  • pricing options: on-demand, reserved, spot, dedicated host
  • placement groups:
    • cluster - wszystkie w jednej AZ
    • spread - każda w osobnym racku, maksymalizacja izolacji (sieć, zasilanie), może być multi AZ (#instancji == #racków <= #AZ). Maks. # instancji w jednej AZ: 7
    • partition - po kilka w jednym racku, może być multi AZ
  • volume types: EBS i instance store
    • jesli instancja ma instance store root device: nie można jej zastopować (od razu znika) i nie można zmienić jej ustawień CPU/ram (bo nie można jesj zastopować do zmiany)
  • AMI: przechowywane per-region
  • security grupy są stanowe

EBS

  • gp2 i io1 storage types
  • IOPS per GB oraz burst
  • snapshoty są przechowywane na S3 (ale nie można ich zobaczyć)
  • volume i instancja są i muszą być w tej samej AZ
  • przenoszenie dysków EBS do innej AZ: zrób snapshot i utwórz volume ze snapshota. Przy tworzeniu volume będzie możliwość wybrania innej AZ
  • przenoszenie dysków EBS do innego regionu: zrób snapshot, wybierz "Copy", wybierz inny region, a następnie utwórz w nowym regionie volume ze snapshota

S3

  • maks. rozmiar pliku: 5TB
  • domyślnie dostęp publiczny jest zablokowany
  • consistency: pierwszy PUT jest consistent, potem dalsze PUTy i DELETEy są eventually consistent
  • storage tiers:
    • regular S3
    • Infrequently Accessed (IA)
    • single AZ IA
    • reduced redundancy (deprecated)
    • glacier (3-5 godz. do odczytu)
    • intelligent tiering (frequently accessed and infrequently accessed)
  • lifecycle policies: automatyczne przenoszenie obiektów do innej klasy storage albo usuwanie na podstawie daty stworzenia (nie ostatniego dostępu)
  • MFA delete - uniemożliwia kasowanie lub wyłączenie wersjonowania bez MFA

ELB

  • pre-warming via support - ensures faster scaling under load
  • ALB może zmieniać adres IP w wyniku skalowania
  • NLB alokuje jeden adres IP per subnet i nie zmienia go
  • można postawić ALB za NLB, żeby zapewnić stałe adresy IP
  • CloudWatch
    • BackendConnectionErrors, (Un)HealthyHostCount, HTTPCodeBackend_{2,3,4,5}XX, Latency, RequestCount

RDS

  • skalowanie to zmiana rozmiaru instancji (downtime)
  • można zwiększać rozmiar mastera i dodawać read repliki
  • Aurora:
    • trzyma sześć kopii danych (2 kopie per AZ)
    • Aurora serverless ma autoskalowanie (automatyczna zmiana rozmiaru instancji master bez downtime'u), w tym skalowanie do zera przy braku użycia
    • Aurora Global ma instancje secondary w innych regionach (r/o, mogą być promowane do r/w w ramach failover w ciągu ok. minuty). Używa fizycznej replikacji na poziomie wolumenów, ma gwarantowany niski replication lag <1s
    • Aurora Cross-region read replicas używają logicznej replikacji, mogą mieć replication lag w zalezności od obciążenia mastera
  • RDS ma automatyczny failover w wypadku awarii AZ, awarii instancji albo prac planowych w AWS
    • AWS aktualizuje wpis DNS dla bazy
    • wszystkie zapisy są replikowane do instancji standby (secondary)
    • downtime wynosi kilkadziesiąt sekund
    • backupy są robione z secondary, żeby nie obciążać mastera
    • można zrobić ręczny failover restartując instancję
  • read replicas:
    • żeby stworzyć RR trzeba włączyć automatyczne backupy
    • maks 5 sztuk
    • mogą być w innych regionach niż master
    • mogą być multi-AZ (replika primary i secondary, z failover)
    • utworzenie repliki wiąże się ze stworzeniem snapshota (obciąża mastera, jeśli nie ma włączonego trybu multiAZ)
    • read replica ma osobny adres DNS
    • read replica ma replication lag
    • snapshoty i backupy nie moga być robione z RR
    • dla Aurory, MySQL i MariaDB można zrobić read replikę z read repliki (second tier replica), wtedy replication latency będzie jeszcze większe
  • szyfrowanie:
    • można włączyć domyślnie szyfrowanie
    • niezaszyfrowaną bazę można zaszyfrowac poprzez:
      1. utworzenie snapshota
      2. skopiowanie snapshota i zaznaczenie opcji "zaszyfruj"
      3. odtworzenie bazy ze snapshota
    • t2.micro nie pozwala na szyfrowanie, trzeba wybrać większą instancję (czyli szyfrowanie nie jest możliwe we Free Tier)

Systems manager

  • run command
  • parameter store

CloudFormation

  • Resources to jedyna obowiązkowa sekcja w szablonie
  • CF domyślnie przy failu skasuje wszystkie utworzone obiekty, można to wyłączyć przełącznikiem --disable-rolback

ElasticBeanstalk

OpsWorks

  • Puppet albo Chef
  • wspiera onprem

VPC networking

  • public subnet: to taka, która ma w tablicy routingu ścieżkę do Internet Gateway
  • Internet Gateway robi 1:1 NAT dla Elastic IPs (dla połączeń w obie strony)
  • NAT Instance - instancja EC2, która robi NAT
  • NAT Gateway
  • Network ACL - domyślna w VPC to allow-all
    • bezstanowe
    • posortowana lista reguł, mogą być allow albo deny (pusta ACL jest deny-all)
    • decyduje pierwsza pasująca reguła, na końcu zawsze jest reguła-asterisk deny-all
    • każda podsieć musi być powiązana z ACLką (tylko jedną), jęsli tego nie zrobisz to dostanie defaultową

Route53

  • routing:
    • Simple
    • Weighted
    • Latency
    • Failover (healthchecki)
    • Geolocation
    • Multivalue answer (healthchecki)

KMS

  • klucze tworzone automatycznie przez AWS są darmowe (tzw. default service keys)
  • default keys nie mogą być udostępniane innym kontom AWS

Elasticache

  • memcached redis
  • multiAZ - redis wspiera, memcached nie
  • monitoring - istotne metryki: CPU, swap, evictions, # aktywnych połączeń

Storage gateway

  • file gateway: NFS/SMB
  • volume gateway:
    • cached volumes: dane w S3, ale cachowane lokalnie w SGW
    • gateway-stored volumes: dane lokalnie (na własnym storage), ale backupy robione jako snapshoty EBS na S3
    • Virtual Tape Library: wystawione po iSCSI, zapisuje do S3 i archiwizuje w Glacier

WAF

  • może chronić ALB, API Gateway albo CloudFront

AWS Inspector

  • skaner instancji - wymaga agenta
  • skaner sieci - bez agenta

Random

  • cost explorer
  • personal and service health dashboard
  • secrets manager vs parameter store
    • SM ma autogenerowanie haseł i wsparcie dla rotacji (wbudowane dla RDS, dla reszty trzeba pisać lambdę
    • SM jest płatny per secret i per request
    • w SM sekrety można udostępniać innym kontom
  • maintenance windows (AWS robi sam upgrade'y):
    • RDS
    • Elasticache
    • Redshift
    • DynamoDB DAX
    • Neptune
    • DocumentDB
  • szyfrowanie musi być ustawione przy tworzeniu, potem wymaga downtime/migracji dla:
    • EFS, RDS, EBS
  • szyfrowanie dla S3 (bucket/obiekty) może być włączone w dowolnym momencie bez downtime'u
  • service lmits - ograniczenia na liczbę zasobów, są osobno ustawione per region i Trusted Advisor może je sprawdzić
  • service catalog - repozytorium z gotowymi szablonami CloudFormation

DevOps Professional

Amazon Kinesis

  • Data Streams
  • KPL
  • KCL
  • Firehose
  • DynamoDB lease table

CloudWatch

  • custom metrics
    • retention period
    • time resolution
  • Amazon CloudWatch Event rule
  • CW Logs metrics filter

X-Ray

  • jak XRay zbiera dane, czy potrzeba demona/agenta?

Amazon States Language

CloudFormation

  • Stack Sets
  • DependsOn resource
  • cfn-init: skrypt do uruchamiania komend przy pierwszym boocie instancji

EC2

  • lifecycle hook to the Auto Scaling launch stage

OpsWorks

Security

groups - mają przypięte policy, do grup można przypinać użytkowników - w ten sposób można zarządzać politykami wielu użytkowników jednocześnie

Domyślna akcja IAM na wszystkich zasobach i wywołaniach API to Deny (implicit Deny). Jeśli w politykach znajduje się reguła Allow i nie ma żadnej reguły Deny umieszczonej explicite, dostęp jest dozwolony.

w IAM reguła blokująca ma zawsze priorytet nad regułami zezwalającymi

polityki - dokument JSON z opisem uprawnień

SCP - Service Control Policies

IAM policy: Statement[]: Effect (Allow/Deny) Action/NotAction Resource

Role: wirtualne konta, mają swoje klucze dostępowe (zarządzane przez STS) i przypięte polityki, ale nie są kontem IAM można je przypinać do usług (np. instancji AWS) role można przypisywać na podstawie zewnętrznego uwierzytelniania (np. SSO)

SSO federation odbywa się przez STS

AWS systems manager

Clone this wiki locally