AWSの学習中に出てきたEIPがわかりづらく感じたので現状わかる範囲でまとめてみました。 EIP elasticなIPアドレスのこと。 elastic...しなやか、弾力 → 融通の効く みたいなイメージ。 パブリックIPを割り当てても、EC2インスタンスの停止時にIPが変わってしまう。 その解決策がEIPらしい。 パブリックIPもプライベートIPもサーバーを再起動すると変更されてしまう。 でもこのElastic IPはサーバーを再起動してもIPアドレスが変わらない。 なのでEIPをパブリックIPとしてEC2インスタンス（サーバー）に設定することで、インスタンス停止時にIP変わる問題を解決する。 おまけ IPアドレスは基本的にパブリックIPアドレスとプライベートIPアドレスの２つに分けることができる。 パブリックIP パブリック＝公的な、つまりVPCの外側（アプリでいうユーザー側）からの通信に使うIPのこと。 （グローバルIPも意味合いとしては同じ） ネットに接続する場合、サーバーは必ずグローバルIPを持たなければならない。 （じゃないとネットと繋がれない） プライベートIP 私的な通信。 WEBサーバーとDBサーバー同士の通信用とか。 ユーザー側からはいじらない部分。

はじめに Lamba のエラー通知を受信したので X-Ray で確認すると、Lambda の状態が「保留中」となったまま実行時間を過ぎてタイムアウトしまいエラーになっていることがありました。その原因がわかったため、ここに記録しておきます。 原因 このエラーは、VPC 内のプライベートサブネットに接続する必要がある Lambda に起こるようです。 Lambda が VPC 内のリソースに接続するとき、サブネットごとにネットワークインターフェイス（ENI）が作成されます。これによって Lambda は各 VPC 内のリソースに通信できるようになります。 この Lambda が長期間アクティブでない場合、Lambda はネットワークインターフェイスを回収し、アイドル状態になります。アイドル状態の Lambda を再度アクティブにするには、その Lambda を呼び出します。すると、この呼び出しは失敗し、ネットワークインターフェイスが使用可能になるまで、Lambda は保留（Pending）状態になります。 このとき、ネットワークインターフェースが使用可能になるまでにかかる時間が Lambda の実行時間を超えてしまうと、Lambda は終了し、エラーになるようです。 VPC 接続しない Lambda ではこの様なエラーは一切見られなかったため、設定などに問題がないか心配していましたが、そういうわけではなくて良かったです。 保留中のままタイムアウトした Lambda の X-Ray 下記は、タイムアウトを 5 秒に設定している Lambda が保留中のまま終了となり、エラーとなった際の X-Ray の表示内容です。 Lambda の状態に関する情報を取得するコマンド 下記のコマンドで、Lambda API を使用して、関数の状態に関する情報を取得できます。表示される各項目の解説は、FunctionConfiguration を参照してください。 $ aws lambda get-function-configuration --function-name my-function { "FunctionName": "my-function", "FunctionArn": "arn:aws:lambda:ap-northeast-1:XXXXXXXX:function:my-function", "Runtime": "go1.x", "Role": "arn:aws:iam::XXXXXXXX:role/XXXXXXXX", "Handler": "XXXXXXXX", "CodeSize": 123456789, "Description": "", "Timeout": 5, "MemorySize": 128, "LastModified": "2021-10-13T07:46:51.452+0000", "CodeSha256": "XXXXXXXX", "Version": "$LATEST", "VpcConfig": { "SubnetIds": [ "subnet-XXXXXXXX", "subnet-XXXXXXXX" ], "SecurityGroupIds": [ "sg-XXXXXXXX" ], "VpcId": "vpc-XXXXXXXX" }, "Environment": { "Variables": { "XXXXXXXX": "XXXXXXXX", } }, "TracingConfig": { "Mode": "Active" }, "RevisionId": "XXXXXXXX", "State": "Active", "LastUpdateStatus": "Successful", "PackageType": "Zip" } 以上です。 参照した記事一覧 【AWS Developer Guide】Lambda function states 【AWS デベロッパーガイド】Lambda API を使用した関数の状態のモニタリング 【AWS Compute Blog】Coming soon: Expansion of AWS Lambda states to all functions 【AWS デベロッパーガイド】FunctionConfiguration

