Basic AWS認定(デベロッパーアソシエイト)カンニングペーパー

2024-04-192024
29.8% (109.4/366)
April
61.3% (18.4/30)
Week 16
63.1% (4.4/7)
Day 19 Fri
41.7% (10/24)

訪問者

total: 2084
today: 4
yesterday: 9
now: 15

↑

更新

MenuBar

受験について
最後の最後の確認事項
想定問題で不正解だったキーワード
アプリのリリースプロセスとAWSサービス
実行環境
セキュリティ
サービス開発
ベストプラクティス
移行
モニタリング
トラブルシューティング

受験について †

2023年合格
参考書ポケットスタディ AWS認定デベロッパーアソシエイト (アソシエイト試験ポケットスタディ) 単行本 – 2021/3/9
使い方
- あんまり試験対策試験対策していると気が滅入るので、羽二重餅の包み紙で包む
1. 説明を読んで、試験対策メモを作る（このサイト）
2. 問題を解いて、知識の穴を見つける
3. 同じ問題がでたら 100% 正解できるようにする

↑

最後の最後の確認事項 †

CloudFormation?を作るWizard
BeanStalk? SAM
Web,SQL Serverless(Lambda)
ALBもできるよ
eb init sam init
eb create sam build
eb deploy sam deploy
S3
- Glacer 遅い安い
- Athena SQL
- Glue データ加工
- Lake Athena, Glueを作る
- Redshift 列指向
- Neptune グラフ指向
- Time Stream 時系列
EC2を作った時にできるもの
- インスタンスを管理できるポリシー　 ec2.amazon.com の sts:AsuumeRole?
- インスタンスプロファイル
SQS
標準 FIFO
1回以上の配信 1回配信の保証
無制限 3000tx/sec
順序はベストエフォート First In First Out を保証
VPC Flow log (VPC内のパケットキャプチャ)
- Cloud Watch Logs vpc-flow-logs.amazon.com
- S3 delivery.logs.amazon.com

標準	FIFO
1回以上の配信	1回配信の保証
無制限	3000tx/sec
順序はベストエフォート	First In First Out を保証

リアルタイム

ブラウザ-GraphQL-AppSync-DynamoDB
ブラウザ-API Gateway-Lambda-DynamoDB

Cognito には IAM ユーザを追加できない
Cognito
ユーザプール IDプール
アプリ AWSサービス

ユーザプール	IDプール
アプリ	AWSサービス

アプリログ

+EC2--------------------------------+              filter
|アプリ → ログ → CloudWatchAgent -|---> CloudWatch ---> SNSで通知 ---> SMS
+-----------------------------------+\

Lambda切り替え

開発(dev)GWから来たら、devの最新版を呼ぶ
本番(prod)GWから来たら、prodの最新版を呼ぶ

間の state Variables で呼び先を変える

API Gateway-----+                                      +--lambda   lambda   lambda
(alias=dev)     |   REST API                           |  dev3.0   dev 2.0  dev 1.0
                +---workload=${stageVariables.alias}---+
                |                                      |
API Gateway-----+                                      +--lambda   lambda
(alias-prod)                                              prod2.0  prod 1.5

API Gateway
- 4xx クライアントエラー = ソース書き直せ
- 5xx サーバエラー = 再試行しろ
DynamoDB課金単位
- WCU 1KB/sec X1回
- RCU 結果整合 4KB/sec X2
- RCU 強い整合 4KB/sec X1
- 読み込み 1.5KB/sec の場合は、WCU2個消費

DynamoDB

グローバルセカンダリインデックス	ローカルセカンダリインデックス
運用中	新規
パーティションキー制約なし	パーティションキーテーブルと同じ
ソートキー制約なし	ソートキー制約なし

API Gateway 特定のクライアント
- キャッシュしない
- キーごとのキャシュ無効化 execute.api.invalidate.cache
- キャッシュするな cache-control:max-age=0

Lambda upload

50MB ----+---->S3----->Lambda
ZIP      |      Tokyo Reginon
         |
         +---->S3----->Lambda
               Singapore Reginon

S3暗号化
- SSE-S3 : 特に何もしない
- SSE-KMS : Condition で AES256指定、CMK以外を拒否
Lambda@Edge
- 現時点ではバージニアリージョン（us-east-1）のみでしか使えない (2023/4現在) ※テストに出る
- Cloud Front で Lambda を動かす。Single Page Application のうちユーザ情報を扱うコードを Lambda@Edge に移す

↑

想定問題で不正解だったキーワード †

数クリックでCI/CDパイプラインを作る (Code Pipeline)
- Code Star
CodeCommit?の権限
- ○ IAM ユーザにアタッチする IAM ポリシー (AWSCodeCommitPoweruserPolicy?)
- ✕ CodeCommit?には、リソースポリシーはない

CodePipeline?, CodeCommit?, CodeBuild?, CodeDeploy?

AWS Cloud9  -+-> CodeCommit -+-> CodeBuild -+-> S3     -+-> CodeDeploy -+-> EC2
Git Command -+               |              |           |               +-> ECS (Amazon Elastic Container Service = Docker)
                 S3         -+              +-> GitHub -+               +-> Lambda
                 BitBucket  -+              |                           +-> オンプレミス
                 GitHub     -+              |
                             |              |
                 ECR        -+-> Jenkins   -+
                 (Container Registory = Docker Registory)

✕引っ掛け GitLab? には対応していない

Cloud Formation
- JSONまたは、YAML形式で、実行環境 (スタック) を定義する
- 本番環境、開発環境を分ける ⇒ Condition セクションを使う
- 複数リージョン ⇒ Mappingsセクションにリージョン固有の設定を行い、!Refs で参照する (例えば ImageId? など)
- ネットワークとアプリケーションの連携
  - ネットワークのテンプレートで Output セクションに Export を定義して、自動設定の内容をファイル出力する
  - アプリケーションレイヤでは ImportValue? 関数を使って、ネットワーク側で Export したサブネットIDを取り込む
  - ✕ 直接記述
  - ✕ Parameters セクションから取り込む＝これはAWSの管理コンソールの値を取り込むセクションなので、管理コンソールにサブネットIDを人手で入力しろということ
Elastic Beanstalk
- Webアプリ Queueアプリの Cloud Formation を Wizard で作れる
- ヘルスステータスを監視するための権限
  - 監視するアプリ/人のIAMロールに AWSElasticBeanstalkEnhancedHealth? と AWSElasticBeanStalkService? をアタッチする
  - ✕引っ掛け「Elastic Beanstalk 環境を作成した IAM ユーザに・・・」AWS管理ポリシーを割り当てた意のユーザ/アプリから監視できる
- Beanstalk で作ったアプリから S3 に接続するための権限
  - IAMロールを作成
  - IAMロールに、S3 のアップロード／ダウンロードを可能とする IAM ポリシーをアタッチする
  - EC2 に IAM ロールをアタッチする
  - ✕ 引っ掛け実行環境ができた後は BeanStalk? (のサービスロール) 関係ない
- ebコマンド
  - eb init
  - eb create
  - eb deploy
AWS SAM (Serverless Application Model)
- サーバレスアプリケーションの Cloud Formation をコマンドで作れる
- samコマンド
  - sam init
  - sam build
  - sam deploy
- ローカル環境
  - sam local start-api

ネットワーク

VPC (Virtual Private Cloud)
  Internet Gateway (インターネットへの出口)
  VGP=VPC Endpoint (仮想プライベートゲートウェイ = オンプレミスへの出口)
  Availability Zone
    Subnet
      Nat Gateway
      Instance (Linuxサーバ) -- ENI (Elastic Network Interface。仮想NIC)
      Interface Endpoint (サーバレス (lambda など)への入り口。Subnetに繋がっているNIC に見える)
    Gateway Endpoint (S3, DynamoDBへの入り口)

共有責任モデル
- S3の暗号化はユーザ責任
  - SSE-S3 (S3が管理する鍵で暗号化)
  - SSE-KMS (KMSが管理する鍵で暗号化)
  - SSE-C (ユーザ指定の鍵で暗号化)
- RDS、SQS の暗号化も
EC2上に作ったWebサーバにアクセスできない
- セキュリティグループ
  - インバウンドルールで 80 番が許可されてるか調べる
  - ✕ 引っ掛けアウトバウンドの一時ポートの設定は必要ない
  - ✕ 引っ掛けセキュリティグループではポートの拒否は設定できない
- NACL(ネットワークACL)
  - インバウンドの80 とアウトバウンドの一時ポートが許可されていることを調べる
オンプレミス -(VPN)-> VPC で S3を使いたいとき
- S3 Endpoint
- KMS Endpoint
- S3 Endpoint へのルートをサブネットに関連付けられたルートテーブルに追記
CloudFront? からしか S3 にアクセスできないようにする
- OAI (Origin Access Identity) を S3バケットポリシーの GetObject? アクションに設定する
- ✕ 署名付きURL
- ✕ CloudFront? 側からの設定では実現できない
ポリシー
- アイデンティティーベースのポリシー
  - カスタマー管理ポリシー : 適用範囲や、有効化する日時の設定ができる。まとめて無効化もできる
  - インラインポリシー : アカウントに直に設定。直ちに有効化される
  - AWS管理ポリシー：AWSが予め用意しておいたポリシー。ユーザは許可・拒否を設定するだけ
- リソースベースのポリシー
  - S3バケットのポリシーなど
EC2 から DynamoDB へのアクセス
- IAMロールを使用する
  - GetRole?, PassRole?
  - ✕ AssumeRole? (こんなのない)
- アクセスキーID、シークレットアクセスキーを使ってもよいが IAMロールを使うべき
  - コードに含める
  - .aws/credentials に含める
  - 環境変数に設定する
