Amazon Web Services (AWS) Software and Solutions

Amazon Linux is used as the primary operating system for running containerized backend services on EC2 and ECS. Amazon Linux 2023 serves as a base image for Docker containers and as the OS for host instances. With a mix of Graviton3 and x86-64 instances, having one OS optimized for both architectures without any extra configuration has been a real advantage.

When migrating the core API layer from Amazon Linux 2 to Amazon Linux 2023, average container cold start time dropped by around 25%. This improvement was largely thanks to boot time optimization in AL2023, with kernel configuration and cloud-init improvements making a noticeable difference. Kernel live patching allows critical fixes to be applied without rebooting instances, which has been significant for uptime requirements.

Amazon Linux 2023 is also used for data processing workers that run on Spot Instances, and the version locking feature has been especially useful in that context. All instances can be pinned to a specific repository snapshot so that a package update in deployment does not cause inconsistencies across the fleet. SELinux enforcing mode is leveraged to meet internal compliance requirements without having to write custom hardening scripts.

Three features stand out as the best that Amazon Linux offers. Kernel live patching is a game-changer for availability because being able to patch vulnerabilities without a reboot has been invaluable. The repository version locking provides deterministic, reproducible deployments. SELinux-by-default posture required some adjustment at first, but having a security-hardened baseline out of the box means less time spent on custom security configuration.

Kernel live patching alone probably saves the on-call team around ten to fifteen hours a month that previously went into scheduling maintenance windows for kernel updates. Version locking helps eliminate a whole class of deployment inconsistency bugs that were caused by package drift across environments. SELinux being pre-configured means the security team signs off on new deployments faster, whereas previously there was a back-and-forth that could delay releases by days.

The biggest organizational impact from Amazon Linux has been on deployment confidence and release velocity. Before AL2023, OS-level inconsistencies caused roughly twenty percent of production incidents. After standardizing on AL2023 with version locking and consistent AMI builds, that number dropped significantly. This also helped pass the SOC 2 audit faster because the security defaults were already aligned with what auditors were looking for. OS-related incident response time was reduced by about forty percent after moving to AL2023. Kernel live patching eliminated roughly six planned maintenance windows per year per cluster, which translates to real savings in engineering time and avoided customer downtime. Base AMI build time was trimmed by around thirty percent because there is no longer a need to layer on as many post-install hardening scripts.

The migration from Amazon Linux 2 to AL2023 was not completely painless, and some packages that were relied on were not available in the core repository and required using SPL, the Supplementary Package Repository, which comes with around-the-clock support. The documentation on SPL limitations could be clearer upfront so teams do not discover it mid-migration. SELinux enforcement, while beneficial for security, requires some ramp-up time for teams that have not worked with it before.

Better inline documentation with the OS itself would be valuable, especially clearer man pages for Amazon-specific tooling like the Amazon Linux Extras equivalent in AL2023. Debugging SELinux denials can be tricky without additional tools, so shipping something like audit2why or better integration with CloudWatch for SELinux logs out of the box would be a nice quality-of-life improvement.

I have been working with Amazon Linux for about three years, and the migration to Amazon Linux 2023 was completed roughly a year and a half ago.

Stability has been excellent with Amazon Linux. In about eighteen months of production use across hundreds of instances, there have been zero OS-level crashes or kernel panics. The version locking feature contributes significantly to this, and the environment is not caught off guard by a package update breaking something in production. Quarterly updates follow a predictable schedule, which makes release planning much more orderly.

Amazon Linux scales very well. The environment has grown from tens to hundreds of EC2 instances without any OS-level bottlenecks. Boot time optimization means new instances come online faster during auto-scaling events, which directly improves response during traffic spikes. There have been no issues running it across multiple AWS regions with consistent behavior everywhere.

AWS Wickr is used for end-to-end encrypted messaging, voice and video calls, and file sharing. The main advantage that I appreciated about AWS Wickr is that no one is able to see the message regardless of the sender and receiver.

A specific example of how my team uses AWS Wickr in our daily workflow is that previously we shared logs and screenshots directly over Teams, but with AWS Wickr, we can be assured that the developers, QAs, and PMs can discuss features, bugs, and releases securely, with no risk of leaks when sharing logs, screenshots, or test builds.

AWS Wickr is used for sharing logs and crash reports, sending test builds, secure calls, and screen sharing, and it has been helpful.

The best features AWS Wickr offers are end-to-end encryption, admin controls, compliance and retention policies, and user management. It fits the need for secure internal communication. Of those features, I find myself relying on the end-to-end encryption the most.

During the setup of AWS Wickr, I created the application from the AWS console, assigned the admin IT roles, and configured the user provisioning. What I appreciated was the easy onboarding, role-based access, and secure authentication. I set up different roles including mobile dev, backend, QA testing, and release management, which freed me from all the risk of release leaks.

AWS Wickr has positively impacted the organization as the features being used have made us confident that the resources we share are not going out of the organization and are not being leaked. AWS Wickr was rolled out to teams including mobile, QA, and product, deploying Wickr apps on iOS, Android, and macOS, and onboarding teams with usage guidelines, security best practices, and guidelines for shared data. It has been beneficial.

AWS Wickr was not embedded directly into the mobile app; instead, it was used as a secure internal collaboration layer for the development and operation teams, which supported secure coordination around mobile development, testing, and releases.

AWS Wickr has been used for the past three months and has been really great.

During the setup of AWS Wickr, I created the application from the AWS console, assigned the admin IT roles, and configured the user provisioning. What I appreciated was the easy onboarding, role-based access, and secure authentication.

Currently, while using AWS Wickr, I have not found any other app in the marketplace that provides the same features, so this is the best option.

My advice to others looking into using AWS Wickr is that all that is needed is the integration part; if integration is sorted, then just create rooms in the AWS console and start using it. The difference will be apparent. I would rate this product a 9 out of 10.