我成功通过AWS CLF考试的时候所做的笔记，只用了三天

2 年 ago

新, 韵

4 minutes

简约概述

这篇文章是我在准备AWS CLF考试时所做的笔记的直接记录。

如果你愿意的话，可以参考我在学习和记笔记时意识到的以下事项。

反复进行第二步，并偶尔回顾笔记。

教材的参考

CLF的应对措施

AWS的概述

クラウドベース

クラウド移行や、最初からクラウド上で実装

オンプレミス（プライベートクラウド）

仮想化ツールとリソース管理ツールの利用

ハイブリッド

クラウドベースからオンプレに繋げる

クラウドコンピューティングの利点６種

先行支出から変動支出（従量課金）
データセンターの維持管理費用が不要（クラウド上にあるから）
キャパシティの予測が不要（サービスをオンデマンドで利用できるから）
圧倒的なスケールメリット（多くのユーザーによるクラウドの使用量が集約されるから、従量課金制の料金を低く抑えることができる）＝「規模の経済」（規模が大きいことによって、資源もトラブル対応もハイクオリティで行うことができる）
スピードと俊敏生を向上（クラウド上にあるから）
数分でグローバルに展開（アプリケーションを低レイテンシーで提供）

云计算

概述

マルチテナンシー

基盤となるハードウェアを、仮想マシン間で共有する（例：銀行）

ハイパーバイザー（仮想化OS）

マルチテナンシーを調整する

垂直スケーリング可能

EC2スペック自体をのあげる

EC2（亚马逊弹性计算云）

アンマネージドサービス（ユーザー側で基盤となる仮想インフラの完全な管理権限を保持することができる）

实例类型

计算优化
计算负载高的任务
游戏服务器
高性能计算（HPC）
科学建模

内存优化
内存负载高的任务
内存是数据的临时存储（RAM）
高性能数据库
大规模数据集在内存中的处理

快速计算
浮点计算
图形处理
数据匹配模式
利用硬件加速器（加快处理速度的辅助功能）

存储优化
针对本地存储的高性能
具体来说，对大规模数据集进行快速连续读写
存储是数据的永久存储位置

费用

根据需求（仅使用所花费的时间）

Amazon EC2节省计划（保证）

按小时预定使用量（保证一定的计算使用量）
1年或3年
最高可节省72%
也可适用于AWS Lambda和AWS Fargate的折扣

预留实例（保证）

在长期能够预测到容量需求稳定时很有用
1年或3年
最高可节省75%
全额预付款或部分预付款或无需预付款

竞价实例

适用于没有确定的启动或关闭时间，或可以中断的情况（如批处理、测试等）
换句话说，可以将未被使用的EC2实例出售，如果购买则可以使用
价格会因供需关系而波动，因此可能会在中途停止服务器（卖方）或无法长时间使用（买方）
最高可节省90%

专用主机

可以使用专用的带有EC2的物理服务器
当然，价格最高

按比例缩放（数量和质量）

拡張性と伸縮性

亚马逊 EC2 自动伸缩技术 (Scaling)

最小キャパシティ、（必要キャパシティ）、最大キャパシティ（Auto Scalingグループの設定に必要な引数）

弹性负载均衡（流量）

EC2AutoScalingと組み合わせることで強力な効果を発揮する。

消息传递和队列

単一障害でカスケード（連鎖的繋がり）の失敗が発生してしまう可能性がある

疎結合

アプリケーションAB間にバッファ（メッセージキュー）を入れることで、どちらかの機能に障害が発生しても、どちらかは稼働できるようになる（バッファにキューを貯める事ができるから）

亚马逊简单队列服务 (Simple Queue Service)

Amazon SQSキュー

メッセージ（ペイロード）が処理されるまで配置される場所

オートスケールする

亚马逊 SNS (简单通知服务)

エンドユーザーに通知を送ることもできる

その仕組みはSQSと異なり、Pub/Subモデルと呼ばれている

Amazon SNS トピック

配信するメッセージのチャンネル

サブスクライバーを構成して、それらにメッセージを送る

サブスクライバーにはエンドポイントを使う事ができる

