2020年6月20日土曜日

Auroraを選ばずにRDSを選ぶ理由

Auroraの方がメリットいっぱいですが、ある意味当たり前でAWS謹製ってやつですからね。

クラスメソッドの記事でもあります。

RDSを敢えて使うとしたら理由は
・バージョンを選びやすい
・料金が20%くらい安い
ということでしょうか。


自分が調べていて見つけたRDSを使うメリットですが、
オンプレミスでリードレプリカが作れるということです。

まぁメリットなんでしょうか。そういう事情もあるのかもしれません。対してAuroraはオンプレミスでは動かせないはずです。


2020年6月17日水曜日

AWS スポットブロック(継続期間)の料金について


スポットインスタンス の継続期間の定義
継続期間 (スポットブロックとも呼ばれます) が定義された スポットインスタンス は、中断されることがなく、選択した期間にわたって継続して実行されます。このようなインスタンスは、バッチ処理、エンコードとレンダリング、モデリングと解析、継続的な統合など、完了までに一定の時間のかかるジョブに最適です。
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/spot-requests.html
スポットインスタンスで、1〜6時間分を確約できる設定です。料金はどれくらいかというと、1時間のスポットブロックで、リザーブドインスタンスの1年より少し安いくらいでした。 

t3.medium 東京で比較


 料金/時間 USD 割引率
 オンデマンド        0.0544  -
 Spot     0.0163 70% 
 Spot 継続1時間  0.03 55% 
 Spot 継続6時間  0.03830% 
 リザーブド 1年40%
リザーブド 3年  60%


2020年6月16日火曜日

IAM trustポリシー、service-linkedロールについて

こちらが良いかも


ーー

ややこしいのでまとめました。


リソースベースポリシーはTrust Policy

リソースベースのポリシーは、Amazon S3 バケットなどのリソースにアタッチする JSON ポリシードキュメントです。
リソースベースのポリシーはインラインポリシーです。リソースベースの管理ポリシーはありません。
IAM サービスは、ロールの信頼ポリシーと呼ばれるリソースベースのポリシーのタイプを 1 つのみサポートします。

信頼ポリシーは他にもあるけど、リソースベースのポリシーは信頼ポリシーしかないです。つまり十分条件ですね。つまり、他のリソースがアクセスすることを信頼するポリシーです。

IAM信頼ポリシー

あるPrincipalが、ロールや認証を引き受けることができるように許可するポリシー。 

この1文がわかりやすかったです。『Trust policyでは、管理者がEC2インスタンスだけにロールを引き受けさせることができます。』

In the role's trust policy, the administrator specifies that only EC2 instances can assume the role. https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-ec2.html 


同じページからポリシーの例。
Principalはec2で、sts:AssumeRoleをAllowしている。 

The abcd role must trust the Amazon EC2 service to assume the role. To do this, the abcd role must have the following trust policy: 

Account 111111111111 abcd Role Trust Policy 


    "Version": "2012-10-17", 

    "Statement": [ 

        { 

            "Sid": "abcdTrustPolicy", 

            "Effect": "Allow", 

            "Action": "sts:AssumeRole", 

            "Principal": {"Service": "ec2.amazonaws.com"} 

        } 

    ] 


Service-linked role 

(「サービスにリンクされたロール」と訳されている。)

あるAWSサービス(1)が他のAWSサービス(2)にアクセスできるようになるためのrole。 
このロールがつくサービス(1)は「trusted service」と呼ばれる。

- AWS Organizationで設定する
- 1つのサービスに限定して作成する
- ロールの管理が楽になる(Organizationzで設定するから)
- 権限のエスカレーションができないので安全
- 他のIAMのパーミッションには影響しない
- このロールの削除は対象のリソースを削除してからでないとできません。

使えるサービスは表になっている。最初はlexだけだったそうです。 
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html 

Service-linked roleを使う設定

あるAWSサービス(trusted serviceと呼ぶ)でservice-linked roleをアタッチするとする。trusted serviceが別のAWSサービスにアクセスできるようにする設定をtrusted accessと呼ぶ。  

条件: 
・AWS Organizationが使えること。 
・Trusted serviceが使えること。 


方法: 
Trusted access を有効にすることで、 trusted serviceが有効にできる。パーミッションの設定を行う。 

organizations:EnableAWSServiceAccess 
organizations:ServicePrincipal 
organizations:ListAWSServiceAccessForOrganization 


