Hatena::ブログ(Diary)

ablog このページをアンテナに追加 RSSフィード

2018-07-16

「コスパのいいシステムの作り方」の紹介

三菱UFJインフォメーションテクノロジーの南さんから献本いただきました。南さんとは一緒に仕事をさせていただいたこともありますが、難易度の高いミッションクリティカルプロジェクトを成功させられていて、こういうベンダーに騙されない目利きができる優秀なPMはユーザー企業の宝だと思っていました。

南さんのようなユーザー企業でリスペクトしている方々に共通しているのは会社のお財布は自分のお財布という感覚を持ち、各分野のスペシャリストと個人的なコネクションを持たれ、ドライな技術からウエットな組織まで筋の通った骨太な考え方を持たれて、馬力があって肝が座られてるところです。ちょっとマネできないなと感じます。

こういうスキルはなかなか人に伝えることは難しいと思いますが、本書はそれを可能な限り搾り出した一冊だと思います。自分がユーザー企業に転職することがあれば、本書を参考にさせていただきたいと思います。

著者が経験を通じて得た経験と勘(暗黙知)を脳内バッファから書出したような一冊です。

システムの「コストパフォーマンス(費用対効果)」に限らずインフラの要素技術、勉強の仕方、後輩の育て方、組織についてなど経験から得られた暗黙知が簡潔に書かれています。

日本のIT業界は内製せずにSIerに委託しているユーザー企業が多いですが、その場合、プロジェクトの成否は製品やソリューションの選定、ベンダーコントロールなどユーザー企業のプロジェクト担当の目利きや腕にかかっていると感じます。

よく、この人はこの会社にいてもらわないとと思うことがあります。

本書はユーザー企業のインフラエンジニアはもちろん、そこに提案に行くベンダーも役に立つと思います。以下、構成と目次です。


概要

「うちって,システムにお金をかけすぎじゃない?」

そんな問いに的確な判断を下すにはどうすればいいか。

「勘に頼らない技術を求めても,結局は勘に頼る部分が少なからずある」

「過去の事例と比較しても,元のコストがまちがっていれば誤りの連続になるし,すぐに陳腐化する」

そんなジレンマに悩む方のために,大規模システムを多数経験してきた著者が,最小限のコストで最大の効果を得る「勘と経験」の本質を教えます。

コスパのいいシステムの作り方 ?しっかり見積もりたいのに勘を使うジレンマに向き合う:書籍案内|技術評論社

構成

本書では,テーマごとに私の経験と勘を明らかにしていこうと思いますが,以下のスキルが重要になります。

これらのスキルを,本書では3部構成でまとめています。まず第1章から第8章までは,システムを構築するうえでの前提知識をまとめました。システム構築は単に技術力があればできるものではありません。幅広い知識と経験が必要で,その要素をまとめています。続いて第9章から第12章まではインフラのテクニカル要素をレイヤーごとに記載しています。何か1つの製品については触れず,どのような製品を使っても役に立つ考え方を記載しています。最後に第13章は,それ以前の章の総まとめです。実際のシステムのパターンごとに,第12章までの知識を集約して考え方を整理しています。

これらのスキルは私のこれまでの経験によるものですが,どのように考えてきたかをお伝えすることで,みなさんの経験と勘にプラスできることを願っています。


目次

出版社の紹介は コスパのいいシステムの作り方 ?しっかり見積もりたいのに勘を使うジレンマに向き合う:書籍案内|技術評論社 をご覧ください。

第1章 どうやって予算を確保するか
文化の違いで変わる見積りへの影響
プロジェクトごとの予算確保から案件化まで
予算が決まった後にすべきこと

第2章 製品を安く買うための工夫
「製品は安く、工数はほどほどに」がコツ
製品の強み、弱みを正確に把握する
ダブルスタンダードで価格をコントロールする
購入時に確認すべき3つのこと

第3章 開発費を削減するための工夫
インフラのコストを下げる基本原則
内製化を検討する
契約で考えるべき4つのポイント

第4章 可用性、性能、運用性を考慮する
システムのコストとSLA
可用性について考察する
性能について考察する
運用性について考察する
後から変わるSLAで不幸にならないためにすべきこと
後々SLAでもめないためのインフラのポイント

第5章 OSSかプロプライエタリか
バグの対処の方法によってコストは大きく変わる
OSSの強みとは
OSSの向き不向きを考える