SQSキュー、AWS Lambda関数、HTTPS,HTTPウェブフック等

エンドユーザーに対しては、モバイルプッシュ、SMS,E-mail等を使える

重要的计算机服务

そもそもEC2は

インスタンスをプロビジョニング
コードをアップロード
アプリケーションの実行中、インスタンスを管理し続ける

この3つ目が面倒なのよ。なんでかっていうと、新しいパッチとかが来たら適用しなければならず、管理コストが発生するから

つまりEC2は「サーバー」「コード」の2つを管理しなければならない

なお、AMI（ソフトウェア構成のテンプレート）を使うとEC2インスタンスからイメージを取得して、そこから新しいインスタンスを作成することができる

AMIは色々とできることが多い。テンプレートだから

サーバーレス

基盤となるインストラクチャの表示またはアクセスをする必要がない
つまり「コード」1つだけの管理をすれば良い

亚马逊云Lambda

短い実行時間
サービス指向
イベント駆動
サーバーのプロビジョニングが不要

の時におすすめできる
ただ実行プロセスは15分以内（深層学習とかには向いていない）

集装箱

我想在AWS上运行基于Docker容器的工作负载！

选择在哪里运行容器

【1】：ECS与EKS（处理容器规模不同）。

【1】：ECS和EKS（处理容器规模的差异）。

ECS（Amazon Elastic Container Service）是支持Docker容器的，可以通过API调用来启动和停止Docker容器（能够执行应用程序本身）。

请注意，Kubernetes是被Amazon Elastic Kubernetes Service（简称EKS）支持的。

【2】：EC2或AWS Fargate

AWS Fargate是AWS提供的容器无服务器计算引擎，因为使用了AWS托管的预设服务器，所以无需进行服务器的配置和管理。

：费用只针对容器所需的资源产生。

弹性容器注册表 (ECR)

AWSクラウドに保存・管理することができる

全球基础设施与可靠性

高可用性と耐障害性

亚马逊云服务全球基础设施

地区

各リージョンは地理的に分離しているので、以下の用件を検討して、どのリージョンを使うのかを選択する事が重要

费用（主要原因是税收）

阿兹

アプリケーションは基本的に、リージョン内の少なくとも2つのAZで実行する

边缘位置 zhi)

CDN(Contents Delivary Network)

Amazon CloudFront
リージョンから分離された世界中のエッジロケーションを使用

顧客の近くにあるエッジロケーションに、必要な分のデータのキャッシュをコピーしておくことで、安定したテイレンテンシーでコンテンツを配信する事ができる

Amazon Route53というDNSサービスも、エッジロケーションで実行される

APIGatewayと連携させる

AWS Outpostsは、独自の建物内でAWSを使用できるサービス

ハイブリッドクラウドアプローチでうんフラストラクチャを運用できる
AWSが所有、運用するが、利用したい建物内でちゃんと分離されている

AWS Global Accelerateは、ユーザーの地理的に近いエンドポイントにトラフィックをルーティングしてくれる

アプリケーションエンドポイントを継続的に監視

AWSリソースのプロビジョニング

APIを使用

AWS マネジメントコンソール
AWS CLI
AWS SDK
その他(cloudFormationとか)

AWSマネジメントコンソール（手動）

ウィザードと自動化されたワークフローを利用して、AWSのサービスでタスクを実行する

テスト環境
AWS請求書の表示
モニタリングの表示
非技術リソースで作業する

ただ、人間の手作業なので間違いが必ず起こる
そこでAPIコールのスクリプト化や、プログラミングを行えるツールを使用する

AWS命令行界面（脚本化）

EC2インスタンスを作成して、特定のAutoScalingグループに接続することだってできる

このようなオートメーションは、長期的安定性に不可欠

AWS SDK（软件开发工具包）的编程化版本。

さまざまなプログラミング言語を使用して、AWSリソースを操作する事ができる

（管理工具篇）

AWS弹性Beanstalk

これにより個別の細かい設定を管理する必要性も無くなるし、可視性も備えているので、細かい修正も可能

