Bottlerocket FAQs

AWS provides an Amazon Machine Image (AMI) for Bottlerocket that you can use to run on supported EC2 instance types from the AWS console, CLI, and SDK. AWS will provide Bottlerocket builds that come pre-configured for use with EKS, ECS, VMware, and EKS Anywhere on bare metal. You can use the orchestrator to update and manage the OS with minimal disruptions without having to log-in to each OS instance.

You can launch containerized applications on a Bottlerocket instance through your orchestrator. You can also use include your software and startup scripts into Bottlerocket during image customization. Refer to Bottlerocket documentation for details.

You can deploy and service Bottlerocket using the following steps:

• Step 1: You can deploy Bottlerocket the same way as any other OS in a virtual machine. On AWS, you can deploy Bottlerocket to EC2 instances from the AWS Management console, via API or via AWS CLI. You need to provide configuration details via user data for each Bottlerocket instance to enroll into an Amazon EKS cluster.
• Step 2: To operate Bottlerocket with your orchestrator, you will need to deploy an integration component to your cluster. The integration component enables the orchestrator to initiate reboots, rollback updates, and replace containers in a minimally disruptive manner for rolling upgrades.

Bottlerocket updates are automatically downloaded from pre-configured AWS repositories when they become available. A reboot of Bottlerocket is needed to apply updates and can be either manually initiated or managed by the orchestrator, such as Kubernetes. You need to select the appropriate mechanism to handle reboots based on the tolerance of your applications to reboots and your operational needs. If your application is stateless and resilient to reboots, reboots can be performed immediately after updates are downloaded. If you are running stateful traditional workloads (e.g., databases, long-running line-of-business apps, etc.) in containers which not resilient to reboots, you will need to ensure that state is preserved before reboots.

Bottlerocket reboots can be managed by orchestrators by draining and restarting containers across hosts to enable rolling updates in a cluster to reduce disruption. Updates to Bottlerocket can also be safely rolled back in case of failures occur via supported orchestrators or with manual action. Refer to Bottlerocket documentation for steps to deploy and use the “Bottlerocket update operator” on Amazon EKS clusters and on Amazon ECS clusters.

AWS-provided builds of Bottlerocket builds follow a “major.minor.patch” semantic versioning scheme. Minor versions of Bottlerocket will be released multiple times in the year with changes such as support for new EC2 platforms, support for new orchestrator agents, and refreshes to open-source components. The version scheme will indicate whether the updates contain breaking changes.

A variant is a build of Bottlerocket that supports different features or integration characteristics. AWS provides Bottlerocket variants that support Kubernetes worker nodes in EC2, in VMware, and on bare metal. AWS also provides Bottlerocket variants for ECS in EC2. You can see the list of all AWS-provided variants.

Yes. Bottlerocket has variants that supports NVIDIA GPU-based Amazon EC2 instance types on Amazon Elastic Container Services (Amazon ECS) and on Kubernetes worker nodes in EC2. Please review the blog posts on how to use these variants on ECS and on EKS.

Bottlerocket feature releases (minor versions, e.g. 1.10.0, 1.11.0) generally happen with a 6 to 8 week cadence. Bug and CVE fixes (patch versions, e.g. 1.10.1, 1.11.1) happen as necessary, and the release cadence depends on the severity of the issue. Please refer to the CHANGELOG that shows all Bottlerocket releases with their timelines.

AWS-provided builds of Bottlerocket will receive security updates, bug fixes, and are covered under AWS support plans. The period of support for a given build will depend on the version of the container orchestrator being used. Bottlerocket builds will be deprecated when the corresponding orchestrator version is deprecated. For example, we no longer support aws-k8s-1.19, which is the Bottlerocket build for Kubernetes 1.19. This is in line with Kubernetes 1.19 no longer receiving support upstream. We recommend that customers replace aws-k8s-1.19 nodes with a more recent build as supported by your cluster. In addition, community support for Bottlerocket is available on GitHub where you can post questions, feature requests, and report bugs. Details on releases and fixes to CVEs will be posted in the Bottlerocket changelog.

The current EKS-optimized AMIs that are based on Amazon Linux will be supported and continue to receive security updates. See EKS optimized Amazon Linux 2 AMI and ECS optimized AMI for details on support lifetimes.

Bottlerocket builds from AWS are supported on HVM and EC2 Bare Metal instance families with the exception of the F, G4ad, and INF instance types.

Yes. Please refer to this blog post for more details.

AWS provides pre-tested updates for Bottlerocket that are applied in a single step. These updates can also be rolled back in a single step to a known good state. As a result, “botched” updates that can leave the system unusable because of inconsistent states that need manual repair do not occur with Bottlerocket. With single-step atomic updates, there is lower complexity, which reduces update failures.

Updates to AWS-provided builds of Bottlerocket are automatically downloaded from pre-configured AWS repositories when they become available. A reboot of Bottlerocket is needed to apply updates and can be either manually initiated or managed by the orchestrator, such as Kubernetes. You need to select the appropriate mechanism to handle reboots based on the tolerance of your applications to reboots and your operational needs. If your application is stateless and resilient to reboots, reboots can be performed immediately after updates are downloaded. If you are running stateful traditional workloads (e.g., databases or long-running line-of-business apps) in containers which are not resilient to reboots, you will need to ensure that the state is preserved before the reboot.