第6章 標準化でコストダウンは図れるのか
標準化の功罪とは
コスト効率と安全性を追求する標準化の進め方

第7章 運用・保守の効率化を考える
増えていくシステム、減らしにくいランニングコスト
保守作業を合理化するための考え方
運用フェーズのコスト削減のポイント
開発・運用の分離とDevOps

第8章 教育コストと体制維持コストの負担
エンジニアが成長するための4つの基本
技術スキルの伸ばし方
教育のためのコストを捻出する

第9章 サーバー(IaaS)のコストを考える
「速いか遅いか」「壊れにくいか壊れやすいか」の2軸でコストを考える
CPUの費用対効果
メモリの強みを理解する
ディスクの故障とシステム停止を想定する
ラックマウントサーバーか、ブレードサーバーか

第10章 仮想化でリソースを効率的に扱う
見積もりとコントロールがうまくできないから仮想化が必要になる
リソースをリニアに追加・削除するときの注意点
集約率を高め、効果的に仮想化するには

第11章 ストレージを効率的に使い切る
ブロックストレージの投資対コスト
思ったよりも使えないディスク容量
ディスクの特性と価格変動を考える
ブロックストレージ以外のストレージを使いこなす

第12章 ミドルウェアがコストに与える影響を理解する
ライセンスコストが問題になりにくいAPサーバー
高額でプロプライエタリなRDBMS製品を使う理由
RDBMSで無駄なリソースを使う問題をどう解決するか
NoSQLの活用でコストは減らせるか
アプライアンス製品か、汎用品か

第13章 システムタイプごとの高コスト、低コスト
シンプルなAP、DBの構成
同時実行ユーザーが多いシステム
ミッションクリティカル系
スパコン・HPCの場合

2017-12-10

MySQL Connector/J(JDBC Driver) で接続時に任意の collation_connection をセットする

MySQL Connector/J(JDBC Driver) で接続時に任意の collation_connection をセットする には以下の用に JDBC URL に「connectionCollation=utf8mb4_bin」のように設定すれば良い。

jdbc:mysql://aurora01.cluster-*******.ap-northeast-1.rds.amazonaws.com:3306/mydb?connectionCollation=utf8mb4_bin

参考

MySQL クライアントプログラム mysql、mysqladmin、mysqlcheck、mysqlimport、および mysqlshow は、次のように、使用するデフォルトの文字セットを特定します。

C アプリケーションは、サーバーに接続する前に次のように mysql_options() を呼び出すことによって、OS 設定に基づいて文字セットの自動検出を使用できます。

mysql_options(mysql,
              MYSQL_SET_CHARSET_NAME,
              MYSQL_AUTODETECT_CHARSET_NAME);
no title

Use characterEncoding=utf8mb4& for jdbc url

jdbc:mysql://x.x.x.x:3306/db?useUnicode=true&characterEncoding=utf8mb4
java - utf8mb4 in MySQL Workbench and JDBC - Stack Overflow

connectionCollation

If set, tells the server to use this collation via 'set collation_connection'

Since version: 3.0.13

no title

2017-12-07

Aurora MySQL互換に LOAD コマンドで CSV ファイルをロードしようとすると "ERROR 1148 (42000)" で失敗する

Aurora MySQL互換というより MySQL の話です。


事象

  • mysql クライアントで接続して、LOAD DATA ステートメントで CSV ファイルをロードしようとすると、"ERROR 1148 (42000): The used command is not allowed with this MySQL version" と怒られる。
% mysql  --local-infile -h aurora01.cluster-******.ap-northeast-1.rds.amazonaws.com -u awsuser -p
mysql> LOAD DATA LOCAL INFILE '.test.csv' INTO TABLE TEST FIELDS TERMINATED BY ',' ENCLOSED BY '"';
ERROR 1148 (42000): The used command is not allowed with this MySQL version

原因

  • セキュリティ上の理由でデフォルトで LOAD DATA ステートメントが無効なため。

解決

% mysql  --local-infile -h aurora01.cluster-******.ap-northeast-1.rds.amazonaws.com -u awsuser -p
mysql LOAD DATA LOCAL INFILE 'test.csv' INTO TABLE TEST FIELDS TERMINATED BY ',' ENCLOSED BY '"';

参考