つまりEBはアプリの迅速な展開に優位性がある
しかも、ただデプロイするだけでなくデプロイメントの詳細（養老のプロビジョニング、負荷分散、Autoscaling、モニタリング）を処理してくれる

AWS 云形成

自動作成や反復可能なデプロイに役立つ

アプリケーションの直接的な展開には利用できない

Iacのサービスで、JSONかYAMLのテキストベースのドキュメントを使用する（CloudFormationテンプレート）

細かく厳密に定義する必要はない＝細かいところはCloudFormationエンジンがやってくれる

EC2以外にも、ストレージ、DB、分析、MLにも使える
複数のアカウント、複数のリージョンで並行展開もできる

OpsWorks

ChefやPuppetのマネージド型インスタンスを利用した構成管理サービス
上記2つのインスタンスを使用して、EC2インスタンスの構成方法を自動化することができる

ネットワーク

VPC

IPアドレスの範囲を定義できる
後述のさまざまなゲートウェイの存在により、1つのVPC内に多くのゲートウェイが存在する可能性があることに留意する

サブネット

VPC内のIPアドレス群
ここに、パブリックとプライベートに分けて、AWSリソースを配置する事ができる

ゲートウェイ

パブリックならインターネットゲートウェイ
「VPC内にプライベートリソースのみが配置されている」なら仮想プライベートゲートウェイ(VPN接続の確立)

ただ、このままだと他の一般ユーザーと同じ帯域幅を使うことになるので、トラフィックの影響を受けてしまう

AWS Direct Connect

そこで、データセンターとプライベートなサブネット（VPC内のコンポーネント）をAWS Direct Connectで繋げることで、完全にプライベートな専用ファイバー接続を確立する事ができる

子网和网络访问控制列表

网络ACL（默认情况下为全部允许）（但是使用自定义网络ACL则为全部拒绝）。

常に独自のリストがチェックされる
処理情報が記録されることはなく、常にチェックリストに当てはまるかどうかだけ確認している

サブネット毎の入国審査官
アウトバウンドも明示的許可が必要

安全组（默认情况下：入全拒绝，出全允许）

処理情報を記録しているので、リターントラフィックはそのまま入ってこれる

全球网络

亚马逊AWS的路由53

AWSが提供するDNSサービス

可用性に優れスケーラブル

トラフィックを異なるエンドポイントに振り分けることもできる。これについては前述のCloudFrontとの連携が強力。

顧客が「oo.com」にアクセス
Route53がDNS解決
顧客からのアクセスは、CloudFrontを介してエッジロケーションに送信
最後に受信パケットを処理

存储和数据库

实例存储和亚马逊弹性块存储（EBS）

实例存储

EC2インスタンスのホストコンピュータに物理的にアタッチされているディスクストレージであるため、存続期間がそのインスタンスと同じ

そのため重要なデータは入れない

EBS 可以翻译为 “电子商务系统”。

つまり重要なデータを入れることになるので、当然バックアップが必要。そこで↓

EBS快照。

データが増えた部分だけ、逐次バックアップをとっていくスタイル

亚马逊简单存储服务（S3）

リージョンストレージだけど、標準でマルチAZ展開してる

对象存储

ブロックレベルのストレージ内のファイル変更は、変更した部分のみ更新されるが、オブジェクトレベルのストレージ内のファイル変更は、オブジェクト全体が更新される

关键字（独特的标识符）

S3只需要一种选项。

階層化やアクセス許可ができる、ということ

ちなみに静的ウェブサイトのホスティングもできる（ブログにも最適）

S3 Transfer Accelerationを使うと、長距離でも高速かつ安全にデータ送信ができる
標準SQLでS3ないのデータを分析する場合は、Athenaを利用する

S3 存储级别

データの取得頻度
データの可用性要件

适用于频繁访问的数据设计
数据将在至少3个可用区备份（且具有单独的耐久性达到11个9）

S3标准-IA（低频访问）

适用于访问频率较低的数据（例如备份、灾难数据和审计数据等）
存储费用较低，但提取费用较高

S3 1区-IA

数据将在一个可用区备份
比S3-IA有更低的存储费用
适用于“节省存储成本”以及“在可用区故障时容易恢复数据”的情况

