クラウドを積極活用したサービスの開発のために

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved.
クラウドを積極活⽤した
サービスの開発のために
2022/11/15
アマゾンウェブサービスジャパン合同会社

アジェンダ
AWS とは
フェーズごとの技術課題と技術選定の際に考えるべきこと
クラウドに最適化された設計とは︖
プロダクト開発に専念できる AWS の使い⽅

スタートアップにとって最も⼤事なことは︖
答︓ビジネスにフォーカスすること（≒ スピード）

• 分かっているつもりで出来ていないスタートアップは多い
• 本質的なところ以外 or その周辺でやるべきことが増える
• セキュリティ / コンプライアンス対応
• ログの収集、集約、⻑期保存
• バックオフィスの改善、効率化、インテグレーション
• 組織の拡⼤によりオーバーヘッドも増える
ビジネスにフォーカスする

AWS(Amazon Web Services) とは

クラウドとは新しい IT リソース利⽤のカタチ
必要な時に、必要なだけ、低価格で
IT リソースを提供

AWS の提供するサービスは仮想サーバーだけではありません︕
AWS はサーバーを貸してくれる会社︖︖
Amazon S3
（ストレージ）
Amazon EC2
（仮想マシン）
Amazon RDS
（データベース）

幅広い機能︓200 以上のサービスを提供
ネットワークアナリティクス
コンピュート
ストレージ & 配信
開発ツール管理ツールセキュリティ
アプリケーションインテグレーション
モバイルサービスデータベース IoT
機械学習
ゲーム
Amazon
EMR
Amazon
Kinesis
Amazon Athena AWS Glue
Amazon
Elasticsearch
Amazon
Redshift
Amazon
QuickSight
AWS
Data Pipeline
Amazon
SNS
Amazon SQS Amazon
MQ
AWS
AppSync
AWS Step
Functions
ELB
AWS Elastic
Beanstalk
AWS
Lambda
Amazon
EC2
Amazon
ECS
Amazon
Aurora
Amazon
DynamoDB
Amazon
ElastiCache
Amazon
Redshift
AWS DMS Amazon
Neptune
Amazon
RDS
AWS
CodeBuild
AWS
CodeCommit
AWS
CodeDeploy
AWS
CodePipeline
Amazon
GameLift
Amazon
FreeRTOS
AWS IoT
Analytics
AWS IoT
Core
AWS IoT Device
Defender
AWS IoT
Greengrass
Amazon
Forecast
Amazon
Polly
Amazon
Rekognition
Amazon
SageMaker
Amazon
Translate
Amazon
CloudWatch
AWS Auto
Scaling
AWS
CloudFormation
AWS
CloudTrail
AWS
Config
AWS Managed
Services
Amazon API
Gateway
AWS
Amplify
AWS
AppSync
AWS Device
Farm
Amazon
Route 53
Amazon
VPC
AWS Direct
Connect
Amazon
GuardDuty
Amazon
Inspector
Amazon
Cognito
AWS
Organizations
AWS
KMS
AWS IAM
Amazon
EFS
Amazon S3 AWS
Snowball
AWS Storage
Gateway
Amazon
FSx
Amazon
EBS

多種多様なサービスを利⽤できるということは
多種多様なビジネスの要件を満たせるということ

• 全⽂検索エンジン
• リアルタイムコミュニケーション（WebRTC）
• ライブ動画配信
• レコメンデーション
• モバイル / Web アプリ
ビジネス要件に対して、最適なサービスを選ぶことが出来る
Amazon OpenSearch Service
Amazon Chime SDK
Amazon Interactive Video Service
Amazon Personalize
AWS Amplify
今必要な機能だけでなく、ピボットや将来の機能拡張にも対応することが出来る

フェーズごとに異なる技術課題

S-Curve で⾒るフェーズごとの技術課題、特性の⼀例
Stage
Growth Seed Eealy Mid Later

