A day without laughter is a day wasted. -15ページ目

A day without laughter is a day wasted.

その昔、チャップリンが言ったらしい。

s3 Access Points:複数のアプリがある場合、各アプリ毎にs3へのアクセス制御を行いたい場合に利用

 

s3バージョニングが有効な場合、上書き、削除時などに旧バージョンが残る

 

s3 awsコマンドを使うと自動的にマルチパートアップロードが適用される

 

s3 Transfer Acceleration:アップロードの高速化ができる(CloudFront)

 

s3は、可用性フォー9、耐久性イレブン9

 

ec2は、ユーザデータを使うと初回起動時に構成スクリプトを実行できる

 

ec2のdedicated hostsはどのHWを占有しているかも分かる

 

DynamoDBは、ショッピングカート用としてつかわれていた。

 

インターネットゲートウェイ:インターネット接続ルータのようなもの

VPC毎にインターネットゲートウェイを作成

 

ENI(Elastic Network Interface)は、EC2の仮想NIC

プライベートIP、ElasticIP、MACアドレスを保持する

 

通信制御

・セキュリティグループはインスタンスに設定する

・ACLはサブネットに設定する

基本的には、セキュリティグループを使うことを推奨

 

仮想プライベートゲートウェイ

VPCと他のネットワークをつなぐ(オンプレ)

VGWーVPN接続ーカスタマーゲートウェイ

 

DirectConnect(DX)

専用線を用いてオンプレをつなぐ

パプリックVIFを使うと、直接s3接続できる

 

VPCピア接続

共通サービスを、いろいろなVPCへ提供する場合などに利用

IP空間は重複不可(CIDRブロックを重複させない)

推移的(中継)なピア接続は不可(直接ピア接続が必要)

 

TransitGateway

フルマネージド型で可用性の高いルーティングサービス

直接VPCピアを貼らなくても、単一のゲートウェイで相互接続可能

ルートテーブルを複数作成することができる

 

VPCエンドポイント

EC2からVPC外のAWSサービスにプライベートアクセス

APIアクセスするs3やDynamoDBなど

・ゲートウェイ型(s3、DynamoDB)

 ルートテーブルが必要

・インターフェイス型

 

可用性99.99% 1年で50分

 

リージョンを跨いだルーティングはRoute53を利用する

 

SAML

オンプレのActiveDirectoryで管理しているユーザを活用できる

ADFS:フェデレーションサービスで、AWS連携設定を事前に行う

ADのグループと、AWSのロールを紐づけておく

 

Cognito

ウェブ、モバイルアプリの認証、認可、ユーザ管理マネージドサービス

 

aws Organization OUにSCP(ポリシー)を適用することで、組織単位で権限コントロール

SCPで制限されたルール内で、自由にAWSアカウントないでIAMロールなどの権限設定ができる

 

CloudFormationはテンプレートと環境の差異(ドラフト)を検出できる

 

運用の自動化は、systems managerで行う。

設定の自動化、セキュリティパッチ適用など

 

キャッシュ

・ElasticCache:Memcached、Redisのマネージドサービス

・CloudFront:コンテンツ配信キャッシュ

 

SQS:1対1、プル型キュー

SNS:1対多、プッシュ型通知

 

Fargate: EKS, ECS

EC2環境で動かすか、Fargate環境で動かすか決められる

SQSにおいて、処理が完了したらメッセージを削除しないと、キューの期限が切れるまで繰り返し処理が実行される。

 

SQS、ロングポーリングはキューが空でも待機時間だけ待ってからレスポンスを返す。

 

SQSの標準キューはS3イベントと連携可能

 

SQSでメッセージが受信された直後は削除されるまでキューに残ったままになる。

その間に他のコンシューマが同じメッセージを処理しないように、可視性タイムアウトを設定している。

可視性タイムアウト:他のインスタンスからは一定時間キューが見えなくなる機能

可視性タイムアウトが経過すると、他のコンシューマも見えるようになり、処理が実施される。

 

SQSのFIFOキューは300メッセージ/秒をサポート。

ただし、バッチアクションにより最大10個までのメッセージをバッチ処理可能。

300*10メッセージ/秒までを処理することが可能。

 

S3バケットをオリジンとしてCloudFrontディストリビューションを利用することで、S3へのアップロード、ダウンロードが高速化される。