Bottlerocket reboots can be managed by orchestrators, such as Kubernetes, that drain and restart containers across hosts to enable rolling updates in a cluster to reduce disruption. By default, Bottlerocket will auto-update to the latest secure version upon boot. Updates to Bottlerocket can also be safely rolled back in case of failures via supported orchestrators or with manual action.

The integrations with orchestrators, such as Kubernetes, help make updates to Bottlerocket minimally disruptive. During the update process, the orchestrator drains containers on hosts being updated and places them on other vacant hosts in the cluster. The orchestrator also rolls back the hosts to the previous version of Bottlerocket if updates fail.

Bottlerocket can run all container images that meet the OCI Image Format specification and Docker images.

Yes, you can move your containers across Amazon Linux 2 and Bottlerocket without modifications.

If your operational workflows to run containers involve installing software on the host OS with yum, directly ssh-ing into instances, customizing each instance individually, or running a third-party ISV software that is not containerized (e.g., agents for logging and monitoring), Amazon Linux 2 may be a better fit. Bottlerocket is optimized to run and manage large containerized deployments and does not easily allow many of these activities.

You can run an “admin container” using Bottlerocket's API (invoked via user data or AWS Systems Manager) and then log in with SSH for advanced debugging and troubleshooting with elevated privileges. AWS provides the admin container that allows you to install and use debugging tools like sosreport, traceroute, strace, tcpdump. The act of logging into an individual Bottlerocket instance is intended to be an infrequent operation for advanced debugging and troubleshooting.

An admin container is an Amazon Linux container image that contains utilities for troubleshooting and debugging Bottlerocket and runs with elevated privileges. Please refer to the details on how to use the admin container.

Bottlerocket enables automatic security updates and reduces exposure to security attacks by including only the essential software to host containers. Bottlerocket uses containers control groups (cgroups) and kernel namespaces for isolation between containers. It also comes with Security-Enhanced Linux (SELinux) in enforcing mode and seccomp. eBPF in the kernel reduces the need for kernel modules for many low-level system operations by providing a low-overhead tracing framework for tracing I/O, file-system operations, CPU usage, intrusion detection, and troubleshooting. Bottlerocket uses device-mapper-verity (dm-verity), a Linux kernel feature which provides integrity checking to help prevent rootkits that can hold onto root privileges.

There are multiple options to collect logs from Bottlerocket nodes. For example, you can use CloudWatch Container Insights or Fluent Bit with OpenSearch.

Yes, Bottlerocket has a CIS Benchmark. The CIS Benchmark is a catalog of security-focused configuration settings that help Bottlerocket customers configure or document any non-compliant configurations in a simple and efficient manner. The CIS Benchmark for Bottlerocket includes both Level 1 and Level 2 configuration profiles and can be accessed from the CIS website.

No, Bottlerocket does not yet have a FIPS certification. FIPS certification for Bottlerocket is on our roadmap, but, at this moment, we do not have an estimate when it will be available.

Yes, you can achieve PCI compliance using Bottlerocket. The optimized feature set and reduced attack surface means that Bottlerocket instances require less configuration to satisfy PCI DSS requirements. The CIS Benchmark for Bottlerocket is an excellent resource for hardening guidance, and supports customer requirements for secure configuration standards under PCI DSS requirement 2.2. Customers can also leverage Fluent Bit to support customer requirements for operating system level audit logging under PCI DSS requirement 10.2. AWS publishes new (patched) Bottlerocket instances periodically to help customers meet PCI DSS requirement 6.2 (for v3.2.1) and requirement 6.3.3 (for v4.0).

Yes, Bottlerocket is an HIPAA-eligible feature authorized for use with regulated workloads for both Amazon EC2 and Amazon EKS. For configuration guidance pertaining to Amazon EKS, please refer to this whitepaper for additional information.

Please refer to the guide on hardening and validating Bottlerocket when it is used with Amazon EKS.

Yes. Amazon Inspector is a vulnerability management service that scans EC2 and container workloads for software vulnerabilities and unintended network exposure. Amazon Inspector leverages the AWS System Manager (SSM) agent to scan for vulnerabilities. In Bottlerocket hosts, the SSM agent runs within the control host container, so you need to make sure it is enabled in your hosts.

Bottlerocket code is licensed under Apache 2.0 OR MIT. Amazon wrote its Bottlerocket in Rust, so we’ve chosen a license that fits into that community easily. Underlying third party code, like the Linux kernel, remains subject to its original license.

Bottlerocket is released as an open source project hosted on GitHub. Design documents, code, build tools, tests, and documentation will be hosted on GitHub. We will use the GitHub’s bug and feature tracking systems for project management. You can view and contribute to Bottlerocket source code using standard GitHub workflows.

You can fork the GitHub repository, make your changes and follow our building guide.

Yes. If you build Bottlerocket from unmodified source and redistribute the results, you may use “Bottlerocket” only if it is clear in both the name of your distribution and the content associated with it that your distribution is your build of Amazon’s Bottlerocket and not the official build, and you must identify the commit from which it is built, including the commit date.

You must modify the os-release file to either use Bottlerocket according to this Policy or to remove the Bottlerocket Trademarks. This can be done by modifying both packages/release/release.spec and tools/rpm2img. Names of the system root (/x86_64-bottlerocket-linux-gnu/sys-root), partition labels, directory paths, and service file descriptions do not need to be changed to comply with this policy.

If you are aware of confusing or misleading use or other misuse of the Bottlerocket Trademarks, you may contact us as described above at trademarks@amazon.com so we can investigate further.