はじめに 以下の公式ドキュメントに沿ってクライアントVPNエンドポイントを作成した後、SSH接続、SessionManager接続を行います。 クライアントはmacOS。 完成図はこちら。 クライアントVPNエンドポイント作成前の注意・確認事項 クライアントVPNの制限とルール VPNエンドポイント作成時のクライアントIPv4CIDR範囲は、関連付けられたサブネットのVPCのCIDRや、クライアントVPNエンドポイントのルートテーブルのルートを重複しないこと クライアントIPv4CIDR範囲は /22 以上 /12 以下 クライアントIPv4CIDR範囲は必要なIPアドレス数の2倍の数が必要 クライアントIPv4CIDR範囲は変更できないから注意 クライアントVPNエンドポイントにはIPアドレスを使用して接続しない アクティブな関連付けと接続数で1時間ごとに料金がかかるから注意 サーバ証明書は事前作成してACMへインポートする ACMへのサーバ証明書のプロビジョニングは必須。 クライアント証明書とサーバ証明書のCAが異なる場合のみクライアント証明書をACMにアップロードする。 CAが同一の場合はサーバ証明書のみアップロードでOK。 クライアントごとに個別の証明書とキーを指定可能。 これにより、クライアントが組織を離れた際は該当の証明書を取り消すことで、そのクライアントの接続を拒否できる。 クライアントVPNエンドポイントは、1024ビット、2048ビットのRSAキーサイズのみサポート。 以下ではサーバ証明書とクライアント証明書を作成し、サーバ証明書をACMにインポートしています。 [21-10-15 23:04 ~/aws]# git clone https://github.com/OpenVPN/easy-rsa.git Cloning into 'easy-rsa'... remote: Enumerating objects: 2095, done. remote: Counting objects: 100% (13/13), done. remote: Compressing objects: 100% (11/11), done. remote: Total 2095 (delta 3), reused 4 (delta 0), pack-reused 2082 Receiving objects: 100% (2095/2095), 11.72 MiB | 7.54 MiB/s, done. Resolving deltas: 100% (917/917), done. [21-10-15 23:04 ~/aws]# cd easy-rsa/easyrsa3 [21-10-15 23:04 ~/aws/easy-rsa/easyrsa3]# ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: /Users/xxxx/aws/easy-rsa/easyrsa3/pki [21-10-15 23:04 ~/aws/easy-rsa/easyrsa3]# ./easyrsa build-ca nopass Using SSL: openssl LibreSSL 2.8.3 Generating RSA private key, 2048 bit long modulus .........................................................+++ ........................................................................................+++ e is 65537 (0x10001) You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Common Name (eg: your user, host, or server name) [Easy-RSA CA]: CA creation complete and you may now import and sign cert requests. Your new CA certificate file for publishing is at: /Users/xxxx/aws/easy-rsa/easyrsa3/pki/ca.crt [21-10-15 23:05 ~/aws/easy-rsa/easyrsa3]# ./easyrsa build-server-full server nopass Using SSL: openssl LibreSSL 2.8.3 Generating a 2048 bit RSA private key ............+++ .......................................................+++ writing new private key to '/Users/xxx/aws/easy-rsa/easyrsa3/pki/easy-rsa-41774.zU59Ev/tmp.cvFWOK' ----- Using configuration from /Users/xxx/aws/easy-rsa/easyrsa3/pki/easy-rsa-41774.zU59Ev/tmp.i6rTfS Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'server' Certificate is to be certified until Jan 18 14:05:37 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated [21-10-15 23:05 ~/aws/easy-rsa/easyrsa3]# ./easyrsa build-client-full client1.domain.tld nopass Using SSL: openssl LibreSSL 2.8.3 Generating a 2048 bit RSA private key .............................................................+++ .................+++ writing new private key to '/Users/xxx/aws/easy-rsa/easyrsa3/pki/easy-rsa-41882.glbR44/tmp.QAQPzY' ----- Using configuration from /Users/xxx/aws/easy-rsa/easyrsa3/pki/easy-rsa-41882.glbR44/tmp.QkNLCo Check that the request matches the signature Signature ok The Subject's Distinguished Name is as follows commonName :ASN.1 12:'client1.domain.tld' Certificate is to be certified until Jan 18 14:05:48 2024 GMT (825 days) Write out database with 1 new entries Data Base Updated [21-10-15 23:05 ~/aws/easy-rsa/easyrsa3]# mkdir ~/aws/cetificate/ [21-10-15 23:06 ~/aws/easy-rsa/easyrsa3]# cp pki/ca.crt ~/aws/cetificate/ [21-10-15 23:07 ~/aws/easy-rsa/easyrsa3]# cp pki/issued/server.crt ~/aws/cetificate/ [21-10-15 23:07 ~/aws/easy-rsa/easyrsa3]# cp pki/private/server.key ~/aws/cetificate/ [21-10-15 23:07 ~/aws/easy-rsa/easyrsa3]# cp pki/issued/client1.domain.tld.crt ~/aws/cetificate/ [21-10-15 23:07 ~/aws/easy-rsa/easyrsa3]# cp pki/private/client1.domain.tld.key ~/aws/cetificate/ [21-10-15 23:08 ~/aws/easy-rsa/easyrsa3]# cd ~/aws/cetificate/ [21-10-15 23:08 ~/aws/cetificate]# aws acm import-certificate --certificate fileb://server.crt --private-key fileb://server.key --certificate-chain fileb://ca.crt --profile hands-on-user { "CertificateArn": "arn:aws:acm:ap-northeast-1:xxxxxxxxxxxx:certificate/xxxxxx-b862-xxxx-b0d3-xxxxxxxxxxx" } クライアントVPNエンドポイントを作成して接続する セキュリティグループの作成 クライアントVPNエンドポイント作成時、クライアントVPNエンドポイントのENIにアタッチされるセキュリティグループを選択できるので、そのセキュリティグループを作成します。 インバウンドルールはなし、アウトバウンドはフルオープンで作成。 インバウンドルールがないが、クライアントVPNエンドポイント接続時に拒否されません。 このセキュリティグループは接続できるクライアントを制限するのものではなく、接続を許可するリソースのセキュリティグループで使用される用途が想定されているようです。 例：以下のインバウンドルールだと、クライアントVPNエンドポイントENIからのssh接続を許可している ssh 22 sg-xxxxxx(クライアントVPNエンドポイントENIのセキュリティグループ) アプリケーションのセキュリティグループにルールを追加して、関連付けに適用されたセキュリティグループからのトラフィックを許可することで、クライアント VPN ユーザーが VPC 内のアプリケーションにアクセスできるようにすることができます。 エンドポイントの作成 クライアントIPv4 CIDRは重複しないように設定します。 サーバ証明書のCAとクライアント証明書のCAが同一であればクライアント証明書ARNはサーバ証明書のものを選択してOK。 DNSサーバーのIPアドレスは10.1.0.2を指定。AmazonProvidedDNSサーバーを指定しています。 AmazonProvidedDNS は、リザーブド IP アドレスで実行中の DNS サーバーにマップされ、VPC IPv4 ネットワークの範囲に 2 をプラスした値です。例えば、10.0.0.0/16 ネットワークの DNS サーバーの位置は 10.0.0.2 となります。 セキュリティグループは、先ほど作成したインバウンドルールがないセキュリティグループを選択。 これでエンドポイントの作成は終了です。 しかし、今までの設定だけでは接続できないので、以下の設定等を行います。 ターゲットネットワークの関連付け 承認ルール設定 クライアントVPNエンドポイント設定ファイルをダウンロード AWS提供のクライアントを使用して接続 ターゲットネットワークの関連付け サブネットをクライアントVPNエンドポイントに関連付けます。 サブネットは少なくとも /27 が必要 クライアントVPNエンドポイントのCIDR範囲と重複しない 関連付けるとクライアントVPNのルートテーブルにも反映されます。 認証ルールの追加 特定のネットワークへのアクセスを付与。 今回はVPC内へのアクセスを付与したいため、VPCのCIDRを指定。 設定ファイルのダウンロード 今回は相互認証を利用するので、ダウンロードした設定ファイルにクライアント証明書とクライアントプライベートキーを追加。 以下のcaは既に記載されているので、certとkeyを追加する。 ~/aws/cetificate/client1.domain.tld.crtの-----BEGIN CERTIFICATE-----から-----END CERTIFICATE-----までを、~/aws/cetificate/client1.domain.tld.keyの-----BEGIN PRIVATE KEY-----から-----END PRIVATE KEY-----までをそれぞれ含めて追記。 また、remoteの行にクライアントVPNエンドポイントのDNS名を指定していますが、VPN接続時にDNS名を解決できないエラーが発生するので、こちらのDNS名の先頭にランダムな文字列を追加します。 random_stringと記載されている箇所はランダムな文字列にしてます。 client dev tun proto udp remote random_string.cvpn-endpoint-0011abcabcabcabc1.prod.clientvpn.eu-west-2.amazonaws.com 443 remote-random-hostname resolv-retry infinite nobind persist-key persist-tun remote-cert-tls server cipher AES-256-GCM verb 3 <ca> Contents of CA </ca> <cert> Contents of client certificate (.crt) file </cert> <key> Contents of private key (.key) file </key> reneg-sec 0 AWS提供のクライアントを使用して接続 こちらからダウンロード。 設定ファイルを使用してプロファイルを追加。 SSH接続 VPN接続できているか確認するため、今回接続するVPCにEC2インスタンスを建て、プライベートIPアドレスでSSH接続してみます。 EC2のセキュリティグループでは、クライアントVPNエンドポイントのENIのセキュリティグループからのsshを許可します。 EC2の作成方法は省略。 VPN接続開始。 ssh接続成功。 [21-10-16 0:57 ~]# ssh -i KeyPair.pem ec2-user@10.1.0.206 The authenticity of host '10.1.0.206 (10.1.0.206)' can't be established. ECDSA key fingerprint is SHA256: Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.1.0.206' (ECDSA) to the list of known hosts. __| __|_ ) _| ( / Amazon Linux 2 AMI ___|\___|___| https://aws.amazon.com/amazon-linux-2/ 3 package(s) needed for security, out of 15 available Run "sudo yum update" to apply all updates. [ec2-user@ip-10-1-0-206 ~]$ pwd /home/ec2-user カスタムDNSサーバを設定しているので、ec2-user@10.1.0.206ではなく、プライベートDNSのec2-user@ip-10-1-0-206.ap-northeast-1.compute.internalでも接続可能です。 カスタムDNSサーバを設定していない場合、ssh: Could not resolve hostname ip-10-1-0-206.ap-northeast-1.compute.internal: nodename nor servname provided, or not knownというエラーが発生しました。 Session Manager接続 今度はSession Managerで接続を試すので、一旦VPNは切断します。 以下構成図の通信の矢印は以下公式ドキュメント及びVPCフローログを参考に作成したものですが、正確さは保証しません（VPCフローログの有効化手順や見方については本記事では説明していません。）。 VPCエンドポイント作成 接続先のVPCにはインターネットゲートウェイが存在しないため、Session Manager接続に必要なエンドポイントを用意します。 私のSession Managerの設定ではログを有効化しているので、logsとS3のエンドポイントも作成します。 また、Session Managerに必要なSSM,EC2message,SSMmessageのエンドポイントも作成します。 DNS解決ができるように、Private DNS names enabled は true にします。 falseにしてSession Managerで接続しようとすると、名前解決できず接続できません。 VPCエンドポイントのセキュリティグループは、インバウンドルールで VPC内からの 443 を許可するように設定します。 コンソールからも作成できますが、インターフェース型のエンドポイントはスクリプトで作成しました。 なお、削除はスクリプトからではなくコンソールから行いました。 #! /bin/bash endpoint_list=("com.amazonaws.ap-northeast-1.ssm" "com.amazonaws.ap-northeast-1.ssmmessages" "com.amazonaws.ap-northeast-1.ec2messages " "com.amazonaws.ap-northeast-1.logs") vpc="vpcID" subnet="subnetId" security_group="sgId" for endpoint in ${endpoint_list[@]}; do aws ec2 create-vpc-endpoint --vpc-endpoint-type Interface --vpc-id $vpc --service-name $endpoint --subnet-ids $subnet --security-group-ids $security_group --profile $1 done S3は無料のゲートウェイ型を使用しますが、作成手順は省略します。 インスタンスへのIAMロールアタッチ インスタンスにIAMロールをアタッチします。 IAMロールには、AmazonEC2RoleforSSMというAWS管理ポリシーを付けています。 接続 Session Managerで接続します。 [21-10-16 1:55 ~]# aws ssm start-session --target ixxxxxxx Starting session with SessionId: xxxxxx-xxxxxxx sh-4.2$ なお、logsのエンドポイントがない状態で接続すると以下のようになりました。 Starting session with SessionId: xxxxxxxxx-xxxx Exiting session with sessionId: xxxxxxxxxx-xxxx. まとめ インターネットゲートウェイがないプライベートなVPCにVPN接続し、SSH接続、SessionManager接続を行いました。 普段あまり気にしないVPC内のDNSについて、どのような構成であればDNSの有効化が必要か、少し理解できた気がします。 個人的にはAWSのクライアントVPNでVPN接続する際、ネームサーバの設定が変更されていたので驚きました（カスタムDNSを設定した場合）。 通常の設定 [21-10-16 20:11]# cat /etc/resolv.conf | grep nameserver nameserver 2001:xx:xx:xx:xx:xxxx:xx:xx nameserver 192.168.10.1 VPN接続時の設定 [21-10-16 20:10]# cat /etc/resolv.conf | grep nameserver nameserver 10.1.0.2 クライアントVPNのDNSについてはこちらをどうぞ。

