docs: document AWS requirements (#2589)

* docs: document AWS requirements

* fix: typo

* fix: agent directories must belong to root (#2590)

* chore: store agent pat into the metadata struct of the agent package

* chore: create agent directories for UNIX-based agent installers

* bump stack version 8.4.0-df27a645 (#2591)

Co-authored-by: apmmachine <infra-root-apmmachine@elastic.co>
Co-authored-by: Manuel de la Peña <mdelapenya@gmail.com>

* bump stack version 8.4.0-3525aaf7 (#2597)

Co-authored-by: apmmachine <infra-root-apmmachine@elastic.co>

* Add test scenario for elastic agent tags (#2552)

* add flags

* gitignore

* gitignore

* typo

* quotes

* remove quotes

* remove restart

* Update e2e/_suites/fleet/fleet.go

Co-authored-by: Manuel de la Peña <social.mdelapenya@gmail.com>

Co-authored-by: Manuel de la Peña <social.mdelapenya@gmail.com>

* docs: improve docs about adding a new platform

* docs: better explained that there are more files

Co-authored-by: apmmachine <58790750+apmmachine@users.noreply.github.com>
Co-authored-by: apmmachine <infra-root-apmmachine@elastic.co>
Co-authored-by: Mariana Dima <mariana@elastic.co>
(cherry picked from commit bea0ea7)

.ci/README.md

@@ -26,6 +26,22 @@ It's possible that a consumer of the e2e tests would need to define a specific l
     - **tags**: a Gherkin expression to filter scenarios by tag. It will drive the real execution of the tests, selecting which feature files and/or Cucumber tags will be added to the current test execution. An example could be `linux_integration` or `running_on_beats`. For reference, see https://github.com/cucumber/godog#tags. Required.
     - **platforms**: a list of platforms where the tests will be executed. Valid values are already declared under the `PLATFORMS` object, using the key of the platform as elements in the list. I.e. `["centos8_arm64", "centos8_amd64", "debian_arm64", "debian_amd64", "sles15"]`. Required.
 
+### Adding a new supported platform
+
+You could be insterested in adding a new operative system in a specific architecture (AMD/ARM)
+
+1. Look up AWS community AMIs in the Ohio (`us-east-2`) region. Take a note on its AMI ID and the default use, as you'll need them later on.
+2. Add a new entry in the `.e2e-platforms.yaml` file, following the same structure, as described above. The default user of the instance is very important, as it's used to log in in the remote machine once created by the tests.
+3. Select an AWS machine type for the new platform, using the existing platforms file as a reference. Our team is actively checking how much cloud resources are consumed by the tests, so please consider using a machine type that already exists.
+
+> If you need a machine type that is bigger or powerful, please open a discussion with us so we can understand your needs.
+
+4. Make sure you install the required software dependencies using Ansible. Please take a look at [this file](./ansible/tasks/install_deps.yml). You will find in it the package manager commands and specific filters for the different OS families that are supported by Ansible.
+
+> It's very likely that the new platform is already covered, as there are tasks for Debian/Ubuntu, CentOS (Fedora, RedHat), and Oracle Linux.
+
+5. Add the new supported platform to the test execution, as described above: open all the test descriptors (i.e. `./.e2e-tests-*.yaml`) and add your new platform to the scenarios you are interested in, as a new platform in the `platforms` array.
+
 ## Running a CI Deployment
 
 ### Prereqs
@@ -49,6 +65,19 @@ But you must first understand that there are two types of Cloud machines:
 1) the VM running the stack, and 
 2) the VMs running the actual tests, where the Elastic Agent will be installed and enrolled into the stack.
 
+#### Running the build scripts outside the Elastic Observability AWS account
+
+In the case you are running the scripts outside the "Elastic Observability" AWS account, please fulfill this requirements before you start creating the instances:
+
+1. Use `us-east-2` (Ohio) as your default AWS region. All the community AMIs that we use are hosted there.
+2. Create a "Security Group" named `e2e`. This security group will allow remote access to certain ports in the remote instances we are creating. In this security group please use `0.0.0.0/0` as the Source for the following ports:
+   - HTTP 80
+   - HTTPS 443
+   - SSH 22
+   - Elasticsearch 9200
+   - Kibana 5601
+   - Fleet Server 8220
+
 ### Create and configure the stack VM
 
 This specialised VM starts Elasticsearch, Kibana and Fleet Server using Docker Compose, but instead of invoking the compose file directly, it uses the test framework to do it. Why? Because we need to wait for Elasticsearch to be ready and request an API Token to be passed to the Fleet Server container. And [we do this with code](https://github.com/elastic/e2e-testing/blob/4517dfa134844f720139d6bab3955cc8d9c6685c/e2e/_suites/fleet/fleet.go#L631-L748).