DEV Community: MIDHUN KRISHNA B

#M for Midhun, M for Macie: Exploring Amazon Macie 🔐☁️

MIDHUN KRISHNA B — Wed, 16 Sep 2026 02:08:15 +0000

Introduction

Cloud storage makes it easy for organizations, colleges, and students to store large amounts of data. However, storing data in the cloud also creates an important question: How do we know whether sensitive information is stored securely?

AWS provides several security services to address different security requirements. One of them is Amazon Macie, a fully managed data security and data privacy service designed to help discover sensitive data stored in Amazon S3.

Amazon Macie uses machine learning and pattern matching to discover sensitive information, monitor the security posture of S3 buckets, and generate findings when it detects potential security or privacy issues.

For me, this service was an interesting choice because my name starts with M, and Amazon Macie also starts with M.

What is Amazon Macie?

Amazon Macie is an AWS data security service that focuses primarily on data stored in Amazon S3.

Macie automatically maintains an inventory of S3 general-purpose buckets and evaluates them for security and access-control issues. For example, if Macie detects that an S3 bucket has become publicly accessible, it can generate a finding for investigation.

Macie can also inspect S3 objects to identify sensitive information such as personally identifiable information (PII), financial information, and credentials. It uses AWS-managed data identifiers as well as custom data identifiers defined by the user.

In simple terms:

S3 stores the data, while Macie helps us understand whether sensitive data exists there and whether the S3 environment has security risks.

Why was Amazon Macie created?

As organizations move more data to cloud storage, it becomes difficult to manually inspect every file and determine whether it contains sensitive information.

For example, a college might have thousands of files containing:

Student information
Academic records
Research documents
Contact information
Project datasets
Financial documents

Manually checking all these files would take significant time.

Macie was designed to automate the discovery and reporting of sensitive data in Amazon S3 while also providing visibility into S3 security and privacy risks.

How Does Amazon Macie Work?

The basic workflow can be understood as:

                College / Organization
                         │
                         ▼
                  ┌─────────────┐
                  │  Amazon S3  │
                  │ Data / Files│
                  └──────┬──────┘
                         │
                         ▼
                  ┌─────────────┐
                  │ Amazon Macie│
                  └──────┬──────┘
                         │
             ┌───────────┴───────────┐
             ▼                       ▼
      Sensitive Data          Security / Privacy
       Detection                  Findings
             │                       │
             └───────────┬───────────┘
                         ▼
                  Administrator
                    Investigation

When Macie is enabled, it creates and maintains an inventory of S3 general-purpose buckets. It can then evaluate the buckets for security and access-control issues.

For sensitive-data discovery, Macie provides two main approaches:

Automated sensitive data discovery
Sensitive data discovery jobs

Automated discovery provides broad visibility by evaluating the S3 inventory and selecting representative objects for analysis. Discovery jobs provide more targeted control because the user can specify which buckets and objects should be analyzed and whether the job should run once or periodically.

Key Features

1. Automated Sensitive Data Discovery

Macie can automatically analyze representative S3 objects to identify where sensitive data may exist.

This provides organizations with broader visibility without requiring administrators to manually inspect every file.

2. Sensitive Data Discovery Jobs

Users can create specific discovery jobs to analyze selected S3 buckets and objects.

These jobs can be configured for one-time analysis or scheduled analysis, making them useful for periodic security assessments.

3. Managed and Custom Data Identifiers

Macie includes built-in techniques for detecting many types of sensitive information, including PII, financial information, and credentials.

Users can also create custom data identifiers using patterns such as regular expressions to detect information specific to their organization.

4. Security and Access Monitoring

Macie continuously maintains an inventory of S3 general-purpose buckets and evaluates them for security and access-control concerns.

If a potential security or privacy issue is detected, Macie creates a finding that administrators can investigate.

5. Findings and Reporting

Macie produces findings containing details about detected sensitive data or S3 security issues.

These findings can also be integrated with services such as Amazon EventBridge and AWS Security Hub for further monitoring and response workflows.

College / Student Use Case 🎓

Consider an AI and Machine Learning department that uses Amazon S3 to store student project datasets.

The department may have files containing:

Student Dataset
Research Data
Project Reports
Student Information
Survey Results

Some datasets may accidentally contain personal information such as names, email addresses, phone numbers, or other sensitive information.

The department could use Macie to analyze its S3 environment and identify where sensitive information may exist.

For example:

Student Project
      │
      ▼
Amazon S3
      │
      ▼
Amazon Macie
      │
      ▼
Sensitive Data Finding
      │
      ▼
Department Administrator
      │
      ▼
Review / Remediation

This could help students and administrators become more aware of data privacy while developing cloud-based applications.

Simple Practical Example

Suppose a student uploads a CSV file to an S3 bucket:

student_data.csv

The file might contain:

Name,Email,Department
Arun,arun@example.com,AI & ML
Rahul,rahul@example.com,AI & ML