S3 Glacier

设计用于低成本数据归档
可以在几分钟到几小时内检索对象（有三个选项可供选择）
使用S3 Glacier保险库锁定策略可以防止对数据进行修改，并实现数据的安全存储（一旦设置，无法更改）
可以指定类似于WORM（一次写入，多次读取）的控制

同时可以应用S3的生命周期管理

可以在不同存储级别之间自动移动数据

例如，最初的120天使用S3标准，接下来的30天使用S3-IA，然后可以设置为S3 Glacier等，数据将自动按照设定进行迁移

S3 Glacier Deep Archive

最低成本的对象存储类别，非常适合归档
在12小时内可以检索对象

与S3 Glacier的区别在于数据检索所需的时间

S3 Intelligent-Tiering

适用于访问模式未知或变化的数据
每个对象需要支付每月少量的监控和自动化费用

如果连续30天没有访问，对象将被转移到S3-IA；如果有S3-IA访问，则对象将转移到S3标准

EBS与S3的对比

如果用户上传的图片，通过一个网络应用程序进行图像分析并展示出与该图片相似的动物的情况。

ウェブが有効（静的ウェブサイトに適応）
地理的に分散（リージョンストレージであり、イレブンナインの耐久性）
コスト削減を実現
サーバーレス（EC2インスタンス不要）

正在对一个80 GB的视频文件进行编辑和修正。

EBS

そもそもオブジェクトストレージとブロックストレージの違いは、データに変更を加えた際に、データのどの部分を再アップロードする必要があるか、という点にある
オブジェクトストレージは、画像、テキスト等全てのデータをオブジェクトとして管理しているので、一つのデータの変更でオブジェクト全体を際アップロードする必要がある
対してブロックストレージは、データを細かくコンポーネント化しているので、細かい修正を多数行っても、アップロードはその変更部分だけで良い
従って動画編集という細かい変更が都度要求されるものはEBSが最適（つまり、変更が頻繁でない場合にはS3、複雑な読み取りや書き込み、関数の変更についてはEBSに軍配が上がる）

Amazon Elastic File System(EFS)

ファイルストレージ

多数のサービスとリソースが同時に同じサービスにアクセスする必要があるユースケースに適している（共有フォルダをみんなで利用する感じ）

EFS

完全マネージド型NFS(Network File System)
複数のインスタンスから同時にEFS内のデータにアクセスできる

リージョンストレージ（複数のAZにデータを保存）
自動でスケーリング
オンプレサーバーからでもAWSDirectConnectでEFSにアクセスできる
NAS（Network Attached Storage）で、インターネットからアクセスできない

Amazon Relational Datebase Service(RDS)

主要なDBをサポート
自動パッチ適用
自動バックアップ
システム構成の冗長性のためのマルチAZ構成(ユーザー側で設定する。自動ではない)（ただ設定さえすれば自動フェイルオーバーしてくれるよ！）

データ冗長性や災害復旧対応、コスト最適化の面ではリードレプリカという機能が有効

フェイルオーバー
災害対策
フルマネージドサービスのためOSにログインすることはできない

Amazon Aurora

最もクラウドに特化したマネージド型RDB
MySQLとPostgreSQLに互換性がある
コストは商用DBの1/10
データレプリケーション（3つのAZ間に6つのデータコピー）
最大十五のリードレプリカ（負荷分散）
S3への継続的なバックアップ
ポイントインタイムリカバリ（特定の期間からの復旧）

AWS Storage Gateway

オンプレとAWSストレージを接続してくれる→ハイブリッドストレージサービス

バックアップ、アーカイブ、災害復旧、クラウドデータ処理、移行に利用することができる

Amazon DynamoDB

サーバーレスDB
NoSQL(キーバリューペア)

JSON形式のデータを扱うドキュメント型DBとして活躍できるよ！

リージョンストレージ

クロスリージョンレプリケーションで、複数のAWSリージョンにまたがって自動的にレプリケートされるテーブルを作成することができる

しかしまずその前に、DynamoDB streamsを有効にしなければならに