LOAD DATA ステートメントの LOCAL バージョンのサポートに関しては、セキュリティーについての潜在的な問題が 2 つあります。

no title

You can specify that as an additional option when setting up your client connection:

mysql -u myuser -p --local-infile somedatabase

This is because that feature opens a security hole. So you have to enable it manually in case you really want to use it.

sql - ERROR 1148: The used command is not allowed with this MySQL version - Stack Overflow

mysql コマンド行クライアントの場合、--local-infile[=1] オプションを指定することによって LOAD DATA LOCAL を有効にするか、--local-infile=0 オプションを指定することによってこれを無効にします。mysqlimport の場合、ローカルデータファイルのロードはデフォルトでオフになっており、--local または -L オプションを使用してこれを有効にします。いずれの場合でも、ローカルロード操作を正常に使用するには、サーバーがこの操作を許可していることが必要。

no title

2017-09-15

MySQL で NOT NULL 制約のある列に複数行インサートするとその型のデフォルト値が入る

MySQLSQL モードが STRICT モードでない場合、NOT NULL 制約のある列に複数行インサートするとその型のデフォルト値(0とか空文字)が入る(1行インサートだとエラーで入らない)。


検証結果

  • Amazon Aurora with MySQL Compatibility に接続する
$ mysql -h ******.******.ap-northeast-1.rds.amazonaws.com -u awsuser -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 53
Server version: 5.6.10 MySQL Community Server (GPL)

Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
  • データベースを選択する
mysql> use mydb;
Database changed
  • テーブルを作成する
mysql> create table `not_null_test` (
    ->   `id` int(10) unsigned not null,
    ->   `int_col` int(10) unsigned not null,
    ->   `char_col` char(10)  not null,
    ->   `ts_col` timestamp not null,
    ->   primary key (`id`)
    -> ) engine=innodb default charset=utf8;
Query OK, 0 rows affected (0.05 sec)
  • SQL モードは設定されていない
mysql> select @@global.sql_mode;
+-------------------+
| @@global.sql_mode |
+-------------------+
|                   |
+-------------------+
1 row in set (0.02 sec)
  • 1行インサートはエラーになる
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be null
  • 複数行インサートは成功する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null), (2, null, null, null);
Query OK, 2 rows affected, 4 warnings (0.02 sec)
Records: 2  Duplicates: 0  Warnings: 4
  • テーブルのデータを確認する
mysql> select * from not_null_test;
+----+---------+----------+---------------------+
| id | int_col | char_col | ts_col              |
+----+---------+----------+---------------------+
|  1 |       0 |          | 2017-09-15 06:54:07 |
|  2 |       0 |          | 2017-09-15 06:54:07 |
+----+---------+----------+---------------------+
2 rows in set (0.02 sec)
  • SQLモードを STRICT_ALL_TABLES にする
mysql> set sql_mode='strict_all_tables';
Query OK, 0 rows affected (0.03 sec)
  • 1行インサートは失敗する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be null
  • 複数行インサートも失敗する
mysql> insert into not_null_test (id, int_col, char_col, ts_col) values (1, null, null, null), (2, null, null, null);
ERROR 1048 (23000): Column 'int_col' cannot be nul

参考

単列インサートの場合はNOT NULLが指定されたカラムにNULL値が挿入されるとそのクエリはエラーとなって失敗するが、複数列インサートの場合は警告(warning)を発するものの、クエリは正常に受け付けられる。

その際、NULL値が指定された各カラムにはそれぞれのカラムのデータ型の暗黙的なデフォルト値が挿入される。(数値型なら0、文字列型なら空文字''、etc…)

MySQLにおけるNOT NULLカラムへのインサート時の挙動 - Sojiro’s Blog

NOT NULL として宣言されているカラムへの NULL の挿入。複数行の INSERT ステートメントまたは INSERT INTO ... SELECT ステートメントの場合、このカラムは、そのカラムデータ型の暗黙のデフォルト値に設定されます。これは、数値型では 0、文字列型では空の文字列 ('')、および日付と時間型では「0」の値です。サーバーは SELECT からの結果セットを検査して、それが単一行を返すかどうかを確認しないため、INSERT INTO ... SELECT ステートメントは複数行の挿入と同じ方法で処理されます。(単一行の INSERT の場合は、NULL が NOT NULL カラムに挿入されても警告は発生しません。代わりに、このステートメントがエラーで失敗します。)

