Summary of "Week 5 Lab: Deploying Web Applications in Cloud"

Concise summary — main ideas and lessons

Goal: learn how to deploy a web application to cloud platforms (AWS and Azure). This is an important skill for software development and ML roles (including MLOps).
Prerequisite: have a web application ready locally or on GitHub (a simple static site or portfolio is fine). The lab focuses on deployment, not building the app.
Expectation: deploy the app, obtain a public URL, share it, and verify the site is accessible. After testing, delete/disable cloud resources to avoid ongoing costs and traffic-based billing.
Timeframe & scope: two weeks to try multiple deployment approaches (at least three), for example S3 static hosting, AWS Amplify, EC2 (or equivalent Azure options).

AWS — Deploy a static web app to S3 (method 1)

Prepare
- Build the web app locally and have code/files ready (HTML/CSS/JS/assets).
Login to AWS.
Create an S3 bucket
- Make sure “Block all public access” is unchecked so the site can be publicly loaded.
Upload your site files
- Put index.html and any other HTML/CSS/JS/assets into the bucket.
Enable static website hosting
- In the bucket’s Properties tab enable “Static website hosting.”
- Specify the index (landing) file (e.g., index.html).
Update bucket permissions / bucket policy
- In Permissions → Bucket Policy, add/modify the JSON policy so the bucket exposes public read access for objects.
Retrieve and share the static website URL
- After policy changes, in Properties → Static website hosting copy the generated URL (e.g., your-bucket.s3-website…).
- Verify the website loads on other devices.
Clean up
- Remove or disable the S3 bucket and any other resources to avoid costs from traffic/hits.

Note: S3 static site URLs may be HTTP or appear insecure. Investigate AWS options (CloudFront + ACM or Amplify) to serve the site over HTTPS if you see security warnings.

AWS — Other deployment options (overview)

AWS Amplify
- Connect Amplify to your GitHub repo so changes in GitHub auto-deploy. This removes the manual upload-to-S3 step and may handle HTTPS automatically.
EC2 / backend deployment
- For full back-end apps (Node.js, Java, Python, database), deploy on EC2 or other compute services and configure backend resources from the console. This workflow is more involved than static hosting.
HTTPS considerations
- Use services like CloudFront with an ACM certificate or Amplify-managed TLS to provide HTTPS for static sites.

Azure — Deploy a static web app to Storage Account (method)

Prepare
- Have web app files ready locally or in GitHub.
Login to Azure.
Create a Storage Account (if needed).
Enable static website hosting
- In the Storage Account go to Data management → Static website and enable it.
- Enabling the static website will auto-create a special container named $web.
Upload files
- Upload all source files into the $web container.
Retrieve and share the URL
- Get the static website URL from the Static website settings and verify it loads publicly.
Clean up
- Delete or disable resources after testing.

Azure — Other deployment options (overview)

Azure App Service
- Can connect to GitHub and deploy apps; suitable for applications with backends.
Azure Static Web Apps
- Intended for front-end/static sites; integrates with source control and CI/CD workflows.
Backend deployment
- Create databases and backend code (Node.js/Python/Java) and deploy a full application from the console — more complex than static hosting.

Lab assignments / expectations

Complete at least three different deployment techniques. Examples:
- S3 static hosting (upload files to S3)
- AWS Amplify (GitHub-connected auto-deploy)
- EC2 or other backend deployment (full application)
- Azure equivalents: Storage static website, App Service, Static Web Apps
Spend roughly two weeks exploring these options and testing.
Make the site public, share the generated URL, and confirm accessibility from other devices.
Handle HTTP vs HTTPS issues — apply AWS/Azure steps needed to serve the site over HTTPS if users see security warnings.
Delete/disable resources after finishing to avoid ongoing costs and repeated hits.

Practical warnings & tips

Have your code ready before the lab — lab time is for deployment, not app development.
Always turn off/delete cloud resources when done to avoid billing from traffic.
Public access must be explicitly allowed (e.g., uncheck S3 “Block all public access” and add a bucket policy).
If users see “not secure” or access errors, investigate switching to HTTPS for the hosted URL.