DEV Community: MOHA PRASATH SA

M for Moha, M for Amazon MQ: My First AWS Deep Dive

MOHA PRASATH SA — Wed, 16 Sep 2026 02:42:35 +0000

Cloud computing is not only about storing files or running websites. Modern applications also need different systems and services to communicate with each other reliably.

For my AWS workshop, I explored Amazon MQ, an AWS managed message broker service. Since my name starts with M, I selected an AWS service starting with the same letter.

My blog title is:

M for Moha, M for Amazon MQ: My First AWS Deep Dive

Introduction

In a distributed application, different components often need to exchange information.

For example, imagine a college application where students register for courses. The registration system may need to send information to another system responsible for notifications, while another system may update student records.

If all these systems communicate directly with each other, the architecture can become complicated.

This is where message brokers can help.

Amazon MQ is a managed message broker service provided by AWS. It supports popular messaging technologies such as Apache ActiveMQ Classic and RabbitMQ, allowing applications to communicate using established messaging protocols.

What is Amazon MQ?

Amazon MQ is a managed message broker service from AWS.

A message broker acts as an intermediate system between applications.

Instead of Application A directly communicating with Application B, Application A can send a message to the broker. Application B can then receive the message from the broker.

A simplified example is:

Application A
     |
     | Message
     v
+----------------+
|  Amazon MQ     |
| Message Broker |
+----------------+
     |
     | Message
     v
Application B

Amazon MQ is particularly useful when applications already use messaging technologies such as RabbitMQ or ActiveMQ Classic and organizations want a managed service instead of managing the broker infrastructure themselves.

Why was Amazon MQ created?

Traditional message brokers require organizations to manage servers, software installation, configuration, maintenance, monitoring and availability.

Amazon MQ provides a managed approach.

AWS manages much of the underlying infrastructure, allowing developers to concentrate more on their applications and messaging architecture.

Another important reason is compatibility.

Organizations may already have applications built around established messaging systems. Moving everything to a completely different messaging technology can require significant application changes.

Amazon MQ supports existing messaging technologies and protocols, making migration to AWS easier in suitable scenarios.

How Amazon MQ Works

The basic process can be explained in four steps.

1. Producer creates a message

A producer application generates information.

For example:

"Student registration completed"

2. Message is sent to the broker

The producer sends the message to Amazon MQ.

3. Broker manages the message

The broker receives and manages the message according to the configured messaging system.

4. Consumer receives the message

A consumer application receives and processes the message.

The overall flow is:

+-------------+
|   Producer  |
| Application |
+------+------+
       |
       | Message
       v
+----------------+
|    Amazon MQ   |
| Message Broker |
+-------+--------+
        |
        | Message
        v
+-------------+
|  Consumer   |
| Application |
+-------------+

This approach helps applications communicate without requiring a direct connection between every application component.

Key Features

1. Managed Message Brokers

Amazon MQ provides managed message broker infrastructure.

Instead of manually setting up and maintaining the broker servers, developers can use AWS infrastructure to run their messaging workloads.

2. Support for Popular Messaging Technologies

Amazon MQ supports ActiveMQ Classic and RabbitMQ.

This is useful for organizations that already have applications using these technologies.

3. High Availability Options

Amazon MQ provides deployment options designed for availability and resilience.

For workloads where message delivery is important, organizations can configure appropriate broker deployments and availability options.

4. Security

Amazon MQ integrates with AWS security capabilities.

Applications can use network controls such as VPC security groups, and communication can be protected using encryption and authentication mechanisms supported by the selected broker.

Security configuration should always be designed according to the application's requirements.

College / Student Use Case

A practical college use case would be a Campus Notification System.

Consider a college with multiple applications:

Student registration system
Attendance system
Examination system
Notification system
Email/SMS service

When a student registers for an event, the registration application could publish a message.

For example:

Student:
Moha

Event:
AWS Cloud Workshop

Status:
Registered

Instead of directly calling the notification system, the registration application can send a message through a message broker.

The notification service can then process the message and send the student a confirmation.

Architecture:

             Student
                |
                v
       +----------------+
       | Registration   |
       | Application    |
       +-------+--------+
               |
               v
        +-------------+
        |  Amazon MQ  |
        +------+------+ 
               |
        +------+------+
        |             |
        v             v
+---------------+ +---------------+
| Email Service | | Notification |
|               | | Service       |
+---------------+ +---------------+

This allows different campus applications to communicate through messaging rather than being tightly connected.

Simple Example

A simplified messaging example can be represented as:

Producer
   |
   | "Assignment submitted"
   v
Amazon MQ
   |
   | Message
   v
Notification Service
   |
   v
Student receives notification

The actual implementation depends on whether RabbitMQ or ActiveMQ Classic is selected and on the application's programming language and messaging protocol.

For a student project, the concept can be demonstrated using a small producer-consumer application.

Advantages

Reduced Infrastructure Management

AWS manages much of the underlying infrastructure, reducing the amount of server administration required.

Compatibility

Applications using supported messaging technologies can potentially move to Amazon MQ without completely redesigning their messaging architecture.

Useful for Distributed Applications

Message brokers can help separate application components and support asynchronous communication.

Integration with AWS

Amazon MQ can operate within AWS networking and security environments, making it useful for applications already running on AWS.

Limitations and Things to Consider

Cost