A Macie sensitive-data discovery job can analyze the S3 object and report sensitive information that matches its detection criteria.

A basic practical workflow is:

Create an S3 bucket.
Upload a test file.
Open Amazon Macie.
Enable Macie for the AWS Region.
Select the S3 bucket for analysis.
Create a sensitive data discovery job.
Run the job.
Review the resulting findings.

AWS provides an official getting-started workflow that includes enabling Macie, configuring result storage, exploring sample findings, creating a sensitive-data discovery job, and reviewing findings.

For a student experiment, it is better to use dummy/test data rather than real personal information.

Advantages

Amazon Macie provides several benefits:

Automated discovery: Reduces the need to manually inspect large numbers of S3 objects.
Security visibility: Helps identify potential S3 security and access-control issues.
Sensitive-data detection: Can detect various categories of sensitive information.
Customization: Custom data identifiers allow organizations to define their own detection patterns.
Integration: Findings can be integrated with other AWS security and event-management services.

Limitations / Things to Consider

Cost

Macie is a paid AWS service, and pricing depends on factors such as the number of S3 buckets monitored, the number of S3 objects involved in automated discovery, and the amount of uncompressed data analyzed.

AWS also provides a 30-day free trial when Macie is enabled for the first time, subject to the applicable conditions. AWS currently also provides a monthly free allowance for analysis of up to 1 GB of S3 data for sensitive-data discovery.

Therefore, students should monitor their AWS usage and costs.

Complexity

Macie is easier to use than building a complete sensitive-data detection system from scratch, but understanding findings, data identifiers, permissions, and S3 security configurations still requires AWS knowledge.

Scalability

Macie is designed to work with S3 data estates at organizational scale. Automated discovery and targeted discovery jobs allow organizations to choose different levels of analysis.

Supported Data

Macie does not analyze every possible S3 storage class and file format. The object must use a supported storage class and supported format for sensitive-data analysis.

Conclusion

Amazon Macie is an AWS service designed to improve visibility into sensitive data and security risks in Amazon S3.

Its combination of machine learning, pattern matching, automated discovery, sensitive-data discovery jobs, security monitoring, and detailed findings makes it useful for organizations that store important information in S3.

For a college or student project, Macie can be particularly useful as an introduction to cloud security, data privacy, and responsible handling of sensitive information.

My takeaway is simple:

Amazon S3 helps us store data, while Amazon Macie helps us understand and protect the sensitive data stored there.

And that makes “M for Midhun, M for Macie” a fitting introduction to my first AWS security deep dive. 🚀

References

AWS Documentation — What is Amazon Macie?
Amazon Macie Documentation
AWS Documentation — Getting Started with Amazon Macie
Getting Started with Amazon Macie
AWS Documentation — Discovering Sensitive Data with Macie
Discovering Sensitive Data with Macie
AWS Documentation — Amazon Macie Pricing
Amazon Macie Pricing Documentation

Cloud Workshop Day 1: Building and Deploying My First HTML Portfolio on AWS

MIDHUN KRISHNA B — Tue, 15 Sep 2026 06:54:57 +0000

From `index.html` to the Cloud: Deploying My Portfolio with AWS S3 and CloudFront

As part of my cloud workshop, I got the opportunity to build and deploy my own personal portfolio website using HTML, CSS, JavaScript, and AWS.

The website itself was straightforward — a single HTML-based portfolio — but deploying it to the cloud taught me much more than simply creating a webpage.

I worked with Amazon S3 to host my website files and Amazon CloudFront to distribute the website through a global content delivery network.

Along the way, I also faced a few errors that helped me understand how cloud deployment actually works.

🛠️ Technologies Used

HTML
CSS
JavaScript
Amazon S3
Amazon CloudFront

1. Building My Portfolio Website

I started by creating my portfolio as an HTML file.

The main file was:

index.html

I used HTML to structure the website and CSS to design the interface. JavaScript was used wherever interactive functionality was required.

The portfolio included sections such as:

About Me
Skills
Projects
Education
Experience / Journey
Contact

The goal was to create a simple, responsive portfolio that could showcase my skills and projects.

At first, the website was running locally on my computer.

The next challenge was:

How can I make this website accessible online?

That's where AWS came in.

☁️ 2. Creating an Amazon S3 Bucket

The first AWS service I used was Amazon S3 (Simple Storage Service).

S3 can store static website files such as:

HTML
CSS
JavaScript
Images
Other frontend assets

I created an S3 bucket specifically for my portfolio website.

After creating the bucket, I uploaded my index.html file along with the required website files.

The basic structure looked like:

Portfolio Website
│
├── index.html
├── style.css
├── script.js
└── images/

The important file was index.html, because it served as the main entry point of the website.

🌐 3. Configuring the Website in S3

After uploading the files, I configured the S3 bucket for hosting the static website.

The idea was simple:

Browser
   ↓
AWS S3
   ↓
index.html

However, simply uploading a file to S3 does not automatically make it publicly accessible.

I had to configure the required settings and permissions so that the website could be accessed properly.

⚠️ 4. Facing the Access Denied Error

One of the first problems I encountered was an:

AccessDenied

error.

The file existed inside the bucket, but accessing it through the website endpoint did not work as expected.

This made me realize an important concept:

Uploading a file to cloud storage and making that file accessible through the internet are two different things.

I had to check the bucket configuration and permissions carefully.

After correcting the required settings, I was able to access the website through S3.

🚀 5. Adding Amazon CloudFront

Once the website was working with S3, I wanted to use Amazon CloudFront.

CloudFront is AWS's Content Delivery Network (CDN). It can distribute website content through edge locations around the world.

The architecture became:

User
  ↓
CloudFront
  ↓
Amazon S3
  ↓
index.html

Instead of users directly accessing the S3 bucket, CloudFront could act as the front-facing distribution layer.

This also introduced another set of configuration requirements.

❌ 6. The CloudFront `NoSuchKey` Error

After configuring CloudFront, I encountered another error:

NoSuchKey

The error indicated that CloudFront was looking for:

index.html/index.html

instead of simply:

index.html

At first, this was confusing because the index.html file definitely existed in the S3 bucket.

I then checked the CloudFront configuration.

🔍 7. Finding the Problem

The problem was related to the Origin Path configuration.

The CloudFront origin had been configured with an origin path that already pointed toward index.html.

At the same time, the CloudFront distribution was configured with:

Default Root Object:
index.html

This caused CloudFront to effectively construct a path similar to:

/index.html/index.html

That file obviously did not exist.

The correct configuration was to remove the unnecessary origin path and allow CloudFront to use:

Default Root Object → index.html

After correcting the configuration, CloudFront could find the actual file in the S3 bucket.

🔄 8. Creating a CloudFront Invalidation

After changing the CloudFront configuration, I created an invalidation for:

/*

This tells CloudFront to remove the cached versions of the requested objects so that the updated configuration/content can be served.

After waiting for the distribution to update, I tested the website again.

This time, the portfolio loaded successfully.

🎉 9. Final Architecture

The final deployment looked like this:

             ┌─────────────────┐
             │      User       │
             └────────┬────────┘
                      │
                      ▼
             ┌─────────────────┐
             │  CloudFront CDN │
             └────────┬────────┘
                      │
                      ▼
             ┌─────────────────┐
             │    Amazon S3    │
             │                 │
             │   index.html    │
             │   CSS / JS      │
             └─────────────────┘

The portfolio was no longer limited to my local computer.

It had been deployed to the AWS cloud and could be delivered through CloudFront.

🧩 Challenges I Faced

The deployment was not completely straightforward.

I faced several issues during the process:

1. S3 `AccessDenied`

The website files existed, but the required access configuration was not correct.

2. Bucket Configuration

I had to carefully check the bucket settings and make sure the configuration matched the website deployment requirements.

3. CloudFront `NoSuchKey`

CloudFront was looking for:

index.html/index.html

instead of:

index.html

4. CloudFront Caching

After making configuration changes, I had to create an invalidation so that the updated content could be served.

These problems were actually one of the most valuable parts of the workshop because they forced me to understand what was happening instead of simply following deployment steps.

💡 What I Learned

This workshop gave me practical experience with cloud deployment.

Some of the key things I learned were:

How static websites can be hosted using Amazon S3.
How cloud storage permissions affect website accessibility.
How CloudFront works as a CDN.
How CloudFront connects to an S3 origin.
How the Default Root Object works.
Why correct origin configuration is important.
How caching can affect website updates.
How to troubleshoot AWS deployment errors.
How a locally created HTML website can be moved to the cloud.

The biggest lesson for me was that deployment is not always about getting everything right on the first attempt.

Errors such as AccessDenied and NoSuchKey initially looked confusing, but investigating them helped me understand the underlying AWS configuration.

🌍 From a Local File to a Cloud Website

Before this workshop, my portfolio was simply a website running on my computer.

After the deployment process, the architecture became:

HTML Portfolio
      ↓
    S3
      ↓
 CloudFront
      ↓
   Internet

That transition gave me a practical understanding of how cloud services can be used to deploy real websites.

It was a small project, but it was a valuable first step toward understanding cloud computing and deployment.

🚀 Conclusion

Building the portfolio was only one part of the experience.

The more valuable part was taking the index.html file from my local system and actually deploying it using AWS.

I learned that cloud deployment involves more than uploading files. Configuration, permissions, origins, caching, and troubleshooting all play an important role.

This workshop gave me hands-on experience with Amazon S3 and CloudFront, and it motivated me to explore more AWS services and cloud-based deployments in the future.

Build it locally. Deploy it to the cloud. Break it. Debug it. Learn from it.