Stage
スピード
コスト効率
AI/ML (API)
カスタマーサポート
バックオフィス
スケーラビリティ、安定性、可⽤性
ログ分析
AI/ML (Custom)
セキュリティ
コンプライアンス
カスタマーエンゲージメント
※ 詳細な要素、タイミングは
ケースバイケースで異なります

Stage
スピード
コスト効率
AI/ML (API)
カスタマーサポート
バックオフィス
スケーラビリティ、安定性、可⽤性
ログ分析
AI/ML (Custom)
セキュリティ
コンプライアンス
カスタマーエンゲージメント
※ 詳細な要素、タイミングは
ケースバイケースで異なります
AWS Amplify, Amazon Lightsail, Serverless Services, AWS Fargate etc
AWS Amplify, AWS Activate, AWS Savings Plan, Spot Instances etc
Amazon Forecast etc Amazon SageMaker
Amazon Pinpoint, Amazon Personalize etc
Amazon Connect, Amazon Lex etc
AWS Amplify, Serverless Services, Auto Scaling etc
Amazon S3, AWS Glue, Amazon Athena etc
Amazon WorkSpaces, AWS SSO etc
AWS IAM, Amazon GuardDuty etc
AWS CloudTrail etc

成⻑に応じて起こること – Seed（創業期） -
• 「とにかく早く作りたい、お⾦もまだない」
• いかに早く MVP を作るか
• いかに早くフィードバックループを回すか
• 余計な⼯数はかけていられない
• 余計なコストもかけていられない
あくまでスピードとコスト効率を意識しつつ
⼿軽に対応できるならやらない⼿はない

スタートアップが
技術選定の際に考えるべきこと

スタートアップがビジネスにフォーカスし、成功確率を⾼めるための考え⽅
•Undifferentiated Heavy Lifting の排除
•⽬の前の判断が Two-way Door なものでは
ないか⾒極める

アイデアの実現の過程には
「差別化に繋がらない重労働」
が多く存在し、それらを減らすことができれ
ば成功確率を上げることが出来る（意訳）
• Web 2.0 Summit での Tim O’Reilly と Jeff Bezos との対談
https://www.flickr.com/photos/farber/292880154
Amazon CTO の Werner Vogels も
メディア取材の際に
「Stop spending money on
“undifferentiated heavy lifting”」
とコメント
Undifferentiated heavy lifting

システム運⽤における Undifferentiated Heavy Lifting の例
• データベースの運⽤、バックアップ、レプリケーション設定
• 認証基盤の保守、管理、運⽤
• リアルタイム通信を⾏うサーバーの保守、管理、運⽤
• セキュリティパッチの管理、適⽤
• etc...

Main
例︓データベース
M S
Replica
レプリケーション
Application
Backup 定期取得
フェイルオーバー
上記以外
• ストレージ容量の確保
• パフォーマンスモニタリング
• パッチ適⽤、監視設定
例︓ビデオ通話機能
配信サーバー配信サーバー
接続先管理⽤
データベース
• 配信サーバーのチューニング
• 配信サーバーのスケーリング
• 配信サーバーのパッチ適⽤
• 接続先の管理、ハンドリング
本当にやりたいのは、これらを⽤いた
プロダクト開発や機能追加、あるいは
それらを通したプロダクトの価値向上のはず

Master
例︓データベース
M S
Slave
レプリケーション
Application
Backup 定期取
得
フェイルオーバー
上記以外
• ストレージ容量の確保
• パフォーマンスモニタリング
• パッチ適⽤、監視設定
例︓ビデオ通話機能
配信サーバー配信サーバー
接続先管理⽤
データベース
• 配信サーバーのチューニング
• 配信サーバーのスケーリング
• 配信サーバーのパッチ適⽤
• 接続先の管理、ハンドリング
本当にやりたいのは、これらを⽤いた
プロダクト開発や機能追加、あるいは
それらを通したプロダクトの価値向上のはず
Amazon Aurora Amazon Chime SDK

