Before You Touch the Console — Deploying Spring Boot on AWS the Right Way (Part 1)

Introduction:

Most deployment guides tell you what to click. This one tells you why — and what it costs.

In this article, we will go deep into deploying a Spring Boot application on AWS. We will cover every decision, why we made it, what it costs, and what the best practice is for each step — and when to skip the best practice because the budget says no.

By the end, you won’t just have an architecture. You’ll have a thinking framework you can apply to any project.

About the Project we will deploy:

The application we are deploying is MIGFORA Sales — an internal tool built for the sales team at MIGFORA, an AWS partner company based in Jordan, serving the GCC and MENA markets.

The sales team uses this tool to inspect companies’ applications and websites, identify weak points in their architecture, and generate AI-powered reports based on the findings — all to support the sales process with real technical insights.

The tech stack is straightforward:

• Spring Boot 3 / Java 21
• Maven
• PostgreSQL
• Qubrid as the LLM provider for report generation
• AWS SES for email delivery
• AWS S3 for report storage”

Meet the Team:

Before I opened the AWS console, before I drew a single box on an architecture diagram — I had three conversations.

That’s the job. Not clicking. Listening.

The Product Manager told me about the budget, the timeline, and what success looks like. No fancy requirements document — just a straight answer: minimum cost, keep it running, we need it live.*

The Development Team walked me through the codebase. Spring Boot, PostgreSQL, a daily email job, and an LLM integration with Qubrid. They also mentioned — almost as a side note — that the app generates PDF reports and uploads them to S3. Almost missed that one.*

Myself. Yes, the architect also has a conversation with himself. About the network. About security. About what happens when you put an internal tool on a public subnet and the bots find it — because they always do.*

Three conversations. Three different perspectives. One architecture.

And it all started with a Slack message: ‘Can you help us go live within 3 days?

The Questions That Shape Everything:

The development team has finished their work. The code is tested, the features are done, and the pressure is on — they want to ship. You get a message on Slack: ‘Can you help us go live within 3 days?’ This is where most people make their first mistake. They open the console.

I don’t.

Before I touch anything on AWS, I need answers. Not assumptions — answers. Because every wrong assumption at this stage costs you a week of rework, a production incident, or worse, a surprise bill at the end of the month. Skip these questions, and I promise you — you won’t go live in 3 days. You’ll go live in 6 months.

These are the questions I ask. Every. Single. Time.

Capacity & Traffic

• How many concurrent users do we expect at launch? What’s the growth target for 6–12 months?

• The MIGFORA sales, is an internal application so the users will use it is only Sales engineer and they are 3 employees.*

• **What are the peak traffic patterns? **the traffic is steady load, the employee will login to it for 8 hour, 5 days in a week.
• What response time SLA do we need? 500ms
• Do we need multi-region, or single-region is enough for now? because the MIGFORA sales is an internal application, so we dont need to enable MultiAz, one AZ is more enghe

Architecture & Services

• How many services does the system have? No service only one application
• Are they monolithic or microservices? it is monolithic
• **What communication pattern between services? **invalid question because the application architecture is monolithic
• Do we need a background job/batch processing layer? Yes we have async API for generate the report using LLM and Email batch job for send reminder for the employess everyday morning at 8 oclock.

“Most architects jump straight to compute and databases. But before I touch any of that, I ask about budget — because there’s no point designing a Ferrari if the budget is a Toyota.”

The Operations & Cost should be defined with Owner or Project manager, they will give you the budget for the infrastucter. and you will build your plan depend on the budget

Operations & Cost

