AWS Summit Osaka 2019
twitter hastag:
AWSSummit, AWSSummitOsaka
my twitter:
silver_birder
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6月27日 10:00-11:30
基調講演
長崎 忠雄 (アマゾン ウェブ サービス ジャパン株式会社)
昨年AWSSummit0sakaをやろうとしたけど、震災の影響で中止になった。
つまり、今回が初めてか!
クラウドコンピューティングの進化が凄まじい。今回は、それの学びの場を提供。
サービスが出すぎて混乱しちゃった私なんだな...
2019年第1四半期
$30.8B → 3.3兆円
年間成長率 31% !?!?
成長しすぎじゃない!?!?
AWSは13年しかたっていない。
アベイラビリティゾーン
分散されたデータセンターの集合地域。
東京には4つある。
全体的には66アベイラビリティゾーンある。
AWSのサービスが、年に400ものサービス追加している。
2008年は24こで、2018年で1957こにも増えてる。
→ むしろ増えすぎてよくわからんかも。
たった一人の個人のアイデアが世界に広がる。
教育期間9000,公共期間5000。すごすぎ。
お客様ほんとさまざま多すぎる。
あらゆる業界ほんとそれ。
AWS OsakaOffice爆誕か!?!?
AWS Loft
StartUpのDeveloper向け。AWSDeveloperがいる。
DEV DAY 2018
Developer向け。(StartUpだけじゃないってことね)
ライブ配信あり。
クラウドコンピューティング
いつでも誰でも手軽に起動できる。
将来のIT人材供給力不足
BigData,Iot,AIが今後産業に大きな革命がありうる。
AWS educate
学生向け。
将来のIT人材育成のため。
ハードウェア主体の考え方から、ソフトウェア主体の考え方が今後重要。
netflixは、過去ハードウェア(DVDレンタル)だったものがソフトウェア(ダウンロードレンタル)になった。
いまは、ハードウェアによる縛りがほぼなくなったから、ソフトウェアが充実してきたもんね。
ハードウェアエンジニアから、ソフトウェアエンジニアが今後必要になる。
デバイスが増えると、トラフィックが膨大に増えていく。
交通、エネルギー、リテール(スーパーとかかな?)、家電。ヘルスケア、農業。
これらの産業でデバイス接続が多くなってる。
AWSは、オフィスを持っていない???
AWSは、お客様の抱えられている問題、喜んでもらえることを先駆けて取り組んでいる。
顧客体験→顧客数→出店者数→品揃え→顧客体験のサイクル。
お客様とのFeedBackを得てTry&Errorのサイクルを早く回していくことで、
満足度を改善していく。
琉球銀行 メディア戦略室 室長の方が登壇。
ラジオをジャックしたりしている。
何事にもチャレンジングな感じ。
新入社員の初仕事はフラッシュモブ。やべえ。
オンプレミスで動いていたサーバをAWSに移行。すごい。
ユーザー部門だけでAmazon Connectを使ったそう。
沖縄では車社会なので、AmazonAlexaを活用。
長崎さんが戻ってきた。
クラウドジャーニー(旅行)って?
クラウドに移行するって意味っぽい?
2つのクラウドジャーニ
サービス系システム、基幹系システム
サービス系は顧客体験の強化、UIの連続的改善。
基幹系はシステムの安定性、データの完全性。
サービス系だと、例えばECサイトのWebサーバをAWSにかな?
基幹系だと、例えば顧客や売上の基幹システムとかかな?
計画→ハイブリッド→拡張と最適化→クラウドファースト
ああ、ちょっとメモ忘れてた...。
次は、京セラ株式会社 藤田さん
基幹システムのクラウド移行。
基幹システム
老朽化
COBOL→Java
オンプレ→クラウド
まじ!?!?
AWSに移行した理由
AWSには、インフラ管理手法(infrastructure as code)が提供されていたため。これは確かに。
immutable infrastructureにも惹かれた。
安定した構築自動化は素晴らしい。
ハードウェアというオンプレからソフトウェアというクラウドに移行。
GCPも、インフラasコード的なんなかったっけ?
データベース
商用データベースでは、扱う量がGBからPBまで増えていく。
レイテンシはmsを求めるように。
ワークロードに適した最適なデータベース選択
DBめっちゃ多い。
リレーショナル、キーバリュー、ドキュメント、インメモリ、グラフ、時系列、データウェアハウス。
DBで87%のお客様が<1mの待ち時間だったみたい。
だけど、ほかはまだ1mを超える待ち時間があった。
amazon redshit concurrency scalingで対応したみたい。
AWS Windowsインスタンス
特殊な設定なくすぐ起動できる。
Azureじゃだめなのか...?
Amazon FSx for Windows file server
おお、データをマウント可能になった。Windows移行も楽チンや。
VMware Cloud on AWS
VMware上でもAWSを導入できる。
Amazon Sumerian
めっちゃきになってる。xR領域に興味あるんだよな〜。
なんか良いこと聞いた「我々が作りたくて作っているのではなくて、お客様の要望による。GKEとかもそう」
ヌーラボの方が登壇。@Masa 👨💻 Nulab
(ちょっとよそ見してた...)
ソフトウェアの構造と開発構造のミスマッチ
→ マイクロサービス化のためK8sを採用。
1.5ヶ月でAWS構成図を自動生成機能ができた。
とても早そう。(よくわからないけど)
backlogもマイクロサービス化を検討
issues,wiki,gantt,git,files.
話は割とDeveloper向けだね。
ごめんなさい、k8sの話で別のこと考えてた...。
下記セッションでその話があるみたい。
「クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そし て組織」
よかった、参加してる!
長崎さんが戻ってきた
Amazon SageMaker
開発→学習→推論
AWS DeepRacer
機械学習を学習しながら遊べるKit.
オンラインで世界中の人が参戦するVirtualレース。
強化学習はしたことあるけど、苦手なんだよな〜。
AIサービスも充実
何も機械学習を知らない人でも、AIサービスがつける。
んー、こういうのって実際プロダクトとして使えるのか?
お試しで学ぶ用途なのかな。
Amazon Forecast 予測
Amazon Personalize リコメンデーション
なんか2年前に見たAWSコンソールから、
いまどんだけサービスあるんだろ。やばそう。
amazon echoやスマホアプリとかでDominoピザのおすすめピザを提供。
Amazon Personalize 。そんなの裏で動いてるんだね。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6月27日 12:00-12:40 会場:C
Amazon Sumerian によるVR/AR/MRアプリケーションの開発
amazon sumerian(スメリアン)を利用すると、どのようなことができるのか。
会場内で使った人いない。。。w
自己紹介
大井さん
日経Sler
Amazon Sumerianの位置づけ
xR
・VR (virtual reality) 仮想の世界に没入
・AR (augmented reality) 物理に仮想をオーバレイ
・MR(mixed reality) 物理と仮想が相互作用
MRは、現実から仮想領域に干渉できる。
xRアプリの課題
・ハードウェアが浸透していない
・何が必要?
・どうやって作る?
・使ってもらえるかわからない
一般的なxrアプリケーション開発のプロセス
発案→3Dエンジンの準備→デバイスSDKの準備→プラットフォームの登録→...→
デバイスが増えると、さらに増える。
Sumerianの特徴
Webブラウザベースの開発環境、Sumerian Host, マルチプラットフォームの利用者環境、AWSのサービスとの連携
お、Webブラウザベース良いやん。
Webブラウザベースの開発環境
→ 従量課金
マルチプラットフォーム
→ モバイル、デスクトップ、VRヘッドセット、ARプラットフォーム
Sumerian Host
→ セリフにあわせて口を動かしたりジェスチャーを行うキャラクター
8人のキャラクターがいる。
自分の好みのキャラを使いたいな。
AWSのサービスとの連携
→ AWS SDKを使って各種サービスを使える。
XRを活用したユースケース
ブランドエンゲージメント、デジタルサイネージデータの可視化、、、
Amazon Sumerian 活用シーン
AR Navigation System NEC ソリューションイノベータ様
ハッカソンのイベントで発表され、日本からの唯一の受賞。
・バーチャル介護士
・VRでの株式情報などの提供
・仮想的なコクピット
Sumerianでよくでる用語
シーン
→XRのコンテンツ
エンティティ
→ シーンで使う3D,2Dオブジェ
アセット
→ かけなかった
Sumerianの基本構成
空のシーンの作成→エンティティの配置→公開
公開したら、クラウドにデータが飛んで、
Web上でJSから見ることができる。まじか。。。
仮想的なドローンをキーボードで操作する
キーマップをシーンにバインドして、操作を決めることができる。
複雑な場合は、JS。
デモを見てる
4つのキーを下降するアクションにバインド。
GUIで手軽にキーバインドできて、良いね。
xRでは、危険体験というサンプルがよくあるみたい。やってみたい。
(落下する体験)
チュートリアルにあるそう。
マネキンを落下させるためのチュートリアルを紹介。
やべえ、面白そう。
高さを増すと怖いだろうな。
VRゴーグルもプラットフォーム対応しているから手軽にできるんだよね。
デジタルツイン?(IoTの話かな?)
IoTでraspberryPiとSensaHatを使った。
1. LEDディスプレイ制御
→ SumerianからraspiberyPiに天気の情報を表示させている。(JS)
2.センサー情報の表示
→ sensaHatのセンサ情報をSumerianに表示。
3. 姿勢の追随
→ raspberryPiの姿勢をSumerianも同じ姿勢になる。
→ レイテンシがあるので、ちょっとズレがある。
→ Sumerianの視点を操作すれば、飛行機に乗っているかのようなこともできる。
4. ジョイスティックでのエンティティ操作
参考例
公式ドキュメント、learning amazon sumerian、youtube、twitch、slack。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6月27日 13:00-13:40 会場:D
クラウドネイティブなモダンアプリケーション開発入門
福井さん
AWS Code, AWS Cloud9, EKSが好き。
なぜモダンアプリケーション開発なのか
急速なイノベーションはもはや必須。
2017年は1430の当たらな機能、サービスをリリース。まじ多いよね。
・数千のチーム!?
モダンアプリケーション開発とは
モダン化のパスを決定
re host (lift-and-shift) data center -> ec2
Re-platform -> vms -> containers
Re-arhitecture -> monolith -> micro
Re-invent(clound-native)
ベストプラクティス
・ライフサイクルをセキュア
→ authenticate, authorize, audit govern, validate
↓
すべてのフェーズを自動化...。
・アプリケーションの構造をマイクロサービス化
→ Monolith -> micro
イベント駆動だね。非同期になるので、並列処理ができる。
トラッキングがしんどくなるけど。
自動化と抽象化
インフラのプロビジョニングや管理が不要なのは、infra as codeか。
オートスケールも大切。monolithだと無理だもん。
AWS Lambda
→ FaaS
・アプリケーションのモデリングとインフラにコードを利用する
→ infra as codeの考え。blue green deployment可能。
AWS Cloud Developement Kit (CDK)
各言語でインフラの構成を記述できる。json,yamlではなくなる。
宣言的じゃなくなるけど、、、わかりにくいのでは・・・?
・CI/CDを利用して迅速リリース
code commit, code build, codeDeploy
AWSに全乗っかりすれば楽になる。ベンダーロックインされまくりだけど。
・モニタリングの機能
monolithだと簡単だけど、microになるとつらい。
サービスメッシュがほしい。
↓
CloudWatch, AWS X-Rayで解決できるみたい。
モダンアプリケーションの実装パターン
・API GatewayPattern
クライアントとサービスの間にくるもの。
BFF的なもの?
Amazon Gateway
・サービスディカバリ/サービス レジストリパターン
k8sにもあるよね。ディカバリのサービスリソース。
Amazon CloudMap (DNSてきなもの)
・サーキットブレーカーパターン
プロキシみたいなもの。
→ 後ろのサービスが死んだら、サーキットブレーカが後ろのサービスを呼ばずに前に返す。
分散システムデザインパターンが良いかもね。
・コマンドクエリ責務分離パターン(CQRS)
書き込むクエリと参照するクエリをわけるやつだっけ。
・イベントソーシングパターン
データソースに対して直接更新するんではなくて、
間接的に更新する?ってこと?
・コレオグラフィパターン
オーケストレーションパターンは、指揮者が統括する。
コレオグラフィパターンは、自律的に動作する。
・集約ログパターン
1つにまとめる(そのまんまw)
・polyglotパーシステムスパターン
よーわからなかった。(異なるデータ処理のニーズに対しては異なるデータストレージテクノロジーを利用するというコンセプト。コピペ)
AWSにおける継続的ンテグレーションについて
・AWSのサービスに全乗っかりすれば、SPAのサービスをGitOps的にCI/CDを全部可能になる。素晴らしい。
・コンテナへのデプロイであればCodePipelineを使えば良い。これもGitOpis的に全自動。
・CodeDeployを使うと、ECRを通るとBlue/GreenDeploymentができる。
ミニマムプロダクトリリース
→ 最小限でリリースして、フィードバックをもらい、機能を増やす。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6月27日 14:00-14:40 会場:A
IoT Well Architected
Iotのベストプラクティスについて話すそう。
辻さん
大阪生まれ、独立系SIerのインフラエンジニア。
IoT SiteWise, IoT Events, IoT Analytics等々IoTのサービスがめっちゃおおい。
AWS Well-Architectued フレームワーク
クラウドのアプリケーション設計におけるベストプラクティス
・運用の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化の5つの柱。
3つのレンズ
・IoT
・HPC
・サーバーレスアプリケーション
5つの柱と3つのレンズの2方向で考える。今回はIoTのレンズのみ。
Well Architected Toolで危険度を図ることができる。
典型的なIoTシステム
デバイス→データの収集&加工&処理→保存→UIアプリケーション
データの収集から処理までをMonolithで作るんじゃなくて分けようね。
Iot設計指針
・収集と後続処理をキュー、バッファ、メッセージサービスなどで疎結合にする。
・オフライン時の動作も設計に組み込む。
→Google I/OやWWDCのときもオフラインが今後重要になるって話題になってたな。
・最小限のデータ量にする
→ そうりゃそうだよね。
・デバイスのステータスを定期的に送信
→ デバイスが死んでてたら送信されないね。デバイスからpushじゃなくて、他からpollingする感じかな。
運用の優勝性
・デバイスのプロビジョニング
→ デバイスのプロビジョニング...?秘密鍵や証明書を埋め込むそう・・・?
・デバイスの起動プロセス
→ 通信先のIPアドレスを固定にするんじゃなくて、DNSを引くようにホスト名を指定するとか。
・OTAを実装する
質問1
何に基づいて運用の優先事項を決めるか?
→ ビジネス成果 (ホワイトペーパーより)
例えば、クラウドを通信したときのレスポンスタイムとか。おそすぎるとだめだよね?ってことか?
質問7
どのようなデバイスへの影響を最小限に抑えながらIoTシステムを発展させるか?
→ ... (OTAから具体的なことがわからない...!)
OTAを実装する
セキュリティ
・デバイスの認証情報を安全に保存する
秘密鍵、証明書を使ってセキュアエレメントのようなチップ(MicroSDカード的なもの?)に保存する。
・デバイスの認証情報ライフサイクルを実装
秘密鍵の有効期限を設定することがある。
質問4
ユーザーがIoTアプリケーションへアクセスする際の認証許可をどのようにするか
→ ユーザやパスワード、ソーシャルIDプロバイダなどで認証
一人に1つの認証だけでなく、一人に複数の認証も考慮しないといけない。
質問8
デバイスのログ、メトリクス、設定をどのように監視するか?
→ クラウドに送るようにする。(当たり前よね)
信頼性
・本番規模のデバイス動作をシュミレートしてテスト
→ 非機能要件をちゃんと見ようねってことだね。
・メッセージ配信はストリームやキューでバッファする
・失敗や障害などを想定した、信頼性の高い設計にする
→ デバイス側に失敗、障害だけじゃなくて、通信先が死んだ場合も考えたほうが良いよね。
質問1. ピーク負荷に対する制限にどのように対応するか。
→ 自動的にスケールアウト可能な構成に。
→ 不要なピークをなくすこと。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6月27日 15:00-15:40 会場:C
クラウドネイティブがもたらすスケーラブルな開発、インフラストラクチャー、そし て組織
コンテナについてとクラウドネイティブについてのセッション。
好みの話。
Kimuraさん
SIer、国内クラウドベンダー。
開発言語は、Go,Java,Node.js
ぬーらぼでは、backlog,cacoo,typetalkの3つプロダクトをもっている。
backlogのユーザは順調に伸びている。100万人。
cacooのユーザ割合は、8割が海外。
(typetalkは?)
開発、インフラ、組織をスケールしたい。
↓
cloud native.
スケーラブルなアプリケーションを構築および実行するための技術の総称。
CloudNativeTrailMap
・コンテナリゼーション、CI/CD、オーケストレーション
github.com/cncf/trailmap
なんだか知っていることが多かった。ちょっと残念。
ぬーらぼのオフィスって、Tokyo,Kyoto,Fukuoka国内3つあるんだ。
kubernetesを導入することで、海外チームとの連携がしやすくなった。
(マイクロサービスになったから)
k8sを入れる大きなメリットは、スケールしやすくするため。
吉岩さんへバトンタッチ
backlogの導入事例について
Backlog
Issues,Wiki,Gantt
→ Monolithだと!?
Git
→ Goで再実装された(Perl,Python,Java) 3つ!?
インフラ部分について
クラスタは日本に6個、海外に2個。
インスタンスは200個もある。
Terraform+Ansibleでコード化。
→ 物理ホストのメンテで非常にコストがかかる。
→ Infra as Codeでなんとか解決しようとしている。
コードベースが巨大化になると開発者、特に新規の人が苦しくなる。
なぜK8sに?
いくつかのサービスがECSに乗っている
→ コンテナ運用のノウハウがある。これが強みだよね〜。。
Cacooは、K8sのControlPlaneの面倒を見るのが辛くなったので、
マネージドサービスであるEKSを使ってみた。
いきなり全部をEKSにするんじゃなくて、Nginxで既存サービスとEKSを並行提供。
新機能のドックフーディングが目的。大切だね。
Monolithな既存サービスを今後どうするか。。。
k8sのMasterNodeもWorkerNodeもTerraformで定義している。
k8sを導入することで、ローリングアップデートが効果的だった。
メンテナンスが楽になる。
ぬーらぼの話を聞いてよかったのは
「全部をいきなりEKSにするんじゃなくて、段階的にEKSへ寄せていく。その際にEKSのメリットをドックフーディングしていく」
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6月27日 16:00-16:40 会場:D
【マネーフォワード】800万+人/事業所の金融データを持つ20+サービスのクラウド大移行
中出さん CTO
マネーフォワードのご紹介
開発拠点って、あんまりないんだ。東京都と京都が半々(営業と開発)、ベトナムは全部開発。
それ以外の拠点は営業所。
4つの事業領域。
MoneyForwardBusiness. MoneyForwardHome, MoneyForwardX, MoneyForwardFinance
MoneyForwardHomeのMEでは、銀行と連携しているので、
すべての出金履歴を家計簿に自動登録される。
なんて神なんだ。。
システムの過去と現状
2012年にアカウントアグリゲーション基盤ができる。
MoneyForward ME
MoneyForward クラウド会計、クラウド確定申告、クラウド請求書、クラウド給与、クラウド経費、クラウド資金調達。
すべてがメインDB物理1つだそう。やばいでしょ!!
オンプレミスの課題
→ 開発スピードの低下、キャパシティの限界、全プロダクト障害の多発、開発余力の減少。。。
もうやばいのはわかる。やばいおぶやばい。
秘伝のタレ方式
→ ブラックボックス化されたインフラ。
→ 構成管理されているけど、継ぎ足し継ぎ足しのインフラ。
もうやだ...。
メリットよりもデメリットが大きすぎる。(全プロダクト障害の多発はやばすぎる)
なんとかしたいよね。
ただ、今を現状維持するだけで手一杯。伸びない。
7年間の負債を2018年新卒(小笠原さん)の人が解決し始めた。
目指すべき姿
組織がスケールしやすいインフラに。
1.インフラが運用するものの数を極力へらす
・マネージドサービスの活用
・Cattle not pets
ペットじゃないよ、使い捨てにしよう。
2.アプリケーションの実行環境を疎結合に
コンテナ化に。他へ影響することがなくなる。
3.アプリケーションチームへの権限委譲
→ 言語のバージョンアップ等をインフラに聞くと時間かかる。
→ Dockerfileにライブラリを含めてリポジトリに登録するように。
インフラとアプリの管理すべき権限を分割してる。
4.infra as code
秘伝のタレをなくす。
宣言的コードになるので、明確化。
AWSのEKSを選んだ理由は、マネージドサービスが豊富なのとRDB系のマネージドサービスが豊富だから。
それは、確かにAWSだね。
AWS移行へ
1. infra as code
terraformを選択。OSSで開発が盛んだし。
terraform Enterpriseを選択。
GitOps的にterraformを運用している。
2. AWS Direct Connect
メインDBを一気に移行するのは危険なので、
AWS Direct Connectすすることで、段階的に移行することができた。
3. スモールプロダクト
新規プロダクトはスモールプロダクトでリリースしてきた。
半年で3つは公開した。
新規プロダクトでプロトタイプを繰り返したから、知見が溜まったのか。
そこから、既存のプロダクトを移行することに。
4. 既存システムの移行
本番投入してみたが、レイテンシ悪化があり延期になった。
メインDBに紐付いているサービスを順次外していく。
紐づくサービスがすくなったらビッグバン移行しようと思う。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
6月27日 17:00-18:40 会場:B
AWS Night School
資料で後でもらえる。
AWSの基本コンプセト
おっと、動画は基調講演でみたやつか?
サービス追加、本当に多いよね。けど、追加すれば良いってわけじゃないと思うけど。
お客様の中で使うサービスは、EC2(7割)を使う割合が多い。RDS(2割)も含めると、9割もある。
従量課金制だから、監視はちゃんとしなよって話も。
リージョンとアベイラビリティゾーン
アベイラビリティゾーンは1個以上のデータセンタ郡のこと。
大阪はローカルリーションもあるみたい。
AWSのシステムは、冗長化した上で、SLAは99.99%となる。
東京リージョンのアベイラビリティゾーンだけを選ぶと、
東京のDCが全台落ちたらまずい。
なので、複数のリージョンを選ぶことが多い。
EC2とEBS
EC2の数は無制限に起動することができるが、
アカウント作成初期段階は、制限がかかっているそう。
無制限ってのは、恐ろしいな。
AMIは、AWSから用意されているものを使うが、
パッチを当てたような独自のAMIも作成することができる。
→ 共有先は全アカウントでも良いし、特定でも良い。
AMIからインスタンスを生成し、EBSのストレージを用意する。(なくても良い)
backupはS3におく。
インスタンスタイプ
c3.8xlarge
c: インスタンスファミリー
3: 世代
8xlarge: サイズ
世代は、新しいものほどコストパフォーマンスが良い。
インスタンスファミリー
汎用(M)
特殊汎用(T)
コンピューティング最適化(C)
メモリ最適化(R,X)
ストレージ最適化(H1)
ベアメタル(i)
ベアメタルは、仮想環境では動作できないようなものに使うみたい。
Amazon EBS
プロビジョニングIOPS SSD(io1)
プロビジョニングの大きさが大きいほど、速度があがるという。(?)
インスタンスメタデータは、/latest/meta-data/と書くと見えちゃうみたい。
恐ろしい。
EBS
永続的なストレージ。EBSにアタッチしないEC2も作れる。けど、EC2にデータが蓄積される。
EC2をシャットダウンすると消える。
EBSをいらないケースもある。計算のみでボリュームがいらない場合。
EBSのスナップショットは、全部データを持っているわけではない。
フルセットと差分セットで良い感じに最適化されている。
EBSの設計は分散設計。
CPUとメモリ、EBSストレージ、マネージドサービスの3つで分かれている。
なので、CPUとメモリが死んでもEBSストレージは死なない。
EC2を削除する際、EBSも削除するかどうか選択できるそう。
インスタンスタイプが変更する場合は、削除するのではなくて一時停止するみたい。
S3
オブジェクトのストレージ。学生の頃Dropbox使っていたときに、S3に移したな〜...。
S3はプログラムでごにょごにゅするものではない。
S3は、論理削除と物理削除どちらもできる。
S3はバージョン管理できたはず。
S3は無制限のオブジェクト保存。オブジェクトは5TB。
年間99.99999999999% (イレブン9)のオブジェクト耐久性。
→ バックアップ設計に関係する。
オブジェクトキーは、2016-03-01/index.htmlだったりする。GUIでは階層構造になってるけど。
セキュリティ設定は、高いレベルの設定が上書きされるそう。
S3のバージョニングって、デフフォルト無効なんだね。
S3から30日間使わなくなったら低頻度S3へ、さらに使わなくなったら、amazon glacierに移動される。
やすくするため。
VPC
publicクラウドだけでなく、private環境を提供する。
新規でAWSの環境を作ると、VPCがデフォルトで有効になっている。
EC2クラシックというものがある。
セキュリティ
アイデンティティ
アクセス管理
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------