Is it a one-way or
a two-way door?

技術選定や設計における One-way Door Decisions
• もちろんスピードは重要だが、その中でも全体に⼤きな影響を与えるもの、
後から変更することが難しいものはちゃんと考えて決めるべし。
「本当にそれで⼤丈夫か︖」
• データの置き場、将来的な活⽤⽅法
• データベース設計
• クラウドプラットフォーム
• etc...

⽬の前の判断が Two-way Door なものではないか考える
• 逆に、「それ試しにやってから後で変えることもできるよね」という
要素（=Two-way Door）では時間を使いすぎずに意思決定する
− 「試しにやる」ハードルを下げる
• ⽬の前の決断が One-way door なのか Two-way door なのか⾒極める
− Two-way door なのに無駄に時間をかけていないか︖
• 少しの⼯夫で Two-way door な状況に出来ないか︖
• 実は⾃分が知らないだけではないのか︖

スタートアップがビジネスにフォーカスし、成功確率を⾼めるための考え⽅(再)
•Undifferentiated Heavy Lifting の排除
•⽬の前の判断が Two-way Door なものでは
ないか⾒極める

クラウドに最適化された
(クラウドネイティブな)設計とは

クラウドネイティブな設計とは何か︖︖
Design for Failure な設計にすること

connect
DevAx
Everything fails all the
time
Dr. Werner Vogels
Chief Technology Officer of Amazon.com

connect
DevAx
Design for Failure
To
Your Application

創業期スタートアップ向け「まずここから」Design for Failure
• 想定上のアクセスが来てもダウンしない
冗⻑構成 (マルチAZ)/オートスケーリング
• 問題のあるインフラがあっても置き換えてくれる
オートヒーリング
• データを誤って消しちゃった時にでも復旧できる
バックアップ・リストア
• (+α) アプリケーションがエラーになった際の
リトライ処理やキューイング

Design for Failure な設計になっていないとどうなるか︖
• 例1: ⼤事な時(e.g. VC へデモを⾒せる時等) にダウンし
ていることによる機会損失
• 例2: メンバーも少ないため、その都度発⽣する障害対応
だけで1⽇が過ぎてしまう

シード期において、Design for Failure を実現するために
Q. 時間のないシード期のスタートアップにとって、Design for Failure
を真⾯⽬に全て向き合うのは難しいのでは︖
• まずは、Design for Failure な設計が組み込まれたサービスを最初か
ら選定できないか考える
• スピードとコストとのトレードオフではない
• むしろ対応に追われる⼯数がなくなりスピードアップ
• 実装やアーキテクチャに依存するところはその先で考える
• AWS の SA に相談も︕

プロダクト開発に専念できる
AWS の使い⽅

オーソドックスな技術スタック

オーソドックスな技術スタック
フロントエンド、
モバイルアプリ
バックエンド
Webサーバー
バックエンド
DBサーバー
⾔語・フレームワーク
React, Vue, Swift,
Kotlin, Java etc
インフラ
Web Hosting サービス、
BaaS etc
⾔語・フレームワーク
Ruby on Rails, Laravel,
Django, Express, Spring etc
インフラ
仮想サーバー、コンテナ、
サーバーレス etc
DB 種類
RDBMS, NoSQL,
Fulltext Search, etc
インフラ
マネージドDBサービス,
仮想サーバー etc

負担をオフロードできる AWS のサービス
フロントエンド、
モバイルアプリ
バックエンド
Webサーバー
バックエンド
DBサーバー
Amplify Hosting AWS App Runner Amazon Aurora
Serverless v2

AWS Amplify は、
⼩さくはじめて⼤きく育てる
スタートアップに最適
爆速
でアプリを開発
簡単
にアプリを開発
スケール
するフロント/モバイル
アプリを開発