詳細は こちらで。
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_integrate_services.html?icmpid=docs_orgs_console 

 

 
 

2020年6月12日金曜日

AWSのManagersとAgentという名前のサービスがconfusingなのでメモ

※Managerはサービス、Agentはスタンドアロンのアプリケーション


Resource Access Manager(RAM)

AWS アカウント全体または組織内でリソースを安全に共有できます。リソースを一元的に調達し、RAM を使用して他のアカウントとリソースを共有できるため、アカウントごとにリソースをプロビジョニングして管理する必要がありません。

Systems Manager (SSM)

複数の AWS のサービスの運用データを一元化し、AWS リソース全体のタスクを自動化できます。


Systems Manager Session Manager

セッションマネージャーは、完全に管理された NoSQL データベースサービスのひとつで、インタラクティブなブラウザベースのシェルおよび CLI を使用することができます。また、このサービスでは、安全で監査可能なインスタンス管理を行うのに役立ちます。ポートを開くほか、踏み台ホストを管理したり SSH キーを管理したりする必要はありません。セッションマネージャーは、インスタンスへの制御されたアクセスを必要とする企業ポリシーに準拠し、インスタンスアクセスのセキュリティと監査性を向上させると同時に、エンドユーザーにシンプルでクロスプラットフォームのインスタンスアクセスを提供します。

Systems Manager Patch Manager

選択したオペレーティングシステムとソフトウェアのパッチを、Amazon EC2 またはオンプレミスの大規模なインスタンスグループに自動的にデプロイできます。パッチベースラインによって、オペレーティングシステムパッチや重要度の高いパッチなど、インストールする特定のパッチのカテゴリを自動承認するためのルールを設定できます。


Systems Manager State Manager
AWS Systems Manager ステートマネージャー は、安全でスケーラブルな設定管理サービスであり、Amazon EC2 およびハイブリッドインフラストラクチャを、定義された状態に保つプロセスを自動化します。
-起動時に特定のソフトウェアを使用してインスタンスをブートストラップする
-定義済みのスケジュールに従ってエージェント (SSM エージェント など) をダウンロードして更新する
-ネットワーク設定を構成する
-インスタンスを Windowsドメインに結合する (Windows Server インスタンスのみ)。
-ライフサイクルを通じてソフトウェアの更新でインスタンスをパッチする
-ライフサイクルを通じて Linux および Windows マネージドインスタンスでスクリプトを実行する



Tag Manager

AWS Tag Managerというサービスは存在しません。Tag Editorはあります。

Secrets Manager

アプリケーション、サービス、IT リソースへのアクセスに必要なシークレットの保護を支援します。DBの認証情報、API キー、その他のシークレットをそのライフサイクルを通して容易にローテーション、管理、取得できるようにします。ローテーションできるのが特徴。

Secrets ManagerとSSM Parameter Store の違い



License Manager

AWS およびオンプレミス環境全体で、Microsoft、SAP、Oracle、IBM などのソフトウェアベンダーからのソフトウェアライセンスを簡単に管理できるようにするサービスです。


===

統合CloudWatch Agent

EC2インスタンスとオンプレミスサーバーから、より多くのメトリクスとログを収集する。サーバにインストールする。Linux、Windows両方で稼働。
統合〜は新しい。以前はCloudWatch Logsエージェント(ログのみ)。

Kinesis Agent

Amazon Kinesis エージェントは、データの収集および Amazon Kinesis データストリームへのデータの送信を容易にする、ビルド済みの Java アプリケーションです。スタンドアロン。サーバにインストールする。

AWS OpsWorks スタック エージェント CLI

AWS OpsWorks スタックによってすべてのインスタンスにインストールされるエージェントは、コマンドラインインターフェース (CLI) を公開しています。SSH を使用してインスタンスにログインすると、CLI を使用して次の操作を実行できます。

Chef 実行のログファイルにアクセスする.
AWS OpsWorks スタックコマンドにアクセスします。
Chef レシピを手動で実行する.
インスタンスレポートを表示する.
エージェントレポートを表示する.

スタック設定およびデプロイ属性の制限されたセットを表示する。


Systems Manager Agent

EC2、オンプレミスサーバ、VMでSystemsManagerを使ってupdate, manage, configureをするためにインストールする。多くのAMIではプリインストールされているが、そうではないものや、オンプレミス、VMでは自分でインストールする。