第１回 【全体編】¶
■全体的な説明、主要サービスの特徴¶
AmazonWebServiceについて¶
GCP（Google）,Azure（Microsoft）と並び三大クラウドサービスの一画（というか最大勢力）。
高いスキルを持ったAWS技術者の市場価値高し。
参考：稼げるIT資格はどれ？―米グローバルナレッジが2020年版のトップ15を発表
クラウドの最大メリット：実物を調達しなくても、必要なものを必要なだけ、簡単に揃えられる。
→個人レベルでも発想とスキル次第で何でもできちゃう世に。
これからのエンジニアはインフラエンジニアだけでなく、アプリケーションエンジニアにもクラウドサービスのリテラシーは必要（と思う）。
三大クラウドのどれか一つでも、それなりに勉強しておけば他のサービスでも活きるはず（似たようなサービスがあるので、ああこれはAWSでいうアレに近いな...など）。
リージョンとAZ¶
VPC内のサービスと外のサービス¶
- VPC(VirtualPrivateCloud)内のサービス→EC2やRDS、ECS、Elasticacheなど
- VPC外のサービス↑以外全部（※）
参考: AWS初心者 入門編 脱・知ってるつもり！AWSのネットワーク関連用語を基礎からおさらい
※ いっぱいありすぎて把握しきれず
普通のシステムを構築する上でよく使うのはS3, Lambda、Route53、CloudFront、CloudWatch、ACM、ELB、SNS、SQS、SES、ApiGateway、DynamoDB、Cognitoあたり
サービス名についているAWSとAmazonの違いについて
AWS用語の基礎知識 〜 気をつけておきたい！サービス名の表記について
マネージドなサービスとそうじゃないやつ¶
それぞれ責任範疇がちがう。
責任共有モデル ←アソシエイト試験で出る
マネージドじゃないやつ → EC2。AWSはインフラを用意してくれるだけ（IaaS）。セキュリティパッチ適用などはユーザの責任。
↓この辺わかりやすいかも
https://capsulecloud.io/blog/aws/5103
グローバルサービスとリージョナルなサービス¶
前者はCloudFront,Route53, IAMなど。リージョンに関係ないグローバルなサービス。
ほとんどが後者のリージョナルサービスに属する。サービスによっては特定のリージョンでしか利用できない。
（時間をおいて後からサポートしてくれる場合あり。例：SES）
アーキテクチャ¶
- ①レガシーなアーキテクチャ
- ②サーバレスアーキテクチャ
①はオンプレミスの構成をそのままとりあえずクラウドに乗っけてみたようなやつを指す。
②はAWSのマネージドサービスだけで構成されたアーキテクチャを指す。
①より②が優れているとかそういうことではなくシステムの要件次第で最適なアーキテクチャを選択する。
システムの一部だけサーバレス化するなど、ハイブリットも化。
https://www.slideshare.net/keisuke69/serverless-revolution
■AWSアカウント作成後の推奨設定¶
ClassMethodさんの記事があるので口頭で補足¶
AWSアカウントを作ったら最初にやるべきこと ～令和元年版～
※ ↑は実際に業務プロジェクトに使う想定でアカウントの管理者向けに書かれている内容と思われるので個人の勉強用AWSアカウントではここまでやる必要はないです
【はじめてのAWS】 AWS Budgetsで予算を管理しよう
仮想MFAデバイスにはGoogle Authenticatorがよく使われるがiPhoneユーザには特にMicrosoftのAuthenticatorの方を強くお勧めしたい。
コスト（料金）について¶
基本的には使った分に応じて課金（オンデマンド）。
インスタンスが立ち上がっていた時間やデータ通信量、APIリクエスト数などで課金される。
予め使いたい量が判っている場合にはまとめて買った方が安くつく場合も。
よくありそうな誤解→「アカウント作成後１年間の無料期間が終わったらいっぱいお金かかりそう」
無料枠には1年間限定のものと永続的なものがある。
1年間限定の無料枠は本当にオマケみたいなもので、使い方次第でお金はいっぱいかかるし逆に無料枠がなくても使い方次第でほとんどかからない。
1年間の無料枠がなくなっていても、勉強用に使うくらいなら月数百円もいかない。
前者の代表的な例はEC2やRDSのt2.microインスタンス利用料金（月750時間無料）やS3のストレージ5GB。
後者の代表的な例はLambda。
AWS 無料利用枠
Lambda無料枠
コスト見積ツール(AWS Pricing Calculator)
サーバレスのアーキテクチャに関連する多くのサービスには永続的な無料枠があり、小規模なサービスであればほとんどゼロコストで運用も可能。
■やってはいけないこと¶
アクセスキー、シークレットキーのソースコードへの埋め込み¶
→ これだけは絶対にやってはいけない！（そもそもそんな必要はない）
→ 万が一、管理者権限などを持つユーザーのキーをgithubなどにアップした場合、速攻で悪人に利用されて短期間に数十～百万の料金を請求されかねない。
→ 必要なアクセス権限はローカルのawsの設定あるいは環境変数や、インスタンスにアタッチしたIAMRoleから設定させる（ソースに埋め込む必要は全くない）
作成した従量課金リソースを放置¶
「何に課金がされるか」を常に意識して無駄な課金を避けましょう。
個人でも業務でも（特に業務では支払う人が自分じゃないからといって意外にずぼらな人がけっこういる印象）。
Qiita記事：AWS初学者が「うっかり課金」されがちなポイントとその対策まとめ
同じ個人が複数のAWSを作るのはありか？¶
→ 普通にあり
システムごとや、本番用や検証用など目的や用途に応じて複数のAWSアカウントを作るのは普通のこと。
たくさん作ると請求や管理が大変になるので複数アカウント管理用のAWS Organizationsというサービスがある（→ソリューションアーキテクト・プロフェッショナル試験でこの辺に関連する問題がよく出る）
同じサービスで無料枠を使って課金を逃れるために複数のAWSアカウントに分散させるようなせこい使い方はNG。
同じメールアドレスで複数のrootアカウントを作れないのでgmailのエイリアスを使うと便利かも
■【HelloWorld】Amazon S3でHelloWorldの静的Webページを公開してみる¶
- "test-アカウントID"のS3バケットを作成
- S3の設定でWebに公開できるようにしてみる
- htmlファイルをアップロード
Amazon S3 での静的ウェブサイトのホスティング
バケットポリシー設定例
■Cloud9からAWS-CLIを使ってみる¶
ブラウザベースの統合開発環境。
"AWS-CLI"や"SAM-CLI"を始め、すぐに開発ができる状態になっている便利な環境。
一方、VSCodeやIntellJ Ideaなどと比べるとさすがにエディタとしての機能はいろいろと劣る（特にJavaは厳しい）。
本格的な開発環境として使うのは自分としては？？だが、JSやpythonでちょっとコード書いて何か作ったり試したりしたいときには便利。
IEやEdgeなどのMicrosoft系のブラウザとは相性悪し。
# アカウントID調べる aws sts get-caller-identity # S3バケットからindex.htmlファイルを取得 aws s3 cp s3://test-アカウントID/index.html ./ # 編集する # S3バケットに編集したindex.htmlファイルをアップロード aws s3 cp ./index.html s3://test-アカウントID/index.html