AWS Amplify の 4 つのコンポーネント
Web やモバイルアプリ
ケーションを⼀般的な
ユースケースベースのガ
イド付きワークフローで
バックエンドを簡単に作
成、管理するツール
Amplify CLI
Web やモバイルアプリ
ケーションと AWS を統
合するためのユースケー
ス中⼼のライブラリ
Amplify Libraries
継続的デプロイメントを
管理し、モダンな Web
アプリケーションをビル
ド、テスト、デプロイ、
そしてホスティングする
ための AWS サービス
Amplify Hosting
AWS 上に最⼩限のコー
ディングでフロントから
バックまでのアプリケー
ションを作成できるビ
ジュアルな開発環境
Amplify Studio

4 つのコンポーネントの役割
.js
.html
.css
クライアント

.js
.html
.css
クライアント
Amplify CLI
Amplify Libraries
Amplify Hosting
Amplify Studio

.js
.html
.css
クライアント
Amplify Hosting

AWS Amplify Hosting
ウェブアプリや静的ウェブサイトのため
のフルマネージドなホスティングサービ
ス
簡単なカスタムドメイン設定も可能
継続的デプロイメント
Amplify CLI で Infrastructure as Code（
IaC）を⽣成
Amplify CLI やコンソールからのデプロ
イ AWS Amplify CLI AWS Amplify Console

Amplify Hosting の利⽤フロー

Amplify Hosting の主な機能
グローバルで利⽤可能
プルリクエストプレビュー
カスタムドメインの簡単設定
シンプルな
継続的ワークフロー
パスワード保護

Amplify Hosting - 環境の分割
接続したブランチ毎に
ホスティングされ、URL
が払い出される

Amplify Hosting - Pull Request Previews
https://docs.aws.amazon.com/amplify/latest/userguide/pr-previews.html
Pull Request が作成されるたびに⼀時的
なウェブサイトをホスト
ホストした URL を Git Hub の Pull
Request ページに載せる
⾮エンジニア職でも気軽に Pull Request
レビューに参加することが可能に
Pull Request が閉じたら⼀時的なウェブ
サイトもクローズ

Amplify Hosting - ベーシック認証
https://docs.aws.amazon.com/amplify/latest/userguide/access-control.html
接続したブランチ毎に
Username/Password を設定して
ベーシック認証をかけることが可能

もっと AWS Amplify を知りたい⽅へ
公式ドキュメント
https://docs.amplify.aws
AWS Summit 2021 「Web・モバイルアプリ開発を加速させる AWS Amplify」
https://d1.awsstatic.com/events/jp/2021/summit-online/AWS-
47_AWS_Summit_Online_2021_FWM01.pdf
ワークショップ
https://amplify-sns.workshop.aws/ja/
Amplify 学習リソース集
https://aws-amplify-jp.github.io/resources
Amplify Japan User Group Slack
https://github.com/aws-amplify-jp/awesome-aws-amplify-ja#slack

AWS は幅広い選択肢を提供

AWS は幅広い選択肢を提供
200 以上のサービス

ウェブアプリケーションを AWS 上で動かしたい場合

AWS サービスを組み合わせてインフラを構築
柔軟性が⾼い
VPC (ネットワーク)
Fargate (コンピュート)
ECS (オーケストレーション)
ALB (ロードバランサ)
AWS Auto Scaling (オートスケール)
CodeBuild (CI/CD)
⼿間がかかる

構築済みのインフラにすぐにデプロイ
AWS App Runner

App Runner とは
インフラや AWS についての経験がなくても、
コンテナ化されたウェブアプリケーションや API を
簡単かつ迅速に AWS 上で動かせるサービス

AWS App Runner の主な特徴
シンプルな
オートスケーリング
統合された
メトリクス・ロギング機能
シンプルな
セットアップ

App Runner 上にウェブアプリケーションをデプロイ
App Runner
Amazon ECR
Image Repo
動かしたいウェブアプリケーションを指定する

