More than 1 year has passed since last update.

AWS Solutions Architect Associate (SAA-C03) メモ

Last updated at 2023-02-20Posted at 2022-10-18

ユーザ管理
インスタンスとデータ保存
Elistic Load Balance（负载均衡）
RDS（Relational Database Service）
- Reaad Replicas
- ElasticCashe
Amazon Root 53
Solution Architecture（サービス接合し、問題を解決）
S3
Integration and Messaging
Cntainer
- Docker
- ECS
Serverless
Database
- database types
- RDS
- Aurora
- ElastiCash
- Dynamo DB
- S3
- Athena
- Redshift
- Glue
- Neptune
- ElasticSearch
CloudWatch
STS(Security Token Service
Security
VPC(Virtual Private Cloud)
disaster recovery
event processing
block an IP address
other service section

some tips from exercise

about network
- 「security group」を使うと、アクセスを”allows”できるが”denies”はでき無い。subnetに対し、denyのIPを設置したい場合、「NACL」を使う。そして、「security group」には”inbound”を許可した後、”outbound”は自動許可されるが、「NACL」の場合、”inbound”と”outbound”、両方の設定が必要
- もしサービスの”workload”が”stateless UDP based”の場合、このサービスのavaliabilityを上るため、NLB（network load balancer）と「Amazon Global Accelerator」を使う
- 複数のVPC、或いはAWS外部networkを繋ぐにはVPC peering以外、privateLinkが使用出来る。且つprivateLinkはNLB後にいるサービスをユーザに提供し、管理の手間が少ない（least amount of　administrative）
- Route 53使う時、”CNAME vs Alias”の場合、「Alias」を選ぶ
- 黙認状態のload balancerはHTTP protocolを使う。
about database
- DynamoDB使う時、もしthroughputが一定値に維持し無い、まだ変動激しいの場合、「on-demand mode」を使う、逆の場合「provisioned mode」を使う
- RDSダータベースの”sub-millisecond”の反応速度求む場合、DBのcacheを「ElasticCache」で構築を考える
- DynamoDBはNoSQLなので、複数のindex使える、そしてTTL設置すると、期限過ぎたデータを削除できる
- 有効期限のあるデータ、ランキングデータ、IoTデータの一時保存先、Pub/Subを使う（Volume(大量データ)とVelocity(秒単位で大量データ)に関する問題を対処）の場合、ElastiCache Redis使う
- ”NFS（network file system） server、SMB file、Amazon FSx for Windows File Server”などの中のデータをS3やEFSに同期の場合、「DataSync」を使う。もし”SFTP to exchange data with third parties”や”FTPS、FTP transfer”の場合、「AWS Transfer XXX」を使う。
- ”SMB・NFS protocol”データのon-premisesとAWS cloudの同期は「Storage gateway」で行う
- 「S3 intelligent tiering」検索費用かから無い、「S3 infrequent Access」は検索費用掛かる。
- RDS DBの”database read”を減らしたい場合、優先ElastiCache Redisを使う、そしてMemcached。
- RDS DBにread replicaを追加する前、先ず”long running transactions(長時間事務)”の終わりを待つ、同時に元DBの自動backupをONにする上、retention period(保留時期)を0以外に設置。
- 頻繁では無いAurora DBの使用は、「Aurora serverless」を使う。
- NFS volumeをbackupの場合、Storage Gateway file gateway hardwareをインスドールし、コピーをS3に入れる。
- on premisesのDBをAWSに移す時、もし複数会の作業があり、同時にその間二つのDBを同期したい場合、Schema Conversion ToolとCompute optimized replication instanceを持つDatabase Migration Serviceを使う
- S3のtotal sizeと実際払う金額で計算した使用量が違う場合、versioningの有効かと不完全のmultipartのuploadが原因かも
about permission/ security
- ”EventBridge(cloudWatch event)”でルールを実行し、Lambda、SNS、SQS、Cloudwatchにアクセスの場合、resource-based policyが必要、kineses streamアクセスの場合、identity-based policyが必要参考記事
- AWS RDS instanceとapp間のデータが”transit encryption”必要の場合、”download AWS-provided root certificates”、そしてこのcertificateをRDS instanceのconnection に提供。
- webサーバーのcross-site scriping（XSS）攻撃を防ぐにはApplication Fire Wall（WAF）を利用、DDos攻撃を防ぐにはShield Standardを利用。同時にWAF上クライアントからのサービスアクセス頻度を制限できる。
- GlacierはS3と同じく、AES-256　encryptが使える。
- 秘密keyを作成、管理、削除など、keyのlifecycle完全コントロールしたい場合、KMSのCloudHSMを使う。
- S3にuploadした物がencryptedを保証したい場合、bucket policyで”x-amz-server-side-encryption headerが無いものを拒否”を設定。
about others
- "synchronous"のサービス見た時, 多分「SQS」と「Lambda」のコンビで、"decouple"や"asynchronous"の必要がある
- 大量のユーザ（万以上）或いは大量のデータを”near-real-time solution”を求める時、kinesis data streamを使う。よく”kinesis data firehose”と一緒にででくるが、firehoseではS3とredshiftに直接データ入れる機能が付いている（DynamoDBはダメ）、streamはデータ保存や処理したい時、よくLambdaと一緒に使う。
- third partyのユーザにAWS resourceをアクセス出来るため、「external ID」の方が短期間アクセスに似合う。もしthird partyがAWSアカウト持ち、そしてSQSにアクセしたい場合、特定のSQS queueに「permission policy」を追加できる。
- ユーザのrequestが不安定で激しい増加があり、この時サービスが対応しきれ無い場合を避けるため、SQSでユーザrequestを受け取り、サービス側がSQSからrequestを取得。
- ”distributed session”を使う場合、「sticky sessions」では無く、「ElistiCache」でsessionを管理する。
- EBSを使うEC2をHibernate（冬眠）したら、EBSのmemory費用がかからない。
- file ServerがServer Massage Block（SMB）使う場合、「Amazon FSx」を使う。
- 設計中のサービスにtrafficを送って、パフォーマンスをテストしたい場合、Amazon Route 53「weighted routing」を使う。もしサービス設計を他の環境移したい場合、AWS CloudFormationのparameter setを使って他環境から同じものを作成。
- サービスにmachine learningやhigh performance computing（HPC）求時、「FSx for Lustre」を使う
- EC2を止める時、root EBSを保留したい場合、EC2をlaunchし、root EBSを作成の時、EBSの「DeleteOnTermination」をfalseにする。そうすると、EBSが保存され、ほかEC2につける事ができる。
- on-premisesのserverをAWSに移行したい場合、「Server Migration Service(SMS)」を使う
- S3中のlogを分析の時、Athenaを分析、そして「Amazon QuickSight」で結果を可視化する
- 同じ「tag」を持つリソースを洗い出したい場合、「Resource Groups Tag Editor」を使う。
- data mining applicationで使う、Elastic MapReduce（EMR）のHadoopはopen sourceのJava framework。

aws root accountと一般ユーザの関係

root account
 |- ユーザ01
 |- ユーザ02
 |- ユーザ03 ...

複数ユーザをまとめ「ユーザグループ」にする事が出来、
ユーザ単体とユーザグループには「権限」の設定が出来、大体root account作成後は使わず、adminのユーザを作成し、「AdministratorAccess」権限を上げ、管理者として使う、例は画像として：

薦めのvirtual MFAアプリ

virtual MFA deviceとして、「Authy」が進め、一つのデバイスで複数のアカウントMFAを行う

AWS CLIでユーザ登録

まずIAMユーザとしてAWS登録、ユーザ詳細画面で、access keyを作成

そしてローカル環境でAWS CLIインストールし、以下のコマンドでユーザ設置

aws configureコマンドでaccess keyを設置

XXXXX@AA-BB-CC AwsFolder % aws configure
AWS Access Key ID [None]: AKIAZ4C6662SPCB7FXXX
AWS Secret Access Key [None]: JZFVu87wwWFOatW5IiXsO8Awl5N9pO58PMsQXXX
Default region name [None]: ap-northeast-1  //(自分に近いサーバーを設置)  
Default output format [None]:  //(直接[enter]を押す)

IAM機能でユーザ管理時の注意点

各EC2インスタンス機能を比較

参考URL：https://instances.vantage.sh/

EC2インスタンスでよく使うport

Elastic IPの使用

EC２インスタンス毎回起動の時、public　IPv４が新規され、もしインスタンスをずっと同じpublic　IPv４に固定したい場合、Elastic IPを発行し、そのインスタンスにくっついていく。大体５個Elastic IPが発行出来るが、発行後すぐインスタンスと連携しないと課金が発生。
このElastic IPの使用はすすまない、インスタンス起動の度、新しいpublic　IPv４使った方がいい

ENIの使用

Elastic Network Interfaceを作成し、インスタンスに追加することができる。
ENIは追加されたインスタンスと同じavailability zone(AZ)にする必要がある、例えは：インスタンスAZが「ap-northeast-1c」、ならENIのAZも「ap-northeast-1c」になる必要がある。
ENIは自分のprivate IPv4を持っている、インスタンスに追加後、該当インスタンスが二つのprivate IPv4を持つことになる。そして、インスタンスを中止後、インスタンス自身のprivate IPv4は再作成されるが、ENIは変わらない。こうしてprivate IPv4を固定することができる。

EC2 hibernate機能の使用

EC2 hibernate(冬眠)と言うのは、stop(停止)、treminated（インスタンス削除）以外、RAMの内容保存し、EC2を冬眠させ、再度起きるの時、再起動は不要。「uptime」コマンドでインスタンス起動時間見ると、時間が加算される。この機能使う場合、インスタンスを作成時「stop-hibernate behiever」にチェック入れる必要があり、そして「root volume」上、インスタンスRAMを保存出来る余裕を持つ必要がある

EBS Snapshotsの使用

EBS Snapshotsを使って、EBS volumeのコピーを取得でき；本来EBS volumeを追加できるのは、同じAZのインスタンスのみ、でもEBS Snapshotsは違ったAZ間でも転移することが出来る。
加えて、インスタンスをterminated（インスタンス削除）ご、rootのEBS volumeが自動的に削除される（これはインスタンス作成時設定できる）が、EBS SnapshotsでrootのEBS volumeをコピーする事も出来る。

amiの使用

AMIはインスタンスを作成前（launch前）の初期化設定をコピーしたもの。AMIを使ってい、似たようなインスタンス再作成の時は便利。

efsの使用

EBSと違い、EFSは違うAZの複数EC2で同時に使用できる。サイズではなく、使用量で課金を測る、少ない共通ファイル保存の時コスパが良い。ただLinux EC2専用、Windows EC2は使用できない

活動モードと特徴：

EC2 instance metadata

load balancer種類

ALB(application　load balancer)
クライアントからのアクセスは全てALBに入り、そしてALBからもう一回インスタンスグループのインスタンスをアクセスする。この場合、ALB作成の時、security groupsを作成、インスタンスのinbound roluにそのgroupsを追加。すると、インスタンスにアクセス出来るのはload balanceのみ
NLB(network　load balancer)
ALBと違い、インスアンスへのアクセスを再作成しないため、インスタンスのinbound roluに全てのクライアントがアクセス出来る様に設定する必要がある
GLB(gateway　load balancer)
全ての情報交換はGLBを通過し、監視される、GLBもload balanceの機能が有る

Cross zone load balancing

SSL TLS関連

SSL(secure sockets layer)はクライアントとload balancer間のデータ暗号化為の物。TLS(Transport layer security)はSSLのレベルアップしたも物；AWSにおいて、TLSほぼイコールSSL。

Connection Draining

Connection Drainingを設置したEC2は、削除や不健康になる時、少し時間を待つ後、load　balancerとの接続を遮断する

Auto Scaling Groups

ASGの中ではELB付きのサービスを一括設置が出来、ASGは設置数に合わせて、EC2を作成；そしてEC2のhealthy状況を監視し、もしunhealthyまた数超えたEC2が出た場合、そのEC2をterminated、そして新EC2を建つ。ASG中欲しEC2数を増やすと、同じく自動的にEC2を作成される。
ASGにScaling Policiesを追加することが出来、SPを使って、EC2の使用状況によってASGの動作を事前に計画する事ができる。例えば特定の日時のインスタンスの追加をスケジュール；或いはEC2の使用率を監視し、もしキャパオーバーの場合、EC2を追加。

Reaad Replicas

大量DBのデータを読み、でも本来のDBの効率に影響与えたくない場合、read-onlyのDBコピーを作成し、そこからデータを取得

もしead-onlyのDBコピーが本体と同じregionの別AZにいる場合（例：us-east-1a / us-east-1b）、追加コストが発生しない。でもお互い違いregionにいる場合（例：us-east-1a / eu-west-1b）、追加コストが発生

ElasticCashe

DBへのデータ読みの需求を下げ、主に読む作業で使う；毎回DBからデータ検索ではなく、Casheから快速取得。

DNS

普通使われているwebサイトの名をIPアドレスに変換する（例：www.google.com => 172.217.18.36）

Amazon Root 53

Amazon専用のDNS申請と管理サービス、ここで自分のDNS名前を作成できる。DNS上の制御
は主に「Record」機能を通じて実現する

Records TTL

clientがDNSからserverのIPアドレスを貰い、そのIPアドレスはclient側での保存時間を設定できる。２４時間だとDNSへの訪問頻度が少ない、６０秒だとDNSへの訪問が増え、もっとコストが掛かる。

CNAME vs Alias

どっちもload balancerを指定できるが、CNAMEではroot目次は使えない、大体の場合aliasの方が良い

Multi Value

Multi Valueを利用し、複数のIPのhealthy状況を監視し、healthyのIPだけクライアント側に渡す

Domain Registrar vs DNS Service

自分のdomainを申し込むのはthird partyサービス提供者で行うことは出来、そしてAmazon Root 53でそのdomainのDNSサービスを提供する。普通third partyサービスdomain提供者はDNSサービスを提供しているはず、それをAmazon Root 53に遷移する為、Root 53作成後、third partyのdomain設定にRoot 53の”Nameserver”入れる必要がある。

WhatIsTheTime

一つの例で、コスパとwebサイトの安定性と拡張便利性をそ総合考慮する参考URL

MyClothes

webAPPを例にして、ユーザの臨時情報保存について案を出し、そしてEC2とDBの配置について案を出す参考URL

MyWordPress

データ保存必要のwebサイトを例にし、EBSとEFSでデータ保存の案を比べる

早めにEC2のAPPを構築

S3 security

ユーザベースとバケット本体ベース、二種類のコントロール方法あり；注意すべきのは、ユーザレベルでバケットのアクセス権をあげ、でもバケット本体レベルでアクセスを拒否したら、結果的にアクセス出来ない。

S3 CROS

S3 access log

log保存用のバケットで、他S3バケットのアクセスや操作の記録を保存できる。但し、絶対に保存用バケットを自分自身のlogを保存しては行けない、無限のループになる。

S3 replication

SRR：同じregionのS3のコピー、CRR：違うregionのS3のコピー

S3 lifecycle rules応用

参考URL

CloudFront

CDNとしてアクセスとS3を制御

CDNとしてアクセスとEC2を制御

Global Accelerator vs CloudFront

storage gateway

FSx for windows

機能としてEFSに似ている、EFSはWindowsシステム上使用できないので、代りにFSx for windowsを使って、複数EC2の共有ファイルを保存。
同時にFSx for Lustreを使って、Linux上大規模並行計算ができる、machine learningやhigh performance computingができる

storage comparsion

AWS各storageサービス概要

SQS

SQSでコマンドや情報を保存し、ほかのサービスをコントロールする

SQS queue access policy

ほかアカウントのサービスもSQSに情報入れろのは出来る、該当SQSのaccess policyにアクセス権の追加が必要

SQS vs SNS vs Kinesis

Docker

ECS

EC2をCPUやRAM見たいの資源として使い、dockerをそのEC2に乗せる、EC2は自分用意必要

一つのAuto Scaling groupにまとめたEC2集合をEC2 Clusterとして、ECSで複数のdockerタスクを起こす

Fargateでは、EC2を自分で用意しなくでいい

what is serverless

Lambda

LambdaEdge

Lambdaを使って、ユーザとCloudFrontのrequest／response、CloudFrontとオリジンサービスのrequest／responseをコントロールできる

DynamoDB

NoSQLデータベース、primary key以外のkeyは毎行カスタマイズできる。

API Gateway

API Gateway Security

Cognito

cognitoをユーザ保存するDBと思え、ユーザがcognitoにログインご、JWTを貰い、そして他のAWSサービスをアクセス出来る。CUPにログイン出来るのは普通のメールアドレスやpassword以外、googleとFacebookアカウントもできる

sam

SAMはserverlessサービスを快速開発為のframework

big data ingestion pipeline

database types

RDS

Aurora

ElastiCash

Dynamo DB

S3

Athena

Redshift

Glue

Neptune

ElasticSearch

Dashboard

dashboardはglobalでmultipleユーザとmultiple regionの使用は可能、dashboard中全てのパーツは同じ時間帯或いは時間点のデータを表示している

CloudWatch Log for EC2

CloudWatchは直接EC2のlog見ることはできないが、EC2にCloudWatch logs agentをインストールすると、CloudWatchへlog送信出来るこの場合、EC2はCloudWatchにアクセスする権限が必要

Evevt Bridge

全てのcloudWatch eventsの機能を持つ同時に、third partyサービスからのevent、cloudWatch events進化版と思え、そしてcloudWatch eventsは徐々にEvevt Bridgeに置き換わっていく

Cloud Trail

AWS上の資源を書き込みや読む操作を記録

Management eventは黙認記録される、Data　eventは黙認記録しない

cloudTrail insights不自然の監視と記録、コスト掛かる

Cloud Trail event監視記録はデフォルト90日保存される、もしもっと長い間保存したい場合、それをS3に移し、そしてAthenaで内容を分析するのもできる

AWS Config

configはAWSサービスの配置或は状態、パラメータを監視、そして希望値に合うかどうか判断出来る

configは操作しない、あくまでも監視と判断のみ

configは判断結果の送信

CloudWatch vs CloudTrail vs Config

STS

AWS基礎的なサービス、ユーザの仮ログイン（他ユーザアカウントを借りる、CROSS-account）、各サービスのアクセス機能にはこれを使っている

Cognito

AWS Organizations

組織として複数のAWSアカウントを管理、mainアカウントは一つ、他のアカウントの支払い方法をmainアカウントに紐付ける。組織に対し、サービス料金の割引もある

IAM Advanced

IAM Permission Boundaries

ユーザとroleのみ適用できる、組織には設置できない。最大の権限を設置し、この最大権限を超える権限が付けられでも有効にならない。

権限のルール：一つサービスに拒否がある場合、例えそのサービスの子機能が許可されたとしても、実際には拒否される。

Resource Access Manager

Single Sign On

複数のサービスのログイン機能をまとめる。AssumeRoleWithSAMLより便利。

three kinds encryption

encryption in flight(SSL HTTPS)、データはクライアント側発送前暗号化され、そしてサーバーで復号される

サーバー側データを保存の前、keyで暗号化し、データを保存；そのkeyはKMS（key manage system）で管理。ユーザがデータを取り出す前、一度復号し、データをユーザに返す

クライアント側でkeyを管理、サーバーで暗号化されたデータのみ保存

KMS

AWS上は大体symmetric種類、Asymmetric使う場合、AWS以外でprivate keyで暗号化する必要がある

parameter store

AWS上サービスパラメーターを暗号化する

secrets manager

shield

DDOS攻撃を防ぐ

CIDR

subnet

igw

subnetとinternetの接続はIGWで管理、さらにIWG中でroute tableを作成、それでsubnet中のEC2のrouter接続設定を管理

nat

NAT instance（古い方法、非推奨）
private subnet中のEC2が外部publicのネットをアクセスしたい場合、まず同じVPCのpublic subnet中接続用EC2を立ち、そして内部から外部へのアクセスを先にNAT instanceにわたし、そしてNAT instanceから外部へ請求を出す、この場合、requestを一度再構築されたので、内部EC２の「source/destination chack」を無効化する必要がある
NAT gateway（NAT instanceの代わり、推奨）

security groups and NACLs

security groupsはstateful、NACLsはstateless；例えは外部からEC2をアクセスの時、requestはNACLとsecurity groupsの検証が必要、そしてEC2からresponse返す時、security groupにとって、一度requestの検証をしたから、responseには検証を掛けない、でもNACLはresponseにも検証を掛ける。逆に、EC2からrequest出す時、security groupからの検証を通過した場合、response受ける時、security groupの検証が不要

NACLは主にsubnetレベルのアクセスIPを制御する、default NACLは全てのinboundとoutboundを許可する。

システムOSにより、requestを発信時ephemeral portが使用する、このportはランダムで取る；ランダムで毎回のrequest　portを取るため、NACL設置の時、このephemeral portを範囲を考慮する必要がある