When your Elastic Beanstalk environment stubbornly remains in "severe" state while your application functions perfectly, it's typically a health check configuration mismatch. The core symptom appears when:

[29/Nov/2017:10:07:46 +0000] "GET / HTTP/1.1" 302 356 "-" "ELB-HealthChecker/2.0"

This reveals the ELB health checker is hitting your root path (/), despite explicitly configuring it to check /news.

AWS health checks operate at multiple levels, and the most common pitfall is not realizing where the configuration actually takes effect:

1. Elastic Beanstalk Console Settings (what you've configured)
2. Load Balancer Health Check Settings (what's actually being used)
3. EC2 Security Group Rules (could block health checks)

Beanstalk environments created before November 2016 default to classic load balancers, while newer environments use Application Load Balancers. The configuration location differs:

# For ALB environments (recommended solution):
aws elasticbeanstalk update-environment \
    --environment-name your-env-name \
    --option-settings \
    Namespace=aws:elasticbeanstalk:environment:process:default,OptionName=HealthCheckPath,Value=/news

For older environments using classic load balancers, you'll need to modify through the EC2 console or CLI:

aws elb configure-health-check \
    --load-balancer-name your-elb-name \
    --health-check Target=HTTP:80/news,Interval=30,UnhealthyThreshold=2,HealthyThreshold=2,Timeout=5

Follow this diagnostic sequence:

1. Verify actual health check path:

   aws elasticbeanstalk describe-configuration-settings \
       --environment-name your-env-name \
       --application-name your-app-name

2. Check load balancer type:

   aws elasticbeanstalk describe-environment-resources \
       --environment-name your-env-name

3. Inspect security groups:

   aws ec2 describe-security-groups \
       --group-ids your-sg-id

For a Node.js application using Express, ensure your health check endpoint explicitly returns 200:

// In your Express app
app.get('/news', (req, res) => {
    // Minimal health check response
    res.status(200).json({ 
        status: 'healthy',
        timestamp: Date.now() 
    });
});

Then update your environment configuration via EB CLI:

# .ebextensions/healthcheck.config
option_settings:
  aws:elasticbeanstalk:environment:process:default:
    HealthCheckPath: "/news"

After configuration changes:

• Wait 15-30 minutes for changes to propagate
• Force an environment update if changes don't apply
• Verify through both EB console and EC2 load balancer settings

You've configured everything correctly - your Elastic Beanstalk environment shows all services operational, your application responds normally to user requests, yet AWS stubbornly reports a severe status. The health dashboard indicates 100% of requests return 3xx status codes, and examining logs confirms ELB health checks hitting your root endpoint:

[29/Nov/2017:10:07:46 +0000] "GET / HTTP/1.1" 302 356 "-" "ELB-HealthChecker/2.0"

When you modify the health check endpoint through the EB console or .ebextensions, you're actually changing the EC2-level health check, not the ELB health check. The ELB continues using the default / endpoint unless explicitly reconfigured.

Create a file named loadbalancer.config in your .ebextensions directory with this configuration:

option_settings:
  aws:elb:healthcheck:
    HealthyThreshold: "3"
    Interval: "10"
    Target: "HTTP:80/news"
    Timeout: "5"
    UnhealthyThreshold: "5"

For HTTPS environments:

option_settings:
  aws:elb:healthcheck:
    Target: "HTTPS:443/news"
    ...

After deployment:

1. Check the Load Balancer configuration in EC2 console
2. Run this AWS CLI command:

   aws elasticbeanstalk describe-configuration-settings \
     --application-name YourAppName \
     --environment-name YourEnvName

3. Monitor CloudWatch metrics for HealthyHostCount

If issues persist:

• Ensure your security group allows traffic from the ELB (typically the default security group)
• Check route tables for proper internet gateway configuration
• Verify your application returns proper headers for /news endpoint

Remember that configuration changes may take 5-10 minutes to propagate through AWS systems.