- 1. LambdaとRDSのセキュアな接続 ~SSL/TLS証明書の選択と実装~
- 2. IAM に関するメモ
- 3. AWSome Dayの備忘録
- 4. AWS CLIアカウント作成
- 5. ユーザーデータを用いてEC2立ち上げ時のログ
- 6. 【OCI クラウド移行ガイド】AWS MySQLonEC2とOCI MySQL on Compute で双方向レプリケーションを設定してみた
- 7. AWS Glue serverless Spark UI observability metricsを試してみた
- 8. 既存の AWS Organizaitons 環境で Control Tower を有効化する際に知っておくべきこと
- 9. EFSをsambaで共有する
- 10. Amazon Interactive Video Service(IVS)について
- 11. Application Migration Service（MGN）でレガシーOSをAWS移行
- 12. Terraformのコードをテストしたい
- 13. AWS DBS-C01 Database Specialty 合格奮闘記
- 14. API Gatewayの耐障害性を考える
- 15. 【aws system manager】クラウドウォッチログとアラート設定
- 16. 【aws system manager】構成管理とドリフト検出
- 17. k8sをオンプレで構築する場合
- 18. CDKで既存のS3バケットを管理する
- 19. バケットポリシーに本気なS3標準テンプレートのご紹介
- 20. 内部通信暗号化が要件になった場合のAWSでの実現案
LambdaとRDSのセキュアな接続 ~SSL/TLS証明書の選択と実装~
最近、アーキテクチャにRDSのリードレプリカを組み込む作業を行ったのですが、Lambda(NestJS)からRDS(リードレプリカ)へのSSL/TLS接続を設定する際、以下のエラーメッセージが表示されました。
“`objectivec
Error: self-signed certificate in certificate chain
“`
この問題の原因と解決方法を備忘録として残します。# 原因
単純に、使用する証明書が不適切だったのが原因でした。## RDS Proxyを介する場合の証明書
元々の構成では、Lambda(NestJS)からRDS Proxyを経由してRDS(プライマリ)に接続しており、この場合には[`AmazonRootCA1.pem`](https://www.amazontrust.com/repository/AmazonRootCA1.pem)証明書を使用していました。RDS Proxyを使用する際には、AWSが提供する`AmazonRootCA1.pem`というルート証明書が重要です。この証明書は、RDS Proxyの身元確認と通信の暗
IAM に関するメモ
# はじめに
AWSのアカウント・ユーザー・権限の関係性が複雑に感じていたので、一から IAM について調べたことをまとめます。
# 概要
– IAM とは
– IAM ユーザー
– IAM ポリシー
– IAM ロール# IAM とは
IAM は「Identity and Access Management」の略で、IDとアクセス権を管理するサービスになります。
複数のAWSアカウントが存在する際、誰がどのアカウントにアクセスできるか、どのサービスを利用できるのかといった権限を管理するためのサービスです。
※複数のAWSアカウントを持つメリットとデメリット
https://dev.classmethod.jp/articles/account-and-vpc-dividing-pattern/
# IAM ユーザー
IAM ユーザーは **人に与えられるID** で、AWSアカウントにログインする際に必要となるユーザー名とパスワードが付与されます。
下記のように１つのAWSアカウントに複数のユーザーを作成することが可能で、従業員１人ずつ個別のIAM
AWSome Dayの備忘録
# はじめに
11月16日にあったAWSome Day Online Conferenceのまとめ
https://awsomeday-apj.virtual.awsevents.com/homejp
# AWSの概要、グローバルインフラストラクチャーとコンピューティング
## AWSの概要
– データセンター
– 通常、数千台のサーバを収容
– アベイラビリティーゾーン（AZ）
– 1つ以上のデータセンターの集合
– 障害を分離する設計
– リージョン
– 3つ以上のAZで構成
– 世界全体で31のリージョンが存在リージョン内のAZは物理的に離れており、複数のAZを利用することでAZレベルの障害の影響から保護でき、システムの高可用性を確保可能
リージョンは100km圏内、AZ間は数km~数十km離れている### サービスの分類
– アンマネージドサービス
– スケーリング、耐障害性、可用性をユーザが管理
– マネージドサービス
– スケーリング、耐障害性、可用性をAWS側が管理## EC2
– ア
AWS CLIアカウント作成
AWS CLIのアカウント作成をしてアカウント内のリソース(S3)を確認する所までをやってみたいと思います。
現在AWS４冠ですが資格ばかり取れてしまって中々実際に手を動かす機会もないのでやってみようと思います。
(でも次はSAP取りたい)自分が吸収力悪い方なのでそんな方にも分かりやすく書けたらと思っています。
EC2を建ててもいいですけど自分のPCからやった方がコストかからずにできるのでいいと思います。
私はMacの環境から作成してみますので、ここから自分のAWSアカウントに接続してみたいと思います。## 前提
・S3権限のついたIAMユーザがアカウントに存在すること
・対象のIAMユーザのアクセスキーを作成しておくこと
・S3バケットの作成## AWS CLIのインストール
素直に公式のドキュメントに沿ってやっていきます。
https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/getting-started-install.html1,ターミナルを開いたら、CLIのファイルを公式からダウンロードを実行します。
ユーザーデータを用いてEC2立ち上げ時のログ
## ユーザーデータでEC2立ち上げ時のログ
ログを見る方法がわからなかったので調べてみました。
### 前提
`EC2`のセキュリティーグループに`ssh(22)`, `http(80)`が`Anywhere`でアクセス許可していることを確認してください。
### Ubuntu, 22.04 LTSにnginxをインストール
`Ubuntu, 22.04 LTS`に`nginx`をインストールするユーザーデータ
“`bash:ubuntuにnginxをインストール
#!/bin/bashsudo apt update
sudo apt install -y nginx
“`### EC2インスタンスにブラウザからアクセス
上記のユーザーデータがエラーなく実行できている場合は次のようなリンクでブラウザからEC2にアクセスし`nginx`のデフォルトページを観測できます。
“`
http://EC2のパブリックアドレス
“`が、発表されました。これにより、GlueでSparkUIで確認できるようになりました。
個人的には、待望の機能だったのでとても嬉しく、早速試してみました。# まとめ
– Spark UIがGlueに組み込まれました。
– CloudWatchメトリクスで詳細なメトリクスが確認できるようになりました。# 実践
## 前提
### データを用意
1. Redshiftのドキュメントに添付されているサンプルのデータセットtickitdb.zipをダウンロードします。1. いくつかのファイルのうち、最も大きいサイズのlisting_pipe.txtを使用します。
“`
$ head listings_p
既存の AWS Organizaitons 環境で Control Tower を有効化する際に知っておくべきこと
## はじめに
すでに運用されている AWS Organizations 環境に Control Tower を導入したい場合、既存リソースへの影響など色々気になることが出てくるかと思います。事前に知っておいた方がよい、考慮しておくとよい点などをまとめました。
## 既存アカウントは Control Tower に自動で登録されない
既存組織が存在する状態で Control Tower を有効化した場合、既存組織に属するアカウントは Control Tower へ自動で登録はされません。そのためサービスの有効化のみでは既存アカウントやその中で稼働するリソースに影響はありません。OU 単位で Control Tower に登録するか、既存のアカウントを Control Tower 有効化済みの OU に登録することで既存アカウントを Control Tower の管理下に置くことができます。
https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/existing-orgs.html
## 監査アカウン
EFSをsambaで共有する
## TL;DR
sambaがNFSボリューム内を共有していると気づいたら quotaを確認しにいくよ。
EFSはquotaに対応していないみたいだよ。
応答がないから60秒のタイムアウトまでsambaのファイルコピーとかが止まるよ。
sambaのquotaを確認する仕組みは停止できないっぽいよ。
“get quota command”でquota取得を別コマンドに委ねられるからこれを使うと幸せになれるかも。## 序章
sambaでとある仕組みを構築していたのだが、今回オンプレからAWSに移行しようということになった。
その際、AWSインフラ担当が、A担「それFSxじゃ駄目なの？」
私 「FSxでinotify使えるなら(以下略)」
A担「EC2もったいないじゃん」
私 「再設計する暇ないし費用もらってない」
A担「使用量の見積もり面倒だからsambaの部分EFSでもいい？」
私 「EFSってNFSだよね。ファイルロックできたっけか？」
A担「AWSでできない訳ないじゃん くぁwせdrftgyふじこlp」
私 「ああ、ロックとかできそうだね。inotifyもできそう。」
A
Amazon Interactive Video Service(IVS)について
## Amazon Interactive Video Service(IVS)とは
魅力的なライブストリームとインタラクティブなビデオ体験を構築するAWSサービス
## 現在の為替相場
1ドル: 147円(約150円)
## 前提知識
### レイテンシー
データ転送における指標のひとつで、転送要求を出してから実際にデータが送られてくるまでに生じる、通信の遅延時間のこと
### Amazon Interactive Video Service の解像度
– 解像度が 480 以下のものが標準解像度 (SD)
– 解像度が 480 超～ 720 以下のものが高解像度 (HD)
– 解像度が 720 超～ 1080 以下のものがフル高解像度 (フル HD)
## 配信種類と特徴・料金
### リアルタイムストリーミング
#### メリット
– ほぼリアルタイムでの配信(ホストから視聴者まで300ミリ秒)
#### デメリット
– 最大視聴者数が低レイテンシーストリーミングに比べて少ない(最大 10,000人の視聴者と最大12人)
– 最大入力解像度が720(HD)でフルHD不可
##
Application Migration Service（MGN）でレガシーOSをAWS移行
# はじめに
久しぶりの記事投稿となりました。
今回はApplication Migration Service（MGN）について調べたことをまとめます。
Windows Server 2008をAWSへ移行しようと思い、さまざまなことを調べた備忘録です。## MGNの概要
* MGNはAWSへのリホストに特化したサーバ移行サービスです。
* リホストに活用できるサービスとして、VM Import/ExportやServer Migration Service などがありますが、AWSからはMGNの利用が推奨されています。## MGNの特徴
■ 柔軟性
* MGNは、物理サーバや仮想サーバ、クラウドサーバに対応
* Linux及びWindowsをサポート■ 信頼性
* 無停止の継続レプリケーション
* AWSへのレプリケーションは暗号化して転送
* VPNやDirect Connectなどのプライベート接続に対応可能■ 高度な自動化
* マネジメントコンソールで簡単な操作が可能
* 移行の計画に合わせたApplication または Wave という単位でまとめ
Terraformのコードをテストしたい
# Terraformのコードの品質担保するためにできること
awsでTerraformを書いているときに、品質を担保するにはどうしたら良いのか検討してみた。## Terraformのコードをフォーマットする。
`terraform fmt`Terraformのfmtコマンドで、コードをフォーマットすることにより、Terraformのコードが綺麗になる。
インデントとか、適当に書いてしまった場合でも、しっかりと整形してくれるので私のようなエンジニアには助かる。## terraform validateコマンドを実行する。
`terraform validate`このコマンドでは構文が正しいことを確認してくれる。参照関係で不十分な箇所を解析してくれる。
## tflint
tflintは、静的解析ツールである。パラメータの値とかを実際のパラメータの取りうる値で書いているのか、などの解析をして、問題があればエラーを返してくれる。
tflintのコマンドをインストールする必要があるが、とても良いツールだと思う。インストールについては、いろいろな人がやっていると思うので、割
AWS DBS-C01 Database Specialty 合格奮闘記
# 調子に乗ってもう一個認定試験受ける
https://qiita.com/kazumatsukazu/items/b016a48843d4e4c38f0f無事にSolution Architect取れたのでこれで仕事探してもいいかなと思ったのですが、せっかく長年SQLで頑張ってるので、Database周りの資格も欲しくなっちゃいました。
なのでこちら受けます
# DBS-C01 Database Specialtyhttps://aws.amazon.com/jp/certification/certified-database-specialty/?ch=sec&sec=rmg&d=1
Analyticsと迷ったのですが、どうやら廃止されて新しい資格できるみたいですね
https://aws.amazon.com/jp/certification/certified-data-engineer-associate/
こういう場合って、現在Analyticsの資格を持っている人は再認定など、資格を延長することはできないのでしょうか？
あとで調べてみたいと思います。#
API Gatewayの耐障害性を考える
# はじめに
この記事はDevOps on AWS大全の一部です。
DevOps on AWS大全の一覧は[こちら](https://qiita.com/tech4anyone/items/b06f88035d27c6ef13b2)。この記事ではAPI Gatewayを耐障害性の観点から超詳細解説しています。
具体的には以下流れで説明します。
– API Gatewayとは
– API Gatewayを更新するときのダウンタイム
– API GatewayのスケーラビリティAWSの区分でいう「Level 200：トピックの入門知識を持っていることを前提に、ベストプラクティス、サービス機能を解説するレベル」の内容です。
# この記事を読んでほしい人
– API Gatewayを採用するときのベストプラクティスを説明できるようになりたい人
– API Gatewayの耐障害性に不安を感じている人
– AWS Certified DevOps Engineer Professionalを目指している人# API Gatewayとは
AWS API Gatewayは、簡単
【aws system manager】クラウドウォッチログとアラート設定
## クラウドウォッチログの概要と活用シナリオ
awsについて初心者エンジニアに向けて、awsのシステムマネージャー（aws systems manager、以下ssm）を使ったクラウドウォッチログとアラート設定について解説します。### クラウドウォッチログとは
クラウドウォッチログは、awsのリソースの情報やアプリケーションのログを収集するためのサービスです。これにより、アプリケーションの問題や障害の追跡、運用監視などを効果的に行うことができます。### クラウドウォッチログの活用シナリオ
クラウドウォッチログは、以下のような活用シナリオで利用されます。1. ログのトラブルシューティング: システムやアプリケーションの問題を特定し、ログを調査して原因を追跡するために使用されます。
2. パフォーマンスの監視: amazon ec2などのリソースのパフォーマンスを監視し、リソースの利用状況や負荷を把握するために使用されます。
3. セキュリティの監視: セキュリティに関連するイベントやログを監視し、セキュリティ侵害の検知や対策を行うために使用されます。以上のような活用
【aws system manager】構成管理とドリフト検出
## aws system manager】構成管理とドリフト検出
こんにちは。今回は、awsについて初心者エンジニアに向けて、aws system managerを使用した構成管理とドリフト検出について解説します。
## 構成管理の重要性とベストプラクティス
構成管理とは、システムやアプリケーションの設定やリソースの管理を一元化し、管理者が状態の追跡や変更の履歴を把握できるようにすることです。aws system managerは、構成管理のためのサービスであり、ドリフト検出も含まれています。
構成管理の重要性は、以下のような理由から言えます。
1. 変更の追跡: システムやアプリケーションの構成が変更された場合、それが問題の原因である可能性があります。構成管理を行うことで、変更の追跡が容易になります。
2. リソースの可視性: システムの構成が把握できれば、リソースの可視性が高まり、適切な管理が可能になります。
3. セキュリティ: 構成管理を行うことで、セキュリティ上の問題を特定し、修正することができます。構成管理のベストプラクティスには、以下のようなものがあります。
k8sをオンプレで構築する場合
# 概要
## k8sを一つの`EC2`(オンプレ)に構築する場合(会社の開発環境構築など)
– 例） Aさんは`dev1.xxx`、Bさんは`dev2.xxx`を利用してください### 簡単手順
1. `golang`、`Docker`と[`k8s`](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/)をダウンロードし、手順に沿ってインストールすること
– [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)をインストールすること
– ダウンロード直後にノードが`NotReady`とk8sの状況で`DNS`が動作されてないので[`Calico`](https://docs.tigera.io/calico/latest/getting-started/kubernetes/quickstart)をインストールすること
– `kubeadm`を初期化する段階で`–cri-soc
CDKで既存のS3バケットを管理する
## 概要
最近AWS CDKで環境構築する機会がありました。
その際に既存のS3バケットをCDKの管理下におく方法を調査したので共有させていただきます。
なお、今回は`cdk import`を使用して既存リソースをインポートしていきます。## 準備
まず、CDKのプロジェクトを作成します。
“`bash
mkdir cdk-import-bucket && cd cdk-import-bucketcdk init sample-app -l typescript
“`
`lib/cdk-import-bucket-stack.ts`を確認すると、`SNS`や`SQS`のリソースを作成する記述があるので削除しておきます。
“`typescript
import { Stack, StackProps } from ‘aws-cdk-lib’;
import { Construct } from ‘constructs’;export class CdkImportBucketStack extends Stack {
constructor(scope: Cons
バケットポリシーに本気なS3標準テンプレートのご紹介
# はじめに
AWSのS3は、オブジェクトストレージサービスとして広く利用されていますが、設定ミスや誤操作によって情報漏洩のリスクにさらされることがあります。この記事では、S3の情報漏洩を防ぐために、リソースベースポリシーを使ったS3標準テンプレートをご紹介します。[Security-JAWS【第31回】勉強会](https://s-jaws.doorkeeper.jp/events/165371)で発表したセッション、「S3の情報漏洩からデータを守るには？CloudFormationで作るS3標準テンプレートのご紹介」の内容を記事化したものです。
セッション資料はこちら
# リソースベースポリシーとは
IAMポリシーとして設定できる対象のひとつです。– アイデンティティベースポリシー
IAMユーザー
内部通信暗号化が要件になった場合のAWSでの実現案
## 0. はじめに
IPAから2023/7/18付けで[重要情報を扱うシステムの要求策定ガイド Ver.1.0](https://www.ipa.go.jp/digital/kaihatsu/system-youkyu.html)という資料が公開されました。この中に「システム基盤内通信路でのデータ暗号化の確保」という要求項目があります。
公共分野の通常のWebシステムではユーザ→ロードバランサまでの通信はHTTPSで暗号化しますが、ロードバランサより内部のアプリケーションサーバ、DBサーバなどとの通信は暗号化しないことが多いです。しかし、今後この資料を元に重要な情報を扱う公共システムで内部通信暗号化が必須要件とされてくる可能性があります。
そこで内部通信暗号化をAWSで行う方法について考え、1つの案について設計への影響を検証してみました。## 目次
[0. はじめに](#0-はじめに)
[1. 暗号化する箇所](#1-暗号化する箇所)
[2. それぞれ暗号化する方法](#2-それぞれ暗号化する方法)
[3. ミドルウェアによらず透過的に暗号化する方法](#3-ミドルウェアによらず