はじめに こんにちは、なじむです。 今週から出社になりました。出社するようになり、朝日を浴びたり、駅まで歩いたり、一日三食ご飯を食べたりして、少し健康になった気がします。 というわけで今週も張り切ってやっていきましょう！AWS Japan さんがまとめている週刊AWSで確認した内容の自分用メモ。 今回は10/4週のアップデートです。 10/4(月) Amazon CodeGuru が Python アプリケーションのセキュリティ検出器と Bandit によるセキュリティ分析を発表 CodeGuru Reviewer は、CodeCommit 等のリポジトリに格納した Java/Python のコードを分析し、コードの品質やセキュリティの脆弱性などを検出してくれるサービスです。今回、Python のコードの分析で以下のアップデートがありました。 分析に OWASP (Open Web Application Security Project) が公開している Top10 等を用いるようになりました。 分析に Bandit を用いるようになりました。 OWASP は Web アプリケーションをはじめとするソフトウェアのセキュリティの問題や開発プロセスに関する情報を発信するオープンソース・ソフトウェアコミュニティです。OWASP では、Web アプリケーションを構築する上で特に注意しなければならない OWASP Top Ten 等を公開しています。 (参考) OWASP Japan Bandit は OSS の Python SAST (Static Application Security Testing) ツールです。 (参考) Bandit 実際に動作を見てみます。 CodeGur Reviewer 用に公開された python のリポジトリが無かったため、今回は CodeGuru Profiler の github を借りて実行しました。 (参考) Amazon CodeGuru Profiler Python Demo Applications やってみましたが、結果に OWASP や Bandit が反映されているのかは、私には分かりませんでした… 特に追加設定は不要で解析できるはずなので、やってることは間違ってはないかと思うのですが… 日本リージョン対応状況 東京：対応 大阪：未対応 ※CodeGuru自体に未対応 Amazon Location Service は、変更検出を追加 Location Service は、アプリケーションに地図を表示したり、現在地を取得したりといった機能が安全に追加できるサービスです。今回 Location Service で、新たに距離ベースのフィルタリングが使用可能になりました。 距離ベースのフィルタリングは、デバイスの位置情報を前回の位置更新と比較して30 m 未満の場合は記録しないようにする機能です。微妙な距離の移動が記録されないため、以下のメリットがあります。 重要な位置の変化のみが記録される ジオフェンス評価のトリガーを抑えることができるためコストが削減できる ジオフェンス評価の回数によって、従量課金されるようです ちなみに、ジオフェンスとはあるエリアを線で囲ったもので、そのエリアの入退室(？)を評価したりできます。 (出典) ジオフェンス 実際の画面は以下です。 トラッキングを作成する際に、距離ベースのフィルタリングが選択できるようになっています。 日本リージョン対応状況 東京：対応 大阪：未対応 ※Location Service 自体に未対応 10/5(火) VMware Cloud on AWS Outposts の一般提供開始を発表 オンプレミスで AWS のサービスを実行できるようになる AWS Outposts で VMware Cloud が使用可能になりました。 Outposts は下図のように、データセンターやオフィスに AWS がラックごと設置してくれます。 (出典) AWS Outpostsが一般提供開始になりました 実際に使ったことが無いのでどうやってリソースを作成するかイメージが湧かないのですが、各種 AWS のリソースをこのハードウェア上に作成します。容量不足にももちろんなるので、リソースの拡張を依頼するとハードが増設させるようです。 今回は、その Outposts で、VMware を実行することができる VMware Cloud が使用可能になりました。 日本リージョンの対応状況はよく分かりませんでした… アップデートには以下の記載があったのですが、これは東京、大阪でも対応している…のか…？ VMware Cloud on AWS Outposts のご利用は、AWS または VMware の営業担当者に連絡して注文後、開始することができます。VMware Cloud on AWS Outposts を米国に出荷し、米国東部 (バージニア北部) または米国西部 (オレゴン) に接続することができます。 米国外で VMware Cloud on AWS Outposts をデプロイしたり、VMware Cloud on AWS Outposts を他の AWS リージョンに接続したい場合は、AWS または VMware の営業担当者にお問い合わせください。 日本リージョン対応状況 東京：不明 大阪：不明 Amazon OpenSearch Service (Amazon Elasticsearch Service の後継サービス) はクロスクラスターレプリケーションのサポートを発表 ElasticSearch の後継サービスである OpenSearch Service で、他の AWS アカウントや他のリージョンに構築した OpenSearch Service にインデックスの複製や同期を自動化するクロスクラスターレプリケーションが使用可能になりました。 DR 対策として有効かなと思います。 注意事項として、Elasticsearch 7.10 を実行しているドメインでなければ使用できません（OpenSearch 1.0 では利用できません） クロスクラスターレプリケーションに対応した OpenSearch 1.1 を近日中リリース予定のようです。 また、クロスクラスターレプリケーションうを設定する上での注意事項は以下です。 Amazon OpenSearchService ドメイン間でのみレプリケーションが可能（自己管理の OpenSearch や Elasticsearch は不可） 最大20の他のドメインに接続可能 同じメジャーバージョンまたは最終的なマイナーバージョンと次のメジャーバージョンを共有する必要がある AWSCloudFormation を使用してドメインを接続することは不可 M3, T2 インスタンスでクロスクラスターレプリケーションは不可 その他の注意事項や詳細な設定方法は以下を参照ください。 (参考) Cross-cluster replication for Amazon OpenSearch Service 実際の画面は以下です。 アウトバウンドの接続のリクエストで、対象の Opensearch ドメインを指定します。 日本リージョン対応状況 東京：対応 大阪：対応 RDS Performance Insights はさらに 4 つのリージョンでご利用可能に RDS のパフォーマンスのモニタリングを行う RDS Performance Insights が大阪リージョンで使用可能になりました。RDS Performance Insights を有効にすると、SQL レベルのメトリクスを参照することが可能となります。 実際の画面は以下です。私の環境はデータが無さ過ぎてつまらないですね… やってみた系は以下の記事が参考になります。ご覧ください。 (参考) SQL レベルのメトリクス をサポートしたパフォーマンスインサイトで高負荷状態のDB稼働を確認してみた 日本リージョン対応状況 東京：対応 大阪：対応 10/6(水) Amazon SageMaker Data Wrangler で時系列データの準備と可視化をする 機械学習のモデルを開発、学習、デプロイするためのマネージドサービスである SageMaker には、SageMaker Data Wrangler という機械学習で使用するデータを作成してくれるサービスがあります。 SageMaker Data Wrangler のやってみた系のブログは以下を参照ください。 (参考) [Amazon SageMaker Data Wrangler] 機械学習用データを簡単で最速に準備できる機能を使ってみた 今回のアップデートでは、時系列変換機能が使用可能になりました。新しい時系列変換機能には以下の特徴があります。 不足値補完、時系列の特徴量化 (フーリエ係数、自己相関統計、エントロピー等) をサポート データセットをダウンサンプリングまたはアップサンプリングして演算子を再サンプリングして頻度の均一化、タイムラグ機能および Window 関数を展開 ベクトル値に基づく列のグループ分け、長さの均一化、フラット化、エキスポートなどのより一般的なオペレーションもサポート データ上の季節的な需要や傾向を可視化し、例外を特定すること可能に 実際の画面は以下です。 Quotas のエラーで怒られてしまいました…これから勉強していくという逃げここまでに… Data Wrangler failed to load. An error occurred (ResourceLimitExceeded) when calling the CreateApp operation: The account-level service limit 'KernelGateway Apps running on ml.m5.4xlarge instance' is 1 Apps, with current utilization of 1 Apps and a request delta of 1 Apps. Please contact AWS support to request an increase for this limit. 日本リージョン対応状況 東京：対応 大阪：対応 AWS Network Firewall がルールの順序とデフォルトドロップの新しい設定オプションを追加 Network Firewall は VPC 向けの Firewall で、インターネットに出る前に、プロトコルや宛先に基づいてパス、ドロップ、アラート等を実行することができます。 (出典) AWS Network Firewallのデプロイモデル 今回、Network Firewall のステートフルルールで以下のアップデートがありました。 最初にドロップルールを評価していたが、アラートルール・ドロップルールを指定した順序で評価できるようになった 追加のルールを書かなくても、すべてのルールにマッチしないトラフィックをデフォルトでドロップできるようになった 実際の画面は以下です（おそらくここの画面のはず…確証なし…） ルールの評価順は以下のように記載している順序で上から評価されます。 デフォルトのドロップのところは以下かなと思います。以前の画面を知らないので確証が無いのですがおそらく… ルールの評価順序が変わったので、影響が出てきそうなところもありそうですよね。注意が必要かもしれません。 日本リージョン対応状況 東京：対応 大阪：対応 10/7(木) Amazon Kendra は 34 言語のサポートを開始 機械学習を用いてドキュメントや FAQ を検索できるサービスである Kendra が日本語に対応しました。個人的にはずっと待っていたアップデートです。 ただ、日本語の自然言語処理って難しいんじゃ？と思っているので、精度とかを検証している方がいたらぜひ拝見したいと思っています（←待ってたなら自分でやれば…） 以下にある "help-desk-faq.csv" をダウンロードし、日本語化したものをサンプルデータとして使ってみます。 (参考) Smarter FAQ bots with Amazon Kendra 実際の画面は以下です。 今回は FAQ を登録しましたが、登録する際の言語を日本語に設定します。 検索する際の言語も日本語にすると… 日本語で検索できるようになってる！！！（料金はまだまだお高いのご注意を） なお、日本語には対応しましたが、日本リージョンには未対応でした。 日本リージョン対応状況 東京：未対応 大阪：未対応 Amazon QuickSight が Pixel-Perfect のダッシュボードのサポートを追加 BI (Business Intelligence) ツールのマネジメントサービスである QuickSight で、フリーフォームレイアウトが使用可能になりました。 これまではダッシュボードに表示するグラフやテーブルは、画面の大きさによって自動的に配置されるようになっていましたが、フリーフォームレイアウトを使用することで、自由に位置を指定することが可能となりました。また、グラフを重ねたりと言ったことも可能となっています。 設定画面は以下です。ここをフリーフォームにすることで、自由自在にグラフなどを配置することが可能となります。 実際の画面は gif でキャプチャを載せている公式ブログが参考になるかと思います。ヌルヌル動く…！ (参考) Create stunning, pixel perfect dashboards with the new free-form layout mode in Amazon QuickSight 日本リージョン対応状況 東京：対応 大阪：未対応 ※QuickSight 自体に未対応 AWS IoT SiteWise は、アジアパシフィック (ボンベイ)、アジアパシフィック (ソウル)、アジアパシフィック (東京) の AWS リージョンで利用可能 産業機器からデータを収集、モニタリングするサービスである IoT SiteWise が東京リージョンでも使用可能になりました。 (出典) AWS IoT SiteWise データを収集することにより、故障する前に機器の事前のメンテナンスができるようになったり、加工している商品・食品の品質管理に役立てることができます。 実際の画面は以下です。 東京リージョンでも利用可能になっています。 デモがあるので、それを基に構築してみると、アセットというものが作衛されます（裏で CFn スタックが作成されます） アセットを構築するだけだと何も情報が見えないので、可視化するためのポータルを構築します。 するとグラフとしてデータを見ることができるようになります。 日本リージョン対応状況 東京：対応 大阪：未対応 10/8(金) Amazon Neptune が Read Replicas 用の Auto Scaling のサポートを開始 グラフデータベースのマネージドサービスである Neptune で、Read Replica の Auto Scaling が利用可能になりました。 グラフデータベースは、例えば以下のようなグラフを作成、操作することができる RDB です。グラフデータベースを使用することにより、各データのつながりをより簡単に把握することが可能となります。 (出典) Amazon Neptune が東京リージョンに対応しました。 今回のアップデートでは、Read Replica の Auto Scaling が可能となり、Read Replica の可用性やコストをより柔軟に運用していくことが可能となりました。 この設定は GUI では実施できず、CLI or SDK を使用する必要があるようです。 CLI での設定方法は以下に記載があります。 (参考) Auto-scaling the number of replicas in an Amazon Neptune DB cluster 日本リージョン対応状況 東京：対応 大阪：未対応 ※Neptune 自体に未対応 Amazon ECS Anywhere が GPU ベースのワークロードのサポートを開始 オンプレでもコンテナの実行、管理を行うことができるようになる ECS Anywhere で、GPU ベースのワークロードがクラスターに追加できるようになりました。 (出典) Running GPU-based container applications with Amazon ECS Anywhere 今回のアップデートでは、ECS Anywhere にインスタンスを登録する際に実行する curl コマンドに --enable-gpu オプションを付与することで、GPUベースのワークロードが使用可能になったようです（動作未検証） curl --proto "https" \ ~~~~~~~（省略）~~~~~~~ --enable-gpu 公式ブログに詳細が記載されていますので、こちらをご覧ください。 (参考) Running GPU-based container applications with Amazon ECS Anywhere 日本リージョン対応状況 東京：対応 大阪：対応 AWS Backup で AWS Backup Vault Lock が利用可能になり、バックアップ保護のためのレイヤーがさらに追加 EC2 や RDS のバックアップ、管理を自動で行ってくれるサービスである AWS Backup で、Backup API を介した場合でもバックアップを削除ができないようにする AWS Backup Vault Lock 機能が使用可能になりました。 元々、AWS Backup で取得したバックアップはユーザが手動で削除することはできませんでした。しかし、AWS Backup の API を介した場合は削除することができていました。今回のアップデートでは、Backup API を介した場合でも削除できないようにする AWS Backup Vault Lock の機能が使用可能になりました。 こちらの設定は、現時点（2021/10/8）では GUI からではできず、CLI or SDK での設定が必要なようです。 やってみた系の記事は以下が参考になりましたので、ご覧ください。 (参考) [アップデート] AWS Backupがボールトのロックをサポートしました 日本リージョン対応状況 東京：対応 大阪：対応 感想 クラメソさんのブログ凄いなと、毎週アップデートを確認すればするほど思います。 このブログ、クラメソさん以外にもリンク張りまくったり、画像載せたりしてるけど大丈夫だろうかとかも思ったり。アウトだったら…すみません。

