aws コマンドで UnicodeDecodeError: ‘ascii’ codec can’t decode エラーが出る

aws コマンドで UnicodeDecodeError: ‘ascii’ codec can’t decode

というエラーが出るようになったので、そのときの対応と少しハマったこと。

 

流れ

  1. aws コマンドで該当のエラーが出る
  2. python のバージョンをあげるために brew pyenv をインストールしようとするが入らない
  3. pyenv python のバージョンをあげる
  4. python のバージョンをあげたが、PATH が通ってない
  5. 無事に aws コマンドでエラーがなく実行できる

aws コマンドで該当のエラーが出る

どうやら、python のバージョンを 3 系にあげるとなおるらしいです。

python のバージョンをあげるために brew pyenv をインストールしようとするが入らない

brew でインストールしようとしたのですが、

`require’: cannot load such file

のエラーが出ます。

いろいろ調べて対象法を試して見ましたが、ダメだったので、

Homebrew をアンインストールして、再度 Homebrew をインストールしたらいけました。

pyenv python のバージョンをあげる

pyenv install 3.6.4

とコマンドを打つことでバージョンを設定できます。

python のバージョンをあげたが、PATH が通ってない

aws コマンドを実行してみましたが、

実行時にまだ python 2 系を参照しているようでした。

export PATH=~/.local/bin:$PATH

とすることで、PATH が通ります。

.bash_profile 等に記載しておけばいいと思います。

無事に aws コマンドでエラーがなく実行できる

めでたく、 phtyon 3 系でコマンドが実行されており、

エラーもなくなりました。

difficult points that make static website, using Route53, CloudFront, ACM and S3 via https

i think, there are some difficult points make https static website using Route53, CloudFront, ACM and S3.

so i searched and writing knowlege in this blog.

Route53

can’t select CloudFront distributions at CNAME Alias, after setting CloudFront.

please set Alias ” No “, and set CloudFront Domain Name in Value.


ACM

please set region US East (N. Virginia) when you get certificate.

if you other region you set, you can’t  select certificate in CloudFront AWS conslole.


CloudFront

can’t set certificate, after you get certificate at US East (N. Virginia) region.

answer 1:

please wait few days.

if you get certificate at Certification Manager, you can’t select in CloudFront immediately.

i waited few days and i could selected it.

 

ansewer 2:

you upload certificate by aws acli.

maybe you can select certificate at CloudFront AWS console immediately.

but i don’t try this method.

https://aws.amazon.com/premiumsupport/knowledge-center/custom-ssl-certificate-cloudfront/

displayed file list of XML, via CloudFront

please set ” Default Root Object ” at CloudFront AWS console.

example, ” index.html “.

Access Deny occur, when you access your domain.

please set ” Alternate Domain Names (CNAMEs) ” your domain at CloudFront AWS console.

Access Deny occur via CloudFront

please public access setting, at S3 object and bucket at S3 BucketPolicy.

i setting every thing, but i can’t access.

there is possibility used cache at CloudFront.

so remove cache at Invalidation tab of CloudFront console. and input ” /* “.


S3

you can access “static website hosting” url. but can’t via CloudFront.

there is possibility, you did’t setting public access policy at S3 object and S3 bucket.

so you setting public access setting at it.

if you have too many object.

using aws cli command is very useful.

aws s3 sync . s3://my-bucket/path –acl public-read

error occur when public access setting at S3 bucket.

please select ” false ” at Piblic access settings of Permissions.

this function is add AWS console, at November 18th, 2018.

Route53 + CloudFront + ACM + S3 で https する際にハマったこと

ネットの記事をみながら構成していくなかで、ハマったこと

Route53

CloudFront の設定が終わって、Route53 で、登録したドメインの CNAME に、CloudFront のドメイン名を登録するときAlias を選択しても、Target の候補に CroudFront が出てこない。

Alias No を選択して、Value CloudFront のドメイン名を入力しよう。


ACM

証明書をとるときは、リージョンを「バージニア北部」にしよう。

そうしないと、CloudFront の画面で取得した証明書を選択できない。


CloudFront

バージニア北部」で証明書を取得しても CloudFront の画面で設定できない。

解決方法1:

待つ。

ACM で証明書を取得しても、すぐには CloudFront の画面で選択ができない。

私は 1,2 日待ったら選択できるようになりました。

 

解決方法2:

手動でアップロードする。

私は試してないですが、手動でアップロードすることですぐに反映されるみたいです。

Amazon CloudFrontの独自ドメインSSL証明書をAWS CLIでアップロードする

CloudFront 経由で S3 にアクセスしたら、ファイル一覧の XML が表示される。

解決方法:

CloudFront の設定画面で、「Default Root Object」を設定しましょう。

例えば、index.html など。

取得したドメインで、CloudFront 経由でアクセスすると AccessDeny になる。

CloudFront Alternate Domain Names (CNAMEs)」に、

アクセスしたいドメインの値を設定しましょう。

CloudFront 経由で AccessDeny になる。

S3 バケットポリシーで、オブジェクトとバケット全体を、パブリック公開設定にしましょう。

もろもろ設定したけど、やっぱりダメだ。

CloudFront でキャッシュが残っている可能性があります。

CloudFront Invalidations “/*” を設定して、全てのキャッシュを削除してみましょう。


S3

static website hosting url にはアクセスできるが、CloudFront 経由でアクセスできない。

バケットと、オブジェクトがパブリック公開になっていない可能性があります。

バケットポリシーを公開設定にして、各オブジェクトを公開設定にしましょう。

オブジェクトが大量にある場合は、 aws cli を用いてコマンドでサイドアップロードするのが手っ取り早いです。

aws s3 sync . s3://my-bucket/path  –acl public-read

バケットポリシーを公開設定にしようとするが、エラーになる。

「アクセス権限」の「パブリックアクセス設定」を全て false にしましょう。

この機能は、201811/18から AWS に追加されました。

[AWS] IAMユーザで請求情報を確認する

AWSの請求画面を表示するには、デフォルトの設定だと

root でログインしなければ見ることができません。

今回は IAM ユーザでログインして請求画面を表示させる方法を書きます。

公式ドキュメント

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/grantaccess.html

 

IAM ユーザで請求画面を表示させるには、次の 2 つの設定が必要になります。

  • root でログインし、請求画面を IAM ユーザにも表示させるように設定
  • IAM ユーザに、請求画面を表示させるポリシーをアタッチ

 

root でログインし、請求画面を IAM ユーザにも表示させる設定

root でログインし、右上のバーからアカウントを開きます。

画面をスクロールし、「IAM ユーザ/ロールによる請求情報へのアクセス」を開き

「IAM アクセスのアクティブ化」にチェックを入れ「更新」します。

IAM ユーザに、請求画面を表示させるポリシーをアタッチ

請求画面を表示させたい IAM を選択し、

「Billing」のポリシーをアタッチします。

これで請求情報の全て(請求書 や 予算 など)が表示できるようになります。

個別に許可したい場合は、下記のドキュメントを参考に個別にポリシーを付与しましょう。

https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/billing-permissions-ref.html

IAM ユーザでログインしなおし、請求画面を開くと問題なく表示ができました。

 

「AKIBA.AWS #6 ネットワーク x 基礎編 – VPNとDirectConnect -」に行ってきました

AKIBA.AWS #6 ネットワーク x 基礎編 – VPNDirectConnect –

https://classmethod.connpass.com/event/84401/

に行ってきたので、そのときのレポート

1. 日本でAWS Direct Connectを利用する話

資料

 

以下、講演を聞きながらのメモ

想定する聴講者

ネットワークはあまり詳しくないけど、AWSを使ってみたいIT技術者

ネットワークセキュリティとその設計

Direct Connectはオンプレとクラウドを繋げるサービス

 

インターネットは怖いのでセキュリティをしなければいけない。

コンピュータセキュリティは大きく分けて2種類ある

エンドポイントセキュリティ

 → ウィルス対策ソフトを入れたり

ゾーンセキュリティ

 → 企業などが、自分の管理下のネットワークを置いて、そこで管理すること。
プライベートなネットワークのこと。

 → 組織内の人のみアクセスできるプライベートネットワーク。専用の箱を作って管理。

 → 誰でもアクセスできるパブリックネットワークとの境界を
しっかり分けて管理しましょうということ。

 → 会社の場合だと、ルータがその境界になっていたりする。

家庭のネットワークと企業のネットワークの違い

会社のネットワークは、システムの用途などでプライベートネットワークが別れている。

オフィスのLANとデータセンターで別ネットワーク。

それぞれのプライベートネットワークをどう繋ごうかと考えたりする。

拠点間プライベートネットワーク

方法としては大きく2種類ある

インターネットVPN

安価でベストエフォート

パブリックなインターネットを経由して行うが、組織内の通信を暗号化することにより実現。

インターネットを経由して行なっているので、使い勝手も特に差異はない。

IP-VPN

高価・高セキュリティで帯域保証つき

インターネットベンダーの設備を経由して、閉じた通信網のなかで行う通信。

 → 昔は、ビルとビルの間に線をつないで、、、とかやってる時代もあった。

 → いまは、ネットワークベンダーの設備を使ってやったりしている。

 

Ethernetであれば、ネットワーク通信自体の要件に違いはない。

セキュリティレベルや品質で選択する。

クラウドのネットワーク設計

いわゆる、VPCの話。AWSVPCはどういうつくりなのか?

VPCとは

AWSで使えるネットワーク機能

ざっくりいうと、AWSで使えるネットワーク機能が詰まったもの。

 

VPCの便利なところというのが、

パブリッククライドとしては、東京リージョンということで共通で使うのだが、

ユーザごとにネットワークを切って使うことができる。

 

それぞれのVPCは独立していて、閉じた仮装プライベートネットワーク。

やろうと思えば、VPC同士の接続(ピア接続)もできる。

 

本番と開発のネットワークを分けたいというような形で使われることが多い。

本番のネットワークのセキュリティレベルはあげたいが、

開発用はポコポコサーバーを建てたい、など。

 

VPCとプライベートネットワーク(社内の環境)との相互接続を実現するために

AWSが提供しているDirect Connectというのがある。

 

VPCとプライベートネットワークを繋げる手段は3

  • VPCのインターネットVPN機能
  • EC2でインターネットVPNソフトウェアを実行
  • AWS Direct Connect (今回のメイン

Direct Connectの特徴

  • 高品質
  • 高セキュリティ

サービスとしてのSLAは未定義なため、

現状は、月のアクセスがどのくらいまで保証、というのが明示されていない。

AWSによるサービスのメンテ頻度など実績で比較する。

Direct Connectはメンテ頻度が少ないので、安定しているなど。

対して、インターネットVPNというのが、構築も簡単で手軽である。

AWS Direct Connect

日本で使えるところ。

  1. エクイニックス ty2(東京 東品川)
  2. アット東京 cc1(東京 新豊洲)
  3. エクイニックス os1(大阪 四つ橋)

AWSのリージョン(東京・大阪)とは別

コラム

Direct Connectがある場所に、日本のAZがあるの?という質問がよくある。

真実はわからないが、違うというアナウンスがされている。

Direct Connectの使い方

Direct Connectが提供してくれるのは全てではなく、

VPCから、先ほどの3箇所(エクイニックスty2、アット東京cc1、エクイニックスos1

までの通信が用意される。

 

その3箇所のところにLANの差込口があるので、そこまでは繋ぐよ。

そこから自社のネットワークまでは、自分で用意してね。っていうようになっている。

自社のネットワークまでの繋ぎ方は2種類ある

占有プラン

3つのいずれかのデータセンターと通信を自前で行なって

IP-VPN接続などをする。

自社内のプライベートネットワークの中に

3つのうちのデータセンターへの口を用意する。

メリット

ユーザが自分でいろいろ設定するので、制約は少ないというメリットがある。

 → たとえば、複数のネットワークベンダーからデータセンターに繋ぐということもできるし、

   いくつものVPCを繋げるということもできる。

デメリット

価格が高いこと

共用プラン

ネットワーク事業者が、3つのうちのデータセンターとクラウドとの接続をやっているので、

自社内からそのクラウドに対して、IP-VPN接続を行う。

メリット

占有プランと比べて、データセンターとのやりとりコストや予算などが抑えられること。

デメリット

制約が多いことと、接続できるVPC数が1つだけであること。

まとめると

  • 共用プラン:比較的手軽
  • 占有プラン:本格利用

とっかかりはどうするか?

Direct Connnectを使いたいとなったら、既存のネットワーク事業者の営業さんに相談をする。

 → 中には、Direct Connectの経験があるネットワークベンダーもある。

 → AというネットワークはIP-VPN接続でやって、
   Bというネットワークはネットワークベンダーにお願いして、というようなやりかたもある。

技術的な不明点があれば、質問したり、AWS専用線アクセス体験ラボの活用がおすすめ

おまけ

  • Direct Connect応用機能
    → 占有プランでないと使えなかったりする。
  • パブリック接続
  • Direct Connect Gateway
  • Lag

まとめ

  • Direct connectはプライベトネットワークとVPCを高品質セキュアにつなぐサービス
  • 占有プランと共有プランがある
  • 質問があればネットワークベンダーに質問してみよう。

Q & A

Q1.

メンテナンスの頻度はよくある?

A1.

Direct Connectの推奨としては、冗長構成となっているので

片方がメンテナンスになってしまっても、

もう片方が残っていればいいというような状況にしておくのがよい。



2. AWS 専用線アクセス体験ラボトレーニング参加レポート

登壇者の方(濱田さん)から。

今回の講演で、面白かったポイントを伝えたりしようと思う。

また、これを聞いた人が参加したいなと思ってもらえたらよいかなと思う。

資料

 

以下、講演を聞きながらのメモ

イントロ

濱田さんが日頃の業務をしているときに

AWSとオンプレとの接続はマスト要件」という案件がある。

そういう場合は、

Configファイルを渡して、つながったら、よしやった!と思う。

ただ、当時のイメージとしては、

お客さん側の得体のしれない機材や得体の知らないネットワークが

どのように稼働しているのかイメージがつかなかったため、

体験ラボハンズオンに参加した。

 

結論からいうと、バックエンドやVPNとかよくわからないという方にとっては

とても学びがあって楽しい。

体験ラボとは?

学べる。

ルータを使った接続の体験とかができる。

会社でネットワークの運用とかをやっている人におすすめ。

 

トレーニングは2種類あって、

ハンズオントレーニングの方をやってきた。

(もう片方は座学なのかもしれない、、、たぶん。)

 

料金が無料!!!!!!!!

 

ハンズオン会場は、AWSのビルの素敵なところで行なう。

注意:ボルダリングするところがあるが、そこの写真とると怒られる。

 

行くときは、PCAWSアカウントを用意しておく。

 

講師は、AWSの菊池さんという人。ガチガチのスペシャリストの人。

とても丁寧に教えてもらえる。

 

ハンズオン形式でテキストを進めて行く形。

 

講演の中で説明されるが、

あるWEBサイトにAWSアカウトを登録すると

自分のAWSアカウントのDirect Connect のところに

Virtual Interfaceが自動で作られる。すごい。

 

ハンズオンの中では、VGWの作成などが

こうやればできますよってテキストに書いてあって、それをやる。

 

ある程度最初に、どんなことをやるのかイメージして

ハンズオンで進めていくことで理解が深まるのでよい。

よかったこと

  • Direct Connectの設定の流れを一気通貫で学ぶことができる。
  • ルーターコマンドを体験できる。
  • 講師にマニアックな質問ができる。
    → 参加人数がそれほど多くないので、
    ネットワークスペシャリストにVPNや専用線の質問ができる!
  • テストラボトレーニングの資料がもらえる。

まとめ

これまで霧のようなイメージだったお客さん側の環境が理解できるようになった!

また、無料だし3時間くらいだし、失うものは何もないので参加すると良い!

AWS 専用線体験」で検索!

Q & A

Q1.

無料ということだったが

ハンズオン内で行うAWS料金も無料?

A1.

そこはさすがに自分持ちです。

ただ、ハンズオン内でかかる費用は50円くらい。

しかも、ハンズオンの資料がもらえるので、それを見ながら1週間くらい遊んだりはできる。

1週間くらいはハンズオン用のデモの環境を残しておいてくれるので)



3. VPN接続とルーティングの基礎

まず始めに、登壇者の菊池さんから

今回はだいぶテクニカルな内容になります。と説明があった。

菊池さんは、AWS認定を8冠しているすごい方。

資料

 

以下、講演を聞きながらのメモ

1. AWSVPN接続

いわゆる、インターネットVPN

 → インターネット上の通信でパケットをカプセル化することで仮想敵なトンネルを形成

 

実現方法によって2つの分類がある。

  • ハードウェアVPN
  • ソフトウェアVPN

ハードウェアVPN

接続に必要な部分が、AWSのサービスとして提供されている。

ソフトウェアVPN

EC2の中にソフトウェアをインストールして、そこを通してVPN接続すること。

 

この2つを比べて一番違う部分が、

ソフトウェアVPNの場合は、

VPN接続の部分を、ユーザが自分たちで保守・運用しないといけない
例えばEC2インスタンス建てたりソフトウェアをインストールしたりとかということ

今回のテーマはハードウェアVPN

ハードウェアVPN = マネージドVPN

拠点間を繋ぐIPSecVPN

2. ハードウェアVPN

出てくるコンポーネントは3

  • customer gateway
    → オンプレ側に設置するルータ
    public ipを必要とする。
  • virtual private gateway
    VPCにアタッチするゲートウェイ
  • VPNトンネル
    → CGWとVPGを繋ぐ

 

AWS上での設定はとても楽。3ステップ。

 

設定ファイルが最後にDLできる

 

設定ファイルには、

  • IPSecVPNの設定情報
    → IKE/Ipsec/TUNNEL
  • BGPルーティングの設定(動的ルーティングの場合)

が書かれており、

IKEの事前共有鍵、AWS側の接続先IPなどが書かれている。

 

AWS側では、2箇所でルートが設定されている。

  • VGW
  • VPCのルートテーブル

3. BGPによる経路交換

AWSを使うと、IPSecまでの設計はほとんどいらない。DLするConfigに書かれている。

ネットワークの経験がない人がBGPをやろうとすると、一気にハードルが高くなる。

 

BGPとは?

Border Gateway Protocol

のこと。

動的ルーティングプロトコルの1

 

AS(Autonomous System:自律システム)間で経路情報を交換する。

ASナンバーというのは、大きなネットワークキャリアとかが、他と通信するための番号。

 

TCPで接続したルータ間で経路をアドバタイズ(広報)する

 → パスアトリビュート属性を付加することで経路を制御

  → ISPとかが複数の経路を提示してくれるが、
この属性によって最短の経路が何かを示してくれる。

 

VGWVPNトンネルの間にルータが2つある。

  • CGWで設定したCIDRCGWから受け取るルータ
  • VPNCIDRCGWに送信するルータ

 

BGPでは、パスアトリビュートのパラメータが10以上ある。

AWSでよく使われているのは

  • Local_Prefence
  • AS_PATH
  • Med

ここら辺の話はとてもディープな話になるので、

また次回の勉強会でやろうかな菊池さんがおっしゃってました。

4. 設定時の注意

CGWには実績のある機器を設定しよう

 → 不具合の回避

 → 実績のない機器を検討する場合は事前検証を。

 

AWSが公式に検証をサポートしている機器もある。

そういうものを使えば、まぁ、間違いないでしょう。

その機器の中に、 Cisco とか Juniper とかある。

コラム

ネットワーク屋さんからすると、CGWVGWは同じ機種を使うのがセオリーなので

AWSで使われている、謎の機器を使うときは、サポートされているものを使いましょう。

サンプルコンフィグの注意点

CGWNAT環境にある場合。

クライアントのFireWallの奥にCGWがある場合。

その時は、インターネットからFireWallを超えてCGWにアクセスできるように設定しよう。

サンプルコンフィグを使うと、NATGWIPが記載されているので、そこの書き換えが必要。

繋がらないときのトラブルシューティング

  • Ipsecがダウンしていないか
  • BGPがダウンしていないか
  • ルートテーブルが反映されているか

まとめ

  • ハードウェアVPNはマネージドなIpsecVPN
  • BGPまたはstaticルーティング経路を設定
  • AWSが、設定は簡単

Q & A

Q1

今回話したような内容は、ネットワークベンダーさんがやってくれる?

A1

基本的にやってくれる。

Q2.

経路交換しているときに、

VPC側の経路情報が流れてしまうという話があったがルーティングの設定をすればよいのか?

A2.

そうですね。オンプレの設定だけルーティングするような設定をしないといけない。

Q3.

Direct ConnnectSLAの設定がないという話で、冗長構成が推奨ということだったが、

どういう内容があるか?

A3.

データセンサーから線を2本引くなど。どこまでお金かけるかとか、考え方とかによることになる。

Q4.

AWS側でVPN接続する際にルータが2

CGWCIDRを受け取るものと、VPCCIDRを送るもの)出てくるが、

それが別れているのはなぜか?

A4.

AWS側が冗長化のためにやっている。

メンテナンスの際は、片方がとまるが、片方は生き残ったままというような形になる。