CloudFrontは、コンテンツ配信ネットワーク(CDN)サービス。

また、S3 TransferAccelerationを有効にすると高速化が可能。

 

EC2のAutoScalingによりインスタンス数が拡張され、利用コストが増大する場合、

特にネットワーク転送アウトが高い場合は、

CloudFrontのグローバルキャッシング機能によりコスト低減が期待できる。

 

ELBをオリジンとしてCloudFrontを設定することで、異なるAZにあるEC2インスタンスから配信させることができる。

 

Route53リゾルバーでインバウンド、アウトバウンドのエンドポイントを設定し、オンプレのDNSリゾルバと疎通出来るようにすることで、オンプレからVPC内の名前解決が可能。

 

CloudFrontのキャッシュコントロールのmax-ageディレクティブで、キャッシュの保存期間を決める。

 

CloudFrontの料金は、AWSからのデータ転送とコンテンツ配信のリクエスト数に応じて変動する。また、エッジの場所によって価格は異なる。

 

CloudFrontはセキュリティグループによるアクセス制御は行えない。オリジンアクセスIDというユーザを作成し、バケットポリシーの設定にて制御する。

 

CloudFrontとの連携について、オリジンがELBの場合ACMを用いて証明書の設定が可能。オリジンがELBではない場合は、ACMではなくサードパーティ証明書の設定が必要。

 

Lambdaは、C#、Go、Java、Node.js、Python、Ruby対応。

 

Lambda Layerは、複数のLambda関数でライブラリを共有できる。(パッケージング化しなくてよい)

 

DynamoDBストリームを利用して、データ格納完了時にSNSでメール通知が可能。

RDSではクロスリージョンリードレプリカを使用して、別リージョンでの読込処理高速化ができる。

 

RDSスケールアップは、インスタンスサイズ変更、インスタンスタイプ変更、ストレージタイプ変更などがある。

 

RDSの暗号化はインスタンスの作成時に実施。(スナップショットから復元して、既存のRDSは終了する)

 

RDSのポイントインタイムリカバリは、スナップショットとトランザクションログを用いて5分前の状態に戻せる。

 

EBSのスナップショット管理自動化は、Data Lifecycle Managerを使用する。

 

ALB,NLBは、IPアドレスを指定可能なので、VPCピアリングされたインスタンスへのルーティングもできる。

 

ELBは、異なるリージョンに展開されたターゲットを分散出来ない。

 

クロスゾーン負荷分散:通常は、異なるAZで均等に負荷を分散するが、クロスゾーン負荷分散では異なるAZに存在するインスタンス毎に均等に負荷を分散する

 

NLBはTLSリスナーを使う、ALBはHTTPSリスナーを使う

 

Connection Draingは、インスタンスが登録解除、異常発生したときに新規リクエストを中止することで、処理中のリクエストがドロップされないようにする。

 

無くなりはしないようです。

あくまでも、トラッキング用サードパーティCookieのサポートのみ廃止されるそうです。

 

サードパーティCookieとは、訪れたサイトとは別のドメインから提供されるCookie。

例えば、訪れたサイト上にある広告のリンクなど。

広告のリンクが置いてるページを見ただけでも付与されそうな雰囲気。

 

 

スポットフリート

インスタンスタイプや入札価格などの条件を指定して、自動で最安値のインスタンスを選択して起動を自動化することができる。

 

スポットブロック

設定した時間は中断されることなく、スポットインスタンスを継続利用できる。

 

リザーブドインスタンス

中長期的に利用継続するようなインスタンスは、リザーブドインスタンスを利用することで割引価格が適用される。

 

EC2プレイスメント戦略

・クラスタープレイスメントグループ

HPCアプリケーションで必要な低レイテンシーネットワークを実現できる。

 

・パーティションプレイスメントグループ

インスタンスを複数の論理パーティションに分散させる。

Hadoopなどの分散処理に向いている。

 

・スプレッドプレイスメントグループ

それぞれに独自のネットワークおよび電源がある異なるラックに別々に配置できる。

 

ハイバネーション

EC2インスタンス停止前にメモリが保持している内容をハードディスクへ退避させて、次回の起動時に状態を復元できる機能。

Hibernationは、冬眠とか引きこもりという意味らしい。

 

VPCコンソールウィザード

・1つのパブリックサブネットを持つVPC

・パブリック、プライベートを持つVPC