App Runner
GitHub
動かしたいウェブアプリケーションを指定する
GitHub Repo

App Runner
GitHub
ソースコードを取得
コンテナイメージをビルドしてデプロイ
コンテナインスタンス
ロードバランサー
ネットワーク (VPC)
App Runner
GitHub Repo

App Runner
App Runner
コンテナイメージを取得
コンテナイメージをデプロイ
Amazon ECR
Image Repo

App Runner
エンドユーザーデフォルトドメイン
https://xxxxxxxx.<region>.awsapprunner.com

App Runner - シンプルなオートスケーリングの設定
オートスケールのしきい値
となるリクエスト数
コンテナインスタンスの
最⼩数
コンテナインスタンスの
最⼤数
デフォルト
の設定値

オートスケール
App Runner
エンドユーザーデフォルトドメイン
エンドユーザー
エンドユーザー

ログ・メトリクス
App Runner 開発者
App Runner コンソール
ログとメトリクスを⾃動で収集
App Runner コンソールから確認

App Runner - Console でのログの閲覧
⾃分でログエージェントを実装する必要なし

App Runner - Console でのメトリクスの閲覧
リクエスト数、応答のレイテンシ、HTTP 2XX 4XX 5XX それぞれの数
を App Runnerのコンソール画⾯で閲覧可能

もっと AWS App Runner を知りたい⽅へ
https://docs.aws.amazon.com/apprunner/latest/dg/what-is-apprunner.html
ブログ
https://aws.amazon.com/jp/blogs/news/introducing-aws-app-runner/
ワークショップ
https://www.apprunnerworkshop.com/
ロードマップ
https://github.com/aws/apprunner-roadmap/projects/1

AWS purpose-built database
従来のアプリ
ケーション、ERP、
CRM、e コマース
トラフィックの
多いウェブアプ
リ、e コマースシ
ステム、ゲーム
アプリケーショ
ン
コンテンツ管理、
カタログ、ユー
ザープロファイ
ル
キャッシュ、
セッション管理、
ゲームのリー
ダーボード、地
理空間アプリ
ケーション
不正検出、ソー
シャルネット
ワーク、レコメ
ンデーションエ
ンジン
IoT アプリケー
ション、DevOps、
産業テレメトリ
記録システム、
サプライチェー
ン、銀⾏トラン
ザクション
産業⽤機器のメ
ンテナンス、取
引監視、フリー
ト管理、ルート
最適化

Amazon Aurora
優れた性能と拡張性
クラウド向けに再設計された MySQL, PostgreSQL と互換性のある RDBMS
商⽤データベースの性能と可⽤性を 1/10 のコストで
⾼可⽤性と耐久性⾼い安全性フルマネージド

Amazon Aurora のアーキテクチャ
ストレージノード
分散ストレージシステム
データベース⽤に設計された
専⽤の分散ストレージシステム
データは3箇所に分散された数百
のストレージノードに6つのコ
ピーとして保存

Amazon Aurora のアーキテクチャ
ストレージノード
データベース⽤に設計された
専⽤の分散ストレージシステム
データは3箇所に分散された数百
のストレージノードに6つのコ
ピーとして保存
SQL を実⾏するインタフェース
は分散ストレージを共有するこ
とで、責務が分離
SQL
トランザクション
キャッシュ
コンピュートノード

フルマネージド化による管理負荷の軽減
拡張性
⾼可⽤性
DB バックアップ
DB パッチ適⽤
DB インストール/構築
OS パッチ適⽤
OS インストール
サーバーメンテナンス
ハードウェア資産管理
電源/ネットワーク/空調
お客様
スキーマのデザイン
クエリの作成
データベースの最適化
AWS
時間のかかる
データベース管理タスクから解放され、
アプリケーションやビジネスに集中できる
アプリケーション最適化

データベース運⽤負荷の軽減
SQL
キャッシュ
ライターインスタンス
SQL
キャッシュ
リーダーインスタンスリーダーインスタンス
SQL
キャッシュ
迅速なインスタンス追加

