Comparing AWS Marketplace offerings: AMI-based vs ECS
Launching a product on a marketplace is an important step. After all, Amazon allows us not only to receive services but also to provide services using the created Amazon marketplace for interaction with the end user. This article will become the first part of a series on the features of interaction with the Amazon Marketplace from the seller’s point of view.
Definition
According to Amazon Marketplace services, the offering is distinguished by the following delivery methods:
Single AMI
You provide a unique Amazon Machine Image (AMI) tailored for your product, which contains the necessary data for initiating an Amazon Elastic Compute Cloud (Amazon EC2) instance.
Customers can employ this solitary AMI to generate Amazon EC2 instances that come pre-loaded with your product, making them instantly operational.
AMI delivered using AWS CloudFormation templates
Customers can acquire a comprehensive solution that grants them access to all the AMIs included in that product with a single purchase.
Private image build
Your product is designed to allow buyers to install it on a base gold image that aligns with their internal criteria for operating system configuration.
Container-based product or application
You provide products encapsulated within container images. These containerized products include options, which comprise a collection of container images and deployment templates designed to function harmoniously.
Data products
Using AWS Data Exchange to create data products.
Machine learning algorithms and model packages
You employ Amazon SageMaker to develop the algorithm or model package and release it on AWS Marketplace.
Software as a service (SaaS)
You can offer SaaS products with subscription-based, contract-based, or contract-with-consumption pricing models.
Professional services
You can provide professional services that complement or collaborate with other AWS Marketplace offerings.
Read more:
As we see, the methods of product delivery can be divided into:
- Those that allow formalizing a contract of interaction with the user, namely:
- Professional services
- Software as a service (SaaS)
- Those built around the PaaS service model provided by Amazon:
- Machine learning algorithms and model packages
- Data products
- Single entity, based on classic compute services:
- Container-based product or application
- Private image build
The golden image approach is a manual configuration, which carries several risks, and it differs little from the approach with AMI, except for the simplified requirements. We will consider this approach equivalent to Single AMI. - Single AMI
- Infrastructure configuration with container and template tools
- AMI delivered using AWS CloudFormation templates.
- Helm chart
It is crucial for the end user who wants to get the product to understand the type of computing on which the product will run rather than the payment model. When we go to the marketplace directly to choose a product, the product breakdown by delivery method is not clear enough, which may confuse the user. The eye turns to “Amazon Machine Image” and “Container Image”. This is precisely what we are trying to compare and understand how such products work and will be delivered.
User’s point of view
It is crucial for the end user who wants to get the product to understand not so much the payment model but the type of computing on which the product will run. When we go to the marketplace directly to choose a product, there is not a clear enough breakdown of products by delivery method, which confuses the user. The eye turns to “Amazon Machine Image” and “Container Image”. This is precisely what we are trying to compare and understand how such products work and will be delivered.
Working with AMI-based products for the end user will be similar to how the user is used to working with available AMIs from the marketplace. I have already written a detailed post about the features of working with AMI and their difference from the approach to working with images on other Cloud providers
To summarize, AMI is a region-dependent service, and accordingly, we must comply with regulatory standards such as GDPR in each region. For example, we need to duplicate the AMI accordingly or get the image ID for each version in each region. This brings specific difficulties, but this is a common procedure for any Amazon user.
An Amazon visualization of the image-based product publishing process is shown in the video.
For a container-based delivery method, delivering the product to the end user is simplified because containers are all about delivery. The ECR service has a built-in mirroring mechanism. When publishing a product, the seller can limit the product’s availability by location. The end user, in turn, gets access to the ECR, from which they have the right to deploy and update the product at any time and as much as they want within the framework of the account for which the service is purchased.
An Amazon visualization of the container-based product publishing process is shown in the video
In addition to the visual difference, the main thing for whoever chooses the delivery method will still be convenience for the end user and convenience for maintaining and ensuring security conditions for the artifact that you will deliver.
Security
AWS Marketplace upholds specific guidelines for all Amazon Machine Image (AMI) products and offerings on the platform. These policies are established to foster a secure and reliable environment for our customers.
Upon submission, all products and their associated metadata undergo a rigorous review to ensure they adhere to or surpass the current AWS Marketplace policies. These policies are subject to periodic assessment and adaptation in alignment with evolving security standards. AWS Marketplace conducts ongoing evaluations of your products to verify their compliance with any changes to the security guidelines. If products no longer meet these criteria, AWS Marketplace will request updates to your AMI product to bring it into compliance with the updated standards. Furthermore, should a newly discovered vulnerability impact the AMI, you will be asked to provide an updated AMI with the necessary patches in place.
The most important principle for preparing an AMI image is to remove any credential from the image — namely, encrypted files with passwords, access hashes, and certificates. One of the most common mistakes is trying to build an All-in-one (AIO) of a finished product, namely a Golden Image, either directly on the OS or using, for example, minikube. Which directly contradicts the requirement for this type of delivery.
That is, all configuration must be performed using active Amazon tools or, at the post-configuration stage, with init scripts.
Learn more about all the requirements and policies by the link:
In addition to the specified requirements for AMI regarding the non-use of any type of credit, assembling the container is much simpler, as the principle of microservice architecture says: one container — one service. Accordingly, any microservice package will consist of separate containers within one ECR.
The splitting by tasks improves the safety of each particle and simplifies the preparation of the product as a whole. After all, it will be much easier to update only one component.
The biggest fear of marketplace sellers is that an AMI or container may become unavailable. This often happens when users add an AMIID to IaC by hardcode. The removal of an AMI is done by the vendor responsible for the availability of the product and the product as a whole. So, if an image is compromised, a condition violation is discovered, or a new vulnerability in the image is found, Amazon only notifies the vendor and demands that the image be updated. Until you update, you will be constantly notified, but the image itself will not be deleted to not violate the integrity of the offer — all update communication. With end users, your customers, you act as a vendor.
Conclusion
To sum up summary, AMI-based products are focused on virtual machines, while container-based products leverage containerization technologies to package and run applications. The choice between the two depends on your specific use case, infrastructure requirements, and the level of control and isolation you need for your applications.
Publishing your product as an AMI base will give your users an easy start, as this is the easiest way to use the product via classic EC2 or even Lightsail.
With the container-based delivery method, the end user must have a ready-made infrastructure on Amazon, where they plan to deliver the service. That is, at least ECS activation is a prerequisite. But at the same time, containers dramatically simplify the service and delivery of the product for you as a seller. After all, you only provide access, and the terms of use are the user’s responsibility.
Here is an overview of what I encountered when choosing a product shipping method. Both AMI and ECS delivery methods have their own audience. For the successful use of your product, you will choose more than one method and combine, as I already mentioned, with the help of Helmchart or a CloudFornation template. You will also select a Professional service if the product is free of charge, and you will take the money specifically for the expertise in setting it up.