Amazon MQ is a paid AWS service. Costs depend on factors such as broker instance type, deployment configuration and data transfer.

Students should check current AWS pricing before creating resources.

For a short workshop, resources should be created carefully and deleted after testing to avoid unnecessary charges.

Complexity

Message brokers introduce additional infrastructure and concepts.

Developers need to understand queues, exchanges, topics, consumers, producers, acknowledgements and message delivery behaviour depending on the broker technology.

Scalability

The scalability characteristics depend on the selected broker, configuration and workload.

It is important to design the messaging architecture according to expected traffic rather than assuming unlimited scaling.

Security

Authentication, authorization, encryption, network access and credentials need to be configured properly.

A production messaging system should not expose a broker unnecessarily to the public internet.

What I Learned

Through this AWS workshop task, I understood that cloud computing is not only about hosting applications.

Communication between distributed applications is also an important part of cloud architecture.

Amazon MQ introduced me to the concept of message brokers and showed how producers and consumers can communicate through an intermediate messaging system.

The college notification example also helped me understand how the concept can be applied to a real student or campus application.

Conclusion

Amazon MQ is an AWS managed message broker service that can help applications communicate using established messaging technologies such as RabbitMQ and ActiveMQ Classic.

Its managed infrastructure, compatibility with existing messaging technologies, security capabilities and integration with AWS make it useful for suitable distributed application architectures.

For my AWS workshop, exploring Amazon MQ helped me understand an important cloud concept: applications do not always need to communicate directly with each other. A message broker can act as a reliable communication layer between them.

References

AWS Documentation — Amazon MQ
AWS Documentation — Amazon MQ for ActiveMQ
AWS Documentation — Amazon MQ for RabbitMQ
AWS Pricing — Amazon MQ

Always check the latest AWS documentation and pricing before deploying resources.

# Day1: Deploying My Portfolio with AWS S3 and CloudFront on Cloud Workshop

MOHA PRASATH SA — Tue, 15 Sep 2026 06:57:00 +0000

This was my first hands-on experience deploying a frontend application using AWS services. Instead of stopping at the development stage, I wanted to understand how a website can be hosted using cloud infrastructure.

For this deployment, I worked with Amazon S3 and attempted to configure Amazon CloudFront.

My Portfolio

The portfolio was developed using:

React
JavaScript
HTML
CSS
Vite

It contains sections for:

About Me
Skills
Projects
Contact

After completing the React application, I generated the production files using:

npm run build

The generated files were available in the dist folder.

Step 1: Creating an S3 Bucket

The first step was creating an Amazon S3 bucket for my portfolio.

After creating the bucket, I uploaded the website files into it.

The main file was:

index.html

Along with the other required website assets.

The basic structure was:

S3 Bucket
│
├── index.html
├── assets/
└── other files

Step 2: Configuring Static Website Hosting

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

I specified:

Index document:
index.html

This tells S3 which HTML file should be loaded as the main page of the website.

Step 3: Configuring Access

I then worked through the S3 access and permission settings required to make the static website accessible.

This was one of the useful parts of the process because it made me understand that simply uploading a file to S3 does not automatically make it available to everyone.

There are separate considerations for:

Bucket access
Object permissions
Static website hosting
Public access settings
Security policies

After configuring the required settings, I was able to work with the S3-hosted version of my portfolio.

Step 4: Trying Amazon CloudFront

The next step was to add Amazon CloudFront.

The architecture I wanted to create was:

                User
                  │
                  ▼
          Amazon CloudFront
                  │
                  ▼
              Amazon S3
                  │
                  ▼
          React Portfolio

CloudFront acts as a CDN and can distribute website content through AWS edge locations.

I wanted to use it as the delivery layer in front of my S3-hosted portfolio.

The CloudFront Problem

While creating the CloudFront resource, I encountered an AWS account-level verification error.

AWS displayed the following message:

"Your account must be verified before you can add new CloudFront resources."

So, at this stage, CloudFront deployment was not completed.

This was actually an important part of the learning experience.

I initially thought deploying a website would simply be:

Write Code → Upload Files → Website Online

But the process also involves:

Application
    ↓
Build
    ↓
Cloud Storage
    ↓
Permissions
    ↓
Service Configuration
    ↓
Account Verification
    ↓
CDN / Delivery
    ↓
Production Website

What I Learned

This small project helped me understand several AWS concepts practically.

Amazon S3

I learned how S3 can be used to store and serve static website files.

Static Website Hosting

I learned how an index.html file can be configured as the entry point for a static website.

Permissions

I learned that storage, website hosting, and access permissions are separate configuration areas.

CloudFront

I learned the role of CloudFront as a CDN in front of an S3-based website, even though I could not complete the CloudFront deployment because of the account verification restriction.

Cloud Deployment

Most importantly, I learned that deploying an application involves more than writing code. Cloud services have their own account requirements, permissions, security configurations, and service restrictions.

Current Architecture

The part I successfully configured was:

React Portfolio
       │
       ▼
   npm run build
       │
       ▼
    index.html
       │
       ▼
    Amazon S3

The architecture I am working toward is:

                    User
                     │
                     ▼
             Amazon CloudFront
                     │
                     ▼
                 Amazon S3
                     │
                     ▼
             React Portfolio

react #aws #amazonS3 #cloudfront #javascript #webdevelopment #cloud #devops #learning