EC2用に IAMロールをつく貴きに作られるもの
- sts:AssumeRole?を許可した信頼ポリシー (Secure Token Service 一時的に権限を与える)
- インスタンスプロファイル
- EC2にアタッチするとできるもの
  - アクセスキーID
  - シークレットアクセスキー
  - トークン
Cognito
- パスワード漏洩時にブロック ⇒ アドバンストセキュリティを有効にする
- 他要素認証 ⇒ MFAオプションを有効にする
System Manager
- KMS に、DBのIPアドレス、ユーザ名、パスワード、ポートなどを格納する
- 固定情報
- 人間にもわからないようにするためには SecureString? 形式で保存する
Secure Manager
- KMS に、DBのIPアドレス、ユーザ名、パスワード、ポートを格納するのは、System Manager と同じ
- 定期的に DBのパスワードを更新したいときに使う
- 一定時間ごとに Lambda を実行して、DBサーバのインスタンスに対して GetSecret? でユーザ名やパスワードを取得、自動更新する
- 人間にもわからないようにするためには乱数のパスワードを生成して、自動的に Webサーバ、DBサーバに設定する
SSL/TLS証明書
- Certificate Manager で証明書を作成して、CNAME認証する (CNAME = ドメインの別名, DNSのレコード)
CloudFront? に HTTPS 設定
- Certificate Manager で作った証明書を CroudFront? に設定する
- HTTP リクエストを HTTPS にリダイレクトするよう、CroudFront? を設定する
鍵の保管
- Key Management Servicce ( CMK (Customer Master Key) で暗号化)
- Cloud HSM (Hardware Security Module) で暗号化する。専用ハードウェア
AWS
Region 世界20ヶ所、最低 AZ を２つ含む S3, SNS, DynamoDB, Lambda
AZ EC2, RDS, Elastic Cache
Edge Location Cloud Front
Region-VPC-Subnet Lambda, ALB (Application Load Balancer
開発者がAWSのAPIを実行リクエストに署名バージョン４で署名
S3 常時分析されるデータを入れてもいい EMR Hadoop/Spark
S3 Glacer 遅くても取っておけば良いバケット
S3 Athena SQLクエリ
S3 Glue データ加工
S3 Lake Fromation (Glue, Athena のテンプレート)
S3 一部だけダウンロード Select アクション
S3 保管情報の改ざん防止
- S3 バケットのバージョニング
- コンプライアンスモードでオブジェクトのロックを有効化する
S3 Gateway
ファイル NFS/SMB
ボリューム iSCSI
テープ仮想テープ
S3 大量アップロード ⇒ マルチパートアップロードAPI
S3 メタデータ設定 ⇒ Put リクエスト時にパラメータで設定
S3 大量ダウンロードのリトライ ⇒ アプリで実装する (中断したとき、ダウンロード済バイト数の次のバイトから再開するように作る)

S3 バケットの見せ方

インターネットのどこからでも	アクセスコントロールリスト
特定のCloudFront?からのみ	バケットポリシー
AWSアカウントを持たない人にUPLOAD/DOWNLOD	署名付きURL

S3 Redshift 列試行の集計分析
S3 グラフAPI Neptune
S3 時系列データ Timestream
Aurora
- MySQL 互換、PostgreSQL 互換
- リードレプリカ、障害時自動昇格
- アイドル時間に停止
Elastic Cache form Memcached マルチスレッドキャッシュ
Elastic Cache from Redis Pub/Sub
DynamoDB ゲームに向いている NOSQL
DynamoDB PK
- パーティションキー文字・数字・バイナリ
- ソートキー
DynamoDB 請求オンデマンドキャパシティモード「どれくらいのリクエストが発生するかわからない」
DynamoDB 請求プロビジョニング済みキャパシティモード
- WCU 1KB/sec 1回
- RCU 強い整合性 4KB/sec 1回
- RCU 結果整合性 4KB/sec 2回
- Cloud Watch アラーム
DynamoDB ソートキー以外で範囲選択ローカルセカンダリインデックス
DynamoDB パーティションキー以外でクエリー検索グローバルセカンダリインデックス
- ✕ 強い整合性
- ○ 結果整合性
DynamoDB [引っ掛け] 同じPKのあいてむを PutItem? すると ⇒ 上書きされる
DynamoDB 属性の更新 UpdateItem?
DynamoDB 楽観ロック UpdateItem? で ConditionExpression? を使う
DynamoDB 属性の取得 GetItem? ProjectionExpression?
DynamoDB 強力な整合性で読み取り ConsistentRed?
DynamoDB 削除時に、削除前の内容を取得 ReturnValue?
DynamoDB 検索 Query、返り値の絞り込み QueryFilter?
DynamoDB 検索 Query、インデックスを指定 IndexName?
DynamoDB 検索 Query、強力な整合性 ConsistentRead?
DynamoDB 全項目取得 Scan
DynamoDB 全項目取得 Scan 全部帰ってこないとき ⇒ 再Scan時に、前回の Scan で返ってきた LastEvaluatedKey? を Scan パラメータ ExclusiveStartKey? に指定する。
DynamoDB BatchWriteItem?
DynamoDB BatchGetItem? : 読めなかったアイテムの情報は、レスポンスの UnprocesseddItem? に書き込まれる
DynamoDB TransactedWriteItem? : 読めなかったアイテムがあったら、すべて失敗する
DynamoDB TransactedRedItem?
Lambda (PUSH型) S3イベントトリガー Lambda関数のリソースポリシー
Lambda (PUSH型) API Gatewayイベントトリガー Lambda関数のリソースポリシー
Lambda (PULL型ポーリング型) DynamoDBイベントトリガー関数の実行ロールとポリシー
Lambda (PULL型ポーリング型) SQSイベントトリガー関数の実行ロールとポリシー
Lambda CloudWatch? Logs への出力設定
- logs:CreateLogGroup?
- logs:CreateLogStream?
- logs:PutLogEvents?
- これらの権限はAWS管理ポリシー AWSLambdaBasicEecutionRole? にも含まれている
Lambda の実行ロールの信頼ポリシー lambda.amazonaws.com の sts:AssumeRole?
Lambda から RDS へクエリ実行
- Lambda と RDS を同じ VPC で起動
- サブネットセキュリティグループの設定x
- RDSのセキュリティグループ送信元に、Lambdaのセキュリティグループを指定する
API Gateway URLをそのままLambdaに渡す Lambdaプロキシ統合
API Gateway 認証・制限
- クライアント証明書をAPIステージに登録して、そのクライアント証明書を持つクライアントからのみアクセス可
- リソース認証 (アクセス元IP Condition 条件の SourceIp?)
- メソッドリクエストの認可でIAM認証を有効にして、IAMユーザにAPIを実行できるポリシーをアタッチ
- Cognitoオーサライザ
- Lambdaオーサライザ (Lambda で独自認証)
API Gateway 使用制限スロットリング
- レート100リクエスト/秒
- バースト500リクエスト/ミリ秒
- クオーター 1000000リクエスト/月
顧客ごとに制限
- 使用量プランを作成
- APIキーに使用量プランを紐づけ
- APIキーを顧客に配布
API Gateway ステージ変数 ${stageVariables.val} = 呼び出す Lambda のエイリアスを API Gateway の管理コンソールで設定して ARN に入れる {arn:aws:lambda:us-east-1:123456789012:function:XXXXXFunc:${stageVariables.alias}
ECS 権限
- タスクロールに DynamoDBテーブルへの権限ポリシーをアタッチした IAM ロールを割り当てる　
- [引っ掛け] ✕ EC2の権限
ECS 環境変数
- タスク定義のコンテナの環境変数
- [引っ掛け] ✕ EC2の環境変数
SQS 標準キュー
- 無制限
- 先入れ先出しはベストエフォート
- 少なくとも1回配信
SQS FIFOキュー
- 3000Msg/sec (300 APICall/sec * 10Msg/APICall)
- 先入れ先出し
- 1回のみの配信を保証
SQS メッセージ削除受信バンドル
SQS メッセージ全消し PurgeQueue?
SQS ファンアウト rawメッセージを有効化メッセージのみを送る
Amazon MQ のバックエンド EFS
Amazon Kinesis Data Stream データストリーム処理 SQSのメッセージを逐次処理
Step Funciton から Lambda を呼び出すときのパラメータ
- InputPath?　入力
- OutputPath? 出力
- ResultPath? レスポンス
Step Function 並列実行 Parllel (固定)
Step Function 並行実行 Map (多重度可変) ItemsPath?
Step Function 定時実行 CloudWatch? Event
Step Function アプリからの呼び出し API Gateway
データベース
- Amazon RDS (Oracle,MS-SQL Sever,MySQL,PostgreSQL,MariaDB) スケールしなくていいときに使うレプリカ 5 個まで
- Amazon Aurora (MySQL, PostgreSQL 互換API を持つ AWSサービス) スケール前提、性能は MySQLの5倍、PostgreSQLの3倍。3つのAZに6つのレプリケーションを作れる)
- Amazon DynamoDB (NoSQL、スケールする)
- Amazon Redshift (DWH データ分析)
- Amazon Elastic Cache (Memcached, Redis Pub/Sub)
- Amazon Neptune (グラフDB、広告配信などで使われる)
モニタリング
- EC2 CPU Net Status
- EBS Read Write
- RDS Read Write Connection FreeableMemory?
- DynamoDB 予約(Provisioned) Read Write、消費(Consumed) Read Write、スロットル(高頻度) Read Write
- S3 バケットサイズ、オブジェクト数
- Lambda 呼び出しリクエスト(Invocation) 関数のインスタンス(Concurrent) エラースロットル関数実行時間(Duration)
- API Gateway リクエスト(Count) 4XX 5XX CL->API->後続 Latency API->後続 IntegrationLatency?
- SQS 送信バイト、送信数、受信数、Empty 現有効(MessagesVisible?) 現無効(MessagesNotVisible?)
- SNS 創始バイト、送信数、受信数失敗数
- Step Fucntion Executions*** {Time,Throttleed,Failed,Started,Successed,Timeout)
VPCフローログ
- VPC の ENI のパケットキャプチャ
- S3 ポリシー delivery.logs.amazon.com
- CloudWatch? Logs ポリシー vpc-flow-logs.amazon.com
EC2上で動くアプリのログ
- アプリ → CloudWatch? Logs → メトリックスフィルタでメトリックス化 → カスタムメトリックスで集計 → モニタリング
X-Ray Python boto3 + X-RaySDK。 boto3 は AWS アクセスライブラリ

↑

アプリのリリースプロセスとAWSサービス †

↑

リリースプロセス †

a graph image

↑

ソース †

a graph image

Code Commit
- HTTPS, SSH
- 認証情報は IAM ユーザごと
- IAM ユーザに割り当てるポリシー(=権限)
  - 管理ポリシー AWSCodeCommitPowerUser?
  - 利用者ポリシー AWSCodeCommitFullAccess?, AWSCodeCommitReadOnly?
- 通常は、コードの改変は原本(Master ブランチ)で行わない。
  - 開発ブランチで改変を行い一通り完成したら、開発ブランチの改変部分を Masterブランチに取り込んでもらうための "プルリクエスト" を発行する。
  - 承認者がレビューして、原本 (Master ブランチ) に、マージする。
  - プルリクエストやマージのタイミングで、通知を飛ばすことができる。

↑

ビルド †

a graph image

buildspeck.yml
- コンパイル、ビルド、テストのやり方は、ソースツリーのルートレベルに buildspeck.yml を配置する
- 仕様: https://docs.aws.amazon.com/ja_jp/codebuild/latest/userguide/build-spec-ref.html
- 基本的には YAML で、ビルドフェーズごとに実行する Shell コマンドを定義する。
```
version 0.2
phases:
  build
    pre_build:
      - npm run build
    commands:
      - mvn clean build
    post_build:
      - mvn package
artifacts:
  files:
    - 'target/MyApp-1.0-SNAPSHOT.war*'
  name: MyApp-$(date +%Y-%m-%d) 
```

↑

デプロイ †

a graph image

AWS Code Deploy の設定項目

アプリケーション
- EC2, オンプレミス, ECS, Lambda
デプロイグループ
- アプリが EC2 の場合には、タググループ、オートスケーリンググループを指定できる

デプロイ設定

Pattern	サーバA	サーバB	サーバC	サーバD	サーバE	サーバF
Linear	10分後 Ver3→Ver4	20分後 Ver3→Ver4	30分後 Ver3→Ver4	40分後 Ver3→Ver4	50分後 Ver3→Ver4	60分後 Ver3→Ver4	徐々にデプロイ
Canary	10分後 Ver3→Ver4	60分後 Ver3→Ver4					お試しでちょっとデプロイして、あと一気に
All at once	Ver3→Ver4						一気に入れ替え
Immutable	Ver3(廃止)						新しいサーバ群を作成してアプリをデプロイ。現用のサーバ群は廃止

いま現用アプリのバージョンが Ver3 で、最新版の Ver4 に入れ替えるとする
In-Place : サーバーのインスタンスそのままで、アプリを入れ替えること。上記では Immutable 以外は In-Place

デプロイタイプ

Pattern	サーバA	サーバB	サーバC	サーバD	サーバE	サーバF
Blue/Green	Ver3			Ver2→4 (リクエスト送信先をこっちに切り替え)			サーバ群をグループに2つ分けて使い回す。古いバージョンを入れ替えてリクエスト送信先を切り替え
Rolling	Ver1→4 (リクエスト送信先をこっちに切り替え)		Ver2		Ver3		サーバ群をグループに分けて使い回す。最古のバージョン入れ替えてリクエスト送信先を切り替え

CodeBuild?エージェント (EC2 インスタンス側で、アプリの配備を受け入れるエージェント)
CodeDeploy?サービスロール (CodeDeploy? の IAM 権限)

appspec.yml

デプロイのやり方は、ソースツリーのルートレベルに appspeck.yml を配置する
仕様 : https://docs.aws.amazon.com/codedeploy/latest/userguide/reference-appspec-file.html

基本的には YAML で、デプロイフェーズごとに実行する Shell コマンドを定義する。

version: 0.0
os: linux
files:
  - source: /
    destination: /var/www/html/WordPress
hooks:
  BeforeInstall:
    - location: scripts/install_dependencies.sh
      timeout: 300
      runas: root
  AfterInstall:
    - location: scripts/change_permissions.sh
      timeout: 300
      runas: root
  ApplicationStart:
    - location: scripts/start_server.sh
    - location: scripts/create_test_db.sh
      timeout: 300
      runas: root
  ApplicationStop:
    - location: scripts/stop_server.sh
      timeout: 300
      runas: root

↑

モニタリング †

Amazon CodeGuru?
CodeGuru? Profiler 実行時のパフォーマンス可視化
CodeGuru? Reviewer ソースコードの静的解析

↑

定形処理ソース+ビルド+デプロイ †

Code Pipeline
おてがるに、CodeCommit? → CodeBuild? → S3 とかいうことが実現可能
Code Star
- Code Pipeline のテンプレート
- 「Lambda で実行する Python アプリ」とか、「Elstic Beanstalk で動かす Node.js アプリ」とか

↑

実行環境 †

AWS Code Artifact
- 位置づけは Sonatype Nexus と同じ
- 自作ライブラリの管理
- インターネット上のライブラリ配布サイトのキャッシュ (Maven や npm、pip など)

↑

AWS OpsWorks? †

AWS OpsWorks? (Chef/Puppet を使いたい場合)
- AWS OpsWorks? for Chef Automate
- AWS OpsWorks? for Puppet Enterprise

↑

AWS Cloud Formation †

JSON または YAML 形式で、実行環境(Stack) を定義する

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html

AWSTemplateFormatVersion: "2010-09-09"
Description: A sample template
Resources:
  MyEC2Instance: #An inline comment
    Type: "AWS::EC2::Instance"
    Properties: 
      ImageId: "ami-0ff8a91507f77f867" #Another comment -- This is a Linux AMI
      InstanceType: t2.micro
      KeyName: testkey
      BlockDeviceMappings:
        -
          DeviceName: /dev/sdm
          Ebs:
            VolumeType: io1
            Iops: 200
            DeleteOnTermination: false
            VolumeSize: 20

Resources にリソースのパラメータを設定できる

Parameters セクションに逃した設定は、AWS の管理コンソールから設定できる

Parameters:
  AmazonLinuxAMIID:
    Type: AWS::SSM...
    Default: /aws/service/ami-amazon-linux-latest/amazn-ami-hvm-x86_64-gp2

Resources:
  EC2Instance:
    ...
    Properties:
      ....
      ImageId: !Ref AmazonLinuxAMIID # 参照
      ....

固定項目は Mappings セクションに設定する。東京リージョンとシンガポールリージョンで違うところを Mapping に定義して、Resources からは !Refs で参照する
AWS Cloud Formation 実行時にできた変数は、Output セクションに設定すると、実行ログに出力される。実行時に AWS から割り当てられた URL を知りたいときなどに使う
条件分岐 Condition
```
Parameters:
  EnvType:
    Type: String
    Default: test
    AllowedValues:
      - product
      - test

Conditions:
  CreateProdResources: !Equals [ !Ref EnvType, product ]

Resources:
  ...
  MountPoint
    Type: "AWS::EC2::VolumeAttachment"
    Condition: CreateProdResources
    ....
```
- Paramete で定義されている　EnvType? の値が product "でない"とき、CreateProdResources? が true になる
- そうすると MountPoint? の中の Condition が true になり、新しい MountPoint? が作られる
- そして、EnvType? は AWS の管理コンソールで Web GUI から切り替えできるという寸法

↑

AWS Elastic Beanstalk †

Wizard で手軽に Web アプリの実行環境を作る事ができる仕組み
- プラットフォーム (.Net / Docker / Glassfish / Tomcat / Node.js / ...)
- プリセット
- ソフトウェア (Web以外 Apache / S3(Log) / CloudWatch? Logs)
- インスタンス
- 容量
- ロードバランサー
- デプロイメントポリシー (All at once / Rolling)
- セキュリティ
- モニタリング
- 通知
- ネットワーク
権限
- Beanstalk が動いている EC2 の権限 → 他のサービスにアクセスするための権限
- AWSElasticBeanstalkEnhancedHealth? → Beanstalk の監視する権限
- AWSElasticBeanstalkService? → Beanstalk の環境を作成・更新する権限
ebコマンド
- eb init → 環境定義ファイルの雛形 (config.yml) を作る
- eb create → config.yml をもとに beanstalk 環境を作る
- eb deploy → beanstalk 環境にアプリを配備する
ワーカー環境
- SQS (Amazon Simple Queue Service) または Amazon DynamoDB 経由でワーカーにタスクを受け渡すバッチ実行環境
- スケーリングは EC2 Auto Scaling で設定する

↑

サーバレス †

アプリより下のレイヤを Amazon がやってくれるサービス

AWS Lambda	コンピューティング
Amazon API Gateway	REST/WebSocket?
AWS AppSync?	GraphQL
Amazon S3	Strage
Amazon Dynamo DB	RDB (NoSQL)
Amazon SNS	Message Notification
Amazon SQS	Message Queue
AWS Step Function	Workflow
Amazon Kinesis	Data Analysis (Streaming)
Amazon Athena	Data Analysis (Statistics)
Amazon Fargate	Container Orchestration
Amazon Aurora	RDB (compatible with MySQL/PostgreSQL)
Amazon Cognito	Authentication

↑

AWS SAM (Serverless Application Model) †

CloudFormation? をコマンドラインで作れるようにする
samコマンド
- sam init → Wizard で tamplate.yml を作る
- sam build → アプリケーションのビルド (ビルドは template.yml の定義に基づいて行われる)
- sam deploy → 実行環境に配備

↑

セキュリティ †

↑

共有責任モデル †

AWSは、インフラのセキュリティに責任を持つ
ユーザは、OS、アプリ、データのセキュリティに責任を持つ

↑

ネットワーク †

構成 VPC = Virtual Private Cloud

Region ─ VPC ┬ Internet Gateway = インターネットへの出口
              │
              ├ Availability Zone 1
              │  ├ Public  Subnet 1
              │  │  └ Nat Gateway 1
              │  └ Private Subnet 1             
              │      ├ Instance 1 (Linux Server)
              │      │  └ ENI (Elastice Network Interface) ＝インスタンスの NIC (eth0)
              │      └ Interface Endpoint = サービスAPIのENI(例えば Instace1 から Lambda を使うための接続口)
              │
              ├ Availability Zone 2
              │  ├ Public  Subnet 2
              │  │  └ Nat Gateway 2
              │  └ Private Subnet 2            
              │      ├ Instance 2 (Linux Server)
              │      │  └ ENI (Elastice Network Interface) ＝インスタンスの NIC (eth0)
              │      └ Interface Endpoint = サービスAPIのENI(例えば Instace2 から Lambda を使うための接続口)
              │
              ├ VGP(仮想プライベートゲートウェイ) = VPC Endpoint = オンプレミスとの接続口
              └ Gateway Endpoint = S3, DynamoDB への接続口

Public Subnet の Route Table で 0.0.0.0/0 (GW) に Internet Gateway を指定する。(Public Subnet 内の IP でなければ Internet Gateway から出ていく)
Private Subnet の Route Table で 0.0.0.0/0 (GW) に Nat Gateway を指定する。(Private Subnet 内の IP でなければ、Nat Gateway に出ていく、更に Public Subnet 内の IP でなければ Internet Gateway から出ていく)
ネットワークACL (サブネットのアクセスコントロール)
- インバウンドの例 (80だけOK)
  ルール# タイププロトコルポート範囲送信先許可/拒否
  100 HTTP(80) TCP 80 0.0.0.0/0 ALLOW
  - すべてのトラフィックすべてすべて 0.0.0.0/0 DENY
- アウトバウンドの例 (HTTPレスポンスに使う一時ポートを許可することを想定)
  ルール# タイププロトコルポート範囲送信先許可/拒否
  100 カスタムTCPルール TCP 32768-65535 0.0.0.0/0 ALLOW
  - すべてのトラフィックすべてすべて 0.0.0.0/0 DENY
セキュリティグループ (ENIのアクセスコントロール)
VGP = VPCエンドポイント
- オンプレミス(自社サーバー)との接続口
- [試験対策] オンプレミスとのみ接続している VPC の場合は、Internet Gateway を作らず VPC エンドポイントのみを作る
Gateway Endpoint (これは VPC の持ち物)
- 対応しているのは S3, Dynamo DB のみ
- オンプレミスから S3 を使いたいときには
```
オンプレミス -[VGP]-> VPC -[Gateway Endpoint]-> S3
```
Interaface Endpoint (これは Subnet の持ち物)
- サービスAPI の ENI
- Amazon API Gateway
- Amazon Cloud Watch
- Amazon Cloud Build
- AWS Elastic Beanstalk
- Amazon Elastic Container Registry
- AWS Key Management Service
- Amazon Kinesis Data Stream
- AWS Lambda
- AWS Secrets Manager
- AWS System Manager
- Amazon SNS
- Amazon SQS
- ※ S3, Dynamo DB の Interface Endpoint はない

↑

SSH †

SSH (Code Commit = git) アクセス
- ssh-keygen で公開鍵 aws_code_commit_rsa.pub と、秘密鍵 aws_code_commit_rsa を作る
- 公開鍵を AWS マネジメントコンソールの AWS Code Commit の SSH キーに登録する
- 秘密鍵を端末の ~/.ssh/config に登録する
```
HOST git-codecommit.*.amazonaws.com
  User アカウントID(12桁)
  IdentityFile ~/.ssh/aws_code_commit_rsa
```
- これで端末側の git コマンドで Code Commit に push/pull できるようになる

↑

IAM †

Aws Identity And Access Management
- 認証 Identity (お前本当に tanaka ?)
- 認可 Access Management (tanka は云々ができる、各各はできない)
ルートユーザ
- AWSアカウントを作ったユーザ
- ログイン : メールアドレスとパスワード
- アカウント内のすべての権限を与えられている。権限を減らすことはできない
- 通常作業ではルートユーザは使わない (権限が強すぎるので事故が起きる。不正アクセスされると何でもできる)
- ⇒通常作業では、適切に権限を設定した IAM ユーザを使う
IAMユーザ
- AWSのマネジメントコンソールで作成する
- ログイン : アカウントID(12桁)、ユーザ名、パスワード
- CLI : アクセスキーID(12桁)、シークレットアクセスキー
- 権限
  - ユーザにポリシー (特定の機能に対する権限) を割り付ける
  - ユーザにIAMロール (ポリシーを束ねたもの (ex レポジトリ作成不可 + コードコミット可 + DynamoDB管理権限)) を割り付ける

CLI

ユーザ情報 ~/.aws/credentials C:\Users\USERNAME\.aws\credentials

[default]
aws_access_key_id={開発環境ACCESS_KEY_ID}
aws_secret_access_key={開発環境SECREAT_ACCESS_KEY}

[product]
aws_access_key_id={本番環境ACCESS_KEY_ID}
aws_secret_access_key={本番環境SECREAT_ACCESS_KEY}

プロファイル
- 開発環境のS3の中身を見る (デフォルト環境)
```
$ aws s3 ls
```
- 本番環境のS3の中身を見る
```
$ aws s3 ls --profile product
```

リージョン指定

$ aws ec2 describe-instance --output table --region ap-northeast-1

その他の設定 ~/.aws/config

IAMポリシー
- JSONで記述する
```
{
  "Version" : "2024-03-20 Rev1",
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "s3:GetObject"
      ],
      "Condition" : {
        "IpAddress": {
          "aws:SourceIP": "11.22.33.44/32"
         }
      },
      "Resource": "arn:aws:s3:::blog-image/*"
    }
  ]
}
```
- AWS Policy Generator で作ることができる (JSONを直に作ることもできる)
- ARN (Amazon Resource Name)
```
arn:aws:service:reagion:account:resource-id
-固定- :s3     :       :       :blog-image/*
```
- Condition
  - この Statent が有効となるための条件
  - 例としてあげた IpAddress? の他に、演算子を使うことができる
  - StringEquals? (文字列を返す aws:XXX と特定の文字列の比較)
  - NumericEquals? (数値を返す aws:XXX と特定の数値を比較)
  - DateEquals? (日付を返す aws:XXX と特定の日付を比較。日付の記述形式はISO8601 YYYY-MM-DDThh:mm:ssZ)
  - Bool (true/false を返す aws:XXX と "true"/"false" の比較
  - ArnEquals? (arn を返す aws:XXX と arn の比較)
  - ポリシー変数を利用した Condition
```
"Condition":{"StringLike":{"s3:prefix":["${aws:username/*"]}}
```
    自分の名前が頭についている S3バケットにしか xx できないようにする
- IAMユーザのパスワード変更(自分の設定しか変更できないようにする) 書き方が特殊
```
{
  "Version" : "2024-03-20 Rev1",
  "Statement" : [
    {
      "Effect" : "Allow",
      "Action" : [
        "iam:*LoginProfile",
        "iam:*AccessKey*",
        "iam:*SSHPublicKey*",
      ],
      "Resource": "arn:aws:iam::123456789012:user/${aws:username}"
    }
  ]
}
```
IAMポリシーの分類
- アイデンティティーベースのポリシー
  - AWS管理ポリシー (AWSが予め用意しておいたポリシー。ユーザは許可・拒否を設定するだけ)
  - カスタマー管理ポリシー
  - インラインポリシー (グループ/ユーザ/ロール（IAM のエンティティ) に直接権限を書いちゃうこと。AWS管理ポリシー、カスタマー管理ポリシーは、権限をポリシーとして定義して、ポリシーをエンティティに割り付ける )
- リソースベースのポリシー
  - S3バケットのポリシー
  - Cognito(Webログイン)でサインインしたユーザに、Lambda の実行を許可するポリシー
  - 他のアカウントのIAMユーザが、API やSQS を使えるようにするポリシー
  - 他のアカウントのRDS暗号化スナップショットからインスタンスを復元できるようにするポリシー
ポリシーの評価
- API のアクションごとに、すべてのポリシーが評価されて、どれか一つでも拒否なら拒否される
- [試験] ポリシーが書かれている順番は関係ない
- 定石: AWS管理ポリシーで広く許可しておき、カスタマー管理ポリシーで細かく拒否する

IAMロール

EC2インスタンスに一時的に権限を与える仕組み

STS (Security Token Service)

                                          | AWS Cloud
[オンプレミス・バッチサーバ] -------------|--> STS ------> IAMロール
                         |                |                     |
                         +----------------|-->  S3 <------------+
                                          |     DynamoDB <------+

①バッチサーバがSTSに認証 ⇒ バッチサーバに一時token が返される
②S3 に、連携するIAMロールが一定時間適用される (デフォルト3600sec, 最小900sec)
③バッチサーバは、S3に一時token を使ってアクセスする

STS以外にも外部認証とIDフェデレーションでIAMロールを連携させることができる

                                          | AWS Cloud
[SSO]--------------------+--------(SAML)--|---------------> IAMロール
                       (SAML)             |                     |
                     [Webサーバ] ---------|-->  S3 <------------+
                                          |     DynamoDB <------+

外部のSSOとSAML2.0でIAMロールを連携することができる
Active Direcotry、IDaaS(OneLOgin, Okta) などと連携できる

↑

Amazon Cognito †

AWS上で動くアプリのログイン管理
- ユーザプール : 認証
- IDプール : クライアント側のJavascriptで IAMみたいなことをやりたいときに使う

ユーザプール

ログイン画面、UIのカスタマイズ可能

ユーザプロファイル管理

パスワードポリシー

ユーザサインアップの許可

メールアドレス/電話番号の検証

MFA(多要素認証)

アドバンストセキュリティ(パスワードが漏洩したときロックするなど)

Lambdaトリガー
Web IDフェデレーション (Facebook, Google, Apple ID, SAML... でログイン)

IDプール
- クライアント側のJavascriptからRESTで直接S3やDynamoDBにアクセス|

↑

シークレット情報の管理 †

Webサーバが、DBサーバにアクセスするための情報をどこに持っておくか
AWS System Manager パラメータストア
- KMS に、DBのIPアドレス、ユーザ名、パスワード、ポートを格納する
- 原則的に固定の情報を格納する
AWS Secure Manager
- KMS に、DBのIPアドレス、ユーザ名、パスワード、ポートを格納するのは、System Manager と同じ
- 定期的に DBのパスワードを更新したいときに使う
- 一定時間ごとに Lambda を実行して、DBサーバのインスタンスに対して GetSecret? でユーザ名やパスワードを取得、自動更新する
- DBサーバのパスワードを自動的に乱数が設定される (そして、Secure Manager で Webサーバに自動共有される) ようにすれば、DBサーバのパスワードを知っている人間がいない運用ができる

↑

暗号化(SSL/TLS) †

AWS Certificate Manager
- 独自ドメインの証明書を管理する
- Amazon Cloud Front
- Elastic Load Balancer
- Amazon API Gateway
AWS Key Management Service
- 証明書の保管
- CMK (Customer Master Key) で暗号化
- ※ より厳格な保管が必要な場合は AWS Cloud HSM を使う
データの暗号化
- S3
  - SSE-S3 (S3が管理する鍵で暗号化)
  - SSE-KMS (KMSが管理する鍵で暗号化)
  - SSE-C (ユーザ指定の鍵で暗号化)
- RDS (Relational Database Service)
  - Amazon Aurora、PostgreSQL、MySQL、MariaDB、Oracle Database、Microsoft SQL Server
  - KMSで管理される鍵で暗号化
  - バックアップも暗号化される
  - リージョンまたぎのコピー : リージョンをまたいで CMK を渡せないので、暗号化されたスナップショットをコピーしても復号化できない。スナップショットのコピーを行うときに、送り先の CMK を指定する
  - 別アカウントでのリストア : CMKのキーポリシーで、他のアカウントにリストアを許可する
- SQS メッセージの暗号化
  - メッセージは KMS が持っている CMK で暗号化/復号化される

↑

サービス開発 †

↑

インフラ †

AWSの構成
- AWS Region (世界20ヶ所以上)
- Availability Zone (Region内に最低2つ)
- Edge Location (世界200ヶ所以上)
Cloud Front
- Edge Location にあるキャッシュサーバ
- Webだけでなく、S3のバケットなども Cloud Front でキャッシュされる ⇒ 例: 北米リージョンで動いているサービスを東京のEdge Location上の Cloud Front からアクセスする
AZを意識しなきゃいけないのは
- EC2
- RDS
- Elastic Cache
Cloud Frontは、リージョンの外 (Edge Locationの持ち物)
その他はリージョンの持ち物 (S3,SNS,Lambda,...)

↑

開発環境 †

                  | AWS Cloud
ユーザ - [UI] ---API---> EC2, Lambda, S3, VPC
                  |

UI
- AWS Management Console
- AWS Command Line Interface
- AWS Tools ans SDKs
  - Toolkit IDEのpluginで提供 (PyCharm?, VSCode, ...)
  - AWS Colud9 (Web IDE)
UIは、API経由でサービスにアクセスしている

APIへのアクセスは「署名バージョン4」で、処理要求に署名をする必要がある

ヘッダに次のものをつける

署名に使用したアルゴリズム	AWS4-HMAC-SHA256
認証情報スコープ	インスタンス+時刻+リージョン+API
署名付きヘッダの一覧	AWSのシークレットアクセスキーから署名キーを取得
計算された署名	リクエストのメタデータと署名キーから計算されたハッシュ値

認証情報として使うものの優先順位
1. コードのオプションやパラメータで指定されたアクセスキー
2. 環境変数 (AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY_
3. /.aws/credentials
4. ECSのIAM ロール (インスタンスプロファイル)

↑

ストレージ †

Amazon Elastic Block Store (EBS)
- インスタンスにアタッチして、OSやソフトウェアをインストールする Block デバイス
- Availability Zone の持ち物 (AZ をまたいで共有できない)
Amazon Elastic File System (EFS)
- インスタンスからマウントして使う、データ領域
- AZをまたいで複数インスタンスからマウントできる
S3 (Amazon Simple Storage Service)
- KVS
- オブジェクトストレージ
- インターネット対応(ブラウザから直接見られる)
- 容量無制限
- 柔軟なセキュリティ設定
S3に格納されているデータ主な用途
- AWS Glue データ加工、データカタログの作成
- Amazon EMR Hadoop/Spark
- Amazon Redshift DWH (Dataware House)
- Amazon SageMaker? 推論
- Amazon Athena SQLクエリで分析
- Amazon Quick Sight BI(Business Intelligence 様々なグラフ化)
- AWS Lake Formation (Glue, Athena などのテンプレート)
S3 Select (SQL文でデータを抽出)
S3 にバックアップ
- バージョニング
- オブジェクトロック(上書きできないようにする)
- Amazon S3 Glacier
  - 頻繁にアクセスしないデータを格納する場所
```
アプリ <==PUT/GET/DELETE===> S3 <--(Archive/Restore)--> S3 Glacier 
```
  - S3より保管料が安い
  - アプリケーションから直接アクセスするオブジェクトは Glacier に移動してはいけない
AWS Storage Gateway
- ファイルゲートウェイ : S3 を NFS/SMB としてアクセスできるようにする
- ボリュームゲートウェイ : S3 を iSCSI としてアクセスできるようにする
- テープゲートウェイ : S3 を仮想テープライブラリとしてアクセスできるようにする
S3 のクロスリプリケーション : 東京リージョンとシンガポールリージョンでS3を同期する
S3 から静的ウェブコンテンツを配信する。Cloud Front と合わせて使う
```
Cloud Front (JPN)-------+ 
Cloud Front (CHN)-------+-----S3 (HTML,CSS,PNG,JPG,...)
Cloud Front (SGN)-------+
```
- アクセスコントロールリストで公開設定する
- より詳細に権限設定する場合は、パケットポリシーを設定する
- 署名付きオブジェクトキー : 一時的にアクセスできるオブジェクトのURL (プロセスが生きている間だけ有効）
- CORS (Cross Origin)
暗号化 SSE-S3, SSE-KMS, SSE-C
整合性 MD5チェックサム
```
openssl md5 -binary xxx.txt | base64
```
で base64 の MD5 チェックサムを計算して、アップロード時に指定する
```
aws s3api put-ouject --bucket yyyy -key xxx.txt --body xxx.txt --content-md5 {MD5}
```
S3のError
- Internal Error ⇒ なんかのエラー、解決法「再試行」
- No Such Bucket
- Bucket Already Exists
- Invalid Bucket Name

↑

Database †

Amazon RDS (Relational Database Service)
- MySQL
- PostgreSQL
- MariaDB
- Oracle
- パスワードは AWS Secret Manager で自動ローテーション・アプリサーバと共有
- レプリケーション
  - 非同期/読み取り専用レプリカは 5 つまで作成できる
  - クロスリージョンレプリカ
- フェイルオーバー : マスター障害時にスタンバイがマスターに昇格
- スナップショット ⇒ S3。他のリージョンにスナップショットを作ることもできる
Amazon Aurora
- MySQL互換API (性能5倍)、PostgreSQL互換API (性能3倍)
- 自動拡張 10GB ⇒ 128TB
- スタンバイはない。読み取り専用のリードレプリカを 15 個まで作れる
- フェイルオーバーは、リードレプリカが昇格。障害後1分以内
- キャパシティータイプ
  - プロビジョニングタイプ : インスタンスを作成する。インスタンスごとの課金
  - サーバレスタイプ : Aurora Serverless。AWSのどっかで動いているが、ユーザは関知しない。ACU (Aurora Capacity Unit) ごとに課金。1ACU=1CPU/2GBメモリ。マネジメントコンソールで設定した最小ACUから最大ACUに自動スケーリング
Amazon Elastic Cache
- Memcached, Redis
- 複数のサブネットを束ねたサブネットグループに配置する ⇒ AZをまたいだキャッシュサーバとして使うことができる
Amazon DynamoDB
- Amazon 独自の KVS
- PK
  - パーティションキーのみ
  - パーティションキーとソートキー
- パーティションキーのハッシュ値を元に、レコードを格納するパーティションを決める。パーティションキーはハッシュキーとも呼ばれる
- パーティションキーの考慮事項
  - 業務的に分配しやすい属性を使用する (ユーザIDなど)
  - そういう属性がないならサフィックスを追加する「.1から.200」 (東京.1, 東京.2, ..., 東京.200, 神奈川.1, 神奈川.2, ...)
- セカンダリインデックス
  - LSI (ローカルセカンダリインデックス) = パーティションキーのこと
  - GSI (グローバルセカンダリインデックス) = パーティションキーと無関係の属性でクエリの検索を行いたいときに設定する
- 請求
  - オンデマンドキャパシティモード : 読み書き回数による課金
  - プロビジョニング済みキャパシティモード : プロビジョニング=確定。予め RCU,WCUを購入する
    RCU Read Capacity Unit 1KB/sec
    WCU Write Capacity Unit 1KB/sec
- DynamDB ストリーム
  - 変更時に変更情報が得られるストリーム。変更ごとに Lambda を呼び出すのに使う
  - どの情報をストリームに乗せるかを設定する
    キーのみ
    新しいイメージ変更後のレコード
    古いイメージ変更前のレコード
    新旧イメージ変更前と変更後のレコード
- DynamoDB グローバルテーブル
  - 他のリージョンにレプリカを作る
  - DynamoDB ストリームによって、変更情報を他のリージョンに配って同期する
- DynamoDB のバックアップ
  - ポイントインタイムリカバリ ⇒ 過去35日以内の任意の時刻に戻れる
  - バックアップ ⇒ 特定の時点のバックアップを取る
- DynamoDB Accelerarator (DAX)
  - インメモリで動く DynamoDB
  - 通常数ミリ秒のレイテンシを数マイクロ秒にできる
  - VPCサブネットグループ上につくる
  - APIは DynamoDB と互換
- DynamoDB API
  - PutItem?
  - UpdateItem? : 楽観ロック ConditionExpression?
  - GetItem?
  - DeleteItem?
  - Query
  - Scan (全項目走査、遅いので Query を使うべし)
  - BatchWriteItem? , BatchGetItem?
  - TransactWriteItems?, TransactGetItems? : 2018に追加、「DynamoDBはトランザクションをサポートしている NoSQLデータベース」
- Java DynamoMapper?
- C# オブジェクト永続性モデル
- DynamoDBのセキュリティ=IAM

↑

Computing †

↑

Lambda †

実行環境 Node.js, Java, Python, .NET, Go, Ruby, カスタムランタイム
- メモリ 128MB〜10GB。CPU, Network はメモリサイズに依存
- リージョン、VPCどちらでも起動可能
- IAMロールの割付ができる
Lambda のイベントモデル
- PUSH : サービス側から Lambda を呼び出す
  - S3 の更新イベント : S3 は更新時に Lambda を呼び出す
  - API Gateway
- PULL : Lambdaからサービスに問い合わせをする
  - DynamoDB : DynamDB Stream を設定すると DB 更新時に Lambda が実行される ⇒ 実装上はDynamoDB Stream に更新情報が貯まる。Lambda が DynamoDB Stream を定期的に見に効く(ポーリング)
  - SQS : SQS にメッセージを投げると Lambda が実行される ⇒ 実装上は Lambda が SQS のキューを定期的に見に行く(ポーリング)
Lambda の権限
- ログ出力
  - logs:CreateLogGroup?
  - logs:CreateLogStream?
  - logs:PutLogEvents?
- AWS管理ポリシー (CloudWatch? 権限が設定されている)
  - AWSLambdaBasicExecutionRole?
ログ監視
- CloudWatch? Logs に書き込まれる
- コードからログを吐くことができる
- Lambdaは次のログを必ず吐く
  - START
  - END
  - REPORT
    Duration 実行時間
    Billed Duration 課金時間 (ms)
    Memory Size 初期サイズ
    Max Memory Size 最大サイズ
Lambda のデプロイ
1. Lambda関数の作成
2. IAMポリシーをアタッチしたIAMロールを割り当てる
3. Lambda関数本体と、依存ライブラリ、設定ファイルを ZIP にまとめてアップロードする。※10MBより大きい場合は S3バケット経由でアップロード
4. テスト実行して CloudWatch? Logs を確認
5. 運用開始 CloudlWatch? Logs + AWS X-Ray (運用監視) でモニタリング
Lambda レイヤー
- 共通的に使うライブラリをレイヤーにまとめる
- 最大 5 レイヤー
- Lambda A, Lambda B, Lambda C から Lambda Layer にある共通ライブラリを参照する
Lambda バージョニング
- Lambda は、関数を配備するごとにバージョンを設定する
- Lambda のエイリアスを設定することによって、開発版・β版・公開版でバージョンを分けることができる
  エイリアス関数バージョン
  XX 2
  XX_PRODUCT 2
  XX_BETA 3
  XX_DEVELOP 4 (=latest)
Lambda 設定
- 環境変数
- メモリサイズ (128MB〜10240MB)
- タイムアウト (デフォルト 3秒、最大 900秒(15分))
- モニタリング (Cloud Watch, AWS X-RAY)
- Lmabda VPC (Lambdaを特定のVPC内で動かすことが可能)
- Lambda EFS (EFSをマウント可能)
- Lambad 同時実行数 (最大1000)
- Lambda プロビジョニング (通常設定では、リクエストが有ってからプロセスを立ち上げる(コールドスタート)。一定数のプロセスを常時立ち上げておく(確保=プロビジョニング)しておくことができる)
Lambda の非同期実行
- 実行に失敗した場合 {イベントの最大有効期間} 以内に、最大 {再試行} 回再実行する
- それでも失敗したら、デットレターキューを Amazon SQS に送る
Lambda の制限
- 最大実効数 1000
- 関数とレイヤーの合計容量 75GB
- メモリ 128〜10240MB
- タイムアウト 15分(900秒)
- レイヤー 5
- デプロイパッケージ 50MB。関数ごとに、レイヤーを含めて 250MB
- /tmp 512MB
Lambda 作成時の留意点
- 設定は環境変数で行う (コードを変えなくても良いようにする)
- 共通モジュール/ライブラリはレイヤーで共有する
- 再帰処理は行わない (※ S3イベント中に、PutObject? したらあかん!(また S3イベントが起きる))
Lambda を呼び出せるイベント
- Alexa
- API Gateway
- S3
- Cloud Watch (AWSアカウント内で発生したイベント。査証など)
- Cloud Watch Logs (特定の属性のログが発生したとき)
- Cloud Formation (仮想環境を作るテンプレート内で Lambda を呼び出すことができる)
- Code Commit
- Cognit (統合認証)
- Config (AWS Config ルールを使用して、設定変更時に Lambdaを呼び出すことができる。設定変更のチェックなど)
- DynamoDB Stream
- Application Load Balancer (ALBでLambdaを負荷分散)
- AWS IoT
- Kiness Data Streams (データストリーム)
- SES (Simple Email Service)
- SNS (Simple Notification Service)
- SQS (Simple Queue Service)
- Step Functions (ワークフローの一部としてLambdaを呼び出す)

↑

Amazon API Gateway †

REST で処理要求を受け付けて Lambda を実行する

              . . . . . . . . . . . . . . . . . . . . . . . . . . 
              :AWS Cloud
              :        . . . . . . . . . . . . . . . . . . . . . . 
              :        :Region
ブラウザ -----+-(REST)--API Gateway-----Lambda-----DynamoDB
              |        :
              +-(HTTP)--Colud Front-----S3バケット (静的コンテンツ)
              :        :
              :        . . . . . . . . . . . . . . . . . . . . . . 
              :. . . . . . . . . . . . . . . . . . . . . . . . . .

直接 DynamoDB を操作することもできる

              . . . . . . . . . . . . . . . . . . . . . . . . . . 
              :AWS Cloud
              :        . . . . . . . . . . . . . . . . . . . . . . 
              :        :Region
              :        :             +--DynamoDBPullItem--+
ブラウザ -----+-(REST)--API Gateway--+                    +-----DynamoDB
              :        :             +--DynamoDBGetItem---+
              :        :
              :        . . . . . . . . . . . . . . . . . . . . . . 
              :. . . . . . . . . . . . . . . . . . . . . . . . . .

アクセス認証・制限
- バックエンド認証用SSL証明書
- リソース認証 (アクセス元IPアドレスの範囲など)
- IAM認証
- Cognitoオーサライザ (Cognitoで認証を行う(アクセス元に一時的ににIAM権限を与える))
- Lambdaオーサライザー (独自のLambdaで認証を行う)
使用量プラン (スロットリング)
- レート 100リクエスト/秒 (最大10000)
- バースト 500リクエスト/ミリ秒
- クオーター 1000000リクエスト/月
APIキーごとにスロットリングを指定できる
メッセージ変換
- 単純に REST を JSON に変換して Lambda に渡す API Gateway を作ることができる
- 複雑なのでは、REST を DynamoDBGetItem? に変換して DynamoDB を呼び出すようなものを作ることができる
キャッシュ
- 同じ REST アクセスに対して、一定期間はキャッシュの内容を返す (Lambad を呼び出さない) ことができる
ログ
- CloudWatch? Logs
- X-Ray
Import/Export
- Swagger形式でインポート・エクスポートが可能
ステージ変数
- 後続の Lambda のエイリアスを、ステージ変数で制御する
  - API Gateway のステージ変数 alias = prod (開発版)
  - API Gateway の後続の Lambdaの設定 {arn:aws:lambda:us-east-1:123456789012:function:XXXXXFunc:${stageVariables.alias}
  - API Gateway が call されたとき、呼ばれる Lambda関数は arn:aws:lambda:us-east-1:123456789012:function:XXXXXFunc:prod
- Lambda 関数のリソースポリシー
  - マネジメントコンソールから設定できない (2023現在)
  - AWS CLI から設定する
```
$ aws lambda add-permission
  --function-name arn:aws:lambda:us-east-1:123456789012:function:XXXXXFunc:prod
  --source-arn "arn:aws:execute-api:us-east-1:123456789012:1ouchacnu1/*/POST/compute_orbit"
  --principal apigateway.amazonaws.com
  --statement-id xxxxx
  --action lambda:InvokeFUnction
```

↑

コンテナ (Docker) †

EC2サーバにDockerをインストールして、勝手に使ってもよい
- docker pull
- docker run
- docker stop
- docker rm
AWSがコンテナの実行環境を用意してくれている
- ECS (Amazon Elastic Container Service)
- ECR (Amazon Elastic Container Registory)
- Images作成の手順
  1. Dockerfileを作る (Cloud9 でやるのがおすすめ)
  2. aws ecr コマンドで、一時ログインパスワードを発行して、docker (dockerコマンドの設定ファイル) に設定する
```
$ aws ecr get-login-password --region us_east-1 | docker login --username AWS --passwoed-stdin 123456789011.dkr.ecr.us-east-1.amazon.com
```
  3. docker build, docker tag でイメージを作る
  4. docker push で ECR にイメージをアップロードする

↑

メッセージング †

Amazon SQS (Simple Queue Service)

注文を SQS に溜め込んで、後でゆっくり RDS に格納する (実感ではやらないほうが良いけど)
```
Webアプリ --- SQS --- Lambda --- AmazonRDS
```
Queue操作
- Send
- Receive
- Delete
送信側：プロデューサー
受信側：コンシューマー
可視性タイムアウト
- コンシューマーが複数いるとき、同時に処理しないようにする仕組み
- コンシューマーA が、メッセージを Receive したら、メッセージは一定時間(60秒) コンシューマーB, Cから見えなくなる
- コンシューマーA が、メッセージの処理に失敗して、メッセージがキューに戻ったとき 60 秒立つと B,C から見えるようになる
- 可視性タイムアウト値 : VisibilityTimeout?
デッドレターキュー
- 一定回数再試行しても処理できないメッセージは、デッドレターキューに移される
- 再試行回数の設定値 RedrivePolcy? の maxRecieveCount?
ロングポーリング
- キューにメッセージが入っていなかったら、次回のポーリング間隔を伸ばす
- SQSの料金はAPIリクエストに対する料金
- メッセージの受信リクエストの WaitTimeSecond?
- キュー属性の RecieveMessageWaitTimeSecond?
共有キュー
- 別アカウントからも受信できるキュー
- 費用はキューを作成した側 (送信側) の負担になる

キューのタイプ

標準タイプ	順序性の保証はない	複数回受信される可能性あり	無制限のパフォーマンス
FIFO (First In First Out)	順序性の保証	1回のみ受信を保証	API 呼び出し 300回/sec まで (300回/sec ✕ 10Msg/回=3000Msg/sec)

キュー管理API
- CreateQueue?
- SetQueueAttribute?
- GetQueueAttribute?
- GetQueueUrl?
- ListQueue?
- DeleteQueue?
キュー操作API
- SendMessage? : MessageBody? + DelaySeconds? + MessageAttributes?
- ReceiveMessage? : WaitTimeSeconds? + VisibilityTimeout? + MaxNumberOfMessage?
- DeleteMessage?
- DeleteMessageBatch? (10個までいっぺんに消せる)
- PurgeQueue? (全削除)
キューの暗号化 : Amazon KMS
Amazon SQS Extended Client Library
- SQSのキューメッセージは 256KB まで
- それより大きいオブジェクトを送りたい場合は、Amazon SQS Extended Clinet Library を使う
- 内部動作 (プロデューサー) データ本体を S3 バケットに格納して、メッセージにはその参照情報を載せる。
- 内部動作 (コンシューマー) メッセージの参照情報を元に S3 バケットからデータを取得。正常終了すると、S3バケットに格納しているデータ本体を削除する。

Amazon SNS (Simple Notification Service)
- 起きたことを掲示板 (Topic)に貼り付けるイメージ
- Topic操作
  - CreateTopic?
  - Publish
  - Subscribe
  - DeleteTopic?
- 送信側：パブリッシャー\
  - AWS SDKs, CloudWatch? Alarm, CloudWatch? Event, RDS Event
- 受信側：サブスクライバ
  - Lambda, SQS, SMS (Mail), モバイルアプリ, HTTP, AWS Chatbot
- ファンアウト
  - 特定のサブスクライバのグループには、全部の属性情報を送り、その他のグループにはメッセージのみを送るようにする
  - rawメッセージを無効化：すべての属性データを送る
  - rawメッセージを有効化：メッセージのみを送る (逆のような気もするけどこれであってる)
- 設定
  - SNSトピックポリシーの設定：どこにパブリッシュするか
  - SNSサブスクリプションの設定 : サブスクライバの設定、rawメッセージの発信を有効化・フィルターポリシー

Amazon MQ

Apache Active MQ
Rabbit MQ
JMS,NMS,AMQP,STOMP,MQTT,WebSocket? が使える

EFSを間に挟んで、AZ間でデータのやり取りをできる

 Region
  -----------------------------------------
 | AZ1                      AZ2
 |  -------------           -------------
 | | App → MQ ー|→ EFS ー|→ MQ → App |
 |  -------------           -------------
  -----------------------------------------

↑

Amazon Kinesis †

ニアリアルタイムなデータストリーム処理

Amazon Kinesis Video Stream	ビデオデバイスからAWSを使った配信。Amazon Rekognition Vidio 動画分析
Amazon Kinesis Date Stream	数GB/sec のデータストリーミング処理
Amazon Kinesis Data Firehouse	ストリームデータの格納。S3, Redshift, Elasticsearch Service
Amazon Kinesis Data Analytics	ストリームデータの分析。SQL, Apache Flink

SDK
- プロディユーサー側 KPL (Kinesis Producer Library)
- コンシューマー側 KCL (Kinesis Client Library)
処理は、シャードで行われる。シャードを増やすと、計算能力がスケールする

↑

AWS Step Functions †

AWS のマイクロサービスを組み合わせたワークフローを作成・制御する
ステートマシン (状態遷移マシン)
- JSONで記述する
- フローチャートで表すことができる
- Pass : 次のノード渡す引数を設定するノード {Type:"Pass", Result:"1234", Next:"Task123"}
- Task : AWSのサービスを起動する
- Activity : 独自のEC2上で動くサービスを起動する
- Wait : 待ち
- Choice : 条件分岐
- Fail : Step Function を"失敗" ステータスで終了する
- Parallel : Step Function の一部を並列で処理させる
- Map : Mapも並列処理だが、多重度が実行時に決まる
- InputPath?, ResultPath?, OutputPath? : Task で lambda を起動するときに引数を渡すときに使う
実行方法
- Start Execution API を使って実行
- Cloud Wathc Eventルールで、特定のイベントが起きた時に実行
- API Gateway 経由で実行

↑

ベストプラクティス †

Auto Scaling
- EC2 Web Auto Scaling (Webアプリ)
- EC2 Worker Auto Scaling (SQSの後続処理)
- Lambda もともと勝手にスケールする
- RDS リードレプリカを5つまで作れる
- Aurora リードレプリカを15こまで作れる。AUC(2GB) の最大値と最小値を決められる
- DynamoDB WCU(Write 1KB/sec) RCU(Read 4KB/sec) の最大値と最小値を決められる。CloudWatch?と組み合わせてオートスケーリングできる。容量は無制限
- S3 容量無制限。3500回/sec以上の書き込み(PUT,COPY,POST,DELETE)、5000回/sec以上の読み込み(GET,HEAD)が発生するときは、キーのプレフィックスを分ける
アプリ方式の定石
- EC2インスタンスをいちいち手作業で作らない
- AMI (Amazon Machine Image) をインスタンスに展開すれば、すぐに動かせるようにする
- データは、初回起動時に、予め決めておいた S3 バケットの最新版を取ってくるようにする
- ステートレスにする or ステートを Elastic Cache (Redis, Memcached) に持つようにする。(Cacheは全インスタンス共通なので、スケールして立ち上がったインスタンスに処理要求が行っても整合性を保って処理できる。インスタンスがステートを持っているとスケールできない)
- 疎結合
- ファンアウト：疎結合の一種。Topicを使って、あるイベントを契機に動く処理を、既存システムに影響なく増やせるようにする
自前でサービスを作らずに、なるべく AWS のサービスを使う (もともとスケールが考えられているので)
適切なデータベースを使う
- Amazon RDS (Oracle,MS-SQL Sever,MySQL,PostgreSQL,MariaDB) スケールしなくていいときに使う
- Amazon Aurora (MySQL, PostgreSQL 互換API を持つ AWSサービス) スケール前提、性能は MySQLの5倍、PostgreSQLの3倍。3つのAZに6つのレプリケーションを作れる)
- Amazon DynamoDB (NoSQL、スケールする)
- Amazon Redshift (DWH データ分析)
- Amazon Elastic Cache (Memcached, Redis Pub/Sub)
- Amazon Neptune (グラフDB、広告配信などで使われる)
単一障害点をなくす
コストを最適化する
- API化 EC2上の独自アプリ → API Gateway + Lambda
- CI/CD CodeStar?
- 迷ったら DynamoDB 使っとけ
キャッシュを使え
- CloudFront? (Webフロント)
- ElasticCache? (バックエンド)
  - 遅延キャッシュ Elastic Cache を見に行って、情報がなければ DynamoDB を見る
  - 書き込みスルー Write Through = DynamoDB を更新するときは、Elastic Cache も更新する
すべてのレイヤでセキュリティを実装する
データの増加に備える → S3/DynamoDB は容量無制限

↑

移行 †

REHOST	オンプレミスのLinux+Redmine+MySQL を EC2上に同じ構成で持っていく
REPLATFORM	コードやデータは変更しない。ロードバランサ+EC2+EFS+RDS を使い冗長構成のRedmineに移行する
REPURCHASE	Redmine から backlog (SaaS)に移行する
REFACTOR/RE-ARCHETECT	再構築
RETIRE	廃止
RETAIN	存続

↑

モニタリング †

Amazon Cloud Watch

カスタムメトリクス
- サービス組み込みのメトリクスの他に、独自のメトリクスを作ることができる
- 独自の監視アプリは、PutMetricData? APIでメトリクスを報告する
EC2
メトリクス
CPUUtilization
NetworkIn?
NetworkOut?
StatusCheckFailed? ステータスまたはシステムチェックに失敗した場合は1、正常時は0
EBS
メトリクス
VolumeReadOps?
VolumeWriteOps?
RDS
メトリクス
DatabaseConnections?
ReadOPS
WriteOps?
FreeableMemory?

メトリクス
CPUUtilization
NetworkIn?
NetworkOut?
StatusCheckFailed?	ステータスまたはシステムチェックに失敗した場合は1、正常時は0

メトリクス
VolumeReadOps?
VolumeWriteOps?

メトリクス
DatabaseConnections?
ReadOPS
WriteOps?
FreeableMemory?

DynamoDB

メトリクス
ProvisionedWriteCapacityUnits?	購入した書き込みキャパシティユニット
ProvisionedReadCapacityUnits?	購入した読み込みキャパシティユニット
ConsumedWriteCapacityUnits?	使っちゃった書き込みキャパシティユニット
ConsumedReadCapacityUnits?	使っちゃった読み込みキャパシティユニット
ThrottledRequest?	キャパシティユニットによって設定されたスループットを超えるリクエスト
ReadThrottleEvent?	〃読み込みリクエスト
WriteThrottleEvent?	〃書き込みリクエスト

S3
メトリクス
BucketSizeBytes?
NumberOfObjects?

メトリクス
BucketSizeBytes?
NumberOfObjects?

Lambda

メトリクス
Invocations	呼び出しリクエスト回数
ConcurrentExecutions?	呼び出し関数インスタンス数
Errors
Throttles	同時実行数が限界から溢れてスロットリングされた回数
Duration	関数の実行時間

API Gateway

メトリクス
Count	リクエスト数
4XXError	クライアント側のエラー
5XXError	サーバ側のエラー
IntegrationLatency?	APIGateway がバックエンドにリクエストを送信してからレスポンスを受け取るまでの時間
Latency	APIGatewayがクライアントからリクエストを受け取って、レスポンスを返すまでの時間

SQS

メトリクス
SentMessageSize?
NumberOfMessagesSent?
NumberOfMessagesReceived?
NumberOfEmptyReceives?
ApproximateNumberOfMessagesVisible?	取得可能なメッセージ数。可視タイムアウトになっていないメッセージ
ApproximateNumberOfMessagesNotVisible?	処理中のメッセージ数。可視タイムアウトによって見えなくなっているメッセージ

SNS

メトリクス
NumberOfMessagesPublished?	トピックにパブリッシュされたメッセージ数
NumberOfNotificationsDeliverd?	サブスクライブに正常配信されたメッセージ数
NumberOfNotificationsFailed?	サブスクライブへの配信に失敗したメッセージ数
PublishSize?	トピックにパブリッシュされたメッセージサイズ

Step Functions

メトリクス
ExecutionTime?	開始から終了までの時間
ExecutionThrottled?	制限に達した実行回数。クオータ引き上げのリクエストを行う(上限緩和の申請を行う)
ExecutionsFailed?
ExecutionsStarted?
ExecutionsSucceded?
ExecutionsTimeOut?

CloudWatch? Logs
- アプリログの出力先 (SyslogのAWS版)
- セットアップ
  1. IAMロールの作成
    CloudWatchAgentAdminPolicy?
    AmazonSSMManagedInstanceCore?
    Action
    cloudwath:PutMetricData?
    logs:PutLogEvents?
  2. Systems Manager を使って、CloudWatch? エージェントをインストール
  3. CloudWatch? エージェント設定ファイルの作成
```
$ sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
$ sudo amazon-linux-extras install -y epel
$ sudo yum -y install collectd
```
  4. CloudWatch? エージェントの開始
- メトリクスフィルター
  - Cloudwatch Logs に出力したログから、文字列などでフィルタリングして、メトリクスにする
- CloudWatch? ダッシュボード
VPCフローログ
- VPC の ENI のパケットキャプチャー
- キャプチャーログは S3 または、CloudWatch? Logs に出力できる
AWS CloudTrais?
- AWSアカウント場で行われたアクションを記録する
- EC2インスタンス落としたのは誰だよ!
- 情報漏洩の原因となったセキュリティグループの変更をしたの誰だよ!
- 不正悪性したユーザが何やったのか?
- リクエストのブロックログによって攻撃が発生した事を知る
AWS X-Ray
- アプリケーションの潜在的はバグを特定したり、パフォーマンスのボトルネックを特定する
- アプリの内部をマップ化してトレースで分析する
- Lambda で X-Ray トレースを有効化する
  1. アクティブトレースを有効化する
    必要ロール
    xray:PutTraceSegments?
    xray:PutTelemetryRecords?
  2. AWS X-Ray SDK をコードに含める
  3. コードを追加する
- X-Rayサービスマップ
- X-Rayトレース
- X-Ray SDK
- X-Ray APIアクション
  - PutTraceSegments? トレースデータの送信
  - GetServiceGraph? JSONサービスグラスの情報を取得
  - GetTraceSummaries? トレースのサマリ情報を取得
  - BatchGetTrace? トレースをIDのリストでまとめて取得

↑

トラブルシューティング †

5xxサーバ側のエラー ⇒ 再試行
4xxクライアント側のエラー ⇒ ソースコードの修正
スロットリングエラー ⇒ クオーターの引き上げ申請
- 同時実行数の制限を超えたとき
  - RateExceeded?エラー
  - CloudWatch? の Throttles メトリクス
KMS (AWS Key Management Service) のリクエストクォータ
AWSのAPIは、エクスポネンシャルバックオフで、自動的に再試行される
- 「指数バックオフ」「指数関数的再試行」
セキュリティ
- IAMポリシーで許可されていないことをやった
- IAMポリシーで拒否されていることをやった
- IAMポリシー：IAMユーザ、IAMロール、リソースベースのポリシー
- CloudTrais?のログを確認する
- IAMポリシーシミュレータで、ユーザ・グループ・ロールを選択して、特定のAPIアクションを実行できるかをエミュレーションできる

Computer#Basic

BeanStalk?	SAM
Web,SQL	Serverless(Lambda)
ALBもできるよ
eb init	sam init
eb create	sam build
eb deploy	sam deploy

Region	世界20ヶ所、最低 AZ を２つ含む	S3, SNS, DynamoDB, Lambda
AZ		EC2, RDS, Elastic Cache
Edge Location		Cloud Front
Region-VPC-Subnet		Lambda, ALB (Application Load Balancer

ファイル	NFS/SMB
ボリューム	iSCSI
テープ	仮想テープ

CodeGuru? Profiler	実行時のパフォーマンス可視化
CodeGuru? Reviewer	ソースコードの静的解析

ルール#	タイプ	プロトコル	ポート範囲	送信先	許可/拒否
100	HTTP(80)	TCP	80	0.0.0.0/0	ALLOW
-	すべてのトラフィック	すべて	すべて	0.0.0.0/0	DENY

キーのみ
新しいイメージ	変更後のレコード
古いイメージ	変更前のレコード
新旧イメージ	変更前と変更後のレコード

Duration	実行時間
Billed Duration	課金時間 (ms)
Memory Size	初期サイズ
Max Memory Size	最大サイズ

エイリアス	関数バージョン
XX	2
XX_PRODUCT	2
XX_BETA	3
XX_DEVELOP	4 (=latest)

RCU	Read Capacity Unit	1KB/sec
WCU	Write Capacity Unit	1KB/sec

Basic AWS認定(デベロッパーアソシエイト)カンニングペーパー

目次

訪問者

更新

最新の10件

人気の10件

MenuBar

受験について †

最後の最後の確認事項 †

想定問題で不正解だったキーワード †

アプリのリリースプロセスとAWSサービス †

リリースプロセス †

ソース †

ビルド †

デプロイ †

モニタリング †

定形処理 ソース+ビルド+デプロイ †

実行環境 †

AWS OpsWorks? †

AWS Cloud Formation †

AWS Elastic Beanstalk †

サーバレス †

AWS SAM (Serverless Application Model) †

セキュリティ †

共有責任モデル †

ネットワーク †

SSH †

IAM †

Amazon Cognito †

シークレット情報の管理 †

暗号化(SSL/TLS) †

サービス開発 †

インフラ †

開発環境 †

ストレージ †

Database †

Computing †

Lambda †

Amazon API Gateway †

コンテナ (Docker) †

メッセージング †

Amazon Kinesis †

AWS Step Functions †

ベストプラクティス †

移行 †

モニタリング †

トラブルシューティング †

定形処理ソース+ビルド+デプロイ †