no title

明示的な DEFAULT 句のない NOT NULL カラムに対するデータエントリでは、INSERT または REPLACE ステートメントにカラムの値を含まれていない場合、または UPDATE ステートメントがカラムを NULL に設定する場合、MySQL はその時点で有効な SQL モードに従ってカラムを処理します。

  • 厳密な SQL モードを有効にした場合、トランザクションテーブルに対してエラーが発生し、ステートメントがロールバックされます。非トランザクションテーブルではエラーが起きるが、これが複数行ステートメントの 2 行目以降の行に対するエラーの場合、先行する行が挿入されています。
  • 厳密モードが有効でない場合、MySQL はカラムデータ型の暗黙的なデフォルト値にカラムを設定します。

(中略)

セクション5.1.7「サーバー SQL モード」を参照してください。

所定のテーブルに対して、SHOW CREATE TABLE ステートメントを使用すると、どのカラムに明示的な DEFAULT 句があるかを確認できます。

暗黙的なデフォルトは次のように定義されます。

  • 数値型のデフォルトは 0 です。ただし、例外として AUTO_INCREMENT 属性で宣言された整数型または浮動小数点型のデフォルトは、そのシーケンスの次の値になります。
  • TIMESTAMP 以外の日付と時間型のデフォルトには、「ゼロ」値が適切です。explicit_defaults_for_timestamp システム変数が有効な場合、これは TIMESTAMP にも当てはまります (セクション5.1.4「サーバーシステム変数」を参照してください)。それ以外の場合、テーブルの最初の TIMESTAMP カラムのデフォルト値は現在の日付と時間になります。セクション11.3「日付と時間型」を参照してください。
  • ENUM ではない文字列型のデフォルト値は空の文字列です。ENUM のデフォルトは、最初の列挙値です。
no title

厳密モードは、MySQL が INSERT や UPDATE などのデータ変更ステートメントで無効な値または欠落した値を処理する方法を制御します。値はいくつかの理由で無効になることがあります。たとえば、カラムに対して正しくないデータ型を持っていたり、範囲外であったりすることがあります。値の欠落が発生するのは、挿入される新しい行の非 NULL カラムに値が含まれておらず、そのカラムに明示的な DEFAULT 句が定義されていない場合です。(NULL カラムの場合、値が欠落しているときは NULL が挿入されます。)

厳密モードが有効でない場合、MySQL は無効または欠落した値に対して調整された値を挿入し、警告を生成します (セクション13.7.5.41「SHOW WARNINGS 構文」を参照してください)。厳密モードでは、INSERT IGNORE または UPDATE IGNORE を使用すると、この動作を実行できます。

データを変更しない SELECT などのステートメントの場合、厳密モードでは無効な値はエラーでなく警告を生成します。

厳密モードは、外部キー制約が検査されるかどうかに影響されません。foreign_key_checks を検査に使用できます。(セクション5.1.4「サーバーシステム変数」を参照してください。)

no title

2017-05-06

AWS の VPC(Virtual Private Network) についてメモ

※以下は個人的なメモです。最新の正確な情報はAWSの公式ドキュメントを参照してください。

VPC とは

Virtual Private Cloud (VPC) は、AWS アカウント専用の仮想ネットワーク。以下のコンポンーネントがある。


  • VPCに使うアドレスレンジ
    • VPCに設定するアドレスは既に使っている、もしくは使うであろうネットワークアドレスを避けるのがポイント
    • 推奨: 172.31.0.0/16 RFC1918レンジ、/16 (65,534アドレス)
    • 作成後変更はできないので注意が必要
    • VPCあたりのサブネット作成上限数はデフォルト200個
  • CIDRに/16 を設定した場合の各サブネット数と使えるIPアドレス数
サブネット
  • サブネットで利用できないIPアドレス
ホストアドレス用途
.0ネットワークアドレス
.1VPCルータ
.2Amazonが提供するDNSサービス
.3AWSで予約
.255ブロードキャストアドレス (VPCではブロードキャストはサポー トされていない)
アベイラビリティゾーン(AZ)
  • AZは1つ以上のデータセンターで構成される
  • 1リージョン内にAZが複数存在
  • AZはお互いに地理的・電源的・ネットワーク的に分離
  • 2つのAZを利用した冗長構成を容易に構築
  • リージョン内のAZ間は高速専用線で接続(リージョン間はインターネット経由)

