Vladimir Rozhkov

Пишете матчер на все и разрешаете его всем. Нужные эндпоинты – закрываете, например:

@Override
    protected void configure(final HttpSecurity http) throws Exception {
        http
            .sessionManagement()
                .sessionCreationPolicy(SessionCreationPolicy.STATELESS).and()
            .csrf().disable()
            .exceptionHandling().and()
            .anonymous().and()
            .servletApi().and()
            .authorizeRequests()
            .antMatchers(HttpMethod.GET, "/api/**").permitAll()
            .antMatchers(HttpMethod.POST, "/api/**").permitAll()
            .anyRequest().authenticated().and()
            .addFilterBefore(
                    new AuthFilter(),
                    UsernamePasswordAuthenticationFilter.class
            );
    }

Зачем хранить билды в git? Выкладывайте их куда-нибудь.

1. Смысл использовать AWS есть. Но в первую очередь ваше приложение само должно быть масштабируемым – сервер должен быть stateless и не хранить никаких данных локально (в том числе пользовательские сессии), на AWS должен быть настроен ELB который будет распределять трафик между вашими инстансами. Если все упирается в базу данных – тогда для нее можно сделать read-реплики, например.

2. T2 инстансы не умеют масштабироваться сами по себе. T2 это самые простые машинки, которые имеют ограничения по времени максимальной нагрузки на них – в терминах амазона это назвается CPU Credits. Cмысл в том, что вы можете давать нагрузку выше 20% (для разных типов этот порог разный) только в течение определенного времени (час, два, больше – опять же, для разных инстансов это время различается), после истечения которого ваш инстанс опустится до базовой производительности (то есть, довольно низкой).
Короче говоря – T2 держит пики, но не держит длительную нагрузку.

Для динамического масштабирования вы можете с помощью Cloudwatch ловить увеличение количества потребляемых ресурсов и давать команду ASG поднять еще инстансов (или опустить, если нагрузка упала). Можно делать то же самое используя свой собственный мониторинг и AWS API для управления облаком.

1. VPC как правило содержит публичные и приватные подсети. Посмотрите какие есть в вашей и где находятся инстансы к которым вы хотите подключиться.
2. Если публичных подсетей нет, то вам нужно добавить таковую
3. Для подключения к инстансам вам нужен ключ. Если ключа у вас нет и других способов подключения вы не настраивали (например, самостоятельно конфигурировали sshd на инстансе) – то к инстансу вы подключиться не сможете, даже если сможете его пингануть
4. Если ваш инстанс находится в приватной подсети, вам нужно создать новый инстанс (пойдет самый простой t2.nano) в публичной подсети и настроить security groups для целевого инстанса чтобы был открыт доступ к нужым портам из публичной подсети
5. Логинитесь на ваш свежесозданный инстанс и уже с него – на целевой.
6. Если ваш целевой инстанс находится в публичной подсети – тогда у него есть публичный ІР адрес, к которому вы можете подключиться (нужно только настроить security group чтобы открыть порты для внешнего доступа)

Верифицируйте домен и запросите увеличение лимита отправляемых писем – тогда вам не нужно будет делать верификацию каждого адреса и вы сможете отправлять письма в рамках Free Tier.

Верификация адресов должна быть проведена для того чтобы вы имели адрес для отправки (отправлять можно только с верифицированного адреса) или тестировали рассылки в сендбоксе.

AWS не пересобирает образ, AWS рестартует контейнер если тот завершился.
Ваш контейнер скорее всего писал логи в stdout.
Зайдите на инстанс по SSH, затем сделайте docker ps -a, там можно будет увидеть только что завершенный контейнер. Раньше AWS их оставлял, но сейчас, в связи с обновлением ECS-агента, судя по всему, он их подчищает, поэтому свой контейнер вы можете не увидеть.
Если же старый контейнер еще остался то все равно можно посмотреть его логи – docker logs <container_id>

Тем не менее, желательно прикрутить внешний сервис логирования, например LogEntries, Papertrail или другие подобные системы.

Наверное вопрос уже не акутален, но если сами задачи выполняются достаточно быстро, то я бы крайне рекомендовал AWS Lambda. Сейчас они добавили туда крон + возможность прокидывать переменные окружения. Придется немножко повозиться с CI, но в итоге при определенных условиях может получиться бесплатное решение.

А так, именно скедулеров для джоб толком и нет. Я в итоге начал писать свой маленький, многи тоже так делают, потому что решения типа Mesosphere или других довольно тяжеловесны и сложны в настройке и поддержке.

Не совсем IDE, но Atom

А чем не устраивает использование .ipr файла для хранения проектных метаданных?