自動マルチAZ展開（３箇所）
自動スケーリング(10兆/day)
継続バックアップは手動で有効にする必要がある
セッションデータの処理に向いている

亚马逊红移

単一のAPIコールを使用できる

弹性 MapReduce（EMR）

データフェアハウジングがなくてビッグデータ分析が出たら、RedshitではなくEMRを選択する

AWS 数据库迁移服务（DMS）

源数据库和目标数据库不必是相同类型。

まず、スキーマ構造、データ型、DBコードが２種間で異なるため、AWS schema Conversion Toolを使用して、それらを変換する必要がある

開発及びテスト環境でのDB移行
DBの統合
継続的なレプリケーション

其他的数据库服务

MongoDBわークローdーをサポートするドキュメントDBサービス
コンテンツ管理、カタログ、ユーザープロファイルの管理に最適

Amazon Neptune

ソーシャルウェブの追跡に最適
グラフデータベース
不正検出のニーズの対応

Amazon Quantum Ledger Database(QLDB)

台帳DBサービス（イミュータブル）
全ての変更履歴を確認することができる

Amazon Managed Blockchain

分散台帳システム
オープンソースフレームワークのブロックチェーンネットワークを作成、管理するために使用できる

Amazon ElastiCache ・ AMazon DynamoDB Accelerator(DAX)

2つともDBアクセラレータ
DB上にキャッシュレイヤーを追加することで、一般的なリクエストの読み込み時間を短縮する

DAXはDynamoDBに特化したDBアクセラレータ

安全性

责任共有模型

OS・アプリケーション・データ → 顧客（クラウド内のセキュリティ）

用户许可和访问权限

亚马逊云服务身份和访问管理（IAM）

IAMユーザーはデフォルトで全否定なので、必要なアクセス権を付与すること
グループはIAMユーザーの集合体。複数のユーザーに同一の権限を付与することができる
IAMロールは、権限の一時的な付与をすることができる。

IAMユーザー、アプリケーション、サービスがIAMロールを引き受けられるようにするために、ロールに切り替える権限を事前に付与しておくこと
IAMロールを引き受けると、以前のロールで持っていたアクセス許可は全て取り消され、新しいロールのアクセス許可が与えられる。

IAMポリシー

AWSのサービスとリソースへのアクセスを許可または拒否するドキュメント

多要素認証

MFA

IDフェデレーション

IAMユーザーを作成しなくても、AWSアカウントのリソースに対する安全なアクセス権が外部の認証に付与される
SSO（シングルサインオン）を有効にできる（googleアカウントによる認証のようなもの）

亚马逊网络服务组织

ボリュームディスカウントもあるよ！

アカウントの階層的なグループ化（OU）
AWSのサービス及びAPIアクションのアクセスコントロール（SCP：サービスコントロールポリシー）

組織のルート、個別のメンバーアカウント、OU（組織単位）に適用することができる（IAM系はIAMポリシーが適用される）

合规

AWS文档库

特定の種類の情報を使用することに関する、AWSとの契約の署名におけるサービス（医療保険や個人情報取扱とか）

AWS Artifact Reports

サードパーティーの監査人からのコンプライアンスレポートを提供

カスタマーコンプライアンスセンター

ベストプラクティスとかチェックリストとかあってめっちゃ便利

服务中断攻击

ELB（SLOWLORISの対抗策）

对于其他类型的攻击，要采取有效的对策。

AWS Web应用程序防火墙 (WAF)

ACLを使用してAWSリソースを保護

AWS Shield – 亚马逊云保护

DDos攻撃にも対応してくれる

其他安全服务

AWS密钥管理服务 (AWS Key Management Service)

保管時の暗号化と送信時の暗号化

亚马逊云安全硬件模块（AWS CloudHSM）

業界水準の暗号化対応実施を保証（KMSの上位互換かもしれん）

亚马逊内部审核

ネットワークの到達性に関する設定
Amzonエージェント
セキュリティ評価サービス

亚马逊云卫士

他のAWSサービスとは独立して実行されるので、既存のワークロードの性能や可用性に無影響

亚马逊STS（安全令牌服务）

AWSリソースに対して一時的な認証情報を提供する

