マニュアルライターが独学でAWSに挫折し、Azureで「インフラを書けるエンジニア」になるまで

はじめに
自分はもともとエンジニアではありませんでした。
マニュアル制作会社でライターをしながら、土日にUdemyの教材を買って独学でプログラミングを勉強していた人間です。そんな自分が、会社の業務として3DアプリをEC2にデプロイすることになりました。
結果は「なんとか動いたけど、正直ずっと不安だった」。
あれから5年以上が経ち、今はAIアプリの開発をしながら、インフラやCI/CDの設定まで実装できるエンジニアになりました。その転換点にあったのが、Azureとの出会いです。
AWSは素人同然の自分には壁が高すぎた
マニュアル制作会社にいたころ、業務で3DアプリケーションをEC2にデプロイする機会がありました。
当時の自分はプログラミングを独学中のマニュアルライター。インフラの知識はほぼゼロです。週末にUdemyで買った教材を見ながら、手探りで設定を進めていました。
つらかったのは、これで合ってるのか?が全くわからないことでした。
- セキュリティグループで、どのポートを開けるべきか。開けすぎたらどうなるのか。
- VPCの設計の「正解」が何なのか。
- HTTPSにするためには何が必要なのか。
調べれば情報は出てくるのですが、「初心者向け」の情報と「本番環境向け」の情報が混在していて、自分がどちらを参照すべきかすら判断できない状態でした。
結局アプリは動きましたが、セキュリティ的に本当に大丈夫なのかという不安が最後まで消えませんでした。それがEC2デプロイの正直な記憶です。
「クラウドって便利なはずなのに、なんでこんなに不安なんだろう」と思いながら、インフラへの苦手意識を持ったまま、その業務は終わりました。
派遣先のITベンチャーでAzureに触れた「衝撃」
時が経ち、マニュアル制作会社からITベンチャー企業に派遣されることになりました。
そこで初めて触ったのがAzureです。Azure PortalとApp Serviceを使って、アプリをデプロイしてみました。
あれ、もうデプロイできてる。しかも、セキュリティの設定もこれで終わり?
EC2のときと比べて、体感で3倍は速く動かせた印象でした。何より違ったのは、不安がなかったことです。
Azure App Serviceは、HTTPSがデフォルトで有効になっています。マネージドな証明書が自動で付いてくる。ポータルのUIも整理されていて、「次へ」を押すだけで最低限の設定が揃っていきます。
EC2では「正解がわからないまま設定していた」のに対して、App Serviceでは「ある程度の正解がUIに組み込まれている」感覚でした。
インフラの深い知識がなくても、動くものが安全な状態で作れる。マニュアルライター上がりの自分には、その差は衝撃的でした。
AWSとAzureを比較してみると
自分の体験をもとに、2つのクラウドを整理してみました。性能の優劣というよりも、「誰に向いているか」の視点での比較です。
| 項目 | AWS | Azure |
|---|---|---|
| 市場シェア | 約31%(世界1位) | 約25%(世界2位) |
| 向いている人 | インフラを深く制御したい人 | アプリ開発に集中したい人 |
| 学習コスト | 高め(自由度が高い分、設定項目が多い) | 比較的低め(マネージドサービスが充実) |
| UIの使いやすさ | 情報量が多く、慣れが必要 | ウィザード形式で「次へ」で進みやすい |
| セキュリティ設定 | 自分で設計する部分が多い | デフォルトである程度整っている |
| Kubernetes | EKS(自分で設定することが多い) | AKS / Container Apps(マネージドで手軽) |
| Microsoft連携 | 別途設定が必要 | Entra ID・M365とシームレスに連携 |
| IaC(Terraform) | 対応。リソースが多い分、設定量も多め | 対応。ポータルとの一貫性が取りやすい |
| コミュニティ | 非常に大きい | 大きい(企業ユーザーが多い) |
| 日本語ドキュメント | 充実している | 充実している |
繰り返しになりますが、AWSが劣っているということではありません。ただ、当時の自分のスキルや目的に対しては「重すぎた」というだけです。
今、エンジニアとしてAzureを使って思うこと
現在はAIテック企業でAIアプリの開発をしながら、インフラやCI/CDの構築・運用も実装しています。
あのころ「セキュリティの正解がわからない」と不安だった自分が、今はTerraformでインフラをコードとして書いています。
Terraformを触ってあらためて感じるのは、インフラがアプリ開発と同じ感覚で書けるようになったということです。
resource "azurerm_container_app" "app" {
name = "my-app"
container_app_environment_id = azurerm_container_app_environment.env.id
resource_group_name = azurerm_resource_group.rg.name
revision_mode = "Single"
template {
container {
name = "my-container"
image = "myregistry.azurecr.io/my-app:latest"
cpu = 0.5
memory = "1Gi"
}
}
}
コードとしてインフラを定義できることで、GitHubで差分を管理できます。レビューもできるし、CI/CDで自動デプロイもできる。インフラを触るのはアプリを書くのとは別世界、という感覚がだいぶ消えました。
今の自分のAzure構成をざっくり図解すると、こんな感じです。
まとめ
| AWS(5年前) | Azure(現在) | |
|---|---|---|
| 自分のスキル | 独学初心者 | 実務経験あり |
| 設定の量 | 多い・自由度が高い | マネージドで省力化 |
| 不安の量 | これで合ってる?が常にある | UIがある程度正解を示してくれる |
| インフラの書き方 | コンソール手作業 | Terraform + CI/CDで自動化 |
クラウドは「玄人専用の道具」から「開発者が普通に使えるインフラ」に確実に進化していると思います。
インフラが苦手で……と感じているアプリ開発者の方には、マネージドなAzureサービスから触ってみることを個人的にはおすすめします。Terraformを使えば、インフラをアプリと同じ感覚でコードに落とせるようにもなります。
インフラへの苦手意識は、適切なツールを選べば、思ったより早く薄れていきますよ。
Discussion