今日はなにの日。

気になったこと勉強になったことのメモ。

トップ > AWS > 今日は、AWSを使っていて色々と困った話をまとめてみたの日。

今日は、AWSを使っていて色々と困った話をまとめてみたの日。

AWS

目次

とある日

年の瀬に色々と振り返るとAWSで困ったなって思ったのでまとめてみました。

AWSを使ってて困ったいろいろな話

AWSを使っていて困った話を色々とまとめてみました。

AWS歴は3,4年ぐらいです。

順番は思いついた順です。

命名規則が違う

ハイフンがつかえたりつかえなかったり、大文字にできなかったりスペースできなかったりなどなどリソースによって異なるので注意が必要。

  • S3バケット
    • バケット名は 3 (最少)～63 (最大) 文字の長さにする必要があります。
    • バケット名は、小文字、数字、ドット (.)、およびハイフン (-) のみで構成できます。
    • バケット名は、文字または数字で開始および終了する必要があります。

Terraformで共有のプロジェクト変数で使えない文字列入れてて怒られることがよくある。

検索バーのパターンが異なる

どういうことかというと、AWSでは各サービス画面でリソースの検索ができるバーがあります。

以下参考画像。

ですが、場所によって完全一致だったり、大文字小文字区別したりと分かれています。

そのため、「Test-RDS-group」みたいなリソースを検索するときに、とある検索バーでは「test」でもヒットしますが、とある検索バーでは「Test」じゃないとだめなところがあったりして困惑します。

リージョン問題

AWS始めたてだとかなりあると思われる、リージョンが分かれていることによる弊害で起きる問題です。

以下に過去あった例をいくつか上げてます。

ACMを使っているときの話

ALBにACM紐付けようとして、「あれない....」って、確認するとリージョンが違って作り直しになるパターンがあります。

他の AWS リージョンまたはアカウントで同じドメイン名を使用して ACM 証明書を作成する

ACM を使うならリージョンに気をつけましょう [cloudpack OSAKA blog] - sorta kinda...

グローバルサービスを使う時の話

グローバルサービスはバージニア北部リージョンにログが集約される。

そのため、IAMの操作ログをCloudTrailで探すときに東京リージョンを指定していると一生ログは出ない。

Route53のイベントをEventBridgeで拾おうとして東京リージョンで一生頑張ってた。

CloudFrontのCloudWatch Alarmを作成してもバージニア北部リージョンに作られるので気をつけましょう。

だから私はバージニア北部リージョンをメインとして検証で使っています。

（それによる弊害もあります）

複数アカウント運用で起こるイベント

MSP事業で、複数のお客様アカウントを使っている場合で起きる話です。

とあるお客様は、東京リージョンで作業を行って、別のお客様にアカウントに切り替えたとき前のアカウントのリージョンが引き継がれる？ので、リージョンサービスを見て、「あれ、リソースが無い、え」ってなります。

心臓に悪いのでやめてほしい（どうしようもない）

アベイラビリティーゾーン問題

リージョン問題と似た話ですが、こちらも色々とあります。

以下に同じくいくつか例を上げておきます。

EBSアタッチするときの話

EBSを新規で作成してEC2にアタッチするとき一覧に出てこなかった。

ボリュームとそのアタッチ先インスタンスは同じアベイラビリティーゾーンに存在している必要があります。

Amazon EBS ボリューム - Amazon Elastic Compute Cloud

作成したいインスタンスタイプがない

作りたいインスタンスタイプが指定したAZになかったりする。

EC2インスタンスタイプ毎に対応しているAZを確認する方法を教えてください | DevelopersIO

ap-northeast-1bあるのかないのか問題

タイトル通りの話。

極力使わないようにしている。

ap-northeast-1a は概念 - less is more

EC2の基盤障害

たまに、EC2が落ちて監視からアートがあがる。

まず最初に基盤を疑う。

最近は、CloudWatch Metricsより先にHealth Dashboardを確認する。

インスタンス障害の原因が基盤障害かどうかの確認方法 | DevelopersIO

これは困っていることというより、クラウドで起きるイベントなのでしょうがないですが、まぁ「ん？」ってなりますね。

クォータに引っかかる

IAMロールに紐付けれる管理ポリシーのクォータに引っかかったことがある。

SES関連のクォータ上限解放はよく聞きますね。

VPCとかもよくよくある話な気がします。

ある日突然クォータでエラーになって、ドキュメント確認して「え、すくな」ってなります。

気をつけましょう

CloudFormationのデプロイが終わらない

クォータ？に関連する話です。

ある日、IAMリソースをCloudFormationで作成していてデプロイが一向に終わらなかったです。（ずっと待っていると終わるのかもしれないですが）

色々と確認すると、作ろうとしたIAMポリシーがポリシーサイズを超えていたみたいなのが原因でした。

コンソールだとオーバーしているよって教えてくれます。

（エラーになってくれてもよくないかと思いました）

コンソールのUIが頻繁に変わる

見方を変えればアップデートが頻繁で良いことなのかもしれないです。

これによって困ることとは、初めて触るサービスでやってみた系の記事を見ながらやってたときに画面が違いすぎて、「え、これなに設定するの...」って虚無の時間が生まれることです。

だから私は「IaC」。

コンソール読み込みおそい

最近RDSを開くとめちゃくちゃ遅い。（共有認識みたい）

変更を押せばなお遅い。

最近はリージョンページを開くと少し読み込みが必要になる。(使わないリージョンを表示しないようにしてくれているおかげ)

AWS CLI ドキュメント を検索するとバージョン1のヒット率高い

論より証拠。

一応補足として、AWS CLIはバージョン1と2があります。

バージョン1を開くと怒られます。

対処法あれば教えてください。

Root以外の操作できなくなることがある

過去にS3バケットのバケットポリシーでALL Denyして、「あ」ってなったことがあります。

Rootでしかできないことが意外とあったりするので、知らないでやると「あ」ってなります。

お願い城之内、Amazon S3 のバケットポリシーに Deny を使わないで！ | NHN テコラス Tech Blog | AWS、機械学習、IoTなどの技術ブログ

ドキュメントの日本語が日本語じゃない

個人的には、もう日本語が悪いと思うことにしました。

ツイッターで調べると色々と出てくる。

サービス名がぱっと見分からない

↓サービス名はこんなやつです。

「access-analyzer.amazonaws.com」

IAMポリシーでプリンシパルを設定するときにリソースごとに指定する必要があります。

間違えると正しく権限を使うことができません。

EventBridgeとEventBridge Schedulerで最近ハマった。

  • EventBridge Scheduler：scheduler.amazonaws.com
  • EventBridge ：events.amazonaws.com

LambdaもLambda@Edgeでも違ったりするので注意が必要。

〆

思いの外、書いているといっぱい出てきた。

それぐらいAWSに触れていると考えると感慨深いと思う今日このごろ。