AWSのルートテーブル
今回AWSのルートテーブルで不思議な構成があったので、メモ
下記のように入力がグローバルIPであった場合に別経路へルーティングする設定がありました。
※TGWは設定していないので存在しないですが例として。
これって以下だと考えています。
- 123.123.123.123で通信がきた場合、折り返しのパケットをTGWに流す
- 逆にVPCから123.123.123.123に通信したら、パケットをTGWに流す
なぜ？どうしてという疑問が湧いていますが、障害要因になっていたので、設定を削除して障害復旧となりました。
AWSをルータとして使っていたのかな？
ただ、疑問はTGW側（他ネットワーク側）このパケット受け取れるのだろうか。
ちょっともやっとしましたが障害は解決したので、よかった。
AWS Certified Solutions Architect - Professional その2
今回はエンドポイントについて。
２種類のエンドポイントの違いなどがはっきりとわかるようにならないと
サービス設計や利用で提供でつまづきそうなので、まとめみました。
ゲートウェイVPCエンドポイント
- S3とDynamo DBで使える。
- 料金が発生しない。
- ルートテーブルの設定が必要
- PryoxyサーバのようなEC2が必要（オンプレなどから直接アクセスできない）
- 高可用性は設計側で検討する必要がある。
インターフェイス VPC エンドポイント (AWS PrivateLink)
- 様々なAWSサービスで使える。
- 料金が発生する。
- AZは設定時に追加できるので高可用性は担保してもらえる。
- サブネットにENIが配置される。
- Proxy不要
- Lambda+VPCを使う場合はインタフェイスエンドポイントがあるとセキュアにサービスが使える
まだまだ書くべきことはあるが、掻い摘んで理解した内容です。
特に最後のPrivate LinkでLambdaを使うケースは実践でやって、重要性と必要性は理解できました。
また、お金は大事です。
まとめ
さらっと始めたが、傾向とし、Professionalレベルになると、単独アカウントや単独のサービスの提供で行うことより組織としてAWSサービスを提供・利用するための管理について重点が置かれているように感じる。
Professionalなので当然といえば当然かなぁとは思いますが。
サービス間連携が理解できないと設計も難しいですしね。
下記に公式のURLを貼り付けておきます。
AWS Certified Solutions Architect - Professional その1
今回は勉強のためにAssumeRoleを試してみました。
『AWSアカウント（A）からのアカウント（B）に対して操作』を許可するケースを簡単にまとめてみました。
B側操作
・ロール作成で、AWSアカウントを選択し、許可したいAWSアカウントID（A)を指定する。
・アカウントIDを指定したら、許可したい操作をポリシー単位で選択する。
A側操作（今回はコンソール）
・下記のコマンドを実行する
aws sts assume-role \ --role-arn "arn:aws:iam::<B側のアカウントID>:role/<ロール名>" --role-session-name <sessionName>
こうすると、AccessKeyId、SecretAccessKey、SessionTokenが取得できるのでexportする。
export AWS_ACCESS_KEY_ID = <assume-roleで取得したAccessKeyId> export AWS_SECRET_ACCESS_KEY = <assume-roleで取得したSecretAccessKey> export AWS_SESSION_TOKEN = <assume-roleで取得したSessionToken>
これでB側のアカウントの操作が可能になる。
まとめ
最小特権の原則（PoLP）に沿わないと簡単に他アカウントのAWSリソースをぶち壊す可能性を秘めている。