目的 API Gateway + Lambda でリダイレクトさせたいときの Go 言語のコードを紹介します。 リダイレクトさせる Go 言語のコード APIGatewayProxyResponse は、リクエストに対して API Gateway によって返されるレスポンスを構成します。よって、APIGatewayProxyResponse にリダイレクト（3xx）のステータスコードとリダイレクト先 URL をセットしてあげれば、クライアントにリダイレクトさせることが可能です。 package main import ( "net/http" "github.com/aws/aws-lambda-go/events" "github.com/aws/aws-lambda-go/lambda" ) func handler(request events.APIGatewayProxyRequest) (events.APIGatewayProxyResponse, error) { return events.APIGatewayProxyResponse{ StatusCode: http.StatusFound, // ステータスコード 302 を指定 Headers: map[string]string{ "Location": "https://aws.amazon.com/jp/", // リダイレクト先 URL を指定 }, }, nil } func main() { lambda.Start(handler) } APIGatewayProxyResponse の内容について APIGatewayProxyResponse で指定したリダイレクトのステータススコードの代表的なものとロケーションヘッダーについて簡単に解説します。詳細を知りたい方はリンク先を参照してください。 代表的なリダイレクトのステータススコード ステータスコードは http パッケージの定数を利用しています。以下に、リダイレクトのステータスコードの代表的なものを紹介します。用途にあわせて使い分けてください。 301 Moved Permanently：リクエストされたリソースが Location ヘッダーで示された URL へ完全に移動したことを示します。ブラウザは、301 リダイレクトを受け取ると、古い URL から新しい URL へのリダイレクトをキャッシュに記憶します。もう一度ブラウザで古い URL を表示しようとすると、古い URL にアクセスすることなく新しい URL にアクセスします。 302 Found：リクエストされたリソースが一時的に Location で示された URL へ移動したことを示します。ブラウザが 302 リダイレクトを受け取っても、リダイレクトをキャッシュに記憶することはありません。もう一度ブラウザで古い URL を表示しようとすると、ブラウザは古い URL にアクセスしたあとでリダイレクトします。 303 See Other：リダイレクトが新しくアップロードされたリソースではなく、 (確認ページやアップロード進捗ページのような) 別なページにリンクすることを示します。このレスポンスコードはふつう、 PUT または POST の結果として送り返されます。また、リダイレクトすときは GET メソッドを使用します。 307 Temporary Redirect：リクエストされたリソースが一時的に Location で示された URL へ移動したことを示します。ブラウザが 307 リダイレクトを受け取っても、リダイレクトをキャッシュに記憶することはありません。307 と 302 の唯一の違いは、 307 はリダイレクトされたリクエストが行われるときに、メソッドと本文が変更されないことが保証されることです。 使用されるメソッドを GET に変更したい場合は、代わりに 303 See Other を使用してください。 308 Permanent Redirect：リクエストされたリソースが Location ヘッダーで示された URL へ完全に移動したことを示します。ブラウザは、308 リダイレクトを受け取ると、古い URL から新しい URL へのリダイレクトをキャッシュに記憶します。301 の場合は GET メソッドに変更される可能性があるのに対し、308 の場合はリクエストメソッドと本文が変更されません。 ロケーションヘッダー ロケーションヘッダー はリダイレクト先の URL を示します。 以上です。

勉強前イメージ AWSのアカウントを楽に切り替える・・・？ 言われてみればなんて説明したらいいか難しい 調査 スイッチロール とは AWSがアカウント管理に使っているIAMの機能で、 複数のアカウントにログインできる権限をロールとして付与し、付与するポリシーによって使えるサービス等を変更することができます。 スイッチロールなしでは以下のように別のAWSアカウントを使用する際は ログインとログアウトを繰り返さなければいけません。 スイッチロールを使用すると、ロールの切り替えのみで、 ログイン・ログアウトをする必要がありません。 また、使用するサービス等をポリシーで変更できると↑で記載しましたが、 各AWSアカウントの管理者も一括にポリシーを変更できます。 スイッチロールのメリット AWSアカウントと管理 AWSアカウントの管理は煩雑で、環境やアカウント、それぞれのIDやユーザ名など管理しないといけません。 また担当者の変更があった際は上記の管理から変更しないといけないので多くの工数が発生します。 ですので、アカウントの管理を簡素化し、各環境にユーザに合った権限で閲覧できるように一元管理を行います。 AWS利用者の操作 管理者だけでなく、利用者もログイン・ログアウトせずとも他の環境に移行できるので煩わしい操作が減少します。 勉強後イメージ 確かにアカウント管理個々のAWSアカウントでやってたらすごいことになりそう・・・ 参考 【AWS】IAMのスイッチロールの設定方法 AWSのスイッチロールとは？そのメリットと設定方法を解説！

他のタグ AWS Android Docker Git Go iOS Java JavaScript Linux Node.js PHP Python Rails React Ruby Swift TypeScript Vim Vue.js 初心者 集計について 期間: 2021-10-16 ~ 2021-10-17 GitHub スターをもらえるととっても励みになります LGTM 数ランキング 1 位: SAP ABAP Platform 1909, Developer Edition（dockerhub）をopenSUSE Leap 15.3（EC2）で起動してみる AWS Docker SAP openSUSE abap 2 LGTM　0 ストック @SAITO_Keita さん ( 2021-10-17 17:59 に投稿 ) 2 位: 【AWS】独自ドメインでのWebサイトアクセス/S3でのSorryページホスティング AWS S3 route53 1 LGTM　1 ストック @zeems さん ( 2021-10-16 12:17 に投稿 ) 3 位: AWS Cloud9でターミナルを消してしまった時の対処法 AWS cloud9 1 LGTM　0 ストック @mi_14 さん ( 2021-10-17 10:59 に投稿 ) 4 位: 何となくわかった気になる週刊AWS - 2021/10/4週 AWS 1 LGTM　0 ストック @NaGym_t さん ( 2021-10-16 20:40 に投稿 ) 5 位: AWSを使った動画配信についてメモ AWS AWSMediaServices 1 LGTM　0 ストック @Masa79 さん ( 2021-10-16 13:59 に投稿 )

AWSを使った動画配信についてメモ AWS Media Services 動画配信に使えるAWSの一連のサービス群 上記2つの画像は下記動画より参照 【AWS Black Belt Online Seminar】AWS Media Services で始めるライブ動画配信 ハンズオン 01 AWSで動画配信をはじめよう 前提: - 有効なAWSアカウントがある - OBSをインストールしていること 第一章 シンプルな HLS ライブ配信 所要時間20-30分 AWS MediaStoreとMediaLive、OBSだけで完結する OBS→MediaLive→MediaStore→hls.jsを使って配信確認 ※ 第一章のハンズオンをした場合の料金 合計で0.68ドルぐらいかかりました。 数分程度のストリーミングでこれなのでやっぱり配信はお金掛かりますね。 OBS OOS リポジトリ→https://github.com/obsproject/obs-studio C, C++で書かれている 動画データの転送にはReal Time Messaging Protocol (RTMP) を使う How to Use OBS Studio - Complete Tutorial for Beginners! インストール 【解説】OBS Studio(Mac版)のダウンロード・インストール方法 プロトコル 上記Black Belt 動画より HLS(HTTP Live Streaming) 参照 HTTP Live Streaming, HLSのまとめ　概要・仕組み・課題など HLSはApple社が開発した技術 現在ではHTTPストリーミング配信では最も多く利用されているプロトコル HLSはインデックスファイル（.m3u8）とセグメントファイル（.ts）に分かれて配信される ハンズオン第一章で配信開始後にMediaStoreで.m3u8の拡張子を探した理由 インデックスファイル（.m3u8）は動画をスムーズに再生させるように以下を記述 配信形式を指定、 tsファイルの順番や秒数 ファイル名を定義 セグメントファイル（.ts） 動画コンテンツを格納したファイル インデックスファイルに定義された規則に従って再生

EC2インスタンスの基本操作について EC2の設置と起動はマネージメントコンソールで行う。 マネージメントコンソールとはログイン後最初に遷移する画面のこと。 起動したEC2に対しては、SSHソフトウェアを利用して接続をして操作する。 EC2の削除について インスタンスの停止と終了の違い 停止はインスタンスを停止する 使用時間を止めたいときなどに使う 終了はインスタンスを削除する インスタンスを削除したい時に使う 削除した場合は数時間後に一覧から消える 終了保護について 大切なインスタンスをうっかり削除しないように終了を押せない設定がある。 大切なインスタンスは設定して置くのが良い。 EC2の画面>アクション>インスタンスの設定>終了保護を変更で設定できる。

はじめに Webサイトに独自ドメインでアクセスできるようにRoute 53を使用して、ホストゾーンの作成・設定をしていきます。 また、Webサイトに障害が発生している時やメンテナンス中などに表示させるSorryページをS3の静的ウェブサイトホスティング機能を使用して構成していきます。 構成図 以下のような構成を目指します。 【通常時】 【障害発生時】 ドメイン取得 今回ドメイン取得は「お名前.com」で行いました。 1年間利用できるドメインを1円で取得できました。 ホストゾーン 作成 マネージド型のAWSサービスである「Route 53」を使用して、取得したドメインとロードバランサーのDNS名を紐付けていきます。 まずはホストゾーンの作成を行います。 Route 53の管理画面を開き、画面左メニューで[ホストゾーン]を選択後、[ホスト ゾーンの作成]をクリックします。 ドメイン名に取得したドメインの名前を入力、タイプで「パブリックホストゾーン」を選択して、[ホストゾーンの作成]をクリックします。 例） example.com 作成したホストゾーンの詳細画面が開きます。 [レコード]タブを選択し、タイプが「NS」となっているレコードを参照し、値/トラフィックのルーティング先に記載されているネームサーバ情報を確認します。 NSレコードに記載されているネームサーバはこのドメインを管理するサーバとなります。 次の手順で取得したドメインにこのネームサーバ情報を登録していきます。 ネームサーバ 登録 取得したドメインの管理画面にて、ネームサーバ設定に先ほどホストゾーン画面で確認したネームサーバを入れていきます。 お名前.comの場合は、ドメイン詳細画面から[ネームサーバーの変更]をクリックします。 2.ネームサーバーの選択で[その他]-[その他のネームサーバーを使う]を選択し、先ほど確認したネームサーバ情報を入力します。 入力ができたら、[確認]をクリックします。 確認画面が表示されるので、[OK]をクリックします。 これでネームサーバの登録は完了です。 Sorryページ用S3バケット 作成/設定 S3バケットを作成 SorryページをホストさせるS3バケットを作成します。 S3の管理画面を開き、画面左メニューで[バケット]を選択後、[バケットを作成]をクリックします。 Webサイトにアクセスする際に使用するサブドメインを後の手順で設定しますが、SorryページをホストするS3バケットの名前はそのサブドメインと同じにする必要があります。 サブドメインとして設定予定の名前をバケット名に入力します。 例） www.example.com 今回は誰からでもアクセスできるように設定するため、このバケットのブロックパブリックアクセス設定の[パブリックアクセスをすべてブロック]のチェックを外します。 チェックを外すと確認項目が表示されるので、[現在の設定により、このバケットとバケット内のオブジェクトが公開される可能性があることを承認します。]にチェックを入れ、[バケットを作成]をクリックします。 Sorryページ用HTMLファイルをアップロード 作成したバケットの詳細画面を開き、[オブジェクト]-[アップロード]をクリックします。 ファイルとフォルダの[ファイルを追加]をクリックし、Sorryページ用HTMLファイルを選択後、[アップロード]をクリックします。 静的ウェブサイトホスティング機能を有効化 バケット詳細画面で[プロパティ]タブを選択し、静的ウェブサイトホスティングの[編集]をクリックします。 [有効にする]を選択し、インデックスドキュメント エラードキュメントにSorryページ用HTMLファイルのファイル名を入力し、[変更の保存]をクリックします。 変更が完了し、静的ウェブサイトホスティングに記載されているバケットウェブサイトエンドポイントのURLにアクセスしてみるとアクセス拒否が発生します。 アクセスを許可するためにバケットポリシーの設定を行います。 バケットポリシーを設定 バケット詳細画面で[アクセス許可]タブを選択し、バケットポリシーの[編集]をクリックします。 以下のバケットポリシーを入力し、[変更の保存]をクリックします。 ※バケット名(Bucket-Name)の部分は置き換えてください。 BucketPolicyEditor { "Version": "2012-10-17", "Statement": [ { "Sid": "PublicReadGetObject", "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetObject" ], "Resource": [ "arn:aws:s3:::Bucket-Name/*" ] } ] } 上記バケットポリシーは以下のAWS公式ドキュメントに記載の値を使用しています。 バケットポリシーを設定することによって、Sorryページへのアクセスができるようになります。 DNSレコード 作成 取得したドメインでWebサイトにアクセスできるようにロードバランサーとの紐付けのためのレコードを作成していきます。 Route 53の管理画面でホストゾーンの詳細画面を開き、[レコードを作成]をクリックします。 最終的には障害発生時にS3の静的ウェブサイトにルーティングする構成とするので、ルーティングポリシーでは[フェイルオーバー]を選択し、[次へ]をクリックします。 本記事のレコード作成手順では「ウィザード」による作成で進めていきます。 以下の画像のような「クイック作成」となっている場合は右上の[ウィザードに切り替える]をクリックして進めてください。 基本的な設定に設定値を入力します。 今回は以下の値で設定します。 項目名 設定値 レコード名 サブドメイン名(S3バケットと同じ名前) レコードタイプ A TTL (秒) 60 [フェイルオーバーレコードを定義]をクリックします。 今回は以下の値にて2つのフェイルオーバーレコードを定義します。 【ロードバランサー用】 項目名 設定値 値/トラフィックのルーティング先 Application Load Balancer と Classic Load Balancer へのエイリアス リージョン アジアパシフィック (東京) [ap-northeast-1] ロードバランサー Webサイトのロードバランサー フェイルオーバーレコードタイプ プライマリ ヘルスチェック なし ターゲットのヘルスを評価 はい レコード ID 任意の値 【S3用】 項目名 設定値 値/トラフィックのルーティング先 S3 ウェブサイトエンドポイントへのエイリアス リージョン アジアパシフィック (東京) [ap-northeast-1] S3エンドポイント 設定したS3 フェイルオーバーレコードタイプ セカンダリ ヘルスチェック なし ターゲットのヘルスを評価 はい レコード ID 任意の値 フェイルオーバーレコードが追加できたら、[レコードを作成]をクリックします。 フェイルオーバー 動作確認 まずはブラウザからサブドメインにアクセスし、Webサイトが表示されることを確認します。 正常にWebサイトを表示することができたら、EC2インスタンスを2台とも停止し、サブドメインにアクセスしてもWebサイトが表示されない状態とします。 TTLに設定した60秒が経過した後にサブドメインにアクセスすると、Sorryページが表示されることを確認します。 ヘルスチェックとエイリアスレコード ヘルスチェック Route 53では指定したリソースの正常性を評価するヘルスチェックを作成し、それをレコードに紐付けることができます。 ヘルスチェックが設定されている場合には Route 53 によって正常なレコードが選択されます。 ヘルスチェックのないレコードは常に正常とみなされるため、実際にリソースが正常でなくてもDNSクエリに対して応答します。 エイリアスレコード Route 53には固有の拡張機能として「エイリアスレコード」というレコードがあります。 レコードの値としてAWSリソースを直接指定するものになります。 詳細は以下を参照してください。 本記事で作成したフェイルオーバーレコードはロードバランサー用、S3用ともにエイリアスレコードとなります。 基本的にエイリアスレコードの正常性を評価するためにヘルスチェックを作成する必要はなく、ターゲットのヘルスを評価を「はい」に設定することでヘルスチェックが実行されます。 補足 別途Route 53のヘルスチェックの作成を試した際にヘルスチェッカーからの通信がセキュリティグループによって許可されていないことで上手くいかないといったことがありました。 世界各地にRoute 53のヘルスチェッカーが存在しますが、AWS CLIの以下コマンドにてヘルスチェッカーのIPアドレスを確認することができます。 AWSCLI $ aws route53 get-checker-ip-ranges あとがき この記事は AWS CloudTech の課題として作成しました。 動画やハンズオン等で学習を進めることができるので、AWS初学者にはおすすめです。