ネットワークACL と セキュリティグループ
ネットワークACLセキュリティグループ
サブネットレベルで効果サーバレベルで効果
Allow/DenyをIN・OUTで指定可能 (ブラックリスト型)AllowのみをIN・OUTで指定可能 (ホワイトリスト型)
ステートレスなので、戻りのトラフィックも明示的に許可設定するステートフルなので、戻りのトラフィックを考慮しなくてよい
番号の順序通りに適用全てのルールを適用
サブネット内のすべてのインスタンスがACLの管理下に入るインスタンス管理者がセキュリティグループを適用すればその管理下になる

AWSクラウドとVPC
  • VPC内と外のどちらにリソースや エンドポイントが存在するかサービスによって異なる
  • VPCからAWSクラウドへのリソースはIGW経由の通信となる
    • プライベートサブネットからは→NATゲートウェイ
    • S3であればVPCエンドポイントの利用も可能
    • パブリックサブネットからは→自動割当てまたはEIPのパブリックIPから直接アクセス
  • S3へのアクセスはVPCエンドポイント利用 可能

VPCエンドポイント for S3
  • VPCエンドポイントをVPCに作成し、プライベートサブネットからAWSクラウド上のS3バケットにアクセス可能
  • VPCエンドポイントを作成すると、ルートテーブルの宛先にS3のプレフィックス、ターゲットにVPCエンドポイントが自動で設定されS3への通信がVPCエンドポイント経由となる
  • VPCエンドポイントポリシーでアクセス制御が可能
  • 追加費用なし(トラフィック課金もなし)

VPC Peering (VPCピア接続)
  • 2つのVPC間でトラフィックのルーティングが可能
  • 同一のAWSアカウントはもちろん、異なるAWSアカウント間(クロス アカウント)のVPC間をピア接続することも可能
  • 単一障害点や帯域幅のボトルネックは存在しない
  • 以下の点に注意
    • MTU (VPC Peering 1,500byte)
    • 直接PeeringしているVPCとのみ
    • 通信可能(2HOPは不可)
    • リージョンは跨げない

Amazon DNS サーバー
  • Amazonが提供するDNSサービス
  • 以下の2つのアドレスが利用可能
    • VPCのネットワーク範囲(CIDR)のアドレスに+2したIP(10.0.0.0/16の場合は10.0.0.2)
    • 169.254.169.253
  • VPC内のEC2インスタンスからのみ参照可能 (VPNや専用線経由では参照できない)
  • Enable DNS resolution
    • 基本はyesとする
    • NoにするとVPCのDNS機能が無効となる
  • Enable DNS hostname
    • TrueにするとDNS名が割り当てられる
    • “Enable DNS resolution”をtrueにしないと有効にならない

VPN接続構成
  • 1つのVPN接続は2つのIPsec トンネルで冗長化
  • ルーティングは以下が選択可能
    • 静的(スタティック)
    • 動的(ダイナミック:BGP)
  • カスタマゲートウェイの要件
機能RFC
Pre-shared キーを使用して、IKE セキュリティ接続を 確立するRFC2409
トンネルを論理インターフェイスに結合する (経路ベースのVPN)-
トンネルモードで、IPsec セキュリティ接続を確立するRFC4301
暗号化前に IP パケットをフラグメント化するRFC4459
AES 128 ビット暗号化または AES 256 ビットの暗号 化機能を使用するRFC3602
(オプション)BGP ピアを確立するRFC4271
SHA-1 または SHA-256 のハッシュ機能を使用するRFC2404
VPN トンネルに入る TCP パケットの最大セグメントサ イズを調整するRFC4459
Diffie-Hellman Perfect Forward Secrecy を使用しま す。以下のグループがサポートされます。
フェーズ 1 グループ: 2,14~18,22,23,24
フェーズ 2 グループ: 1,2,5,14~18,22,23,24
RFC2409
パケットの "フラグメント化しない" フラグをリセット するRFC791
IPsec Dead Peer Detection の利用RFC3706

