絶賛追記中
アプリのリリースプロセスとAWSサービス †
リリースプロセス †
ソース †
- Code Commit
- HTTPS, SSH
- 認証情報は IAM ユーザごと
- IAM ユーザに割り当てるポリシー(=権限)
- 管理ポリシー AWSCodeCommitPowerUser?
- 利用者ポリシー AWSCodeCommitFullAccess?, AWSCodeCommitReadOnly?
- 通常は、コードの改変は原本(Master ブランチ)で行わない。
- 開発ブランチで改変を行い一通り完成したら、開発ブランチの改変部分を Masterブランチに取り込んでもらうための "プルリクエスト" を発行する。
- 承認者がレビューして、原本 (Master ブランチ) に、マージする。
- プルリクエストやマージのタイミングで、通知を飛ばすことができる。
ビルド †
デプロイ †
- AWS Code Deploy の設定項目
- アプリケーション
- デプロイグループ
- アプリが 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
モニタリング †
- 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 の持ち物)
- 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) アクセス
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}
- プロファイル
- リージョン指定
$ 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
- 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を意識しなきゃいけないのは
- 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のシークレットアクセスキーから署名キーを取得 |
| 計算された署名 | リクエストのメタデータと署名キーから計算されたハッシュ値 |
- 認証情報として使うものの優先順位
- コードのオプションやパラメータで指定されたアクセスキー
- 環境変数 (AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY_
/.aws/credentials
- 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
- 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
Computer#Basic
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
