What is our primary use case?
We use Amazon ECS with ECS-Optimized Amazon Linux AMIs to host our microservices. Our AI-powered services, such as resume parsing and the Job Grabber, run as independent microservices within ECS.
Each microservice is exposed on a dedicated port (for example, 5000 for resume parsing and 5001 for other AI services), allowing us to deploy, scale, and manage them independently. This architecture provides better resource utilization, scalability, and reliability, particularly for document parsing and other AI workloads.
How has it helped my organization?
Using ECS-Optimized Amazon Linux for our Amazon ECS workloads has improved the stability, performance, and operational efficiency of our microservices platform. It provides a secure, AWS-optimized environment that simplifies container deployment and management.
For our AI-driven microservices, including resume parsing and document processing, we have experienced:
- Improved application reliability and consistent performance.
- Faster deployment and simplified infrastructure management.
- Better resource utilization for containerized workloads.
- Easier scaling to handle varying document processing volumes.
- Reduced operational overhead through AWS-managed optimizations and regular security updates.
Overall, ECS-Optimized Amazon Linux has enabled us to operate a reliable, scalable, and cost-effective container platform for our AI and document processing services.
What is most valuable?
Using ECS-Optimized Amazon Linux has significantly improved the performance, scalability, and cost efficiency of our containerized microservices compared to running workloads on traditional EC2 instances.
One of the biggest advantages has been automatic scaling. As application traffic increases, Amazon ECS automatically launches additional tasks based on CPU and utilization metrics, enabling our AI services, such as resume parsing and document processing, to handle higher workloads without impacting performance. When traffic decreases, the task count is automatically reduced, ensuring we only pay for the resources we actually use.
This dynamic scaling has helped us achieve approximately 40–50% savings in our infrastructure costs compared to a fixed-capacity EC2 deployment.
From an operational perspective, ECS has also improved our service reliability. Since adopting ECS-Optimized Amazon Linux, we have maintained high availability with no production downtime attributable to infrastructure scaling.
We also leverage Amazon CloudWatch to monitor CPU utilization and other critical metrics. Automated alerts are sent through Amazon SNS via email and SMS whenever resource utilization crosses predefined thresholds, allowing our engineering team to proactively investigate and resolve potential issues before they impact customers.
In addition, we have built an internal monitoring portal that aggregates application logs, access logs, error logs, and performance metrics. This provides real-time visibility into system health, API response times, and resource utilization, enabling us to quickly identify bottlenecks and optimize performance.
To further protect our platform, we have implemented automated traffic controls that detect unusually high request rates from individual IP addresses. Requests exceeding our defined thresholds are temporarily blocked, helping safeguard our services from abuse and ensuring consistent performance for legitimate users.
Overall, ECS-Optimized Amazon Linux has provided a highly scalable, reliable, and cost-effective platform for running our production microservices while significantly reducing operational overhead and infrastructure costs.
What needs improvement?
While ECS-Optimized Amazon Linux has provided significant benefits in terms of scalability and cost optimization, we have encountered a few operational challenges.
One limitation is application-level debugging. Compared to traditional EC2 instances, troubleshooting in ECS can be more complex because containers are ephemeral. Without centralized observability tools, it is more difficult to pinpoint the exact source of an issue, such as the specific line of code, request, or service responsible for an error or performance bottleneck. To address this, we have implemented our own centralized logging and monitoring solution to improve visibility into application behavior.
Another consideration is resource sizing. Our microservices have relatively modest memory requirements, so the available ECS task configurations are sufficient for our workloads. However, for large, monolithic applications with higher memory and compute requirements, scaling can require a different architecture or deployment strategy. Since our platform is built using independently scalable microservices, this has not been a significant limitation for our environment.
For how long have I used the solution?
What do I think about the stability of the solution?
As for the stability of the product, we do not see any downtime; ECS-Optimized Amazon Linux Support by SupportedImages is pretty stable.
How are customer service and support?
We do have account managers for our account with ECS-Optimized Amazon Linux Support by SupportedImages. Whenever we need any help, we are just directly contacting them. They are going to help us. Currently, we are not taking any help as all services are good.
How was the initial setup?
In the initial days, we faced some problems with installation of ECS-Optimized Amazon Linux Support by SupportedImages, but we tried once and everything looked good. We have prepared the installation documentation, and whenever we require it, we will go through the documentation and get it done. It will not take much time; hardly 30 minutes to implement any ECS service.
What other advice do I have?
For the updates specifically, we are using New Relic. This is one agent we installed on the API side. This agent is going to keep track of all the latency issues and high time-consuming API requests. Ours is a SaaS-based application, so the frontend and backend are completely different. With the help of this New Relic, we are able to see where the problem is and how we can improve the situation based on the number of requests or whether it is based on the SQL side, like an indexing problem. We are able to see a lot of traces by using this New Relic agent.
We assess ECS-Optimized Amazon Linux Support by SupportedImages positively for the pre-configured environment for deploying applications. We are using a webhook. By using Python, we built some internal applications where we can use that webhook trigger especially for production purposes. We are validating and reviewing code, and after that, we are manually doing this production deployment, especially from the backend. Coming to the frontend, we are using Bitbucket code pipelines.
For the data protection features, everything we are managing through tokenization. Without having a proper authorization token, no one can access any data. Authorization is one aspect, and we enabled MFA for almost all our users. They need to whitelist their IPs. We are using AWS cloud, and by default, the AES encryption and decryption mechanism is already applied to all our data. At the same time, we are using the HTTPS protocol. There is no option to use HTTP.
The biggest challenge is to understand the process of ECS-Optimized Amazon Linux Support by SupportedImages.
We used to receive notifications from AWS regarding future updates. Whenever we require it, or whenever there are any changes, we automatically review those changes and replicate them before the deadline. We are good in terms of that with ECS-Optimized Amazon Linux Support by SupportedImages.
We rate this product a 10 out of 10.
Which deployment model are you using for this solution?
Hybrid Cloud
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Amazon Web Services (AWS)