• What is the monthly budget envelope? because the **MIGFORA is startup company and the application is just for help the [MIGFORA](https://migfora.com)** sales engineer so the budget should be minimum possible budget to keep the application running reliably.
• Do we need centralized logging, metrics, and alerting from day one? For sure we need enable logging and metrics, to find the bugs, and any unexpected behavior.
• **What’s the CI/CD strategy? **We need this for help us to automation the deployment and update the images, but i will not mention it on the article, about the options, you can use GitHub Actions, Code pipeline and many other tools.
• What environments do we need? The best practice here, you should have at least two environments (dev, prod) and we can add staging environment, but in this article, we will focus on the production environment only.

Compute:

You should answer most of these questions after gather all the requirements

• What is the deployment unit? Depend on the above requirement the best is ECS Fargate, good cost, can work with our budget, and it is manage by AWS so need to prepare ASG or assign DevOps only for this environment. and if we go with ECS + EC2 the cost is less than ECS Fargate but we will take care about the services deploy and prepare ASG, and invest more effort in monitoring the application..
• Do we need auto-scaling? Yes we need ECS Service Auto Scaling and the ECS Farget will take care about it, the desired instance is one, and the max is 3 instances, and that is enough depend on the traffic and capacity.
• What are the scale-in/scale-out triggers? Depend on the project requirements we can scale based on CPU, and memory usage.
• What is the expected CPU/memory profile per service? *MIGFORA Sales is a Spring Boot application with light traffic — 3 internal users, standard working hours, and LLM calls that are I/O-bound rather than CPU-heavy. The bottleneck is the LLM response time, not our compute. A profile of 0.5 vCPU / 1GB RAM on Fargate is sufficient to start — we can always scale up if needed.”*

“We could save a few dollars with ECS + EC2, but we’d be trading money for time — and for a 3-person internal tool, engineer time is more expensive than the cost difference.”

Database & Storage

You should answer most of these questions after gather all the requirements

• What type of data? The application use the PostgreSQL so it is relational DB.
• **What are the read/write ratios? Do we need read replicas? *This question is not just about infrastructure — it’s about alignment. Before you make any decision, talk to the development team and ask: ‘Is your application configured to use a read replica?’ Because if you provision a single PostgreSQL instance and the code is already pointing to a replica endpoint, you’ll spend your go-live day chasing connection errors instead of celebrating the launch. I’ve seen this happen. It’s not fun. For [MIGFORA](https://migfora.com)* Sales, the answer is straightforward: no read replicas, no master/replica setup. The traffic doesn’t justify it, and the budget certainly doesn’t. A single PostgreSQL instance is enough — and everyone on the team knows it.”
• Do we need multi-AZ for HA? What’s the RTO/RPO target? the application is internal, used only by MIGFORA staff, and the budget doesn’t justify Multi-AZ
• Do we have cache? The application does not support cache.

Security & Access

In this part of questions, you should think from the Security perspective, and you should ask about the authentication, authorisation, user management, and Network isolation you should ask some questions from the development team, and you should ask your self, some question and find the answer, regarding the budget and requirements. and the problem here, at the network level, that means more traffic, possible attack, this is serious.

• Who are the users? internal employees
• How is authentication handled? (Cognito, OAuth2, SAML, Keyclock, Spring Security) Cognito
• What are the network isolation requirements? Ask yourself one critical question: does the application need access to the public internet? For MIGFORA Sales — yes. Qubrid, our LLM provider, lives outside AWS. That external dependency forces a decision: Option 1 — Private subnet + NAT Gateway: clean network isolation, but NAT Gateway adds cost that our budget simply doesn’t support. Option 2 — Public subnet: no NAT Gateway, lower cost, but now Fargate is technically reachable from the internet. Before you panic — this is manageable. Security Groups act as your firewall at the instance level, and NACLs add a second layer at the subnet level. Lock them down correctly, and your application is protected.
• We went with Option 2. Cost won — but security wasn’t compromised.
• **Do we need WAF, DDoS protection, or compliance requirements (SOC2, ISO)? **I said WAF wasn’t justified for an internal tool — then I opened CloudWatch and saw hundreds of 404s from bots I never invited. Scanners don’t care that your app is internal. They’ll find your ALB’s public DNS and probe every path they know. The real cost isn’t just security — it’s money. Every request that passes through ALB and hits your Fargate container costs you compute time. WAF sits between the internet and your ALB, killing those requests before they cost you a cent. For MIGFORA Sales, we added AWS WAF with a basic managed rule set. Best practice and budget-justified — the bot traffic made the decision for us.

Others:

After Discussion with Owner and product manager, and the Development team, they mentioned some points, such as LLM, Email, Reports ..etc, so you should find a good question to see what is missing to build full context about the project.

This is where the real architecture starts. Not from a requirements document — but from a casual mention in a meeting. ‘Oh by the way, we generate PDF reports using an LLM.’ That one sentence added S3, IAM roles, and a retention policy to my architecture. Always ask about the ‘by the ways.

• Where is the LLM hosted? is it on AWS or another 3rd party provider? Yes, we use qubrid and it is not AWS service.
• *Do we need object storage (S3) for files/reports/assets? * we use S3 to store the reports generated by the LLM.
• You mentioned a batch job for email? how you send an email? and when it is working? is the job working on the same service or another service? The batch job runs inside the same application — no separate service needed. And for email delivery, the team is using AWS SES. Important note here: new AWS accounts start in SES sandbox mode, which means you can only send emails to verified addresses until you request production access. Request it early — approval can take 24–48 hours, and you don’t want this blocking your go-live.

Conclusion:

And that’s where Part 1 ends — not at the console, not at the architecture diagram, but here. With a list of answers.

Because that’s the real work. Anyone can click through the AWS console. The architect’s job is to ask the right questions before touching anything — and now you have the framework to do exactly that.

In Part 2, we take everything we learned here and turn it into a real AWS architecture. We’ll draw the diagram, choose the services, break down the costs, and deploy MIGFORA Sales step by step — every decision explained, every cost justified.

If this article saved you from a bad architecture decision — or at least made you think twice before opening the console — share it. Someone on your team needs to read this before their next deployment.

See you in Part 2.

— Abd-alrhman Alkraien Cloud Architect & Founder, MIGFORA abdalrhman@migfora.com LinkedIn migfora.com