监控和分析

システムの監視
メトリクス（評価尺度）の収集
データを使用した意思決定

つまり「システムパフォーマンスの測定」「異常発生時のアラート送信」に役立つ

亚马逊云监控

メトリクスにある変数の閾値を設定することで、その変数が閾値に達した時にアラームを鳴らして、アクションをトリガーする

一元的な場所から全てのメトリクスにアクセスできる
アプリケーションインフラストラクチャサービスを可視化する
MTTR（問題解決のための平均時間）を短縮しTCO（総所有コスト）を改善する
アプリケーションと運用リソースの最適化に役立つインサイトを引き出す

AWS云跟踪

全てのリクエストがCloudTrailエンジンでログ(S3 無制限)に記録される
異常なアカウントアクティビティモ自動的に検出してくれる

CloudTrail Insightsを使用することで、次に実行すべきアクション（知見）も教えてくれる

亚马逊云服务（AWS）系统管理器

AWSで利用しているインフラストラクチャを可視化して、制御する

AWS可信顾问

コスト最適化
パフォーマンス
セキュリティ
耐障害性
サービスの制限

一部無料

费用和支持

亚马逊云计算（AWS）免费使用配额

AWSLambdaは月100万回の呼び出しが無料
DynamoDBでは毎月25GBのストレージを無料利用可能

12ヶ月間無料

AWSアカウントを作成した日から
オブジェクトストアサービスのS3は、最大5GBの標準ストレージが12ヶ月間無料

トライアル

一部のサービスは短期間の無料トライアルが可能
AWS Lightsailでは1ヶ月間のトライアルで最大750時間使用可能

AWS的收费模式

大体そう

予約支払い

EC2SavingPlansとか

ボリュームディスカウント

S3は使用量が大きくなるごとに1GBあたりの料金は下がってく

请提供仪表板

過去のデータとかも参照できるよ

合并账单（统一结算）

アカウント間で割引の共有(使用量を合算してディスカウントラインまで引き上げる、ってのはできないよ)

AWS 预算

亚马逊云服务 (Amazon Web Services) 预算

使用量が予算を超えた場合に送信される、アラートを設定できる

AWS成本浏览器

カスタムレポートを作成できる

亚马逊云计算服务价目计算工具

ユースケースのコスト見積もりを作成する

AWS支持计划

無料
24時間365日対応のカスタマーサービス
ドキュメント
ホワイトペーパー
サポートフォーラム
AWS Trusted Advisor
AWS Personal Health DashBoard

デベロッパー

ベーシックサポート
カスタマーサポートへのEメールアクセス（12時間以内）

ビジネス

デベロッパーサポート
AWS Trusted Advisorのベストプラクティスフルセット
クラウドサポートエンジニアへの直接電話アクセス（4時間以内）
インフラストラクチャイベント管理（キャンペーン・イベント支援）

エンタープライズサポート

ビジネスサポート
ビジネスクリティカルなワークロードに対応する15分のSLA
TAM（専属のテクニカルアカウントマネージャー）サポート

亚马逊网络服务市场

ほとんどのベンダーはAWSで使われることを許可してるし、従量課金制

转型和创新

亚马逊云采用框架（AWS CAF）

ビジネス
人員
ガバナンス
プラットフォーム
セキュリティ
オペレーション

转型策略

リホスト

リフトアンドシフトとも言われる
何も変更せずに、アプリを移行する

リプラットフォーム

リフトティンカーシフトとも言われる
基本的にはリホストだが、いくつかのクラウド最適化を行う（基幹のコードは変えない）

リファクタリング

アーキテクチャの再設計を行う
最も初期コストが高い

再購入

古いベンダーとの契約を終了し、新しいベンダーに切り替える
もちろん時間がかかるものもある

保持

ソース環境でビジネスに重要なアプリケーションを維持する

リタイア

10％〜20％の不要になったアプリケーションを削除する

AWS雪球系列产品

AWS Snowcone

最大8TB
エッジコンピューティング（EC2とか）のデータも送れる
普通はS3に保存される

AWS Snowball Edge

Storage Optimized

80TB

Compute Optimized

