だまし売りNo

AWS Service Catalog はクラウドリソースのプロビジョニング用のサービス。エンドユーザーがIT serviceを自分で管理し、デプロイできるようにする。インフラ管理者が組織内での利用を許可するAWS serviceをカタログ化し、これにより組織内で利用可能なサービスを制限することでガバナンスを強化する。
サービスには仮想マシンイメージ、サーバ、ソフトウェア、DBから包括的な多層アプリケーションアーキテクチャまで様々なものが含まれる。利用できるIT serviceとそのバージョンや、提供されたサービスでの設定内容を制御できる。個人やグループ別にアクセス許可を付与する対象を管理できる。
IT管理者がエンドユーザー向けのクラウドリソースを全てプロビジョニングする必要はない。エンドユーザーは、日々の業務を遂行するために使用しなければならない承認済みIIT serviceを探して、自分でデプロイする。組織によって設定された制約に従い、必要な承認済みのサービスのみをデプロイする。

Service Catalogの利用手順は以下。
組織内で利用可能なAWSサービスの環境を構築するためのCloudFormation templateを作成する。
ポートフォリオという論理的なリソースを作成する。
製品という論理的なリソースを作成し、関連するCloudFormation templateを紐づけ、グルーピングする。
このポートフォリオの単位で組織内のエンドユーザーに使用許可を与え、利用可能なAWSサービスを制限できる。エンドユーザーはポートフォリオに含まれる製品から必要なものを選択し、製品経由でCloudFormationテンプレートを実行し、必要なAWSインフラを構築できる。
Service Catalogの起動制約には、エンドユーザーが製品を起動する時にAWS Service Catalog が引き受ける AWS IAM roleを指定する。起動の制約はポートフォリオ内の製品に関連付けられる。起動制約がない場合、エンドユーザーは各自の IAM 認証情報を使用して製品を起動し、管理する。
Service Catalog はStack Set Instance操作をサポートする。利用者はAWS Service Catalog管理者が指定した制約内で、Stack Set の個々のInstanceを制御できる。
Service Catalog の AppRegistry は、AWSでリソースコレクションを整理し、アプリケーションメタデータを管理するリポジトリを提供する。管理者は Service Catalog consoleを使用して、アプリケーション、アプリケーションメタデータ、リソースの関連付けを管理できる。

AWSにはDocker containerをサポートするcontainer orchestration service としてAmazon ECS; Amazon Elastic Container ServiceとAmazon EKS; Elastic Kubernetes Serviceがある。ECSにはEC2起動タイプとFargate起動タイプがある。
EC2起動タイプはEC2上にタスクとしてContainerをデプロイし、サービスをスケーリングすることで処理を分散する。Container自体がスケールし、ホストのリソースをひっ迫させた場合もホストするEC2自体がスケーリングするため、ワークロードに合わせたインフラストラクチャを利用できる。起動したEC2に対して費用が発生する。
EC2起動タイプはContainer実行環境であるホストマシンの管理・運用が必要である。インフラストラクチャを含めて設定を管理したい場合に利用する。
Fargate起動タイプはプラットフォームを含めてフルマネージドになる。ホストマシンを意識せずにContainerを実行できる。EC2 Instance typeの選択やクラスターのプロビジョニングとスケール、各サーバのパッチ適用と更新が不要。ユーザーはアプリケーションのデプロイに集中できる。AWS FargateはAmazon ECSとAmazon Elastic Kubernetes Service; EKS の両方で動作するContainer向けのサーバーレスコンピューティングエンジン。
Amazon ECSは、Amazon ECS タスク定義での Amazon FSx for Windows ファイルサーバーの使用をサポートする。これによってECS Container間で永続的な共有ストレージを使用できる。
ECSではIAMリソースポリシーを VPCエンドポイントにアタッチできる。インターフェイス VPC エンドポイントを使用するようにECSを設定することで、VPCとECS間のトラフィックをAmazonネットワークに制限してVPCセキュリティを向上させることができる。

