前提となる知識の理解
以下の資料を読んで理解を深めた。
アマゾン ウェブ サービスの概要
20180411 AWS Black Belt Online Seminar Amazon EC2
リージョンとアベイラビリティーゾーン - Amazon Elastic Compute Cloud
AWSにおけるマルチアカウント管理の手法とベストプラクティス
AWS アカウント ID とその別名 - AWS Identity and Access Management
AWS Black Belt Online Seminar AWS Identity and Access Management (AWS…
RegionとAvailability Zone
- AWS クラウドインフラストラクチャはリージョンとアベイラビリティーゾーン (AZ) を中心として構築される。
- リージョンは2つ以上のAZ から構成されている（ローカルリージョンを除く）。各リージョンは、他のリージョンと完全に分離されるように設計されている。
- 各AZは互いに影響にを受けないように、地理的・電源的・ネットワーク的に独立している。AZ間は低遅延の高速専用線で繋がれている。
- AZ は 1 つ以上の独立したデータセンターで構成される。各データセンターは、冗長性のある電源、ネットワーキング、および接続性を備えており、別々の設備に収容されている。このような AZ によって、お客様は単一のデータセンターでは実現できない高い可用性、耐障害性、および拡張性を備えた本番用のアプリケーションとデータベースを運用できる。
- AZはAWS上ではリージョンコードとそれに続く文字識別子によって表されます (us-east-1a など)
- 東京リージョンのリージョンコードはap-northeast-1で大阪ローカルリージョンのリージョンコードはap-northeast-3となっている。
Account
- AWSアカウントはAWSアカウントIDによって一意に識別される。全てのAWS製品の中で一意であれば、AWS アカウントの別名を作成することもできる（ただし一つまで）
- AWSアカウントとは、”リソース管理の単位”かつ”セキュリティ上の境界”であり、”AWS課金単位”でもある。
- 単一でなく、複数のAWSアカウントの使用がAWSゴールドパートナーであるNRIさんの推奨である。
- 複数のAWSアカウントを用いる理由（メリット）
- ガバナンスの観点
- 本番環境の管理コンソール(後述)を分離できる
- 本番環境と非本番環境を管理するメンバーとで明確な権限の分離
- 環境間におけるセキュリティ対策の分離が可能
- 課金の観点
- 組織の観点
- 異なるLOBを異なる課金管理と共にサポートすることができ、LOB単位での管理を容易に行うことができる
- 統制や課金が異なる専用アカウントを用いる個々の顧客に対してサービスプロバイダー型のサービスを提供しやすい
- 運用の観点
- ガバナンスの観点
サービスにアクセスする方法
AWS IAM (Identity and Access Management)
- AWS操作をよりセキュアに⾏うための認証・認可の仕組み
- AWS利⽤者の認証と、アクセスポリシーを管理
- AWS操作のためのグループ・ユーザー・ロールの作成が可能
- グループ、ユーザーごとに、実⾏出来る操作を規定できる
- ユーザーごとに認証情報の設定が可能
AWSアカウント（root）ユーザー
- AWSアカウント作成時のID
- アカウントの全ての AWS サービスとリソースへの完全なアクセス権限を持つ
- アカウントの作成に使⽤したメールアドレスとパスワードでサインイン
- ⽇常的なタスクには、それが管理者タスクであっても、root ユーザーを使⽤しないことを強く推奨
- AWSのroot権限が必要な操作
- AWS ルートアカウントのメールアドレスやパスワードの変更
- IAMユーザーの課⾦情報へのアクセスに関するactivate/deactivate 等々…
- AWSルートアカウントはIAMで設定するアクセスポリシーが適⽤されない強⼒なアカウントであるため、⼗分に強度の強いパスワードを設定した上、通常は極⼒利⽤しないような運⽤をする。Security CredentialのページからAccess Keyの削除を行う。
IAMユーザー
IAMグループ
- IAMユーザーをまとめるグループ(1AWSアカウント毎に100グループまで作成可能)
- グループ毎にグループ名/パス(オプション)/パーミッション
IAMで使⽤する認証情報
- アクセスキーID/シークレットアクセスキー(2つまで) = REST,Query形式のAPI利⽤時の認証に使⽤
- X.509 Certificate = SOAP形式のAPIリクエスト⽤
- AWSマネジメントコンソールへのログインパスワード
- 多要素認証（MFA）
アクセス条件の記述
AWS CloudTrail
- AWSアカウントで利⽤されたAPI Callを記録し、S3上にログを保存するサービス。
- AWSのリソースにどのような操作が加えられたか記録に残す機能であり全リージョンでの有効化を推奨。
- 適切なユーザーが与えられた権限で環境を操作しているかの確認と記録に使⽤。
- 記録される情報
IAMロール
AWS STS(Security Token Service)
- ⼀時的に利⽤するトークンを発⾏するサービス
- ユーザーに対して、以下の3つのキーを発⾏
- アクセスキー：（ASIAJTNDEWXXXXXXX）
- シークレットアクセスキー：（HQUdrMFbMpOHJ3d+Y49SOXXXXXXX）
- セッショントークン（AQoDYXdzEHQ……1FVkXXXXXXXXXXXXXXXXXXXXXXXX）
- トークンのタイプにより有効期限は様々
AWSを運用する上での常識を身につける
以下の資料を読んで理解を深めた。 (英語のホワイトペーパーは読めてない)
20180403 AWS White Belt Online Seminar AWS利用開始時に最低限おさえておきたい10のこと
AWS Well-Architected Framework
AWS Black Belt Online Seminar 2016 AWS CloudTrail & AWS Config
Amazon RDS 入門
セキュリティ
- AWSルートアカウントは極力使用しない
- 十分に強度の強いパスワードを設定した上で多要素認証（MFA）で保護し、通常は極力使用しない運用を行う。
- Security CredentialのページからAccess Keyの削除を行う。
- ユーザには最小限の権限を付与する
- IAMユーザとIAMグループを利用する
- 最小限のアクセス権を設定し、必要に応じて追加のアクセス権限を付与する。
- 特権のあるIAMユーザ（機密性の高いリソースやまたはAPIにアクセスが許されているユーザ）に対してはMFAを設定する
- 認証情報を定期的にローテーションする
- 認証情報を埋め込まない
- 証跡取得（ログ取得）
- 各レイヤでのセキュリティ対策
- ネットワークレイヤ（ネットワークACL）
- VPCのサブネット単位で設定するステートレスなファイアーウォール
- ベースラインとなるポリシーを設定するのに用いる
- Amazon RDS / EC2などのリソース（セキュリティグループ）
- インスタンス（グループ）単位に設定するステートフルなファイアーウォール
- サーバの機能や用途に応じたルール設定に適している
- AWS WAF
- ウェブアプリケーションを対象とした悪意のあるリクエストを検出し、ブロックすること助ける
- SQLインジェクションやXSSといった一般的なウェブの弱点から保護するためのルールを作成
- ALB(Application Load Balancer)とCloudFrontに設定できる
- AWS Shield
- DDoS攻撃に対する保護サービス
- ネットワークレイヤ（ネットワークACL）
コスト最適化
- 適切なサイジング
データのバックアップ
- EC2のAMI(Amazon Machine Image)を作成。
- EBSのスナップショットを取得。作成時はデータ整合性を保つために静止点を設けることを推奨
- RDSの自動バックアップ機能
障害や不具合への対策
- ELB(Elastic Load Balancing)の活用
- AutoScalingの活用
- EC2 AutoRecoveryの活用
Amazon VPC(Virtual Private Cloud)
以下の資料を読んで理解を深めた。
20180418 AWS Black Belt Online Seminar Amazon VPC
AWS Black Belt Online Seminar 2016 AWS CloudFormation
概要
- AWS クラウドの論理的に分離されたセクションをプロビジョニング(※1)し定義した仮想ネットワーク内の AWS リソースを起動することができる
- 独自の IP アドレス範囲の選択、サブネットの作成、ルートテーブル、ネットワークゲートウェイの設定など、仮想ネットワーク環境を完全にコントロールできる
- VPC のネットワーク設定は容易にカスタマイズすることができる。たとえば、インターネットとのアクセスが可能なウェブサーバーのパブリックサブネットを作成し、データベースやアプリケーションサーバーなどのバックエンドシステムをインターネットとのアクセスを許可していないプライベートサブネットに配置できる。
- 既存のデータセンターと自分の VPC 間にハードウェア仮想プライベートネットワーク (VPN) 接続を作成することができるので、AWS クラウドを既存のデータセンターを拡張するかのように活用することができる。
※1 プロビジョニング:
必要に応じてネットワークやコンピューターの設備などのリソースを提供できるよう予測し、準備しておくこと
↓あとでそれぞれの項目を補足する
インターネット接続VPCのステップ
- アドレスレンジの選択
- 推奨: /16 65,534アドレス
- AZに於けるサブネットの選択
- インターネットへの経路を設定
-
|ネットワークACL |セキュリティグループ| |:--:|:--:| |サブネットレベルで効果|サーバレベルで効果| |Allow/DenyをIN・OUTで指定可能(ブラックリスト型)|AllowのみをIN・OUTで指定可能(ホワイトリスト型)| |ステートレスなので、戻りのトラフィックも明示的に許可設定する|ステートフルなので、戻りのトラフィックを考慮しなくて よい| |番号の順序通りに適用|全てのルールを適用| |サブネット内のすべてのインスタンスがACLの管理下に入る|インスタンス管理者がセキュリティグループを適用すればその管理下になる|
VPCとのプライベート接続
VPC設計のポイント
- CIDR(IPアドレス)は既存のVPC、社内のDCやオフィスと被らないアドレス帯をアサイン
- 複数のアベイラビリティゾーンを利用し、可用性の高いシステムを構築
- パブリック/プライベートサブネットへのリソースの配置を慎重に検討
VPCと他サービスとのやり取り
- サービスによってVPC内と外のどちらにリソースやエンドポイントが存在するかが異なる
- VPC Endpointは、グローバルIPをもつAWSのサービス（例えば、DynamoDB / Lambda / S3 / SQS 等…）に対して、VPC内部から直接アクセスするための出口です。
- VPC EndpointはGateway型の動作とPrivateLink (Interface型)の動作に分かれる
NATゲートウェイ
- AWSによるマネージドNATサービス
- プライベートサブネットのリソースがインターネットまたはAWSクラウドへ通信するために必要
- アベイラビリティゾーン毎に設置するのがベストプラクティス
- Elastic IP（固定グローバルIPアドレス）の割当て可能
VPC Flow Logs
- ネットワークトラフィックをキャプチャし、CloudWatch LogsへPublishする機能
- ネットワークインタフェースを送信元/送信先とするトラフィックが対象
- セキュリティグループとネットワークACLのルールでaccepted/rejectされたトラフィックログを取得
- 運用例：Elasticsearch Service + kibanaによる可視化
Amazon ECS(Elastic Container Service)
以下の資料を読んで理解を深めた。
20180220 AWS Black Belt Online Seminar - Amazon Container Services
20180313 Amazon Container Services アップデート
What is Amazon Elastic Container Service? - Amazon Elastic Container Service
Task Definition Parameters - Amazon Elastic Container Service
Amazon EC2 Container Service(ECS)の概念整理 - Qiita
概要
- Amazon EC2 Container Service (ECS) は、Docker コンテナをサポートするスケーラビリティに優れた高性能なコンテナ管理サービス
- Amazon EC2 インスタンスのマネージド型クラスターで簡単にアプリケーションを実行できる
- 簡単な API 呼び出しで、Docker が有効なアプリケーションを起動および停止したり、クラスターの完全な状態を問い合わせたり、セキュリティグループ、Elastic Load Balancing、Amazon Elastic Block Store (Amazon EBS) ボリューム、AWSIdentity and Access Management (IAM) ロールなどの機能にアクセスすることができる
- Amazon EC2 Container Registry (ECR)
- 開発者が Docker コンテナイメージを簡単に保存、管理、デプロイできる完全マネージド型の Docker コンテナレジストリ
コンテナを利用した開発に必要な技術要素
Task: コンテナ(群)の実行単位
- Task Definitionの情報から起動される
- Task Definitionとは、jsonフォーマットのテキストファイルで、これは１つ以上（最大１０）のコンテナーを記述できる
- 記述するパラメータは以下のようなものがある
- family : タスク定義の名前で、この名前をベースにシーケンシャルにリビジョンナンバーが付与される
- taskRoleArn : タスク定義を登録するときに、IAM タスクロールを割り当てて、タスクのコンテナに、関連するポリシーに指定された AWS API を呼び出すためのアクセス権限を付与できる。
- executionRoleArn : タスク定義を登録するとき、タスクのコンテナがユーザーに代わってコンテナイメージを取得して、CloudWatch にコンテナログを発行するためのタスク実行ロールを提供することができる
- networkMode : タスクのコンテナで使用する Docker ネットワーキングモード。有効な値は、none、bridge、awsvpc、および host です。Fargate 起動タイプを使用している場合、awsvpc ネットワークモードが必要。
- containerDefinitions
- Task内のコンテナ群は同じホスト上で実行
- CPUとメモリの上限を指定し、それをもとにスケジュールする。
Service : ロングランニングアプリ用スケジューラ
- Taskの数を希望数に保つ
- Task Definitionを新しくするとBlue/Greenデプロイ
- ELBと連携することも可能
- メトリクスに応じてTask数のAuto Scalingも可能
IAM Role: Task毎に異なる権限のAWS認証が可能
※ タスクの単位について
例えば、裏にいるAPIをCallしてWEB UIを提供するもので、expressのアプリケーション のコンテナとnginx(expressにプロキシする） のコンテナで構成されるFront Serviceがある場合には、expressコンテナとnginxコンテナはTaskという単位でくくられる。
コンテナの数をAuto Scalingさせる
- 何らかのメトリクス(例えば、コンテナのCPU・メモリ使用率 / リクエスト数)に応じて、コンテナの数を自動スケールさせたい
- コントロールプレーンの課題 : メトリクスの変化に対して、コンテナ数をどの程度変化させるのか
- データプレーンの課題 : コンテナのスケールに応じて、インスタンス数もスケールが必要
→ ECSのTarget TrackingとFargateの組合せがオススメ
Target Trackingとの連携
- メトリクスに対してターゲットの値を設定するだけ(例: CPU使用率 50%)
- その値に近づく様に、Application AutoScalingが自動的にServiceのDesiredCountを調整
Fargateを利用したコンテナAuto Scalingの優位性
- Serviceのスケールに応じて自然にコンテナが起動・終了する
- コンテナの起動時間に対してのみ課金