42TB

AWS Snowmobile

100PBまで乗っけれるトラックが来るよ！

在AWS上的创新

サーバーレス

AWS Lambda

IoT
Kinesis → IoTデータのストリーミング処理を実施してデータを収集する

人工知能

Amazon Transcribe→音声をテキストに
Amazon Comprehend→テキストパターンを検出
Amazon Fraud Detector→不正可能性のあるオンラインアクティビティを検出
Amazon Lex→音声及びチャットbotを構築

機械学習

Amazon SageMaker

云旅途

AWS Well-Architected框架

コスト最適化

练习问题

基本原则

世界中の全てのAWSリージョンで一意
3〜63文字以内

可用性
IDフェデレーション

IAMユーザーを作成しなくても、権限付与ができる
SSOを有効にできる

AWS内データの削除方法

物理メディアはそのままで、ストレージブロックを未割り当てとする

スケールメリット＝規模の経済
S3＝リーションストレージ
CloudFrontは単一障害点にはならないが、既存の単一障害点を解決することには役立たない。適切なエンドポイントにルーティングするRoute53、ELB、Autoscalingは単一障害点を解消することができる
カーブアウト(VPCができる)

企業が事業の一部を切り出して、その事業を社外事業の1つとして独立させること

ALB → Application Load Balancer
NLB → Network Load Balancer
CLB → Classic Load Balancer（ELBの古い版）
ELB → Elastic Load Balancer

ALB + CLB = ELB
CLBは特殊なケースを除いて基本使わない
NLBは高性能だが、利用すべき専用の用件が定義されていない限りWEBアプリケーション用のELBはALBを使う

EC2インスタンスのログ系は「CloudWatchログ」
マネージド型サービスにおいてユーザー側が実行すべきセキュリティ手順は「SSL/TLS（データ送信の暗号化）」＋「ログ管理」
見積もり→AWS料金計算ツール
S3はIPアドレスつけられないけど、URL経由で保存データはダウンロードできるよ（静的ウェブサイトホスティングできるからね）
RDS読み取り＝リードレプリカ（読み取り処理の負荷軽減）

オフロード＝負荷分散（システムの一部分を外部システムに渡す）

AWSプロフェッショナルチーム

ビジネス成果を実現

AWSコンシェルジュ

請求とアカウントの専門

Route53はWEBサーバーのヘルスチェックに基づいた監視に利用できる

だから正常なエンドポイントにトラフィックをルーティングして負荷分散を実現している

VPCフローログ

VPCのトラフィックログを取得する

Fargateはコンテナサービスのエンジンだからサーバーレス
メトリクス（評価尺度）→CloudWatch
AWS Config

AWSリソース設定の継続的モニタリング＋設定に対する記録の評価

Snowballはダメ→Snowball edgeならOK
データレイヤー.＝.DB
スナップショット＝簡易的なバックアップ（的な認識。EC2とかEBSで使う）

AWS CodeCommit（ソース管理）

アプリケーションリソースをアプリケーションコードと一緒に保存できる

AWS CodePipeline（デリバリーサービス）

フルマネージド型デリバリーサービス
アプリとインフラのアップデート用のパイプラインリリースの自動化

AWS CodeBuild（ビルド＆テスト）

クラウド内のコードのビルド及びテストができるよ

AWS CodeDeploy（デプロイ）

EC2,Fargate,Lambda、オンプレのサーバーなど、さまざまなコンピューティングサービスへのソフトウェアデプロイを自動化する
フルマネージド型のサービス

Neptune→グラフアプリケーション
Cognito→ウェブ・モバイルアプリにユーザーのアクセスコントロール機能を追加する
RDSはアプリケーション向けのRDB、EC2向けはEBSかEFS（単一・複数のEC2インスタンスにアタッチするかで変わる）
IAMエンティティにポリシーは含まれない（ユーザー、グループ、ロールの3つ）（ポリシーだけドキュメントだから、それを元に仲間外れにする）
S3は自動バックアップをしていない（複数のAZに自動的にレプリケートしているが、これは厳密にはバックアップではない）
プログラム呼び出しを認証→アクセスキー＋シークレットアクセスきー