AWSはDocker containerをサポートするcontainer orchestration service としてAmazon ECS; Amazon Elastic Container Serviceを提供する。ECSにはEC2起動タイプとFargate起動タイプがある。
EC2起動タイプはEC2上にタスクとしてContainerをデプロイし、サービスをスケーリングすることで処理を分散する。Container自体がスケールし、ホストのリソースをひっ迫させた場合もホストするEC2自体がスケーリングするため、ワークロードに合わせたインフラストラクチャを利用できる。起動したEC2に対して費用が発生する。
EC2起動タイプはContainer実行環境であるホストマシンの管理・運用が必要である。インフラストラクチャを含めて設定を管理したい場合に利用する。
Fargate起動タイプはプラットフォームを含めてフルマネージドになる。ホストマシンを意識せずにContainerを実行できる。EC2 Instance typeの選択やクラスターのプロビジョニングとスケール、各サーバのパッチ適用と更新が不要。ユーザーはアプリケーションのデプロイに集中できる。AWS FargateはAmazon ECSとAmazon Elastic Kubernetes Service; EKS の両方で動作するContainer向けのサーバーレスコンピューティングエンジン。
Amazon ECSは、Amazon ECS タスク定義での Amazon FSx for Windows ファイルサーバーの使用をサポートする。これによってECS Container間で永続的な共有ストレージを使用できる。

AWSはMQ; Message Queue のマネージドサービスとして、Amazon SQS; Simple Queue ServiceやAmazon MQを提供する。MQの利用によって疎結合アーキテクチャの実装が容易になる。
Amazon MQ は、Apache ActiveMQやRabbitMQというオープンソースメッセージブローカーをプロビジョニングおよび管理するフルマネージドサービス。メッセージブローカーはAmazon EFS; Elastic File Systemによって耐久性を有し、メッセージは複数のAZに冗長に保存する。

AWSはEmailのサービスとしてAmazon SES; Simple Email Serviceを提供する。Amazon SESでは利用者が自分の連絡先リストを管理できる。連絡先リストにはエンドユーザー情報とそのユーザーに関連するトピックが含まれている。Amazon SESではEmailフッターのサブスクリプション解除リンクやlist-unsubscribeヘッダーを追加できる。Amazon SESはエンドユーザーのサブスクリプション設定に基づいてリストを自動的に更新する。

Amazon API Gatewayでは、デフォルトで自動生成されたHTTP APIやREST APIのEndpointを無効化できる。API Gateway のデフォルトの REST API Endpointは「https://{restapi_id}.execute-api.{region}.amazonaws.com」となる。この機能はAPIにカスタムドメイン名を使用し、APIへの全てのトラフィックをデフォルトのEndpointではなくカスタムドメイン名のみを通過するようにしたい利用者向けである。

gRPC はトランスポートに HTTP/2 を使用し、マイクロサービスベースのアーキテクチャ上に構築されたアプリケーションのサービス間通信で普及しつつある。AWSのALBはgRPCプロトコルをサポートする。ALBを使用してマイクロサービス間または gRPC 対応のクライアントとサービス間でgRPCトラフィックをルーティング及び負荷分散できる。

【AWS Service Catalog】
AWSはクラウドリソースのプロビジョニングのためにAWS Service Catalogを提供する。AWS Service Catalog はStack Set Instance操作をサポートする。利用者はAWS Service Catalog管理者が指定した制約内で、StackSet の個々のInstanceを制御できる。

