MONTH や DAY が 8 (一桁) の時、
YYYYMMDD 形式でフォーマットが崩れないようにするためのワンライナー
YYYYMMDD=${YEAR}$(printf "%02d" ${MONTH})$(printf "%02d" ${DAY})IDEA Note
-
年月を、シェルでゼロ埋めする
-
VPC とサブネットで IPv6 の使用を有効にするためのステップ
以下の順番に対応する
- AWS が提供する IPv6 CIDR ブロックを VPC およびサブネットと関連付ける。
- IPv6 トラフィックがルーティングされるようにルートテーブルを更新。
パブリックサブネットの場合
サブネットからインターネットゲートウェイに IPv6 トラフィックをすべてルーティングするルートを作成する。
プライベートサブネットの場合
サブネットから Egress-only インターネットゲートウェイに
インターネット経由の IPv6 トラフィックをすべてルーティングするルートを作成する。 - IPv6 アドレスのルールを含めて、セキュリティグループルールを更新する。
これを行うことでIPv6 トラフィックはインスタンスに出入りできるようになる。
カスタムネットワーク ACL ルールを作成して、サブネットに出入りするトラフィックの流れを制御している場合、
IPv6 トラフィックのルールを含める必要がある。 - インスタンスタイプが IPv6 をサポートしていない場合は、インスタンスタイプを変更する。
- サブネットの IPv6 アドレスの範囲からインスタンスに IPv6 アドレスを割り当てる。
- DHCPv6 を使用するように設定されていない AMI からインスタンスが起動された場合、
インスタンスに割り当てられている IPv6 アドレスが認識されるように
手動でインスタンスを設定する必要がある。
- AWS が提供する IPv6 CIDR ブロックを VPC およびサブネットと関連付ける。
-
オンプレミスのライセンスごとAWSに移行方法
オンプレミスの DB2、SAP、Windows などを AWS に移行する方法について
- 移行方法
- ライセンスの管理方法
上記２点を考える必要がある。
移行方法について
これらのライセンスをそのまま移行するためには、
EC2インスタンスにソフトウェアをインストールすることになる。
そのための移行方法としてAWS SMSを利用してECインスタンスへの移行が選択肢になる。
ライセンスの管理について
AWS License Manager を利用する
AWS License Manager の特徴
ライセンスルールを定義。
ライセンス対象となるソフトウェアをインストールしたEC2インスタンスに適用することができる。
コンソールを利用してライセンス利用状況を追跡することも可能。
ソフトウェアベンダーのライセンスを簡単に管理できるようになる。
管理者はライセンス契約の規約をエミュレートするカスタマイズされたライセンスルールを作成することで、EC2 のインスタンスの起動時にそれらのルールを適用できる。
管理者はこれらのルールを使用して、契約が定める以上のライセンスを使用する。
または短期的に異なるサーバーにライセンスを再度割り当てるといったライセンス違反を規制できる。
AWS License Manager は AWS のサービスと統合し、1 つの AWS アカウントを通じて、複数のアカウント、IT カタログ、オンプレミスにわたってライセンスの管理を簡素化することができる。
また、ライセンス管理者は AWS Service Catalog でルールを追加することができる。
参考情報
AWS Licence Manager
https://aws.amazon.com/jp/license-manager/features/
AWS Service Catalog
-
Amazon Rekognition について
Amazon Rekognition
画像検品作業は可能だが、
画像検品に特化したサービスではない
もし画像検品などを行いたい場合は、
G2インスタンスにソフトウェアを導入するなどの対応が必要。
低レイテンシネットワーキングを備えた高度なグラフィック処理サーバーについて言及する場合は、EC2インスタンスの中のG2インスタンスが最適。
-
Amazon SWF について
Amazon SWF の特徴
- マネージド型の状態トラッカー
- タスクコーディネーター
ユースケース
開発者が
- 並行したステップ
- 連続したステップがあるバックグラウンドジョブを構築、実行
するケース。
SWFはAWSサービスとの人間のやり取りを含むワークフローをサポートするが、
現在ではワークフロー作成にはSWFではなくAWS Step Functions の利用が推奨されている
AWS Step Functions よりも Amazon SWFの使用が求められるユースケース
- 結果を親に返す子プロセスを起動する場合
- プロセスにおいて介入する外部信号が必要な場合
公式は以下の通り
-
AWS Organizations の[組織の証跡]について整理する
「組織の証跡」とは
組織内のマスターアカウントとすべてのメンバーアカウントの CloudTrail イベントを同じ
- Amazon S3 バケット
- CloudWatch Logs
- CloudWatch イベント
に配信できるようにする設定である。
組織の証跡を作成すると、組織のための統一されたイベントログ記録戦略を定義するのに役立つ。
組織の証跡を作成すると、自分の組織に属するすべての AWS アカウントに、指定した名前の証跡が作成される。
メンバーアカウントで CloudTrail アクセス許可を持つユーザーは、
- AWS アカウントから AWSCloudTrail コンソールにログインしたとき
- describe-trails などの AWS CLI コマンドを実行したとき
この証跡 (証跡 ARN を含む) を表示することができる。
各AWSアカウントでアクティビティが発生すると、そのアクティビティはCloudTrailイベントに記録される。
イベント履歴に移動すると、CloudTrailコンソールで最近のイベントを簡単に表示できる。
マルチリージョンおよびグローバルイベントの追跡を有効にすることもできる。
デフォルトでは、CloudTrailによってバケットに配信されるログファイルは、
Amazon S3管理の暗号化キー（SSE-S3）を使用したAmazonサーバー側の暗号化によって暗号化される。
直接管理可能なセキュリティレイヤーを提供するために、
CloudTrailログファイルにAWS KMS管理キー（SSE-KMS）を使用したサーバーサイド暗号化を使用できる。
ログを保護するには、S3バケットを暗号化し、バケット作成時にデータ削除不可の設定を行うことで、永続的にログを保存することが可能。
マスターアカウントに対して単一のCloudTrailを有効化して、ターゲットアカウント設定において他の子アカウントをターゲット設定・・・と言うことは必要ない。
AWS Organizationsを利用して、CloudTrailの「組織の証跡」を利用することで子アカウントにも自動的にCloudTrailログを設定することが可能になるからだ。
-
IPSec VPN の特徴
デフォルトで Amazon VPC 内に起動されるインスタンスと、ユーザー独自のネットワークとの通信はできない。
VPC から独自のネットワークへのアクセスを可能にするには、以下のアプローチが必要になる。
- 仮想プライベートゲートウェイを VPC に関連付ける
- カスタムルートテーブルを作成
- セキュリティグループ規則を更新
- AWS Site-to-Site VPN接続を作成する
Site-to-Site VPN は、インターネットプロトコルセキュリティ (IPsec) VPN 接続をサポートしている。
IPSecの特徴
- Site-to-Site VPN 接続は、AWS Classic VPN または AWS VPN のいずれか。
- IPSecトンネル経由で送信されるデータの整合性を保持する。
- IPSecトンネルを経由して送信されるデータは暗号化される。
- IPSecはインターネット経由で送信中のデータを保護する。
- IPSecトンネルのセットアップ中にIDが認証される。
- VPNゲートウェイ（VPG）とカスタマーゲートウェイ（CGW）の間にIPSecトンネルが確立される。
データは暗号化されるが、SSLを利用してはいるわけではないと言うのは大きな特徴だ。
参考情報
IPsec-VPNとは？SSL-VPNとの違いもわかりやすく徹底解説！
-
AWS Elastic Beanstalk の deploy policy を整理する
AWS Elastic Beanstalk は、デプロイポリシーも含めデプロイを処理するいくつかのオプションがある。
All at once
新しいバージョンをすべてのインスタンスに同時に展開する。
環境内のすべてのインスタンスは、展開が行われている間、短時間サービスが停止することになる。
そのため、展開に必要な合計時間を最短にする方法にはなる。
Rolling
Elastic Beanstalk は環境の EC2 インスタンスを複数のバッチに分割し、アプリケーションの新しいバージョンを一度に 1 つのバッチにデプロイする。
そのため、環境内の残りのインスタンスは古いアプリケーションバージョンを実行した状態になる。
つまりローリングデプロイ中は、アプリケーションの古いバージョンでリクエストを処理するインスタンスもあり、新しいバージョンでリクエストを処理するインスタンスも存在する。
Rolling with additional batch
新しいバージョンをバッチで展開するが、最初にインスタンスの新しいバッチを起動して、展開プロセス中に完全な容量を確保する。
Immutable
変更不可能な更新を実行して、古いバージョンを起動しているインスタンスと並行しながら、別の Auto Scaling グループにあるアプリケーションの新しいバージョンを起動している新しいインスタンスのフルセットを起動する。
部分的に完了したローリングデプロイにより発生する問題を防止することができる。
新しいインスタンスがヘルスチェックをパスしなかった場合、Elastic Beanstalkはそれを終了し、元のインスタンスをそのまま残す。
参考情報
-
AWSアカウントを跨いで S3 などを共有する
リソースベースポリシーのクロスアカウントアクセスを設定することで対応が可能。
一部の AWS サービスでは、リソースに対するクロスアカウントアクセス許可を付与することができる。
クロスアカウントの理論についてはこちら
これを行うには、プロキシとしてロールを使用するのではなく、
共有するリソースに直接ポリシーをアタッチすることになる。
共有するリソースは、リソースベースのポリシーをサポートしている必要がある。
なお、リソースベースポリシーが有効になっているサービスは
- S3
- SNS
- SQS
のみ。
https://docs.aws.amazon.com/ja_jp/IAM/latest/UserGuide/id_roles_compare-resource-policies.html
ユーザーベースのポリシーとの違い
端的に言うと、ユーザーに割り当てるのではなく、サービスに割り当てるもの。
リソースベースポリシーは Principal が必須となる。
公式のスライドはこちら
公式ドキュメントはちょっと難解なので、Classmethod さんの記事が非常にわかりやすく噛み砕かれていた。
-
Lambda カスタム統合/Lambdaプロキシ統合 について
API Gateway と Lambdaファンクションを統合して実行するための方法は
- Lambda カスタム統合
- Lambdaプロキシ統合
の２つあるのでそれぞれ整理する
Lambda カスタム統合
プロキシ統合のセットアップ手順に加えて、
受信リクエストデータがどのように統合リクエストにマッピングされるか、
統合レスポンスデータの結果がメソッドレスポンスにどのようにマッピングされるかを指定す。Lambda プロキシ統合
おそらく、API GW + lambda の構成の場合最も使われている機能だと思う。
API にコンテンツのエンコーディングやキャッシュが不要な場合は、
統合の HTTP メソッドを POST に設定し、統合エンドポイント URI を特定の Lambda 関数のアクションを呼び出す Lambda 関数の ARN に設定することで、認証情報を API Gateway がユーザーに代わって Lambda 関数を呼び出すことを許可する。