・パブリック、プライベート、VPNをもつVPC

・プライベート、VPNをもつVPC

 

踏み台サーバの例

データベースサーバは、プライベートサブネットに作成する。

踏み台サーバは、パブリックサブネットに作成する。

踏み台サーバとデータベースサーバは通信が可能。

踏み台サーバへのアクセスは、特定のIPアドレスを介したSSH(ポート22)でのアクセスのみを許可する。

Windowsの場合は、RDP(ポート3389)を許可する。

 

IPフローティング

ElasticIPを用いて稼働サーバを稼働させておき、故障した場合には待機系サーバへElasticIPを付け替えることで、即座に切り替える。

 

ENIアタッチ

ホットアタッチ:インスタンスの実行中にアタッチすること

ウォームアタッチ:インスタンスの停止中にアタッチすること

コールドアタッチ:インスタンスの起動中にアタッチすること

 

起動設定

AutoScalingグループがEC2インスタンスを起動するために使用するインスタンス設定テンプレート

一度作成した起動設定は変更出来ないため、変更が必要な場合は新規作成が必要。

AutoScalingグループは、起動テンプレートを使うことも可能。

 

Auto Scalingは最小容量、最大容量、希望する容量(desired )を設定することで、Auto Scaling グループのサイズを設定できる。

 

スケーリングポリシー

ターゲット追跡:CPU60%をしきい値等を設定して、スケーリングを実施

ステップ:アラーム超過のサイズに基づいてインスタンス数を動的にスケーリングする1 つ以上のステップ調整値を指定して複数回の段階的なスケーリングを実施

スケジュール:定期的に特定のスケジュールにあわせてスケーリングを実施

 

スケーリングが多発:インスタンス数が不足しているので、Auto Scalingグループサイズを増やす

スケールインが多発:Auto ScalingスケールダウンポリシーをトリガーするCloudWatchアラームのしきい値を変更して、スケールインの発生を抑制

クールダウン期間が短い:スケーリングアクティビティが有効になる前に、追加のインスタンス起動・停止をしないようにする

 

Auto Scalingグループのライフサイクルフック

スケーリングを実行する前に、カスタムアクションを実行することが可能

 

Dedicated Hostは、同じAWSアカウントでも、IAMグループ毎に別の物理的にサーバーを利用できる

ハードウェア専有インスタンスは、別のAWSアカウントとは物理的に分離されるが、同じAWSアカウント内では共有される可能性がある。

AWSの勉強をしていたら、すごいサービスを知った。

超大量データをAWSへ転送するためのサービスで、申し込むとトラック(車)が来るので、トラックへデータを入れてAWSへ持っていってくれるらしい。

生きているうちに、利用する機会は無いだろうな。

 

関東は、昨日梅雨明け宣言されたらしい。

暑すぎるから、避暑地(イオンモール)でも行こうかと思う。

 

2023年に制度が終了するらしい。

でも、小さい子供がいて、資産に多少余裕があるなら絶対にやった方が良いようだ。

 

年間80万円まで投資できて、子供が20歳になるまで非課税枠で運用できる。

なので、今年始めたとしても3年分の240万円分を運用しておいて、子供が20歳になったら、そのままNISAへ移行できる。

 

もし、お金が必要になった場合の払い出しも2023年以降は可能になる。

つまり、いつでも課税されずに引き出しできるので貯蓄としても機能する。

(もちろん投資信託は元本割れのリスクはある。)

 

SNMPトラップは一度しか送信されないため、マネージャが受信できないと障害通知が受け取れない可能性がある。

その場合、SNMPインフォームを使うことで、確実にマネージャに情報が届く。

SNMPトラップ要らなくね?と思ったけど、何か有用なのだろうか。


IPアドレスをサブネット化した際に、サブネット部が全て0のアドレス(ゼロサブネット)を使うと、サブネット化前のネットワークアドレスと同じになるので混乱の原因になる可能性がある。

最新のCiscoルータのデフォルト設定は、サブネットゼロは有効になっている。

 

サブネット部が全て1のアドレス(オールワンサブネット)も同様に混乱の原因になる。

こちらは設定は無さそうで、明示的に許可になっている。

 

上記2つのアドレスを使わないようにするのは古い習慣のようだが、いずれにしても、利用は推奨されていないらしい。

具体的にどのような設定ミスの恐れがあるのかは理解できていない。