クラウド時代はセキュリティの考え方が変わっていく。これまではファイアウォールや非武装地帯DMZ; Demilitarized Zoneなど社内と社外にネットワーク的な境界線を設け、内と外で対策を切り替える境界防御が中心であった。しかし、クラウド時代は境界防御だけでは守ることはできない。
クラウドはFirewallの外側にあるため、別の方法が必要になる。BYODからO365やSalesForceなどのクラウドサービスにアクセスする場合は、オンプレミスのFirewallは意味を持たなくなる。そこではアイデンティティが新たな境界線になる（Identity as a new perimeter）。ID管理サービスIDaaS; Identity as a Serviceが重要になる。
セキュリティでは認証と認可は区別される。
認証は識別して特定すること。
認可（承認）は認証されたユーザーやデバイスにアクセス権を与えること。
認証サーバと認可をするアプリケーションサーバは分離する。
役割ベースのアクセスコントロールRole Based Access Control; RBACは、アクセス制御の手法の一つ。ユーザーと権限を直接紐付けず、間にロールを挟みこむことで権限管理をシンプルにする。リソースに対して直接アクセス権を割り当てるのではなく、リソースに対してロールを割り当てる。これは認証と認可の分離に直結する。

Azure Service HealthはAzureサービスの正常性のモニタリングツール。サービスのインシデントと計画メンテナンスを通知する。Service Health ダッシュボードの起動は、ポータルのダッシュボードにある [Service Health] タイルを選択する。Service Health Alertを設定し、サービスの問題、計画メンテナンスなどの通知を受け取ることも可能。

Microsoft Service Trust Portal; STPはMicrosoft Cloud Service全体の監査レポートを掲載する。Compliance Manager Serviceをホストしている。一部のリソースにアクセスするためには、Microsoftクラウドサービスアカウントを使用して認証済みユーザーとしてログインし、法令遵守のためのMicrosoftの機密保持契約書を確認して同意する必要がある。

AzureはMicrosoftのPublic Cloud Serviceである。Azureは多種多様なサービスを提供する。その進化のスピードが速く、新機能の追加が頻繁に発表されている。AzureのサービスはPrivate Preview, Public Preview, GA; General Availabilityを経る。プレビューにはPrivate PreviewとPublic Previewがある。Private Previewは特定の顧客のみ利用できる。Public PreviewはPortal上に「プレビュー」と表示される。Azure Portalにもプレビューがある。原則としてPreviewは無償であるが、GAは有償になる。
Azureの技術サポートは有償である。Basicは技術サポートなし。
有償サポートのレベルにはDeveloper, Standard, Professional Direct, Premierがある。
有償サポートプランは無料Basicサポートを拡張する。
Developerは営業時間のメール問い合わせのみ。
Standardは24時間365日で電話のサポートも受けられる。
Azureの契約はAzureの使用権が含まれる。課金はSubscriptionに対してなされる。部署毎に課金を分ける場合はSubscriptionを分ける。SubscriptionとAzure Active Directory; AADの関係は一対一ではない。一つのAADに複数のSubscriptionを紐づけることができる。一つのSubscriptionが複数のAADに紐づくことはない。
前払いする場合はAzure予約で価格の割引を受けることができる。Cloud Solution Provider; CSP経由でAzureを利用する場合は、請求もCSP経由になる。
Azureは管理グループ、Subscription、Resource Group、Resourceの階層構造になっている。管理グループは複数のAzureサブスクリプションを管理できる。管理グループだけが階層構造にすることができる。
ResourceはResource Groupに所属する。Resource Groupはライフサイクルが同じResourceを所属させることがベストプラクティス。一つのResourceが複数のGroupに所属することはできない。Resource Groupは1階層のみ。Resource GroupはSubscriptionに所属する。Subscriptionは管理グループに所属する。

AWS DMS; Database Migration ServiceはDBデータの移行サービス。Source Data StoreからTarget Data Storeへデータを移行する。この2つのData StoreはEndpointと呼ばれる。

移行中もSource DBは完全に利用可能な状態に保たれ、DBを利用するアプリケーションのダウンタイムを最小限に抑えられる。TargetにはEC2やRDS、オンプレミスのDBを使用できる。

AWS DMS タスクではSource Data Storeへの継続的な変更をキャプチャすることができる。サポートされているターゲットデータストアへの初回（全ロード）の移行が完了した後で、継続的な変更をキャプチャするタスクを作成することもできる。このプロセスは継続的なレプリケーションまたは Change Data Capture; CDC と呼ばれる。AWS DMS では、このプロセスを使用してSource Data Storeの継続的な変更をレプリケートする。