専用線(Direct Connect)接続構成
  • AWSとお客様設備を専用線で ネットワーク接続
  • 相互接続ポイントへ専用線を敷設 し、AWSのルータと相互接続
  • 日本の相互接続ポイントは以下の2つ
    • 東京(Equinix TY2)
    • 大阪(Equinix OS1)
  • ルーティングはBGPのみ
  • 接続先は以下の2つ
    • VPC(プライベート接続)
    • AWSクラウド(パブリック接続)
  • VPNよりも一貫性がある
  • 帯域のパフォーマンスも向上
  • ネットワークコストも削減

VPCからオンプレミスへのルート設定
  • VPCからオンプレミスへの通信をするためには各サブネットのルートテーブルの設定が必要
    • 宛先: オンプレミスのIP
    • ターゲット:VGWのID
  • ルートテーブルで”ルート伝達 (プロパゲート)”を有効にするとVGWで受信したルート情報をルートテーブルに自動的に伝達(頻繁にオンプレのルートが更新 される場合はこちらを利用)

インターネットVPN vs 専用線
インターネットVPN専用線
コスト安価なベストエフォート回線も利用可能キャリアの専用線サービスの契約が必要
リードタイム即時~数週間~
帯域暗号化のオーバーヘッドにより制限あり~10Gbps
品質インターネットベースのため経路上のネットワーク状態の影響を受けるキャリアにより高い品質が保証されている
障害時の切り分けインターネットベースのため自社で保持している範囲以外での切り分けが難しいエンドツーエンドでどの経路を利用しているか把握できているため比較的容易

VPC Flow Logs
  • ネットワークトラフィックをキャプチャ し、CloudWatch LogsへPublishする機能
  • ネットワークインタフェースを送信元/ 送信先とするトラフィックが対象
  • セキュリティグループとネットワークACL のルールでaccepted/rejectされた トラフィックログを取得
  • キャプチャウインドウと言われる時間枠 (約10分間)で収集、プロセッシング、 保存
  • RDS, Redshift、ElasticCache WorkSpacesのネットワークインタフェーストラフィックも取得可能
  • 追加料金はなし(CloudWatch Logsの標準料金は課金)
  • Flow Log レコードの項目
フィールド説明
versionVPC flow logsのバージョン
account-idflow logを取得したAWSアカウント
interface-idログストリームが適用されているネットワークインタフェースのID
srcaddr送信元アドレス(※)
dsraddr送信先アドレス(※)
srcport送信元ポート
dsrport送信先ポート
protocolIANAで定義されたプロトコル番号
packetsキャプチャウインドウの中で取得したパケット数
bytesキャプチャウインドウの中で取得したバイト数
startキャプチャウインドウ開始時のUNIX時間
endキャプチャウインドウ終了時のUNIX時間
actionトラフィックのアクション(ACCEPT/REJECT)
log-statusログステータス(OK/NODATA/SKIPDATA)

IPv6対応
  • S3、CloudFront、WAF、Route53、VPC、ALBがIPv6対応

VPCにおけるIPv4とIPv6の特徴と制限
IPv4IPv6
アドレス体系32bit128bit
VPCでの利用デフォルトで適用オプトイン(自動適用ではなく任意)
CIDRブロックサイズ16~28bitで選択 自分で任意のアドレスを設定可能56bit固定 かつ自動で56bit CIDRが アサインされる(選べない)
サブネットブロックサイズ16~28bitで選択64bit固定
パブリックIP/ プライベートIPそれぞれ存在 (NATを介してパブリックIPをプライマリプライベートIPにMAP) パブリックのみ (プライベートにするにはEgress-only Internet Gatewayを利用)
インスタンスタイプ全てのインスタンスタイプM3、G2を除く全ての現行世代の インスタンスタイプでサポート
アマゾン提供DNSプライベートIP、Elastic IPに対する それぞれのDNSホスト名を受信提供されるDNSホスト名はなし
閉域接続VPN、DirectConnectDirectConnectのみ

代表的なVPCのリミット
リソース
リージョン当たりの VPC の数5
VPC 当たりのサブネットの数200
AWS アカウント当たり、1 リージョン内の Elastic IP 数5
ルートテーブル当たりのルートの数100
VPCあたりのセキュリティグループの数500
セキュリティグループあたりのルール数(In/Out)50
ネットワークインタフェースあたりのセキュリティグループ5
VPC当たりのアクティブなVPCピア接続125
VPCあたり(仮想プライベートゲートウェイ)のVPN接続数10

VPCの作成方法

用語


参考