障害時の⾃動復旧①
SQL
キャッシュ
SQL
キャッシュ
SQL
キャッシュ

障害時の⾃動復旧②
SQL
キャッシュ
SQL
キャッシュ
リーダーインスタンスライターインスタンス
SQL
キャッシュ
通常30秒以内に完了

障害時の⾃動復旧③
SQL
キャッシュ
リーダーインスタンスライターインスタンス
SQL
キャッシュ
SQL
キャッシュ
リーダーインスタンス

ストレージ⾃動拡張①
SQL
キャッシュ
SQL
キャッシュ
SQL
キャッシュ
データが
増えた︕

ストレージ⾃動拡張②
SQL
キャッシュ
SQL
キャッシュ
SQL
キャッシュ
10GB単位で128TBまで⾃動的に拡張

バックアップ⾃動化
SQL
キャッシュ
SQL
キャッシュ
SQL
キャッシュ
Amazon Simple Storage
Service (Amazon S3)
継続的な増分バックアップ
・バックアップ保持期間は1〜35⽇
・保持期間内の任意の時点に復元できる

サーバレスデータベースとして
ワークロードの拡⼤

Amazon Aurora Serverless v2
アプリケーションのニーズに応じて⾃動的に容量を拡張
インスタンスタイプの⼀つとして簡単なセットアップ
秒単位のシンプルな従量課⾦
瞬時に拡張し、要求の厳しいアプリケーションをサポート
データベースのキャパシティ管理の⼼配からの解放

急激なアクセス増減対応の選択肢
Storage fleet
⾃動スケール

Storage fleet
Compute fleet
⾃動スケール
⾃動スケール

Storage fleet
Compute fleet
⾃動スケール
⾃動スケール
• インプレーススケール：CPUやメモリのリ
ソースなどを動的に追加することで、1秒以
内にスケーリングが可能
• パフォーマンス影響なし：数十万トランザク
ションを実行中でも、スケーリングによる影
響はない
https://aws.amazon.com/jp/blogs/news/amazon-aurora-serverless-v2-is-
generally-available-instant-scaling-for-demanding-workloads/

Aurora Serverless v2 のシームレスなスケーリング
Aurora Serverless v2 のスケーリング例 (定期的に同時実⾏数を上げながら OLTP 処理を実施)
同時実⾏数
が増加
同時実⾏数
が増加
同時実⾏数
が増加
処理終了
同時実⾏数が増加して、必要なリソースが
増加した時点で、Aurora Serverless v2の
キャパシティが増加(⻘線)
また、スケール時にトランザクション
(⾚線のCommitThroughput)を阻害しない
処理が終了して、リソースが不要
になると徐々にキャパシティが
減少(⻘線)

もっと Amazon Aurora Serverless v2 を知りたい⽅へ
https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html
ブログ
https://aws.amazon.com/jp/blogs/news/amazon-aurora-serverless-v2-is-generally-available-
instant-scaling-for-demanding-workloads/
Deep Dive
https://www.youtube.com/watch?time_continue=350&v=b2Tl6SsWC-M&feature=emb_title

• スタートアップにとって⼤事なことはビジネスにフォーカ
スできること
• スタートアップが技術選定の際に考えるべきこと
• Undifferentiated Heavy Lifting の排除
• ⽬の前の判断が Two-way Door なものではないか⾒極める
• まずは、Design for Failure な設計が組み込まれたサービ
スを選定できないか考える
さいごに – お伝えしたかったこと -

Thank you

Appendix 1.
簡易セキュリティチェック項⽬