我在使用中遇到了很多未知的东西。

SystemManager と CloudWatch(CloudWatchAgentとSystemManagerとの連携が前提)

アーキテクチャのスケーリングに関するガイダンス

IEM(Infrastructure Event Management)

侵入テスト

AWSからの許可なしに顧客がテストできる

EC2インスタンスに対するセキュリティなどは、顧客の責任範囲であるため

CLIの初期設定には、アクセスキーが求められる（他にはシークレットアクセスキー＋AWSリージョン＋出力形式）
AWS Organizationは、S3を統合して包括的なディスカウントを受けることのできる可能性がある

DynamoDBは、複雑なトランザクション処理が発生する業務システムには向いていない（銀行の振り込み処理とか）

トランザクションは、分割できない一連の処理のこと
つまり単純な記録の蓄積・処理には向いている

ユーザー側の責任の範囲は、**クラウド内（OS、ネットワーク、データ）**である
マイクロサービスアーキテクチャで構成されるアプリケーション（分散型アプリケーション）（ブロックチェーンみたいなもん）の分析・デバッグはAWS X-Rayで行う
Inspectorは、事前に定義されたセキュリティテンプレートを参照してEC2インスタンスを分析する
信頼性＝「障害の発生のしにくさ」＝「可用性の高さ」

システムの中断からの復旧、中断を緩和させる

障害からの早期復旧＋Autoscalingを活用した自動プロビジョニング

Snowball Edgeのもう1つの顔

「データ移行(Storage)」＋**「エッジコンピューティング(Compute)」**

切断された環境（軍事、海軍とか）における高度な機械学習＋フルモーションビデオ分析とか

不正処理は不正使用対策チームへご連絡を
閾値を超えた時にトリガーされる＝CloudWatch+SNS

請求額が予算を超えそうな時とか

CloudFrontの料金

トラフィック分散
リクエスト
データ転送アウト

インスタンスを停止させてもEBSのデータ保存料を支払う必要がある

逆に言えば、インスタンスを料金は支払わずに、データを保存しておくことができる

AWSの設計原則

スケーラビリティ
デプロイ可能なリソース
環境の自動化
疎結合化
サーバー代わりのマネージドサービス（サーバーレス）
柔軟なストレージオプション

コンタクトセンターソリューション＝Amazon Connect

Configは設定を外れると自動的にSNSがトリガーされる

コンプライアンスや脆弱性への有効策

SystemManagerはインフラとAWSサービスを可視化して制御するためのサービス

コンプライアンス・脆弱性向きではない

各フェーズに応じたカスタムコンソール＝AWSリソースグループ

RDSはオブジェクトを使用していません
RDSは途中でインスタンスタイプを縮小できる

ちなみにデータ容量だけはスケーリングできるよ（キャパシティは無理）

DAXを忘れないで！

ElastiCacheのDynamoDB版。処理の高速化よ！

DynamoDBにリードレプリカはないよ！

その代わりDAXクラスターにはある

CloudHSM(ハードウェアセキュリティモジュール)（モジュール＝システムの構成要素）
AWS Trusted Advisor

コスト、パフォーマンス、セキュリティ

スケーリングはIEMへ

DynamoDB＝ドキュメント型DBとして利用できる
リザーブドできるやつ

EC2インスタンス
RDSインスタンス
ElastiCacheノード
DynamoDBキャパシティ
Redshiftノード

S3やEFSは、データ使用量（＋データリクエスト量）に対して料金を支払う

MCS(Managed Apache Cassandra Service)

DynamoDBはAWS専用であるのに対して、MCSはオープンソースとの互換性がある

基本问题

RDSは自動バックアップしてくれるけど、マルチAZ展開は手動

DynamoDBとS3は自動マルチAZ展開

「初めからマルチAZ展開」＝リージョンストレージ

見積もり→AWS料金計算ツール

簡易見積もりツールは、AWS料金計算ツールに統合される

リザーブドインスタンスは、途中で利用をやめようと思えば、お金は返ってこないがマーケットプレイスで売りに出せる

S3は自動バックアップをしているわけではない