AWS OpsWorks无法注册跨VPC新EC2实例故障求助

Let's walk through the issues you're facing and tackle each potential root cause step by step:

1. Fix the SNIMissingWarning & Outdated Agent Dependencies #

The error log shows you're using an extremely old OpsWorks agent release (20160913111958_3440) paired with aws-sdk-v1-1.65.0. This outdated SDK doesn't support modern TLS/SNI requirements, which is almost certainly triggering the SNIMissingWarning and breaking API communication.

• Action: Upgrade your OpsWorks agent to the latest version with these commands:

  sudo yum update -y opsworks-agent
  sudo service opsworks-agent restart
  

  After upgrading, re-run the registration command to see if the warning and credential error clear up.

2. Diagnose the MissingCredentialsError (Even With AWS CLI Configured) #

You mentioned setting up AWS CLI credentials, but the OpsWorks agent uses a separate credential flow when you use --use-instance-profile. Here's what to verify:

a. Check Instance IAM Role Permissions #

Make sure the EC2 instance's attached IAM role has the minimum required permissions for OpsWorks registration:

• opsworks:RegisterInstance
• opsworks:DescribeStacks
• iam:PassRole (if your stack uses a service role)

You can start by attaching the managed policy AWS OpsWorks Register Instance Policy, then refine permissions later if needed.

b. Validate Instance Metadata Service (IMDS) Access #

The agent fetches credentials from the EC2 IMDS. Test access with these commands:

# Check if an IAM role is attached to the instance
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Replace [ROLE_NAME] with the output from the first command
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/[ROLE_NAME]

If you get a valid JSON response with AccessKeyId, SecretAccessKey, and SessionToken, metadata access works. If not:

• Ensure IMDS isn't disabled in your instance settings (check "Metadata options").
• Confirm your subnet's security group allows outbound traffic to 169.254.169.254 on port 80.

3. VPC Connectivity Checks (Your Suspicions Are On Target!) #

Since the instance is in a different VPC, connectivity to AWS OpsWorks APIs is critical:

• Internet Access: For private subnets, confirm a NAT Gateway is attached to the subnet's route table to allow outbound HTTPS (443) traffic. For public subnets, make sure an Internet Gateway is present.
• Test API Reachability: Run this command to check if the instance can reach the OpsWorks endpoint:

  curl https://opsworks.us-east-1.amazonaws.com
  

  A successful response (even an authentication error) means connectivity works. If you get a timeout or connection refused, your VPC/security group routing is blocking traffic.
• VPC Endpoints (Optional): If you want to avoid public internet access, create an OpsWorks VPC Endpoint in your VPC. This lets the instance communicate with OpsWorks via AWS's private network.

4. Debug With Explicit Credentials (Temporary Test) #

To rule out IAM role issues quickly, try registering with explicit credentials (only for testing, not production):

aws opsworks register --access-key YOUR_ACCESS_KEY --secret-key YOUR_SECRET_KEY --infrastructure-class ec2 --region us-east-1 --stack-id 50aebe6e-5aa1-4d2e-801c-b50ff1f22884 --local

If this succeeds, the problem is definitely with your instance's IAM role or metadata access. If it still fails, focus on agent version or VPC connectivity issues.

内容的提问来源于stack exchange，提问作者user11896097