DEV Community

alok-38
alok-38

Posted on

AWS DevOps Practice Summary

AWS Setup

S3 Bucket Creation

  • Created a bucket: believe-in-bucket on AWS Free Tier.
  • Bucket settings: default “Block Public Access ON”, Object Ownership: Bucket owner enforced.

EC2 Instance

  • Launched an EC2 instance (Amazon Linux 2)
  • Connected via SSH from WSL2 and VSCode Remote-SSH
  • Verified IAM role attached to EC2 had **AmazonS3FullAccess **to communicate with S3.

2. EC2 → S3 Connectivity

Verified connection:

aws s3 ls
aws s3 ls s3://believe-in-bucket

Enter fullscreen mode Exit fullscreen mode
  • Success: EC2 could list the bucket, confirming IAM permissions are correct.
  • Troubleshooting::
    • Initially had to create an IAM role with AmazonS3FullAccess and attach to EC2
  • Ensured EC2 uses that role by checking aws sts get-caller-identity

SCP / VSCode Connectivity

  • SSH Connection Setup

  • Configured ~/.ssh/config on WSL2 and Windows

  • Verified connection:

ssh ec2-dev
Enter fullscreen mode Exit fullscreen mode
  • Issue: SCP using my-ec2 host failed due to “Could not resolve hostname”

  • Fix: Ensure the host alias in ~/.ssh/config matches the SSH command. Using actual EC2 public DNS worked.

  • VSCode Remote-SSH

  • Configured the same SSH config in VSCode

  • Connection worked, but public key permissions/paths needed corrections (used Windows paths in IdentityFile)

Uploading DevOps Folder to EC2

  • Created ~/DevOps folder on EC2

  • Copied index.html from WSL to EC2 via scp

  • Observation: Only index.html existed initially — no CSS/JS or subfolders.

Uploading to S3

  • First attempt:
aws s3 cp ~/DevOps s3://believe-in-bucket/ --recursive --acl public-read
Enter fullscreen mode Exit fullscreen mode
  • Errors encountered:
  1. AccessControlListNotSupported → caused by bucket having owner enforced ACLs

    1. Only index.html uploaded → folder structure and .git skipped (by default & ACL errors)
    2. Bucket policy changes failed → due to Block Public Access being ON
  • Troubleshooting Steps:
  1. Removed --acl public-read

  2. Excluded .git folder explicitly:

aws s3 cp ~/DevOps s3://believe-in-bucket/ --recursive --exclude ".git/*"

Enter fullscreen mode Exit fullscreen mode
  1. Verified folder structure:
aws s3 ls s3://believe-in-bucket/ --recursive

Enter fullscreen mode Exit fullscreen mode
  • Result: Files like index.html, css/style.css, js/app.js uploaded successfully.

Static Website Hosting

  • Enabled S3 website hosting:
aws s3 website s3://believe-in-bucket/ --index-document index.html
Enter fullscreen mode Exit fullscreen mode
  • Error: 403 Forbidden when accessing the URL in a browser

Troubleshooting:

  • Cause: Bucket is private, Block Public Access ON

  • Solution:

  1. Disable Block Public Access (for testing)

  2. Add bucket policy for public read:

{
  "Version": "2012-10-17",
  "Statement": [
      {
          "Sid": "PublicReadGetObject",
          "Effect": "Allow",
          "Principal": "*",
          "Action": "s3:GetObject",
          "Resource": "arn:aws:s3:::believe-in-bucket/*"
      }
  ]
}
Enter fullscreen mode Exit fullscreen mode
  • After this, the S3 URL was accessible.

  • Issue: Blank page appeared → cause: index.html had no content in <body>

  • Fix: Added minimal content to <body>:

<body>
    <h1>Welcome to AWS DevOps!</h1>
</body>
Enter fullscreen mode Exit fullscreen mode

Final Folder Structure in S3

index.html
css/style.css
js/app.js
Enter fullscreen mode Exit fullscreen mode
  • .git was excluded
  • Folder structure preserved, contents accessible via static website

Key Lessons / Gotchas

  1. S3 ACL vs Bucket Owner Enforced
  • --acl public-read fails on owner-enforced buckets → must use bucket policy for public access.
  1. ** Recursive uploads**
  • Only uploads existing files

  • Empty folders are not stored in S3

  • Exclude .git to avoid ACL/metadata issues

  1. Static Website
  • Needs public read via policy

  • URL must match folder structure (index.html at root vs in subfolder)

  1. SSH / SCP / VSCode
  • Host alias in ~/.ssh/config must match command

  • Identity file path correct for WSL vs Windows

  • SCP requires correct relative path to copy folders

  1. Blank page troubleshooting
  • Often caused by empty <body> or wrong paths for CSS/JS

Outcome:

  • EC2 instance created and connected via SSH/VSCode

  • IAM role attached to allow S3 access

  • DevOps folder uploaded from WSL → EC2 → S3

  • Bucket policy allows public read, website enabled

  • Website successfully serves index.html and all static assets

Top comments (0)