簡易セキュリティチェック項⽬ 1/2
1. ルートユーザーにMulti-Factor Authentication (MFA) は設定していますか︖
2. Amazon S3 バケット許可は適切な設定になっていますか︖
すべてのユーザーにアップロードや削除のアクセス許可を付与していませんか︖
3. セキュリテイグループでリソースへの無制限アクセスを許可していませんか︖
4. セキュリティグループで特定のポートに無制限アクセスを許可していませんか︖
5. Amazon RDS セキュリティグループに対する過度なアクセス権限は設定されていませんか︖
特定のセキュリテイグループまたは特定のIPアドレスからのみの許可となっていますか︖

簡易セキュリティチェック項⽬に対するTo Do 1/2
1. ルートユーザーにMulti-Factor Authentication (MFA) は設定していますか︖
⇒ハードウェアまたは仮想デバイスのMFAトークンを使⽤することで、トークン所持者のみがログイン可能となります。
⇒参考ドキュメント︓AWS での多要素認証 (MFA) の使⽤
2. Amazon S3 バケット許可は適切な設定になっていますか︖
すべてのユーザーにアップロードや削除のアクセス許可を付与していませんか︖
⇒適切な権限を設定をすることで、意図しないファイルの読み取り・削除、不適切なファイルのアップロードから
守ることができます。
⇒参考ドキュメント︓Amazon S3のセキュリティベストプラクティス
3. セキュリテイグループでリソースへの無制限アクセスを許可していませんか︖
4. セキュリティグループで特定のポートに無制限アクセスを許可していませんか︖
⇒例えば、インバウンド通信でHTTPSのポート 443のみを許可することで、HTTPS以外の意図しない通信を
受け⼊れないようにできます。
⇒参考ドキュメント︓VPCのセキュリティのベストプラクティス
5. Amazon RDS セキュリティグループに対する過度なアクセス権限は設定されていませんか︖
特定のセキュリテイグループまたは特定のIPアドレスからのみの許可となっていますか︖
⇒必要なシステムに対してのみ許可することで、意図しないデータの参照・更新から
データベースを守ることができます。
⇒参考ドキュメント︓Amazon RDSのセキュリティのベストプラクティス

簡易セキュリティチェック項⽬ 2/2
6. IAM パスワードポリシーやパスワードコンテンツの要件は
有効化していますか︖
7. IAMアクセスキーは定期的にローテーションしていますか︖
8. AWS CloudTrail ロギングは有効化されていますか︖
9. ⾮推奨のランタイムを使⽤する AWS Lambda 関数はありませんか︖

簡易セキュリティチェック項⽬に対するTo Do 2/2
6. IAMパスワードポリシーやパスワードコンテンツの要件は有効化していますか︖
⇒容易に推測されないパスワードを使⽤することで、総当たり攻撃などからの耐性を強くすることができます。
⇒参考ドキュメント︓ IAM でのセキュリティのベストプラクティス
7. IAMアクセスキーは定期的にローテーションしていますか︖
⇒使⽤していないIAMアクセスキーを停⽌させましょう。使⽤している場合は、定期的にローテーションしましょう
⇒参考ドキュメント︓ IAM でのセキュリティのベストプラクティス
8. AWS CloudTrail ロギングは有効化されていますか︖
⇒CloudTrailはAWSインフラ全体での活動の証跡を記録します。万⼀の際の問題切り分けの⼿がかりの⼀つとなります。
⇒参考ドキュメント︓組織の証跡の作成
9. ⾮推奨のランタイムを使⽤する AWS Lambda 関数はありませんか︖
⇒⾮推奨のランタイムはすでにセキュリティパッチなどの提供を停⽌しています。
サポート中のランタイムへのアップデートを推奨します。
⇒参考ドキュメント︓ランタイムの⾮推奨化に関するポリシー

クラウドを積極活用したサービスの開発のために

Recommandé

Recommandé

Contenu connexe

Similaire à クラウドを積極活用したサービスの開発のために

Similaire à クラウドを積極活用したサービスの開発のために (20)

Plus de Yuichiro Saito

Plus de Yuichiro Saito (18)

Dernier

Dernier (10)